Before updating, copy the old configuration files to a separate medium, such as tape device, removable hard disk, USB stick, or ZIP drive, to secure the data. This primarily applies to files stored in /etc as well as some of the directories and files in /var and /opt. You may also want to write the user data in /home (the HOME directories) to a backup medium. Back up this data as root. Only root has read permission for all local files.

Before starting your update, make note of the root partition. The command df / lists the device name of the root partition. In Example 10.1, “List with df -h”, the root partition to write down is /dev/hda3 (mounted as /).

Filesystem     Size  Used Avail Use% Mounted on
/dev/hda3       74G   22G   53G  29% /
tmpfs          506M     0  506M   0% /dev/shm
/dev/hda5      116G  5.8G  111G   5% /home
/dev/hda1       44G    4G   40G   9% /data

If you update a default system from the previous version to this version, YaST works out necessary changes and performs them. Depending on your customizations, some steps or the entire update procedure may fail and you must resort to copying back your backup data. Check the following issues before starting the system update.

Following the preparation procedure outlined in Section 10.1.1, “Preparations”, you can now update your system:

At the end of the installation read the release notes and then click Finish to restart the computer and log in.

There are two preferred ways to update the system to the Service Pack (SP) feature level. One way is to boot from the SP medium. The alternative is to perform an “Online Update” by running YaST Online Update or zen-updater. Other update ways are running rug commands manually, using the Patch CD (see Section 8.3.7, “Updating from a Patch CD”), or making use of a locally installed SMT system.

	Do not miss the Update to Service Pack patch
If you do not select the Update to Service Pack patch, your system will stay at the previous feature level and you will get bug fixes and security updates for a limited time only (six months after the release of the latest SP). Thus for ongoing system integrity it is recommended to switch to the new feature level as early as possible.

On System z systems, the Patch CD update option is not available.

Before initiating an “Online Update” to update to the SP feature level with YaST Online Update, zen-updater, or rug, make sure that the following requirements are met:

10.2.1.2. Updating with YaST Online Update¶

With YaST Online Update you can perform the update to a Service Pack from within the running system. A reboot is only needed once, when the Service Pack installation has finished. Ensure the requirements listed at Requirements for an “Online” Service Pack Update are met before starting the update.

Figure 10.1. Example: Service Pack 1 Package Management Update¶

Figure 10.2. Example: Update to Service Pack 2¶

During update migration using YaST Online Update, the ZMD stack is updated and the ZMD daemon is restarted, too. Therefore, it is advisable to avoid using any other software management tools such as rug, zen-updater, zen-installer and zen-remover. It is recommended to quit the zen-updater during the migration.

1. In a running SUSE Linux Enterprise system, select Computer+YaST+Software+Online Update. The Online Update dialog appears.

   If you are not logged in as root, enter the root password when prompted.

2. Manually select the patch move-to-sles10-sp4 to start the Service Pack installation.

   	move-to-sles10-sp4 not Preselected
   The move-to-sles10-sp4 patch is marked optional. If you do not select it, your system will stay at the current feature level and you will get bug fixes and security updates only for a limited time (six month after the availibility of the latest SP).

3. The Patch Download and Installation dialog tracks the progress log of the migration patch installation. When Total Progress reaches 100%, click Finish.

4. If you are using 3rd party repositories, review and adjust the repository configuration now, if necessary.

5. Install the remaining patches by restarting YaST Online Update again. The necessary patches product-sles10-sp4 and slesp4o-sp4_online are already preselected. Click Accept to start the installation.

   Click Close to finish the update to SUSE Linux Enterprise Server 10 SP4 and reboot.

10.2.1.3. Updating with Software Updater¶

With Software Updater you can perform the update to a Service Pack from within the running system. A reboot is only needed once, when the Service Pack installation has finished. Ensure the requirements listed at Requirements for an “Online” Service Pack Update are met before starting the update. For background information about ZENworks, see Chapter 9, Managing Software with ZENworks.

Figure 10.3. Apply SLE10 SP Maintenance Stack Update¶

1. In a running SUSE Linux Enterprise system, start the Software Updater by clicking the updater icon at the bottom.

   	Waking up ZMD
   If you see the ZMD not running message, check in a terminal as root with rczmd status whether ZMD is alive. In case of trouble enter rug restart --clean to force a restart and cleanup of ZMD and its database.

   If you are not logged in as root, enter the root password when prompted.

