View source for Labeled NFS/Demo/Manual/Post-Install

Following are additional post-install configuration steps that can be performed to better integrate the clients and server in a way that more closely resembles what might be seen in an enterprise environment.

= Automounting User Home Directories =

Autofs/Autmount is used to automatically mounts user's home directories.
<pre>
   # yum install autofs
</pre>

== Edit /etc/auto.master ==

Add the following to the /etc/auto.master file:

<pre>
/home /etc/auto.home
</pre>

== Edit /etc/auto.home ==

The file /etc/auto.home should have the following line in it.
* An administrator may want to adjust some of the NFS parameters
<pre>
*    -fstype=nfs4,sec=krb5,security_label,soft,intr,rsize=8192,wsize=8192,nosuid,tcp nfs.example.com:/home:&
</pre>

= Enable Kerberos Authentication and LDAP User Information on the Client =

At the command line, run the authentication configuration tools on
the client machine '''authconfig-tui''':

<pre>
client# authconfig-tui
</pre>

It presents a number of terminal selection boxes.  The first one is
'''Authentication Configuration'''

Under '''Authentication''':
* Select '''Use Kerberos'''
** This enables logins via Kerberos.
** this can change a number of files, the PAM configuration is the main one.
* Leave selected or select '''Use Shadow Passwords''' and '''Local authorization is sufficient'''
** This allows local passwords to work as well.

Under '''User Information''':
* Select '''Use LDAP'''

Select '''Next'''

It now presents '''LDAP Settings'''.  This should have the correct
configuration information from previously configuring the LDAP
server.  But if it is blank or just to double check:
* '''Use TLS''' should be selected.
* '''Server:''' should be the LDAP server
** e.g. ldap://sefos.example.com
* '''Base DN:''' should be the base DN
** e.g. dc=example,dc=com

Select '''Next'''

It now presents '''Kerberos Settings'''.  Again, this should have
the correct configuration information from previously configuring
the Kerberos server.  But if it is blank or just to double check:
* '''Realm:''' should be the local realm
** e.g. EXAMPLE.COM
* '''KDC:''' should be the name of the Kerberos KDC
** e.g. sefos.example.com (the port number, 88, may be appended)
* '''Admin Server:''' should be the Kerberos Admin server
** e.g. sefos.example.com (the same as the KDC in this example; the port number, 749, may be appended)
* leave unselected '''Use DNS to resolve hosts to realms'''
* leave unselected '''Use DNS to locate KDCs for realms'''


= Adding Users =

After following the previous instructions, the network's Kerberos,
NFS, and LDAP services are ready to be used by a client machine.
But the user information necessary to make everything work has not
been added yet.  For most enterprises, the existing user
provisioning system will need to be modified in some fashion to
perform the following steps when adding a user.  With the exception
of some of the LDAP loading, what follows is mostly manual
instructions for adding the user information for a single user.  In
a production system, these steps should be scripted and integrated
into an enterprise's provisioning system to simplify user changes.

== Kerberos Principles ==

The first step is to create a Kerberos principal for a new user.  For this example, '''newuser''' is used.  
* This command needs to be done by a principal that has write access to the Kerberos data.

<pre>
root@sefos/etc kadmin
Authenticating as principal root/admin@EXAMPLE.COM with password.
Password for root/admin@EXAMPLE.COM:
kadmin:  addprinc newuser
NOTICE: no policy specified for newuser@EXAMPLE.COM; assigning "default"
Enter password for principal "newuser@EXAMPLE.COM":
Re-enter password for principal "newuser@EXAMPLE.COM":
Principal "newuser@EXAMPLE.COM" created.
kadmin:  listprincs
K/M@EXAMPLE.COM
host/seclient.example.com@EXAMPLE.COM
host/sefos.example.com@EXAMPLE.COM
kadmin/admin@EXAMPLE.COM
kadmin/changepw@EXAMPLE.COM
kadmin/history@EXAMPLE.COM
kadmin/sefos.example.com@EXAMPLE.COM
krbtgt/EXAMPLE.COM@EXAMPLE.COM
ldap/sefos.example.com@EXAMPLE.COM
newuser@EXAMPLE.COM
nfs/seclient.example.com@EXAMPLE.COM
nfs/seclient.example.com@EXAMPLE.COM
nfs/sefos.example.com@EXAMPLE.COM
root/admin@EXAMPLE.COM
</pre>

'''Note''': The listprincs results have been truncated here.
'listprincs' was just run to check that 'newuser' was created.

== Creating Home Directories ==

NFS home directories can be handled in a number of different ways.
This is just one way to do it.  In this example, the NFS server's
/mnt/export/home directory is bound to the local /home directory.

From the command line or placed in /etc/rc.d/rc.local for automatic
binding at boot time:
<pre>
[root@sefos \]# mount -n --bind /home /mnt/export/home
</pre>

Each new user is then created on the NFS server.  An explicit Group
ID number (GID) and User ID number (UID) can also be given with the
commands below, although it is not necessary.  Unique numbers are
generated automatically.

<pre>
[root@sefos /] groupadd newuser
[root@sefos /] useradd -m -s /sbin/nologin -g newuser newuser
</pre>

