Technical Concerns in Making /usr/local Visible to the Public
This document is intended to list some of technical concerns in sharing our /usr/local via NFS with the general SLAC UNIX community. /usr/local is our local filesystem where all production software (executables, libraries, configurations and etc) are located.
The primary reason for making /usr/local visible to the public UNIX machines is that one would be able to read files on the production machines without login and thus quickly verify file status when needed. Such a convenience is apparently an advantage. Kristi may list more benefits. However, the price seems to be heavy. Quoted below is a response from SCS to our request:
“As you are no doubt aware, SCS strongly recommends against, and does not normally support, the practice of sharing local disks via NFS between user-managed workstations or servers and the general SLAC UNIX community. There are a number of reasons for this policy, including concerns about backup and about the instability and/or poor performance that can result from mixing different services on a single server.
However, our most serious concern is that problems on the server can hang all the clients, potentially disrupting the stability of nearly any UNIX machine at SLAC.
As far as we can recall, /nfs/opi00gtw00/u1 is a grandfathered exception to this policy. We would very much like to remove all such exceptions and would not be willing to permit a new one without a very strong justification and a careful review of how opi00gtw00 is currently used and maintained.
Perhaps if you
Listed below, on RonC’s request, is some technical concerns on our side. The hope is to examine all issues and to find a proper solution to meet Kristi’s need.
Reliability is my primary concern. The SCS’s concern that the problems on NFS server might hang all the clients is serious indeed, in particular if the clients include all of our production machines which are tailored by SCS. These tailored production machines include slcs1, slcs2, slcs6, opi00gtw04 and opi00gtw05 which are important to NLCTA, 8-pack and Babar. Furthermore, there would surely be a dependence for these machines on the availability of opi00gtw00; for instance, if opi00gwt00 is down for whatever reasons (whether system failure or maintenance), all these production machines may hang upon reboot. Of course, we may work out a way to make sure that the machines can boot up without opi00gtw00, but we will have to find a way to mount /usr/local on these machines later when opi00gtw00 is back. Nonetheless, there might be a period of confusion for users who want to access /usr/local via NFS mounting point and for NLCTA and 8-pack operations when opi00gtw00 is out of service. Simply put, we are likely to add more dependences of NLCTA and 8-pack on PEPII, which is exactly what we have been trying to avoid.
Security issue may not be as outstanding as reliability and maintenance in this matter. But we should be aware that
/usr/local is the most critical and essential local
filesystem, which is served by opi00gtw00 and maintains all production
software. The software includes executables, libraries, configurations and
documents critical to run the controls system. It could become a
Currently, slcsun1 is the only development machine on lavc although there are a few more (nlcdev-opi01,02,03,05) on nlcdev. In most cases, people do their development using more powerful SCS machines such like flora. If we limit /usr/local sharing only with our development and production machines which are tailored by SCS, then users will still have to log in these machines if they happen to work on flora (as in the most cases) in order to read /usr/local. Thus, the convenience which is the primary push for sharing, is itself in question: why not log in opi00gtw00 directly to view /usr/local plus other filesystems? How much convenience do users really gain by paying all these prices? Do users really want to give up flora and confine their work on our development machines?
If users want to enjoy the same kind of convenience on flora as on our machines as they should, then the question is that if SCS would allow us to mount /usr/local on flora.
Sharing /usr/local only to a list of machines that belongs us is doable. The maintenance may not be so trivial, however. For instance, the “SUDO” doesn’t grant me privilege to mount /usr/local on /nfs/opi00gtw00 which is maintained by SCS. We will have to reconfigure each of our systems, create each mounting point locally, automate mounting during reboot and maintain the mounting point individually on each system. These systems include slcsun1, slcs1, slcs2, slcs6, opi00gtw04, opi00gtw05, nlcdev-opi01, nlcdev-opi02, nlcdev-opi03, nlcdev-opi04, nlcdev-opi05. Again, we should be aware that maintenance work on opi00gtw00 could bring down these machines assuming these machines would rely on opi00gtw00.
Saying that much, I must say that my concerns are less than what SCS might have. If SCS is OK with /usr/local sharing, I will make an effort to make it happen. Just in case, the “tide” in SCS hasn’t changed to our favor, below can be some of alternatives. As always in the distributed environment, an authorized person can read files via SSH. For instance
jingchen@slcsun1 $ ssh opi00gtw00 ls -l /usr/local
drwxr-xr-x 8 jingchen other 512 Dec 19 admin
drwxr-xr-x 5 bin bin 2560 May 15 bin
drwxr-xr-x 3 cddev
drwxr-xr-x 9 cmlog staff 512 Mar 17 cmlog
drwxr-xr-x 13 bin bin 512 May 15 doc
drwxr-xr-x 10 cdepics dev 512 May 1 epics
drwxr-xr-x 2 bin bin 512 Mar 27 etc
drwxr-xr-x 2 root
drwxr-xr-x 3 bin bin 512 Mar 27 include
drwxr-xr-x 2 bin bin 2560 Dec 18 info
drwxr-xr-x 11 bin bin 2048 May 15 lib
drwxr-xr-x 3 bin bin 512 Mar 27 libexec
drwx------ 5 root
drwxr-xr-x 7 bin
drwxrwxr-x 12 root
drwxrwxr-x 4 root
drwxr-xr-x 11 cddev
drwxr-xr-x 2 bin bin 512 Mar 27 sbin
drwxr-xr-x 4 bin bin 512 May 15 share
-rw-r--r-- 1 root other 1114 Mar 27 ssh_config
-rw-r--r-- 1 root other 2457 Mar 27 sshd_config
drwxr-xr-x 10 root other 512 Mar 27 ssl
drwxr-xr-x 6 root
ssh opi00gtw00 cat will allow users to see the contents. For instance,
jingchen@slcsun1 $ ssh opi00gtw00 cat /usr/local/pepii/ctrl/prod/config/CONFIG
# Add any changes to make rules here
CROSS_COMPILER_TARGET_ARCHS = mv167 mv166 mv177 niCpu030 ppc603
Although this may not be as handy and natural as with NFS mounting point, it nearly gives users enough convenience to verify files on the production machines.
A very promising alternative would be to mirror our /usr/local to a designated and better protected public area. /nfs/opi00gtw00/usr/local is just fine. It would become a real copy of /usr/local on opi00gtw00. Authorized users could work on the files just like he/she would with NFS mounting. Technically speaking, it is nearly identical to NFS mounting, but there would be some delay (say some minutes, depending on how often mirroring is done). Would the minutes of delay be a big problem? I have tested and worked on a package called rsync, a very powerful software, which, as an alternative to rdist and scp, let us mirror files and directories between a local host and a remote host. Rsync uses SSH as a secure channel, and provides the most efficient file transfer by sending/receiving only the bytes insides files that changed since the last replication. With rsync, I can create a mirroring from /usr/local on opi00gtw00 to /nfs/opi00gtw00/usr/local on the public like:
opi00gtw00:/usr/local -> /nfs/opi00gtw00/usr/local.
Everything in /nfs/opi00gtw00/usr/local would look the same as /usr/local on opi00gtw00. I am sure SCS is more than happy to offer other alternatives.