Technical Concerns in Making /usr/local Visible to the Public


                                                                           Jingchen Zhou

                                                                           (May 27, 2003)


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 tell us more about what you are trying to accomplish we can recommend alternative solutions”


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 security concern if we would make /usr/local visible to the public via NFS, in particular when /usr/local does contain configurations and documents.     




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.


Alternative Solutions


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

total 70

drwxr-xr-x   8 jingchen other        512 Dec 19 15:29 admin

drwxr-xr-x   5 bin      bin         2560 May 15 10:24 bin

drwxr-xr-x   3 cddev    dev          512 Aug  1  2002 cd

drwxr-xr-x   9 cmlog    staff        512 Mar 17 11:44 cmlog

drwxr-xr-x  13 bin      bin          512 May 15 10:24 doc

drwxr-xr-x  10 cdepics  dev          512 May  1 11:27 epics

drwxr-xr-x   2 bin      bin          512 Mar 27 13:19 etc

drwxr-xr-x   2 root     other       5120 Sep  3  1997 icons

drwxr-xr-x   3 bin      bin          512 Mar 27 10:04 include

drwxr-xr-x   2 bin      bin         2560 Dec 18 16:54 info

drwxr-xr-x  11 bin      bin         2048 May 15 10:24 lib

drwxr-xr-x   3 bin      bin          512 Mar 27 10:15 libexec

drwx------   5 root     root         512 Jun 24  1998 lost+found

drwxr-xr-x   7 bin      bin          512 Jan 10  2002 man

drwxrwxr-x  12 root     other        512 Oct 18  2001 matlab6

drwxrwxr-x   4 root     other        512 Sep  3  2002 mclib

drwxr-xr-x  11 cddev    dev          512 Sep  4  2002 pepii

drwxr-xr-x   2 bin      bin          512 Mar 27 10:15 sbin

drwxr-xr-x   4 bin      bin          512 May 15 10:24 share

-rw-r--r--   1 root     other       1114 Mar 27 10:16 ssh_config

-rw-r--r--   1 root     other       2457 Mar 27 10:16 sshd_config

drwxr-xr-x  10 root     other        512 Mar 27 10:06 ssl

drwxr-xr-x   6 root     dev          512 Nov  8  2001 vxworks


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.