These release notes cover the following areas:
This release of SUSE Linux Enterprise Server ships with Novell AppArmor. The AppArmor intrusion prevention framework builds a firewall around your applications by limiting the access to files, directories, and POSIX capabilities to the minimum required for normal operation. AppArmor protection can be enabled via the AppArmor control panel, located in YaST under Novell AppArmor. For detailed information about using Novell AppArmor, see the documentation in /usr/share/doc/packages/apparmor-docs.
The AppArmor profiles included with SUSE Linux have been developed with our best efforts to reproduce how most users use their software. The profiles provided work unmodified for many users, but some users find our profiles too restrictive for their environments.
If you discover that some of your applications do not function as you expected, you may need to use the AppArmor Update Profile Wizard in YaST (or use the aa-logprof(8) command line utility) to update your AppArmor profiles. Place all your profiles into learning mode with the following: aa-complain /etc/apparmor.d/*
When a program generates many complaints, the system's performance is degraded. To mitigate this, we recommend periodically running the Update Profile Wizard (or aa-logprof(8)) to update your profiles even if you choose to leave them in learning mode. This reduces the number of learning events logged to disk, which improves the performance of the system.
SuSEfirewall2 is enabled by default. That means that 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.
Starting with SUSE Linux Enterprise 10, vsftpd can be configured independently or over the xinetd. The default is stand-alone. In previous versions, the default was xinetd.
To run it over xinetd, make sure that the service is enabled in the xinetd configuration (/etc/xinetd.d/vsftpd) and set the following line in /etc/vsftpd.conf:
listen=NO
If you cannot access https://update.novell.com directly but via a mandatory proxy server, proceed as explained in the Technical Information Document (TID) at http://www.novell.com/support/search.do?cmd=displayKC&docType=kc&externalId=3377050&sliceId=SAL_Public
The kernel is crashing or otherwise misbehaving and a kernel core dump needs to be captured for analysis.
A description on how to setup kdump can be found under the following URL: http://www.novell.com/support/search.do?cmd=displayKC&docType=kc&externalId=3374462&sliceId=SAL_Public
Xen has been updated to version 3.0.4 with select features upstream. This new version includes new tools, supports paravirtualized frame buffer, allows 32-bit VMs to run on a 64-bit hypervisor, and offers improved fully-virtualized guest support.
The VM installation tool has moved from the "System" category in YaST to the new "Virtualization" category. The VM installation tool has been rewritten to take advantage of new Xen features and to better integrate with other virtualization tools. The VM installation tool can run graphically or in text mode. For graphical operation, install the optional python-gtk package. For more information, read the vm-install man page.
An optional VM management tool has been added. To use it, install the virt-manager package,
and look in YaST's "Virtualization" category. The tool currently does not manage VM configurations
that are not known to xend (that is, those in /etc/xen/vm that are not running).
To place a VM configuration under xend's control, run the "xm new
The VM installation tool now defaults to displaying VMs with VNC rather than SDL, to allow interoperability with virt-manager.
If you experience problems with VNC access, it may be because the VNC ports are selected dynamically. The easiest solution to this problem is to use virt-manager (which looks up the port in xenstore) to open the display. You can also use the following script to attach the vncviewer to the dynamic VNC port. #!/bin/sh set -e domid=`xm domid "$1"` port=`xenstore-read /local/domain/${domid}/console/vnc-port` vncviewer ::$port
When you update from SLES10 goldmaster to SLES10 SP1, any changes you have made to the domain 0 configuration (in /etc/xen/xend-config.sxp) will be lost. You need to manually re-enter your changes, which were saved in /etc/xen/xend-config.sxp.rpmsave. Also, the format of the VM definition files has changed, requiring you to update the definition files of all VMs.
hot-add-memory is not supported at this point in time. A maintenance update will explicitly mention the availability of this function.
On a Hyper-Thread or Multi-Core capable i386 or x86_64 arch system, do not enable (write '1' or other non-zero value into) the 'cpu_exclusive' flag of any cpuset whose 'cpus' setting includes only some, not all, of the logical CPUs on a Hyper-Thread capable core or some, not all, of the Multiple Cores in a single processor package. Also on such a system, do not modify the 'cpus' setting of any cpuset whose 'cpu_exclusive' flag is set (enabled) in such a way as to request disabling some but not all such Hyper-Threads or Multi-Cores on a single processor package. Any such combination of operations that attempts to invoke 'cpu_exclusive' on just a portion of the logical CPUs on a processor package will cause the system to quickly and completely freeze, requiring a system reset.
Administrators of Hyper-Thread and Multi-Core capable i386 and x86_64 arch systems should not allow untrusted users permission to manipulate cpusets in the above manner, to avoid exposing the entire system to the risk of freezing. Perhaps the least invasive way to do this would be to disable the 'cpu_exclusive' setting in any cpuset that an untrusted user is granted permission to modify, and to make that 'cpu_exclusive' per-cpuset file owned by root and writable by no one else.
Batch schedulers on such systems should ensure that any cpuset they automatically mark 'cpu_exclusive' is configured to include either all or none of the logical CPUs (Hyper-Threads and/or Multi-Cores) on each processor package.
Depending on the workload, i586 and i686 machines with 16GB-48GB of memory can run into instabilities. Machines with more than 48GB of memory are not supported at all. To run on such a machine, lower the memory with the mem= kernel boot option.
On such memory scenarious we strongly recommend to use a x86_64 with 64-bit SLES and run the x86 applications on it.
By default, IPv6 support is not enabled for KDE. You can enable it using the /etc/sysconfig editor of YaST. This feature is disabled because IPv6 addresses are not properly supported by all Internet service providers and, as a consequence, would lead to error messages while browsing the Web and delays while displaying Web pages.
When running real-time applications on larger systems, lower maximum latencies can be achieved by employing the new disable_buffer_lru kernel command-line option. This disables the per-CPU LRU in the buffer cache, and may thus decrease overall filesystem performance.
Heartbeat 2 documentation in addition to that provided in the SLES 10 Administration Guide can be found at http://www.novell.com/documentation/sles10/hb2/data/hb2_config.html.
The "sapinit" RPM package has been updated to version 2.0.1. This version fixes a long standing problem of not being able to adequately setting various kernel parameters for an SAP system.
With this new version, it is now possible easily to set various important kernel parameters by usage of the configuration parameters found in the file "/etc/sysconfig/SAPinit", either using YaST or by directly editing this file, although this usually should not be necessary, while the various parameters are now also assigned reasonable default values taken from the relevant SAP notes.
The configuration file "/etc/sysctl.conf" as well as "/etc/fstab" is now automatically updated by the "/usr/sbin/SAPinit" script (which is run at each restart of the system, or manually from the command line by the user), to reflect the defined values used for the various kernel parameters as defined in "/etc/sysconfig/SAPinit".
For further informations, refer to "/etc/sysconfig/SAPinit", "/usr/share/doc/packages/sapinit/README", and "/usr/sbin/SAPinit".
Updates from SLES 9 to SLES 10 are supported starting from one of the following bases:
Update a system by starting the SLES 10 installation system and choosing Update instead of New installation. To verify whether one of the above variants is installed, you can use the tool SPident -vv. This shows the current level of your system.
SUSE Linux Enterprise 10 products offer various migration paths for updating the system to Service Pack 1. We recommend to pay extra attention if you plan to migrate your system that has an Add-on product or Kernel Module Packages (e.g 3rd party drivers from ATI/nVidia) installed.
Updating the system via PatchCD is only possible if no further installation source (e.g. SDK) was registered previously. In case you depend on this update path the workaround is to provide the PatchCD via FTP/NFS/HTTP as installation source.
Please find further information at http://developer.novell.com/wiki/index.php/Migration_to_SP1_with_Add-on_and_kmps
Under SLES 9, when extracting a directory from a tar archive that already existed as a symbolic link in the target directory, tar would overwrite the symlink with an actual directory. Under SLES 10, tar leaves the symlink and places the contents of the archive within it.
To enforce the old behavior please use the option --no-overwrite-dir when extracting an archive.
MIT Kerberos is now used instead of heimdal. Converting an existing Heimdal configuration automatically is not always possible. During a system update, backup copies of configuration files are created in /etc with the suffix .heimdal. YaST-generated configuration settings in /etc/krb5.conf are converted, but check whether the results match your expectations.
Before starting the update, you should decrypt an existing Heimdal database into a human-readable file with the command kadmin -l dump -d heimdal-db.txt. This way, you can create a list of available principals that you can restore one-by-one using kdc from MIT Kerberos. Find more information about setting up a KDC in the documentation in the "krb5-doc" package.
To configure a Kerberos client, start the YaST Kerberos Client module and enter your values for "Standard Domain", "Standard Realm", and "KDC Server Address".
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 to a kernel version lower than 2.6.5, everything breaks because ld.so looks for libraries in a version that does not exist anymore.
SUSE Linux Enterprise Server 9 set up the user environment with an unlimited stack size resource limit to work around restrictions in stack handling of multithreaded applications. With SUSE Linux Enterprise Server 10, this is no longer necessary and has been removed. The login environment now defaults to the kernel default stack size limit. To restore the old behavior, add "ulimit -Ss unlimited" to /etc/profile.local. If you want an automatic configuration of your resource limits suited to protect desktop systems, you may want to install the "ulimit" package.
During the upgrade from SLES9 to SLES10 also MySQL is upgraded from 4.x to 5.x. To complete this migration you have also to upgrade your data as described in the MySQL documentation.
When updating a system with the snd-intel8x0 module (for Intel, SIS, AMD, and Nvidia on-board chips), the system might be unable to load the module at reboot, because the module option joystick was removed from the newer version. To fix the problem, reconfigure the sound system using YaST.
Although most existing PHP 4 code should work without changes, there are a few backwards-incompatible changes. Find a list of these changes at:
http://www.zend.com/manual/migration5.incompatible.php
To use iSCSI disks during installation it is necessary to add the following parameter to the kernel parameter line:
withiscsi=1During installation, an additional screen appears that provides the possibility to attach iSCSI disks to the system and use them in the installation process.
SLES10 SP1 supports booting from an iSCSI server on i386, x86_64 and ppc, when an iSCSI enabled firmware is used.
On ppc, a single bootfile (zImage.initrd) instead of yaboot is used.
iSCSI devices cannot be used for Linux Software RAID. Using MD devices on top of iSCSI triggers a cyclic dependency that leads to a crash.
QLogic iSCSI Expansion Card for IBM BladeCenter provides both Ethernet and iSCSI functions. Some parts on the card are shared by both functions. The current qla3xxx and qla4xxx drivers support Ethernet and iSCSI function individually. They do not support using both functions at the same time. Using both Ethernet and iSCSI functions at the same time may hang the device and cause data lost and filesystem corruptions on iSCSI devices or network disruptions on Ethernet.
The qla3xxx (ethernet) and qla4xxx (iSCSI) drivers work good individually. However, when both drivers are active at the same time, one of the driver would hang or lost connection. The consiquences are network disruption and iSCSI target filesystem corruption.
Do not use the /dev/mapper device path for the root= kernel parameter. /dev/mapper is an internal name of the LVM2 system. Instead use the proper LVM notation /dev/VG/LV, as in /dev/system/root for the logical volume root on volume group system.
If you want to use EDD information (/sys/firmware/edd/<device>) to identify your storage devices, change the installer default settings using an additional kernel parameter.
Requirements:
Procedure:
If you have installed and configured an iSCSI SAN and have created and configured EVMS Disks or Volumes on that iSCSI SAN, your EVMS volumes might not be visible or accessible. This problem is caused by EVMS starting before the iSCSI service. iSCSI must be started and running before any disks or volumes on the iSCSI SAN can be accessed.
To resolve this problem, enter either chkconfig evms on or chkconfig boot.evms on at the Linux server console of every server that is part of your iSCSI SAN. This ensures that EVMS and iSCSI start in the proper order each time your servers reboot.
If you plan to add additional storage devices to your system after the OS installation, we strongly recommend to use persistent device names for all storage devices during installation. The installer by default uses the kernel device names.
How to proceed:
During installation, enter the partitioner. For each partition, select "Edit" and go to the "FStab Options" dialog. Any mount option except "Device name" provide you persistent devicenames.
To switch an already installed system to using persistent device names, proceed as described above for all existing partitions. In addition, rerun the boot loader module in YaST to switch the bootloader to using the persistent device name also. Just start the module and select "Finish" to write the new proposed configuration to disk. This needs to be done before adding new storage devices.
For forther information please look at http://en.opensuse.org/Persistant_Storage_Device_Names.
With SUSE Linux Enterprise Server 10, we switched to "cryptoloop" as the default encryption module. SUSE Linux Enterprise Server 9 used twofish256 using loop_fish2 with 256 bits. Now we are using twofish256 using cryptoloop with 256 bits. The old twofish256 is available as twofishSL92.
When the way the root device is mounted (by UUID or by label) is changed in YaST, the boot loader configuration needs to be saved again to make the change effective for the boot loader.
The "mount by" setting displayed in the YaST2 boot loader module is the setting that will be in effect after saving the configuration.
JFS is no longer supported for new installations. The kernel file system driver is still there, but YaST does not offer partitioning with JFS.
To load unsupported kernel drivers automatically during boot, set the sysconfig variable LOAD_UNSUPPORTED_MODULES_AUTOMATICALLY in /etc/sysconfig/hardware/config to "yes".
Hotplug events are now completely handled by the udev daemon (udevd). We do not use the event multiplexer system in /etc/hotplug.d and /etc/dev.d anymore. 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.
Users of the XFS filesystem may see degraded performance when upgrading from SLES10 to SLES10-SP1. Typical symptoms will be slow file creation, removal and attribute manipulation. The degraded performance may be seen on LVM, device mapper or MD/RAID1 based filesystems and are a result of barriers being incorrectly enabled on these devices. Performance can be restored by applying the "nobarrier" mount option in /etc/fstab.
Some Intel Core Duo or Core 2 Duo laptops produce a high pitched noise when working on battery. If you suffer from this problem, you can work around this by passing max_cstate=2 as boot parameter or echo 2 >/sys/module/processor/parameters/max_cstate at runtime. Be aware that battery life time might be shorten by this workaround.
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 shell script sux was removed. The functionality of forwarding xauth keys between users is now handled by the pam_xauth module and su.
By default, the kernel tries to keep threads on the local CPU (and local node on NUMA machines). Depending on the application, this may not deliver the best performance, especially applications with a large working set for each thread tend to perform better when being scheduled to different nodes because they can then use caches of multiple nodes.
With the following sysctl, this behavior is changed. By setting the sysctl variable kernel.affinity_load_balancing to 1, the scheduler no longer tries to keep thread local to a CPU.
Using this sysctl on the wrong application scenario may degrade system performance.
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.
Java packages are changed to follow the JPackage Standard (http://www.jpackage.org/). Read the documentation in /usr/share/doc/packages/jpackage-utils/ for information.
If you are not satisfied with locale system defaults, change the settings in ~/.i18n. Entries in ~/.i18n override system defaults from /etc/sysconfig/language. Use the same variable names but without the RC_ namespace prefixes, for example, use LANG instead of RC_LANG. For information about locales in general, see "Language and Country-Specific Settings" in the Reference Manual.
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 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:
/etc/slp.reg.d/ntp.reg
/etc/init.d/ntp
/etc/logrotate.d/ntp
/usr/sbin/rcntp
/etc/sysconfig/ntp
Entering KDB code breakpoints on multiple CPUs in parallel can lead to deadlocks.
Already introduced for SUSE Linux Enterprise Server 9 on the x86-64 (AMD64) architecture with 64-bit kernels, the Linux kernel in SUSE Linux Enterprise Server also supports nonexecutable stack (NX) on x86 for CPUs that support it (Intel Prescott and AMD64) with 32-bit kernels. For this to work, the kernel with PAE support, kernel-bigsmp, must be installed. Go into YaST and install that kernel instead of your default kernel. For 64-bit kernels, all kernels support NX.
The nonexecutable stack improves the security of your system. Many security vulnerabilities are stack overflows, where an attacker overwrites the stack of your program by feeding oversized data to the application that fails to properly check the length. Depending on the details of the program, with nonexecutable stack, these vulnerabilities may either not be exploitable (and only crash the program, resulting in a DoS) or at least be significantly harder to exploit.
Some applications do require executable stacks. The compiler detects this during compilation and marks the binaries accordingly. The kernel enable an executable stack for them to allow them to work.
On x86-64, to provide a higher level of security, the user can pass noexec=on on the kernel command line. The kernel then uses a nonexecutable stack unconditionally and also marks the data section of a program nonexecutable. This provides a higher protection level than just the nonexecutable stack, but potentially causes problems for some applications. SUSE has not found any problems during testing the most commonly used applications and services. Because it is not the default, this has not been tested as extensively as the stack protection alone, so SUSE only recommends this setup for servers after the administrator has verified that all needed services continue to function properly.
For reasons of compatibility with SLES 9, the mapped-base functionality is present in SLES 10. This functionality is used by 32-Bit applications that need a larger dynamic data space (such as database management systems).
With SLES 10, a similar functionality called flexmap is available. Because this is now the preferred way, mapped-base is deprecated and will vanish in future releases.
SLES 10 provides different I/O schedulers. The scheduler can be set per disk. The general default is CFQ. This default may be modified by the device driver or by the user with
echo keyword > /sys/block/dasda/queue/schedulerwhere keyword is one of the following:
noop anticipatory [deadline] cfqChanging the scheduler may seriously impact the system performance.
The default (by the kernel or the device driver) has been shown to be the best selection. There may be setups where this is not true.
The libhugetlbfs project shipped with SLES 10 is a preview of application provision with transparent access to system huge pages. While the library provides an application with easy access to huge pages when sufficient huge pages have been previously allocated on the system, additional development and testing is required to provide a stable transition to normal pages in a production environment.
The default mdadm.conf (and lvm.conf) do not work properly with multipathed devices. By default, both md and LVM2 scan physical devices only and ignore any symlinks or device-mapper devices.
This does not work for multipathed devices as there we have to omit all physical devices and scan devices in /dev/disk/by-name only (as these are the correct multipathed devices).
If there was a previous MD installation you'll have either modify mdadm.conf to handle the devices correctly (by using the line 'DEVICES /dev/disk/by-name/*') or clear the md superblock altogether.
A root partition on multipath is only supported if the /boot partition is on a separate, nonmultipathed partition. Otherwise no bootloader is written.
During boot, there may be drivers loaded that are not needed at runtime. To prevent this load at boot time, insert the following line into /etc/modprobe.conf.local:
install driver-name /bin/true Replace driver-name with the actual name of the module.WARNING
Be very careful. Inserting the wrong module name may lead to an unusable system.
With SLES 10 running on a HP MSA1000 SAN, whenever a disk fails or faults, MSA1000 SAN requires the failed or faulted disk to be removed from the disk array and re-created. By re-creating the disk, the disk array reshuffles the order of the disks in the SAN. The re-created disk will be pushed to the last device in the array.
An iSCSI shared device should never be mounted directly on the local machine. In an OCFS2 environment, doing so cause all hardware to hard hang.
Kernel Module Packages (KMP) can now update a system's PCI ID database to add support for new hardware components.
To update a system's PCI ID database a KMP installs a file containing updated PCI ID information in the /usr/share/pci.id.d/ directory. This file contains PCI ID information formatted using the standard pci.ids file syntax (see http://pciids.sourceforge.net/pci.ids)
To merge the updated PCI ID information into the system's PCI ID database a KMP's %post section of its spec file must include the following:
if [ -x /usr/bin/merge-pciids -a -x /usr/bin/perl ]; then /usr/bin/merge-pciids else echo "ERROR: merge-pciids or perl not found" fi
On the top level of the first CD, find a very detailed ChangeLog. Also read the READMEs on the CD.
If you encounter a bug, please report it through your support contact.
Your SUSE Linux Enterprise Team
Fri Nov 9 15:33:03 UTC 2007