What we have done for the last 25 years on Unix and Linux systems to avoid this problem. On a separate disk we put /home, /usr/local, /opt to keep the OS install sysem from rewriting these directories. There is also a /co-lib disk that we keep all data sheets and parts info etc In a manufacturing environment this is real help.
We add these to the users PATH and everything works out pretty well. They can easily find information and added sw. It it doesn't run correctly we then have get a new version a crude way of doing things but it works. Above all else run a couple of back ups and keep on offsite. Our insurance agent kept a back of system on a separate box. The theirves stold it all and the only thing that saved him was we had upgraded his system a week before and the old disks were still on the shelf. So without the orig. disks a cloud back up may not be a solution. Larry Linder On Friday November 13 2015 7:36 am, Nico Kadel-Garcia wrote: > On Fri, Nov 13, 2015 at 7:28 AM, Nico Kadel-Garcia <nka...@gmail.com> wrote: > > On Thu, Oct 29, 2015 at 2:17 PM, Steve Gaarder <gaar...@math.cornell.edu> wrote: > >> I always thought that /usr/local was defined to be an area left alone by > >> the operating system. For many years, we have made it a symlink to a > >> read-only directory in AFS space. This has worked fine - until now. > >> When I tried to update the "filesystem" package, it failed because it > >> tried to do chmods on (at least) /usr/local/bin and /usr/local/etc. Why > >> is it doing this? Is /usr/local no longer truly local? > > Sorry, that was my own fault, Now I have my coffee. > > The /usr/local/ directories are part of the File System Hierarchy, at > http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY > The particular stanza you want to review is below: > > Requirements > > The following directories, or symbolic links to directories, must > be in /usr/local > > DirectoryDescription > bin Local binaries > etc Host-specific system configuration for local binaries > games Local game binaries > include Local C header files > > etc., etc. > > So, yes, it looks like upstream is following the File System > Hierarchy. To play nicely with it, you should ideally, replace the > subdirectories in /usr/local/ with individual symlinks. > > And you've my sympathies: I just spent some work dealing with systems > where someone had replaced "/opt" with a symlink to "/usr/local" and > not documented why anywhere, and seriously broke new software that > expected the SELinux privileges it had set for commercial software in > "/opt" to be useable.
