[OpenAFS] Home directory in AFS

[Turbo Fredriksson]

>>>>> "Derek" == Derek Atkins <warlord@MIT.EDU> writes:

    Turbo> The module [pam_mkhomedir]  should be modified to recognize
    Turbo> AFS.  After  the directory have been created,  add the user
    Turbo> to  the group  owning the  directory (?).  AND,  the module
    Turbo> should  be able  to create  VOLUMES instead  of DIRECTORIES

    Derek> Just running as root is insufficient; it has to run with
    Derek> administrator _TOKENS_ which means your client host needs
    Derek> to be able to obtain tokens for system:administrator.

Doh! Naturaly, sorry. Should have thought about that to :)

    Derek> Basically, you'd need to change pam_mkhomedir such that it:
    Derek> a) obtained system:administrator tokens

This should be quite easy to do, even in a secure manner..

I use the way described in 'http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html#kerbcron'
to have my master LDAP server replicate to it's slave.

So just configure pam_mkhomedir to recognize a KerberosV keytab, do the
'kinit', then the 'aklog' (both with propper options) equivalences in C.

    Derek> b) created the volume, mountpoint, and released the parent
    Derek> c) set the new volume quota and acl
    Derek> d) ran 'fs checkb' to update the local  parent volume

These seems to me the problem. I NEVER coded with AFS, so this needs
some looking into... Anyone have some examples?

    Derek> e) dropped the tokens so your user doesn't get admin privs.

Just as easy as GETTING the token.

    Derek> This is a LOT of work.  Considering you already have to
    Derek> create the user accounts anyways, why not do this at the
    Derek> same time?  It's a simple perl scripts which _YOU_ can run
    Derek> with _YOUR_ admin tokens!

Yes, this is easier for ME, but _IF_ I modify the pam_mkhomedir, others
will be able to benefit, and have a easier

The thing is, CURRENTLY OpenLDAP (v2.0) can't store the Kerberos/GSSAPI
credentials in database, but the next version is rumored to have that
possibility.

So whenever that happens, I will get back the functionality I had when
I had passwords in my OpenLDAP 1.2 db (using 'userPassword: {crypt}...'
functionality).

That is _ONE_ place to do modifications/additions/deletions of users!! This
was originaly the _ONLY_ (and later PRIMARILY) reason to have LDAP.

When I added kerberos functionality (the reason for THAT was so that I didn't
have to put the password for LDAP replication in cleartext, later crypted,
in the config file).

So you see, my reasons for such a complicated system is quite ... irregular (?)
:)


With this I want to say that  having _ONE_ place for user modifications
is the _PRIMARY_ goal for me. And this HAVE to be possible through a web
page. I'm implementing this kind of system on quite a number of system,
out of my control, and where the USER want to have the control, but don't
have the knowledge...

So having the pam_mkhomedir is ESSENTIAL for this to work properly. Fine,
hard work. I don't mind :) In theory it's not THAT hard, but we all know
that theory and practise differs :)

I don't know if I'm _ABLE_ to do this, since I never coded with AFS before,
but if someone could give me some URL's to example AFS client code, I'll
take a look and see if I can use anything...

    Derek> If you don't use an AFS-aware backup system then you will
    Derek> lose certain AFS-specific information (in particular
    Derek> directory ACL information).

This is a bummer. Is it possible to only backup the ACL information, without
taking the data?

Not knowing quite  what I'm talking about, this  should be possible by
using 'fs la'  in a recursive loop under each  volume, parse the info,
and create a restore script  that restores the ACL info... This script
is created BEFORE the backup of the AFS volume takes place, and is backed
up WITH the volume data.

So when a restore have to take place, the data is restored WITHOUT the
AFS ACL information, but that information is located in the script,
so can be restored.
-- 
Cocaine toluene munitions DES tritium domestic disruption Albanian Uzi
plutonium Ft. Meade CIA NSA FBI killed Mossad
[See http://www.aclu.org/echelonwatch/index.html for more about this]