302 lines
11 KiB
Plaintext
302 lines
11 KiB
Plaintext
IMPORTANT NOTE:
|
|
|
|
As of Feb. 11, 2002 (and indeed, for quite some time before that),
|
|
the /etc/rc.diskless{1,2} scripts support a slightly different
|
|
diskless boot process than the one documented in the rest of
|
|
this file (which is 3 years old).
|
|
|
|
I am not deleting the information below because it contains some
|
|
useful background information on diskless operation, but for the
|
|
actual details you should look at /etc/rc.diskless1, /etc/rc.diskless2,
|
|
and the /usr/share/examples/diskless/clone_root script which can
|
|
be useful to set up clients and server for diskless boot.
|
|
|
|
--- $FreeBSD$ ---
|
|
------------------------------------------------------------------------
|
|
|
|
TEMPLATING machine configurations
|
|
|
|
Matthew Dillon
|
|
dillon@backplane.com
|
|
|
|
This document describes a general mechanism by which you can template
|
|
/ and /usr. That is, to keep a 'master template' of / and /usr on a
|
|
separate machine which is then used to update the rest of your machines.
|
|
|
|
Generally speaking, you can't simply mirror /. You might be able to
|
|
get away with mirroring /usr. There are two main problems involved with
|
|
templating:
|
|
|
|
(1) Avoiding overwriting run-time generated files
|
|
|
|
By default, the system maintains a number of files in the root
|
|
partition. For example, sendmail will dbm /etc/aliases into
|
|
/etc/aliases.db. vipw or chpass or other password related routines
|
|
will regenerate the password dbm's /etc/spwd.db, /etc/pwd.db, and
|
|
passwd. /etc/namedb/s might contain generated secondaries. And
|
|
so forth.
|
|
|
|
The templating mechanism must avoid copying over such files.
|
|
|
|
(2) Customizing machines.
|
|
|
|
Customizing machines is actually considerably simpler. You create
|
|
a configuration hierarchy and convert the configuration files that
|
|
have to be customized into softlinks that run through a special
|
|
softlink in the configuration directory. This will work for every
|
|
configuration file except possibly /etc/master.passwd
|
|
|
|
For example, /etc/resolv.conf would be turned into a softlink to
|
|
/conf/ME/resolv.conf, and /conf/ME itself would be a softlink to
|
|
/conf/<HOSTNAME>. The actual resolv.conf configuration file
|
|
would reside in /conf/<HOSTNAME>.
|
|
|
|
If you have a lot of hosts, some configuration files may be commonly
|
|
classified. For example, all your shell machines might have the
|
|
same /etc/resolv.conf. The solution is to make
|
|
/conf/<HOSTNAME>/resolv.conf a softlink to a common directory, say
|
|
/conf/HT.SHELL/resolv.conf. It may sound a little messy, but this
|
|
sort of categorization actually makes the sysadmins job much, much
|
|
easier.
|
|
|
|
The /conf/ directory hierarchy is stored on the template and
|
|
distributed to all the machines along with the rest of the root
|
|
partition.
|
|
|
|
This type of customization is taken from my direct experience
|
|
instituting such a system at BEST. At the time, BEST had over 45
|
|
machines managed from a single template.
|
|
|
|
RUN-TIME GENERATED OR MODIFIED FILES IN / or /USR
|
|
|
|
/etc/aliases.db
|
|
/etc/master.passwd
|
|
/etc/spwd.db
|
|
/etc/pwd.db
|
|
/etc/passwd
|
|
/etc/namedb/s
|
|
/root/.history
|
|
/root/.ssh/identity
|
|
/root/.ssh/identity.pub
|
|
/root/.ssh/random_seed
|
|
/root/.ssh/known_hosts
|
|
/conf/ME
|
|
/kernel* ( note 2 )
|
|
/dev ( note 3 )
|
|
/var ( note 4 )
|
|
/home ( note 4 )
|
|
/lost+found
|
|
|
|
/usr/lost+found
|
|
/usr/home ( note 4 )
|
|
/usr/crash ( note 5 )
|
|
/usr/obj ( note 5 )
|
|
/usr/ports ( note 5 )
|
|
/usr/src ( note 5 )
|
|
/usr/local/crack ( note 5 )
|
|
/usr/X11R6/lib/X11/xdm/xdm-errors ( note 6 )
|
|
/usr/X11R6/lib/X11/xdm/xdm-pid ( note 6 )
|
|
/usr/local/etc/ssh_host_key ( note 6 )
|
|
/usr/local/etc/ssh_host_key.pub ( note 6 )
|
|
/usr/local/etc/ssh_random_seed ( note 6 )
|
|
|
|
/conf/ME ( note 7 )
|
|
|
|
note 2: You typically want to update kernels manually and *NOT*
|
|
template them as a safety measure. This also allows you to run
|
|
different kernels on different machines or.
|
|
|
|
note 3: /dev must be updated manually. Some devices, such as tty's and
|
|
pty's, use the access and/or modify time and/or user/group
|
|
operationally and regenerating the devices on the fly would be
|
|
bad.
|
|
|
|
note 4: /var and /home are usually separately mounted partitions and
|
|
thus would not fall under the template, but as a safety measure
|
|
the template copier refuse to copy directories named 'home'.
|
|
|
|
note 5: These are directories that are as often created directly on
|
|
/usr as they are separately-mounted partitions. You typically
|
|
do not want to template such directories.
|
|
|
|
note 6: Note that you can solve the problem of xdm and sshd creating
|
|
files in /usr. With xdm, edit /usr/X11R6/lib/xdm/xdm-config
|
|
and change the errorLogFile and pidFile config lines.
|
|
|
|
With sshd, add 'HostKey' and 'RandomSeed' directives to specify
|
|
/var/db for the location of the host key and run-time sshd
|
|
random seed:
|
|
|
|
HostKey /var/db/ssh_host_key
|
|
RandomSeed /var/db/ssh_random_seed
|
|
|
|
note 7: In this example, /conf/ME is the machine customizer and must
|
|
be pointed to the /conf/<full-host-name>/ directory, which is
|
|
different for each machine. Thus, the /conf/ME softlink
|
|
should never be overwritten by the templating copy.
|
|
|
|
|
|
TYPICAL CUSTOMIZED CONFIGRATION SOFTLINKS
|
|
|
|
The following files typically need to be turned into softlinks
|
|
to /conf/ME/<filename>:
|
|
|
|
/etc/ccd.conf -> /conf/ME/ccd.conf
|
|
/etc/ipfw.conf ...
|
|
/etc/fstab
|
|
/etc/motd
|
|
/etc/resolv.conf
|
|
/etc/aliases
|
|
/etc/sendmail.cw
|
|
/etc/organization
|
|
/etc/named.conf
|
|
/etc/rc.conf.local
|
|
/etc/printcap
|
|
/etc/inetd.conf
|
|
/etc/login.conf
|
|
/etc/gettytab
|
|
/etc/ntp.conf
|
|
/etc/exports
|
|
/root/.k5login -> /conf/ME/root/.k5login
|
|
|
|
And, of course, /conf/ME is usually a softlink to the appropriate
|
|
/conf/<full-host-name>/. Depending on your system configuration,
|
|
there may be other files not listed above that you have to worry about.
|
|
|
|
In many cases, /conf/ME/filename is itself a softlink to
|
|
"../HT.xxxx/filename", where HT.xxxx is something like HT.STD ... this
|
|
added complexity actually makes it easier to manage multiple
|
|
classifications of machines.
|
|
|
|
DELETION OF FILES
|
|
|
|
Any file found on the template destination that does not exist in the
|
|
source and is not listed as an exception by the source should be deleted.
|
|
However, deletion can be dangerous and cpdup will ask for confirmation
|
|
by default. Once you know you aren't going to blow things up, you can
|
|
turn this feature off and update your systems automatically from cron.
|
|
|
|
By formalizing the delete operation, you can be 100% sure that it is
|
|
possible to recreate / and /usr on any machine with only the original
|
|
template and a backup of the ( relatively few ) explicitly-excepted
|
|
files. The most common mistake a sysop makes is to make a change to a
|
|
file in / or /usr on a target machine instead of the template machine.
|
|
If the target machine is updated once a night from cron, the sysop
|
|
quickly learns not to do this ( because his changes get overwritten
|
|
overnight ). With a manual update, these sorts of mistakes can propagate
|
|
for weeks or months before they are caught.
|
|
|
|
TEMPLATE COPYING AND SAFETY
|
|
THE CPDUP PROGRAM
|
|
|
|
The 'cpdup' program is a program which efficiently duplicates a directory
|
|
tree. The program copies source to destination, duplicating devices,
|
|
softlinks, hardlinks, files, modification times, uid, gid, flags, perms,
|
|
and so forth. The program incorporates several major features:
|
|
|
|
* The program refuses, absolutely, to cross partition boundaries.
|
|
i.e. if you were copying the template /usr from an NFS mount to
|
|
your /usr, and you had a mount point called /usr/home, the
|
|
template copying program would *NOT* descend into /usr/home on
|
|
the destination.
|
|
|
|
This is a safety.
|
|
|
|
* The program accesses a file called .cpignore in each directory
|
|
it descends into on the source to obtain a list of exceptions
|
|
for that directory -- that is, files not to copy or mess with.
|
|
|
|
This is a templating function.
|
|
|
|
* The program refuses to delete a directory on the destination
|
|
being replaced by a softlink or file on the source.
|
|
|
|
This is a safety mechanism
|
|
|
|
* The program is capable of maintaining MD5 check cache files and
|
|
doing an MD5 check between source and destination during the
|
|
scan.
|
|
|
|
* The program is capable of deleting files/directories on the
|
|
destination that do not exist on the source, but asks for
|
|
confirmation by default.
|
|
|
|
This is a templating and a safety mechanism.
|
|
|
|
* The program uses a copy-to-tmp-and-rename methodology allowing
|
|
it to be used to update live filesystems.
|
|
|
|
This is a templating mechanism.
|
|
|
|
* The program, by default, tries to determine if a copy is required
|
|
by checking modify times, file size, perms, and other stat
|
|
elements. If the elements match, it does not bother to copy
|
|
( unless an MD5 check is being made, in which case it must read
|
|
the destination file ).
|
|
|
|
You typically run cpdup on the target machine. The target machine
|
|
temporarily mounts the template machine's / and /usr via NFS, read-only,
|
|
and runs cpdup to update / and /usr. If you use this methodology note
|
|
that THERE ARE SECURITY CONSIDERATIONS! See 'SECURITY CONSIDERATIONS WITH
|
|
NFS' below.
|
|
|
|
Whatever script you use that does the NFS mounts should ensure that the
|
|
mount succeeded before continuing with the cpdup.
|
|
|
|
You should create .cpignore files in the appropriate directories on the
|
|
template machine's / and /usr partitions so as not to overwrite active
|
|
files on the target. The most critical .cpignore files should be
|
|
protected with 'chflags schg .cpignore'. Specifically, the ones in /
|
|
and /etc, but possibly others as well. For example, the .cpignore
|
|
hierarchy for protect /root is:
|
|
|
|
# /root/.cpignore contains
|
|
.history
|
|
|
|
# /root/.ssh/.cpignore contains
|
|
random_seed
|
|
known_hosts
|
|
authorized_keys
|
|
identity
|
|
identity.pub
|
|
|
|
WHEN INITIALLY CONVERTING A TARGET MACHINE TO USE TEMPLATING, ALWAYS
|
|
MAKE A FULL BACKUP OF THE TARGET MACHINE FIRST! You may accidently delete
|
|
files on the target during the conversion due to forgetting to enter
|
|
items into appropriate .cpignore files on the source.
|
|
|
|
SECURITY CONSIDERATIONS WITH NFS ROOT EXPORT FROM TEMPLATE MACHINE
|
|
SECURITY CONSIDERATIONS WITH NFS USR EXPORT FROM TEMPLATE MACHINE
|
|
|
|
There are some serious security considerations that must be taken into
|
|
account when exporting / and /usr on the template machine.
|
|
|
|
* only export read-only
|
|
|
|
* the password file ( aka vipw ) may not contain any crypted passwords
|
|
at all. You MUST use ssh or kerberos to access the template machine.
|
|
|
|
You can get away with giving only root a crypted password, but only
|
|
if you disallow network root logins and only allow direct root
|
|
logins on the console.
|
|
|
|
* The machine's private ssh_host_key usually resides in /usr/local/etc.
|
|
You must move this key to /var/db. You can softlink link so no
|
|
modification of sshd_config is required.
|
|
|
|
* The machine's private ~root/.ssh/identity file is also exposed by
|
|
the NFS export, you should move this file to /var/db as well and
|
|
put a softlink in ~root/.ssh.
|
|
|
|
* DON'T EXPORT /var ! Either that, or don't put the private keys
|
|
in /var/db ... put them somewhere else.
|
|
|
|
* You may want to redirect the location of the random_seed file, which
|
|
can be done by editing ~root/.ssh/sshd_config and
|
|
/usr/local/etc/sshd_config so it is not exposed either.
|
|
|
|
-Matt
|
|
Matthew Dillon
|
|
dillon@backplane.com
|
|
|