Book Sle Admin Color en
Book Sle Admin Color en
Book Sle Admin Color en
SUSE LLC
1800 South Novell Place
Provo, UT 84606
USA
https://documentation.suse.com
Copyright © 2006– 2020 SUSE LLC and contributors. All rights reserved.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free
Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this
copyright notice and license. A copy of the license version 1.2 is included in the section entitled “GNU
Free Documentation License”.
For SUSE trademarks, see http://www.suse.com/company/legal/ . All other third party trademarks are the
property of their respective owners. A trademark symbol (®, ™ etc.) denotes a SUSE or Novell trademark;
an asterisk (*) denotes a third party trademark.
All information found in this book has been compiled with utmost attention to detail. However, this does
not guarantee complete accuracy. Neither SUSE LLC, its affiliates, the authors nor the translators shall be
held liable for possible errors or the consequences thereof.
Contents
2 Feedback xxii
4.4 Limitations 39
Data Consistency 39 • Reverting User Additions 39 • No Rollback on /
boot and Boot Loader Changes 40
iv Administration Guide
with zypper 54 • Managing Repositories with zypper 58 • Querying
Repositories and Packages with Zypper 60 • Configuring
Zypper 61 • Troubleshooting 62 • Zypper Rollback Feature on btrfs File
System 62
II SYSTEM 88
v Administration Guide
9.3 Software Compilation on Biarch Platforms 91
vi Administration Guide
12 UEFI (Unified Extensible Firmware Interface) 131
12.1 Secure Boot 131
Implementation on SUSE Linux Enterprise 132 • MOK (Machine
Owner Key) 135 • Booting a Custom Kernel 135 • Using Non-Inbox
Drivers 137 • Limitations 138
15.6 Influencing Kernel Device Event Handling with udev Rules 170
Using Operators in udev Rules 172 • Using Substitutions in udev
Rules 173 • Using udev Match Keys 174 • Using udev Assign Keys 175
ix Administration Guide
20 Power Management 222
20.1 Power Saving Functions 222
IV SERVICES 238
x Administration Guide
22.3 Name Resolution 255
xi Administration Guide
24.3 Dynamic Time Synchronization at Runtime 309
26 DHCP 335
26.1 Configuring a DHCP Server with YaST 336
Initial Configuration (Wizard) 336 • DHCP Server Configuration (Expert) 341
28 Samba 368
28.1 Terminology 368
xv Administration Guide
33 The Squid Proxy Server 450
33.1 Some Facts about Proxy Caches 450
Squid and Security 451 • Multiple Caches 451 • Caching Internet
Objects 452
V TROUBLESHOOTING 499
This guide is intended for use by professional network and system administrators during the
operation of SUSE® Linux Enterprise. As such, it is solely concerned with ensuring that SUSE
Linux Enterprise is properly configured and that the required services on the network are avail-
able to allow it to function properly as initially installed. This guide does not cover the process
of ensuring that SUSE Linux Enterprise offers proper compatibility with your enterprise's appli-
cation software or that its core functionality meets those requirements. It assumes that a full
requirements audit has been done and the installation has been requested or that a test instal-
lation, for the purpose of such an audit, has been requested.
This guide contains the following:
System
Learn more about the underlying operating system by studying this part. SUSE Linux En-
terprise supports a number of hardware architectures and you can use this to adapt your
own applications to run on SUSE Linux Enterprise. The boot loader and boot procedure
information assists you in understanding how your Linux system works and how your own
custom scripts and applications may blend in with it.
Mobile Computers
Laptops, and the communication between mobile devices like PDAs, or cellular phones
and SUSE Linux Enterprise need some special attention. Take care for power conservation
and for the integration of different devices into a changing network environment. Also get
in touch with the background technologies that provide the needed functionality.
Services
SUSE Linux Enterprise is designed to be a network operating system. It offers a wide range
of network services, such as DNS, DHCP, Web, proxy, and authentication services, and in-
tegrates well into heterogeneous environments including MS Windows clients and servers.
Troubleshooting
Many chapters in this manual contain links to additional documentation resources. This includes
additional documentation that is available on the system as well as documentation available
on the Internet.
For an overview of the documentation available for your product and the latest documentation
updates, refer to http://www.suse.com/doc .
1 Available Documentation
We provide HTML and PDF versions of our books in different languages. The following manuals
for users and administrators are available for this product:
Administration Guide
Covers system administration tasks like maintaining, monitoring, and customizing an ini-
tially installed system.
Book “AutoYaST”
AutoYaST is a system for installing one or more SUSE Linux Enterprise systems automati-
cally and without user intervention, using an AutoYaST profile that contains installation
and configuration data. The manual guides you through the basic steps of auto-installation:
preparation, installation, and configuration.
In addition to the comprehensive manuals, several quick start guides are available:
Find HTML versions of most product manuals in your installed system under /usr/share/doc/
manual or in the help centers of your desktop. Find the latest documentation updates at http://
www.suse.com/doc where you can download PDF or HTML versions of the manuals for your
product.
2 Feedback
Several feedback channels are available:
User Comments
We want to hear your comments about and suggestions for this manual and the other
documentation included with this product. Use the User Comments feature at the bottom of
each page in the online documentation or go to http://www.suse.com/doc/feedback.html
and enter your comments there.
Mail
For feedback on the documentation of this product, you can also send a mail to doc-
team@suse.de . Make sure to include the document title, the product version, and the
publication date of the documentation. To report errors or suggest enhancements, provide
a concise description of the problem and refer to the respective section number and page
(or URL).
3 Documentation Conventions
The following typographical conventions are used in this manual:
Alt , Alt – F1 : a key to press or a key combination; keys are shown in uppercase as on
a keyboard
amd64, em64t, ipf This paragraph is only relevant for the architectures amd64 , em64t ,
and ipf . The arrows mark the beginning and the end of the text block.
IBM Z, ipseries This paragraph is only relevant for the architectures System z and
ipseries . The arrows mark the beginning and the end of the text block.
Novell offers a continuous stream of software security updates for your product. By default, the
update applet is used to keep your system up-to-date. Refer to Book “Deployment Guide”, Chapter 9
“Installing or Removing Software”, Section 9.4 “Keeping the System Up-to-date” for further information
on the update applet. This chapter covers the alternative tool for updating software packages:
YaST Online Update.
The current patches for SUSE® Linux Enterprise Server are available from an update software
repository. If you have registered your product during the installation, an update repository is al-
ready configured. If you have not registered SUSE Linux Enterprise Server, you can do so by run-
ning Software Online Update Configuration in YaST and start Advanced Register for Support and
Get Update Repository. Alternatively, you can manually add an update repository from a source
you trust. To add or remove repositories, start the Repository Manager with Software Software
Repositories in YaST. Learn more about the Repository Manager in Book “Deployment Guide”,
Chapter 9 “Installing or Removing Software”, Section 9.3 “Managing Software Repositories and Services”.
Security Updates
Fix severe security hazards and should definitely be installed.
Recommended Updates
Fix issues that could compromise your computer.
Optional Updates
Fix non-security relevant issues or provide enhancements.
The Summary section on the left lists the available patches for SUSE Linux Enterprise Server.
The patches are sorted by security relevance: security , recommended , and optional . You
can change the view of the Summary section by selecting one of the following options from Show
Patch Category:
Unneeded Patches
Patches that either apply to packages not installed on your system, or patches that have
requirements which have already have been fulfilled (because the relevant packages have
already been updated from another source).
Each list entry in the Summary section consists of a symbol and the patch name. For an overview
of the possible symbols and their meaning, press Shift – F1 . Actions required by Security
and Recommended patches are automatically preset. These actions are Autoinstall, Autoupdate
and Autodelete.
If you install an up-to-date package from a repository other than the update repository, the
requirements of a patch for this package may be fulfilled with this installation. In this case a
check mark is displayed in front of the patch summary. The patch will be visible in the list until
you mark it for installation. This will in fact not install the patch (because the package already
is up-to-date), but mark the patch as having been installed.
Select an entry in the Summary section to view a short Patch Description at the bottom left corner
of the dialog. The upper right section lists the packages included in the selected patch (a patch
can consist of several packages). Click an entry in the upper right section to view details about
the respective package that is included in the patch.
The upper right section lists the available (or already installed) patches for SUSE Linux Enter-
prise Server. To filter patches according to their security relevance, click the corresponding Pri-
ority entry in the upper right section of the window: Security , Recommended , Optional or
All patches .
If all available patches are already installed, the Package listing in the upper right section will
show no entries. The box in the bottom left-hand section shows the number of both available
and already installed patches and lets you toggle the view to either Available or Installed patches.
Select an entry in the Package listing section to view a patch description and further details at the
bottom right corner of the dialog. As a patch can consist of several packages, click the Applies
to entry in the lower right section to see which packages are included in the respective patch.
Click on a patch entry to open a row with detailed information about the patch in the bottom
of the window. Here you can see a detailed patch description as well as the versions available.
You can also choose to Install optional patches—security and recommended patches are already
preselected for installation.
2. To automatically apply all new patches (except optional ones) that are currently avail-
able for your system, proceed with Apply or Accept to start the installation of the prese-
lected patches.
a. Use the respective filters and views the GTK and Qt interfaces provide. For details,
refer to Section 1.1.1, “KDE Interface (Qt)” and Section 1.1.2, “GNOME Interface (GTK)”.
b. Select or deselect patches according to your needs and wishes by activating or deac-
tivating the respective check box (GNOME) or by right-clicking the patch and choos-
ing the respective action from the context menu (KDE).
c. Most patches include updates for several packages. If you want to change actions
for single packages, right-click a package in the package view and choose an action
(KDE).
d. To confirm your selection and apply the selected patches, proceed with Apply or
Accept.
4. After the installation is complete, click Finish to leave the YaST Online Update. Your system
is now up-to-date.
1. After installation, start YaST and select Software Online Update Configuration.
Alternatively, start the module with yast2 online_update_configuration from the
command line.
4. Select if you want to Skip Interactive Patches in case you want the update procedure to
proceed fully automatically.
In case of problems, a detailed system report may be created with either the sup-
portconfig command line tool or the YaST Support module. Both will collect in-
formation about the system such as: current kernel version, hardware, installed
packages, partition setup and much more. The result is a TAR archive of les. After
opening a Service Request (SR), you can upload the TAR archive to Global Techni-
cal Support. It will help to locate the issue you reported and to assist you in solving
the problem.
The command line tool is provided by the package supportutils which is in-
stalled by default. The YaST Support module is based on the command line tool.
US customers: ftp://ftp.novell.com/incoming
Alternatively, you can manually attach the TAR archive to your service request using the service
request URL: http://www.novell.com/center/eservice .
5. If you want to submit the archive to Global Technical Support at the end of the information
collection process, Upload Information is required. YaST automatically proposes an upload
server. If you want to modify it, refer to Section 2.1.2, “Upload Targets” for details of which
upload servers are available.
If you want to submit the archive later on, you can leave the Upload Information empty
for now.
8. Review the data collection: Select the File Name of a log le to view its contents in YaST. To
remove any les you want excluded from the TAR archive before submitting it to support,
use Remove from Data. Continue with Next.
9. Save the TAR archive. If you started the YaST module as root user, by default YaST
proposes to save the archive to /var/log (otherwise, to your home directory). The le
name format is nts_HOST_DATE_TIME.tbz .
10. If you want to upload the archive to support directly, make sure Upload log les tarball to
URL is activated. The Upload Target shown here is the one that YaST proposes in Step 5. If
you want to modify the upload target, nd detailed information of which upload servers
are available in Section 2.1.2, “Upload Targets”.
11. If you want to skip the upload, deactivate Upload log les tarball to URL.
2. Run supportconfig without any options. This gathers the default system information.
4. The default archive location is /var/log , with the le name format being
nts_HOST_DATE_TIME.tbz
12 Creating a Supportconfig Archive from Command Line SUSE Linux Enterp… 11 SP4
Use the minimal option ( -m ):
supportconfig -m
supportconfig -i LVM
For a complete list of feature keywords that you can use for limiting the collected infor-
mation to a specific area, run
supportconfig -F
supportconfig -l
This is especially useful in high logging environments or after a Kernel crash when syslog
rotates the log les after a reboot.
The following examples use 12345678901 as a placeholder for your service request number.
Replace 12345678901 with the service request number you created in Section 2.1.1, “Creating a
Service Request Number”.
The following procedure assumes that you have already created a supportconfig archive,
but have not uploaded it yet. Make sure to have included your contact information in
the archive as described in Section 2.1.3, “Creating a Supportconfig Archive with YaST”, Step 4.
For instructions on how to generate and submit a supportconfig archive in one go, see
Section 2.1.3, “Creating a Supportconfig Archive with YaST”.
2. Click Upload.
3. In Package with log les specify the path to the existing supportconfig archive or Browse
for it.
4. YaST automatically proposes an upload server. If you want to modify it, refer to Sec-
tion 2.1.2, “Upload Targets” for details of which upload servers are available.
5. Click Finish.
The following procedure assumes that you have already created a supportconfig archive,
but have not uploaded it yet. For instructions on how to generate and submit a support-
config archive in one go, see Section 2.1.3, “Creating a Supportconfig Archive with YaST”.
supportconfig -r 12345678901
3. After the TAR archive is in the incoming directory of our FTP server, it becomes automat-
ically attached to your service request.
Kernel modules supported by SUSE partners and delivered using SUSE SolidDriver Pro-
gram are marked “external”.
Kernel modules not provided under a license compatible to the license of the Linux Ker-
nel will also taint the Kernel. For details, see /usr/src/linux/Documentation/sysctl/
kernel.txt and the state of /proc/sys/kernel/tainted .
modprobe : The modprobe utility for checking module dependencies and loading modules
appropriately checks for the value of the supported ag. If the value is “yes” or “external”
the module will be loaded, otherwise it will not. For information on how to override this
behavior, see Section 2.3.2, “Working with Unsupported Modules”.
Note
SUSE does not generally support the removal of storage modules via modprobe -r .
During installation, unsupported modules may be added through driver update disks, and
they will be loaded. To enforce loading of unsupported modules during boot and after-
ward, use the Kernel command line option oem-modules . While installing and initializ-
ing the module-init-tools package, the Kernel ag TAINT_NO_SUPPORT ( /proc/sys/
kernel/tainted ) will be evaluated. If the Kernel is already tainted, allow_unsupport-
ed_modules will be enabled. This will prevent unsupported modules from failing in the
system being installed. If no unsupported modules are present during installation and the
other special Kernel command line option ( oem-modules=1 ) is not used, the default still
is to disallow unsupported modules.
Remember that loading and running unsupported modules will make the Kernel and the whole
system unsupported by SUSE.
http://www.suse.com/communities/conversations/basic-server-health-check-
supportconfig/ —A Basic Server Health Check with Supportconfig.
https://www.novell.com/communities/coolsolutions/cool_tools/create-your-own-
supportconfig-plugin/ —Create Your Own Supportconfig Plugin.
http://www.suse.com/communities/conversations/creating-a-
central-supportconfig-repository/ —Creating a Central Supportconfig Repository.
This section is intended for system administrators and experts who do not run an X server on
their systems and depend on the text-based installation tool. It provides basic information about
starting and operating YaST in text mode.
YaST in text mode uses the ncurses library to provide an easy pseudo-graphical user interface.
The ncurses library is installed by default. The minimum supported size of the terminal emulator
in which to run YaST is 80x25 characters.
When you start YaST in text mode, the YaST Control Center appears (see Figure 3.1). The main
window consists of three areas. The left frame features the categories to which the various
modules belong. This frame is active when YaST is started and therefore it is marked by a bold
white border. The active category is highlighted. The right frame provides an overview of the
modules available in the active category. The bottom frame contains the buttons for Help and
Quit.
Function Keys
The F keys ( F1 through F12 ) enable quick access to the various buttons. Available F
key shortcuts are shown in the bottom line of the YaST screen. Which function keys are
actually mapped to which buttons depend on the active YaST module, because the different
modules offer different buttons (Details, Info, Add, Delete, etc.). Use F10 for Accept, OK,
Next, and Finish. Press F1 to access the YaST help.
Alt shortcuts can be executed with Esc instead of Alt . For example, Esc – H replaces
Alt – H . (First press Esc , then press H .)
yast -h
To save time, the individual YaST modules can be started directly. To start a module, enter:
yast <module_name>
View a list of all module names available on your system with yast -l or yast --list . Start
the network module, for example, with yast lan .
yast -i <package_name>
or
package_name can be a single short package name, for example gvim , which is installed with
dependency checking, or the full path to an rpm package, which is installed without dependency
checking.
If you need a command-line based software management utility with functionality beyond what
YaST provides, consider using zypper. This new utility uses the same software management
library that is also the foundation for the YaST package manager. The basic usage of Zypper is
covered in Section 6.1, “Using Zypper”.
If a module does not provide command line support, the module is started in text mode and
the following message appears:
This YaST module does not support the command line interface.
22 Installing Packages from the Command Line SUSE Linux Enterp… 11 SP4
4 Snapshots/Rollback with Snapper
Being able to do le system snapshots providing the ability to do rollbacks on Linux
is a feature that was often requested in the past. Snapper, in conjunction with the
Btrfs le system or thin-provisioned LVM volumes now lls that gap.
Btrfs , a new copy-on-write le system for Linux, supports le system snapshots (a
copy of the state of a subvolume at a certain point of time) of subvolumes (one or
more separately mountable le systems within each physical partition). Snapper lets
you manage these snapshots. Snapper comes with a command line and a YaST inter-
face.
By default Snapper and Btrfs on SUSE Linux Enterprise Server are set up to serve
as an “undo tool” for system changes made with YaST and zypper. Before and af-
ter running a YaST module or zypper, a snapshot is created. Snapper lets you com-
pare the two snapshots and provides means to revert the differences between the
two snapshots. The tools also provide system backups by creating hourly snapshots
of the system subvolumes.
4.1 Requirements
Since Btrfs is the only le system on SUSE Linux Enterprise Server supporting snapshots, it is
required on all partitions or subvolumes you want to “snapshot”.
As a result, partitions containing snapshots need to be larger than “normal” partitions. The
exact amount strongly depends on the number of snapshots you keep and the amount of data
modifications. As a rule of thumb you should consider using twice the size than you normally
would.
Snapper can also be used to create and manage snapshots on thin-provisioned LVM volumes
formatted with ext3 or XFS (see Section 4.6, “Using Snapper on Thin-Provisioned LVM Volumes”).
Important: Limitations
Make sure you know about Snapper's limitations before attempting to use its rollback
mechanism. See Section 4.4, “Limitations” for details.
1. Start the Snapper module from the Miscellaneous section in YaST or by entering yast2
snapper .
3. Choose a pair of pre- and post-snapshots from the list. Both, YaST and Zypper snapshot
pairs are of the type Pre & Post. YaST snapshots are labeled as yast module_name in the
Description column; Zypper snapshots are labeled zypp (zypper) .
4. Click Show Changes to open the list of les that differ between the two snapshots. The fol-
lowing image shows a list of les that have changed after having added the user tester .
6. To restore a set of les, select the relevant les or directories by ticking the respective
check box. Click Restore Selected and confirm the action by clicking Yes.
1. Get a list of YaST and Zypper snapshots by running snapper list -t pre-post . YaST
snapshots are labeled as yast module_name in the Description column; Zypper snapshots
are labeled zypp (zypper) .
2. Get a list of changed les for a snapshot pair with snapper status PRE .. POST . Files
with content changes are marked with c, les that have been added are marked with +
and deleted les are marked with -. The following example shows a snapshot pair for the
installation of the package ncftp .
3. To display the di for a certain le, run snapper diff PRE .. POST FILENAME . If you do
not specify FILENAME , a di for all les will be displayed.
4. To restore one or more les run snapper -v undochange PRE .. POST FILENAMES . If you
do not specify a FILENAMES , all changed les will be restored.
30 Using Snapper to Restore Files from Hourly Backups SUSE Linux Enterp… 11 SP4
4.2.3 Creating and Modifying Snapper Configurations
The way Snapper behaves is defined in a config le that is specific for each partition or Btrfs
subvolume. These config les reside under /etc/snapper/configs/ . The default config in-
stalled with Snapper for the / directory is named root . It creates and manages the YaST and
Zypper snapshots as well as the hourly backup snapshot for / .
You may create your own configurations for other partitions formatted with Btrfs or existing
subvolumes on a Btrfs partition. In the following example we will set up a Snapper configu-
ration for backing up the Web server data residing on a separate, Btrfs -formatted partition
mounted at /srv/www .
You can use either snapper itself or the YaST Snapper module to restore les from these snap-
shots. In YaST you need to select your Current Configuration, while you need to specify your
config for snapper with the global switch -c (e.g. snapper -c myconfig list).
To create a new Snapper configuration, run snapper create-config :
SUBVOLUME
FSTYPE
File system type of the partition. Do not change.
NUMBER_CLEANUP
Defines whether to automatically delete old snapshots when the total snapshot count ex-
ceeds a number specified with NUMBER_LIMIT and an age specified with NUMBER_MIN_AGE .
Valid values: yes , no
NUMBER_LIMIT
Defines how many snapshots to keep if NUMBER_CLEANUP is set to yes .
NUMBER_MIN_AGE
Defines the minimum age in seconds a snapshot must have before it can automatically
be deleted.
TIMELINE_CREATE
If set to yes , hourly snapshots are created.This is currently the only way to automatically
create snapshots, therefore setting it to yes is strongly recommended. Valid values: yes ,
no
TIMELINE_CLEANUP
Defines whether to automatically delete old snapshots when the snapshot count ex-
ceeds a number specified with the TIMELINE_LIMIT_* options and an age specified with
TIMELINE_MIN_AGE . Valid values: yes , no
TIMELINE_MIN_AGE
Defines the minimum age in seconds a snapshot must have before it can automatically
be deleted.
TIMELINE_CREATE="yes"
TIMELINE_CLEANUP="yes"
TIMELINE_MIN_AGE="1800"
TIMELINE_LIMIT_HOURLY="10"
TIMELINE_LIMIT_DAILY="10"
TIMELINE_LIMIT_MONTHLY="10"
TIMELINE_LIMIT_YEARLY="10"
This example configuration enables hourly snapshots which are automatically cleaned up.
TIMELINE_MIN_AGE and TIMELINE_LIMIT_* are always evaluated both. In this example,
the minimum age of a snapshot, before it can be deleted is set to 30 minutes (1800 seconds).
Since we create hourly snapshots, this ensures that only the latest snapshots are kept. If
TIMELINE_LIMIT_DAILY is set to not zero, this means that the rst snapshot of the day
is kept, too.
SNAPSHOTS TO BE KEPT
Daily: The rst daily snapshot that has been made is kept for the last ten days.
Monthly: The rst snapshot made on the last day of the month is kept for the last
ten months.
Yearly: The rst snapshot made on the last day of the year is kept for the last ten years.
For these purposes Snapper configurations that grant permissions to users or/and groups can
be created. In addition to this configuration change, the corresponding .snapshots directory
needs to be readable and accessible by the specified users.
1. If not existing, create a Snapper configuration for the partition or subvolume on which the
user should be able to use Snapper. Refer to Section 4.2.3, “Creating and Modifying Snapper
Configurations” for instructions. Example:
3. Set values for ALLOW_USERS and/or ALLOW_GROUPS to grant permissions to users and/or
groups, respectively. Multiple entries need to be separated by Space . To grant permissions
to the user www_admin for example, enter:
ALLOW_USERS="www_admin"
4. Grant read and access permissions on the snapshot directory PATH /.snapshots. PATH is to
be replaced by the subvolume you specified in the rst step of this procedure. Example:
The given Snapper configuration can now be used by the specified user(s) and/or group(s).
You can test it with the list command, for example:
TIMELINE_CREATE="no"
USE_SNAPPER="no"
Type: Snapshot type, see Section 4.3.1.1, “Snapshot Types” for details. This data cannot be
changed.
Pre Number: Specifies the number of the corresponding pre snapshot. For snapshots of
type post only. This data cannot be changed.
Snapper knows three different types of snapshots: pre, post, and single. Physically they do not
differ, but Snapper handles them differently.
pre
Snapshot of a le system before a modification. Each pre snapshot has got a corresponding
post snapshot. Used e.g. for the automatic YaST/zypper snapshots.
post
Snapshot of a le system after a modification. Each post snapshot has got a corresponding
pre snapshot. Used e.g. for the automatic YaST/zypper snapshots.
single
Stand-alone snapshot. Used e.g. for the automatic hourly snapshots. This is the default
type when creating snapshots.
4.3.1.2 Cleanup-algorithms
Snapper provides three algorithms to clean up old snapshots. The algorithms are executed in
a daily cron-job. The cleanup-frequency itself is defined in the Snapper configuration for the
partition or subvolume (see Section 4.2.3.1, “Adjusting the Config File” for details).
number
Deletes old snapshots when a certain snapshot count is reached.
time line
Deletes old snapshots having passed a certain age, but keeps a number of hourly, daily,
monthly, and yearly snapshots.
empty-pre-post
Deletes pre/post snapshot pairs with empty dis.
snapper create --type pre --print-number --description "Before the Apache config
cleanup"
Creates a snapshot of the type pre and prints the snapshot number. First command needed
to create a pair of snapshots used to save a “before” and “after” state.
snapper create --type post --pre-number 30 --description "After the Apache con-
fig cleanup"
Creates a snapshot of the type post paired with the pre snapshot number 30 . Second
command needed to create a pair of snapshots used to save a “before” and “after” state.
snapper delete 65
Deletes snapshot 65 for the default ( root ) configuration.
Snapshots are also automatically deleted by a daily cron-job. Refer to Section 4.3.1.2, “Cleanup-
algorithms” for details.
4.4 Limitations
Although being ready for production, Btrfs as well as Snapper are constantly developed fur-
ther. The following limitations exist at the moment. It is planned to solve these issues in future
releases.
/opt
/srv
/tmp
/var/crash
/var/log
/var/run
/var/spool
/var/tmp
40 No Rollback on /boot and Boot Loader Changes SUSE Linux Enterp… 11 SP4
Can I Boot a Snapshot from the Boot Loader?
This is currently not possible. The boot loader on SUSE Linux Enterprise Server currently
does not support booting from a Btrfs partition.
In order to use Snapper on a thin-provisioned LVM volume you need to create a Snapper configu-
ration for it. On LVM it is required to specify the le system with --fstype=lvm(FILESYSTEM) .
To date ext3 and XFS are supported, so ext3 or xfs are valid values for FILESYSTEM . Example:
You can adjust this configuration according to your needs as described in Section 4.2.3.1, “Adjusting
the Config File”. Now you can use Snapper to create and manage snapshots, to restore les, and
undo changes as described above.
Virtual Network Computing (VNC) enables you to control a remote computer via a
graphical desktop (as opposed to a remote shell access). VNC is platform-indepen-
dent and lets you access the remote machine from any operating system.
SUSE Linux Enterprise Server supports two different kinds of VNC sessions: One-
time sessions that “live” as long as the VNC connection from the client is kept up,
and persistent sessions that “live” until they are explicitly terminated.
3. If necessary, also check Open Port in Firewall (for example, when your network interface
is configured to be in the External Zone). If you have more than one network interface,
restrict opening the firewall ports to a specific interface via Firewall Details.
5. In case not all needed packages are available yet, you need to approve the installation
of missing packages.
VNC display numbers and X display numbers are independent in one-time sessions. A VNC
display number is manually assigned to every configuration that the server supports (:1 in
the example above). Whenever a VNC session is initiated with one of the configurations,
it automatically gets a free X display number.
vncviewer jupiter.example.com:1
Instead of the VNC display number you can also specify the port number with two colons:
vncviewer jupiter.example.com::5901
Alternatively use a Java-capable Web browser to view the VNC session by entering the following
URL: http://jupiter.example.com:5801
rcxinetd reload
1. Open a shell and make sure you are logged in as the user that should own the VNC session.
2. If the network interface serving the VNC sessions is protected by a firewall, you need to
manually open the port used by your session in the firewall. If starting multiple sessions
you may alternatively open a range of ports. See Book “Security Guide”, Chapter 15 “Mas-
querading and Firewalls” for details on how to configure the firewall.
vncserver uses the ports 5901 for display :1 , 5902 for display :2 , and so on. For
persistent sessions, the VNC display and the X display usually have the same number.
3. To start a session with a resolution of 1024x769 pixel and with a color depth of 16-bit,
enter the following command:
The vncserver command picks an unused display number when none is given and prints
out its choice. See man 1 vncserver for more options.
When running vncviewer for the rst time, it asks for a password for full access to the session.
If needed, you can also provide a password for view-only access to the session.
The password(s) you are providing here are also used for future sessions started by the same
user. They can be changed with the vncpasswd command.
To terminate the session shut down the desktop environment that runs inside the VNC session
from the VNC viewer as you would shut it down if it was a regular local X session.
vncviewer jupiter.example.com:1
Instead of the VNC display number you can also specify the port number with two colons:
vncviewer jupiter.example.com::5901
Alternatively use a Java-capable Web browser to view the VNC session by entering the following
URL: http://jupiter.example.com:5801
/usr/bin/gnome # GNOME
/usr/bin/startkde # KDE
This chapter describes Zypper and RPM, two command line tools for managing soft-
ware. For a definition of the terminology used in this context (for example, repos-
itory , patch , or update ) refer to Book “Deployment Guide”, Chapter 9 “Installing or
Removing Software”, Section 9.1 “Definition of Terms”.
The components enclosed in brackets are not required. The simplest way to execute Zypper
is to type its name, followed by a command. For example, to apply all needed patches to the
system type:
zypper patch
Additionally, you can choose from one or more global options by typing them just before the
command. For example, --non-interactive means running the command without asking any-
thing (automatically applying the default answers):
To use the options specific to a particular command, type them right after the command. For ex-
ample, --auto-agree-with-licenses means applying all needed patches to the system with-
out asking to confirm any licenses (they will automatically be accepted):
Some options also require an argument. The following command will list all known patterns:
You can combine all of the above. For example, the following command will install the mplayer
and amarok packages from the factory repository while being verbose:
The --from option makes sure to keep all repositories enabled (for solving any dependencies)
while requesting the package from the specified repository.
Most Zypper commands have a dry-run option that does a simulation of the given command.
It can be used for test purposes.
Zypper supports the global --userdata string option for transaction identification purpos-
es. The user-defined string is passed to Zypper history logs in /var/log/zypp/history and
Snapper.
Zypper knows various ways to address packages for the install and remove commands:
or
48 Installing and Removing Software with Zypper SUSE Linux Enterp… 11 SP4
zypper install MozillaFirefox-3.5.3
by capability
For example, if you would like to install a perl module without knowing the name of the
package, capabilities come in handy:
To install and remove packages simultaneously use the +/- modifiers. To install emacs and
remove vim simultaneously, use:
49 Installing and Removing Software with Zypper SUSE Linux Enterp… 11 SP4
To prevent the package name starting with the - being interpreted as a command option, always
use it as the second argument. If this is not possible, precede it with -- :
If (together with a certain package) you automatically want to remove any packages that become
unneeded after removing the specified package, use the --clean-deps option:
rm package_name --clean-deps
By default, Zypper asks for a confirmation before installing or removing a selected package, or
when a problem occurs. You can override this behavior using the --non-interactive option.
This option must be given before the actual command ( install , remove , and patch ) as in
the following:
This option allows the use of Zypper in scripts and cron jobs.
That command will also install the build dependencies of the specified package. If you do not
want this, add the switch -D . To install only the build dependencies use -d .
50 Installing and Removing Software with Zypper SUSE Linux Enterp… 11 SP4
Of course, this will only work if you have the repository with the source packages enabled in your
repository list (it is added by default, but not enabled). See Section 6.1.5, “Managing Repositories
with zypper” for details on repository management.
A list of all source packages available in your repositories can be obtained with:
You can also download source packages for all installed packages to a local directory. To down-
load source packages, use:
zypper source-download
6.1.2.2 Utilities
To verify whether all dependencies are still fulfilled and to repair missing dependencies, use:
zypper verify
In addition to dependencies that must be fulfilled, some packages “recommend” other packages.
These recommended packages are only installed if actually available and installable. In case
recommended packages were made available after the recommending package has been installed
(by adding additional packages or hardware), use the following command:
zypper install-new-recommends
This command is very useful after plugging in a webcam or WLAN device. It will install drivers
for the device and related software, if available. Drivers and related software are only installable
if certain hardware dependencies are fulfilled.
zypper patch
In this case, all patches available in your repositories are checked for relevance and installed,
if necessary. After registering your SUSE Linux Enterprise Server installation, an official update
repository containing such patches will be added to your system. The above command is all you
must enter in order to apply them when needed.
Zypper knows three different commands to query for the availability of patches:
zypper patch-check
Lists the number of needed patches (patches, that apply to your system but are not yet
installed)
~ # zypper patch-check
Loading repository data...
Reading installed packages...
5 patches needed (1 security patch)
zypper list-patches
Lists all needed patches (patches, that apply to your system but are not yet installed)
~ # zypper list-patches
Loading repository data...
Reading installed packages...
zypper patches
Lists all patches available for SUSE Linux Enterprise Server, regardless of whether they are
already installed or apply to your installation.
It is also possible to list and install patches relevant to specific issues. To list specific patches,
use the zypper list-patches command with the following options:
--bugzilla[=number]
Lists all needed patches for Bugzilla issues. Optionally, you can specify a bug number if
you only want to list patches for this specific bug.
--cve[=number]
To install a patch for a specific Bugzilla or CVE issue, use the following commands:
or
For example, to install a security patch with the CVE number CVE-2010-2713 , execute:
zypper update
To update individual packages, specify the package with either the update or install command:
A list of all new installable packages can be obtained with the command:
zypper list-updates
Note that this command only packages lists packages that match the following criteria:
is provided by repositories with at least the same priority than the already installed pack-
age,
A list of all new available packages (regardless whether installable or not) can be obtained with:
no vendor changes
no architecture changes
no downgrades
keep installed packages
When executing zypper dist-upgrade , all packages will be installed from the reposito-
ries currently enabled. This rule is enforced, so packages might change vendor or archi-
tecture or even might get downgraded. All packages that have unfulfilled dependencies
after the upgrade will be uninstalled.
With the zypper command line utility you can upgrade to the next version of the distribution.
Most importantly, you can initiate the system upgrade process from within the running system.
Close as many applications and unneeded services as possible and log out all regular users.
Disable third party repositories before starting the upgrade, or lower the priority of these
repositories to make sure packages from the default system repositories will get preference.
Enable them again after the upgrade and edit their version string to match the version
number of the distribution of the upgraded now running system.
Make sure to have the system registered. f this is not done already, it can either be regis-
tered by using the Novell Customer Center Configuration module in YaST or by using the
suse_register commandline tool. This will add update sources to the system.
zypper ref -s
zypper up -t patch
SUSE_SLES-SP3-migration
sle-sdk-SP3-migration
suse_register -d 2 -L /root/.suse_register.log
zypper ref -s
6. Check the repositories using zypper lr . If needed, disable the SP1/SP2 Pool/Core/Up-
dates repositories manually and enable the new SP3 ( SP3-Pool , SP3-Updates ) repos-
itories:
7. Perform a dist upgrade by using the following command (example for SLES, adjust catalog
names in case SLED is updated):
You can add more catalogs here if needed, for example, in case addon products are in-
stalled. Zypper will report that it will delete the migration product and update the main
products. Confirm the message to continue updating the rpm packages.
suse_register -d 2 -L /root/.suse_register.log
shutdown -r
zypper repos
When specifying repositories in various commands, an alias, URI or repository number from
the zypper repos command output can be used. A repository alias is a short version of the
repository name for use in repository handling commands. Note that the repository numbers
can change after modifying the list of repositories. The alias will never change by itself.
By default, details such as the URI or the priority of the repository are not displayed. Use the
following command to list all details:
zypper repos -d
Sometimes, the list contains a large number of repositories that are not enabled, which might
be confusing. To only show enabled repositories, use the following command:
zypper repos -E
Always make sure that the GPG check output is set to “Yes”. If set to “No” your system
can possibly be compromised by, for example, package downgrades that re-introduce
previously xed vulnerabilities. It is recommended not to trust repositories where this
option is set to “No”. In case you are sure that the GPG check was disabled by mistake, re-
enable the option by adding the following line to the respective repository configuration
le in /etc/zypp/repos.d :
gpgcheck=1
If you want to remove a repository from the list, use the command zypper removerepo to-
gether with the alias or number of the repository you want to delete. For example, to remove
the repository listed as third entry in Example 6.1, “Zypper—List of Known Repositories”, use the
following command:
zypper removerepo 3
Enable or disable repositories with zypper modifyrepo . You can also alter the repository's
properties (such as refreshing behavior, name or priority) with this command. The following
command will enable the repository named updates , turn on auto-refresh and set its priority
to 20:
Modifying repositories is not limited to a single repository—you can also operate on groups:
-a : all repositories
-l : local repositories
-t : remote repositories
-m TYPE : repositories of a certain type (where TYPE can be one of the following: http , https ,
ftp , cd , dvd , dir , file , cifs , smb , nfs , hd , iso )
To rename a repository alias, use the renamerepo command. The following example changes
the alias from Mozilla Firefox to just firefox :
zypper products
zypper patterns
60 Querying Repositories and Packages with Zypper SUSE Linux Enterp… 11 SP4
zypper packages
zypper patches
To query all repositories for certain packages, use search . It works on package names, or,
optionally, on package summaries and descriptions. Using the wild cards * and ? with the
search term is allowed. By default, the search is not case-sensitive.
To search for packages which provide a special capability, use the command what-provides .
For example, if you would like to know which package provides the perl module SVN::Core ,
use the following command:
To query single packages, use info with an exact package name as an argument. It displays
detailed information about a package. To also show what is required/recommended by the
package, use the options --requires and --recommends :
zypper refresh
This forces a complete refresh and rebuild of the database, including a forced download of raw
metadata.
RPM packages have a GPG signature. To verify the signature of an RPM package, use the com-
mand rpm --checksig package -1.2.3.rpm to determine whether the package originates from
Novell/SUSE or from another trustworthy facility. This is especially recommended for update
packages from the Internet.
Normally, the installation of an RPM archive is quite simple: rpm -i package .rpm. With this
command the package is installed, but only if its dependencies are fulfilled and if there are no
conflicts with other packages. With an error message, rpm requests those packages that need
to be installed to meet dependency requirements. In the background, the RPM database ensures
that no conflicts arise—a specific le can only belong to one package. By choosing different
If a configuration le was not changed by the system administrator, rpm installs the new
version of the appropriate le. No action by the system administrator is required.
If a configuration le was changed by the system administrator before the update, rpm
saves the changed le with the extension .rpmorig or .rpmsave (backup le) and installs
the version from the new package (but only if the originally installed le and the newer
version are different). If this is the case, compare the backup le ( .rpmorig or .rpmsave )
with the newly installed le and make your changes again in the new le. Afterwards, be
sure to delete all .rpmorig and .rpmsave les to avoid problems with future updates.
.rpmnew les appear if the configuration le already exists and if the noreplace label
was specified in the .spec le.
Following an update, .rpmsave and .rpmnew les should be removed after comparing them,
so they do not obstruct future updates. The .rpmorig extension is assigned if the le has not
previously been recognized by the RPM database.
Otherwise, .rpmsave is used. In other words, .rpmorig results from updating from a foreign
format to RPM. .rpmsave results from updating from an older RPM to a newer RPM. .rpmnew
does not disclose any information as to whether the system administrator has made any changes
to the configuration le. A list of these les is available in /var/adm/rpmconfigcheck . Some
configuration les (like /etc/httpd/httpd.conf ) are not overwritten to allow continued op-
eration.
The -U switch is not just an equivalent to uninstalling with the -e option and installing with
the -i option. Use -U whenever possible.
64 Managing Packages: Install, Update, and Uninstall SUSE Linux Enterp… 11 SP4
To remove a package, enter rpm -e package . rpm , which only deletes the package if there are
no unresolved dependencies. It is theoretically impossible to delete Tcl/Tk, for example, as long
as another application requires it. Even in this case, RPM calls for assistance from the database.
If such a deletion is, for whatever reason, impossible (even if no additional dependencies exist),
it may be helpful to rebuild the RPM database using the option --rebuilddb .
rpm -q pine
pine-4.44-188
Then check if the patch RPM is suitable for this version of pine :
This patch is suitable for three different versions of pine. The installed version in the ex-
ample is also listed, so the patch can be installed.
Which patches are already installed in the system and for which package versions?
A list of all patches installed in the system can be displayed with the command rpm -
qPa . If only one patch is installed in a new system (as in this example), the list appears
as follows:
rpm -qPa
pine-4.44-224
If, at a later date, you want to know which package version was originally installed, this
information is also available in the RPM database. For pine , this information can be
displayed with the following command:
More information, including information about the patch feature of RPM, is available in the
man pages of rpm and rpmbuild .
Using applydeltarpm , you can reconstruct the new RPM from the le system if the old package
is already installed:
To derive it from the old RPM without accessing the le system, use the -r option:
With the -q option rpm initiates queries, making it possible to inspect an RPM archive (by
adding the option -p ) and also to query the RPM database of installed packages. Several switch-
es are available to specify the type of information required. See Table 6.1, “The Most Important
RPM Query Options”.
-i Package information
-l File list
For example, the command rpm -q -i wget displays the information shown in Example 6.2,
“rpm -q -i wget”.
EXAMPLE 6.2: RPM -Q -I WGET
The option -f only works if you specify the complete filename with its full path. Provide as
many filenames as desired. For example, the following command
results in:
rpm-4.8.0-4.3.x86_64
If only part of the filename is known, use a shell script as shown in Example 6.3, “Script to Search
for Packages”. Pass the partial filename to the script shown as a parameter when running it.
#! /bin/sh
for i in $(rpm -q -a -l | grep $1); do
echo "\"$i\" is in package:"
rpm -q -f $i
echo ""
done
The command rpm -q --changelog rpm displays a detailed list of change information about
a specific package (in this case, the rpm package), sorted by date.
With the help of the installed RPM database, verification checks can be made. Initiate these with
-V , -y or --verify . With this option, rpm shows all les in a package that have been changed
since installation. rpm uses eight character symbols to give some hints about the following
changes:
S File size
L Symbolic link
T Modification time
U Owner
G Group
In the case of configuration les, the letter c is printed. For example, for changes to /etc/
wgetrc ( wget package):
rpm -V wget
S.5....T c /etc/wgetrc
The following directories must be available for rpm and rpmbuild in /usr/src/packages
(unless you specified custom settings in a le like /etc/rpmrc ):
SOURCES
for the original sources ( .tar.bz2 or .tar.gz les, etc.) and for distribution-specific
adjustments (mostly .diff or .patch les)
SPECS
for the .spec les, similar to a meta Makefile, which control the build process
BUILD
all the sources are unpacked, patched and compiled in this directory
RPMS
where the completed binary packages are stored
SRPMS
here are the source RPMs
Warning
Do not experiment with system components ( glibc , rpm , sysvinit , etc.), because this
endangers the stability of your system.
The following example uses the wget.src.rpm package. After installing the source package,
you should have les similar to those in the following list:
/usr/src/packages/SOURCES/wget-1.11.4.tar.bz2
/usr/src/packages/SOURCES/wgetrc.patch
/usr/src/packages/SPECS/wget.spec
-bp
Prepare sources in /usr/src/packages/BUILD : unpack and patch.
-bc
Do the same as -bp , but with additional compilation.
-bi
Do the same as -bp , but with additional installation of the built software. Caution: if the
package does not support the BuildRoot feature, you might overwrite configuration les.
-bb
Do the same as -bi , but with the additional creation of the binary package. If the compile
was successful, the binary should be in /usr/src/packages/RPMS .
-ba
Do the same as -bb , but with the additional creation of the source RPM. If the compilation
was successful, the binary should be in /usr/src/packages/SRPMS .
--short-circuit
Skip some steps.
The danger with many packages is that unwanted les are added to the running system during
the build process. To prevent this use build , which creates a defined environment in which
the package is built. To establish this chroot environment, the build script must be provided
with a complete package tree. This tree can be made available on the hard disk, via NFS, or
from DVD. Set the position with build --rpms directory . Unlike rpm , the build command
looks for the .spec le in the source directory. To build wget (like in the above example) with
the DVD mounted in the system under /media/dvd , use the following commands as root :
cd /usr/src/packages/SOURCES/
mv ../SPECS/wget.spec .
build --rpms /media/dvd/suse/ wget.spec
The build script offers a number of additional options. For example, cause the script to prefer
your own RPMs, omit the initialization of the build environment or limit the rpm command to
one of the above-mentioned stages. Access additional information with build --help and by
reading the build man page.
Midnight Commander ( mc ) can display the contents of RPM archives and copy parts of them.
It represents archives as virtual le systems, offering all usual menu options of Midnight Com-
mander. Display the HEADER with F3 . View the archive structure with the cursor keys and
Enter . Copy archive components with F5 .
A full-featured package manager is available as a YaST module. For details, see Book “Deployment
Guide”, Chapter 9 “Installing or Removing Software”.
These days many people use computers with a graphical user interface (GUI) like
KDE or GNOME. Although they offer lots of features, their use is limited when it
comes to the execution of automated tasks. Shells are a good addition to GUIs and
this chapter gives you an overview of some aspects of shells, in this case Bash.
1. Interactive login shell. This is used when logging in to a machine, invoking Bash with the
--login option or when logging in to a remote machine with SSH.
2. “Ordinary” interactive shell. This is normally the case when starting xterm, konsole,
gnome-terminal or similar tools.
3. Non-interactive shell. This is used when invoking a shell script at the command line.
Depending on which type of shell you use, different configuration les are being read. The
following tables show the login and non-login shell configuration les.
File Description
File Description
The following table provides a short overview of the most important higher-level directories that
you nd on a Linux system. Find more detailed information about the directories and important
subdirectories in the following list.
/boot
Contains data required for booting, such as the boot loader, the kernel, and other data that
is used before the kernel begins executing user-mode programs.
/dev
Holds device les that represent hardware components.
/etc
Contains local configuration les that control the operation of programs like the X Window
System. The /etc/init.d subdirectory contains scripts that are executed during the boot
process.
/home/username
Holds the private data of every user who has an account on the system. The les located
here can only be modified by their owner or by the system administrator. By default, your
e-mail directory and personal desktop configuration are located here in the form of hidden
les and directories. KDE users nd the personal configuration data for their desktop in
.kde4 , GNOME users nd it in .gconf .
/lib
Contains the essential shared libraries needed to boot the system and to run the commands
in the root le system. The Windows equivalent for shared libraries are DLL les.
/media
Contains mount points for removable media, such as CD-ROMs, USB sticks and digital
cameras (if they use USB). /media generally holds any type of drive except the hard drive
of your system. As soon as your removable medium has been inserted or connected to the
system and has been mounted, you can access it from here.
/mnt
/opt
Reserved for the installation of third-party software. Optional software and larger add-on
program packages can be found here.
/root
Home directory for the root user. The personal data of root is located here.
/sbin
As the s indicates, this directory holds utilities for the superuser. /sbin contains the bi-
naries essential for booting, restoring and recovering the system in addition to the binaries
in /bin .
/srv
Holds data for services provided by the system, such as FTP and HTTP.
/tmp
This directory is used by programs that require temporary storage of les.
/usr
/usr has nothing to do with users, but is the acronym for UNIX system resources. The
data in /usr is static, read-only data that can be shared among various hosts compliant
with the Filesystem Hierarchy Standard (FHS). This directory contains all application pro-
grams and establishes a secondary hierarchy in the le system. KDE4 and GNOME are also
located here. /usr holds a number of subdirectories, such as /usr/bin , /usr/sbin , /
usr/local , and /usr/share/doc .
/usr/bin
Contains generally accessible programs.
/usr/sbin
Contains programs reserved for the system administrator, such as repair functions.
/usr/local
/usr/share/doc
Holds various documentation les and the release notes for your system. In the manual
subdirectory nd an online version of this manual. If more than one language is installed,
this directory may contain versions of the manuals for different languages.
Under packages nd the documentation included in the software packages installed on
your system. For every package, a subdirectory /usr/share/doc/packages/package-
name is created that often holds README les for the package and sometimes examples,
configuration les or additional scripts.
If HOWTOs are installed on your system /usr/share/doc also holds the howto subdi-
rectory in which to nd additional documentation on many tasks related to the setup and
operation of Linux software.
/var
Whereas /usr holds static, read-only data, /var is for data which is written during system
operation and thus is variable data, such as log les or spooling data. For an overview of
the most important log les you can nd under /var/log/ , refer to Table 36.1, “Log Files”.
#!/bin/sh 1
Before you can run this script you need some prerequisites:
1. Every script should contain a Shebang line (this is already the case with our example
above.) If a script does not have this line, you have to call the interpreter manually.
2. You can save the script wherever you want. However, it is a good idea to save it in a
directory where the shell can nd it. The search path in a shell is determined by the
environment variable PATH . Usually a normal user does not have write access to /usr/
bin . Therefore it is recommended to save your scripts in the users' directory ~/bin/ . The
above example gets the name hello.sh .
3. The script needs executable permissions. Set the permissions with the following command:
chmod +x ~/bin/hello.sh
If you have fulfilled all of the above prerequisites, you can execute the script in the following
ways:
1. As Absolute Path. The script can be executed with an absolute path. In our case, it is ~/
bin/hello.sh .
2. Everywhere. If the PATH environment variable contains the directory where the script is
located, you can execute the script just with hello.sh .
Standard Output. This is the default output channel. Whenever a command prints some-
thing, it uses the standard output channel.
Standard Input. If a command needs input from users or other commands, it uses this
channel.
ls > listing.txt
ls >> listing.txt
Command1 | Command2
Redirects the output of the left command as input for the right command. For example,
the cat command outputs the content of the /proc/cpuinfo le. This output is used by
grep to filter only those lines which contain cpu :
Every channel has a le descriptor: 0 (zero) for standard input, 1 for standard output and 2 for
standard error. It is allowed to insert this le descriptor before a < or > character. For example,
the following line searches for a le starting with foo , but suppresses its errors by redirecting
it to /dev/null :
alias NAME=DEFINITION
For example, the following line defines an alias lt which outputs a long listing (option -l ),
sorts it by modification time ( -t ) and prints it in reverse order while sorting ( -r ):
printenv PATH
echo $PATH
To set a local variable, use a variable name followed by the equal sign, followed by the value:
PROJECT="SLED"
Do not insert spaces around the equal sign, otherwise you get an error. To set an environment
variable, use export :
export NAME="tux"
unset NAME
The following table contains some common environment variables which can be used in you
shell scripts:
TABLE 7.5: USEFUL ENVIRONMENT VARIABLES
To access all the arguments which are passed to your script, you need positional parameters.
These are $1 for the rst argument, $2 for the second, and so on. You can have up to nine
parameters. To get the script name, use $0 .
The following script foo.sh prints all arguments from 1 to 4:
#!/bin/sh
echo \"$1\" \"$2\" \"$3\" \"$4\"
If you execute this script with the above arguments, you get:
${VAR#pattern}
removes the shortest possible match from the left:
file=/home/tux/book/book.tar.bz2
echo ${file#*/}
home/tux/book/book.tar.bz2
file=/home/tux/book/book.tar.bz2
echo ${file##*/}
book.tar.bz2
${VAR%pattern}
removes the shortest possible match from the right:
file=/home/tux/book/book.tar.bz2
echo ${file%.*}
/home/tux/book/book.tar
${VAR%%pattern}
removes the longest possible match from the right:
file=/home/tux/book/book.tar.bz2
echo ${file%%.*}
/home/tux/book/book
${VAR/pattern_1/pattern_2}
substitutes the content of VAR from the pattern_1 with pattern_2 :
file=/home/tux/book/book.tar.bz2
echo ${file/tux/wilber}
/home/wilber/book/book.tar.bz2
Command1 ; Command2
executes the commands in sequential order. The exit code is not checked. The following
line displays the content of the le with cat and then prints its le properties with ls
regardless of their exit codes:
Command1 || Command2
runs the right command, when the left command has failed (logical OR). The following
line creates only a directory in /home/wilber/bar when the creation of the directory in
/home/tux/foo has failed:
funcname() { ... }
creates a shell function. You can use the positional parameters to access its arguments. The
following line defines the function hello to print a short message:
hello Tux
which prints:
Hello Tux
The test expression can be as complex or simple as possible. The following expression checks
if the le foo.txt exists:
if test -e /tmp/foo.txt ;
then
echo "Found foo.txt"
fi
if [ -e /tmp/foo.txt ] ; then
echo "Found foo.txt"
fi
for i in *.png; do
ls -l $i
done
85 Creating Loops With the For Command SUSE Linux Enterp… 11 SP4
http://tldp.org/LDP/abs/html/index.html —Advanced Bash-Scripting Guide
FAQ Support
https://www.suse.com/support/faq.html
SUSE® Linux Enterprise Server is available for several 64-bit platforms. This does not necessarily
mean that all the applications included have already been ported to 64-bit platforms. SUSE
Linux Enterprise Server supports the use of 32-bit applications in a 64-bit system environment.
This chapter offers a brief overview of how this support is implemented on 64-bit SUSE Linux
Enterprise Server platforms. It explains how 32-bit applications are executed (runtime support)
and how 32-bit applications should be compiled to enable them to run both in 32-bit and 64-bit
system environments. Additionally, nd information about the kernel API and an explanation
of how 32-bit applications can run under a 64-bit kernel.
SUSE Linux Enterprise Server for the 64-bit platforms ia64, ppc64, System z and x86_64 is
designed so that existing 32-bit applications run in the 64-bit environment “out-of-the-box.” The
corresponding 32-bit platforms are x86 for ia64, ppc for ppc64, and x86 for x86_64. This support
means that you can continue to use your preferred 32-bit applications without waiting for a
corresponding 64-bit port to become available. The current ppc64 system runs most applications
in 32-bit mode, but you can run 64-bit applications.
All 64-bit libraries and object les are located in directories called lib64 . The 64-bit object
les that you would normally expect to nd under /lib and /usr/lib are now found under
/lib64 and /usr/lib64 . This means that there is space for the 32-bit libraries under /lib
and /usr/lib , so the filename for both versions can remain unchanged.
Subdirectories of 32-bit /lib directories which contain data content that does not depend on
the word size are not moved. This scheme conforms to LSB (Linux Standards Base) and FHS
(File System Hierarchy Standard).
ipf The 64-bit libraries for ia64 are located in the standard lib directories, there is neither a
lib64 directory nor a lib32 directory. ia64 executes 32-bit x86 code under an emulation. A set
of basic libraries is installed in /emul/ia32-linux/lib and /emul/ia32-linux/usr/lib .
Biarch Compiler
Both 32-bit and 64-bit objects can be generated with a biarch development tool chain. A
biarch development tool chain allows generation of 32-bit and 64-bit objects. The compi-
lation of 64-bit objects is the default on almost all platforms. 32-bit objects can be gener-
ated if special ags are used. This special ag is -m32 for GCC. The ags for the binutils
are architecture-dependent, but GCC transfers the correct ags to linkers and assemblers.
A biarch development tool chain currently exists for amd64 (supports development for x86
and amd64 instructions), for System z and for ppc64. 32-bit objects are normally created
on the ppc64 platform. The -m64 ag must be used to generate 64-bit objects.
No Support
SUSE Linux Enterprise Server does not support the direct development of 32-bit software
on all platforms. To develop applications for x86 under ia64, use the corresponding 32-
bit version of SUSE Linux Enterprise Server.
libaio-32bit
32-bit runtime package
libaio-devel-32bit
Headers and libraries for 32-bit development
libaio
64-bit runtime package
libaio-devel
64-bit development headers and libraries
Most open source programs use an autoconf -based program configuration. To use autoconf
for configuring a program for the second architecture, overwrite the normal compiler and linker
settings of autoconf by running the configure script with additional environment variables.
The following example refers to an x86_64 system with x86 as the second architecture. Examples
for ppc64 with ppc as the second architecture would be similar. This example does not apply
to ia64 where you cannot build 32-bit packages.
CC="gcc -m32"
LD="gcc -m32"
AS="gcc -c -m32"
4. Specify linker ags, such as the location of 32-bit libraries, for example:
LDFLAGS="-L/usr/lib"
--libdir=/usr/lib
--x-libraries=/usr/lib
Not all of these variables are needed for every program. Adapt them to the respective program.
An example configure call to compile a native 32-bit application on x86_64, ppc64 or System
z could appear as follows:
CC="gcc -m32"
LDFLAGS="-L/usr/lib;"
./configure --prefix=/usr --libdir=/usr/lib --x-libraries=/usr/lib
make
make install
Booting a Linux system involves different components. The hardware itself is ini-
tialized by the BIOS, which starts the Kernel by means of a boot loader. After this
point, the boot process with init and the runlevels is completely controlled by the
operating system. The runlevel concept enables you to maintain setups for everyday
usage as well as to perform maintenance tasks on the system.
1. BIOS. After turning on the computer, the BIOS initializes the screen and keyboard and
tests the main memory. Up to this stage, the machine does not access any mass storage
media. Subsequently, the information about the current date, time, and the most important
peripherals are loaded from the CMOS values. When the rst hard disk and its geometry
are recognized, the system control passes from the BIOS to the boot loader. If the BIOS
supports network booting, it is also possible to configure a boot server that provides the
boot loader. On x86 systems, PXE boot is needed. Other architectures commonly use the
BOOTP protocol to get the boot loader.
2. Boot Loader. The rst physical 512-byte data sector of the rst hard disk is loaded into
the main memory and the boot loader that resides at the beginning of this sector takes
over. The commands executed by the boot loader determine the remaining part of the boot
process. Therefore, the rst 512 bytes on the rst hard disk are referred to as the Master
Boot Record (MBR). The boot loader then passes control to the actual operating system,
in this case, the Linux Kernel. More information about GRUB, the Linux boot loader, can
be found in Chapter 11, The Boot Loader GRUB. For a network boot, the BIOS acts as the
boot loader. It gets the image to start from the boot server and starts the system. This is
completely independent of local hard disks.
3. Kernel and initramfs . To pass system control, the boot loader loads both the Kernel
and an initial RAM–based le system ( initramfs ) into memory. The contents of the
initramfs can be used by the Kernel directly. initramfs contains a small executable
4. init on initramfs . This program performs all actions needed to mount the proper root
le system, like providing Kernel functionality for the needed le system and device drivers
for mass storage controllers with udev . After the root le system has been found, it is
checked for errors and mounted. If this is successful, the initramfs is cleaned and the
init program on the root le system is executed. For more information about init ,
refer to Section 10.1.2, “init on initramfs”. Find more information about udev in Chapter 15,
Dynamic Kernel Device Management with udev.
5. init . init handles the actual booting of the system through several different levels
providing different functionality. init is described in Section 10.2, “The init Process”.
10.1.1 initramfs
initramfs is a small cpio archive that the Kernel can load to a RAM disk. It provides a minimal
Linux environment that enables the execution of programs before the actual root le system is
mounted. This minimal Linux environment is loaded into memory by BIOS routines and does not
have specific hardware requirements other than sufficient memory. initramfs must always
provide an executable named init that should execute the actual init program on the root
le system for the boot process to proceed.
Before the root le system can be mounted and the operating system can be started, the Kernel
needs the corresponding drivers to access the device on which the root le system is located.
These drivers may include special drivers for certain kinds of hard drives or even network drivers
to access a network le system. The needed modules for the root le system may be loaded by
init on initramfs . After the modules are loaded, udev provides the initramfs with the
needed devices. Later in the boot process, after changing the root le system, it is necessary to
regenerate the devices. This is done by boot.udev with the command udevtrigger .
If you need to change hardware (for example hard disks) in an installed system and this hardware
requires different drivers to be present in the Kernel at boot time, you must update initramfs .
This is done in the same way as with its predecessor, init —by calling mkinitrd . Calling
When init is called during the initial boot as part of the installation process, its tasks differ
from those mentioned above:
Starting YaST
Finally, init starts YaST, which starts package installation and system configuration.
10.2.1 Runlevels
In Linux, runlevels define how the system is started and what services are available in the running
system. After booting, the system starts as defined in /etc/inittab in the line initdefault .
Usually this is 3 or 5 . See Table 10.1, “Available Runlevels”. As an alternative, the runlevel can be
specified at boot time (by adding the runlevel number at the boot prompt, for instance). Any
parameters that are not directly evaluated by the Kernel itself are passed to init . To boot into
runlevel 3, just add the single number 3 to the boot prompt.
TABLE 10.1: AVAILABLE RUNLEVELS
Runlevel Description
0 System halt
6 System reboot
To change runlevels while the system is running, enter telinit and the corresponding number
as an argument. Only the system administrator is allowed to do this. The following list summa-
rizes the most important commands in the runlevel area.
telinit 3
All essential programs and services (including network) are started and regular users are
allowed to log in and work with the system without a graphical environment.
telinit 5
The graphical environment is enabled. Usually a display manager like XDM, GDM or KDM
is started. If autologin is enabled, the local user is logged in to the preselected window
manager (GNOME or KDE or any other window manager).
Generally, two things happen when you change runlevels. First, stop scripts of the current run-
level are launched, closing down some programs essential for the current runlevel. Then start
scripts of the new runlevel are started. Here, in most cases, a number of programs are started.
For example, the following occurs when changing from runlevel 3 to 5:
2. init checks the current runlevel ( runlevel ) and determines it should start /etc/
init.d/rc with the new runlevel as a parameter.
3. Now rc calls the stop scripts of the current runlevel for which there is no start script in the
new runlevel. In this example, these are all the scripts that reside in /etc/init.d/rc3.d
(the old runlevel was 3) and start with a K . The number following K specifies the order to
run the scripts with the stop parameter, because there are some dependencies to consider.
4. The last things to start are the start scripts of the new runlevel. In this example, these
are in /etc/init.d/rc5.d and begin with an S . Again, the number that follows the S
determines the sequence in which the scripts are started.
All scripts are located in /etc/init.d . Scripts that are run at boot time are called through
symbolic links from /etc/init.d/boot.d . Scripts for changing the runlevel are called through
symbolic links from one of the subdirectories ( /etc/init.d/rc0.d to /etc/init.d/rc6.d ).
This is just for reasons of clarity and avoids duplicate scripts if they are used in several runlevels.
Because every script can be executed as both a start and a stop script, these scripts must un-
derstand the parameters start and stop . The scripts also understand the restart , reload ,
force-reload , and status options. These different options are explained in Table 10.2, “Possi-
ble init Script Options”. Scripts that are run directly by init do not have these links. They are
run independently from the runlevel when needed.
Option Description
Links in each runlevel-specific subdirectory make it possible to associate scripts with different
runlevels. When installing or uninstalling packages, these links are added and removed with the
help of the program insserv (or using /usr/lib/lsb/install_initd , which is a script calling
this program). See man 8 insserv for more details.
All of these settings may also be changed with the help of the YaST module. If you need to check
the status on the command line, use the tool chkconfig , described in the man 8 chkconfig
man page.
A short introduction to the boot and stop scripts launched rst or last, respectively, follows as
well as an explanation of the maintaining script.
boot
Executed while starting the system directly using init . It is independent of the chosen
runlevel and is only executed once. Here, the /proc and /dev/pts le systems are mount-
ed and blogd (boot logging daemon) is activated. If the system is booted for the rst time
after an update or an installation, the initial system configuration is started.
The blogd daemon is a service started by boot and rc before any other one. It is stopped
after the actions triggered by these scripts (running a number of subscripts, for example,
making special block les available) are completed. blogd writes any screen output to the
log le /var/log/boot.msg , but only if and when /var is mounted read-write. Other-
wise, blogd buers all screen data until /var becomes available. Get further information
about blogd with man 8 blogd .
The boot script is also responsible for starting all the scripts in /etc/init.d/boot.d
with names that start with S . There, the le systems are checked and loop devices are
configured if needed. The system time is also set. If an error occurs while automatically
checking and repairing the le system, the system administrator can intervene after rst
entering the root password. The last executed script is boot.local .
halt
This script is only executed while changing into runlevel 0 or 6. Here, it is executed either
as init or as init . Whether the system shuts down or reboots depends on how halt is
called. If special commands are needed during the shutdown, add these to the init script.
rc
This script calls the appropriate stop scripts of the current runlevel and the start scripts of
the newly selected runlevel. Like the /etc/init.d/boot script, this script is called from
/etc/inittab with the desired runlevel as parameter.
You can create your own scripts and easily integrate them into the scheme described above. For
instructions about formatting, naming and organizing custom scripts, refer to the specifications
of the LSB and to the man pages of init , init.d , chkconfig , and insserv . Additionally
consult the man pages of startproc and killproc .
To create a custom init script for a given program or service, use the le /etc/init.d/
skeleton as a template. Save a copy of this le under the new name and edit the relevant
program and filenames, paths and other details as needed. You may also need to enhance the
script with your own parts, so the correct actions are triggered by the init procedure.
The INIT INFO block at the top is a required part of the script and must be edited. See Exam-
ple 10.1, “A Minimal INIT INFO Block”.
In the rst line of the INFO block, after Provides: , specify the name of the program or service
controlled by this init script. In the Required-Start: and Required-Stop: lines, specify
all services that need to be still running when the service itself is stopped. This information
is used later to generate the numbering of script names, as found in the runlevel directories.
After Default-Start: and Default-Stop: , specify the runlevels in which the service should
automatically be started or stopped. Finally, for Description: , provide a short description of
the service in question.
To create the links from the runlevel directories ( /etc/init.d/rc?.d/ ) to the corresponding
scripts in /etc/init.d/ , enter the command insserv new-script-name . insserv evaluates
the INIT INFO header to create the necessary links for start and stop scripts in the runlevel
directories ( /etc/init.d/rc?.d/ ). The program also takes care of the correct start and stop
order for each runlevel by including the necessary numbers in the names of these links. If you
prefer a graphical tool to create such links, use the runlevel editor provided by YaST, as described
in Section 10.2.3, “Configuring System Services (Runlevel) with YaST”.
If a script already present in /etc/init.d/ should be integrated into the existing runlevel
scheme, create the links in the runlevel directories right away with insserv or by enabling the
corresponding service in the runlevel editor of YaST. Your changes are applied during the next
reboot—the new service is started automatically.
Do not set these links manually. If something is wrong in the INFO block, problems will arise
when insserv is run later for some other service. The manually added service will be removed
with the next run of insserv for this script.
After starting this YaST module with YaST System System Services (Runlevel), it displays an
overview listing all the available services and the current status of each service (disabled or
enabled). Decide whether to use the module in Simple Mode or in Expert Mode. The default Simple
Mode should be sufficient for most purposes. The left column shows the name of the service, the
center column indicates its current status and the right column gives a short description. For
the selected service, a more detailed description is provided in the lower part of the window. To
enable a service, select it in the table then select Enable. The same steps apply to disable a service.
104 Configuring System Services (Runlevel) with YaST SUSE Linux Enterp… 11 SP4
For detailed control over the runlevels in which a service is started or stopped or to change
the default runlevel, rst select Expert Mode. The current default runlevel or “initdefault” (the
runlevel into which the system boots by default) is displayed at the top. Normally, the default
runlevel of a SUSE Linux Enterprise Server system is runlevel 5 (full multiuser mode with net-
work and X). A suitable alternative might be runlevel 3 (full multiuser mode with network).
This YaST dialog allows the selection of one of the runlevels (as listed in Table 10.1, “Available Run-
levels”) as the new default. Additionally, use the table in this window to enable or disable indi-
vidual services and daemons. The table lists the services and daemons available, shows whether
they are currently enabled on your system and, if so, for which runlevels. After selecting one of
the rows with the mouse, click the check boxes representing the runlevels (B, 0, 1, 2, 3, 5, 6, and
S) to define the runlevels in which the selected service or daemon should be running. Runlevel 4
is undefined to allow creation of a custom runlevel. A brief description of the currently selected
service or daemon is provided below the table overview.
105 Configuring System Services (Runlevel) with YaST SUSE Linux Enterp… 11 SP4
FIGURE 10.1: SYSTEM SERVICES (RUNLEVEL)
With Start, Stop, or Refresh, decide whether a service should be activated. Refresh status checks
the current status. Set or Reset lets you select whether to apply your changes to the system or
to restore the settings that existed before starting the runlevel editor. Selecting OK saves the
changed settings to disk.
The YaST sysconfig editor provides an easy-to-use front-end for system configuration. Without
any knowledge of the actual location of the configuration variable you need to change, you
can just use the built-in search function of this module, change the value of the configuration
variable as needed and let YaST take care of applying these changes, updating configurations
that depend on the values set in sysconfig and restarting services.
The YaST sysconfig dialog is split into three parts. The left part of the dialog shows a tree
view of all configurable variables. When you select a variable, the right part displays both the
current selection and the current setting of this variable. Below, a third window displays a
short description of the variable's purpose, possible values, the default value and the actual
Changing the System Configuration Using the YaST sysconfig Editor SUSE Linux Enterp…
107 11 SP4
configuration le from which this variable originates. The dialog also provides information
about which configuration script is executed after changing the variable and which new service
is started as a result of the change. YaST prompts you to confirm your changes and informs
you which scripts will be executed after you leave the dialog by selecting Finish. Also select
the services and scripts to skip for now, so they are started later. YaST applies all changes
automatically and restarts any services involved for your changes to take an effect.
1. Become root .
2. Bring the system into single user mode (runlevel 1) with telinit 1 .
5. Bring your system back to the previous runlevel with a command like telinit de-
fault_runlevel . Replace default_runlevel with the default runlevel of the system.
Choose 5 if you want to return to full multiuser with network and X or choose 3 if you
prefer to work in full multiuser with network.
This procedure is mainly relevant when changing systemwide settings, such as the network
configuration. Small changes should not require going into single user mode, but you may still
do so to make absolutely sure that all the programs concerned are correctly restarted.
108 Changing the System Configuration Manually SUSE Linux Enterp… 11 SP4
11 The Boot Loader GRUB
This chapter describes how to configure GRUB (Grand Unified Bootloader), the boot
loader used in SUSE® Linux Enterprise Server. A special YaST module is available
for configuring all settings. If you are not familiar with the subject of booting in Lin-
ux, read the following sections to acquire some background information. This chap-
ter also describes some of the problems frequently encountered when booting with
GRUB and their solutions.
This chapter focuses on boot management and the configuration of the boot loader GRUB. The
boot procedure as a whole is outlined in Chapter 10, Booting and Configuring a Linux System. A boot
loader represents the interface between the machine (BIOS) and the operating system (SUSE
Linux Enterprise Server). The configuration of the boot loader directly impacts the start of the
operating system.
The following terms appear frequently in this chapter and might need some explanation:
/boot/grub/menu.lst
This le contains all information about partitions or operating systems that can be booted
with GRUB. Without this information, the GRUB command line prompts the user for how
to proceed (see Section 11.1.1.3, “Editing Menu Entries during the Boot Procedure” for details).
/etc/grub.conf
This le contains the commands, parameters and options the GRUB shell needs for in-
stalling the boot loader correctly.
/etc/sysconfig/bootloader
This le contains configuration options (such as Kernel parameters) that will be used as
fallback in specific situations, see Section 11.1.4, “The File /etc/sysconfig/bootloader”.
/etc/sysconfig/bootloader is not a GRUB-specific configuration le—the values are
applied to any boot loader installed on SUSE Linux Enterprise Server.
GRUB can be controlled in various ways. Boot entries from an existing configuration can be
selected from the graphical menu (splash screen). The configuration is loaded from the le
menu.lst .
In GRUB, all boot parameters can be changed prior to booting. For example, errors made when
editing the menu le can be corrected in this way. Boot commands can also be entered interac-
tively at a kind of input prompt. For details, see Section 11.1.1.3, “Editing Menu Entries during the
Boot Procedure”. GRUB offers the possibility of determining the location of the kernel and the
initrd prior to booting. In this way, you can even boot an installed operating system for which
no entry exists in the boot loader configuration.
GRUB actually exists in two versions: as a boot loader and as a normal Linux program in /usr/
sbin/grub . The latter is referred to as the GRUB shell. It provides an emulation of GRUB in
the installed system and can be used to install GRUB or test new settings before applying them.
The functionality to install GRUB as the boot loader on a hard disk or floppy disk is integrated
in GRUB in the form of the command setup . This is available in the GRUB shell when Linux
is loaded.
chainloader (hd0,3)+1
The device names in GRUB are explained in Section 11.1.1.1, “Naming Conventions for Hard Disks
and Partitions”. This example specifies the rst block of the fourth partition of the rst hard disk.
Use the command kernel to specify a kernel image. The rst argument is the path to the kernel
image in a partition. The other arguments are passed to the kernel on its command line.
If the kernel does not have built-in drivers for access to the root partition or a recent Linux
system with advanced hotplug features is used, initrd must be specified with a separate GRUB
command whose only argument is the path to the initrd le. Because the loading address of
the initrd is written into the loaded kernel image, the command initrd must follow after
the kernel command.
The command root simplifies the specification of kernel and initrd les. The only argument of
root is a device or a partition. This device is used for all kernel, initrd , or other le paths
for which no device is explicitly specified until the next root command.
The boot command is implied at the end of every menu entry, so it does not need to be written
into the menu le. However, if you use GRUB interactively for booting, you must enter the boot
command at the end. The command itself has no arguments. It merely boots the loaded kernel
image or the specified chain loader.
After writing all menu entries, define one of them as the default entry. Otherwise, the rst one
(entry 0 ) is used. You can also specify a time-out in seconds after which the default entry should
boot. timeout and default usually precede the menu entries. An example le is described in
Section 11.1.1.2, “An Example Menu File”.
The naming convention GRUB uses for hard disks and partitions differ from that used for normal
Linux devices. It more closely resembles the simple disk enumeration the BIOS does and the
syntax is similar to that used in some BSD derivatives. In GRUB, the numbering of the partitions
start with zero. This means that ( hd0,0 ) is the rst partition of the rst hard disk. On a common
desktop machine with a hard disk connected as primary master, the corresponding Linux device
name is /dev/sda1 .
The four possible primary partitions are assigned the partition numbers 0 to 3 . The logical
partitions are numbered from 4 :
Being dependent on BIOS devices, GRUB does not distinguish between PATA (IDE), SATA, SCSI,
and hardware RAID devices. All hard disks recognized by the BIOS or other controllers are
numbered according to the boot sequence preset in the BIOS.
Unfortunately, it is often not possible to map the Linux device names to BIOS device names
exactly. It generates this mapping with the help of an algorithm and saves it to the le de-
vice.map , which can be edited if necessary. Information about the le device.map is available
in Section 11.1.2, “The File device.map”.
A complete GRUB path consists of a device name written in parentheses and the path to the
le in the le system in the specified partition. The path begins with a slash. For example, the
bootable kernel could be specified as follows on a system with a single PATA (IDE) hard disk
containing Linux in its rst partition:
(hd0,0)/boot/vmlinuz
gfxmenu (hd0,4)/boot/message 1
default 0 3
timeout 8 4
title linux 5
root (hd0,4)
kernel /boot/vmlinuz root=/dev/sda7 vga=791 resume=/dev/sda9
initrd /boot/initrd
title windows 6
rootnoverify (hd0,0)
chainloader +1
title floppy 7
rootnoverify (hd0,0)
chainloader (fd0)+1
title failsafe 8
root (hd0,4)
kernel /boot/vmlinuz.shipped root=/dev/sda7 ide=nodma \
apm=off acpi=off vga=normal nosmp maxcpus=0 3 noresume
initrd /boot/initrd.shipped
1 The background image message is located in the /boot directory of the /dev/sda5 par-
tition.
2 Color scheme: white (foreground), blue (background), black (selection) and light gray
(background of the selection). The color scheme has no effect on the splash screen, only on
the customizable GRUB menu that you can access by exiting the splash screen with Esc .
3 The rst ( 0 ) menu entry title linux is booted by default.
4 After eight seconds without any user input, GRUB automatically boots the default entry.
To deactivate automatic boot, delete the timeout line. If you set timeout 0 , GRUB boots
the default entry immediately.
The second and largest block lists the various bootable operating systems. The sections for the
individual operating systems are introduced by title .
5 The rst entry ( title linux ) is responsible for booting SUSE Linux Enterprise Server.
The kernel ( vmlinuz ) is located in the rst logical partition (the boot partition) of the
rst hard disk. Kernel parameters, such as the root partition and VGA mode, are appended
In the graphical boot menu, select the operating system to boot with the arrow keys. If you
select a Linux system, you can enter additional boot parameters at the boot prompt. To edit
individual menu entries directly, press Esc to exit the splash screen and get to the GRUB text-
based menu then press E . Changes made in this way only apply to the current boot and are
not adopted permanently.
Editing menu entries facilitates the repair of a defective system that can no longer be booted,
because the faulty configuration le of the boot loader can be circumvented by manually en-
tering parameters. Manually entering parameters during the boot procedure is also useful for
testing new settings without impairing the native system.
title linux
root(hd0,0)
kernel /vmlinuz root=/dev/sda3 additional parameter
initrd /initrd
GRUB automatically adopts the new parameters the next time the system is booted. Alternative-
ly, this change can also be made with the YaST boot loader module. Append the new parameters
to the existing line, separated by spaces.
(fd0) /dev/fd0
(hd0) /dev/sda
(hd1) /dev/sdb
or
(fd0) /dev/fd0
(hd0) /dev/disk-by-id/DISK1 ID
(hd1) /dev/disk-by-id/DISK2 ID
Because the order of PATA (IDE), SCSI and other hard disks depends on various factors and Linux
is not able to identify the mapping, the sequence in the le device.map can be set manually.
If you encounter problems when booting, check if the sequence in this le corresponds to the
After manually changing device.map , execute the following command to reinstall GRUB. This
command causes the le device.map to be reloaded and the commands listed in grub.conf
to be executed:
The third important GRUB configuration le after menu.lst and device.map is /etc/
grub.conf . This le contains the commands, parameters and options the GRUB shell needs for
installing the boot loader correctly:
This command tells GRUB to automatically install the boot loader to the second partition on the
rst hard disk (hd0,1) using the boot images located on the same partition. The --stage2=/
boot/grub/stage2 parameter is needed to install the stage2 image from a mounted le sys-
tem. Some BIOSes have a faulty LBA support implementation, --force-lba provides a solution
to ignore them.
This le is read by the perl-bootloader library which is used when configuring the boot loader
with YaST. It contains configuration options (such as Kernel parameters) that will be used as
fallback.
Whenever a new kernel is installed, a heuristic tries to nd matching parameters from the pre-
vious kernel. Only if that does not work, for example when the Kernel flavor has changed, the
settings from /etc/sysconfig/boot loader will take effect.
So, changing settings in /etc/ (either manually or with the YaST sysconfig editor) will not
affect the actual boot loader configuration. On the other hand, changing the actual bootloader
configuration le in rare cases may not survive a change of the kernel flavor.
LOADER_TYPE
Specifies the boot loader installed on the system (e.g. GRUB or LILO). Do not modify—
use YaST to change the boot loader as described in Procedure 11.6, “Changing the Boot Loader
Type”.
CYCLE_DETECTION / CYCLE_NEXT_ENTRY
Configure whether to use boot cycle detection and if so, which alternative entry from /
boot/grub/menu.lst to boot in case of a reboot cycle (e.g. Failsafe ). See /usr/share/
doc/packages/bootcycle/README for detailed information.
Even before the operating system is booted, GRUB enables access to le systems. Users without
root permissions can access les in your Linux system to which they have no access once the
system is booted. To block this kind of access or to prevent users from booting certain operating
systems, set a boot password.
# grub-md5-crypt
Password: ****
Retype password: ****
Encrypted: $1$lS2dv/$JOYcdxIn7CJk9xShzzJVw/
2. Paste the encrypted string into the global section of the le menu.lst :
gfxmenu (hd0,4)/message
Now GRUB commands can only be executed at the boot prompt after pressing P and
entering the password. However, users can still boot all operating systems from the boot
menu.
3. To prevent one or several operating systems from being booted from the boot menu, add
the entry lock to every section in menu.lst that should not be bootable without entering
a password. For example:
title linux
kernel (hd0,4)/vmlinuz root=/dev/sda7 vga=791
initrd (hd0,4)/initrd
lock
After rebooting the system and selecting the Linux entry from the boot menu, the following
error message is displayed:
Press Enter to enter the menu. Then press P to get a password prompt. After enter-
ing the password and pressing Enter , the selected operating system (Linux in this case)
should boot.
120 Configuring the Boot Loader with YaST SUSE Linux Enterp… 11 SP4
FIGURE 11.1: BOOT LOADER SETTINGS
Use the Section Management tab to edit, change and delete boot loader sections for the individual
operating systems. To add an option, click Add. To change the value of an existing option, select
it with the mouse and click Edit. To remove an existing entry, select it and click Delete. If you
are not familiar with boot loader options, read Section 11.1, “Booting with GRUB” rst.
Use the Boot Loader Installation tab to view and change settings related to type, location and
advanced loader settings.
Click Other to access advanced configuration options. The build-in editor lets you change the
GRUB configuration les. For details, see Section 11.1, “Booting with GRUB”. You can also delete
the existing configuration and Start from Scratch or let YaST Propose a New Configuration. It is
also possible to write the configuration to disk or reread the configuration from the disk. To
restore the original Master Boot Record (MBR) that was saved during the installation, choose
Restore MBR of Hard Disk.
121 Adjusting the Default Boot Entry SUSE Linux Enterp… 11 SP4
2. Select the desired entry from the list.
1. Select the Boot Loader Installation tab and then choose one of the following options for
Boot Loader Location:
122 Modifying the Boot Loader Location SUSE Linux Enterp… 11 SP4
2. Click Boot Loader Options.
3. Change the value of Time-Out in Seconds by typing in a new value and clicking the appro-
priate arrow key with your mouse, or by using the arrow keys on the keyboard.
Using this YaST module, you can also set a password to protect booting. This gives you an
additional level of security.
3. Activate the Protect Boot Loader with Password option with a click and type in your Password
twice.
If your computer has more than one hard disk, you can specify the boot sequence of the disks to
match the BIOS setup of the machine (see Section 11.1.2, “The File device.map”). To do so, proceed
as follows:
Advanced boot options can be configured via Boot Loader Installation Boot Loader Options. Nor-
mally, it should not be necessary to change the default settings.
Debugging Flag
Sets GRUB in debug mode where it displays messages to show disk activity.
Warning
When hiding the boot menu, you will not be able to access GRUB during boot time.
When having set the default boot option to a non-Linux operation system at the
same time, this effectively disables access to the Linux system.
Set the boot loader type in Boot Loader Installation. The default boot loader in SUSE Linux En-
terprise Server is GRUB. To use LILO or ELILO, proceed as follows:
3. In the dialog box that opens, select one of the following actions:
1. Change into a directory in which to create the ISO image, for example: cd /tmp
2. Create a subdirectory for GRUB and change into the newly created iso directory:
126 Uninstalling the Linux Boot Loader SUSE Linux Enterp… 11 SP4
3. Copy the kernel, the les stage2_eltorito , initrd , menu.lst and message to iso/
boot/ :
cp /boot/vmlinuz boot/
cp /boot/initrd boot/
cp /boot/message boot/
cp /usr/lib/grub/stage2_eltorito boot/grub
cp /boot/grub/menu.lst boot/grub
In some cases (when booting multiple operating systems, for example) it may be useful to
also copy /boot/grub/device.map to boot/grub .
4. Replace the root (hdx, y) entries with root (cd) to point to the CD_ROM device.
You may also need to adjust the paths to the message le, the kernel and the initrd—they
need to point to /boot/message , /boot/vmlinuz and /boot/initrd , respectively. Af-
ter having made the adjustments, menu.lst should look similar to the following example:
timeout 8
default 0
gfxmenu (cd)/boot/message
title Linux
root (cd)
kernel /boot/vmlinuz root=/dev/sda5 vga=794 resume=/dev/sda1 \
splash=verbose showopts
initrd /boot/initrd
Use splash=silent instead of splash=verbose to prevent the boot messages from ap-
pearing during the boot procedure.
6. Write the resulting le grub.iso to a CD using your preferred utility. Do not burn the
ISO image as a data le, but use the option for burning a CD image in your burning utility.
Warning: No Support
SUSE cannot provide any support for your system if you run it with a custom kernel.
11.6 Troubleshooting
This section lists some of the problems frequently encountered when booting with GRUB and
a short description of possible solutions. Some of the problems are covered in articles in the
Knowledge base at http://www.suse.com/support . Use the search dialog to search for keywords
like GRUB, boot and boot loader.
...
title windows
map (hd0) (hd1)
map (hd1) (hd0)
chainloader(hd1,0)+1
...
In this example, Windows is started from the second hard disk. For this purpose, the logical
order of the hard disks is changed with map . This change does not affect the logic within
the GRUB menu le. Therefore, the second hard disk must be specified for chainloader .
UEFI (Unified Extensible Firmware Interface) is the interface between the rmware that comes
with the system hardware, all the hardware components of the system, and the operating system.
UEFI is becoming more and more available on PC systems and thus is replacing the traditional
PC-BIOS. UEFI, for example, properly supports 64-bit systems and offers secure booting (“Secure
Boot”, rmware version 2.3.1c or better required), which is one of its most important features.
Last but not least, with UEFI a standard rmware will become available on all x86 platforms.
UEFI additionally offers the following advantages:
Booting from large disks (over 2 TiB) with a GUID Partition Table (GPT).
CSM (Compatibility Support Module) to support booting legacy operating systems via a
PC-BIOS-like emulation.
Supporting UEFI Secure Boot essentially requires having a boot loader with a digital signature
that the rmware recognizes as a trusted key. In order to be useful to SUSE Linux Enterprise cus-
tomers, that key is trusted by the rmware a priori, without requiring any manual intervention.
There are two ways of getting there. One is to work with hardware vendors to have them en-
dorse a SUSE key, which SUSE then signs the boot loader with. The other way is to go through
Microsoft’s Windows Logo Certification program to have the boot loader certified and have Mi-
crosoft recognize the SUSE signing key (i.e., have it signed with their KEK). By now, SUSE got
the loader signed by UEFI Signing Service (that's Microsoft in this case).
At the implementation layer, SUSE uses the shim loader—it is a smart solution that avoids legal
issues, and simplifies the certification and signing step considerably. The shim loader’s job is
to load a boot loader such as eLILO or GRUB2 and verify it; this boot loader in turn will load
kernels signed by a SUSE key only. SUSE provides this functionality with SLE11 SP3 on fresh
installations with UEFI Secure Boot enabled.
First, those who hold the keys. The Platform Key (PK) allows almost everything. The Key
Exchange Key (KEK) allows all a PK can except changing the PK.
Second, anyone with physical access to the machine. A user with physical access can reboot
the machine, and configure UEFI.
UEFI offers two types of variables to fulfill the needs of those users:
The rst is the so-called “Authenticated Variables”, which can be updated from both within
the boot process (the so-called Boot Services Environment) and the running OS, but only
when the new value of the variable is signed with the same key that the old value of the
variable was signed with. And they can only be appended to or changed to a value with
a higher serial number.
The second is the so-called “Boot Services Only Variables”. These variables are accessible
to any code that runs during the boot process. After the boot process ends and before the
OS starts, the boot loader must call the ExitBootServices call. After that, these variables
are no longer accessible, and the OS cannot touch them.
The various UEFI key lists are of the rst type, as this allows online updating, adding, and
blacklisting of keys, drivers, and rmware fingerprints. It is the second type of variable, the
“Boot Services Only Variable”, that helps to implement Secure Boot, in a matter that is both
secure and open source friendly, and thus compatible with GPLv3.
SUSE starts with shim —a small and simple EFI boot loader—which was originally developed
by Fedora. It is signed by a certificate signed by the SUSE KEK and a Microsoft-issued certificate,
based on which KEKs are available in the UEFI key database on the system.
This allows shim to load and execute.
shim then goes on to verify that the boot loader it wants to load is trusted. In a default situation
shim will use an independent SUSE certificate embedded in its body. In addition, shim will
allow to “enroll” additional keys, overriding the default SUSE key. In the following, we call
them “Machine Owner Keys” or MOKs for short.
Next the boot loader will verify and then boot the kernel, and the kernel will do the same on
the modules.
certutil -d . -N
4. Import the key and the certificate contained in PKCS#12 into the NSS database:
pk12util -d . -i cert.p12
pesign -n . -S -i vmlinuz.signed
At that point, you can install the kernel in /boot as usual. Because the kernel now has
a custom signature the certificate used for signing needs to be imported into the UEFI
rmware or MOK.
7. Convert the certificate to the DER format for import into the rmware or MOK:
a. Reboot
c. Type:
chainloader $efibootdir/MokManager.efi
f. Follow the instructions to enroll the key. Normally this should be pressing ' 0 ' and
then ' y ' to confirm.
Alternatively, the rmware menu may provide ways to add a new key to the Signa-
ture Database.
Add the needed keys to the rmware database via rmware/system management tools
before the installation. This option depends on the specific hardware you are using. Consult
your hardware vendor for more information.
To use the bootable driver ISO to enroll the driver keys to the MOK list, follow these steps:
2. Start the installation by booting from the new CD/DVD media, having the standard SUSE
Linux Enterprise media at hand or a URL to a network installation server.
If doing a network installation, enter the URL of the network installation source on the
boot command line using the install= option.
If doing installation from optical media, the installer will rst boot from the driver kit and
then ask to insert the rst disk of the SUSE Linux Enterprise product.
Hybridified ISO images are not recognized as bootable on UEFI systems. Thus, UEFI booting
from USB devices is not supported with SP3.
To ensure that Secure Boot cannot be easily circumvented, some kernel features are dis-
abled when running under Secure Boot.
Access to /dev/kmem and /dev/mem is not possible, not even as root user.
Access to the I/O port is not possible, not even as root user. All X11 graphical drivers must
use a kernel driver.
Blog posts by Olaf Kirch and Vojtěch Pavlík (the chapter above is heavily based on these
posts):
http://www.suse.com/blogs/uefi-secure-boot-plan/
http://www.suse.com/blogs/uefi-secure-boot-overview/
http://www.suse.com/blogs/uefi-secure-boot-details/
This chapter starts with information about various software packages, the virtual
consoles and the keyboard layout. We talk about software components like bash ,
cron and logrotate , because they were changed or enhanced during the last re-
lease cycles. Even if they are small or considered of minor importance, users may
want to change their default behavior, because these components are often closely
coupled with the system. The chapter concludes with a section about language and
country-specific settings (I18N and L10N).
1. /etc/profile
2. ~/.profile
3. /etc/bash.bashrc
4. ~/.bashrc
mv ~/.bashrc ~/.bashrc.old
139 Information about Special Software Packages SUSE Linux Enterp… 11 SP4
cp /etc/skel/.bashrc ~/.bashrc
mv ~/.profile ~/.profile.old
cp /etc/skel/.profile ~/.profile
If you want to run commands regularly and automatically in the background at predefined times,
cron is the tool to use. cron is driven by specially formatted time tables. Some of them come
with the system and users can write their own tables if needed.
The cron tables are located in /var/spool/cron/tabs . /etc/crontab serves as a systemwide
cron table. Enter the username to run the command directly after the time table and before
the command. In Example 13.1, “Entry in /etc/crontab”, root is entered. Package-specific tables,
located in /etc/cron.d , have the same format. See the cron man page ( man cron ).
EXAMPLE 13.1: ENTRY IN /ETC/CRONTAB
You cannot edit /etc/crontab by calling the command crontab -e . This le must be loaded
directly into an editor, then modified and saved.
A number of packages install shell scripts to the directories /etc/cron.hourly , /etc/
cron.daily , /etc/cron.weekly and /etc/cron.monthly , whose execution is controlled by
/usr/lib/cron/run-crons . /usr/lib/cron/run-crons is run every 15 minutes from the
main table ( /etc/crontab ). This guarantees that processes that may have been neglected can
be run at the proper time.
To run the hourly , daily or other periodic maintenance scripts at custom times, remove the
time stamp les regularly using /etc/crontab entries (see Example 13.2, “/etc/crontab: Remove
Time Stamp Files”, which removes the hourly one before every full hour, the daily one once
a day at 2:14 a.m., etc.).
59 * * * * root rm -f /var/spool/cron/lastrun/cron.hourly
14 2 * * * root rm -f /var/spool/cron/lastrun/cron.daily
29 2 * * 6 root rm -f /var/spool/cron/lastrun/cron.weekly
44 2 1 * * root rm -f /var/spool/cron/lastrun/cron.monthly
Important
The create option reads all settings made by the administrator in /etc/permissions* .
Ensure that no conflicts arise from any personal modifications.
Systemwide entries can be made in /etc/profile . There, enable creation of core les (needed
by programmers for debugging). A normal user cannot increase the values specified in /etc/
profile by the system administrator, but can make special entries in ~/.bashrc .
Memory allocations must be specified in KB. For more detailed information, see man bash .
Important
Not all shells support ulimit directives. PAM (for instance, pam_limits ) offers com-
prehensive adjustment possibilities if you depend on encompassing settings for these re-
strictions.
For some GNU applications (such as tar), the man pages are no longer maintained. For these
commands, use the --help option to get a quick overview of the info pages, which provide
more in-depth instructions. Info is GNU's hypertext system. Read an introduction to this system
by entering info info . Info pages can be viewed with Emacs by entering emacs -f info
or directly in a console with info . You can also use tkinfo, xinfo or the help system to view
info pages.
GNU Emacs is a complex work environment. The following sections cover the configuration
les processed when GNU Emacs is started. More information is available at http://www.gnu.org/
software/emacs/ .
On start-up, Emacs reads several les containing the settings of the user, system administrator
and distributor for customization or preconfiguration. The initialization le ~/.emacs is in-
stalled to the home directories of the individual users from /etc/skel . .emacs , in turn, reads
the le /etc/skel/.gnu-emacs . To customize the program, copy .gnu-emacs to the home di-
rectory (with cp /etc/skel/.gnu-emacs ~/.gnu-emacs ) and make the desired settings there.
.gnu-emacs defines the le ~/.gnu-emacs-custom as custom-file . If users make settings
with the customize options in Emacs, the settings are saved to ~/.gnu-emacs-custom .
144 Man Pages and Info Pages SUSE Linux Enterp… 11 SP4
With SUSE Linux Enterprise Server, the emacs package installs the le site-start.el in the
directory /usr/share/emacs/site-lisp . The le site-start.el is loaded before the ini-
tialization le ~/.emacs . Among other things, site-start.el ensures that special configura-
tion les distributed with Emacs add-on packages, such as psgml , are loaded automatically.
Configuration les of this type are located in /usr/share/emacs/site-lisp , too, and always
begin with suse-start- . The local system administrator can specify systemwide settings in
default.el .
More information about these les is available in the Emacs info le under Init File: in-
fo:/emacs/InitFile . Information about how to disable the loading of these les (if necessary)
is also provided at this location.
The components of Emacs are divided into several packages:
emacs-el : the uncompiled library les in Emacs Lisp. These are not required at runtime.
/etc/inputrc
/etc/X11/Xmodmap
/etc/skel/.emacs
/etc/skel/.gnu-emacs
/etc/skel/.vimrc
/etc/csh.cshrc
/etc/termcap
/usr/share/terminfo/x/xterm
/usr/share/X11/app-defaults/XTerm
/usr/share/emacs/VERSION/site-lisp/term/*.el
These changes only affect applications that use terminfo entries or whose configuration les
are changed directly ( vi , emacs , etc.). Applications not shipped with the system should be
adapted to these defaults.
Under X, the compose key (multikey) can be enabled as explained in /etc/X11/Xmodmap .
Further settings are possible using the X Keyboard Extension (XKB). This extension is also used
by the desktop environments GNOME (gswitchit) and KDE (kxkb).
RC_LC_ALL
This variable, if set, overwrites the values of the variables already mentioned.
RC_LANG
If none of the previous variables are set, this is the fallback. By default, only RC_LANG is
set. This makes it easier for users to enter their own values.
ROOT_USES_LANG
A yes or no variable. If set to no , root always works in the POSIX environment.
The variables can be set with the YaST sysconfig editor (see Section 10.3.1, “Changing the System
Configuration Using the YaST sysconfig Editor”). The value of such a variable contains the language
code, country code, encoding and modifier. The individual components are connected by special
characters:
LANG=<language>[[_<COUNTRY>].<Encoding>[@<Modifier>]]
LANG=en_US.UTF-8
This is the default setting if American English is selected during installation. If you selected
another language, that language is enabled but still with UTF-8 as the character encoding.
LANG=en_US.ISO-8859-1
This sets the language to English, country to United States and the character set to
ISO-8859-1 . This character set does not support the Euro sign, but it can be useful some-
times for programs that have not been updated to support UTF-8 . The string defining the
charset ( ISO-8859-1 in this case) is then evaluated by programs like Emacs.
LANG=en_IE@euro
The above example explicitly includes the Euro sign in a language setting. This setting
is basically obsolete now, as UTF-8 also covers the Euro symbol. It is only useful if an
application supports ISO-8859-15 and not UTF-8.
In former releases, it was necessary to run SuSEconfig after doing any changes to /etc/
sysconfig/language . SuSEconfig then wrote the changes to /etc/SuSEconfig/profile and
/etc/SuSEconfig/csh.login . Upon login, these les were read by /etc/profile (for the
Bash) or by /etc/csh.login (for the tcsh) .
In recent releases, /etc/SuSEconfig/profile has been replaced with /etc/pro-
file.d/lang.sh , and /etc/SuSEconfig/csh.login with /etc/profile.de/lang.csh . But
if they exist, both legacy le are still read upon login.
The process chain is now as follows:
LANG=cs_CZ.UTF-8
LC_COLLATE=C
A fallback chain can also be defined, for example, for Breton to French or for Galician to Spanish
to Portuguese:
LANGUAGE="br_FR:fr_FR"
LANGUAGE="gl_ES:es_ES:pt_PT"
If desired, use the Norwegian variants Nynorsk and Bokmål instead (with additional fallback
to no ):
LANG="nn_NO"
LANGUAGE="nn_NO:nb_NO:no"
or
LANG="nb_NO"
LANGUAGE="nb_NO:nn_NO:no"
The GNU C Library Reference Manual, Chapter “Locales and Internationalization”. It is in-
cluded in glibc-info . The package is available from the SUSE Linux Enterprise Software
Development Kit (SDK). The SDK is an add-on product for SUSE Linux Enterprise and is
available for download from http://download.suse.com/ .
Markus Kuhn, UTF-8 and Unicode FAQ for Unix/Linux, currently at http://www.cl.cam.ac.uk/
~mgk25/unicode.html .
SUSE® Linux Enterprise Server supports printing with many types of printers, including remote
network printers. Printers can be configured manually or with YaST. For configuration instruc-
tions, refer to Book “Deployment Guide”, Chapter 8 “Setting Up Hardware Components with YaST”, Sec-
tion 8.5 “Setting Up a Printer”. Both graphical and command line utilities are available for starting
and managing print jobs. If your printer does not work as expected, refer to Section 14.7, “Trou-
bleshooting”.
CUPS (Common Unix Printing System) is the standard print system in SUSE Linux Enterprise
Server.
Printers can be distinguished by interface, such as USB or network, and printer language. When
buying a printer, make sure that the printer has an interface (like USB or parallel port) that is
available on your hardware and a suitable printer language. Printers can be categorized on the
basis of the following three classes of printer languages:
PostScript Printers
PostScript is the printer language in which most print jobs in Linux and Unix are generat-
ed and processed by the internal print system. If PostScript documents can be processed
directly by the printer and do not need to be converted in additional stages in the print
system, the number of potential error sources is reduced.
Before you buy a new printer, refer to the following sources to check how well the printer you
intend to buy is supported:
http://www.openprinting.org/printers/
The OpenPrinting home page with the printer database. The database shows the latest
Linux support status. However, a Linux distribution can only integrate the drivers available
at production time. Accordingly, a printer currently rated as “perfectly supported” may not
have had this status when the latest SUSE Linux Enterprise Server version was released.
Thus, the databases may not necessarily indicate the correct status, but only provide an
approximation.
http://pages.cs.wisc.edu/~ghost/
The Ghostscript Web page.
/usr/share/doc/packages/ghostscript-library/catalog.devices
List of included drivers.
152 The Workflow of the Printing System SUSE Linux Enterp… 11 SP4
If you use a PostScript printer, the filter system converts the data into printer-specific PostScript.
This does not require a printer driver. If you use a non-PostScript printer, the filter system con-
verts the data into printer-specific data. This requires a printer driver suitable for your printer.
The back-end receives the printer-specific data from the filter then passes it to the printer.
153 Methods and Protocols for Connecting Printers SUSE Linux Enterp… 11 SP4
New PPD les can be stored in the directory /usr/share/cups/model/ or added to the print
system with YaST as described in Book “Deployment Guide”, Chapter 8 “Setting Up Hardware Com-
ponents with YaST”, Section 8.5 “Setting Up a Printer”, Section 8.5.1 “Configuring Local Printers”, Sec-
tion 8.5.1.1 “Adding Drivers with YaST”. Subsequently, the PPD le can be selected during the printer
setup.
Be careful if a printer manufacturer wants you to install entire software packages. First, this
kind of installation may result in the loss of the support provided by SUSE Linux Enterprise
Server and second, print commands may work differently and the system may no longer be
able to address devices of other manufacturers. For this reason, the installation of manufacturer
software is not recommended.
socket
Socket refers to a connection in which the plain print data is sent directly to a TCP socket.
Some of the socket port numbers that are commonly used are 9100 or 35 . The device URI
(uniform resource identifier) syntax is: socket:// IP.of.the.printer : port , for example:
socket://192.168.2.202:9100/ .
The protocol supported by the printer must be determined before configuration. If the manufac-
turer does not provide the needed information, the command nmap (which comes with the nmap
package) can be used to ascertain the protocol. nmap checks a host for open ports. For example:
With lpadmin the CUPS server administrator can add, remove or manage print queues. To add
a print queue, use the following syntax:
Then the device ( -v ) is available as queue ( -p ), using the specified PPD le ( -P ). This means
that you must know the PPD le and the device URI to configure the printer manually.
155 Configuring CUPS with Command Line Tools SUSE Linux Enterp… 11 SP4
Do not use -E as the rst option. For all CUPS commands, -E as the rst argument sets use
of an encrypted connection. To enable the printer, -E must be used as shown in the following
example:
lpadmin -p ps -v parallel:/dev/lp0 -P \
/usr/share/cups/model/Postscript.ppd.gz -E
lpadmin -p ps -v socket://192.168.2.202:9100/ -P \
/usr/share/cups/model/Postscript-level1.ppd.gz -E
lpoptions -p queue -l
Example:
lpoptions -p queue -l
When a normal user runs lpoptions , the settings are written to ~/.cups/lpoptions . How-
ever, root settings are written to /etc/cups/lpoptions .
156 Configuring CUPS with Command Line Tools SUSE Linux Enterp… 11 SP4
14.5 Printing from the Command Line
To print from the command line, enter lp -d queuename filename , substituting the corre-
sponding names for queuename and filename .
Some applications rely on the lp command for printing. In this case, enter the correct command
in the application's print dialog, usually without specifying filename , for example, lp -d
queuename .
Normally, a CUPS client runs on a regular workstation located in a trusted network environment
behind a firewall. In this case it is recommended to configure the network interface to be in the
Internal Zone , so the workstation is reachable from within the network.
If the CUPS server is part of a trusted network environment protected by a firewall, the network
interface should be configured to be in the Internal Zone of the firewall. It is not recommended
to set up a CUPS server in an untrusted network environment unless you take care that it is
protected by special firewall rules and secure settings in the CUPS configuration.
157 Printing from the Command Line SUSE Linux Enterp… 11 SP4
14.6.2 PPD Files in Various Packages
The YaST printer configuration sets up the queues for CUPS using the PPD les installed in /
usr/share/cups/model . To nd the suitable PPD les for the printer model, YaST compares
the vendor and model determined during hardware detection with the vendors and models in
all PPD les. For this purpose, the YaST printer configuration generates a database from the
vendor and model information extracted from the PPD les.
The configuration using only PPD les and no other information sources has the advantage
that the PPD les in /usr/share/cups/model can be modified freely. For example, if you
only have PostScript printers, normally you do not need the Foomatic PPD les in the cups-
drivers package or the Gutenprint PPD les in the gutenprint package. Instead, the PPD
les for your PostScript printers can be copied directly to /usr/share/cups/model (if they do
not already exist in the manufacturer-PPDs package) to achieve an optimum configuration
for your printers.
The generic PPD les in the cups package have been complemented with adapted Foomatic
PPD les for PostScript level 1 and level 2 printers:
/usr/share/cups/model/Postscript-level1.ppd.gz
/usr/share/cups/model/Postscript-level2.ppd.gz
Normally, the Foomatic printer filter foomatic-rip is used together with Ghostscript for non-
PostScript printers. Suitable Foomatic PPD les have the entries *NickName: ... Foomat-
ic/Ghostscript driver and *cupsFilter: ... foomatic-rip . These PPD les are located
in the cups-drivers package.
YaST generally prefers a manufacturer-PPD le. However, when no suitable manufactur-
er-PPD le exists, a Foomatic PPD le with the entry *NickName: ... Foomatic ... (rec-
ommended) is selected.
14.7 Troubleshooting
The following sections cover some of the most frequently encountered printer hardware and
software problems and ways to solve or circumvent these problems. Among the topics covered
are GDI printers, PPD les and port configuration. Common network printer problems, defective
printouts, and queue handling are also addressed.
These printers do not support any common printer language and can only be addressed with
special proprietary control sequences. Therefore they can only work with the operating system
versions for which the manufacturer delivers a driver. GDI is a programming interface developed
by Microsoft* for graphics devices. Usually the manufacturer delivers drivers only for Windows,
and since the Windows driver uses the GDI interface these printers are also called GDI printers.
The actual problem is not the programming interface, but the fact that these printers can only
be addressed with the proprietary printer language of the respective printer model.
Interrupt: irrelevant
160 No Suitable PPD File Available for a PostScript Printer SUSE Linux Enterp… 11 SP4
Mode: Normal , SPP , or Output Only
DMA: disabled
If the printer cannot be addressed on the parallel port despite these settings, enter the I/O ad-
dress explicitly in accordance with the setting in the BIOS in the form 0x378 in /etc/mod-
probe.conf . If there are two parallel ports that are set to the I/O addresses 378 and 278
(hexadecimal), enter these in the form 0x378,0x278 .
If interrupt 7 is free, it can be activated with the entry shown in Example 14.1, “/etc/mod-
probe.conf: Interrupt Mode for the First Parallel Port”. Before activating the interrupt mode, check
the le /proc/interrupts to see which interrupts are already in use. Only the interrupts cur-
rently being used are displayed. This may change depending on which hardware components
are active. The interrupt for the parallel port must not be used by any other device. If you are
not sure, use the polling mode with irq=none .
If the connection to lpd cannot be established, lpd may not be active or there may be
basic network problems.
echo -e "\004queue" \
| netcat -w 2 -p 722 host 515
If lpd does not respond, it may not be active or there may be basic network problems.
If lpd responds, the response should show why printing is not possible on the queue on
host . If you receive a response like that shown in Example 14.2, “Error Message from lpd”,
the problem is caused by the remote lpd .
If a broadcasting CUPS network server exists, the output appears as shown in Example 14.3,
“Broadcast from the CUPS Network Server”.
ipp://192.168.2.202:631/printers/queue
IBM Z Take into account that IBM System z ethernet devices do not receive broadcasts
by default.
The following command can be used to test if a TCP connection can be established to
cupsd (port 631 ) on host :
This output indicates that the printer connected to the print server box can be addressed
via TCP socket on port 9100 . By default, nmap only checks a number of commonly known
ports listed in /usr/share/nmap/nmap-services . To check all possible ports, use the
command nmap -p from_port - to_port IP-address . This may take some time. For
further information, refer to the man page of nmap .
Enter a command like
164 Defective Printouts without Error Message SUSE Linux Enterp… 11 SP4
14.7.8 Defective Print Jobs and Data Transfer Errors
If you switch the printer o or shut down the computer during the printing process, print jobs
remain in the queue. Printing resumes when the computer (or the printer) is switched back on.
Defective print jobs must be removed from the queue with cancel .
If a print job is defective or an error occurs in the communication between the host and the
printer, the printer prints numerous sheets of paper with unintelligible characters, because it is
unable to process the data correctly. To rectify this situation, follow these steps:
1. To stop printing, remove all paper from ink jet printers or open the paper trays of laser
printers. High-quality printers have a button for canceling the current printout.
2. The print job may still be in the queue, because jobs are only removed after they are sent
completely to the printer. Use lpstat -o or lpstat -h cups.example.com -o to check
which queue is currently printing. Delete the print job with cancel queue - jobnumber
or cancel -h cups.example.com queue - jobnumber .
3. Some data may still be transferred to the printer even though the print job has been deleted
from the queue. Check if a CUPS back-end process is still running for the respective queue
and terminate it. For example, for a printer connected to the parallel port, the command
fuser -k /dev/lp0 can be used to terminate all processes that are still accessing the
printer (more precisely: the parallel port).
4. Reset the printer completely by switching it o for some time. Then insert the paper and
turn on the printer.
2. Stop cupsd .
4. Start cupsd .
165 Defective Print Jobs and Data Transfer Errors SUSE Linux Enterp… 11 SP4
6. Check the messages in /var/log/cups/error_log* to identify the cause of the problem.
Every received event is matched against the set of provides rules. The rules can add or change
event environment keys, request a specific name for the device node to create, add symlinks
pointing to the node or add programs to run after the device node is created. The driver core
uevents are received from a kernel netlink socket.
MODALIAS=usb:v046DpC03Ed2000dc00dsc00dp00ic03isc01ip02
Every device driver carries a list of known aliases for devices it can handle. The list is contained
in the kernel module le itself. The program depmod reads the ID lists and creates the le
modules.alias in the kernel's /lib/modules directory for all currently available modules.
With this infrastructure, module loading is as easy as calling modprobe for every event that
carries a MODALIAS key. If modprobe $MODALIAS is called, it matches the device alias composed
for the device with the aliases provided by the modules. If a matching entry is found, that module
is loaded. All this is automatically triggered by udev .
168 Drivers, Kernel Modules and Devices SUSE Linux Enterp… 11 SP4
As an example, a USB mouse present during boot may not be initialized by the early boot logic,
because the driver is not available at that time. The event for the device discovery was lost
and failed to nd a kernel module for the device. Instead of manually searching for possibly
connected devices, udev just requests all device events from the kernel after the root le system
is available, so the event for the USB mouse device just runs again. Now it nds the kernel
module on the mounted root le system and the USB mouse can be initialized.
From userspace, there is no visible difference between a device coldplug sequence and a device
discovery during runtime. In both cases, the same rules are used to match and the same config-
ured programs are run.
The UEVENT lines show the events the kernel has sent over netlink. The UDEV lines show the
finished udev event handlers. The timing is printed in microseconds. The time between UEVENT
and UDEV is the time udev took to process this event or the udev daemon has delayed its
execution to synchronize this event with related and already running events. For example, events
for hard disk partitions always wait for the main disk device event to finish, because the partition
events may rely on the data that the main disk event has queried from the hardware.
169 Monitoring the Running udev Daemon SUSE Linux Enterp… 11 SP4
udevadm monitor --env shows the complete event environment:
ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.0/input/input10
SUBSYSTEM=input
SEQNUM=1181
NAME="Logitech USB-PS/2 Optical Mouse"
PHYS="usb-0000:00:1d.2-1/input0"
UNIQ=""
EV=7
KEY=70000 0 0 0 0
REL=103
MODALIAS=input:b0003v046DpC03Ee0110-e0,1,2,k110,111,112,r0,1,8,amlsfw
udev also sends messages to syslog. The default syslog priority that controls which messages
are sent to syslog is specified in the udev configuration le /etc/udev/udev.conf . The log
priority of the running daemon can be changed with udevadm control log_priority= lev-
el/number .
Every line in the rules le contains at least one key value pair. There are two kinds of keys,
match and assignment keys. If all match keys match their values, the rule is applied and the
assignment keys are assigned the specified value. A matching rule may specify the name of the
device node, add symlinks pointing to the node or run a specified program as part of the event
handling. If no matching rule is found, the default device node name is used to create the device
node. Detailed information about the rule syntax and the provided keys to match or import data
are described in the udev man page. The following example rules provide a basic introduction
to udev rule syntax. The example rules are all taken from the udev default rule set that is
located under /etc/udev/rules.d/50-udev-default.rules .
# console
170 Influencing Kernel Device Event Handling with udev Rules SUSE Linux Enterp… 11 SP4
KERNEL=="console", MODE="0600", OPTIONS="last_rule"
# serial devices
KERNEL=="ttyUSB*", ATTRS{product}=="[Pp]alm*Handheld*", SYMLINK+="pilot"
# printer
SUBSYSTEM=="usb", KERNEL=="lp*", NAME="usb/%k", SYMLINK+="usb%k", GROUP="lp"
The console rule consists of three keys: one match key ( KERNEL ) and two assign keys ( MODE ,
OPTIONS ). The KERNEL match rule searches the device list for any items of the type console .
Only exact matches are valid and trigger this rule to be executed. The MODE key assigns special
permissions to the device node, in this case, read and write permissions to the owner of this
device only. The OPTIONS key makes this rule the last rule to be applied to any device of this
type. Any later rule matching this particular device type does not have any effect.
The serial devices rule is not available in 50-udev-default.rules anymore, but it is
still worth considering. It consists of two match keys ( KERNEL and ATTRS ) and one assign key
( SYMLINK ). The KERNEL key searches for all devices of the ttyUSB type. Using the * wild card,
this key matches several of these devices. The second match key, ATTRS , checks whether the
product attribute le in sysfs for any ttyUSB device contains a certain string. The assign
key ( SYMLINK ) triggers the addition of a symbolic link to this device under /dev/pilot . The
operator used in this key ( += ) tells udev to additionally perform this action, even if previous
or later rules add other symbolic links. As this rule contains two match keys, it is only applied
if both conditions are met.
The printer rule deals with USB printers and contains two match keys which must both apply
to get the entire rule applied ( SUBSYSTEM and KERNEL ). Three assign keys deal with the naming
for this device type ( NAME ), the creation of symbolic device links ( SYMLINK ) and the group
membership for this device type ( GROUP ). Using the * wild card in the KERNEL key makes it
match several lp printer devices. Substitutions are used in both, the NAME and the SYMLINK
keys to extend these strings by the internal device name. For example, the symlink to the rst
lp USB printer would read /dev/usblp0 .
The kernel firmware loader rule makes udev load additional rmware by an external helper
script during runtime. The SUBSYSTEM match key searches for the firmware subsystem. The
ACTION key checks whether any device belonging to the firmware subsystem has been added.
The RUN+= key triggers the execution of the firmware.sh script to locate the rmware that
is to be loaded.
171 Influencing Kernel Device Event Handling with udev Rules SUSE Linux Enterp… 11 SP4
Some general characteristics are common to all rules:
Each rule consists of one or more key value pairs separated by a comma.
A key's operation is determined by the operator. udev rules support several different op-
erators.
Each line of the rules le represents one rule. If a rule is longer than just one line, use \
to join the different lines just as you would do in shell syntax.
udev rules support a shell-style pattern that matches the * , ? , and [] patterns.
==
Compare for equality. If the key contains a search pattern, all results matching this pattern
are valid.
!=
Compare for non-equality. If the key contains a search pattern, all results matching this
pattern are valid.
=
Assign a value to a key. If the key previously consisted of a list of values, the key resets
and only the single value is assigned.
+=
Add a value to a key that contains a list of entries.
:=
%r , $root
The device directory, /dev by default.
%p , $devpath
The value of DEVPATH .
%k , $kernel
The value of KERNEL or the internal device name.
%n , $number
The device number.
%N , $tempnode
The temporary name of the device le.
%M , $major
The major number of the device.
%m , $minor
The minor number of the device.
%s{attribute} , $attr{attribute}
The value of a sysfs attribute (specified by attribute ).
%E{variable} , $attr{variable}
The value of an environment variable (specified by variable ).
%c , $result
The output of PROGRAM .
%%
The % character.
$$
ACTION
The name of the event action, for example, add or remove when adding or removing a
device.
DEVPATH
The device path of the event device, for example, DEVPATH=/bus/pci/drivers/ipw3945
to search for all events related to the ipw3945 driver.
KERNEL
The internal (kernel) name of the event device.
SUBSYSTEM
The subsystem of the event device, for example, SUBSYSTEM=usb for all events related to
USB devices.
ATTR{filename}
sysfs attributes of the event device. To match a string contained in the vendor attribute
le name, you could use ATTR{vendor}=="On[sS]tream" , for example.
KERNELS
Let udev search the device path upwards for a matching device name.
SUBSYSTEMS
Let udev search the device path upwards for a matching device subsystem name.
DRIVERS
Let udev search the device path upwards for a matching device driver name.
ATTRS{filename}
Let udev search the device path upwards for a device with matching sysfs attribute
values.
ENV{key}
PROGRAM
Let udev execute an external program. To be successful, the program must return with
exit code zero. The program's output, printed to stdout, is available to the RESULT key.
RESULT
Match the output string of the last PROGRAM call. Either include this key in the same rule
as the PROGRAM key or in a later one.
NAME
The name of the device node to be created. Once a rule has set a node name, all other
rules with a NAME key for this node are ignored.
SYMLINK
The name of a symlink related to the node to be created. Multiple matching rules can add
symlinks to be created with the device node. You can also specify multiple symlinks for
one node in one rule using the space character to separate the symlink names.
ATTR{key}
Specify a value to be written to a sysfs attribute of the event device. If the == operator
is used, this key is also used to match against the value of a sysfs attribute.
ENV{key}
Tell udev to export a variable to the environment. If the == operator is used, this key is
also used to match against an environment variable.
RUN
Tell udev to add a program to the list of programs to be executed for this device. Keep in
mind to restrict this to very short tasks to avoid blocking further events for this device.
GOTO
Tell udev to skip a number of rules and continue with the one that carries the label
referenced by the GOTO key.
IMPORT{type}
Load variables into the event environment such as the output of an external program. udev
imports variables of several different types. If no type is specified, udev tries to determine
the type itself based on the executable bit of the le permissions.
program tells udev to execute an external program and import its output.
parent tells udev to import the stored keys from the parent device.
WAIT_FOR_SYSFS
Tells udev to wait for the specified sysfs le to be created for a certain device. For
example, WAIT_FOR_SYSFS="ioerr_cnt" informs udev to wait until the ioerr_cnt le
has been created.
OPTIONS
The OPTION key may have several possible values:
ignore_remove tells udev to ignore all later remove events for the device.
all_partitions tells udev to create device nodes for all available partitions on a
block device.
/dev/disk
|-- by-id
| |-- scsi-SATA_HTS726060M9AT00_MRH453M4HWHG7B -> ../../sda
| |-- scsi-SATA_HTS726060M9AT00_MRH453M4HWHG7B-part1 -> ../../sda1
| |-- scsi-SATA_HTS726060M9AT00_MRH453M4HWHG7B-part6 -> ../../sda6
| |-- scsi-SATA_HTS726060M9AT00_MRH453M4HWHG7B-part7 -> ../../sda7
| |-- usb-Generic_STORAGE_DEVICE_02773 -> ../../sdd
| `-- usb-Generic_STORAGE_DEVICE_02773-part1 -> ../../sdd1
|-- by-label
| |-- Photos -> ../../sdd1
| |-- SUSE10 -> ../../sda7
| `-- devel -> ../../sda6
|-- by-path
| |-- pci-0000:00:1f.2-scsi-0:0:0:0 -> ../../sda
| |-- pci-0000:00:1f.2-scsi-0:0:0:0-part1 -> ../../sda1
| |-- pci-0000:00:1f.2-scsi-0:0:0:0-part6 -> ../../sda6
| |-- pci-0000:00:1f.2-scsi-0:0:0:0-part7 -> ../../sda7
| |-- pci-0000:00:1f.2-scsi-1:0:0:0 -> ../../sr0
| |-- usb-02773:0:0:2 -> ../../sdd
| |-- usb-02773:0:0:2-part1 -> ../../sdd1
`-- by-uuid
|-- 159a47a4-e6e6-40be-a757-a629991479ae -> ../../sda7
|-- 3e999973-00c9-4917-9442-b7633bd95b9e -> ../../sda6
`-- 4210-8F8C -> ../../sdd1
/dev/*
Dynamically created device nodes and static content copied at boot time from /lib/udev/
devices/*
The following les and directories contain the crucial elements of the udev infrastructure:
/etc/udev/udev.conf
/etc/udev/rules.d/*
udev event matching rules.
/lib/udev/devices/*
Static /dev content.
/lib/udev/*
Helper programs called from udev rules.
udev
General information about udev , keys, rules and other important configuration issues.
udevadm
udevadm can be used to control the runtime behavior of udev , request kernel events,
manage the event queue and provide simple debugging mechanisms.
udevd
Information about the udev event managing daemon.
The X Window System (X11) is the de facto standard for graphical user interfaces in UNIX. X
is network-based, enabling applications started on one host to be displayed on another host
connected over any kind of network (LAN or Internet). This chapter describes the setup and
optimization of the X Window System environment, and provides background information about
the use of fonts in SUSE® Linux Enterprise Server.
179 Manually Configuring the X Window System SUSE Linux Enterp… 11 SP4
The command sax2 creates the /etc/X11/xorg.conf le. This is the primary configuration
le of the X Window System. Find all the settings here concerning your graphics card, mouse
and monitor.
The following sections describe the structure of the configuration le /etc/X11/xorg.conf . It
consists of several sections, each one dealing with a certain aspect of the configuration. Each
section starts with the keyword Section <designation> and ends with EndSection . The
following convention applies to all sections:
Section "designation"
entry 1
entry 2
entry n
EndSection
TABLE 16.1: SECTIONS IN /ETC/X11/XORG.CONF
Type Meaning
Files The paths used for fonts and the RGB color
table.
180 Manually Configuring the X Window System SUSE Linux Enterp… 11 SP4
Type Meaning
tions defining the Protocol and Device .
You normally have one InputDevice sec-
tion per device attached to the computer.
181 Manually Configuring the X Window System SUSE Linux Enterp… 11 SP4
Type Meaning
ver used. For example, if you use the i810
driver, nd more information about the
available options in the manual page man 4
i810 .
Monitor , Device and Screen are explained in more detail. Further information about the
other sections can be found in the manual pages of X.Org and xorg.conf .
There can be several different Monitor and Device sections in xorg.conf . Even multiple
Screen sections are possible. The ServerLayout section determines which of these sections
is used.
182 Manually Configuring the X Window System SUSE Linux Enterp… 11 SP4
16.1.1 Screen Section
The screen section combines a monitor with a device section and determines the resolution and
color depth to use. A screen section might resemble Example 16.1, “Screen Section of the File /etc/
X11/xorg.conf”.
Section "Screen" 1
DefaultDepth 16 2
SubSection "Display" 3
Depth 16 4
Virtual 1152x864 6
EndSubSection
SubSection "Display"
Depth 24
Modes "1280x1024"
EndSubSection
SubSection "Display"
Depth 32
Modes "640x480"
EndSubSection
SubSection "Display"
Depth 8
Modes "1280x1024"
EndSubSection
Device "Device[0]"
Identifier "Screen[0]" 7
Monitor "Monitor[0]"
EndSection
2 DefaultDepth determines the color depth to use by default unless another color depth
is explicitly specified.
3 For each color depth, different Display subsections are specified.
4 Depth determines the color depth to be used with this set of Display settings. Possible
values are 8 , 15 , 16 , 24 and 32 , though not all of these might be supported by all X
server modules or resolutions.
A device section describes a specific graphics card. You can have as many device entries in
xorg.conf as you like, provided their names are differentiated using the keyword Identifier .
If you have more than one graphics card installed, the sections are simply numbered in order.
The rst one is called Device[0] , the second one Device[1] , and so on. The following le
shows an excerpt from the Device section of a computer with a Matrox Millennium PCI graphics
card (as configured by SaX2):
Section "Device"
BoardName "MGA2064W"
BusID "0:19:0" 1
Identifier "Device[0]"
VendorName "Matrox"
Option "sw_cursor"
EndSection
1 The BusID refers to the PCI or AGP slot in which the graphics card is installed. This matches
the ID displayed by the command lspci . The X server needs details in decimal form, but
lspci displays these in hexadecimal form. The value of BusID is automatically detected
by SaX2.
2 The value of Driver is automatically set by SaX2 and specifies which driver to use for your
graphics card. If the card is a Matrox Millennium, the driver module is called mga . The
X server then searches through the ModulePath defined in the Files section in the dri-
vers subdirectory. In a standard installation, this is the /usr/lib/xorg/modules/dri-
vers directory or the /usr/lib64/xorg/modules/drivers directory for 64-Bit operating
systems directory. _drv.o is added to the name, so, in the case of the mga driver, the
driver le mga_drv.o is loaded.
The behavior of the X server or of the driver can also be influenced through additional options.
An example of this is the option sw_cursor , which is set in the device section. This deactivates
the hardware mouse cursor and depicts the mouse cursor using software. Depending on the
driver module, there are various options available (which can be found in the description les
of the driver modules in the directory /usr/share/doc/packages/package_name ). Generally
valid options can also be found in the manual pages ( man xorg.conf , man 4 <driver mod-
ule> , and man 4 chips ).
If the graphics card has multiple video connectors, it is possible to configure the different devices
of this single card as one single view. Use SaX2 to set up your graphics interface this way.
Like the Device sections, the Monitor and Modes sections describe one monitor each. The
configuration le /etc/X11/xorg.conf can contain as many Monitor sections as desired. Each
Monitor section references a Modes section with the line UseModes if available. If no Modes
section is available for the Monitor section, the X server calculates appropriate values from
the general synchronization values. The server layout section specifies which Monitor section
is relevant.
Warning
Unless you have in-depth knowledge of monitor and graphics card functions, do not
change the modelines, because this could severely damage your monitor.
Those who try to develop their own monitor descriptions should be very familiar with the docu-
mentation in /usr/share/X11/doc . Install the package xorg-x11-doc to nd PDFs and HTML
pages.
Manual specification of modelines is rarely required today. If you are using a modern multisync
monitor, the allowed frequencies and optimal resolutions can, as a rule, be read directly from
the monitor by the X server via DDC, as described in the SaX2 configuration section. If this is
not possible for some reason, use one of the VESA modes included in the X server. This will
work with most graphics card and monitor combinations.
The following is an excerpt from /etc/fonts/fonts.conf . This le is the standard configura-
tion le that should be appropriate for most configurations. It also defines the included direc-
tory /etc/fonts/conf.d . In this directory, all les or symbolic links starting with a two digit
number are loaded by fontconfig. For a more detailed explanation of this functionality, have a
look at /etc/fonts/conf.d/README .
<dir>/usr/lib/Adobe/Reader9/Resource/Font</dir>
<dir>/usr/lib/Adobe/Reader9/Resource/Font/PFM</dir>
To install additional fonts system-wide, manually copy the font les to a suitable directory (as
root ), such as /usr/share/fonts/truetype . Alternatively, the task can be performed with
the KDE font installer in the KDE Control Center. The result is the same.
Instead of copying the actual fonts, you can also create symbolic links. For example, you may
want to do this if you have licensed fonts on a mounted Windows partition and want to use
them. Subsequently, run SuSEconfig --module fonts .
SuSEconfig --module fonts executes the script /usr/sbin/fonts-config , which handles
the font configuration. For more information on this script, refer to its manual page ( man fonts-
config ).
The procedure is the same for bitmap fonts, TrueType and OpenType fonts, and Type1
(PostScript) fonts. All these font types can be installed into any directory.
X.Org contains two completely different font systems: the old X11 core font system and the newly
designed Xft and fontconfig system. The following sections briey describe these two systems.
Today, the X11 core font system supports not only bitmap fonts but also scalable fonts, like Type1
fonts, TrueType, and OpenType fonts. Scalable fonts are only supported without anti-aliasing
and subpixel rendering and the loading of large scalable fonts with glyphs for many languages
may take a long time. Unicode fonts are also supported, but their use may be slow and require
more memory.
The X11 core font system has a few inherent weaknesses. It is outdated and can no longer
be extended in any meaningful way. Although it must be retained for reasons of backward
compatibility, the more modern Xft and fontconfig system should be used if at all possible.
If the X server is already active, newly installed fonts in mounted directories can be made avail-
able with the command xset fp rehash . This command is executed by SuSEconfig --mod-
ule fonts . Because the command xset needs access to the running X server, this only works
if SuSEconfig --module fonts is started from a shell that has access to the running X server.
The easiest way to achieve this is to acquire root permissions by entering su and the root
password. su transfers the access permissions of the user who started the X server to the root
shell. To check if the fonts were installed correctly and are available by way of the X11 core
font system, use the command xlsfonts to list all available fonts.
By default, SUSE Linux Enterprise Server uses UTF-8 locales. Therefore, Unicode fonts should
be preferred (font names ending with iso10646-1 in xlsfonts output). All available Unicode
fonts can be listed with xlsfonts | grep iso10646-1 . Nearly all Unicode fonts available
in SUSE Linux Enterprise Server contain at least the glyphs needed for European languages
(formerly encoded as iso-8859-* ).
16.2.2 Xft
From the outset, the programmers of Xft made sure that scalable fonts including anti-aliasing are
well supported. If Xft is used, the fonts are rendered by the application using the fonts, not by the
X server as in the X11 core font system. In this way, the respective application has access to the
actual font les and full control of how the glyphs are rendered. This constitutes the basis for the
correct display of text in a number of languages. Direct access to the font les is very useful for
embedding fonts for printing to make sure that the printout looks the same as the screen output.
In SUSE Linux Enterprise Server, the two desktop environments (KDE and GNOME), Mozilla
and many other applications already use Xft by default. Xft is already used by more applications
than the old X11 core font system.
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
</fontconfig>
To add directories to search for fonts, append lines such as the following:
<dir>/usr/local/share/fonts/</dir>
However, this is usually not necessary. By default, the user-specific directory ~/.fonts is al-
ready entered in /etc/fonts/fonts.conf . Accordingly, all you need to do to install additional
fonts is to copy them to ~/.fonts .
You can also insert rules that influence the appearance of the fonts. For example, enter
<match target="font">
<edit name="antialias" mode="assign">
<bool>false</bool>
</edit>
</match>
<match target="font">
<test name="family">
<string>Luxi Mono</string>
<string>Luxi Sans</string>
</test>
<edit name="antialias" mode="assign">
<bool>false</bool>
</edit>
</match>
<alias>
<family>sans-serif</family>
<prefer>
<family>FreeSans</family>
</prefer>
</alias>
<alias>
<family>serif</family>
<prefer>
<family>FreeSerif</family>
</prefer>
</alias>
<alias>
<family>monospace</family>
<prefer>
<family>FreeMono</family>
</prefer>
</alias>
Because nearly all applications use these aliases by default, this affects almost the entire system.
Thus, you can easily use your favorite fonts almost everywhere without having to modify the
font settings in the individual applications.
Use the command fc-list to nd out which fonts are installed and available for use. For
instance, the command fc-list returns a list of all fonts. To nd out which of the available
scalable fonts ( :scalable=true ) contain all glyphs required for Hebrew ( :lang=he ), their
font names ( family ), their style ( style ), their weight ( weight ) and the name of the les
containing the fonts, enter the following command:
Lucida Sans:style=Demibold:weight=200
DejaVu Sans:style=Bold Oblique:weight=200
Lucida Sans Typewriter:style=Bold:weight=200
DejaVu Sans:style=Oblique:weight=80
Lucida Sans Typewriter:style=Regular:weight=80
DejaVu Sans:style=Book:weight=80
DejaVu Sans:style=Bold:weight=200
Lucida Sans:style=Regular:weight=80
TABLE 16.2: PARAMETERS OF fc-list
FUSE is the acronym for le system in userspace. This means you can configure and
mount a le system as an unprivileged user. Normally, you have to be root for this
task. FUSE alone is a kernel module. Combined with plug-ins, it allows you to ex-
tend FUSE to access almost all le systems like remote SSH connections, ISO im-
ages, and more.
Mobile computing is mostly associated with laptops, PDAs and cellular phones (and
the data exchange between them). Mobile hardware components, such as external
hard disks, ash drives, or digital cameras, can be connected to laptops or desktop
systems. A number of software components are involved in mobile computing sce-
narios and some applications are tailor-made for mobile use.
18.1 Laptops
The hardware of laptops differs from that of a normal desktop system. This is because criteria like
exchangeability, space requirements and power consumption must be taken into account. The
manufacturers of mobile hardware have developed standard interfaces like PCMCIA (Personal
Computer Memory Card International Association), Mini PCI and Mini PCIe that can be used to
extend the hardware of laptops. The standards cover memory cards, network interface cards,
ISDN (and modem cards) and external hard disks.
Detailed background information about power management in SUSE Linux Enterprise Server is
provided in Chapter 20, Power Management.
Your system needs to adapt to changing operating environments when used for mobile comput-
ing. Many services depend on the environment and the underlying clients must be reconfigured.
SUSE Linux Enterprise Server handles this task for you.
? ?
? ?
X configuration ? ?
? Proxy
Network
The services affected in the case of a laptop commuting back and forth between a small home
network and an office network are:
Network
This includes IP address assignment, name resolution, Internet connectivity and connec-
tivity to other networks.
Printing
A current database of available printers and an available print server must be present,
depending on the network.
X (Graphical Environment)
If your laptop is temporarily connected to a projector or an external monitor, different
display configurations must be available.
NetworkManager
NetworkManager is especially tailored for mobile networking on laptops. It provides a
means to easily and automatically switch between network environments or different types
of networks such as mobile broadband (such as GPRS, EDGE, or 3G), wireless LAN, and
Ethernet. NetworkManager supports WEP and WPA-PSK encryption in wireless LANs. It
also supports dial-up connections (with smpppd). Both desktop environments (GNOME
and KDE) include a front-end for NetworkManager. For more information about the desk-
top applets, see Section 27.4, “Using KNetworkManager” and Section 27.5, “Using the GNOME Net-
workManager Applet”.
is a laptop Yes
Use the YaST tools to configure networking whenever NetworkManager should not handle
network configuration.
Two KDE system monitoring tools are provided by SUSE Linux Enterprise Server:
Power Management
Power Management is an application which lets you adjust energy saving related behavior
of the KDE desktop. You can typically access it via the Battery Monitor tray icon, which
changes according to the type of the current power supply. Other way to open its con-
figuration dialog is through the Kickoff Application Launcher: Applications Configure Desk-
top Advanced Power Management.
Click the Battery Monitor tray icon to access options to configure its behavior. You can
choose one of ve displayed power profiles which best ts your needs. For example, the
Presentation scheme disables the screen saver and the power management in general, so
that your presentation is not interrupted by system events. Click More... to open a more
complex configuration screen. Here you can edit individual profiles and set advanced pow-
er management options and notifications, such as what to do when the laptop lid has been
closed, or when the battery charge is low.
In the GNOME environment use Power Management Preferences and System Monitor.
When switching between working on a mobile machine disconnected from the network and
working at a networked workstation in an office, it is necessary to keep processed data synchro-
nized across all instances. This could include e-mail folders, directories and individual les that
need to be present for work on the road as well as at the office. The solution in both cases is
as follows:
Synchronizing E-Mail
Use an IMAP account for storing your e-mails in the office network. Then access the e-mails
from the workstation using any disconnected IMAP–enabled e-mail client, like Mozilla
Thunderbird Mail, Evolution, or KMail. The e-mail client must be configured so that the
same folder is always accessed for Sent messages . This ensures that all messages are
available along with their status information after the synchronization process has com-
pleted. Use an SMTP server implemented in the mail client for sending messages instead of
the system-wide MTA postfix or sendmail to receive reliable feedback about unsent mail.
As well as connecting to a home or office network with a cable, a laptop can also use wireless
connection to access other computers, peripherals, cellular phones or PDAs. Linux supports three
types of wireless communication:
WLAN
With the largest range of these wireless technologies, WLAN is the only one suitable for
the operation of large and sometimes even spatially separate networks. Single machines
can connect with each other to form an independent wireless network or access the Inter-
net. Devices called access points act as base stations for WLAN-enabled devices and act as
intermediaries for access to the Internet. A mobile user can switch among access points
depending on location and which access point is offering the best connection. Like in cel-
lular telephony, a large network is available to WLAN users without binding them to a
specific location for accessing it. Find details about WLAN in Chapter 19, Wireless LAN.
Bluetooth
Bluetooth has the broadest application spectrum of all wireless technologies. It can be
used for communication between computers (laptops) and PDAs or cellular phones, as can
IrDA. It can also be used to connect various computers within range. Bluetooth is also
used to connect wireless system components, like a keyboard or a mouse. The range of this
technology is, however, not sufficient to connect remote systems to a network. WLAN is
the technology of choice for communicating through physical obstacles like walls.
IrDA
IrDA is the wireless technology with the shortest range. Both communication parties must
be within viewing distance of each other. Obstacles like walls cannot be overcome. One
possible application of IrDA is the transmission of a le from a laptop to a cellular phone.
The short path from the laptop to the cellular phone is then covered using IrDA. The long
range transport of the le to the recipient of the le is handled by the mobile network.
Another application of IrDA is the wireless transmission of printing jobs in the office.
Strong Authentication
Use biometric authentication in addition to standard authentication via login and pass-
word. SUSE Linux Enterprise Server supports fingerprint authentication. For more details,
see Book “Security Guide”, Chapter 7 “Using the Fingerprint Reader”.
Network Security
Any transfer of data should be secured, no matter how the transfer is done. Find general
security issues regarding Linux and networks in Book “Security Guide”, Chapter 1 “Security and
Confidentiality”. Security measures related to wireless networking are provided in Chapter 19,
Wireless LAN.
Wireless LANs, or Wireless Local Area Network (WLANs), have become an indis-
pensable aspect of mobile computing. Today, most laptops have built-in WLAN
cards. This chapter describes how to set up a WLAN card with YaST, encrypt trans-
missions, and use tips and tricks.
802.11 Legacy cards are not supported by SUSE® Linux Enterprise Server. Most cards using
802.11a, 802.11b, 802.11g and 802.11n are supported. New cards usually comply with the
802.11n standard, but cards using 802.11g are still available.
Master Mode
In master mode your network card is used as the access point. It works only if your
WLAN card supports this mode. Find out the details of your WLAN card on http://lin-
ux-wless.passys.nl .
None (Open)
An open system is a system that does not require authentication. Any station can join the
network. Nevertheless, WEP encryption can be used, see Section 19.4, “Encryption”.
Transport Layer Security (EAP-TLS): TLS authentication relies on the mutual ex-
change of certificates for both server and client. First, the server presents its certifi-
cate to the client where it is evaluated. If the certificate is considered valid, the client
in turn presents its certificate to the server. While TLS is secure, it requires a working
certification management infrastructure in your network. This infrastructure is rarely
found in private networks.
Protected Extensible Authentication Protocol (EAP-PEAP): Both TTLS and PEAP are
two-stage protocols. In the rst stage, a secure connection is established and in the
second the client authentication data is exchanged. They require far less certification
management overhead than TLS, if any.
19.4 Encryption
There are various encryption methods to ensure that no unauthorized person can read the data
packets that are exchanged in a wireless network or gain access to the network:
To configure a wireless LAN with YaST, you need to define the following parameters:
IP Address
Use either a static IP address or let a DHCP server dynamically assign an IP address to
the interface.
Operating Mode
Defines how to integrate your machine into a WLAN, depending on the network topology.
For background information, refer to Section 19.2, “Operating Modes”.
2. In the YaST Control Center, select Network Devices Network Settings to open the Network
Settings dialog.
If your network is currently controlled by NetworkManager, you see a warning message
that the network settings cannot be edited by YaST.
3. To enable editing with YaST, leave the message with OK and on the Global Options tab,
activate Traditional Method with ifup.
4. For further configuration, proceed with Section 19.5.2, “Configuration for Access Points” or
Section 19.5.3, “Establishing an Ad-Hoc Network”.
Otherwise confirm your changes with OK to write the network configuration.
2. Switch to the Overview tab where all network cards are listed that have been detected by
the system. If you need more information about general network configuration, refer to
Section 22.4, “Configuring a Network Connection with YaST”.
4. On the Address tab, configure whether to use a dynamic or a static IP address for the
machine. Usually Dynamic Address with DHCP is ne.
6. To use your WLAN card to connect to an access point, set the Operating Mode to Managed.
If however you want to use your WLAN card as access point, set the Operating Mode to
Master. Note that not all WLAN cards support this mode.
7. To connect to a certain network, enter the Network Name (ESSID). Alternatively, click Scan
Network and select a network from the list of available wireless networks.
All stations in a wireless network need the same ESSID for communicating with each other.
If no ESSID is specified, your WLAN card automatically associates with the access point
that has the best signal strength.
8. Select an Authentication Mode for your network. Which mode is suitable, depends on your
WLAN card's driver and the ability of the other devices in the network.
9. If you have chosen to set the Authentication Mode to No Encryption, finish the configuration
by clicking Next. Confirm the message about this potential security risk and leave the
Overview tab (showing the newly configured WLAN card) with OK.
If you haven chosen any of the other authentication modes, proceed with Procedure 19.2,
“Entering the Encryption Details”.
The following authentication methods require an encryption key: WEP - Open, WEP -
Shared Key, and WPA-PSK.
For WEP, usually only key is needed—however, up to 4 different WEP keys can be defined
for your station. One of them needs to be set as the default key and is used for encryption.
The others are used for decryption. Per default, a key length of 128-bit is used, but you
can also choose to set the length to 64-bit.
For higher security, WPA-EAP uses a RADIUS server to authenticate users. For authentica-
tion at the server, three different methods are available: TLS, TTLS and PEAP. The creden-
tials and certificates you need for WPA-EAP depend on the authentication method used
for the RADIUS server. Ask your system administrator to provide the needed information
and credentials. YaST searches for any certificate under /etc/cert . Therefore, save the
certificates given to you to this location and restrict access to these les to 0600 (owner
read and write).
c. To adjust the key length to a lower bit rate (which might be necessary for older
hardware), click WEP Keys and set the Key Length to 64 bit. The WEP Keys dialog also
shows the WEP keys that have been entered so far. Unless another key is explicitly
set as default, YaST always uses the rst key as default key.
d. To enter more keys for WEP or to modify one of the keys, select the respective entry
and click Edit. Select the Key Input Type and enter the key.
3. If you have chosen WPA-EAP authentication, click Next to switch to the WPA-EAP dialog,
where you enter the credentials and certificates you have been given by your network
administrator.
a. Select the EAP Mode the RADIUS server uses for authentication. The details you need
to enter in the following depend on the selected EAP Mode.
b. For TLS, provide Identity, Client Certificate, Client Key, and Client Key Password. To
increase security, you can also configure a Server Certificate used to validate the
server's authenticity.
TTLS and PEAP require Identity and Password, whereas Server Certificate and Anony-
mous Identity are optional.
c. To enter the advanced authentication dialog for your WPA-EAP setup, click Details.
e. If the automatically-determined setting does not work for you, choose a specific PEAP
Version to force the use of a certain PEAP implementation.
4. Confirm your changes with OK. The Overview tab shows the details of your newly con-
figured WLAN card.
2. Switch to the Overview tab, choose your wireless card from the list and click Edit to open
the Network Card Setup dialog.
6. Choose a Network Name (ESSID). This can be any name, but it has to be used on every
computer in the ad-hoc network.
7. Select an Authentication Mode for your network. Which mode is suitable, depends on your
WLAN card's driver and the ability of the other devices in the network.
10. Configure the other WLAN cards in the network accordingly, using the same Network Name
(ESSID), the same Authentication Mode but different IP addresses.
Channel
The specification of a channel on which the WLAN station should work. This is only need-
ed in Ad-hoc and Master modes. In Managed mode, the card automatically searches the
available channels for access points.
Bit Rate
Depending on the performance of your network, you may want to set a certain bit rate for
the transmission from one point to another. In the default setting Auto, the system tries
to use the highest possible data transmission rate. Some WLAN cards do not support the
setting of bit rates.
Access Point
In an environment with several access points, one of them can be preselected by specifying
the MAC address.
Power Management
When you are on the road, power saving technologies can help to maximize the operat-
ing time of your battery. More information about power management is available in Chap-
ter 20, Power Management. Using power management may affect the connection quality and
increase the network latency.
2. Switch to the Overview tab, choose your wireless card from the list and click Edit to open
the Network Card Setup dialog.
5. In Ad-hoc mode, select one of the offered channels (11 to 14, depending on your country)
for the communication of your station with the other stations. In Master mode, determine
on which Channel your card should offer access point functionality. The default setting
for this option is Auto.
7. Enter the MAC address of the Access Point you want to connect to.
9. Confirm your changes with OK and click Next and OK to finish the configuration.
19.6.1 Utilities
The package wireless-tools contains utilities that allow to set wireless LAN specific para-
meters and get statistics. See http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html
for more information.
217 Tips and Tricks for Setting Up a WLAN SUSE Linux Enterp… 11 SP4
During operation, check the signal strength with the iwconfig utility on the command line
( Link Quality eld) or with the NetworkManager applets provided by KDE or GNOME. If you
have problems with the signal quality, try to set up the devices somewhere else or adjust the
position of the antennas of your access points. Auxiliary antennas that substantially improve
the reception are available for a number of PCMCIA WLAN cards. The rate specified by the
manufacturer, such as 54 Mbit/s, is a nominal value that represents the theoretical maximum.
In practice, the maximum data throughout is no more than half this value.
The iwspy command can displays WLAN statistics:
iwspy wlan0
wlan0 Statistics collected:
00:AA:BB:CC:DD:EE : Quality:0 Signal level:0 Noise level:0
Link/Cell/AP : Quality:60/94 Signal level:-50 dBm Noise level:-140 dBm
(updated)
Typical/Reference : Quality:26/94 Signal level:-60 dBm Noise level:-90 dBm
19.6.3 Security
If you want to set up a wireless network, remember that anybody within the transmission range
can easily access it if no security measures are implemented. Therefore, be sure to activate an
encryption method. All WLAN cards and access points support WEP encryption. Although this
is not entirely safe, it does present an obstacle for a potential attacker.
For private use, use WPA-PSK if available. Although Linux supports WPA on most hardware
components, some drivers do not offer WPA support. It may also not be available on older access
points and routers with WLAN functionality. For such devices, check if WPA can be implemented
by means of a rmware update. If WPA is not available, WEP is better than no encryption. In
enterprises with advanced security requirements, wireless networks should only be operated
with WPA.
Use strong passwords for your authentication method. For example, the Web page https://
www.grc.com/passwords.htm generates random 64 character passwords.
1. Do you know the device name of the WLAN card? Usually it is wlan0 . Check with the
tool ifconfig .
iwconfig wlan0
wlan0 IEEE 802.11abg ESSID:"guest"
Mode:Managed Frequency:5.22GHz Access Point: 00:11:22:33:44:55
Bit Rate:54 Mb/s Tx-Power=13 dBm
Retry min limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality:62/92 Signal level:-48 dBm Noise level:-127 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:10 Invalid misc:0 Missed beacon:0
You can also get the previous information with the iwlist command. For example, the follow-
ing line displays the current bit rate:
If you want an overview how many access points are available, it can also be done with the
iwlist command. It gives you a list of “cells” which looks like this:
http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Wireless.html
The Internet pages of Jean Tourrilhes, who developed the Wireless Tools for Linux, present
a wealth of useful information about wireless networks.
http://tuxmobil.org
Useful hands-on information about mobile computers under Linux.
http://www.linux-on-laptops.com
IBM Z The features and hardware described in this chapter do not exist on IBM System z,
making this chapter irrelevant for these platforms.
Power management is especially important on laptop computers, but is also useful on other sys-
tems. ACPI (Advanced Configuration and Power Interface) is available on all modern computers
(laptops, desktops, and servers). Power management technologies require suitable hardware and
BIOS routines. Most laptops and many modern desktops and servers meet these requirements.
It is also possible to control CPU frequency scaling to save power or decrease noise.
Standby
not supported.
Battery Monitor
ACPI checks the battery charge status and provides information about it. Additionally, it
coordinates actions to perform when a critical charge status is reached.
Depending on the operating mode of the computer, these methods can be combined. Saving
energy also means that the system heats up less and the fans are activated less frequently.
223 Advanced Configuration and Power Interface (ACPI) SUSE Linux Enterp… 11 SP4
Frequency scaling and throttling are only relevant if the processor is busy, because the most
economic C-state is applied anyway when the processor is idle. If the CPU is busy, frequency
scaling is the recommended power saving method. Often the processor only works with a partial
load. In this case, it can be run with a lower frequency. Usually, dynamic frequency scaling
controlled by the kernel on-demand governor is the best approach.
Throttling should be used as the last resort, for example, to extend the battery operation time
despite a high system load. However, some systems do not run smoothly when they are throttled
too much. Moreover, CPU throttling does not make sense if the CPU has little to do.
For in-depth information, refer to Book “System Analysis and Tuning Guide”, Chapter 11 “Power
Management”.
20.2.2 Troubleshooting
There are two different types of problems. On one hand, the ACPI code of the kernel may contain
bugs that were not detected in time. In this case, a solution will be made available for download.
More often, the problems are caused by the BIOS. Sometimes, deviations from the ACPI speci-
fication are purposely integrated in the BIOS to circumvent errors in the ACPI implementation
of other widespread operating systems. Hardware components that have serious errors in the
ACPI implementation are recorded in a blacklist that prevents the Linux kernel from using ACPI
for these components.
The rst thing to do when problems are encountered is to update the BIOS. If the computer does
not boot at all, one of the following boot parameters may be helpful:
pci=noacpi
Do not use ACPI for configuring the PCI devices.
acpi=ht
Only perform a simple resource configuration. Do not use ACPI for other purposes.
acpi=o
Disable ACPI.
225 Rest for the Hard Disk SUSE Linux Enterp… 11 SP4
It can be used to modify various hard disk settings. The option -y instantly switches the hard
disk to the standby mode. -Y puts it to sleep. hdparm -S x causes the hard disk to be spun
down after a certain period of inactivity. Replace x as follows: 0 disables this mechanism,
causing the hard disk to run continuously. Values from 1 to 240 are multiplied by 5 seconds.
Values from 241 to 251 correspond to 1 to 11 times 30 minutes.
Internal power saving options of the hard disk can be controlled with the option -B . Select a
value from 0 to 255 for maximum saving to maximum throughput. The result depends on the
hard disk used and is difficult to assess. To make a hard disk quieter, use the option -M . Select
a value from 128 to 254 for quiet to fast.
Often, it is not so easy to put the hard disk to sleep. In Linux, numerous processes write to the
hard disk, waking it up repeatedly. Therefore, it is important to understand how Linux handles
data that needs to be written to the hard disk. First, all data is buered in the RAM. This buer
is monitored by the pdflush daemon. When the data reaches a certain age limit or when the
buer is lled to a certain degree, the buer content is ushed to the hard disk. The buer size
is dynamic and depends on the size of the memory and the system load. By default, pdush is
set to short intervals to achieve maximum data integrity. It checks the buer every 5 seconds
and writes the data to the hard disk. The following variables are interesting:
/proc/sys/vm/dirty_writeback_centisecs
Contains the delay until a pdush thread wakes up (in hundredths of a second).
/proc/sys/vm/dirty_expire_centisecs
Defines after which timeframe a dirty page should be written out latest. Default is 3000 ,
which means 30 seconds.
/proc/sys/vm/dirty_background_ratio
Maximum percentage of dirty pages until pdush begins to write them. Default is 5 %.
/proc/sys/vm/dirty_ratio
When the dirty page exceeds this percentage of the total memory, processes are forced to
write dirty buers during their time slice instead of continuing to write.
226 Rest for the Hard Disk SUSE Linux Enterp… 11 SP4
Apart from these processes, journaling le systems, like Btrfs , Ext3 , Ext4 and others write
their metadata independently from pdflush , which also prevents the hard disk from spinning
down.
Another important factor is the way active programs behave. For example, good editors regularly
write hidden backups of the currently modified le to the hard disk, causing the disk to wake
up. Features like this can be disabled at the expense of data integrity.
In this connection, the mail daemon postfix makes use of the variable POSTFIX_LAPTOP . If this
variable is set to yes , postfix accesses the hard disk far less frequently.
20.4 Troubleshooting
All error messages and alerts are logged in the le /var/log/messages . The following sections
cover the most common problems.
For the procedure below, make sure the following packages are installed: kernel-source ,
pmtools , and mkinitrd .
2. If the le extension of the downloaded table is .asl (ACPI source language) instead,
compile it by executing the following command:
4. Edit /etc/sysconfig/kernel and adapt the path to the DSDT le accordingly.
5. Start mkinitrd . Whenever you install the kernel and use mkinitrd to create an initrd
le, the modified DSDT is integrated and loaded when the system is booted.
228 CPU Frequency Does Not Work SUSE Linux Enterp… 11 SP4
21 Using Tablet PCs
SUSE® Linux Enterprise Server comes with support for Tablet PCs. In the following,
learn how to install and configure your Tablet PC and discover some useful Linux*
applications which accept input from digital pens.
The following Tablet PCs are supported:
Tablet PCs with serial and USB Wacom tablet (pen based), touch-screen or multi-touch
devices.
Tablet PCs with touch screen devices, such as Asus R2H, Clevo TN120R, Fujitsu Siemens
Computers P-Series, LG C1, Samsung Q1/Q1-Ultra.
After you have installed the Tablet PC packages and configured your digitizer correctly, input
with the pen (also called a stylus) can be used for the following actions and applications:
Actions that can also be triggered by other pointing devices (such as mouse or touch pad),
for example, moving the cursor on the screen, starting applications, closing, resizing and
moving windows, shifting window focus and dragging and dropping objects
Taking notes or sketching with applications like Jarnal or Xournal or editing larger
amounts of text with Dasher
x11-input-evtouch : the X input module for some Tablet PCs with touch screens
xorg-x11-driver-input : the X input module for input devices, including the module for
Wacom devices.
If these packages are not installed, manually install the packages you need from command line
or select the TabletPC pattern for installation in YaST.
If you want to use xvkbd after login, start it from the main menu or with xvkbd from a shell.
PROCEDURE 21.1: TRAINING CELLWRITER
1. Start CellWriter from the main menu or with cellwriter from the command line. On the
rst start, CellWriter automatically starts in the training mode. In training mode it shows
a set of characters of the currently chosen key map.
2. Enter the gesture you would like to use for a character into the respective character's cell.
With the rst input, the background changes its color to white, whereas the character
itself is shown in light gray. Repeat the gesture multiple times until the character changes
its color to black. Untrained characters are shown on a light gray or brown background
(depending on the desktop's color scheme).
3. Repeat this step until you have trained CellWriter for all characters you need.
4. If you want to train CellWriter for another language, click the Setup button and select a
language from the Languages tab. Close the configuration dialog. Click the Train button and
select the key map from the drop-down box at the bottom right corner of the CellWriter
window. Now repeat your training for the new map of keys.
5. After having finished the training for the map of keys, click the Train button to switch
to the normal mode.
In the normal mode, the CellWriter windows shows a couple of empty cells in which to enter
the gestures. The characters are not sent to another application until you click the Enter button,
so you can correct or delete characters before you use them as input. Characters that have been
recognized with a low degree of confidence will appear highlighted. To correct your input, use
the context menu that appears on right-clicking a cell. To delete a character, either use your pen's
eraser, or middle-click with the mouse to clear the cell. After finishing your input in CellWriter,
define which application should receive the input by clicking into the application's window.
Then send the input to the application by clicking Enter.
If you click the Keys button in CellWriter, you get a virtual keyboard that can be used instead
of the handwriting recognition.
To hide CellWriter, close the CellWriter window. The application now appears as icon in your
system tray. To show the input window again, click the icon in the system tray.
1. Start xstroke from the main menu or with xstroke from a shell. This adds a pencil icon
to your system tray.
2. Start the application for which you want to create text input with the pen (for example,
a terminal window, a text editor or an LibreOffice Writer).
3. To activate the gesture recognition mode, click the pencil icon once.
4. Perform some gestures on the graphics tablet with the pen or another pointing device.
xstroke captures the gestures and transfers them to text that appears in the application
window that has the focus.
5. To switch focus to a different window, click the desired window with the pen and hold
for a moment (or use the keyboard shortcut defined in your desktop's control center).
6. To deactivate the gesture recognition mode, click the pencil icon again.
Dasher is another useful application. It was designed for situations where keyboard input is
impractical or unavailable. With a bit of training, you can rapidly enter larger amounts of text
using only the pen (or other input devices—it can even be driven with an eye tracker).
234 Taking Notes and Sketching with the Pen SUSE Linux Enterp… 11 SP4
Start Dasher from the main menu or with dasher from a shell. Move your pen in one direction
and the application starts to zoom into the letters on the right side. From the letters passing
the cross hairs in the middle, the text is created or predicted and is printed to the upper part of
the window. To stop or start writing, click the display once with the pen. Modify the zooming
speed at the bottom of the window.
The Dasher concept works for many languages. For more information, refer to the Dasher Web
site, which offers comprehensive documentation, demonstrations and training texts. Find it at
http://www.inference.phy.cam.ac.uk/dasher/
21.7 Troubleshooting
Virtual Keyboard Does Not Appear on Login Screen
xrandr -o normal && xsetwacom --set "Serial Wacom Tablet" Rotate NONE
xrandr -o inverted && xsetwacom --set "Serial Wacom Tablet" Rotate HALF
xrandr -o left && xsetwacom --set "Serial Wacom Tablet" Rotate CCW
Note that the commands above depend on the output of the xsetwacom list command.
Replace "Serial Wacom Tablet" with the output for the stylus or the touch device. If
you have a Wacom device with touch support (you can use your fingers on the tablet to
move the cursor), you need to rotate also the touch device.
Find more information about the Linux Wacom project at: https://linuxwacom.github.io/
Find a very informative Web site about the Dasher project at http://www.infer-
ence.phy.cam.ac.uk/dasher/
26 DHCP 335
28 Samba 368
Linux offers the necessary networking tools and features for integration into all
types of network structures. Network access using a network card, modem or other
device can be configured with YaST. Manual configuration is also possible. In this
chapter only the fundamental mechanisms and the relevant network configuration
les are covered.
Linux and other Unix operating systems use the TCP/IP protocol. It is not a single network pro-
tocol, but a family of network protocols that offer various services. The protocols listed in Ta-
ble 22.1, “Several Protocols in the TCP/IP Protocol Family”, are provided for the purpose of exchanging
data between two machines via TCP/IP. Networks combined by TCP/IP, comprising a world-
wide network, are also referred to as “the Internet.”
RFC stands for Request for Comments. RFCs are documents that describe various Internet pro-
tocols and implementation procedures for the operating system and its applications. The RFC
documents describe the setup of Internet protocols. To expand your knowledge of any of
the protocols, refer to the appropriate RFC documents. These are available at http://www.iet-
f.org/rfc.html .
Data Transfer
The diagram provides one or two examples for each layer. The layers are ordered according to
abstraction levels. The lowest layer is very close to the hardware. The uppermost layer, however,
is almost a complete abstraction from the hardware. Every layer has its own special function.
The special functions of each layer are mostly implicit in their description. The data link and
physical layers represent the physical network used, such as ethernet.
Almost all hardware protocols work on a packet-oriented basis. The data to transmit is collected
into packets (it cannot be sent all at once). The maximum size of a TCP/IP packet is approximately
64 KB. Packets are normally quite smaller, as the network hardware can be a limiting factor.
The maximum size of a data packet on an ethernet is about fifteen hundred bytes. The size of a
TCP/IP packet is limited to this amount when the data is sent over an ethernet. If more data is
transferred, more data packets need to be sent by the operating system.
For the layers to serve their designated functions, additional information regarding each layer
must be saved in the data packet. This takes place in the header of the packet. Every layer
attaches a small block of data, called the protocol header, to the front of each emerging packet.
When an application sends data over the network, the data passes through each layer, all im-
plemented in the Linux kernel except the physical layer. Each layer is responsible for preparing
the data so it can be passed to the next layer. The lowest layer is ultimately responsible for
sending the data. The entire procedure is reversed when data is received. Like the layers of an
onion, in each layer the protocol headers are removed from the transported data. Finally, the
transport layer is responsible for making the data available for use by the applications at the
destination. In this manner, one layer only communicates with the layer directly above or below
it. For applications, it is irrelevant whether data is transmitted via a 100 Mbit/s FDDI network
or via a 56-Kbit/s modem line. Likewise, it is irrelevant for the data line which kind of data is
transmitted, as long as packets are in the correct format.
EXAMPLE 22.1: WRITING IP ADDRESSES
In decimal form, the four bytes are written in the decimal number system, separated by periods.
The IP address is assigned to a host or a network interface. It can be used only once throughout
the world. There are exceptions to this rule, but these are not relevant to the following passages.
The points in IP addresses indicate the hierarchical system. Until the 1990s, IP addresses were
strictly categorized in classes. However, this system proved too inflexible and was discontinued.
Now, classless routing (CIDR, classless interdomain routing) is used.
Netmasks are used to define the address range of a subnetwork. If two hosts are in the same
subnetwork, they can reach each other directly. If they are not in the same subnetwork, they
need the address of a gateway that handles all the traffic for the subnetwork. To check if two IP
addresses are in the same subnet, simply “AND” both addresses with the netmask. If the result
is identical, both IP addresses are in the same local network. If there are differences, the remote
IP address, and thus the remote interface, can only be reached over a gateway.
To understand how the netmask works, look at Example 22.2, “Linking IP Addresses to the Netmask”.
The netmask consists of 32 bits that identify how much of an IP address belongs to the network.
All those bits that are 1 mark the corresponding bit in the IP address as belonging to the network.
All bits that are 0 mark bits inside the subnetwork. This means that the more bits are 1 , the
smaller the subnetwork is. Because the netmask always consists of several successive 1 bits, it is
also possible to just count the number of bits in the netmask. In Example 22.2, “Linking IP Addresses
to the Netmask” the rst net with 24 bits could also be written as 192.168.0.0/24 .
To give another example: all machines connected with the same ethernet cable are usually
located in the same subnetwork and are directly accessible. Even when the subnet is physically
divided by switches or bridges, these hosts can still be reached directly.
IP addresses outside the local subnet can only be reached if a gateway is configured for the
target network. In the most common case, there is only one gateway that handles all traffic that
is external. However, it is also possible to configure several gateways for different subnets.
If a gateway has been configured, all external IP packets are sent to the appropriate gateway.
This gateway then attempts to forward the packets in the same manner—from host to host—
until it reaches the destination host or the packet's TTL (time to live) expires.
Base Network Address This is the netmask AND any address in the
network, as shown in Example 22.2, “Linking IP
Addresses to the Netmask” under Result . This
address cannot be assigned to any hosts.
Because IP addresses must be unique all over the world, you cannot just select random addresses.
There are three address domains to use if you want to set up a private IP-based network. These
cannot get any connection from the rest of the Internet, because they cannot be transmitted over
the Internet. These address domains are specified in RFC 1597 and listed in Table 22.3, “Private
IP Address Domains”.
Network/Netmask Domain
Due to the emergence of the WWW (World Wide Web), the Internet has experienced explosive
growth, with an increasing number of computers communicating via TCP/IP in the past fifteen
years. Since Tim Berners-Lee at CERN (http://public.web.cern.ch ) invented the WWW in 1990,
the number of Internet hosts has grown from a few thousand to about a hundred million.
As mentioned, an IPv4 address consists of only 32 bits. Also, quite a few IP addresses are lost—
they cannot be used due to the way in which networks are organized. The number of addresses
available in your subnet is two to the power of the number of bits, minus two. A subnetwork has,
for example, 2, 6, or 14 addresses available. To connect 128 hosts to the Internet, for example,
you need a subnetwork with 256 IP addresses, from which only 254 are usable, because two
IP addresses are needed for the structure of the subnetwork itself: the broadcast and the base
network address.
Under the current IPv4 protocol, DHCP or NAT (network address translation) are the typical
mechanisms used to circumvent the potential address shortage. Combined with the convention
to keep private and public address spaces separate, these methods can certainly mitigate the
shortage. The problem with them lies in their configuration, which is a chore to set up and a
burden to maintain. To set up a host in an IPv4 network, you need a number of address items,
such as the host's own IP address, the subnetmask, the gateway address and maybe a name
server address. All these items need to be known and cannot be derived from somewhere else.
With IPv6, both the address shortage and the complicated configuration should be a thing of
the past. The following sections tell more about the improvements and benefits brought by IPv6
and about the transition from the old protocol to the new one.
22.2.1 Advantages
The most important and most visible improvement brought by the new protocol is the enormous
expansion of the available address space. An IPv6 address is made up of 128 bit values instead
of the traditional 32 bits. This provides for as many as several quadrillion IP addresses.
Autoconfiguration
IPv6 makes the network “plug and play” capable, which means that a newly set up system
integrates into the (local) network without any manual configuration. The new host uses its
automatic configuration mechanism to derive its own address from the information made
available by the neighboring routers, relying on a protocol called the neighbor discovery
(ND) protocol. This method does not require any intervention on the administrator's part
and there is no need to maintain a central server for address allocation—an additional
advantage over IPv4, where automatic address allocation requires a DHCP server.
Nevertheless if a router is connected to a switch, the router should send periodic advertis-
ments with ags telling the hosts of a network how they should interact with each other.
For more information, see RFC 2462 and the radvd.conf(5) man page, and RFC 3315.
Mobility
IPv6 makes it possible to assign several addresses to one network interface at the same
time. This allows users to access several networks easily, something that could be compared
with the international roaming services offered by mobile phone companies: when you
take your mobile phone abroad, the phone automatically logs in to a foreign service as
soon as it enters the corresponding area, so you can be reached under the same number
everywhere and are able to place an outgoing call just like in your home area.
Secure Communication
With IPv4, network security is an add-on function. IPv6 includes IPsec as one of its core
features, allowing systems to communicate over a secure tunnel to avoid eavesdropping
by outsiders on the Internet.
Backward Compatibility
Realistically, it would be impossible to switch the entire Internet from IPv4 to IPv6 at
one time. Therefore, it is crucial that both protocols are able to coexist not only on the
Internet, but also on one system. This is ensured by compatible addresses (IPv4 addresses
can easily be translated into IPv6 addresses) and through the use of a number of tunnels.
See Section 22.2.3, “Coexistence of IPv4 and IPv6”. Also, systems can rely on a dual stack IP
Unicast
Addresses of this type are associated with exactly one network interface. Packets with such
an address are delivered to only one destination. Accordingly, unicast addresses are used
to transfer packets to individual hosts on the local network or the Internet.
Multicast
Addresses of this type relate to a group of network interfaces. Packets with such an address
are delivered to all destinations that belong to the group. Multicast addresses are mainly
used by certain network services to communicate with certain groups of hosts in a well-
directed manner.
Anycast
Addresses of this type are related to a group of interfaces. Packets with such an address
are delivered to the member of the group that is closest to the sender, according to the
principles of the underlying routing protocol. Anycast addresses are used to make it easier
An IPv6 address is made up of eight four-digit elds, each representing 16 bits, written in hexa-
decimal notation. They are separated by colons ( : ). Any leading zero bytes within a given eld
may be dropped, but zeros within the eld or at its end may not. Another convention is that
more than four consecutive zero bytes may be collapsed into a double colon. However, only
one such :: is allowed per address. This kind of shorthand notation is shown in Example 22.3,
“Sample IPv6 Address”, where all three lines represent the same address.
EXAMPLE 22.3: SAMPLE IPV6 ADDRESS
Each part of an IPv6 address has a defined function. The rst bytes form the prefix and specify
the type of address. The center part is the network portion of the address, but it may be unused.
The end of the address forms the host part. With IPv6, the netmask is defined by indicating the
length of the prefix after a slash at the end of the address. An address, as shown in Example 22.4,
“IPv6 Address Specifying the Prefix Length”, contains the information that the rst 64 bits form the
network part of the address and the last 64 form its host part. In other words, the 64 means
that the netmask is lled with 64 1-bit values from the left. Just like with IPv4, the IP address is
combined with AND with the values from the netmask to determine whether the host is located
in the same subnetwork or in another one.
EXAMPLE 22.4: IPV6 ADDRESS SPECIFYING THE PREFIX LENGTH
fe80::10:1000:1a4/64
IPv6 knows about several predefined types of prefixes. Some of these are shown in Table 22.4,
“Various IPv6 Prefixes”.
TABLE 22.4: VARIOUS IPV6 PREFIXES
Public Topology
The rst part (which also contains one of the prefixes mentioned above) is used to route
packets through the public Internet. It includes information about the company or institu-
tion that provides the Internet access.
Site Topology
The second part contains routing information about the subnetwork to which to deliver
the packet.
Interface ID
On top of this basic structure, IPv6 distinguishes between ve different types of unicast address-
es:
:: (unspecified)
This address is used by the host as its source address when the interface is initialized for
the rst time—when the address cannot yet be determined by other means.
::1 (loopback)
The address of the loopback device.
Local Addresses
There are two address types for local use:
link-local
This type of address can only be used in the local subnetwork. Packets with a source or
target address of this type should not be routed to the Internet or other subnetworks.
These addresses contain a special prefix ( fe80::/10 ) and the interface ID of the
network card, with the middle part consisting of zero bytes. Addresses of this type
are used during automatic configuration to communicate with other hosts belonging
to the same subnetwork.
site-local
As a completely new feature introduced with IPv6, each network interface normally gets several
IP addresses, with the advantage that several networks can be accessed through the same inter-
face. One of these networks can be configured completely automatically using the MAC and a
known prefix with the result that all hosts on the local network can be reached as soon as IPv6
is enabled (using the link-local address). With the MAC forming part of it, any IP address used in
the world is unique. The only variable parts of the address are those specifying the site topology
and the public topology, depending on the actual network in which the host is currently operating.
For a host to go back and forth between different networks, it needs at least two addresses. One
of them, the home address, not only contains the interface ID but also an identifier of the home
network to which it normally belongs (and the corresponding prefix). The home address is a
static address and, as such, it does not normally change. Still, all packets destined to the mobile
host can be delivered to it, regardless of whether it operates in the home network or somewhere
outside. This is made possible by the completely new features introduced with IPv6, such as
stateless autoconfiguration and neighbor discovery. In addition to its home address, a mobile host
gets one or more additional addresses that belong to the foreign networks where it is roaming.
These are called care-of addresses. The home network has a facility that forwards any packets
destined to the host when it is roaming outside. In an IPv6 environment, this task is performed
by the home agent, which takes all packets destined to the home address and relays them through
a tunnel. On the other hand, those packets destined to the care-of address are directly transferred
to the mobile host without any special detours.
6over4
IPv6 packets are automatically encapsulated as IPv4 packets and sent over an IPv4 network
capable of multicasting. IPv6 is tricked into seeing the whole network (Internet) as a huge
local area network (LAN). This makes it possible to determine the receiving end of the IPv4
tunnel automatically. However, this method does not scale very well and is also hampered
by the fact that IP multicasting is far from widespread on the Internet. Therefore, it only
provides a solution for smaller corporate or institutional networks where multicasting can
be enabled. The specifications for this method are laid down in RFC 2529.
6to4
With this method, IPv4 addresses are automatically generated from IPv6 addresses, en-
abling isolated IPv6 hosts to communicate over an IPv4 network. However, a number of
problems have been reported regarding the communication between those isolated IPv6
hosts and the Internet. The method is described in RFC 3056.
http://www.ipv6.org/
The starting point for everything about IPv6.
http://www.ipv6day.org
All information needed to start your own IPv6 network.
http://www.ipv6-to-standard.org/
The list of IPv6-enabled products.
http://www.bieringer.de/linux/IPv6/
Here, nd the Linux IPv6-HOWTO and many links related to the topic.
RFC 2640
The fundamental RFC about IPv6.
IPv6 Essentials
A book describing all the important aspects of the topic is IPv6 Essentials by Silvia Hagen
(ISBN 0-596-00125-8).
The protocol whois is closely related to DNS. With this program, quickly nd out who is re-
sponsible for any given domain.
On SUSE Linux Enterprise Desktop, where NetworkManager is active by default, all network
cards are configured. If NetworkManager is not active, only the rst interface with link up (with
a network cable connected) is automatically configured. Additional hardware can be configured
any time on the installed system. The following sections describe the network configuration for
all types of network connections supported by SUSE Linux Enterprise Server.
To configure your wired or wireless network card in YaST, select Network Devices Network
Settings. After starting the module, YaST displays the Network Settings dialog with four tabs:
Global Options, Overview, Hostname/DNS and Routing.
256 Configuring a Network Connection with YaST SUSE Linux Enterp… 11 SP4
The Global Options tab allows you to set general networking options such as the use of Network-
Manager, IPv6 and general DHCP options. For more information, see Section 22.4.1.1, “Configuring
Global Networking Options”.
The Overview tab contains information about installed network interfaces and configurations.
Any properly detected network card is listed with its name. You can manually configure new
cards, remove or change their configuration in this dialog. If you want to manually configure a
card that was not automatically detected, see Section 22.4.1.3, “Configuring an Undetected Network
Card”. If you want to change the configuration of an already configured card, see Section 22.4.1.2,
“Changing the Configuration of a Network Card”.
The Hostname/DNS tab allows to set the hostname of the machine and name the servers to be
used. For more information, see Section 22.4.1.4, “Configuring Hostname and DNS”.
The Routing tab is used for the configuration of routing. See Section 22.4.1.5, “Configuring Routing”
for more information.
257 Configuring the Network Card with YaST SUSE Linux Enterp… 11 SP4
22.4.1.1 Configuring Global Networking Options
The Global Options tab of the YaST Network Settings module allows you to set important global
networking options, such as the use of NetworkManager, IPv6 and DHCP client options. These
settings are applicable for all network interfaces.
In the Network Setup Method choose the way network connections are managed. If you want
a NetworkManager desktop applet to manage connections for all interfaces, choose User Con-
trolled with NetworkManager. This option is well suited for switching between multiple wired
and wireless networks. If you do not run a desktop environment (GNOME or KDE), or if your
computer is a Xen server, virtual system, or provides network services such as DHCP or DNS
in your network, use the Traditional Method with ifup. If NetworkManager is used, nm-applet
should be used to configure network options and the Overview, Hostname/DNS and Routing tabs
of the Network Settings module are disabled. For more information on NetworkManager, see
Chapter 27, Using NetworkManager.
In the IPv6 Protocol Settings choose whether you want to use the IPv6 protocol. It is possible
to use IPv6 together with IPv4. By default, IPv6 is activated. However, in networks not using
IPv6 protocol, response times can be faster with IPv6 protocol disabled. If you want to disable
IPv6, uncheck the Enable IPv6 option. This disables autoload of the kernel module for IPv6. This
will be applied after reboot.
In the DHCP Client Options configure options for the DHCP client. If you want the DHCP client
to ask the server to always broadcast its responses, check Request Broadcast Response. It may be
needed if your machine is moving between different networks. The DHCP Client Identifier must
be different for each DHCP client on a single network. If left empty, it defaults to the hardware
address of the network interface. However, if you are running several virtual machines using
the same network interface and, therefore, the same hardware address, specify a unique free-
form identifier here.
The Hostname to Send specifies a string used for the hostname option eld when dhcpcd sends
messages to DHCP server. Some DHCP servers update name server zones (forward and reverse
records) according to this hostname (Dynamic DNS). Also, some DHCP servers require the Host-
name to Send option eld to contain a specific string in the DHCP messages from clients. Leave
AUTO to send the current hostname (that is the one defined in /etc/HOSTNAME ). Leave the
option eld empty for not sending any hostname. If yo do not want to change the default route
according to the information from DHCP, uncheck Change Default Route via DHCP.
258 Configuring the Network Card with YaST SUSE Linux Enterp… 11 SP4
22.4.1.2 Changing the Configuration of a Network Card
To change the configuration of a network card, select a card from the list of the detected cards
in Network Settings Overview in YaST and click Edit. The Network Card Setup dialog appears
in which to adjust the card configuration using the General, Address and Hardware tabs. For
information about wireless card configuration, see Section 19.5, “Configuration with YaST”.
You can set the IP address of the network card or the way its IP address is determined in the
Address tab of the Network Card Setup dialog. Both IPv4 and IPv6 addresses are supported. The
network card can have No IP Address (which is useful for bonding devices), a Statically Assigned
IP Address (IPv4 or IPv6) or a Dynamic Address assigned via DHCP or Zeroconf or both.
If using Dynamic Address, select whether to use DHCP Version 4 Only (for IPv4), DHCP Version
6 Only (for IPv6) or DHCP Both Version 4 and 6.
If possible, the rst network card with link that is available during the installation is automati-
cally configured to use automatic address setup via DHCP. On SUSE Linux Enterprise Desktop,
where NetworkManager is active by default, all network cards are configured.
DHCP should also be used if you are using a DSL line but with no static IP assigned by the
ISP (Internet Service Provider). If you decide to use DHCP, configure the details in DHCP Client
Options in the Global Options tab of the Network Settings dialog of the YaST network card config-
uration module. Specify whether the DHCP client should ask the server to always broadcast its
responses in Request Broadcast Response. This option may be needed if your machine is a mobile
client moving between networks. If you have a virtual host setup where different hosts commu-
nicate through the same interface, an DHCP Client Identifier is necessary to distinguish them.
DHCP is a good choice for client configuration but it is not ideal for server configuration. To
set a static IP address, proceed as follows:
1. Select a card from the list of detected cards in the Overview tab of the YaST network card
configuration module and click Edit.
259 Configuring the Network Card with YaST SUSE Linux Enterp… 11 SP4
2. In the Address tab, choose Statically Assigned IP Address.
3. Enter the IP Address. Both IPv4 and IPv6 addresses can be used. Enter the network mask in
Subnet Mask. If the IPv6 address is used, use Subnet Mask for prefix length in format /64 .
Optionally, you can enter a fully qualified Hostname for this address, which will be written
to the /etc/hosts configuration le.
4. Click Next.
If you use the static address, the name servers and default gateway are not configured automat-
ically. To configure name servers, proceed as described in Section 22.4.1.4, “Configuring Hostname
and DNS”. To configure a gateway, proceed as described in Section 22.4.1.5, “Configuring Routing”.
Using YaST to set an alias for your network card, proceed as follows:
1. Select a card from the list of detected cards in the Overview tab of the YaST network card
configuration module and click Edit.
3. Enter Alias Name, IP Address, and Netmask. Do not include the interface name in the alias
name.
4. Click OK.
5. Click Next.
260 Configuring the Network Card with YaST SUSE Linux Enterp… 11 SP4
22.4.1.2.3 Changing the Device Name and Udev Rules
It is possible to change the device name of the network card when it is used. It is also possible
to determine whether the network card should be identified by udev via its hardware (MAC)
address or via the bus ID. The later option is preferable in large servers to ease hot swapping of
cards. To set these options with YaST, proceed as follows:
1. Select a card from the list of detected cards in the Overview tab of the YaST Network Settings
module and click Edit.
2. Go to the Hardware tab. The current device name is shown in Udev Rules. Click Change.
3. Select whether udev should identify the card by its MAC Address or Bus ID. The current
MAC address and bus ID of the card are shown in the dialog.
4. To change the device name, check the Change Device Name option and edit the name.
For some network cards, several kernel drivers may be available. If the card is already config-
ured, YaST allows you to select a kernel driver to be used from a list of available suitable dri-
vers. It is also possible to specify options for the kernel driver. To set these options with YaST,
proceed as follows:
1. Select a card from the list of detected cards in the Overview tab of the YaST Network
Settings module and click Edit.
3. Select the kernel driver to be used in Module Name. Enter any options for the selected
driver in Options in the form option = value . If more options are used, they should
be space-separated.
261 Configuring the Network Card with YaST SUSE Linux Enterp… 11 SP4
22.4.1.2.5 Activating the Network Device
If you use the traditional method with ifup, you can configure your device to either start during
boot, on cable connection, on card detection, manually or never. To change device start-up,
proceed as follows:
1. In YaST select a card from the list of detected cards in Network Devices Network Settings
and click Edit.
2. In the General tab, select the desired entry from Device Activation.
Choose At Boot Time to start the device during the system boot. With On Cable Connection,
the interface is watched for any existing physical connection. With On Hotplug, the inter-
face is set as soon as available. It is similar to the At Boot Time option, and only differs in
the fact that no error occurs if the interface is not present at boot time. Choose Manually
to control the interface manually with ifup . Choose Never to not start the device at all.
The On NFSroot is similar to At Boot Time, but the interface does not shut down with the
rcnetwork stop command. Use this if you use an nfs or iscsi root le system.
3. Click Next.
Usually, only the system administrator can activate and deactivate network interfaces. If you
want any user to be able to activate this interface via KInternet, select Enable Device Control for
Non-root User via KInternet.
You can set a maximum transmission unit (MTU) for the interface. MTU refers to the largest
allowed packet size in bytes. A higher MTU brings higher bandwidth efficiency. However, large
packets can block up a slow interface for some time, increasing the lag for further packets.
1. In YaST select a card from the list of detected cards in Network Devices Network Settings
and click Edit.
2. In the General tab, select the desired entry from the Set MTU list.
3. Click Next.
262 Configuring the Network Card with YaST SUSE Linux Enterp… 11 SP4
22.4.1.2.7 Configuring the Firewall
Without having to enter the detailed firewall setup as described in Book “Security Guide”, Chap-
ter 15 “Masquerading and Firewalls”, Section 15.4 “SuSEfirewall2”, Section 15.4.1 “Configuring the Firewall
with YaST”, you can determine the basic firewall setup for your device as part of the device setup.
Proceed as follows:
1. Open the YaST Network Devices Network Settings module. In the Overview tab, select a
card from the list of detected cards and click Edit.
3. Determine the firewall zone to which your interface should be assigned. The following
options are available:
Firewall Disabled
This option is available only if the firewall is disabled and the firewall does not run at
all. Only use this option if your machine is part of a greater network that is protected
by an outer firewall.
Demilitarized Zone
A demilitarized zone is an additional line of defense in front of an internal network
and the (hostile) Internet. Hosts assigned to this zone can be reached from the inter-
nal network and from the Internet, but cannot access the internal network.
External Zone
The firewall is running on this interface and fully protects it against other—presum-
ably hostile—network traffic. This is the default option.
4. Click Next.
263 Configuring the Network Card with YaST SUSE Linux Enterp… 11 SP4
5. Activate the configuration by clicking OK.
1. In the Network Devices Network Settings Overview dialog in YaST click Add.
2. In the Hardware dialog, set the Device Type of the interface from the available options and
Configuration Name. If the network card is a PCMCIA or USB device, activate the respective
check box and exit this dialog with Next. Otherwise, you can define the kernel Module
Name to be used for the card and its Options, if necessary.
In Ethtool Options, you can set ethtool options used by ifup for the interface. See the
ethtool manual page for available options. If the option string starts with a - (for ex-
ample -K interface_name rx on ), the second word in the string is replaced with the
current interface name. Otherwise (for example autoneg off speed 10 ) ifup prepends
-s interface_name .
3. Click Next.
4. Configure any needed options, such as the IP address, device activation or firewall zone
for the interface in the General, Address, and Hardware tabs. For more information about
the configuration options, see Section 22.4.1.2, “Changing the Configuration of a Network Card”.
5. If you selected Wireless as the device type of the interface, configure the wireless connec-
tion in the next dialog. Detailed information about wireless device configuration is avail-
able in Chapter 19, Wireless LAN.
6. Click Next.
If you did not change the network configuration during installation and the wired card was
already available, a hostname was automatically generated for your computer and DHCP was
activated. The same applies to the name service information your host needs to integrate into
264 Configuring the Network Card with YaST SUSE Linux Enterp… 11 SP4
a network environment. If DHCP is used for network address setup, the list of domain name
servers is automatically lled with the appropriate data. If a static setup is preferred, set these
values manually.
To change the name of your computer and adjust the name server search list, proceed as follows:
1. Go to the Network Settings Hostname/DNS tab in the Network Devices module in YaST.
2. Enter the Hostname and, if needed, the Domain Name. The domain is especially important
if the machine is a mail server. Note that the hostname is global and applies to all set
network interfaces.
If you are using DHCP to get an IP address, the hostname of your computer will be auto-
matically set by the DHCP. You may want to disable this behavior if you connect to dif-
ferent networks, because they may assign different hostnames and changing the hostname
at runtime may confuse the graphical desktop. To disable using DHCP to get an IP address
uncheck Change Hostname via DHCP.
Assign Hostname to Loopback IP associates your hostname with 127.0.0.2 (loopback)
IP address in /etc/hosts . This is an useful option if you want to have the hostname
resolvable at all times, even without active network.
3. In Modify DNS Configuration, select the way the DNS configuration (name servers, search
list, the content of the /etc/resolv.conf le) is modified.
If the Use Default Policy option is selected, the configuration is handled by the netconfig
script which merges the data defined statically (with YaST or in the configuration les)
with data obtained dynamically (from the DHCP client or NetworkManager). This default
policy is sufficient in most cases.
If the Only Manually option is selected, netconfig is not allowed to modify the /etc/
resolv.conf le. However, this le can be edited manually.
If the Custom Policy option is selected, a Custom Policy Rule string defining the merge policy
should be specified. The string consists of a comma-separated list of interface names to be
considered a valid source of settings. Except for complete interface names, basic wild cards
to match multiple interfaces are allowed, as well. For example, eth* ppp? will rst target
all eth and then all ppp0-ppp9 interfaces. There are two special policy values that indicate
how to apply the static settings defined in the /etc/sysconfig/network/config le:
STATIC
The static settings have to be merged together with the dynamic settings.
STATIC_FALLBACK
265 Configuring the Network Card with YaST SUSE Linux Enterp… 11 SP4
The static settings are used only when no dynamic configuration is available.
4. Enter the Name Servers and ll in the Domain Search list. Name servers must be specified
by IP addresses, such as 192.168.1.116, not by hostnames. Names specified in the Domain
Search tab are domain names used for resolving hostnames without a specified domain. If
more than one Domain Search is used, separate domains with commas or white space.
It is also possible to edit the hostname using YaST from the command line. The changes made
by YaST take effect immediately (which is not the case when editing the /etc/HOSTNAME le
manually). To change the hostname, use the following command:
To make your machine communicate with other machines and other networks, routing infor-
mation must be given to make network traffic take the correct path. If DHCP is used, this infor-
mation is automatically provided. If a static setup is used, this data must be added manually.
2. Enter the IP address of the Default Gateway (IPv4 and IPv6 if necessary). The default
gateway matches every possible destination, but if any other entry exists that matches the
required address, use this instead of the default route.
3. More entries can be entered in the Routing Table. Enter the Destination network IP address,
Gateway IP address and the Netmask. Select the Device through which the traffic to the
defined network will be routed (the minus sign stands for any device). To omit any of
these values, use the minus sign - . To enter a default gateway into the table, use default
in the Destination eld.
266 Configuring the Network Card with YaST SUSE Linux Enterp… 11 SP4
Note
If more default routes are used, it is possible to specify the metric option to de-
termine which route has a higher priority. To specify the metric option, enter -
metric number in Options. The route with the highest metric is used as default.
If the network device is disconnected, its route will be removed and the next one
will be used. However, the current kernel does not use metric in static routing, only
routing daemons like multipathd do.
4. If the system is a router, enable the IP Forwarding option in the Network Settings.
22.4.2 Modem
In the YaST Control Center, access the modem configuration under Network Devices Modem. If
your modem was not automatically detected, go to the Modem Devices tab and open the dialog
for manual configuration by clicking Add. Enter the interface to which the modem is connected
under Modem Device.
If you are behind a private branch exchange (PBX), you may need to enter a dial prefix. This is
often a zero. Consult the instructions that came with the PBX to nd out. Also select whether
to use tone or pulse dialing, whether the speaker should be on and whether the modem should
wait until it detects a dial tone. The last option should not be enabled if the modem is connected
to an exchange.
Under Details, set the baud rate and the modem initialization strings. Only change these settings
if your modem was not detected automatically or if it requires special settings for data transmis-
sion to work. This is mainly the case with ISDN terminal adapters. Leave this dialog by clicking
OK. To delegate control over the modem to the normal user without root permissions, activate
Enable Device Control for Non-root User via KInternet. In this way, a user without administrator
permissions can activate or deactivate an interface. Under Dial Prefix Regular Expression, specify
a regular expression. The Dial Prefix in KInternet, which can be modified by the normal user,
must match this regular expression. If this eld is left empty, the user cannot set a different Dial
Prefix without administrator permissions.
In the next dialog, select the ISP. To choose from a predefined list of ISPs operating in your
country, select Country. Alternatively, click New to open a dialog in which to provide the data
for your ISP. This includes a name for the dial-up connection and ISP as well as the login and
password provided by your ISP. Enable Always Ask for Password to be prompted for the password
each time you connect.
Dial on Demand
If you enable Dial on Demand, set at least one name server. Use this feature only if your
Internet connection is inexpensive, because there are programs that periodically request
data from the Internet.
Automatically Reconnect
If this options is enabled, the connection is automatically reestablished after failure.
Ignore Prompts
This option disables the detection of any prompts from the dial-up server. If the connection
build-up is slow or does not work at all, try this option.
IP Details
This opens the address configuration dialog. If your ISP does not assign a dynamic IP
address to your host, disable Dynamic IP Address then enter your host's local IP address
and the remote IP address. Ask your ISP for this information. Leave Default Route enabled
and close the dialog by selecting OK.
Selecting Next returns to the original dialog, which displays a summary of the modem configu-
ration. Close this dialog with OK.
Use this module to configure one or several ISDN cards for your system. If YaST did not detect
your ISDN card, click on Add in the ISDN Devices tab and manually select your card. Multiple
interfaces are possible, but several ISPs can be configured for one interface. In the subsequent
dialogs, set the ISDN options necessary for the proper functioning of the card.
FIGURE 22.5: ISDN CONFIGURATION
In the next dialog, shown in Figure 22.5, “ISDN Configuration”, select the protocol to use. The default
is Euro-ISDN (EDSS1), but for older or larger exchanges, select 1TR6. If you are in the US, select
NI1. Select your country in the relevant eld. The corresponding country code then appears in
the eld next to it. Finally, provide your Area Code and the Dial Prefix if necessary. If you do
not want to log all your ISDN traffic, uncheck the Start ISDN Log option.
The number to enter for My Phone Number depends on your particular setup:
1. Smaller private branch exchanges (PBX) built for home purposes mostly use the Eu-
ro-ISDN (EDSS1) protocol for internal calls. These exchanges have an internal S0 bus
and use internal numbers for the equipment connected to them.
2. Larger phone exchanges designed for businesses normally use the 1TR6 protocol for
internal calls. Their MSN is called EAZ and usually corresponds to the direct-dial
number. For the configuration under Linux, it should be sufficient to enter the last
digit of the EAZ. As a last resort, try each of the digits from 1 to 9.
For the connection to be terminated just before the next charge unit is due, enable ChargeHUP.
However, remember that may not work with every ISP. You can also enable channel bundling
(multilink PPP) by selecting the corresponding option. Finally, you can enable the firewall for
your link by selecting External Firewall Interface and Restart Firewall. To enable the normal user
without administrator permissions to activate or deactivate the interface, select the Enable Device
Control for Non-root User via KInternet.
Details opens a dialog in which to implement more complex connection schemes which are not
relevant for normal home users. Leave the Details dialog by selecting OK.
In the next dialog, configure IP address settings. If you have not been given a static IP by your
provider, select Dynamic IP Address. Otherwise, use the elds provided to enter your host's local
IP address and the remote IP address according to the specifications of your ISP. If the interface
should be the default route to the Internet, select Default Route. Each host can only have one
interface configured as the default route. Leave this dialog by selecting Next.
The following dialog allows you to set your country and select an ISP. The ISPs included in
the list are call-by-call providers only. If your ISP is not in the list, select New. This opens the
Provider Parameters dialog in which to enter all the details for your ISP. When entering the phone
number, do not include any blanks or commas among the digits. Finally, enter your login and
the password as provided by the ISP. When finished, select Next.
To use Dial on Demand on a stand-alone workstation, specify the name server (DNS server) as
well. Most ISPs support dynamic DNS, which means the IP address of a name server is sent by
the ISP each time you connect. For a single workstation, however, you still need to provide a
placeholder address like 192.168.22.99 . If your ISP does not support dynamic DNS, specify
the name server IP addresses of the ISP. If desired, specify a time-out for the connection—the
period of network inactivity (in seconds) after which the connection should be automatically
terminated. Confirm your settings with Next. YaST displays a summary of the configured inter-
faces. To activate these settings, select OK.
In some countries it is quite common to access the Internet through the TV cable network. The
TV cable subscriber usually gets a modem that is connected to the TV cable outlet on one side
and to a computer network card on the other (using a 10Base-TG twisted pair cable). The cable
modem then provides a dedicated Internet connection with a xed IP address.
Depending on the instructions provided by your ISP, when configuring the network card either
select Dynamic Address or Statically Assigned IP Address. Most providers today use DHCP. A static
IP address often comes as part of a special business account.
22.4.5 DSL
To configure your DSL device, select the DSL module from the YaST Network Devices section.
This YaST module consists of several dialogs in which to set the parameters of DSL links based
on one of the following protocols:
In the DSL Devices tab of the DSL Configuration Overview dialog, you will nd a list of installed
DSL devices. To change the configuration of a DSL device, select it in the list and click Edit. If
you click Add, you can manually configure a new DSL device.
Tip
Values in IP Address and Subnet Mask are only placeholders. They are only needed to
initialize the network card and do not represent the DSL link as such.
In the rst DSL configuration dialog (see Figure 22.7, “DSL Configuration”), select the PPP Mode and
the Ethernet Card to which the DSL modem is connected (in most cases, this is eth0 ). Then use
Activate Device to specify whether the DSL link should be established during the boot process.
Click Enable Device Control for Non-root User via KInternet to authorize the normal user without
root permissions to activate or deactivate the interface with KInternet.
In the next dialog select your country and choose from a number of ISPs operating in it. The
details of any subsequent dialogs of the DSL configuration depend on the options set so far,
which is why they are only briey mentioned in the following paragraphs. For details on the
available options, read the detailed help available from the dialogs.
To use Dial on Demand on a stand-alone workstation, also specify the name server (DNS server).
Most ISPs support dynamic DNS—the IP address of a name server is sent by the ISP each time you
connect. For a single workstation, however, provide a placeholder address like 192.168.22.99 .
If your ISP does not support dynamic DNS, enter the name server IP address provided by your
ISP.
To add a qeth-hsi (Hipersockets) interface to the installed system, start the Network De-
vices Network Settings module in YaST. Select one of the devices marked Hipersocket to use as
the READ device address and click Edit. Enter the device numbers for the read, write and control
channels (example device number format: 0.0.0600 ). Then click next. In the Network Address
Setup dialog, specify the IP address and netmask for the new interface and leave the network
configuration by pressing Next and OK.
To add a qeth-ethernet (IBM OSA Express Ethernet Card) interface to the installed system,
start the Network Devices Network Settings module in YaST. Select one of the devices marked IBM
OSA Express Ethernet Card to use as the READ device address and click Edit. Enter a device num-
ber for the read, write and control channels (example device number format: 0.0.0600 ). Enter
the needed port name, port number (if applicable) and some additional options (see the Linux
for IBM System z: Device Drivers, Features, and Commands manual for reference, http://www.ib-
m.com/developerworks/linux/linux390/documentation_novell_suse.html ), your IP address, and
an appropriate netmask. Leave the network configuration with Next and OK.
276 IBM System z: Configuring Network Devices SUSE Linux Enterp… 11 SP4
22.4.6.3 The ctc Device
To add a ctc (IBM parallel CTC Adapter) interface to the installed system, start the Network
Devices Network Settings module in YaST. Select one of the devices marked IBM Parallel CTC
Adapter to use as your read channel and click Configure. Choose the Device Settings that t your
devices (usually this would be Compatibility Mode). Specify both your IP address and the IP
address of the remote partner. If needed, adjust the MTU size with Advanced Detailed Settings.
Leave the network configuration with Next and OK.
Warning
The use of this interface is deprecated. This interface will not be supported in future
versions of SUSE Linux Enterprise Server.
To add an lcs (IBM OSA-2 Adapter) interface to the installed system, start the Network De-
vices Network Settings module in YaST. Select one of the devices marked IBM OSA-2 Adapter and
click Configure. Enter the needed port number, some additional options (see the Linux for IBM
System z: Device Drivers, Features, and Commands manual for reference, http://www.ibm.com/de-
veloperworks/linux/linux390/documentation_novell_suse.html ), your IP address and an appro-
priate netmask. Leave the network configuration with Next and OK.
To add an iucv (IUCV) interface to the installed system, start the Network Devices Network
Settings module in YaST. Select a device marked IUCV and click Edit. YaST prompts you for the
name of your IUCV partner (Peer). Enter the name (this entry is case-sensitive) and select Next.
Specify both the IP Address and the Remote IP Address of your partner. If needed, Set MTU size
on General tab. Leave the network configuration with Next and OK.
Warning
The use of this interface is deprecated. This interface will not be supported in future
versions of SUSE Linux Enterprise Server.
277 IBM System z: Configuring Network Devices SUSE Linux Enterp… 11 SP4
22.5 NetworkManager
NetworkManager is the ideal solution for laptops and other portable computers. With Network-
Manager, you do not need to worry about configuring network interfaces and switching between
networks when you are moving.
root Privileges
If you use NetworkManager for network setup, you can easily switch, stop or start your
network connection at any time from within your desktop environment using an applet.
NetworkManager also makes it possible to change and configure wireless card connections
without requiring root privileges. For this reason, NetworkManager is the ideal solution
for a mobile workstation.
Traditional configuration with ifup also provides some ways to switch, stop or start the
connection with or without user intervention, like user-managed devices. However, this
always requires root privileges to change or configure a network device. This is often a
problem for mobile computing, where it is not possible to preconfigure all the connection
possibilities.
In case no profile is configured, NetworkManager automatically creates one and names it Auto
$INTERFACE-NAME . That is made in an attempt to work without any configuration for as many
cases as (securely) possible. If the automatically created profiles do not suit your needs, use
the network connection configuration dialogs provided by KDE or GNOME to modify them as
desired. For more information, refer to Section 27.3, “Configuring Network Connections”.
279 NetworkManager Functionality and Configuration Files SUSE Linux Enterp… 11 SP4
When the Kernel detects a network card and creates a corresponding network interface, it assigns
the device a name depending on the order of device discovery, or order of the loading of the
Kernel modules. The default Kernel device names are only predictable in very simple or tightly
controlled hardware environments. Systems which allow adding or removing hardware during
runtime or support automatic configuration of devices cannot expect stable network device
names assigned by the Kernel across reboots.
However, all system configuration tools rely on persistent interface names. This problem is
solved by udev. The udev persistent net generator ( /lib/udev/rules.d/75-persistent-net-
generator.rules ) generates a rule matching the hardware (using its hardware address by de-
fault) and assigns a persistently unique interface for the hardware. The udev database of network
interfaces is stored in the le /etc/udev/rules.d/70-persistent-net.rules . Every line in
the le describes one network interface and specifies its persistent name. System administrators
can change the assigned names by editing the NAME="" entries. The persistent rules can also
be modified using YaST.
Table 22.5, “Manual Network Configuration Scripts” summarizes the most important scripts involved
in the network configuration.
Command Function
For more information about udev and persistent device names, see Chapter 15, Dynamic Kernel
Device Management with udev.
22.6.1.1 /etc/sysconfig/network/ifcfg-*
These les contain the configurations for network interfaces. They include information such
as the start mode and the IP address. Possible parameters are described in the manual page
of ifup . Additionally, most variables from the dhcp le can be used in the ifcfg-* les if
a general setting should be used for only one interface. However, most of the /etc/syscon-
fig/network/config variables are global and cannot be overridden in ifcfg-les. For example
NETWORKMANAGER or NETCONFIG_* variables are global.
IBM Z IBM System z do not support USB. The names of the interface les and network aliases
contain System z-specific elements like qeth .
The le config contains general settings for the behavior of ifup , ifdown and ifstatus .
dhcp contains settings for DHCP. The variables in both configuration les are commented.
Some of the variables from /etc/sysconfig/network/config can also be used in ifcfg-*
The static routing of TCP/IP packets is determined here. All the static routes required by the
various system tasks can be entered in the /etc/sysconfig/network/routes le: routes to a
host, routes to a host via a gateway and routes to a network. For each interface that needs in-
dividual routing, define an additional configuration le: /etc/sysconfig/network/ifroute-
* . Replace * with the name of the interface. The entries in the routing configuration les look
like this:
The route's destination is in the rst column. This column may contain the IP address of a net-
work or host or, in the case of reachable name servers, the fully qualified network or hostname.
The second column contains the default gateway or a gateway through which a host or network
can be accessed. The third column contains the netmask for networks or hosts behind a gateway.
For example, the mask is 255.255.255.255 for a host behind a gateway.
The fourth column is only relevant for networks connected to the local host such as loopback,
Ethernet, ISDN, PPP and dummy device. The device name must be entered here.
An (optional) fth column can be used to specify the type of a route. Columns that are not needed
should contain a minus sign - to ensure that the parser correctly interprets the command. For
details, refer to the routes(5) man page.
The unified format for IPv4 and IPv6 now looks as follows:
prefix/lengthgateway - [interface]
prefixgatewaylength [interface]
For IPv4 you still can use the old format with netmask:
ipv4-networkgatewayipv4-netmask [interface]
22.6.1.4 /etc/resolv.conf
The domain to which the host belongs is specified in this le (keyword search ). Also listed is
the status of the name server address to access (keyword nameserver ). Multiple domain names
can be specified in the le. When resolving a name that is not fully qualified, an attempt is
made to generate one by attaching the individual search entries. Multiple name servers can
be specified in multiple lines, each beginning with nameserver . Comments are preceded by #
signs. Example 22.5, “/etc/resolv.conf” shows what /etc/resolv.conf could look like.
However, the /etc/resolv.conf should not be edited by hand. Instead, it is generated by the
netconfig script. To define static DNS configuration without using YaST, edit the appropriate
variables manually in the /etc/sysconfig/network/config le:
NETCONFIG_DNS_STATIC_SEARCHLIST
list of DNS domain names used for hostname lookup
NETCONFIG_DNS_STATIC_SERVERS
list of name server IP addresses to use for hostname lookup
NETCONFIG_DNS_FORWARDER
defines the name of the DNS forwarder that has to be configured
To disable DNS configuration using netconfig, set NETCONFIG_DNS_POLICY='' . For more infor-
mation about netconfig , see man 8 netconfig .
# Our domain
search example.com
#
# We use dns.example.com (192.168.1.116) as name server
nameserver 192.168.1.116
22.6.1.5 /sbin/netconfig
netconfig is a modular tool to manage additional network configuration settings. It merges
statically defined settings with settings provided by autoconfiguration mechanisms as DHCP or
PPP according to a predefined policy. The required changes are applied to the system by calling
the netconfig modules that are responsible for modifying a configuration le and restarting a
service or a similar action.
netconfig recognizes three main actions. The netconfig modify and netconfig remove
commands are used by daemons such as DHCP or PPP to provide or remove settings to netconfig.
Only the netconfig update command is available for the user:
modify
The netconfig modify command modifies the current interface and service specific dy-
namic settings and updates the network configuration. Netconfig reads settings from stan-
dard input or from a le specified with the --lease-file filename option and internally
stores them until a system reboot (or the next modify or remove action). Already existing
settings for the same interface and service combination are overwritten. The interface is
specified by the -i interface_name parameter. The service is specified by the -s ser-
vice_name parameter.
remove
The netconfig remove command removes the dynamic settings provided by a modifica-
tory action for the specified interface and service combination and updates the network
configuration. The interface is specified by the -i interface_name parameter. The ser-
vice is specified by the -s service_name parameter.
update
The netconfig update command updates the network configuration using current set-
tings. This is useful when the policy or the static configuration has changed. Use the -
m module_type parameter, if you want to update a specified service only ( dns , nis ,
or ntp ).
22.6.1.6 /etc/hosts
EXAMPLE 22.6: /etc/hosts
127.0.0.1 localhost
192.168.2.100 jupiter.example.com jupiter
192.168.2.101 venus.example.com venus
22.6.1.7 /etc/networks
Here, network names are converted to network addresses. The format is similar to that of the
hosts le, except the network names precede the addresses. See Example 22.7, “/etc/networks”.
EXAMPLE 22.7: /etc/networks
loopback 127.0.0.0
localnet 192.168.0.0
Name resolution—the translation of host and network names via the resolver library—is con-
trolled by this le. This le is only used for programs linked to libc4 or libc5. For current glibc
programs, refer to the settings in /etc/nsswitch.conf . A parameter must always stand alone
in its own line. Comments are preceded by a # sign. Table 22.6, “Parameters for /etc/host.conf”
shows the parameters available. A sample /etc/host.conf is shown in Example 22.8, “/etc/
host.conf”.
order hosts, bind Specifies in which order the services are ac-
cessed for the name resolution. Available ar-
guments are (separated by blank spaces or
commas):
EXAMPLE 22.8: /etc/host.conf
22.6.1.9 /etc/nsswitch.conf
The introduction of the GNU C Library 2.0 was accompanied by the introduction of the Name
Service Switch (NSS). Refer to the nsswitch.conf(5) man page and The GNU C Library Reference
Manual for details.
The order for queries is defined in the le /etc/nsswitch.conf . A sample nsswitch.conf
is shown in Example 22.9, “/etc/nsswitch.conf”. Comments are preceded by # signs. In this
example, the entry under the hosts database means that a request is sent to /etc/hosts
( files ) via DNS (see Chapter 25, The Domain Name System).
EXAMPLE 22.9: /etc/nsswitch.conf
passwd: compat
group: compat
services: db files
protocols: db files
rpc: files
ethers: files
netmasks: files
netgroup: files nis
publickey: files
bootparams: files
automount: files nis
aliases: files nis
shadow: compat
The “databases” available over NSS are listed in Table 22.7, “Databases Available via /etc/nss-
witch.conf”.
The configuration options for NSS databases are listed in Table 22.8, “Configuration Options for NSS
“Databases””.
22.6.1.10 /etc/nscd.conf
This le is used to configure nscd (name service cache daemon). See the nscd(8) and
nscd.conf(5) man pages. By default, the system entries of passwd and groups are cached
by nscd. This is important for the performance of directory services, like NIS and LDAP, because
otherwise the network connection needs to be used for every access to names or groups. hosts
is not cached by default, because the mechanism in nscd to cache hosts makes the local system
unable to trust forward and reverse lookup checks. Instead of asking nscd to cache names, set
up a caching DNS server.
If the caching for passwd is activated, it usually takes about fifteen seconds until a newly
added local user is recognized. Reduce this waiting time by restarting nscd with the command
rcnscd restart .
22.6.1.11 /etc/HOSTNAME
This contains the fully qualified hostname with the domain name attached. This le is read
by several scripts while the machine is booting. It must contain only one line (in which the
hostname is set).
ip is a tool to show and configure network devices, routing, policy routing, and tunnels.
ip is a very complex tool. Its common syntax is ip options object command . You can work
with the following objects:
link
This object represents a network device.
address
This object represents the IP address of device.
neighbor
This object represents a ARP or NDISC cache entry.
route
This object represents the routing table entry.
rule
This object represents a rule in the routing policy database.
maddress
This object represents a multicast address.
mroute
This object represents a multicast routing cache entry.
tunnel
This object represents a tunnel over IP.
To have a working connection, you must also configure the default gateway. To set a gateway
for your system, enter ip route add gateway_ip_address . To translate one IP address to
another, use nat : ip route add nat ip_address via other_ip_address .
To display all devices, use ip link ls . To display the running interfaces only, use ip link
ls up . To print interface statistics for a device, enter ip -s link ls device_name . To view
addresses of your devices, enter ip addr . In the output of the ip addr , also nd information
about MAC addresses of your devices. To show all routes, use ip route show .
For more information about using ip , enter ip help or see the ip(8) man page. The help
option is also available for all ip subcommands. If, for example, you need help for ip addr ,
enter ip addr help . Find the ip manual in /usr/share/doc/packages/iproute2/ip-cre-
f.pdf .
The ping command is the standard tool for testing whether a TCP/IP connection works. It uses
the ICMP protocol to send a small data packet, ECHO_REQUEST datagram, to the destination
host, requesting an immediate reply. If this works, ping displays a message to that effect, which
indicates that the network link is basically functioning.
ping does more than only test the function of the connection between two computers: it also
provides some basic information about the quality of the connection. In Example 22.10, “Output
of the Command ping”, you can see an example of the ping output. The second-to-last line con-
tains information about the number of transmitted packets, packet loss, and total time of ping
running.
As the destination, you can use a hostname or IP address, for example, ping example.com or
ping 192.168.3.100 . The program sends packets until you press Ctrl –C .
If you only need to check the functionality of the connection, you can limit the number of
the packets with the -c option. For example to limit ping to three packets, enter ping -c 3
example.com .
ping -c 3 example.com
The default interval between two packets is one second. To change the interval, ping provides
the option -i . For example, to increase the ping interval to ten seconds, enter ping -i 10
example.com .
In a system with multiple network devices, it is sometimes useful to send the ping through a
specific interface address. To do so, use the -I option with the name of the selected device, for
example, ping -I wlan1 example.com .
For more options and information about using ping, enter ping -h or see the ping (8) man
page.
For more options and information about using ifconfig , enter ifconfig -h or see the if-
config (8) man page.
route is a program for manipulating the IP routing table. You can use it to view your routing
configuration and to add or remove routes.
route is especially useful if you need quick and comprehensible information about your routing
configuration to determine problems with routing. To view your current routing configuration,
enter route -n as root .
route -n
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
10.20.0.0 * 255.255.248.0 U 0 0 0 eth0
link-local * 255.255.0.0 U 0 0 0 eth0
loopback * 255.0.0.0 U 0 0 0 lo
default styx.exam.com 0.0.0.0 UG 0 0 0 eth0
For more options and information about using route, enter route -h or see the route (8)
man page.
Apart from the configuration les described above, there are also various scripts that load the
network programs while the machine is booting. These are started as soon as the system is
switched to one of the multiuser runlevels. Some of these scripts are described in Table 22.9, “Some
Start-Up Scripts for Network Programs”.
2. Use Add and change the Device Type to Bond. Proceed with Next.
3. Select how to assign the IP address to the bonding device. Three methods are at your
disposal:
No IP Address
4. In the Bond Slaves tab, select the Ethernet devices that should be included into the bond
by activating the related check box.
balance-rr
active-backup
balance-xor
broadcast
802.3ad
balance-tlb
balance-alb
6. Make sure that the parameter miimon=100 is added to the Bond Driver Options. Without
this parameter, the data integrity is not checked regularly.
All modes, and many more options are explained in detail in the Linux Ethernet Bonding Dri-
ver HOWTO found at /usr/src/linux/Documentation/networking/bonding.txt after in-
stalling the package kernel-source .
ifcfg-bond0
STARTMODE='auto' # or 'onboot'
BOOTPROTO='static'
IPADDR='192.168.0.1/24'
BONDING_MASTER='yes'
BONDING_SLAVE_0='eth0'
BONDING_SLAVE_1='eth1'
BONDING_MODULE_OPTS='mode=active-backup miimon=100'
ifcfg-eth0
STARTMODE='hotplug'
BOOTPROTO='none'
ifcfg-eth1
STARTMODE='hotplug'
BOOTPROTO='none'
BOOTPROTO=none uses the ethtool options (when provided), but does not set the link up on
ifup eth0 . The reason is that the slave interface is controlled by the bond master.
STARTMODE=hotplug causes the slave interface to join the bond automatically as soon as it is
available.
The udev rules in /etc/udev/rules.d/70-persistent-net.rules have to be changed to
match the device by bus ID (udev KERNELS keyword equal to "SysFS BusID" as visible in hwin-
fo --netcard ) instead of by MAC address to allow to replacement of defective hardware (a
network card in the same slot but with a different MAC), and to avoid confusion as the bond
changes the MAC address of all its slaves.
For example:
At boot time, /etc/init.d/network does not wait for the hotplug slaves, but for the bond
to become ready, which requires at least one available slave. When one of the slave interfaces
gets removed (unbind from NIC driver, rmmod of the NIC driver or true PCI hotplug remove)
from the system, the kernel removes it from the bond automatically. When a new card is added
to the system (replacement of the hardware in the slot), udev renames it using the bus-based
persistent name rule to the name of the slave, and calls ifup for it. The ifup call automatically
joins it into the bond.
open-inet-socket = yes|no
To control smpppd via the network, set this option to yes . smpppd listens on port 3185 . If
this parameter is set to yes , the parameters bind-address , host-range and password
must be set accordingly.
bind-address = ip address
If a host has several IP addresses, use this parameter to determine at which IP address
smpppd should accept connections. The default is to listen at all addresses.
password = password
By assigning a password, limit the clients to authorized hosts. As this is a plain-text pass-
word, you should not overrate the security it provides. If no password is assigned, all clients
are permitted to access smpppd.
slp-register = yes|no
More information about smpppd is available in the smpppd(8) and smpppd.conf(5) man
pages.
cinternet can be used to control a local or remote smpppd. cinternet is the command-line coun-
terpart to the graphical KInternet. To prepare these utilities for use with a remote smpppd, edit
the configuration le /etc/smpppd-c.conf manually or using cinternet. This le only uses
four options:
server = server
The host on which smpppd runs.
port = port
The port on which smpppd runs.
password = password
The password selected for smpppd.
If smpppd is active, try to access it. For example, with cinternet --verbose --inter-
face-list . In case of difficulties at this point, refer to the smpppd-c.conf(5) and cinter-
net(8) man pages.
300 Configuring cinternet for Remote Use SUSE Linux Enterp… 11 SP4
23 SLP Services in the Network
The service location protocol (SLP) was developed to simplify the configuration of
networked clients within a local network. To configure a network client, including
all required services, the administrator traditionally needs detailed knowledge of
the servers available in the network. SLP makes the availability of selected services
known to all clients in the local network. Applications that support SLP can use the
information distributed and be configured automatically.
SUSE® Linux Enterprise Server supports installation using installation sources provided with
SLP and contains many system services with integrated support for SLP. YaST and Konqueror
both have appropriate front-ends for SLP. You can use SLP to provide networked clients with
central functions, such as an installation server, le server, or print server on your system.
23.1 Installation
All packages necessary are installed by default. However, if you want to provide services via
SLP, check that the package openslp-server is installed.
slptool
slptool is a command line program that can be used to announce SLP inquiries in the
network or announce proprietary services. slptool --help lists all available options and
functions. For example, to nd all time servers that announce themselves in the current
network, run the command:
YaST
YaST also provides an SLP browser. However, this browser is not available from the YaST
Control Center. To start it, run yast2 slp as root user. Click on a Service Type on the
lefthand side to get more information about a service.
302 SLP Front-Ends in SUSE Linux Enterprise Server SUSE Linux Enterp… 11 SP4
## en means english language
## 65535 disables the timeout, so the service registration does
## not need refreshes
service:scanner.sane://$HOSTNAME:6566,en,65535
watch-port-tcp=6566
description=SANE scanner daemon
The most important line in this le is the service URL, which begins with service: . This
contains the service type ( scanner.sane ) and the address under which the service is
available on the server. $HOSTNAME is automatically replaced with the full hostname. The
name of the TCP port on which the relevant service can be found follows, separated by
a colon. Then enter the language in which the service should appear and the duration of
registration in seconds. These should be separated from the service URL by commas. Set
the value for the duration of registration between 0 and 65535 . 0 prevents registration.
65535 removes all restrictions.
The registration le also contains the two variables watch-port-tcp and description .
watch-port-tcp links the SLP service announcement to whether the relevant service is
active by having slpd check the status of the service. The second variable contains a more
precise description of the service that is displayed in suitable browsers.
http://www.openslp.org
The home page of the OpenSLP project.
/usr/share/doc/packages/openslp
This directory contains the documentation for SLP coming with the openslp-server
package, including a README.SuSE containing the SUSE Linux Enterprise Server details,
the RFCs, and two introductory HTML documents. Programmers who want to use the SLP
functions nd more information in the Programmers Guide that is included in the openslp-
devel package.
The NTP (network time protocol) mechanism is a protocol for synchronizing the
system time over the network. First, a machine can obtain the time from a server
that is a reliable time source. Second, a machine can itself act as a time source for
other computers in the network. The goal is twofold—maintaining the absolute time
and synchronizing the system time of all machines within a network.
Maintaining an exact system time is important in many situations. The built-in hardware clock
does often not meet the requirements of applications such as databases or clusters. Manual
correction of the system time would lead to severe problems because, for example, a backward
leap can cause malfunction of critical applications. Within a network, it is usually necessary to
synchronize the system time of all machines, but manual time adjustment is a bad approach. NTP
provides a mechanism to solve these problems. The NTP service continuously adjusts the system
time with the help of reliable time servers in the network. It further enables the management
of local reference clocks, such as radio-controlled clocks.
Only Manually
Select Only Manually, if you want to manually start the ntpd daemon.
305 Configuring an NTP Client with YaST SUSE Linux Enterp… 11 SP4
24.1.2 Changing Basic Configuration
The servers and other time sources for the client to query are listed in the lower part of the
General Settings tab. Modify this list as needed with Add, Edit, and Delete. Display Log provides
the possibility to view the log les of your client.
Click Add to add a new source of time information. In the following dialog, select the type of
source with which the time synchronization should be made. The following options are available:
Server
In the pull-down Select list (see Figure 24.1, “YaST: NTP Server”), determine whether to set up
time synchronization using a time server from your local network (Local NTP Server) or
an Internet-based time server that takes care of your time zone (Public NTP Server). For
a local time server, click Lookup to start an SLP query for available time servers in your
network. Select the most suitable time server from the list of search results and exit the
dialog with OK. For a public time server, select your country (time zone) and a suitable
server from the list under Public NTP Server then exit the dialog with OK. In the main
dialog, test the availability of the selected server with Test. Options allows you to specify
additional options for ntpd .
Peer
A peer is a machine to which a symmetric relationship is established: it acts both as a time
server and as a client. To use a peer in the same network instead of a server, enter the
address of the system. The rest of the dialog is identical to the Server dialog.
Radio Clock
To use a radio clock in your system for the time synchronization, enter the clock type, unit
number, device name, and other options in this dialog. Click Driver Calibration to ne-tune
the driver. Detailed information about the operation of a local radio clock is available in
/usr/share/doc/packages/ntp-doc/refclock.html .
Outgoing Broadcast
Time information and queries can also be transmitted by broadcast in the network. In
this dialog, enter the address to which such broadcasts should be sent. Do not activate
broadcasting unless you have a reliable time source like a radio controlled clock.
Incoming Broadcast
If you want your client to receive its information via broadcast, enter the address from
which the respective packets should be accepted in this elds.
In the Security Settings tab (see Figure 24.2, “Advanced NTP Configuration: Security Settings”), deter-
mine whether ntpd should be started in a chroot jail. By default, Run NTP Daemon in Chroot
Jail is activated. This increases the security in the event of an attack over ntpd , as it prevents
the attacker from compromising the entire system.
Restrict NTP Service to Configured Servers Only increases the security of your system by disallowing
remote computers to view and modify NTP settings of your computer and to use the trap facility
for remote event logging. Once enabled, these restrictions apply to all remote computers, unless
you override the access control options for individual computers in the list of time sources in
the General Settings tab. For all other remote computers, only querying for local time is allowed.
Enable Open Port in Firewall if SuSEfirewall2 is active (which it is by default). If you leave the
port closed, it is not possible to establish a connection to the time server.
server ntp.example.com
To add more time servers, insert additional lines with the keyword server . After initializing
ntpd with the command rcntp start , it takes about one hour until the time is stabilized and
the drift le for correcting the local computer clock is created. With the drift le, the systematic
error of the hardware clock can be computed as soon as the computer is powered on. The
correction is used immediately, resulting in a higher stability of the system time.
There are two possible ways to use the NTP mechanism as a client: First, the client can query
the time from a known server in regular intervals. With many clients, this approach can cause
a high load on the server. Second, the client can wait for NTP broadcasts sent out by broadcast
time servers in the network. This approach has the disadvantage that the quality of the server
is unknown and a server sending out wrong information can cause severe problems.
If the time is obtained via broadcast, you do not need the server name. In this case, enter the
line broadcastclient in the configuration le /etc/ntp.conf . To use one or more known
time servers exclusively, enter their names in the line starting with servers .
309 Manually Configuring NTP in the Network SUSE Linux Enterp… 11 SP4
2. Select the server you want to configure. Then click Edit.
3. Activate the Options eld and add dynamic . Separate it with a space, if there are already
other options entered.
4. Click Ok to close the edit dialog. Repeat the previous step to change all servers as wanted.
Other clocks follow the same pattern. Following the installation of the ntp-doc package, the
documentation for NTP is available in the directory /usr/share/doc/packages/ntp-doc . The
le /usr/share/doc/packages/ntp-doc/refclock.html provides links to the driver pages
describing the driver parameters.
311 Clock Synchronization to an External Time Reference (ETR) SUSE Linux Enterp… 11 SP4
25 The Domain Name System
DNS (domain name system) is needed to resolve the domain names and hostnames
into IP addresses. In this way, the IP address 192.168.2.100 is assigned to the host-
name jupiter , for example. Before setting up your own name server, read the gen-
eral information about DNS in Section 22.3, “Name Resolution”. The following configu-
ration examples refer to BIND.
Zone
The domain namespace is divided into regions called zones. For instance, if you have
example.com , you have the example section (or zone) of the com domain.
DNS server
The DNS server is a server that maintains the name and IP information for a domain. You
can have a primary DNS server for master zone, a secondary server for slave zone, or a
slave server without any zones for caching.
Forwarder
Forwarders are DNS servers to which your DNS server should send queries it cannot an-
swer. To enable different configuration sources in one configuration, netconfig is used
(see also man 8 netconfig ).
Record
NS record
An NS record tells name servers which machines are in charge of a given domain
zone.
MX record
The MX (mail exchange) records describe the machines to contact for directing mail
across the Internet.
SOA record
SOA (Start of Authority) record is the rst record in a zone le. The SOA record is
used when using DNS to synchronize data between multiple computers.
25.2 Installation
To install a DNS server, start YaST and select Software Software Management. Choose View Pat-
terns and select DHCP and DNS Server. Confirm the installation of the dependent packages to
finish the installation process.
Forwarders are DNS servers to which your DNS server sends queries it cannot answer
itself. Enter their IP address and click Add.
2. The DNS Zones dialog consists of several parts and is responsible for the management of
zone les, described in Section 25.6, “Zone Files”. For a new zone, provide a name for it in
Name. To add a reverse zone, the name must end in .in-addr.arpa . Finally, select the
Type (master, slave, or forward). See Figure 25.2, “DNS Server Installation: DNS Zones”. Click
Edit to configure other settings of an existing zone. To remove a zone, click Delete.
3. In the final dialog, you can open the DNS port in the firewall by clicking Open Port in
Firewall. Then decide whether to start the DNS server when booting (On or O). You can
also activate LDAP support. See Figure 25.3, “DNS Server Installation: Finish Wizard”.
25.3.2.1 Start-Up
Under Start-Up, define whether the DNS server should be started when the booting the system
or manually. To start the DNS server immediately, click Start DNS Server Now. To stop the DNS
server, click Stop DNS Server Now. To save the current settings, select Save Settings and Reload
DNS Server Now. You can open the DNS port in the firewall with Open Port in Firewall and modify
the firewall settings with Firewall Details.
By selecting LDAP Support Active, the zone les are managed by an LDAP database. Any changes
to zone data written to the LDAP database are picked up by the DNS server as soon as it is
restarted or prompted to reload its configuration.
25.3.2.2 Forwarders
If your local DNS server cannot answer a request, it tries to forward the request to a Forwarder,
if configured so. This forwarder may be added manually to the Forwarder List. If the forwarder is
not static like in dial-up connections, netconfig handles the configuration. For more information
about netconfig, see man 8 netconfig .
In this section, set basic server options. From the Option menu, select the desired item then
specify the value in the corresponding entry eld. Include the new entry by selecting Add.
25.3.2.4 Logging
To set what the DNS server should log and how, select Logging. Under Log Type, specify where
the DNS server should write the log data. Use the systemwide log le /var/log/messages by
selecting System Log or specify a different le by selecting File. In the latter case, additionally
specify a name, the maximum le size in megabytes and the number of logfile versions to store.
25.3.2.5 ACLs
Use this dialog to define ACLs (access control lists) to enforce access restrictions. After providing
a distinct name under Name, specify an IP address (with or without netmask) under Value in
the following fashion:
{ 192.168.1/24; }
The syntax of the configuration le requires that the address ends with a semicolon and is put
into curly braces.
The main purpose of TSIGs (transaction signatures) is to secure communications between DHCP
and DNS servers. They are described in Section 25.8, “Secure Transactions”.
To generate a TSIG key, enter a distinctive name in the eld labeled Key ID and specify the le
where the key should be stored (Filename). Confirm your choices with Generate.
To use a previously created key, leave the Key ID eld blank and select the le where it is stored
under Filename. After that, confirm with Add.
To add a slave zone, select DNS Zones, choose the zone type Slave, write the name of the new
zone, and click Add.
In the Zone Editor sub-dialog under Master DNS Server IP, specify the master from which the
slave should pull its data. To limit access to the server, select one of the ACLs from the list.
To add a master zone, select DNS Zones, choose the zone type Master, write the name of the new
zone, and click Add. When adding a master zone, a reverse zone is also needed. For example,
when adding the zone example.com that points to hosts in a subnet 192.168.1.0/24 , you
should also add a reverse zone for the IP-address range covered. By definition, this should be
named 1.168.192.in-addr.arpa .
To edit a master zone, select DNS Zones, select the master zone from the table, and click Edit.
The dialog consists of several pages: Basics (the one opened rst), NS Records, MX Records, SOA,
and Records.
The basic dialog, shown in Figure 25.5, “DNS Server: Zone Editor (Basics)”, lets you define settings for
dynamic DNS and access options for zone transfers to clients and slave name servers. To permit
the dynamic updating of zones, select Allow Dynamic Updates as well as the corresponding TSIG
key. The key must have been defined before the update action starts. To enable zone transfers,
select the corresponding ACLs. ACLs must have been defined already.
hostname.example.com. IN A 192.168.0.1
1.0.168.192.in-addr.arpa IN PTR hostname.example.com.
However, do not set up an official domain until one is assigned to you by the responsible insti-
tution. Even if you have your own domain and it is managed by the provider, you are better
o not using it, because BIND would otherwise not forward requests for this domain. The Web
server at the provider, for example, would not be accessible for this domain.
To start the name server, enter the command rcnamed start as root . If “done” appears to the
right in green then named (as the name server process is called) has been started successfully.
Test the name server immediately on the local system with the host or dig programs, which
should return localhost as the default server with the address 127.0.0.1 . If this is not the
case, /etc/resolv.conf probably contains an incorrect name server entry or the le does not
exist at all. For the rst test, enter host 127.0.0.1 , which should always work. If you get
322 Starting the BIND Name Server SUSE Linux Enterp… 11 SP4
an error message, use rcnamed status to see whether the server is actually running. If the
name server does not start or behaves unexpectedly, you can usually nd the cause in the log
le /var/log/messages .
To use the name server of the provider (or one already running on your network) as the for-
warder, enter the corresponding IP address or addresses in the options section under for-
warders . The addresses included in Example 25.1, “Forwarding Options in named.conf” are just ex-
amples. Adjust these entries to your own setup.
EXAMPLE 25.1: FORWARDING OPTIONS IN NAMED.CONF
options {
directory "/var/lib/named";
forwarders { 10.11.12.13; 10.11.12.14; };
listen-on { 127.0.0.1; 192.168.1.116; };
allow-query { 127/8; 192.168/16 };
notify no;
};
The options entry is followed by entries for the zone, localhost , and 0.0.127.in-ad-
dr.arpa . The type hint entry under “.” should always be present. The corresponding les do
not need to be modified and should work as they are. Also make sure that each entry is closed
with a “;” and that the curly braces are in the correct places. After changing the configuration le
/etc/named.conf or the zone les, tell BIND to reread them with rcnamed reload . Achieve
the same by stopping and restarting the name server with rcnamed restart . Stop the server
at any time by entering rcnamed stop .
options {
zone "localhost" in {
type master;
file "localhost.zone";
};
zone "0.0.127.in-addr.arpa" in {
type master;
file "127.0.0.zone";
};
zone "." in {
type hint;
file "root.hint";
};
forwarders { ip-address ; };
Specifies the name servers (mostly of the provider) to which DNS requests should be for-
warded if they cannot be resolved directly. Replace ip-address with an IP address like
192.168.1.116 .
forward first;
Causes DNS requests to be forwarded before an attempt is made to resolve them via the
root name servers. Instead of forward first , forward only can be written to have all
requests forwarded and none sent to the root name servers. This makes sense for firewall
configurations.
allow-transfer ! *;;
Controls which hosts can request zone transfers. In the example, such requests are com-
pletely denied with ! * . Without this entry, zone transfers can be requested from any-
where without restrictions.
statistics-interval 0;
In the absence of this entry, BIND generates several lines of statistical information per
hour in /var/log/messages . Set it to 0 to suppress these statistics completely or set an
interval in minutes.
cleaning-interval 720;
This option defines at which time intervals BIND clears its cache. This triggers an entry in
/var/log/messages each time it occurs. The time specification is in minutes. The default
is 60 minutes.
interface-interval 0;
BIND regularly searches the network interfaces for new or nonexistent interfaces. If this
value is set to 0 , this is not done and BIND only listens at the interfaces detected at start-
up. Otherwise, the interval can be defined in minutes. The default is sixty minutes.
For a list of available options, read the manual page man 5 named.conf .
25.5.2 Logging
What, how, and where logging takes place can be extensively configured in BIND. Normally, the
default settings should be sufficient. Example 25.3, “Entry to Disable Logging”, shows the simplest
form of such an entry and completely suppresses any logging.
logging {
category default { null; };
};
zone "example.com" in {
type master;
file "example.com.zone";
notify no;
};
After zone , specify the name of the domain to administer ( example.com ) followed by in and
a block of relevant options enclosed in curly braces, as shown in Example 25.4, “Zone Entry for
example.com”. To define a slave zone, switch the type to slave and specify a name server that
administers this zone as master (which, in turn, may be a slave of another master), as shown
in Example 25.5, “Zone Entry for example.net”.
zone "example.net" in {
type slave;
file "slave/example.net.zone";
masters { 10.0.0.1; };
};
type master;
By specifying master , tell BIND that the zone is handled by the local name server. This
assumes that a zone le has been created in the correct format.
type slave;
This zone is transferred from another name server. It must be used together with masters .
type hint;
The zone . of the hint type is used to set the root name servers. This zone definition
can be left as is.
masters { server-ip-address ; };
This entry is only needed for slave zones. It specifies from which name server the zone
le should be transferred.
allow-update {! *; };
This option controls external write access, which would allow clients to make a DNS en-
try—something not normally desirable for security reasons. Without this entry, zone up-
dates are not allowed at all. The above entry achieves the same because ! * effectively
bans any such activity.
1. $TTL 2D
2. example.com. IN SOA dns root.example.com. (
3. 2003072441 ; serial
4. 1D ; refresh
5. 2H ; retry
6. 1W ; expiry
7. 2D ) ; minimum
8.
9. IN NS dns
10. IN MX 10 mail
11.
12. gate IN A 192.168.5.1
13. IN A 10.0.0.1
14. dns IN A 192.168.1.116
15. mail IN A 192.168.3.108
16. jupiter IN A 192.168.2.100
17. venus IN A 192.168.2.101
18. saturn IN A 192.168.2.102
19. mercury IN A 192.168.2.103
20. ntp IN CNAME dns
21. dns6 IN A6 0 2002:c0a8:174::
Line 1:
$TTL defines the default time to live that should apply to all the entries in this le. In this
example, entries are valid for a period of two days ( 2 D ).
Line 2:
This is where the SOA (start of authority) control record begins:
The name of the domain to administer is example.com in the rst position. This
ends with "." , because otherwise the zone would be appended a second time. Al-
ternatively, @ can be entered here, in which case the zone would be extracted from
the corresponding entry in /etc/named.conf .
After IN SOA is the name of the name server in charge as master for this zone. The
name is expanded from dns to dns.example.com , because it does not end with a
"." .
Line 3:
The serial number is an arbitrary number that is increased each time this le is changed.
It is needed to inform the secondary name servers (slave servers) of changes. For this, a
10 digit number of the date and run number, written as YYYYMMDDNN, has become the
customary format.
Line 4:
The refresh rate specifies the time interval at which the secondary name servers verify
the zone serial number . In this case, one day.
Line 5:
The retry rate specifies the time interval at which a secondary name server, in case of
error, attempts to contact the primary server again. Here, two hours.
Line 6:
The expiration time specifies the time frame after which a secondary name server
discards the cached data if it has not regained contact to the primary server. Here, a week.
Line 7:
The last entry in the SOA record specifies the negative caching TTL —the time for which
results of unresolved DNS queries from other servers may be cached.
Line 9:
The IN NS specifies the name server responsible for this domain. dns is extended to
dns.example.com because it does not end with a "." . There can be several lines like
this—one for the primary and one for each secondary name server. If notify is not set
to no in /etc/named.conf , all the name servers listed here are informed of the changes
made to the zone data.
Line 10:
Lines 12–19:
These are the actual address records where one or more IP addresses are assigned to host-
names. The names are listed here without a "." because they do not include their domain,
so example.com is added to all of them. Two IP addresses are assigned to the host gate ,
as it has two network cards. Wherever the host address is a traditional one (IPv4), the
record is marked with A . If the address is an IPv6 address, the entry is marked with AAAA .
Line 20:
The alias ntp can be used to address dns ( CNAME means canonical name).
The pseudodomain in-addr.arpa is used for the reverse lookup of IP addresses into hostnames.
It is appended to the network part of the address in reverse notation. So 192.168 is resolved
into 168.192.in-addr.arpa . See Example 25.7, “Reverse Lookup”.
EXAMPLE 25.7: REVERSE LOOKUP
1. $TTL 2D
2. 168.192.in-addr.arpa. IN SOA dns.example.com. root.example.com. (
3. 2003072441 ; serial
4. 1D ; refresh
5. 2H ; retry
6. 1W ; expiry
7. 2D ) ; minimum
Line 1:
$TTL defines the standard TTL that applies to all entries here.
Line 2:
The configuration le should activate reverse lookup for the network 192.168 . Given
that the zone is called 168.192.in-addr.arpa , it should not be added to the hostnames.
Therefore, all hostnames are entered in their complete form—with their domain and with
a "." at the end. The remaining entries correspond to those described for the previous
example.com example.
Lines 3–7:
See the previous example for example.com .
Line 9:
Again this line specifies the name server responsible for this zone. This time, however, the
name is entered in its complete form with the domain and a "." at the end.
Lines 11–13:
These are the pointer records hinting at the IP addresses on the respective hosts. Only the
last part of the IP address is entered at the beginning of the line, without the "." at the
end. Appending the zone to this (without the .in-addr.arpa ) results in the complete IP
address in reverse order.
Normally, zone transfers between different versions of BIND should be possible without any
problems.
Khost1-host2.+157+34265.private Khost1-host2.+157+34265.key
The key itself (a string like ejIkuCyyGJwwuN3xAteKgg== ) is found in both les. To use it for
transactions, the second le ( Khost1-host2.+157+34265.key ) must be transferred to the re-
mote host, preferably in a secure way (using scp, for example). On the remote server, the key
must be included in the /etc/named.conf le to enable a secure communication between
host1 and host2 :
key host1-host2 {
algorithm hmac-md5;
secret "ejIkuCyyGJwwuN3xAteKgg==";
};
include "filename"
To enable the server host1 to use the key for host2 (which has the address 10.1.2.3 in this
example), the server's /etc/named.conf must include the following rule:
server 10.1.2.3 {
keys { host1-host2. ;};
};
This topic is discussed in more detail in the BIND Administrator Reference Manual under up-
date-policy .
One way to configure a DHCP server is to identify each client using the hardware address of
its network card (which should be xed in most cases), then supply that client with identical
settings each time it connects to the server. DHCP can also be configured to assign addresses to
each relevant client dynamically from an address pool set up for this purpose. In the latter case,
the DHCP server tries to assign the same address to the client each time it receives a request,
even over extended periods. This works only if the network does not have more clients than
addresses.
DHCP makes life easier for system administrators. Any changes, even bigger ones, related to
addresses and the network configuration in general can be implemented centrally by editing the
server's configuration le. This is much more convenient than reconfiguring numerous worksta-
tions. It is also much easier to integrate machines, particularly new machines, into the network,
because they can be given an IP address from the pool. Retrieving the appropriate network
settings from a DHCP server is especially useful in case of laptops regularly used in different
networks.
In this chapter, the DHCP server will run in the same subnet as the workstations,
192.168.2.0/24 with 192.168.2.1 as gateway. It has the xed IP address 192.168.2.254
and serves two address ranges, 192.168.2.10 to 192.168.2.20 and 192.168.2.100 to
192.168.2.200 .
The YaST DHCP module ( yast2-dhcp-server ) allows you to set up your own DHCP server for
the local network. The module can run in wizard mode or expert configuration mode.
1. Select the interface from the list to which the DHCP server should listen and click Select.
After this, select Open Firewall for Selected Interfaces to open the firewall for this interface,
and click Next. See Figure 26.1, “DHCP Server: Card Selection”.
336 Configuring a DHCP Server with YaST SUSE Linux Enterp… 11 SP4
FIGURE 26.1: DHCP SERVER: CARD SELECTION
2. Use the check box to determine whether your DHCP settings should be automatically
stored by an LDAP server. In the entry elds, provide the network specics for all clients
the DHCP server should manage. These specics are the domain name, address of a time
server, addresses of the primary and secondary name server, addresses of a print and a
WINS server (for a mixed network with both Windows and Linux clients), gateway address,
and lease time. See Figure 26.2, “DHCP Server: Global Settings”.
4. Define how the DHCP server should be started. Specify whether to start the DHCP server
automatically when the system is booted or manually when needed (for example, for
testing purposes). Click Finish to complete the configuration of the server. See Figure 26.4,
“DHCP Server: Start-Up”.
5. Instead of using dynamic DHCP in the way described in the preceding steps, you can also
configure the server to assign addresses in quasi-static fashion. Use the entry elds pro-
vided in the lower part to specify a list of the clients to manage in this way. Specifically,
provide the Name and the IP Address to give to such a client, the Hardware Address, and the
Network Type (token ring or Ethernet). Modify the list of clients, which is shown in the up-
per part with Add, Edit, and Delete from List. See Figure 26.5, “DHCP Server: Host Management”.
Subnet Configuration
This dialog allows you specify a new subnet with its IP address and netmask. In the middle
part of the dialog, modify the DHCP server start options for the selected subnet using Add,
Edit, and Delete. To set up dynamic DNS for the subnet, select Dynamic DNS.
After completing all configuration steps, close the dialog with OK. The server is now started
with its new configuration.
This simple configuration le should be sufficient to get the DHCP server to assign IP addresses
in the network. Make sure that a semicolon is inserted at the end of each line, because otherwise
dhcpd is not started.
The sample le can be divided into three sections. The rst one defines how many seconds an
IP address is leased to a requesting client by default ( default-lease-time ) before it should
apply for renewal. This section also includes a statement of the maximum period for which a
machine may keep an IP address assigned by the DHCP server without applying for renewal
( max-lease-time ).
The line option domain-name defines the default domain of your network.
With the entry option domain-name-servers , specify up to three values for the DNS
servers used to resolve IP addresses into hostnames and vice versa. Ideally, configure a
name server on your machine or somewhere else in your network before setting up DHCP.
That name server should also define a hostname for each dynamic address and vice versa.
To learn how to configure your own name server, read Chapter 25, The Domain Name System.
The line option broadcast-address defines the broadcast address the requesting client
should use.
With option routers , set where the server should send data packets that cannot be
delivered to a host on the local network (according to the source and target host address
and the subnet mask provided). In most cases, especially in smaller networks, this router
is identical to the Internet gateway.
The last section of the le defines a network, including a subnet mask. To finish, specify the
address range that the DHCP daemon should use to assign IP addresses to interested clients. In
Example 26.1, “The Configuration File /etc/dhcpd.conf”, clients may be given any address between
192.168.2.10 and 192.168.2.20 as well as 192.168.2.100 and 192.168.2.200 .
After editing these few lines, you should be able to activate the DHCP daemon with the command
rcdhcpd start . It will be ready for use immediately. Use the command rcdhcpd check-
syntax to perform a brief syntax check. If you encounter any unexpected problems with your
configuration (the server aborts with an error or does not return done on start), you should be
able to nd out what has gone wrong by looking for information either in the main system log
/var/log/messages or on console 10 ( Ctrl – Alt – F10 ).
DHCP can also be used to assign a predefined, static address to a specific client. Addresses as-
signed explicitly always take priority over dynamic addresses from the pool. A static address
never expires in the way a dynamic address would, for example, if there were not enough ad-
dresses available and the server needed to redistribute them among clients.
To identify a client configured with a static address, dhcpd uses the hardware address (which
is a globally unique, xed numerical code consisting of six octet pairs) for the identification of
all network devices (for example, 00:30:6E:08:EC:80 ). If the respective lines, like the ones in
Example 26.2, “Additions to the Configuration File”, are added to the configuration le of Example 26.1,
“The Configuration File /etc/dhcpd.conf”, the DHCP daemon always assigns the same set of data to
the corresponding client.
host jupiter {
hardware ethernet 00:30:6E:08:EC:80;
fixed-address 192.168.2.100;
}
The name of the respective client ( host hostname , here jupiter ) is entered in the rst line
and the MAC address in the second line. On Linux hosts, nd the MAC address with the command
ip link show followed by the network device (for example, eth0 ). The output should contain
something like
link/ether 00:30:6E:08:EC:80
In the preceding example, a client with a network card having the MAC address
00:30:6E:08:EC:80 is assigned the IP address 192.168.2.100 and the hostname jupiter
automatically. The type of hardware to enter is ethernet in nearly all cases, although to-
ken-ring , which is often found on IBM systems, is also supported.
To enable dhcpd to resolve hostnames even from within the chroot environment, some other
configuration les must be copied as well:
/etc/localtime
/etc/host.conf
/etc/hosts
/etc/resolv.conf
These les are copied to /var/lib/dhcp/etc/ when starting the init script. Take these copies
into account for any changes that they require if they are dynamically modified by scripts like
/etc/ppp/ip-up . However, there should be no need to worry about this if the configuration
le only specifies IP addresses (instead of hostnames).
If your configuration includes additional les that should be copied into the chroot environment,
set these under the variable DHCPD_CONF_INCLUDE_FILES in the le /etc/sysconfig/dhcpd .
To ensure that the DHCP logging facility keeps working even after a restart of the syslog-ng
daemon, there is an additional entry SYSLOGD_ADDITIONAL_SOCKET_DHCP in the le /etc/
sysconfig/syslog .
350 The SUSE Linux Enterprise Server Version SUSE Linux Enterp… 11 SP4
27 Using NetworkManager
NetworkManager is the ideal solution for laptops and other portable computers. It supports
state-of-the-art encryption types and standards for network connections, including connections
to 802.1X protected networks. 802.1X is the “IEEE Standard for Local and Metropolitan Area
Networks—Port-Based Network Access Control”. With NetworkManager, you need not worry
about configuring network interfaces and switching between wired or wireless networks when
you are moving. NetworkManager can automatically connect to known wireless networks or
manage several network connections in parallel—the fastest connection is then used as default.
Furthermore, you can manually switch between available networks and manage your network
connection using an applet in the system tray.
Instead of only one connection being active, multiple connections may be active at once. This
enables you to unplug your laptop from an Ethernet and remain connected via a wireless con-
nection.
Your computer provides network services for other computers in your network, for exam-
ple, it is a DHCP or DNS server.
Your computer is a Xen server or your system is a virtual system inside Xen.
a. In the Network Setup Method eld, select User Controlled with NetworkManager.
a. In the Network Setup Method eld, choose Traditional Method with ifup.
b. Click OK.
c. Set up your network card with YaST using automatic configuration via DHCP or a
static IP address. Alternatively, configure your modem with YaST:
To open the network configuration dialog in GNOME, open the main menu and click the Network
entry at the right. Alternatively, press Alt – F2 and enter nm-connection-editor or select
System Network Connections in the GNOME Control Center.
If you use KDE, open the main menu and click Configure Desktop. In the Personal Settings, select
Network Settings (on the General tab) to open the network configuration dialog.
When configuring network connections with NetworkManager, you can also define sys-
tem connections that can be shared by all users. In contrast to user connections ,
system connections are made available right after NetworkManager is started—before any
users log in. For more details about both types of connections, refer to Section 27.7.1, “User
and System Connections”.
Currently, the system connection option is not available in KDE. To set up system
connections, you need to use YaST in this case.
1. In the network configuration dialog, click the tab for the connection type you want to use.
2. Click Add to create a new connection or select an existing connection and click Edit.
4. For a hidden network, enter the ESSID and the encryption parameters.
5. You can tie the connection to a certain device, if more than one physical device per con-
nection type is available (for example, your machine is equipped with two ethernet cards
or two wireless cards).
If you use KDE, do so by using the Restrict to Interface option. If you use GNOME, enter the
MAC address of the device you want to tie the connection to and confirm your settings.
7. To turn a connection into a system connection activate Available to all users (GNOME).
To create and edit system connections, root permission is required.
After having confirmed your changes, the newly configured network connection appears in the
list of available networks you get by left-clicking the NetworkManager applet.
1. Left-click the applet icon to show a menu with available networks. The connection cur-
rently being used is selected in the menu and marked as Active.
3. Click the KNetworkManager icon and select the newly configured connection to activate it.
1. Left-click the applet icon and select Create Network Connection. KNetworkManager shows
a list of available visible wireless networks, including details about signal strength and
security.
2. To connect to a visible network, select the network from the list and click Connect. If the
network is encrypted, a dialog opens. Choose the type of Security the network uses and
enter the appropriate credentials.
3. To connect to a network that does not broadcast its service set identifier (SSID or ESSID)
and therefore cannot be detected automatically, select Connect to Other Network with WLAN
interface.
4. In the dialog that opens, enter the SSID or ESSID and set encryption parameters, if nec-
essary.
5. Confirm your changes and click OK. NetworkManager now activates the new connection.
6. To terminate a connection and to disable wireless networking, click the applet icon and
uncheck Enable Wireless. This can be useful if you are on a plane or in any other environ-
ment where wireless networking is not allowed.
A wireless network that has been chosen explicitly will remain connected as long as possible. If
a network cable is plugged in during that time, any connections that have been set to Connect
Automatically will be connected, while the wireless connection remains up.
1. Click the KNetworkManager applet and select Create Network Connection New Ad-Hoc
Network.
2. In the following configuration dialog, enter a name for your network in the SSID eld.
357 Configuring Your Wireless Card as an Access Point SUSE Linux Enterp… 11 SP4
Important: Unprotected Wireless Networks Are a Security
Risk
If you set Security to None , everybody can connect to your network, reuse your
connectivity and intercept your network connection. To restrict access to your ac-
cess point and to secure your connection, use encryption. You can choose between
various WEP and WPA–based encryptions. If you are not sure which technology is
best for you, read Section 19.3, “Authentication”.
4. On the IP Address tab, make sure the Configure option is set to Shared (which is the default
option for ad-hoc networks).
To explore the options available, right-click the NetworkManager system tray icon, select Man-
age Connections and click Other on the left-hand side of the configuration dialog.
As KNetworkManager can keep multiple connections active at once, you might wish to
be informed about the connection status for several connections at one glance. You can
do so by using multiple NetworkManager icons in your system tray, each representing a
different group of connection types (for example, one icon for wired connections, another
icon for wireless connections).
3. Select the network connection types you want to be represented by this icon and group
them under the respective icon.
Now the system tray shows multiple NetworkManager icons from which you then can access
the connection types tied to that icon.
When configuring a network connection as described in Procedure 27.1, “Adding or Editing Connec-
tions”, KNetworkManager also allows you to customize the icon displayed for this connection.
To change the icon, click the icon button next to Connection Name and in the following dialog,
select the icon of your choice. After confirming your changes, the new icon is displayed in the
list of available connections you get by clicking the KNetworkManager icon in the system tray.
359 Using the GNOME NetworkManager Applet SUSE Linux Enterp… 11 SP4
1. Left-click the applet icon to show a menu with available networks. The currently used
connection is selected in the menu.
3. To switch o all network connections, both wired and wireless, right-click the applet icon
and uncheck Enable Networking.
1. To connect to a wireless network, left-click the applet icon and choose an entry from the
list of available wireless networks.
2. If the network is encrypted, a dialog opens. It shows the type of encryption the network
uses (Wireless Security) and holds a number of input elds according to the respective
encryption and authentication settings. Enter the appropriate credentials.
3. To connect to a network that does not broadcast its service set identifier (SSID or ESSID)
and therefore cannot be detected automatically, left-click the NetworkManager icon and
choose Connect to Hidden Wireless Network.
4. In the dialog that opens, enter the SSID or ESSID in Network Name and set encryption
parameters if necessary.
5. To disable wireless networking, right-click the applet icon and uncheck Enable Wireless.
This can be useful if you are on a plane or in any other environment where wireless
networking is not allowed.
A wireless network that has been chosen explicitly will remain connected as long as possible.
If a network cable is plugged in during that time, any connections that have been set to Stay
connected when possible will be connected, while the wireless connection remains up.
1. Click the NetworkManager applet and select Create New Wireless Network.
2. Enter a Network Name and set the encryption to use with the Wireless Security drop-down
list.
361 Configuring Your Wireless Card as an Access Point SUSE Linux Enterp… 11 SP4
27.6 NetworkManager and VPN
NetworkManager supports several Virtual Private Network (VPN) technologies. For each tech-
nology, SUSE Linux Enterprise Server comes with a base package providing the generic support
for NetworkManager. In addition to that, you also need to install the respective desktop-specific
package for your applet.
NovellVPN
To use this VPN technology, install
NetworkManager-novellvpn and
NetworkManager-novellvpn-kde4 or NetworkManager-novellvpn-gnome .
NovellVPN support for KDE is not available yet, but is currently being worked on.
OpenVPN
To use this VPN technology, install
NetworkManager-openvpn and
NetworkManager-openvpn-kde4 or NetworkManager-openvpn-gnome .
vpnc (Cisco)
To use this VPN technology, install
NetworkManager-vpnc and
NetworkManager-vpnc-kde4 or NetworkManager-vpnc-gnome .
NetworkManager-pptp and
NetworkManager-pptp-kde4 or NetworkManager-pptp-gnome .
After you have installed the packages, configure your VPN connection as described in Section 27.3,
“Configuring Network Connections”.
How to specify a certain access point in case multiple access points with the same ESSID are
detected?
When multiple access points with different wireless bands (a/b/g/n) are available, the
access point with the strongest signal is automatically chosen by default. To override this,
use the BSSID eld when configuring wireless connections.
The Basic Service Set Identifier (BSSID) uniquely identifies each Basic Service Set. In an
infrastructure Basic Service Set, the BSSID is the MAC address of the wireless access point.
In an independent (ad-hoc) Basic Service Set, the BSSID is a locally administered MAC
address generated from a 46-bit random number.
Start the dialog for configuring network connections as described in Section 27.3, “Configur-
ing Network Connections”. Choose the wireless connection you want to modify and click Edit.
On the Wireless tab, enter the BSSID.
1. Start the dialog for configuring network connections as described in Section 27.3, “Con-
figuring Network Connections”. Choose the connection you want to modify and click
Edit. If you are using GNOME, switch to the IPv4 Settings tab and from the Method
drop-down list, choose Shared to other computers. If you are using KDE, switch to the
IP Address tab and from the Configure drop-down list, choose Shared. That will enable
IP traffic forwarding and run a DHCP server on the device. Confirm your changes
in NetworkManager.
2. As the DCHP server uses port 67 , make sure that it is not blocked by the firewall: On
the machine sharing the connections, start YaST and select Security and Users Fire-
wall. Switch to the Allowed Services category. If DCHP Server is not already shown
as Allowed Service, select DCHP Server from Services to Allow and click Add. Confirm
your changes in YaST.
How to provide static DNS information with automatic (DHCP, PPP, VPN) addresses?
In case a DHCP server provides invalid DNS information (and/or routes), you can override
it. Start the dialog for configuring network connections as described in Section 27.3, “Con-
figuring Network Connections”. Choose the connection you want to modify and click Edit. If
you are using GNOME, switch to the IPv4 Settings tab, and from the Method drop-down
list, choose Automatic (DHCP) addresses only. If you are using KDE, switch to the IP Address
tab, and from the Configure drop-down list, choose Automatic (DHCP) addresses only. Enter
the DNS information in the DNS Servers and Search Domains elds. To Ignore automatically
obtained routes click Routes (GNOME) and activate the respective check box, or from the
drop-down list at the bottom of the tab (KDE), select Routes and activate the respective
check box. Confirm your changes.
How to make NetworkManager connect to password protected networks before a user logs in?
Define a system connection that can be used for such purposes. For more information,
refer to Section 27.7, “NetworkManager and Security”.
Package Documentation
Also check out the information in the following directories for the latest information about
NetworkManager and the GNOME and KDE NetworkManager applets:
/usr/share/doc/packages/NetworkManager/ ,
/usr/share/doc/packages/NetworkManager-kde4/ , and
/usr/share/doc/packages/NetworkManager-gnome/ .
Using Samba, a Unix machine can be configured as a le and print server for Mac
OS X, Windows, and OS/2 machines. Samba has developed into a fully-edged and
rather complex product. Configure Samba with YaST, SWAT (a Web interface), or
by editing the configuration le manually.
28.1 Terminology
The following are some terms used in Samba documentation and in the YaST module.
SMB protocol
Samba uses the SMB (server message block) protocol that is based on the NetBIOS services.
Microsoft released the protocol so other software manufacturers could establish connec-
tions to a Microsoft domain network. With Samba, the SMB protocol works on top of the
TCP/IP protocol, so the TCP/IP protocol must be installed on all clients.
CIFS protocol
CIFS (common Internet le system) protocol is another protocol supported by Samba. CIFS
defines a standard remote le system access protocol for use over the network, enabling
groups of users to work together and share documents across the network.
NetBIOS
NetBIOS is a software interface (API) designed for communication between machines pro-
viding a name service. It enables machines connected to the network to reserve names for
themselves. After reservation, these machines can be addressed by name. There is no cen-
tral process that checks names. Any machine on the network can reserve as many names
as it wants as long as the names are not already in use. The NetBIOS interface can be
implemented for different network architectures. An implementation that works relatively
Samba server
Samba server provides SMB/CIFS services and NetBIOS over IP naming services to clients.
For Linux, there are three daemons for Samba server: smbd for SMB/CIFS services, nmbd
for naming services, and winbind for authentication.
Samba client
The Samba client is a system that uses Samba services from a Samba server over the SMB
protocol. All common operating systems, such as Mac OS X, Windows, and OS/2, support
the SMB protocol. The TCP/IP protocol must be installed on all computers. Samba provides
a client for the different UNIX flavors. For Linux, there is a kernel module for SMB that
allows the integration of SMB resources on the Linux system level. You do not need to run
any daemon for the Samba client.
Shares
SMB servers provide resources to the clients by means of shares. Shares are printers and
directories with their subdirectories on the server. It is exported by means of a name and
can be accessed by its name. The share name can be set to any name—it does not have to
be the name of the export directory. A printer is also assigned a name. Clients can access
the printer by its name.
DC
A domain controller (DC) is a server that handles accounts in domain. For data replication,
additional domain controllers are available in one domain.
When starting the module for the rst time, the Samba Installation dialog starts, prompting you
to make just a few basic decisions concerning administration of the server. At the end of the
configuration it prompts for the Samba administrator password (Samba Root Password). For later
starts, the Samba Configuration dialog appears.
The Samba Installation dialog consists of two steps and optional detailed settings:
If you do not want to proceed with a detailed server configuration, confirm with OK. Then in
the final pop-up box, set the Samba root Password.
You can change all settings later in the Samba Configuration dialog with the Start-Up, Shares,
Identity, Trusted Domains, and LDAP Settings tabs.
During the rst start of the Samba server module the Samba Configuration dialog appears directly
after the two initial steps described in Section 28.3.1.1, “Initial Samba Configuration”. Use it to adjust
your Samba server configuration.
After editing your configuration, click OK to save your settings.
In the Start Up tab, configure the start of the Samba server. To start the service every time your
system boots, select During Boot. To activate manual start, choose Manually. More information
about starting a Samba server is provided in Section 28.2, “Starting and Stopping Samba”.
In this tab, you can also open ports in your firewall. To do so, select Open Port in Firewall. If you
have multiple network interfaces, select the network interface for Samba services by clicking
Firewall Details, selecting the interfaces, and clicking OK.
28.3.1.2.2 Shares
In the Shares tab, determine the Samba shares to activate. There are some predefined shares,
like homes and printers. Use Toggle Status to switch between Active and Inactive. Click Add to
add new shares and Delete to delete the selected share.
Allow Users to Share Their Directories enables members of the group in Permitted Group to share
directories they own with other users. For example, users for a local scope or DOMAIN\Users
for a domain scope. The user also must make sure that the le system permissions allow access.
With Maximum Number of Shares, limit the total amount of shares that may be created. To permit
access to user shares without authentication, enable Allow Guest Access.
28.3.1.2.3 Identity
In the Identity tab, you can determine the domain with which the host is associated (Base Set-
tings) and whether to use an alternative hostname in the network (NetBIOS Hostname). It is also
possible to use Microsoft Windows Internet Name Service (WINS) for name resolution. In this
case, activate Use WINS for Hostname Resolution and decide whether to Retrieve WINS server via
DHCP. To set expert global settings or set a user authentication source, for example LDAP in-
stead of TDB database, click Advanced Settings.
371 Configuring a Samba Server with YaST SUSE Linux Enterp… 11 SP4
28.3.1.2.4 Trusted Domains
To enable users from other domains to access your domain, make the appropriate settings in
the Trusted Domains tab. To add a new domain, click Add. To remove the selected domain, click
Delete.
In the tab LDAP Settings, you can determine the LDAP server to use for authentication. To test
the connection to your LDAP server, click Test Connection. To set expert LDAP settings or use
default values, click Advanced Settings.
For more information about LDAP configuration, see Book “Security Guide”, Chapter 4 “LDAP—A
Directory Service”.
The following parameters of the [global] section need some adjustment to match the require-
ments of your network setup so other machines can access your Samba server via SMB in a
Windows environment.
workgroup = TUX-NET
This line assigns the Samba server to a workgroup. Replace TUX-NET with an appropriate
workgroup of your networking environment. Your Samba server appears under its DNS
name unless this name has been assigned to some other machine in the network. If the
DNS name is not available, set the server name using netbiosname=MYNAME . For more
details about this parameter, see the smb.conf man page.
os level = 20
This parameter triggers whether your Samba server tries to become LMB (local master
browser) for its workgroup. With the Samba 3 release series, it is seldom necessary to
override the default setting ( 20 ). Choose a very low value such as 2 to spare the existing
Windows network from any disturbances caused by a misconfigured Samba server. More
information about this important topic can be found in the Network Browsing chapter of
the Samba 3 Howto; for more information on the Samba 3 Howto, see Section 28.7, “For
More Information”.
If no other SMB server is present in your network (such as a Windows 2000 server) and
you want the Samba server to keep a list of all systems present in the local environment,
set the os level to a higher value (for example, 65 ). Your Samba server is then chosen
as LMB for your local network.
When changing this setting, consider carefully how this could affect an existing Windows
network environment. First test the changes in an isolated network or at a noncritical time
of day.
The following examples illustrate how a CD-ROM drive and the user directories ( homes ) are
made available to the SMB clients.
[cdrom]
To avoid having the CD-ROM drive accidentally made available, these lines are deactivated
with comment marks (semicolons in this case). Remove the semicolons in the rst column
to share the CD-ROM drive with Samba.
;[cdrom]
; comment = Linux CD-ROM
; path = /media/cdrom
; locking = No
path = /media/cdrom
path exports the directory /media/cdrom .
By means of a very restrictive default configuration, this kind of share is only made avail-
able to the users present on this system. If this share should be made available to every-
body, add a line guest ok = yes to the configuration. This setting gives read permissions
to anyone on the network. It is recommended to handle this parameter with great care.
This applies even more to the use of this parameter in the [global] section.
[homes]
The [homes] share is of special importance here. If the user has a valid account and
password for the Linux le server and his own home directory, he can be connected to it.
EXAMPLE 28.2: [HOMES] SHARE
[homes]
comment = Home Directories
valid users = %S
browseable = No
read > create mask = 0640
directory mask = 0750
valid users = %S
%S is replaced with the concrete name of the share as soon as a connection has
been successfully established. For a [homes] share, this is always the username. As
a consequence, access rights to a user's share are restricted exclusively to that user.
browseable = No
This setting makes the share invisible in the network environment.
read > By default, Samba prohibits write access to any exported share by means of the read
parameter. To make a share writable, set the value read ,
which is synonymous with writable = Yes .
To improve security, each share access can be protected with a password. SMB offers the fol-
lowing ways of checking permissions:
The selection of share, user, server, or domain level security applies to the entire server. It is not
possible to offer individual shares of a server configuration with share level security and others
with user level security. However, you can run a separate Samba server for each configured IP
address on a system.
More information about this subject can be found in the Samba 3 HOWTO. For multiple servers
on one system, pay attention to the options interfaces and bind interfaces only .
Configure a Samba client to access resources (les or printers) on the Samba or Windows server.
Enter the NT or Active Directory domain or workgroup in the dialog Network Services Windows
Domain Membership. If you activate Also Use SMB Information for Linux Authentication, the user
authentication runs over the Samba, NT or Kerberos server.
Click Expert Settings for advanced configuration options. For example, use the Mount Server Di-
rectories table to enable mounting server home directory automatically with authentication. This
way users will be able to access their home directories when hosted on CIFS. For details, see
the the pam_mount man page.
After completing all settings, confirm the dialog to finish the configuration.
[global]
workgroup = TUX-NET
domain logons = Yes
domain master = Yes
If encrypted passwords are used for verification purposes the Samba server must be able to
handle these. The entry encrypt passwords = yes in the [global] section enables this (with
Samba version 3, this is now the default). In addition, it is necessary to prepare user accounts
and passwords in an encryption format that conforms with Windows. Do this with the command
smbpasswd -a name . Create the domain account for the computers, required by the Windows
domain concept, with the following commands:
useradd hostname\$
377 Configuring a Samba Client with YaST SUSE Linux Enterp… 11 SP4
smbpasswd -a -m hostname
With the useradd command, a dollar sign is added. The command smbpasswd inserts this
automatically when the parameter -m is used. The commented configuration example ( /usr/
share/doc/packages/samba/examples/smb.conf.SUSE ) contains settings that automate this
task.
To make sure that Samba can execute this script correctly, choose a Samba user with the required
administrator permissions and add it to the ntadmin group. Then all users belonging to this
Linux group can be assigned Domain Admin status with the command:
For more information about this topic, see Chapter 12 of the Samba 3 HOWTO, found in /usr/
share/doc/packages/samba/Samba3-HOWTO.pdf .
3. Enter the domain to join at Domain or Workgroup in the Windows Domain Membership
screen.
378 Samba Server in the Network with Active Directory SUSE Linux Enterp… 11 SP4
FIGURE 28.1: DETERMINING WINDOWS DOMAIN MEMBERSHIP
4. Check Also Use SMB Information for Linux Authentication to use the SMB source for Linux
authentication on your SUSE Linux Enterprise Server.
5. Click OK and confirm the domain join when prompted for it.
6. Provide the password for the Windows Administrator on the AD server and click OK.
Your server is now set up to pull in all authentication data from the Active Directory
domain controller.
Tip
In an environment with more than one Samba server, UIDs and GIDs will not be created
consistently. The UIDs that get assigned to users will be dependent on the order in which
they rst log in, which results in UID conflicts across servers. To x this, you need to
make use of idnetity mapping. See https://www.samba.org/samba/docs/man/Samba-HOW-
TO-Collection/idmapper.html for more details
379 Samba Server in the Network with Active Directory SUSE Linux Enterp… 11 SP4
28.7 For More Information
Detailed Samba information is available in the digital documentation. Enter apropos samba
at the command line to display some manual pages or just browse the /usr/share/doc/pack-
ages/samba directory if Samba documentation is installed for more online documentation and
examples. Find a commented example configuration ( smb.conf.SUSE ) in the examples sub-
directory.
The Samba 3 HOWTO provided by the Samba team includes a section about troubleshooting.
In addition to that, Part V of the document provides a step-by-step guide to checking your con-
figuration. You can nd Samba 3 HOWTO in /usr/share/doc/packages/samba/Samba3-HOW-
TO.pdf after installing the package samba-doc .
Distributing and sharing le systems over a network is a common task in corpo-
rate environments. The well-proven network le system (NFS) works together with
NIS, the yellow pages protocol. For a more secure protocol that works together with
LDAP and may also use Kerberos, check NFSv4. Combined with pNFS, you can elim-
inate performance bottlenecks.
NFS with NIS makes a network transparent to the user. With NFS, it is possible to
distribute arbitrary le systems over the network. With an appropriate setup, users
always nd themselves in the same environment regardless of the terminal they
currently use.
29.1 Terminology
The following are terms used in the YaST module.
Exports
A directory exported by an NFS server, which clients can integrate it into their system.
NFS Client
The NFS client is a system that uses NFS services from an NFS server over the Network File
System protocol. The TCP/IP protocol is already integrated into the Linux kernel; there is
no need to install any additional software.
NFS Server
The NFS server provides NFS services to clients. A running server depends on the following
daemons: nfsd (worker), idmapd (user and group name mappings to IDs and vice versa),
statd (le locking), and mountd (mount requests).
With YaST, turn a host in your network into an NFS server—a server that exports directories
and les to all hosts granted access to it. The server can also provide applications to all members
of a group without installing the applications locally on each and every host.
To set up such a server, proceed as follows:
1. Start YaST and select Network Services NFS Server; see Figure 29.1, “NFS Server Configuration
Tool”. You may be prompted to install additional software.
3. If a firewall is active on your system (SuSEfirewall2), check Open Ports in Firewall. YaST
adapts its configuration for the NFS server by enabling the nfs service.
5. Click Enable GSS Security if you need secure access to the server. A prerequisite for this
is to have Kerberos installed on your domain and to have both the server and the clients
kerberized. Click Next.
6. Click Add Directory in the upper half of the dialog to export your directory.
7. If you have not configured the allowed hosts already, another dialog for entering the client
information and options pops up automatically. Enter the host wild card (usually you can
leave the default settings as they are).
There are four possible types of host wild cards that can be set for each host: a single host
(name or IP address), netgroups, wild cards (such as * indicating all machines can access
the server), and IP networks.
383 Exporting File Systems with YaST SUSE Linux Enterp… 11 SP4
29.3.1.1 Exporting for NFSv4 Clients
For a xed set of NFSv4 clients, there are two types of directories that can be exported—direc-
tories that act as pseudo root le systems and those that are bound to some subdirectory of the
pseudo le system. This pseudo le system acts as a base point under which all le systems
exported for the same client set take their place. For a client or set of clients, only one directory
on the server can be configured as pseudo root for export. For this client, export multiple direc-
tories by binding them to some existing subdirectory in the pseudo root.
For example, suppose that the directory /exports is chosen as the pseudo root directory for all
the clients that can access the server. Then add this into the list of exported directories and make
sure that the options entered for this directory include fsid=0 . If there is another directory, /
data , that also needs to be NFSv4 exported, add this directory also to the list. While entering
options for this, make sure that bind=/exports/data is in the list and that /exports/data is
an already existing subdirectory of /exports . Any change in the option bind=/target/path ,
whether addition, deletion, or change in value, is reflected in Bindmount Targets.
In order to set up the server to export directories for NFSv4 clients, use the the general guideline
in Procedure 29.1, “Setting Up an NFSv3 Server”, but change the following steps:
3. Click Add Directory in the upper half of the dialog to export your directory and confirm
with Ok.
4. Enter your hostnames in the Host Wild Card texteld and options.
In Options texteld, include fsid=0 in the comma-separated list of options to configure
the directory as pseudo root. If this directory needs to be bound to another directory under
an already configured pseudo root, make sure that a target bind path is given in the option
list with bind=/target/path .
384 Exporting File Systems with YaST SUSE Linux Enterp… 11 SP4
The Bindmount Targets column is not a directly editable column, but instead summarizes
directories and their nature.
Make sure that Enable NFSv4 is not checked in the initial dialog before clicking Next.
The next dialog has two parts. In the upper text eld, enter the directories to export. Below,
enter the hosts that should have access to them. There are four types of host wild cards that
can be set for each host: a single host (name or IP address), netgroups, wild cards (such as *
indicating all machines can access the server), and IP networks.
This dialog is shown in Figure 29.2, “Exporting Directories with NFSv2 and v3”. Find a more thorough
explanation of these options in man exports . Click Finish to complete the configuration.
385 Exporting File Systems with YaST SUSE Linux Enterp… 11 SP4
29.3.1.3 Coexisting v3 and v4 Exports
NFSv3 and NFSv4 exports can coexist on a server. After enabling the support for NFSv4 in the
initial configuration dialog, those exports for which fsid=0 and bind=/target/path are not
included in the option list are considered v3 exports.
Consider the example in Section 29.3.1.1, “Exporting for NFSv4 Clients”. If you add another directory,
such as /data2 , using Add Directory then in the corresponding options list do not mention either
fsid=0 or bind=/target/path , this export acts as a v3 export.
Important
Automatic Firewall Configuration
If SuSEfirewall2 is active on your system, YaST adapts its configuration for the NFS server
by enabling the nfs service when Open Ports in Firewall is selected.
The configuration les for the NFS export service are /etc/exports and /etc/syscon-
fig/nfs . In addition to these les, /etc/idmapd.conf is needed for the NFSv4 server configu-
ration. To start or restart the services, run the command rcnfsserver restart . This also starts
the rpc.idmapd if NFSv4 is configured in /etc/sysconfig/nfs . The NFS server depends on
a running RPC portmapper. Therefore, also start or restart the portmapper service with rcr-
pcbind restart .
NFSv4 is the latest version of NFS protocol available on SUSE Linux Enterprise Server. Config-
uring directories for export with NFSv4 differs slightly from previous NFS versions.
29.3.2.1.1 /etc/exports
The /etc/exports le contains a list of entries. Each entry indicates a directory that is shared
and how it is shared. A typical entry in /etc/exports consists of:
/shared/directory host(option_list)
/export 192.168.1.2(rw,fsid=0,sync,crossmnt)
/export/data 192.168.1.2(rw,bind=/data,sync)
Here the IP address 192.168.1.2 is used to identify the allowed client. You can also use the
name of the host, a wild card indicating a set of hosts ( *.abc.com , * , etc.), or netgroups ( @my-
hosts ).
The directory which specifies fsid=0 is special. It is the root of the le system that is exported,
sometimes referred to as the pseudo root le system. This directory must also have the crossmnt
for correct operation with NFSv4. All other directories exported via NFSv4 must be mounted
below this point. If you want to export a directory that is not within the exported root, it needs
to be bound into the exported tree. This can be done using the bind= syntax.
In the example above, /data is not within /export , so we export /export/data , and specify
that the /data directory should be bound to that name. The directory /export/data must
exist and should normally be empty.
When clients mount from this server, they just mount servername:/ rather than server-
name:/export . It is not necessary to mount servername:/data , because it will automatically
appear beneath wherever servername:/ was mounted.
29.3.2.1.2 /etc/sysconfig/nfs
The /etc/sysconfig/nfs le contains a few parameters that determine NFSv4 server daemon
behavior. It is important to set the parameter NFS4_SUPPORT to yes . NFS4_SUPPORT deter-
mines whether the NFS server supports NFSv4 exports and clients.
29.3.2.1.3 /etc/idmapd.conf
Every user on a Linux machine has a name and ID. idmapd does the name-to-ID mapping for
NFSv4 requests to the server and replies to the client. It must be running on both server and
client for NFSv4, because NFSv4 uses only names for its communication.
Make sure that there is a uniform way in which usernames and IDs (uid) are assigned to users
across machines that might probably be sharing le systems using NFS. This can be achieved by
using NIS, LDAP, or any uniform domain authentication mechanism in your domain.
[General]
Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = localdomain
[Mapping]
Nobody-User = nobody
Nobody-Group = nobody
For further reference, read the man page of idmapd and idmapd.conf ; man idmapd , man
idmapd.conf .
After changing /etc/exports or /etc/sysconfig/nfs , start or restart the NFS server service
with rcnfsserver restart . After changing /etc/idmapd.conf , reload the configuration le
with the command killall -HUP rpc.idmapd .
If the NFS service needs to start at boot time, run the command chkconfig nfsserver on .
Exporting le systems with NFS involves two configuration les: /etc/exports and /etc/
sysconfig/nfs . A typical /etc/exports le entry is in the format:
/shared/directory host(list_of_options)
For example:
/export 192.168.1.2(rw,sync)
Here, the directory /export is shared with the host 192.168.1.2 with the option list rw,sync .
This IP address can be replaced with a client name or set of clients using a wild card (such as
*.abc.com ) or even netgroups.
1. Make sure that both the server and the client are in the same Kerberos domain. They must
access the same KDC (Key Distribution Center) server and share their krb5.keytab le
(the default location on any machine is /etc/krb5.keytab ). For more information about
Kerberos, see Book “Security Guide”, Chapter 6 “Network Authentication with Kerberos”.
For more information about configuring kerberized NFS, refer to the links in Section 29.5, “For
More Information”.
3. Enable Open Port in Firewall in the NFS Settings tab if you use a Firewall and want to allow
access to the service from remote computers. The firewall status is displayed next to the
check box.
4. When using NFSv4, make sure that the check box Enable NFSv4 is selected and that the
NFSv4 Domain Name contains the same value as used by the NFSv4 server. The default
domain is localdomain .
The configuration is written to /etc/fstab and the specified le systems are mounted. When
you start the YaST configuration client at a later time, it also reads the existing configuration
from this le.
mount host:remote-pathlocal-path
To import user directories from the nfs.example.com machine, for example, use:
/nfsmounts /etc/auto.nfs
Now the /nfsmounts directory acts as the root for all the NFS mounts on the client if the au-
to.nfs le is lled appropriately. The name auto.nfs is chosen for the sake of convenience—
you can choose any name. In auto.nfs add entries for all the NFS mounts as follows:
Activate the settings with rcautofs start as root . In this example, /nfsmounts/localda-
ta , the /data directory of server1 , is mounted with NFS and /nfsmounts/nfs4mount from
server2 is mounted with NFSv4.
If the /etc/auto.master le is edited while the service autofs is running, the automounter
must be restarted for the changes to take effect with rcautofs restart .
NFSv4 mounts may also be added to the /etc/fstab le. For these mounts, use nfs4 instead
of nfs in the third column and make sure that the remote le system is given as / after the
nfs.example.com: in the rst column. A sample line for an NFSv4 mount in /etc/fstab
looks like this:
The noauto option prevents the le system from being mounted automatically at start up. If you
want to mount the respective le system manually, it is possible to shorten the mount command
specifying the mount point only:
mount /local/path
Note, that if you do not enter the noauto option, the initialization scripts of the system will
handle the mount of those le systems at start up.
With small les most of the time is spent collecting the metadata
With big les most of the time is spent on transfering the data from server to client
pNFS, or parallel NFS, overcomes this limitation as it separates the le system metadata from
the location of the data. As such, pNFS requires two types of servers:
The metadata and the storage servers form a single, logical NFS server. When a client wants to
read or write, the metadata server tells the NFSv4 client which storage server to use to access
the le chunks. The client can access the data directly on the server.
SUSE Linux Enterprise supports pNFS on the client side only.
Proceed as described in Procedure 29.2, “Importing NFS Directories”, but click the pNFS (v4.1) check
box and optionally NFSv4 share. YaST will do all the necessary steps and will write all the
required options in the le /etc/exports .
Refer to Section 29.4.2, “Importing File Systems Manually” to start. Most of the configuration is done
by the NFSv4 server. For pNFS, the only difference is to add the minorversion option and the
metadata server MDS_SERVER to your mount command:
To help with debugging, change the value in the /proc le system:
For instructions for setting up kerberized NFS, refer to NFS Version 4 Open Source Reference
Implementation (http://www.citi.umich.edu/projects/nfsv4/linux/krb5-setup.html) .
If you have questions on NFSv4, refer to the Linux NFSv4 FAQ (http://www.citi.umich.e-
du/projects/nfsv4/linux/faq/) .
These days, many people use several computers—one computer at home, one or
several computers at the workplace, and possibly a laptop, tablet, or a smartphone
on the road. Many les are needed on all these computers. You may want to be able
to work with all computers and modify the les so that you have the latest version
of the data available on all computers.
The time-consuming and error-prone task of manually synchronizing data can be avoided by
using one of the programs that use various methods to automate this job. The following sum-
maries are merely intended to convey a general understanding of how these programs work and
how they can be used. If you plan to use them, read the program documentation.
CVS, which is mostly used for managing program source versions, offers the possibility of keep-
ing copies of the les on multiple computers. Accordingly, it is also suitable for data synchro-
nization. CVS maintains a central repository on the server in which the les and changes to
les are saved. Changes that are performed locally are committed to the repository and can be
retrieved from other computers by means of an update. Both procedures must be initiated by
the user.
CVS is very resilient to errors when changes occur on several computers. The changes are merged
and (if changes took place in the same lines) a conflict is reported. When a conflict occurs, the
database remains in a consistent state. The conflict is only visible for resolution on the client
host.
30.1.2 rsync
When no version control is needed but large directory structures need to be synchronized over
slow network connections, the tool rsync offers well-developed mechanisms for transmitting
only changes within les. This not only applies to text les, but also binary les. To detect the
differences between les, rsync subdivides the les into blocks and computes checksums over
them.
The effort put into the detection of the changes comes at a price. The systems to synchronize
should be scaled generously for the usage of rsync. RAM is especially important.
30.2.6 History
An additional feature of CVS is that old le versions can be reconstructed. A brief editing remark
can be inserted for each change and the development of the les can easily be traced later based
on the content and the remarks. This is a valuable aid for theses and program texts.
30.2.8 GUI
Experienced users normally run CVS from the command line. However, graphical user interfaces
are available for Linux (such as cervisia) and other operating systems (like wincvs). Many de-
velopment tools (such as kdevelop) and text editors (such as Emacs) provide support for CVS.
The resolution of conflicts is often much easier to perform with these front-ends.
397 Data Volume and Hard Disk Requirements SUSE Linux Enterp… 11 SP4
TABLE 30.1: FEATURES OF THE FILE SYNCHRONIZATION TOOLS: -- = VERY POOR, - = POOR OR NOT AVAILABLE, O =
MEDIUM, + = GOOD, ++ = EXCELLENT, X = AVAILABLE
CVS rsync
Interactivity x x
Speed o +
Conflicts ++ o
History x -
GUI o -
Difficulty o +
Data Loss ++ +
CVS_RSH=ssh CVSROOT=tux@server:/serverdir
The command cvs init can be used to initialize the CVS server from the client side. This
needs to be done only once.
Finally, the synchronization must be assigned a name. Select or create a directory on the client to
contain les to manage with CVS (the directory can also be empty). The name of the directory is
also the name of the synchronization. In this example, the directory is called synchome . Change
to this directory and enter the following command to set the synchronization name to synchome :
Many CVS commands require a comment. For this purpose, CVS starts an editor (the editor
defined in the environment variable $EDITOR or vi if no editor was defined). The editor call
can be circumvented by entering the comment in advance on the command line, such as in the
following example:
U
The local version was updated. This affects all les that are provided by the server and
missing on the local system.
M
The local version was modified. If there were changes on the server, it was possible to
merge the differences in the local copy.
P
The local version was patched with the version on the server.
C
The local le conflicts with current version in the repository.
?
This le does not exist in CVS.
The status M indicates a locally modified le. Either commit the local copy to the server or
remove the local le and run the update again. In this case, the missing le is retrieved from
the server. If you commit a locally modified le and the le was changed in the same line and
committed, you might get a conflict, indicated with C .
Up to this point, the handling does not differ much from that of a regular copying tool, like scp.
rsync should be operated in “rsync” mode to make all its features fully available. This is done by
starting the rsyncd daemon on one of the systems. Configure it in the le /etc/rsyncd.conf .
For example, to make the directory /srv/ftp available with rsync, use the following config-
uration:
gid = nobody
uid = nobody
read >use chroot = no
transfer logging = true
[FTP]
path = /srv/ftp
comment = An Example
Then start rsyncd with rcrsyncd start . rsyncd can also be started automatically during the
boot process. Set this up by activating this service in the runlevel editor provided by YaST or
by manually entering the command insserv rsyncd . rsyncd can alternatively be started by
xinetd. This is, however, only recommended for servers that rarely use rsyncd.
The example also creates a log le listing all connections. This le is stored in /var/log/
rsyncd.log .
It is then possible to test the transfer from a client system. Do this with the following command:
This command lists all les present in the directory /srv/ftp of the server. This request is
also logged in the log le /var/log/rsyncd.log . To start an actual transfer, provide a target
directory. Use . for the current directory. For example:
By default, no les are deleted while synchronizing with rsync. If this should be forced, the
additional option --delete must be stated. To ensure that no newer les are deleted, the option
--update can be used instead. Any conflicts that arise must be resolved manually.
rsync
Important information about rsync is provided in the man pages man rsync and
man rsyncd.conf . A technical reference about the operating principles of rsync is fea-
tured in /usr/share/doc/packages/rsync/tech_report.ps . Find the latest news about
rsync on the project Web site at http://rsync.samba.org/ .
With a share of more than 50%, the Apache HTTP Server (Apache) is the world's
most widely-used Web server according to the Survey from http://www.net-
craft.com/ . Apache, developed by the Apache Software Foundation (http://www.a-
pache.org/ ), is available for most operating systems. SUSE® Linux Enterprise
Server includes Apache version 2.2. In this chapter, learn how to install, configure
and set up a Web server; how to use SSL, CGI, and additional modules; and how to
troubleshoot Apache.
31.1.1 Requirements
Make sure the following requirements are met before trying to set up the Apache Web server:
1. The machine's network is configured properly. For more information about this topic, refer
to Chapter 22, Basic Networking.
2. The machine's exact system time is maintained by synchronizing with a time server. This is
necessary because parts of the HTTP protocol depend on the correct time. See Chapter 24,
Time Synchronization with NTP to learn more about this topic.
3. The latest security updates are installed. If in doubt, run a YaST Online Update.
4. The default Web server port ( 80 ) is opened in the firewall. For this, configure the SuSE-
Firewall2 to allow the service HTTP Server in the external zone. This can be done using
YaST. See Book “Security Guide”, Chapter 15 “Masquerading and Firewalls”, Section 15.4 “SuSE-
firewall2”, Section 15.4.1 “Configuring the Firewall with YaST” for details.
Apache on SUSE Linux Enterprise Server is not installed by default. To install it with a standard,
predefined configuration that runs “out of the box”, proceed as follows:
2. Choose Filter Patterns and select Web and LAMP Server int Server Functions.
3. Confirm the installation of the dependent packages to finish the installation process.
The installation includes the multiprocessing module apache2-prefork as well as the PHP5
module. Refer to Section 31.4, “Installing, Activating, and Configuring Modules” for more information
about modules.
31.1.3 Start
You can start Apache automatically at boot time or start it manually.
1. To make sure that Apache is automatically started during boot in runlevels 3 and 5 ,
execute the following command:
chkconfig -a apache2
For more information about the runlevels in SUSE Linux Enterprise Server and a description of
the YaST runlevel editor, refer to Section 10.2.3, “Configuring System Services (Runlevel) with YaST”.
To manually start Apache using the shell, run rcapache2 start .
If you do not receive error messages when starting Apache, this usually indicates that the
Web server is running. To test this:
Now that the Web server is running, you can add your own documents, adjust the configuration
according to your needs, or add functionality by installing modules.
Manual configuration offers a higher level of detail, but lacks the convenience of the YaST GUI.
This section gives an overview of the Apache configuration les. If you use YaST for configura-
tion, you do not need to touch these les—however, the information might be useful for you if
you want to switch to manual configuration later on.
/etc/sysconfig/apache2
/etc/apache2/
31.2.1.1 /etc/sysconfig/apache2
/etc/sysconfig/apache2 controls some global settings of Apache, like modules to load, ad-
ditional configuration les to include, ags with which the server should be started, and ags
that should be added to the command line. Every configuration option in this le is extensively
documented and therefore not mentioned here. For a general-purpose Web server, the settings
in /etc/sysconfig/apache2 should be sufficient for any configuration needs.
31.2.1.2 /etc/apache2/
/etc/apache2/ hosts all configuration les for Apache. In the following, the purpose of each
le is explained. Each le includes several configuration options (also referred to as directives).
Every configuration option in these les is extensively documented and therefore not mentioned
here.
The Apache configuration les are organized as follows:
/etc/apache2/
|
|- charset.conv
|- conf.d/
| |
| |- *.conf
|
|- default-server.conf
|- errors.conf
|- httpd.conf
|- listen.conf
|- magic
|- mime.types
|- mod_*.conf
|- server-tuning.conf
|- ssl.*
|- ssl-global.conf
|- sysconfig.d
charset.conv
Specifies which character sets to use for different languages. Do not edit this le.
conf.d/*.conf
Configuration les added by other modules. These configuration les can be included into
your virtual host configuration where needed. See vhosts.d/vhost.template for exam-
ples. By doing so, you can provide different module sets for different virtual hosts.
default-server.conf
Global configuration for all virtual hosts with reasonable defaults. Instead of changing the
values, overwrite them with a virtual host configuration.
errors.conf
Defines how Apache responds to errors. To customize these messages for all virtual hosts,
edit this le. Otherwise overwrite these directives in your virtual host configurations.
httpd.conf
The main Apache server configuration le. Avoid changing this le. It primarily contains
include statements and global settings. Overwrite global settings in the pertinent configu-
ration les listed here. Change host-specific settings (such as document root) in your vir-
tual host configuration.
listen.conf
Binds Apache to specific IP addresses and ports. Name-based virtual hosting is also con-
figured here. For details, see Section 31.2.2.1.1, “Name-Based Virtual Hosts”.
magic
Data for the mime_magic module that helps Apache automatically determine the MIME
type of an unknown le. Do not change this le.
mime.types
mod_*.conf
Configuration les for the modules that are installed by default. Refer to Section 31.4, “In-
stalling, Activating, and Configuring Modules” for details. Note that configuration les for op-
tional modules reside in the directory conf.d .
server-tuning.conf
Contains configuration directives for the different MPMs (see Section 31.4.4, “Multiprocess-
ing Modules”) as well as general configuration options that control Apache's performance.
Properly test your Web server when making changes here.
sysconfig.d/*.conf
Configuration les automatically generated from /etc/sysconfig/apache2 . Do not
change any of these les—edit /etc/sysconfig/apache2 instead. Do not put other con-
figuration les in this directory.
uid.conf
Specifies under which user and group ID Apache runs. Do not change this le.
vhosts.d/*.conf
Your virtual host configuration should be located here. The directory contains template
les for virtual hosts with and without SSL. Every le in this directory ending with .conf
is automatically included in the Apache configuration. Refer to Section 31.2.2.1, “Virtual Host
Configuration” for details.
Configuring Apache manually involves editing plain text configuration les as user root .
The term virtual host refers to Apache's ability to serve multiple universal resource identifiers
(URIs) from the same physical machine. This means that several domains, such as www.exam-
ple.com and www.example.net, are run by a single Web server on one physical machine.
It is common practice to use virtual hosts to save administrative effort (only a single Web server
needs to be maintained) and hardware expenses (each domain does not require a dedicated
server). Virtual hosts can be name based, IP based, or port based.
To list all existing virtual hosts, use the command httpd2 -S . This outputs a list showing
the default server and all virtual hosts together with their IP addresses and listening ports.
Furthermore, the list also contains an entry for each virtual host showing its location in the
configuration les.
Virtual hosts can be configured via YaST as described in Section 31.2.3.1.4, “Virtual Hosts” or by
manually editing a configuration le. By default, Apache in SUSE Linux Enterprise Server is
prepared for one configuration le per virtual host in /etc/apache2/vhosts.d/ . All les in
this directory with the extension .conf are automatically included to the configuration. A
basic template for a virtual host is provided in this directory ( vhost.template or vhost-
ssl.template for a virtual host with SSL support).
With name-based virtual hosts, more than one Web site is served per IP address. Apache uses
the host eld in the HTTP header that is sent by the client to connect the request to a matching
ServerName entry of one of the virtual host declarations. If no matching ServerName is found,
the rst specified virtual host is used as a default.
The directive NameVirtualHost tells Apache on which IP address and, optionally, which port
it should listen to for requests by clients containing the domain name in the HTTP header. This
option is configured in the configuration le /etc/apache2/listen.conf .
The rst argument can be a fully qualified domain name, but it is recommended to use the IP
address. The second argument is the port and is optional. By default, port 80 is used and is
configured via the Listen directive.
The wild card * can be used for both the IP address and the port number to receive requests
on all interfaces. IPv6 addresses must be enclosed in square brackets.
EXAMPLE 31.1: VARIATIONS OF NAME-BASED VirtualHost ENTRIES
# NameVirtualHost IP-address[:Port]
NameVirtualHost 192.168.3.100:80
NameVirtualHost 192.168.3.100
NameVirtualHost *:80
NameVirtualHost *
NameVirtualHost [2002:c0a8:364::]:80
The opening VirtualHost tag takes the IP address (or fully qualified domain name) previously
declared with the NameVirtualHost as an argument in a name-based virtual host configuration.
A port number previously declared with the NameVirtualHost directive is optional.
The wild card * is also allowed as a substitute for the IP address. This syntax is only valid in
combination with the wild card usage in NameVirtualHost * . When using IPv6 addresses, the
address must be included in square brackets.
EXAMPLE 31.2: NAME-BASED VirtualHost DIRECTIVES
<VirtualHost 192.168.3.100:80>
<VirtualHost 192.168.3.100>
...
</VirtualHost>
<VirtualHost *:80>
...
</VirtualHost>
<VirtualHost *>
...
</VirtualHost>
<VirtualHost [2002:c0a8:364::]>
...
</VirtualHost>
This alternative virtual host configuration requires the setup of multiple IPs for a machine. One
instance of Apache hosts several domains, each of which is assigned a different IP.
The physical server must have one IP address for each IP-based virtual host. If the machine does
not have multiple network cards, virtual network interfaces (IP aliasing) can also be used.
The following example shows Apache running on a machine with the IP 192.168.3.100 , host-
ing two domains on the additional IPs 192.168.3.101 and 192.168.3.102 . A separate Vir-
tualHost block is needed for every virtual server.
<VirtualHost 192.168.3.101>
...
</VirtualHost>
<VirtualHost 192.168.3.102>
...
</VirtualHost>
Here, VirtualHost directives are only specified for interfaces other than 192.168.3.100 .
When a Listen directive is also configured for 192.168.3.100 , a separate IP-based virtual
host must be created to answer HTTP requests to that interface—otherwise the directives found
in the default server configuration ( /etc/apache2/default-server.conf ) are applied.
At least the following directives should be present in each virtual host configuration in order to
set up a virtual host. See /etc/apache2/vhosts.d/vhost.template for more options.
ServerName
The fully qualified domain name under which the host should be addressed.
DocumentRoot
Path to the directory from which Apache should serve les for this host. For security rea-
sons, access to the entire le system is forbidden by default, so you must explicitly unlock
this directory within a Directory container.
ServerAdmin
E-mail address of the server administrator. This address is, for example, shown on error
pages Apache creates.
ErrorLog
The error log le for this virtual host. Although it is not necessary to create separate error
log les for each virtual host, it is common practice to do so, because it makes the debug-
ging of errors much easier. /var/log/apache2/ is the default directory for Apache's log
les.
CustomLog
The access log le for this virtual host. Although it is not necessary to create separate
access log les for each virtual host, it is common practice to do so, because it allows
the separate analysis of access statistics for each host. /var/log/apache2/ is the default
directory for Apache's log les.
As mentioned above, access to the whole le system is forbidden by default for security reasons.
Therefore, explicitly unlock the directories in which you have placed the les Apache should
serve—for example the DocumentRoot :
<Directory "/srv/www/www.example.com/htdocs">
Order allow,deny
Allow from all
</Directory>
<VirtualHost 192.168.3.100>
To configure your Web server with YaST, start YaST and select Network Services HTTP Server.
When starting the module for the rst time, the HTTP Server Wizard starts, prompting you to
make a few basic decisions concerning administration of the server. After having finished the
wizard, the HTTP Server Configuration dialog starts each time you call the HTTP Server module.
For more information, see Section 31.2.3.2, “HTTP Server Configuration”.
The HTTP Server Wizard consists of ve steps. In the last step of the dialog, you are given the
opportunity to enter the expert configuration mode to make even more specific settings.
Here, specify the network interfaces and ports Apache uses to listen for incoming requests. You
can select any combination of existing network interfaces and their respective IP addresses. Ports
from all three ranges (well-known ports, registered ports, and dynamic or private ports) that
are not reserved by other services can be used. The default setting is to listen on all network
interfaces (IP addresses) on port 80 .
Check Open Port In Firewall to open the ports in the firewall that the Web server listens on. This
is necessary to make the Web server available on the network, which can be a LAN, WAN, or the
public Internet. Keeping the port closed is only useful in test situations where no external access
to the Web server is necessary. If you have multiple network interfaces, click Firewall Details...
to specify on which interface(s) the port(s) should be opened.
31.2.3.1.2 Modules
The Modules configuration option allows for the activation or deactivation of the script languages
that the Web server should support. For the activation or deactivation of other modules, refer
to Section 31.2.3.2.2, “Server Modules”. Click Next to advance to the next dialog.
This option pertains to the default Web server. As explained in Section 31.2.2.1, “Virtual Host Con-
figuration”, Apache can serve multiple virtual hosts from a single physical machine. The rst
declared virtual host in the configuration le is commonly referred to as the default host. Each
virtual host inherits the default host's configuration.
To edit the host settings (also called directives), choose the appropriate entry in the table then
click Edit. To add new directives, click Add. To delete a directive, select it and click Delete.
Document Root
Alias
With the help of Alias directives, URLs can be mapped to physical le system locations.
This means that a certain path even outside the Document Root in the le system can be
accessed via a URL aliasing that path.
The default SUSE Linux Enterprise Server Alias /icons points to /usr/share/apache2/
icons for the Apache icons displayed in the directory index view.
ScriptAlias
Similar to the Alias directive, the ScriptAlias directive maps a URL to a le system
location. The difference is that ScriptAlias designates the target directory as a CGI
location, meaning that CGI scripts should be executed in that location.
Directory
With Directory settings, you can enclose a group of configuration options that will only
apply to the specified directory.
Access and display options for the directories /srv/www/htdocs , /usr/share/apache2/
icons and /srv/www/cgi-bin are configured here. It should not be necessary to change
the defaults.
Include
With include, additional configuration les can be specified. Two Include directives are
already pre-configured: /etc/apache2/conf.d/ is the directory containing the configura-
tion les that come with external modules. With this directive, all les in this directory end-
ing in .conf are included. With the second directive, /etc/apache2/conf.d/apache2-
manual.conf , the apache2-manual configuration le is included.
Server Name
This specifies the default URL used by clients to contact the Web server. Use a fully qualified
domain name (FQDN) to reach the Web server at http://FQDN/ or its IP address. You
cannot choose an arbitrary name here—the server must be “known” under this name.
After finishing with the Default Host step, click Next to continue with the configuration.
In this step, the wizard displays a list of already configured virtual hosts (see Section 31.2.2.1,
“Virtual Host Configuration”). If you have not made manual changes prior to starting the YaST
HTTP wizard, no virtual host is present.
To add a host, click Add to open a dialog in which to enter basic information about the host,
such as Server Name, Server Contents Root ( DocumentRoot ), and the Administrator E-Mail. Server
Resolution is used to determine how a host is identified (name based or IP based). Specify the
name or IP address with Change Virtual Host ID
Clicking Next advances to the second part of the virtual host configuration dialog.
In part two of the virtual host configuration you can specify whether to enable CGI scripts and
which directory to use for these scripts. It is also possible to enable SSL. If you do so, you
must specify the path to the certificate as well. See Section 31.6.2, “Configuring Apache with SSL”
for details on SSL and certificates. With the Directory Index option, you can specify which le
to display when the client requests a directory (by default, index.html ). Add one or more
filenames (space-separated) if you want to change this. With Enable Public HTML, the content
of the users public directories ( ~user/public_html/ ) is made available on the server under
http://www.example.com/~user .
31.2.3.1.5 Summary
This is the final step of the wizard. Here, determine how and when the Apache server is started:
when booting or manually. Also see a short summary of the configuration made so far. If you
are satisfied with your settings, click Finish to complete configuration. If you want to change
something, click Back until you have reached the desired dialog. Clicking HTTP Server Expert
Configuration opens the dialog described in Section 31.2.3.2, “HTTP Server Configuration”.
The HTTP Server Configuration dialog also lets you make even more adjustments to the config-
uration than the wizard (which only runs if you configure your Web server for the rst time).
It consists of four tabs described in the following. No configuration option you change here is
effective immediately—you always must confirm your changes with Finish to make them effec-
tive. Clicking Abort leaves the configuration module and discards your changes.
In HTTP Service, select whether Apache should be running (Enabled) or stopped (Disabled). In
Listen on Ports, Add, Edit, or Delete addresses and ports on which the server should be available.
The default is to listen on all interfaces on port 80 . You should always check Open Port In
Firewall, because otherwise the Web server is not reachable from outside. Keeping the port closed
is only useful in test situations where no external access to the Web server is necessary. If you
have multiple network interfaces, click Firewall Details... to specify on which interface(s) the
port(s) should be opened.
You can change the status (enabled or disabled) of Apache2 modules by clicking Toggle Status.
Click Add Module to add a new module that is already installed but not yet listed. Learn more
about modules in Section 31.4, “Installing, Activating, and Configuring Modules”.
These dialogs are identical to the ones already described. Refer to Section 31.2.3.1.3, “Default Host”
and Section 31.2.3.1.4, “Virtual Hosts”.
status
Checks if Apache is started.
start
startssl
Starts Apache with SSL support if it is not already running. For more information about
SSL support, refer to Section 31.6, “Setting Up a Secure Web Server with SSL”.
stop
Stops Apache by terminating the parent process.
restart
Stops and then restarts Apache. Starts the Web server if it was not running before.
try-restart
Stops then restarts Apache only if it is already running.
reload or graceful
Stops the Web server by advising all forked Apache processes to rst finish their requests
before shutting down. As each process dies, it is replaced by a newly started one, resulting
in a complete “restart” of Apache.
restart-graceful
Starts a second Web server that immediately serves all incoming requests. The previous
instance of the Web server continues to handle all existing requests for a defined period
of time configured with GracefulShutdownTimeout .
rcapache2 restart-graceful is either useful when upgrading to a new version or when
having changed configuration options that require a restart. Using this option ensures a
minimum server downtime.
GracefulShutdownTimeout needs to be set, otherwise restart-graceful will result in
a regular restart. If set to zero, the server will wait indefinitely until all remaining requests
have been fully served.
A graceful restart can fail if the original Apache instance is not able to clear all necessary
resources. In this case, the command will result in a graceful stop.
stop-graceful
configtest or extreme-configtest
Checks the syntax of the configuration les without affecting a running Web server. Be-
cause this check is forced every time the server is started, reloaded, or restarted, it is usu-
ally not necessary to run the test explicitly (if a configuration error is found, the Web
server is not started, reloaded, or restarted). The extreme-configtest options start the
Web server as user nobody and actually load the configuration, so more errors can be
detected. Note that although the configuration is loaded, it is not possible to test the SSL
setup because the SSL certificates cannot be read by nobody .
probe
Probes for the necessity of a reload (checks whether the configuration has changed) and
suggests the required arguments for the rcapache2 command.
421 Installing, Activating, and Configuring Modules SUSE Linux Enterp… 11 SP4
Apache modules can be divided into four different categories:
Base Modules
Base modules are compiled into Apache by default. Apache in SUSE Linux Enterprise Server
has only mod_so (needed to load other modules) and http_core compiled in. All others
are available as shared objects: rather than being included in the server binary itself, they
can be included at runtime.
Extension Modules
In general, modules labeled as extensions are included in the Apache software package,
but are usually not compiled into the server statically. In SUSE Linux Enterprise Server,
they are available as shared objects that can be loaded into Apache at runtime.
External Modules
Modules labeled external are not included in the official Apache distribution. However,
SUSE Linux Enterprise Server provides several of them.
If you have done a default installation as described in Section 31.1.2, “Installation”, the following
modules are already installed: all base and extension modules, the multiprocessing module Pre-
fork MPM, and the external modules mod_php5 and mod_python .
You can install additional external modules by starting YaST and choosing Software Software
Management. Now choose Filter Search and search for apache. Among other packages, the results
list contains all available external Apache modules.
All base and extension modules are described in detail in the Apache documentation. Only
a brief description of the most important modules is available here. Refer to http://httpd.a-
pache.org/docs/2.2/mod/ to learn details about each module.
mod_actions
Provides methods to execute a script whenever a certain MIME type (such as applica-
tion/pdf ), a le with a specific extension (like .rpm ), or a certain request method (such
as GET ) is requested. This module is enabled by default.
mod_alias
Provides Alias and Redirect directives with which you can map a URl to a specific
directory ( Alias ) or redirect a requested URL to another location. This module is enabled
by default.
mod_auth*
The authentication modules provide different authentication methods: basic authentica-
tion with mod_auth_basic or digest authentication with mod_auth_digest . Digest au-
thentication in Apache 2.2 is considered experimental.
mod_auth_basic and mod_auth_digest must be combined with an authentication
provider module, mod_authn_* (for example, mod_authn_file for text le–based au-
thentication) and with an authorization module mod_authz_* (for example, mod_au-
thz_user for user authorization).
mod_autoindex
Autoindex generates directory listings when no index le (for example, index.html ) is
present. The look and feel of these indexes is configurable. This module is enabled by
default. However, directory listings are disabled by default via the Options directive—
overwrite this setting in your virtual host configuration. The default configuration le for
this module is located at /etc/apache2/mod_autoindex-defaults.conf .
mod_cgi
mod_cgi is needed to execute CGI scripts. This module is enabled by default.
mod_deflate
Using this module, Apache can be configured to compress given le types on the y before
delivering them.
mod_dir
mod_dir provides the DirectoryIndex directive with which you can configure which
les are automatically delivered when a directory is requested ( index.html by default).
It also provides an automatic redirect to the correct URL when a directory request does
not contain a trailing slash. This module is enabled by default.
mod_env
Controls the environment that is passed to CGI scripts or SSI pages. Environment variables
can be set or unset or passed from the shell that invoked the httpd process. This module
is enabled by default.
mod_expires
With mod_expires , you can control how often proxy and browser caches refresh your
documents by sending an Expires header. This module is enabled by default.
mod_include
mod_include lets you use Server Side Includes (SSI), which provide a basic functionality
to generate HTML pages dynamically. This module is enabled by default.
mod_info
Provides a comprehensive overview of the server configuration under http://local-
host/server-info/. For security reasons, you should always limit access to this URL. By
default only localhost is allowed to access this URL. mod_info is configured at /etc/
apache2/mod_info.conf .
mod_mime
The mime module makes certain that a le is delivered with the correct MIME header
based on the filename's extension (for example text/html for HTML documents). This
module is enabled by default.
mod_negotiation
Necessary for content negotiation. See http://httpd.apache.org/docs/2.2/content-negotia-
tion.html for more information. This module is enabled by default.
mod_nss
Enables encrypted connections between Web server and clients via TLS 1.1 and TLS 1.2
protocols using the Mozilla Network Security Services library. See Section 31.7, “Setting Up
a Secure Web Server with NSS” for details.
mod_rewrite
Provides the functionality of mod_alias , but offers more features and flexibility. With
mod_rewrite , you can redirect URLs based on multiple rules, request headers, and more.
mod_setenvif
Sets environment variables based on details of the client's request, such as the browser
string the client sends, or the client's IP address. This module is enabled by default.
mod_speling
mod_speling attempts to automatically correct typographical errors in URLs, such as
capitalization errors.
mod_ssl
Enables encrypted connections between Web server and clients. See Section 31.6, “Setting Up
a Secure Web Server with SSL” for details. This module is enabled by default.
mod_status
Provides information on server activity and performance under http://localhost/serv-
er-status/. For security reasons, you should always limit access to this URL. By default, only
localhost is allowed to access this URL. mod_status is configured at /etc/apache2/
mod_status.conf
mod_suexec
mod_userdir
Enables user-specific directories available under ~user/ . The UserDir directive must be
specified in the configuration. This module is enabled by default.
Prefork MPM
mod-apparmor
Adds support to Apache to provide AppArmor confinement to individual CGI scripts han-
dled by modules like mod_php5 and mod_perl .
mod_mono
mod_auth_kerb provides Kerberos authentication to the Apache Web server.
mod_mono
Using mod_mono allows you to run ASP.NET pages in your server.
mod_perl
mod_perl enables you to run Perl scripts in an embedded interpreter. The persistent in-
terpreter embedded in the server avoids the overhead of starting an external interpreter
and the penalty of Perl start-up time.
mod_php5
PHP is a server-side, cross-platform HTML embedded scripting language.
mod_python
mod_python allows embedding Python within the Apache HTTP server for a considerable
boost in performance and added flexibility in designing Web-based applications.
mod_security
mod_security provides a Web application firewall to protect Web applications from a
range of attacks. It also enables HTTP traffic monitoring and real-time analysis.
31.4.6 Compilation
Apache can be extended by advanced users by writing custom modules. To develop modules
for Apache or compile third-party modules, the package apache2-devel is required along with
the corresponding development tools. apache2-devel also contains the apxs2 tools, which
are necessary for compiling additional modules for Apache.
apxs2 enables the compilation and installation of modules from source code (including the
required changes to the configuration les), which creates dynamic shared objects (DSOs) that
can be loaded into Apache at runtime.
/usr/sbin/apxs2 —suitable for building an extension module that works with any MPM.
The installation location is /usr/lib/apache2 .
Install and activate a module from source code with the following commands:
where -c compiles the module, -i installs it, and -a activates it. Other options of apxs2 are
described in the apxs2(1) man page.
<Directory "/srv/www/www.example.com/cgi-bin/">
Options +ExecCGI 2
Order allow,deny 4
1 Tells Apache to handle all les within this directory as CGI scripts.
2 Enables CGI script execution
3 Tells the server to treat les with the extensions .pl and .cgi as CGI scripts. Adjust according
to your needs.
4 The Order and Allow directives control the default access state and the order in which
allow and deny directives are evaluated. In this case “allow” statements are evaluated
before “deny” statements and universal access is enabled.
CGI TROUBLESHOOTING
Have you reloaded the server after having changed the configuration? Check with rca-
pache2 probe .
If you have configured your custom CGI directory, is it configured properly? If in doubt, try
the script within the default CGI directory /srv/www/cgi-bin/ and call it with http://
localhost/cgi-bin/test.cgi .
Are the le permissions correct? Change into the CGI directory and execute ls -l test.c-
gi . Its output should start with
Make sure that the script does not contain programming errors. If you have not changed
test.cgi , this should not be the case, but if you are using your own programs, always
make sure that they do not contain programming errors.
The most visible effect of using mod_ssl with Apache is that URLs are prefixed with https://
instead of http:// .
Generating a dummy certificate is simple. Just call the script /usr/bin/gensslcert . It creates
or overwrites the les listed below. Make use of gensslcert 's optional switches to ne-tune
the certificate. Call /usr/bin/gensslcert -h for more information.
/etc/apache2/ssl.crt/ca.crt
/etc/apache2/ssl.crt/server.crt
/etc/apache2/ssl.key/server.key
/etc/apache2/ssl.csr/server.csr
/root/.mkcert.cfg
If you are setting up a secure Web server for an intranet or for a defined circle of users, it might
be sufficient if you sign a certificate with your own certificate authority (CA).
Creating a self-signed certificate is an interactive nine-step process. Change into the directory
/usr/share/doc/packages/apache2 and run the following command: ./mkcert.sh make
--no-print-directory /usr/bin/openssl /usr/sbin/ custom . Do not attempt to run this
command from outside this directory. The program provides a series of prompts, some of which
require user input.
The script's result page presents a list of certificates and keys it has generated. Contrary to what
the script outputs, the les have not been generated in the local directory conf , but to the
correct locations under /etc/apache2/ .
The last step is to copy the CA certificate le from /etc/apache2/ssl.crt/ca.crt to a location
where your users can access it in order to incorporate it into the list of known and trusted CAs
in their Web browsers. Otherwise a browser complains that the certificate was issued by an
unknown authority. The certificate is valid for one year.
First the script asks for a password with which the CSR should be encrypted. Then you are asked
to enter a distinguished name. This requires you to answer a few questions, such as country
name or organization name. Enter valid data—everything you enter here later shows up in the
certificate and is checked. You do not need to answer every question. If one does not apply to
you or you want to leave it blank, use “.”. Common name is the name of the CA itself—choose
a significant name, such as My company CA. Last, a challenge password and an alternative
company name must be entered.
Find the CSR in the directory from which you called the script. The le is named newreq.pem .
The SSL module is enabled by default in the global server configuration. In case it has been
disabled on your host, activate it with the following command: a2enmod ssl . To finally enable
SSL, the server needs to be started with the ag “SSL”. To do so, call a2enflag SSL . If you
DocumentRoot
ServerName
ServerAdmin
ErrorLog
TransferLog
By default it is not possible to run multiple SSL-enabled virtual hosts on a server with only one
IP address. Name-based virtual hosting requires that Apache knows which server name has been
requested. The problem with SSL connections is, that such a request can only be read after the
SSL connection has already been established (by using the default virtual host). As a result, users
will receive a warning message stating that the certificate does not match the server name.
SUSE Linux Enterprise Server comes with an extension to the SSL protocol called Server Name
Indication (SNI) addresses this issue by sending the name of the virtual domain as part of the SSL
negotiation. This enables the server to “switch” to the correct virtual domain early and present
the browser the correct certificate.
SNI is enabled by default on SUSE Linux Enterprise Server. In order to enable Name-Based
Virtual Hosts for SSL, configure the server as described in Section 31.2.2.1.1, “Name-Based Virtual
Hosts” (note that you need to use port 443 rather than port 80 with SSL).
Both mod_ssl and mod_nss can be initialized at the same time, but the protocol handlers
( SSLEngine on for mod_ssl and NSSEngine on for mod_nss ) cannot be active simultaneous-
ly, at a global scope, or in the context of a VirtualHost configuration directive block.
438 Setting Up a Secure Web Server with NSS SUSE Linux Enterp… 11 SP4
If only one VirtualHost section has the directive NSSEngine set to on , it will have precedence
over all other VirtualHost declarations (that may have SSLEngine set to on in their context),
for a port that Apache listens on. A simultaneaous operation of both modules for different Vir-
tualHosts on the same IP address and port is not possible. If you need support for encrypted
connections using both mod_nss and mod_ssl , you should consider using more than one IP
address and configuring the server's cryptographic modules to be bound to their IP addresses.
If you do not need both cryptographic modules simultaneaously, it is recommended to decide
on one and deactivate the other.
Because mmod_nss uses a database format for the server and CA certificates and the private
key, existing mod_ssl-based certificates need to be converted for the use with mmod_nss . The
package apache2-mod_nss contains the perl script /usr/sbin/mod_nss_migrate.pl for this
task. The script creates a new database.
To list the certificates contained in the NSS database, use the following command:
certutil -d /etc/apache2/mod_nss.d -L
For more information about the certutil NSS database management utility, use certutil
--help .
The default configuration le that comes with the mod_nss package is /etc/apache2/con-
f.d/mod_nss.conf . Read the comments in the le for more information.
31.9 Troubleshooting
If Apache does not start, the Web page is not accessible, or users cannot connect to the Web
server, it is important to nd the cause of the problem. Here are some typical places to look for
error explanations and important things to check:
Output of rcapache2
Instead of starting and stopping the Web server with the binary /usr/sbin/httpd2 , rather
use the rcapache2 script instead (described in Section 31.3, “Starting and Stopping Apache”).
It is verbose about errors, and it even provides tips and hints for fixing configuration errors.
If the error cannot be tracked down with the help of any these, check the online Apache bug
database at http://httpd.apache.org/bug_report.html . Additionally, the Apache user communi-
ty can be reached via a mailing list available at http://httpd.apache.org/userslist.html . A rec-
ommended newsgroup is comp.infosystems.www.servers.unix .
mod-apparmor
http://en.opensuse.org/SDB:AppArmor
mod-auth_kerb
http://modauthkerb.sourceforge.net/
mod_mono
http://www.mono-project.com/Mod_mono
mod_perl
http://perl.apache.org/
mod_php5
http://www.php.net/manual/en/install.unix.apache2.php
mod_python
http://www.modpython.org/
mod_security
http://modsecurity.org/
31.10.3 Development
More information about developing Apache modules or about getting involved in the Apache
Web server project are available at the following locations:
Using the YaST FTP Server module, you can configure your machine to function as
an FTP (File Transfer Protocol) server. Anonymous and/or authenticated users can
connect to your machine and download les using the FTP protocol. Depending on
the configuration, they can also upload les to the FTP server. YaST provides a uni-
fied configuration interface for various FTP server daemons installed on your sys-
tem.
You can use the YaST FTP Server configuration module to configure two different FTP server
daemons:
pure-ftpd
1. Open YaST Control Center and choose Network Services FTP Server or run the yast2 ftp-
server command as root .
2. If there is not any FTP server installed in your system, you will be asked which server to
install when the YaST FTP Server module starts. Choose a server and confirm the dialog.
If there are two servers installed, choose the preferred server and click OK.
3. In the Start-Up dialog, configure the options for starting of the FTP server. For more infor-
mation, see Section 32.1, “Starting the FTP Server”.
In the General dialog, configure FTP directories, welcome message, le creation masks and
various other parameters. For more information, see Section 32.2, “FTP General Settings”.
In the Performance dialog, set the parameters that affect the load on the FTP server. For
more information, see Section 32.3, “FTP Performance Settings”.
In the Authentication dialog, set whether the FTP server should be available for anonymous
and/or authenticated users. For more information, see Section 32.4, “Authentication”.
32.4 Authentication
In the Enable/Disable Anonymous and Local Users frame of the Authentication dialog, you are able
to set which users are allowed to access your FTP server. You can choose between the following
options: granting access to anonymous users only, to authenticated users only (with accounts
on the system) or to both types of users.
If you want to allow users to upload les to the FTP server, check Enable Upload in the Uploading
frame of the Authentication dialog. Here you are able to allow uploading or creating directories
even for anonymous users by checking the respective box.
Squid is a widely-used proxy cache for Linux and UNIX platforms. This means that
it stores requested Internet objects, such as data on a Web or FTP server, on a ma-
chine that is closer to the requesting workstation than the server. It may be set up
in multiple hierarchies to assure optimal response times and low bandwidth usage,
even in modes that are transparent for the end user. Additional software like squid-
Guard may be used to filter Web contents.
Squid acts as a proxy cache. It redirects object requests from clients (in this case, from Web
browsers) to the server. When the requested objects arrive from the server, it delivers the ob-
jects to the client and keeps a copy of them in the hard disk cache. One of the advantages of
caching is that several clients requesting the same object can be served from the hard disk cache.
This enables clients to receive the data much faster than from the Internet. This procedure also
reduces the network traffic.
Along with the actual caching, Squid offers a wide range of features such as distributing the
load over intercommunicating hierarchies of proxy servers, defining strict access control lists
for all clients accessing the proxy, allowing or denying access to specific Web pages with the
help of other applications, and generating statistics about frequently-visited Web pages for the
assessment of the users' surfing habits. Squid is not a generic proxy. It normally proxies only
HTTP connections. It supports the protocols FTP, Gopher, SSL, and WAIS, but it does not support
other Internet protocols, such as Real Audio, news, or video conferencing. Because Squid only
supports the UDP protocol to provide communication between different caches, many other
multimedia programs are not supported.
450 Some Facts about Proxy Caches SUSE Linux Enterp… 11 SP4
33.1.1 Squid and Security
It is possible to use Squid together with a firewall to secure internal networks from the outside
using a proxy cache. The firewall denies all clients access to external services except Squid. All
Web connections must be established by the proxy. With this configuration, Squid completely
controls Web access.
If the firewall configuration includes a DMZ, the proxy should operate within this zone. Sec-
tion 33.5, “Configuring a Transparent Proxy” describes how to implement a transparent proxy. This
simplifies the configuration of the clients, because in this case they do not need any information
about the proxy.
Several instances of Squid can be configured to exchange objects between them. This reduces
the total system load and increases the chances of finding an object already existing in the local
network. It is also possible to configure cache hierarchies, so a cache is able to forward object
requests to sibling caches or to a parent cache—causing it to get objects from another cache in
the local network or directly from the source.
Choosing the appropriate topology for the cache hierarchy is very important, because it is not
desirable to increase the overall traffic on the network. For a very large network, it would make
sense to configure a proxy server for every subnetwork and connect them to a parent proxy,
which in turn is connected to the proxy cache of the ISP.
All this communication is handled by ICP (Internet cache protocol) running on top of the UDP
protocol. Data transfers between caches are handled using HTTP (hypertext transmission pro-
tocol) based on TCP.
To nd the most appropriate server from which to get the objects, one cache sends an ICP
request to all sibling proxies. These answer the requests via ICP responses with a HIT code if
the object was detected or a MISS if it was not. If multiple HIT responses were found, the proxy
server decides from which server to download, depending on factors such as which cache sent
the fastest answer or which one is closer. If no satisfactory responses are received, the request
is sent to the parent cache.
Not all objects available in the network are static. There are a lot of dynamically generated CGI
pages, visitor counters, and encrypted SSL content documents. Objects like this are not cached
because they change each time they are accessed.
The question remains as to how long all the other objects stored in the cache should stay there.
To determine this, all objects in the cache are assigned one of various possible states. Web and
proxy servers nd out the status of an object by adding headers to these objects, such as “Last
modified” or “Expires” and the corresponding date. Other headers specifying that objects must
not be cached are used as well.
Objects in the cache are normally replaced, due to a lack of free hard disk space, using algorithms
such as LRU (last recently used). Basically this means that the proxy expunges the objects that
have not been requested for the longest time.
In a small cache, the probability of a HIT (finding the requested object already located there)
is small, because the cache is easily lled and the less requested objects are replaced by newer
ones. If, for example, one GB is available for the cache and the users only surf ten MB per day,
it would take more than one hundred days to ll the cache.
The easiest way to determine the needed cache size is to consider the maximum transfer rate of
the connection. With a 1 Mbit/s connection, the maximum transfer rate is 125 KB/s. If all this
traffic ends up in the cache, in one hour it would add up to 450 MB and, assuming that all this
traffic is generated in only eight working hours, it would reach 3.6 GB in one day. Because the
connection is normally not used to its upper volume limit, it can be assumed that the total data
volume handled by the cache is approximately 2 GB. This is why 2 GB of disk space is required
in the example for Squid to keep one day's worth of browsed data cached.
33.2.3 RAM
The amount of memory (RAM) required by Squid directly correlates to the number of objects
in the cache. Squid also stores cache object references and frequently requested objects in the
main memory to speed up retrieval of this data. Random access memory is much faster than
a hard disk.
In addition to that, there is other data that Squid needs to keep in memory, such as a table
with all the IP addresses handled, an exact domain name cache, the most frequently requested
objects, access control lists, buers, and more.
33.2.4 CPU
Squid is not a program that requires intensive CPU usage. The load of the processor is only
increased while the contents of the cache are loaded or checked. Using a multiprocessor machine
does not increase the performance of the system. To increase efficiency, it is better to buy faster
disks or add more memory.
To start Squid, enter rcsquid start at the command line as root . In the initial start-up, the
directory structure of the cache must rst be defined in /var/cache/squid . This is done auto-
matically by the start script /etc/init.d/squid and can take a few seconds or even minutes. If
done appears to the right in green, Squid has been successfully loaded. To test the functionality
of Squid on the local system, enter localhost as the proxy and 3128 as the port in the browser.
The command rcsquid status can be used to check if the proxy is running. The command
rcsquid stop causes Squid to shut down. This can take a while, because Squid waits up to
half a minute ( shutdown_lifetime option in /etc/squid/squid.conf ) before dropping the
connections to the clients and writing its data to the disk.
If Squid dies after a short period of time even though it was started successfully, check whether
there is a faulty name server entry or whether the /etc/resolv.conf le is missing. Squid
logs the cause of a start-up failure in the le /var/log/squid/cache.log . If Squid should be
loaded automatically when the system boots, use the YaST runlevel editor to activate Squid for
the desired runlevels. See Section 10.2.3, “Configuring System Services (Runlevel) with YaST”.
An uninstall of Squid does not remove the cache hierarchy or the log les. To remove these,
delete the /var/cache/squid directory manually.
Setting up a local DNS server makes sense even if it does not manage its own domain. It then
simply acts as a caching-only name server and is also able to resolve DNS requests via the root
name servers without requiring any special configuration (see Section 25.4, “Starting the BIND Name
Server”). How this can be done depends on whether or not you chose dynamic DNS during the
configuration of the Internet connection.
Dynamic DNS
Static DNS
With static DNS, no automatic DNS adjustments take place while establishing a connection,
so there is no need to change any sysconfig variables. You must, however, enter the local
DNS server in the le /etc/resolv.conf as described above. Additionally, the providers
static name server must be entered manually in the /etc/named.conf le under for-
warders along with its IP address.
http_port 3128
This is the port on which Squid listens for client requests. The default port is 3128 , but
8080 is also common. If desired, specify several port numbers separated by blank spaces.
cache_mem 8 MB
This entry defines the amount of memory Squid can use for very popular replies. The
default is 8 MB . This does not specify the memory usage of Squid and may be exceeded.
emulate_httpd_log o
If the entry is set to on, obtain readable log les. Some evaluation programs cannot inter-
pret this, however.
client_netmask 255.255.255.255
With this entry, mask IP addresses of clients in the log les. The last digit of the IP address
is set to zero if you enter 255.255.255.0 here. You may protect the privacy of your clients
this way.
ftp_user Squid@
With this, set the password Squid should use for the anonymous FTP login. It can make
sense to specify a valid e-mail address here, because some FTP servers check these for
validity.
cache_mgr webmaster
An e-mail address to which Squid sends a message if it unexpectedly crashes. The default
is webmaster.
logfile_rotate 0
If you run squid -k rotate , Squid can rotate secured log les. The les are numbered
in this process and, after reaching the specified value, the oldest le is overwritten. The
default value is 0 because archiving and deleting log les in SUSE Linux Enterprise Server
is carried out by a cron job set in the configuration le /etc/logrotate/squid .
append_domain <domain>
With append_domain, specify which domain to append automatically when none is given.
Usually, your own domain is entered here, so entering www in the browser accesses your
own Web server.
forwarded_for on
If you set the entry to o, Squid removes the IP address and the system name of the client
from HTTP requests. Otherwise it adds a line to the header like
Squid provides a detailed system for controlling the access to the proxy. By implementing ACLs,
it can be configured easily and comprehensively. This involves lists with rules that are processed
sequentially. ACLs must be defined before they can be used. Some default ACLs, such as all and
localhost, already exist. However, the mere definition of an ACL does not mean that it is actually
applied. This only happens in conjunction with http_access rules.
In another example using these rules, the group teachers always has access to the Inter-
net. The group students only gets access Monday to Friday during lunch time.
The list with the http_access entries should only be entered, for the sake of readability, at
the designated position in the /etc/squid/squid.conf le. That is, between the text
redirect_program /usr/bin/squidGuard
With this option, specify a redirector such as squidGuard, which allows the blocking of
unwanted URLs. Internet access can be individually controlled for various user groups
with the help of proxy authentication and the appropriate ACLs. squidGuard is a separate
package that can be installed and configured.
The REQUIRED after proxy_auth can be replaced with a list of permitted usernames or with
the path to such a list.
Here, too, replace REQUIRED with a list of permitted usernames. Using ident can slow
down the access time quite a bit, because ident lookups are repeated for each request.
For security reasons, it is recommended that all clients use a proxy to surf the Internet.
All clients must use a proxy, regardless of whether they are aware of it.
The proxy in a network is moved, but the existing clients need to retain their old config-
uration.
In all these cases, a transparent proxy may be used. The principle is very easy: the proxy inter-
cepts and answers the requests of the Web browser, so the Web browser receives the requested
pages without knowing from where they are coming. As the name indicates, the entire process
is done transparently.
To inform squid that it should act as a transparent proxy, use the option transparent at the
tag http_port in the main configuration le /etc/squid/squid.conf . After restarting squid,
the only other thing that must be done is to reconfigure the firewall to redirect the http port to
the port given in http_port . In the following squid config line, this would be the port 3128.
Now redirect all incoming requests via the firewall with help of a port forwarding rule to the
Squid port. To do this, use the enclosed tool SuSEFirewall2, described in Book “Security Guide”,
Chapter 15 “Masquerading and Firewalls”, Section 15.4 “SuSEfirewall2”, Section 15.4.1 “Configuring the
Firewall with YaST”. Its configuration le can be found in /etc/sysconfig/SuSEfirewall2 . The
configuration le consists of well-documented entries. To set a transparent proxy, you must
configure several firewall options:
Define ports and services (see /etc/services ) on the firewall that are accessed from untrusted
(external) networks such as the Internet. In this example, only Web services are offered to the
outside:
FW_SERVICES_EXT_TCP="www"
Define ports or services (see /etc/services ) on the firewall that are accessed from the secure
(internal) network, both via TCP and UDP:
This allows accessing Web services and Squid (whose default port is 3128 ). The service “do-
main” stands for DNS (domain name service). This service is commonly used. Otherwise, simply
take it out of the above entries and set the following option to no :
FW_SERVICE_DNS="yes"
# 15.)
# Which accesses to services should be redirected to a local port on
# the firewall machine?
#
# This option can be used to force all internal users to surf via
# your squid proxy, or transparently redirect incoming webtraffic to
# a secure webserver.
#
# Format:
# list of <source network>[,<destination network>,<protocol>[,dport[:lport]]
# Where protocol is either tcp or udp. dport is the original
# destination port and lport the port on the local machine to
# redirect the traffic to
#
# An exclamation mark in front of source or destination network
# means everything EXCEPT the specified network
#
# Example: "10.0.0.0/8,0/0,tcp,80,3128 0/0,172.20.1.1,tcp,80,8080"
The comments above show the syntax to follow. First, enter the IP address and the netmask of
the internal networks accessing the proxy firewall. Second, enter the IP address and the netmask
to which these clients send their requests. In the case of Web browsers, specify the networks
0/0 , a wild card that means “to everywhere.” After that, enter the original port to which these
requests are sent and, finally, the port to which all these requests are redirected. Because Squid
supports protocols other than HTTP, redirect requests from other ports to the proxy, such as
FTP (port 21), HTTPS, or SSL (port 443). In this example, Web services (port 80 ) are redirected
to the proxy port (port 3128 ). If there are more networks or services to add, they must be
separated by a blank space in the respective entry.
FW_REDIRECT="192.168.0.0/16,0/0,tcp,80,3128"
To start the firewall and the new configuration with it, change an entry in the /etc/syscon-
fig/SuSEfirewall2 le. The entry START_FW must be set to "yes" .
Start Squid as shown in Section 33.3, “Starting Squid”. To verify that everything is working properly,
check the Squid logs in /var/log/squid/access.log .
To verify that all ports are correctly configured, perform a port scan on the machine from any
computer outside your network. Only the Web services (port 80) should be open. To scan the
ports with nmap, the command syntax is nmap -O IP_address .
33.6.1 Setup
First, a running Web server on your system is required. Configure Apache as described in Chap-
ter 31, The Apache HTTP Server. To check if Apache is already running, as root enter the command
rcapache status . If a message like this appears:
Apache is running on the machine. Otherwise, enter rcapache start to start Apache with
the SUSE Linux Enterprise Server default settings. The last step to set it up is to copy the le
cachemgr.cgi to the Apache directory cgi-bin . For 32-bit, this works as follows:
cp /usr/lib/squid/cachemgr.cgi /srv/www/cgi-bin/
In a 64-bit environment, the le cachemgr.cgi is located below /usr/lib64/squid/ and the
command to copy it to the Apache directory is the following:
cp /usr/lib64/squid/cachemgr.cgi /srv/www/cgi-bin/
These rules assume that the Web server and Squid are running on the same machine. If the
communication between the cache manager and Squid originates at the Web server on another
computer, include an extra ACL as in Example 33.2, “Access Rules”.
EXAMPLE 33.2: ACCESS RULES
Then add the rules in Example 33.3, “Access Rules” to permit access from the Web server.
EXAMPLE 33.3: ACCESS RULES
Configure a password for the manager for access to more options, like closing the cache remotely
or viewing more information about the cache. For this, configure the entry cachemgr_passwd
with a password for the manager and the list of options to view. This list appears as a part of
the entry comments in /etc/squid/squid.conf .
Restart Squid every time the configuration le is changed. Do this easily with rcsquid reload .
33.7 squidGuard
This section is not intended to explain an extensive configuration of squidGuard, only to intro-
duce it and give some advice for using it. For more in-depth configuration issues, refer to the
squidGuard Web site at http://www.squidguard.org .
Limit Web access for some users to a list of accepted or well-known Web servers or URLs.
Block access to some listed or blacklisted Web servers or URLs for some users.
Block access to URLs matching a list of regular expressions or words for some users.
Use different access rules based on time of day, day of the week, date, etc.
Before it can be used, install squidGuard . Provide a minimal configuration le as /etc/squid-
guard.conf . Find configuration examples in http://www.squidguard.org/Doc/examples.html .
Experiment later with more complicated configuration settings.
Next, create a dummy “access denied” page or a more or less complex CGI page to redirect Squid
if the client requests a blacklisted Web site. Using Apache is strongly recommended.
Now, configure Squid to use squidGuard. Use the following entry in the /etc/squid/
squid.conf le:
redirect_program /usr/bin/squidGuard
Another option called redirect_children configures the number of “redirect” (in this case
squidGuard) processes running on the machine. The more processes you set, the more RAM is
required. Try low numbers (e.g. 4) rst.
redirect_children 4
-a
output all available reports
-w
output as HTML report
-l
include a message or logo in report header
More information about the various options can be found in the program's manual page with
man calamaris .
This puts the report in the directory of the Web server. Apache is required to view the reports.
467 Cache Report Generation with Calamaris SUSE Linux Enterp… 11 SP4
33.9 For More Information
Visit the home page of Squid at http://www.squid-cache.org/ . Here, nd the “Squid User Guide”
and a very extensive collection of FAQs on Squid.
Following the installation, a small HOWTO about transparent proxies is available in how-
toenh as /usr/share/doc/howto/en/txt/TransparentProxy.gz . In addition, mailing lists
are available for Squid at squid-users@squid-cache.org . The archive for this is located at http://
www.squid-cache.org/mail-archive/squid-users/ .
Common Information Model is a conceptual information model that describes system manage-
ment. It is not bound to a particular implementation and enables the interchange of management
information between management systems, networks, services and applications. There are two
parts to CIM — the CIM Specification and the CIM Schema.
The CIM Schema provides the actual model descriptions. It supplies a set of classes with
properties and associations that provide a well understood conceptual framework within
which it is possible to organize the available information about the managed environment.
The Common Information Model Object Manager (CIMOM) is a CIM object manager or, more
specifically, an application that manages objects according to the CIM standard. CIMOM man-
ages communication between CIMOM providers and a CIM client, where the administrator man-
ages the system.
CIMOM providers are software performing specific tasks within the CIMOM that are requested
by client applications. Each provider instruments one or more aspects of the CIMOM's schema.
These providers interact directly with the hardware.
Standards Based Linux Instrumentation for Manageability (SBLIM) is a collection of tools designed
to support Web-Based Enterprise Management (WBEM). SUSE® Linux Enterprise Server uses the
open source CIMOM (or CIM server) from the SBLIM project called Small Footprint CIM Broker .
Small Footprint CIM Broker is a CIM server intended for use in resource-limited or embedded envi-
ronments. It is designed to be modular and lightweight at the same time. Its based on open stan-
dards and it supports CMPI providers, CIM-XML encoding, and Managed Object Format (MOF).
It is highly configurable and performs stability even if the provider crashes. It is also easily ac-
cessible as it supports various transport protocols, such as HTTP, HTTPS, Unix domain sockets,
Service Location Protocol (SLP), and Java Database Connectivity (JDBC).
cmpi-bindings-pywbem
Contains an adapter to write and run CMPI-type CIM providers in Python.
cmpi-pywbem-base
Contains base system CIM providers.
cmpi-pywbem-power-management
Contains power management providers based on DSP1027.
python-pywbem
Contains a Python module for making CIM operation calls through the WBEM protocol to
query and update managed objects.
sblim-sfcc
Contains Small Footprint CIM Client library runtime libraries.
sblim-wbemcli
Contains WBEM command line interface. It is a standalone command line WBEM client
especially suited for basic systems management tasks.
smis-providers
Contains providers to instrument the volumes and snapshots on the Linux le system.
These are based on SNIA's SMI-S volume management profile and Copy Services profile
respectively.
473 Starting, Stopping and Checking Status for SFCB SUSE Linux Enterp… 11 SP4
34.2.3.1 Certificates
Secure Socket Layers (SSL) transports require a certificate for secure communication to occur.
When SFCB is installed, it has a self-signed certificate generated.
You can replace the path to the default certificate with a path to a commercial or self-signed
one by changing the sslCertificateFilePath: path_filename setting in /etc/sfcb/
sfcb.cfg . The le must be in PEM format.
If you want to generate a new certificate, enter the following command as root in the command
line:
tux@mercury:~> sh /usr/share/sfcb/genSslCert.sh
Generating SSL certificates in .
Generating a 2048 bit RSA private key
...................................................................+++
.+++
writing new private key to '/var/tmp/sfcb.0Bjt69/key.pem'
-----
By default, the script generates certificates client.pem , file.pem and server.pem in the
current working directory. If you want the script to generate the certificates in /etc/sfcb
directory, you need to append it to the command. If these les already exist, a warning message
is displayed and the old certificates are not overwritten.
You must remove the old certificates from the le system and run the command again.
34.2.3.2 Ports
By default, SFCB is configured to accept all communications through the secure port 5989. The
following paragraphs explain the communication port setup and recommended configuration.
If you want to change the default port assignments, see Section 34.2.3.2, “Ports”.
34.2.3.3 Authentication
SFCB supports HTTP basic authentication and authentication based on client certificates (HTTP
over SSL connections). Basic HTTP authentication is enabled by specifying doBasicAuth
= true in the SFCB configuration le ( /etc/sfcb/sfcb.cfg by default). SUSE® Linux Enter-
prise Server installation of SFCB supports Pluggable Authentication Modules (PAM) approach;
therefore the local root user can authenticate to the SFCB CIMOM with local root user creden-
tials.
PATH
Specifies the path to the sfcbd daemon and utilities.
LD_LIBRARY_PATH
Specifies the path to the sfcb runtime libraries. Alternatively, you can add this path to the
system-wide dynamic loader configuration le /etc/ld.so.conf .
SFCB_PAUSE_PROVIDER
Specifies the provider name. The SFCB server pauses after the provider is loaded for the
rst time. You can then attach a runtime debugger to the provider's process for debugging
purposes.
SFCB_TRACE
Specifies the level of debug messages for SFCB. Valid values are 0 (no debug messages),
or 1 (key debug messages) to 4 (all debug messages). Default is 1.
SFCB_TRACE_FILE
By default, SFCB outputs its debug messages to standard error output (STDERR). Setting
this variable causes the debug messages to be written to a specified le instead.
SBLIM_TRACE
Specifies the level of debug messages for SBLIM providers. Valid values are 0 (no debug
messages), or 1 (key debug messages) to 4 (all debug messages).
SBLIM_TRACE_FILE
By default, SBLIM provider outputs its trace messages to STDERR. Setting this variable
causes the trace messages to be written to a specified le instead.
-d, --daemon
Forces sfcbd and its child processes to run in the background.
-s, --collect-stats
Turns on runtime statistics collecting. Various sfcbd runtime statistics will be written to
the sfcbStat le in the current working directory. By default, no statistics are collected.
tux@mercury:~> sfcbd -t ?
--- Traceable Components: Int Hex
--- providerMgr: 1 0x0000001
--- providerDrv: 2 0x0000002
--- cimxmlProc: 4 0x0000004
--- httpDaemon: 8 0x0000008
--- upCalls: 16 0x0000010
--- encCalls: 32 0x0000020
--- ProviderInstMgr: 64 0x0000040
--- providerAssocMgr: 128 0x0000080
--- providers: 256 0x0000100
--- indProvider: 512 0x0000200
--- internalProvider: 1024 0x0000400
--- objectImpl: 2048 0x0000800
--- xmlIn: 4096 0x0001000
--- xmlOut: 8192 0x0002000
--- sockets: 16384 0x0004000
--- memoryMgr: 32768 0x0008000
--- msgQueue: 65536 0x0010000
--- xmlParsing: 131072 0x0020000
--- responseTiming: 262144 0x0040000
--- dbpdaemon: 524288 0x0080000
--- slp: 1048576 0x0100000
A useful value that reveals the internal functions of sfcbd but does not generate too many
messages, is -t 2019 .
34.3.3.1 httpPort
Purpose
Specifies the local port value that sfcbd should listen to receive HTTP (insecure) requests from
CIM clients. Default is 5988 .
Syntax
httpPort: port_number
34.3.3.2 enableHttp
Purpose
Specifies whether SFCB should accept HTTP client connections. Default is false .
Syntax
enableHttp: option
Option Description
Purpose
Specifies the maximum number of simultaneous HTTP client connections before new incoming
HTTP requests are blocked. Default is 8 .
Syntax
httpProcs: max_number_of_connections
Purpose
These options control what user the http server will run under. If httpUserSFCB is true , http
will run under the same user as the SFCB main process. If it is false the username specified
for httpUser will be used. This setting is used for both http and https servers. httpUser must
be specified if httpUserSFCB is set to false . the default is true .
Syntax
httpUserSFCB: true
34.3.3.5 httpLocalOnly
Purpose
Syntax
httpLocalOnly: false
Purpose
Specifies the local port value where sfcbd listens for HTTPS requests from CIM clients. Default
is 5989 .
Syntax
httpsPort: port_number
34.3.3.7 enableHttps
Purpose
Syntax
enableHttps: option
Option Description
34.3.3.8 httpsProcs
Purpose
Specifies the maximum number of simultaneous HTTPS client connections before new incoming
HTTPS requests are blocked. Default is 8 .
httpsProcs: max_number_of_connections
34.3.3.9 enableInterOp
Purpose
Specifies if SFCB will provide the interop namespace for indication support. Default is true .
Syntax
enableInterOp: option
Option Description
34.3.3.10 provProcs
Purpose
Specifies the maximum number of simultaneous provider processes. After this point, if a new
incoming request requires loading a new provider, then one of the existing providers will rst
be automatically unloaded. Default is 32 .
Syntax
provProcs: max_number_of_procs
Purpose
Switches basic authentication on or o based on the client user identifier before it accepts the
request. Default value is true which means that basic client authentication is performed.
Syntax
doBasicAuth: option
Option Description
34.3.3.12 basicAuthLib
Purpose
Specifies the local library name. The SFCB server loads the library to authenticate the client user
identifier. Default is sfcBasicPAMAuthentication .
Syntax
provProcs: max_number_of_procs
34.3.3.13 useChunking
Purpose
This option switches the use of HTTP/HTTPS “chunking” on or o. If switched on, the server
will return large volumes of response data to the client in smaller “chunks” , rather than to
buer the data and send it back all in one chunk. Default is true .
useChunking: option
Option Description
34.3.3.14 keepaliveTimeout
Purpose
Specifies the maximum time in seconds that SFCB HTTP process waits between two requests on
one connection before it terminates. Setting it to 0 disables HTTP keep-alive. Default is 0 .
Syntax
keepaliveTimeout: secs
34.3.3.15 keepaliveMaxRequest
Purpose
Specifies the maximum number of consecutive requests on one connection. Setting it to 0 dis-
ables HTTP keep-alive. Default value is 10 .
Syntax
keepaliveMaxRequest: number_of_connections
Purpose
Specifies the registration directory, which contains the provider registration data, the staging
area, and the static repository. Default is /var/lib/sfcb/registration .
Syntax
registrationDir: dir
34.3.3.17 providerDirs
Purpose
Specifies a space-separated list of directories where SFCB is searching for provider libraries.
Default is /usr/lib64 /usr/lib64 /usr/lib64/cmpi .
Syntax
providerDirs: dir
34.3.3.18 providerSampleInterval
Purpose
Specifies the interval in seconds at which the provider manager is checking for idle providers.
Default is 30 .
Syntax
providerSampleInterval: secs
Purpose
Specifies the interval in seconds before an idle provider gets unloaded by the provider manager.
Default is 60 .
Syntax
providerTimeoutInterval: secs
34.3.3.20 providerAutoGroup
Purpose
If the provider registration le does not specify any other group, and the option is set to true ,
all providers in the same shared library are executed in the same process.
Syntax
providerAutoGroup: option
Option Description
34.3.3.21 sslCertificateFilePath
Purpose
Specifies the name of the le that contains the server certificate. The le must be in PEM (Privacy
Enhanced Mail, RFC 1421 and RFC 1424) format. This le is only required if enableHttps is
set to true . Default is /etc/sfcb/server.pem .
sslCertificateFilePath: path
34.3.3.22 sslKeyFilePath
Purpose
Specifies the name of the le that contains the private key for the server certificate. The le
must be in PEM format and may not be protected by passphrase. This le is only required if
enableHttps is set to true . Default is /etc/sfcb/file.pem .
Syntax
sslKeyFilePath: path
34.3.3.23 sslClientTrustStore
Purpose
Specifies the name of the le that contains either the CA or self-signed certificates of the clients.
This le must be in PEM format and is only required if sslClientCertificate is set to accept
or require . Default is /etc/sfcb/client.pem .
Syntax
sslClientTrustStore: path
Purpose
Specifies the way SFCB handles client certificate based authentication. If set to ignore , it will
not request a certificate from the client. If set to accept it will request a certificate from the
client but will not fail if the client does not present one. If set to require , it will refuse the
client connection if the client does not present a certificate. Default value is ignore .
Syntax
sslClientCertificate: option
Option Description
34.3.3.25 certificateAuthLib
Purpose
Specifies the name of the local library to request for the user authentication based on client
certificate. This is only requested if sslClientCertificate is not set to ignore . Default value
is sfcCertificateAuthentication .
Syntax
certificateAuthLib: file
Purpose
Specifies the trace level for SFCB. You can override it by setting environment variable
SFCB_TRACE_LEVEL . Default value is 0 .
Syntax
traceLevel: num_level
34.3.3.27 traceMask
Purpose
Specifies the trace mask for SFCB. you can override it by the command line option --trace-
components . Default value is 0 .
Syntax
traceMask: mask
34.3.3.28 traceFile
Purpose
Specifies the trace le for SFCB. You can override it by setting environment variable
SFCB_TRACE_FILE . Default value is stderr (standard error output).
Syntax
traceFile: output
Testing SFCB
Class repository is a place where SFCB stores information about CIM classes. It usually consists
of a directory tree comprised of namespace components. Typical CIM namespaces are root/
cimv2 or root/interop , which respectively translate to the class repository directory path on
the le system
/var/lib/sfcb/registration/repository/root/cimv2
and
/var/lib/sfcb/registration/repository/root/interop
Each namespace directory contains the le classSchemas . The le has a compiled binary rep-
resentation of all the CIM classes registered under that namespace. It also contains necessary
information about their CIM superclasses.
Copy the provider class definition les to the ./mofs subdirectory of staging area directory
( /var/lib/sfcb/stage/mofs ).
Copy a registration le which contains the name of the class or classes and type of provider,
and the name of the executable library le into the ./regs subdirectory.
There are two default “mof” (class definition) les in the staging directory: indication.mof
and interop.mof . MOF les under the root stage directory /var/lib/sfcb/stage/mofs will
be copied into each namespace after running sfcbrepos command. The interop.mof will
only be compiled into the interop namespace.
The directory layout may look like the following example:
tux@mercury:~> ls /var/lib/sfcb/stage
default.reg mofs regs
tux@mercury:~> ls /var/lib/sfcb/stage/mofs
indication.mof root
tux@mercury:~> ls /var/lib/sfcb/stage/mofs/root
cimv2 interop suse virt
tux@mercury:~> ls -1 /var/lib/sfcb/stage/mofs/root/interop
ComputerSystem.mof
ElementConformsToProfile.mof
HostSystem.mof
interop.mof
Linux_DHCPElementConformsToProfile.mof
[..]
OMC_SMIElementSoftwareIdentity.mof
OMC_SMISubProfileRequiresProfile.mof
OMC_SMIVolumeManagementSoftware.mof
ReferencedProfile.mof
RegisteredProfile.mof
tux@mercury:~> ls -1 /var/lib/sfcb/stage/regs
AllocationCapabilities.reg
Linux_ABIParameter.reg
Linux_BaseIndication.reg
Linux_DHCPGlobal.reg
Linux_DHCPRegisteredProfile.reg
[..]
OMC_Base.sfcb.reg
OMC_CopyServices.sfcb.reg
OMC_PowerManagement.sfcb.reg
OMC_Server.sfcb.reg
RegisteredProfile.reg
[<class-name>]
provider: <provide-name>
location: <library-name>
type: [instance] [association] [method] [indication]
group: <group-name>
unload: never
namespace: <namespace-for-class> ...
where:
<class-name>
The CIM class name (required)
<provider-name>
The CMPI provider name (required)
<location-name>
The name of the provider library (required)
type
The type of the provider (required). This can be any combination of: instance , associ-
ation , method or indication .
<group-name>
unload
Specifies the unload policy for the provider. Currently the only supported option is never ,
which specifies that the provider will not be monitored for idle times and will never be
unloaded. By default each provider will be unloaded when its idle times exceed the value
specified in the configuration le.
namespace
List of namespaces for which this provider can be executed. This is required, although for
most providers this will be root/cimv2 .
Once all the class definitions and provider registration les are stored in the staging area, you
need to rebuild the SFCB class repository with the command sfcbrepos -f .
You can add, change or remove classes this way. After rebuilding the class repository, restart
SFCB with command rcsfcb restart .
Alternatively, the SFCB package contains a utility that will copy provider class mof les and
registration les to the correct locations in the staging area.
sfcbstage -r [provider.reg] [class1.mof] [class2.mof] ...
After running this command you still need to rebuild the class repository and restart SFCB
service.
Sending this request to SFCB CIMOM returns a list of all supported classes for which there is a
registered provider. Suppose you save the le as cim_xml_test.xml .
The classes listed will vary depending on what providers are installed on your system.
The second script xmltest is also used to send a raw CIM-XML test le to the SFCB CIMOM. It
then compares the returned results against a previously saved “OK” result le. If there does not
yet exist a corresponding “OK” le, it will be created for later use:
496 Command Line CIM Client: wbemcli SUSE Linux Enterp… 11 SP4
From server: CIMOperation: MethodResponse
From server: <?xml version="1.0" encoding="utf-8" ?>
<CIM CIMVERSION="2.0" DTDVERSION="2.0">
<MESSAGE ID="4711" PROTOCOLVERSION="1.0">
<SIMPLERSP>
<IMETHODRESPONSE NAME="EnumerateClasses">
<IRETURNVALUE>
<CLASS NAME="CIM_ResourcePool" SUPERCLASS="CIM_LogicalElement">
<PROPERTY NAME="Generation" TYPE="uint64">
</PROPERTY>
<PROPERTY NAME="ElementName" TYPE="string">
</PROPERTY>
<PROPERTY NAME="Description" TYPE="string">
</PROPERTY>
<PROPERTY NAME="Caption" TYPE="string">
</PROPERTY>
<PROPERTY NAME="InstallDate" TYPE="datetime">
</PROPERTY>
[..]
<CLASS NAME="Linux_ReiserFileSystem" SUPERCLASS="CIM_UnixLocalFileSystem">
<PROPERTY NAME="FSReservedCapacity" TYPE="uint64">
</PROPERTY>
<PROPERTY NAME="TotalInodes" TYPE="uint64">
</PROPERTY>
<PROPERTY NAME="FreeInodes" TYPE="uint64">
</PROPERTY>
<PROPERTY NAME="ResizeIncrement" TYPE="uint64">
<VALUE>0</VALUE>
</PROPERTY>
<PROPERTY NAME="IsFixedSize" TYPE="uint16">
<VALUE>0</VALUE>
</PROPERTY>
[..]
The -dx option shows you the actual XML send to SFCB by wbemcli as well as the actual
XML received. In the above example, the rst of many returned classes was CIM_ResourcePool
followed by Linux_ReiserFileSystem . Similar entries will appear for all of the other registered
classes.
If you omit the -dx option, wbemcli will display only a compact representation of the returned
data:
497 Command Line CIM Client: wbemcli SUSE Linux Enterp… 11 SP4
PoolID=,Primordial=,Capacity=,Reserved=,ResourceType=, \
OtherResourceType=,ResourceSubType=, \AllocationUnits=
localhost:5988/root/cimv2:Linux_ReiserFileSystem FSReservedCapacity=, \
TotalInodes=,FreeInodes=,ResizeIncrement=,IsFixedSize=,NumberOfFiles=, \
OtherPersistenceType=,PersistenceType=,FileSystemType=,ClusterSize=, \
MaxFileNameLength=,CodeSet=,CasePreserved=,CaseSensitive=, \
CompressionMethod=,EncryptionMethod=,ReadOnly=,AvailableSpace=, \
FileSystemSize=,BlockSize=,Root=,Name=,CreationClassName=,CSName=, \
CSCreationClassName=,Generation=,ElementName=,Description=,Caption=, \
InstanceID=,InstallDate=,OperationalStatus=,StatusDescriptions=, \
Status=,HealthState=,PrimaryStatus=,DetailedStatus=,OperatingStatus= \
,CommunicationStatus=,EnabledState=,OtherEnabledState=,RequestedState= \
,EnabledDefault=,TimeOfLastStateChange=,AvailableRequestedStates=, \
TransitioningToState=,PercentageSpaceUse=
[..]
http://www.dmtf.org
Distributed Management Task Force Web site
http://www.dmtf.org/standards/wbem/
Web-Based Enterprise Management (WBEM) Web site
http://www.dmtf.org/standards/cim/
Common Information Model (CIM) Web site
SUSE® Linux Enterprise Server comes with various sources of information and doc-
umentation, many of which are already integrated into your installed system.
Documentation in /usr/share/doc
This traditional help directory holds various documentation les and release notes for your
system. It contains also information of installed packages in the subdirectory packages .
Find more detailed information in Section 35.1, “Documentation Directory”.
35.1.2 HOWTOs
If the howto package is installed on your system, /usr/share/doc also holds the howto sub-
directory, where you nd additional documentation for many tasks relating to the setup and
operation of Linux software.
BUGS
Known bugs or malfunctions. Might also contain a link to a Bugzilla Web page where you
can search all bugs.
CHANGES ,
ChangeLog
Summary of changes from version to version. Usually interesting for developers, because
it is very detailed.
COPYING ,
LICENSE
Licensing information.
FAQ
Question and answers collected from mailing lists or newsgroups.
INSTALL
How to install this package on your system. As the package is already installed by the time
you get to read this le, you can safely ignore the contents of this le.
README , README.*
General information on the software. For example, for what purpose and how to use it.
TODO
Things that are not implemented yet, but probably will be in the future.
MANIFEST
List of les with a brief summary.
NEWS
Description of what is new in this version.
and Page ↓ . Move between the beginning and the end of a document with Home and End . End
this viewing mode by pressing Q . Learn more about the man command itself with man man .
Man pages are sorted in categories as shown in Table 35.1, “Man Pages—Categories and Descriptions”
(taken from the man page for man itself).
Number Description
6 Games
Each man page consists of several parts labeled NAME , SYNOPSIS , DESCRIPTION , SEE ALSO ,
LICENSING , and AUTHOR . There may be additional sections available depending on the type
of command.
and Page ↓ but only Space and <— will take you also to the previous or subsequent node.
Press Q to end the viewing mode. Not every man page comes with an info page and vice versa.
Novell Forums
There are several forums where you can dive in on discussions about Novell products. See
http://forums.novell.com/ for a list.
Cool Solutions
An online community, which offers articles, tips, Q and A, and free tools to download:
http://www.novell.com/communities/coolsolutions
KDE Documentation
Find documentation for many aspects of KDE suitable for users and administrators at http://
www.kde.org/documentation/ .
GNOME Documentation
You may also want to try general-purpose search engines. For example, use search terms Linux
CD-RW help or OpenOffice file conversion problem if you have trouble with burning CDs
or LibreOffice le conversion.
This chapter describes a range of potential problems and their solutions. Even if your situation
is not precisely listed here, there may be one similar enough to offer hints to the solution of
your problem.
TABLE 36.1: LOG FILES
Apart from log les, your machine also supplies you with information about the running system.
See Table 36.2: System Information With the /proc File System
File Description
Apart from the /proc le system, the Linux kernel exports information with the sysfs module,
an in-memory le system. This module represents kernel objects, their attributes and relation-
ships. For more information about sysfs , see the context of udev in Chapter 15, Dynamic Kernel
Device Management with udev. Table 36.3 contains an overview of the most common directories
under /sys .
File Description
Linux comes with a number of tools for system analysis and monitoring. See Book “System Analy-
sis and Tuning Guide”, Chapter 2 “System Monitoring Utilities” for a selection of the most important
ones used in system diagnostics.
Each of the following scenarios begins with a header describing the problem followed by a
paragraph or two offering suggested solutions, available references for more detailed solutions,
and cross-references to other scenarios that are related.
If you encounter any problems using the SUSE Linux Enterprise Server installation media, check
the integrity of your installation media with Software Media Check. Media problems are more
probable with the media you burn yourself. To check the SUSE Linux Enterprise Server medium,
insert it into the drive and click Start Check in the Media Check screen of YaST. This may take
several minutes. If errors are detected, do not use this medium for installation.
Display detected hardware and technical data using Hardware Hardware Information. Click any
node of the tree for more information about a device. This module is especially useful, when
submitting a support request for which you need information about your hardware.
Save the displayed hardware information to a le by clicking Save to File. Select the desired
directory and filename then click Save to create the le.
On some older computers, there is no bootable DVD drive available, but there is a floppy disk
drive present. To install on such a system, create boot disks and boot your system with them.
The boot disks include the loader called SYSLINUX and the program linuxrc. SYSLINUX enables
the selection of a kernel during the boot procedure and the specification of any parameters
needed for the hardware used. The program linuxrc supports the loading of kernel modules for
your hardware and subsequently starts the installation.
When booting from a boot disk, the boot procedure is initiated by the boot loader SYSLINUX
(package syslinux ). When the system is booted, SYSLINUX runs a minimum hardware detec-
tion that mainly consists of the following steps:
1. The program checks if the BIOS provides VESA 2.0–compliant framebuffer support and
boots the kernel accordingly.
3. The rst block of the rst hard disk (MBR) is read to map BIOS IDs to Linux device names
during the boot loader configuration. The program attempts to read the block by means
of the the lba32 functions of the BIOS to determine if the BIOS supports these functions.
If you keep Shift pressed when SYSLINUX starts, all these steps are skipped. For troubleshoot-
ing purposes, insert the line
verbose 1
in syslinux.cfg for the boot loader to display which action is currently being performed.
If the machine does not boot from the floppy disk, you may need to change the boot sequence
in the BIOS to A,C,CDROM .
1. Enter the BIOS using the proper key as announced by the boot routines and wait for the
BIOS screen to appear.
2. To change the boot sequence in an AWARD BIOS, look for the BIOS FEATURES SETUP
entry. Other manufacturers may have a different name for this, such as ADVANCED CMOS
SETUP. When you have found the entry, select it and confirm with Enter .
3. In the screen that opens, look for a subentry called BOOT SEQUENCE or BOOT ORDER.
The boot sequence looks something like C,A or A,C . In the former case, the machine rst
searches the hard disk (C) then the floppy drive (A) to nd a bootable medium. Change
the settings by pressing PgUp or PgDown until the sequence is A,CDROM,C .
4. Leave the BIOS setup screen by pressing Esc . To save the changes, select SAVE & EXIT
SETUP, or press F10 . To confirm that your settings should be saved, press Y .
513 Booting from Installation Media Fails SUSE Linux Enterp… 11 SP4
PROCEDURE 36.2: CHANGING THE BOOT SEQUENCE IN A SCSI BIOS (ADAPTEC HOST ADAPTER)
2. Select Disk Utilities. The connected hardware components are now displayed.
Make note of the SCSI ID of your DVD drive.
4. Open Configure Adapter Settings. Under Additional Options, select Boot Device Options and
press Enter .
6. Press Esc twice to return to the start screen of the SCSI BIOS.
7. Exit this screen and confirm with Yes to boot the computer.
Regardless of what language and keyboard layout your final installation will be using, most
BIOS configurations use the US keyboard layout as depicted in the following figure:
~ ! @ # $ % ^ & * ( ) _ + |
- <--
` 1 2 3 4 5 6 7 8 9 0 = \
Tab Q W E R T Y U I O P { }
[ ]
Caps A S D F G H J K L : "
Lock ; ' Enter
Shift Z X C V B N M < > ? Shift
, . /
1. With the DVD still in the drive, reboot the machine with Ctrl – Alt – Del or using the
hardware reset button.
2. When the boot screen appears, press F5 , use the arrow keys of your keyboard to navigate
to No ACPI and press Enter to launch the boot and installation process. This option
disables the support for ACPI power management techniques.
3. Proceed with the installation as described in Book “Deployment Guide”, Chapter 6 “Installation
with YaST”.
If this fails, proceed as above, but choose Safe Settings instead. This option disables ACPI and
DMA support. Most hardware will boot with this option.
If both of these options fail, use the boot options prompt to pass any additional parameters
needed to support this type of hardware to the installation kernel. For more information about
the parameters available as boot options, refer to the kernel documentation located in /usr/
src/linux/Documentation/kernel-parameters.txt .
There are various other ACPI-related kernel parameters that can be entered at the boot prompt
prior to booting for installation:
acpi=off
This parameter disables the complete ACPI subsystem on your computer. This may be
useful if your computer cannot handle ACPI at all or if you think ACPI in your computer
causes trouble.
acpi=force
Always enable ACPI even if your computer has an old BIOS dated before the year 2000.
This parameter also enables ACPI if it is set in addition to acpi=off .
acpi=noirq
Do not use ACPI for IRQ routing.
acpi=ht
acpi=strict
Be less tolerant of platforms that are not strictly ACPI specification compliant.
pci=noacpi
Disable PCI IRQ routing of the new ACPI system.
pnpacpi=off
This option is for serial or parallel problems when your BIOS setup contains wrong inter-
rupts or ports.
notsc
Disable the time stamp counter. This option can be used to work around timing problems
on your systems. It is a recent feature, if you see regressions on your machine, especially
time related or even total hangs, this option is worth a try.
nohz=off
Disable the nohz feature. If your machine hangs, this option may help. Otherwise it is of
no use.
Once you have determined the right parameter combination, YaST automatically writes them
to the boot loader configuration to make sure that the system boots properly next time.
If unexplainable errors occur when the kernel is loaded or during the installation, select Memory
Test in the boot menu to check the memory. If Memory Test returns an error, it is usually a
hardware error.
3. Select Installation and proceed with the installation as described in Book “Deployment
Guide”, Chapter 6 “Installation with YaST”.
3. Select Installation and proceed with the installation as described in Book “Deployment
Guide”, Chapter 6 “Installation with YaST”.
PROCEDURE 36.5: VNC INSTALLATION
vnc=1 vncpassword=some_password
4. If using a browser to access the installer, launch the browser and enter the address infor-
mation provided by the installation routines on the future SUSE Linux Enterprise Server
machine and hit Enter :
http://ip_address_of_machine:5801
A dialog opens in the browser window prompting you for the VNC password. Enter it and
proceed with the installation as described in Book “Deployment Guide”, Chapter 6 “Installation
with YaST”.
Important
Installation via VNC works with any browser under any operating system, provided
Java support is enabled.
Boot Options
Unlike the graphical interface, the different boot options cannot be selected using the
cursor keys of your keyboard. The boot menu of the text mode boot screen offers some
keywords to enter at the boot prompt. These keywords map to the options offered in the
graphical version. Enter your choice and hit Enter to launch the boot process.
Screen Resolutions
Use the F keys to determine the screen resolution for installation. If you need to boot in
text mode, choose F3 .
518 Only Minimalistic Boot Screen Started SUSE Linux Enterp… 11 SP4
36.3.1 Fails to Load the GRUB Boot Loader
If the hardware is functioning properly, it is possible that the boot loader is corrupted and Linux
cannot start on the machine. In this case, it is necessary to reinstall the boot loader. To reinstall
the boot loader, proceed as follows:
4. Select a language.
7. Once in the YaST System Repair module, select Expert Tools then select Install New Boot
Loader.
BIOS Settings
Check your BIOS for references to your hard drive. GRUB may simply not be started if the
hard drive itself cannot be found with the current BIOS settings.
519 Fails to Load the GRUB Boot Loader SUSE Linux Enterp… 11 SP4
36.3.2 No Graphical Login
If the machine comes up, but does not boot into the graphical login manager, anticipate problems
either with the choice of the default runlevel or the configuration of the X Window System. To
check the runlevel configuration, log in as the root user and check whether the machine is
configured to boot into runlevel 5 (graphical desktop). A quick way to check this is to examine
the contents of /etc/inittab , as follows:
The returned line indicates that the machine's default runlevel ( initdefault ) is set to 5 and
that it should boot to the graphical desktop. If the runlevel is set to any other number, use the
YaST Runlevel Editor module to set it to 5 .
Important
Do not edit the runlevel configuration manually. Otherwise SuSEconfig (run by YaST) will
overwrite these changes on its next run. If you need to make manual changes here, disable
future SuSEconfig changes by setting CHECK_INITTAB in /etc/sysconfig/suseconfig
to no .
The network is not working. For further directions on this, turn to Section 36.5, “Network
Problems”.
DNS is not working at the moment (which prevents GNOME or KDE from working and the
system from making validated requests to secure servers). One indication that this is the
case is that the machine takes an extremely long time to respond to any action. Find more
information about this topic in Section 36.5, “Network Problems”.
If the system is configured to use Kerberos, the system's local time may have drifted past
the accepted variance with the Kerberos server time (this is typically 300 seconds). If NTP
(network time protocol) is not working properly or local NTP servers are not working,
Kerberos authentication ceases to function because it depends on common clock synchro-
nization across the network.
The home partition is encrypted. Find more information about this topic in Section 36.4.3,
“Login to Encrypted Home Partition Fails”.
2. Enter 1 at the boot prompt to make the system boot into single-user mode.
5. Boot into the full multiuser and network mode by entering telinit 5 at the command
line.
The user's home directory containing the desktop configuration les is corrupted or write
protected.
There may be problems with the X Window System authenticating this particular user,
especially if the user's home directory has been used with another Linux distribution prior
to installing the current one.
1. Check whether the user remembered his password correctly before you start debugging the
whole authentication mechanism. If the user may not remember his password correctly,
use the YaST User Management module to change the user's password. Pay attention to
the Caps Lock key and unlock it, if necessary.
2. Log in as root and check /var/log/messages for error messages of the login process
and of PAM.
522 Valid Username and Password Not Accepted SUSE Linux Enterp… 11 SP4
3. Try to log in from a console (using Ctrl – Alt – F1 ). If this is successful, the blame cannot
be put on PAM, because it is possible to authenticate this user on this machine. Try to
locate any problems with the X Window System or the desktop (GNOME or KDE). For
more information, refer to Section 36.4.4, “Login Successful but GNOME Desktop Fails” and Sec-
tion 36.4.5, “Login Successful but KDE Desktop Fails”.
4. If the user's home directory has been used with another Linux distribution, remove the
Xauthority le in the user's home. Use a console login via Ctrl – Alt – F1 and run
rm .Xauthority as this user. This should eliminate X authentication problems for this
user. Try graphical login again.
5. If graphical login still fails, do a console login with Ctrl – Alt – F1 . Try to start an X
session on another display—the rst one ( :0 ) is already in use:
startx -- :1
This should bring up a graphical screen and your desktop. If it does not, check the log
les of the X Window System ( /var/log/Xorg.displaynumber.log ) or the log le for
your desktop applications ( .xsession-errors in the user's home directory) for any ir-
regularities.
6. If the desktop could not start because of corrupt configuration les, proceed with Sec-
tion 36.4.4, “Login Successful but GNOME Desktop Fails” or Section 36.4.5, “Login Successful but
KDE Desktop Fails”.
The following are some common reasons why network authentication for a particular user may
fail on a specific machine:
The username exists in the machine's local authentication les and is also provided by a
network authentication system, causing conflicts.
The home directory exists but is corrupt or unavailable. Perhaps it is write protected or is
on a server that is inaccessible at the moment.
The user does not have permission to log in to that particular host in the authentication
system.
The machine has changed hostnames, for whatever reason, and the user does not have
permission to log in to that host.
523 Valid Username and Password Not Accepted SUSE Linux Enterp… 11 SP4
The machine cannot reach the authentication server or directory server that contains that
user's information.
There may be problems with the X Window System authenticating this particular user, es-
pecially if the user's home has been used with another Linux distribution prior to installing
the current one.
To locate the cause of the login failures with network authentication, proceed as follows:
1. Check whether the user remembered their password correctly before you start debugging
the whole authentication mechanism.
2. Determine the directory server which the machine relies on for authentication and make
sure that it is up and running and properly communicating with the other machines.
3. Determine that the user's username and password work on other machines to make sure
that his authentication data exists and is properly distributed.
4. See if another user can log in to the misbehaving machine. If another user can log in
without difficulty or if root can log in, log in and examine the /var/log/messages le.
Locate the time stamps that correspond to the login attempts and determine if PAM has
produced any error messages.
5. Try to log in from a console (using Ctrl – Alt – F1 ). If this is successful, the problem
is not with PAM or the directory server on which the user's home is hosted, because it
is possible to authenticate this user on this machine. Try to locate any problems with
the X Window System or the desktop (GNOME or KDE). For more information, refer to
Section 36.4.4, “Login Successful but GNOME Desktop Fails” and Section 36.4.5, “Login Successful
but KDE Desktop Fails”.
6. If the user's home directory has been used with another Linux distribution, remove the
Xauthority le in the user's home. Use a console login via Ctrl – Alt – F1 and run
rm .Xauthority as this user. This should eliminate X authentication problems for this
user. Try graphical login again.
7. If graphical login still fails, do a console login with Ctrl – Alt – F1 . Try to start an X
session on another display—the rst one ( :0 ) is already in use:
startx -- :1
524 Valid Username and Password Not Accepted SUSE Linux Enterp… 11 SP4
This should bring up a graphical screen and your desktop. If it does not, check the log
les of the X Window System ( /var/log/Xorg.displaynumber.log ) or the log le for
your desktop applications ( .xsession-errors in the user's home directory) for any ir-
regularities.
8. If the desktop could not start because of corrupt configuration les, proceed with Sec-
tion 36.4.4, “Login Successful but GNOME Desktop Fails” or Section 36.4.5, “Login Successful but
KDE Desktop Fails”.
It is recommended to use an encrypted home partition for laptops. If you cannot log in to your
laptop, the reason is usually simple: your partition could not be unlocked.
During the boot time, you have to enter the passphrase to unlock your encrypted partition. If
you do not enter it, the boot process continues, leaving the partition locked.
To unlock your encrypted partition, proceed as follows:
2. Become root .
/etc/init.d/boot.crypto restart
5. Exit the text console and switch back to the login screen with Alt – F7 .
6. Log in as usual.
525 Login to Encrypted Home Partition Fails SUSE Linux Enterp… 11 SP4
quickly by simply moving the user's GNOME configuration directory to a new location, which
causes GNOME to initialize a new one. Although the user is forced to reconfigure GNOME, no
data is lost.
mv .gconf .gconf-ORIG-RECOVER
mv .gnome2 .gnome2-ORIG-RECOVER
4. Log out.
6. Recover your individual application configuration data (including the Evolution e-mail
client data) by copying the ~/.gconf-ORIG-RECOVER/apps/ directory back into the new
~/.gconf directory as follows:
cp -a .gconf-ORIG-RECOVER/apps .gconf/
If this causes the login problems, attempt to recover only the critical application data and
reconfigure the remainder of the applications.
Replace user with your username. Removing these two directories just removes the corrupted
cache les. No real data is harmed using this procedure.
526 Login Successful but KDE Desktop Fails SUSE Linux Enterp… 11 SP4
Corrupted desktop configuration les can always be replaced with the initial configuration les.
If you want to recover the user's adjustments, carefully copy them back from their temporary
location after the configuration has been restored, using the default configuration values.
To replace a corrupted desktop configuration with the initial configuration values, proceed as
follows:
3. Move the KDE configuration directory and the .skel les to a temporary location:
mv .kde .kde-ORIG-RECOVER
mv .skel .skel-ORIG-RECOVER
mv .kde4 .kde4-ORIG-RECOVER
mv .skel .skel-ORIG-RECOVER
4. Log out.
5. Log in again.
6. After the desktop has started successfully, copy the user's own configurations back into
place:
cp -a KDEDIR/share .kde/share
Important
If the user's own adjustments caused the login to fail and continue to do so, repeat
the procedure as described above, but do not copy the .kde/share directory.
527 Login Successful but KDE Desktop Fails SUSE Linux Enterp… 11 SP4
36.5 Network Problems
Many problems of your system may be network-related, even though they do not seem to be
at rst. For example, the reason for a system not allowing users to log in may be a network
problem of some kind. This section introduces a simple checklist you can apply to identify the
cause of any network problem encountered.
1. If you use an ethernet connection, check the hardware rst. Make sure that your network
cable is properly plugged into your computer and router (or hub, etc.). The control lights
next to your ethernet connector are normally both be active.
If the connection fails, check whether your network cable works with another machine.
If it does, your network card causes the failure. If hubs or switches are included in your
network setup, they may be faulty, as well.
2. If using a wireless connection, check whether the wireless link can be established by other
machines. If not, contact the wireless network's administrator.
3. Once you have checked your basic network connectivity, try to nd out which service is
not responding. Gather the address information of all network servers needed in your set-
up. Either look them up in the appropriate YaST module or ask your system administrator.
The following list gives some of the typical network servers involved in a setup together
with the symptoms of an outage.
Kerberos (Authentication)
Authentication will not work and login to any machine fails.
4. Check whether the network servers are running and whether your network setup allows
you to establish a connection:
Important
The debugging procedure described below only applies to a simple network serv-
er/client setup that does not involve any internal routing. It assumes both server
and client are members of the same subnet without the need for additional routing.
a. Use ping IP address or hostname (replace hostname with the hostname of the
server) to check whether each one of them is up and responding to the network. If
this command is successful, it tells you that the host you were looking for is up and
running and that the name service for your network is configured correctly.
b. Use host hostname to check whether the hostname of the server you are trying to
connect to is properly translated into an IP address and vice versa. If this command
returns the IP address of this host, the name service is up and running. If the host
command fails, check all network configuration les relating to name and address
resolution on your host:
/etc/resolv.conf
This le is used to keep track of the name server and domain you are currently
using. It can be modified manually or automatically adjusted by YaST or DHCP.
Automatic adjustment is preferable. However, make sure that this le has the
following structure and all network addresses and domain names are correct:
search fully_qualified_domain_name
nameserver ipaddress_of_nameserver
This le can contain more than one name server address, but at least one of
them must be correct to provide name resolution to your host. If needed, adjust
this le using the YaST Network Setting module (Hostname/DNS tab).
If your network connection is handled via DHCP, enable DHCP to change host-
name and name service information by selecting Change Hostname via DHCP
and Update Name Servers and Search List via DHCP in the YaST DNS and Host-
name module.
/etc/nsswitch.conf
This le tells Linux where to look for name service information. It should look
like this:
...
hosts: files dns
The dns entry is vital. It tells Linux to use an external name server. Normally,
these entries are automatically managed by YaST, but it would be prudent to
check.
If all the relevant entries on the host are correct, let your system administra-
tor check the DNS server configuration for the correct zone information. For
detailed information about DNS, refer to Chapter 25, The Domain Name System.
If you have made sure that the DNS configuration of your host and the DNS
server are correct, proceed with checking the configuration of your network
and network device.
c. If your system cannot establish a connection to a network server and you have ex-
cluded name service problems from the list of possible culprits, check the configu-
ration of your network card.
Use the command ifconfig network_device (executed as root ) to check
whether this device was properly configured. Make sure that both inet address
and Mask are configured correctly. An error in the IP address or a missing bit in
your network mask would render your network configuration unusable. If necessary,
perform this check on the server as well.
d. If the name service and network hardware are properly configured and running,
but some external network connections still get long time-outs or fail entirely, use
traceroute fully_qualified_domain_name (executed as root ) to track the net-
work route these requests are taking. This command lists any gateway (hop) that a
request from your machine passes on its way to its destination. It lists the response
time of each hop and whether this hop is reachable at all. Use a combination of
traceroute and ping to track down the culprit and let the administrators know.
Once you have identified the cause of your network trouble, you can resolve it yourself (if the
problem is located on your machine) or let the system administrators of your network know
about your findings so they can reconfigure the services or repair the necessary systems.
rcnetwork restart -o nm
3. Open a Web page, for example, http://www.opensuse.org as normal user to see, if you
can connect.
2. Select your source device. Typically this is something like /dev/sda (labeled as SOURCE ).
If you only need a partition to backup, replace the SOURCE placeholder with your respective
partition. In this case, your image le can lie on the same hard disk, but on a different partition.
System backups can be easily managed using the YaST System Backup module:
2. Create a backup profile holding all details needed for the backup, filename of the archive
le, scope, and type of the backup:
c. Enter the path to the location of the backup if you want to keep a local backup. For
your backup to be archived on a network server (via NFS), enter the IP address or
name of the server and the directory that should hold your archive.
e. Determine the backup options to use, such as whether les not belonging to any
package should be backed up and whether a list of les should be displayed prior
to creating the archive. Also determine whether changed les should be identified
using the time-consuming MD5 mechanism.
Use Expert to enter a dialog for the backup of entire hard disk areas. Currently, this
option only applies to the Ext2 le system.
3. Once you have finished the profile settings, you can start the backup right away with
Create Backup or configure automatic backup. It is also possible to create other profiles
tailored for various other purposes.
4. Determine the backup start time. These settings depend on the backup frequency selected.
5. Decide whether to keep old backups and how many should be kept. To receive an auto-
matically generated status message of the backup process, check Send Summary Mail to
User root.
6. Click OK to apply your settings and have the rst backup start at the time specified.
2. Enter the location of the backup le. This could be a local le, a network mounted le, or
a le on a removable device, such as a floppy or a DVD. Then click Next.
The following dialog displays a summary of the archive properties, such as the filename,
date of creation, type of backup, and optional comments.
3. Review the archived content by clicking Archive Content. Clicking OK returns you to the
Archive Properties dialog.
4. Expert Options opens a dialog in which to ne-tune the restore process. Return to the
Archive Properties dialog by clicking OK.
6. After you click Accept, the backup is restored. Click Finish to leave the module after the
restore process is completed.
There are several reasons why a system could fail to come up and run properly. A corrupted
le system following a system crash, corrupted configuration les, or a corrupted boot loader
configuration are the most common ones.
SUSE Linux Enterprise Server offers two different methods to resolve these situations. You can
either use the YaST System Repair functionality or boot the rescue system. The following sections
cover both types of system repair methods.
Before launching the YaST System Repair module, determine in which mode to run it to best t
your needs. Depending on the severity and cause of your system failure (and your expertise),
there are three different modes to choose from:
Automatic Repair
If your system failed due to an unknown cause and you basically do not know which part of
the system is to blame for the failure, use Automatic Repair. An extensive automated check
will be performed on all components of your installed system. For a detailed description
of this procedure, refer to Section 36.6.4.1.1, “Automatic Repair”.
Customized Repair
Expert Tools
If you already have a clear idea of what component failed and how this should be xed,
you can skip the analysis runs and directly apply the tools necessary for the repair of the
relevant component. For details, refer to Section 36.6.4.1.3, “Expert Tools”.
Choose one of the repair modes as described above and proceed with the system repair as out-
lined in the following sections.
To start the automatic repair mode of YaST System Repair, proceed as follows:
1. Insert the installation medium of SUSE Linux Enterprise Server into your DVD drive.
The following main test runs are performed with every run. They contain, in turn, a num-
ber of individual subtests:
6. Whenever an error is encountered, the procedure stops and a dialog opens outlining the
details and possible solutions.
Read the screen messages carefully before accepting the proposed x. If you decide to
decline a proposed solution, your system remains unchanged.
7. After the repair process has been terminated successfully, click OK and Finish and remove
the installation media. The system automatically reboots.
To launch the Customized Repair mode and selectively check certain components of your
installed system, proceed as follows:
1. Insert the installation medium of SUSE Linux Enterprise Server into your DVD drive.
7. After the repair process has been terminated successfully, click OK and Finish and remove
the installation media. The system automatically reboots.
If you are knowledgeable with SUSE Linux Enterprise Server and already have a very clear idea of
what needs to be repaired in your system, directly apply the tools, skipping the system analysis.
To make use of the Expert Tools feature of the YaST System Repair module, proceed as follows:
1. Insert the installation medium of SUSE Linux Enterprise Server into your DVD drive.
6. After the repair process has been terminated successfully, click OK and Finish and remove
the installation media. The system automatically reboots.
The Expert Tools provides the following options to repair your faulty system:
SUSE Linux Enterprise Server contains a rescue system. The rescue system is a small Linux system
that can be loaded into a RAM disk and mounted as root le system, allowing you to access
your Linux partitions from the outside. Using the rescue system, you can recover or modify any
important aspect of your system:
Check the le system for defects and start automatic repair processes.
Resize partitions using the parted command. Find more information about this tool at the
GNU Parted website http://www.gnu.org/software/parted/parted.html .
3. At the boot screen, press F4 and choose DVD-ROM. Then choose Rescue System from the
main menu.
If your hardware setup does not include a DVD drive, you can boot the rescue system
from a network source. The following example applies to a remote boot scenario—if using
another boot medium, such as a DVD, modify the info le accordingly and boot as you
would for a normal installation.
1. Enter the configuration of your PXE boot setup and add the lines install=proto-
col://instsource and rescue=1 . If you need to start the repair system, use repair=1
instead. As with a normal installation, protocol stands for any of the supported network
protocols (NFS, HTTP, FTP, etc.) and instsource for the path to your network installa-
tion source.
2. Boot the system using “Wake on LAN”, as described in Book “Deployment Guide”, Chapter 14
“Remote Installation”, Section 14.3 “Preparing the Boot of the Target System”, Section 14.3.7 “Wake
on LAN”.
Once you have entered the rescue system, you can make use of the virtual consoles that can be
reached with Alt – F1 to Alt – F6 .
A shell and many other useful utilities, such as the mount program, are available in the /bin
directory. The sbin directory contains important le and network utilities for reviewing and
repairing the le system. This directory also contains the most important binaries for system
maintenance, such as fdisk, mkfs, mkswap, mount, mount, init, and shutdown, and ifconfig, ip,
route, and netstat for maintaining the network. The directory /usr/bin contains the vi editor,
nd, less, and ssh.
To see the system messages, either use the command dmesg or view the le /var/log/mes-
sages .
As an example for a configuration that might be xed using the rescue system, imagine you
have a broken configuration le that prevents the system from booting properly. You can x
this using the rescue system.
1. Start the rescue system using one of the methods described above.
2. To mount a root le system located under /dev/sda6 to the rescue system, use the fol-
lowing command:
cd /mnt
4. Open the problematic configuration le in the vi editor. Adjust and save the configuration.
umount /mnt
Generally, le systems cannot be repaired on a running system. If you encounter serious prob-
lems, you may not even be able to mount your root le system and the system boot may end
with a “kernel panic”. In this case, the only way is to repair the system from the outside. It is
strongly recommended to use the YaST System Repair for this task (see Section 36.6.4.1, “Using
YaST System Repair” for details). However, if you need to do a manual le system check or repair,
boot the rescue system. It contains the utilities to check and repair the btrfs , ext2 , ext3 ,
ext4 , reiserfs , xfs , dosfs , and vfat le systems.
If you need to access the installed system from the rescue system, you need to do this in a
change root environment. For example, to modify the boot loader configuration, or to execute
a hardware configuration utility.
To set up a change root environment based on the installed system, proceed as follows:
1. First mount the root partition from the installed system and the device le system (change
the device name to your current settings):
chroot /mnt
mount /proc
mount /sys
mount -a
5. Now you have access to the installed system. Before rebooting the system, unmount the
partitions with umount -a and leave the “change root” environment with exit .
Warning: Limitations
Although you have full access to the les and applications of the installed system, there
are some limitations. The kernel that is running is the one that was booted with the rescue
system, not with the change root environment. It only supports essential hardware and it
is not possible to add kernel modules from the installed system unless the kernel versions
are exactly the same. Always check the version of the currently running (rescue) kernel
with uname -r and then nd out if a matching subdirectory exists in the /lib/modules
directory in the change root environment. If yes, you can use the installed modules, oth-
erwise you need to supply their correct versions on other media, such as a USB stick. Most
often the rescue kernel version differs from the installed one — then you cannot simply
access a sound card, for example. It is also not possible to start a graphical user interface.
Sometimes a system cannot boot because the boot loader configuration is corrupted. The start-
up routines cannot, for example, translate physical drives to the actual locations in the Linux
le system without a working boot loader.
To check the boot loader configuration and reinstall the boot loader, proceed as follows:
1. Perform the necessary steps to access the installed system as described in Section 36.6.4.2.3,
“Accessing the Installed System”.
2. Check whether the following les are correctly configured according to the GRUB config-
uration principles outlined in Chapter 11, The Boot Loader GRUB and apply fixes if necessary.
/etc/grub.conf
/boot/grub/device.map
/boot/grub/menu.lst
/etc/sysconfig/bootloader
4. Unmount the partitions, log out from the “change root” environment, and reboot the sys-
tem:
umount -a
exit
reboot
A kernel update may introduce a new bug which can impact the operation of your system. For
example a driver for a piece of hardware in your system may be faulty, which prevents you from
accessing and using it. In this case, revert to the last working kernel (if available on the system)
or install the original kernel from the installation media.
multiversion.kernels = latest,latest-1,running
A similar case is when you need to reinstall or update a broken driver for a device not supported
by SUSE Linux Enterprise Server. For example when a hardware vendor uses a specific device,
such as a hardware RAID controller, which needs a binary driver to be recognized by the op-
erating system. The vendor typically releases a Driver Update Disk with the xed or updated
version of the required driver.
In both cases you need to access the installed system in the rescue mode and x the kernel
related problem, otherwise the system may fail to boot correctly:
2. If you are recovering after a faulty kernel update, skip this step. If you need to use a driver
update disk (DUD), press F6 to load the driver update after the boot menu appears, and
choose the path or URL to the driver update and confirm with Yes.
3. Choose Rescue System from the boot menu and press Enter . If you chose to use DUD, you
will be asked to specify where the driver update is stored.
5. Manually mount the target system and “change root” into the new environment. For more
information, see Section 36.6.4.2.3, “Accessing the Installed System”.
6. If using DUD, install/reinstall/update the faulty device driver package. Always make sure
the installed kernel version exactly matches the version of the driver you are installing.
a. Identify your DVD device with hwinfo --cdrom and mount it with mount /dev/
sr0 /mnt .
b. Navigate to the directory where your kernel les are stored on the DVD, for example
cd /mnt/suse/x86_64/ .
d. After the installation finishes, check that a new menu entry relevant for the new-
ly installed kernel was added to the boot loader configuration le ( /boot/grub/
menu.lst for grub ).
7. Update configuration les and reinitialize the boot loader if needed. For more information,
see Section 36.6.4.2.4, “Modifying and Reinstalling the Boot Loader”.
8. Remove any bootable media from the system drive and reboot.
546 IBM System z: Using initrd as a Rescue System SUSE Linux Enterp… 11 SP4
Data Available”. Additionally, you need the channel number of the device and the partition
number within the device that contains the root le system of the SUSE Linux Enterprise
Server installation.
First, IPL the SUSE Linux Enterprise Server for IBM System z installation system as described in
Book “Deployment Guide”, Chapter 4 “Installation on IBM System z”, Section 4.2 “Preparing for Installa-
tion”. A list of choices for the network adapter to use is then presented.
Select Start Installation or System then Start Rescue System to start the rescue system. Depending
on the installation environment, you now must specify the parameters for the network adapter
and the installation source. The rescue system is loaded and the following login prompt is shown
at the end:
Rescue login:
PROCEDURE 36.8: CONFIGURING DASDS
dasd_configure 0.0.0150 1 0
0.0.0150 is the channel to which the DASD is connected. The 1 means activate the disk
(a 0 at this place would deactivate the disk). The 0 stands for “no DIAG mode” for the
disk (a 1 here would enable DAIG access to the disk).
2. Now the DASD is online (check with cat /proc/partitions ) and can used for subse-
quent commands.
1. To configure a zFCP disk, it is necessary to rst configure the zFCP adapter. Do this with
the following command:
zfcp_host_configure 0.0.4000 1
2. After the adapter is activated, a disk can be configured. Do this with the following com-
mand:
3. Now the zFCP disk is online (check with cat /proc/partitions ) and can used for sub-
sequent commands.
By just issuing the command mount , it is possible to check whether the le system could be
mounted correctly.
sh-2.05b# zipl
building bootmap : /boot/zipl/bootmap
adding Kernel Image : /boot/kernel/image located at 0x00010000
adding Ramdisk : /boot/initrd located at 0x00800000
adding Parmline : /boot/zipl/parmfile located at 0x00001000
Bootloader for ECKD type devices with z/OS compatible layout installed.
Syncing disks....
...done
Finally, halt the rescue system with the halt command. The SUSE Linux Enterprise Server
system can now be IPLed as described in Book “Deployment Guide”, Chapter 6 “Installation with
YaST”, Section 6.15 “Performing the Installation”, Section 6.15.1 “IBM System z: IPLing the Installed System”.
549 Changing to the Mounted File System SUSE Linux Enterp… 11 SP4
A An Example Network
This example network is used across all network-related chapters of the SUSE® Linux Enterprise
Server documentation.
The "Invariant Sections" are certain Secondary Examples of suitable formats for Transparent
Sections whose titles are designated, as being copies include plain ASCII without markup,
those of Invariant Sections, in the notice that Texinfo input format, LaTeX input format,
says that the Document is released under this SGML or XML using a publicly available
License. If a section does not t the above defi- DTD, and standard-conforming simple HTML,
nition of Secondary then it is not allowed to be PostScript or PDF designed for human modifi-
designated as Invariant. The Document may cation. Examples of transparent image formats
contain zero Invariant Sections. If the Docu- include PNG, XCF and JPG. Opaque formats
ment does not identify any Invariant Sections include proprietary formats that can be read
then there are none. and edited only by proprietary word proces-
sors, SGML or XML for which the DTD and/
The "Cover Texts" are certain short passages
or processing tools are not generally available,
of text that are listed, as Front-Cover Texts or
and the machine-generated HTML, PostScript
Back-Cover Texts, in the notice that says that
or PDF produced by some word processors for
the Document is released under this License. A
output purposes only.
Front-Cover Text may be at most 5 words, and
a Back-Cover Text may be at most 25 words. The "Title Page" means, for a printed book, the
title page itself, plus such following pages as
A "Transparent" copy of the Document means
are needed to hold, legibly, the material this
a machine-readable copy, represented in a for-
License requires to appear in the title page. For
mat whose specification is available to the
works in formats which do not have any title
general public, that is suitable for revising
page as such, "Title Page" means the text near
the document straightforwardly with gener-