CentOS 7 and Chef

CentOS 7 is centrally supported at SLAC for the following platforms:

• VMware virtual machine
• OpenStack virtual machine
• Bare metal server with devctl for remote console
• Desktop productivity - under development.  If you wish to help testing, email unix-admin@slac.stanford.edu

Although RHEL 7 is also available if required by your application for support, CentOS 7 is preferred and recommended instead.  Any instructions below for CentOS 7 also apply for RHEL 7.

Step-by-step guide

These are the steps to install and configure CentOS 7 with Chef at SLAC for a headless bare metal server.
To request a CentOS 7 virtual machine (VM) in VMware or OpenStack, please email unix-admin@slac.stanford.edu . You can also find information about SLAC's OpenStack cluster here: https://confluence.slac.stanford.edu/display/SCSPub/Using+the+OpenStack+cluster+at+SLAC

1. Install CentOS 7 using either the Minimal or the DVD ISO available here (available on the SLAC network or VPN).  The ISO image can also be used for a USB key install.

   http://yum.slac.stanford.edu/iso/centos/7

   N.B. some systems may have gpt labeled drives which enable larger than 2.2TB drives, these require an entry in the kickstart script like:  part biosboot --fstype=biosboot --size=1

   Without this entry, the kickstart will halt telling you that you need to create a 1MB biosboot partition.

    

2. Log into your new CentOS 7 host. 
   Become root by using sudo or /bin/su. 
   Install Chef on bare metal or a VM by running this command (get a root prompt, or use sudo as shown below):

   curl -s http://yum.slac.stanford.edu/go-chef | sudo /bin/sh

   If you want to only configure yum, and not run any of the other Chef recipes, then don't run the above command, run this instead:

   curl -s http://yum.slac.stanford.edu/go-chef  >  /tmp/go-chef

   Then modify the /tmp/go-chef script, and change the chef-client command line towards the bottom to just run the slac_yum cookbook, something like this:

        [...] chef-client -l info -L /var/log/chef-client-install.log -r slac_yum

   Note these instructions are subject to frequent change, so please check back to this page for the most recent version. Configuring only yum, and nothing else, means that your CentOS 7 host is unmodified except it can now apply yum updates, even if your machine is on a private 172.X subnet.  If you need help, email unix-admin at slac.
   
   
   

3. After you have run one of the above curl commands, you can optionally install the AFS client. Do not install the AFS client unless you have to. AFS is optional for CentOS 7 and it is not required to have a centrally manged CentOS 7 host. The default SLAC CentOS 7 host will not have AFS installed, but it is available if you require it.
   
   You must run 'yum upgrade' before attempting to install and configure openafs with Chef.  This is to deal with RPM dependency resolution issues.  A reboot should not be necessary.

   $ sudo yum upgrade

   After you update the RPMs as shown above, here is the command to install, configure, and start openafs:

   $ sudo chef-client -o slac_openafs

   This recipe takes a long time to run since it compiles an openafs kernel module for the running kernel.  The openafs client will start automatically – no reboot is required. You will not automatically get an afs token when logging in.  The slac_openafs Chef cookbook will install and enable DKMS (dynamic kernel module system) so future kernel updates should rebuild an afs client module automatically at the time the updated kernel is installed.  Run the following command to get an afs token from your Kerberos ticket:

   $ aklog

   If you want to leave your home directory alone (ie, keep it on the local disk) then you are done.  But if you want to have your AFS home directory as your home directory on this machine when you login, here are the steps to do that:

   Edit this file: /etc/sssd/sssd.conf
   
   comment out the line that says:
   override_homedir = /home/%u
   Run this command:
   systemctl restart sssd
   
   Create a symlink by running this command:
   ln -s /afs/slac.stanford.edu/u /u
   
   You should now have this symlink:
   /u -> /afs/slac.stanford.edu/u
   
   logout and login - and you should be in your AFS home directory, but you still need to run 'aklog' to get an AFS token after logging in.
   
   
   

4.  Note, a Cheffed node by default does not limit login to the node, anyone at SLAC would be able to login to the node.  If you want to limit  login to the node please contact unix-admin@slac.stanford.edu with the name of the node and how you would like access to be restricted.

5. And still before you exit your root prompt, create a sudoers entry for yourself inside the /etc/sudoers.d directory.
   If you do not want or need sudo access, you can skip this step.
   
   You can copy and paste the following (replace 'ksa' with your username):
   cat > /etc/sudoers.d/user-ksa << EOF
   ksa   ALL=ALL
   EOF
   
   Be sure to read and fill out the sudo request form.  This is required for auditing purposes:
   https://www.slac.stanford.edu/comp/unix/auth/superuser-req.shtml
   
   
   

