[OpenAFS] Debian - openafs -noauth problems

[Madhusudan Singh]

Thanks for the help again.

I am now reading up on the administration of OpenAFS.

Let us refer to :

http://www.openafs.org/pages/doc/AdminGuide/auagd018.htm#HDRWQ503

This provides a command by command reference for setting up individual user 
accounts on AFS. For my users, I decided to create a user group (bgroup) for 
future scalability (we might have users later who would have different set of 
permissions or ACLs).

#pts creategroup bgroup

I skipped the kas create commands since I am using the KDC for authentication. 
(Am I correct in assuming that all I need to do here is to add some pam_krb 
related entries in /etc/pam.d/common-auth ?)

Step 12 suggests that I use the AFS id for setting the ownership of the 
mountpoints for the users. Now this sounds fishy to me. The ID in the 
argument to chown usually corresponds to the system groups (not AFS groups). 
But I went ahead anyways. The AFS ID of user m_singh is 1, while for another 
user heidel, it is 43114. As I expected, a listing of the directories 
reveals :

#pwd
/afs/omega.domain.edu/user
#ls -l
drwxrwxrwx  2 daemon root 2048 2005-08-25 16:38 m_singh
drwxrwxrwx  2  43114 root 2048 2005-08-25 16:45 heidel

Now, I had added both m_singh and heidel to bgroup (pts adduser username 
bgroup) . So, is the upshot of all this the following :

There must be a system group corresponding to the pts group for each such 
group and an additional chgrp command must be issued (in contrast to the 
suggestions in the guide).

?

I am still not sure what to do about the ownership of the directories - the 
system UID's seem to be trumping the AFS UID's in AFS space. In addition, how 
does one change the AFS UID of a member of system:administrators ? (Such as 
m_singh above) ?


On Wednesday 24 August 2005 9:36 pm, Russ Allbery wrote: 

> Madhusudan Singh <singh.madhusudan@gmail.com> writes:
> > Thanks for all the help. Ran afs-newcell, got tokens as the admin, and
> > ran afs-rootvol and the whole process seems to have concluded
> > successfully. Thanks for the very helpful scripts. I will be studying
> > the logs to see how this process differed from my prior attempt.
>
> Excellent, I'm glad to hear that it worked!
>
> > Your excellent README then suggests that the AFS admin guide be
> > consulted. I looked at :
> >
> > http://grand.central.org/twiki/bin/view/AFSLore/InstallingtheFirstAFSMach
> >ine#Storing_AFS_Binaries_in_AFS
> >
> > which suggests that AFS related binaries be stored in the AFS filespace
> > under its own volume (sysname = i486_linux24 for me).
>
> Some of this information really doesn't apply to Debian; it's designed
> more for sites that are planning on doing all their software management
> via AFS.  With Debian, all the AFS binaries are installed in /usr/bin and
> similar paths as appropriate, as with any other package.
>
> > Now, under Debian, the AFS binaries are dumped into /usr/bin, indistinct
> > from other system binaries. So, what is the recommended policy for
> > Debian ?
>
> Just use the client packages and be happy; there's no need to put any of
> that into AFS.  Hard drives aren't as tiny as they used to be.
>
> > In a previous incarnation, this server was a simple Linux server where a
> > bunch of users had some files stored in /home/username. Prior to my
> > setting up the OpenAFS server, I had backed these up to another server
> > (not running OpenAFS) under /backup/username. I was wondering if there
> > is a certain method to be followed in restoring these for use. Right
> > now, I can see the following steps :
> >
> > 1. Create a user group under pts.
> > 2. Add all the users to the user group.
> > 3. Unknown.
> >
> > PS : How does one set quotas for the users ?
>
> This is where reading the admin guide will come in handy.  You will
> generally want to create a separate volume for every user, since AFS
> quotas are by volume, and mount those under /afs/your.cell/users.  Each
> user should then have a PTS entry created with a UID matching the UID
> they'll use on your systems, and then they can be added to the ACL for
> their home volumes.
>
> There's no need to create a user group unless you want content to be
> accessible to that particular set of people but not to other people who
> use your AFS cell.
>
> But I recommend reading through the admin guide, since there are a bunch
> of concepts you'll now want to read about and experiment with.