Novell LINUX ENTERPRISE SERVER 11 - ADMINISTRATION, SUSE LINUX ENTERPRISE SERVER 11 Administration Manual
Page 1
SUSE Linux Enterprise
Server
www.novell.com11
March23,2009 Administration Guide
Page 2
Administration Guide
All content is copyright © 2006- 2009 Novell, Inc.
Legal Notice
This manual is protected under Novell intellectual property rights. By reproducing, duplicating or
distributing this manual you explicitly agree to conform to the terms and conditions of this license
agreement.
This manual may be freely reproduced, duplicated and distributed either as such or as part of a bundled
package in electronic and/or printed format, provided however that the following conditions are fullled:
That this copyright notice and the names of authors and contributors appear clearly and distinctively
on all reproduced, duplicated and distributed copies. That this manual, specically for the printed
format, is reproduced and/or distributed for noncommercial use only. The express authorization of
Novell, Inc must be obtained prior to any other use of any manual or part thereof.
For Novell trademarks, see the Novell Trademark and Service Mark list http://www.novell
.com/company/legal/trademarks/tmlist.html. * Linux is a registered trademark of
Linus Torvalds. All other third party trademarks are the property of their respective owners. A trademark
symbol (®, ™ etc.) denotes a 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 Novell, Inc., SUSE LINUX Products GmbH, the authors,
nor the translators shall be held liable for possible errors or the consequences thereof.
Page 3
Contents
About This Guide xi
Part I Support and Common Tasks 1
1 YaST Online Update 3
1.1 Installing Patches Manually Using the Qt Interface . . . . . . . . . . . . 4
1.2 Installing Patches Manually Using the gtk Interface . . . . . . . . . . . 6
1.3 Automatic Online Update . . . . . . . . . . . . . . . . . . . . . . 7
2 Gathering System Information for Support 9
2.1 Novell Support Link Overview . . . . . . . . . . . . . . . . . . . . 9
2.2 Using Supportcong . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Submitting Information to Novell . . . . . . . . . . . . . . . . . . 12
2.4 For More Information . . . . . . . . . . . . . . . . . . . . . . . 14
3 YaST in Text Mode 15
3.1 Navigation in Modules . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Restriction of Key Combinations . . . . . . . . . . . . . . . . . . . 17
3.3 YaST Command Line Options . . . . . . . . . . . . . . . . . . . . 18
4 Managing Software with Command Line Tools 21
4.1 Using Zypper . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2 RPM—the Package Manager . . . . . . . . . . . . . . . . . . . . 26
Page 4
5 Bash and Bash Scripts 39
5.1 What is “The Shell”? . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2 Writing Shell Scripts . . . . . . . . . . . . . . . . . . . . . . . . 45
5.3 Redirecting Command Events . . . . . . . . . . . . . . . . . . . . 46
5.4 Using Aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.5 Using Variables in Bash . . . . . . . . . . . . . . . . . . . . . . 47
5.6 Grouping And Combining Commands . . . . . . . . . . . . . . . . 50
5.7 Working with Common Flow Constructs . . . . . . . . . . . . . . . 51
5.8 For More Information . . . . . . . . . . . . . . . . . . . . . . . 52
Part II System 53
6 32-Bit and 64-Bit Applications in a 64-Bit System Environment 55
6.1 Runtime Support . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.2 Software Development . . . . . . . . . . . . . . . . . . . . . . 57
6.3 Software Compilation on Biarch Platforms . . . . . . . . . . . . . . 57
6.4 Kernel Specications . . . . . . . . . . . . . . . . . . . . . . . 59
7 Booting and Conguring a Linux System 61
7.1 The Linux Boot Process . . . . . . . . . . . . . . . . . . . . . . 61
7.2 The init Process . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.3 System Conguration via /etc/syscong . . . . . . . . . . . . . . . 74
8 The Boot Loader GRUB 77
8.1 Booting with GRUB . . . . . . . . . . . . . . . . . . . . . . . . 78
8.2 Conguring the Boot Loader with YaST . . . . . . . . . . . . . . . . 87
8.3 Uninstalling the Linux Boot Loader . . . . . . . . . . . . . . . . . 93
8.4 Creating Boot CDs . . . . . . . . . . . . . . . . . . . . . . . . 93
8.5 The Graphical SUSE Screen . . . . . . . . . . . . . . . . . . . . . 95
8.6 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . 95
8.7 For More Information . . . . . . . . . . . . . . . . . . . . . . . 97
9 Special System Features 99
9.1 Information about Special Software Packages . . . . . . . . . . . . . 99
9.2 Virtual Consoles . . . . . . . . . . . . . . . . . . . . . . . . . 106
9.3 Keyboard Mapping . . . . . . . . . . . . . . . . . . . . . . . . 107
9.4 Language and Country-Specic Settings . . . . . . . . . . . . . . . 108
Page 5
10 Printer Operation 113
10.1 The Workow of the Printing System . . . . . . . . . . . . . . . . 115
10.2 Methods and Protocols for Connecting Printers . . . . . . . . . . . . 115
10.3 Installing the Software . . . . . . . . . . . . . . . . . . . . . . 116
10.4 Network Printers . . . . . . . . . . . . . . . . . . . . . . . . . 117
10.5 Graphical Printing Interfaces . . . . . . . . . . . . . . . . . . . . 119
10.6 Printing from the Command Line . . . . . . . . . . . . . . . . . . 120
10.7 Special Features in SUSE Linux Enterprise Server . . . . . . . . . . . 120
10.8 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . 123
11 Dynamic Kernel Device Management with udev 131
11.1
The /dev Directory . . . . . . . . . . . . . . . . . . . . . . . 131
11.2 Kernel uevents and udev . . . . . . . . . . . . . . . . . . . . . 132
11.3 Drivers, Kernel Modules and Devices . . . . . . . . . . . . . . . . 132
11.4 Booting and Initial Device Setup . . . . . . . . . . . . . . . . . . 133
11.5 Monitoring the Running udev Daemon . . . . . . . . . . . . . . . 133
11.6 Inuencing Kernel Device Event Handling with udev Rules . . . . . . . 135
11.7 Persistent Device Naming . . . . . . . . . . . . . . . . . . . . . 142
11.8 Files used by udev . . . . . . . . . . . . . . . . . . . . . . . . 142
11.9 For More Information . . . . . . . . . . . . . . . . . . . . . . 143
12 The X Window System 145
12.1 Manually Conguring the X Window System . . . . . . . . . . . . . 145
12.2 Installing and Conguring Fonts . . . . . . . . . . . . . . . . . . 152
12.3 For More Information . . . . . . . . . . . . . . . . . . . . . . 158
13 Accessing File Systems with FUSE 159
13.1 Conguring FUSE . . . . . . . . . . . . . . . . . . . . . . . . 159
13.2 Mounting an NTFS Partition . . . . . . . . . . . . . . . . . . . . 159
13.3 Mounting Remote File System with SSHFS . . . . . . . . . . . . . . 160
13.4 Mounting an ISO File System . . . . . . . . . . . . . . . . . . . 161
13.5 Available FUSE Plug-ins . . . . . . . . . . . . . . . . . . . . . . 161
13.6 For More Information . . . . . . . . . . . . . . . . . . . . . . 162
Part III Mobile Computers 163
14 Mobile Computing with Linux 165
14.1 Laptops . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
14.2 Mobile Hardware . . . . . . . . . . . . . . . . . . . . . . . . 172
14.3 Cellular Phones and PDAs . . . . . . . . . . . . . . . . . . . . . 173
Page 6
14.4 For More Information . . . . . . . . . . . . . . . . . . . . . . 173
15 Power Management 175
15.1 Power Saving Functions . . . . . . . . . . . . . . . . . . . . . . 175
15.2 ACPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
15.3 Rest for the Hard Disk . . . . . . . . . . . . . . . . . . . . . . 180
15.4 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . 182
15.5 For More Information . . . . . . . . . . . . . . . . . . . . . . 184
16 Using Tablet PCs 185
16.1 Installing Tablet PC Packages . . . . . . . . . . . . . . . . . . . . 186
16.2 Conguring Your Tablet Device . . . . . . . . . . . . . . . . . . . 187
16.3 Using the Virtual Keyboard . . . . . . . . . . . . . . . . . . . . 188
16.4 Rotating Your Display . . . . . . . . . . . . . . . . . . . . . . . 189
16.5 Using Gesture Recognition . . . . . . . . . . . . . . . . . . . . 189
16.6 Taking Notes and Sketching with the Pen . . . . . . . . . . . . . . 192
16.7 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . 194
16.8 For More Information . . . . . . . . . . . . . . . . . . . . . . 195
Part IV Services 197
17 Basic Networking 199
17.1 IP Addresses and Routing . . . . . . . . . . . . . . . . . . . . . 202
17.2 IPv6—The Next Generation Internet . . . . . . . . . . . . . . . . 205
17.3 Name Resolution . . . . . . . . . . . . . . . . . . . . . . . . 214
17.4 Conguring a Network Connection with YaST . . . . . . . . . . . . 216
17.5 NetworkManager . . . . . . . . . . . . . . . . . . . . . . . . 239
17.6 Conguring a Network Connection Manually . . . . . . . . . . . . . 240
17.7 smpppd as Dial-up Assistant . . . . . . . . . . . . . . . . . . . . 255
18 Wireless Communication 259
18.1 Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . . . 259
19 SLP Services in the Network 269
19.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
19.2 Activating SLP . . . . . . . . . . . . . . . . . . . . . . . . . . 270
19.3 SLP Front-Ends in SUSE Linux Enterprise Server . . . . . . . . . . . . 270
19.4 Installation over SLP . . . . . . . . . . . . . . . . . . . . . . . 271
19.5 Providing Services via SLP . . . . . . . . . . . . . . . . . . . . . 271
Page 7
19.6 For More Information . . . . . . . . . . . . . . . . . . . . . . 272
20 Time Synchronization with NTP 273
20.1 Conguring an NTP Client with YaST . . . . . . . . . . . . . . . . 273
20.2 Manually Conguring ntp in the Network . . . . . . . . . . . . . . 277
20.3 Setting Up a Local Reference Clock . . . . . . . . . . . . . . . . . 277
20.4 Clock Synchronization to an External Time Reference (ETR) . . . . . . . 278
21 The Domain Name System 279
21.1 DNS Terminology . . . . . . . . . . . . . . . . . . . . . . . . 279
21.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
21.3 Conguration with YaST . . . . . . . . . . . . . . . . . . . . . . 280
21.4 Starting the Name Server BIND . . . . . . . . . . . . . . . . . . 290
21.5 The Conguration File /etc/named.conf . . . . . . . . . . . . . . . 291
21.6 Zone Files . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
21.7 Dynamic Update of Zone Data . . . . . . . . . . . . . . . . . . . 300
21.8 Secure Transactions . . . . . . . . . . . . . . . . . . . . . . . 300
21.9 DNS Security . . . . . . . . . . . . . . . . . . . . . . . . . . 302
21.10 For More Information . . . . . . . . . . . . . . . . . . . . . . 302
22 DHCP 303
22.1 Conguring a DHCP Server with YaST . . . . . . . . . . . . . . . . 304
22.2 DHCP Software Packages . . . . . . . . . . . . . . . . . . . . . 315
22.3 The DHCP Server dhcpd . . . . . . . . . . . . . . . . . . . . . 316
22.4 For More Information . . . . . . . . . . . . . . . . . . . . . . 319
23 Using NetworkManager 321
23.1 Use Cases for NetworkManager . . . . . . . . . . . . . . . . . . 321
23.2 Enabling NetworkManager . . . . . . . . . . . . . . . . . . . . 322
23.3 Conguring Network Connections . . . . . . . . . . . . . . . . . 323
23.4 Using KDE NetworkManager Widget . . . . . . . . . . . . . . . . 324
23.5 Using GNOME NetworkManager Applet . . . . . . . . . . . . . . . 325
23.6 NetworkManager and VPN . . . . . . . . . . . . . . . . . . . . 327
23.7 NetworkManager and Security . . . . . . . . . . . . . . . . . . . 328
23.8 Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . 329
23.9 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . 331
23.10 For More Information . . . . . . . . . . . . . . . . . . . . . . 332
24 Samba 333
24.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Page 8
24.2 Starting and Stopping Samba . . . . . . . . . . . . . . . . . . . 335
24.3 Conguring a Samba Server . . . . . . . . . . . . . . . . . . . . 335
24.4 Conguring Clients . . . . . . . . . . . . . . . . . . . . . . . . 342
24.5 Samba as Login Server . . . . . . . . . . . . . . . . . . . . . . 343
24.6 Samba Server in the Network with Active Directory . . . . . . . . . . 344
24.7 For More Information . . . . . . . . . . . . . . . . . . . . . . 345
25 Sharing File Systems with NFS 347
25.1 Installing the Required Software . . . . . . . . . . . . . . . . . . 347
25.2 Importing File Systems with YaST . . . . . . . . . . . . . . . . . . 348
25.3 Importing File Systems Manually . . . . . . . . . . . . . . . . . . 349
25.4 Exporting File Systems with YaST . . . . . . . . . . . . . . . . . . 351
25.5 Exporting File Systems Manually . . . . . . . . . . . . . . . . . . 356
25.6 NFS with Kerberos . . . . . . . . . . . . . . . . . . . . . . . . 359
25.7 For More Information . . . . . . . . . . . . . . . . . . . . . . 359
26 File Synchronization 361
26.1 Available Data Synchronization Software . . . . . . . . . . . . . . . 361
26.2 Determining Factors for Selecting a Program . . . . . . . . . . . . . 363
26.3 Introduction to CVS . . . . . . . . . . . . . . . . . . . . . . . 366
26.4 Introduction to rsync . . . . . . . . . . . . . . . . . . . . . . . 368
26.5 For More Information . . . . . . . . . . . . . . . . . . . . . . 370
27 The Apache HTTP Server 371
27.1 Quick Start . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
27.2 Conguring Apache . . . . . . . . . . . . . . . . . . . . . . . 373
27.3 Starting and Stopping Apache . . . . . . . . . . . . . . . . . . . 388
27.4 Installing, Activating, and Conguring Modules . . . . . . . . . . . . 391
27.5 Getting CGI Scripts to Work . . . . . . . . . . . . . . . . . . . . 398
27.6 Setting Up a Secure Web Server with SSL . . . . . . . . . . . . . . 401
27.7 Avoiding Security Problems . . . . . . . . . . . . . . . . . . . . 407
27.8 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . 409
27.9 For More Information . . . . . . . . . . . . . . . . . . . . . . 410
28 Setting up an FTP server with YaST 413
28.1 Starting the FTP server . . . . . . . . . . . . . . . . . . . . . . 414
28.2 FTP General Settings . . . . . . . . . . . . . . . . . . . . . . . 415
28.3 FTP Performance Settings . . . . . . . . . . . . . . . . . . . . . 416
28.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . 416
28.5 Expert Settings . . . . . . . . . . . . . . . . . . . . . . . . . 417
28.6 For more information . . . . . . . . . . . . . . . . . . . . . . 417
Page 9
29 The Proxy Server Squid 419
29.1 Some Facts about Proxy Caches . . . . . . . . . . . . . . . . . . 420
29.2 System Requirements . . . . . . . . . . . . . . . . . . . . . . . 421
29.3 Starting Squid . . . . . . . . . . . . . . . . . . . . . . . . . . 423
29.4 The Conguration File /etc/squid/squid.conf . . . . . . . . . . . . . 425
29.5 Conguring a Transparent Proxy . . . . . . . . . . . . . . . . . . 431
29.6 cachemgr.cgi . . . . . . . . . . . . . . . . . . . . . . . . . . 434
29.7 Cache Report Generation with Calamaris . . . . . . . . . . . . . . 436
29.8 For More Information . . . . . . . . . . . . . . . . . . . . . . 437
Page 10
Page 11
About This Guide
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 congured and that the required services on
the network are available 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 application 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 installation, for the purpose of such an
audit, has been requested.
This guide contains the following:
Administration
SUSE Linux Enterprise offers a wide range of tools to customize various aspects
of the system. This part introduces a few of them. A breakdown of available device
technologies, high availability congurations, and advanced administration possibilities introduces the system to the administrator.
System
Learn more about the underlying operating system by studying this part. SUSE
Linux Enterprise 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 Computing
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 integrates well into heterogeneous environments including MS
Windows clients and servers.
Page 12
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.novell.com/documentation.
1 Available Documentation
We provide HTML and PDF versions of our books in different languages. The following
manuals for users and administrators are available on this product:
Deployment Guide (↑Deployment Guide)
Shows how to install single or multiple systems and how to exploit the product
inherent capabilities for a deployment infrastructure. Choose from various approaches, ranging from a local installation or a network installation server to a mass deployment using a remote-controlled, highly-customized, and automated installation
technique.
Administration Guide (page 1)
Covers system administration tasks like maintaining, monitoring and customizing
an initially installed system.
Security Guide (↑Security Guide)
Introduces basic concepts of system security, covering both local and network security aspects. Shows how to make use of the product inherent security software
like Novell AppArmor (which lets you specify per program which les the program
may read, write, and execute) or the auditing system that reliably collects information about any security-relevant events.
Virtualization with Xen (↑Virtualization with Xen)
Offers an introduction to virtualization technology of your product. It features an
overview of the various elds of application and installation types of each of the
xii Administration Guide
Page 13
platforms supported by SUSE Linux Enterprise Server as well as a short description
of the installation procedure.
Storage Administration Guide
Provides information about how to manage storage devices on a SUSE Linux Enterprise Server.
In addition to the comprehensive manuals, several quick start guides are available:
Installation Quick Start (↑Installation Quick Start)
Lists the system requirements and guides you step-by-step through the installation
of SUSE Linux Enterprise Server from DVD, or from an ISO image.
Linux Audit Quick Start
Gives a short overview how to enable and congure the auditing system and how
to execute key tasks such as setting up audit rules, generating reports, and analyzing
the log les.
Novell AppArmor Quick Start
Helps you understand the main concepts behind Novell® AppArmor.
Find HTML versions of most SUSE Linux Enterprise Server 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.novell.com/
documentation where you can download PDF or HTML versions of the manuals
for your product.
2 Feedback
Several feedback channels are available:
• To report bugs for a product component or to submit enhancements requests, please
use https://bugzilla.novell.com/. If you are new to Bugzilla, you
might nd the Bug Writing FAQs helpful, available from the Novell Bugzilla home
page.
• We want to hear your comments and suggestions about this manual and the other
documentation included with this product. Please use the User Comments feature
About This Guide xiii
Page 14
at the bottom of each page of the online documentation and enter your comments
there.
3 Documentation Conventions
The following typographical conventions are used in this manual:
•
/etc/passwd: directory names and lenames
•
placeholder: replace placeholder with the actual value
•
PATH: the environment variable PATH
•
ls, --help: commands, options, and parameters
•
user: users or groups
•
Alt, Alt + F1: a key to press or a key combination; keys are shown in uppercase as
on a keyboard
•
File, File > Save As: menu items, buttons
• ►amd64 em64t ipf: This paragraph is only relevant for the specied architectures.
The arrows mark the beginning and the end of the text block. ◄
►ipseries zseries: This paragraph is only relevant for the specied architectures.
The arrows mark the beginning and the end of the text block. ◄
•
Dancing Penguins (Chapter Penguins, ↑Another Manual): This is a reference to a
chapter in another manual.
xiv Administration Guide
Page 15
Part I. Support and Common
Tasks
Page 16
Page 17
1
YaST Online Update
Novell offers a continuous stream of software security updates for your product. By
default openSUSE Updater is used to keep your system up-to-date. Refer to Section “Keeping the System Up-to-date” (Chapter 9, Installing or Removing Software,
↑Deployment Guide) for further information on openSUSE Updater. 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 already congured. If you have not registered SUSE Linux Enterprise
Server, you can do so by running Software > Online Update Conguration 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 Section “Managing Software
Repositories and Services” (Chapter 9, Installing or Removing Software, ↑Deployment
Guide).
NOTE: Error on Accessing the Update Catalog
If you are not able to access the update catalog, this might be due to an expired
subscription. Normally, SUSE Linux Enterprise Server comes with a one or three
years subscription, during which you have access to the update catalog. This
access will be denied once the subscription ends.
In case of an access denial to the update catalog you will see a warning message
with a recommendation to visit the Novell Customer Center and check your
YaST Online Update 3
Page 18
subscription. The Novell Customer Center is available at http://www.novell
.com/center/.
Novell provides updates with different relevance levels. Security updates x severe
security hazards and should denitely be installed. Recommended updates x issues
that could compromise your computer, whereas Optional updates x non-security
relevant issues or provide enhancements.
To install updates and improvements with YaST, run Software > Online Update from
YaST. All new patches (except the optional ones) that are currently available for your
system are already marked for installation. Clicking Accept or Apply automatically installs these patches. After the installation has completed, conrm with Finish. Your
system is now up-to-date.
TIP: Disabling deltarpms
By default updates are downloaded as deltarpms. Since rebuilding rpm packages
from deltarpms is a memory and CPU time consuming task, certain setups or
hardware congurations might require you to disable the usage of deltarpms
for performance sake. To disable the use of deltarpms edit the le /etc/
zypp/zypp.conf and set download.use_deltarpm to false.
1.1 Installing Patches Manually Using
the Qt Interface
The Online Update window consists of four sections. The list of all patches available
is on the left. Find the description of the selected patch displayed below the list of
patches. The right column lists the packages included in the selected patch (a patch can
consist of several packages) and below, a detailed description of the selected package.
Optionally, the disk usage can be displayed at the bottom of the left column (this display
is faded out by default—use the dotted slider to make it visible).
4 Administration Guide
Page 19
Figure 1.1
YaST Online Update
The patch display lists the available patches for SUSE Linux Enterprise Server. The
patches are sorted by security relevance (security, recommended, and optional).
There are three different views on patches. Use Show Patch Category to toggle the
views:
Needed Patches (default view)
Non-installed patches that apply to packages installed on your system.
Unneeded Patches
Patches that either apply to packages not installed on your system, or patches that
have requirements which have already have been fullled (because they have already
been updated from another source).
All Patches
All patches available for SUSE Linux Enterprise Server.
A list entry consists of a symbol and the patch name. For a list of possible symbols,
press Shift + F1. Actions required by Security and Recommended patches are au-
tomatically preset. These actions are Autoinstall, Autoupdate and Autodelete. Actions
for Optional patches are not preset—right-click on a patch and choose an action
from the list.
YaST Online Update 5
Page 20
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 fullled 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.
Most patches include updates for several packages. If you want to change actions for
single packages, right-click on a package in the package window and choose an action.
Once you have marked all patches and packages as desired, proceed with Accept.
1.2 Installing Patches Manually Using
the gtk Interface
The Online Update window consists of two main sections. The left pane lists all
patches and provides different lters for the patch list. See the right pane for a list of
changes that will carried out once you Apply them.
Figure 1.2
YaST Online Update
6 Administration Guide
Page 21
Patch List Filters
Available
Non-installed patches that apply to packages installed on your system.
Installed
Patches that are already installed.
All
Patches that are either already installed or available.
Severity
Only show Optional, Recommended, or Security patches. By default, All patches
are shown.
Repositories
This lter lets you display the patches per repository.
Packages Listing
Apply your custom lter here.
Click on a patch entry to open a row with detailed information about the patch in the
bottom area of the left pane. 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.
1.3 Automatic Online Update
YaST also offers the possibility to set up an automatic update. Open Software > Online
Update Conguration. Check Automatic Online Update and choose whether to update
Daily, Weekly, or Monthly. Some patches, such as kernel updates, require user interac-
tion, which would cause the automatic update procedure to stop. Therefore you should
check Skip Interactive Patches if you want the update procedure to proceed fully automatically. Having done so, you should run a manual Online Update from time to time
in order to install patches that require interaction.
YaST Online Update 7
Page 22
Page 23
2
Gathering System Information
for Support
Once a problem arises, supportconfig can be used to collect system information.
Such information can be, for example, the current kernel version being used, the hardware, RPM database, partitions and others. The result is used to help the Novell Support
Center nd your problem.
2.1 Novell Support Link Overview
Novell Support Link (NSL) is new to SUSE Linux Enterprise Server. It is a tool that
gathers system information and allows you to upload that information to another server
for further analysis. Novell Support Center uses Novell Support Link to gather system
information from problematic servers and sends the information to Novell's public FTP
server. System information gathered includes: current kernel version being used, the
hardware, RPM database, partitions, and more. The result is used to help the Novell
Support Center resolve your open service request.
There are two ways to use Novell Support Link:
1. Use the YaST Support module.
2.
Use the command line utility supportconfig.
The YaST Support module calls supportconfig to gather system information.
Gathering System Information for Support 9
Page 24
2.2 Using Supportcong
The following sections describe how to use supportconfig with YaST, with the
command line and what other options you have.
2.2.1 Using YaST to Collect Information
To use YaST to gather your system information, proceed as follows:
1
Open the URL http://www.novell.com/center/eservice and create
a service request number.
2
Start YaST.
3
Open the Support module.
4
Click on Create report tarball.
5
Select an option from the radio button list. If you want to test it rst, use Only
gather a minimum amount of info. Proceed with Next.
6
Enter your contact information. Use your service request number from Step 1
(page 10) and enter it into the text eld labeled Novell 11 digit service request
number. Proceed with Next.
7
The information gathering begins. After the process is nished, continue with
Next.
8
Review the data collection and use Remove from Data if you do not need the respective lename. Continue with Next.
9
Save your tarball. If you want to upload to the Novell customer center, make
sure Upload log les tarball into URL is activated. Finish the operation with
Next.
10 Administration Guide
Page 25
2.2.2 Using Supportcong Directly to
Collect Information
To use supportconfig from the the commandline, proceed as follows:
1
Open a shell and become root.
2
Run supportconfig without any options. This gathers the default system
information.
3
Wait for the tool to complete the operation.
4
The default archive location is /var/log with the lename format nts_HOST
_DATE_TIME.tbz
2.2.3 Common Supportcong Options
The supportconfig utility has a variety of startup options. You can see these options
with supportconfig -h or use the man page. Generally supportconfig is run
without any options. The following is a summary of some of the more common startup
options:
•
Use the minimal option (-m) to reduce the size of the information being gathered:
supportconfig -m
• Include additional contact information in the output (in one line):
supportconfig -E tux@example.org -N "Tux Penguin" -O "Penguin Inc." ...
• While troubleshooting a problem, you may want to gather information only about
the area of the problem you are currently working on. For example, if you have
problems with LVM, and recently found the problem with the default supportcong
output. After making changes, you want to gather the current LVM information.
The following would gather the minimum supportcong information and LVM
only.
supportconfig -i LVM
Gathering System Information for Support 11
Page 26
To see a complete feature list, run:
supportconfig -F
•
Use the -u and -r options to upload a supportcong tarball with the associated
service request number. For example, if you have opened a service request with
Novell and the tracking number is 12345678901, run the following:
supportconfig -ur 12345678901
2.3 Submitting Information to Novell
You can use the YaST Support module or the supportcong command line utility to
submit system information to Novell. When you experience a server issue and would
like Novell's assistance, you will need to open a service request and submit your server
information to Novell. Both YaST and command line methods are described.
Procedure 2.1
Submitting Information to Novell with YaST
1
Open the URL http://www.novell.com/center/eservice and create
a service request number.
2
Write down your 11 digit service request number. The following examples will
assume the service request number is 12345678901.
3
Click on Create report tarball in the YaST Support module window.
4
Select the Use custom radio button. Proceed with Next.
5
Enter your contact information, ll in Novell 11 digit service request number
and include Novell's upload target URL.
•
For the secure upload target, use: https://secure-www.novell.com/
upload?appname=supportconfig&file={tarball}.
•
For the normal FTP upload target, use: ftp://ftp.novell.com/
incoming.
12 Administration Guide
Page 27
Proceed with Next. Information gathering starts. After the process is nished,
continue with Next.
6
Review the data collection and use Remove from Data to remove any les you
want excluded from the tarball uploaded to Novell. Continue with Next.
7
By default, a copy of the tarball will be saved in /root. Conrm you are using
one of the Novell upload targets described above and the Upload log les tarball
into URL is activated. Finish with Next.
8
Click Finish.
Procedure 2.2
Submitting Information to Novell with supportcong
1
Open the URL http://www.novell.com/center/eservice and create
a service request number.
2
Write down your 11 digit service request number. The following examples will
assume the service request number is 12345678901.
3
Servers with Internet connectivity:
3a
To use the default upload target, run:
supportconfig -ur 12345678901
3b
For the secure upload target, use the following on one line:
supportconfig -r 12345678901 -U
'https://secure-www.novell.com/upload?appname=supportconfig&file={tarball}'
4
Servers without Internet connectivity
4a
Run the following:
supportconfig -r 12345678901
4b
Manually upload the /var/log/nts_SR12345678901*tbz tarball to
Novell's FTP server (ftp://ftp.novell.com/incoming).
Gathering System Information for Support 13
Page 28
4c
You can also attach the tarball to your service request using the service request URL: http://www.novell.com/center/eservice.
5
Once the tarball is in the ftp://ftp.novell.com/incoming directory,
it becomes automatically attached to your service request.
2.4 For More Information
Find more information about gathering system information in the following documents:
•
man supportconfig—The manpage of supportcong
•
man supportconfig.conf—The manpage of the supportcong conguration
le
•
http://www.novell.com/communities/print/node/4097—A Basic
Server Health Check with Supportcong
•
http://www.novell.com/communities/print/node/4827—Create
Your Own Supportcong Plugin
•
http://www.novell.com/communities/print/node/4800—Creating
a Central Supportcong Repository
14 Administration Guide
Page 29
3
YaST in Text Mode
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.
Figure 3.1
Main Window of YaST in Text Mode
When YaST is started in text mode, the YaST Control Center appears rst (see Figure 3.1
). The main window consists of three areas. The left frame, which is surrounded by a
thick white border, features the categories to which the various modules belong. The
YaST in Text Mode 15
Page 30
active category is indicated by a colored background. The right frame, which is surrounded by a thin white border, provides an overview of the modules available in the
active category. The bottom frame contains the buttons for Help and Quit.
When the YaST Control Center is started, the category Software is selected automati-
cally. Use ↓ and ↑ to change the category. To start a module from the selected category,
press →. The module selection now appears with a thick border. Use ↓ and ↑ to select
the desired module. Keep the arrow keys pressed to scroll through the list of available
modules. When a module is selected, the module title appears with a colored background.
Press Enter to start the desired module. Various buttons or selection elds in the module
contain a letter with a different color (yellow by default). Use Alt + yellow_letter to
select a button directly instead of navigating there with Tab. Exit the YaST Control
Center by pressing Alt + Q or by selecting Quit and pressing Enter.
3.1 Navigation in Modules
The following description of the control elements in the YaST modules assumes that
all function keys and Alt key combinations work and are not assigned to different
global functions. Read Section 3.2, “Restriction of Key Combinations” (page 17) for
information about possible exceptions.
Navigation among Buttons and Selection Lists
Use Tab to navigate among the buttons and frames containing selection lists. To
navigate in reverse order, use Alt + Tab or Shift + Tab combinations.
Navigation in Selection Lists
Use the arrow keys (↑ and ↓) to navigate among the individual elements in an active
frame containing a selection list. If individual entries within a frame exceed its
width, use Shift + → or Shift + ← to scroll horizontally to the right and left. Alternatively, use Ctrl + E or Ctrl + A. This combination can also be used if using → or
← results in changing the active frame or the current selection list, as in the Control
Center.
Buttons, Radio Buttons, and Check Boxes
To select buttons with empty square brackets (check boxes) or empty parentheses
(radio buttons), press Space or Enter. Alternatively, radio buttons and check boxes
can be selected directly with Alt + yellow_letter. In this case, you do not need to
16 Administration Guide
Page 31
conrm with Enter. If you navigate to an item with Tab, press Enter to execute the
selected action or activate the respective menu item.
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.
Using Navigation Tree in ncurses Mode
Some YaST modules use a navigation tree in the left part of the window to select
conguration dialogs. In ncurses mode, Enter must be pressed after a selection in
the navigation tree in order to show the selected dialog. This is an intentional behaviour to save time consuming redraws when browsing through the navigation
tree.
Figure 3.2
The Software Installation Module
3.2 Restriction of Key Combinations
If your window manager uses global Alt combinations, the Alt combinations in YaST
might not work. Keys like Alt or Shift can also be occupied by the settings of the terminal.
YaST in Text Mode 17
Page 32
Replacing Alt with Esc
Alt shortcuts can be executed with Esc instead of Alt. For example, Esc – H replaces
Alt + H. (First press Esc, then press H.)
Backward and Forward Navigation with Ctrl + F and Ctrl + B
If the Alt and Shift combinations are occupied by the window manager or the terminal, use the combinations Ctrl + F (forward) and Ctrl + B (backward) instead.
Restriction of Function Keys
The F keys are also used for functions. Certain function keys might be occupied
by the terminal and may not be available for YaST. However, the Alt key combinations and function keys should always be fully available on a pure text console.
3.3 YaST Command Line Options
Besides the text mode interface, YaST provides a pure command line interface. To get
a list of YaST command line options, enter:
yast -h
3.3.1 Starting the Individual Modules
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.
3.3.2 Installing Packages from the Command
Line
If you know a package name and the package is provided by any of your active installation repositories, you can use the command line option -i to install the package:
yast -i <package_name>
18 Administration Guide
Page 33
or
yast --install <package_name>
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 4.1, “Using Zypper” (page 21).
3.3.3 Command Line Parameters of the YaST
Modules
To use YaST functionality in scripts, YaST provides command line support for individual modules. Not all modules have command line support. To display the available
options of a module, enter:
yast <module_name> help
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.
YaST in Text Mode 19
Page 34
Page 35
4
Managing Software with
Command Line Tools
This chapter describes Zypper and RPM, two command line tools for managing software.
4.1 Using Zypper
Zypper is a command line tool for installing and updating packages. Zypper's syntax
is similar to that of rug. In contrast to rug, zypper does not require the zmd daemon to
run behind the scenes. For more information about rug compatibility, see man zypper,
section “COMPATIBILITY WITH RUG”. It is especially useful for accomplishing
remote software management tasks or managing software from shell scripts.
zypper has a help overview built in:
zypper help
4.1.1 General Usage
The general syntax of zypper is:
zypper [global-options] command [command-options] [arguments] ...
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
Managing Software with Command Line Tools 21
Page 36
Additionally, you can choose from one or more global options by typing them just before
the command. For example, --non-interactive means, run the command without
asking anything, decide on your own:
zypper --non-interactive patch
To use the options specic to a particular command, type them right after the command.
For example, --auto-agree-with-licenses means, apply all needed patches
to the system without asking to conrm any licenses—all of them were read in advance:
zypper patch --auto-agree-with-licenses
Some of the commands require one or more arguments:
zypper install mplayer
Some of the options also require an argument. The following command will list all
known patterns:
zypper search -t pattern
You can combine all of the above. For example, the following command will install
mplayer and amarok packages using the factory repository only and be verbose:
zypper -v install --repo factory mplayer amarok
4.1.2 Installing and Removing Software with
Zypper
To install a package from registered repositories, use:
zypper install package_name
To install a specic version of a package, use:
zypper install package_name=version
zypper also supports wild cards. For example, to install all packages starting with
package_name use the following:
zypper install package_name*
You can also install a local or remote RPM directly—Zypper will also install all packages
that package_name is dependent on automatically with the following:
zypper install http://www.example.com/package_name.rpm
22 Administration Guide
Page 37
To remove an installed package, use:
zypper remove package_name
To install and remove packages simultaneously use the +/- or ~/! modiers:
zypper install emacs -vim
Or:
zypper remove emacs +vim
Or, if you choose to use - with the rst package you specify, you must write -- before
it to prevent its interpretation as a command option:
zypper install -- -vim emacs
WARNING: Do not Remove Mandatory System Packages
Do not remove packages such as glibc, zypper, kernel, or similar packages.
These packages are mandatory for the system and if removed the system may
stop working.
By default, Zypper asks for a conrmation 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:
zypper --non-interactive install package_name
This option allows the use of Zypper in scripts and cron jobs.
If you want to install the corresponding source package of a package, use:
zypper source-install package_name
The following command will also install the build dependencies of the specied package.
If you do not want this, add the switch --no-build-deps as follows:
zypper source-install --no-build-deps package_name
Of course, this will only work if you have the repository with the source packages added
to your repository list. Enter zypper search -t srcpackage to get a list of
source packages available in your repositories. For more information about adding
repositories, see Section 4.1.4, “Managing Repositories” (page 24).
Managing Software with Command Line Tools 23
Page 38
If an error occurs during installation, or anytime you feel the need, verify whether all
dependencies are still fullled:
zypper verify
4.1.3 Updating Software with Zypper
There are two different ways to update software using Zypper. To integrate all ofcially
released patches into your system, just run:
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 installation, an
ofcial 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.
If a repository just contains new packages, but does not provide patches,
zypper patch does not show any effect. To update all installed packages with
newer available versions, use:
zypper update
To update individual packages, use the update command with arguments:
zypper update package_name
Or the installation command:
zypper install package_name
A list of all new packages available can be obtained with the command:
zypper list-updates
Similarily, to list all needed patches, use:
zypper list-patches
4.1.4 Managing Repositories
All installation or patch commands of Zypper rely on a list of known repositories. To
list all repositories known to the system, use the command:
zypper repos
24 Administration Guide
Page 39
The result will look similar to the following output:
# | Alias | Name
| Enabled | Refresh
--+-----------------------------------+-----------------------------------+---------+-------1 | SUSE-Linux-Enterprise-Server 11-0 | SUSE-Linux-Enterprise-Server 11-0
| Yes | No
2 | SLES-11-Updates | SLES 11 Online Updates
| Yes | Yes
3 | broadcomdrv | Broadcom Drivers
| Yes | No
When specifying repositories in various commands, an alias, URI or repository number
from the zypper repos command output can be used. Note however that the numbers
can change after modifying the list of repositories. The alias will never change by itself.
If you want to remove a repository from the list, use the command zypper
removerepo together with the alias or number of the repository you want to delete.
To remove the Broadcom Drivers from the example, use the following command:
zypper removerepo 3
To add a repository, run
zypper addrepo URI Alias
URI can either be an Internet repository, a directory or a CD or DVD. The Alias is
a shorthand and unique identier of the repository. You can freely choose it, with the
only exception that is has to be unique. Zypper will issue a warning if you specify an
alias that is already in use.
To make working with repositories more convenient, use short and easy to remember
aliases. A repository alias can be changed using the renamerepo command. For example, to rename the lengthy SUSE-Linux-Enterprise-Server 11-0 from
the example to the short and handy label main, enter:
zypper renamerepo 1 main
4.1.5 Querying
Various querying commands such as search, info or what-provides are available.
Managing Software with Command Line Tools 25
Page 40
search works on package names or, optionally, on package summaries and descriptions, and displays status (S) information in the rst column of the list of found packages.
info with a package name as an argument displays detailed information about a
package.
The what-provides package is similar to rpm -q --whatprovides
package, but rpm is only able to query the RPM database (that is the database of all
installed packages). Zypper, on the other hand, will tell you about providers of the capability from any repository, not only those that are installed.
For more query commands and detailed usage information, see the Zypper manpage
(man zypper).
4.1.6 For More Information
For more information about managing software from the command line, enter zypper
help or zypper help command or see the zypper(8) manpage.
4.2 RPM—the Package Manager
RPM (RPM Package Manager) is used for managing software packages. Its main
commands are rpm and rpmbuild. The powerful RPM database can be queried by
the users, system administrators and package builders for detailed information about
the installed software.
Essentially, rpm has ve modes: installing, uninstalling (or updating) software packages,
rebuilding the RPM database, querying RPM bases or individual RPM archives, integrity
checking of packages and signing packages. rpmbuild can be used to build installable
packages from pristine sources.
Installable RPM archives are packed in a special binary format. These archives consist
of the program les to install and certain meta information used during the installation
by rpm to congure the software package or stored in the RPM database for documentation purposes. RPM archives normally have the extension .rpm.
26 Administration Guide
Page 41
TIP: Software Development Packages
For a number of packages, the components needed for software development
(libraries, headers, include les, etc.) have been put into separate packages.
These development packages are only needed if you want to compile software
yourself (for example, the most recent GNOME packages). They can be identied
by the name extension -devel, such as the packages alsa-devel,
gimp-devel, and kdelibs3-devel.
4.2.1 Verifying Package Authenticity
RPM packages have a GnuPG signature. The key including the ngerprint is:
1024D/9C800ACA 2000-10-19 SuSE Package Signing Key <build@suse.de>
Key fingerprint = 79C1 79B2 E1C8 20C1 890F 9994 A84E DAE8 9C80 0ACA
The command rpm --checksig package-1.2.3.rpm can be used to verify
the signature of an RPM package to determine whether it originates from SUSE or from
another trustworthy facility. This is especially recommended for update packages from
the Internet. The SUSE public package signature key normally resides in /root/
.gnupg/. The key is additionally located in the directory /usr/lib/rpm/gnupg/
to enable normal users to verify the signature of RPM packages.
4.2.2 Managing Packages: Install, Update,
and Uninstall
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 fullled
and there are no conicts 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 conicts arise—a specic le can only
belong to one package. By choosing different options, you can force rpm to ignore
these defaults, but this is only for experts. Otherwise, you risk compromising the integrity
of the system and possibly jeopardize the ability to update the system.
The options -U or --upgrade and -F or --freshen can be used to update a
package (for example, rpm -F package.rpm). This command removes the les
Managing Software with Command Line Tools 27
Page 42
of the old version and immediately installs the new les. The difference between the
two versions is that -U installs packages that previously did not exist in the system, but
-F merely updates previously installed packages. When updating, rpm updates conguration les carefully using the following strategy:
•
If a conguration 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 conguration 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 conguration le already exists and if the noreplace
label was specied 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 conguration le. A list of these les is
available in /var/adm/rpmconfigcheck. Some conguration les (like /etc/
httpd/httpd.conf) are not overwritten to allow continued operation.
The -U switch is not just an equivalent to uninstalling with the -e option and installing
with the -i option. Use -U whenever possible.
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
28 Administration Guide
Page 43
(even if no additional dependencies exist), it may be helpful to rebuild the RPM database
using the option --rebuilddb.
4.2.3 RPM and Patches
To guarantee the operational security of a system, update packages must be installed
in the system from time to time. Previously, a bug in a package could only be eliminated
by replacing the entire package. Large packages with bugs in small les could easily
result in this scenario. However the SUSE RPM offers a feature enabling the installation
of patches in packages.
The most important considerations are demonstrated using pine as an example:
Is the patch RPM suitable for my system?
To check this, rst query the installed version of the package. For pine, this can
be done with
rpm -q pine
pine-4.44-188
Then check if the patch RPM is suitable for this version of pine:
rpm -qp --basedon pine-4.44-224.i586.patch.rpm
pine = 4.44-188
pine = 4.44-195
pine = 4.44-207
This patch is suitable for three different versions of pine. The installed version in
the example is also listed, so the patch can be installed.
Which les are replaced by the patch?
The les affected by a patch can easily be seen in the patch RPM. The rpm parameter -P allows selection of special patch features. Display the list of les with the
following command:
rpm -qpPl pine-4.44-224.i586.patch.rpm
/etc/pine.conf
/etc/pine.conf.fixed
/usr/bin/pine
or, if the patch is already installed, with the following command:
rpm -qPl pine
/etc/pine.conf
Managing Software with Command Line Tools 29
Page 44
/etc/pine.conf.fixed
/usr/bin/pine
How can a patch RPM be installed in the system?
Patch RPMs are used just like normal RPMs. The only difference is that a suitable
RPM must already 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:
rpm -q --basedon pine
pine = 4.44-188
More information, including information about the patch feature of RPM, is available
in the man pages of rpm and rpmbuild.
4.2.4 Delta RPM Packages
Delta RPM packages contain the difference between an old and a new version of an
RPM package. Applying a delta RPM onto an old RPM results in a completely new
RPM. It is not necessary to have a copy of the old RPM because a delta RPM can also
work with an installed RPM. The delta RPM packages are even smaller in size than
patch RPMs, which is an advantage when transferring update packages over the Internet.
The drawback is that update operations with delta RPMs involved consume considerably
more CPU cycles than plain or patch RPMs.
The prepdeltarpm, writedeltarpm and applydeltarpm binaries are part
of the delta RPM suite (package deltarpm) and help you create and apply delta RPM
packages. With the following commands, create a delta RPM called new.delta.rpm.
The following command assumes that old.rpm and new.rpm are present:
prepdeltarpm -s seq -i info old.rpm > old.cpio
prepdeltarpm -f new.rpm > new.cpio
30 Administration Guide
Page 45
xdelta delta -0 old.cpio new.cpio delta
writedeltarpm new.rpm delta info new.delta.rpm
Finally, remove the temporary working les old.cpio, new.cpio, and delta.
Using applydeltarpm, you can reconstruct the new RPM from the le system if
the old package is already installed:
applydeltarpm new.delta.rpm new.rpm
To derive it from the old RPM without accessing the le system, use the -r option:
applydeltarpm -r old.rpm new.delta.rpm new.rpm
See /usr/share/doc/packages/deltarpm/README" for technical details.
4.2.5 RPM Queries
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 switches are available to specify the type of information required. See Table 4.1,
“The Most Important RPM Query Options” (page 31).
Table 4.1
The Most Important RPM Query Options
Package information
-i
File list
-l
Query the package that contains the le FILE (the full
path must be specied with FILE)
-f FILE
File list with status information (implies -l)-s
List only documentation les (implies -l)-d
List only conguration les (implies -l)-c
File list with complete details (to be used with -l, -c,
or -d)
--dump
Managing Software with Command Line Tools 31
Page 46
List features of the package that another package can request with --requires
--provides
Capabilities the package requires
--requires, -R
Installation scripts (preinstall, postinstall, uninstall)
--scripts
For example, the command rpm -q -i wget displays the information shown in
Example 4.1, “rpm -q -i wget” (page 32).
Example 4.1
rpm -q -i wget
Name : wget Relocations: (not relocatable)
Version : 1.9.1 Vendor: SUSE LINUX AG,
Nuernberg, Germany
Release : 50 Build Date: Sat 02 Oct 2004
03:49:13 AM CEST
Install date: Mon 11 Oct 2004 10:24:56 AM CEST Build Host: f53.suse.de
Group : Productivity/Networking/Web/Utilities Source RPM:
wget-1.9.1-50.src.rpm
Size : 1637514 License: GPL
Signature : DSA/SHA1, Sat 02 Oct 2004 03:59:56 AM CEST, Key ID
a84edae89c800aca
Packager : http://www.suse.de/feedback
URL : http://wget.sunsite.dk/
Summary : A tool for mirroring FTP and HTTP servers
Description :
Wget enables you to retrieve WWW documents or FTP files from a server.
This can be done in script files or via the command line.
[...]
The option -f only works if you specify the complete lename with its full path. Provide
as many lenames as desired. For example, the following command
rpm -q -f /bin/rpm /usr/bin/wget
results in:
rpm-4.1.1-191
wget-1.9.1-50
If only part of the lename is known, use a shell script as shown in Example 4.2, “Script
to Search for Packages” (page 33). Pass the partial lename to the script shown as a
parameter when running it.
32 Administration Guide
Page 47
Example 4.2
Script to Search for Packages
#! /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 specic package, sorted by date. The above example shows information
about the package rpm.
With the help of the installed RPM database, verication 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:
Table 4.2
RPM Verify Options
MD5 check sum
5
File size
S
Symbolic link
L
Modication time
T
Major and minor device numbers
D
Owner
U
Group
G
Mode (permissions and le type)
M
In the case of conguration les, the letter c is printed. For example, for changes to
/etc/wgetrc (wget):
rpm -V wget
S.5....T c /etc/wgetrc
Managing Software with Command Line Tools 33
Page 48
The les of the RPM database are placed in /var/lib/rpm. If the partition /usr
has a size of 1 GB, this database can occupy nearly 30 MB, especially after a complete
update. If the database is much larger than expected, it is useful to rebuild the database
with the option --rebuilddb. Before doing this, make a backup of the old database.
The cron script cron.daily makes daily copies of the database (packed with gzip)
and stores them in /var/adm/backup/rpmdb. The number of copies is controlled
by the variable MAX_RPMDB_BACKUPS (default: 5) in /etc/sysconfig/backup.
The size of a single backup is approximately 1 MB for 1 GB in /usr.
4.2.6 Installing and Compiling Source
Packages
All source packages carry a .src.rpm extension (source RPM).
TIP
Source packages can be copied from the installation medium to the hard disk
and unpacked with YaST. They are not, however, marked as installed ([i]) in
the package manager. This is because the source packages are not entered in
the RPM database. Only installed operating system software is listed in the RPM
database. When you “install” a source package, only the source code is added
to the system.
The following directories must be available for rpm and rpmbuild in /usr/src/
packages (unless you specied custom settings in a le like /etc/rpmrc):
SOURCES
for the original sources (.tar.bz2 or .tar.gz les, etc.) and for distributionspecic adjustments (mostly .diff or .patch les)
SPECS
for the .spec les, similar to a meta Makele, which control the build process
BUILD
all the sources are unpacked, patched and compiled in this directory
34 Administration Guide
Page 49
RPMS
where the completed binary packages are stored
SRPMS
here are the source RPMs
When you install a source package with YaST, all the necessary components are installed
in /usr/src/packages: the sources and the adjustments in SOURCES and the
relevant .spec le in SPECS.
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 package
with YaST, you should have les similar to the following listing:
/usr/src/packages/SOURCES/nops_doc.diff
/usr/src/packages/SOURCES/toplev_destdir.diff
/usr/src/packages/SOURCES/wget-1.9.1+ipvmisc.patch
/usr/src/packages/SOURCES/wget-1.9.1-brokentime.patch
/usr/src/packages/SOURCES/wget-1.9.1-passive_ftp.diff
/usr/src/packages/SOURCES/wget-LFS-20040909.tar.bz2
/usr/src/packages/SOURCES/wget-wrong_charset.patch
/usr/src/packages/SPECS/wget.spec
rpmbuild -b X /usr/src/packages/SPECS/wget.spec starts the com-
pilation. X is a wild card for various stages of the build process (see the output of
--help or the RPM documentation for details). The following is merely a brief explanation:
-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 conguration les.
Managing Software with Command Line Tools 35
Page 50
-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 binary RPM created can now be installed with rpm -i or, preferably, with rpm
-U. Installation with rpm makes it appear in the RPM database.
4.2.7 Compiling RPM Packages with build
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 dened 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
Subsequently, a minimum environment is established at /var/tmp/build-root.
The package is built in this environment. Upon completion, the resulting packages are
located in /var/tmp/build-root/usr/src/packages/RPMS.
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.
36 Administration Guide
Page 51
4.2.8 Tools for RPM Archives and the RPM
Database
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 Commander. Display the HEADER with F3. View the archive structure
with the cursor keys and Enter. Copy archive components with F5.
KDE offers the kpackage tool as a front-end for rpm. A full-featured package manager
is available as a YaST module (see Chapter 9, Installing or Removing Software (↑De-
ployment Guide)).
Managing Software with Command Line Tools 37
Page 52
Page 53
5
Bash and Bash Scripts
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 automatical tasks. Shells are a good addition to GUIs and this chapter
gives you an overview of some aspects of shells, in this case Bash.
5.1 What is “The Shell”?
Traditionally, the shell is Bash (Bourne again Shell). When this chapter speaks about
“the shell” it means Bash. There are actually more available shells than Bash, each
employing different features and characteristics. If you need further information about
other shells, search for shell in YaST.
5.1.1 Knowing The Bash Conguration Files
A shell can be invoked:
1. as an 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. as an “ordinary” interactive shell. This is normally the case when starting xterm,
konsole or similar tools.
3. as an non-interactive shell. This is used when invoking a shell script at the commandline.
Bash and Bash Scripts 39
Page 54
Depending on which type of shell you use, different conguration les are being read.
The following tables show the login and non-login shell conguration les.
Table 5.1
Bash Conguration Files for Login Shells
DescriptionFile
Do not modify this le, otherwise your modications can be destroyed during your next update!
/etc/profile
use this le if you extent /etc/profile/etc/profile.local
contains system-wide conguration les for specic
programs
/etc/profile.d/
insert user specic conguration for login shells
here
~/.profile
Table 5.2
Bash Conguration Files for Non-Login Shells
Do not modify this le, otherwise your modications can be destroyed during your next update!
/etc/bash.bashrc
use this le to insert your system-wide modications for Bash only
/etc/bash.bashrc
.local
insert user specic conguration here
~/bashrc
Additionally, Bash uses some more les:
Table 5.3
Special Files for Bash
DescriptionFile
contains a list of all commands you have been
typing
~/.bash_history
used when logging out
~/.bash_logout
40 Administration Guide
Page 55
5.1.2 The Directory Structure
The following table provides a short overview of the most important higher-level directories you nd on a Linux system. Find more detailed information about the directories
and important subdirectories in the following list.
Table 5.4
Overview of a Standard Directory Tree
ContentsDirectory
Root directory—the starting point of the directory tree.
/
Essential binary les, such as commands that are needed
by both the system administrator and normal users. Usually
also contains the shells, such as Bash.
/bin
Static les of the boot loader.
/boot
Files needed to access host-specic devices.
/dev
Host-specic system conguration les.
/etc
Holds the home directories of all users who have an account
on the system. Only root's home directory is not located
in /home but in /root.
/home
Essential shared libraries and kernel modules.
/lib
Mount points for removable media.
/media
Mount point for temporarily mounting a le system.
/mnt
Add-on application software packages.
/opt
Home directory for the superuser root./root
Essential system binaries.
/sbin
Bash and Bash Scripts 41
Page 56
ContentsDirectory
Data for services provided by the system.
/srv
Temporary les.
/tmp
Secondary hierarchy with read-only data.
/usr
Variable data such as log les.
/var
Only available if you have both Microsoft Windows* and
Linux installed on your system. Contains the Windows
data.
/windows
The following list provides more detailed information and gives some examples of
which les and subdirectories can be found in the directories:
/bin
Contains the basic shell commands that may be used both by root and by other
users. These commands include ls, mkdir, cp, mv, rm and rmdir. /bin also
contains Bash, the default shell in SUSE Linux Enterprise Server.
/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 conguration 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 modied by their owner or by the system administrator.
By default, your e-mail directory and personal desktop conguration are located
here in the form of hidden les and directories. KDE users nd the personal con-
42 Administration Guide
Page 57
guration data for their desktop in .kde or .kde4 respectively, GNOME users
nd it in .gconf.
NOTE: Home Directory in a Network Environment
If you are working in a network environment, your home directory may be
mapped to a directory in the le system other than /home.
/lib
Contains 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
This directory provides a mount point for a temporarily mounted le system. root
may mount le systems here.
/opt
Reserved for the installation of additional software. Optional software and larger
add-on program packages can be found here. KDE3 is located here, whereas KDE4
and GNOME have moved to /usr now.
/root
Home directory for the root user. Personal data of root is located here.
/sbin
As the s indicates, this directory holds utilities for the superuser. /sbin contains
binaries 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.
Bash and Bash Scripts 43
Page 58
/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 to the Filesystem Hierarchy Standard (FHS). This directory contains all
application programs 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
In this directory the system administrator can install local, distribution-independent
extensions.
/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 lan-
guage 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/packagename is created that often holds README les for the
package and sometimes examples, conguration les or additional scripts.
If HOWTOs are installed on your system /usr/share/doc also holds the
howto subdirectory in which to nd additional documentation on many tasks re-
lated 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
44 Administration Guide
Page 59
example, the log les of your system are in /var/log/messages (only accessible for root).
5.2 Writing Shell Scripts
Shell scripts are a convenient way of doing all sorts of tasks: collecting data, searching
for a word or phrase in a text and many other useful things. The following example
shows a small shell script that prints a text:
Example 5.1
A Shell Script Printing a Text
#!/bin/sh ❶
# Output the following line: ❷
echo "Hello World" ❸
❶
The rst line begins with the Shebang characters (#!) which is an indicator that
this le is a script. The script is executed with the specied interpreter after the
Shebang, in this case /bin/sh.
❷
The second line is a comment beginning with the hash sign. It is recommended
to comment difcult lines to remember what they do.
❸
The third line uses the built-in command echo to print the respective text.
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 yourself.
2. You can save the script wherever you want. However, it is a good idea to save it
in a directory where the shell searches for it. The search path in a shell is determined
by the environment variable PATH. For example, save it in the directory ~/bin/
under 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 fulllled all of the above prerequisites, you can execute the script with either
~/bin/hello.sh or hello.sh. The rst call uses an absolute path whereas the
Bash and Bash Scripts 45
Page 60
second one searches for the command in each directory given by the PATH environment
variable.
5.3 Redirecting Command Events
Each command can use three channels, either for input or output:
• Standard Output This is the default output channel. Whenever a command
prints something, it uses the standard output channel.
• Standard Input If a command needs input from users or other commands, it
uses this channel.
• Standard Error Commands use this channel for error reporting.
To redirect these channels, there are the following possibilities:
Command > File
Saves the output of the command into a le, an existing le will be deleted. For
example, the ls command writes its output into the le listing.txt:
ls > listing.txt
Command >> File
Appends the output of the command to a le. For example, the ls command appends its output to the le listing.txt:
ls >> listing.txt
Command < File
Reads the le as input for the given command. For example, the read command
reads in the content of the le into a variable:
read a < foo
Command1 | Command2
Redirects the output of the left command as input for the right command.
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 > char-
46 Administration Guide
Page 61
acter. For example, the following line searches for a le starting with foo, but suppresses
its errors by redirecting it to /dev/null:
find / -name "foo*" 2>/dev/null
5.4 Using Aliases
An alias is a shortcut denition of one or more commands. The syntax for an alias is:
alias NAME=DEFINITION
For example, the following line denes an alias lt which outputs a long listing (option
-l), sorts it by modication time (-t) and prints it in reverse order while sorting (-r):
alias lt='ls -ltr'
To view all alias denitions, use alias.
5.5 Using Variables in Bash
A shell variable can be global or local. Global variables, or environment variables, can
be accessed in all shells. In contrast, local variables are visible in the current shell only.
To view all environment variables, use the printenv command. If you need a special
variable, insert the name of your variable as an argument:
printenv PATH
A variable can also be viewed with echo:
echo $PATH
This prints the PATH variable. 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 a environment variable, use export:
export NAME="tux"
Bash and Bash Scripts 47
Page 62
To remove a variable, use unset:
unset NAME
The following table contains some common environment variables which can be used
in you shell scripts:
Table 5.5
Useful Environment Variables
the home directory of the current user
HOME
the current host name
HOST
when a tool is localized, it uses the language from this environment variable. English can also be set to C
LANG
the search path of the shell, a list of directories separated by
colon
PATH
species the normal prompt printed before each command
PS1
species the secondary prompt printed when you execute a
multi-line command
PS2
current working directory
PWD
the current user
USER
5.5.1 Using Argument Variables
For example, if you have the script foo.sh you can execute it like this:
foo.sh "Tux Penguin" 2000
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:
48 Administration Guide
Page 63
#!/bin/sh
echo \"$1\" \"$2\" \"$3\" \"$4\"
If you execute this script with the above arguments, you get:
"Tux Penguin" "2000" "" ""
5.5.2 Using Variable Substitution
Variable substitutions apply a pattern to the content of a variable either from the left
or right side. The following list contains the possible syntax forms:
${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
${VAR##pattern}
removes the longest possible match from the left:
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
Bash and Bash Scripts 49
Page 64
5.6 Grouping And Combining
Commands
Shells allow0.0 you to concatenate and group commands for conditional execution.
Each command returns an exit code which determines the success or failure of its operation. If it is 0 (zero) the command was successful, everything else marks an error which
is specic to the command.
The following list shows, how commands can be grouped:
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:
cat filelist.txt ; ls -l filelist.txt
Command1 && Command2
runs the right command, if the left command was successful (logical AND). The
following line displays the content of the le and prints its le properties only,
when the previous command was successful (compare it with the previous entry
in this list):
cat filelist.txt && ls -l filelist.txt
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:
mkdir /home/tux/foo || mkdir /home/wilber/bar
funcname(){ ... }
creates a shell function. You can use the positional parameters to access its arguments. The following line denes the function hello to print a short message:
hello() { echo "Hello $1"; }
You can call this function like this:
hello Tux
50 Administration Guide
Page 65
which prints:
Hello Tux
5.7 Working with Common Flow
Constructs
To control the ow of your script, a shell has while, if, for and case constructs.
5.7.1 The if Control Command
The if is used to check expressions. For example, the following code tests whether
the current user is Tux:
if test $USER = "tux" then
echo "Hello Tux."
else
echo "You are not Tux."
fi
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
Find more useful expressions at http://www.cyberciti.biz/nixcraft/
linux/docs/uniqlinuxfeatures/lsst/ch03sec02.html.
5.7.2 Creating Loops With The For
Command
The for loop allows you to execute commands to a list of entries. For example, the
following code prints some information about PNG les in the current directory:
for i in *.png; do
ls -l $i
done
Bash and Bash Scripts 51
Page 66
5.8 For More Information
Important information about Bash is provided in the man pages man sh. More about
this topic can be found in the following list:
•
http://tldp.org/LDP/Bash-Beginners-Guide/html/index
.html—Bash Guide for Beginners
•
http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO.html—BASH
Programming - Introduction HOW-TO
•
http://tldp.org/LDP/abs/html/index.html—Advanced Bash-
Scripting Guide
•
http://www.grymoire.com/Unix/Sh.html—Sh - the Bourne Shell
52 Administration Guide
Page 67
Part II. System
Page 68
Page 69
6
32-Bit and 64-Bit Applications
in a 64-Bit System
Environment
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 32bit 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 64bit applications.
32-Bit and 64-Bit Applications in a 64-Bit System Environment 55
Page 70
6.1 Runtime Support
IMPORTANT: Conicts between Application Versions
If an application is available both for 32-bit and 64-bit environments, parallel
installation of both versions is bound to lead to problems. In such cases, decide
on one of the two versions and install and use this.
An exception to this rule is PAM (pluggable authentication modules). SUSE
Linux Enterprise Server uses PAM in the authentication process as a layer that
mediates between user and application. On a 64-Bit operating system that also
runs 32-Bit applications it is necessary to always install both versions of a PAM
module.
To be executed correctly, every application requires a range of libraries. Unfortunately,
the names for the 32-bit and 64-bit versions of these libraries are identical. They must
be differentiated from each other in another way.
To retain compatibility with the 32-bit version, the libraries are stored at the same place
in the system as in the 32-bit environment. The 32-bit version of libc.so.6 is located
under /lib/libc.so.6 in both the 32-bit and 64-bit environments.
All 64-bit libraries and object les are located in directories called lib64. The 64-bit
object les 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 lename 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. ◄
56 Administration Guide
Page 71
6.2 Software Development
All 64-bit architectures support the development of 64-bit objects. The level of support
for 32-bit compiling depends on the architecture. These are the various implementation
options for the tool chain from GCC (GNU Compiler Collection) and binutils, which
include the assembler as and the linker ld:
Biarch Compiler
Both 32-bit and 64-bit objects can be generated with a biarch development tool
chain. The compilation of 64-bit objects is the default on almost all platforms. 32-
bit objects can be generated 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.
All header les must be written in an architecture-independent form. The installed 32bit and 64-bit libraries must have an API (application programming interface) that
matches the installed header les. The normal SUSE Linux Enterprise Server environment is designed according to this principle. In the case of manually updated libraries,
resolve these issues yourself.
6.3 Software Compilation on Biarch
Platforms
To develop binaries for the other architecture on a biarch architecture, the respective
libraries for the second architecture must additionally be installed. These packages are
called rpmname-32bit or rpmname-x86 (for ia64) if the second architecture is a
32-bit architecture or rpmname-64bit if the second architecture is a 64-bit architecture. You also need the respective headers and libraries from the rpmname-devel
32-Bit and 64-Bit Applications in a 64-Bit System Environment 57
Page 72
packages and the development libraries for the second architecture from
rpmname-devel-32bit or rpmname-devel-64bit.
For example, to compile a program that uses libaio on a system whose second architecture is a 32-bit architecture (x86_64 or System z), you need the following RPMs:
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 conguration. To use
autoconf for conguring 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.
1
Use the 32-bit compiler:
CC="gcc -m32"
2
Instruct the linker to process 32-bit objects (always use gcc as the linker frontend):
LD="gcc -m32"
3
Set the assembler to generate 32-bit objects:
AS="gcc -c -m32"
4
Determine that the libraries for libtool and so on come from /usr/lib:
58 Administration Guide
Page 73
LDFLAGS="-L/usr/lib"
5
Determine that the libraries are stored in the lib subdirectory:
--libdir=/usr/lib
6
Determine that the 32-bit X libraries are used:
--x-libraries=/usr/lib/xorg
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
make
make install
6.4 Kernel Specications
The 64-bit kernels for x86_64, ppc64 and System z offer both a 64-bit and a 32-bit
kernel ABI (application binary interface). The latter is identical with the ABI for the
corresponding 32-bit kernel. This means that the 32-bit application can communicate
with the 64-bit kernel in the same way as with the 32-bit kernel.
The 32-bit emulation of system calls for a 64-bit kernel does not support all the APIs
used by system programs. This depends on the platform. For this reason, a small number
of applications, like lspci, must be compiled on non-ppc64 platforms as 64-bit programs to function properly. On IBM System z, not all ioctls are available in the 32-bit
kernel ABI.
A 64-bit kernel can only load 64-bit kernel modules that have been specially compiled
for this kernel. It is not possible to use 32-bit kernel modules.
32-Bit and 64-Bit Applications in a 64-Bit System Environment 59
Page 74
TIP
Some applications require separate kernel-loadable modules. If you intend to
use such a 32-bit application in a 64-bit system environment, contact the
provider of this application and Novell to make sure that the 64-bit version of
the kernel-loadable module and the 32-bit compiled version of the kernel API
are available for this module.
60 Administration Guide
Page 75
7
Booting and Conguring a
Linux System
Booting a Linux system involves different components. The hardware itself is initialized
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.
7.1 The Linux Boot Process
The Linux boot process consists of several stages each represented by a different component. The following list briey summarizes the boot process and features all the
major components involved.
1. BIOS After the computer has been turned on, 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 congure 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
Booting and Conguring a Linux System 61
Page 76
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 8, The
Boot Loader GRUB (page 77). For a network boot, the BIOS acts as the boot
loader. It gets the image to start from the boot server then 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 called init that handles the mounting of the real root le system. If special
hardware drivers are needed before the mass storage can be accessed, they must
be in initramfs. For more information about initramfs, refer to Section 7.1.1,
“initramfs” (page 62). If the system does not have a local hard disk, the initramfs
must provide the root le system to the kernel. This can be done with the help of
a network block device like iSCSI or SAN, but it is also possible to use NFS as
the root device.
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 has been
successful, the initramfs is cleaned and the init program on the root le system is
executed. For more information about init, refer to Section 7.1.2, “init on initramfs”
(page 63). Find more information about udev in Chapter 11, Dynamic Kernel
Device Management with udev (page 131).
5. init init handles the actual booting of the system through several different levels
providing different functionality. init is described in Section 7.2, “The init Process”
(page 65).
7.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 specic hardware requirements other than sufcient
62 Administration Guide
Page 77
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 (e.g. 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, initrd—by calling
mkinitrd. Calling mkinitrd without any argument creates an initramfs. Calling
mkinitrd -R creates an initrd. In SUSE® Linux Enterprise Server, the modules to
load are specied by the variable INITRD_MODULES in /etc/sysconfig/
kernel. After installation, this variable is automatically set to the correct value. The
modules are loaded in exactly the order in which they appear in INITRD_MODULES.
This is only important if you rely on the correct setting of the device les /dev/sd?.
However, in current systems you also may use the device les below /dev/disk/
that are sorted in several subdirectories, named by-id, by-path and by-uuid, and
always represent the same disk. This is also possible at install time by specifying the
respective mount option.
IMPORTANT: Updating initramfs or initrd
The boot loader loads initramfs or initrd in the same way as the kernel. It is
not necessary to reinstall GRUB after updating initramfs or initrd, because GRUB
searches the directory for the right le when booting.
7.1.2 init on initramfs
The main purpose of init on initramfs is to prepare the mounting of and access to the
real root le system. Depending on your system conguration, init is responsible for
the following tasks.
Booting and Conguring a Linux System 63
Page 78
Loading Kernel Modules
Depending on your hardware conguration, special drivers may be needed to access
the hardware components of your computer (the most important component being
your hard drive). To access the nal root le system, the kernel needs to load the
proper le system drivers.
Providing Block Special Files
For each loaded module, the kernel generates device events. udev handles these
events and generates the required block special les on a RAM le system in /dev.
Without those special les, the le system and other devices would not be accessible.
Managing RAID and LVM Setups
If you congured your system to hold the root le system under RAID or LVM,
init sets up LVM or RAID to enable access to the root le system later. Find information about RAID and LVM in Chapter 15, Advanced Disk Setup (↑Deployment
Guide).
Managing Network Conguration
If you congured your system to use a network-mounted root le system (mounted
via NFS), init must make sure that the proper network drivers are loaded and that
they are set up to allow access to the root le system.
If the le system resides on a networked block device like iSCSI or SAN, connection
to the storage server is also set up by the initramfs.
When init is called during the initial boot as part of the installation process, its tasks
differ from those mentioned earlier:
Finding the Installation Medium
As you start the installation process, your machine loads an installation kernel and
a special initrd with the YaST installer from the installation medium. The YaST
installer, which is run in a RAM le system, needs to have information about the
location of the installation medium to access it and install the operating system.
Initiating Hardware Recognition and Loading Appropriate Kernel Modules
As mentioned in Section 7.1.1, “initramfs” (page 62), the boot process starts with
a minimum set of drivers that can be used with most hardware congurations. init
starts an initial hardware scanning process that determines the set of drivers suitable
for your hardware conguration. The names of the modules needed for the boot
64 Administration Guide
Page 79
process are written to INITRD_MODULES in /etc/sysconfig/kernel.
These names are used to generate a custom initramfs that is needed to boot the
system. If the modules are not needed for boot but for coldplug, the modules are
written to /etc/sysconfig/hardware/hwconfig-*. All devices that are
described with conguration les in this directory are initialized in the boot process.
Loading the Installation System or Rescue System
As soon as the hardware has been properly recognized, the appropriate drivers have
been loaded, and udev has created the device special les, init starts the installation
system, which contains the actual YaST installer, or the rescue system.
Starting YaST
Finally, init starts YaST, which starts package installation and system conguration.
7.2 The init Process
The program init is the process with process ID 1. It is responsible for initializing the
system in the required way. init is started directly by the kernel and resists signal 9,
which normally kills processes. All other programs are either started directly by init or
by one of its child processes.
init is centrally congured in the /etc/inittab le where the runlevels are dened
(see Section 7.2.1, “Runlevels” (page 66)). The le also species which services and
daemons are available in each of the runlevels. Depending on the entries in /etc/
inittab, several scripts are run by init. By default, the rst script that is started after
booting is /etc/init.d/boot. Once the system initialization phase is nished, the
system changes the runlevel to its default runlevel with the /etc/init.d/rc script.
For reasons of clarity, these scripts, called init scripts, all reside in the directory /etc/
init.d (see Section 7.2.2, “Init Scripts” (page 68)).
The entire process of starting the system and shutting it down is maintained by init.
From this point of view, the kernel can be considered a background process whose task
is to maintain all other processes and adjust CPU time and hardware access according
to requests from other programs.
Booting and Conguring a Linux System 65
Page 80
7.2.1 Runlevels
In Linux, runlevels dene how the system is started and what services are available in
the running system. After booting, the system starts as dened in /etc/inittab in
the line initdefault. Usually this is 3 or 5. See Table 7.1, “Available Runlevels”
(page 66). As an alternative, the runlevel can be specied 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 a the
single number 3 to the boot prompt.
Table 7.1
Available Runlevels
DescriptionRunlevel
System halt0
Single user modeS or 1
Local multiuser mode without remote network (NFS, etc.)2
Full multiuser mode with network3
User Dened, this is not used unless the administrator congures this runlevel.
4
Full multiuser mode with network and X display manager—KDM, GDM, or XDM
5
System reboot6
IMPORTANT: Avoid Runlevel 2 with a Partition Mounted via NFS
You should not use runlevel 2 if your system mounts a partition like /usr via
NFS. The system might behave unexpectedly if program les or libraries are
missing because the NFS service is not available in runlevel 2 (local multiuser
mode without remote network).
66 Administration Guide
Page 81
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 summarizes the most important commands in the runlevel area.
telinit 1 or shutdown now
The system changes to single user mode. This mode is used for system maintenance
and administration tasks.
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).
telinit 0 or shutdown -h now
The system halts.
telinit 6 or shutdown -r now
The system halts then reboots.
Runlevel 5 is the default runlevel in all SUSE Linux Enterprise Server standard installations. Users are prompted for login with a graphical interface or the default user is
logged in automatically. If the default runlevel is 3, the X Window System must be
congured properly, as described in Chapter 12, The X Window System (page 145), before
the runlevel can be switched to 5. If this is done, check whether the system works in
the desired way by entering telinit 5. If everything turns out as expected, you can
use YaST to set the default runlevel to 5.
WARNING: Errors in /etc/inittab May Result in a Faulty System Boot
If /etc/inittab is damaged, the system might not boot properly. Therefore,
be extremely careful while editing /etc/inittab. Always let init reread
/etc/inittab with the command telinit q before rebooting the machine.
Booting and Conguring a Linux System 67
Page 82
Generally, two things happen when you change runlevels. First, stop scripts of the
current runlevel 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:
1.
The administrator (root) requests init to change to a different runlevel by entering
telinit 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 (old runlevel was 3) and start with a K. The number
following K species 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.
When changing into the same runlevel as the current runlevel, init only checks /etc/
inittab for changes and starts the appropriate steps, for example, for starting a
getty on another interface. The same functionality may be achieved with the command
telinit q.
7.2.2 Init Scripts
There are two types of scripts in /etc/init.d:
Scripts Executed Directly by init
This is the case only during the boot process or if an immediate system shutdown
is initiated (power failure or a user pressing Ctrl + Alt + Del). For IBM System z
systems, this is the case only during the boot process or if an immediate system
shutdown is initiated (power failure or via “signal quiesce”). The execution of these
scripts is dened in /etc/inittab.
68 Administration Guide
Page 83
Scripts Executed Indirectly by init
These are run when changing the runlevel and always call the master script
/etc/init.d/rc, which guarantees the correct order of the relevant scripts.
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 understand the parameters
start and stop. The scripts also understand the restart, reload,
force-reload, and status options. These different options are explained in Ta-
ble 7.2, “Possible init Script Options” (page 69). Scripts that are run directly by init do
not have these links. They are run independently from the runlevel when needed.
Table 7.2
Possible init Script Options
DescriptionOption
Start service.
start
Stop service.
stop
If the service is running, stop it then restart it. If it is
not running, start it.
restart
Reload the conguration without stopping and restarting
the service.
reload
Reload the conguration if the service supports this.
Otherwise, do the same as if restart had been given.
force-reload
Show the current status of service.
status
Links in each runlevel-specic 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 the insserv(8) man page for details.
Booting and Conguring a Linux System 69
Page 84
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 chkcong, described in the
chkcong(8) 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 mounted 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 conguration 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 block special 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. Otherwise, blogd buffers all screen data until /var becomes
available. Get further information about blogd on the blogd(8) man page.
The boot script is also responsible for starting all the scripts in /etc/init.d/
boot.d with names that starts with S. There, the le systems are checked and
loop devices are congured 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.
boot.local
Here, enter additional commands to execute at boot before changing into a runlevel.
It can be compared to AUTOEXEC.BAT on DOS systems.
halt
This script is only executed while changing into runlevel 0 or 6. Here, it is executed
either as halt or as reboot. 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 halt.local script.
70 Administration Guide
Page 85
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 specications of the LSB and to the man pages of init, init.d, chkconfig,
and insserv. Additionally consult the man pages of startproc and killproc.
WARNING: Faulty init Scripts May Halt Your System
Faulty init scripts may hang your machine up. Edit such scripts with great care
and, if possible, subject them to heavy testing in the multiuser environment.
Find useful information about init scripts in Section 7.2.1, “Runlevels” (page 66).
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 lenames, 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 Example 7.1, “A Minimal INIT INFO Block” (page 71).
Example 7.1
A Minimal INIT INFO Block
### BEGIN INIT INFO
# Provides: FOO
# Required-Start: $syslog $remote_fs
# Required-Stop: $syslog $remote_fs
# Default-Start: 3 5
# Default-Stop: 0 1 2 6
# Description: Start FOO to allow XY and provide YZ
### END INIT INFO
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 started or stopped before
the service itself is started or 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
Booting and Conguring a Linux System 71
Page 86
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. The insserv program 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 7.2.3, “Conguring System Services (Runlevel) with YaST”
(page 72).
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.
7.2.3 Conguring System Services (Runlevel)
with YaST
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 sufcient 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.
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 run-
72 Administration Guide
Page 87
level 5 (full multiuser mode with network 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 7.1,
“Available Runlevels” (page 66)) as the new default. Additionally, use the table in this
window to enable or disable individual 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 dene the runlevels
in which the selected service or daemon should be running. Runlevel 4 is undened to
allow creation of a custom runlevel. A brief description of the currently selected service
or daemon is provided below the table overview.
WARNING: Faulty Runlevel Settings May Damage Your System
Faulty runlevel settings may make your system unusable. Before applying your
changes, make absolutely sure that you know their consequences.
Figure 7.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
Booting and Conguring a Linux System 73
Page 88
changes to the system or to restore the settings that existed before starting the runlevel
editor. Selecting Finish saves the changed settings to disk.
7.3 System Conguration via
/etc/syscong
The main conguration of SUSE Linux Enterprise Server is controlled by the conguration les in /etc/sysconfig. The individual les in /etc/sysconfig are
only read by the scripts to which they are relevant. This ensures that network settings,
for example, only need to be parsed by network-related scripts.
There are two ways to edit the system conguration. Either use the YaST syscong
Editor or edit the conguration les manually.
7.3.1 Changing the System Conguration
Using the YaST syscong Editor
The YaST syscong editor provides an easy-to-use front-end for system conguration.
Without any knowledge of the actual location of the conguration variable you need
to change, you can just use the built-in search function of this module, change the value
of the conguration variable as needed and let YaST take care of applying these changes,
updating congurations that depend on the values set in sysconfig and restarting
services.
WARNING: Modifying /etc/sysconfig/* Files Can Damage Your
Installation
Do not modify the /etc/sysconfig les if you lack previous experience
and knowledge. It could do considerable damage to your system. The les in
/etc/sysconfig include a short comment for each variable to explain what
effect they actually have.
74 Administration Guide
Page 89
Figure 7.2
System Conguration Using the syscong Editor
The YaST syscong dialog is split into three parts. The left part of the dialog shows a
tree view of all congurable 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 conguration le from which this variable originates. The dialog also
provides information about which conguration script is executed after changing the
variable and which new service is started as a result of the change. YaST prompts you
to conrm 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.
Booting and Conguring a Linux System 75
Page 90
7.3.2 Changing the System Conguration
Manually
To manually change the system conguration, proceed as follows
1
Become root.
2
Bring the system into single user mode (runlevel 1) with telinit 1.
3
Change the conguration les as needed with an editor of your choice.
If you do not use YaST to change the conguration les in /etc/sysconfig,
make sure that empty variable values are represented by two quotation marks
(KEYTABLE="") and that values with blanks in them are enclosed in quotation
marks. Values consisting of one word only do not need to be quoted.
4
Execute SuSEconfig to make sure that the changes take effect.
5
Bring your system back to the previous runlevel with a command like telinit
default_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 conguration. 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.
TIP: Conguring Automated System Conguration
To disable the automated system conguration by SuSEcong, set the variable
ENABLE_SUSECONFIG in /etc/sysconfig/suseconfig to no. Do not
disable SuSEcong if you want to use the SUSE installation support. It is also
possible to disable the autoconguration partially.
76 Administration Guide
Page 91
8
The Boot Loader GRUB
This chapter describes how to congure GRUB, the boot loader used in SUSE® Linux
Enterprise Server. A special YaST module is available for conguring all settings. If
you are not familiar with the subject of booting in Linux, read the following sections
to acquire some background information. This chapter also describes some of the
problems frequently encountered when booting with GRUB and their solutions.
NOTE: No GRUB on machines using UEFI
GRUB will routinely be installed on machines equipped with a traditional BIOS
and on UEFI (Unied Extensible Firmware Interface) machines using a Compatibility Support Module (CSM). On UEFI machines without enabled CSM, eLILO
will automatically be installed (provided DVD1 booted successfully). Refer to
the eLILO documentation at /usr/share/doc/packages/elilo/ on your
system for details.
This chapter focuses on boot management and the conguration of the boot loader
GRUB. The boot procedure as a whole is outlined in Chapter 7, Booting and Conguring
a Linux System (page 61). A boot loader represents the interface between the machine
(BIOS) and the operating system (SUSE Linux Enterprise Server). The conguration
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:
Master Boot Record
The structure of the MBR is dened by an operating system–independent convention. The rst 446 bytes are reserved for the program code. They typically hold
The Boot Loader GRUB 77
Page 92
part of a boot loader program or an operating system selector. The next 64 bytes
provide space for a partition table of up to four entries. The partition table contains
information about the partitioning of the hard disk and the le system types. The
operating system needs this table for handling the hard disk. With conventional
generic code in the MBR, exactly one partition must be marked active. The last
two bytes of the MBR must contain a static “magic number” (AA55). An MBR
containing a different value is regarded as invalid by some BIOSes, so is not considered for booting.
Boot Sectors
Boot sectors are the rst sectors of hard disk partitions with the exception of the
extended partition, which merely serves as a “container” for other partitions. These
boot sectors have 512 bytes of space for code used to boot an operating system installed in the respective partition. This applies to boot sectors of formatted DOS,
Windows, and OS/2 partitions, which also contain some basic important data of
the le system. In contrast, the boot sectors of Linux partitions are initially empty
after setting up a le system other than XFS. Therefore, a Linux partition is not
bootable by itself, even if it contains a kernel and a valid root le system. A boot
sector with valid code for booting the system has the same magic number as the
MBR in its last two bytes (AA55).
8.1 Booting with GRUB
GRUB (Grand Unied Bootloader) comprises two stages. Stage 1 consists of 512 bytes
and its only task is to load the second stage of the boot loader. Subsequently, stage 2
is loaded. This stage contains the main part of the boot loader.
In some congurations, an intermediate stage 1.5 can be used, which locates and loads
stage 2 from an appropriate le system. If possible, this method is chosen by default
on installation or when initially setting up GRUB with YaST.
Stage 2 is able to access many le systems. Currently, Ext2, Ext3, ReiserFS, Minix,
and the DOS FAT le system used by Windows are supported. To a certain extent,
XFS, and UFS and FFS used by BSD systems are also supported. Since version 0.95
GRUB is also able to boot from a CD or DVD containing an ISO 9660 standard le
system pursuant to the “El Torito” specication. Even before the system is booted,
GRUB can access le systems of supported BIOS disk devices (oppy disks or hard
disks, CD drives and DVD drives detected by the BIOS). Therefore, changes to the
78 Administration Guide
Page 93
GRUB conguration le (menu.lst) do not require a new installation of the boot
manager. When the system is booted, GRUB reloads the menu le with the valid paths
and partition data of the kernel or the initial RAM disk (initrd) and locates these
les.
The actual conguration of GRUB is based on three les that are described below:
/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 “Editing Menu Entries during the Boot
Procedure” (page 84) for details).
/boot/grub/device.map
This le translates device names from the GRUB and BIOS notation to Linux device
names.
/etc/grub.conf
This le contains the commands, parameters and options the GRUB shell needs
for installing the boot loader correctly.
GRUB can be controlled in various ways. Boot entries from an existing conguration
can be selected from the graphical menu (splash screen). The conguration 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 interactively at a kind of input prompt (see Section “Editing Menu Entries
during the Boot Procedure” (page 84)). 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 conguration.
GRUB actually exists in two versions: as a boot loader and as a normal Linux program
in /usr/sbin/grub. This program 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 oppy disk is integrated in GRUB in the form of the commands
install and setup. This is available in the GRUB shell when Linux is loaded.
The Boot Loader GRUB 79
Page 94
8.1.1 The GRUB Boot Menu
The graphical splash screen with the boot menu is based on the GRUB conguration
le /boot/grub/menu.lst, which contains all information about all partitions or
operating systems that can be booted by the menu.
Every time the system is booted, GRUB loads the menu le from the le system. For
this reason, GRUB does not need to be reinstalled after every change to the le. Use
the YaST boot loader to modify the GRUB conguration as described in Section 8.2,
“Conguring the Boot Loader with YaST” (page 87).
The menu le contains commands. The syntax is very simple. Every line contains a
command followed by optional parameters separated by spaces like in the shell. For
historical reasons, some commands permit an = in front of the rst parameter. Comments
are introduced by a hash (#).
To identify the menu items in the menu overview, set a title for every entry. The
text (including any spaces) following the keyword title is displayed as a selectable
option in the menu. All commands up to the next title are executed when this menu
item is selected.
The simplest case is the redirection to boot loaders of other operating systems. The
command is chainloader and the argument is usually the boot block of another
partition, in GRUB block notation. For example:
chainloader (hd0,3)+1
The device names in GRUB are explained in Section “Naming Conventions for Hard
Disks and Partitions” (page 81). This example species 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 specied 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.
80 Administration Guide
Page 95
The command root simplies the specication 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 specied until the next root com-
mand.
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 specied chain loader.
After writing all menu entries, dene 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 “An Example Menu File” (page 82).
Naming Conventions for Hard Disks and Partitions
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:
(hd0,0) first primary partition of the first hard disk
(hd0,1) second primary partition
(hd0,2) third primary partition
(hd0,3) fourth primary partition (usually an extended partition)
(hd0,4) first logical partition
(hd0,5) second logical partition
Being dependent on BIOS devices, GRUB does not distinguish between 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 Boot Loader GRUB 81
Page 96
the le device.map, which can be edited if necessary. Information about the le
device.map is available in Section 8.1.2, “The File device.map” (page 85).
A complete GRUB path consists of a device name written in parentheses and the path
to the le in the le system in the specied partition. The path begins with a slash. For
example, the bootable kernel could be specied as follows on a system with a single
IDE hard disk containing Linux in its rst partition:
(hd0,0)/boot/vmlinuz
An Example Menu File
The following example shows the structure of a GRUB menu le. The example installation has a Linux boot partition under /dev/sda5, a root partition under /dev/
sda7 and a Windows installation under /dev/sda1.
gfxmenu (hd0,4)/boot/message
color white/blue black/light-gray
default 0
timeout 8
title linux
root (hd0,4)
kernel /boot/vmlinuz root=/dev/sda7 vga=791 resume=/dev/sda9
initrd /boot/initrd
title windows
rootnoverify (hd0,0)
chainloader +1
title floppy
rootnoverify (hd0,0)
chainloader (fd0)+1
title failsafe
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
The rst block denes the conguration of the splash screen:
gfxmenu (hd0,4)/message
The background image message is located in the top directory of the /dev/
sda5 partition.
82 Administration Guide
Page 97
color white/blue black/light-gray
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.
default 0
The rst menu entry title linux is the one to boot by default.
timeout 8
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.
•
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 here. The root partition is specied according to the
Linux naming convention (/dev/sda7/) because this information is read by the
kernel and has nothing to do with GRUB. The initrd is also located in the rst
logical partition of the rst hard disk.
• The second entry is responsible for loading Windows. Windows is booted from the
rst partition of the rst hard disk (hd0,0). The command chainloader +1
causes GRUB to read and execute the rst sector of the specied partition.
• The next entry enables booting from oppy disk without modifying the BIOS settings.
•
The boot option failsafe starts Linux with a selection of kernel parameters that
enables Linux to boot even on problematic systems.
The menu le can be changed whenever necessary. GRUB then uses the modied settings during the next boot. Edit the le permanently using YaST or an editor of your
choice. Alternatively, make temporary changes interactively using the edit function of
GRUB. See Section “Editing Menu Entries during the Boot Procedure” (page 84).
The Boot Loader GRUB 83
Page 98
Editing Menu Entries during the Boot Procedure
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.
IMPORTANT: Keyboard Layout during the Boot Procedure
The US keyboard layout is the only one available when booting. See Figure “US
Keyboard Layout” (↑System Analysis and Tuning Guide).
Editing menu entries facilitates the repair of a defective system that can no longer be
booted, because the faulty conguration le of the boot loader can be circumvented by
manually entering parameters. Manually entering parameters during the boot procedure
is also useful for testing new settings without impairing the native system.
After activating the editing mode, use the arrow keys to select the menu entry of the
conguration to edit. To make the conguration editable, press E again. In this way,
edit incorrect partitions or path specications before they have a negative effect on the
boot process. Press Enter to exit the editing mode and return to the menu. Then press
B to boot this entry. Further possible actions are displayed in the help text at the bottom.
To enter changed boot options permanently and pass them to the kernel, open the le
menu.lst as the user root and append the respective kernel parameters to the existing
line, separated by spaces:
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.
Alternatively, this change can also be made with the YaST boot loader module. Append
the new parameters to the existing line, separated by spaces.
84 Administration Guide
Page 99
8.1.2 The File device.map
The le device.map maps GRUB and BIOS device names to Linux device names.
In a mixed system containing IDE and SCSI hard disks, GRUB must try to determine
the boot sequence by a special procedure, because GRUB may not have access to the
BIOS information on the boot sequence. GRUB saves the result of this analysis in the
le /boot/grub/device.map. For a system on which the boot sequence in the
BIOS is set to IDE before SCSI, the le device.map could appear as follows:
(fd0) /dev/fd0
(hd0) /dev/sda
(hd1) /dev/sdb
Because the order of 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 sequence in the BIOS and use the GRUB prompt to modify it
temporarily, if necessary. After the Linux system has booted, the le device.map
can be edited permanently with the YaST boot loader module or an editor of your
choice.
NOTE: Maximum Number of Hard Disks
To address a hard disk, GRUB uses BIOS services. This is done via the software
interrupt Int13h. Since Int13h is limited to handling a maximum number of
eight disks, GRUB can only boot from the disks handled by Int13h, even if there
are more disks present (which is often the case on multipath systems). The
device.map le created during the installation will therefore only contain a
maximum number of the eight disks handled by Int13h.
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:
grub --batch < /etc/grub.conf
The Boot Loader GRUB 85
Page 100
8.1.3 The File /etc/grub.conf
The third important GRUB conguration 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:
setup --stage2=/boot/grub/stage2 --force-lba (hd0,1) (hd0,1)
quit
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 system. Some BIOSes have a faulty LBA support implementation,
--force-lba provides a solution to ignore them.
8.1.4 Setting a Boot Password
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.
IMPORTANT: Boot Password and Splash Screen
If you use a boot password for GRUB, the usual splash screen is not displayed.
As the user root, proceed as follows to set a boot password:
1
At the root prompt, encrypt the password using grub-md5-crypt:
# 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
color white/blue black/light-gray
default 0
timeout 8
password --md5 $1$lS2dv/$JOYcdxIn7CJk9xShzzJVw/
86 Administration Guide
Loading...