http://selinuxproject.org/w/?title=Labeled_NFS/Demo/Manual/Post-Install&limit=100&action=history&feed=atom Labeled NFS/Demo/Manual/Post-Install - Revision history 2024-03-29T07:33:31Z Revision history for this page on the wiki MediaWiki 1.23.13 http://selinuxproject.org/w/?title=Labeled_NFS/Demo/Manual/Post-Install&diff=345&oldid=prev CraigGrube: New page: 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 ent... 2008-12-11T14:16:13Z <p>New page: 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 ent...</p> <p><b>New page</b></p><div>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.<br /> <br /> = Automounting User Home Directories =<br /> <br /> Autofs/Autmount is used to automatically mounts user's home directories.<br /> &lt;pre&gt;<br /> # yum install autofs<br /> &lt;/pre&gt;<br /> <br /> == Edit /etc/auto.master ==<br /> <br /> Add the following to the /etc/auto.master file:<br /> <br /> &lt;pre&gt;<br /> /home /etc/auto.home<br /> &lt;/pre&gt;<br /> <br /> == Edit /etc/auto.home ==<br /> <br /> The file /etc/auto.home should have the following line in it.<br /> * An administrator may want to adjust some of the NFS parameters<br /> &lt;pre&gt;<br /> * -fstype=nfs4,sec=krb5,security_label,soft,intr,rsize=8192,wsize=8192,nosuid,tcp nfs.example.com:/home:&amp;<br /> &lt;/pre&gt;<br /> <br /> = Enable Kerberos Authentication and LDAP User Information on the Client =<br /> <br /> At the command line, run the authentication configuration tools on<br /> the client machine '''authconfig-tui''':<br /> <br /> &lt;pre&gt;<br /> client# authconfig-tui<br /> &lt;/pre&gt;<br /> <br /> It presents a number of terminal selection boxes. The first one is<br /> '''Authentication Configuration'''<br /> <br /> Under '''Authentication''':<br /> * Select '''Use Kerberos'''<br /> ** This enables logins via Kerberos.<br /> ** this can change a number of files, the PAM configuration is the main one.<br /> * Leave selected or select '''Use Shadow Passwords''' and '''Local authorization is sufficient'''<br /> ** This allows local passwords to work as well.<br /> <br /> Under '''User Information''':<br /> * Select '''Use LDAP'''<br /> <br /> Select '''Next'''<br /> <br /> It now presents '''LDAP Settings'''. This should have the correct<br /> configuration information from previously configuring the LDAP<br /> server. But if it is blank or just to double check:<br /> * '''Use TLS''' should be selected.<br /> * '''Server:''' should be the LDAP server<br /> ** e.g. ldap://sefos.example.com<br /> * '''Base DN:''' should be the base DN<br /> ** e.g. dc=example,dc=com<br /> <br /> Select '''Next'''<br /> <br /> It now presents '''Kerberos Settings'''. Again, this should have<br /> the correct configuration information from previously configuring<br /> the Kerberos server. But if it is blank or just to double check:<br /> * '''Realm:''' should be the local realm<br /> ** e.g. EXAMPLE.COM<br /> * '''KDC:''' should be the name of the Kerberos KDC<br /> ** e.g. sefos.example.com (the port number, 88, may be appended)<br /> * '''Admin Server:''' should be the Kerberos Admin server<br /> ** e.g. sefos.example.com (the same as the KDC in this example; the port number, 749, may be appended)<br /> * leave unselected '''Use DNS to resolve hosts to realms'''<br /> * leave unselected '''Use DNS to locate KDCs for realms'''<br /> <br /> <br /> = Adding Users =<br /> <br /> After following the previous instructions, the network's Kerberos,<br /> NFS, and LDAP services are ready to be used by a client machine.<br /> But the user information necessary to make everything work has not<br /> been added yet. For most enterprises, the existing user<br /> provisioning system will need to be modified in some fashion to<br /> perform the following steps when adding a user. With the exception<br /> of some of the LDAP loading, what follows is mostly manual<br /> instructions for adding the user information for a single user. In<br /> a production system, these steps should be scripted and integrated<br /> into an enterprise's provisioning system to simplify user changes.<br /> <br /> == Kerberos Principles ==<br /> <br /> The first step is to create a Kerberos principal for a new user. For this example, '''newuser''' is used. <br /> * This command needs to be done by a principal that has write access to the Kerberos data.<br /> <br /> &lt;pre&gt;<br /> root@sefos/etc kadmin<br /> Authenticating as principal root/admin@EXAMPLE.COM with password.<br /> Password for root/admin@EXAMPLE.COM:<br /> kadmin: addprinc newuser<br /> NOTICE: no policy specified for newuser@EXAMPLE.COM; assigning &quot;default&quot;<br /> Enter password for principal &quot;newuser@EXAMPLE.COM&quot;:<br /> Re-enter password for principal &quot;newuser@EXAMPLE.COM&quot;:<br /> Principal &quot;newuser@EXAMPLE.COM&quot; created.<br /> kadmin: listprincs<br /> K/M@EXAMPLE.COM<br /> host/seclient.example.com@EXAMPLE.COM<br /> host/sefos.example.com@EXAMPLE.COM<br /> kadmin/admin@EXAMPLE.COM<br /> kadmin/changepw@EXAMPLE.COM<br /> kadmin/history@EXAMPLE.COM<br /> kadmin/sefos.example.com@EXAMPLE.COM<br /> krbtgt/EXAMPLE.COM@EXAMPLE.COM<br /> ldap/sefos.example.com@EXAMPLE.COM<br /> newuser@EXAMPLE.COM<br /> nfs/seclient.example.com@EXAMPLE.COM<br /> nfs/seclient.example.com@EXAMPLE.COM<br /> nfs/sefos.example.com@EXAMPLE.COM<br /> root/admin@EXAMPLE.COM<br /> &lt;/pre&gt;<br /> <br /> '''Note''': The listprincs results have been truncated here.<br /> 'listprincs' was just run to check that 'newuser' was created.<br /> <br /> == Creating Home Directories ==<br /> <br /> NFS home directories can be handled in a number of different ways.<br /> This is just one way to do it. In this example, the NFS server's<br /> /mnt/export/home directory is bound to the local /home directory.<br /> <br /> From the command line or placed in /etc/rc.d/rc.local for automatic<br /> binding at boot time:<br /> &lt;pre&gt;<br /> [root@sefos \]# mount -n --bind /home /mnt/export/home<br /> &lt;/pre&gt;<br /> <br /> Each new user is then created on the NFS server. An explicit Group<br /> ID number (GID) and User ID number (UID) can also be given with the<br /> commands below, although it is not necessary. Unique numbers are<br /> generated automatically.<br /> <br /> &lt;pre&gt;<br /> [root@sefos /] groupadd newuser<br /> [root@sefos /] useradd -m -s /sbin/nologin -g newuser newuser<br /> &lt;/pre&gt;<br /> <br /> * The GUI 'system-config-users' can also be used.<br /> * 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.<br /> * 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.<br /> * '-m' creates a new /home/ directory for the user and copies the skeleton files (/etc/skel/) into it.<br /> ** 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.<br /> ** Since the home/ directory is bound to /mnt/export/home/, the NFS user's home/ directory and default skeleton files are automatically created.<br /> <br /> == LDAP User Information ==<br /> <br /> The next step is to add user information into the LDAP directory<br /> service. For most Enterprise systems this likely will be scripted.<br /> The OpenLDAP package has a number of schemas in place to handle user<br /> information that this example will build from. The package<br /> migrationtools is a good place to get started.<br /> <br /> === Migrationtools ===<br /> <br /> Migrationtools is a set of '''Perl''' scripts that convert a number<br /> of different standard network information databases into a format<br /> that can be added into a LDAP directory service.<br /> &lt;pre&gt;<br /> [root@sefos /] yum install migrationtools<br /> &lt;/pre&gt;<br /> * Installs scripts into /usr/share/migrationtools<br /> <br /> It should be noted that migrationtools has scripts for transferring<br /> everything at once, migrate_all_online.pl and<br /> migrate_all_offline.pl. Since this example is just interested in<br /> the user information (user, group, home directory, etc...), these<br /> scripts are not used. To just grab the pertinent user information<br /> and place it into the LDAP directory service, the scripts<br /> /usr/share/migrationtools/migrate_passwd.pl and<br /> /usr/share/migrationtools/migrate_group.pl are run to generate user<br /> information for the LDAP directory. 'migrate_password.pl' will pull<br /> user information out of a unix /etc/passwd file and put it into a<br /> LDAP ldif formatted output file. 'migrate_group.pl' will pull group<br /> information out of a unix /etc/group file and put it in a LDAP ldif<br /> formatted output file. This assumes there is an existing unix<br /> system with user's and group's that should be in the LDAP directory<br /> service.<br /> <br /> To make life easier, there is a configuration script,<br /> /usr/share/migrationtools/migrate_common.ph that holds two pieces of<br /> information that should change. Change the default domain and base<br /> in this file to the desired values for the current domain.<br /> <br /> &lt;pre&gt;<br /> # Default DNS domain<br /> $DEFAULT_MAIL_DOMAIN = &quot;example.com&quot;;<br /> <br /> # Default base<br /> $DEFAULT_BASE = &quot;dc=example,dc=com&quot;;<br /> &lt;/pre&gt;<br /> <br /> === Group information ===<br /> <br /> Next create the list of groups to migrate to LDAP.<br /> <br /> &lt;pre&gt;<br /> [root@sefos ~] /usr/share/migrationtools/migrate_group.pl /etc/group group.ldif<br /> &lt;/pre&gt;<br /> <br /> The file group.ldif holds a list of ldif formatted group<br /> definitions that look similar to:<br /> <br /> &lt;pre&gt;<br /> dn: cn=newuser,ou=Group,dc=example,dc=com<br /> objectClass: posixGroup<br /> objectClass: top<br /> cn: newuser<br /> userPassword: {crypt}x<br /> gidNumber: 501<br /> &lt;/pre&gt;<br /> <br /> For the example, this individual record is pulled out and placed in<br /> a separate file, 'newusergroup.ldif'. <br /> * The '''userPassword''' value is not needed here, so it is excised.<br /> * The '''gidNumber''' should be unique within the network user information.<br /> ** For this example, this means unique within the LDAP directory server.<br /> ** 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.<br /> <br /> <br /> The new file 'newusergroup.ldif' now looks like:<br /> <br /> &lt;pre&gt;<br /> dn: cn=newuser,ou=Group,dc=example,dc=com<br /> objectClass: posixGroup<br /> objectClass: top<br /> cn: newuser<br /> gidNumber: 902<br /> &lt;/pre&gt;<br /> <br /> Add it to the LDAP directory services on the server:<br /> <br /> &lt;pre&gt;<br /> # chcon system_u:object_r:slapd_db_t:s0 /tmp/newusergroup.ldif<br /> # ldapadd -ZZ -f newusergroup.ldif<br /> &lt;/pre&gt;<br /> <br /> === User Information ===<br /> <br /> 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.<br /> <br /> &lt;pre&gt;<br /> [root@sefos~] /usr/share/migrationtools/migrate_passwd.pl /etc/passwd users.ldif<br /> &lt;/pre&gt;<br /> <br /> The file users.ldif holds ldif formatted information that is similar to:<br /> <br /> &lt;pre&gt;<br /> dn: uid=newuser,ou=People,dc=example,dc=com<br /> uid: newuser<br /> cn: newuser<br /> objectClass: account<br /> objectClass: posixAccount<br /> objectClass: top<br /> objectClass: shadowAccount<br /> userPassword: {crypt}!!<br /> shadowLastChange: 14071<br /> shadowMax: 99999<br /> shadowWarning: 7<br /> loginShell: /sbin/nologin<br /> uidNumber: 502<br /> gidNumber: 502<br /> homeDirectory: /home/newuser<br /> &lt;/pre&gt;<br /> <br /> This as also parsed down to the values we need for this example and placed within a separate file, 'newuserinfo.ldif'.<br /> * 'objectClass: shadowAccount', userPassword, shadowLastChange, shadowMax, and shadowWarning are all excised as they are not pertinent to the network user information in this example.<br /> * loginShell is changed to a useful login shell.<br /> * The group ID (GID) is changed to match the newuser group that was just created.<br /> * 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).<br /> ** The UID is set above the F9 default 500+ UID values to try to avoid conflicting numbers.<br /> <br /> &lt;pre&gt;<br /> dn: uid=newuser,ou=People,dc=example,dc=com<br /> uid: newuser<br /> cn: newuser<br /> objectClass: account<br /> objectClass: posixAccount<br /> objectClass: top<br /> loginShell: /bin/tcsh<br /> uidNumber: 902<br /> gidNumber: 902<br /> homeDirectory: /home/newuser<br /> &lt;/pre&gt;<br /> <br /> Add the new information to the LDAP directory services. On the server:<br /> <br /> &lt;pre&gt;<br /> # chcon system_u:object_r:slapd_db_t:s0 /tmp/newuserinfo.ldif<br /> # ldapadd -ZZ -f newusergroup.ldif<br /> &lt;/pre&gt;<br /> <br /> = Testing =<br /> <br /> Everything should be set properly to allowing logging in. To test,<br /> simply go to the GDM login display on the client machine and login<br /> using the 'newuser' user name and the the password created for that<br /> user's Kerberos credentials.</div> CraigGrube