Linux Desktop 2.0 - Centos 7 pilot project

News Update: On 2/21/2019, TG officially "moved in" to a SLAC managed Centos7 Linux Desktop 2.0 environment.  A major milestone!

This page describes certain features of the "Linux Desktop 2.0" pilot/R&D project.  While this project has been in progress for some time, these notes begin in July 2018.

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....

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  )

Notes:

1. X11 & GUI installed in this way:  

   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

   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:

• From the Applications menu, select System Tools and then Settings.  Or, use gnome-command-center from the command line.  Not all settings are available in this way.  There is a second utility accessed via Applications -> Utilities -> Tweak Tools, which offers additional desktop configurations.
• The gsettings command provides access to all of the dconf DB
• The GUI app, dconf-editor, which is not included in the centos7 installation by default, is a graphical front-end to gsettings

For example, to increase the idle time interval until the screen blanks and locks to one hour:

$ 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

To change gnome's default behavior of opening new windows maximized, do this:

$ gsettings set org.gnome.mutter auto-maximize false

gpg

If you use this encryption tool, it can be fussy about how it asks for your pass phrase, depending on, for example, whether you have a $DISPLAY variable set.  I've found that one way to force gpg to use a terminal-emulator style (e.g., curses) dialog is to create the following file:

$ cd ~/.gnupg
$ cat > gpg-agent.conf
pinentry-program /usr/bin/pinentry-curses
^D

OS Update Log

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.)

Currently recommended partition sizes are in blue.

Here is comet2's current disk config (on a 160 GB HDD):

$ lsblk
NAME                    MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda                       8:0    0 149.1G  0 disk 
├─sda1                    8:1    0   600M  0 part /boot
└─sda2                    8:2    0 148.5G  0 part 
  ├─VolGroup00-LogVol07 253:0    0  55.2G  0 lvm  /scratch
  ├─VolGroup00-LogVol01 253:1    0    30G  0 lvm  /opt
  ├─VolGroup00-LogVol06 253:2    0     5G  0 lvm  /tmp
  ├─VolGroup00-LogVol05 253:3    0     5G  0 lvm  /scswork
  ├─VolGroup00-LogVol04 253:4    0     4G  0 lvm  /usr/vice/cache
  ├─VolGroup00-LogVol03 253:5    0     8G  0 lvm  [SWAP]
  ├─VolGroup00-LogVol02 253:6    0    10G  0 lvm  /var
  └─VolGroup00-LogVol00 253:7    0    30G  0 lvm  /

Useful storage-related commands.

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.

'gsettings set org.gnome.nautilus.icon-view default-zoom-level small'

The second part of the log commences with the installation of a new SSD into comet2 and a complete re-install of all other software.

    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.

• At this time (1/7/2020), updating YFS without a concurrent OS kernel update may fail due to an issue with the kmod-yfs library.  The workaround is:

  sudo yum erase kmod-yfs-0.190-1.3.10.0_1062.9.1.el7.x86_64   # (substitute your current version)
  sudo yum update                                              # or "yum upgrade"

• 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:

  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.
  
  

  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.
  
  

  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