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.
Contents
Automounting User Home Directories
Autofs/Autmount is used to automatically mounts user's home directories.
# yum install autofs
Edit /etc/auto.master
Add the following to the /etc/auto.master file:
/home /etc/auto.home
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
* -fstype=nfs4,sec=krb5,security_label,soft,intr,rsize=8192,wsize=8192,nosuid,tcp nfs.example.com:/home:&
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:
client# authconfig-tui
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.
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
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:
[root@sefos \]# mount -n --bind /home /mnt/export/home
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.
[root@sefos /] groupadd newuser [root@sefos /] useradd -m -s /sbin/nologin -g newuser newuser
- 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.
[root@sefos /] yum install migrationtools
- 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.
# Default DNS domain $DEFAULT_MAIL_DOMAIN = "example.com"; # Default base $DEFAULT_BASE = "dc=example,dc=com";
Group information
Next create the list of groups to migrate to LDAP.
[root@sefos ~] /usr/share/migrationtools/migrate_group.pl /etc/group group.ldif
The file group.ldif holds a list of ldif formatted group definitions that look similar to:
dn: cn=newuser,ou=Group,dc=example,dc=com objectClass: posixGroup objectClass: top cn: newuser userPassword: {crypt}x gidNumber: 501
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:
dn: cn=newuser,ou=Group,dc=example,dc=com objectClass: posixGroup objectClass: top cn: newuser gidNumber: 902
Add it to the LDAP directory services on the server:
# chcon system_u:object_r:slapd_db_t:s0 /tmp/newusergroup.ldif # ldapadd -ZZ -f newusergroup.ldif
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.
[root@sefos~] /usr/share/migrationtools/migrate_passwd.pl /etc/passwd users.ldif
The file users.ldif holds ldif formatted information that is similar to:
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
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.
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
Add the new information to the LDAP directory services. On the server:
# chcon system_u:object_r:slapd_db_t:s0 /tmp/newuserinfo.ldif # ldapadd -ZZ -f newusergroup.ldif
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.