2. In the Software Updater window, page down and manually select the optional move-to-sles10-sp4 patch and apply it to start the Service Pack installation.

   	move-to-sles10-sp4 not Preselected
   The move-to-sles10-sp4 patch is marked optional. If you do not select it, your system will stay at the current feature level and you will get bug fixes and security updates only for a limited time (six month after the availibility of the latest SP).

3. Once the installation has finished, choose Refresh from the context menu. The remaining patches product-sles10-sp4 and slesp4o-sp4_online are already preselected—apply them to finally bring the system to the SP4 level.

4. Click Close to finish the update to SUSE Linux Enterprise Server 10 SP4 and reboot.

10.2.1.4. Using rug¶

For background information about rug command line tool, see Section 9.1, “Update from the Command Line with rug”. Use rug, if you need a scriptable solution for the update.

Before initiating the online update using rug to progress to the SP feature level, make sure that the requirements are met as listed in Requirements for an “Online” Service Pack Update.

This it the minimal command sequence needed to migrate the system to the SP4 patch level:

rug ping -a
rug in -y --agree-to-third-party-licences -t patch move-to-sles10-sp4
sleep 40 && rug ping -a
rug up -y --agree-to-third-party-licences -t patch <<EOF
n
EOF
sleep 240 && rug ping -a
rug up -y --agree-to-third-party-licences -t patch <<EOF
n
EOF

rug ping -a ensures, that the ZMD initialization is complete after the previous rug command.

Installing a SUSE Linux Enterprise Service Pack is very similar to installing the original SUSE Linux Enterprise media. As with the original installation, you can choose to install from a local CD or DVD drive containing the Service Pack CD/DVD or from a central network installation source providing a Service Pack installation source. Refer to Part I, “Deployment” for details.

Setting Up a Network Installation Source for Service Pack Media

As with the initial installation of SUSE Linux Enterprise, it is much more efficient having a central installation source on your network to serve all clients rather than installing all of them separately using a set of physical media. Basically, follow the procedure outlined in Section 4.2, “Setting Up the Server Holding the Installation Sources”. Just add another installation source called SLE-10-SP-x-arch, SLES-10-SP-x-arch, or SLED-10-SP-x-arch (where x is the number of the Service Pack and arch is the name of your hardware architecture) and make it available via NFS, HTTP, or FTP.

It is possible to install multiple kernels side by side. This feature is meant to allow administrators to upgrade from one kernel to another by installing the new kernel, verifying that the new kernel works as expected, then uninstalling the old kernel. While YaST does not yet support this feature, kernels can easily be installed and uninstalled from the shell using rpm -i package.rpm.

The default boot loader menus contain one kernel entry. Before installing multiple kernels, it is useful to add an entry for the extra kernels, so they can be selected easily. The kernel that was active before installing the new kernel can be accessed as vmlinuz.previous and initrd.previous. By creating a boot loader entry similar to the default entry and having this entry refer to vmlinuz.previous and initrd.previous instead of vmlinuz and initrd, the previously active kernel can be accessed. Alternatively, GRUB and LILO support wild card boot loader entries. Refer to the GRUB info pages (info grub) and to the lilo.conf(5) manual page for details.

The following kernel modules are no longer available:

The following kernel module package was changed internally:

For technical reasons, it was necessary to drop support for Ralink WLAN cards. The following modules were not part of the distribution and will not be added in the future:

As of 2.6.10, serial devices on ia64 are named based on the order of ACPI and PCI enumeration. The first device in the ACPI name space (if any) becomes /dev/ttyS0, the second becomes /dev/ttyS1, etc., and PCI devices are named sequentially starting after the ACPI devices.

On HP systems, you must reconfigure the EFI console then you can drop the console parameter from the kernel boot command. As a work-around, you can try console=ttyS1... as a boot parameter instead of console=ttyS0....

Find details in /usr/src/linux/Documentation/ia64/serial.txt, which is part of the kernel-source software package.

