...
Expand | ||
---|---|---|
| ||
7/13/2018 - comet2 machine arrives in bldg 48 rm 248. Kerberos authentication (temporary). Initial pass at identifying and installing needed software packages (above table) 8/28/2018 - comet2 rebuilt, lose login ability 9/28/2018 - regain ability to login via local account. Re-install needed packages. Also move offending file which causes polkitd to consume too much CPU, "A workaround that I've been using is to remove /etc/xdg/autostart/org.gnome.SettingsDaemon.Account.desktop until the above mentioned bug is fixed." (but this does not clear up the issue - polkitd still consumes 7-6% of the CPU continuously) 11/13/2018 - chef client installed (by Karl). Unexpectedly (to TG), this also activated unix kerberos authentication, thus I begin to use the 'dragon' (SLAC) account in favor of the dragon1 (local) account on comet2. 12/17/2018 - Karl adds 'dragon1' and 'dragon' accounts to /etc/group 'wheel' group. This allows a user to run, for example, the software installation tool GUI launched from the Applications -> System Tools menu in the WM. 12/19/2018 - Karl adds 'dragon' to sudo list. 1/14/2019 - Add system monitor to "top panel" in Gnome3 (right-click in that area no allows one to add new widgets): Applications->System Tools->Application Installer->Add-ons 1/18/2019 - Erik Chavez kindly provided two displayPort-to-DVI adaptors and that seems to work just fine with default display driver, etc. 1/22/2019 - install 'hdparm' on comet2 in anticipation of running with SSD. Use: "lsblk" to determine the device for the HDD/SSD, then "hdparm -I /dev/sda2" for details. (Current HDD is Western Digital 160 GB drive.) 1/24/2019 - Karl installed GTK+ v3, enabling build of galculator (./configure, make, make install). 1/24/2019 - Attempt to update BIOS on comet2 (from A26 -> A30). After multiple attempts, was unable to produce a bootable FreeDOS USB device using parted & unetbootin on comet2. However, using rufus (http://rufus.akeo.ie/) on a Win10 machine was trivial (and successful). BIOS was updated to version A30 on 1/25/2019. Hint: rename the Dell bios updater app so that it has 6 or fewer characters, or it will be abbreviated by DOS. 1/25/2019 - Reduce those huge desktop icons with
1/30/2019 - 'sudo yum install redhat-support-tool' and search for data on SSD/trim support in RHEL. 2/21/2019 - official "move in date". That is, switch comet < – > comet2 as my primary desktop computer 4/10/2019 - After a flurry of "Important OS Update" notifications, and after three reboots did not clear the notifications, Karl manually intervenes due to an issue with YFS: sudo yum clean all; sudo yum erase kmod-yfs; sudo yum install kmod-yfs; sudo yum upgrade
|
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.
Expand | ||||
---|---|---|---|---|
| ||||
2/19/2019 - Install 1 TB SSD in comet2 using partitioning scheme above. Andrew activates kerberos and adds me to sudo list. Then begin process of installing needed software all over again! 2/20/2018 -
2/21/2019 -
4/10/2019 - After a flurry of "Important OS Update" notifications, and after three reboots did not clear the notifications, Karl manually intervenes due to an issue with YFS:
|
Gotchas
Here is a list of gotchas or concerns that I stumbled into during this project investigations.
5/17/2019 - comet2 has been operating normally (no observed hardware hiccups) |
Gotchas
Here is a list of gotchas or concerns that I stumbled into during this 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.
- 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: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/lsstafs/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.
...