From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <9front-bounces@9front.inri.net>
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4
Received: from 9front.inri.net (9front.inri.net [168.235.81.73])
	by inbox.vuxu.org (Postfix) with ESMTP id E36CF24F17
	for <ml@inbox.vuxu.org>; Sun, 10 Nov 2024 18:09:40 +0100 (CET)
Received: from berlin.kesim.org ([159.69.178.44]) by 9front; Sun Nov 10 12:08:07 -0500 2024
Received: (qmail 333481 invoked by uid 112); 10 Nov 2024 17:08:05 -0000
Received: from unknown (HELO kesim.org) (oec@2a02:8106:4:4000:2c4d:7ae9:934:d6bc)
  by 2a01:4f8:c010:1226::1 with ESMTPA; 10 Nov 2024 17:08:05 -0000
Date: Sun, 10 Nov 2024 18:08:03 +0100
From: =?utf-8?B?w5Z6Z8O8cg==?= Kesim <oec-9front@kesim.org>
To: 9front@9front.org
Message-ID: <fdudxdyfamk45yg6woaqmtbrlmtpixfuagtkqruzvawlbkgbi5@5vxkqirfcfsz>
References: <z4tnp5k6zxtcln2pwhrubrfz4ukh5ofgspcackc44egm5msuqd@4mm3yoihlfgm>
 <B5DDC17F50D7866DBD4120AB14211091@pheist.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <B5DDC17F50D7866DBD4120AB14211091@pheist.org>
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: event-scale information factory 
Subject: Re: [9front] Problem with authentication on file server
Reply-To: 9front@9front.org
Precedence: bulk

Hi Tobias,

Thank you for your input, TIL about `history -D`.

But as it turns out, the issue was on the client side:

There was a spurious `factotum` left running from an earlier experiment
with 9pfs on my linux machine, and drawterm tried to retrieve the
(non-existent) key material from /tmp/ns.user.:0/factotum.

Killing the factotum process on linux resolved the issue.  (However,
getting factotum showing a prompt on linux is also worth an experiment
at some point).

Cheers,
oec


Thus spake theinicke@pheist.org (theinicke@pheist.org):

> Hi,
> 
> not really an expert, but usually altering /lib/ndb/local might require to
> execute auth/wrkey again, depending on what has changed...
> 
> Also maybe you want to history -D /lib/ndb/local to see what you changed
> exactly?
> 
> And finally you could remove /adm/keys and recreate them, ex. using
> auth/changeuser (if anything else fails and no one has a better idea :)
> 
> Good luck,
> Tobias Heinicke
> 
> 
> Quoth Özgür Kesim <oec-9front@kesim.org>:
> > Hi,
> > 
> > I have a 9front file+cpu+auth server on my desk that I occasionally use
> > for some experiments.  About a week ago I did a sysupdate on the machine
> > and some changes to ndb/local (IIRC, only adding an authdom to the
> > ipnet).  Now connection to it via drawterm (the 9front version) fails,
> > with the following complaint:
> > 
> > drawterm: can't authenticate: auth_proxy rpc: p9any client ask for keys: unable to find common key
> > 
> > Altering ndb/local didn't help.  Before I dig deeper and try to extract
> > more information from the cpu server -- does anybody have an idea and a
> > hint where I should look?
> > 
> > Cheers,
> > oec
>