Re: [9fans] Mysterious auth again...?
Hi Stevie, I know, auth can be tricky... In fact. Without having further information about your setup I can only recommend reading this doc: http://kamalatta.ddnss.de/config/Plan9Tutorial.txt. Thanks for the link, going to recheck my configuration. P.S.: I don't know the full background, but connecting as the hostowner seems to have other prerequisites. That's what is surprising me. I can 'cpu' the machine with 'bootes' (hostowner) uid. I can 'srv' the machine... I must have something strange there... Pavel
Re: [9fans] Mysterious auth again...?
Hi Stevie, I know, auth can be tricky... In fact. Without having further information about your setup I can only recommend reading this doc: http://kamalatta.ddnss.de/config/Plan9Tutorial.txt. Thanks for the link, going to recheck my configuration. P.S.: I don't know the full background, but connecting as the hostowner seems to have other prerequisites. That's what is surprising me. I can 'cpu' the machine with 'bootes' (hostowner) uid. I can 'srv' the machine... I must have something strange there... Pavel Hi Pavel, I think this thread on 9fans might help: http://marc.info/?l=9fansm=116732560810918w=2 Read the whole thread, but I think my linked message has the answer. Do you start keyfs before listen in your cpurc? Stevie
Re: [9fans] Mysterious auth again...?
Hi Stevie, I think this thread on 9fans might help: http://marc.info/?l=9fansm=116732560810918w=2 thanks, going to read it too. Read the whole thread, but I think my linked message has the answer. Do you start keyfs before listen in your cpurc? Yes, it was 1st thing I checked... Pavel
Re: [9fans] Mysterious auth again...?
Hi Stevie, you were right, I missed one point during the server installation/configuration: I forgot 'auth/changeuser bootes'... :( Now 'auth/debug' works well, sorry for a noise. And thank you. Pavel 2014-08-05 11:09 GMT+02:00 Pavel Klinkovský pavel.klinkov...@gmail.com: Hi Stevie, I think this thread on 9fans might help: http://marc.info/?l=9fansm=116732560810918w=2 thanks, going to read it too. Read the whole thread, but I think my linked message has the answer. Do you start keyfs before listen in your cpurc? Yes, it was 1st thing I checked... Pavel
Re: [9fans] Mysterious auth again...?
Hi all,
I am fighting with configuration of '9pccpuf' server.
I have configured user 'bootes' as a hostowner.
I have 'listen', 'keyfs' running.
I can 'cpu' such server from another Plan9 terminal ('9pcf') as user
'bootes'.
I can 'srv' such server from another Plan9 terminal ('9pcf') as user
'bootes'.
BUT:
server# auth/debug
p9sk1 key: dom=xxx proto=p9sk1 user=bootes !hex? !password?
successfully dialed auth server
password for bootesatxxx [hit enter to skip test]:
cannot decrypt ticket1 from auth server (bad t.num=0x...)
auth server and you do not agree on key for bootesatxxx
I found that it was already solved in the past...
http://comments.gmane.org/gmane.os.plan9.general/55049
but it looks I have a correct sequence in /rc/bin/cpurc, /cfg/server/cpurc,
/cfg/server/cpustart...
Any idea what do I have wrong?
Thanks in advance.
Pavel
P.S.: I cannot make 'auth' system to work with another added user... :(
Hi,
I know, auth can be tricky, but it's a long time since I configured
authentication. Without having further information about your setup I
can only recommend reading this doc:
http://kamalatta.ddnss.de/config/Plan9Tutorial.txt.
It helped me a lot configuring my server. Just try to find the step
you probably missed.
I hope, that will help you.
stevie
P.S.: I don't know the full background, but connecting as the
hostowner seems to have other prerequisites.
Re: [9fans] mysterious auth
in case anyone's wondering, my problem was due to the fact that keyfs was started after aux/listen for trusted services; /mnt/keys/* wasn't in authsrv's namespace. in my case, i put the trusted services in /cfg/bootes/cpurc, while keyfs was started later in the sequence of /rc/bin/cpurc. the default config in the distro CD could lead others to do the same. given that only auth needs to run keyfs and trusted services, it would be better to create a /cfg/example.auth/cpurc that includes keyfs and trusted services in it and remove them from /rc/bin/cpurc, since they come after /cfg/$sysname/cpurc is run. are you sure that the passwords in nvram and auth/changeuser do match for bootes? pretty sure. i've zero'ed the nvram and re-entered it. i went so far as stopping keyfs, zero'ing /adm/keys and /adm/keys.who and reinstalling bootes from scratch and restarting. it is very puzzling. Lucio said: Should you not add a role=server to whatever the chosen entry is? It will at minimum help with debugging. i did, but the result changed only slightly; trying to connect to auth from another system now results in the same behavior as auth/debug exhibits: no key matches.
Re: [9fans] mysterious auth
On Fri Jan 22 18:29:45 EST 2010, 9...@9netics.com wrote: in case anyone's wondering, my problem was due to the fact that keyfs was started after aux/listen for trusted services; /mnt/keys/* wasn't in authsrv's namespace. in my case, i put the trusted services in /cfg/bootes/cpurc, while keyfs was started later in the sequence of /rc/bin/cpurc. the default config in the distro CD could lead others to do the same. given that only auth needs to run keyfs and trusted services, it would be better to create a /cfg/example.auth/cpurc that includes keyfs and trusted services in it and remove them from /rc/bin/cpurc, since they come after /cfg/$sysname/cpurc is run. i was wondering. thanks for the explaination. - erik
Re: [9fans] mysterious auth
it would be better to create a /cfg/example.auth/cpurc that includes keyfs and trusted services in it and remove them from /rc/bin/cpurc, since they come after /cfg/$sysname/cpurc is run. You could submit a patch... I have a feeling that the philosophy is for /cfg to be entirely optional, so putting examples in there is not encouraged. But what about (late in /rc/bin/cpurc): # cpu-specific late startup if(test -e /cfg/$sysname/cpustart) . /cfg/$sysname/cpustart ? ++L
Re: [9fans] mysterious auth
with similar results. in that case factotum debug says no key matches proto=p9sk1 role=server dom?. this last message looked a bit weird and when i check /dev/hostdomain, it is empty. /dev/hostdomain empty here, too. - erik
Re: [9fans] mysterious auth
are you sure that the passwords in nvram and auth/changeuser do match for bootes? On Mon, Jan 11, 2010 at 8:22 PM, Skip Tavakkolian 9...@9netics.com wrote: on a new network and standalone auth+fs (built from CD image of Jan 7th), auth is refusing to concur. i've used Russ' message from a while back [1] as a checklist. auth/debug reports: cannot decrypt ticket1 from auth server (bad t.num=0x...) auth server and you do not agree on key for boo...@bta.somedomainx.org factotum debug output says no key matches; factotum has the right key and i've zero'ed nvram a couple of times to be sure. it's interesting that reading /mnt/factotum/ctl also gives no key matches/failure no key matches message along with the key. key looks like this: key proto=p9sk1 dom=bta.somedomainx.org user=bootes !password? i've tried logging in from a term (pxeloaded from the same auth+fs) with similar results. in that case factotum debug says no key matches proto=p9sk1 role=server dom?. this last message looked a bit weird and when i check /dev/hostdomain, it is empty. any ideas? [1] http://groups.google.com/group/comp.os.plan9/browse_thread/thread/797bce6a973b84e8/0941aa4593f9dc73?lnk=gstq=factotum+nvram#0941aa4593f9dc73 -- Federico G. Benavento
Re: [9fans] mysterious auth
responding to feedback from multiple 9fans: Federico said: are you sure that the passwords in nvram and auth/changeuser do match for bootes? pretty sure. i've zero'ed the nvram and re-entered it. i went so far as stopping keyfs, zero'ing /adm/keys and /adm/keys.who and reinstalling bootes from scratch and restarting. it is very puzzling. Lucio said: Should you not add a role=server to whatever the chosen entry is? It will at minimum help with debugging. i did, but the result changed only slightly; trying to connect to auth from another system now results in the same behavior as auth/debug exhibits: no key matches.