6. If you would like a Kerberos host keytab installed on your CentOS 7 host, send an email to unix-admin@slac.stanford.edu .

   The subject line of the email to unix-admin for a host keytab request should be "please update whitelist to include 'your_node_name_here'

   e.g "just cheffed node, please update whitelist to include lsst-aio02"

   
   Without a Kerberos host keytab, you will need to enter your SLAC password when connecting via ssh, even when you already have a Kerberos ticket granting ticket (TGT).  If you have unix-admin install a Kerberos host keytab, then you can use passwordless GSSPAI via ssh to connect without a password when you already have a Kerberos TGT.
   
   automation of putting a keytab on the host, is part of the chef short-term goals (Chef short-term todo list)   'automate method of putting node on whitelist, or putting node in system.info with chef.lastrun data which auto keytab install could use to determine if keytab can be installed'

Soon we will run the chef client as a daemon, but at the moment the go-chef command is a one-time configuration script, which will not install a cron job or a daemon to run chef periodically.  This is because we do not want to overwrite the access.netgroup.conf file and remove any modification you have made to the user login list.  Soon we will have your user login list maintained by Chef, but we are still working on that now.

After you install Chef using the go-chef script, your CentOS 7 host will be configured for central authentication using Unix Kerberos.

In addition, here is an incomplete list of the configuration items that will be configured by Chef (just to give you an idea):

• cron
• logrotate
• rsyslog
• /etc/motd
• root password
• kerberos
• ssh
• shells
• sssd
• ntp
• yum
• yum-cron
• sudo for unix-admin
• login access for unix-admin

These are the configuration items Scientific Computing Services (SCS) is working on next:

• AFS client
• Automated keytab installation (for passwordless ssh connections)
• NFS client
• grub2 configuration for bare metal server installation
• login access for users
• sudo access for users
• GDM login on video console for a desktop

In addition, the SLAC Desktop Support team are currently testing CentOS 7 on their lab machines. 

Scope of Support for CentOS 7 on the Desktop

CentOS 7 on the desktop should be thought of as a personal productivity machine, not a development or server. Development machines and servers can be hosted in virtual machines or bare metal machines in servers rooms. Virtualization platforms available include OpenStack, VMware, and (in the future) Amazon Web Services public cloud. AWS for SLAC use is currently being tested.

List of supported personal productivity applications.  The following are the applications supported by the Help Desk IT Desktop Support (ITDS) team.  These are standard RPM packages supported by Red Hat, or else standard supported applications (such as Outlook Web Access email web client).

Graphics Card Support

CentOS 7 includes supported drivers for proprietary graphics cards such as nVidia and ATI.  These supported drivers are included with each kernel update, so when you reboot into a new kernel, an updated graphics kernel module is available and your graphics will work. 

ITDS specifically does not support graphics drivers that are not part of the standard operating system.  If you want to replace the CentOS 7 support noveau driver with the proprietary Nvidia driver (for example), you are now responsible for any graphics configuration on your machine.  ITDS is not responsible for supporting non-standard graphics drivers.  When you replace the noveau driver with the Nvidia driver, special steps are required to verify the noveau driver gets blacklisted.  Also, each kernel update will require you to rebuild the Nvidia kernel module.  This is a non-standard configuration and is not covered under central support, because of the relationship between updated kernels and patching policy, the manual process of rebuilding the Nvidia kernel module with each kernel update, and the reboot policy.  If you wish to install the Nvidia driver, you need to have a documented procedure in place regarding how often you update the kernel, when you reboot the kernel, and when you rebuild the Nvidia kernel module after you reboot into a new kernel.  

Yum (RPM) Repositories

This is a list of the recommended yum repositories for CentOS 7 and RHEL 7.  Some of these will be enabled by default, and others can be enabled if you require them.

We do not recommend these repositories: ATrpms, RPMForge, RepoForge. Those repositories do not play well with RHEL or CentOS. You can easily break your system due to distribution RPMs being replaced by the third party RPMs, and therefore causing rpm dependency problems that prevent routine security patches from being applied. If you need RPMs or software that you cannot find in the recommended repositories above, email unix-admin@slac.stanford.edu for advice.

Frequently Asked Questions:

Please send any questions to unix-admin@slac.stanford.edu