FreeBSD Operating System

Updating the system software

Разбить на страницы
Показывать лекцию целиком

In the previous chapter, we looked at how to get an up-to-date FreeBSD source tree. Once you have the sources, you can build various components of the system. The main tool we use for this purpose is make, which we looked at on page 168. The best way to think of upgrading the system is that everything is a matter of changing files. For the purposes of this discussion, you can divide the files on your system into the following categories:

  • The userland, that part of the system software that is not the kernel. Unlike some other operating systems, FreeBSD expects to keep userland and kernel at the same release level. We'll look at the interaction between kernel and userland below.
  • The kernel. You may build a new kernel without updating the sources, of course, if you want to add functionality to the kernel. In this chapter we'll look at upgrading the kernel in the context of a complete system upgrade. We'll consider building a custom kernel in the next chapter, Chapter 33, Custom kernels.
  • Support for booting the machine, which is currently performed as a separate step.
  • Configuration files relating to your system. Some of them, such as etc/fstab and etc/rc.conf, overlap with the previous category.
  • The Ports Collection. This doesn't have to be done at the same time as userland and kernel, though if you upgrade to a significant new version of FreeBSD, it's a good idea to upgrade the ports as well. We looked at upgrading ports on page 178.
  • Your own files. They have nothing to do with a software upgrade.
  • You can make upgrading less onerous by planning in advance. Here are some suggestions:

  • Keep system files and user files on different file systems.
  • Keep careful records of which configuration files you change, for example with RCS, the Revision Control System. This proves to be the most complicated part of the entire upgrade process.
  • The only files that are upgraded are on the traditional root file system and /usr. No others are affected by an upgrade. Table 32-1 , an abridged version of Table 10-2 on page 188, gives an overview of where the system files come from.

    FreeBSD directory hierarchy
    Directory nameUsagePopulated by
    /binExecutable programs of general use.make world
    /bootFiles used when booting the system.make install in /usr/src/sys.
    /devDirectory of device nodes.System startup (devfs)
    /etcConfiguration files used at system startupInstall from CD-ROM only, merge master, administrator
    /sbinSystem executables needed at system startup time.make world
    /usr/XllR6X-based programs in theThe X11 windowing system. Ports Collection
    /usr/binStandard executable programs that are not needed at system start.make world
    /usr/compatA directory containing code for emulated systems, such as Linux.Ports Collection
    /usr/gamesGames.make world
    /usr/includeHeader files for programmers.make world
    /usr/libLibrary files.make world
    /usr/libexecExecutable files that are not started directly by the user.make world
    /usr/libdataMiscellaneous files used by system utilities.make world
    /usr/localAdditional programs that are not part of the operating system.Ports collection
    /usr/objTemporary object files created when building the system.make world
    /usr/portsThe Ports Collectionsysinstall, cvs
    /usr/sbinSystem administration programs that are not needed at system startup.make world
    /usr/shareMiscellaneous read-only files, mainly informative.make world
    /usr/srcSystem source files.sysinstall, cvs

    Upgrading kernel and userland

    The core part of a system upgrade consists of a synchronized update of both kernel and userland. It's relatively simple to do, but depending on the speed of the machine, it may keep the computer busy for several hours. In general, you build and install the userland first, then you build and install the kernel.

    The traditional way to build the userland is:

    # cd /usr/src
    # make world
    

    This operation performs a number of functions, which can be influenced by variables you pass to make. Without any variables, make world performs the following steps:

  • It removes the old build directories and creates new ones. You can skip this step by setting the NOCLEAN variable. Don't set NOCLEAN unless you know exactly why you are doing so, since it can cause inconsistencies that come back to bite you later. In particular, if you do have problcodes after building the world in this manner, you should first go back and perform a complete rebuild without NOCLEAN.
  • It rebuilds and installs build tools, including make, the C compiler and the libraries.
  • It builds the rest of the system, with the exception of the kernel and the boot tools.
  • It installs everything. You can omit this stage by building the buildworld target instead of world.
  • It does this by building a number of subtargets. Occasionally, you might find it useful to build them individually: make world can pose a chicken-and-egg problem. It creates the userland, and make kernel makes the kernel. Userland and kernel belong together, and if you upgrade the userland first, you may find that the new userland takes advantage of differences in the newer version of the kernel. A typical situation is when a new system call is added to the kernel. In this case, you may find processes exiting with a signal 12 (invalid system call). If this happens, you may have to perform the upgrade with the sequence:

    make buildworld
    make kernel
    (reboot)
    make installworld
    

    You'll find information about such requirements in the file /usr/src/UPDATING. Table 32-2 gives an overview of the more useful targets to the top-level Makefile.

    Targets for top-level Makefile
    TargetPurpose
    buildworldRebuild everything, including glue to help do upgrades.
    installworldInstall everything built by buildworld.
    worldPerform buildworld and installworld.
    updateUpdate your source tree.
    mostBuild user commands, no libraries or include files.
    installmostInstall user commands, but not libraries or include files.
    reinstallIf you have a build server, you can NFS mount the source and object directories and do a make reinstall on the client to install new binaries from the most recent build on the server.
    buildkernelBuild a kernel for your architecture. By default, use the GENERIC kernel configuration file. You can select a different configuration file, say MYKERNEL, with:
    # make buildkernel KERNCONF=MYKERNEL
    

    By default, this target builds all the KLDs (Kernel Loadable Modules), which significantly increases the time it takes. If you know that your KLDs will not change, or that you won't be using any, you can skip building them by specifying the -DNO_MODULES flag.

    installkernelInstall a kernel you have built with buildkernel.
    reinstallkernelInstall a kernel you have built with buildkernel. Don’t rename the previous kernel directory to kernel.old. Use this target when the previous kernel is not worth keeping.
    kernelBuild and install a kernel.

    Another issue is that the system configuration might have changed. For example, in early 2002 the default configuration for sendmail changed. The process added a daemon user and group, both called smmsp. To install the userland, this user already needed to be present.

    The solution to this issue is called mergemaster, a script that helps you to upgrade the configuration files. We'll look at it in more detail below, but at this point you should know that you need to run it with the -p (pre-build) option:

    # mergemaster -p
    

    As we've seen in table 32-1 , the installworld target changes a number of directories. Sometimes, though, it leaves old binaries behind: it doesn't remove anything that it doesn't replace. The result can be that you end up using old programs that have long passed their use-by date. One solution to this problem is to look at the last modification date of each program in the directories.

    For example, if you see:

    $ ls -lrt /usr/sbin
    -r-xr-xr-x  1  root  wheel     397  Jul  14  11:36  svr4
    -r-xr-xr-x  1  root  wheel     422  Jul  14  11:29  linux
    -r-xr-xr-x  1  root  wheel  142080  Jul  13  17:20  sshd
    …
    -r-xr-xr-x  1  root  wheel   68148  Jul  13  17:16  uuchk
    -r-xr-xr-x  1  root  wheel    6840  Jan   5   2002  ispppcontrol
    -r-xr-xr-x  1  root  wheel   27996  Apr  21   2001  k5stash
    -r-xr-xr-x  1  root  wheel   45356  Apr  21   2001  ktutil
    -r-xr-xr-x  1  root  wheel   11124  Apr  21   2001  kdb_util
    -r-xr-xr-x  1  root  wheel   6768   Apr  21   2001  kdb init
    

    It's fairly clear that the files dated April 2001 have not just been installed, so they must be out of date. You can use a number of techniques to delete them; one might be:

    # find . -mtime +10 | xargs rm
    

    This command removes all files in the current directory (.) that are older than 10 days (+10). Of course, this method will only work if you haven't installed anything in these directories yourself. You shouldn't have done so; that's the purpose of the directory hierarchy /usr/local, to ensure that you keep system files apart from ports and private files.

    Be careful with /usr/lib: a number of ports refer to libraries in this directory hierarchy, and if you delete them, the ports will no longer work. In general there's no problem with old libraries in /usr/lib, unless they take up too much space, so you're safer if you don't clean out this directory hierarchy.

    Note that you need to specify the KERNCONF parameter to all the targets relating to kernel builds.

    Upgrading the kernel

    There are two reasons for building a new kernel: it might be part of the upgrade process, which is what we'll look at here, or you may build a kernel from your current sources to add functionality to the system. We'll look at this aspect in Chapter 33.

    One point to notice is that if you're upgrading from an older custom configuration file, you could have a lot of trouble. We'll see a strategy for minimizing the pain on page 617. In addition, when upgrading to FreeBSD Release 5 from an older release of FreeBSD, you need to install a file /boot/device.hints, which you can typically copy from /usr/src/sys/i386/conf/GENERIC.hints:

    # cp /usr/src/sys/i386/conf/GENERIC.hints /boot/device.hints
    

    See page 609 for more details.

    When upgrading the kernel, you might get error messages like this one:

    # config GENERIC
    config: GENERIC:71: devices with zero units are not likely to be correct
    

    Alternatively, you might get a clearer message:

    # config GENERIC
    ../../conf/files: coda/coda_fbsd.c must be optional, mandatory or standard
    Your version of config(8) is out of sync with your kernel source.
    

    Apart from that, you might find that the kernel fails to link with lots of undefined references. This, too, could mean that the config program is out of synchronization with the kernel modules. In each case, build and install the new version of config:

    # cd /usr/src/usr.sbin/config
    # make depend all install clean
    

    You need to make clean at the end since this method will store the object files in non-standard locations.

    Upgrading the boot files

    At the time of writing, it's still necessary to install the files in /boot separately. It's possible that this requirement will go away in the future. There are two steps: first you build and install the boot files in the /boot directory, then you install them on your boot disk. Assuming your system disk is the SCSI disk /dev/da0, you would perform some of the following steps.

    # cd /usr/src/sys    build directory
    # make install       build and install the bootstraps
    # bsdlabel -B da0    Either,for a dedicated disk
    # bsdlabel -B da0s1  Or,for a PC disk slice
    # boot0cfg -B da0    Or,booteasy for a dedicated PC disk
    

    If you have a dedicated disk, which is normal on a non-Intel platform, use the first bsdlabel invocation to install the bootstrap (boot1) at the beginning of the disk. Otherwise, install boot1 at the beginning of your FreeBSD slice and use boot0cfg to install the boot0 boot manager at the beginning of the disk.

    Upgrading the configuration files

    Currently, the system build procedure does not install the configuration files in /etc. You need to do that separately. There are two possible methods:

  • Do it manually:
  • Backup the old configuration files. They're not very big, so you can probably make a copy on disk somewhere.
  • Install pristine new configuration files:
    # cd /usr/src/etc/
    # make install
    
  • Compare the files and update the new ones with information from your configuration.
  • Use mergemaster, a semi-automatic method of doing effectively the same thing.
  • The simple method is: run mergemaster with the options -i and -a, which tell it to run automatically (in other words, not to stop and ask questions), and to install new files automatically. That doesn't mean intelligently: you may run into problems anyway.

    mergemaster produces a lot of output, and some of it in the middle is important, so you should save the output to disk with the tee command. The first time you try, you might see:

    # mergemaster -ia 2>1 | tee -a /var/tmp/merge
    
    *** Creating the temporary root environment in /var/tmp/temproot
     *** /var/tmp/temproot ready for use
     *** Creating and populating directory structure in /var/tmp/temproot
    
    set - `grep "^[a-zA-Z]" /usr/src/etc/locale.deprecated`;   while [ $# -gt 0 ]  ;
    do for dir in /usr/share/locale   /usr/share/nls   /usr/local/share/nls;
    do test -d /va r/tmp/temproot/${dir}  cd /var/tmp/tenproot/${dir};
    test -L "$2"  rm -rf "$2";
    test -L "$1"  test -d "$1"  mv "$1" "$2"; done; shift; shift;
    done mtree -deU -f /usr/src/etc/mtree/BSD.root.dist -p /var/tmp/temproot/
     ./bin missing (created)
     ./boot missing (created)
    ...
    ./vm missing (created)
    mtree -deU -f /usr/src/etc/mtree/BSD.sendmail.dist -p /var/tmp/temproot/
    mtree: line 10: unknown user smmsp
    *** Error code 1
    
    Stop in /usr/src/etc.
    
    *** FATAL ERROR: Cannot 'cd' to /usr/src/etc and install files 
        to the temproot environment
    

    These messages are somewhat misleading. First, the files that are created are all in /var/tmp/temproot. In addition, the message Cannot 'cd' to /usr/src/etc does not refer to any problem with that directory; it's just an indication that it can't continue with the installation due to the previous errors.

    The real issue here is that the user smmsp doesn't exist. As we saw above, this user was added some time in 2002 to address some mail security problems. It's in the new /etc/master.passwd file, but it's not in the one on the system. But how do you merge the two files? One way would to be to use mergemaster with the -p option, but then mergemaster prompts you for every single file that it finds to be different, usually about 300 of them. In addition, the editing facilities are relatively basic. It's better to edit the file in advance with an editor.

    Merging the password file

    As we saw on page 145, the password file is quite complicated. Depending on how much work you want to do, you have a couple of possibilities:

  • You can choose to completely replace the old /etc/master.passwd with the new one. This will cause all added user names and passwords to disappear, so unless this is just a test machine, it's unlikely you'll want to follow this path.
  • You can take advantage of the fact that, with the exception of root, the distribution /etc/master.passwd contains no "real" users. You can merge the entries for real users with the entries in the distribution /etc/master.passwd.This works relatively well, but it removes the passwords of the system users, so you have to set them again. We'll look at how to do that below.
  • The distribution version of /etc/master.passwd looks something like this:

    #$FreeBSD: src/etc/master.passwd,v 1.33 2002/06/23 20:46:44 des Exp $
    #
    root::0:0::0:0:Charlie :/root:/bin/csh
    toor:*:0:0::0:0:Bourne-again Superuser:/root:
    ...etc
    

    The individual fields are separated by colons (:). We'll look at only the fields that interest us in the following expansion. It's easier to look at if they're separated by spaces; numerically, they're the first, second, eighth, ninth and tenth fields. For a description of the other fields, see the man page master.passwd(4).

    User      password  GECOS               home directory           shell
    root       *   Charlie                 /root                    /bin/csh
    toor       *   Bourne-again Superuser   /root   
    daemon     *   Owner of many processes  /root                    /sbin/nologin
    operator   *   System                  /                        /sbin/nologin
    bin        *   Binaries Commands        /                        /sbin/nologin
    tty        *   Tty Sandbox              /                        /sbin/nologin
    kmem       *   KMem Sandbox             /                        /sbin/nologin
    games      *   Games pseudo-user        /usr/games               /sbin/nologin
    news       *   News Subsystem           /                        /sbin/nologin
    man        *   Mister Man Pages         /usr/share/man           /sbin/nologin
    sshd       *   Secure Shell Daemon      /var/empty               /sbin/nologin
    smmsp      *   Sendmail Submission      /var/spool/clientmqueue  /sbin/nologin
    mailnull   *   Sendmail Default User    /var/spool/mqueue        /sbin/nologin
    bind       *   Bind Sandbox             /                        /sbin/nologin
    xten       *   X-10 daemon              /usr/local/xten          /sbin/nologin
    pop        *   Post Office Owner        /nonexistent             /sbin/nologin
    www        *   World Wide Web Owner     /nonexistent             /sbin/nologin
    nobody     *   Unprivileged user        /nonexistent             /sbin/nologin
    

    The first field is the name of the user. In the course of time, a number of pseudo-users have been added to reduce exposure to security issues. The main issue in merging the files is to add these users. If you don't have the user in your current /etc/master.passwd, you can add the line from the distribution file.

    The second field contains the password. In the distribution file, it's usually *, which means it needs to be set before you can log in at all. Only root has no password; you need to be able to log in as root to set passwords. By contrast, in your installed /etc/master.passwd, you will almost certainly have a password, and in general you will want to keep it.

    The home directory entry has not changed much. You'll notice directory names like /nonexistent and /var/empty. The former is a fake, the latter a directory that can't be changed. It's possible that this entry will change from one release to another, and it's important to get it correct.

    For many accounts, the shell field contains the name /sbin/nologin, which prints the text "This account is currently not available" and exits. Currently only root has a real shell, but that could change.

    To update the /etc/master.passwd, you can use the following method:

  • Make a copy of your old /etc/master.passwd!
  • Maintain a strict separation of the original lines from the distribution file and your own entries. This will help you with the next update.
  • Copy the entire distribution /etc/master.passwd to the top of your /etc/master.passwd file. At this point you will have a number of duplicates.
  • Check the entries for root. You can probably remove the distribution entry and leave your entry in the file, preserving the password and shell. In this case, you should make an exception to the separation between distribution and local additions: due to the way the name lookups work, if you put user root below user toor ("root" spelt backwards, and the same user with possibly a different shell), all files will appear to belong to toor instead of to root.
  • Check what other entries you have for user ids under 1000. You can probably remove them all, but if you have installed ports that require their own user ID, you will need to keep them.
  • You should be able to keep all the entries for users with IDs above and including 1000, with the exception of user nobody (ID 65534). Use the entry from the distribution file for nobody.
  • Once you have merged the files, you need to run pwdmkdb to rebuild the password files /etc/passwd, /etc/pwd.db and /etc/spwd.db. /etc/passwd is gradually going out of use, but you probably have one on your system, and some ports use it, so it's preferable to recreate it. Do this with the -p option to pwd_mkdb:

    # pwd_mkdb -p /etc/master.passwd
    

    Merging /etc/group

    In addition to /etc/master.passwd, you will probably need to upgrade /etc/group. In this case, the main issue is to add users to the wheel group. The distribution /etc/group looks like this:

    #$FreeBSD: src/etc/group,v 1.27 2002/10/14 20:55:49 rwatson Exp $ #
    wheel:*:0:root daemon:*:1: kmem:*:2: sys:*:3:
    tty:*:4:
    operator:*:5:root
    mail:*:6:
    bin:*:7:
    news:*:8:
    man:*:9:
    games:*:13:
    staff:*:20: sshd:*:22:
    smmsp:*:25:
    mailnull:*:26:
    guest:*:31:
    bind:*:53:
    uucp:*:66:
    xten:*:67:
    dialer:*:68:
    network:*:69:
    www:*:80:
    nogroup:*:65533:
    nobody:*:65534:
    

    Again, new groups have appeared for security reasons. Use a similar method to the one you used for /etc/master.passwd:

  • Make a copy of your old /etc/group!
  • Maintain a strict separation of the original lines from the distribution file and your own entries. This will help you with the next update.
  • Copy the entire distribution /etc/group to the top of your /etc/group file. At this point you will have a number of duplicates.
  • Check the entries for wheel .You can probably remove the distribution entry and leave your entry in the file, preserving the users.
  • In addition, you may have some users in other groups. For example, installing postfix adds the user postfix to group mail. You need to preserve these users.
  • You don't need to do anything special after updating /etc/group. You can now continue with mergemaster.

    Mergemaster, second time around

    Before running mergemaster again, you should delete the contents of /var/tmp/temproot. Otherwise you might see something like:

    *** The directory specified for the temporary root environment,
        /var/tmp/temproot, exists. This can be a security risk if untrusted
        users have access to the system.
    

    mergemaster does not delete the old directories: you should do so yourself. If this file already exists, mergemaster ignores it and creates a new directory with a name like /var/tmp/temproot.0917.02.18.06. The numbers are a representation of the date and time of creation.

    mergemaster doesn't make it easy to remove the /var/tmp/temproot directory. You may see:

    # rm -rf /var/tmp/temproot
    rm: /var/tmp/temproot/var/empty: Operation not permitted
    rm: /var/tmp/temproot/var: Directory not empty
    rm: /var/tmp/temproot: Directory not empty
    

    The problem here is that the directory /var/empty has been set immutable. Change that with the chflags command and try again:

    # find /var/tmp/temproot|xargs chflags noschg
    # rm -rf /var/tmp/temproot
    

    Run mergemaster in the same way as before, saving the output. If you haven't deleted the old /var/tmp/temproot directory, you might see:

    mergemaster -ia 2>1 | tee -a /var/tmp/merge
    *** Creating the temporary root environment in /var/tmp/temproot.1102.15.01.14
     *** /var/tmp/temproot.1102.15.01.14 ready for use
     *** Creating and populating directory structure in /var/tmp/temproot.1102.15.01.14
    
    set - `grep "^[a-zA-Z]" /usr/src/etc/locale.deprecated`; while [ $# -gt 0 ] ;
    do for dir in /usr/share/locale /usr/share/nls /usr/local/share/nls;
    do   test -d /var/tmp/temproot.1102.15.01.14/${dir}  cd /var/tmp/temproot.1102.15.01.14/${dir};
    test -L "$2"  rm -rf "$2";
    test -L  test -d  mv "$2";
    done; shift; shift; done
    mtree -deU -f /usr/src/etc/mtree/BSD.root.dist -p /var/tmp/temproot.1102.15.01.14/ 
    ./bin missing (created)
    ./boot missing (created)
    ./boot/defaults missing (created)
    ./boot/kernel missing (created)
    ./boot/modules missing (created)
    ./
    ...
    install -o root -g wheel -m 644 /dev/null /var/tinp/temproot.1102.15.01.14/var/run/utmp
    install -o root -g wheel -m 644 /usr/src/etc/minfree /var/tmp/temproot.1102.15.01.14/var/crash
    cd /usr/src/etc/..;
    install -o root -g wheel -m 444 COPYRIGHT /var/tmp/temproot.110 2.15.01.14/
    cd /usr/src/etc/../share/man; make makedb
    makewhatis /var/tmp/temproot.1102.15.01.14/usr/share/man
    *** Beginning comparison
    
    *** Temp ./etc/defaults/rc.conf and installed have the same CVS Id, deleting
    *** Temp ./etc/defaults/pccard.conf and installed have the same CVS Id, deleting
       *** ./etc/defaults/periodic.conf will remain for your consideration 
    *** Temp ./etc/gnats/freefall and installed have the same CVS Id, deleting
    *** Temp ./etc/isdn/answer and installed have the same CVS Id, deleting
    *** Temp ./etc/isdn/isdntel.sh and installed have the same CVS Id, deleting
    ...
    
    *** Comparison complete
    
    *** Files that remain for you to merge by hand:
    /var/tmp/temproot.1102.15.01.14/etc/defaults/periodic.conf
    /var/tmp/temproot.1102.15.01.14/etc/mail/freebsd.mc
    /var/tmp/temproot.1102.15.01.14/etc/mail/freebsd.cf
    /var/tmp/temproot.1102.15.01.14/etc/mail/sendmail.cf
    /var/tmp/temproot.1102.15.01.14/etc/mail/freebsd.submit.cf
    /var/tmp/temproot.1102.15.01.14/etc/mail/mailer.conf
    /var/tmp/temproot.1102.15.01.14/etc/mtree/BSD.include.dist
    /var/tmp/temproot.1102.15.01.14/etc/mtree/BSD.local.dist
    /var/tmp/temproot.1102.15.01.14/etc/mtree/BSD.usr.dist
    /var/tmp/temproot.1102.15.01.14/etc/mtree/BSD.var.dist
    /var/tmp/temproot.1102.15.01.14/etc/pam.d/su
    /var/tmp/temproot.1102.15.01.14/etc/periodic/security/100.chksetuid
    /var/tmp/temproot.1102.15.01.14/etc/periodic/security/200.chkmounts
    /var/tmp/temproot.1102.15.01.14/etc/periodic/security/500.ipfwdenied
    /var/tmp/temproot.1102.15.01.14/etc/periodic/security/600.ip6fwdenied
    /var/tmp/temproot.1102.15.01.14/etc/periodic/security/700.kernelmsg
    /var/tmp/temproot.1102.15.01.14/etc/rc.d/local
    /var/tmp/temproot.1102.15.01.14/etc/crontab
    /var/tmp/temproot.1102.15.01.14/etc/inetd.conf
    /var/tmp/temproot.1102.15.01.14/etc/motd
    /var/tmp/temproot.1102.15.01.14/etc/syslog.conf
    
    *** You chose the automatic install option for files that did not
        exist on your system. The following were installed for you:
          /etc/periodic/security/510.ipfdenied
          /etc/periodic/security/security.functions
          /etc/mac.conf
    

    You're not done yet: there are 21 files above that need looking at. There's a good chance that you've never heard of some of them, let alone changed them. If you know for a fact that you have never changed them, for example if you have religiously kept track of your changes with RCS, you don't need to bother: mergemaster errs on the side of safety. You may have changed others, though. The most obvious one above is /etc/crontab, which contains system-wide commands to be executed by cron.To compare them, use diff:

    $ diff -wu /etc/crontab /var/tmp/temproot.1102.15.01.14/etc/crontab
    --- /var/tmp/crontab Sat Nov 2 16:27:02 2002
    +++ /var/tmp/temproot.1102.15.01.14/etc/crontab Sat Nov 2 15:01:16 2002
    @@ -1,6 +1,6 @@
     # /etc/crontab - root’s crontab for FreeBSD
     #
    -# $FreeBSD: src/etc/crontab,v 1.21 1999/12/15 17:58:29 obrien Exp $
    +# $FreeBSD: src/etc/crontab,v 1.31 2001/02/19 02:47:41 peter Exp $
     #
     SHELL=/bin/sh
     PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin
    @@ -10,19 +10,18 @@
     #
     */5   *   *   *   *   root       /usr/libexec/atrun
     #
    +# save some entropy so that /dev/random can reseed on boot
    +*/11  *   *   *   *   operator   /usr/libexec/save-entropy
    +#
     # rotate log files every hour, if necessary
     0     *   *   *   *   root       newsyslog
     #
     # do daily/weekly/monthly maintenance
    -59    1   *   *   *   root       periodic daily
    -30    3   *   *   6   root       periodic weekly
    +1     3   *   *   *   root       periodic daily
    +15    4   *   *   6   root       periodic weekly
     30    5   1   *   *   root       periodic monthly
     #
     # time zone change adjustment for wall cmos clock,
    -# does nothing if you have UTC cmos clock.
    +# does nothing, if you have UTC cmos clock.
     # See adjkerntz(8) for details.
    -#1,31 0-5 *   *   *   root       adjkerntz -a
    +1,31  0-5 *   *   *   root       adjkerntz -a
    -0,30  *   *   *   *   build      /home/build/build_farm/build_test 2>
    /home/build/cron.err
    -0     21  *   *   *   root       /usr/local/bin/cleanup
    -0      7  *   *   *   grog       /home/grog/bin/update-FreeBSD-cvs
    -1     *   *   *   *   root       (cd /usr/local/etc/postfix; make) 2
    >/dev/null >/dev/null
    

    The lines starting with - show lines only in the old file, which is still in /etc/crontab. The lines starting with + show lines only in the new file, which is in /var/tmp/temp-root.1102.15.01.14/etc/crontab. There are a number of changes here: the CVS ID ($FreeBSD$) has changed from 1.21 to 1.31, and the times of the periodic maintenance have changed. In the meantime, though, you have added other tasks (the bottom four lines), and you have also commented out the periodic invocation of adjkerntz.These are the changes you need to make to the new /etc/crontab before you install it.

    There's a simpler possibility here, though: the only real change that would then be left in /etc/crontab is the change in the starting times for the daily and weekly housekeeping. Does that matter? If you want, you don't need to change anything: the old/etc/crontab is fine the way it is.

    There's a whole list of files that you're likely to change from the defaults. Here are some more likely candidates:

  • You may find it necessary to change /etc/syslog.conf. If so, you may have to merge by hand, but it shouldn't be too difficult.
  • You will almost certainly change /etc/ftab. About the only reason why you might need to merge changes would be if the file format changes, which it hasn't done for over 20 years.
  • /etc/motd contains the login greeting. There's never a reason to take the new version.
  • /etc/inetd.conf can be a problem: as new services are introduced, it changes. At the same time, you may have added services via ports, or enabled services in the manner we will see on page 448. You definitely need to merge this one yourself.
  • If you're using postfix, don't install the distribution version of /etc/mail/mailer.conf. It will reenable sendmail, which can cause significant problems.
  • If you have changed anything in /etc/sysctl.conf, you'll need to move the changes to the new file.
  • Страницы:

    In the previous chapter, we looked at how to get an up-to-date FreeBSD source tree. Once you have the sources, you can build various components of the system. The main tool we use for this purpose is make, which we looked at on page 168. The best way to think of upgrading the system is that everything is a matter of changing files. For the purposes of this discussion, you can divide the files on your system into the following categories:

  • The userland, that part of the system software that is not the kernel. Unlike some other operating systems, FreeBSD expects to keep userland and kernel at the same release level. We'll look at the interaction between kernel and userland below.
  • The kernel. You may build a new kernel without updating the sources, of course, if you want to add functionality to the kernel. In this chapter we'll look at upgrading the kernel in the context of a complete system upgrade. We'll consider building a custom kernel in the next chapter, Chapter 33, Custom kernels.
  • Support for booting the machine, which is currently performed as a separate step.
  • Configuration files relating to your system. Some of them, such as etc/fstab and etc/rc.conf, overlap with the previous category.
  • The Ports Collection. This doesn't have to be done at the same time as userland and kernel, though if you upgrade to a significant new version of FreeBSD, it's a good idea to upgrade the ports as well. We looked at upgrading ports on page 178.
  • Your own files. They have nothing to do with a software upgrade.
  • You can make upgrading less onerous by planning in advance. Here are some suggestions:

  • Keep system files and user files on different file systems.
  • Keep careful records of which configuration files you change, for example with RCS, the Revision Control System. This proves to be the most complicated part of the entire upgrade process.
  • The only files that are upgraded are on the traditional root file system and /usr. No others are affected by an upgrade. Table 32-1 , an abridged version of Table 10-2 on page 188, gives an overview of where the system files come from.

    FreeBSD directory hierarchy
    Directory nameUsagePopulated by
    /binExecutable programs of general use.make world
    /bootFiles used when booting the system.make install in /usr/src/sys.
    /devDirectory of device nodes.System startup (devfs)
    /etcConfiguration files used at system startupInstall from CD-ROM only, merge master, administrator
    /sbinSystem executables needed at system startup time.make world
    /usr/XllR6X-based programs in theThe X11 windowing system. Ports Collection
    /usr/binStandard executable programs that are not needed at system start.make world
    /usr/compatA directory containing code for emulated systems, such as Linux.Ports Collection
    /usr/gamesGames.make world
    /usr/includeHeader files for programmers.make world
    /usr/libLibrary files.make world
    /usr/libexecExecutable files that are not started directly by the user.make world
    /usr/libdataMiscellaneous files used by system utilities.make world
    /usr/localAdditional programs that are not part of the operating system.Ports collection
    /usr/objTemporary object files created when building the system.make world
    /usr/portsThe Ports Collectionsysinstall, cvs
    /usr/sbinSystem administration programs that are not needed at system startup.make world
    /usr/shareMiscellaneous read-only files, mainly informative.make world
    /usr/srcSystem source files.sysinstall, cvs

    Upgrading kernel and userland

    The core part of a system upgrade consists of a synchronized update of both kernel and userland. It's relatively simple to do, but depending on the speed of the machine, it may keep the computer busy for several hours. In general, you build and install the userland first, then you build and install the kernel.

    The traditional way to build the userland is:

    # cd /usr/src
    # make world
    

    This operation performs a number of functions, which can be influenced by variables you pass to make. Without any variables, make world performs the following steps:

  • It removes the old build directories and creates new ones. You can skip this step by setting the NOCLEAN variable. Don't set NOCLEAN unless you know exactly why you are doing so, since it can cause inconsistencies that come back to bite you later. In particular, if you do have problcodes after building the world in this manner, you should first go back and perform a complete rebuild without NOCLEAN.
  • It rebuilds and installs build tools, including make, the C compiler and the libraries.
  • It builds the rest of the system, with the exception of the kernel and the boot tools.
  • It installs everything. You can omit this stage by building the buildworld target instead of world.
  • It does this by building a number of subtargets. Occasionally, you might find it useful to build them individually: make world can pose a chicken-and-egg problem. It creates the userland, and make kernel makes the kernel. Userland and kernel belong together, and if you upgrade the userland first, you may find that the new userland takes advantage of differences in the newer version of the kernel. A typical situation is when a new system call is added to the kernel. In this case, you may find processes exiting with a signal 12 (invalid system call). If this happens, you may have to perform the upgrade with the sequence:

    make buildworld
    make kernel
    (reboot)
    make installworld
    

    You'll find information about such requirements in the file /usr/src/UPDATING. Table 32-2 gives an overview of the more useful targets to the top-level Makefile.

    Targets for top-level Makefile
    TargetPurpose
    buildworldRebuild everything, including glue to help do upgrades.
    installworldInstall everything built by buildworld.
    worldPerform buildworld and installworld.
    updateUpdate your source tree.
    mostBuild user commands, no libraries or include files.
    installmostInstall user commands, but not libraries or include files.
    reinstallIf you have a build server, you can NFS mount the source and object directories and do a make reinstall on the client to install new binaries from the most recent build on the server.
    buildkernelBuild a kernel for your architecture. By default, use the GENERIC kernel configuration file. You can select a different configuration file, say MYKERNEL, with:
    # make buildkernel KERNCONF=MYKERNEL
    

    By default, this target builds all the KLDs (Kernel Loadable Modules), which significantly increases the time it takes. If you know that your KLDs will not change, or that you won't be using any, you can skip building them by specifying the -DNO_MODULES flag.

    installkernelInstall a kernel you have built with buildkernel.
    reinstallkernelInstall a kernel you have built with buildkernel. Don’t rename the previous kernel directory to kernel.old. Use this target when the previous kernel is not worth keeping.
    kernelBuild and install a kernel.

    Another issue is that the system configuration might have changed. For example, in early 2002 the default configuration for sendmail changed. The process added a daemon user and group, both called smmsp. To install the userland, this user already needed to be present.

    The solution to this issue is called mergemaster, a script that helps you to upgrade the configuration files. We'll look at it in more detail below, but at this point you should know that you need to run it with the -p (pre-build) option:

    # mergemaster -p
    

    As we've seen in table 32-1 , the installworld target changes a number of directories. Sometimes, though, it leaves old binaries behind: it doesn't remove anything that it doesn't replace. The result can be that you end up using old programs that have long passed their use-by date. One solution to this problem is to look at the last modification date of each program in the directories.

    For example, if you see:

    $ ls -lrt /usr/sbin
    -r-xr-xr-x  1  root  wheel     397  Jul  14  11:36  svr4
    -r-xr-xr-x  1  root  wheel     422  Jul  14  11:29  linux
    -r-xr-xr-x  1  root  wheel  142080  Jul  13  17:20  sshd
    …
    -r-xr-xr-x  1  root  wheel   68148  Jul  13  17:16  uuchk
    -r-xr-xr-x  1  root  wheel    6840  Jan   5   2002  ispppcontrol
    -r-xr-xr-x  1  root  wheel   27996  Apr  21   2001  k5stash
    -r-xr-xr-x  1  root  wheel   45356  Apr  21   2001  ktutil
    -r-xr-xr-x  1  root  wheel   11124  Apr  21   2001  kdb_util
    -r-xr-xr-x  1  root  wheel   6768   Apr  21   2001  kdb init
    

    It's fairly clear that the files dated April 2001 have not just been installed, so they must be out of date. You can use a number of techniques to delete them; one might be:

    # find . -mtime +10 | xargs rm
    

    This command removes all files in the current directory (.) that are older than 10 days (+10). Of course, this method will only work if you haven't installed anything in these directories yourself. You shouldn't have done so; that's the purpose of the directory hierarchy /usr/local, to ensure that you keep system files apart from ports and private files.

    Be careful with /usr/lib: a number of ports refer to libraries in this directory hierarchy, and if you delete them, the ports will no longer work. In general there's no problem with old libraries in /usr/lib, unless they take up too much space, so you're safer if you don't clean out this directory hierarchy.

    Note that you need to specify the KERNCONF parameter to all the targets relating to kernel builds.

    Upgrading the kernel

    There are two reasons for building a new kernel: it might be part of the upgrade process, which is what we'll look at here, or you may build a kernel from your current sources to add functionality to the system. We'll look at this aspect in Chapter 33.

    One point to notice is that if you're upgrading from an older custom configuration file, you could have a lot of trouble. We'll see a strategy for minimizing the pain on page 617. In addition, when upgrading to FreeBSD Release 5 from an older release of FreeBSD, you need to install a file /boot/device.hints, which you can typically copy from /usr/src/sys/i386/conf/GENERIC.hints:

    # cp /usr/src/sys/i386/conf/GENERIC.hints /boot/device.hints
    

    See page 609 for more details.

    When upgrading the kernel, you might get error messages like this one:

    # config GENERIC
    config: GENERIC:71: devices with zero units are not likely to be correct
    

    Alternatively, you might get a clearer message:

    # config GENERIC
    ../../conf/files: coda/coda_fbsd.c must be optional, mandatory or standard
    Your version of config(8) is out of sync with your kernel source.
    

    Apart from that, you might find that the kernel fails to link with lots of undefined references. This, too, could mean that the config program is out of synchronization with the kernel modules. In each case, build and install the new version of config:

    # cd /usr/src/usr.sbin/config
    # make depend all install clean
    

    You need to make clean at the end since this method will store the object files in non-standard locations.

    Upgrading the boot files

    At the time of writing, it's still necessary to install the files in /boot separately. It's possible that this requirement will go away in the future. There are two steps: first you build and install the boot files in the /boot directory, then you install them on your boot disk. Assuming your system disk is the SCSI disk /dev/da0, you would perform some of the following steps.

    # cd /usr/src/sys    build directory
    # make install       build and install the bootstraps
    # bsdlabel -B da0    Either,for a dedicated disk
    # bsdlabel -B da0s1  Or,for a PC disk slice
    # boot0cfg -B da0    Or,booteasy for a dedicated PC disk
    

    If you have a dedicated disk, which is normal on a non-Intel platform, use the first bsdlabel invocation to install the bootstrap (boot1) at the beginning of the disk. Otherwise, install boot1 at the beginning of your FreeBSD slice and use boot0cfg to install the boot0 boot manager at the beginning of the disk.

    Upgrading the configuration files

    Currently, the system build procedure does not install the configuration files in /etc. You need to do that separately. There are two possible methods:

  • Do it manually:
  • Backup the old configuration files. They're not very big, so you can probably make a copy on disk somewhere.
  • Install pristine new configuration files:
    # cd /usr/src/etc/
    # make install
    
  • Compare the files and update the new ones with information from your configuration.
  • Use mergemaster, a semi-automatic method of doing effectively the same thing.
  • The simple method is: run mergemaster with the options -i and -a, which tell it to run automatically (in other words, not to stop and ask questions), and to install new files automatically. That doesn't mean intelligently: you may run into problems anyway.

    mergemaster produces a lot of output, and some of it in the middle is important, so you should save the output to disk with the tee command. The first time you try, you might see:

    # mergemaster -ia 2>1 | tee -a /var/tmp/merge
    
    *** Creating the temporary root environment in /var/tmp/temproot
     *** /var/tmp/temproot ready for use
     *** Creating and populating directory structure in /var/tmp/temproot
    
    set - `grep "^[a-zA-Z]" /usr/src/etc/locale.deprecated`;   while [ $# -gt 0 ]  ;
    do for dir in /usr/share/locale   /usr/share/nls   /usr/local/share/nls;
    do test -d /va r/tmp/temproot/${dir}  cd /var/tmp/tenproot/${dir};
    test -L "$2"  rm -rf "$2";
    test -L "$1"  test -d "$1"  mv "$1" "$2"; done; shift; shift;
    done mtree -deU -f /usr/src/etc/mtree/BSD.root.dist -p /var/tmp/temproot/
     ./bin missing (created)
     ./boot missing (created)
    ...
    ./vm missing (created)
    mtree -deU -f /usr/src/etc/mtree/BSD.sendmail.dist -p /var/tmp/temproot/
    mtree: line 10: unknown user smmsp
    *** Error code 1
    
    Stop in /usr/src/etc.
    
    *** FATAL ERROR: Cannot 'cd' to /usr/src/etc and install files 
        to the temproot environment
    

    These messages are somewhat misleading. First, the files that are created are all in /var/tmp/temproot. In addition, the message Cannot 'cd' to /usr/src/etc does not refer to any problem with that directory; it's just an indication that it can't continue with the installation due to the previous errors.

    The real issue here is that the user smmsp doesn't exist. As we saw above, this user was added some time in 2002 to address some mail security problems. It's in the new /etc/master.passwd file, but it's not in the one on the system. But how do you merge the two files? One way would to be to use mergemaster with the -p option, but then mergemaster prompts you for every single file that it finds to be different, usually about 300 of them. In addition, the editing facilities are relatively basic. It's better to edit the file in advance with an editor.

    Merging the password file

    As we saw on page 145, the password file is quite complicated. Depending on how much work you want to do, you have a couple of possibilities:

  • You can choose to completely replace the old /etc/master.passwd with the new one. This will cause all added user names and passwords to disappear, so unless this is just a test machine, it's unlikely you'll want to follow this path.
  • You can take advantage of the fact that, with the exception of root, the distribution /etc/master.passwd contains no "real" users. You can merge the entries for real users with the entries in the distribution /etc/master.passwd.This works relatively well, but it removes the passwords of the system users, so you have to set them again. We'll look at how to do that below.
  • The distribution version of /etc/master.passwd looks something like this:

    #$FreeBSD: src/etc/master.passwd,v 1.33 2002/06/23 20:46:44 des Exp $
    #
    root::0:0::0:0:Charlie :/root:/bin/csh
    toor:*:0:0::0:0:Bourne-again Superuser:/root:
    ...etc
    

    The individual fields are separated by colons (:). We'll look at only the fields that interest us in the following expansion. It's easier to look at if they're separated by spaces; numerically, they're the first, second, eighth, ninth and tenth fields. For a description of the other fields, see the man page master.passwd(4).

    User      password  GECOS               home directory           shell
    root       *   Charlie                 /root                    /bin/csh
    toor       *   Bourne-again Superuser   /root   
    daemon     *   Owner of many processes  /root                    /sbin/nologin
    operator   *   System                  /                        /sbin/nologin
    bin        *   Binaries Commands        /                        /sbin/nologin
    tty        *   Tty Sandbox              /                        /sbin/nologin
    kmem       *   KMem Sandbox             /                        /sbin/nologin
    games      *   Games pseudo-user        /usr/games               /sbin/nologin
    news       *   News Subsystem           /                        /sbin/nologin
    man        *   Mister Man Pages         /usr/share/man           /sbin/nologin
    sshd       *   Secure Shell Daemon      /var/empty               /sbin/nologin
    smmsp      *   Sendmail Submission      /var/spool/clientmqueue  /sbin/nologin
    mailnull   *   Sendmail Default User    /var/spool/mqueue        /sbin/nologin
    bind       *   Bind Sandbox             /                        /sbin/nologin
    xten       *   X-10 daemon              /usr/local/xten          /sbin/nologin
    pop        *   Post Office Owner        /nonexistent             /sbin/nologin
    www        *   World Wide Web Owner     /nonexistent             /sbin/nologin
    nobody     *   Unprivileged user        /nonexistent             /sbin/nologin
    

    The first field is the name of the user. In the course of time, a number of pseudo-users have been added to reduce exposure to security issues. The main issue in merging the files is to add these users. If you don't have the user in your current /etc/master.passwd, you can add the line from the distribution file.

    The second field contains the password. In the distribution file, it's usually *, which means it needs to be set before you can log in at all. Only root has no password; you need to be able to log in as root to set passwords. By contrast, in your installed /etc/master.passwd, you will almost certainly have a password, and in general you will want to keep it.

    The home directory entry has not changed much. You'll notice directory names like /nonexistent and /var/empty. The former is a fake, the latter a directory that can't be changed. It's possible that this entry will change from one release to another, and it's important to get it correct.

    For many accounts, the shell field contains the name /sbin/nologin, which prints the text "This account is currently not available" and exits. Currently only root has a real shell, but that could change.

    To update the /etc/master.passwd, you can use the following method:

  • Make a copy of your old /etc/master.passwd!
  • Maintain a strict separation of the original lines from the distribution file and your own entries. This will help you with the next update.
  • Copy the entire distribution /etc/master.passwd to the top of your /etc/master.passwd file. At this point you will have a number of duplicates.
  • Check the entries for root. You can probably remove the distribution entry and leave your entry in the file, preserving the password and shell. In this case, you should make an exception to the separation between distribution and local additions: due to the way the name lookups work, if you put user root below user toor ("root" spelt backwards, and the same user with possibly a different shell), all files will appear to belong to toor instead of to root.
  • Check what other entries you have for user ids under 1000. You can probably remove them all, but if you have installed ports that require their own user ID, you will need to keep them.
  • You should be able to keep all the entries for users with IDs above and including 1000, with the exception of user nobody (ID 65534). Use the entry from the distribution file for nobody.
  • Once you have merged the files, you need to run pwdmkdb to rebuild the password files /etc/passwd, /etc/pwd.db and /etc/spwd.db. /etc/passwd is gradually going out of use, but you probably have one on your system, and some ports use it, so it's preferable to recreate it. Do this with the -p option to pwd_mkdb:

    # pwd_mkdb -p /etc/master.passwd
    

    Merging /etc/group

    In addition to /etc/master.passwd, you will probably need to upgrade /etc/group. In this case, the main issue is to add users to the wheel group. The distribution /etc/group looks like this:

    #$FreeBSD: src/etc/group,v 1.27 2002/10/14 20:55:49 rwatson Exp $ #
    wheel:*:0:root daemon:*:1: kmem:*:2: sys:*:3:
    tty:*:4:
    operator:*:5:root
    mail:*:6:
    bin:*:7:
    news:*:8:
    man:*:9:
    games:*:13:
    staff:*:20: sshd:*:22:
    smmsp:*:25:
    mailnull:*:26:
    guest:*:31:
    bind:*:53:
    uucp:*:66:
    xten:*:67:
    dialer:*:68:
    network:*:69:
    www:*:80:
    nogroup:*:65533:
    nobody:*:65534:
    

    Again, new groups have appeared for security reasons. Use a similar method to the one you used for /etc/master.passwd:

  • Make a copy of your old /etc/group!
  • Maintain a strict separation of the original lines from the distribution file and your own entries. This will help you with the next update.
  • Copy the entire distribution /etc/group to the top of your /etc/group file. At this point you will have a number of duplicates.
  • Check the entries for wheel .You can probably remove the distribution entry and leave your entry in the file, preserving the users.
  • In addition, you may have some users in other groups. For example, installing postfix adds the user postfix to group mail. You need to preserve these users.
  • You don't need to do anything special after updating /etc/group. You can now continue with mergemaster.

    Mergemaster, second time around

    Before running mergemaster again, you should delete the contents of /var/tmp/temproot. Otherwise you might see something like:

    *** The directory specified for the temporary root environment,
        /var/tmp/temproot, exists. This can be a security risk if untrusted
        users have access to the system.
    

    mergemaster does not delete the old directories: you should do so yourself. If this file already exists, mergemaster ignores it and creates a new directory with a name like /var/tmp/temproot.0917.02.18.06. The numbers are a representation of the date and time of creation.

    mergemaster doesn't make it easy to remove the /var/tmp/temproot directory. You may see:

    # rm -rf /var/tmp/temproot
    rm: /var/tmp/temproot/var/empty: Operation not permitted
    rm: /var/tmp/temproot/var: Directory not empty
    rm: /var/tmp/temproot: Directory not empty
    

    The problem here is that the directory /var/empty has been set immutable. Change that with the chflags command and try again:

    # find /var/tmp/temproot|xargs chflags noschg
    # rm -rf /var/tmp/temproot
    

    Run mergemaster in the same way as before, saving the output. If you haven't deleted the old /var/tmp/temproot directory, you might see:

    mergemaster -ia 2>1 | tee -a /var/tmp/merge
    *** Creating the temporary root environment in /var/tmp/temproot.1102.15.01.14
     *** /var/tmp/temproot.1102.15.01.14 ready for use
     *** Creating and populating directory structure in /var/tmp/temproot.1102.15.01.14
    
    set - `grep "^[a-zA-Z]" /usr/src/etc/locale.deprecated`; while [ $# -gt 0 ] ;
    do for dir in /usr/share/locale /usr/share/nls /usr/local/share/nls;
    do   test -d /var/tmp/temproot.1102.15.01.14/${dir}  cd /var/tmp/temproot.1102.15.01.14/${dir};
    test -L "$2"  rm -rf "$2";
    test -L  test -d  mv "$2";
    done; shift; shift; done
    mtree -deU -f /usr/src/etc/mtree/BSD.root.dist -p /var/tmp/temproot.1102.15.01.14/ 
    ./bin missing (created)
    ./boot missing (created)
    ./boot/defaults missing (created)
    ./boot/kernel missing (created)
    ./boot/modules missing (created)
    ./
    ...
    install -o root -g wheel -m 644 /dev/null /var/tinp/temproot.1102.15.01.14/var/run/utmp
    install -o root -g wheel -m 644 /usr/src/etc/minfree /var/tmp/temproot.1102.15.01.14/var/crash
    cd /usr/src/etc/..;
    install -o root -g wheel -m 444 COPYRIGHT /var/tmp/temproot.110 2.15.01.14/
    cd /usr/src/etc/../share/man; make makedb
    makewhatis /var/tmp/temproot.1102.15.01.14/usr/share/man
    *** Beginning comparison
    
    *** Temp ./etc/defaults/rc.conf and installed have the same CVS Id, deleting
    *** Temp ./etc/defaults/pccard.conf and installed have the same CVS Id, deleting
       *** ./etc/defaults/periodic.conf will remain for your consideration 
    *** Temp ./etc/gnats/freefall and installed have the same CVS Id, deleting
    *** Temp ./etc/isdn/answer and installed have the same CVS Id, deleting
    *** Temp ./etc/isdn/isdntel.sh and installed have the same CVS Id, deleting
    ...
    
    *** Comparison complete
    
    *** Files that remain for you to merge by hand:
    /var/tmp/temproot.1102.15.01.14/etc/defaults/periodic.conf
    /var/tmp/temproot.1102.15.01.14/etc/mail/freebsd.mc
    /var/tmp/temproot.1102.15.01.14/etc/mail/freebsd.cf
    /var/tmp/temproot.1102.15.01.14/etc/mail/sendmail.cf
    /var/tmp/temproot.1102.15.01.14/etc/mail/freebsd.submit.cf
    /var/tmp/temproot.1102.15.01.14/etc/mail/mailer.conf
    /var/tmp/temproot.1102.15.01.14/etc/mtree/BSD.include.dist
    /var/tmp/temproot.1102.15.01.14/etc/mtree/BSD.local.dist
    /var/tmp/temproot.1102.15.01.14/etc/mtree/BSD.usr.dist
    /var/tmp/temproot.1102.15.01.14/etc/mtree/BSD.var.dist
    /var/tmp/temproot.1102.15.01.14/etc/pam.d/su
    /var/tmp/temproot.1102.15.01.14/etc/periodic/security/100.chksetuid
    /var/tmp/temproot.1102.15.01.14/etc/periodic/security/200.chkmounts
    /var/tmp/temproot.1102.15.01.14/etc/periodic/security/500.ipfwdenied
    /var/tmp/temproot.1102.15.01.14/etc/periodic/security/600.ip6fwdenied
    /var/tmp/temproot.1102.15.01.14/etc/periodic/security/700.kernelmsg
    /var/tmp/temproot.1102.15.01.14/etc/rc.d/local
    /var/tmp/temproot.1102.15.01.14/etc/crontab
    /var/tmp/temproot.1102.15.01.14/etc/inetd.conf
    /var/tmp/temproot.1102.15.01.14/etc/motd
    /var/tmp/temproot.1102.15.01.14/etc/syslog.conf
    
    *** You chose the automatic install option for files that did not
        exist on your system. The following were installed for you:
          /etc/periodic/security/510.ipfdenied
          /etc/periodic/security/security.functions
          /etc/mac.conf
    

    You're not done yet: there are 21 files above that need looking at. There's a good chance that you've never heard of some of them, let alone changed them. If you know for a fact that you have never changed them, for example if you have religiously kept track of your changes with RCS, you don't need to bother: mergemaster errs on the side of safety. You may have changed others, though. The most obvious one above is /etc/crontab, which contains system-wide commands to be executed by cron.To compare them, use diff:

    $ diff -wu /etc/crontab /var/tmp/temproot.1102.15.01.14/etc/crontab
    --- /var/tmp/crontab Sat Nov 2 16:27:02 2002
    +++ /var/tmp/temproot.1102.15.01.14/etc/crontab Sat Nov 2 15:01:16 2002
    @@ -1,6 +1,6 @@
     # /etc/crontab - root’s crontab for FreeBSD
     #
    -# $FreeBSD: src/etc/crontab,v 1.21 1999/12/15 17:58:29 obrien Exp $
    +# $FreeBSD: src/etc/crontab,v 1.31 2001/02/19 02:47:41 peter Exp $
     #
     SHELL=/bin/sh
     PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin
    @@ -10,19 +10,18 @@
     #
     */5   *   *   *   *   root       /usr/libexec/atrun
     #
    +# save some entropy so that /dev/random can reseed on boot
    +*/11  *   *   *   *   operator   /usr/libexec/save-entropy
    +#
     # rotate log files every hour, if necessary
     0     *   *   *   *   root       newsyslog
     #
     # do daily/weekly/monthly maintenance
    -59    1   *   *   *   root       periodic daily
    -30    3   *   *   6   root       periodic weekly
    +1     3   *   *   *   root       periodic daily
    +15    4   *   *   6   root       periodic weekly
     30    5   1   *   *   root       periodic monthly
     #
     # time zone change adjustment for wall cmos clock,
    -# does nothing if you have UTC cmos clock.
    +# does nothing, if you have UTC cmos clock.
     # See adjkerntz(8) for details.
    -#1,31 0-5 *   *   *   root       adjkerntz -a
    +1,31  0-5 *   *   *   root       adjkerntz -a
    -0,30  *   *   *   *   build      /home/build/build_farm/build_test 2>
    /home/build/cron.err
    -0     21  *   *   *   root       /usr/local/bin/cleanup
    -0      7  *   *   *   grog       /home/grog/bin/update-FreeBSD-cvs
    -1     *   *   *   *   root       (cd /usr/local/etc/postfix; make) 2
    >/dev/null >/dev/null
    

    The lines starting with - show lines only in the old file, which is still in /etc/crontab. The lines starting with + show lines only in the new file, which is in /var/tmp/temp-root.1102.15.01.14/etc/crontab. There are a number of changes here: the CVS ID ($FreeBSD$) has changed from 1.21 to 1.31, and the times of the periodic maintenance have changed. In the meantime, though, you have added other tasks (the bottom four lines), and you have also commented out the periodic invocation of adjkerntz.These are the changes you need to make to the new /etc/crontab before you install it.

    There's a simpler possibility here, though: the only real change that would then be left in /etc/crontab is the change in the starting times for the daily and weekly housekeeping. Does that matter? If you want, you don't need to change anything: the old/etc/crontab is fine the way it is.

    There's a whole list of files that you're likely to change from the defaults. Here are some more likely candidates:

  • You may find it necessary to change /etc/syslog.conf. If so, you may have to merge by hand, but it shouldn't be too difficult.
  • You will almost certainly change /etc/ftab. About the only reason why you might need to merge changes would be if the file format changes, which it hasn't done for over 20 years.
  • /etc/motd contains the login greeting. There's never a reason to take the new version.
  • /etc/inetd.conf can be a problem: as new services are introduced, it changes. At the same time, you may have added services via ports, or enabled services in the manner we will see on page 448. You definitely need to merge this one yourself.
  • If you're using postfix, don't install the distribution version of /etc/mail/mailer.conf. It will reenable sendmail, which can cause significant problems.
  • If you have changed anything in /etc/sysctl.conf, you'll need to move the changes to the new file.
  • Вернуться к учебному плану