Cryptic Names
Some admins that really don't know how to name their machines like to put Sercie Code, Serial Number or Asset Code for the machine name. While they claim that this pack lot of info about the machine into the name, it is flawed in the sense that it defeats the purpose of naming the machine: It was supposed to be easy to remember and talk about! Such cryptic names are essentially the worse of both world and hated by users and sys admins alike.Certainly, if a user call and say my laptop lp3c4d7e battery isn't charing anymore, you can probably call dell and give them the service code that is embeded in the name to get a replacement battery. But if you get a page that pc78df53 has a virus, would you know who to talk or where to go to work on the machine?? Serial number, asset tag, and other such info should be kept in the inventory database and refered when necessary.
The whole exercise of naming machine is that they can be remembered. Those cryptic serial numbers and service code are so hard to remember that IP address may as well be used instead of the machine name!! Furthermore, IP address that one needs to remember is probably only one octet or two. Calling a machine x.x.13.25 is only 4 digits and may add the info that machine is on in building 1, floor 3. It would certainly be easier to remember and more meaningful than tag834761, as asset tag is not used 99.999% of the time of dealing with a machine.
So, in summary, don't upset everyone, try to at least please one set of people, and keep in mind that a name is supposed to be meaningful!
Network Application Tree
Lot of sys admin create a central repository of applications stored on NFS server, so that all users can easily gain access to the same set of applications at the same version. In environment where more than one platoform is supported, there are typically two ways of doing it:(1) /nfsapp/PLATFORM/program -or-
(2) /nfsapp/program/PLATFORM
PLATFORM could be a cascade of directories that represent things from uname -s, uname -m, uname -r, etc. For example:
Both choices seems largely the same. In reality either choice presents its own set of challenges, as multi-plaform management is obviously more complicated than a single platform. That said, from a sys admin and end user perspective, I would argue that option (1) is better. Developer might have a slight preference for option (2). The reason for the latter is likely because developers start writing code for one platform, then as they port their code to other platform, architecture dependent code get added as sub-directories. But if they plan for multi-architecture from the getgo, (1) wouldn't hinter their work.
As a sys admin, these are some reasons why I argue (1) is better:
$NFSBASE/oracle/bin
rather than
/nfsapp/oracle/$OS/$ARCH/bin
/nfsapp/$OS/$ARCH/oracle than
/nfsapp/oracle/$OS/$ARCH/, which the installer may change to /nfsapp/oracle/$OS/$ARCH/oracle
/nfsapp/$OS/$ARCH/oracle/bin:\
/nfsapp/$OS/$ARCH/oracle/jdbc/bin:\
/nfsapp/$OS/$ARCH/oracle/oui/bin:\
/nfsapp/$OS/$ARCH/oracle/opmn/bin:\
/nfsapp/$OS/$ARCH/oracle/perl/bin
than
/nfsapp/oracle/$OS/$ARCH/bin:\
/nfsapp/oracle/$OS/$ARCH/jdbc/bin:\
/nfsapp/oracle/$OS/$ARCH/oui/bin:\
/nfsapp/oracle/$OS/$ARCH/opmn/bin:\
/nfsapp/oracle/$OS/$ARCH/perl/bin
And, really, if using option (2), is one going to create path like /nfsapp/oracle/$OS/$ARCH/jdbc/$OS/$ARCH/bin? Even if one was up to doing it, installer like Oracle OUI won't likely make this easy.
Oracle is not the only such program. Other examples are gistic/MATLAB_Runtime_Component, GenePatternServer/Tomcat, etc ...
/nfsapp/$OS/$ARCH/sybyl8.1
and it will add parallel componets to:
/nfsapp/$OS/$ARCH/trigo
/nfsapp/$OS/$ARCH/sybylAdminTools
However, if one were to use option 2, the installer would need to see sybyl in the path twice: /nfsapp/sybyl/$OS/$ARCH/sybyl8.1
Resistance would be futile. If the last sybyl8.1 is removed, (ie used /nfsapp/sybyl/$OS/$ARCH/), the installer would place parallel components at a directory one level higher up, a mess that would eat out the $ARCH part of the PLATFORM definition, like this:
/nfsapp/sybyl/$OS/$ARCH/
/nfsapp/sybyl/$OS/trigo/
/nfsapp/sybyl/$OS/AdminTools/
This would present quite a hair pulling experience. The components could be mangled up to be redistributed into the original option 2's philosophy of <PROGRAM>/<PLATFORM>, but it would be a lot of work. Most programs natually just expect a local install that did not have to address the PLATFORM info, which is why option 1 is a more natural choice.
On the flip side, if you started with multiple platform but they are gradually dying, option (1) presents a structure that would be less tedious to work with when things fall back into a single structure. eg, you will find yourself working almost exclusively on /nfsapp/Linux/x86_64 and forget that /nfsapp/hpux/itanium/11.23 ever existed ;-)
Challenges present in both (1) and (2):
Option (1): /nfsapp/NOARCH/program.
Option (2): /nfsapp/program/NOARCH.
From the above, option (2) would be more elegant than option (1) as it allows config file closer to the directory of program's binary. However, I suggest that ALL config files be stored in a single directory, a la /etc/profile.d:
Option 1: /nfsapp/NOARCH/conf
Option 2: /nfsapp/conf/NOARCH
or simply, /nfsapp/conf
This way, one doesn't have to hunt all over the place for the config files (site.cshrc.csh, site.bash.profile, site.alias, tnsnames.ora and schrodinger.hosts will all be found in one place). Oracle now supports the use of environment variable TNSADMIN to point to the dir containing the config files and make this solution easy to implement. But for some older programs, one may have to link files from the program bin directory to the conf to preserve the "natural" location. eg, For old version of oracle, one could have link to a central config file as:
cd /nfsapp/SunOS/5.8/oracle-client-9i/network/admin/
ln ../../../../../conf/oracle-client-9i/network/admin/tnsnames.ora ./tnsnames.ora
Yes, the path is a bit ugly, but it is better than keeping many different versions for each version of the program, for each platform.
Option (1) allows for /nfsapp/PLATFORM to be mounted as /usr/local (or a subpart like /nfsapp/SunOS/5.9/ to be mounted as /opt/sfw). However, program tha need config files may not work as well. Using hard link instead of symbolic link help help around the problem if everything is based on the same NFS server.
Alternatively, /usr/local could be a sym link to /net/NFS-server/nfsapp/PLATFORM/, this allow for config file to be sym link to the config dir using ../ path, but csh's cd would show the real dir and make it quite unsigthy to the user :-(. If your orgainzation use sh/ksh/bash, then this isn't as big (or ugly) of a problem.
Finally, option (2) does not present an easy way to hide other PLATFORM binary on a given machine via mount or sym link of directories.
Many OS provides some sort of binary compatibilities between versions. For example, old binaries produced for Solaris 7 will work in Solaris 9 (the converse may not be true). A lazy (or prudent?) sys admin can sym link such programs into a single directory. However, if the user use csh/tcsh, the cd command would tend to expose all these paths and make things quite ugly (sh/ksh/bash is much better in hiding in this regard). Both option (1) and (2) would result in a spagetti of links, with option (2) having slighly fewer kinks as ARCH is at the end of the path and thus readily visible where things point to.
PS. AIX 4.3.3 binaries are not compatible with 5.x, HP-UX PA-RISC 11 binaries are not compatible with 11i.
[Doc URL: http://www.grumpyxmas.com/netArch.html]
[Doc URL: http://tin6150.github.io/psg/netArch.html]
(cc) Tin Ho. See main page for copyright info.
Last updated: 2009-03-03
[Doc URL: http://tin6150.github.io/psg/netArch.html]
(cc) Tin Ho. See main page for copyright info.
Last updated: 2009-03-03
hoti1
bofh1