Page History

...

There are an estimated 200-300 Linux desktop users at SLAC.  This project aims to provide a basic managed and maintained building block desktop from which users may customize to their specific needs.  At this writing, either Ubuntu or CentOS are available options.  This is very much a work in progress....

Table of Contents

To-Do

•   consider should the  user  have the netboot file remain active and have the user manually remove the link that makes it active  with
  echo "get Kickstart_end" | /usr/bin/tftp lnxpapa  or do this for them automatically after the first build. Make this an attribute for the node build ?  Consider this for ubuntu too - And ubuntu and kickstart are not great together, unless this is very, very dated https://help.ubuntu.com/community/KickstartCompatibility
• Decide if we want the pxekicktit to by default run chef on the node. As of 2018-09-27, a build with ks.cfg.centos7.linux_desktop_2 does not run chef. I suggest we do run chef in the default installation, and one picks ks.cfg.centos7.linux_desktop_2.no_chef_run  If one does not want to run chef.
• decide is this only for SLAC owned equipment or can users with non-SLAC equipment use the chef cookbooks - what does that mean for slac_motd - the content of that message does it change at all?

Current Pilot Machine Status

• A test machine, named comet2 (Dell Optiplex 9010, PC90105), was setup in Tom G's office, bldg 48/rm 248, on 7/13/2018.  Linux (centos7) was installed over the network.  Andrew set up the "old style" kerberos authentication to allow site-wide logins.  This is expected to change in the near future to a Windows authentication scheme.
• At this time, comet2 is considered available for reboot with little or no notification as experts continue their development of the deployment software.  Rebuilding from scratch becomes increasingly painful as more and more software is installed.
• As of 9/23/2018, a 2nd machine, ppa-pc89438-l, is also running centos7 in Warren Focke's office, bldg 48/rm 249, using Andrew's latest net install.

List of candidate add-on software to be included in CentOS 7 network-install image. 

(The initial network-install might not have all this - but one can add it with post install step(s). A status of 'required' does not mean that configuration management can do that, as of  10 Jan 2019 , but that is it considered a requirement by a user community at SLAC. The user communities represented here include LSST Camera, DESC and Fermi  )

...

1. X11 & GUI installed in this way:  

   Code Block
   title X11 and GUI
   curl http://yum/centos-gui > /tmp/centos-gui /bin/sh /tmp/centos-gui

   (very large set of packages, takes a long time...)
   
   

2. Software installed via the GUI, e.g., Thunderbird, emacs, LibreOffice

   Code Block
   sudo gnome-software

3. Attempt to install FastX downloaded from www.starnet.com.  Code is unpacked from a tar.gz file and run without any special installation.  Attempt to configure SLAC but code fails with a relocation error associated with /lib64/libssl.so.10.  Karl to the rescue!  Use the "ssh" connection rather than "https" while he queries the vendor for a proper fix.

4. TRS should not be used as it currently requires the use of DES enctypes that are insecure. WE have a todo to remove the ability for this weak-key to work. And are working to make TRS more secure so it can be used on Centos.
   
   

    

Configuration Hints

Desktop

The default desktop manager is gnome.  A large number of desktop settings are stored in the dconf database.  There are several ways to view/set these settings:

...

$ gsettings set org.gnome.desktop.session idle-delay 3600
$ gsettings get org.gnome.desktop.session idle-delay
uint32 3600


and
 
$ gsettings set org.gnome.desktop.screensaver lock-delay 0
$ gsettings get org.gnome.desktop.screensaver lock-delay
uint32 0

OS Updates

Disk Partitioning

The following table indicates a "standard" suggested disk partitioning for centos7 with a 1 TB SSD.  (Note: the machine, comet2, has 16 GB of RAM.)

...

On a new build, old or new hardware

1.  check if firmware updates need to happen

   - BIOS, IDRAC, DISK/PERC
   
   

2. NETDB needs for the node:

   a. NetDB must have the MAC address

   b. NetDB must have these dhcp-opt  options:  --options filename=pxelinux.0,next-server=lnxpapa,tftp-server-name=lnxpapa

   c. NetDB must have dhcp enabled

   d. Determine the pxeboot-kickstart to use. There are many!  and we should agree on which one to use. I'd recommend we make that part of the netdb record the way we do with some newer builds - I think it helps. See for instance comet2 pxekickit: CentOS7/default.netboot.CentOS7.linux_desktop_2  

   
   NOTE I would like to change the attribute name on the netdb record from 'pxekickit' to 'netboot'  I came up with the pxekickitit name, it made sense sorta at that time, but now that we will expect to have more than just kickstart builds, think Ubuntu, I think it better to just change this naming convention to netboot. 

   e. NetDB must have the MAC address
   
   

