SUSE Linux Enterprise
www.novell.com11 SP1
November08,2010 Administration Guide
Server
Administration Guide
All content is copyright © 2006–2010 Novell, Inc. All rights reserved.
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.
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 . . . . . . . . . . . . . . . . . . . . 30
5 Bash and Bash Scripts 43
5.1 What is “The Shell”? . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2 Writing Shell Scripts . . . . . . . . . . . . . . . . . . . . . . . . 49
5.3 Redirecting Command Events . . . . . . . . . . . . . . . . . . . . 50
5.4 Using Aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.5 Using Variables in Bash . . . . . . . . . . . . . . . . . . . . . . 51
5.6 Grouping And Combining Commands . . . . . . . . . . . . . . . . 54
5.7 Working with Common Flow Constructs . . . . . . . . . . . . . . . 55
5.8 For More Information . . . . . . . . . . . . . . . . . . . . . . . 56
Part II System 57
6 32-Bit and 64-Bit Applications in a 64-Bit System Environment 59
6.1 Runtime Support . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.2 Software Development . . . . . . . . . . . . . . . . . . . . . . 61
6.3 Software Compilation on Biarch Platforms . . . . . . . . . . . . . . 61
6.4 Kernel Specications . . . . . . . . . . . . . . . . . . . . . . . 63
7 Booting and Conguring a Linux System 65
7.1 The Linux Boot Process . . . . . . . . . . . . . . . . . . . . . . 65
7.2 The init Process . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.3 System Conguration via /etc/syscong . . . . . . . . . . . . . . . 78
8 The Boot Loader GRUB 81
8.1 Booting with GRUB . . . . . . . . . . . . . . . . . . . . . . . . 82
8.2 Conguring the Boot Loader with YaST . . . . . . . . . . . . . . . . 93
8.3 Uninstalling the Linux Boot Loader . . . . . . . . . . . . . . . . . 98
8.4 Creating Boot CDs . . . . . . . . . . . . . . . . . . . . . . . . 99
8.5 The Graphical SUSE Screen . . . . . . . . . . . . . . . . . . . . 100
8.6 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . 101
8.7 For More Information . . . . . . . . . . . . . . . . . . . . . . 102
9 Special System Features 103
9.1 Information about Special Software Packages . . . . . . . . . . . . 103
9.2 Virtual Consoles . . . . . . . . . . . . . . . . . . . . . . . . . 110
9.3 Keyboard Mapping . . . . . . . . . . . . . . . . . . . . . . . . 111
9.4 Language and Country-Specic Settings . . . . . . . . . . . . . . . 112
10 Printer Operation 117
10.1 The Workow of the Printing System . . . . . . . . . . . . . . . . 119
10.2 Methods and Protocols for Connecting Printers . . . . . . . . . . . . 119
10.3 Installing the Software . . . . . . . . . . . . . . . . . . . . . . 120
10.4 Network Printers . . . . . . . . . . . . . . . . . . . . . . . . . 121
10.5 Printing from the Command Line . . . . . . . . . . . . . . . . . . 123
10.6 Special Features in SUSE Linux Enterprise Server . . . . . . . . . . . 124
10.7 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . 126
11 Dynamic Kernel Device Management with udev 135
11.1
The /dev Directory . . . . . . . . . . . . . . . . . . . . . . . 135
11.2 Kernel uevents and udev . . . . . . . . . . . . . . . . . . . . . 136
11.3 Drivers, Kernel Modules and Devices . . . . . . . . . . . . . . . . 136
11.4 Booting and Initial Device Setup . . . . . . . . . . . . . . . . . . 137
11.5 Monitoring the Running udev Daemon . . . . . . . . . . . . . . . 137
11.6 Inuencing Kernel Device Event Handling with udev Rules . . . . . . . 139
11.7 Persistent Device Naming . . . . . . . . . . . . . . . . . . . . . 146
11.8 Files used by udev . . . . . . . . . . . . . . . . . . . . . . . . 146
11.9 For More Information . . . . . . . . . . . . . . . . . . . . . . 147
12 The X Window System 149
12.1 Manually Conguring the X Window System . . . . . . . . . . . . . 149
12.2 Installing and Conguring Fonts . . . . . . . . . . . . . . . . . . 156
12.3 For More Information . . . . . . . . . . . . . . . . . . . . . . 162
13 Accessing File Systems with FUSE 163
13.1 Conguring FUSE . . . . . . . . . . . . . . . . . . . . . . . . 163
13.2 Available FUSE Plug-ins . . . . . . . . . . . . . . . . . . . . . . 163
13.3 For More Information . . . . . . . . . . . . . . . . . . . . . . 164
Part III Mobile Computers 165
14 Mobile Computing with Linux 167
14.1 Laptops . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
14.2 Mobile Hardware . . . . . . . . . . . . . . . . . . . . . . . . 175
14.3 Cellular Phones and PDAs . . . . . . . . . . . . . . . . . . . . . 176
14.4 For More Information . . . . . . . . . . . . . . . . . . . . . . 176
15 Wireless LAN 177
15.1 WLAN Standards . . . . . . . . . . . . . . . . . . . . . . . . . 177
15.2 Operating Modes . . . . . . . . . . . . . . . . . . . . . . . . 178
15.3 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . 179
15.4 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
15.5 Conguration with YaST . . . . . . . . . . . . . . . . . . . . . . 181
15.6 Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
15.7 Tips and Tricks for Setting Up a WLAN . . . . . . . . . . . . . . . 186
15.8 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . 187
15.9 For More Information . . . . . . . . . . . . . . . . . . . . . . 189
16 Power Management 191
16.1 Power Saving Functions . . . . . . . . . . . . . . . . . . . . . . 191
16.2 ACPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
16.3 Rest for the Hard Disk . . . . . . . . . . . . . . . . . . . . . . 196
16.4 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . 198
16.5 For More Information . . . . . . . . . . . . . . . . . . . . . . 200
17 Using Tablet PCs 201
17.1 Installing Tablet PC Packages . . . . . . . . . . . . . . . . . . . . 202
17.2 Conguring Your Tablet Device . . . . . . . . . . . . . . . . . . . 203
17.3 Using the Virtual Keyboard . . . . . . . . . . . . . . . . . . . . 204
17.4 Rotating Your Display . . . . . . . . . . . . . . . . . . . . . . . 205
17.5 Using Gesture Recognition . . . . . . . . . . . . . . . . . . . . 205
17.6 Taking Notes and Sketching with the Pen . . . . . . . . . . . . . . 208
17.7 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . 210
17.8 For More Information . . . . . . . . . . . . . . . . . . . . . . 211
Part IV Services 213
18 Basic Networking 215
18.1 IP Addresses and Routing . . . . . . . . . . . . . . . . . . . . . 218
18.2 IPv6—The Next Generation Internet . . . . . . . . . . . . . . . . 221
18.3 Name Resolution . . . . . . . . . . . . . . . . . . . . . . . . 231
18.4 Conguring a Network Connection with YaST . . . . . . . . . . . . 233
18.5 NetworkManager . . . . . . . . . . . . . . . . . . . . . . . . 256
18.6 Conguring a Network Connection Manually . . . . . . . . . . . . . 258
18.7 smpppd as Dial-up Assistant . . . . . . . . . . . . . . . . . . . . 273
19 SLP Services in the Network 277
19.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
19.2 Activating SLP . . . . . . . . . . . . . . . . . . . . . . . . . . 278
19.3 SLP Front-Ends in SUSE Linux Enterprise Server . . . . . . . . . . . . 278
19.4 Installation over SLP . . . . . . . . . . . . . . . . . . . . . . . 279
19.5 Providing Services via SLP . . . . . . . . . . . . . . . . . . . . . 279
19.6 For More Information . . . . . . . . . . . . . . . . . . . . . . 280
20 Time Synchronization with NTP 281
20.1 Conguring an NTP Client with YaST . . . . . . . . . . . . . . . . 281
20.2 Manually Conguring ntp in the Network . . . . . . . . . . . . . . 285
20.3 Dynamic Time Synchronization at Runtime . . . . . . . . . . . . . . 285
20.4 Setting Up a Local Reference Clock . . . . . . . . . . . . . . . . . 286
20.5 Clock Synchronization to an External Time Reference (ETR) . . . . . . . 287
21 The Domain Name System 289
21.1 DNS Terminology . . . . . . . . . . . . . . . . . . . . . . . . 289
21.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
21.3 Conguration with YaST . . . . . . . . . . . . . . . . . . . . . . 290
21.4 Starting the Name Server BIND . . . . . . . . . . . . . . . . . . 300
21.5 The Conguration File /etc/named.conf . . . . . . . . . . . . . . . 301
21.6 Zone Files . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
21.7 Dynamic Update of Zone Data . . . . . . . . . . . . . . . . . . . 310
21.8 Secure Transactions . . . . . . . . . . . . . . . . . . . . . . . 310
21.9 DNS Security . . . . . . . . . . . . . . . . . . . . . . . . . . 312
21.10 For More Information . . . . . . . . . . . . . . . . . . . . . . 312
22 DHCP 313
22.1 Conguring a DHCP Server with YaST . . . . . . . . . . . . . . . . 314
22.2 DHCP Software Packages . . . . . . . . . . . . . . . . . . . . . 325
22.3 The DHCP Server dhcpd . . . . . . . . . . . . . . . . . . . . . 326
22.4 For More Information . . . . . . . . . . . . . . . . . . . . . . 329
23 Using NetworkManager 331
23.1 Use Cases for NetworkManager . . . . . . . . . . . . . . . . . . 331
23.2 Enabling NetworkManager . . . . . . . . . . . . . . . . . . . . 332
23.3 Conguring Network Connections . . . . . . . . . . . . . . . . . 333
23.4 Using KNetworkManager . . . . . . . . . . . . . . . . . . . . . 336
23.5 Using GNOME NetworkManager Applet . . . . . . . . . . . . . . . 340
23.6 NetworkManager and VPN . . . . . . . . . . . . . . . . . . . . 342
23.7 NetworkManager and Security . . . . . . . . . . . . . . . . . . . 343
23.8 Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . 344
23.9 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . 346
23.10 For More Information . . . . . . . . . . . . . . . . . . . . . . 347
24 Samba 349
24.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
24.2 Starting and Stopping Samba . . . . . . . . . . . . . . . . . . . 351
24.3 Conguring a Samba Server . . . . . . . . . . . . . . . . . . . . 351
24.4 Conguring Clients . . . . . . . . . . . . . . . . . . . . . . . . 358
24.5 Samba as Login Server . . . . . . . . . . . . . . . . . . . . . . 359
24.6 Samba Server in the Network with Active Directory . . . . . . . . . . 360
24.7 For More Information . . . . . . . . . . . . . . . . . . . . . . 361
25 Sharing File Systems with NFS 363
25.1 Installing the Required Software . . . . . . . . . . . . . . . . . . 363
25.2 Importing File Systems with YaST . . . . . . . . . . . . . . . . . . 364
25.3 Importing File Systems Manually . . . . . . . . . . . . . . . . . . 365
25.4 Exporting File Systems with YaST . . . . . . . . . . . . . . . . . . 367
25.5 Exporting File Systems Manually . . . . . . . . . . . . . . . . . . 372
25.6 NFS with Kerberos . . . . . . . . . . . . . . . . . . . . . . . . 375
25.7 For More Information . . . . . . . . . . . . . . . . . . . . . . 375
26 File Synchronization 377
26.1 Available Data Synchronization Software . . . . . . . . . . . . . . . 377
26.2 Determining Factors for Selecting a Program . . . . . . . . . . . . . 379
26.3 Introduction to CVS . . . . . . . . . . . . . . . . . . . . . . . 382
26.4 Introduction to rsync . . . . . . . . . . . . . . . . . . . . . . . 384
26.5 For More Information . . . . . . . . . . . . . . . . . . . . . . 386
27 The Apache HTTP Server 387
27.1 Quick Start . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
27.2 Conguring Apache . . . . . . . . . . . . . . . . . . . . . . . 389
27.3 Starting and Stopping Apache . . . . . . . . . . . . . . . . . . . 404
27.4 Installing, Activating, and Conguring Modules . . . . . . . . . . . . 407
27.5 Getting CGI Scripts to Work . . . . . . . . . . . . . . . . . . . . 414
27.6 Setting Up a Secure Web Server with SSL . . . . . . . . . . . . . . 417
27.7 Avoiding Security Problems . . . . . . . . . . . . . . . . . . . . 423
27.8 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . 425
27.9 For More Information . . . . . . . . . . . . . . . . . . . . . . 426
28 Setting up an FTP server with YaST 429
28.1 Starting the FTP server . . . . . . . . . . . . . . . . . . . . . . 430
28.2 FTP General Settings . . . . . . . . . . . . . . . . . . . . . . . 431
28.3 FTP Performance Settings . . . . . . . . . . . . . . . . . . . . . 432
28.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . 432
28.5 Expert Settings . . . . . . . . . . . . . . . . . . . . . . . . . 433
28.6 For more information . . . . . . . . . . . . . . . . . . . . . . 433
29 The Squid Proxy Server 435
29.1 Some Facts about Proxy Caches . . . . . . . . . . . . . . . . . . 436
29.2 System Requirements . . . . . . . . . . . . . . . . . . . . . . . 437
29.3 Starting Squid . . . . . . . . . . . . . . . . . . . . . . . . . . 439
29.4 The /etc/squid/squid.conf Conguration File . . . . . . . . . . . . . 441
29.5 Conguring a Transparent Proxy . . . . . . . . . . . . . . . . . . 447
29.6 cachemgr.cgi . . . . . . . . . . . . . . . . . . . . . . . . . . 450
29.7 Cache Report Generation with Calamaris . . . . . . . . . . . . . . 452
29.8 For More Information . . . . . . . . . . . . . . . . . . . . . . 453
30 Web Based Enterprise Management using SFCB 455
30.1 Introduction and Basic Concept . . . . . . . . . . . . . . . . . . 455
30.2 Setting Up SFCB . . . . . . . . . . . . . . . . . . . . . . . . . 457
30.3 SFCB CIMOM Conguration . . . . . . . . . . . . . . . . . . . . 462
30.4 Advanced SFCB Tasks . . . . . . . . . . . . . . . . . . . . . . . 475
30.5 For More Details . . . . . . . . . . . . . . . . . . . . . . . . . 483
Part V Troubleshooting 485
31 Help and Documentation 487
31.1 Documentation Directory . . . . . . . . . . . . . . . . . . . . . 488
31.2 Man Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
31.3 Info Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
32 Common Problems and Their Solutions 493
32.1 Finding and Gathering Information . . . . . . . . . . . . . . . . . 493
32.2 Installation Problems . . . . . . . . . . . . . . . . . . . . . . . 496
32.3 Boot Problems . . . . . . . . . . . . . . . . . . . . . . . . . 506
32.4 Login Problems . . . . . . . . . . . . . . . . . . . . . . . . . 509
32.5 Network Problems . . . . . . . . . . . . . . . . . . . . . . . . 516
32.6 Data Problems . . . . . . . . . . . . . . . . . . . . . . . . . . 521
32.7 IBM System z: Using initrd as a Rescue System . . . . . . . . . . . . 534
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.
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.
System Analysis and Tuning Guide (↑System Analysis and Tuning Guide)
An administrator's guide for problem detection, resolution and optimization. Find
how to inspect and optimize your system by means of monitoring tools and how
to efciently manage resources. Also contains an overview of common problems
and solutions and of additional help and documentation resources.
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
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 product manuals in your installed system under /usr/
share/doc/manual or in the help centers of your desktop. Find the latest documentation updates at http://www.novell.com/documentation where you can
download PDF or HTML versions of the manuals for your product.
2 Feedback
Several feedback channels are available:
Bugs and Enhancement Requests
For services and support options available for your product, refer to http://www
.novell.com/services/.
To report bugs for a product component, please use http://support.novell
.com/additional/bugreport.html.
Submit enhancement requests at https://secure-www.novell.com/rms/
rmsTool?action=ReqActions.viewAddPage&return=www.
About This Guide xiii
User Comments
We want to hear your comments and suggestions about this manual and the other
documentation included with this product. Use the User Comments feature at the
bottom of each page in the online documentation or go to http://www.novell
.com/documentation/feedback.html 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
Part I. Support and Common
Tasks
YaST Online Update
Novell offers a continuous stream of software security updates for your product. By
default the update applet is used to keep your system up-to-date. Refer to Section “Keeping the System Up-to-date” (Chapter 9, Installing or Removing Software, ↑Deployment
Guide) for further information on the update applet. This chapter covers the alternative
tool for updating software packages: YaST Online Update.
The current patches for SUSE® Linux Enterprise Server are available from an update
software repository. If you have registered your product during the installation, an update
repository is 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. Alternativelly,
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.
1
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
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.
Procedure 1.1
Run Software > Online Update in YaST
1
All new patches (except the optional ones) that are currently available for your
2
system are already marked for installation. Click Accept or Apply to automatically
install them.
Conrm with Finish after the installation has completed. Your system is now
3
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.
Installing Patches with YaST Online Update
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.
4 Administration Guide
Figure 1.1
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 the relevant
packages have already been updated from another source).
YaST Online Update
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.
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
YaST Online Update 5
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
Patch List Filters
Available
Non-installed patches that apply to packages installed on your system.
YaST Online Update
6 Administration Guide
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 of the window. Here you can see a detailed patch description as well as the
versions available. You can also choose to Install optional patches—security and recommended patches are already preselected for installation.
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
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.
2
The YaST Support module calls supportconfig to gather system information.
Gathering System Information for Support 9
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.
Start YaST.
2
Open the Support module.
3
Click on Create report tarball.
4
Select an option from the radio button list. If you want to test it rst, use Only
5
gather a minimum amount of info. Proceed with Next.
Enter your contact information. Use your service request number from Step 1
6
(page 10) and enter it into the text eld labeled Novell 11 digit service request
number. Proceed with Next.
The information gathering begins. After the process is nished, continue with
7
Next.
Review the data collection and use Remove from Data if you do not need the re-
8
spective lename. Continue with Next.
Save your tarball. If you want to upload to the Novell customer center, make
9
sure Upload log les tarball into URL is activated. Finish the operation with
Next.
10 Administration Guide
2.2.2 Using Supportcong Directly to
Collect Information
To use supportconfig from the commandline, proceed as follows:
1
Open a shell and become root.
2
Run supportconfig without any options. This gathers the default system
information.
Wait for the tool to complete the operation.
3
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
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
1
Open the URL http://www.novell.com/center/eservice and create
a service request number.
Write down your 11 digit service request number. The following examples will
2
assume the service request number is 12345678901.
Click on Create report tarball in the YaST Support module window.
3
Select the Use custom radio button. Proceed with Next.
4
Enter your contact information, ll in Novell 11 digit service request number
5
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.
Submitting Information to Novell with YaST
12 Administration Guide
Proceed with Next. Information gathering starts. After the process is nished,
continue with Next.
Review the data collection and use Remove from Data to remove any les you
6
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.
Click Finish.
8
Procedure 2.2
1
Open the URL http://www.novell.com/center/eservice and create
Submitting Information to Novell with supportcong
a service request number.
Write down your 11 digit service request number. The following examples will
2
assume the service request number is 12345678901.
Servers with Internet connectivity:
3
To use the default upload target, run:
3a
supportconfig -ur 12345678901
For the secure upload target, use the following on one line:
3b
supportconfig -r 12345678901 -U
'https://secure-www.novell.com/upload?appname=supportconfig&file={tarball}'
Servers without Internet connectivity
4
Run the following:
4a
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
You can also attach the tarball to your service request using the service re-
4c
quest 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—Themanpage 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
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.
3
Figure 3.1
When you start YaST in text mode, the YaST Control Center appears (see Figure 3.1).
The main window consists of three areas. The left frame features the categories to which
the various modules belong. This frame is active when YaST is started and therefore
Main Window of YaST in Text Mode
YaST in Text Mode 15
it is marked by a bold white border. The active category is highlighted. The right frame
provides an overview of the modules available in the active category. The bottom frame
contains the buttons for Help and Quit.
When you start the YaST Control Center, the category Software is selected automatically. Use ↓ and ↑ to change the category. To select a module from the category, activate
the right frame with → and then use ↓ and ↑ to select the module. Keep the arrow keys
pressed to scroll through the list of available modules. The selected module is highligted.
Press Enter to start the active module.
Various buttons or selection elds in the module contain a highlighted letter (yellow
by default). Use Alt + highlighted_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 + highlighted_letter. In this case, you do not need
16 Administration Guide
to 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. Use the arrow keys (↑ and ↓) to navigate in the tree. Use
Space to open or close tree items. 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
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
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
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 package manager for installing, updating and removing
packages as well as for managing repositories. 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.
For more information on managing software from the command line, enter zypper
help or zypper help command or see the zypper(8) manpage. .
4.1.1 General Usage
The general syntax of Zypper is:
zypper [global-options] command [command-options] [arguments] ...
4
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
Additionally, you can choose from one or more global options by typing them just before
the command. For example, --non-interactive means running the command
without asking anything (automatically applying the default answers):
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 applying all needed
patches to the system without asking to conrm any licenses (they will automatically
be accepted):
zypper patch --auto-agree-with-licenses
Some commands require one or more arguments. When using the install command, for
example, you need to specify which package(s) to install:
zypper install mplayer
Some 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
Most Zypper commands have a dry-run option that does a simulation of the given
command. It can be used for test purposes.
zypper remove --dry-run MozillaFirefox
4.1.2 Installing and Removing Software with
Zypper
To install or remove packages use the following commands:
zypper install package
zypper remove package
Zypper knows various ways to address packages for the install and remove commands:
22 Administration Guide
by the exact package name
zypper in MozillaFirefox
by repository alias and package name
zypper in mozilla:MozillaFirefox
Where mozilla is the alias of the repository from which to install.
by package name using wildcards
The following command will install all packages that have names starting with
“Moz”. Use with care, especially when removing packages.
zypper in Moz*
by capability
If you, for example, would like to install a perl module without knowing the name
of the package, capabilities come in handy:
zypper in 'perl(Time::ParseDate)'
by capability and/or architecture and/or version
Together with a capability you can specify an architecture (such as i586 or
x86_64) and/or a version. The version must be preceded by an operator: < (lesser
than), <= (lesser than or equal), = (equal>, >= (greater than or equal), > (greater
than).
zypper in 'firefox.x86_64'
zypper in 'firefox>=3.5.3'
zypper in 'firefox.x86_64>=3.5.3'
by path
You can also specify a local or remote path to a package:
zypper in /tmp/install/MozillaFirefox.rpm
zypper in
http://download.opensuse.org/repositories/mozilla/SUSE_Factory/x86_64/MozillaFirefox-3.5.3-1.3.x86_64.rpm
To install and remove packages simultaneously use the +/- modiers. To install emacs
and remove vim simultaneously, use:
zypper install emacs -vim
To remove emacs and install vim simultaneously, use:
Managing Software with Command Line Tools 23
zypper remove emacs +vim
To prevent the package name starting with the - being interpreted as a command option,
always use it as the second argument. If this is not possible, precede it with --:
zypper install -emacs +vim # Wrong
zypper install vim -emacs # Correct
zypper install -- -emacs +vim # same as above
zypper remove emacs +vim # same as above
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.
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, may cause the
system to become unstable or stop working altogether.
Installing Source Packages
If you want to install the corresponding source package of a package, use:
zypper source-install package_name
That command will also install the build dependencies of the specied package. If you
do not want this, add the switch -D. To install only the build dependencies use -d.
zypper source-install -d package_name # source package only
zypper source-install -D package_name # build dependencies only
Of course, this will only work if you have the repository with the source packages enabled in your repository list (it is added by default, but not enabled). See Section 4.1.4,
“Managing Repositories with Zypper” (page 27) for details on repository management.
A list of all source packages available in your repositories can be obtained with:
zypper search -t srcpackage
24 Administration Guide
Utilities
To verify whether all dependencies are still fullled and to repair missing dependencies,
use:
zypper verify
In addition to dependencies that must be fullled, some packages “recommend” other
packages. These recommended packages are only installed if actually available. In case
recommended packages were made available after the recommending package has been
installed (by adding additional packages), use the following command:
zypper install-new-recommends
4.1.3 Updating Software with Zypper
There are three different ways to update software using Zypper: by installing patches,
by installing a new version of a package or by updating the entire distribution. The
latter is achieved with the zypper dist-upgrade command which is discussed
in Section “Distribution Upgrade with zypper” (Chapter 7, Updating SUSE Linux En-
terprise, ↑Deployment Guide).
Installing Patches
To install all ofcially released patches applying to 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 Server 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.
Zypper knows three different commands to query for the availability of patches:
zypper patch-check
Lists the number of needed patches (patches, that apply to your system but are not
yet installed)
~ # zypper patch-check
Loading repository data...
Managing Software with Command Line Tools 25
Reading installed packages...
5 patches needed (1 security patch)
zypper list-patches
Lists all needed patches (patches, that apply to your system but are not yet installed)
~ # zypper list-updates
Loading repository data...
Reading installed packages...
S | Repository | Name | Current | Available | Arch
--+------------+-------------------------------+---------+------------+------v | Updates | update-test-interactive | 0-2.35 | 0-9999.1.2 | noarch
v | Updates | update-test-optional | 0-2.35 | 0-9999.1.2 | noarch
v | Updates | update-test-reboot-needed | 0-2.35 | 0-9999.1.2 | noarch
v | Updates | update-test-relogin-suggested | 0-2.35 | 0-9999.1.2 | noarch
v | Updates | update-test-security | 0-2.35 | 0-9999.1.2 | noarch
zypper patches
Lists all patches available for SUSE Linux Enterprise Server, regardless of whether
they are already installed or apply to your installation.
It is also possible to list and install patches relevant to specic issues. To list specic
patches, use the zypper list-patches command with the following options:
-b
Lists all needed patches for Bugzilla issues.
--bugzilla[=number]
Lists needed patches for the Bugzilla issue with the specied number.
To install a patch for a specic issue, use command:
zypper patch --bugzilla=number
Installing Updates
If a repository contains only 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
26 Administration Guide
To update individual packages, specify the package with either the update or install
command:
zypper update package
zypper install package
A list of all new packages available can be obtained with the command:
zypper list-updates
NOTE: Differences between zypper update and zypper dist-upgrade
Choose zypper update to update packages to newer versions available for
your product version while maintaining system integrity. zypper update will
honor the following rules:
no vendor changes
no architecture changes
no downgrades
keep installed packages
To upgrade your installation to a new product version use zypper
dist-upgrade with the required repositories (see Section 4.1.4, “Managing
Repositories with Zypper” (page 27) for details). This command ensures that
all packages will be installed from the repositories currently enabled. This rule
is enforced, so packages might change vendor or architecture or even might
get downgraded. All packages that have unfullled dependencies after the
upgrade will be uninstalled.
4.1.4 Managing Repositories with Zypper
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
The result will look similar to the following output:
# | Alias | Name
| Enabled | Refresh
--+-----------------------------------+-----------------------------------+---------+--------
Managing Software with Command Line Tools 27
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.
By default, details as the URI or the priority of the repository is not displayed. Use the
following command to list all details:
Adding Repositories
To add a repository, run
zypper addrepo URI Alias
URI can either be an Internet repository, a network resource, a directory or a CD or
DVD (see http://en.opensuse.org/Libzypp/URI for details). 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.
Removing Repositories
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 3rd entry from the example, use the following command:
zypper removerepo 3
Modifying Repositories
Enable or disable repositories with zypper modifyrepo. You can also alter the
repository's properties (such as refreshing behavior, name or priority) with this command.
The following command will enable the repository name “updates”, turn on auto-refresh
and set it's priority to 20:
28 Administration Guide
zypper mr -er -p 20 'updates'
Modifying repositories is not limited to a single repository—you can also operate on
groups:
-a: all repositories
-l: local repositories
-t: remote repositories
-m TYPE: repositories of a certain type (TYPE can be one of the following: http, https,
ftp, cd, dvd, dir, le, cifs, smb, nfs, hd, iso)
To rename a repository alias, use the renamerepo command. The following example
changes the alias from “Mozilla Firefox” to just “refox”:
zypper renamerepo 'Mozilla Firefox' firefox
4.1.5 Querying Repositories and Packages
with Zypper
Zypper offers various methods to query repositories or packages. To get lists of all
products, patterns, packages or patches available, use the following commands:
zypper products
zypper patterns
zypper packages
zypper patches
To query all repositories for certain packages, use search. It works on package names,
capabilities or, optionally, on package summaries and descriptions. Using the wildcards
* and ? with the search term is allowed. By default, the search is not case-sensitive.
zypper se firefox # simple search for "firefox"
zypper se *fire* # using wildcards
zypper se -d fire # also search in package descriptions and summaries
zypper se -u firefix # only display packages not already installed
To search for packages which provide a special capability, use the command
what-provides. If you, for example, would like to know which package provides
the perl Module SVN::Core, use the following command:
zypper what-provides 'perl(SVN::Core)'
Managing Software with Command Line Tools 29
To query single packages, use info with an exact package name as an argument. It
displays detailed information about a package. Use the options --requires and
--recommends to also show what is required/recommended by the package:
zypper info --requires MozillaFirefox
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.
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.
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.
30 Administration Guide
4.2.1 Verifying Package Authenticity
RPM packages have a GnuPG signature. 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.
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
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 con-
guration 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.
Managing Software with Command Line Tools 31
•
.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
(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
32 Administration Guide
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
/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:
Managing Software with Command Line Tools 33
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.
NOTE: Ofcial Updates for SUSE Linux Enterprise Server
In order to make the download size of updates as small as possible, ofcial
updates for SUSE Linux Enterprise Server are not provided as Patch RPMs, but
as Delta RPM packages (see Section 4.2.4, “Delta RPM Packages” (page 34) for
details).
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
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:
34 Administration Guide
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 35).
Table 4.1
-i
-l
-f FILE
--dump
--provides
--requires, -R
The Most Important RPM Query Options
Package information
File list
Query the package that contains the le FILE (the full
path must be specied with 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)
List features of the package that another package can request with --requires
Capabilities the package requires
--scripts
For example, the command rpm -q -i wget displays the information shown in
Example 4.1, “rpm -q -i wget” (page 36).
Installation scripts (preinstall, postinstall, uninstall)
Managing Software with Command Line Tools 35
Example 4.1
Name : wget Relocations: (not relocatable)
Version : 1.11.4 Vendor: openSUSE
Release : 1.70 Build Date: Sat 01 Aug 2009
09:49:48 CEST
Install Date: Thu 06 Aug 2009 14:53:24 CEST Build Host: build18
Group : Productivity/Networking/Web/Utilities Source RPM:
wget-1.11.4-1.70.src.rpm
Size : 1525431 License: GPL v3 or later
Signature : RSA/8, Sat 01 Aug 2009 09:50:04 CEST, Key ID b88b2fd43dbdc284
Packager : http://bugs.opensuse.org
URL : http://www.gnu.org/software/wget/
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.
[...]
rpm -q -i wget
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.4.2.3-45.5
wget-1.11.4-1.70
If only part of the lename is known, use a shell script as shown in Example 4.2, “Script
to Search for Packages” (page 36). Pass the partial lename to the script shown as a
parameter when running it.
Example 4.2
#! /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.
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
36 Administration Guide
Script to Search for Packages
that have been changed since installation. rpm uses eight character symbols to give
some hints about the following changes:
Table 4.2
5
S
L
T
D
U
G
M
RPM Verify Options
MD5 check sum
File size
Symbolic link
Modication time
Major and minor device numbers
Owner
Group
Mode (permissions and le type)
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
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.
Managing Software with Command Line Tools 37
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
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.
38 Administration Guide
WARNING
Do not experiment with system components (glibc, rpm, sysvinit, etc.),
because this endangers the stability of your system.
The following example uses the wget.src.rpm package. After installing the source
package, you should have les similar to those in the following list:
/usr/src/packages/SOURCES/wget-1.11.4.tar.bz2
/usr/src/packages/SOURCES/wgetrc.patch
/usr/src/packages/SPECS/wget.spec
rpmbuild -bX /usr/src/packages/SPECS/wget.spec starts the compi-
lation. 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.
-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.
Managing Software with Command Line Tools 39
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.
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.
40 Administration Guide
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 41
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 (ash, csh,
ksh, zsh, …), 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 as an:
1. interactive login shell. This is used when logging in to a machine, invoking Bash
with the --login option or when logging in to a remote machine with SSH.
5
2. “ordinary” interactive shell. This is normally the case when starting xterm, konsole,
gnome-terminal or similar tools.
3. non-interactive shell. This is used when invoking a shell script at the commandline.
Bash and Bash Scripts 43
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
/etc/profile
/etc/profile.d/
~/.profile
Table 5.2
/etc/bash.bashrc
/etc/bash.bashrc
.local
Bash Conguration Files for Login Shells
Bash Conguration Files for Non-Login Shells
DescriptionFile
Do not modify this le, otherwise your modications can be destroyed during your next update!
Use this le if you extend /etc/profile/etc/profile.local
Contains system-wide conguration les for specic
programs
Insert user specic conguration for login shells
here
Do not modify this le, otherwise your modications can be destroyed during your next update!
Use this le to insert your system-wide modications for Bash only
~/bashrc
Additionally, Bash uses some more les:
Table 5.3
~/.bash_history
~/.bash_logout
44 Administration Guide
Special Files for Bash
Insert user specic conguration here
DescriptionFile
Contains a list of all commands you have been
typing
Executed when logging out
5.1.2 The Directory Structure
The following table provides a short overview of the most important higher-level directories that you nd on a Linux system. Find more detailed information about the directories and important subdirectories in the following list.
Table 5.4
/
/bin
/boot
/dev
/etc
/home
/lib
/media
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.
Static les of the boot loader.
Files needed to access host-specic devices.
Host-specic system conguration les.
Holds the home directories of all users who have accounts
on the system. However, root's home directory is not located in /home but in /root.
Essential shared libraries and kernel modules.
Mount points for removable media.
/mnt
/opt
/sbin
Mount point for temporarily mounting a le system.
Add-on application software packages.
Home directory for the superuser root./root
Essential system binaries.
Bash and Bash Scripts 45
ContentsDirectory
/srv
/tmp
/usr
/var
/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.
Data for services provided by the system.
Temporary les.
Secondary hierarchy with read-only data.
Variable data such as log les.
Only available if you have both Microsoft Windows* and
Linux installed on your system. Contains the Windows
data.
/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-
46 Administration Guide
guration data for their desktop in .kde or .kde4 . 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 the essential shared libraries needed to boot the system and to run the
commands in the root le system. The Windows equivalent for shared libraries are
DLL les.
/media
Contains mount points for removable media, such as CD-ROMs, USB sticks and
digital cameras (if they use USB). /media generally holds any type of drive except
the hard drive of your system. As soon as your removable medium has been inserted
or connected to the system and has been mounted, you can access it from here.
/mnt
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. The personal data of root is located here.
/sbin
As the s indicates, this directory holds utilities for the superuser. /sbin contains
the 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 47
/tmp
This directory is used by programs that require temporary storage of les.
/usr
/usr has nothing to do with users, but is the acronym for UNIX system resources.
The data in /usr is static, read-only data that can be shared among various hosts
compliant with the Filesystem Hierarchy Standard (FHS). This directory contains
all application 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
48 Administration Guide
an overview of the most important log les you can nd under /var/log/, refer
to Table 32.1, “Log Files” (page 494).
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
#!/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 corresponding 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 manually.
2. You can save the script wherever you want. However, it is a good idea to save it
in a directory where the shell can nd it. The search path in a shell is determined
by the environment variable PATH. Usually a normal user does not have write access
to /usr/bin. Therefore it is recommended to save your scripts in the users' directory ~/bin/. The above example gets the name hello.sh.
A Shell Script Printing a Text
3. The script needs executable permissions. Set the permissions with the following
command:
chmod +x ~/bin/hello.sh
Bash and Bash Scripts 49
If you have fulllled all of the above prerequisites, you can execute the script in the
following ways:
1. As Absolute Path The script can be executed with an absolute path. In our case,
it is ~/bin/hello.sh.
2.
Everywhere If the PATH environment variable contains the directory where
the script is located, you can execute the script just with hello.sh.
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 the variable:
read a < foo
50 Administration Guide
Command1 | Command2
Redirects the output of the left command as input for the right command. For example, the cat command outputs the content of the /proc/cpuinfo le. This
output is used by grep to lter only those lines which contain cpu:
cat /proc/cpuinfo | grep cpu
Every channel has a le descriptor: 0 (zero) for standard input, 1 for standard output
and 2 for standard error. It is allowed to insert this le descriptor before a < or > character. For example, the following line searches for a le starting with foo, but suppresses its errors by redirecting it to /dev/null:
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. Remove your alias with unalias and the
corresponding alias name.
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 to know
the value of a variable, insert the name of your variable as an argument:
printenv PATH
A variable, be it global or local, can also be viewed with echo:
echo $PATH
Bash and Bash Scripts 51
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"
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
HOME
HOST
LANG
PATH
PS1
PS2
PWD
USER
Useful Environment Variables
the home directory of the current user
the current host name
when a tool is localized, it uses the language from this environment variable. English can also be set to C
the search path of the shell, a list of directories separated by
colon
species the normal prompt printed before each command
species the secondary prompt printed when you execute a
multi-line command
current working directory
the current user
52 Administration Guide
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:
#!/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
Bash and Bash Scripts 53
${VAR%%pattern}
removes the longest possible match from the right:
file=/home/tux/book/book.tar.bz2
echo ${file%%.*}
/home/tux/book/book
${VAR/pattern_1/pattern_2}
substitutes the content of VAR from the pattern_1 with pattern_2:
file=/home/tux/book/book.tar.bz2
echo ${file/tux/wilber}
/home/wilber/book/book.tar.bz2
5.6 Grouping And Combining Commands
Shells allow 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
54 Administration Guide
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
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 command 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
Bash and Bash Scripts 55
echo "Found foo.txt"
fi
The test expression can also be abbreviated in angled brackets:
if [ -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
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
56 Administration Guide
Part II. System
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.
6
32-Bit and 64-Bit Applications in a 64-Bit System Environment 59
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. ◄
60 Administration Guide
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 61
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.
Use the 32-bit compiler:
1
CC="gcc -m32"
Instruct the linker to process 32-bit objects (always use gcc as the linker front-
2
end):
LD="gcc -m32"
Set the assembler to generate 32-bit objects:
3
AS="gcc -c -m32"
Specify linker ags, such as the location of 32-bit libraries, for example:
4
LDFLAGS="-L/usr/lib"
62 Administration Guide
Specify the location for the 32-bit object code libraries:
5
--libdir=/usr/lib
Specify the location for the 32-bit X libraries:
6
--x-libraries=/usr/lib
Not all of these variables are needed for every program. Adapt them to the respective
program.
An example configure call to compile a native 32-bit application on x86_64, ppc64
or System z could appear as follows:
CC="gcc -m32"
LDFLAGS="-L/usr/lib;"
./configure --prefix=/usr --libdir=/usr/lib --x-libraries=/usr/lib
make
make install
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.
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
32-Bit and 64-Bit Applications in a 64-Bit System Environment 63
the kernel-loadable module and the 32-bit compiled version of the kernel API
are available for this module.
64 Administration Guide
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 turning on the computer, the BIOS initializes the screen and keyboard
and tests the main memory. Up to this stage, the machine does not access any mass
storage media. Subsequently, the information about the current date, time, and the
most important peripherals are loaded from the CMOS values. When the rst hard
disk and its geometry are recognized, the system control passes from the BIOS to
the boot loader. If the BIOS supports network booting, it is also possible to 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.
7
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 65
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 81). 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 66). 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 is successful, the
initramfs is cleaned and the init program on the root le system is executed. For
more information about init, refer to Section 7.1.2, “init on initramfs” (page 67).
Find more information about udev in Chapter 11, Dynamic Kernel Device Manage-
ment with udev (page 135).
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 69).
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
66 Administration Guide
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 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 al-
ways 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 67
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 above:
Finding the Installation Medium
As you start the installation process, your machine loads an installation kernel and
a special initrd with the YaST installer on 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 66), 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
68 Administration Guide
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 is properly recognized, the appropriate drivers are loaded,
and udev creates the special device les, init starts the installation system with 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 70)). 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 72)).
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 to maintain
all other processes and adjust CPU time and hardware access according to requests
from other programs.
Booting and Conguring a Linux System 69
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 70). 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
4
5
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).
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.
Full multiuser mode with network and X display manager—KDM, GDM, or XDM
System reboot6
70 Administration Guide
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.
WARNING: Errors in /etc/inittab May Result in a Faulty System Boot
If /etc/inittab is damaged, the system may 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.
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:
Booting and Conguring a Linux System 71
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 (the 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.
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 run-
72 Administration Guide
level 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 73). Scripts that are run directly by init do
not have these links. They are run independently from the runlevel when needed.
Table 7.2
start
stop
restart
reload
force-reload
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.
Possible init Script Options
DescriptionOption
Start service.
Stop service.
If the service is running, stop it then restart it. If it is
not running, start it.
Reload the conguration without stopping and restarting
the service.
Reload the conguration if the service supports this.
Otherwise, do the same as if restart had been given.
Show the current status of service.
All of these settings may also be changed with the help of the YaST module. If you
need to check the status on the command line, use the tool chkconfig, described in
the 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.
Booting and Conguring a Linux System 73
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 start 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 is similar 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.
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
74 Administration Guide
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 70).
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 75).
Example 7.1
### 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
A Minimal INIT INFO Block
In the rst line of the INFO block, after Provides:, specify the name of the program
or service controlled by this init script. In the Required-Start: and
Required-Stop: lines, specify all services that need to be still running when the
service itself is stopped. This information is used later to generate the numbering of
script names, as found in the runlevel directories. After Default-Start: and
Default-Stop:, specify the runlevels in which the service should automatically be
started or stopped. Finally, for Description:, provide a short description of the
service in question.
To create the links from the runlevel directories (/etc/init.d/rc?.d/) to the
corresponding scripts in /etc/init.d/, enter the command insserv
new-script-name. The insserv program evaluates the INIT INFO header to create
Booting and Conguring a Linux System 75
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 76).
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 runlevel 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 70)) as the new default. Additionally, use the table in this
window to enable or disable individual services and daemons. The table lists the services
76 Administration Guide
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
With Start, Stop, or Refresh, decide whether a service should be activated. Refresh
status checks the current status. Set or Reset lets you select whether to apply your
changes to the system or to restore the settings that existed before starting the runlevel
editor. Selecting Finish saves the changed settings to disk.
System Services (Runlevel)
Booting and Conguring a Linux System 77
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 without 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.
78 Administration Guide
Figure 7.2
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.
System Conguration Using the syscong Editor
Booting and Conguring a Linux System 79
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.
Change the conguration les as needed with an editor of your choice.
3
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.
80 Administration Guide
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 65). 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.
8
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 81
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
82 Administration Guide
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 four 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 88) 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.
/etc/sysconfig/bootloader
This le is read by the perl-bootloader library which is used when conguring the
bootloader with YaST and every time a new kernel is installed. It contains conguration options (such as kernel parameters) that will be added by default to the
bootloader conguration le.
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 88)). 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.
The Boot Loader GRUB 83
GRUB actually exists in two versions: as a boot loader and as a normal Linux program
in /usr/sbin/grub. The latter is referred to as the GRUB shell. It provides an em-
ulation 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 command setup.
This is available in the GRUB shell when Linux is loaded.
8.1.1 The File //boot/grub/menu.lst
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 93).
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 85). This example species the rst block of the fourth
partition of the rst hard disk.
84 Administration Guide
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.
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 86).
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
The Boot Loader GRUB 85
(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 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 89).
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)
86 Administration Guide
Loading...