* The GUI 'system-config-users' can also be used.
* By default on F9, a unique group with the same name as the user (e.g. a 'newuser' group) is created when a  user is created.
* The UID and GID values that are set in LDAP later do not have to match the values generated here. The NFS files will be mapped between the two.
* '-m' creates a new /home/ directory for the user and copies the skeleton files (/etc/skel/) into it.
** The files created within a new user's home account can be set up to be what is administratively required and a different skeleton directory can be specified as well.
** Since the home/ directory is bound to /mnt/export/home/, the NFS user's home/ directory and default skeleton files are automatically created.

== LDAP User Information ==

The next step is to add user information into the LDAP directory
service.  For most Enterprise systems this likely will be scripted.
The OpenLDAP package has a number of schemas in place to handle user
information that this example will build from.  The package
migrationtools is a good place to get started.

=== Migrationtools ===

Migrationtools is a set of '''Perl''' scripts that convert a number
of different standard network information databases into a format
that can be added into a LDAP directory service.
<pre>
  [root@sefos /] yum install migrationtools
</pre>
* Installs scripts into /usr/share/migrationtools

It should be noted that migrationtools has scripts for transferring
everything at once, migrate_all_online.pl and
migrate_all_offline.pl.  Since this example is just interested in
the user information (user, group, home directory, etc...), these
scripts are not used.  To just grab the pertinent user information
and place it into the LDAP directory service, the scripts
/usr/share/migrationtools/migrate_passwd.pl and
/usr/share/migrationtools/migrate_group.pl are run to generate user
information for the LDAP directory.  'migrate_password.pl' will pull
user information out of a unix /etc/passwd file and put it into a
LDAP ldif formatted output file.  'migrate_group.pl' will pull group
information out of a unix /etc/group file and put it in a LDAP ldif
formatted output file.  This assumes there is an existing unix
system with user's and group's that should be in the LDAP directory
service.

To make life easier, there is a configuration script,
/usr/share/migrationtools/migrate_common.ph that holds two pieces of
information that should change.  Change the default domain and base
in this file to the desired values for the current domain.

<pre>
# Default DNS domain
$DEFAULT_MAIL_DOMAIN = "example.com";

# Default base
$DEFAULT_BASE = "dc=example,dc=com";
</pre>

=== Group information ===

Next create the list of groups to migrate to LDAP.

<pre>
[root@sefos ~] /usr/share/migrationtools/migrate_group.pl  /etc/group  group.ldif
</pre>

The file group.ldif holds a list of ldif formatted group
definitions that look similar to:

<pre>
dn: cn=newuser,ou=Group,dc=example,dc=com
objectClass: posixGroup
objectClass: top
cn: newuser
userPassword: {crypt}x
gidNumber: 501
</pre>

For the example, this individual record is pulled out and placed in
a separate file, 'newusergroup.ldif'.  
* The '''userPassword''' value is not needed here, so it is excised.
* The '''gidNumber''' should be unique within the  network user information.
** For this example, this means unique within the LDAP directory server.
** The GID is changed to be a higher value so that it is less likely to conflict with F9 defaults which use GIDs starting at 0 for system accounts and GIDs starting at 500 for user accounts.


The new file 'newusergroup.ldif' now looks like:

<pre>
dn: cn=newuser,ou=Group,dc=example,dc=com
objectClass: posixGroup
objectClass: top
cn: newuser
gidNumber: 902
</pre>

Add it to the LDAP directory services on the server:

<pre>
# chcon system_u:object_r:slapd_db_t:s0 /tmp/newusergroup.ldif
# ldapadd -ZZ -f newusergroup.ldif
</pre>

=== User Information ===

Next the ldif file for the user information is created and added to the LDAP directory.  Pull out user info from the /etc/passwd file.

<pre>
[root@sefos~] /usr/share/migrationtools/migrate_passwd.pl /etc/passwd users.ldif
</pre>

The file users.ldif holds ldif formatted information that is similar to:

<pre>
dn: uid=newuser,ou=People,dc=example,dc=com
uid: newuser
cn: newuser
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}!!
shadowLastChange: 14071
shadowMax: 99999
shadowWarning: 7
loginShell: /sbin/nologin
uidNumber: 502
gidNumber: 502
homeDirectory: /home/newuser
</pre>

This as also parsed down to the values we need for this example and placed within a separate file, 'newuserinfo.ldif'.
* 'objectClass: shadowAccount', userPassword, shadowLastChange, shadowMax, and shadowWarning are all excised as they are not pertinent to the network user information in this example.
* loginShell is changed to a useful login shell.
* The group ID (GID) is changed to match the newuser group that was just created.
* The user ID (UID) is changed to a value unique within the network's user information (i.e. in this case, unique within the LDAP directory).
** The UID is set above the F9 default 500+ UID values to try to avoid conflicting numbers.

<pre>
dn: uid=newuser,ou=People,dc=example,dc=com
uid: newuser
cn: newuser
objectClass: account
objectClass: posixAccount
objectClass: top
loginShell: /bin/tcsh
uidNumber: 902
gidNumber: 902
homeDirectory: /home/newuser
</pre>

Add the new information to the LDAP directory services.  On the server:

<pre>
# chcon system_u:object_r:slapd_db_t:s0 /tmp/newuserinfo.ldif
# ldapadd -ZZ -f newusergroup.ldif
</pre>

= Testing =

Everything should be set properly to allowing logging in.  To test,
simply go to the GDM login display on the client machine and login
using the 'newuser' user name and the the password created for that
user's Kerberos credentials.