3. Determine is there anything special about this machine that needs to be considered

   If this is rhel[56] node with a taylor.opts take a look and see if there is a one to one correspondence between what taylor.opts is doing on the node and what we can do in chef.  For example, if the pre-cheffed node is using automounter, then all parties ( unix platform, the user)  need to know that no NFS native mounts are supported.

User Log

The first part of the log concerns the first build up on comet2.

...

    sudo semanage fcontext -a -t abrt_var_log_t '/var/adm'
    sudo restorecon -v '/var/adm'
    sudo systemctl restart rsyslog

# usermod -a -G wheel dragon

sudo yum clean all; sudo yum erase kmod-yfs; sudo yum install kmod-yfs; sudo yum upgrade

Gotchas

Here is a list of gotchas or concerns that I stumbled into during these project investigations.

• Tilde (~) does not work.  Remember that LD2.0 machines have their own user databases which are not the same as the SLAC site unix user database.  If you are accustomed to typing "$ ls ~lsstprod/workflows", that will no longer function.  It is not clear how to implement a good, reliable work-around.

• Absolute NFS file paths will be different.  Using sshfs means every remote file system must have a local mount point.  On central SLAC machines, "/nfs" works.  However, sshfs documentation recommends that mount points be r/w by the user and, usually, /nfs is not such a candidate.  So any scripts or aliases that use the "/nfs" path must be changed. [AFS/YFS is different in that if you elect to have the client installed, the absolute paths will look identical with that on a public SLAC machine.]
  ** WORKAROUND: On a single-user workstation in the SLAC network, the following example shows how to allow a customary absolute NFS path using a symbolic link:

  Code Block
  sudo ln -s /nfs /home/dragon/nfs mkdir -p /home/dragon/nfs/farm/g/lsst sshfs dragon@rhel6-64:/nfs/farm/g/lsst /nfs/farm/g/lsst

• Access to AFS home directories can proceed either via an absolute path, e.g., `/afs/slac/u/...` or one can create a symbolic link to recover the familiar `/u/ec/dragon/...` path.
  
  

  Code Block
  sudo ln -s /afs/slac.stanford.edu/u /u

• Lots of SLAC-written and SLAC-specific commands are no longer available locally, e.g., everything in /usr/local/bin
  ** WORKAROUND: Create an alias in your .bashrc to prefix your favorite SLAC command(s) with "ssh rhel6-64 ", e.g.
  
  

  Code Block
  alias person='ssh rhel6-64 person '

• Printing is currently possible via the unix print server, but I've heard rumors that this service might be deprecated and replaced with a Windows-based system.  Also, the current print config in use on comet2 is very rudimentary and needs further thought.  It does not, for example, know about printer-specific functions & capabilities, such as faxing, duplex printing, oddball paper sizes, etc.
  ** FIX: The "BrightQ" print drivers for Canon printers are straight-forward to install, interface seamlessly with CUPS, and offer all the features of my printer (a Canon C5255).  There is a bit of a rigamorole involved (one must "register" twice, once for download and again for installation), but in the end it worked well.  Get the drivers here: https://www.codehost.com/canon/
• Many users will need a moderately-to-highly customized application repertoire to work well for them.  The application list above is acceptable for my (TG) work needs. But there are items that even I need only rarely and it is not clear it is better to seek them out and install locally, or to simply log into a public login machine to use.  Here I am thinking of database tools, advanced development tools, TeX (and friends), more sophisticated printing capabilities, etc.
• While for may activities it is desirable to work locally, one will still need to log onto a public SLAC login machine (think licensed software, certain computing resource management functions, dealing with PPI,  etc.) There are certain files and directories that I would like synchronized between the desktop machine and my SLAC environment (such as ssh keys, personal logbook, app configurations).  Possibly a trscron job would do the trick, but then which copy becomes the master?  I would like a smart synchronizer that allows either environment to make changes that will then be reflected in the other environment.

References:

1. SLAC minimum security requirements:
   https://docs.slac.stanford.edu/sites/pub/Publications/701-I02-001-00_Min_Sec_Req_for_Comp.pdf

2. Stanford minimum security requirements:  
   https://uit.stanford.edu/guide/securitystandards

3. SLAC support for Linux:
   Ubuntu/CentOS 7 Desktop Scope of Support

...