Here is the promised reply to your other points. I've finished rewriting the documentation (after walking through the process and catching a few other points that weren't clear), and am about to do one more walkthrough and then will send you the new documentation and the new scripts for more testing.
Faheem Mitha <[EMAIL PROTECTED]> writes: > comment begins******************************************************** > I've only the sketchiest idea what the purpose of these principals is. The > original transcript compounds confusion by using a preexisting account, eg. > "Re-enter KDC database master key to verify:foo > Authenticating as principal hartmans/[EMAIL PROTECTED] with password." > Do I need to create two principals, namely faheem and faheem/admin. If so, > what purposes do they serve? > Is there some way I can authenticate that I have set this up correctly? > comment ends*********************************************************** The documentation should hopefully clarify the role of those two principals. The message printed by kadmin.local is nonsensical and can be ignored. (It's really a bug in krb5 that it prints anything at all, since the comment that it prints is a lie. kadmin.local is authenticating using a local key, not as any user principal.) > This seems a good time to stop and look at files that have been > created in /etc/openafs, since we'll soon run into trouble in that > context. > So, here is > /etc/openafs/server/CellServDB begins****************************** > >dulci.biostat.duke.edu > /etc/openafs/server/CellServDB ends****************************** > Note /etc/openafs/ThisCell and /etc/openafs/server/ThisCell are the same. > /etc/openafs/server/CellServDB looks dodgy to me. It will now get overwritten by afs-newcell, but yes, I think that the dodgy CellServDB may be behind the problems you ran into with bos. > What administrative principal should be used? faheem > comment begins************************************************************ > Why isn't this faheem/admin? What is the difference? > comment ends************************************************************** It should probably be faheem/admin. I'm not sure why Sam used his regular user principal at this point in the transcript. The documentation makes this a bit clearer, and I probably need to regenerate the transcript. > echo \>dulci.biostat.duke.edu >/etc/openafs/server/CellServDB > /etc/init.d/openafs-fileserver start > Starting AFS Server: bosserver. > bos addhost riverside riverside -localauth ||true > bos: could not find entry (can't find cell '<default>' in cell database) > bos adduser riverside faheem -localauth > bos: could not find entry (can't find cell '<default>' in cell database) > Failed: 256 > bos: could not find entry (can't find cell '<default>' in cell database) > riverside:/home/faheem# exit > exit > configuration transcript ends******************************************* I'm a little curious what cell database bos was using, but it sure sounds like it was trying to use server/CellServDB. afs-newcell now generates that file directly rather than using bos addhost, and that seems to work much better. > comment begins************************************************************ > The files in /etc/openafs are unchanged after this script runs. > The above error goes away, and the script seemingly gets a bit further > before exiting with another error, if /etc/openafs/server/CellServDB is > replaced by > >dulci.biostat.duke.edu > 152.3.172.51 # riverside.dulci.biostat.duke.edu That's the correct fix. I'm a bit curious what the next error is, but hopefully whatever it is is also resolved with the new scripts and documentation. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
