[OpenAFS] Home directory in AFS

[Turbo Fredriksson]

>>>>> "Todd" == Todd M Lewis <utoddl@email.unc.edu> writes:

    Turbo>  NOW you're talking! Luckily theory and practise differs a
    Turbo> little, and it's not EXACTLY as bad as enter the clear text
    Turbo> password in a world readable file on disk. Close, but not
    Turbo> quite...
    Turbo> 
    Turbo> Unfortunately I don't know any other way to get around this.

    Todd> Without being to sardonic, the way to get around this is to
    Todd> do it the AFS way.  That's basically why it was set up this
    Todd> way to start with.

I was referring generally. As it is now, my SLAPd (LDAP server) needs ONE
key tab, the PostgreSQL server ONE, and when (if) I start using Cyrus
IMAP/POP daemon, they need ONE.

Granted, that's the 'server' key tab, not needed on every host...

    Todd> This is a key feature of AFS, and worth repeating since this
    Todd> seems to be one point you are missing: You don't have to do
    Todd> any cell level administration on clients.  Don't put admin
    Todd> keytabs out there.  If you do, you're working too hard, and
    Todd> decreasing security.

True, didn't think that far.

    Turbo> So having the pam_mkhomedir is ESSENTIAL for this to work
    Turbo> properly. Fine, hard work. I don't mind :) In theory it's
    Turbo> not THAT hard, but we all know that theory and practise
    Turbo> differs :)
    Turbo>
    Charles> Umm... why can't you create a home directory from this
    Charles> web interface?  At least you'd only have to put a keytab
    Charles> on one machine.

    Todd> That's what we do; all our users are created through a web
    Todd> based front end.

It have to be a specialised web tool. It have been agreed on on the
OpenLDAP list, that it will probably never be a 'general LDAP web admin
tool', since all (LDAP) databases differ so much, and it seems no one
have bothered to write one that's general enough. They all assume
that the DB looks a certain way...

I've been using LDAPExplorer, but have more or less been forced to
do it the old way, with shell scripts (because of the KerberosV
db addition). WHEN (if?) OpenLDAP have the possibility to store MIT
KerberosV auth secrets, then I might go back...

As it is now, it seems like I'm forced to obey, do it the AFS way :)

I created all the user volumes yesterday. I ended up with 63 volumes!

Oki, granted, that's not much. I bet anyone here have at least 10 times
as much, but..

    Turbo> This is a bummer. Is it possible to only backup the ACL
    Turbo> information, without taking the data?
    Turbo>
    Charles> Nope.
    Turbo>  I'm not convinced. Care to elaborate (WITHOUT calling me names
    Turbo> this time)?

    Todd> Of course you can harvest ACLs and store them in some format
    Todd> that allows you to restore them later.  But all that work is
    Todd> already done for you with AFS's volume dump, restore, and
    Todd> backup procedures.

Yes, but I started a thread about a week ago (?) which discussed this,
and I never got a clear answer (or at least none that I understood).

I have to backup a lot of non-AFS space as well, and have only ONE
tape drive (three tapes).

Is it possible to mix the two, 'simultaneous'?

    Todd> You don't  have to  restore backed up  volumes to  their old
    Todd> names, so if you want to do easy web based partial restores,
    Todd> put your  work into restoring the volume  in the background,
    Todd> then grabbing for  the user just the files  s/he wants.  And
    Todd> ACLs too if that's what you're after.  Inventing AFS backups
    Todd> again is lots of work, and it's already been done.  Build on
    Todd> it, but understand it first.

Oki, no need to answer the previous question then. I'll dig a little
deeper in how AFS (backups) work, and come back if/when I have more
questions :) Scare thought, right? :)

    Todd> The  fact  that experienced  people  are suggesting  (rather
    Todd> strongly)  that  it  isn't  a  good  idea  should  tell  you
    Todd> something.

Absolutely. But I will _NEVER_ _EVER_ (!!) obey 'experienced people'
just because they think/claim they are experienced. Not with a very
good explanation WHY it is a bad idea.

MY problem, but that's the way (most?) people work. Telling someone
"that's a bad idea" won't do you much good.

    Todd> Understand their  reasons before  you spend to  much effort
    Todd> turning your  AFS cell  into less than  it could  be because
    Todd> that was the vision you had when you started with AFS.

It took a while, but I only got ONE good reason every now and then, but
I 'finally saw the light'. I'm currently doing it the AFS way, not because
I believe in it, but because it seems to be "the road with least hassles".

    Turbo> I still think that the 'pam_mkhomedir' module would be nice to
    Turbo> have, added the needed functionality.

    Todd> I'm not sure what all 'pam_mkhomedir' does.  I assume it
    Todd> creates a home directory and adds a user to the
    Todd> passwd/shadow files.

Yes and no. It creates the home directory, IF it doesn't already exists,
and IF the user is properly authenticated and authorised.

It actually have no idea what the /etc/(passwd|group|shadow|gshadow) files
are all about. It doesn't have to.

    Charles> From everything you've said, I strongly suggest you stick
    Charles> with NFS.  It would be more appropriate for your
    Charles> environment.
    Turbo>  I have. NFS gave me more problem than it was worth, I need
    Turbo> something completely different. And I might even USE NFS in
    Turbo> some areas, but I first going to explore the 'whole' (at least
    Turbo> as much as I have to to understand it enough) AFS business.

    Todd> Well, AFS is completely different all right. I have the same
    Todd> tendency you seem to have -- to try to coerce a "new" (to me
    Todd> that is) system into my existing mental models of how
    Todd> computing works.  Try to work with it instead of against it
    Todd> until you understand why it is the way it is.

I've been doing this (computing, system admin, system design etc, etc)
for a very long time. MY (!) way of learning is to question, try to
make the software fit MY 'mental model' instead of the reverse (which
naturally should be the correct way). That way the MENTAL MODEL will be
updated when I get smacked with the "don't do that, it's bad". The way
_I_ learn suites _ME_.

I've tried hard to forget all the "don't do that, it's bad" beating I
got when I tried to learn LDAP (I only knew SQL at that time, and thought
I was good at it to! :).
-- 
plutonium terrorist pits Mossad killed South Africa Cuba supercomputer
Semtex Cocaine smuggle DES Clinton Uzi SEAL Team 6
[See http://www.aclu.org/echelonwatch/index.html for more about this]