The linkchildren directive is a closely related to the cfengine model for NFS filesystems. It is a way of making links which embodies a rudimentary kind of `intelligence'.
links:
any::
/usr/local/lib/emacs +> linkchildren
The word linkchildren automatically tells cfengine that it should
look for an appropriate file to link to on a binary server for the
current host. The exact meaning of the above statement is as follows.
cfengine begins searching though the list of mountable resources,
discarding any filesystems which do not belong to valid binary servers.
It looks for a filesystem ending in `emacs' (the last link of the left
hand side). If all is well, these file systems are already mounted and
they can be searched. If no resource is found ending in `emacs', we go
to the next link lib and look for a filesystem ending in `lib'.
If this is not found we go to local and so on. When a match is
made, cfengine then tries to locate the file by checking whether it
exists relative to the matched filesystem. For example, suppose `local'
matched with host:/site/host/local. It would then try to locate
host:/site/host/local/lib/emacs and link all of the children
therein to the local file directory /usr/local/lib/emacs.
Here is another example which makes reference to the cfengine model for
mounting NFS filesystems. Suppose you have a host with some spare disk
space. You want to mount /usr/local from the binary architecture
server, but you also want to use the disk you have locally. The
following lines
links:
electron::
/$(site)/electron/local +> linkchildren
any::
/usr/local -> /$(site)/$(binserver)/local
have the effect of creating a directory /$(site)/electron/local
and filling it with links to all of the files and directories on the
binary server's mounted filesystem. It results in an exact copy (by
linkage) on the local disk, but does not use up your local disk space.
The space you have remaining could, for example, be used for software
with a special license for that host. The second link links
/usr/local to the `nearest' binary server. But the nearest
binary server is always $(host) which means this evaluates to a
file which now exists because of the first command, so on the host
`electron' the directory /usr/local ends up being a link to
/$(site)/electron/local which is full of links to the binary
server.
If you've caught your breath after that mouthful you probably have mixed feelings about creating a bunch of links in this way. What happens if the files they point to are removed? Then you are left with a lot of useless links. Actually this is no problem for cfengine, since you can ask cfengine to simply remove links which point to non-existent files See section files. Nevertheless, this feature clearly requires some caution and is mainly a spice for advanced users of the cfengine model.
Go to the first, previous, next, last section, table of contents.