wiley publishing suse linux 9 bible phần 10 ppsx

554
Part V ✦ SUSE Linux in the Enterprise
Upgrading a Kernel Package
Upgrading from one kernel package to another is simple; you just need to install the new
package using the
rpm command. If you want to retain the ability to run the old kernel,
you should back up the files called
/boot/vmlinuz-<version number> and /boot/
initrd-<version-number> and also the directory /lib/modules/<version-number>/
and restore them after you have installed the new kernel RPM. You also want to check that
you have an entry in the GRUB configuration for the old kernel and possibly do a
mkinitrd
(see the section “Building the Kernel” later in the chapter). If you use LILO for booting, check
the LILO configuration and rerun LILO before rebooting.
Kernel Configuration
To be able to build kernels, you obviously need the kernel source package (called kernel-
source) installed. In addition, you need gcc, make, and a number of other packages. One of
the SUSE installation package set options is “Kernel development”; if you have installed that
selection, you have everything you need.
If you want to base your kernel configuration on the currently running kernel, you have more
than one way to begin.
The configuration of the kernel that is actually running is always available in
/proc/config
.gz, which is a gzipped “virtual” file in the /proc filesystem, which is created in memory on
the fly by the running kernel (see Listing 27-1).
Listing 27-1: Looking at the Configuration of the Running Kernel
root@bible: /proc # zcat config.gz | more
#
# Automatically generated make config: don’t edit
#
CONFIG_X86=y

CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
# CONFIG_STANDALONE is not set
CONFIG_BROKEN_ON_SMP=y
#
# General setup

37_577395 ch27.qxd 12/15/04 12:28 AM Page 554
555
Chapter 27 ✦ The Kernel
It is instructive to page through this file and look at the various options in it that refer to the
hardware, filesystems, and so on that are to be supported by the kernel.
✦ The
=y at the end of lines means that the support for the relevant item is compiled into
the kernel.
✦ Lines ending
is not set clearly imply that the support is not included.
✦ Lines ending
=m imply that the support is provided by a loadable kernel module rather
than being compiled into the kernel itself. SUSE provides most functionality in the form
of modules.
In a newly installed system, you should find that
/usr/src/linux/.config is identical to
/boot/config-<version-number>-default and to the content of /proc/config.gz when

uncompressed.
The kernel build process takes place in
/usr/src/linux/, which is a symbolic link to
/usr/src/linux-<version number>/ (for example, /usr/src/ linux-2.6.5-7.79/). The
commands that you use to build the kernel must be issued in this directory because they
refer to the top-level kernel makefile, which is
/usr/src/linux/Makefile.
The configuration file for building the kernel is the file
.config in this directory. If this file
does not exist, you need to create it for the first time. If the kernel that is running is the exact
same version that the source code is for, you can simply do this:
root@bible:~ # zcat /proc/config.gz > /usr/src/linux/.config
root@bible:~ # cd /usr/src/linux/
root@bible: /usr/src/linux-2.6.5-7.79/ # make oldconfig
You may want to back up any existing .config file first.
Alternatively, the command make cloneconfig has exactly the same effect. If the version of
the kernel source is newer than the running kernel, then the command
make oldconfig is
what you need.
Creating a new kernel configuration can be done in essentially one of three ways.
✦ If you type
root@bible: ~ # cd /usr/src/linux/
root@bible: /usr/src/linux-2.6.5-7.79/ # make config
(note that the version number you see on the directory depends on the kernel source
version that is installed), you will see something like this:
root@bible: /usr/src/linux-2.6.5-7.79/ # make config
scripts/kconfig/conf arch/i386/Kconfig
drivers/char/lirc/Kconfig:102:warning: ‘select’ used by config symbol
‘LIRC_SIR’ refer to undefined symbol ‘LIRC_SIR_IRDA’
#

# using defaults found in .config
#
*
* Linux Kernel Configuration
*
Tip
37_577395 ch27.qxd 12/15/04 12:28 AM Page 555
556
Part V ✦ SUSE Linux in the Enterprise
*
* Code maturity level options
*
Prompt for development and/or incomplete code/drivers (EXPERIMENTAL)
[Y/n/?] Y
Select only drivers expected to compile cleanly (CLEAN_COMPILE)
[Y/n/?] Y
Select only drivers that don’t need compile-time external firmware
(STANDALONE) [N/y/?]
*
* General setup
*
Support for paging of anonymous memory (swap) (SWAP) [Y/n/?]
This is simply a series of questions and answers; there is no way to go back, and it cer-
tainly could not be described as “user friendly.”
✦ A more pleasant method is the following:
root@bible: /usr/src/linux-2.6.5-7.79 # make menuconfig
This requires the ncurses-devel package to be installed. You will see a screen some-
thing like the one in Figure 27-1.
Figure 27-1: Using make menuconfig for kernel configuration
This is a much nicer text-based, menu-driven interface that splits the items into sec-

