6.4 Dealing with Symbolic Links
6.4.1 Description
Symbolic links can be extremely useful and can also provide a
massive cross-link headache for an administrator. How they are used can increase
the efficiency of your environment.
Example One: Linking System Files and Directories
Flavors: AT&T, BSD
It
is perfectly fine to create symbolic links for system directories such as, /bin,
/sbin, /usr, and /var. They should always be linked to a directory or partition
that is on the system disk. If the link is to a directory on a second disk and
that second disk goes offline, the system might not be able to boot in to a
multiuser or even a single user state. In many flavors of UNIX, the kernel uses
these areas during boot time and, if they cannot be seen, the system will not
boot.
If system files, such as /lib/sendmail.cf and other configuration
files are linked to other disks and filesystems, certain services like mail
might never get started if the filesystem has problems getting mounted. Always
try to keep the symbolic links on the same filesystem and disk drive that the
file currently resides on. If you don't, you only add one more possible
level of failure and put your system at risk.
Example Two: Creating Links to Links to Links
Flavors: AT&T, BSD
As
centralized file servers and NFS-mounted filesystems become more prevalent in
many environments, there is a need to share similar data to all the workstations.
This data typically includes man pages, online documentation, source code, binary
freeware programs, and project-related data. Most servers and systems today
are purchased having the capability of expanding the disk capacity in the future.
As new disks, volumes, or raid arrays are brought online to free
up disk space, administrators sometimes need to migrate existing data to the
new area. They often go for the easiest data that can be moved on to the new
disks. The nonvolatile static data that isn't constantly changing is usually
the first to go. Administrators simply copy the files to the new area and place
a symbolic link in its place. This way the user is pointing to a symbolic link
that points to another link, which points to the directory where the data resides.
rocket 27% ls -l /usr/local
lrwxrwxrwx 1 root 6 Oct 14 1996 /usr/local -> /hosts/planet/usr/local
rocket 28% ls -l /hosts/planet/usr/local
lrwxrwxrwx 1 root 6 Jan 12 1997 /hosts/planet/usr/local -> /hosts/planet/disk2/local
rocket 29% ls -l /hosts/planet/disk2/local
drwxr-xr-x 3 root 5120 Nov 6 14:34 bin/
drwxr-xr-x 5 root 512 Jul 30 14:23 src/
drwxr-xr-x 14 root 512 Mar 25 1997 gnu/
drwxr-xr-x 31 root 2048 Jun 29 1997 lib/
drwxr-xr-x 16 bin 512 Oct 21 1996 man/
You can see that a new area on the host planet has new disks located
at /disk2. The content of /usr/local is shared by all the workstation and is
symbolically linked to the new area from the old area. When the user attempts
to follow /usr/local to the new area, the system processes the request and takes
the user to the old area where a link is waiting to point the user to the new
location of where the files physically reside.
After all the files have been migrated and the new links are in
place, each workstation should be updated to reflect the change right away.
So the old link
rocket 30% ls -l /usr/local
lrwxrwxrwx 1 root 6 Oct 14 1996 /usr/local -> /hosts/planet/usr/local
is updated to point to the new location
rocket 8% mv local local.O; ln -s /hosts/planet/disk2/local /usr/local
rocket 31% ls -l /usr/local*
lrwxrwxrwx 1 root 6 Nov 22 12:22 /usr/local -> /hosts/planet/disk2/local
lrwxrwxrwx 1 root 6 Oct 14 1996 /usr/local.O -> /hosts/planet/usr/local
To limit the possibility of interrupting the user, execute a quick
move and link command back-to-back so the change happens instantaneously to
the user with little or no interruption.
rocket 32% mv local local.O; ln -s /hosts/planet/disk2/local /usr/local
|
Warning - Do not attempt this
quick move and link with open files or daemons locked to them. This can
play havoc with the some applications, including license managers.
|
Example Three: Searching for Dead Links
Flavors: AT&T, BSD
Shells: sh, perl
Syntax:
find [dir] -type l -print | perl -nle '-e || print'
Before you can start cleaning links up, you might want to search
for all the links that are unconnected to any files. As filesystems are moved
around to other partitions and even other hosts, symbolic links will break.
You can run a find and pipe it to a Perl routine
to check for nonexistent links; if it finds one, it prints it to STDOUT.
vi badlinks
#! /bin/sh
find . -type l -print | perl -nle '-e || print'
Line 1: Define the shell to be used.
Line 2: From the current directory, find all the files that are
links and check whether they are nonexistent. If so, print them to STDOUT.
You can then use the script to output all the bad links on the
system to a file.
# cd /
# badlinks > /usr/tmp/badlinks.txt
After all the bad links are discovered, you can generally relink
them to the new location of the files they used to be linked to. If you feel
that all the bad links are no longer needed on the system, you can pass the
badlinks script to the rm
program to remove the bad links for you.
# cd /
# rm `badlinks`
Starting at the root level, every time a bad link is found, it
is immediately removed from the system. There is a greater chance of these bad
links being discovered in user home directories and work areas. They tend to
create links to filesystems that can disappear or be changed by the system administrator,
escaping the user's notice until they are gone. It is best to run this
script immediately after you move any files from one area to another.
Example Four: Cleaning Up Links to Links to Links
Flavors: AT&T, BSD
In many cases, there are times that you might inherit a system
that has links pointing to multiple links within a system. This is one true
case where a directory had multiple links. Here the link didn't just connect
to another filesystem on the local workstation, but it went across two NFS filesystems
to a directory a remote host.
lrwxrwxrwx 1 root 6 Jun 22 1995 /usr/local/bin -> /var/local/bin
lrwxrwxrwx 1 root 6 Oct 10 1996 /var/local/bin -> /hosts/planet/usr2/local/bin
lrwxrwxrwx 1 root 6 May 24 1997 /hosts/planet/usr2/local/bin -> /hosts/planet/vol04/local
lrwxrwxrwx 1 root 6 Aug 12 16:22 /hosts/planet/vol04/local -> /hosts/saturn/vol01/local
This can be considered sloppy administration. The local binary
files that once resided in /usr were moved to /var. A file server called planet
was implemented and the files were accessed through NFS mount points to /usr2.
As it starting filling up, a new array was installed and the files were moved
to /vol04. Soon a new, faster fileserver came along to replace planet and the
files were moved to the host saturn on /vol01 and accessed through NFS mount
points.
In some cases, these links are done not by administrators, but
by users. In cleaning up repetitive links there are two ways that these can
be tackled. The local link either points to the physical directory or points
to a link on a remote server.
-
Pointing to the physical directory --In this
method, you take the local link and follow all the links until you come
to the end and reach the physical directory. This could be local or even
on a remote host. Create the symbolic link to point at this physical directory.
-
Pointing to the server --If there are plans
to move the files and directories around, it is best to make the link on
the local host point to most stable link on the server. In this example,
saturn (the new file server) has the most reliable links.
If there is more than one link for the same file or directory
on the local host, it is best to link the last one in the chain on the local
hosts to the physical destination or server.
lrwxrwxrwx 1 root 6 Jun 22 1995 /usr/local/bin -> /var/local/bin
Users tend to have scripts and programs that might have the paths
hard-coded. It is best to remove all the middle links first and, if nothing
breaks for the user, clean up the local links. Check with any users who might
be affected before you attempt this and before doing any mass cleanup of files
and links to make sure you don't crash their sessions or applications that
might be running.
Reason
Symbolic links are extremely flexible. They can cross filesystems
and networks to other systems. Most of all, you can have multiple names pointing
to the same piece of data, and that data can be either a file or a directory.
Real World Experience
On some flavors of UNIX the current path follows the link, and
on others it doesn't.
rocket 33% ls -al
lrwxrwxrwx 1 root 6 Jun 22 1995 /usr/people/jimmy -> /home/people/jimmy
rocket 34% cd /usr/people/jimmy
rocket 35% pwd
/home/people/jimmy
This sometimes confuses a user and makes them wonder whether their
files have changed or disappeared. You then have to assure them that nothing
has happened to their files and possibly spend a little time explaining what
transpired. If you notify the user before the changes, you can possibly avoid
any later phone calls.
There
is a caveat in creating a symbolic link to a filesystem that is NFS-mounted.
If that NFS mount point goes stale, you tend to see the system acting sluggishly
with any directory that has a link pointing to the slate mount point. For this
reason, you want to keep all symbolic links local to a server and never point
one to a filesystem over NFS mount points.
Whenever
possible, it is always better to have many local symbolic links pointing to
areas in the local system, rather than many local symbolic links pointing to
directories across an NFS mount point.
If you have the ability to have one host or server trusted by
all other systems, you can create symbolic links to all the important files
on all the systems. This way you never have to log in to a remote system to
change any files. There is some security risk at the cost of doing all the administration
from one location. If that one system is fully compromised, your entire network
of hosts could be at risk. To limit the risk, the password file and the root
.rhost file should not be included in this list of configuration files. Here
is how it works:
# mkdir /usr/ADMIN
# cd /usr/ADMIN
# mkdir motd inetd.conf sendmail.cf
# ls -l
drwxr----- 2 root sys 1024 Nov 23 18:08 inetd.conf/
drwxr----- 2 root sys 1024 Nov 23 18:09 motd/
drwxr----- 2 root sys 1024 Nov 23 18:07 sendmail.cf/
# cd motd
# ln -s /hosts/earth/etc/motd earth
# ln -s /hosts/pluto/etc/motd pluto
# ln -s /hosts/saturn/etc/motd saturn
# ls -l
lrwxrwxrwx 1 root sys 21 Nov 23 18:09 earth -> /hosts/earth/etc/motd
lrwxrwxrwx 1 root sys 21 Nov 23 18:09 pluto -> /hosts/pluto/etc/motd
lrwxrwxrwx 1 root sys 22 Nov 23 18:09 saturn -> /hosts/saturn/etc/motd
Now, whenever you need to update the message-of-the-day file on
all the systems you support, you don't have to log in to each and every
system to make the change. The files that would make good candidates for this
would be sendmail.cf, inetd.conf, ttys, inittab, hosts, and even the filesystem
table.
Other Resources
Man pages:
ln
© Copyright Macmillan USA. All rights
reserved.
