Nicolas Williams wrote: > On Thu, Jan 25, 2007 at 01:31:25PM -0500, Kyle McDonald wrote: > >> If everything is in /usr/bin, how do I configure my users environments >> to look for these things on the network *before* /usr/bin, and yet allow >> them to get OS level things (mv, rm, ls, etc.) locally even when the >> network server is having issues? >> > > Networked filesystems are an issue no matter what. The issue isn't just > order of appearance in PATH: home directories are normally on NFS > servers too. > > Yes. But if my home directory is available, and I wnat to run ls on it, if /usr/bin is first in my path I don't notice that the server conaining gcc, gmake, or ghostscript or whatever is rebooting at the moment.
If /some/network/path/to/gnu/bin is first everything hangs up. I dont' think I'm the only existing Solaris admin who uses the 'kepp it al in one place, update it in only one place' idea to distributing and maintaining these tools. All of Suns customers with large networks of solaris machines are most likely going to be bit in some way by this. > And networked filesystems are an issue because the relevant filesystem > system calls are synchronous and don't provide a simple way for apps to > deal with timeouts. And that's because before networked filesystems > such features weren't needed. Those interfaces have stuck around due to > their ease of use and familiarity, and now we pay this price, that when > file servers go away their clients become unresponsive. > > That's only a problem if you can get the app to start running in the first place. That's a known issue, and something many users are prepared to deal with - at least they're getting the gdb they expect to get when things are all working correctly. >> I guess I'll just have to put the network path first, and then invest in >> HA-NFS. >> > > You had to do the latter anyways. > Well, the expense trade-off wasn't required before. This change (assuming I can't just not install these packages.) will force me to spend the money. > As to the former, avoid conflicts and you're OK; of course, we can > create conflicts any time, but that's part and parcel of the trade-offs > involved in serendipitous discovery. Life's tough. > > I don't understand the suggestion to 'avoid the conflicts'... How can I avoid having the Solaris Perl or GDB or whatever tool not conflict with the one I'm installing for my users? By putting Solaris's conflicts in /usr/gnu you're admitting that using a separate directory in the users' path is a good solution... but you only want it to be available to Solaris's conflicts not the end users? Why the double standard? -Kyle > Nico >
