[plug] NFS

[Craig Ringer]

> I've never touched NFS or LDAP yet .. will do in a few weeks.  Are there any 
> particularly good documents anyone suggests I read regarding LDAP in
> particular, but NFS also?  Will the standard howtos be enough to get me going?

NFS is honestly pretty easy.

apt-get install nfs-user-server nfs-client nfs-common
man /etc/exports
vi /etc/exports
/etc/init.d/nfs-user-server restart
mount -t nfs localhost:/nfstestdir /mnt/test

As for LDAP - well, its used for lots of things. As a result, it can be 
hard to get a clear idea of "How to use LDAP to handle user 
authentication on linux systems". I might have a bookmark or two lying 
around, but overall found it pretty painful finding documentation.

Two tools I strongly suggest you get are "LDAP Browser/Editor" and 
"Directory Administrator":

http://www.iit.edu/~gawojar/ldap/

LBE is a general tool that's exceedingly handy, and Diradmin is a great 
thing when it comes to managing users in the db.

You'll want to use pam_mkhomedir, libpam_ldap and libnss_ldap for the 
client side. On the server side, slapd is all you really need. Initial 
directory setup can be interesting, but once its running its pretty 
simple. If you're doing it with debian, its not too hard at all.

I suggest you read a generic "what is LDAP" document before anything 
else. Its a very strange protocol/standard and takes a bit of 
head-wrapping, especially if you're used to RDBMSes. The data is in a 
tree. There's no concept of a "file" or "directory" but instead any 
object can have children. All objects have elements, which are 
name=value pairs. Object Classes (objectClass=nameofobjectclass eg 
objectClass=posixAccount) define what elements must and may be present 
for a given object. Queries are done in heirachical searches. It all 
makes sense once you get used to it, but it takes some getting used to.

Once you have an idea of the protocol and how it relates to user auth, 
you set up your ldap server, init the directory, add a couple of users, 
and aim the clients at it. It generally then "just works". Its the first 
two steps that can be interesting. Do try to select user IDs well above 
the usual range your distro picks by default (I start at 10000 and go up 
from there) to keep the space clear.

I'll have a look later and see if I kept any references when I was 
researching it.

In the mean time, here's a sample user def'n you can use with "ldapadd" 
as a template. Anything in all caps is to be replaced.

dn: uid=UID,ou=People,REST_OF_YOUR_BASE_DN_EG dc=blah,dc=com,dc=au
objectclass: top
objectclass: posixAccount
uid: UID_SAME_AS_ABOVE
cn: COMMON_NAME
uidnumber: UIDNUM
gidnumber: GIDNUM
homedirectory: /home/UID
userPassword: {MD5}NOPASSWORD
gecos: WHATEVER LIVES IN YOUR SYSTEM'S /etc/passwd GECOS FIELD
loginShell: /bin/bash
objectclass: inetOrgPerson
sn: SURNAME
givenName: GIVENNAME
homePhone: PHONENUMBER
mail: USER at DOMAIN.2LD.AU
mobile: MOBILEPHONE

Of those entries, some - like phone numbers - are optional. See the 
schema defn's in /etc/ldap/schema or /etc/openldap/schema (depends on 
distro) for details, look for posixAccount and inetOrgPerson ObjectClasses.

Here's a group definition. Groups use "cn=" for the final element in 
their DN (Distinguished Name) instead of "uid=" like for user accounts. 
Due to the way LDAP searches work (you look for all groups with element 
memberUID=craig for example), the member list is not a single element 
with a list of UIDs. Instead, its many memberUID elements, one per member.

dn: cn=GID,ou=Group,dc=localnet
objectclass: posixGroup
objectclass: top
cn: GID_AS_ABOVE
gidNumber: GIDNUM
memberUID: ONE_MEMBERS_NAME_ONLY
memberUID: ANOTHER_GROUP_MEMBER
description: SHORT_TEXT_DESCRIPTION

Examples:

dn: cn=users,ou=Group,dc=localnet
objectclass: posixGroup
objectclass: top
cn: testgroup
gidNumber: 10000
memberUID: craig
memberUID: stegoman
memberUID: ondine
memberUID: bunnym
description: All real users

dn: uid=craig,ou=People,dc=localnet
objectclass: top
objectclass: posixAccount
uid: craig
cn: Craig Ringer
cn: Craig S. Ringer
cn: Ringer, Craig
cn: Craig Shaun Ringer
uidnumber: 10000
gidnumber: 10000
homedirectory: /home/craig
userPassword: {MD5}PASSWORDBLANKEDOUT
gecos: Craig S. Ringer
loginShell: /bin/bash
objectclass: inetOrgPerson
sn: Ringer
givenName: Craig
mail: craig at postnewspapers.com.au

Other tips, just quickly: when testing, do your testing entirely with a 
separate new account - don't try to migrate yours until you're sure its 
all working perfectly. ALWAYS KEEP AT LEAST ONE ROOT CONSOLE OPEN, and I 
don't mean an xterm, I mean a real VC. Never mess with ldap over ssh, 
its embarrasing when you shut down the ldap server then realise what 
you've done. (Amusingly, its quite fine to work on ssh over ssh, you can 
stop sshd and still keep working away due the the way openssh works). DO 
NOT put root in the ldap directory unless you want a "single root" 
across all your machines. tcpdump is your friend, as is ethereal - 
because all ldap traffic is IP, you can "tcpdump -i lo" and watch what's 
  going on.

Oh, setting up PAM for the clients. Its pretty simple but doesn't seem 
so at first. Here's an example file from /etc/pam.d/gdm that uses LDAP.

auth     required       pam_nologin.so
auth     required       pam_env.so
auth     sufficient             pam_ldap.so
auth     required       pam_unix_auth.so try_first_pass
account  sufficient             pam_ldap.so
account  required       pam_unix_acct.so
password sufficient             pam_ldap.so
password required       pam_unix_passwd.so shadow
# Create the user's home directory, if it doesn't already exist
session    optional   pam_mkhomedir.so skel=/etc/skel umask=0022
session  sufficient             pam_ldap.so
session  required       pam_unix_session.so
session  required       pam_limits.so

Oh, and if a particular thing (eg gdm) won't auth over LDAP when you set 
it up to, restart it. Many programs only seem to read 
/etc/pam.d/progname at load time.

/phew/. Enough for tonight. Hope that helps... might want to try google 
for an LDAP ref or two. There are HOWTOs out there but I found them less 
than useful - they all assumed you had a detailed knowledge of LDAP and 
already had a working ldap server.

Craig Ringer