tions and submenus. When you have completed your selections, save the configuration
file (see Figure 27-2).
37_577395 ch27.qxd 12/15/04 12:28 AM Page 556
557
Chapter 27 ✦ The Kernel
Figure 27-2: Saving the configuration
✦ However, the nicest interface is the graphical one that you can get by running the
command
root@bible: /usr/src/linux-2.6.5-7.79 # make xconfig
This requires the qt3-devel package to be installed to create the graphical user inter-
face. This contains exactly the same information as the other two systems but is easier
to navigate and is a new interface (previously
make xconfig used the less elegant Tk
graphical toolkit to create its graphical user interface). See Figures 27-3 and 27-4 for
examples of the interface.
A nice feature of this interface is that if you choose Options➪ Show all Options, you
can see the name of each kernel configuration variable, the possible values it can have,
and its current setting.
There is also an option make gconfig that uses the GTK+ libraries for a GNOME-like
interface.
Whichever interface you use for configuring the kernel, most items offer the choice of y, m,
or
n (in the xconfig interface these are represented by a tick in the checkbox, a dot in the
checkbox, and an empty checkbox, respectively):
✦
y means “Compile this option into the kernel.”
✦
m means “Compile this option as a module.”
✦
n means “Don’t include this option.”

When you have saved your configuration, you will have a new
.config file. This is the one
you will use when you start building the kernel.
Tip
37_577395 ch27.qxd 12/15/04 12:28 AM Page 557
558
Part V ✦ SUSE Linux in the Enterprise
Figure 27-3: Using make xconfig for kernel configuration
Figure 27-4: Selecting options in the xconfig interface
37_577395 ch27.qxd 12/15/04 12:28 AM Page 558
559
Chapter 27 ✦ The Kernel
Building the Kernel
Now, assuming the architecture is x86, you need to do the following:
root@bible: /usr/src/linux-2.6.5-7.79/ # make bzImage
Historically, the b stands for big, and the z indicates that it is a compressed image. On other
architectures, the command you need is different. Details specific to SUSE are available at
www.suse.de/~agruen/kernel-doc/.
This is where the real work gets done. In the 2.6 kernels, by default you see slightly less out-
put on the screen than before (see Listing 27-2).
Listing 27-2: Output from the Kernel Build Process
root@bible: /usr/src/linux-2.6.5-7.79/ # make bzImage
SPLIT include/linux/autoconf.h -> include/config/*
make[1]: `arch/i386/kernel/asm-offsets.s’ is up to date.
CHK include/linux/compile.h
UPD include/linux/compile.h
CC init/version.o
LD init/built-in.o
CC init/kerntypes.o
IKCFG kernel/ikconfig.h

GZIP kernel/config_data.gz
IKCFG kernel/config_data.h
CC kernel/configs.o
LD kernel/built-in.o
GEN .version
CHK include/linux/compile.h
UPD include/linux/compile.h
CC init/version.o
[ ]
When the build process has completed, all being well, you will see a message similar to this:
Root device is (3, 1)
Boot sector 512 bytes.
Setup is 5039 bytes.
System is 1426 kB
Kernel: arch/i386/boot/bzImage is ready
You can now navigate to that directory and see the file that has been created.
root@bible: ~ # cd /usr/src/linux/arch/i386/boot/
root@bible: /usr/src/linux-2.6.5-7.79/arch/i386/boot/ # ls –l bzImage
You should see a brand-new file bzImage with a timestamp showing that it has just been
created.
37_577395 ch27.qxd 12/15/04 12:28 AM Page 559
560
Part V ✦ SUSE Linux in the Enterprise
When you’ve made the bzImage, you have several more steps to perform:
1. Build the modules:
root@bible: /usr/src/linux-2.6.5-7.79/ # make modules
Note that if you simply issue the command make or make all, the bzImage and the
modules will be built in one step.
2. Install the kernel and the modules:
root@bible: /usr/src/linux-2.6.5-7.79/ # make install

This copies the bzImage file to the /boot directory. (Before you do this you may want
to back up the old kernel, particularly if it has the same version number.)
root@bible: /usr/src/linux-2.6.5-7.79/ # make modules_install
3. Create a new initial ramdisk to correspond to the new kernel:
root@bible: /usr/src/linux-2.6.5-7.79/ # mkinitrd
4. Check that both the new and old kernels are referenced in the GRUB menu so that you
can go back to the old kernel if you need to. Edit the file
/boot/grub/menu.lst to con-
firm this.
If you use LILO for booting, you need to both edit
/etc/lilo.conf to ensure that both
the new and old kernels are included and run the
lilo command.
Now, all being well, you can reboot and select the new kernel.
If you have compiled things into the kernel that were previously being loaded as mod-
ules, it is important that these modules themselves should not be loaded when the new ker-
nel is booted; otherwise, unexpected problems could occur. You may need to adjust /etc/
modprobe.conf in this case.
Rebuilding the km_* Packages
A number of packages have names beginning with km_. These packages contain source code
for additional external kernel modules that you may need to compile separately to add sup-
port for certain things. For example, the
km_ocfs package adds support for the Oracle
Cluster File System (OCFS), and the
km_smartlink-softmodem package adds support for a
certain class of “winmodems.”
You can find these packages by searching for “km_” in YaST’s software module.
To make use of these packages, you must have the source for the running kernel installed.
When you install these packages, they install the relevant source code to a directory under
/usr/src/kernel-modules/. To add support for OCFS, for example, change to the directory

/usr/src/kernel-modules/ocfs2/, and then issue the commands:
# make modules KERNEL_SOURCE=/usr/src/linux
# make install KERNEL_SOURCE=/usr/src/linux
Alternatively, you can issue this command:
# make -C /usr/src/linux SUBDIRS=$PWD modules
Caution
37_577395 ch27.qxd 12/15/04 12:28 AM Page 560
561
Chapter 27 ✦ The Kernel
This runs the make command in /usr/src/linux while referring to the current directory to
find the module code.
You will then find that the module has been built and installed as:
/lib/modules/<version-number>-default/extra/ocfs2.ko
If you install a new kernel, you will need to rebuild these modules, whether or not you build
the new kernel from source.
The kernel and third-party software
Third-party commercial software that requires low-level kernel support is sometimes run only
on or with particular kernel versions. In the worst case this is because the vendor ships
binary-only kernel modules, but even when a module source is shipped that needs to be built
against the running kernel, it can be limited to very specific kernel versions. This can be a
real problem, particularly when a kernel update is recommended by SUSE (for example, for
security reasons) and vendors are slow to respond. The problem can be worse if you are try-
ing to run two such pieces of software at the same time.
Consider the following example of this kind of problem in a production environment: A cus-
tomer needed to run a piece of proprietary software allowing multipath access to storage
area network (SAN) storage and at the same time needed to run a third-party clustering solu-
tion with kernel modules for its filesystem. Although both of these products supported the
version of SLES that the customer was running, when you looked at the small print, things
were more difficult because only one version of the kernel package among the various
updates provided by SUSE worked with both products. And that kernel version was not the

latest and had been officially superceded because of a security patch.
These problems will persist until all third-party vendors gain a better understanding of the
dynamics of Linux and realize that releasing their code in a more flexible and open way does
not necessarily prevent them from making money from their products.
When certain third-party modules load, you will see a message of the form:
Warning: loading <module file> will taint the kernel: non-GPL license -
Proprietary. [ ]
See < for information about tainted
modules
Module <module file> loaded, with warnings
This indicates that a module with a non-GPL license is being loaded into the kernel. This
warning is not simply about software ideology: When proprietary (and particularly binary-
only) modules are loaded, little can be done to debug any problems they may cause.
Kernel of the Day
The SUSE FTP server always has a so-called “kernel of the day,” which is the latest test kernel, with
versions available for each supported architecture. This is available at
/>projects/kernel/kotd/. It goes without saying that these kernels should be used only with cau-
tion because they have not been officially released and are provided for testing purposes.
37_577395 ch27.qxd 12/15/04 12:28 AM Page 561
562
Part V ✦ SUSE Linux in the Enterprise
Loading kernel modules
In the 2.6 kernel, kernel modules have filenames ending with .ko (rather than .o as in 2.4). To
check what modules are loaded:
root@bible: ~ # lsmod
Module Size Used by
nls_cp437 6016 0
vfat 14208 0
fat 43584 1 vfat
usb_storage 60096 0

nls_iso8859_1 4352 2
udf 85380 0
nls_utf8 2304 0
[ ]
Dependencies between modules are indicated in the last column of the output.
To load a module manually, you use the following:
root@bible: ~ # modprobe tulip
To unload a module, use the following:
root@bible: ~ # rmmod tulip
The automatic loading of modules is now (in 2.6 kernels) controlled by the file /etc/
modprobe.conf, which has replaced the /etc/modules.conf file.
The file
/lib/modules/<version-number>-default/modules.dep contains a listing of all
the dependencies between available modules. This file can be regenerated if necessary by the
command
depmod -a.
Kernel Parameters at Boot Time
You can pass parameters to the kernel at boot time either permanently by editing the GRUB
configuration file or temporarily by typing at the boot prompt. These control the behavior of
the kernel when it boots in various ways. Current versions of SUSE use the
showopts keyword
in the GRUB configuration file, which has the unfortunate effect of hiding the parameters that
are being passed. Actually what this keyword does is to hide the options that are listed before
it and show those that appear after it.
If you remove
showopts from the default entry line in /boot/grub/menu.lst, then at the
next boot you will see exactly which boot parameters are being passed to the kernel when it
loads. You will also be able to edit these parameters in the initial boot screen.
A list of supported parameters and their meanings are in the file:
/usr/src/linux/Documentation/kernel-parameters.txt

A few examples of parameters that you might want to pass at boot time are as follows:
✦
root=/dev/hda3 — Sets the root device
✦
vga=791 — Sets the framebuffer resolution to 1024 × 768
37_577395 ch27.qxd 12/15/04 12:28 AM Page 562
563
Chapter 27 ✦ The Kernel
See Chapter 8 for more information on framebuffer graphics and resolution.
✦ acpi=off — Disables Advanced Configuration and Power Interface (ACPI), often
required on troublesome hardware
✦
ide=nodma — Disables Direct Memory Access (DMA) access to IDE disks
✦
noapic — Does not use the APIC interrupt controller
These last three will be seen as part of the failsafe entry in /boot/grub/menu.lst
because each of them can solve common problems with particular hardware.
The Initial Ramdisk
As the system boots, it needs drivers for (for example) the disk controllers and the filesys-
tems on the hard disk; otherwise, it will not be able to mount the disks. The necessary
drivers may not be included in the kernel itself but loaded as drivers. This is not a problem
on the running system but can create a “chicken and egg” situation at boot time. This prob-
lem is solved by loading the initrd into memory at boot time. (Typically the initrd loaded is
whatever is pointed to by the symbolic link
/boot/initrd, but a different initrd can be speci-
fied if required in the GRUB menu
/boot/grub/menu.lst. The initrd is in fact a compressed
EXT2 filesystem that is decompressed and loaded into memory at initial boot time.) The ini-
trd and the kernel are loaded in the same way: either directly from known physical locations
on the boot device (in the case of LILO) or through the use of a boot loader that is capable of

reading at the filesystem “from the outside” (in the case of GRUB). The initrd is then mounted
temporarily by the kernel prior to the mounting of the disk partitions. Exactly what the initrd
includes is set in the file
/etc/sysconfig/kernel in the INITRD_MODULES variable. On a
desktop machine, this may simply look like this:
INITRD_MODULES=”reiserfs”
If you have SCSI disks, it will almost certainly need to include a driver for the disk controller.
This will normally be handled correctly during installation, but there are occasions when
you may need to change this manually. Having done so, you will need to run the command
mkinitrd to create a new initrd with the correct modules included. Once the initrd has been
created, if you reboot, the necessary support should be present.
See Chapter 4 for a description of the booting process.
Although the process described in this chapter for configuring and building a kernel from
source is an interesting one, it is probably not something you will often need to do in prac-
tice. If you are running SLES in a production environment, SUSE will probably not give you
support for a self-built kernel unless they themselves have recommended this course of
action for a specific reason.
It is, however, certainly useful to have some familiarity with the process, and it is interesting
and instructive to look around in
/usr/src/linux/, particularly in the Documentation
subdirectory.
✦✦✦
Cross-
Reference
Note
Cross-
Reference
37_577395 ch27.qxd 12/15/04 12:28 AM Page 563
37_577395 ch27.qxd 12/15/04 12:28 AM Page 564
The SUSE Linux

Standard Server
T
he SUSE Linux Standard Server was introduced by SUSE some
time after the release of SUSE Linux Enterprise Server (SLES) 8,
and it was marketed partly as an “entry-level” version of the
Enterprise Server. But its real distinguishing feature is the fact that it
can be set up to act as a “black box” server— designed to be simple
to set up and to require minimal administration after installation —
for a small business, using a simple web interface. Once correctly
configured, it happily sits in the corner and does its job without
further intervention. The web administration interface has been
designed to be easy to use and allows you to set up the server for its
intended uses without assuming that you have any particular Linux
expertise.
To quote from SUSE’s own literature:
With its comprehensive graphical administration, SUSE Linux
Standard Server was designed for small organizations and
departments that want to implement their Internet access as
well as e-mail, print, and file services in a reliable, secure way.
Standard Server is available for 32-bit processors (x86) from
AMD and Intel and supports up to two CPUs.
The Standard Server is designed to act as an Internet gateway, mail
server, Domain Name System (DNS) and Dynamic Host Configuration
Protocol (DHCP) server, proxy server, and file and print server for
Windows clients, with almost all configuration through a simple web
interface. The web interface in particular controls the addition of
users into the system, ensuring that they exist as users in the Cyrus
IMAPD mail system, are created in OpenLDAP, and have home direc-
tories created for them that are shared by Samba.
Although the Standard Server is by no means the first Linux-based

product that has tried to fill this kind of role, it does the job very
well and is a genuinely usable “small business server” that can be
installed and configured by a non-expert.
Another way of thinking of the Standard Server is that it is very
roughly SUSE Linux OpenExchange Server (SLOX) without the group-
ware; the web administration interface and the way in which users
are held in OpenLDAP are basically identical in both products. It does
not offer a webmail interface, but it is not difficult to add this func-
tionality using one of the well-known “webmail for IMAP” packages
such as
squirrelmail or imp.
28
28
CHAPTER
✦✦✦✦
In This Chapter
Introducing the
Standard Server
Relating the Standard
Server to SUSE Linux
Enterprise Server
Installing the Standard
Server
Working with the web
interface
✦✦✦✦
38_577395 ch28.qxd 12/15/04 12:30 AM Page 565
566
Part V ✦ SUSE Linux in the Enterprise
Standard Server Structure

In common with SLES 8 and the SUSE Linux OpenExchange Server (SLOX), the Standard
Server is a UnitedLinux-based product. (UnitedLinux is the core of SLES 8 and was developed
by SUSE but used by certain other vendors as a base for their products also.) These versions
all have a modular structure; they are composed of a disk set that contains three disks in
common — UnitedLinux (UL) CDs 1, 2, and 3 — and an initial install disk, which gives the par-
ticular product its personality. So SLOX CD1 and UL CDs 1, 2, and 3 are a full installation set
for SLOX, while Standard Server CD1 and UL CDs 1, 2, and 3 are a full installation set for
Standard Server. In practice, the default installation in each case can be achieved with just
the first two disks of the set.
The fact that all the packages included on the UL disks are available means that you can
choose to add a wide variety of software (beyond the default) to a Standard Server install.
The UnitedLinux consortium was a collaboration between four Linux vendors (SUSE,
TurboLinux, Connectiva, and SCO) with SUSE as the main development partner. The aim was
to produce a core Enterprise Linux distribution on top of which vendors could create their
own products. In the case of SUSE, the products created on top of the UnitedLinux base were
SLES 8, SUSE Linux OpenExchange Server, and SUSE Linux Standard Server. The UnitedLinux
consortium is no longer active, following SCO’s legal claims and actions regarding the own-
ership of Linux code.
The same modular structure exists in SUSE Linux Enterprise Server (SLES) 9: There is an ini-
tial disk to start the install (SLES CD1), and a set of other disks (CORE CDs 1–5). This allows
for a replacement of the first disk by either a replacement for update purposes, or a replace-
ment that makes the set as a whole into a different product. It remains to be seen whether a
Standard Server version based on SLES 9 will be released; at the time of this writing there has
been no announcement to that effect.
It is as yet unclear whether a version of the Standard Server based on SLES 9 will be released.
The fact that there is an easy web interface for setting it up is a major selling point for those who
sell services to the small business market. SUSE Linux Standard Server occupies roughly the
same area of the market as Microsoft’s Small Business Server, and this is a market where Linux
has not progressed as well as it might have because the small companies that service this mar-
ket often know only Microsoft solutions. The Standard Server offers these people a friendly

migration path to Linux, and we certainly hope SUSE/Novell continues to make it available.
Like SLES and SLOX, Standard Server is one of SUSE’s business products. It is obtained
through SUSE’s resellers and business partners and is not available by download. The
Standard Server is a maintained product: The price includes a year’s maintenance/upgrade
protection that allows you to get online updates (YaST Online Update) through a username
and password that are issued when you register the product.
Standard Server Installation
Installation of the Standard Server is similar to installation of any other SUSE version, but
with one or two interesting differences.
For a refresher on what’s involved in a standard SUSE Linux installation, see Chapter 1.
Cross-
Reference
Note
Note
38_577395 ch28.qxd 12/15/04 12:30 AM Page 566
567
Chapter 28 ✦ The SUSE Linux Standard Server
On some hardware, you may need to add a boot parameter similar to:
cdromdevice=hdc
in the initial screen when the installer boots. (This assumes that your CD drive will be seen
by Linux as
/dev/hdc — that is, the first device on the second IDE channel. Change this
according to your hardware.) If you do not include this parameter, it is quite likely that the
installer will fail when it gets to the point where it evaluates the software selections.
At the start of the installation, you will be asked a very general question in the Utilization
Purposes screen where you are invited to choose between Standard Installation and Basic
Installation (see Figure 28-1).
Figure 28-1: Utilization Purposes screen during the installation
✦ Standard Installation — Sets up the Standard Server for the role it was designed for
(the integrated gateway and office server scenario).

✦ Basic Installation — Gives you a normal Linux installation that you can configure in any
way you want.
When you choose Standard Installation, the correct package set is chosen for this implemen-
tation scenario. You can, of course, add extra packages to the installation.
38_577395 ch28.qxd 12/15/04 12:30 AM Page 567
568
Part V ✦ SUSE Linux in the Enterprise
From this point on, the package installation proceeds. After the end of the package installa-
tion there are a number of differences from other SUSE installations:
✦ When you set the root password (see Figure 28-2), you are not only setting the “unix”
password for root (the one that is held encrypted in
/etc/shadow), but you are also
setting the password for the
cyrus user (IMAP mail administrator), for Lightweight
Directory Access Protocol (LDAP) administration, for the user
mailadmin, and the
password used for generating Secure Sockets Layer (SSL) certificates.
Be aware that changing the root password subsequently with YaST alters only the “unix”
password.
Figure 28-2: Setting the root password during installation
Caution
38_577395 ch28.qxd 12/15/04 12:30 AM Page 568
569
Chapter 28 ✦ The SUSE Linux Standard Server
✦ In the networking setup (see Figure 28-3), you are first required to set the IP address(es)
for the network interfaces. It is possible that the Standard Server itself may be your
Internet gateway. If so, you set an external and an internal address. If at all possible,
you want your Internet access set up in such a way that you have a fixed external IP
address. Certainly if you intend to use it as a mail server for your organization with
mail being delivered directly to it, you must have a fixed IP address and appropriate

DNS MX (mail exchanger) records set up, pointing to it.
Figure 28-3: Network settings during the installation
There is one point in the networking setup that you should similarly be particularly
careful about. It is not easy to change the host name or domain name of the Standard
Server. (The reason for this is that the LDAP setup and the SSL certificates depend on
these.) You should therefore be quite sure about your plans before you set these
names.
38_577395 ch28.qxd 12/15/04 12:30 AM Page 569
570
Part V ✦ SUSE Linux in the Enterprise
You will also be asked whether the Standard Server is to be your Internet gateway and
whether it should be set up as a DNS server (see Figure 28-4).
Figure 28-4: Final network settings screen during the installation
✦ Additionally, you have to make three other settings:
• You make the settings for the Windows network: if the server should act as a
primary domain controller for the network, if you want it to join a Windows
workgroup, and the name of the workgroup. See Figure 28-5.
• You are asked if you want to set up a DHCP server. The installer determines
whether there is a DHCP server existing on the network. If there is, you should
make a decision as to whether you want to keep the existing DHCP server or
replace it with the one in the Standard Server.
• You are prompted to enter your country and organization name (see Figure 28-6).
These will be used both for the setup of the OpenLDAP server and for the cre-
ation of SSL certificates.
38_577395 ch28.qxd 12/15/04 12:30 AM Page 570
571
Chapter 28 ✦ The SUSE Linux Standard Server
Figure 28-5: Samba settings screen during the installation
Figure 28-6: Setting country and organization during the installation
38_577395 ch28.qxd 12/15/04 12:30 AM Page 571

572
Part V ✦ SUSE Linux in the Enterprise
The Web Administration Interface
When the installation is complete, the server knows where in the world it lives, what organi-
zation it is in, what its host name and domain name are, what network(s) it is on, and which
services it is going to provide to the network (DNS, DHCP, Samba). It doesn’t yet have any
information about the organization’s users or the other hosts on the network. To administer
all these things, you do not (and generally cannot) use YaST; you must use the web adminis-
tration interface. It is also important to realize that most of the administration information
you enter into the web administration interface is stored in OpenLDAP rather than written
directly to the relevant configuration files. Therefore, if you have chosen the Standard
Installation, you should configure the system through the web interface rather than by edit-
ing configuration files directly.
Each of the services that can be configured here is covered in general elsewhere in the book;
please see the relevant chapters in Part IV for background information.
It is important to realize why this is so. For example, if you were to add users by using YaST,
then they would exist on the system as “unix” users only and would not be added to
OpenLDAP or to the mail system.
To access the web administration system, you need to enter the IP address of the server in a
browser, as shown in Figure 28-7.
Figure 28-7: Standard Server login screen
Note
38_577395 ch28.qxd 12/15/04 12:30 AM Page 572
573
Chapter 28 ✦ The SUSE Linux Standard Server
In this case, we entered http://192.168.2.254/, but the system has redirected us to the
login URL. If you are able to resolve names on the network, you could of course have entered
the name instead of the IP number, and of course, you can work on the server itself using
http://localhost/. Now for many administration tasks (and in particular the addition of
users and hosts to the DNS configuration), you can log in to the web interface as user

cyrus
with the password that was set during the installation. When you have logged in, you will see
something like Figure 28-8.
Figure 28-8: Web administration interface main screen
At the top of this screen is a series of icons with descriptions. Clicking any of these produces
a new screen within the browser with a tabbed appearance.
Users and groups
The User Management screen allows you to create and edit users. To create a user, use the
New tab (see Figure 28-9).
Some things to note about this screen:
✦ It prompts you for much more information than you need to give to YaST to set up a
new user.
✦ A default password has been preset; you almost certainly want to force the user to
change the password, which is done by using the User Must Change Password check-
box. The user must then log in to the web interface for the first time with the default
password and change the password before being able to get mail or access files on the
server.
38_577395 ch28.qxd 12/15/04 12:30 AM Page 573
574
Part V ✦ SUSE Linux in the Enterprise
✦ You can add an email alias, and by default an alias in the form Firstname.Lastname@
domain.com will be created also. If you wish to give this user a mail quota different
from the default, you can also do so here. (The default setting for the mail quota is set
in the IMAP Configuration tab under Mail Server.)
✦ The Edit tab of the User Management screen gives you the opportunity to change any
of the properties of an existing user.
Figure 28-9: User management in the web administration interface
Selecting the Groups/Folders icon brings up the Groups/Folders area, which enables you to
create and edit groups. Look at the Edit Groups section first, and you can see that SUSE has
decided to set up some predefined groups by default. These are IT, administration, info, man-

agement, purchase, sales, and users. If this seems a little “hard-wired,” don’t worry; you can
delete them and replace them with group names of your choice. In the Create Groups screen,
you can create a new group and add existing users to it from a list of all users.
You will probably want to edit the groups and create suitable groups before you start adding
users; then you can ensure that each user’s “primary group” is the one you want.
Tip
38_577395 ch28.qxd 12/15/04 12:30 AM Page 574
575
Chapter 28 ✦ The SUSE Linux Standard Server
The other two tabs allow you to create and edit shared folders; these are Internet Message
Access Protocol (IMAP) folders, which can, if desired, be given a mail address. The Edit
Shared Folders tab allows you to set permissions for groups or individual users on the shared
folder (see Figure 28-10).
Figure 28-10: Setting IMAP folder permissions in the web administration interface
These constitute the standard set of permissions provided by
cyrus-imapd for IMAP mail
folders, which are described in Chapter 17. They allow the setting of very fine-grained permis-
sions for shared folders.
Mail server settings
Selecting the Mail Server icon brings up the Mail Server Settings area. Here there are five
tabs: Postfix (subtitled Basic Postfix Configuration), Postfix for Experts, IMAP Configuration,
Fetch Mail, and Alias Management.
✦ Postfix — You can set up a relay host, if you are using one; dial on demand for
machines that are not permanently online; and spam filtering. You can switch on secure
Simple Mail Transport Protocol (SMTP) and Transport Layer Security (TLS) encrypted
connections.
38_577395 ch28.qxd 12/15/04 12:30 AM Page 575
576
Part V ✦ SUSE Linux in the Enterprise
✦ Postfix for Experts — This is simply a web front end to the /etc/postfix/main.cf

configuration file — not particularly useful in itself.
✦ IMAP Configuration — Has the useful global settings for user quotas (but individual
users can have different settings) and for POP and IMAP timeouts. It also allows you to
set up a catchall destination user for undeliverable mail.
✦ Fetch Mail — Applies only if you are fetching the mail for your domain by POP3 from an
ISP’s server, rather than receiving it directly.
✦ Alias Management — Allows you to view and change mail aliases (see Figure 28-11). If
you choose the “sort by user” option, you can add an alias for an existing user. Again,
this is simply a web front end for editing the file
/etc/aliases (and running the
newaliases command).
Figure 28-11: Setting aliases in the web administration interface
38_577395 ch28.qxd 12/15/04 12:30 AM Page 576
577
Chapter 28 ✦ The SUSE Linux Standard Server
Security settings
Selecting the Security icon takes you to the Security Settings area. Here you can switch on or
off the Secure Sockets Layer (SSL) support for the web server and for the IMAP, POP3, and
OpenLDAP services. You can also enable the Standard Server as a virtual private network
(VPN) server and, if necessary, remove the SSL certificate prior to generating a new one.
Network services
Selecting the Network Services icon brings up the Manage Network Services area. This sec-
tion includes tabs to manage DNS, dynamic DNS, the Squid proxy, and printers. If you choose
to use the Standard Server as your network DHCP server, you will also find a DHCP tab on
this page.
✦ DNS Configuration — Certainly adds some real value; getting the syntax of the
bind
configuration files right if you create them from scratch is often an irritation (see
Figure 28-12).
Figure 28-12: Editing DNS settings in the web administration interface

38_577395 ch28.qxd 12/15/04 12:30 AM Page 577
578
Part V ✦ SUSE Linux in the Enterprise
Here, adding a host in the web interface (see Figure 28-13) “does the right thing” in
terms of creating the entries in the zone file and the reverse DNS file.
Figure 28-13: Adding a host to the DNS server
In fact, what happens is that the information you enter here is added to LDAP; the files
under
/var/named are autogenerated from the LDAP information.
✦ The same applies to the DHCP configuration section.— Here you can set up individual
hosts with static DCHP addresses based on their MAC addresses, or you can set up a
pool of dynamically allocated addresses. The information is actually held in LDAP and
exported to the file
/etc/dhcpd.conf.
✦ Dynamic DNS — Allows you to configure dynamic DNS for the Standard Server itself if
you are in the position of being forced to use an Internet connection without a fixed IP
number. If your Standard Server is receiving mail for your domain, you almost certainly
don’t want to do this because of the problems that can occur when your IP number
changes.
✦ Proxy — Allows you to make global settings for the Squid proxy server. The “expert set-
tings” section allows you to set access control lists (ACLs) for Squid (as described in
Chapter 25). In the main screen, if Use Web filter is checked, squidGuard will be used
(see also Chapter 25). If you intend to use squidGuard, and particularly if you are in an
environment where blocking offensive sites is expected or required, then you should
certainly download updated blacklists to
/var/squidGuard/db/ and then as root at a
shell prompt, do the following:
root@standard: ~ # squidGuard -c /etc/squid/squidguard.conf -C all
root@standard: ~ # standard:/var/squidGuard/db # rcsquid restart
38_577395 ch28.qxd 12/15/04 12:30 AM Page 578