diff options
Diffstat (limited to 'share/examples/diskless/README.TEMPLATING')
| -rw-r--r-- | share/examples/diskless/README.TEMPLATING | 286 |
1 files changed, 0 insertions, 286 deletions
diff --git a/share/examples/diskless/README.TEMPLATING b/share/examples/diskless/README.TEMPLATING deleted file mode 100644 index babf670c1eee..000000000000 --- a/share/examples/diskless/README.TEMPLATING +++ /dev/null @@ -1,286 +0,0 @@ - - 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 propogate - 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 boundries. - 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 descending 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 maintaing 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 - |