From mboxrd@z Thu Jan 1 00:00:00 1970 From: andrey mirtchovski To: 9fans@cse.psu.edu Subject: Re: [9fans] strange things in /sys/log/auth In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Wed, 2 Jul 2003 10:35:57 -0600 Topicbox-Message-UUID: e565953c-eacb-11e9-9e20-41e7f4b1d025 i fixed the problem -- the /adm/keys file was fscked somehow. i was able to see directory entries for all users i've added in /mnt/keys, but after the directory listing there was garbage, the same thing Geoff sent a few messages back. when started keyfs was reporting 'bad status in key'. i ended up doing: % rm /adm/keys % con -l /srv/fscons main: create /active/adm/keys bootes bootes 660 % auth/changeuser bootes ... and then added all other users again. i've saved the old keys file, in case anyone is interested in playing with it to see what's wrong. i've changed all passwords :) i'm a little worried, though -- i was thinking that bootes can only change passwords on the console, but killing keyfs and restarting it again as bootes in a local namespace gives me write privileges to /mnt/keys (though i loose the ability to login to the machine, naturally :) is it advisable to lock the keyfs process the same way factotum's process is? put it in the kernel? disallow 'echo kill > /proc/xx/ctl'? inquiring minds want to know :) On Tue, 1 Jul 2003, David Presotto wrote: > It means you have to: > > 1) kill keyfs > 2) run auth/convkeys on the keyfile > 3) reboot the auth server (or just give the new key to factotum on the auth server) > 4) if you use an nvram on the auth server to store the key, use auth/wrkey > to rewrite it