Do not set the LD_ASSUME_KERNEL environment variable any longer. In the past, it was possible to use it to enforce LinuxThreads support, which was dropped. If you set LD_ASSUME_KERNEL=2.4.x in SUSE Linux Enterprise 10, everything breaks because ld.so looks for glibc and related tools in a path that does not exist.

The tar usage syntax is stricter now. The tar options must come before the file or directory specifications. Appending options, like --atime-preserve or --numeric-owner, after the file or directory specification makes tar fail. Check your backup scripts. Commands such as the following no longer work:

tar czf etc.tar.gz /etc --atime-preserve

See the tar info pages for more information.

The Apache Web server (version 2) has been replaced with version 2.2. For Apache version 2.2, Chapter 40, The Apache HTTP Server was completely reworked. In addition, find generic upgrade information at http://httpd.apache.org/docs/2.2/upgrading.html and the description of new features at http://httpd.apache.org/docs/2.2/new_features_2_2.html.

Kerberos is the default for network authentication instead of heimdal. Converting an existing heimdal configuration automatically is not possible. During a system update, backup copies of configuration files are created as shown in Table 10.1, “Backup Files”.

The client configuration (/etc/krb5.conf) is very similar to the one of heimdal. If nothing special was configured, it is enough to replace the parameter kpasswd_server with admin_server.

It is not possible to copy the server-related (kdc and kadmind) data. After the system update, the old heimdal database is still available under /var/heimdal. MIT kerberos maintains the database under /var/lib/kerberos/krb5kdc. For more information, see Chapter 45, Network Authentication—Kerberos and Chapter 46, Installing and Administering Kerberos.

Hotplug events are now completely handled by the udev daemon (udevd). The event multiplexer system in /etc/hotplug.d and /etc/dev.d is no longer used. Instead, udevd calls all hotplug helper tools directly according to its rules. Udev rules and helper tools are provided by udev and various other packages.

To increase security, the enclosed firewall solution SuSEFirewall2 is activated at the end of the installation in the proposal dialog. This means that all ports are closed initially and can be opened in the proposal dialog if necessary. By default, you cannot log in from remote systems. It also interferes with network browsing and multicast applications, such as SLP, Samba ("Network Neighborhood"), and some games. You can fine-tune the firewall settings using YaST.

If network access is required during the installation or configuration of a service, the respective YaST module opens the needed TCP and UDP ports of all internal and external interfaces. If this is not desired, close the ports in the YaST module or specify other detailed firewall settings.

By default, IPv6 support is not enabled for KDE. You can enable it using the /etc/sysconfig editor of YaST. The reason for disabling this feature is that IPv6 addresses are not properly supported by all Internet service providers and, as a consequence, this would lead to error messages while browsing the Web and delays while displaying Web pages.

Online Update now supports a special kind of RPM package that only stores the binary difference from a given base package. This technique significantly reduces the package size and download time at the expense of higher CPU load for reassembling the final package. See /usr/share/doc/packages/deltarpm/README for technical details.

At the end of the installation (proposal dialog), the ports needed for the print system must be open in the firewall configuration. Port 631/TCP and port 631/UDP are needed for CUPS and should not be closed for normal operation. Port 515/TCP (for the old LPD protocol) and the ports used by Samba must also be open for printing via LPD or SMB.

The change from XFree86 to X.Org is facilitated by compatibility links that enable access to important files and commands with the old names.

In the course of the change to X.Org, the packages were renamed from XFree86* to xorg-x11*.

The configuration tool SaX2 writes the X.Org configuration settings into /etc/X11/xorg.conf. During an installation from scratch, no compatibility link from XF86Config to xorg.conf is created.

The packages xview, xview-devel, xview-devel-examples, olvwm, and xtoolpl were dropped. In the past, only the XView (OpenLook) base system was provided. The XView libraries are no longer provided after the system update. Even more important, OLVWM (OpenLook Virtual Window Manager) is no longer available.

A number of terminal emulators were removed because they are either no longer maintained or do not work in the default environment, especially by not supporting UTF-8. SUSE Linux Enterprise Server offers standard terminals, such as xterm, the KDE and GNOME terminals, and mlterm (Multilingual Terminal Emulator for X), which might be a replacement for aterm and eterm.

The sound mixer kmix is preset as the default. For high-end hardware, there are other mixers, like QAMix. KAMix, envy24control (only ICE1712), or hdspmixer (only RME Hammerfall).

