From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4277F671.1010806@asgaard.homelinux.org> Date: Wed, 4 May 2005 00:08:49 +0200 From: =?ISO-8859-1?Q?=22Nils_O=2E_Sel=E5sdal=22?= User-Agent: Mozilla Thunderbird 1.0.2-1 (X11/20050323) MIME-Version: 1.0 To: Russ Cox , 9fans@cse.psu.edu Subject: Re: [9fans] Auth woes. References: <4277BB46.6020001@asgaard.homelinux.org> <4277C5DB.7050601@asgaard.homelinux.org> <4277DCC4.5010806@asgaard.homelinux.org> <4277EEE4.5060504@asgaard.homelinux.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: Content-Transfer-Encoding: quoted-printable Topicbox-Message-UUID: 44e7c74c-ead0-11e9-9d60-3106f5b1d025 Russ Cox wrote: >>>It sure sounds like your auth server (keyfs) and your factotum >>>do not agree on what the password is. The new factotum that >>>I said to pull fixed a different problem -- if the server side fails >>>the auth, it could be because the client lied, so that case doesn't >>>disable the key anymore. But the case you're running into is that >>>the tickets coming back from the auth server don't decrypt properly, >>>and since factotum trusts the auth server, it disables the key. >> >>Ok. I'm not quite sure I follow, You're saying the key(password) in nvr= am >>doesn't match what's stored in /adm/keys ? >>(if so I'm pretty sure they're the same, but I'll try to investigate fu= rther..) >=20 >=20 > if you're not using securestore, then yes that's what i'm saying. > (if you're using securestore, then i'm saying that the password > in the secstore file doesn't match what is stored in /adm/keys.) Well, bootes secstore only holds my key for sources.. I reinitialized nvram (echo asda >/dev/sdC0/nvram, rebooted) and ran 'passwd' as bootes , ensuring both passwords were the same. I suspect they already were, else no login/passwd changing would have wor= ked ? Still, I can only drawterm to it (as bootes, or anyone else) until cron has run. *sigh* I'm too new/not any good at this. -- Nils O. Sel=E5sdal