In the past, a patch was applied to the cdrecord binary from the cdrecord package to support burning DVDs. Instead, a new binary cdrecord-dvd is installed that has this patch.

The growisofs program from the dvd+rw-tools package can now burn all DVD media (DVD+R, DVD-R, DVD+RW, DVD-RW, DVD+RL). Try using that one instead of the patched cdrecord-dvd.

The Manual Installation mode is gone from the boot loader screen. You can still get linuxrc into manual mode using manual=1 at the boot prompt. Normally this is not necessary because you can set installation options at the kernel prompt directly, such as textmode=1 or a URL as the installation source.

Due to technical problems with JFS, it is no longer supported. The kernel file system driver is still there, but YaST does not offer partitioning with JFS.

As an intrusion detection system, use AIDE (package name aide), which is released under the GPL. Tripwire is no longer available on SUSE Linux.

You should include these default configuration files from within your application-specific configuration file, because it is easier to modify and maintain one file instead of the approximately forty files that used to exist on the system. If you install an application later, it inherits the already applied changes and the administrator is not required to remember to adjust the configuration.

The changes are simple. If you have the following configuration file (which should be the default for most applications):

#%PAM-1.0
auth     required       pam_unix2.so
account  required       pam_unix2.so
password required       pam_pwcheck.so
password required       pam_unix2.so    use_first_pass use_authtok
#password required      pam_make.so     /var/yp
session required        pam_unix2.so

you can change it to:

#%PAM-1.0
auth     include        common-auth
account  include        common-account
password include        common-password
session  include        common-session

By default, calling su to become root does not set the PATH for root. Either call su - to start a login shell with the complete environment for root or set ALWAYS_SET_PATH to yes in /etc/default/su if you want to change the default behavior of su.

The configuration files in /etc/sysconfig/powersave have changed:

/etc/powersave.conf has become obsolete. Existing variables have been moved to the files listed in Table 10.4, “Split Configuration Files in /etc/sysconfig/powersave”. If you changed the “event” variables in /etc/powersave.conf, these must now be adapted in /etc/sysconfig/powersave/events.

The names of sleep states have changed from:

To:

Names of the powersave configuration variables are changed for consistency, but the sysconfig files are still the same. Find more information in Section 28.5.1, “Configuring the powersave Package”.

cardmgr no longer manages PC cards. Instead, as with Cardbus cards and other subsystems, a kernel module manages them. All necessary actions are executed by hotplug. The pcmcia start script has been removed and cardctl is replaced by pccardctl. For more information, see /usr/share/doc/packages/pcmciautils/README.SUSE.

Many applications now rely on D-BUS for interprocess communication (IPC). Calling dbus-launch starts dbus-daemon. The systemwide /etc/X11/xinit/xinitrc uses dbus-launch to start the window manager.

If you have a local ~/.xinitrc file, you must change it accordingly. Otherwise applications like f-spot, banshee, tomboy, or Network Manager banshee might fail. Save your old ~/.xinitrc. Then copy the new template file into your home directory with:

cp /etc/skel/.xinitrc.template ~/.xinitrc

Finally, add your customizations from the saved .xinitrc.

For reasons of compatibility with LSB (Linux Standard Base), most configuration files and the init script were renamed from xntp to ntp. The new filenames are:

For proper functionality, GNOME applications depend on file system change notification support. For local-only file systems, install the gamin package (preferred) or run the FAM daemon. For remote file systems, run FAM on both the server and client and open the firewall for RPC calls by FAM.

GNOME (gnome-vfs2 and libgda) contains a wrapper that picks gamin or fam to provide file system change notification:

By default, xinetd no longer starts the vsftpd FTP server. It is now a stand-alone daemon and you must configure it with the YaST runtime editor.

With Firefox 1.5, the method for applications to open a Firefox instance or window has changed. The new method was already partly available in former versions where the behavior was implemented in the wrapper script.

If your application does not use mozilla-xremote-client or firefox -remote, you do not need to change anything. Otherwise the new command to open a URL is firefox url and it does not matter whether Firefox is already running or not. If it is already running, it follows the preference configured in Open links from other applications in.

From the command line, you can influence the behavior by using firefox -new-window url or firefox -new-tab url.