3103 Manual

3103

Novell Training Services

www.novell.com

AU THO RIZED CO UR SEWARE

Part # 100-005205-001-REV A Version 1 Novell, Inc. Copyright 2009-CNI USE ONLY-1 HARDCOPY PERMITTED. NO OTHER PRINTING, COPYING, OR DISTRIBUTION ALLOWED.

Novell Training Services (en) 15 April 2009

SUSE Linux Enterprise Server 11 Administration Manual


Legal Notices Novell, Inc., makes no representations or warranties with respect to the contents or use of this documentation, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc., reserves the right to revise this publication and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. Further, Novell, Inc., makes no representations or warranties with respect to any software, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc., reserves the right to make changes to any and all parts of Novell software, at any time, without any obligation to notify any person or entity of such changes. Any products or technical information provided under this Agreement may be subject to U.S. export controls and the trade laws of other countries. You agree to comply with all export control regulations and to obtain any required licenses or classification to export, re-export or import deliverables. You agree not to export or re-export to entities on the current U.S. export exclusion lists or to any embargoed or terrorist countries as specified in the U.S. export laws. You agree to not use deliverables for prohibited nuclear, missile, or chemical biological weaponry end uses. See the Novell International Trade Services Web page (http:/ /www.novell.com/info/exports/) for more information on exporting Novell software. Novell assumes no responsibility for your failure to obtain any necessary export approvals. Copyright © 2008 Novell, Inc. All rights reserved. No part of this publication may be reproduced, photocopied, stored on a retrieval system, or transmitted without the express written consent of the publisher. Novell, Inc., has intellectual property rights relating to technology embodied in the product that is described in this document. In particular, and without limitation, these intellectual property rights may include one or more of the U.S. patents listed on the Novell Legal Patents Web page (http://www.novell.com/ company/legal/patents/) and one or more additional patents or pending patent applications in the U.S. and in other countries. Novell, Inc. 404 Wyman Street, Suite 500 Waltham, MA 02451 U.S.A. www.novell.com Online Documentation: To access the latest online documentation for this and other Novell products, see the Novell Documentation Web page (http://www.novell.com/documentation).

Novell Trademarks For Novell trademarks, see the Novell Trademark and Service Mark list (http:// www.novell.com/company/legal/trademarks/tmlist.html).

Third-Party Materials All third-party trademarks are the property of their respective owners.

Novell, Inc. Copyright 2009-CNI USE ONLY-1 HARDCOPY PERMITTED. NO OTHER PRINTING, COPYING, OR DISTRIBUTION ALLOWED.

SECTION 1 Objective 1

Exercise 1-1 Objective 2



Exercise 1-4


Exercise 2-1

Version 1

Introduction

11

Enable Fundamental Network Services

17

Configure NFS (Network File System)

18

NFS Background. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NFS Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NFS Client Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Automounter Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NFS System Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Set Up and Manage Network File System (NFS). . . . . . . . . . . . . . . . . . . . . . . . . . Configure Time on SUSE Linux Enterprise Server 11

Time Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Synchronize Time with hwclock or netdate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Network Time Protocol (NTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Synchronize Time with NTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configure ntpd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enable the Extended Internet Daemon (xinetd)

What xinetd Is . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configure xinetd with YaST. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Manage xinetd Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configure the Internet Daemon (xinetd). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enable an FTP Server

The Role of an FTP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How FTP Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Advantages of PureFTPd Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installation of PureFTPd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration of PureFTPd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Management of PureFTPd Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configure Anonymous PureFTPd Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18 21 27 32 34 35 36

36 38 40 43 52 53

53 53 55 62 63

63 63 64 65 66 70 71

Summary

72

Manage Printing

73

Configure CUPS

74

When to Configure a Printer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Required Printing Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How to Add Printers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configure Printers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Copying all or part of this manual, or distributing such copies, is strictly prohibited. To report suspected copying, please call 1-800-PIRATES.

74 75 76 90

3



Contents


SUSE Linux Enterprise Server 11 Administration / Manual

Objective 2


Manage Print Jobs and Queues

91

Generate a Print Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Display Information on Print Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cancel Print Jobs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Manage Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configure Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Start and Stop CUPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Manage Printers from the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Understand how CUPS Works

91 92 93 94 94 97 98 99

Steps of the Printing Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Print Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Objective 4


Exercise 2-4


Configure and Manage Print Server Access

106

Syntax of /etc/cups/cupsd.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Access Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Manage Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Use the Web Interface to Manage a CUPS Server

113

Administration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Documentation/Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Printers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Use the Web Interface to Manage a CUPS Server . . . . . . . . . . . . . . . . . . . . . . . .

114 115 115 116 117 119

Summary

120

Configure and Use OpenLDAP

121

Describe How LDAP Works

122

How Directory Services Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 What is LDAP? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 How the LDAP Directory Tree Is Structured . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Objective 2

Install and Configure OpenLDAP on SLES 11

Objective 3

Add, Modify, and Delete Entries to the LDAP Directory Tree

Exercise 3-1

4

136 Install and Configure the LDAP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Install and Configure the LDAP Client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 155 Managing LDAP Users and Groups from the Shell Prompt. . . . . . . . . . . . . . . . . 155 Managing LDAP Users and Groups in YaST . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 Configure OpenLDAP on SLE 11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169


Version 1


Objective 1

170

Configure and Use Samba

173

Describe the Role and Function of Samba

174

SMB Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NetBIOS Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How SMB Communications Work. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How Samba Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objective 2






Configure a Simple File Server with Samba

Installing Samba on the Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Samba Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Samba in YaST. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Create a Basic Samba Share . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configure Samba Authentication

Exercise 5-1

Version 1

178

178 179 185 191 192

Configuring the Samba User Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Configuring Samba to Require User Authentication . . . . . . . . . . . . . . . . . . . . . . 198 Configure Samba to Use LDAP Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . 201 Use Samba‘s Client Tools

Using nmblookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using smbclient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mounting Samba Shares in the Linux File System. . . . . . . . . . . . . . . . . . . . . . . . Work with Samba Shares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Use Samba as a Domain Controller

How Domains Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Samba as a Domain Controller. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating Machine Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mapping Local Linux Groups to Windows Groups . . . . . . . . . . . . . . . . . . . . . . . Configuring Samba as a Domain Controller. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

202

202 202 204 206 207

207 211 215 216 218

Integrate Samba into a Windows Domain

219

Summary

221

Configure a Web Server

223

Set up a Basic Web Server with Apache

224

How a Web Server Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing Apache Web Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Apache Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Default Apache Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objective 2

174 174 176 177

Configure Virtual Hosts

224 226 229 231 233

Understand Virtual Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 Configure a Virtual Host. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 Configure a Virtual Host. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236


5



SECTION 4

Summary



Objective 3



Exercise 5-4


Limit Access to the Web Server

237

Limiting Access By Network Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 Requiring User Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 Configure User Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 Configure Apache with OpenSSL

241

How SSL Encryption Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a Test Certificate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Apache to Use SSL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configure SSL for a Virtual Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Install PHP

241 243 245 247 248

How PHP Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Testing the PHP Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Install PHP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

248 249 250 251

Summary

252

Configure and Use IPv6

255

Understand IPv6 Theory

256

IPv6 Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 IPv6 Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 IPv6 Address Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 Objective 2

Exercise 6-1


Configure IPv6 on SLE 11

261

IPv6 Autoconfiguration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting an IPv6 Address Using YaST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing IPv6 Addresses Using the Command Line Tools . . . . . . . . . . . . . . . . Connecting to Other IPv6 Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configure IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary

272

Perform a Health Check and Performance Tuning

273

Find Performance Bottlenecks

274

Analyze Processes and Processor Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . Analyze Memory Utilization and Performance . . . . . . . . . . . . . . . . . . . . . . . . . . Analyze Storage Performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Analyze Network Utilization and Performance . . . . . . . . . . . . . . . . . . . . . . . . . . Objective 2

Exercise 7-1

6

261 262 265 265 271

Reduce System and Memory Load

286

Analyze CPU-Intensive Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Run Only Required Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Keep Your Software Up to Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Optimize Swap Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Change Hardware Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reduce Resource Utilization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


274 275 278 281 286 286 288 288 289 290

Version 1


Optimize the Storage System

Configure IDE Drives with hdparm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tune Kernel Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tune File System Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Change Hardware Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objective 4

Tune the Network Performance

291

291 292 294 295 296

Change Kernel Network Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 Change Your Network Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297


Summary

299

Create Shell Scripts

301

Bash Basics

302

Bash Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 Bash Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 Return Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306 Objective 2



Exercise 8-3 Exercise 8-4 Objective 5





Exercise 8-9

Version 1

Use Basic Script Elements

Elements of a Shell Script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A Simple Backup Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Debug Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Create a Simple Shell Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Understand Variables and Command Substitution

307

307 308 310 311 312

Use Variables and Command Substitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 Use Control Structures

Create Branches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Use an if Control Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Create Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Use a while Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

316

316 320 320 324

Use Arithmetic Operators

325 Use Arithmetic Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327

Read User Input

328

Read User Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330 Use Arrays

331

Use Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 Finalize the Course Project

334

Use rsync to Keep Versions of Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336 Use Advanced Scripting Techniques

337

Use Shell Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 Read Options with getopts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 Use Shell Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340


7



Objective 3



Objective 10

Learn about Useful Commands in Shell Scripts

341

Use the cat Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Use the cut Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Use the date Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Use the grep and egrep Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Use the sed Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Use the test Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Use the tr Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


341 341 342 342 343 345 347

Summary

349

Deploy SUSE Linux Enterprise 11

353

Introduction to AutoYaST

354

Autoinstallation Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354 Installation Options and Deployment Strategies. . . . . . . . . . . . . . . . . . . . . . . . . . 355 Objective 2




Exercise 9-4 Exercise 9-5


Installation Server: Setup and Use

358

Set Up an Installation Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358 Use the Installation Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368 Set Up an Installation Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370 Set Up PXE Boot for Installations

371

Install and Configure tftp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configure pxelinux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Install and Configure the DHCP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Set Up PXE Boot for Installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Create a Configuration File for AutoYaST

371 372 374 380 381

Create an AutoYaST Control File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384 Perform an Automated Installation

385 Provide the Control File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385 Boot and Install the System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385 Perform an Automated Installation of SUSE Linux Enterprise Server 11 . . . . . . 389 Activate PXE Booting and Install SUSE Linux Enterprise Server (Conditional, depending on hardware support) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390

Summary

391

Manage Virtualization with Xen

393

Understand How Virtualization with Xen Works

394

Understand Virtualization Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395 Understand the Xen Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396 Objective 2


Exercise 10-2

8

Install Xen

398

Install a Xen Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398 Install a Xen Virtual Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400 Install a Xen Server and an Unprivileged Domain . . . . . . . . . . . . . . . . . . . . . . . . 408 Manage Xen Domains with Virt-Manager

409

Change Memory Allocation of a Guest Domain. . . . . . . . . . . . . . . . . . . . . . . . . . 414


Version 1



Exercise 10-4

Understand Managed and Unmanaged Domains . . . . . . . . . . . . . . . . . . . . . . . . . Understand a Domain Configuration File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Use the xm Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Use the virsh Tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Automate Domain Startup and Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Automate Domain Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Understand Xen Networking

415

415 415 416 418 420 421 422

Understand Bridging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422 Understand the Xen Networking Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423 Check the Network Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 Summary

427

Prepare for the Novell CLP 11 Practicum

429

Objective 1

Install a Xen Environment

430

Objective 2


431

Objective 3

Configure a Samba File Server

432

Objective 4

Automate System Tasks

433

SECTION 11

Version 1

Manage Xen Domains from the Command Line


9



Objective 4



10


Version 1


Introduction

In the SUSE Linux Enterprise Server 11 Server Administration (3103) course, you learn the SUSE Linux Enterprise Server 11 administration skills necessary to complete your basic SUSE Linux Enterprise Server 11 skill set. These skills, along with those taught in the SUSE Linux Enterprise 11 Fundamentals (3101) and SUSE Linux Enterprise 11 Administration (3102) courses, prepare you to take the Novell® Certified Linux® Professional 11 (Novell CLP11) certification practicum test. Your student kit includes the following: 

SUSE Linux Enterprise Server 11 Administration manual



SUSE Linux Enterprise Server 11 Administration workbook



SUSE Linux Enterprise Server 11 Administration course DVD



SUSE Linux Enterprise Server 11 product DVD



SUSE Linux Enterprise Desktop 11 product DVD

The SUSE Linux Enterprise Server 11 Administration course DVD contains a preinstalled VMware image of SUSE Linux Enterprise Server 11 that you can use with the SUSE Linux Enterprise Server 11 Administration Workbook to practice the skills you need to take the Novell CLP 11 practicum. NOTE: Instructions for setting up a self-study environment are in the Setup directory on the Course DVD.

Course Objectives

This course teaches you how to perform the following SUSE Linux Enterprise Server 11 administrative tasks:

Version 1



Configure Fundamental Network Services



Manage Printing




















11



Introduction








Manage Virtualization with XEN

These are tasks common to an experienced SUSE Linux administrator in an enterprise environment. The final day of class is reserved for a “LiveFire” exercise that provides a set of scenarios to test your SUSE Linux Enterprise Server 11 administration skills and prepare you to take the Novell CLP 11 Practicum. Audience

This course is designed for those who already have experience with Linux, including general system configuration and command line work, and seek advanced administration skills on SUSE Linux Enterprise Server 11. It is also designed for those who have completed the previous two courses in the Novell CLP11 curriculum and those preparing to take the Novell CLP11 Practicum exam. Certification and Prerequisites

This course helps you prepare for the Novell Certified Linux Professional 11 (Novell CLP11) Practical Test, called a practicum. The Novell CLP 11 is an entry-level certification for people interested in becoming SUSE Linux Enterprise administrators. As with all Novell certifications, course work is recommended. To achieve the certification, you are required to pass the Novell CLP 11 Practicum (050-721). The Novell CLP 11 Practicum is a hands-on, scenario-based exam where you apply the knowledge you have learned to solve real-life problems—demonstrating that you know what to do and how to do it. The practicum tests you on objectives in this course (SUSE Linux Enterprise Server 11 Administration - Course 3103) and the skills outlined in the following Novell CLP 11 courses:

12



SUSE Linux Enterprise 11 Fundamentals - Course 3101



SUSE Linux Enterprise 11 Administration - Course 3102


Version 1


The following illustrates the training/testing path for Novell CLP 11: Figure Intro-1

Certification Path

This course is designed for those who have intermediate-level knowledge of Linux. They should be able to do the following: 

Understand what Linux is and know about the Open Source concept



Perform a basic installation of SUSE Linux Enterprise Server 11 / SUSE Linux Enterprise Desktop 11



Perform partitioning and file system setup and maintenance



Perform system configuration including network setup and user management



Manage software packages



Work on the command line including file management and text editing

This knowledge can be gained through the SUSE Linux Enterprise 11 Fundamentals (Course 3101) and SUSE Linux Enterprise 11 Administration (Course 3102). NOTE: For more information about Novell certification programs and taking the Novell CLP 11 Practicum, see (http://www.novell.com/training/certinfo/).

SUSE Linux Enterprise Server 11 Support and Maintenance

The copy of SUSE Linux Enterprise Server 11 you receive in your student kit is a fully functioning copy of the SUSE Linux Enterprise Server 11 product.

Version 1


13



Introduction



However, to receive official support and maintenance updates, you need to do one of the following: 

Register for a free registration/serial code that provides you with 60 days of support and maintenance.



Purchase a copy of SUSE Linux Enterprise Server 11 from Novell (or an authorized dealer).

You can obtain your free 60 day support and maintenance code at (http:// www.novell.com/products/server/eval.html). NOTE: You will need to have a Novell login account to access the 60 day evaluation.

Novell Customer Center

Novell Customer Center is an intuitive, Web-based interface that helps you to manage your business and technical interactions with Novell. Novell Customer Center consolidates access to information, tools, and services such as the following: 

Automated registration for new SUSE Linux Enterprise products



Patches and updates for all shipping Linux products from Novell



Order history for all Novell products, subscriptions, and services



Entitlement visibility for new SUSE Linux Enterprise products



Linux subscription renewal status



Subscription renewals via partners or Novell

For example, a company might have an administrator who needs to download SUSE Linux Enterprise software updates, a purchaser who wants to review the order history, and an IT manager who has to reconcile licensing. With Novell Customer Center, the company can meet all these needs in one location and can give users access rights appropriate to their roles. You can access the Novell Customer Center at (http://www.novell.com/ customercenter). SUSE Linux Enterprise Server 11 Online Resources

Novell provides a variety of online resources to help you configure and implement SUSE Linux Enterprise Server 11: 

(http://www.novell.com/products/server/) This is the Novell home page for SUSE Linux Enterprise Server 11.



(http://www.novell.com/documentation/sles11/) This is the Novell Documentation Web site for SUSE Linux Enterprise Server 11.



14

(http://support.novell.com/linux/)


Version 1


This is the home page for all Novell Linux support and it includes links to support options such as Knowledgebase, downloads, and FAQs. 

(http://www.novell.com/coolsolutions/) This Web site provides the latest implementation guidelines and suggestions from Novell on a variety of products, including SUSE Linux Enterprise.

Agenda

The following is the agenda for this five-day course: Table Intro-1

Agenda

Day 1

Day 2

Day 3

Day 4

Day 5

Section

Duration

Introduction

00:30

Section 1: Configure Fundamental Network Services

04:30

Section 2: Manage Printing

01:00

Section 2: Manage Printing

02:00

Section 3: Configure and Use OpenLDAP

03:00

Section 4: Configure and Use Samba

01:30

Section 4: Configure and Use Samba (cont’d)

01:30

Section 5: Configure a Web Server

03:30

Section 6: Configure and Use IPv6

01:30

Section 7: Perform a Health Check and Performance Tuning 01:30 Section 8: Create Shell Scripts

05:00

Section 9: Deploy SUSE Linux Enterprise

03:00

Section 10: Manage Virtualization with XEN

02:00

Section 11: Prepare for the Novell CLP Practicum

01:30

Scenario

The exercises in this course center around the fictional Digital Airlines Company that has offices at various airports around the globe. The Digital Airlines management has made the decision to migrate several back-end services to Linux servers running SUSE Linux Enterprise Server 11. You have already installed SUSE Linux Enterprise Server 11 before and are familiar with administering SUSE Linux Enterprise Server 11 from YaST and from the command line. The migration plan includes the following: 

Version 1

Providing basic networking services as well as file and print services


15



Introduction





Introducing IPv6



Automating tasks using shell scripts



Installing of desktops and servers using AutoYaST



Virtualizing with Xen

Your task is to set up a test server in the lab to enhance your skills in these areas. Exercise Conventions

When working through an exercise, you will see conventions that indicate information you need to enter that is specific to your server. The following describes the most common conventions: 

italicized text: This is refers to your unique situation, such as the hostname of your server. For example, supposing the hostname of your server is da50 and you see the following hostname.digitalairlines.com You would enter da50.digitalairlines.com



172.17.8.xx: This is the IP address that is assigned to your SUSE Linux Enterprise Server 11. For example, supposing your IP address is 172.17.8.50 and you see the following 172.17.8.xx You would enter 172.17.8.50



Select: The word select is used in exercise steps with reference to menus where you can choose between different entries, such as drop-down menus.



Enter and Type: The words enter and type have distinct meanings. The word enter means to type text in a field or at a command line and press the Enter key when necessary. The word type means to type text without pressing the Enter key. If you are directed to type a value, make sure you do not press the Enter key or you might activate a process that you are not ready to start.

16


Version 1


SECTION 1


In this section, you learn the basics of enabling some of the more commonly used network services available in SUSE Linux Enterprise Server 11. Objectives

Version 1

1.

“Configure NFS (Network File System)” on page 18

2.

“Configure Time on SUSE Linux Enterprise Server 11” on page 36

3.

“Enable the Extended Internet Daemon (xinetd)” on page 53

4.

“Enable an FTP Server” on page 63


17






Objective 1

Configure NFS (Network File System) Network File System (NFS) lets you configure an NFS file server that gives users transparent access to data and programs files on the server. To administer NFS successfully, you need to know the following: 

“NFS Background” on page 18



“NFS Server Configuration” on page 21



“NFS Client Configuration” on page 27



“Automounter Configuration” on page 32



“NFS System Monitoring” on page 34

NFS Background In Linux and Unix environments, NFS is a very reliable way to provide users with file access over the network. As a background to NFS, you need to understand the following: 

“Network File System Basics” on page 18



“How NFS Works” on page 19



“NFSv4 Features” on page 20



“NFS Configuration Overview” on page 21

Network File System Basics

NFS is designed for sharing files and directories over a network, and it requires configuration of an NFS server (where the files and directories are located) and NFS clients (computers that access the files and directories remotely). File systems are exported by an NFS server, and they appear and behave on a NFS client as if they were located on a local machine. For example, each user’s home directory can be exported by an NFS server and imported to a client, so the same home directories are accessible from every workstation on the network. Directories like /home/, /opt/, and /usr/ are good candidates for export via NFS. However, others—including /bin/, /boot/, /dev/, /etc/, /lib/, /root/, /sbin/, /tmp/, and / var/—should be available on the local disk only. Using NFS for home directories makes sense only with a central user management (for instance OpenLDAP).

18


Version 1


The following is an example of mounting the directory /home/ (exported by the NFS Server sun) on the computer earth: Figure 1-1

NFS

A computer can be both an NFS server and an NFS client. It can supply file systems over the network (export) and mount file systems from other hosts (import). The NFS daemon is part of the kernel and only needs to be configured and then activated. The start script is /etc/init.d/nfsserver. The kernel NFS daemon includes file locking, which means that only one user at a time has write access to files. How NFS Works

NFS is an RPC (Remote Procedure Call) service. An essential component for RPC services is rpcbind (previously called portmapper) that manages these services and needs to be started first. The rpcbind utility is activated by default on SUSE Linux Enterprise Server 11. When an RPC service starts up, it binds to a port in the system (as any other network service), but it also communicates this port and the service it offers (such as NFS) to rpcbind. Because every RPC program must be registered by rpcbind when it is started, RPC programs must be restarted each time you restart rpcbind.

Version 1


19






The following lists the services required on an NFS server: Table 1-1

Services Required by an NFS Server Service

Program (daemon)

Start Script

rpcbind utility

/sbin/rpcbind

/etc/init.d/rpcbind

NFS server v3

/usr/sbin/rpc.nfsd

/etc/init.d/nfsserver

/usr/sbin/rpc.mountd /usr/sbin/rpc.statd NFS server v4

Same as version 3 plus:

/etc/init.d/nfsserver

NFSv4 ID <-> name mapping daemon, /usr/sbin/rpc.idmapd If encryption is used, /usr/sbin/ rpc.svcgssd (requires Kerberos)

In SUSE Linux Enterprise Server 11, the NFS lock manager is started automatically by the kernel. The /sbin/rpc.lockd program starts the NFS lock manager on kernels that do not start it automatically. The manual pages for the respective programs contain additional information on their functionality. You can use the /etc/init.d/nfsserver command to start the NFS server. The nfsserver script passes the list of exported directories to the kernel, and then starts or stops the daemon rpc.mountd and, using rpc.nfsd, the nfsd kernel threads. The mount daemon (/usr/sbin/rpc.mountd) accepts each mount request and compares it with the entries in the configuration file /etc/exports. If access is allowed, the data is delivered to the client. Because rpc.nfsd can start several kernel threads, the start script interprets the variable USE_KERNEL_NFSD_NUMBER in the file /etc/sysconfig/nfs. This variable determines the number of threads to start. By default, four server threads are started. NFSv4 support is activated by setting the variable NFS4_SUPPORT to yes in / etc/sysconfig/nfs. NFSv4 Features

NFS version 4 comes with several improvements compared to version 3. These include:

20



The mount and lock protocol are now part of the NFS protocol, simplifying firewall rules for NFS. NFS uses TCP port 2049; UDP is no longer supported.



Using Kerberos, it is possible to allow access on a per-user basis, not only based on IP addresses or DNS names as in version 3.


Version 1




Encryption is part of the specification. While Secure-RPC allowed encryption with version 3, it was hardly ever used.



Additional improvements concern the use of user@computername instead of numeric IDs to identify users, ACLs, and changes in the way files are locked.

NFS Configuration Overview

The /etc/exports file on the NFS server contains all settings regarding which directories are exported, how, and to which clients. Client-side configuration is written to the /etc/fstab file. Both files will be covered in detail later. Some configuration parameters for the NFS server (for instance, if version 4 and encryption should be used) are specified in the /etc/sysconfig/nfs file. Both the NFS server and the clients can be configured with YaST modules. You can also modify the configuration files directly. For the NFS server to start automatically when the computer is booted, the corresponding symbolic links in the runlevel directories must be created. If you configure the NFS server with YaST, this is done automatically; otherwise, you need to create them with insserv nfsserver.

NFS Server Configuration There are several ways you can configure an NFS server: 

“Configure an NFS Server with YaST” on page 21



“Configure an NFS Server Manually” on page 24



“Export a Directory Temporarily” on page 26

Configure an NFS Server with YaST

To use YaST to configure the NFS server, start YaST and then select Network Services > NFS Server. You can also start the NFS Server module directly by entering yast2 nfs_server in a terminal window as root.

Version 1


21






The following appears: Figure 1-2

NFS Server Configuration

Select Start in the upper part of the dialog. The middle part is active only if the firewall is activated. In this case, you can open the ports necessary for NFS by selecting Open Port in Firewall. If you want to use NFS version 4, select Enable NSFv4 in the lower part of the dialog. In this case, you have to enter an NFSv4 domain name, such as your DNS domain name. If you do not have special requirements, you can use the suggested localdomain domain. Checking Enable GSS Security is useful only within an existing Kerberos infrastructure.

22


Version 1


Continue by selecting Next. A Directories to Export dialog appears: Figure 1-3

NFS Directories to Export

Add a directory to export by clicking Add Directory, typing in or browsing to a directory, then clicking OK. The following dialog appears: Figure 1-4

NFS Export Options

Host Wild Card lets you configure the hosts that should have access to the directory. You can define a single host, netgroups, wildcards, and IP networks. Under Options, add options like rw or root_squash for that directory. For details on the possible host settings, see “Configure an NFS Server Manually” on page 24.

Version 1


23






To add more hosts allowed to access a directory, select the directory and click Add Host; to edit or delete an existing host entry for a directory, select the directory and the host entry and click Edit or Delete. When you finish, save the configuration by clicking Finish. Configure an NFS Server Manually

You can configure the server from the command line by doing the following: 

Check for service (daemon) availability: Make sure the nfs-kernel-server rpm package is installed on your NFS server.



Configure the services to start at bootup: For services to be started by the / etc/init.d/rpcbind and /etc/init.d/nfsserver scripts when the system is booted, enter the following commands: insserv rpcbind (activated by default) insserv nfsserver



Define exported directories in /etc/exports: For each directory to export, one line is needed to define which computers can access that directory with what permissions. All subdirectories of this directory are automatically exported as well. The following is the general syntax of the /etc/exports file: directory [host[(option1,option2,option3,...)]] ... Do not put any spaces between the hostname, the parentheses enclosing the options, and the option strings themselves. A host can be one of the following: 



A standalone computer with its name in short form (it must be possible to resolve this with name resolution), with its Fully Qualified Domain Name (FQDN) or its IP address. A network, specified by an address with a netmask, or by the domain name with a prefixed placeholder (such as *.digitalairlines.com).

Authorized computers are usually specified with their full names (including domain name), but you can use wildcards like * or ?. If you do not specify a host or use *, any computer can import the file system with the given permissions. 

24

Set permissions for exported directories in /etc/exports: You need to set permission options for the file system to export in parenthesis after the computer name. The most commonly used options include the following:


Version 1


Table 1-2

NFS Export Options Option

Meaning

bind=/path/directory

This is an NFS Version 4 option. On the server, this directory is mounted with the exported directory as mount point using the bind mount option. On the client, the content of the directory specified after bind= appears in the exported directory within the pseudo-root directory tree.

crossmnt

This is an NFS Version 4 option. If you use the bind=/ path/directory option, the option crossmnt needs to be added to the line that contains the fsid=0 option. Without it, NFSv4 does not cross file systems.

fsid=0

This is an NFS Version 4 option. In version 4, the client is presented with one seamless directory tree. The option fsid=0 (or fsid=root, which is equivalent) indicates that this exported directory is the pseudo-root of that directory tree.

no_root_squash

Does not assign user ID 65534 to user ID 0, keeping the root permissions valid.

no_subtree_check

(Default since version 1.1.0 of nfs-utils) No subtree_check is performed. If you specify neither subtree_check nor no_subtree_check, a message informs you when starting the NFS server that no_subtree_check is used.

Version 1

ro

File system is exported with read-only permission (default).

root_squash

(Default) This ensures that the root user of the client machine does not have root permissions on this file system. This is achieved by assigning user ID 65534 to users with user ID 0 (root). This user ID should be set to nobody (which is the default).

rw

File system is exported with read-write permission. The local file permissions are not overridden.

subtree_check

If a subdirectory of a file system is exported, but the whole file system is not, then whenever an NFS request arrives, the server must check not only that the accessed file is in the appropriate file system but also that it is in the exported tree. This check is called subtree check.

sync

Reply to requests only after the changes have been committed to stable storage (this is the default, but if neither sync or async are specified, a warning appears when starting the NFS server).


25






The following is an example of an edited /etc/exports file for NFS version 3 that includes permissions: # # /etc/exports # /home da10(rw,sync,no_subtree_check) \ da20(rw,sync,no_subtree_check) /srv/ftp *(ro,sync,no_subtree_check)

Whenever you want to specify different permissions for a subdirectory (such as / home/geeko/pictures/) from an already exported directory (such as / home/geeko/), the additional directory needs its own separate entry in /etc/ exports. The following is an example of an edited /etc/exports file for NFS version 4 that includes permissions: # # /etc/exports # /export *(fsid=0,crossmnt,rw,sync,no_subtree_check) /export/data *(ro,sync,no_subtree_check,bind=/data)

The /export and /data directories are separate on the server, whereas on the client, the content of both directories appears within one directory structure. If, for example, the client mounts the pseudo-root directory on /imports, the content of /data from the server appears in /imports/data on the client. 

Reload the configuration: The /etc/exports is read by mountd and nfsd. If you change anything in this file, you need to reload the configuration for your changes to take effect. You can do this by entering rcnfsserver reload (rcnfsserver restart works as well).

Export a Directory Temporarily

You can export a directory temporarily (without editing the file /etc/exports) by using the exportfs command: For example, to read-only export the /software directory to all hosts in the network 192.168.0.0/24, you would enter the following command: exportfs -o ro,root_squash,sync 192.168.0.0/24:/software To restore the original state, all you need to do is enter the command exportfs r. The /etc/exports file is reloaded and any directories not listed in the /etc/ exports file are no longer exported. After adding directories to export in the /etc/exports file, exportfs -a exports the additional directories. The directories that are currently exported are listed in the /var/lib/nfs/etab file. The content of this file is updated when you use the command exportfs.

26


Version 1


NFS Client Configuration There are two ways you can configure NFS clients: 

“Configure NFS Client Access with YaST” on page 27



“Configure NFS Client Access from the Command Line” on page 29

Configure NFS Client Access with YaST

NFS directories exported on a server can be mounted into the file system tree of a client. The easiest way to do this is to use the YaST NFS Client module. To use YaST to configure the NFS client, start the YaST Control Center and then select Network Services > NFS Client. You can also start the NFS Client module directly by entering yast2 nfs in a terminal window as root. The NFS Client Configuration dialog appears: Figure 1-5

Version 1

NFS Client Configuration, NFS Shares


27






Add a directory to the list by clicking Add. The following appears: Figure 1-6

NFS Client Configuration, Add Directory

From this dialog, you can configure how the directory exported on the server is mounted in your file system tree. Configure the directory by doing the following: 1.

Enter the NFS server’s hostname, or find and select the NFS server from a list of NFS servers on your network by selecting Choose.

2.

In the Remote Directory field, type the directory exported on the NFS server you want to mount, or find and select the available directory by selecting Select.

For directories exported using NFSv4, you have to specify the directory relative to the NFSv4 pseudo-root directory, not the actual path on the server as with NFSv3. Provided the server exported the pseudo-root directory with the option crossmnt, subdirectories exported on the server are accessible within the exported tree; they do not need to be mounted separately. 1.

In the Mount Point (local) field, type the mount point in your local file tree to mount the exported directory, or browse to and select the mount point by selecting Browse.

2.

Select NFSv4 Share if applicable.

3.

In the Options field, type any options you would normally use with the mount command. For a list of general mount options, in a terminal window enter man 8 mount; for a list of nfs-specific mount options, enter man 5 nfs.

4.

When you finish configuring the directory, select OK. You are returned to the NFS client configuration dialog.

28


Version 1


The NFS Client Configuration dialog also offers an NFS Settings tab: Figure 1-7

NFS Client Configuration, NFS Settings

Here you can set the NFSv4 Domain Name and open the ports needed for NFS in the firewall. Save the NFS client settings by clicking OK. The settings are saved and the exported directories are mounted in your local file system tree. Configure NFS Client Access from the Command Line

To configure and mount NFS directories, you need to know how to do the following: 

“Import Directories Manually from an NFS Server” on page 29



“Mount NFS Directories Automatically” on page 31

Import Directories Manually from an NFS Server

You can import a directory manually from an NFS server by using the mount command. The only prerequisite is a running rpcbind (portmapper), which you can start by entering (as root) rcrpcbind start. The mount command automatically tries to recognize the file system (such as ext2, ext3, or ReiserFS). However, you can also use the mount option -t to indicated the

Version 1


29






file system type. For NFS version 3 and earlier, the file system type is nfs; for NFS version 4, it is nfs4. In the following example, the file system type nfs is specified: mount -t nfs -o options host:/directory /mountpoint Instead of a device file, the name of the NFS server together with the directory to import is used within the command. The following are the most important mount options (-o) used with NFS: 

soft (opposite: hard): If the attempt to access the NFS server extends beyond the default number of tries (or the value set with the retrans= option), the mount attempt will be aborted. If the hard option (or neither soft nor hard) is specified, the client attempts to mount the exported directory until it receives feedback from the server that the attempt was successful. If a system tries to mount an NFS file system at boot time, the hard option can cause the boot process to hang because the process will stop at this point when it attempts to mount the NFS directory. For directories that are not essential for the system to function, you can use the soft option. For directories that must be mounted (such as home directories), you can use the hard option.



bg (default: fg): If you use the bg option, and the first attempt is unsuccessful, all further mount attempts are run in the background. This prevents the boot process from hanging when NFS exports are automatically mounted, with attempts to mount the directories continuing in the background.



rsize=n: Lets you set the number of bytes (n, positive integral multiple of 1024, maximum 1,048,576) that NFS reads from the NFS server at one time. If this value is not set, the client and server negotiate the highest possible value that they both support. The negotiated value is shown in /proc/mounts.



wsize=n: Lets you set the number of bytes (n, positive integral multiple of 1024, maximum 1,048,576) that can be written to the NFS server. If this value is not set, the client and server negotiate the highest possible value that they both support. The negotiated value is shown in /proc/mounts.

30



retry=n: Lets you set the number of minutes (n) an attempt can take to mount a directory through NFS. The default value for foreground mounts is two minutes; for background mounts it is 10000 minutes (approximately one week).



nosuid: Lets you disable any interpretation of the SUID and SGID bits on the corresponding file system.


Version 1


For security reasons, always use this option for any file system that might be susceptible to tampering. If you do not use this option, there is a possibility that a user can obtain root access to the local file system by putting a SUID root executable on the imported file system. 

nodev: Lets you disable any interpretation of device files in the imported file system. We recommend that you use this option for security reasons. Without setting this option, someone could create a device such as /dev/sda on the NFS export, then use it to obtain write permissions for the hard disk as soon as the file can be accessed from the client side.



exec (opposite: noexec): Lets you permit or disallow the execution of binaries on the mounted file system.

You can use the umount command to unmount a file system. However, you can do this only if the file system is currently not being accessed. NOTE: For additional information on nfs, mount options, and the /etc/fstab file, in a terminal window enter man 5 nfs, man 8 mount, or man 5 fstab.

Mount NFS Directories Automatically

To mount directories automatically when booting (such as the home directories from a file server), you need to make corresponding entries in the /etc/fstab file. When the system is booted, the /etc/init.d/nfs start script loads the /etc/ fstab file, which indicates which file systems are mounted, where, and with which options. The following is an example of an entry for an NFS mount point in the /etc/ fstab file: da1:/training/home /home nfs soft,noexec 0 0

In this entry, the first value indicates the hostname of the NFS server (da1) and the directory it exports (/training/home/). The second value indicates the mount point, which is the directory in the local file system where the exported directory should be attached (/home/). The third value indicates the file system type (nfs). The comma-separated values following the file system type provide NFS-specific and general mounting options. At the end of the line, there are two numbers (0 0). The first indicates whether to back up the file system with the help of dump (1) or not (0). The second number configures whether the file system check is disabled (0), done on this file system with no parallel checks (1), or parallelized when multiple disks are available on the computer (2). In the example, the system does neither, as both options are set to 0.

Version 1


31






After modifying an entry of a currently mounted file system in the /etc/fstab file, you can have the system read the changes by entering mount -o remount / mountpoint. To mount all file systems that are not currently mounted and do not contain the option noauto, enter mount -a. (noauto is used with devices that are not automatically mounted, like floppy disks.)

Automounter Configuration When you use the method described in “NFS Client Configuration” on page 27 to mount home directories, all home directories on the server are visible on the client machines. This can make it quite hard for a user to find his own home directory. With the automounter, only the directory needed by a user is mounted. Another advantage of the automounter is the reduced number of actual mounts on the server, as only those directories get mounted by clients that are actually needed. Unlike with a static configuration in the /etc/fstab file, with the automounter, directories are mounted automatically when needed and unmounted automatically when not in use for some time. The kernel-based automounter is contained in the autofs package which is part of the default installation. In the past, the automounter was also used to mount and unmount CD-ROMs; however, this functionality is now integrated into the KDE or Gnome desktop environments. The automounter remains very useful to mount and unmount directories that are exported by file servers. The automounter configuration consists of the general /etc/auto.master file and files that are referenced within /etc/auto.master, such as /etc/ auto.home. To mount the home directories exported from another server, you need the following entry in the /etc/auto.master file: /home

/etc/auto.home

The first column lists the mount point and the second column lists the file that contains the configuration details for this mount point. The /etc/auto.home file could look like the following (for NFSv4 fstype would be nfs4): geeko

-fstype=nfs,rw

da1.digitalairlines.com:/home/geeko

As soon as some process accesses the local /home/geeko directory (the entry in the first column, geeko, is appended to the directory given in the first column in the /etc/auto.master file, /home), the local /home/geeko directory is created and the /home/geeko directory from the server (last column) is mounted. After some time or when the automounter is stopped, the remote directory is unmounted and the mount point (/home/geeko in the example above) is deleted. With several users, you would need an entry for each user. This is cumbersome, but might be your only choice if home directories reside on several servers.

32


Version 1


As long as all users have their home directories on one server, the automounter allows you to simplify the configuration with the use of wildcards, as shown in the following: *

-fstype=nfs,rw

da1.digitalairlines.com:/home/&

The “*” in the first column denotes any directory below /home. The “&” in the last column is replaced by whatever directory is accessed. When the automounter configuration is complete, you start the automounter with rcautofs start. To stop the automounter, use rcautofs stop. The chkconfig autofs on command ensures the automounter is started automatically when the system boots. The following commands highlight how the automounter works: da10:~ # rcautofs start Starting automount da10:~ # ls /home/ da10:~ # mount ... (no automounts) da10:~ # ls /home/geeko .bash_history Documents merkur2:~ # mount

.gnome2 ...

... da1.digitalairlines.com:/home/geeko on /home/geeko type nfs (rw,nosuid,nodev,sloppy,addr=10.0.0.254,nfsvers=3, proto=tcp,mountproto=udp)

When using NFS to import home directories, it is advisable to also use a networkbased user database, like NIS or LDAP. This ensures that a user has the same UID no matter where he logs in within the network. Instead of local map files, it is also possible to use NIS (Network Information System) or LDAP to distribute the automounter information.

Version 1


33






NFS System Monitoring Some tools are available to help you monitor the NFS system. Enter rpcinfo -p to display information about rpcbind (portmapper). The option -p displays all the programs registered with the portmapper, similar to the following: da10:~ # rpcinfo -p program vers proto port service 100000 4 tcp 111 portmapper 100000 3 tcp 111 portmapper 100000 2 tcp 111 portmapper 100000 4 udp 111 portmapper 100000 3 udp 111 portmapper 100000 2 udp 111 portmapper 100005 1 udp 42763 mountd 100005 1 tcp 49450 mountd 100005 2 udp 42763 mountd 100005 2 tcp 49450 mountd 100005 3 udp 42763 mountd 100005 3 tcp 49450 mountd 100024 1 udp 41731 status 100024 1 tcp 53770 status 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 4 udp 2049 nfs 100021 1 udp 46880 nlockmgr 100021 3 udp 46880 nlockmgr 100021 4 udp 46880 nlockmgr 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100021 1 tcp 53206 nlockmgr 100021 3 tcp 53206 nlockmgr 100021 4 tcp 53206 nlockmgr

The NFS server daemon registers itself to the portmapper with the name nfs. The NFS mount daemon uses the name mountd. You can use the showmount command to display information about the exported directories of an NFS server. showmount -e da1 displays the directories exported on the machine da1. The option -a shows which computers have mounted which directories.

34


Version 1


Exercise 1-1

Set Up and Manage Network File System (NFS) In the first part of this exercise, you create a directory named /export/ documentation, copy documents from /usr/share/doc/manual/ into it, and export it to others using NFS. In the second part, you create a directory named /import/docs and use it as mount point to import the /export/documentation directory from your own server using NFS. Create an /etc/fstab entry to mount the directory automatically at boot time. You wil find this exercise in the workbook. (End of Exercise)

Version 1


35






Objective 2

Configure Time on SUSE Linux Enterprise Server 11 Many network services, like directory services, as well as forensic investigations that need to correlate log entries on different machines, rely on uniform time settings across all computers within the network. In order to implement uniform time settings on all computers in a network, all computers must be able to access at least one time server so clocks will synchronize. There are two ways of synchronizing the time on a SUSE Linux Enterprise Server: netdate and NTP (Network Time Protocol). To configure and synchronize the time, you need to understand the following: 

“Time Overview” on page 36



“Synchronize Time with hwclock or netdate” on page 38



“The Network Time Protocol (NTP)” on page 40



“Synchronize Time with NTP” on page 43

Time Overview In order to configure and synchronize time on a SUSE Linux Enterprise Server 11, you need to understand the following fundamental concepts: 

“Hardware Clock and System Clock” on page 36



“GMT (UTC) and Local Time” on page 37



“Time Configuration Files” on page 37

Hardware Clock and System Clock

There are two main clocks in a Linux system: 

Hardware clock: Clock that runs independently of any control program running in the CPU. It even runs when you turn off the server. This clock is part of the ISA (Industry Standard Architecture) standard and is commonly called the hardware clock. It is also called the time clock, the RTC (Real Time Clock), the BIOS clock, or the CMOS (Complementary Metal-oxide Semiconductor) clock. The term hardware clock is used on Linux systems to indicate the time set by the hwclock utility.



System time: Time kept by a clock inside the Linux kernel. It is driven by a timer interrupt (another ISA standard). System time is meaningful while Linux is running on the server. System time is the number of seconds since 00:00:00 January 1, 1970 UTC (or the number of seconds since 1969).

36


Version 1


On a Linux server, it is the system time that is important. The hardware clock's basic purpose is to keep time when Linux is not running. The system time is synchronized to the hardware clock when Linux boots. After that, Linux uses only the system time. Once the system time is set on the Linux server, it is important that you do not use commands such as date or netdate to adjust the system time without considering the impact on applications and network connections. For a Linux server connected to the Internet (or equipped with a precision oscillator or radio clock), the best way to regulate the system clock is with ntpd. For a standalone or intermittently connected machine, you can use adjtimex instead to at least correct systematic drift (man adjtimex lists the options). You can set the hardware clock (with a command such as hwclock) while the system is running. The next time you start Linux, it will synchronize with the adjusted time from the hardware clock. The Linux kernel also maintains a concept of a local time zone for the system. Some programs and parts of the Linux kernel (such as file systems) use the kernel time zone value. An example is the vfat file system. If the kernel timezone value is wrong, the vfat file system reports and sets the wrong time stamps on files. However, programs that care about the time zone (perhaps because they want to display a local time for you) almost always use a more traditional method of determining the time zone such as using the /etc/localtime file and the files in the /usr/share/zoneinfo/ directory. GMT (UTC) and Local Time

On startup, Linux reads the time from the computer’s local hardware (CMOS) clock and takes control of the time. The hardware clock can be set using one of the following: 

UTC (Universal Time Coordinated): This time is also referred to as GMT (Greenwich Mean Time). For this setting, the variable HWCLOCK in the /etc/ sysconfig/clock file has the value -u.



Local time: If the hardware clock is set to the local time, the variable HWCLOCK in the /etc/sysconfig/clock file has the value --localtime.

Choosing GMT as the hardware time makes it easier to coordinate a large number of computers in different places (especially if the computers are located in different time zones.) Time Configuration Files

The current time (system time) is calculated with the help of the variable TIMEZONE in the /etc/sysconfig/clock file, which also handles the required changes between daylight saving time and standard time.

Version 1


37






The following is an example of the settings in /etc/sysconfig/clock: HWCLOCK="--localtime" SYSTOHC="yes" TIMEZONE="Europe/Berlin" DEFAULT_TIMEZONE="US/Eastern"

By means of the variable TIMEZONE, the time configured on the local host (= system time) is set in the /etc/localtime file, a copy of the respective timezone file from /usr/share/zoneinfo/. The /usr/share/zoneinfo/ directory is a database of all time zones. SYSTOHC=”yes” makes sure the current system time is written to the hardware clock when the system shuts down. NOTE: In SLES 9, there used to be a symbolic link /usr/lib/zoneinfo/localtime pointing to /etc/ localtime. This link does not exist anymore in SLES 10 and SLES 11, even though it might still be mentioned in /etc/sysconfig/clock.

Synchronize Time with hwclock or netdate To synchronize time between network servers with hwclock or netdate, you need to know the following: 

“Use hwclock” on page 38



“Use netdate” on page 39

Use hwclock

hwclock is a tool to access the hardware clock. You can display the current time, set the hardware clock to a specified time, set the hardware clock to the system time, and set the system time from the hardware clock. You can also run hwclock periodically to insert or remove time from the hardware clock to compensate for systematic drift (where the clock consistently gains or loses time at a certain rate if left to run). hwclock uses several methods to get and set hardware clock values. The normal way is to initialize an I/O process to the device special file /dev/rtc (RTC: Real Time Clock), which is maintained by the rtc device driver. However, this method is not always available. The rtc driver is a relatively recent addition to Linux and is not available on older systems. On older systems, the method of accessing the hardware clock depends on the system hardware. NOTE: For additional details on how the system accesses the hardware clock and other hwclock options, enter in a terminal window man hwclock.

38


Version 1


Some of the more commonly used options with hwclock include the following: Table 1-3

Options of the hwclock Command Option

Description

-a or --adjust

Adds or subtracts time from the hardware clock to account for system drift (enter man hwclock for details).

-r or --show

Displays the current time of the hardware clock. The time is always shown in local time, even if you keep your hardware clock set to UTC time.

-s or --hctosys

Sets the system time to the current hardware clock time. It also sets the kernel’s timezone value to the local time zone as indicated by the TZ variable.

--set --date=newdate

Sets the hardware clock to the date given by the --date option. For example: hwclock --set --date=”9/22/09 16:45:05”

-v or --version

Displays the version of hwclock.

-w or --systohc

Sets the hardware clock to the current system time.

You can also view the hardware clock time by entering cat /proc/driver/ rtc. Use netdate

To setup the system time once only, you can use the command netdate as follows: netdate timeserver1 timeserver2 . . . where timeserver represents a time server on the network or the Internet that offers the time service on UDP port 37. After querying the time servers, the netdate client compares their times with its own time. Time differences are then sorted into groups to determine which is the largest group of servers with an identical time (within certain limits). The first computer in the group is then used to update the time on the local server. To synchronize the time to a specific external time source, you enter netdate time_source, as in the following: netdate ptbtime1.ptb.de In this case, the client queries the time server at the Physikalisch-Technische Bundesanstalt (PTB) in Braunschweig, Germany. You then need to set the hardware clock to the system clock time by entering hwclock --systohc or hwclock -w.

Version 1


39






NOTE: A simple way to implement time synchronization with netdate and hwclock is to use a script that is run regularly by cron.

The Network Time Protocol (NTP) The disadvantage of using netdate is that it causes jumps of the system time into the past or the future compared to the current system time. NTP provides a means to avoid such jumps by slightly speeding or slowing system time, thus (within limits) keeping the time continuum of the system time while adjusting it. As the networking environment continues to expand to include mixed operating system environments, time synchronization is becoming more dependent on NTP. To configure NTP on SUSE Linux Enterprise Server 11, you need to understand the following: 

“The Network Time Protocol” on page 40



“Stratum” on page 40



“NTP Daemon (ntpd)” on page 41



“NTP Terms” on page 42



“How the NTP Daemon Works” on page 42

NOTE: For more information on NTP, visit www.ntp.org.

The Network Time Protocol

NTP is an industry standard protocol that uses UDP on port 123 to communicate between time servers and time clients. An NTP server uses the NTP protocol to provide time information to other servers or to workstations on the network. An NTP client is a computer that understands the Network Time Protocol and gets time information from an NTP server. A time client can also, in turn, act as a time server for other servers and client workstations on the network. Any computers on your network with Internet access can get time from NTP servers on the Internet. NTP synchronizes clocks to the UTC standard, the international time standard. NTP not only corrects the time, but it also keeps track of consistent time variations and automatically adjusts for system time drift on the client. This reduces the network traffic and it keeps the client clocks more stable, even when the network is down. Stratum

NTP introduces the concept of a stratum. Stratum x is used as a designation of the location of the servers in the NTP tree hierarchy.

40


Version 1


Stratum 1 is the first (highest) level in the hierarchy. It denotes servers that adjust their time by means of some external reference time source (such as GPS [Global Positioning System], an atomic clock, or radio). Servers that synchronize their time to stratum 1 servers are denoted as stratum 2, and those that use stratum 2 servers to synchronize their time are denoted as stratum 3, and so on until you reach a stratum level of 16 (the maximum allowed). Differences between stratum 2 and stratum 1 servers are normally very small and, for the majority of users, unnoticeable. The following figure depicts the stratum hierarchy. Figure 1-8

Stratum Hierarchy

External Time Source

Stratum 1

Stratum 2

Stratum 3

Stratum 4

Generally only one server in a network communicates with an external time provider. This reduces network traffic across geographical locations and minimizes traffic across routers and WANs. NTP Daemon (ntpd)

The NTP distribution in the ntp package includes ntpd, the NTP daemon. This daemon is used by both the time server and the time client to give and to obtain time, respectively. The ntpd process is designed to adjust time continuously, making the time adjustments very small. ntpd can also limit the drift of the system clock based on historical data, even when an external time server is unavailable.

Version 1


41






The ntpd process requires little resource overhead. This allows NTP to be easily deployed on servers hosting other services, even if the servers are heavily loaded. ntpd uses the following approaches to avoid sudden time changes: 

Regularly corrects the local computer clock on the basis of collected correction data.



Continuously corrects the local time with the help of time servers in the network.



Enables the management of local reference clocks, such as radio-controlled clocks.

NTP Terms

To configure and adjust NTP, you need to understand the following terms: 

Drift: During operation, ntpd measures and corrects incidental clock frequency errors and writes the current value to a file under /var/lib/ntp/drift/. If you start and stop ntpd, the daemon initializes the frequency from this file. This helps prevent a potentially long interval to relearn the frequency error.



Jitter: This is the estimated time error of the peer clock (the delta between the client and server since the last poll).

How the NTP Daemon Works

After starting the NTP Daemon, it automatically synchronizes the system time with a time server on an ongoing basis. The correction takes place in small increments by expanding or compressing the system time (not abruptly, as when netdate and hwclock are used). Transactions between the client and the server occur about once per minute, increasing gradually to once per 17 minutes under normal conditions. Poorly synchronized clients will tend to poll more often than well synchronized clients. The client uses the information it gets from the server or servers to calibrate its clock. This consists of the client determining how far its clock is off and adjusting its time to match that of the server. To allow clocks to quickly achieve high accuracy yet avoid overshooting the time with large time adjustments, NTP uses a system where large adjustments occur quickly and small adjustments occur over time. For small time differences (less than 128 milliseconds), NTP uses a gradual adjustment. This is called slewing. For larger time differences, the adjustment is immediate. This is called stepping. If the difference between system time and the reference server at the start of the NTP daemon is larger than about 17 minutes, the NTP daemon is aborted. You can change this behavior by starting ntpd with the option -g (the default on SLES11). This option makes sure the system time is adjusted in one jump after the start of the daemon.

42


Version 1


If the accuracy of a clock becomes too insufficient (off by more than about 17 minutes) while NTP is running, NTP aborts the NTP daemon, with the assumption that something has gone wrong with either the client or the server. (This behaviour is independent of the option -g used to start the NTP daemon.) The NTP daemon does not start if the difference . Because NTP averages the results of several time exchanges in order to reduce the effects of variable latency, it might take several minutes for NTP to even reach consensus on what the average latency is. It often takes several adjustments (and several minutes) for NTP to reach synchronization. In the long run, NTP tries to decrease the amount of polling it does by making the clock on each system become more accurate. Because of the algorithm that the NTP daemon uses, it is best to synchronize with multiple servers to help protect the client from an incorrect or downed server. In many environments, it is unlikely that an NTP server failure will be noticed quickly.

Synchronize Time with NTP To synchronize network time with NTP, you need to know how to do the following: 

“Configure the NTP Server” on page 43



“Start and Stop the NTP Server” on page 49



“Monitor the NTP Server” on page 50

Configure the NTP Server

As soon as you start ntpd on a host, it serves as an NTP server and can be queried via NTP. You configure the NTP server either by using the YaST NTP Configuration module, or by editing the NTP configuration files /etc/ntp.conf and /etc/sysconfig/ntp and starting the NTP server from the command line. 

“Configure the NTP Server Using YaST” on page 43



“Configure the NTP Server Using the Command Line” on page 47

Configure the NTP Server Using YaST

YaST provides an NTP Configuration module to configure the NTP daemon on your SUSE Linux Enterprise Server 11. The server can, as client, synchronize with an existing NTP server and act, in turn, as an NTP server to other clients. To configure the NTP with YaST, start YaST and select Network Services > NTP Configuration. From a terminal you can start the module directly as root by entering yast2 ntp-client.

Version 1


43






The Advanced NTP Configuration dialog appears. Advanced NTP Configuration, General Settings

On the General Settings tab, you configure the NTP daemon to start each time you boot your system by selecting Now and On Boot. Once you select Now and On Boot, you can click the Add button. The New Synchronization dialog appears: Figure 1-9

44

NTP Configuration, New Synchronization


Version 1


Here you select whether you want to synchronize to a time Server, a Peer (a specialized relationship to another machine that can act as server or as client; see / usr/share/doc/packages/ntp-doc/ confopt.html), a Radio Clock, or an Incoming Broadcast. Select Outgoing Broadcast if you want your server to send broadcasts to its clients. The dialogs that appear after selecting Next differ slightly, depending on the option you choose. To configure the server, the following dialog appears: Figure 1-10

Version 1

NTP Configuration, NTP Server Settings


45






You can enter the Fully Qualified Domain Name or the IP address manually, or select Select ... > Public NTP Server and choose from a list of public NTP servers. The dialog allows you to select a time server close to your geographical location: Figure 1-11

NTP Configuration, Select Public NTP Server

The information in parenthesis tells you which clients the NTP server serves according to its policy. You should choose a server that is near you and allows you to use it. Select your time server and click OK. The server will appear in the General Settings overview.

46


Version 1


The Security Settings tab offers additional configuration options: Figure 1-12

Advanced NTP Configuration, Security Settings

You can choose to run ntpd in a change root environment and open the NTP port in the firewall if the firewall is active. After clicking OK, the configuration is written to /etc/ntp.conf and /etc/ sysconfig/ntp, and the service is started. Configure the NTP Server Using the Command Line

Instead of using YaST, you can edit the NTP configuration files directly. The /etc/ ntp.conf configuration file is used by the NTP daemon; variables defined in the / etc/sysconfig/ntp file are used by the /etc/init.d/ntp start script. When editing the /etc/ntp.conf file, you need to make sure that the following entries exist for the local clock, which is used if the time server is not available: server 127.127.1.0 fudge 127.127.1.0 stratum 10

# local clock (LCL) # LCL is unsynchronized

The following server entries in /etc/ntp.conf concern the time servers that are used to get the current time: ## Outside source of synchronized time server timeserver1.example.com server timeserver1.digitalairlines.com

Version 1


47






There are two possible methods of synchronization between the time server and the client: 

Polling: With polling, the client asks the server for the current time. Polling starts at one-minute intervals. If the time interval is determined to be trustworthy, the interval is reset to once every 1024 seconds. You can set the minimum and maximum limits of the polling in /etc/ntp.conf, as in the following: server timeserver1.example.com minpoll 4 maxpoll 12

The minpoll and maxpoll values are interpreted as powers of 2 (in seconds). The default settings are 6 (26 = 64 seconds) and 10 (210 = 1024 seconds), respectively. Values between 4 and 17 are permitted. 

Broadcasting: By means of broadcasting, the server sends the current time to all clients, and the clients receive the signal through the broadcastclient option in their ntpd.conf. In large networks, traffic caused by polling can be significant. In this case, you might want to configure the time server to distribute time information by sending broadcast packets. To do this, you need to enter the following in /etc/ntp.conf on the server (where the IP address is the broadcast address used in the network): broadcast 10.0.0.255

On the client: disable auth broadcastclient

For reasons of security, broadcast-based synchronization should be used together with an authentication key so that the client accepts information only from trustworthy time servers. See the documentation in authopt.html and miscopt.html in the /usr/share/doc/packages/ntp-doc/ directory (package ntp-doc). You also need to include the name for the drift file and log file in /etc/ntp.conf, as in the following: driftfile /var/lib/ntp/drift/ntp.drift logfile /var/log/ntp

The drift file contains information that describes how the hardware clock drifts. When the daemon ntpd is started for the first time, this file does not exist. It takes about 15 minutes for the daemon to gather enough information to create the file.

48


Version 1


The /etc/sysconfig/ntp file contains variables that are used to configure the way the daemon is started, as shown in the following ## Path: Network/NTP ## Description: Network Time Protocol (NTP) server settings ## Type: string ## Default: "-g -u ntp:ntp" # # Additional arguments when starting ntpd. The most # important ones would be # -u user[:group] to make ntpd run as a user (group) other than root. # NTPD_OPTIONS="-g -u ntp:ntp" ## Type: yesno ## Default: yes ## ServiceRestart: ntp # # Shall the time server ntpd run in the chroot jail /var/lib/ntp? # # Each time you start ntpd with the init script, /etc/ntp.conf will be # copied to /var/lib/ntp/etc/. # # The pid file will be in /var/lib/ntp/var/run/ntpd.pid. # NTPD_RUN_CHROOTED="yes"

If you want, for instance, to limit NTP communication to a certain interface, you change the NTPD_OPTIONS variable: NTPD_OPTIONS="-g -u ntp:ntp -I eth0"

Start and Stop the NTP Server

You can start the NTP daemon by entering rcntp start (or /etc/init.d/ ntp start). You can check the status of ntpd by entering rcntp status. To stop the NTP Daemon, use rcntp stop. In SLES 10 and earlier, the start script called the ntpdate program to initially set the system time before starting ntpd. In SLES 11, this is no longer the case, because the NTP daemon is now able to deal with time differences greater than 1000 seconds, provided it is started with the option -g. The use of ntpdate is deprecated in the current version of NTP. If the time difference between the NTP server and its time source is greater than 1000 seconds, the time is adjusted with one jump, as shown in the following excerpt from the /var/log/ntp log file (note the change of the system time in the last line): da10:~ ... 22 Jan 22 Jan 22 Jan 23 Jan

Version 1

# tail -f /var/log/ntp 16:44:12 16:44:12 16:45:16 14:54:11

ntpd[11507]: ntpd[11507]: ntpd[11507]: ntpd[11507]:

synchronized to LOCAL(0), stratum 10 kernel time sync status change 0001 synchronized to 192.168.1.15, stratum 3 time reset +78898.715082 s


49






NOTE: If you want to set the time of a SLES 11 machine once with no NTP daemon running, use the sntp program as replacement for ntpdate. Enter in a terminal window man sntp to learn about its syntax.

To start NTP automatically when the system is booted, you need to create the symbolic links in the respective runlevel directories by entering insserv ntp. If any changes are made to the ntp.conf file, you need to restart ntpd using the command rcntp restart. After the /etc/ntp.conf file has been read by ntpd, the client sends a request to the server (its time provider), and the server sends back a time stamped response, along with information such as its accuracy and stratum. Other computers can now, in turn, use it as their time server. NOTE: For time requests of other kinds (such as time servers for netdate) to be processed, the services must be made available by means of inetd or xinetd. For this reason, the prepared entries for daytime and time must be enabled for UDP and TCP in the configuration file of inetd or xinetd.

Monitor the NTP Server

Different tools allow you to get information on the status of the NTP server. You need to know how to do the following: 

“Trace the Time Source with ntptrace” on page 50



“Query the NTP Daemon Status” on page 51

Trace the Time Source with ntptrace

The NTP distribution includes the ntptrace program. ntptrace is an informational tool that traces the source of time that a time consumer is receiving. It can be a useful debugging tool. The following is an example of ntptrace output: da10:~ # ntptrace localhost: stratum 3, offset 0.000723, synch distance 1.18225 tick.east.ca: stratum 2, offset 1.601143, synch distance 0.06713 tock.usask.ca: stratum 1, offset 1.712003, synch distance 0.00723, refid ’TRUE’

The ntptrace output lists the client name, its stratum, its time offset from the local host, the synchronization distance, and the ID of the reference clock attached to a server, if one exists. The synchronization distance is a measure of clock accuracy, assuming that it has a correct time source.

50


Version 1


Query the NTP Daemon Status

To verify that the time server is working properly, you can enter ntpq -p. The command queries the status of the ntpd daemon and returns information similar to the following: da10:~ # ntpq -p remote refid st t when poll reach delay offset jitter ==================================================================== LOCAL(0) LOCAL(0) 10 l 15 64 1 0.000 0.000 0.008 *ptb1.ptb.de .PTB. 1 u 14 64 1 27.165 2.348 0.001 ntp2.ptb.de .PTB. 1 u 13 64 1 26.159 0.726 0.001

Displayed information includes the following: 

remote: Hostname or IP address of the time server.



refid: Type of reference source (0.0.0.0 = unknown).



st: Stratum value for the server.



when: Number of seconds since the last poll.



poll: Number of seconds between two polls.



reach: Indicates if the time server was reached in the last poll attempt. Reach begins with the value 0 when you start ntpd. For every successful attempt, a 1 is added to the binary register on the right. The maximum value of 377 means that the server was reachable in the last eight requests.



delay: Time between the ntpd request and the arrival of the answer (in milliseconds).



offset: Difference between the reference time and the system time (in milliseconds).



jitter: Size of the discrepancies between individual time comparisons (in milliseconds).

An asterisk (*) in front of a server name means that this server is the current reference server with which system time is compared. If this server cannot be reached; then the server that is marked with a plus sign (+) is used.

Version 1


51






Exercise 1-2

Configure ntpd In this exercise, you configure your server to get time information from another server. You will find this exercise in the workbook. (End of Exercise)

52


Version 1


Objective 3

Enable the Extended Internet Daemon (xinetd) In this objective, you learn how to enable the extended internet daemon (xinetd) by reviewing the following: 

“What xinetd Is” on page 53



“Configure xinetd with YaST” on page 53



“Manage xinetd Manually” on page 55

What xinetd Is Services can run either standalone, meaning they listen on a port themselves, or via the “super daemon” xinetd. In this case, the super daemon acts as a mediator of connection requests for a series of services. It accepts the connection requests, starts the required service, and passes the request to the newly started server process. If the connection between the client and the server is terminated, the server process started by xinetd is removed from memory. Starting services through xinetd has both advantages and disadvantages. The most significant advantage is saving resources (especially memory), since a server process is started only when it is needed. A disadvantage, however, is that a delay occurs while the required service is loaded, started, and connected. As a rule, you want to use xinetd only for services that are occasionally (not permanently) needed on the server. Some of the services run traditionally by xinetd include Telnet and FTP. NOTE: For detailed information about xinetd, enter man 8 xinetd.

Configure xinetd with YaST To configure the services mediated by xinetd, you can use the YaST Network Services (xinetd) module. Start the YaST Control Center and then select Network Services > Network Services (xinetd). Or open a terminal window, su - to root, and then enter yast2 inetd. NOTE: The YaST module to configure xinetd is called inetd. The reason for this is that in the past, the default super daemon on SUSE Linux was inetd, not xinetd.

Version 1


53






Enable the xinetd super daemon by selecting Enable. This activates the Currently Available Services list. You can add, edit, or delete services in the list: Figure 1-13

Network Service Configuration (xinetd)

NOTE: To manage the services available through xinetd (except for enabling services such as Telnet or FTP) requires a skill set beyond the objectives of this course. This is especially true of configuring services with Edit.

Notice that some services are off (---), while others are not installed (NI). To configure a service, select the service and then select Toggle Status (On or Off). If a service is not installed, it will be installed. The word “On” appears in the Status column. An “X” appears in the Changed (Ch) column to indicate that the service has been edited and will be changed in the system configuration. You can change the status of all installed services to On or Off by selecting Status for All Services > Activate All Services or Status for All Services > Deactivate All Services. When you finish configuring the services, save the configuration setting and start the xinetd daemon by selecting Finish.

54


Version 1


Manage xinetd Manually To manage xinetd manually, you need to know how to do the following: 

“Start, Stop, and Restart xinetd” on page 55



“Configure xinetd” on page 55



“Configure Access Control” on page 59



“Configure Log Files” on page 61

Start, Stop, and Restart xinetd

The default installation of SUSE Linux Enterprise Server 11 includes the xinetd package. To have the daemon automatically activated at boot, enter insserv xinetd. xinetd is controlled by the /etc/init.d/xinetd script. /usr/sbin/ rcxinetd is a link to this script. You can start and stop the daemon by entering rcxinetd start or rcxinetd stop. You can find out whether the daemon is activated or not by entering rcxinetd status. Additionally, xinetd can be influenced by signals sent with kill or killall. The following table lists some of the signals that can be used with xinetd: Table 1-4

Signals Used with xinetd Signal

Number

Description

SIGHUP

1

xinetd re-reads the configuration file and stops listening on ports of services that are no longer available and/or binds to ports now available according to the new configuration.

SIGQUIT

3

Causes xinetd termination.

SIGUSR1

10

Causes an internal state dump (the default dump file is /var/run/xinetd.dump).

SIGTERM

15

Terminates all running servers before terminating xinetd.

SIGIO

29

Causes an internal consistency check to verify that the data structures used by the program have not been corrupted.

Configure xinetd

The configuration of xinetd is distributed across several files. /etc/xinetd.conf lists general options, while files in /etc/xinetd.d/ contain the configuration of specific services provided via xinetd. These files are included into the xinetd configuration by an include statement at the end of /etc/xinetd.conf.

Version 1


55






To configure xinetd, you need to know the following: 

“The File /etc/xinetd.conf” on page 56



“The Directory /etc/xinetd.d/” on page 57



“Internal Services” on page 58



“chkconfig” on page 59

The File /etc/xinetd.conf

In SUSE Linux Enterprise 11, the /etc/xinetd.conf file contains only general options, no service configurations. The following is the syntax of /etc/xinetd.conf for the default configuration parameters of xinetd: defaults { key operator parameter parameter. . . }

Operators include =, -=, and +=. Most attributes (keys) support only the operator =, but you can include additional values to some attributes by entering += or remove them by entering -=. The defaults entry in the configuration file is optional and allows you to set defaults such as the following: defaults { log_type = FILE /var/log/xinetd.log log_on_success = HOST EXIT DURATION log_on_failure = HOST ATTEMPT # only_from = localhost instances = 30 cps = 50 10 } includedir /etc/xinetd.d

The configurations for log_type and instances will be overwritten if something else has been defined in the individual service entries. For all other attributes, the default configurations are combined with the values set in the services. The log_type statement can define whether (as in the example) the output is written directly to a log file (/var/log/xinetd.log) or forwarded to the daemon syslog (such as log_type = SYSLOG authpriv). NOTE: If there are high security demands, you might want to consider leaving logging up to the syslog daemon in order to prevent potential unwanted access to the xinetd log file.

The keys log_on_success and log_on_failure configure what should be recorded in the log file, depending on whether the connection to a network service succeeds or fails. The key instances can be used to limit the maximum possible number of daemons for each service, which protects the machine from either intentional or

56


Version 1


accidental overload due to too many simultaneous connections (denial-of-service attempts). cps stands for connections per second. The first value (50) is the maximum number of connections per second that can be handled. the second value (10) is the wait period before accepting new connections after the maximum has been exceeded (helpful in preventing Denial of Service attacks). The directive includedir /etc/xinetd.d prompts xinetd to search all files in the directory /etc/xinetd.d/ for the configuration of services. The same attributes and the same syntax is used as in /etc/xinetd.conf. The Directory /etc/xinetd.d/

In the /etc/xinetd.d/ directory, there is a separate configuration file for every service. The main advantage of splitting the configuration in several files is improved transparency. The syntax for configuring network services in these files is similar to the one used for the options in /etc/xinetd.conf above: service service_name { key operator parameter parameter. . . key operator parameter parameter. . . }

The following is an example of the configuration of finger: # default: off # description: The finger server answers finger requests. # Finger is a protocol that allows remote users to see # information such as login name and login time for # currently logged in users. service finger { socket_type = stream protocol = tcp wait = no user = nobody server = /usr/sbin/in.fingerd server_args = -w disable = yes }

The significance of the keywords in the example is as follows: Table 1-5

Version 1

xinetd Configuration Parameters Keyword

Description

disable

Disables the service if set to yes.

protocol

Specifies the protocol (usually tcp or udp) used by the corresponding network service. The protocol must be listed in the /etc/protocols file.


57






Keyword

Description

server

Specifies the absolute pathname of the daemon to start.

server_args

Specifies which parameters to pass to the daemon when it starts.

socket_type

Specifies the type of socket (stream, dgram, raw, or seqpacket).

user

Indicates which user ID the daemon will start under. The user name must be listed in the /etc/passwd file.

wait

Specifies whether xinetd must wait for the daemon to release the port before it can process further connection requests for the same port (Yes: single-threaded) or not (No: multithreaded).

NOTE: For a description of all possible parameters, in a terminal window enter man xinetd.conf.

Internal Services

Certain services (such as echo, time, daytime, chargen, and discard) are provided by xinetd itself without calling another program. These are called internal services and are labeled in the configuration as follows: type = INTERNAL

Without this line, xinetd assumes that external services are involved. With services such as echo, which are both TCP- and UDP-based services, you not only specify the respective socket_type, but you also need to identify the service in the id field in such a way that it is properly distinguished from other services. The following two examples show this for echo. Echo over TCP: # /etc/xinet.d/echo # default: off # description: An echo server. This is the tcp version. service echo { type id socket_type protocol user wait disable FLAGS }

= = = = = = = =

INTERNAL echo-stream stream tcp root no yes IPv6 IPv4

Echo over UDP:

58


Version 1


# /etc/xinet.d/echo-udp # default: off # description: An echo server. This is the udp version. service echo { type id socket_type protocol user wait disable port FLAGS }

= = = = = = = = =

INTERNAL UNLISTED echo-dgram dgram udp root yes yes 7 IPv6 IPv4

chkconfig

The chkconfig program can be used to list services covered by xinetd: da10:~ # chkconfig -l ... xinetd based services: chargen: chargen-udp: daytime: daytime-udp: echo: ...

off off on on off

It can also be used to turn services on and off: da10:~ # daytime da10:~ # da10:~ # da10:~ # daytime

chkconfig daytime xinetd chkconfig daytime off chkconfig daytime off

Configure Access Control

The xinetd daemon recognizes four parameters used to control access: 

only_from: Lets you define which hosts can use which service. You can specify IP addresses (such as 192.168.1.1, 192.168.1.0, or 192.168.), network addresses (IP address with network mask), network names, or hostnames. For IPv6 addresses, you have to specify the complete address or a network address with netmask. You can define this parameter in the defaults or service section.



Version 1

no_access: Lets you define which hosts are excluded from access. The specification follows the same rules as outlined in only_from.


59






You can define this parameter in the defaults or service section. 

access_time: Lets you define when the service is available (in 24-hour format). You can define this parameter in the defaults or service section.



disabled: Lets you completely shut off a server. This also applies to logging access attempts. The following is an example for the attribute disabled: disabled = finger

With this setting, the service finger is switched off completely. If a computer tries to access the service, the attempt is not even logged. This parameter disabled can be used only in the defaults section. (Within a service section, the corresponding parameter to use is disable. Note the missing d at the end!) The following is an example for the Telnet service: # default: off # description: Telnet is the old login server which is # INSECURE and should therefore not be used. Use secure # shell (openssh). If you need telnetd not to # "keep-alives" e.g. if it runs over an ISDN uplink, # add "-n". See 'man telnetd' for more details. service telnet { socket_type = stream protocol = tcp wait = no user = root server = /usr/sbin/in.telnetd server_args = -n only_from = 192.168.0.3 192.168.0.7 only_from += 192.168.0.10 192.168.0.12 only_from += 192.168.1.0/24 no_access = 192.168.1.10 flags = IDONLY access_times = 07:00-21:00 # disable = yes }

These settings result in the following: 

Access is permitted for machines with the following IP addresses: 192.168.0.3 192.168.0.7 192.168.0.10 192.168.0.12 192.168.1.0-255

60



Access is denied to the host with the IP address 192.168.1.10.



The service is available from 7:00 a.m. to 9:00 p.m.


Version 1


If you place high demands on access monitoring, you can tighten the security level even more by using the INTERCEPT and IDONLY parameters in the flags entry. If the USERID parameter was set in the log_on_access and log_on_failure entries, IDONLY then makes sure that a connection to the network service is permitted only when the user identification service (such as identd) of the host requesting the network service issues the user ID. If the INTERCEPT parameter has been entered as well, xinetd also attempts to make sure that an authorized host is on the other end of already existing connections—that the connection has not been intercepted. However, connection monitoring does not function with multithreaded or internal xinetd services. In addition, it puts a heavy burden on the network connection and the performance of the network service. Configure Log Files

Almost every hacker has to make several attempts and needs some time before achieving success. To protect your server, you not only need hacker-resistant software, but you also need log files that the system administrator can use to detect unauthorized login attempts. Because of this, it does not make sense to only deter unauthorized access attempts. To maintain optimal system security, you also need to record failed and unauthorized connection attempts. To shut off a service but still retain its logging functions, configure only_from without using any additional parameters (such as the following): only_from

=

Logging through xinetd is controlled by the log_type statement along with the log_on_success and log_on_failure attributes. These let you record from which host and for how long an access attempt was made, and which user was using the service (if the remote host supports this feature). In addition, you can also log the circumstances of how and why the network service was used. However, even the best log does not mean much if you do not check it on a regular basis for failed connection attempts.

Version 1


61






Exercise 1-3

Configure the Internet Daemon (xinetd) In the first part of this exercise, use the YaST module Network Services (xinetd) to set up a Telnet server on your computer. In the second part, install vsftp if it is not yet installed, and edit its configuration in / etc/xinetd.d/ to activate the service. You will find this exercise in the workbook. (End of Exercise)

62


Version 1


Objective 4

Enable an FTP Server To enable an FTP server on SLES 11 you need to understand the following: 

“The Role of an FTP Server” on page 63



“How FTP Works” on page 63



“Advantages of PureFTPd Server” on page 64



“Installation of PureFTPd” on page 65



“Configuration of PureFTPd” on page 66



“Management of PureFTPd Logs” on page 70

The Role of an FTP Server As the name indicates, the File Transfer Protocol (FTP) enables the transfer of files from one computer to another. Today, FTP is used mainly for file transfer on the Internet, while internal networks usually rely on NFS or SMB (Server Message Blocks) for file transfers. The following basic features are supported by FTP and available to the user: 

Sending, receiving, deleting, and renaming files



Creating, deleting, and changing directories



Transferring data in binary or ASCII mode

An FTP server allows access after authentication against a password database. As a rule, these are the /etc/passwd and /etc/shadow files. Other authentication systems, such as NIS or LDAP, are possible. The PureFTPd FTP server also supports authentication against its own password database, which is independent from the /etc/passwd and /etc/shadow files. In addition, guest access can be set up as anonymous FTP (aFTP). Generally, users logging in to aFTP use anonymous or ftp as their username and use their e-mail address as the password. The address is normally not checked for correctness, although some servers check the syntax and require an entry in the format [email protected]. An anonymous user is normally given access to a restricted directory tree (a chroot environment).

How FTP Works The FTP protocol uses the TCP transport protocol. FTP uses two TCP connections between the client and the server, one for commands and the other for data. The first of these connections sends FTP commands from the client to the server. To begin an FTP session, the client addresses the FTP command channel on port 21 of the server. The client then sends its commands to the FTP server.

Version 1


63






For the actual file transfer, or in response to certain commands like ls, FTP uses the second TCP connection, which is created only when a file is ready for transfer (for example, by a GET or PUT command). There are two different types of data transfer: 

Figure 1-14

Active data transfer: The FTP client offers the FTP server an unprivileged TCP port for the data channel connection. The server then initializes the data channel from its port 20 to the port offered by the client.

Active FTP



Passive data transfer: The FTP client informs the FTP server that it wants to use a passive data transfer using the PASV command. The FTP server then offers the FTP client an unprivileged TCP port for a data channel connection and the client initializes the data channel to the port offered by the server.

Figure 1-15

Passive FTP

Passive FTP transfer avoids the need of having to allow incoming connections on the client. This makes it easier for firewall administrators on the client side to establish a secure configuration.

Advantages of PureFTPd Server A number of FTP servers for Linux are available, such as the standard FTP server, in.ftpd; the FTP server from Washington University, wu.ftpd; proftpd; or the PureFTPd FTP server, pure-ftpd. PureFTPd has several features that make it stand out from other FTP servers:

64



Consistent use of chroot environments



Uncomplicated configuration of virtual FTP servers


Version 1




Virtual users independent of the system users listed in the file /etc/passwd



Configuration via command line parameters or with a configuration file

Installation of PureFTPd You can install the PureFTPd server with the YaST Software Management module by selecting the pure-ftpd package. After installation, you configure the FTP server manually by editing the /etc/ pure-ftpd/pure-ftpd.conf configuration file. You can run PureFTPd server using one of the following methods: 

From the command line: Enter pure-ftpd options (such as pure-ftpd -B -e). If you start pure-ftpd this way, no configuration file is used. NOTE: For details on the possible pure-ftpd options, enter man pure-ftpd.



From a start script: Enter /etc/init.d/pure-ftpd start (or rcpure-ftpd start). To stop the PureFTPd service, enter rcpure-ftpd stop. The /etc/pure-ftpd/pure-ftpd.conf configuration file is parsed by the Perl script /usr/sbin/pure-config-args to translate the parameters in the configuration file to command line options. These options are then passed to the /usr/sbin/pure-ftpd daemon. If you want pure-ftpd to be initialized upon startup, you need to set symbolic links by entering the following: insserv /etc/init.d/pure-ftpd



From xinetd: If you want to start PureFTPd via xinetd, you need to edit the / etc/xinetd.d/pure-ftpd file and add the required options as in the following example: # # # # # # # # # # #

default: off description: The ftpd server serves FTP connections. It uses normal, unencrypted usernames and passwords for authentication. This ftpd is the pure-ftpd. ** NOTE ** when using pure-ftpd from xinetd the arguments to control it's behaviour should be added here in this file in the "server_args" line since the configuration file /etc/pure-ftpd.conf is only for standalone pure-ftpd. The command "/usr/sbin/pure-config-args /etc/pure-ftpd.conf" will print the arguments needed for behaviour like standalone pure-ftpd.

service ftp { socket_type = stream server = /usr/sbin/pure-ftpd server_args = -A -i

Version 1


65






protocol = tcp user = root wait = no disable = yes }

Because the pure-ftpd.conf configuration file is not parsed or evaluated when PureFTPd is started via xinetd, all the required options must be given in the /etc/xinetd.d/pure-ftpd file as server arguments in the server_args line. NOTE: For details on all command line options for PureFTPd, enter pure-ftpd --help.

Configuration of PureFTPd To perform basic configuration tasks for the PureFTPd server, you need to know the following: 

“Configure Anonymous FTP” on page 66



“Configure FTP with Virtual Hosts for Anonymous FTP” on page 67



“Configure FTP for Authorized Users” on page 68



“Configure FTP with Virtual Users Not Included in /etc/passwd” on page 69

Configure Anonymous FTP

To configure anonymous FTP for PureFTPd, you need to have an FTP user and home directory (such as /srv/ftp/) in the /etc/passwd file (exists by default in SLES 11). However (unlike other FTP servers), you do not need to create any subdirectories (such as bin) in the home directory. The following is an example of a simple pure-ftpd.conf file: # Cage in every user in his home directory ChrootEveryone yes # Don't allow authenticated users - have a public anonymous FTP only. AnonymousOnly yes # Disallow anonymous users to upload new files (no = upload is allowed) AnonymousCantUpload yes # Fork in background Daemonize

yes

In this configuration file, it is possible to log in only as an anonymous user, regardless of what username is given. It is not possible to change to a directory other than / srv/ftp/ or below, and no files can be uploaded to the server—only downloads are possible. The server detaches from the terminal it is started in (Daemonize yes).

66


Version 1


The equivalent command on the command line would be pure-ftpd -A -e -i -B If you want anonymous users to be able to upload files to the server, the configuration file would look like the following: # Cage in every user in his home directory ChrootEveryone yes # Don’t allow authenticated users - have a public anonymous FTP only. AnonymousOnly yes # Allow anonymous users to upload new files AnonymousCantUpload no # Disallow downloading of files owned by “ftp”, ie. # files that were uploaded but not validated by a local admin. AntiWarez yes # Never overwrite files. When a file whose name already exists is # uploaded, it gets automatically renamed to file.1, file.2, file.3, ... AutoRename yes

You have to allow write access to the /sr/ftp directory, using the chown ftp / srv/ftp command, and also have to make sure the permissions are set properly, using the chmod 755 /srv/ftp command. The AntiWarez option is recommended because the server could otherwise be misused to handle undesirable (or even illegal) data. Files uploaded to the server belong to the user ftp, but files of the user ftp cannot be downloaded from the server because of this option. The administrator must change the owner of the file (for instance to root) using the chown command before this is possible. The last line ensures that a file that might already exist is not overwritten. Instead, a new file is created with a number on the end (such as file.1). The equivalent command on the command line would be pure-ftpd -A -e -s -r. Configure FTP with Virtual Hosts for Anonymous FTP

Virtual FTP hosts allow a number of FTP sites to be hosted on one machine (such as ftp.slc.digitalairlines.com and ftp.muc.digitalairlines.com). Each of these FTP sites requires its own IP address, because the FTP protocol cannot handle hostnames. For this reason, you need to assign multiple IP addresses to your network card. In addition, you need to configure the DNS so that domain names match IP addresses correctly. You configure virtual hosts through the /etc/pure-ftpd/vhosts/ directory, not by changing the /etc/pure-ftpd/pure-ftpd.conf file.

Version 1


67






The configuration is a very simple two-step process: 1.

From the command line, use the ip command to create virtual network devices, as in the following example: ip address add 172.17.8.80/16 brd + dev eth0 ip address add 172.17.8.81/16 brd + dev eth0

2.

Create a symbolic link in /etc/pure-ftpd/vhosts/ with this IP address, which is linked to the directory containing the files available at this IP address. The following is an example: cd /etc/pure-ftpd/vhosts/ ln -s /ftp/directory/of/ftp.slc.digitalairlines.com \ 172.17.8.80 ln -s /ftp/directory/of/ftp.muc.digitalairlines.com \ 172.17.8.81

To prevent these anonymous areas from being filled with undesired files, start PureFTPd with the option -i. This makes it impossible for anonymous users to upload files. Virtual FTP servers handle only anonymous FTP users and not authorized users. Configure FTP for Authorized Users

Configuring an FTP server for authorized users is important for those who are hosting Web sites. Individual customers maintain their own pages in directories which they alone have access to. The following is an example configuration in which no anonymous FTP access is allowed and where all users are limited to their home directory: # Cage in every user in his home directory ChrootEveryone yes # Disallow anonymous connections. Only allow authenticated users. NoAnonymous yes

The equivalent command on the command line would be pure-ftpd -A -E. To run the server in the background, add the -B option on the command line, or Daemonize yes to the configuration file. If you want to modify the above configuration so that certain users are not confined in a chroot environment (for example, members of a group ftpadmin with the GID 500), you could enter the following: # Cage in every user in his home directory ChrootEveryone no # If the previous option is set to "no", members of the following group # won't be caged. Others will be. If you don't want chroot()ing anyone,

68


Version 1


# just comment out ChrootEveryone and TrustedGID. TrustedGID 500 # Disallow anonymous connections. Only allow authenticated users. NoAnonymous yes

The equivalent command on the command line would be pure-ftpd -a 500 E. To run the server in the background, add the -B option on the command line, or Daemonize yes to the configuration file. Configure FTP with Virtual Users Not Included in /etc/passwd

PureFTPd provides a way of administering FTP users in a file of its own, similar in structure to the /etc/passwd file. The advantages are that PureFTP users are separated from system users and can access the system by FTP only. A normal login is not possible if there are no matching entries in the /etc/passwd file. To administer PureFTPd users in a separate user database, you need to create a system user whose UID the FTP users appear in the system: useradd -m ftpusers Once this is done, you can then create the FTP users with pure-pw (in the file / etc/pure-ftpd/pureftpd.passwd) by entering the following (using user joe as an example): pure-pw useradd joe -u ftpusers -d /home/ftpusers/joe You are requested to enter a password (twice) for the user. With the help of command line options, you can specify user options such as quotas for the number of files (-n 100), size limits in MB (-N 10), or the times when users can log in (-z 0900-1800). PureFTPd does not use the /etc/pure-ftpd/pureftpd.passwd ASCII file directly, but the /etc/pure-ftpd/pureftpd.pdb binary file. This file must be regenerated every time changes are made by entering pure-pw mkdb. To use the special user database, you need to start PureFTPd with the option -l puredb:/path/pureftpd.pdb. Combining this with the -j option ensures that the home directory is created as soon as the user logs in. The following is an example: pure-ftpd -j -l puredb:/etc/pure-ftpd/pureftpd.pdb The corresponding entries in the configuration files would look like this:

Version 1


69






# Automatically create home directories if they are missing CreateHomeDir yes # PureDB user database (see README.Virtual-Users) PureDB /etc/pure-ftpd/pureftpd.pdb

You can modify FTP users by entering pure-pw usermod and delete users by entering pure-pw userdel. NOTE: For additional details on using the pure-pw syntax, enter man 8 pure-pw or pure-pw --help.

Management of PureFTPd Logs PureFTPd sends its messages to the syslog daemon, so these messages appear in the usual log files. It is also possible for PureFTPd to write its own log files in various formats. The option for this is -O format:logfile, where format can be clf (Common Log Format, a format similar to that used by the Apache Web server), stats (special output format, designed for log file analysis software), or w3c (special output format parsed by most commercial log analyzers). Suitable entries already exist in the /etc/pure-ftpd/pure-ftpd.conf configuration file. You need to remove the comment symbol (#) to activate the entry. The following is an example entry: AltLog

70

clf:/var/log/pureftpd.log


Version 1


Exercise 1-4

Configure Anonymous PureFTPd Access In this exercise, you configure anonymous FTP access with the permission to upload files. You will find this exercise in the workbook.

(End of Exercise)

Version 1


71






Summary Objective

Summary

Configure NFS (Network File System)

Network File System (NFS) lets you configure an NFS file server that gives users transparent files access over the network. Directories to export are specified in /etc/exports. NFS is an RPC-based service and thus needs the portmapper (rpcbind) to function properly. /etc/init.d/nfsserver is the script to start the NFS server. Directories from other servers can be imported using the mount command or during boot according to entries in the /etc/fstab file.

Configure Time on SUSE Linux Enterprise Server 11

In order to implement a uniform time on all computers in a network, all computers must have access to at least one time server. The ntp package contains the ntpd time server to get the time from another time server as well as provide time to other machines on the network via NTP.

Enable the Extended Internet Daemon (xinetd)

The Extended Internet Daemon (xinetd) is used to start various network services like FTP or POP3 when a connection is made to the respective port. The xinetd configuration is contained in the /etc/ xinetd.conf file and in individual files for the various services in the /etc/xinetd.d/ directory. Configuration can be done with the YaST Network Services Module, an editor and, to a certain extent, the chkconfig command.

Enable an FTP Server

FTP is a widely used file transfer protocol. It uses two TCP connections, one for control commands and one for the data transfer. There are various FTP servers available. PureFTPd has the advantage of a flexible configuration and the reputation of being secure. It can be configured via a configuration file or command line options.

72


Version 1


SECTION 2

Manage Printing

SUSE Linux Enterprise Server 11 uses CUPS (Common UNIX Printing System) to provide print services. CUPS is based on the Internet Printing Protocol (IPP). This protocol is supported by most printer manufacturers and operating systems. IPP is a standardized printer protocol that enables authentication and access control. This section covers the configuration of locally connected and remote printers, the management of print queues using CUPS command line tools, the configuration of CUPS as print server to make locally connected printers available to others in the network, and access control. Objectives

Version 1

1.

“Configure CUPS” on page 74

2.

“Manage Print Jobs and Queues” on page 91

3.

“Understand how CUPS Works” on page 99

4.

“Configure and Manage Print Server Access” on page 106

5.

“Use the Web Interface to Manage a CUPS Server” on page 113


73



Manage Printing



Objective 1

Configure CUPS YaST provides printer installation and configuration functionality. To configure a printer, you need to know the following: 

“When to Configure a Printer” on page 74



“Required Printing Software” on page 75



“How to Add Printers” on page 76

When to Configure a Printer You can configure your printer at the following times: 

Figure 2-1

During installation: If you are at the Hardware Configuration dialog during installation (see the following figure) and your automatic detection is not correct, select the Printer link or use the Change drop-down list:

Installation: Hardware Configuration

Note that during installation, only locally connected printers are detected automatically and listed under Printer. However, if you select Printer, the complete YaST printer configuration options are at your disposal to configure local and remote printers or to configure CUPS:

74


Version 1


Figure 2-2

Installation: Printer Configuration



After installation: You can change your printer configuration settings from the YaST Control Center by selecting Hardware > Printer. You can also start the YaST printer configuration module directly from a terminal window with the yast2 printer command.

Required Printing Software The following packages are needed to set up a print server: Table 2-1

CUPS Software Components Package

Content

cups

Provides the cupsd printer daemon.

cups-client

Provides the command line printing tools.

cups-drivers

Provides the PPD files for print queues.

cups-libs

Should always be installed, because a number of programs (such as Samba) are linked against the CUPS libraries.

foomatic-filters

Filter scripts used by the printer spoolers to convert the incoming PostScript data into the printer's native format.

These files are installed automatically if YaST is used for printer configuration.

Version 1


75



Manage Printing



YaST also creates the symbolic links in runlevel directories to ensure that the CUPS daemon is started automatically when booting. Other packages required by the printing system, such as ghostscript-library, are automatically selected during a standard installation.

How to Add Printers There are two ways to add printers: 

“Add a Printer with YaST” on page 76



“Add a Printer from the Command Line” on page 89

Add a Printer with YaST

The Printer Configuration dialog used to configure your printer is the same during and after installation. You can access the dialog either by selecting YaST > Hardware > Printer or by entering yast2 printer in a terminal window as root. The following dialog appears: Figure 2-3

Printer Configuration

In the left part of the dialog, you can select different aspects of the printer configuration. The right part of the dialog shows the configuration options available for your selection.

76


Version 1


The left part offers the following selections: 

“Printer Configurations” on page 77



“Access Network Printer” on page 80



“Print via Print Server Machine” on page 82



“Special” on page 83



“Print via Network” on page 84



“Share Printers” on page 87



“Policies” on page 88



“Autoconfig Settings” on page 88

Printer Configurations

The Printer Configurations dialog gives you an overview over the configured printers and allows you to add, edit, or delete existing print queues. To add a printer that does not show up in the Printer Configurations dialog, select Add. A screen similar to the following (depending on the make of the attached printer) appears: Figure 2-4

Add New Printer Configuration

NOTE: If you want to change the suggested name of the new print queue, you have to do it at this point in the Set Name box.

Version 1


77



Manage Printing



When you click More Connections, the local connections are scanned again and any newly detected printers are added to the page. Click OK to add them to the list of configured printers: Figure 2-5


In the example above, the existing printer was detected again. This might be useful if you want to have queues for the same printer with different settings. Select the new entry and click Edit to change the settings for this queue. Should you have no use for the new entry, select it and click Delete.

78


Version 1


Clicking Connection Wizard in the Add New Printer Configuration dialog opens the following dialog: Figure 2-6

Printer Connection Wizard

Selecting an item on the left opens a new pane on the right where you can enter the specific parameters for your choice. Selecting an item under Directly Connected Device on the left and then clicking OK leads to the Add New Printer Configuration dialog. The other entries lead to slightly different dialogs:

Version 1



Access Network Printer



Print Via Print Server Machine



Special


79



Manage Printing



Access Network Printer

Depending on what type of network printer you select on the left, the pane on the right lists the parameters needed to access that type of printer. The following shows the pane for the TCP port Connection Settings: Figure 2-7

Printer: Connection Wizard

Type the IP address of the printer and its manufacturer. To test the connection, you can click the Test Connection button. Click OK to continue.

80


Version 1


You are returned to the Add New Printer Configuration dialog, but when configuring a network printer, you have to manually select a driver from the list of available drivers, as shown in the following: Figure 2-8

Add New Printer Configuration

Select the driver for your printer and click OK. You are returned to the initial Printer Configurations dialog with your new printer listed:

Version 1


81



Manage Printing



Figure 2-9


Print via Print Server Machine

To access a printer that is connected to a print server, in the Connection Wizard dialog select the type of print server your printer is connected to.

82


Version 1


The pane on the right allows you to enter the configuration values needed to access the printer. The following shows the pane to access a CUPS server, with some values already entered manually: Figure 2-10

Printer: Connection Wizard

Clicking OK returns you to the Add New Printer Configuration dialog where you can select a driver and change the queue name. Clicking OK once more returns you to the Printer Configurations dialog with the new printer listed as a local printer. Special

CUPS supports the IPP, LPD, SMB, IPX, and socket protocols. After selecting the entry Specify Arbitrary Device URI, you can enter the device URI (Universal Resource Identifier) to access printers using these protocols. See “Add a Printer from the Command Line” on page 89. 

IPP (Internet Printing Protocol): IPP is a relatively new protocol (since 1999) that is based on the HTTP protocol. Compared to other protocols, it can transmit much more job-related data. CUPS uses IPP for the internal data transmission. This is the preferred protocol for a forwarding queue between CUPS servers. The port number for IPP is 631. Device URI example: ipp://cupsserver/printers/printqueue.

Version 1


83



Manage Printing





LPD (Line Printer Daemon): The LPD protocol is described in RFC 1179 (Requests For Comments can be found at (http://www.ietf.org/rfc.html)). Because some job-related data, such as the printer queue, is sent before the actual print data, a printer queue must be specified when configuring the LPD protocol for data transmission. The implementations of most printer manufacturers are flexible enough to accept any name as the printer queue. The printer manual might indicate which name to use (such as LPT, LPT1, or LP1). An LPD queue can also be configured on a different Linux or UNIX host in a network that uses the CUPS system. The port number for an LPD service is 515. Device URI example: lpd://host-printer/LPT1



SMB (Standard Message Block): CUPS supports printing on printers connected to Windows shares. The protocol used for this purpose is SMB. SMB uses port numbers 137, 138, and 139. Device URI examples: smb://user:password@workgroup/server/printer smb://user:password@host/printer smb://server/printer



IPX. This is used to print via a Novell NetWare Server.



socket. This is used to connect to a printer equipped with a network port, such as HP’s JetDirect technology. The socket port numbers that are commonly used include 9100 and 35. Device URI example: socket://host-printer:9100/

84


Version 1


Print via Network

The Print via Network page in the main Printer Configurations window allows you to configure how to connect to other CUPS servers in the network. Figure 2-11

Print via Network

CUPS servers can communicate the printers they make available using a mechanism called browsing. The CUPS server that has printers connected sends out broadcast packets at regular intervals publishing the available printers. A local CUPS server makes these printers available to the local users.

Version 1


85



Manage Printing



Figure 2-12

CUPS Broadcasts

If this function is enabled, the server broadcasts the printer information every 30 seconds. This printer information typically uses only 80 bytes per printer; therefore, you can add a large number of servers and printers. The Use CUPS to Print Via Network section has the following options: 

Do not Receive Printer Information from Remote CUPS Servers: When this option is selected, printers that are published by other CUPS servers using the browsing mechanism are not made available locally. Any printers you want to use have to be set up as described in “Printer Configurations” on page 77.



Receive Printer Information from Remote CUPS Servers: When this option is selected, the local CUPS server uses the browsing information broadcast within the network to make printers available locally. Using the drop-down menu under Accept Information from the Following Servers, you can limit the servers that browsing information is accepted from. This option is probably the most convenient, as any printers that other CUPS servers advertise using the broadcast mechanism are available automatically.



Do All Your Printing Directly via One Remote CUPS Server: When this option is selected, no local CUPS server is running. All print jobs are sent to the single print server you specify in the Hostname/IP Address field. The server name is written to the /etc/cups/client.conf file. This choice is useful only when all printing is done via exactly one remote CUPS server.

86


Version 1


Clicking the Connection Wizard button opens the same dialog as described in “Printer Configurations” on page 77. Share Printers

The Share Printers page n the main Printer Configurations window allows you to configure how the CUPS server can be accessed from the network and whether or not it advertises its available printers to the clients using browsing. Figure 2-13

CUPS: Share Printers

There are two main options: 

Deny Remote Access: When this option is selected, the CUPS server binds to localhost (127.0.0.1) only and is not accessible from any attached network.



Allow Remote Access: Here you can decide if you only want to allow remote access, or if you additionally want turn on browsing: 





Version 1

For computers within the local network: Selecting this option (and no other) allows access on all local interfaces (eth0, eth1, etc.), but does not turn on browsing. Publish printers by default in the local network: This includes the previous choice, but turns on browsing on all local interfaces as well. Via network interfaces specified below: Instead of allowing access with or without browsing on all local interfaces as above, you can make this choice separately for each interface by clicking Add.


87



Manage Printing



Select the interface and check Publish printers by default via the interface below if you want to turn on browsing on this interface. Then click OK. 

For Experts: Here you can define more specific limitations based on IP addresses or networks for access and browsing.

The settings are written to the /etc/cups/cupsd.conf file. Policies

The Policies page, accessible from the main Printer Configurations dialog, allows you to set the error and the operation policy. Figure 2-14

CUPS: Policies

Autoconfig Settings

The settings you make on this page determine how CUPS deals with printers when they are connected to a USB port.

88


Version 1


Figure 2-15

CUPS: Autoconfig Settings

Add a Printer from the Command Line

Besides using YaST, you can also configure CUPS with command line tools. After collecting the information you need (such as the PPD [Postscript Printer Description] file and the name of the device), use the lpadmin command to add a printer: lpadmin

-p

queue

-v

device-URI

-P

PPD-file

-E

The -p option specifies the print queue name of the printer, the -v option sets the device URI attribute of the printer queue (see“Special” on page 83), and the -P option is used to specify the PPD file. Do not use -E as the first option. For all CUPS commands, -E as the first argument implies the use of an encrypted connection, and -E at the end enables the printer to accept print jobs. For example, to enable a parallel printer, enter a command similar to the following (on one line): lpadmin -p ps -v parallel:/dev/lp0 -P /usr/share/cups/model/Postscript.ppd.gz -E To enable a network printer, enter a command similar to the following (on one line): lpadmin -p ps -v socket://10.0.0.200:9100/ /usr/share/cups/model/Postscript-level1.ppd.gz

Version 1


-P -E

89



Manage Printing



Exercise 2-1

Configure Printers In this exercise, you add a local printer and print to a remote queue. You will find this exercise in the workbook. (End of Exercise)

90


Version 1


Objective 2

Manage Print Jobs and Queues CUPS comes with several command line tools to start, stop, and modify print queues. The command line tools for the CUPS printing system and their man pages are included in the cups-client package. The manual pages are also accessible using the CUPS Web interface. To access this interface from SLES 11, open a browser and point to the local http page at http:// localhost:631/help/. The CUPS tools allow you to use commands according to two different styles or conventions: 

Berkeley (these commands are identical to those used with the LPRng printing system)



System V

Compared with Berkeley style, System V provides a somewhat more extensive range of features for printer administration. To manage printer queues, you need to know how to do the following: 

“Generate a Print Job” on page 91



“Display Information on Print Jobs” on page 92



“Cancel Print Jobs” on page 93



“Manage Queues” on page 94



“Configure Queues” on page 94



“Start and Stop CUPS” on page 97

Print queues can also be managed via a Web interface, which is covered later in this section.

Generate a Print Job Use the following commands to generate a print job: 

Berkeley: lpr -P queue file



System V: lp -d queue file

Example: lpr -P color chart.ps or: lp -d color chart.ps With these commands, the chart.ps file is submitted to the color queue. If no queue is specified, the job is printed to the default queue.

Version 1


91



Manage Printing



The -o parameter needs to be used whenever any additional print options are specified: lpr -P lp -o duplex=none order.ps or: lp -d lp -o duplex=none order.ps This submits the order.ps file to the lp queue and also disables duplex printing for the corresponding device (duplex=none). To view possible options, enter lpoptions -l -d queue (see “Configure Queues” on page 94). You have to give the command in a slightly different form to print through a remote queue: 

Berkeley: lpr -P queue@server file



System V: lp -d queue -h server file

Example: lpr -P lp -H da10.digitalairlines.com /etc/motd or: lp -d lp -h da10.digitalairlines.com /etc/motd This submits the /etc/motd file to the lp queue located on the da10.digitalairlines.com print server. NOTE: For more information on these command line tools, enter man lpr and man lp,

Display Information on Print Jobs Use the following commands to display print job information: 

Berkeley: lpq -P queue



System V: lpstat -o queue -p printer

To display active print jobs of the default queue, use the lpq command as shown in the following: geeko@da10:~ # lpq draft is ready and printing Rank Owner Job File(s) active root 14 fstab

Total Size 1024 bytes

To list the same information in a slightly different format, use lpq -l.

92


Version 1


To display the print jobs of another queue, enter the -P queue as shown in the following: geeko@da10:~ # lpq -P printer printer is ready no entries

To display the active print jobs of all available queues, enter lpq -a as shown in the following: geeko@da10:~ # lpq -a no entries

To actualize the output in a fixed interval, enter lpq -P queue +seconds The following shows the output of lpstat -o queue -p queue. The lpstat -a command shows information on the accepting state: da10:~ # lpstat -o draft -p draft draft-6 root 1024 Wed Feb 4 16:06:53 2009 printer draft now printing draft-0. enabled since Wed Feb 16:06:53 2009 Connected to host, sending print job... geeko@da10:~ # lpstat -a draft accepting requests since Tue Feb 3 14:11:08 2009 ps accepting requests since Wed Feb 4 16:19:43 2009

4

NOTE: For more information on these commands, enter man lpq and man lpstat.

Cancel Print Jobs Use the following commands to cancel a print job: 

Berkeley: lprm -P queue jobnumber



System V: cancel [-h server] queue-jobnumber

NOTE: For more information on these commands, enter man lprm and man cancel.

Version 1


93



Manage Printing



Manage Queues In addition to controlling single jobs in a queue, you can also control the queue itself. 

Disable printing on a queue while jobs can still be sent to it by entering cupsdisable destination. Queues that are disabled still accept jobs for printing but won't actually print any files until they are enabled again. Disabling a print queue is useful if a printer malfunctions and you need time to fix the problem.



Start printing again on a queue that is disabled by entering cupsenable destination. If there are any queued print jobs, they are printed after the printer is enabled.



Stop accepting print jobs on a queue by entering /usr/sbin/reject destination. With the /usr/sbin/reject command, the printer finishes the print jobs in the queue but rejects any new print jobs. This command is useful for times when you need to perform maintenance on a printer and the printer will not be available for a significant period of time. NOTE: lpstat -a shows information on the accepting state of the queues.



Accept print jobs again on a queue that rejected them by entering /usr/sbin/ accept destination. By using this command, you can reset the print queue to begin accepting new print jobs. If the queue is also disabled, actual printing starts only after enabling the queue again.

NOTE: The commands cupsdisable, cupsenable, and reject are all links pointing to / usr/sbin/enable.

Configure Queues Printer-specific options that affect the physical aspects of the output are stored in the PPD (PostScript Printer Description) file for each queue in the /etc/cups/ppd/ directory. PPD is the computer language that describes the properties (such as resolution) and options (such as duplex unit) of PostScript printers. These descriptions are necessary to use the various printer options in CUPS. During the installation of SUSE Linux Enterprise Server 11, a lot of PPD files are pre-installed. In this way, even printers that do not have built-in PostScript support can be used.

94


Version 1


If a PostScript printer is configured, the best approach is to get a suitable PPD file and store it in the /usr/share/cups/model/ directory. You can then select the PPD file during the installation. If the model does not show up, select Add Driver in the Add New Printer Configuration dialog (Figure 2-8) and follow the simple steps to add the PPD file to the database. Users can see the current settings of a local queue by entering lpoptions -p queue -l NOTE: The sequence of options is important. If you specify -l first, the settings of the default queue are listed, no matter what you specify after -p.

The output of this command has the following structure: option/string: value value value ...

The following is an example: da10:~ # lpoptions -l HalftoningAlgorithm/Halftoning Algorithm: Accurate *Standard WTS REt/REt Setting: Dark Light *Medium Off TonerDensity/Toner Density: 1 2 *3 4 5 Duplex/Double-Sided Printing: *DuplexNoTumble DuplexTumble None Manualfeed/Manual Feed of Paper: Off On InputSlot/Media Source: *Default Tray1 Tray2 Tray3 Tray4 Envelope Manual Auto Copies/Number of Copies: *1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ... PageSize/Page Size: *A4 Letter 11x17 A3 A5 B5 Env10 EnvC5 EnvDL EnvISOB5 EnvMonarch Executive Legal PageRegion/PageRegion: A4 Letter 11x17 A3 A5 B5 Env10 EnvC5 EnvDL EnvISOB5 EnvMonarch Executive Legal Resolution/Resolution: 75x75dpi *150x150dpi 300x300dpi 600x600dpi Economode/Toner Saving: *Off On LowToner/Behaviour when Toner Low: *Continue Stop

The * symbol in front of a value indicates the currently active setting. The significance of some of these options is as follows: 

REt/REt Setting: (Resolution Enhancement) Includes three modes to improve the quality of dark, light, and medium print jobs. Generally, the difference in print quality is small.

Version 1



TonerDensity/Toner Density: Specifies the quantity of toner (1=little, 5=much).



Duplex/Double-Sided Printing: Disables or enables double-sided printing, assuming that your printer supports duplex printing.



InputSlot/Media Source: If your printer has different paper trays, lets you select the tray for your print job.



Copies/Number of Copies: Specifies the number of copies printed.


95



Manage Printing





PageSize/Page Size: Specifies the physical size of the paper in the selected paper tray.



PageRegion/PageRegion: Normally equals the page size. This option is read by the PostScript interpreter.



Resolution/Resolution: Specifies the resolution used for the print queue.



Economode/Toner Saving: Used to enable economode to save toner, but the quality of prints degrades.



LowToner/Behaviour when Toner Low: Specifies whether the printer continues or stops printing when the toner gets low.

To change any of the options for a local queue, enter a command with the following syntax: lpoptions -p queue -o option=value The following command changes the page size of the lp queue to Letter: lpoptions -p lp -o PageSize=Letter However, the range of users affected by the new settings varies, depending on which user has actually changed the settings: 

If a normal user (such as geeko) enters a command as above, the changes apply only to that user and are stored in the ~/.cups/lpoptions file (in the user’s home directory).



If root enters the command, changes apply to all users on the corresponding host. They are then used as default and stored in the /etc/cups/lpoptions file. The PPD file of the queue, however, is not modified by this.

There is a way for root to change the defaults in the PPD file of any local queue. Such changes would apply network wide to all users submitting print jobs to the corresponding queue. To achieve this, enter (as root) lpadmin -p queue -o option=value For example, to set the default page size for the lp queue, enter lpadmin -p lp -o PageSize=Letter CUPS provides collections of printers called printer classes. Jobs sent to a class are forwarded to the first available printer in the class. You can also use the lpadmin command to

96



Define classes of printers or queues.



Edit such classes (by adding a queue to a class or deleting a queue from a class).



Delete classes.


Version 1


For example, to add a queue to a class, enter lpadmin -p queue -c class If the class does not exist yet, it will be automatically created. To remove a queue from a class, enter lpadmin -p queue -r class If the class will be empty (with no other queues left in it) as a result of such a command, it will be automatically deleted. To see which queues belong to which class on a given host, look at the /etc/cups/ classes.conf file. NOTE: For more information on all the available options of lpadmin, enter man lpadmin. You can also get information on the commands covered above in a browser by entering the following http location http://localhost:631/help/ (notice its a location found locally on your SLES 11 machine); and then selecting Man Pages.

Start and Stop CUPS As the root user, you can start or stop cupsd manually with the following commands: 

/etc/init.d/cups start or rccups start



/etc/init.d/cups stop or rccups stop

If you make changes manually to the /etc/cups/cupsd.conf file, you need to restart the daemon by entering /etc/init.d/cups restart or rccups restart.

Version 1


97



Manage Printing



Exercise 2-2

Manage Printers from the Command Line In this exercise, you practice managing printer queues from the command line. You will find this exercise in the workbook. (End of Exercise)

98


Version 1


Objective 3

Understand how CUPS Works To understand how CUPS works, you need to understand the following: 

“Steps of the Printing Process” on page 99



“Print Queues” on page 100



“Log Files” on page 102



“Configuration File” on page 105

Steps of the Printing Process The printing process involves the following steps: 1.

A print job is submitted by a user or program.

2.

The file destined for the printer is stored in a print queue, which creates two files per print job in the /var/spool/cups/ directory One of the file contains the actual data to print. The other one contains information about the print job; for example, it might contain the identity of the user who created the print job and the printer to use.

3.

The cupsd printer daemon acts as the print spooler. It is responsible for watching all print queues and for starting the filters required to convert data into the printer-specific format.

4.

The conversion of print data is done in the following way: a.

The data type is determined using the entries in /etc/cups/ mime.types

b.

Subsequently, data is converted into PostScript using the program specified in /etc/cups/mime.convs

c.

After that, the pstops program (/usr/lib/cups/filter/pstops) is used to determine the number of pages, which is written to /var/log/ cups/page_log

d.

CUPS uses other filtering capabilities of pstops as needed, depending on the options set for the print job. For instance, the psselect option of pstops makes it possible to limit the printout to a certain selection of pages, while the ps-n-up option of pstops allows several pages to be printed on one sheet.

e.

If the selected printer is not a PostScript printer, cupsd will start the appropriate filter to convert data into the printer-specific format. One of these filter programs is /usr/lib/cups/filter/ cupsomatic which, in turn, relies on ghostscript for conversion. Filters are responsible for processing all printer-specific options, including resolution, paper size, and others.

f.

Version 1

For the actual transfer of the data stream to the printer device, CUPS uses another type of filter, or back end, depending on how the printer is connected to the host.


99



Manage Printing



These back ends are found in the /usr/lib/cups/backend/ directory: da10:~ canon epson hp 5.

# ls /usr/lib/cups/backend/ hpfax lpd serial socket http parallel smb usb ipp scsi snmp

Once the print job has been transferred to the printer, the print spooler deletes the job from the queue and starts processing the next job. When the job is deleted, the print data file in /var/spool/cups/ is removed.

The file that has information about the print job is not deleted. The filename for the first print job is labeled c00001. The number in each of the following print jobs is increased by one. The following is a schematic representation of the filtering process: Figure 2-16

CUPS Filtering Process

Print Queues With CUPS, printer devices are addressed using print queues. Rather than being sent directly to the printer, print jobs are sent to a print queue associated with the device. On a print server, each print queue is registered with its name in the /etc/cups/ printers.conf file. Among other things, this file defines which queues the printer is addressed through, how it is connected, and which interface it is connected to.

100


Version 1


Several print queues can be defined for one printer, as in the following example: # Printer configuration file for CUPS v1.3.9 # Written by cupsd on 2009-02-05 14:06 Info HP LaserJet 6mp Foomatic/hpijs, hpijs 2.8.7.3 DeviceURI parallel:/dev/lp0 State Idle StateTime 1233839191 Accepting Yes Shared Yes JobSheets none none QuotaPeriod 0 PageLimit 0 KLimit 0 OpPolicy default ErrorPolicy stop-printer Info HP LaserJet 6mp Foomatic/hpijs, hpijs 2.8.7.3 DeviceURI parallel:/dev/lp0 State Idle StateTime 1233839040 Accepting Yes Shared Yes JobSheets none none QuotaPeriod 0 PageLimit 0 KLimit 0 OpPolicy default ErrorPolicy stop-printer ...

For instance, in the case of color printers, it can be useful to have two queues, one for black-and-white printing of text documents and one for color printing. The following explains some entries in /etc/cups/printers.conf: 

: The entry for the default printer.



and : The queues as defined for the “HP LaserJet 6mp” printer.



State Idle: Currently, this print queue does not have any print jobs.



Accepting Yes: The queue is accepting print jobs.



JobSheets none none: Starting and ending banner will not be printed.

Each existing queue has its own configuration file, which is stored on the print server in the /etc/cups/ppd/ directory. These files contain settings to configure the paper size, the resolution, and other settings.

Version 1


101



Manage Printing



By contrast, on the client side the names of queues are registered in the /etc/ printcap file: da10:~ # cat /etc/printcap # This file was automatically generated by cupsd(8) from # the /etc/cups/printers.conf file. All changes to this # file will be lost. hp_normal|HP LaserJet 6mp Foomatic/hpijs, hpijs 2.8.7.3:rm=da10.digitalairlines.com:rp=hp_normal: hp_draft|HP LaserJet 6mp Foomatic/hpijs, hpijs 2.8.7.3:rm=da10.digitalairlines.com:rp=hp_draft:

This file is generated and updated automatically by cupsd and is relevant for a number of applications (such as OpenOffice.org) that use the entries in it to list the available printers in their printer selection dialogs. NOTE: You should not change the /etc/printcap file manually.

Log Files The log files of CUPS are stored in the /var/log/cups/ directory. CUPS has three log files: 

“The access_log File” on page 102



“The error_log File” on page 104



“The page_log File” on page 104



“Set the Log Level to Record Errors” on page 105

For troubleshooting CUPS issues, you need to know how to 

“The access_log File” on page 102



“The error_log File” on page 104



“The page_log File” on page 104



“Set the Log Level to Record Errors” on page 105

The access_log File

The access_log file lists each HTTP resource that is accessed by a Web browser or CUPS/IPP client.

102


Version 1


Lines in the log file look like the following: localhost - - [05/Feb/2009:14:18:22 +0100] CUPS-Get-Printers successful-ok localhost - - [05/Feb/2009:14:18:22 +0100] CUPS-Get-Classes successful-ok localhost - - [05/Feb/2009:14:18:22 +0100] CUPS-Get-Default successful-ok localhost - - [05/Feb/2009:14:18:22 +0100] HTTP/1.1" 200 982 Print-Job successful-ok

"POST / HTTP/1.1" 200 416 "POST / HTTP/1.1" 200 416 "POST / HTTP/1.1" 200 75 "POST /printers/hp_normal

The entries in the lines (from left to right) are explained below: 

The host field contains the name of the host (in the example: localhost).



The group field always contains "-" in CUPS.



The user field contains the authenticated username of the requesting user. If a username and password are not supplied for the request, this field contains – (as in the example).



The date-time field shows the date and time of the request in local time (in this example: [05/Feb/2009:14:18:22 +0100]). The format is [DD/MON/YYYY:HH:MM:SS +ZZZZ], where ZZZZ is the time zone offset in hours and minutes from coordinated universal time (UTC).



The method field is the HTTP method used (such as GET, PUT, and POST).



The resource field is the filename of the requested resource. Possible resources are





/



/admin/



/printers/



/jobs/

The version field is the HTTP version used by the client. For CUPS clients, this is always HTTP/1.1.



The status field contains the HTTP result status of the request. Usually it is 200, but other HTTP status codes are possible. For example, 401 indicates unauthorized access.



The bytes field contains the number of bytes in the request. For POST requests, the bytes field contains the number of bytes that were received from the client.

Version 1


103



Manage Printing



The error_log File

The error_log file lists messages (such as errors and warnings) from the scheduler: I [05/Feb/2009:14:18:22 +0100] [Job 14] "none". I [05/Feb/2009:14:18:22 +0100] [Job 14] "none". I [05/Feb/2009:14:18:22 +0100] [Job 14] queued by "root". I [05/Feb/2009:14:18:22 +0100] [Job 14] "root". I [05/Feb/2009:14:18:22 +0100] [Job 14] filter/texttops (PID 28773) I [05/Feb/2009:14:18:22 +0100] [Job 14] filter/pstops (PID 28774) I [05/Feb/2009:14:18:22 +0100] [Job 14] filter/foomatic-rip-hplip (PID 28775) I [05/Feb/2009:14:18:22 +0100] [Job 14] cups/backend/parallel (PID 28776) I [05/Feb/2009:14:18:24 +0100] [Job 14]

Adding start banner page Adding end banner page File of type text/plain Queued on "hp_normal" by Started filter /usr/lib/cups/ Started filter /usr/lib/cups/ Started filter /usr/lib/cups/ Started backend /usr/lib/ Completed successfully.




The level field contains the type of message: 

E: An error occurred.



W: The server was unable to perform an action.



I: Informational message.



D: Debugging message.

The date-time field contains the date and time of the entry (for example, when a page started printing). The format of this field is identical to the date-time field in the access_log file.



The message field contains a free-form text message.

The page_log File

The page_log file lists each page that is sent to a printer. hp_normal root 14 [05/Feb/2009:14:18:23 +0100] 1 1 - localhost


The printer field contains the name of the printer that printed the page (in this example: hp_normal). If you send a job to a printer class, this field contains the name of the printer that was assigned the job.



104

The user field contains the name of the user that submitted this file for printing.


Version 1




The job-id field contains the job number of the page being printed (in this example: 14).



The date-time field contains the date and time the page started printing. The format of this field is identical to the date-time field in the access_log file.



The page-number field contain the number of pages (in this example: 1).



The num-pages field contains the number of copies (in this example: 1). For printers that cannot produce copies on their own, the num-pages field will always be 1.



The job-billing field contains a copy of the job-billing attribute provided with the IPP create-job or print-job requests or – (if none was provided).



The hostname field contains the name of the host that originated the print job (in this example: localhost).

Set the Log Level to Record Errors

Messages from cupsd are written to the /var/log/cups/error_log file. With the default log level info, only requests and status changes are logged to the file. If you want errors recorded, you need to change the LogLevel option in the cupsd / etc/cups/cupsd.conf configuration file: # Log general information in error_log - change "info" to "debug" for # troubleshooting... LogLevel info

For debugging and troubleshooting, set the log level to debug or debug2. After changing the configuration, restart CUPS by entering rccups restart.

Configuration File The CUPS configuration file is /etc/cups/cupsd.conf. It has a format similar to that of the Apache web server configuration file. Various options are used to configure the server itself, as well as to configure filtering, networking, browsing, and access. Networking, browsing, and access are covered in the next objective.

Version 1


105



Manage Printing



Objective 4

Configure and Manage Print Server Access In Objective 1, “Configure CUPS” on page 74, you learned how to configure CUPS to be able to print from a local machine and how to control access to the print server using the options provided in YaST. YaST or command line tools took care of the underlying configuration. In this objective, you will gain an understanding of the /etc/cups/cupsd.conf configuration file. You will learn how to control in more detail who may use your printer via the network. To be able to do this, you need to understand the following: 

“Syntax of /etc/cups/cupsd.conf” on page 106



“Access Restrictions” on page 107

Syntax of /etc/cups/cupsd.conf The syntax of the /etc/cups/cupsd.conf file used to configure CUPS is similar to the Apache configuration file syntax. The general syntax is a directive followed by a value, such as Listen *:631

The above makes CUPS listen on all interfaces on port 631. The following directives control the way browse packets are sent by the server: # Show shared printers on the local network. Browsing On BrowseAddress @LOCAL

Browsing On turns on browsing. It needs to be accompanied by a BrowseAddress directive specifying where browse packets should be sent. With the value @LOCAL, browse information is sent to all local (non-point-to-point) interfaces. Other possible values are broadcast addresses (10.0.0.255:631), IP addresses (host.example.com), or single interfaced (@IF(name)). The directives BrowseAllow, BrowseDeny, and BrowseOrder control how CUPS deals with incoming browse packets. With the following configuration, browse packets are ignored: BrowseOrder allow,deny BrowseAllow none BrowseDeny all

With the following configuration, CUPS processes browse packets that arrive on the local interfaces: BrowseAllow @LOCAL BrowseOrder allow,deny

106


Version 1


NOTE: All directives that can be used within the /etc/cups/cupsd.conf file are described in the following configuration files found using a browser pointed at the following: http://localhost:631/ help/ref-cupsd-conf.html (found locally on your SLES 11 machine).

The effect of some directives can be limited by putting them within sections, such as # Restrict access to the server... Order allow,deny Allow @LOCAL Allow 127.0.0.2

This is mainly used to limit access to certain resources, as explained in “Access Restrictions” on page 107.

Access Restrictions You can restrict the access to various CUPS resources, based on criteria such as IP address, user name, or group membership. You can also restrict what activities can or cannot be performed based by different users. You can do the following: 

“Restrict Access Using the Location Directive” on page 107



“Restrict Access Using the Policy Directive” on page 109



“Restrict Access Using the lpadmin Command” on page 111

Restrict Access Using the Location Directive

The location directive within the /etc/cups/cupsd.conf file can be used to specify access control and authentication options for the specified HTTP resource or path. The settings are relevant for the access to the Web interface using a Web browser (such as http://localhost:631/printers) as well as IPP access by users printing documents. Common locations on the server include the following: 

/ (root): The access restrictions for this resource apply for all subsequent resources if no other restrictions are specified there.



/printers: All printers or queues.



/classes: Available printer classes (for example, all color printers).



/jobs: Print jobs on the CUPS server.



/admin: Access to the server configuration.

Here is an example: Order allow,deny Allow 127.0.0.2 Allow @LOCAL

Version 1


107



Manage Printing



Order Allow,Deny Allow 127.0.0.1 Allow 127.0.0.2 AuthType Basic Require user @SYSTEM # Allow remote access to the configuration files... Order allow,deny Allow @LOCAL

The following explains the configuration directives: 

Order: Defines the order of the rules and the default directive. Allow,Deny: Default is to deny access. Allow requests from systems in an Allow directive, unless they are also listed in a Deny directive. Deny,Allow: Default is to allow access. Deny requests from systems in a Deny directive, unless they are also listed in an Allow directive.



Deny From ...: Access to the resource is prohibited for the item named. You can specify a host or domain name (host.example.com, *.example.com), an IP address (1.2.3.4 or a:b:c:d::e), a network (10.*, 10.0.0.0/24, or IPv6 network), an interface name (@IF(name)), or local interfaces (@LOCAL). (The word “from” can also be omitted.)



Allow From ...: Access is permitted for the item named, specified as above.



AuthType. Basic uses the Linux password and group files. BasicDigest uses the /etc/cups/passwd.md5 file for authentication; lppasswd is the utility to add, change, and delete users and passwords in this file.

da10:~ # lppasswd -a root -g sys Enter password: Enter password again:

This command creates the user root in the group sys. Any user name will do, as long it is member of the group sys. The user name does not have to exist as a Linux user name. NOTE: The password has to be at least six characters long and must contain at least one letter and one number. 

Require: user specifies that the authenticated user must be one of the listed users, or a member of the listed groups. @SYSTEM refers to the groups specified with the SystemGroup directive, usually the groups sys and root.

The resource /printers concerns all queues. You can specify access restrictions on a per-queue basis in additional entries that might look like this one:

108


Version 1


Order Allow,Deny Allow From 10.0.0.0/24 Allow From 10.0.1.2 Order Allow,Deny Allow From 10.0.0.10

In the above example, all clients belonging to network 10.0.0.0/24 and host 10.0.1.2 can print on all queues in the network, with the exception of the color queue, which can be accessed only by the client 10.0.0.10. Restrict Access Using the Policy Directive

While the location directive can be used to restrict or allow access to resources based on the directory structure on the CUPS server, the policy directive within the /etc/ cups/cupsd.conf file specifies IPP operation access control limits. Policy directives are evaluated after the location-based access control rules and, therefore, cannot be used to allow access that is limited by a location directive. In other words, if a location directive forbids access to a printer, it cannot be granted by a policy directive. Each policy contains one or more limit sections. The basic syntax looks like the following: ... ... ...

Within the /etc/cups/cupsd.conf file, a default policy is defined. It consists of several Limit sections: DefaultPolicy default Require user @OWNER @SYSTEM Order deny,allow

Version 1


109



Manage Printing



The first Limit section lists job-related operations that require either the owner of a job or a member of the system group to execute, but no authentication. Operations are listed one after the other separated by spaces. The Require directive specifies the user requirements, and the Order deny,allow line at the end allows request to come from any system allowed by the Location sections. A list of Operations can be found by pointing your browser at the following location (found locally on your SLES 11 machine): http://localhost:631/help/ref-cupsdconf.html?TOPIC=References&QUERY=#LimitIPP. The following Limit section lists printer-related operations that require authentication: AuthType Default Require user @SYSTEM Order deny,allow

The line AuthType Default turns on authentication. Only members of the SYSTEM group can perform these operations. Within the default policy there is another Limit section that concerns queue-related operations: AuthType Default Require user @SYSTEM Order deny,allow

Its access restrictions are the same as those for the printer-related options. They could have been listed within one Limit section as well, but grouping them makes the configuration easier to understand. The last section allows all operations that have not been covered so far: Order deny,allow

You can create your own policy by creating Policy sections as above, using a name of your choice. You can set your own policy as default using the line DefaultPolicy MyPolicy

110


Version 1


Using the lpadmin command, you can also use your policy for specific queues, such as the following: lpadmin -p color -o printer-op-policy=MyPolicy Restrict Access Using the lpadmin Command

On the command line, you can use the lpadmin command to restrict access to queues to specific users: 

To permit printing for individual users, enter lpadmin -p queue -u allow:user1, user2 or for a group, enter lpadmin -p queue -u allow:@group



To prohibit printing for users or groups, enter lpadmin -p queue -u deny:user,@group NOTE: The commands above do not add to the existing user entries, but replace them.



To permit printing for all, enter lpadmin -p queue -u allow:all or lpadmin -p queue -u deny:none

These access restrictions are written to the /etc/cups/printers.conf file, as in the following: ... AllowUser user1 AllowUser user2 AllowUser @users

Version 1


111



Manage Printing



Exercise 2-3

Manage Access In this exercise, you learn how to administer access to your CUPS server. You will find this exercise in the workbook. (End of Exercise)

112


Version 1


Objective 5

Use the Web Interface to Manage a CUPS Server You can access the Web interface of the CUPS server by using the Local URL http:// IP_Address:631 The main menu is shown in the following figure:

Figure 2-17

CUPS Webinterface: Welcome

The top navigation bar is available on all pages. To manage printers and jobs or to modify the current settings, you have to authenticate. Depending on what you want to do, you have to authenticate as the owner of the job you want to modify or as administrator of the CUPS server (by default, this is the root user). NOTE: Enabling administrative access via the Web interface is described in “Restrict Access Using the Location Directive” on page 107.

The navigation bar at the top includes the following tabs:

Version 1



“Administration” on page 114



“Classes” on page 115



“Documentation/Help” on page 115


113



Manage Printing





“Jobs” on page 116



“Printers” on page 117



“Use the Web Interface to Manage a CUPS Server” on page 119

Administration In the Administration module (http://localhost:631/admin) you can perform all administration tasks: Figure 2-18

CUPS Webinterface: Administration



Printers: Here you can add and find new printers. The Manage Printers button opens the same page as the Printers tab at the top of the page.



Classes: Here you can add a printer class. The Manage Classes button opens the same page as the Classes tab at the top of the page.



Jobs: The Manage Jobs button opens the same page as the Jobs tab at the top of the page.



Server: The Basic Server Settings section allows you to make specific changes by selecting or unselecting the respective configuration options. The Edit Configuration File button opens a dialog that allows you to edit the / etc/cups/cupsd.conf file directly.

114


Version 1


The buttons referring to different logs open the respective logs in a browser window.

Classes In the Classes module (http://localhost:631/classes) you can manage existing printer classes. Figure 2-19

CUPS Webinterface: Classes

To add a class, select the Administration tab and click the Add Class button.

Documentation/Help The Web interface allows you to quickly access documentation and help for different aspects of CUPS, as shown in the following:

Version 1


115



Manage Printing



Figure 2-20

CUPS Webinterface: Help

Jobs In the Jobs module (http://localhost:631/jobs) you can switch between the view of the completed jobs or the view of the active jobs.

116


Version 1


Figure 2-21

CUPS Webinterface: Jobs

To switch between the two views, select Show Completed Jobs or Show Active Jobs. Click All Jobs to view active and complete jobs. If any jobs are in the queue, you can also 

Hold the job.



Cancel the job.

The management dialog is the same as the dialog you get when you select Manage Jobs in the Administration interface.

Printers In the Printers module (http://localhost:631/printers), you can do the following: 

Print a test page



Stop/start the printer



Reject/accept print jobs



Modify the printer configuration



Set printer options (paper size, resolution, and banner)



Delete the printer configuration



Set a printer as default printer



Set users that are allowed to print

The dialog is shown in the following:

Version 1


117



Manage Printing



Figure 2-22

CUPS Webinterface: Printers

Clicking a printer entry shows information on the print jobs for that printer. The configuration dialog is the same as the dialog you get when you select Manage Printers in the Administration module.

118


Version 1


Exercise 2-4

Use the Web Interface to Manage a CUPS Server In this exercise, you add a second printer via the Web front end of CUPS. You will find this exercise in the workbook. (End of Exercise)

Version 1


119



Manage Printing



Summary Objective

Summary

Configure CUPS

CUPS, the Common UNIX Printing System, is the default printing system used in SUSE Linux Enterprise Server 11. CUPS can be used to print on local or remote printers. The protocol used is IPP, but other protocols are also supported. Printers are addressed by using print queues. The YaST module to configure CUPS can be found at YaST Control Center > Hardware > Printer

Manage Print Jobs and Queues

CUPS tools allow you to use commands according to 

Berkeley (LPRng) style, such as lpr, lpq, and lprm.



System V style, such as lp, lpstat, and cancel.

To list the current settings of a local queue, enter lpoptions -p queue -l Understand how CUPS Works

The main configuration file for CUPS is /etc/cups/ cupsd.conf. Information on the print queues is kept in /etc/cups/ printers.conf A configuration file for each queue is located in the / etc/cups/ppd/ directory. These files store settings affecting the printout through the given queue. The /etc/printcap file, which is created and updated automatically, contains an entry for each of the defined queues. CUPS can distribute information about the available printers to all network clients.

Configure and Manage Print Server Access

A CUPS server can distribute information about the available queues within the network (browsing). Access to resources and IPP options on the CUPS server can be restricted based on IP addresses, users, groups, or passwords.

Use the Web Interface to Manage a CUPS Server

You can enter the CUPS Web front end at http:// localhost:631/ or http://IP_Address:631 The Web interface allows the administration of all aspects of CUPS, including printer management, viewing of log files, or editing of the /etc/cups/ cupsd.conf file.

120


Version 1


SECTION 3


In this section, you learn how to configure the OpenLDAP service on a SLES 11 server and configure it to store user accounts. Objectives

Version 1

1.

“Describe How LDAP Works” on page 122

2.

“Install and Configure OpenLDAP on SLES 11” on page 136

3.

“Add, Modify, and Delete Entries to the LDAP Directory Tree” on page 155


121






Objective 1

Describe How LDAP Works Before learning how to set up OpenLDAP on your server, you first need to understand what LDAP is and how it works. In this objective, the following topics are addressed: 

“How Directory Services Work” on page 122



“What is LDAP?” on page 127



“How the LDAP Directory Tree Is Structured” on page 127

How Directory Services Work Most people are familiar with directory services, such as a telephone directory. Telephone companies provide a directory of their subscribers’ names, addresses, and phone numbers that allows telephone service users to easily contact each other. All the contact information is in one place—the phone book, which organizes the information in alphabetical order. Similarly, a network Directory service provides the location of network resources. This allows network service users and administrators to easily connect to and use or manage these network resources. To understand the need for LDAP (Lightweight Directory Access Protocol), you first need to understand that by default your Linux system stores its user and group information locally in the file system. For example, your user accounts are stored as plain text in the /etc/passwd file. A section of it is shown below: wwwrun:x:30:8:WWW daemon apache:/var/lib/wwwrun:/bin/false geeko:x:1000:100:Geeko Novell:/home/geeko:/bin/bash tux:x:1001:100:Tux Novell:/home/tux:/bin/bash

Each line represents one user record. Each record is composed of several fields separated by colons (:). Your users’ passwords are not stored in the passwd file. Instead, they are stored in encrypted format in the /etc/shadow file. The corresponding section of the shadow file for the passwd file from the example above is shown below (password hashes are shortened): wwwrun:*:14306:::::: geeko:$2a$05$Eso3tbJJXTVAjUdRk0L9DODn/pgleI...xyz:14309:0:99999:7::: tux:$2a$05$mNcSSMBMxF3eZayvZxtyH.RZZjC1WkO/...def:14309:0:99999:7:::

Likewise, your groups are saved in the /etc/group file, as shown below: trusted:x:42: tty:x:5: utmp:x:22: uucp:x:14: uuidd:!:104:

122


Version 1


video:x:33:geeko,tux wheel:x:10: www:x:8: xok:x:41: users:x:100:

As with the passwd file, each line in the group file represents one group record. The record is composed of several fields separated by colons (:). Storing your user and group information in the local file system has many advantages. It’s easy to manage and can be secured using file system access controls. However, storing your user and group information locally also has several drawbacks. Consider the following: 

The passwd, shadow, and group files store information in a flat format. User and group accounts can’t be organized into a hierarchy that reflects your organization’s geographic locations or functional arrangement.



The files are stored in the local file system. If you have multiple servers and workstations in your network and want to use the same users, groups, and passwords, then you must synchronize these files to all of the other systems. For years, this has been done by configuring the Network Information Service (NIS) on your systems. You set up a NIS server that serves as a central repository for all configuration information. Other systems are set up as NIS clients that receive user, group, and configuration information from the NIS server. This solution functions well. However, it works only with Linux/UNIX systems. If you have a heterogeneous network with multiple operating systems and a variety of network services, you can’t use NIS to distribute configuration information.

A better solution would be to configure a centralized repository of user, group, and configuration information on your network that allows the following: 

A single-point of administration: You need to be able to configure your user and group information in one location and have it automatically applied to all systems in your network



A hierarchical structure: Instead of storing users and groups in an unordered flat file, you need to be able to organize your information into a hierarchy— grouped and nested according to geographic location, organization, department, team, and/or function.



Support for multiple operating systems: The central repository of user and group information should be compatible with multiple operating systems.



Support for many types of information: The central repository should be extensible such that it can store information other than just users and groups. For example, network services running on servers in your network, such as DNS and DHCP, should be able to store their configuration information in the central repository instead of in a file in the local file system.

Version 1


123






This allows you to quickly replace a service if its host server goes down. All you have to do is reinstall the service on a different server and point it to the existing configuration information in the central repository. 

Support for replication: To prevent the creation of a single point of failure, the central repository should be able to replicate its information to other servers in the network. That way, if the server goes down, other servers can handle information requests.

This is shown in the figure below: Figure 3-1

Using a Central Repository of User and Group Information

In short, you need to ensure your crucial network information is organized and easily accessible. This can be done using a Directory service that stores information in a well structured, quickly searchable form. All the network resource information is in one place—the Directory tree, which organizes the physical network into a logical network representation. A Directory is a compilation of services that provide discovery, security, storage, and relationship management. A Directory does the following:

124



Enables access to resources on the entire network and not just specific servers



Provides secure access to network resources



Provides a scalable, indexed, and cacheable database (for performance)



Manages relationships between Directory entities, such as users and the resources they access


Version 1


With the global direction of the modern economy and current business practices, it is logical and necessary that Directories, at least in their basic structural form, adhere to certain standards. X.500 is an International Organization for Standardization (ISO) and International Telecommunication Union (ITU) standard that globally defines how Directory services ought to be structured at the basic level. To effectively understand and manage a Directory in your network, you need to understand the components of the X.500 Directory. The following figure illustrates the components of the X.500 Directory: Figure 3-2

The X.500 Directory Model Directory User Agent (DUA)

ss ce ) Ac AP ry (D cto ol re o c Di rot P

Directory System Agent (DSA)

em st P) Sy DS ry l ( to co c o ire t D Pro

DSA DSA DSA

DSA DSA DSA

DIB DIB

Directory Information Shadowing Protocol (DISP)

DIB DIB

DSA DSA DSA

DIB DIB

Directory Information Base (DIB)

Directory Information Tree (DIT)

The X.500 Directory standard includes seven essential components: 

“Directory Information Database (DIB)” on page 125



“Directory Information Tree (DIT)” on page 126



“Directory User Agent (DUA)” on page 126



“Directory System Agent (DSA)” on page 126



“Directory Access Protocol (DAP)” on page 126



“Directory System Protocol (DSP)” on page 127



“Directory Information Shadowing Protocol (DISP)” on page 127

Directory Information Database (DIB)

A Directory is made up of objects that represent physical resources in the real world, such as users. Collectively, these objects are known as the Directory Information Database (DIB). Each object, or entry, in the DIB has a distinguished name that uniquely identifies it. Each entry consists of one or more attributes and each attribute has a value.

Version 1


125






Directory Information Tree (DIT)

The Directory Information Tree (DIT) is a tree structure that logically represents and describes the collection of objects and the relationship of information in the DIB. The objects are contained in a hierarchical arrangement in this tree structure. For example, a person (object/entry) works for a company (object/entry) that is located within a country (object/entry). To keep the Directory organized, a set of rules is enforced to ensure that the DIB remains stable and intact as modifications are made to it over time. These rules are known as the Directory schema. They prevent entries from having wrong attribute types and prevent objects from being a member of the wrong object class. Directory User Agent (DUA)

The X.500 specification uses a client/server approach in communicating information. The client interacts with a server to perform specific Directory operations. The Directory User Agent (DUA), acting as the client, is an application process that represents each user accessing the Directory. Users are people or programs that can read, modify, or search the Directory. The DUA requests information from the Directory and then relays that information to the user or program. Directory System Agent (DSA)

The Directory System Agent (DSA) is the server side of the client/server relationship. The DSA takes a request from a DUA, services the request, and sends replies to the DUA. If it doesn’t have the requested information, it will pass the request on to another DSA. The DSA consists of many different pieces, including components that communicate with other DSAs on behalf of a DUA and components that are responsible for replication of data between DSAs. Directory Access Protocol (DAP)

The Directory Access Protocol (DAP) is the protocol that a DUA uses when it communicates with a DSA to make a request of the DSA. The APIs used to access eDirectory as well as the Lightweight Directory Access Protocol (LDAP) are examples of a DAP.

126


Version 1


Directory System Protocol (DSP)

If a DSA cannot fulfill the request of a DUA, the DSA passes the request to another DSA. The Directory System Protocol (DSP) provides the communication between the two DSAs. Directory Information Shadowing Protocol (DISP)

The DIB should be replicated to other DSAs. This improves the performance of requests made to the Directory and provides fault tolerance with a secondary (or backup) copy of the DIB. In eDirectory, the process of distributing the DIB is called replication; in the X.500 specification, it is called shadowing. The Directory Information Shadowing Protocol (DISP) performs the actual exchange of replicated information between DSAs. In summary, directories are designed to 

Store small amounts of data that doesn’t change frequently.



Provide fast searching capabilities.



Provide fast read operations.



Provide cross-platform application support.



Replicate information between Directory servers.



Control access to Directory information.

What is LDAP? Lightweight Directory Access Protocol (LDAP) is a set of protocols designed to access and maintain information in a Directory. An LDAP Directory can be used to store many types of information including user, group, and service configuration settings. LDAP is a standardized open protocol, which ensures that many different client applications can access the information stored in the Directory. While there are a variety of LDAP-compliant directories that you could implement on a Linux server (including Novell eDirectory), we’re going to focus on OpenLDAP in this section.

How the LDAP Directory Tree Is Structured An LDAP Directory uses a hierarchical tree structure. All entries (called objects) in the Directory have a defined position within its hierarchy. The complete path from the root of the tree to a particular entry, including the entry’s name, is called its distinguished name or DN. The DN uniquely identifies an object in the Directory tree.

Version 1


127






To designate an entry relative to some point in the tree (not from the root of the tree), the object’s relative distinguished name or RDN is used. Objects can be categorized into one of two possible types: 

Container objects: Container objects can contain other objects. They are like branches within the Directory tree. Container object classes include the following: 

root: The root element of the Directory tree. In LDAP, there is no actual object that represents the tree root. NOTE: The tree root is also called the root entry.





c (country): Represents a country. For example, c=US.



o (organization): Represents an organization. For example, o=DA.





dc (dcObject): Represents an element of your domain. It can represent any part of a domain name. For example, dc=digitalairlines,dc=com.

ou (organizationalUnit): Represents a division, department, team, or other functional group within an organization.

Leaf objects: Leaf objects are like leaves at the end of tree branches. They have no subordinate objects. Leaf objects usually represent a physical network resource. Examples include the following: 

InetOrgPerson: Represents a single user.



groupofNames: Represents a group.

Unlike a real tree, a Directory tree is inverted. The top of the Directory tree is the tree root. The bottom of the tree are the leaf objects. The tree root can contain one of the following objects: 

c (country)



dc (domain component)



o (organization)

There are two commonly used tree strategies for defining the top of the Directory tree. The first uses domain component objects to define the top of the tree hierarchy. Beneath the domain components are organizational units that define logical groupings of Directory objects. Consider the following example:

128


Version 1


Figure 3-3

Using Domain Components to Define the Top of the Tree

Notice in the figure above that dc=digitalairlines,dc=com together defines the top layer of the tree hierarchy, not dc=com by itself. Alternatively, you could also define the top of the tree hierarchy using country (optional), organization, and organizational unit objects. If desired, you can create a country object at the top of the tree and then create one or more organization objects within the country object. You can also omit the country object and simply create an organization object at the top of the tree. An example of this tree design is shown in the figure below: Figure 3-4

Using an Organization Object to Define the Top Layer of the Tree

Either strategy is acceptable. Generally speaking, administrators who have prior experience with Microsoft Active Directory tend to favor using domain components at the top of an OpenLDAP Directory tree. NOTE: The use of domain components is the default structure used by OpenLDAP.

Those coming from a Novell eDirectory background tend to favor using organization objects at the top of the tree.

Version 1


129






When working with an LDAP Directory, you need to be familiar with the following concepts: 

“Objects” on page 130



“Context” on page 134



“Naming” on page 134

Objects

First, you need to be familiar with the schema. The schema defines the types of objects that can be created in your tree (such as organizationalUnit, inetOrgPerson, and groupOfNames) and what information is required or optional at the time the object is created. An object (also referred to as an entry) is a unit of information about a resource, comparable to a record in a conventional database. Different types or categories of objects exist. An object can represent a resource (such as a user or group), service configuration information (such as DNS records), or an organizational element (such as a team or department). Several sample objects are shown in the figure below: Figure 3-5

Sample LDAP Objects

Directory objects are defined by properties and values. A property (also referred to as an attribute) is a category of information associated with an object. Each Directory object consists of properties that can be used to store information about the resource. A collection of properties defines or makes up the class of an object. For example, a groupOfNames object differs from an inetOrgPerson object in the properties it contains and, therefore, in how the object can be used. Object classes and properties are defined and controlled by the schema. A value, on the other hand, is the data contained by a specific property. For example, an inetOrgPerson object has a property called givenName, which in turn has a value, such as Geeko.

130


Version 1


The properties and values of the Geeko inetOrgPerson object is shown in the following figure: Figure 3-6

Version 1

inetOrgPerson Properties and Values


131






The attributes and values of a groupOfNames object named Research are shown in the following figure: Figure 3-7

groupOfNames Object Properties and Values

Finally, the properties and values that comprise the people organizationalUnit object are shown in the following figure:

132


Version 1


Figure 3-8

organizationalUnit Object Properties and Values

Notice in the above figures that not all of the object properties are populated with values. Some properties are mandatory, such as objectClass or uid, but others are optional. The schema defines which properties are required and which are optional. When creating an object, you must supply values for all mandatory properties; otherwise, you won’t be allowed to create the object. The schema also defines the rules of containment, which specify which containers can contain which object types. A schema, therefore, must contain definitions of all object classes and attributes used in the desired application scenario. There are several common schemas (described in RFC 2252 and 2256). The LDAP RFC also defines a few commonly used Schemas (RFC 4519). Additionally there are Schemas available for many other applications (such as Samba, NIS, DNS, and DHCP). It is, however, possible to create a custom schema or to use multiple schemas complementing each other if this is required by the environment the LDAP server operates in.

Version 1


133






Context

Context can be defined as an object’s position in the LDAP Directory tree. It is a list of container objects leading from the object to the root of the tree. Locating an object through the context is similar to locating a file using the directory path. An LDAP tree cannot have multiple leaf objects with the same name in the same container. However, a tree can have multiple leaf objects with the same name in different containers because their context is different. For example, in the following figure, the difference between the two BJohnson user objects is their context. The user object on the left is in the SLC organizational unit; the user object on the right is in the DA organization. Figure 3-9

Understanding Context

Login BJohnson? DA SLC

BJohnson

BJohnson

The context for the BJohnson object on the left is ou=SLC,o=DA. The context for the BJohnson object on the right is o=DA. Naming

LDAP uses naming conventions to allow you to precisely identify and locate objects in your tree. You must provide enough information to locate the object in the tree, and you specify this information in the object name. For example, in the preceding figure, two user objects named BJohnson exist in separate containers in the tree. If you log in as BJohnson, which user object should be used? An object name identifies an object in the tree. So, in the figure above, the exact names are different because their object names contain information that identifies their location in the tree. The name of each object you create in the tree consists of the following: 

Name attribute type



Name value

The attribute type of the object name determines if the object will be accessed as a container or leaf object in the tree. The value of the object is the name you enter for the object when you create it.

134


Version 1


The following name attribute types are assigned to the most common objects: 

c: Country (for example, c=IR for Ireland)



o: Organization name (for example, o=DA)



ou: Organizational unit name (for example, ou=SLC)



cn: Common name of leaf objects (for example, cn=BJohnson)

An object’s distinguished name (DN) is a combination of its common name and its context. This identifies the object all the way to the top, or root, of the tree. An object is exactly identified with a distinguished name. Two objects in the same tree cannot have the same distinguished name. The objects in the name are separated by commas. The names of all objects, from the tree object to the object being named, are included in the distinguished name. In the figure below, the distinguished name for the user object BJohnson in the organizational unit SLC in the organization DA is cn=BJohnson,ou=SLC,o=DA. The distinguished name for the user object BJohnson in the organization DA is cn=BJohnson,o=DA. Figure 3-10

Distinguished Names

Login BJohnson? DA SLC

BJohnson

BJohnson

A relative distinguished name (RDN), on the other hand, lists the path of objects leading from the object being named to the container representing the current context, or current location, in the tree. For example, if your current context is O=DA, you could refer to each BJohnson user object as listed below: 

cn=BJohnson



cn=BJohnson,ou=SLC

When you use a relative distinguished name, LDAP must build a distinguished name from it. This is accomplished by appending the relative distinguished name to the current context: RDN + Current Context = DN

Version 1


135






Objective 2

Install and Configure OpenLDAP on SLES 11 With this conceptual information about LDAP in mind, you are now ready to install and configure an LDAP server on SLES 11. The following topics are addressed in this objective: 

“Install and Configure the LDAP Server” on page 136



“Install and Configure the LDAP Client” on page 145

Install and Configure the LDAP Server The first task you need to complete is to install the LDAP service on your SLES 11 server. To do this, complete the following: 1.

In YaST, select Network Services > LDAP Server.

2.

If the openldap package has not been installed on your server, you will be prompted to install it. If you are prompted to install the package, select Install. When complete the following is displayed: Configuring General LDAP Server Settings

Figure 3-11

3.

In the General Settings screen, configure the following: a.

136

Under Start LDAP Server, select Yes to start the service.


Version 1


4.

b.

If you want the LDAP server to register itself with an SLP Service Agent, select Register at an SLP Daemon.

c.

If your server’s host firewall is enabled, select Open Port in Firewall.

Select Next. The following screen is displayed: Configuring LDAP Server TLS Settings

Figure 3-12

You use the TLS Settings screen to enable encryption for your LDAP transmissions. Transport Layer Security (TLS) is a cryptographic protocol derived from Secure Sockets Layer (SSL). It is used to encrypt data transmissions between network hosts at the Transport layer of the OSI model. 5.

Under Basic settings, enable encryption using TLS by configuring the following: a.

Verify that Enable TLS is selected. If this option is selected, you also need to specify the certificate the server should use for encryption.

b.

Verify that Enable LDAP Over SSL (ldaps) Interface is selected. This enables the LDAP server to accept ldaps connections on port 636. NOTE: Clear-text LDAP communications use port 389. Secure LDAP communications occur on port 636.

c.

Version 1

Verify that Use Common Server Certificate is selected.


137






This certificate was created when SLES 11 was initially installed. If you want the LDAP server to use a different certificate, specify the appropriate file names in the CA Certificate File, Certificate File, and Certificate Key File fields. NOTE: If the Use Common Server Certificate option is greyed out, click the Launch CAManagement Module Button and create a CA and a common server certificate. 6.

Select Next. The Basic Database Settings screen is displayed: Configuring LDAP Database Settings

Figure 3-13

7.

Configure your database settings by doing the following: a.

b.

In the Database Type field, select the database you want to use. You can select from the following: 

bdb: Configures the Berkeley Data Base as the LDAP server’s backend.



hdb (default): Configures the Hierarchical Berkeley Data Base as the LDAP server’s backend. The hdb database is a variant of the bdb database that uses a hierarchical database layout.

For the Base DN, use the default root entry or define a new one. By default, the Base DN field is populated with your domain name defined by domain component objects. This will be your root entry of your LDAP Directory tree.

138


Version 1


For example, in the figure above, the root element is dc=digitalairlines,dc=com. c.

In the Administrator DN field, enter the cn of your LDAP super user. By default, cn=Administrator is entered.

d.

Next to the Administrator DN field, verify that Append Base DN is selected. This will place your super user at the root of the tree. In the example above, selecting this box would yield an administrator DN of cn=Administrator,dc=digitalairlines,dc=com.

e.

In the LDAP Administrator Password and Validate Password fields, type a password for your LDAP super user.

f.

(Conditional) If you want to use this database as the default database for OpenLDAP client tools, such as ldapsearch, select Use this Database as the Default for OpenLDAP Clients. Marking this option causes the SLES 11 server’s host name and the base DN entered in this screen to be written to the OpenLDAP client configuration file (/etc/openldap/ldap.conf).

8.

Select Next.

9.

On the Configuration Summary screen, select Finish.

10. In YaST, select LDAP Server again. 11. Expand Global Settings; then select Allow/Disallow Features.

Version 1


139






The following is displayed: Figure 3-14

Configuring Allow/Disallow Features

12. Under Select Allow Flags, configure the features the LDAP server should allow

(as appropriate for your server and network): 

LDAPv2 Bind Requests: Enables connection requests (bind requests) from clients using the previous version of the LDAP protocol (LDAPv2). NOTE: In LDAP, authentication information is supplied in an operation called a bind.



Anonymous Bind When Credentials Not Empty: Normally the LDAP server denies any authentication attempts with empty credentials (DN and/or password). Enabling this option, however, makes it possible to connect with a password and no DN to establish an anonymous connection. NOTE: A client that sends an LDAP request without performing a bind operation is treated as an anonymous client.

140



Unauthenticated Bind When DN Not Empty: Allows connecting without authentication (anonymously) using a DN but no password.



Unauthenticated Update Options to Process: Allows non-authenticated (anonymous) update operations. Access is restricted according to ACLs and other rules


Version 1


13. Under Select Disallow Flags, configure the features the LDAP server should not

allow (as appropriate for your server and network): 

Disable Acceptance of Anonymous Bind Requests: Disables acceptance of anonymous bind requests.



Disable Simple Bind Authentication: Disables simple bind authentication. Simple binds use clear-text passwords.



Disable Forcing Session to Anonymous Status upon StartTLS Operation Receipt: Disables forcing an authenticated connection back to the anonymous state when receiving a StartTLS operation.



Disallow the StartTLS Operation if Authenticated: Disallows the StartTLS operation on connections that have already been authenticated.

14. Expand Databases > your root entry > Password Policy Configuration.


Enabling Password Policies

15. Enable password policy settings for your LDAP server by selecting from the

following settings:

Version 1



Enable Password Policies: Allows you to specify a password policy for the LDAP server.



Hash Clear Text Passwords: Causes clear text passwords to be hashed before they are written to the database whenever they are added or modified.



Disclose "Account Locked" Status: Provides a meaningful error message to bind requests for locked accounts.


141






NOTE: We recommend that you do not enable this option. The Locked Account error message provides sensitive information that could be exploited by a potential attacker. 

Default Policy Object DN: By default, YaST creates an object named Default Policy in your root entry. Change this name as desired.

16. Specify your password policy settings by doing the following: a.

Select Edit Policy.

b.

When prompted, type your LDAP administrator’s password and select OK. The Password Change Policies tab in the Password Policy Configuration screen is displayed: Configuring Password Change Policies

Figure 3-16

c.

142

On the Password Change Policies tab, configure the following: 

Maximum Number of Passwords Stored in History: Determines the maximum number of passwords stored in the password history. Saved passwords may not be reused by the user.



User Must Change Password after Reset: Determines whether users need to change their password after a reset by the administrator.



User Can Change Password: Determines whether users can change their own passwords.



Old Password Required for Password Change: Requires the old password for password changes.



Password Quality Checking: Determines whether, and to what extent, passwords should be subject to quality checking. You can set a minimum


Version 1


password length that must be met before a password is valid in the Minimum Password Length field. If you select Accept Uncheckable Passwords, users are allowed to use encrypted passwords, but quality checks cannot be performed. If you opt for Only Accept Checked Passwords, only those passwords that pass the quality tests are accepted as valid. d.

Select the Password Aging Policies tab. The following is displayed: Configuring Password Aging Policies

Figure 3-17

e.

f.

Version 1

Configure the following password aging policies: 

Minimum Password Age: Determines the minimum password age (the time that needs to pass between two valid password changes).



Maximum Password Age: Determines the maximum password age.



Time before Password Expiration to Issue Warning: Determines the time between a password expiration warning and the actual password expiration.



Allowed Uses of an Expired Password: Sets the number of postponement uses of an expired password before the password expires entirely.

Select the Lockout Policies tab.


143






The following is displayed: Configuring Lockout Policies

Figure 3-18

g.

h.

Configure the following lockout policies on the Lockout Policies tab: 

Enable Password Locking: Enables password locking.



Bind Failures to Lock the Password: Determines the number of bind failures that trigger a password lock.



Password Lock Duration: Determines the duration of the password lock.



Bind Failures Cache Duration: Determines how long password failures are kept in the cache before they are purged.

Select OK.

17. On the Password Policy Setting screen, select OK.

At this point, the LDAP daemon (ldap) is started on your server. The executable file that provides this service is /usr/lib/openldap/sldapd. The daemon is managed using the /etc/init.d/ldap init script (or its corresponding rc link). You can use the following options with this init script: 

/etc/init.d/ldap start: Starts the LDAP daemon.



/etc/init.d/ldap stop: Stops the LDAP daemon.



/etc/init.d/ldap status: Displays the status of the LDAP daemon.

After the installation and configuration is complete, the LDAP daemon is started. It is configured to run automatically at runlevels 3 and 5.

144


Version 1


Install and Configure the LDAP Client At this point, the LDAP Directory service has been installed on the SLES 11 server. However, it contains only a few entries. If you were to use the YaST LDAP Browser module to access your LDAP tree, you would see it contains only the root entry, as shown below: Figure 3-19

Minimal LDAP Directory Tree

In addition, your SLES server system is still configured to use only its default authentication mechanism via PAM, such as the /etc/passwd file. To fix this, you need to configure the LDAP client on the server and on all other systems that will use the LDAP service for authentication. To do this, complete the following: 1.

Version 1

In YaST, select Network Services > LDAP Client.


145






The following is displayed: Configuring the System as an LDAP Client

Figure 3-20

2.

To use the OpenLDAP server for user authentication on the system, select Use LDAP. When you do, your /etc/nsswitch.conf configuration file will be updated accordingly. Prior to enabling the LDAP Client, your server was probably configured to use the /etc/passwd, /etc/shadow, and /etc/group files to store user accounts. In this configuration, you server’s /etc/nsswitch.conf file probably appeared similar to the following: # # For more information, please read the nsswitch.conf.5 # manual page. # # passwd: files nis # shadow: files nis # group: files nis passwd: compat group: compat

146

hosts: networks:

files dns files dns

services:

files


Version 1


protocols: rpc: ethers: netmasks: netgroup: publickey:

files files files files files nis files

bootparams: automount: aliases:

files files nis files

After enabling the LDAP client, your system will be reconfigured to use either local files or the LDAP directory service for user authentication. Your /etc/ nsswitch.conf file will be updated in a manner similar to the following: # # # # # # #

For more information, please read the nsswitch.conf.5 manual page. passwd: shadow: group:

files nis files nis files nis

passwd: group:

compat files ldap

hosts: networks:

files dns files dns

services: protocols: rpc: ethers: netmasks: netgroup: publickey:

files ldap files files files files files ldap files

bootparams: automount: aliases: passwd_compat: 3.

files files nis files ldap ldap

In the Address of LDAP Servers field, type the IP address of your LDAP server. If your LDAP service is configured to advertise itself via SLP, you can select Find to locate it.

4.

In the LDAP Base DN field, type the root entry of your LDAP directory. To retrieve the base DN automatically, you can select Fetch DN. YaST will check for an LDAP database on the server specified above.

Version 1

5.

If TLS or SSL protected communication with the server is required, select LDAP TLS/SSL.

6.

If the LDAP server still uses LDAPv2, explicitly enable the use of this protocol version by selecting LDAP Version 2.


147






7.

Select Start Automounter to mount remote directories on your client, such as a remotely managed /home directory.

8.

Select Create Home Directory on Login to have a user's home automatically created on the first user login.

9.

Select Advanced Configuration. The Client Settings tab is displayed:

Figure 3-21

Configuring Advanced LDAP Client Settings

10. On the Client Settings tab, adjust the following settings according to your needs: a.

If the search base for users, passwords, and groups differs from the global search base specified in the LDAP base DN, type the appropriate name contexts in following fields. 

User Map



Password Map



Group Map

These values are set in the nss_base, nss_base_shadow, and nss_base_group attributes in the /etc/ldap.conf file. b.

From the Password Change Protocol drop-down list, specify the password change protocol. You can select from the following options: 

148

clear: Changes passwords using an LDAPModify request, replacing the userPassword value with the new clear-text password.


Version 1




clear_remove_old: Changes passwords using an LDAPModify request, first removing the userPassword value containing the old clear-text password, and then adding the userPassword value with the new cleartext password. This protocol is necessary for use with Novell NDS and IBM RACF.



crypt: Changes passwords using an LDAPModify request, first generating a one-way hash of the new password using crypt and then replacing userPassword value with the new hashed password.



md5: Changes passwords using an LDAPModify request, first generating a one-way hash of the new password using MD5 and then replacing userPassword value with the new hashed password.



nds: This is an alias for clear_remove_old.



racf: This is an alias for clear_remove_old.



ad: Changes passwords using an LDAPModify request, using the Active Directory Services Interface (ADSI) password change protocol.



exop (default): Changes passwords using the RFC 3062 password modify extended operation (only the new password is sent).



exop_send_old: Changes passwords using the RFC 3062 password modify extended operation (both the old and new passwords are sent).

This setting is configured in the pam_password attribute of the /etc/ldap.conf file. c.

From the Group Member Attribute drop-down list, select the LDAP group to use with Group Member Attribute. The default value is member.

11. Select the Administration Settings tab.

Version 1


149







Configuring Advanced Administration Settings in the LDAP Client

12. Configure the following settings on the Administration Settings tab: a.

In the Configuration Base DN field, type the base context for storing your user management data.

b.

In the Administrator DN field, type your administrator user’s DN. This DN must be identical to the rootdn value specified in /etc/openldap/ slapd.conf to enable this user to manipulate data stored on the LDAP server. You can enter the full DN (such as cn=Administrator,dc=digitalairlines, dc=com) or type cn=Administrator and select Append Base DN to have the base DN added automatically.

c.

Select Create Default Configuration Objects to create the basic configuration objects required to enable user management via LDAP.

d.

If your LDAP server should act as a file server for home directories across your network, select Home Directories on This Machine.

e.

Use the Password Policy section to select, add, delete, or modify the password policies to use.

13. Configure the YaST Group and User Administration modules.

You use the YaST LDAP Client module to adapt the YaST User and Group Administration modules to support LDAP accounts by doing the following: a.

150

Select Configure User Management Settings.


Version 1


b.

When prompted, enter your Administrator user’s password.

c.

When prompted that the ldapconfig organizational unit doesn’t exist, select Yes to created it now.

d.

Select New.

e.

To create a new user configuration module, select suseUserConfiguration.

f.

In the Name of New Module field, type Users; then select OK. A table is displayed listing all attributes allowed in this module with their assigned values: Configuring the Users Module

Figure 3-23

Notice that the template is connected to its module using the susedefaulttemplate attribute value, which is set to the DN of the template.

Version 1

g.

If you want to change an attribute, select the desired attribute; then select Edit.

h.

If you want to configure the user template, select Configure Template.


151






Configuring the Users Template

Figure 3-24

i.

To change a template attribute, select the desired attribute; then select Edit.

j.

To modify the default values for new objects, use the Add, Edit, or Delete buttons.

k.

When done, select OK.

l.

On the Module Configuration screen, select New.

m. To create a new group configuration module, select

suseGroupConfiguration. n.

152

In the Name of New Module field, type Groups; then select OK.


Version 1


The following is displayed: Configuring the Groups Module

Figure 3-25

Notice that the template is connected to its module using the susedefaulttemplate attribute value, which is set to the DN of the template.

Version 1

o.

If you want to change an attribute, select the desired attribute; then select Edit.

p.

If you want to configure the groups template, select Configure Template.


153






The following is displayed: Configuring the Groups Template

Figure 3-26

q.

To change a template attribute, select the desired attribute; then select Edit.

r.

To modify the default values for new objects, use the Add, Edit, or Delete buttons.

s.

When done, select OK.

t.

In the Module Configuration screen, select OK.

14. On the Advanced Configuration screen, select OK. 15. On the LDAP Client Configuration screen, select OK. 16. If prompted, install the pam_ldap and nss_ldap packages by selecting Install.

You can repeat this process to configure the LDAP Client on all SLES or SLED systems that will use the LDAP server for authentication. The configuration of YaST Group and User Administration modules has to be done only once, not on every LDAP client.

154


Version 1


Objective 3

Add, Modify, and Delete Entries to the LDAP Directory Tree In the previous objectives in this section, you learned how to install and configure the OpenLDAP server and client on your SLE systems. However, at this point there are no user accounts in the LDAP directory tree. In this objective, you learn how to manage users and groups in the LDAP directory tree. The following topics are addressed: 

“Managing LDAP Users and Groups from the Shell Prompt” on page 155



“Managing LDAP Users and Groups in YaST” on page 159

Managing LDAP Users and Groups from the Shell Prompt Just as you can add, delete, and modify local user and group accounts using command line tools, you can also manage users and groups in the LDAP directory from the shell prompt. For accounts stored locally, you use the following commands to manage users and groups from the shell prompt: 

useradd: Create new user accounts.



userdel: Delete existing user accounts.



usermod: Modify an existing user account.



passwd: Modify a user’s password.



groupadd: Create new groups.



groupdel: Delete existing groups.



groupmod: Modify an existing group.

If you have installed and configured OpenLDAP on your servers and workstations, you can still use these utilities to manipulate accounts stored in /etc/passwd, / etc/shadow, and /etc/group. To use these commands to manage users in the ldap directory, you have to use the options --service ldap -D binddn (such as “cn=Administrator,dc=digitalairlines,dc=com”. You are prompted for the password of the Administrator. NOTE: Remember that after installing the LDAP Client, your system is configured (by default) to use both the local files and the LDAP directory for authentication.

In addition to the above tools to manage LDAP users and groups from the shell prompt, you can use a special set of utilities. First, you can use the ldapsearch utility to search for entries within the LDAP directory. The syntax for using ldapsearch is as follows: ldapsearch -x -b search_base "(objectClass=*)" The -b option specifies the context in the tree where the search should be performed. The -x option enables simple authentication. The (objectClass=*) option specifies that all objects contained in the directory should be read.

Version 1


155






This command option can be used after the creation of a new directory tree to verify that all entries have been recorded correctly and the server responds as desired. For example: ldapsearch -x -b dc=digitalairlines,dc=com "(objectClass=*)" When you enter this command, the tree is queried at the specified context and the results are displayed, as shown below: Figure 3-27

Viewing the Output of the ldapsearch Command

Notice that the output is formatted using the LDAP Data Interchange Format (LDIF), which is a plain-text way of describing LDAP directory entries. LDIF is a standard that defines an ASCII text file format used to import or export data to and from an LDAP-compliant directory service. LDIF files are commonly used to initially build a directory database or to add large numbers of entries to a directory at the same time. LDIF files can also be used to make changes to existing directory entries. LDIF files consist of one or more entries separated by a blank line. Each LDIF entry consists of an optional entry ID, a required distinguished name, one or more object classes, and multiple attribute definitions. The basic syntax of an LDIF file is as follows: dn: distinguished name changetype: type of change objectClass: object class attribute type: attribute value

156


Version 1


Only the DN and at least one object class definition are required. Attributes required by object classes you define for the entry must also be defined. Other attributes and object classes are optional. You can specify object classes and attributes in any order. The following describes the LDIF fields shown in the previous example: Table 3-1

LDIF Fields Parameter

Value

dn

Distinguished name for the entry.

changetype

Valid changetype values include add, modify, moddn, and delete.

objectClass

Object class to use with this entry. Each object class defines the types of attributes allowed or required for the entry.

attribute type

Attribute to define for the entry.

attribute value

Value to be assigned to the attribute type.

For example, you could use the following LDIF file to define a user named geeko: # geeko LDIF dn: cn=geeko,ou=People,dc=digitalairlines,dc=com changetype: add objectClass: inetOrgPerson cn: geeko givenName: Geeko sn: Chameleon mail: [email protected] uid: geeko telephoneNumber: 801-861-7000

Understanding LDIF files is important because you can use them in conjunction with the ldapadd command to add new users to the LDAP directory from the shell prompt. This command uses the following syntax: ldapadd -x -D administrator_DN -W -f ldif_file The -x option switches off SASL authentication. The -D option specifies the user used to bind to the directory. The -W option prompts you for the administrator user’s password. The -f option specifies the name of the LDIF file to import. For example, to import an LDIF file named geeko.ldif into the LDAP directory, you would use the following command (in one line): ldapadd -x -D cn=Administrator,dc=digitalairlines,dc=com -W -f geeko.ldif

Version 1


157






When done, the entry defined in the geeko.ldif file is imported (as shown on the previous page). The output from the command is shown in the figure below: da1:~ # ldapadd -x -D cn=Administrator,dc=digitalairlines,dc=com \ -W -f geeko.ldif Enter LDAP Password: adding new entry "cn=geeko,ou=People,dc=digitalairlines,dc=com" da1:~ #

The LDIF file used with ldapadd can contain one or many directory entries defined within it. This allows you to, if appropriate, populate your entire LDAP directory with one single ldapadd command. Just as you use usermod to modify an existing local user account, you use the ldapmodify command to modify an existing entry in the LDAP directory. As with the ldapadd command, you run the command from the shell prompt and pass to it the name of an LDIF file to process. With the ldapadd command, you use the changetype: add command in the LDIF file to specify that the entry be added to the directory. With the ldapmodify command, however, you use the changetype: modify command in the LDIF file to indicate that an existing entry should be modified using the attributes and values listed in the file. For example, if you needed to change the geeko user’s phone number to 801-5557001, you could create a file similar to the following: # geeko modify dn: cn=geeko,ou=People,dc=digitalairlines,dc=com changetype: modify replace: telephoneNumber telephoneNumber: 801-555-7001 NOTE: Make sure you have no trailing white spaces at the end of the lines, as these can cause errors.

Then you import the LDIF modify file into the LDAP directory using the following command (in one line): ldapmodify -x -D cn=Administrator,dc=digitalairlines,dc=com -W -f geeko.ldif When you do, the following is displayed: da1:~ # # ldapmodify -x -D cn=Administrator,dc=digitalairlines,dc=com -W -f newuser2.ldif Enter LDAP Password: modifying entry "cn=geeko,ou=People,dc=digitalairlines,dc=com" da1:~ #

158


Version 1


Finally, you can delete entries from the LDAP directories using the ldapdelete command. The syntax for this utility is similar to that used by the other LDAP shell commands. For example, to delete the geeko user we just created, you would enter the following (in one line): ldapdelete -x -D cn=Administrator,dc=digitalairlines,dc=com -W cn=geeko,ou=People,dc=digitalairlines,dc=com

Managing LDAP Users and Groups in YaST As with local user accounts, you can manage LDAP users and groups using YaST modules as well as command line utilities. To do this, complete the following: 1.

Start YaST, then select Security and Users > User and Group Management.

2.

On the Users tab, select Set Filter > LDAP Users.

3.

When prompted, enter your LDAP Administrator user’s password. The following screen is displayed: Managing Users in YaST

Figure 3-28

4.

To add a new user, do the following: a.

Select Add. The User Data tab in the New LDAP User screen is displayed:

Version 1


159






Creating a New LDAP User

Figure 3-29

b.

c.

160

Enter the following information about the user: 

First Name



Last Name



Username



Password

Select the Details tab.


Version 1


The following is displayed: Configuring New User Details

Figure 3-30

Notice that the fields on the Details tabs are already populated for the new user. You defined these defaults when you set up your user and group templates earlier. d.

Version 1

Select OK.


161






The new user is added to your list of LDAP users, as shown below: Viewing a New LDAP User

Figure 3-31

5.

To edit an existing LDAP user, select the user to be modified, then select Edit.

6.

Make the appropriate changes to the User Data and Details tabs, then select OK.

7.

To delete an LDAP user, select the user to be removed, then select Delete.

8.

When you’re done, select OK.

Managing LDAP groups is done in a similar manner. Do the following:

162

1.

Start YaST, then select Security and Users > User and Group Management.

2.

Select the Groups tab, then select Set Filter > LDAP Groups.

3.

When prompted, enter your LDAP Administrator user’s password.


Version 1


A list of your LDAP groups is displayed, as shown below: Managing LDAP Groups

Figure 3-32

4.

Version 1

To add a new group, select Add.


163






The following is displayed: Creating a New LDAP Group

Figure 3-33

5.

164

Enter the following information for the group: 

Group Name



Group ID (should be automatically populated based on the template you created earlier)



Password (optional)

6.

In the right column, select the users you want to be members of the group.

7.

Select OK.


Version 1


Viewing New LDAP Groups

Figure 3-34

8.

As with LDAP users, you can use the Edit and Delete options on this screen to modify or remove an LDAP group.

9.

When complete, select OK.

You can use the YaST LDAP Browser module to view the contents of your LDAP tree graphically. To do this, complete the following:

Version 1

1.

Start YaST, then select Network Services > LDAP Browser.

2.

(Conditional) If this is the first time you access your LDAP tree, you must configure an LDAP connection for the LDAP Browser. a.

On the LDAP Connections screen, select Add.

b.

Enter a name for the connection, then select OK.

c.

Specify the following information for the connection: 

LDAP Server: The IP address or DNS name of your LDAP server.



Administrator DN: The DN of your LDAP server’s Administrator user.



LDAP Server Password: Your Administrator user’s password.



LDAP TLS: If your LDAP server uses TLS, select this option.


165






An example is shown in the following: Configuring an LDAP Connection

Figure 3-35

d.

Select OK. Your LDAP tree is displayed.

3.

166

Double-click your root entry in the left pane.


Version 1


You should see your first-level container objects, as shown below: Figure 3-36

Version 1

Viewing the LDAP Tree


167






You can use the left pane to navigate through the tree. Whenever you select an object in the left pane, its attributes and values are displayed in the right pane. For example, if you were to select uid=tux,ou=People,dc=digitalairlines, dc=com, you would see the various attributes that comprise the tux user object and its associated values in the right pane, as shown below: Viewing an Object and Its Attributes

Figure 3-37

4.

If you need to edit an attribute value, do the following: a.

Double-click the attribute in the right pane. A window similar to the following is displayed: Editing an Attribute Value in the LDAP Browser

Figure 3-38

b. 5.

168

Make the desired change, then select OK.

When you’re done, select Close.


Version 1


Exercise 3-1

Configure OpenLDAP on SLE 11 In this exercise, you install and configure an LDAP server on DA1. You then configure the LDAP client on your DA1 server and on your workstation. You will find this exercise in the workbook. (End of Exercise)

Version 1


169






Summary Objective

Summary

Describe How LDAP Works

LDAP stands for Lightweight Directory Access Protocol. It’s a set of protocols designed to access and maintain information in a Directory. An LDAP Directory can be used to store many types of information including user, group, and service configuration settings. LDAP is a standardized open protocol, which ensures that many different client applications can access the information stored in the Directory. A Directory is a compilation of services that provide discovery, security, storage, and relationship management. A Directory does the following: 

Enables access to resources on the entire network and not just specific servers



Provides secure access to network resources



Provides a scalable, indexed, and cacheable database (for performance)



Manages relationships between Directory entities, such as users and the resources they access

An LDAP Directory uses a hierarchical tree structure. All entries (called objects) in the Directory have a defined position within its hierarchy. The complete path from the root of the tree to a particular entry, including the entry’s name, is called its distinguished name or DN. The DN uniquely identifies an object in the Directory tree. Objects can be categorized into one of two possible types: 

Container Objects



Leaf Objects

When working with an LDAP Directory, you need to be familiar with the following concepts:

170



Objects



Context



Naming


Version 1


Objective

Summary

Install and Configure OpenLDAP on SLES 11

SLES and SLED 11 can be configured to use an LDAP Directory service to store user accounts and service configuration information. To do this, you need complete the following tasks:

1. Configure the LDAP server. 2. Configure the LDAP client. Add, Modify, and Delete Entries to the LDAP Directory Tree

If you have installed and configured OpenLDAP on your servers and workstations, you can still use your standard comman line user management utilities to manipulate accounts stored in /etc/passwd, /etc/ shadow, and /etc/group. To use these commands to manage users in the ldap directory, you have to use the options -service ldap -D binddn In addition, you can use a special set of user management utilities:

Version 1



ldapsearch



ldapadd



ldapmodify



YaST User Management Module


171






172


Version 1


SECTION 4


In this section, you will learn how to configure SLES 11 as file and print server for Linux, OS X, and Windows workstations using Samba. Objectives

Version 1

1.

“Describe the Role and Function of Samba” on page 174

2.

“Configure a Simple File Server with Samba” on page 178

3.

“Configure Samba Authentication” on page 192

4.

“Use Samba‘s Client Tools ” on page 202

5.

“Use Samba as a Domain Controller” on page 207

6.

“Integrate Samba into a Windows Domain” on page 219


173






Objective 1

Describe the Role and Function of Samba Using Samba, a Linux system can be configured as a file and print server for Linux, Mac OSX, Windows, and OS/2 workstations. Essentially, Samba allows your Linux system to emulate a Window server. Users can access shared directories and printers on the Linux server just as they would on a Windows server. You can configure Samba as a domain controller. You can even join an Active Directory domain. The key to making all of this work is the fact that Samba uses the Server Message Block (SMB) protocol. To fully implement Samba, you need to have a solid understanding of SMB. In this objective, you learn the following: 

“SMB Overview” on page 174



“NetBIOS Overview” on page 174



“How SMB Communications Work” on page 176

SMB Overview The earliest version of the SMB protocol was developed by IBM in the 1980s. The protocol was later integrated natively into the Windows desktop and server operating systems. SMB has also been integrated into Linux/UNIX as well. Using the Samba package, a Linux server can also support native Windows clients. The SMB protocol implements sharing. Shared resources, such as directories and printers, are referenced using the Universal Naming Convention (UNC). UNC uses the following syntax to identify a share: \\server_name\share_name For example, if you had a SLES 11 server named DA1 with Samba configured, you could create a directory named /home/shared as a place for network users to store their files. Using Samba, you could share this directory with the share name shared. To reference the share, you would use a UNC of \\DA1\shared. You can also use a URL to reference an SMB share, as shown below: smb://server_name/share_name SMB operates at the Application and Presentation layers of the OSI model. The role of SMB is to provide clients with access to the file system and printers on a server. SMB uses the internal security of the server file system to determine what the client can and cannot do.

NetBIOS Overview Because it’s an upper-layer protocol, SMB can’t operate alone. It must be implemented in conjunction with a middle-layer protocol. The most common implementation is to use SMB in conjunction with Network Basic Input/Output System (NetBIOS) protocol on top of IP. NetBIOS was original developed in the mid-1980s and is used as the basic networking protocol for the Windows operating system. NetBIOS operates at the Session layer of the OSI model. As such, it has no routing capabilities. To make

174


Version 1


NetBIOS routable, you have to use it in conjunction with a Network-layer protocol, such as IPX or IP. This relationship is shown in the figure below: Figure 4-1

The Relationship between SMB, NetBIOS, TCP, and IP

As you know, IP uses a numerical IP address to uniquely identify each network host. NetBIOS, on the other hand, uses a 16-byte, 15-character alphanumeric name to uniquely identify network hosts. The very last byte of a NetBIOS name (called the NetBIOS Suffix) is not used for the name value. Instead, it is used to identify the type of host. A workstation will have a value of 00 (hex). A server will have a hex value of 20. A Primary Domain Controller (PDC) or a Backup Domain Controller (BDC) will have a hex value of 1C. Any given system can have both a NetBIOS name and a hostname. These two names are completely separate. Because NetBIOS works on top of IP, you need to be able to resolve NetBIOS names into IP addresses, just as you need to resolve hostnames and DNS names into IP addresses. In NetBIOS, name resolution is done using a Windows Internet Naming Service (WINS) server. A WINS server works much like a DNS server. When a NetBIOS computer is booted on the network, it does the following: 

If a WINS server is detected on the network, the NetBIOS computer registers itself with the server on startup. If its NetBIOS name is not already in use, the WINS server puts the system’s name and IP address in its database. All other NetBIOS hosts can send queries to the WINS server to resolve the NetBIOS name into an IP address.



Version 1

If a WINS server is not detected, the NetBIOS computer will simply broadcast its NetBIOS name on the network when it boots.


175






If another system is already using that NetBIOS name, an error will be generated indicating that a name conflict exists. Hosts still need to be able to resolve NetBIOS names into IP addresses. To do this without a WINS server, a NetBIOS host that needs to contact another host sends out a broadcast. The host with the requested NetBIOS name responds back with its IP address.

How SMB Communications Work When you attempt to open an SMB connection, the NetBIOS protocol is used to establish a connection at the Session layer between the sending and receiving systems. Once a NetBIOS session has been established, clients and servers communicate with each other at the upper layers of the OSI model with the SMB protocol, using Server Message Blocks (SMBs). SMBs contain commands that establish communications and manipulate shared directories, files, and printers. SMBs work on a command/response model. Consider the following SMB session. A user on a workstation needs to create a file on a server, add content to the file, and save it. The SMB commands and responses required to do this include the following: 1.

The client sends an SMBNegProt command to the server. This tells the server which dialect of SMB it's using. NOTE: There are many different SMB protocol versions and dialects.

2.

The server sends an SMBNegProt response back to the client, agreeing on the dialect to be used.

3.

The client sends an SMBSesssetup command to the server. This SMB contains the username and password of the user.

4.

If the username and password are valid, the server responds with an SMBSesssetup response reporting that the user is authenticated.

5.

The client sends an SMBtcon command. This tells the server which share it wants to use.

6.

The server responds with an SMBtcon response, telling the client that it has been granted permission to use the share.

7.

The client sends an SMBmknew command. This SMB tells the server to create a new file.

8.

The server sends an SMBmknew response after the file has been created.

9.

The client sends an SMBopen command that tells the server to open the file that was just created.

10. The client sends an SMBread command. The server responds with the requested

file. At this point, the user can work on the open file from the client workstation.

176


Version 1


11. When the editing is complete, the file is saved and closed. The client sends an

SMBwriteclose command. 12. The server system writes the file to disk and closes it.

In addition to the SMBs discussed in the example above, many other commands can be used when working with shared resources on the server, including the following: 

SMBcopy: Copies files



SMBmove: Moves files



SMBsplopen: Opens a print spool for printing

How Samba Works The Samba service on a SLES 11 system allows Samba clients to connect to shared directories and printers on your server. You can use Samba for the following purposes: 

Provide file and print services for Samba clients (such as Windows, OSX, and Linux workstations).



Act as a domain controller for Windows clients.



Integrate into an existing Windows domain for authentication purposes

The server side of Samba consists of two daemons: 

nmbd: Handles all NetBIOS-related tasks. It also can provide a WINS server.



smbd: Provides file and print services for clients in the network.

In addition, to integrate the Samba server into a Windows environment, Samba also provides the following services and utilities: 

winbind: Integrates a Linux system into a Windows authentication system, such as Active Directory. Essentially, it allows Windows domain users to function as local Linux users.



nmblookup: Used for NetBIOS name resolution and testing.



smbclient: Provides access to SMB file and print services.

SLES 11 includes Samba version 3.2.7. Novell is an important contributor of the Samba project. You can find more information about the Novell/SUSE Samba packages and the Novell/SUSE Samba team at (http://www.opensuse.org/samba).

Version 1


177






Objective 2

Configure a Simple File Server with Samba To set up a simple file server with Samba, you need to be familiar with the following tasks: 

“Installing Samba on the Server” on page 178



“Using the Samba Configuration File” on page 179



“Configuring Samba in YaST” on page 185

Installing Samba on the Server To configure a file server, the Samba packages need to be installed: 

samba: Main Samba package. It contains the Samba server software.



samba-client: Contains the Samba client tools.



samba-doc (optional): Provides additional documentation about Samba.

NOTE: The samba and samba-client packages are installed by default during the installation of SLES 11.

You can verify that the packages are installed with the rpm -q samba and rpm q samba-client commands. If they are installed, rpm displays the installed version, or an error message informs you that the package is not installed.

178


Version 1


If the packages have not been installed, you can install them using the rpm command. You can also start YaST on your server and use the Software Management module to install the File Server pattern, as shown below: Figure 4-2

Installing the File Server Pattern

After the packages have been installed, you can start the Samba daemons with the following commands: rcnmb start rcsmb start To start the Samba services automatically when the system is booting, enter the following commands: insserv nmb insserv smb

Using the Samba Configuration File The Samba service is configured in the /etc/samba/smb.conf file. The options in the this file are grouped into several sections. Each section starts with a keyword in square brackets. In this part of the course, you learn how to set up a simple file server with Samba. You need to be familiar with the following tasks: 

Version 1

“Configuring General Server Options” on page 180


179








“Sharing Users’ Home Directories” on page 181



“Configuring Shares” on page 182



“Sharing Printers” on page 183

Configuring General Server Options

The first task you need to be familiar with is configuring general server options in the smb.conf file. The general server configuration section starts with the keyword [global]. The following is an example of a basic global section: [global] workgroup = DigitalAirlines netbios name = DA1 security = share server string = DA1 File Server

The entries of the global section in this example are described below: 

workgroup = DigitalAirlines Defines the name of the workgroup or domain the Samba server will participate in.



netbios name = DA1 Used to manually set the NetBIOS name of the Samba server. If you don’t include this parameter, the NetBIOS name will default to the server’s hostname.



security = share Determines how a client has to authenticate itself when accessing a share. This option can have the following values: 











180

share: Authentication is handled on a per-share basis. Each share in the system is assigned its own password. Client systems can access the share by simply providing the share’s password. Usernames are not checked. user: Authentication is handled on a per-user basis. An SMB client must first authenticate with a valid username and password to the Samba server before it is allowed to access shared resources on the server. This is the default value if the security option isn’t explicitly included in smb.conf. server: Specifies that the client must provide a username and password when it connects to the server. Samba contacts another SMB server in the network to validate the password. This is usually used in a workgroup configuration. domain: All authentication processes are handled by a remote primary domain controller or a backup domain controller. This value is usually used in a domain configuration. ads: Specifies that Samba acts as domain member of an ADS realm to validate the username and password.

server string: Provides a description of the Samba server that will be displayed in My Network Places for Windows clients. This text string can contain any


Version 1


value you want. If you don’t include this parameter, smbd will default to a a description of Samba samba_version_number. In addition to the above, you can also include the following global server options, if required for your particular implementation: 

encrypt passwords: Configures smbd to use encrypted passwords. This should be enabled as every version of Windows since Windows 98 requires encrypted passwords.



passdb backend: Identifies where Samba user accounts are stored.



wins server: Specifies the IP address of your network’s WINS server.



wins support: If your network doesn’t already have a WINS server on your network, set this parameter to yes. This will enable WINS by running the nmbd daemon on your server.



username map: Specifies a file that is used to map SMB client usernames to local server usernames. By default, this is /etc/samba/smbusers.

NOTE: There are many other parameters that you can optionally include in the [global] section of the smb.conf file. See the smb.conf man page to learn more.

Sharing Users’ Home Directories

Next, you need to know how to share users’ home directories. By default, the smb.conf file is pre-configured to share user home directories in the [homes] section. An example is shown below: [homes] comment = Home Directories valid users = %S, %D%w%S browseable = No read only = No inherit acls = Yes

This section of the smb.conf file automatically shares the home directories of the users on your server. A user can access his or her share using the following UNC: \\server_name\username

Version 1


181






For example, if your Linux username were rtracy and you accessed your Samba server from a Windows workstation, you would see a share named rtracy, as shown below: Figure 4-3

Viewing Shared Home Directories

Configuring Shares

In addition to sharing home directories, you can also share other directories in the server’s file system. You do this by adding a share definition to the smb.conf file for each directory on your file server that will be shared. The following example defines a simple share: [data] comment = Data path = /srv/data read only = Yes guest ok = Yes

The entries in this example are described below: 

[data]: Defines the identifier for the share. The share in this example can be accessed with the following UNC: \\da1\data



182

comment = Data: Defines a comment that displays additional information about the share. The comment is displayed when you browse the network with Windows Explorer.


Version 1




path = /srv/data: Sets the path in the local file system that the share points to. Verify that the local user accounts who need access to the files in this share have been granted the appropriate file system rights.



read only = Yes: Specifies that the client accessing the share is not allowed to modify, delete, or create any files. This is the default value used if this parameter is not included in the share definition.



guest ok = Yes: Specifies that a password is not required to access the share.

There many more configuration options available for defining shares in smb.conf. Depending upon your needs, you could also include the following: 

browseable: Specifies whether or not the share can be browsed in My Network Places on Windows systems. If you don’t include this parameter, a default value of yes is assumed.



writeable: If set to yes, users may create or edit files in the shared directory, as long as the file system permissions assigned to the directory allow it.



public: If set to yes, users can connect to the shared directory without a password using the nobody system user account. This option is used only with share-level security. The default value for this option is no.



valid users: Restricts access to the share to a specified list of users. Separate usernames with a comma (,).

NOTE: There are many other parameters that you can optionally include when defining a share in the smb.conf file. See the smb.conf man page to learn more.

Sharing Printers

You can also use Samba to share the printers configured on your SLES 11 server. This is a signification benefit for users who use Windows workstations. By default, the Windows operating system isn’t compatible with network CUPS printers. Using Samba, however, Windows users can send print jobs to your SLES 11 server and have them print on your CUPS printers. Samba accepts print jobs from SMB clients that it spools to a local spool directory. When the entire print job has been received, Samba runs a local print command and passes the spooled file to it. The local printing system then processes the print job and sends it to the printer. By default, the smb.conf file is preconfigured to share all configured printers in the [printers] section. If this section exists within the smb.conf files, users can connect to any printer in the Samba host's printcap file. On startup, Samba creates a printer share for every printer defined in the printcap file. The [printers] section contains settings that are applied by default to all Samba printers on the server. A sample [printers] section is shown below:

Version 1


183






[printers] comment = All Printers path = /var/tmp printable = Yes create mask = 0600 browseable = No

The options in this file are explained below: 

comment = All Printers: Causes the comment specified to be shown next to the share in Network Neighborhood (or with the net view command).



path = /var/tmp: Defines the directory that will be used to spool print jobs.



printable = Yes: When set to Yes, this option allows client systems to create spool files for printing in the directory defined above. This value must exist within [printers], otherwise the Samba daemon won’t start.



create mask: Sets the necessary POSIX permissions to the directory.



browseable = No: Makes the [printer] share itself invisible in the list of available shares in Network Neighborhood. Individual shared printers, however are still visible. This option should always be set to No if printable = yes.

In addition to the above options, you can also use the following options, as appropriate: 

guest ok = Yes: Allows anonymous guest printing to the printer. No password is required. The guest account maps to the nobody user account and print jobs are sent as this user. Otherwise, the user must first authenticate to the Samba service to send a print job.



public = Yes: Performs the same function as guest ok = Yes.



read only = Yes: Allows users to spool print jobs to the directory defined, but prevents normal write operations in this directory.



writable = No: Performs the same function as read only = Yes.

In addition to the [printers] section, you can also add several printing-related options to the [global] section of the smb.conf file. These include the following:

184



load printers: If you include this parameter in your smb.conf file, all printers defined in the /etc/printcap file will automatically be shared. If you use this parameter, you do not need to define separate shares for your printers. Each automatically created printer share will use the configuration options found in the [printers] section of the smb.conf file.



printing: Defines the type of printing system that will be shared by Samba. The possible values are CUPS, LPRNG, PLP, SYSV, AIX, HPUX, QNX, SOFTQ, and BSD. Usually you will use CUPS for this parameter.



show add printer wizard: If set to Yes, this option causes the Add Printer icon to appear in the Printers folder of the Samba server's share in Network Neighborhood. The Add Printer Wizard lets you upload a printer driver to the [print$] share and associate it with a printer.


Version 1




max print jobs: Sets the maximum number of print jobs that can be active on the Samba server at any one time.



printcap name: Tells Samba where to look for a list of available printer names. By default, this is cups.



printer admin: Specifies a user or group (identified with @) that are allowed to add drivers and set printer properties. The root user is always a printer admin.

NOTE: You can configure Samba to support the uploading and downloading of printer drivers. This is done with the [print$] share in the smb.conf file. See the printing section in the /usr/ share/doc/packages/samba/Samba3-HOWTO.pdf file.

Testing the Samba Configuration

After you have configured your smb.conf file, you need to restart the Samba server daemons for the changes to take effect. However, before doing so, you should use the testparm command at the shell prompt to test the syntax of your Samba configuration file. When you do, you should see output similar to the following: da1:~ # testparm Load smb config files from /etc/samba/smb.conf Processing section "[homes]" Processing section "[profiles]" Processing section "[users]" Processing section "[groups]" Processing section "[printers]" Processing section "[print$]" Processing section "[data]" Loaded services file OK. Server role: ROLE_STANDALONE Press enter to see a dump of your service definitions

In this example, no errors are found. If there were any errors in the file, the command would display the errors grouped by configuration sections. An interesting option for testparm is --section-name section_name, which tests only the specified section. This can be very useful when you have a very long smb.conf.

Configuring Samba in YaST In addition to manually modifying the smb.conf file with a text editor, you can also configure your Samba server using YaST. 1.

Version 1

Start YaST and select Network Services > Samba Server.


185






A list of shares defined on the Samba server is displayed, as shown below: Viewing Samba Shares in YaST

Figure 4-4

2.

186

To configure your Samba server’s global options, select the Identity tab.


Version 1


The following is displayed: Configuring the Samba Server’s Identity

Figure 4-5

3.

4.

Version 1

Configure the following parameters: 

Workgroup or Domain Name



NetBios Hostname



WINS Server Support or Remote WINS Server



Use WINS for Hostname Resolution

If you need more granular control over your Samba server’s configuration, select Advanced Settings > Expert Global Settings.


187






When you do, the following is displayed: Configuring Expert Global Settings

Figure 4-6

In this screen, you can use the Add, Edit, or Delete buttons to add, modify, or remove Samba global configuration options. Notice that the options displayed are the same as those discussed earlier in this section in “Configuring General Server Options” on page 180. When done making changes, select OK. 5.

188

To create a new share, select the Shares tab, then select Add.


Version 1


Defining a New Share

Figure 4-7

6.

7.

Enter the following information in the New Share screen: 

Share Name



Share Description



Share Type



Share Path

Select OK. The share is added to the list of defined shares.

8.

To enable or disable an existing share, select it from the list, then select Toggle Status.

9.

To hide system-defined shares, select Filter > Do Not Show System Shares. When you do, only the [homes] and [groups] shares are displayed along with any custom shares you have defined.

10. To edit an existing share, select it from the list, then select Edit.

Version 1


189






When you do, the share definition is displayed, as shown below: Figure 4-8

Editing an Existing Share

You can use the Add, Edit, and Delete buttons to add, modify, or remove options from the share definition. Notice that the options displayed are the same as those discussed earlier in “Configuring Shares” on page 182. When done modifying the share, select OK. 11. To delete a share, select it from the list, then select Delete.

190


Version 1


Exercise 4-1

Create a Basic Samba Share In this exercise, you learn how to configure a basic samba share. You will find this exercise in the workbook. (End of Exercise)

Version 1


191






Objective 3

Configure Samba Authentication In the example presented in the previous objective, the [data] share is accessible on the Samba server without supplying a username and password. In most cases, this level of access is inappropriate. In this objective, you learn how to configure Samba authentication. The following topics are addressed: 

“Configuring the Samba User Database” on page 192



“Configuring Samba to Require User Authentication” on page 198

Configuring the Samba User Database The first task you need to complete is to determine where Samba user accounts will be stored. It’s important to recognize that Samba maintains its own database of user accounts that are used to authenticate to the service. NOTE: The user accounts in your /etc/passwd file are not directly used by Samba. However, they can be mapped over to your Samba database of user accounts.

You have several options for storing your Samba users, including the following: 

“Using /etc/samba/smbpasswd” on page 192



“Using LDAP” on page 193

Using /etc/samba/smbpasswd

By default, the /etc/samba/smbpasswd file is used by Samba to store user accounts, but it does not have any users defined. To populate the smbpasswd file with user accounts, you use the smbpasswd utility at the shell prompt. To do this, complete the following: 1.

Open a terminal session and switch to root using the su - command. NOTE: If you run smbpasswd as any user other than root, it can be used to mange the smbpasswd account only for the current user.

2.

At the shell prompt, enter smbpasswd -a username.

3.

When prompted, enter a password for the Samba user account. While not required, many administrators prefer to use the same password for the Samba user account as the Linux user account.

4.

192

Restart the Samba daemon.


Version 1


Once done, the user account is added to the /etc/samba/smbpasswd file, as shown below: # This file is the authentication source for Samba if 'passdb backend' # is set to 'smbpasswd' and 'encrypt passwords' is 'Yes' in the # [global] section of /etc/samba/smb.conf # # See section 'passdb backend' and 'encrypt passwords' in the manual # page of smb.conf for more information. geeko:1000:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:55DB0294BC42D6E1B81AE2B5C 7F2943F:[U ]:LCT-49D5D363:

To remove a user from the file, you use the smbpasswd -x username command at the shell prompt. To disable a user, you use the smbpasswd -d username command at the shell prompt. To reactivate a disabled account, you use the smbpasswd -e username command. To change a user’s Samba password, you use smbpasswd username at the shell prompt. The /etc/samba/smbusers file is used by Samba to map usernames from client systems to user accounts on the local server. The following syntax is used: unix_name = smb_name This file is not included in the default configuration. Using LDAP

In addition to local files, the Samba service can also be configured to store its users in an OpenLDAP directory service. To do this, complete the following:

Version 1

1.


2.

Select the LDAP Settings tab.


193






The following is displayed: Configuring Samba LDAP Settings

Figure 4-9

3.

Select Use LDAP Password Back-End.

4.

When prompted that all values will be rewritten, select Yes to continue. The various fields in this interface are automatically populated for you using the default values found in your server’s /etc/openldap/ldap.conf file.

5.

Make any changes that are necessary to the various settings.

6.

Type your LDAP administrator’s password in the Administration Password fields.

7.

Select Test Connection.

8.

If the test was successful, select OK.

9.

Select OK to apply your settings.

10. Close YaST.

After making your configuration changes, several important changes are made to the [global] section of your smb.conf file. Instead of using local files for the passwd backend, your LDAP directory service is specified. An example is shown below: idmap backend = ldap:ldap://127.0.0.1 ldap admin dn = cn=Administrator,dc=digitalairlines,dc=com ldap delete dn = No ldap group suffix = ou=group ldap idmap suffix = ou=Idmap

194


Version 1


ldap machine suffix = ou=Machines ldap passwd sync = Yes ldap replication sleep = 1000 ldap ssl = Start_tls ldap suffix = dc=digitalairlines,dc=com ldap timeout = 5 ldap user suffix = ou=people passdb backend = ldapsam:ldap://127.0.0.1

These configuration changes do the following: 

Identify the URL of the LDAP server



Identify the dn of the LDAP administrator



Identify where user, group, and machine objects will be stored in the directory



Identify the base dn (root entry) of the LDAP directory

Likewise, the appropriate entries are added to your LDAP directory. A sample is shown below: Figure 4-10

Viewing Samba Objects in the LDAP Directory

In the above example, Samba was configured to use ou=people to store its user accounts. This is the same directory where the system user accounts are stored. From this point on, any users created on the system will automatically be Samba enabled.

Version 1


195






For example, in the figure below, the lmorgan user account has been created and automatically Samba enabled. Figure 4-11

196

New Users Automatically Samba Enabled


Version 1


However, any user accounts that existed in the LDAP directory prior to configuring Samba will still need to be Samba enabled. For example, in the figure below, the tux user account has not been Samba enabled: Figure 4-12

Samba Enabling an Existing LDAP User

You Samba enable an LDAP user using the smbpasswd command in the same manner as was done previously. In this example, you enter smbpasswd -a tux (as root) at the shell prompt and enter a Samba password for the user.

Version 1


197






After doing so, the various Samba-related properties are added to the tux user object, as shown below: Figure 4-13

Samba Enabled LDAP User Account

Configuring Samba to Require User Authentication In the [data] share definition presented in the previous objective, guest access was allowed to the share, as shown below: [data] comment = Data path = /srv/data read only = Yes guest ok = Yes

In addition, the security option in the [global] section was set to share, as shown below: [global] workgroup = DigitalAirlines netbios name = DA1 security = share server string = DA1 File Server

This security level requires a password to be set on a per-share basis. Client system can access the share by simply proving the share’s password. Usernames are not checked.

198


Version 1


In most situations, you will want to reconfigure this share with a higher level of security. In this part of this objective, you learn how to reconfigure the share such that users must supply a valid Samba username and password to access it. The first task is to change the security option in the [global] section in the smb.conf file to security = user, as shown below: [global] workgroup = DigitalAirlines netbios name = DA1 security = user server string = DA1 File Server

This forces users to authenticate when a client attempts to connect to the Samba server. However, once they do, your users have access to every share defined in the smb.conf file. Usually, this is not acceptable. More than likely, you will want to restrict access to a given share to a specific set of users. You can use the valid users option within the share definition to specify which Samba users are allowed access to the share. In the following, the guest ok option has been replaced with the valid users option to restrict access to the [data] share to only the tux user: [data] comment = Data path = /srv/data read only = no valid users = tux

You can specify one user or more users with this option. Multiple usernames must be separated by commas. Changing the read only option to a value of No makes the share writable. You can also use groups with the valid users option. Group names must begin with @, for example @accounting. Remember that all group members must be Samba enabled with the smbpasswd command. The following example configures the [data] share such that it is readable and writable by all members of the accounting group: [data] comment = Accounting Data path = /srv/data read only = no valid users = @accounting force user = tux force group = accounting

Version 1


199






In this example, several options have been modified or added:

200



valid users = @accounting: Allows all users who are in the accounting group to access the share.



force user = tux: Forces Samba to perform all file operations in the share as the tux user, which can be very useful. For example, using this option allows you to set your POSIX permissions in the file system for the tux user and have those permissions automatically applied to every other user who is allowed to access the share.



force group = accounting: Forces the Samba server to perform all file operations using the accounting group.


Version 1


Exercise 4-2

Configure Samba to Use LDAP Authentication In this exercise, you learn how to configure Samba to store its user accounts in an LDAP directory service. You will find this exercise in the workbook. (End of Exercise)

Version 1


201






Objective 4

Use Samba‘s Client Tools Although Samba is commonly used to provide Windows workstations with access to Linux servers, Linux workstations can also access Samba shares. Samba provides a variety of tools that you can use to access shares from a Linux system. These tools can be used to access a Samba server or a native Windows server. In this objective, you learn how to use these tools. The following tasks are addressed: 

“Using nmblookup” on page 202



“Using smbclient” on page 202



“Mounting Samba Shares in the Linux File System” on page 204

Using nmblookup With the nmblookup tool, you can resolve NetBIOS names into IP addresses. In the following example, the IP address for the Samba server with the NetBIOS name da1 is looked up: geeko@DA-SLED:~> nmblookup da1 querying da1 on 172.17.8.255 172.17.8.101 da1<00>

In the first line of the output, nmblookup states that it is querying the server name with a broadcast to 172.17.8.255. In the second line of the output, it displays the result of the query. In this case, the system with a NetBIOS name of DA1 has an IP address of 172.17.8.101. NOTE: If the system you are querying is not in the same subnet, the name cannot be resolved with a broadcast query. Instead, nmblookup must use a WINS server to resolve the name. For more information, see the man page for nmblookup.

Using smbclient With the smbclient tool, you can access shares on a Samba server. It's also a very useful tool for testing your Samba server configuration. You can perform several tasks with smbclient.: 

“Browsing Shares Provided by a Samba Server” on page 202



“Accessing Files Provided by a Samba Server” on page 203



“Sending Print Jobs to Samba Printers” on page 204

Browsing Shares Provided by a Samba Server

The smbclient utility can be used to display a list of shares offered by a Samba server. To do this, enter the following command at the shell prompt: smbclient -L //server_name

202


Version 1


When smbclient asks for your password, press Enter to proceed. The output of smbclient will appear similar to the following: geeko@DA-SLED:~> smbclient -L //da1 Enter geeko's password: Domain=[DIGITALAIRLINES] OS=[Unix] Server=[Samba 3.2.7-1.3-2042-SUSECODE11] Sharename Type Comment -----------------profiles Disk Network Profiles Service users Disk All users groups Disk All groups print$ Disk Printer Drivers data Disk Data IPC$ IPC IPC Service (DA1 File Server) Domain=[DIGITALAIRLINES] OS=[Unix] Server=[Samba 3.2.7-1.3-2042-SUSECODE11] Server --------DA1

Comment ------DA1 File Server

Workgroup --------DIGITALAIRLINES

Master -------

The smbclient utility first displays all available shares on the Samba server. The IPC$ share provides information about the other shares available on the SMB server. The lower part of the smbclient output provides workgroup information. The smbclient command can be very valuable for testing purposes. After you have set up a share, you can use smbclient to test the availability of the share. Some shares are not browseable without authentication. In this case, you can pass a username to smbclient, as in the following example: smbclient -L //server_name -U username With these options, smbclient connects to the server with the username specified and prompts for the corresponding password. Accessing Files Provided by a Samba Server

You can also use smbclient to access a share on a server. To do this, you need to supply the share name along with the server name (without the -L option). In the following example, smbclient connects to the share data on the Samba server named da1: smbclient //da1/data

Version 1


203






A username can also be supplied with the -U option. After smbclient has connected to a share, it displays the following prompt: smb: \>

At this point, smbclient can be used like a command line FTP client. Some of the most commonly used commands include the following: 

ls: Displays the contents of the current directory.



cd: Changes to a directory.



get: Copies a file from the share to the current working directory.



put: Copies a file to the share. The share must be writable to use this command.

Sending Print Jobs to Samba Printers

You can also use smbclient to send print jobs to shared Samba printers. Use the following syntax: smbclient //server_name/shared_printer_name -c file_to_print The -c option performs the given command automatically after the connection to the server has been established. You can also enter the print command on the smb:\ command line after you have connected to the server.

Mounting Samba Shares in the Linux File System In addition to accessing shared files with smbclient, you can also mount a remote Samba share into the local file system, much like an NFS export. This is done using the mount command: mount -t cifs //server_name/share_name

/mount_point

For example: mount -t cifs //da1/data /mnt/samba In this example, the data share on the da1 Samba server is mounted into the /mnt/ samba directory. The -t cifs option to specifies that the resource to be mounted is an SMB share. If the share requires authentication, you can also supply a username as in the following: mount -t cifs -o username=geeko //da1/data /mnt/samba You will be prompted for the password. It is also possible to provide the password in the command as in the following: mount -t cifs -o username=geeko,password=novell //da1/ data /mnt/samba

204


Version 1


However, the password will be visible in the password history. If you use the /etc/ fstab file to mount the file system, the issue is similar, as every user on the system could view the password. The solution is to provide the password in the /etc/ samba/smbfstab file that is only readable for the system administrator. The equivalent to the above command line would look similar to the following: # # # # # # # # # # #

Version 1

This file allows you to mount SMB/ CIFS shares during system boot while hiding passwords to other people than root. Use /etc/fstab for public available services. You have to specify at least a service name and a mount point. Current default vfstype is smbfs. Possible vfstypes are smbfs and cifs. The options are explained in the manual page of smbmount and mount.cifs. service

moint-point

vfstype options

//da1/data

/mnt/samba

cifs

username=geeko,password=novell


205






Exercise 4-3

Work with Samba Shares In this exercise, you access a share with smbclient and you mount a Samba share in the file system of a Linux workstation. You will find this exercise in the workbook.

(End of Exercise)

206


Version 1


Objective 5

Use Samba as a Domain Controller In the preceding objectives, you have configured Samba on SLES 11 to function in a workgroup. However, Samba can also be configured to allow your server to function as a Windows domain controller. To do this, you need to be familiar with the following topics and tasks: 

“How Domains Work” on page 207



“Configuring Samba as a Domain Controller” on page 211



“Creating Machine Accounts” on page 215



“Mapping Local Linux Groups to Windows Groups” on page 216

How Domains Work Before discussing how to configure Samba as a domain controller, you need to have a basic understanding of how Windows domains work. NOTE: A full discussion of Windows networking topics is beyond the scope of this course.

The the following topics are addressed here: 

“Windows Workgroups” on page 207



“Windows Domains” on page 210



“Domain Controllers” on page 210



“Trust Relationships” on page 211

Windows Workgroups

A Windows workgroup is a logical organization of hosts that have been grouped together on a network. A workgroup is usually confined to the network hosts on a single network segment. A Windows workstation can be configured to participate in a workgroup using the System applet:

Version 1


207






Figure 4-14

Setting the Workgroup

To create a workgroup, type the same name in the Workgroup field on all the workstations and servers that will be members. Once configured, users can browse shared resources provided by the hosts that are members of the workgroup, as shown below:

208


Version 1


Figure 4-15

Viewing Workgroup Hosts

This browsing functionality makes Windows networking much easier for users. Instead of supplying a UNC path to a shared resource, users can browse through the workgroup to the particular host and select the resource. To make browsing possible, one computer system in the workgroup is elected to be the master browser. The master browser keeps a list of all hosts and shared resources in the workgroup. NOTE: Browsing works with Windows domains as well as workgroups.

The master browser is sometimes referred to as the local master browser. When systems in the workgroup are booted, they go through an election process to decide which system will be the master browser. Using factors such as system load and the length of time a host has been up, one system is elected to be the master browser for the workgroup. Master browsers are critical to the overall function of the workgroup. Without a master browser, each individual host in the workgroup would have to query every other host in the workgroup to identify the resources each has to share whenever he browsed the workgroup. This would take a considerable amount of time and would generate a lot of unnecessary network traffic. To speed things up, the master browser alone does all the probing to discover shared resources in the workgroup. When a user browses the workgroup, the host contacts the master browser to get a list of shared resources. Windows workgroups don’t require a Windows server, although they aren’t prevented from participating in a workgroup. Windows 9x, ME, NT, 2000, XP, Server 2003, Vista, and Server 2008 systems can all share resources in a workgroup.

Version 1


209






Any of these systems can function as a master browser in a workgroup. In addition, a Samba server or client on Linux can participate in a Windows workgroup. The other Windows systems in the workgroup don’t know the difference between a Linux Samba system and other Windows hosts. However, workgroups have a major shortcoming that limits their usefulness. Each computer system has to maintain its own separate set of user accounts. If users want to access resources on another system in the workgroup, they must have a user account configured on the remote system. If users need to use resources located on multiple systems, they must authenticate separately to each host. If the user passwords are the same on all hosts, this process works relatively well. However, if different usernames or passwords are used on each system, access is denied. Keeping user accounts synchronized in a large workgroup can quickly become a difficult administrative task. In addition, because of the way NetBIOS uses broadcasts, it can be difficult to implement a workgroup on a routed network. Windows Domains

For the reasons listed above, workgroups usually aren’t implemented in large organizations. Instead, most large Windows networks are configured to use domains. A Windows domain is a logical grouping of computer systems on a network, much like a workgroup. Unlike a workgroup, however, a domain uses a central database of user accounts that all systems that are members of the domain use for authentication. A single server is configured with the user account database (the domain). Domains overcome the weaknesses associated with workgroups. First, domains can span multiple network segments. In addition, domains also create a single point of administration. Domains also eliminate the need for multiple user logins. Because access to all resources in the domain is controlled by the domain database, users need to authenticate only once to the domain. After they are authenticated, they can access whatever domain resources they have access to. NOTE: Not all Windows operating systems can participate in a domain. Windows XP Home, for example, can participate only in a workgroup.

Domain Controllers

The system that hosts the domain database is called the domain controller. In a Windows network, the domain controller is a Windows server that runs a service called the Security Account Manager (SAM). Each domain must have one or more domain controllers. On a Windows network, one server is configured as a Primary Domain Controller (PDC). The PDC is the authoritative source of domain data.

210


Version 1


Each domain can have only one PDC. However, for fault-tolerance purposes, more than one domain controller should be configured. For redundancy purposes, a Windows network can be configured with a Backup Domain Controller (BDC). A BDC has a copy of the domain database from the PDC. If the PDC goes down, the BDC jumps in and takes over, ensuring that the network keeps working. A domain can have multiple BDCs. A BDC is non-authoritative in a Windows network. You can’t directly update the domain database on a BDC. Instead, you make all changes to the PDC domain database. The PDC then synchronizes the domain with all BDCs in the domain at periodic intervals. A user can use either a PDC or a BDC to authenticate to the domain. It’s also possible for a server to exist in a domain without being a PDC or a BDC. It’s called a member server. With the winbindd daemon running on a Linux Samba server, it can participate in a Windows domain. It can function as a PDC in a Windows NT-type network. It can also function as a BDC if the PDC is another Samba server. However, if the PDC is a Windows server, it can’t function as a BDC. Likewise, a Samba PDC can’t interoperate with a Windows BDC. This is because Samba doesn’t support SAM replication with Windows domain controllers. A Linux Samba server can also function as a member server in a Windows NT-style domain. If, however, you are using Active Directory, your options are a little more limited. Your Linux Samba server can function only as a member server in an ADS domain— it can’t be a PDC. NOTE: ADS domain control is scheduled to be implemented in Samba version 4.

Trust Relationships

Windows trust relationships allow you to establish trust relationships between two Windows domains to allow users in one domain to access shared resources in the other domain. Samba supports trust relationships.

Configuring Samba as a Domain Controller You can configure Samba as a domain controller by either manually editing /etc/ samba/smb.conf or by running the YaST Samba Server module. In this course, we will configure Samba as a domain controller using YaST and then look at the changes that were made to the smb.conf file. To do this, complete the following:

Version 1

1.


2.

Select the Identity tab.


211






The following is displayed: Viewing the Identity Tab

Figure 4-16

Notice in the figure above that the Samba server is not configured as a domain controller. In this configuration, it is functioning in a simple workgroup.

212

3.

To make the Samba server a domain controller, select either Primary (PDC) or Backup (BDC) from the Domain Controller drop-down list.

4.

Select OK.


Version 1


You are prompted to create a Samba administrative usernamed root, as shown below: Creating a Samba root User

Figure 4-17

5.

In the fields provided, type a password for the Samba root user; then select OK.

6.

Close YaST.

When you do, several changes are made to the /etc/samba/smb.conf file. The [global] section from a smb.conf file that configures the Samba server as a PDC is shown below: [global] workgroup = DigitalAirlines netbios name = DA1 security = user server string = DA1 File Server printing = cups printcap name = cups printcap cache time = 750 cups options = raw map to guest = Bad User include = /etc/samba/dhcp.conf logon path = \\%L\profiles\.msprofile logon home = \\%L\%U\.9xprofile logon drive = P: usershare allow guests = Yes idmap backend = ldap:ldap://127.0.0.1 ldap admin dn = cn=Administrator,dc=digitalairlines,dc=com ldap delete dn = No

Version 1


213






ldap group suffix = ou=group ldap idmap suffix = ou=Idmap ldap machine suffix = ou=Machines ldap passwd sync = Yes ldap replication sleep = 1000 ldap ssl = Start_tls ldap suffix = dc=digitalairlines,dc=com ldap timeout = 5 ldap user suffix = ou=people passdb backend = ldapsam:ldap://127.0.0.1 wins support = Yes add machine script = /sbin/yast /usr/share/YaST2/data/ add_machine.ycp %m$ domain logons = Yes domain master = Yes local master = Yes os level = 65 preferred master = Yes

The following changes are made to the [global] section: 

If the security level was set to share, it is changed to user.



add machine script = /sbin/yast /usr/share/YaST2/data/add_machine.ycp %m$: Specifies the script to run to create domain machine accounts when a system joins the domain.



domain logons = Yes: Configures Samba as a domain controller. When set to Yes, the Samba server runs the netlogon service, which allows users to authenticate to the domain.



domain master = Yes: When set to Yes, configures Samba as a PDC. When set to No, configures Samba as a BDC.



local master = Yes: Allows Samba to participate in the election of the local master browser.



os level = 65: Configures how well the Samba will do when electing a master browser. If you omit this parameter, the Samba server is assigned an os level of 20 by default. This causes the Samba server to win out over any other Windows systems in the workgroup or domain except for a PDC or BDC. Setting the os level to 65 causes the Samba server to win over any other system in a browser election.



preferred master = Yes: Configures the Samba server to be the preferred master browser for the workgroup or domain. If set to Yes, an election will be forced when the service is started. If domain master is also set to Yes, the Samba server will win the election.

In addition to these changes, the following share is also added to the end of the smb.conf file: [netlogon] comment = Network Logon Service path = /var/lib/samba/netlogon write list = root

214


Version 1


All Windows PDCs and BDCs provide a share called netlogon. It’s used to store logon scripts and group policies. Likewise, your Samba PDC or BDC should also provide this share. By default, the path to the netlogon directory is /var/lib/ samba/netlogon/. Only root is allowed to write files to this share.

Creating Machine Accounts Next, you need to create machine accounts for your workstations. You need a machine account on the Samba server for each Windows workstation that is going to be a member of the domain. The machine account is used to establish a trust relationship and a secure connection between the domain controller and the client system. To create machine accounts for your workstations, do the following: 1.

Using the utility of your choice, create a group in /etc/group named machines.

2.

Create a user account for the workstation in your /etc/passwd file by doing the following: a.

Open a terminal session and switch to your root user account using the su command.

b.

At the shell prompt, enter the following command: useradd -g machines -d /var/lib/nobody -c “comment” -s /bin/false machine_name$ This command creates a new user in /etc/passwd for the machine. The -g machines option makes the account a member of the machines group you created earlier. The -d option sets a null home directory for the machine account. The -c option adds a comment to the account. The -s option specifies a null default shell. The account name itself must be exactly the same as the machine’s NetBIOS name with a $ character appended to the end. The account has no password assigned.

3.

Samba enable the machine account by entering the following command at the shell prompt: smbpasswd -a -m machine_name For example, if you had a workstation with a NetBIOS name of da-sled and you’ve already created the da-sled$ user account in /etc/passwd, you would enter the following: da1:~ # smbpasswd -a -m da-sled Added user da-sled$. da1:~ #

Version 1


215






When you do, the machine account is added to your Samba account database. For example, the da-sled account above is added to the ou=Machines container in the LDAP directory: Machine Account in LDAP Browser

Figure 4-18

WARNING: Doing this is the equivalent of creating a machine trust account on a Windows server using Server Manager. Between the time you manually create the machine account until the time the client system joins the domain, there’s a risk that an intruder could join the domain using that NetBIOS name.

Mapping Local Linux Groups to Windows Groups With Samba configured as a PDC on your SLES 11 server, you next need to map several local Linux groups on the PDC to groups within Samba. This is done using the net groupmap command. Using this command, you should create two key group mappings: 

Map a local Linux group to the Domain Administrators group.



Map the local users group to the Domain Users group.

When installing Windows on a workstation, the installation program creates several default users and groups, including the Administrators group. It provisions this group with the privileges required to perform essential system tasks, such setting the system date and time and managing processes running on the system. In addition, the Administrator user is automatically made a member of the Administrators group.

216


Version 1


When a Windows system is made a member of the domain, the Domain Admins group on the PDC is automatically added to the Administrators group on the local workstation. Thus, every member of the Domain Admins group inherits the rights of the local Administrators group. You should create a new Linux group on the PDC that contains users who need administrative rights to domain workstations. Once done, you can map the group to the Domain Admins group by entering the following command at the shell prompt (as root): net groupmap set “Domain Admins” “group_name” For example, if the name of your Linux group is Admins, you would enter: net groupmap set “Domain Admins” “Admins” To view the mapping, enter net groupmap list at the shell prompt. In the example below, the Domain Admins group is mapped to the Admins group on the PDC: DA1:~ # net groupmap list Domain Admins (S-1-5-21-3504129146-1711875527-3885176169-3001) -> Admins DA1:~ #

In addition, you can also map the users Linux group on the PDC to the Domain Users group in Samba. Doing this makes all of your local Linux users members of the Domain Users group. Enter the following command: net groupmap set “Domain Users” “users” Again, you can enter net groupmap list at the shell prompt to view the mapping. An example is shown below: DA1:~ # net groupmap list Domain Admins (S-1-5-21-3504129146-1711875527-3885176169-3001) -> Admins Domain Users (S-1-5-21-3504129146-1711875527-3885176169-1201) -> users DA1:~ #

Version 1


217






Exercise 4-4

Configuring Samba as a Domain Controller In this exercise, you configure a Samba server as a Primary Domain Controller. You will find this exercise in the workbook. (End of Exercise)

218


Version 1


Objective 6

Integrate Samba into a Windows Domain SLES 11 includes the Windows Domain Membership YaST module that you can use to integrate a Linux system into a workgroup, Windows NT domain or Active Directory domain. This allows you to use domain user accounts to authenticate to the Linux system. 1.

Start YaST and supply your root user’s password.

2.

In YaST, select Network Services > Windows Domain Membership. When you start the module, the following is displayed: The YaST Windows Domain Membership Module

Figure 4-19

3.

In the Domain or Workgroup field, type the name of the domain or workgroup you would like to add the system to.

4.

Select Also Use SMB Information for Linux Authentication. This option allows verification of passwords with the Windows server or the Kerberos server (if joining an Active Directory domain).

5.

(Optional) Select Create Home Directory on Login. This causes local home directories to be created the first time a domain user logs in to the system.

6.

(Optional) Select Offline Authentication. This option allows the user to log in even if the domain controller is unreachable. However, the user must have already logged in at least once for this to work. The

Version 1


219






first time a user logs in, his or her credentials are stored in encrypted format locally. These credentials are then used for authentication in the event the domain controller is unreachable.

220

7.

Select OK.

8.

If prompted, supply the credentials of your domain controller administrator.


Version 1


Summary Objective

Summary

Describe the Role and Function of Samba

Using Samba, a Linux system can be configured as a file and print server for Linux, Mac OSX, Windows, and OS/2 workstations. Essentially, Samba allows your Linux system to emulate a Window server. Users can access shared directories and printers on the Linux server just as they would on a Windows server. You can configure Samba as a domain controller. You can even join an Active Directory domain. The key to making all of this work is the fact that Samba uses the Server Message Block (SMB) protocol.

Configure a Simple File Server with Samba

Before you can configure a file server, you need to verify that the Samba packages have been installed: 

samba: The main Samba package. It contains the Samba server software.



samba-client: Contains the Samba client tools.



samba-doc (optional): Provides additional documentation about Samba.

The Samba service is configured in the / etc/samba/smb.conf file. The options in this file are grouped into several sections. Each section starts with a keyword in square brackets. Configure Samba Authentication

You need to determine where Samba user accounts will be stored. Samba maintains its own database of user accounts that are used to authenticate to the service. The user accounts in your /etc/passwd file are not directly used by Samba. However, they can be mapped over to your Samba database of user accounts. The options for storing your Samba users include /etc/samba/smbpasswd and LDAP.

Version 1


221






Objective

Summary

Use Samba‘s Client Tools

Linux workstations can access Samba shares. Samba provides a variety of tools that you can use to access shares from a Linux system. These tools can be used to access a Samba server or a native Windows server. These tools include nmblookup, smbclient, and the mount command.

Use Samba as a Domain Controller

Samba can function in a workgroup configuration or as a domain controller. You can configure Samba as a domain controller by either manually editing /etc/ samba/smb.conf or by running the YaST Samba Server module. When you do, several changes are made to the /etc/samba/smb.conf file. The [global] section has the following changes made: 

If the security level was set to share, it is changed to user.



add machine script = /sbin/yast /usr/share/ YaST2/data/add_machine.ycp %m$



domain logons = Yes



domain master = Yes



local master = Yes



os level = 65



preferred master = Yes

In addition to these changes, the [netlogon] share is added to the end of the smb.conf file. Integrate Samba into a Windows Domain

SLES 11 includes the Windows Domain Membership YaST module that you can use to integrate a Linux system into a workgroup, Windows NT domain, or Active Directory domain. This allows you to use domain user accounts to authenticate to the Linux system.

222


Version 1


SECTION 5


In this section, you learn how to install and configure the Apache Web Server on SUSE Linux Enterprise Server 11. Objectives

Version 1

1.

“Set up a Basic Web Server with Apache” on page 224

2.

“Configure Virtual Hosts” on page 233

3.

“Limit Access to the Web Server” on page 237

4.

“Configure Apache with OpenSSL” on page 241

5.

“Install PHP” on page 248


223






Objective 1

Set up a Basic Web Server with Apache In this objective, you learn how to set up a basic Apache Web Server on SLES 11. To do this, you need to be familiar with the following: 

“How a Web Server Works” on page 224



“Installing Apache Web Server” on page 226

How a Web Server Works There are a variety of Web server packages that you can use on Linux, but by far, the most popular is the Apache Web Server. Most of the Web servers you access on the Internet are actually running some version of Apache. Web servers provide much of the functionality we associate with the Internet today. A Web server’s job is to send Web pages, graphics, and other files to clients requesting them. A Web server can transfer just about any type of file between the server and the client. However, the most common type of file used with a Web server are HyperText Markup Language (HTML) documents. An HTML document is a text file written using HTML markup coding that instructs the Web browser how the information should be formatted and displayed. A simple HTML file is shown below: Figure 5-1

224

Sample HTML Document


Version 1


When a user’s Web browser receives this file from the Web server, it interprets the marked-up text from the file and displays it on the screen. The information in the file is reformatted and displayed according to the markup information it contains. For example, when the file above is opened in a Web browser, it appears as shown below: Figure 5-2

Viewing an HTML Document in a Web Browser

The files that comprise a Web site are saved in a special directory in the file system of the system running the Web server daemon. This directory is called the document root or root directory. The Apache Web server’s document root is the /srv/www/ htdocs directory (you can configure a different directory as document root for apache). Communications between the Web browser and the Web server are accomplished using the IP protocol in conjunction with the Hyper Text Transfer Protocol (HTTP). HTTP is a request/response protocol used by the Web browser to get information from the Web server. The browser initiates the request by establishing a TCP/IP communication session between the client system and the Web server, which runs on TCP port 80 by default. The Web server then listens for the browser to tell it what information it wants. The browser does this by sending a request message to the Web server, which responds with the requested files. The request message consists of the following: 

Version 1

Request method: Specifies the resource being requested from the server. The HTTP protocol defines several request methods, including the following: 

GET: Requests the specified resource.



POST: Submits data to the Web server to be processed



PUT: Uploads a resource to the Web server.



DELETE: Deletes a specified resource from the Web server, if permitted.



OPTIONS: Requests the HTTP methods the Web server supports.


225








HTTP headers: Define the characteristics of the requested data, such as acceptable content types, character sets, encodings, languages, etc.



Message body: This is optional.

When using a Web browser, you use a Uniform Resource Locator (URL) to access the Web server. The URL is used by your browser to specify the exact information you need from the Web server as well as how it is to be retrieved. The syntax for a URL is as shown below: protocol://domain_name_or_IP:port/directory/filename The protocol portion of the URL specifies the protocol the browser will use to retrieve information. When accessing a Web server, you use either the HTTP or HTTPS protocol. The HTTP protocol transfers information from the Web server using unencrypted communications. This level of security may be acceptable for many Web pages, but the transfer of sensitive information requires transmissions to be encrypted. For sensitive information, such as credit card numbers or personal information, you should use the HTTPS protocol. HTTPS uses standard HTTP, but it also uses the Secure Socket Layer (SSL) protocol to encrypt the data before sending it. Only the sender and receiver have keys that can decrypt the information. After specifying the protocol in the URL, you next specify the domain name or IP address of the Web server you want to access. After the address, you can optionally specify the TCP port where the Web server is running. For example: http://www.digitalairlines.com:81 This tells the browser to access port 81 on www.digitalairlines.com. Web browsers default to port 80 if you don’t specify a port number in the URL. Therefore, a port number is required only if the service you are accessing is running on a port other than 80 (HTTP) or 443 (HTTPS). You can also specify the filename that you want to retrieve from the Web server by appending it to the end of the URL. For example: http://www.digitalairlines.com/index.html This parameter is optional. Web servers are usually configured such that if no filename is specified in the URL, it sends a filenamed index.html by default. If you want to request a specific file, however, you need to include it in the URL. In addition to delivering data to the Web browser, a Web server can perform tasks such as limiting access to specific Web pages, logging access to a file, and encrypting the connection between a server and browser.

Installing Apache Web Server To install Apache on your SLES 11 system, you need to install the following packages: 

226

apache2: Basic Web server software.


Version 1




apache2-prefork: Additional Apache package that influences the multiprocessing behavior of the Web server.



apache2-example-pages: Sample HTML pages.



apache2-doc: Apache Web server documentation.

The easiest way to do this is to run YaST, access the Software Management module, and install the Web and LAMP Server pattern. This is shown in the figure below: Figure 5-3

Installing Apache Web Server in YaST

When you install the Web and LAMP Server pattern, YaST automatically resolves dependencies for you and may prompt you to install one or more additional packages. If this is the case, be sure to install the additional packages by selecting Continue. After installing the required software, you need to start the Apache Server service on your SLES 11 system. You do this by opening a terminal window, switching to root, and then entering the following command at the shell prompt: rcapache2 start or /etc/init.d/apache2 start You can verify that Apache is running by entering one of the following at the shell prompt: rcapache2 status

Version 1


227






or /etc/init.d/apache2 status If you need to stop Apache, you can enter one of the following to stop the Web server: rcapache2 stop or /etc/init.d/apache2 stop If you want the Web server to start automatically every time the server is booted, enter the following at the shell prompt: insserv apache2 This command causes Apache to be automatically started at runlevels 3 and 5. To test the Web server after installation, open a Web browser on your SLES 11 server desktop and enter the following URL: http://localhost If Apache was installed correctly and the apache-example-pages package is installed, the browser should display the following page: Figure 5-4

Testing the Web Server

If your SLES 11 system is connected to the network, you can access the Web server remotely from other hosts by open a browser and then accessing the following URL: http://IP_address or DNS_name

228


Version 1


By default, Apaches stores the documents it serves in the document root /srv/ www/htdocs. After installing Apache, the document root contains the Apache example page shown above. The default files in the document root are shown below: Figure 5-5

Default Web Server Files

You can replace the files in the document root directory with your own Web server content. Simply create your own content and copy it to /srv/www/htdocs. However, be aware that the Apache daemon must have at least read access to your Web server content files. Apache runs as the wwwrun user on SLES 11. Therefore, you need to make sure that wwwrun has read access to the files in the document root directory., using the chmod command as needed. When creating your Web server content, you can create subdirectories within the document root. If you do, you can access those subdirectories by adding the name of the subdirectory to your URLs: http://server_address/subdirectory/ If a filename is not included in the URL, Apache looks for a file with the name index.html in the specified directory. NOTE: You can change the name of the default file in the Apache configuration files.

Using the Apache Configuration Files The Apache Web server is configured using a variety of configuration files located in /etc/apache2/. To configure the Apache Web server, you need to be familiar with the following:

Version 1



“Location of the Apache Configuration Files” on page 230



“Basic Rules for Apache Configuration Files” on page 230


229






Location of the Apache Configuration Files

The configuration of the Apache Web Server is spread among several configuration files located in the /etc/apache2/ directory. These files are shown below: Figure 5-6

Apache Web Server Configuration Files

The following are some of the more important Apache configuration files: 

httpd.conf: The main Apache configuration file.



default-server.conf: Contains the basic Web server configuration. However, options set in this file can be overwritten by options in other configuration files.



vhost.d/: Directory that contains configuration files for virtual hosts. You will learn more about virtual hosts later in this section.



uid.conf: Sets the user and group ID used by Apache. By default, Apache uses the wwwrun user and the www group.



listen.conf: Specifies the IP addresses and ports the Apache daemon is listening on. By default, Apache listens on all interfaces on port 80.



server-tuning.conf: Used to fine tune the performance of the Apache daemon. The default values in this file are usually appropriate for most installations. However, if your Web server must handle a large number of simultaneous requests, then you can adjust the values in this file to increase performance.



error.conf: Configures the behavior of Apache when a request cannot be handled correctly.



ssl-global.conf: Configures the encryption of connections with SSL.



/etc/sysconfig/apache2. This file contains variables that are used to create apache2 configuration files in /etc/apache2/sysconfig.d/.

Basic Rules for Apache Configuration Files

The options contained within the Apache configuration files are called directives. Directives are case insensitive, which means that “include” is interpreted the same as “Include,” but arguments to directives such as paths and filenames, are often case sensitive.

230


Version 1


Directives can be grouped so that they apply only to a specific Web server directory instead of the entire server. For example, in the following the directives are applied only to the /srv/www/htdocs directory: Options None AllowOverride None Order allow,deny Allow from all

Notice in this example that the directives are nested within the and tags, which limits their application to only the /srv/www/htdocs directory. You can use the # character to indicate comments in the configuration file. All lines starting with a # are ignored by the Apache daemon. Whenever you modify an Apache configuration file, you need to reload the Web server to have the change applied. This is done by entering the following command at the shell prompt (as root): rcapache2 reload This command forces the Apache daemon to reload its configuration files without stopping and restarting. Some changes, such as changing the port the server listens on, will require you to stop and restart the Apache daemon. This is done by entering the following command at the shell prompt (as root): rcapache2 restart After making changes to the Apache configuration files, you can verify that your modifications use the correct syntax by entering the following command at the shell prompt (as root): apache2ctl configtest If the syntax is correct, the command displays a “Syntax OK” message.

The Default Apache Configuration The default Apache Web server configuration is defined in the /etc/apache2/ default-server.conf file. A sample default-server.conf file is shown below: DocumentRoot "/srv/www/htdocs" Options None AllowOverride None Order allow,deny Allow from all Alias /icons/ "/usr/share/apache2/icons/" Options Indexes MultiViews AllowOverride None Order allow,deny

Version 1


231






Allow from all ScriptAlias /cgi-bin/ "/srv/www/cgi-bin/" AllowOverride None Options +ExecCGI -Includes Order allow,deny Allow from all UserDir public_html Include /etc/apache2/mod_userdir.conf #AliasMatch ^/users/([a-zA-Z0-9-_.]*)/?(.*) /home/$1/public_html/ $2 Include /etc/apache2/conf.d/*.conf Include /etc/apache2/conf.d/apache2-manual?conf

The following table provides an overview of some of the more important directives used in the default-server.conf file: Table 5-1

default-server.conf Directives Directive

Description

DocumentRoot

Specifies the document root directory used by the Web server.

/

All directives listed within this block apply only to the specified directory.

Options

With this directive additional options can be applied to logical blocks like directories.

AllowOverride

Determines whether directives are allowed to be overwritten by a configuration option found in a .htaccess file in a directory.

Alias “fakename” “realname”

Allows you to create an alias to a directory.

ScriptAlias

Allows you to create an alias to a directory containing scripts for dynamic content generation.

In most cases, the default settings in this file are suitable for most installations and don't need to be modified. The default-server.conf file that is installed by default contains comments that explain the respective entries. NOTE: An overview of all Apache directives can be found at (http://httpd.apache.org/docs/2.2/ mod/directives.html).

232


Version 1


Objective 2

Configure Virtual Hosts Now that you understand how to configure the default Apache Web server, you are ready to create virtual hosts. To use the virtual host feature of Apache, you need to do the following:  

“Understand Virtual Hosts” on page 233 “Configure a Virtual Host” on page 234

Understand Virtual Hosts In its default configuration, the Apache Web server can be reached from a browser using the following URLs: 

http://localhost (from the computer where the Web server is running)



http://web_server_IP_address



http://web_server_hostname

For all of these URLs, Apache serves the files located in the document root directory. This configuration works well for a basic Web server. However, Apache can also be configured to host multiple virtual Web servers on the same physical server system. These virtual Web servers are called virtual hosts. This allows you to host Web servers for multiple domains on the same system. For example, suppose your organization has its own domain: www.digitalairlines.com. In addition, your organization wants to allow local subsidiaries to present themselves with their own domain: 

www.ditigalairlines-slc.com



www.digitalairlines-la.com

Using just the basic Apache configuration, you would have to set up three separate servers to host the three domains. Fortunately, using virtual domains, you can set up a virtual host for each domain on the same server. Each domain is accessed using its domain name on port 80. To access a virtual host, a separate DNS entry is needed for every virtual host on the Apache Web server. The following outlines the steps of sending a request to the virtual host www.ditigalairlines-slc.com:

Version 1

1.

The Web browser requests the IP address of the host www.ditigalairlines-slc.com from a DNS server.

2.

The browser uses the IP address to request a file from the Apache Web server listening on the IP address of www.ditigalairlines-slc.com.

3.

In the HTTP request, the browser includes the host name of the server it wants to reach.

4.

Apache uses the host name to determine the corresponding virtual host and delivers the requested data from that host.


233






Configure a Virtual Host To create a virtual host, you need to create a configuration file in the /etc/ apache2/vhosts.d/ directory. The name of the configuration file has to end with .conf. You can use the vhost.template file in the /etc/apache2/vhosts.d/ directory as a template for your virtual host configuration file. You need to edit the following directives in the template: Table 5-2

Virtual Host Directives Directive

Description

ServerAdmin

Type the e-mail address of the virtual host system administrator here.

ServerName

Type the host name of the virtual host as it is configured in the DNS record.

DocumentRoot

Set the document root directory of the virtual host. The directory and the files in the directory must be readable by the wwwrun user.

ErrorLog

Type a filename for the error log.

CustomLog

Type a filename for the log file.

ScriptAlias

Set the ScriptAlias to a directory of your choice. The directory must not be under the DocumentRoot of the virtual host. If you don’t need scripts for dynamic content creation, delete this directive.

If you’ve set a ScriptAlias, you have to specify the directory which contains the script files. If you are not using a ScriptAlias, you can delete this directive.

You need to modify the pathname of this directive to your document root path.

After customizing the virtual host file, you need to reload the Apache daemon. You also need to make sure the DNS record for the domain has been updated so that the virtual host domain name resolves correctly. In addition to the above, you need to activate name-based virtual hosting in /etc/ apache2/listen.conf. Remove the comment sign in front of one the lines starting with NameVirtualHost, as shown in the following: ... # Use name-based virtual hosting # # - on a specified address / port: # #NameVirtualHost 12.34.56.78:80 # # - name-based virtual hosting: # #NameVirtualHost *:80

234


Version 1


# # - on all addresses and ports. This is your best bet when you are on # dynamically assigned IP addresses: # NameVirtualHost *

Version 1


235






Exercise 5-1

Configure a Virtual Host In this exercise, you configure a virtual host for the accounting department. You will find this exercise, in the workbook.

(End of Exercise)

236


Version 1


Objective 3

Limit Access to the Web Server By default, Apache allows Web server data access to all network hosts that can reach the server. This configuration is appropriate for public Web servers. However, there may be times when you need to restrict access to the content on the Web server to specific users or hosts. This can be done in two ways: 

“Limiting Access By Network Address” on page 237



“Requiring User Authentication” on page 238

Limiting Access By Network Address If you need to limit access to Web server content to specific network hosts, you can add directives to your configuration file that limit access based on a host’s IP address or domain name. You can use the following directives to limit access to the Web server based on host address: Table 5-3

Apache Configuration File Directives for Restricting Access Based on IP Address Directive

Description

allow

IP addresses or networks listed after this directive are allowed to access the Web server.

deny

IP addresses or networks listed after this directive are not allowed to access the Web server.

order

S This directive sets the order in which the allow and deny directives are evaluated.

These directives must be added within a block. This causes Apache to restrict access to all data in that directory as well as its subdirectories based on the parameters you supply. For example, suppose you wanted to restrict access to the data in the /srv/www/ htdocs directory on the Web server to hosts on the 10.0.0.0/24 network only. You could add the following directive: Order deny,allow Deny from all Allow from 10.0.0.0/24

The lines in the directive above do the following: 

Version 1

: Starts the directory block. The directives within the block apply only to the directory /srv/www/htdocs directory on the Web server.


237








Order deny,allow: Determines the order in which the allow and deny directives are evaluated. You have the following options: 





Deny,Allow: Deny directives are evaluated before the allow directives. Access is allowed by default. Any client which does not match a deny directive or does match an allow directive is allowed access to the server. Allow,Deny: Allow directives are evaluated before the deny directives. Access is denied by default. Any client which does not match an allow directive or does match a deny directive is denied access to the server.

Deny from all: Deny directive is evaluated first and, in this case, access is denied for all clients. You can use the following options with the deny and the allow directives:  

 





all: Applies to all hosts. A (partial) domain-name. Applies to hosts whose names match the given expression (such as novell.com). Only complete domain components are matched. For example, specifying novell.com would match www.novell.com but not foonovell.com. A full IP address: Applies to a specific IP address (such as 10.0.0.23). A partial IP address: Applies to IP addresses starting with the specified IP address fragment (such as 10.0.0). A network/netmask pair: Applies to IP addresses matching to the given network/netmask pair (such as 10.0.0.0/255.255.255.0) A network/CIDR specification: Applies to IP addresses matching to the given CIDR expression (such as 10.0.0.0/24).



Allow from 10.0.0.0/24: This allow directive is evaluated after the deny directive. In this case, hosts in the network 10.0.0.0/24 are allowed access.



: Ends the directory block.

Requiring User Authentication By limiting access to certain network addresses, you control the hosts that can access the Web server. However, you have no control over who is using the host. To rectify this, Apache also allows you to restrict access based on username. This is called basic authentication. Basic authentication requires users to log in before they can access the data on the Web server. Before you can configure Apache to use basic authentication, you first have to create user accounts for the Web server daemon. This is done using the htpasswd2 command line utility. The following command creates a password file for Apache to use named /etc/apache2/htpasswd and adds a new user account named tux. htpasswd2 -c /etc/apache2/htpasswd tux When you add a user to the htpasswd file for the first time, you have to call htpasswd2 with the -c option to initially create the file. You can use a different

238


Version 1


location for the password file, but you have to make sure that it’s readable by the wwwrun user. It also must not reside within the document root of the Web server. The htpasswd2 utility prompts you for a password for the user as you create the user account. If you want to add more users, use the following command: htpasswd2 /etc/apache2/htpasswd username To delete a user from the password file, use the following command: htpasswd2 -D /etc/apache2/htpasswd username After you have created your htpasswd file and added your user accounts, you next need to configure Apache to prompt for a password when accessing restricted data. To do this, you need to add the following lines to the block for the directory that you want to restrict: AuthType Basic AuthName "Restricted Files" AuthUserFile /etc/apache2/htpasswd Require user tux

The directives above do the following: 

AuthType Basic: Sets the authentication method, in this case to Basic authentication.



AuthName “Restricted Files”: Sets the name of the authorization realm for the directory. This realm is sent to the client so that the user knows which username and password to use. If the realm name contains spaces, it must be enclosed in quotation marks, as shown in the example above. It must also be accompanied by the AuthType, Require, and AuthUserFile directives.



AuthUserFile /etc/apache2/htpasswd: Specifies the password file used for the restricted directory.



Require user tux: Lists the users from the password file who are allowed to access the directory. You can add more than one user by separating the usernames with spaces, or you can use the following directive: Require valid-user This defines that any valid username in the password file is granted access.

NOTE: The password is transferred cleartext over the network. For critical applications, you should configure SSL encryption. This is discussed in the next objective.

Version 1


239






Exercise 5-2

Configure User Authentication In this exercise, you add user authentication to your virtual host. You will find this exercise in the workbook.

(End of Exercise)

240


Version 1


Objective 4

Configure Apache with OpenSSL By default, the connections between the Web browser and the Web server are not encrypted. All data is passed as clear text. Anyone running sniffer software can capture a copy of the network packets exchanged between browser and server, allowing them to view the transferred information. For public Web servers, this may be an acceptable situation. However, for Web sites that store sensitive information and require authentication, you should encrypt the communications between the browser and the server. The Apache daemon can be configured to use the Secure Socket Layer (SSL) protocol to encrypt the connection. To configure an SSL encryption with an Apache Web server, you need to be familiar with the following: 

“How SSL Encryption Works” on page 241



“Creating a Test Certificate” on page 243



“Configuring Apache to Use SSL” on page 245

How SSL Encryption Works SSL uses RSA keys to encrypt and decrypt data transmissions between the Apache server and client browsers. RSA is also used by other encryption software as well, such as Pretty Good Privacy (PGP) to encrypt e-mails and by Secure Shell (ssh) to encrypt data transfers between two computers. SSL encryption is based on the use of two different keys, called Public Key Cryptographic or Asymmetric Key Cryptography: 

Private key



Public key

With asymmetric encryption, the key used to encrypt data is different from the key used to decrypt it. The private key is known only to the owner, but the public key is freely distributed. Data is encrypted by the sender with the recipient’s public key and can be decrypted only with the associated private key.

Version 1


241






The following figure depicts the encryption process: Figure 5-7

Encrypting Data

Public key of the recipient

This is unencrypted text.

Recipient

Mtdte86led 8rklgBx34kl 6yPl0kUm23

This is unencrypted text.

Sender Private key of the recipient NOTE: Actually SSL is a bit more complex than described above, as the public/private key pair is not used to directly encrypt/decrypt the data sent, but to encrypt/decrypt another key that is used to encrypt/decrypt the transmitted data using a symmetric encryption algorithm.

In addition to encrypting and decrypting data, public and private keys can also be used to digitally sign data. When data is signed, an cryptographic checksum is generated from the data. The sender then signs the checksum with his private key. The signature can be checked by the recipient using the public key of the sender. This allows the recipient to determine whether the data is really from the sender. The recipient can also verify that the data has not been modified by a third party. The following illustrates the digital signing process: Figure 5-8

Digitally Signing Data

Private key of the sender

This is text..

Recipient

This is text.. Signature

Signature valid/ Signature invalid

Sender Public key of the sender

242


Version 1


Then encryption process described above works well; however, it has a weakness. How can you verify who owns the public key? In other words, can you really be sure the sender really is who they claim to be? The solution to this problem is to use a Certificate Authority (CA) as a trusted third party which signs the public keys with its own private keys. A public key that is signed by a CA is also called a certificate. You can set up your own CA or use a third-party CA. Examples of well-known thirdparty CAs include organizations such VeriSign and VISA. The public keys from these organizations are automatically installed into most popular Web browsers. By verifying the signature with the public key of the CA, the browser can verify that the public key from a Web server is valid. The following describes the process of using SSL encryption with a CA to secure Web server communications: 1.

The browser identifies a URL starting with https:// as a secure connection that should be encrypted. The default port for HTTPS connections is 443 instead of 80 (which is used for normal unencrypted HTTP connections).

2.

The Web browser asks the server for its public RSA key (certificate).

3.

The Web server sends the public key to the Web browser.

4.

The Web browser verifies the key from the server with the public key of the CA that signed the key.

5.

If the key is valid, the Web browser and Web server establish a secure connection.

You need an officially signed key to set up a secure Web server in this manner. You can, however, also set up your own CA and sign a certificate yourself. This can be a useful tool when testing a secure Web server. However, be aware that if you use a self-signed certificate, most Web browsers won’t recognize your CA. Users will have to manually add your CA to their list of trusted CAs. We recommend that you don’t use self-signed certificates in a production environment.

Creating a Test Certificate As mentioned above, however, self-signed certificates can be very useful for testing a secure Web site implementation. To create a test certificate, you need to complete the following tasks:

Version 1



“Create an RSA Key Pair” on page 244



“Sign the Public Key to Create a Certificate” on page 244


243






Create an RSA Key Pair

To create the key pair, you first need to create a file containing as many random numbers as possible. You can generate a file of this type from the shell prompt by entering the following command: cat /dev/random > /tmp/random Stop this procedure after a few minutes by pressing Ctrl+C. The file generated should be at least a thousand bytes in size. You can speed the gathering of random numbers by creating some activity on your computers, such as moving the mouse, starting and stopping programs, etc. You can now generate the key pair by entering the following command: openssl genrsa -des3 -out server.key -rand /tmp/random 2048 During the process, you are prompted to enter a password. This password is used to secure the private key of the key pair. The generated keys are saved together in the server.key file. Sign the Public Key to Create a Certificate

Next you need to sign your public key to create the certificate. This is done by entering the following command: openssl req -new -x509 -key server.key -out server.crt During the process, you are prompted for the following information: 

Enter pass phrase for server.key: Passphrase you chose for the server key.



Country Name (2 letter code) [AU]: Country code of your country (such as DE for Germany).



State or Province Name (full name) [Some-State]: State or province name. You can enter a period (.) to leave this field blank.



Locality Name (eg, city) []: Name of your city.



Organization Name (eg, company) [Internet Widgits Pty Ltd]: Name of your company.



Organizational Unit Name (eg, section) []: Name of your organizational unit. You can enter a period (.) to leave it blank.



Common Name (eg, YOUR name) []: Fully qualified domain name of your system (such as www.digitalairlines.com). The certificate will be valid for this host name only.



Email Address []: E-mail address of the administrator who is responsible for the server.

After you have answered all questions, the server certificate is saved into the server.crt file.

244


Version 1


Finally, copy the server.key and server.crt files to the following locations: 

server.key: /etc/apache2/ssl.key/ directory.



server.crt: /etc/apache2/ssl.crt/directory.

Configuring Apache to Use SSL After you have generated the RSA key pair and the server certificate, you next need to configure Apache to use SSL. First, you need to change two settings in the /etc/sysconfig/apache2 file. Set the following variables to the appropriate values: 

APACHE_START_TIMEOUT=”10”: Extends the start timeout of Apache so that you have more time to enter the passphrase of the private RSA key.



APACHE_SERVER_FLAGS=”SSL”: Additional server flag SSL, which defines the SSL variable when evaluating the Apache configuration files. This enables Apache to listen on port 443 as well as port 80.

You also need to modify the server configuration files to enable SSL. This can be accomplished by doing one of the following: 

“Configuring the Main Server to Use SSL Encryption” on page 245



“Configuring a Virtual Host to Use SSL Encryption” on page 246

Configuring the Main Server to Use SSL Encryption

To configure the main server to use SSL encryption, you need to add the following directives to the /etc/apache2/default-server.conf file (you can find these directives and detailed explanations in the /etc/apache2/vhosts.d/ vhost-ssl.template file): SSLEngine on SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL SSLCertificateFile /etc/apache2/ssl.crt/server.crt SSLCertificateKeyFile /etc/apache2/ssl.key/server.key

These directives do the following: 

SSLEngine on: Enables the Apache SSL engine.



SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+ EXP:+eNULL: Sets the details of the encryption method. The line displayed above is the default Apache configuration. NOTE: For more information about this directive, go to (http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslciphersuite).

Version 1


245








SSLCertificateFile /etc/apache2/ssl.crt/server.crt: Points to the server certificate file.



SSLCertificateKeyFile /etc/apache2/ssl.key/server.key: Points to the server key file.

After you make the above modifications, you need to restart Apache. When you do, the Apache daemon prompts you for the passphrase of the server key file. WARNING: The Apache server might not start up correctly at boot time in this configuration. This is because it requires the passphrase for the server key. If this happens, you should disable apache2 in all run levels and then start it manually after the system has booted.

Once done, you can access the Web server host via SSL by using the URL https:/ /server_address. Configuring a Virtual Host to Use SSL Encryption

You can also configure a virtual host to use SSL instead of the main server. To do this, add the directives described in “Configuring the Main Server to Use SSL Encryption” on page 245 to your virtual host configuration file. You also need to modify your virtual host definition to the following:

246


Version 1


Exercise 5-3

Configure SSL for a Virtual Host In this exercise, you add SSL encryption to a virtual host. You will find this exercise in the workbook.

(End of Exercise)

Version 1


247






Objective 5

Install PHP PHP is a very popular scripting language for Web applications. In this objective, you learn how to install PHP on SLES 11. The following topics are addressed: 

“How PHP Works” on page 248



“Installing PHP” on page 249



“Testing the PHP Installation” on page 250

How PHP Works PHP is a scripting language used in conjunction with the Apache Web server. it accepts PHP code as its input and uses it to output HTML documents. Because of the way it operates, PHP is considered a server-side scripting language, meaning the processing of the script is done by the server running the Web server, not the client Web browser. To install a PHP Web application, the script files need to be copied into the document root of the Web server. PHP files usually have an extension of .php. A PHP application can be started by accessing the PHP file with an ULR such as http://www.mydomain.com/application.php. The Web server then opens the PHP file. However, instead of sending it directly to the browser, it is passed through the PHP interpreter first. The PHP interpreter runs the PHP script in the file and passes the dynamically generated HTML output through the Web server to the browser. The end user never sees the PHP application code. The PHP interpreter is implemented as an Apache extension module. You can also run PHP applications directly via CGI, but this is not covered in this course. The following is an overview of the PHP architecture: Figure 5-9

248

PHP Framework


Version 1


Installing PHP On SLES 11, the PHP components are split into several software packages. You need at least the following packages for a basic PHP Web application server: 

PHP5: Core PHP interpreter and libraries.



apache2_mod_php5: PHP module for Apache.

If you search for php in YaST’s Software Management module, you’ll notice that there are many more PHP packages available, as shown below: Figure 5-10

PHP Packages

These modules extend the functionality of PHP. Which packages you need depends on the requirements of the PHP application you would like to run. The PHP interpreter has several configuration options that can be adjusted in the / etc/php5/apache2/php.ini file. However, the default configuration should be used in most situations. The following are a few of the options available in this file: 

Version 1

memory_limit: Defines how much memory a script is allowed to use. For complex applications, this might need to be set to a higher value. The default is 8 MB.


249








max_execution_time: Sets the maximum execution time, in seconds. Complex applications sometimes need a longer execution time. The default is 30 seconds.



display_errors: Determines whether errors or warning messages are displayed in the HTML output. For production systems, this option should be set to Off, while on a development system it is useful to set it to On. The default is Off.

After installing PHP packages, you have to restart Apache with the rcapache2 restart command.

Testing the PHP Installation A PHP installation can be easily tested by creating a file somewhere in the document root of the Web server with the following content:

This content is a simple PHP application. Calling the phpinfo() function outputs a Web page with information on the PHP installation. When you request this file in a Web browser, a page similar to the following is displayed: Figure 5-11

250

Testing the PHP Server


Version 1


Exercise 5-4

Install PHP In this exercise, you install and test PHP on SLES 11. You will find the exercise in the workbook. (End of Exercise)

Version 1


251






Summary Objective

Summary

Set up a Basic Web Server with Apache

Web servers provide much of the functionality we associate with the Internet today. A Web server’s job is to send Web pages, graphics, and other files to clients requesting them. A Web server can transfer just about any type of file between the server and the client. However, the most common type of file used with a Web server are Hyper-Text Markup Language (HTML) documents. An HTML document is a text file written using HTML mark-up coding that instructs the Web browser how the information should be formatted and displayed. The easiest way to install Apache2 is to run YaST and install the Web and LAMP Server pattern.

Configure Virtual Hosts

Apache can be configured to host multiple virtual Web servers on the same physical server system. These virtual Web servers are called virtual hosts. To create a virtual host, you need to create a configuration file in the /etc/apache2/ vhosts.d/ directory. The name of the configuration file has to end with .conf. You can use the vhost.template file in the / etc/apache2/vhosts.d/ directory as a template for your virtual host configuration file.

Limit Access to the Web Server

By default, Apache allows access to Web server data to all network hosts that can reach the server. This configuration is appropriate for public Web servers. However, there may be times when you need to restrict access to the content on the Web server to specific users or hosts. This can be done in two ways:

252



Limiting access by network address



Requiring user authentication


Version 1


Objective

Summary

Configure Apache with OpenSSL

By default, the connection between the Web browser and the Web server are not encrypted. All data is passed clear text. Anyone running sniffer software can capture a copy of the network packets exchanged between browser and server, allowing them to view the transferred information. For Web sites that store sensitive information and require authentication, you should encrypt the communications between the browser and the server. The Apache daemon can be configured to use the Secure Socket Layer (SSL) protocol to encrypt the connection. To configure an SSL encryption with an Apache Web server, you need to be familiar with the following:

Install PHP



How SSL encryption works



Creating a test certificate



Configuring Apache to use SSL

PHP is a scripting language used in conjunction with the Apache Web server. It accepts PHP code as its input and outputs HTML documents. To install a PHP Web application, the script files need to be copied into the document root of the Web server. PHP files usually have an extension of .php. A PHP application can be started by accessing the PHP file in a ULR, such as http://www.mydomain.com/ application.php. The Web server then opens the PHP file. However, instead of sending it directly to the browser, it is passed through the PHP interpreter first. The PHP interpreter runs the PHP script in the file and passes the dynamically generated HTML output through the Web server to the browser. You need to install at least the following packages for a basic PHP Web application server:  

Version 1

PHP5 apache2_mod_php5


253






254


Version 1


SECTION 6


IPv6 (Internet Protocol Version 6) was designed by the Internet Engineering Task Force (IETF) to replace the current Internet Protocol version, IPv4. IPv6 not only overcomes the most obvious shortcoming of IPv4, the imminent shortage of available IP addresses, but also adds improvements in other areas, like routing and network autoconfiguration. This section explains IPv6 and its configuration on SUSE Linux Enterprise Server 11. Objectives

Version 1

1.

“Understand IPv6 Theory” on page 256

2.

“Configure IPv6 on SLE 11” on page 261


255






Objective 1

Understand IPv6 Theory During recent years, the end of IPv4 has often been predicted, but IPv4 has proven remarkably resilient. The use of private address ranges within private and company networks made it possible to use the remaining IPv4 addresses in a more efficient manner, and classless interdomain routing (CIDR) helped to slow the growth of the size of routing tables. However, as more and more devices become able to connect to the internet, the limitations of IPv4 become more and more relevant. It is not a question of if the shift to IPv6 has to happen, it is only a question of when. Within the context of IPv6, you need to understand: 

“IPv6 Features” on page 256



“IPv6 Addresses” on page 256



“IPv6 Address Types” on page 257

IPv6 Features IPv6 addresses the shortcomings of IPv4 with features that include the following: 

Increased address space. In IPv4, an IP address is 32 bits long, which is allows up to about four Billion addresses. In IPv6, an IP address is 128 bits long, which allows for a really huge number of addresses: 340,282,366,920,938,463,463,374,607,431,768,211,456 (or 3.4 * 1038 or, in the US system, 340 undecillions). To give you some idea of what this number means, it in theory allows about 650 * 1021 addresses for every square meter of the surface of earth. For practical purposes, as not every address will be used for hosts, certainly more than 1,500 addresses remain for every square meter of earth’s surface.



Improvements in routing capabilities.



Simplified header.



Quality of Service (QoS) capabilities.



Authentication and privacy capabilities.



Flexible transition from IPv4 to IPv6 over a longer period of time.

IPv6 Addresses IPv6 addresses consist of 128 zeroes and ones, which is very unwieldy for humans. To make them somewhat easier to deal with, they are represented in hexadecimal format, with four bits (a “nibble”) represented by digits or characters from 0-9 and af (10-15). To improve readability, a colon is inserted after every four hexadecimal values (representing 16 bits): ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff

A possible address could look like the following:

256


Version 1


fe80:0000:0000:0000:0211:11ff:fec2:35f4

For simplification, leading zeroes in each block can be omitted, and one sequence of 16 bit blocks containing only zeroes can be replaced by “::”. The above address could, therefore, be written as follows: fe80::211:11ff:fec2:35f4

As another example, the localhost address 0000:0000:0000:0000:0000:0000:0000:0001

can be shortened to ::1

IPv6 Address Types IPv6 addresses can serve different purposes, such as multicast or unicast addresses. Different leading bits, such as fe80 in one of the examples above, indicate different types of addresses. One interface can have more than one IPv6 address. Similar to IPv4 addresses, IPv6 addresses can be split into network and host parts using subnet masks. The notation is similar to the CIDR notation used with IPv4: fe80::211:11ff:fec2:35f4/64

The corresponding network address is fe80:0000:0000:0000:0000:0000:0000:0000

with a netmask of: ffff:ffff:ffff:ffff:0000:0000:0000:0000

To be able to differentiate the different IPv6 address types, you need to understand the following: 

“Addresses without a Specific Network Prefix” on page 257



“Network Addresses” on page 258



“Host Addresses” on page 259

Addresses without a Specific Network Prefix

Addresses without a specific network prefix comprise the following: 

“Localhost” on page 257



“Unspecified Address” on page 258

Localhost

The address for the loopback interface, similar to 127.0.0.1 in IPv4, is 0000:0000:0000:0000:0000:0000:0000:0001

Version 1


257






Packets with this address as source or destination are not supposed to leave the machine. Unspecified Address

This is the IPv6 equivalent to 0.0.0.0 (or “any”) in IPv4: 0000:0000:0000:0000:0000:0000:0000:0000

or in short: ::

This address is, for instance, seen in the output of netstat: da10:~ # netstat -atun Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address tcp 0 0 :::80 :::* tcp 0 0 :::22 :::*

State LISTEN LISTEN

The third colon in the output above separates the address from the port number. Network Addresses

The network addresses are used to distinguish the following categories: 

“Link Local Addresses” on page 258



“Globally Unique Local IPv6 Unicast Addresses” on page 258



“Global Address Type “global unicast”” on page 259

Link Local Addresses

Link local addresses are valid only on a link of an interface. A packet with a link local address would not pass a router. They begin with the following (x is any hex character, but usually “0”): fe8x fe9x feax febx

(this is the only one currently in use)

Such an address can be found on each IPv6-enabled interface after stateless autoconfiguration. It is used for link communications, for instance, to find out if anyone else is on this link or to locate a router. Globally Unique Local IPv6 Unicast Addresses

This address type begins with fdxx. (It could also begin with fcxx, but currently this prefix is not used.) A part of the prefix (40 bits) is generated using a pseudo-random algorithm (described in RFC 4193). While it is not impossible that two generated prefixes are

258


Version 1


equal, it is improbable. Therefore, connecting networks that were formerly independent is not likely to cause problems, as their prefixes will be different. The Global ID is followed by a 16-bit Subnet ID as an identifier within a site. The following illustration, taken from RFC 4193, shows the different parts of a globally unique local IPv6 Unicast address: | 7 bits |1| 40 bits | 16 bits | 64 bits | +--------+-+------------+-----------+--------------------+ | Prefix |L| Global ID | Subnet ID | Interface ID | +--------+-+------------+-----------+--------------------+ NOTE: There used to be a site local address type, starting with fecx, fedx, feex, or fefx. However, its use is deprecated in RFC 3879 and it is replaced by the above.

Global Address Type “global unicast”

Addresses delegated to Internet Service Providers (ISP) currently begin with 2001:

The following addresses are reserved for examples and documentations and should be filtered on border routers to the Internet: 3fff:ffff::/32 2001:0DB8::/32

Addresses for tunneling IPv6 packets in IPv4 packets begin with 2002:

Multicast addresses start with ffxy, where x is hex number and y indicates the scope (such as y=1: node local, y=2: link local, y=3: site local). Depending on the host part of the address, different multicast types are addressed (RFC 4291 / IP Version 6 Addressing Architecture): 

All Nodes Address: 1. Addresses all hosts on the local node (ff01:0:0:0:0:0:0:1) or the connected link (ff02:0:0:0:0:0:0:1).



All Routers Address: 2. Addresses all routers on the local node (ff01:0:0:0:0:0:0:2), the connected link (ff02:0:0:0:0:0:0:2), or the local site (ff05:0:0:0:0:0:0:2).

There are other types, like anycast addresses, that are not covered in this course. Host Addresses

The host address can be automatically computed or set manually.

Version 1



“Automatically Computed Host Address” on page 260



“Manually Set Host Address” on page 260


259






Automatically Computed Host Address

When automatically computed, the MAC address is used and expanded according to the IEEE-Tutorial Extended Unique Identifier EUI-64 (http://standards.ieee.org/ regauth/oui/tutorials/EUI64.html). For instance, with a MAC address of 00:11:11:C2:35:D4, the resulting 64-bit interface identifier is 0211:11ff:fec2:35d4. Together with a network prefix (for instance, one used for Globally Unique Local IPv6 Unicast Addresses), the following IPv6 address results: fd7b:5c7e:40bf:1234:0211:11ff:fec2:35d4 NOTE: The above way of creating the interface identifier has some privacy implications, especially for mobile devices. When connecting to the Internet using different providers, the network part of the address changes, while the interface identifier remains the same. This can allow tracking of the mobile device. RFC 4941 describes ways to mitigate this issue.

Manually Set Host Address

Simpler addresses might be easier to remember and, for instance, for some servers you might want such an address. It is possible to assign an additional address to the interface, such as fd7b:5c7e:40bf:1234::1

In the automatically generally set address, the seventh most significant bit (with the count starting with 1) of the host address is set to 1 when calculating the automatic address. It is required to set this bit to 0 when setting a host address manually. The reason for this is, first of all, convenience, as otherwise the above address would be fd7b:5c7e:40bf:1234:0200::1

instead of fd7b:5c7e:40bf:1234::1

Also some other bit combinations are reserved for anycast addresses, such as all host bits set to 0 for the subnet router. NOTE: The Linux IPv6 HOWTO (http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/) contains a lot more information on IPv6.

260


Version 1


Objective 2

Configure IPv6 on SLE 11 From the kernel to various applications, SLES 11 and SLED 11 support IPv6. To configure IPv6 on SLE 11, you need to understand the following: 

“IPv6 Autoconfiguration” on page 261



“Setting an IPv6 Address Using YaST” on page 262



“Managing IPv6 Addresses Using the Command Line Tools” on page 265



“Connecting to Other IPv6 Addresses” on page 265

IPv6 Autoconfiguration One design goal of IPv6 was to make IP autoconfiguration easier. Even without a DHCP server, interfaces can obtain a valid IP address. In the context of IPv6 autoconfiguration, you need to understand the following: 

“Link Local Autoconfiguration” on page 261



“Stateless Autoconfiguration” on page 262

Link Local Autoconfiguration

By default, a link local address is configured automatically for every network interface in SLE 11: da10:~ # ip address show dev eth0 2: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 100 link/ether 00:19:d1:9f:17:f4 brd ff:ff:ff:ff:ff:ff inet6 fe80::219:d1ff:fe9f:17f4/64 scope link valid_lft forever preferred_lft forever

You can use this address to test the link using ping6: da10:~ # ping6 -I eth0 fe80::219:d1ff:fe9f:1787 PING fe80::219:d1ff:fe9f:1787(fe80::219:d1ff:fe9f:1787) from fe80::219:d1ff:fe9f:17f4 eth0: 56 data bytes 64 bytes from fe80::219:d1ff:fe9f:1787: icmp_seq=1 ttl=64 time=5.47 ms

When pinging a link local address, the option -I interface is required, as every interface has a link local address and the kernel doesn’t know which one to use.

Version 1


261






You can detect IPv6 active hosts by using ping6 to the link local, all-node multicast address: da10:~ # ping6 -I eth0 ff02::1 PING ff02::1(ff02::1) from fe80::219:d1ff:fe9f:17f4 eth0: 56 data bytes 64 bytes from fe80::219:d1ff:fe9f:17f4: icmp_seq=1 ttl=64 time=0.020 ms 64 bytes from fe80::219:d1ff:fe9f:1787: icmp_seq=1 ttl=64 time=5.09 ms (DUP!)

Unlike in IPv4, where replies to a ping to the broadcast address can be disabled using the /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts file, this behavior cannot be disabled currently in IPv6, except by local IPv6 firewalling. Stateless Autoconfiguration

To access the Internet, a host needs an IPv6 address with global scope. The steps to obtain such an address are as follows: 1.

Using its link-local address, the host sends a Solicitation Message to the ff02::2 multicast address (all routers on the local link), asking for an IPv6 prefix.

2.

The router answers this Solicitation Message with an Advertisement Message containing an address prefix for this network.

3.

Using this prefix and its MAC address, the host creates an IPv6 address.

4.

Using Duplicate Address Detection (DAD, RFC 4862), the host checks if the address is already in use in the network. If the address is unused, the host assigns the address to the NIC and activates it.

5.

The client can now contact other hosts within the local network using their IPv6 addresses and, depending on the network topology, hosts outside the local network as well.

The router distributes the network prefix and information on the default route only. Information that goes beyond this, such as information on DNS or other routes, needs to be added manually to the configuration or distributed using DHCP6.

262


Version 1


Setting an IPv6 Address Using YaST To set an IPv6 address manually (which is necessary, for instance, on a router), you use the same dialog in YaST that is used to set IPv4 addresses. The following shows the dialog that appears during installation: Figure 6-1

Network Card Setup

Type the IPv6 address in its usual format and the netmask in the CIDR notation, such as /64, as shown in the figure above.

Version 1


263






Select Next. The data you typed appears in the Network Settings Overview: Network Settings Overview

Click OK to close the dialog. YaST writes the configuration information to files in / etc/sysconfig/network/, such as the ifcfg-eth0 file. After installation, you can reach the same dialogs by selecting Computer > YaST > Network Devices > Network Settings. The settings are written to the /etc/sysconfig/network/ifcfg-ethx file, as shown below: BOOTPROTO='static' BROADCAST='' ETHTOOL_OPTIONS='' IPADDR='fd7b:5c7e:40bf:1234::2/64' MTU='' NAME='82566DM Gigabit Network Connection' NETWORK='' REMOTE_IPADDR='' STARTMODE='auto' USERCONTROL='no' NETMASK=''

264


Version 1


Managing IPv6 Addresses Using the Command Line Tools The ip command can be used for both, IPv4 and IPv6 addresses. The following examples demonstrate the use of the ip command for IPv6. Use the following command to add an IPv6 address: da10:~ # ip -6 addr add fd7b:5c7e:40bf:1234::2/64

dev eth0

The current configuration is displayed using the ip address show command (address and show can be shortened to their first letter). Adding the option -6 limits the output to IPv6 addresses: da10:~ # ip -6 a s 2: eth0: mtu 1500 qlen 100 inet6 fd7b:5c7e:40bf:1234::2/64 scope global valid_lft forever preferred_lft forever inet6 fe80::219:d1ff:fe9f:17f4/64 scope link valid_lft forever preferred_lft forever

To delete an address, use ip address delete: da10:~ # ip -6 add del fd7b:5c7e:40bf:1234::2/64

dev eth0

The ip command is also used to view, set, and delete routes. ip -6 route show displays the current routing table: da10:~ # ip -6 ro sh dev eth0 fd7b:5c7e:40bf:1234::/64 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295

Connecting to Other IPv6 Addresses If your Internet Service Provider (ISP) supplies you with an IPv4 as well as an IPv6 address, you can connect to both worlds without problems. If you get an IPv4 address only, there are two possible approaches to connect to IPv6 addresses: 

“6to4-Tunneling” on page 265



“6in4-Tunneling” on page 270

6to4-Tunneling

At the time of this writing, ISPs do not yet provide IPv6 addresses as a general practice. However, as one of the design goals of IPv6 was to make a smooth transition from IPv4 to IPv6 possible, you start using IPv6 immediately even if you get only an IPv4 address from your ISP.

Version 1


265






Following the method outlined in RFC 3056, a site with a globally unique IPv4 address can be assigned a globally unique IPv6 address based on its IPv4 address. This is considered an interim solution until the ISP assigns a native IPv6 prefix. IPv6 addresses used for this purpose have the following format (taken from RFC 3056): | 3 | 13 | 32 | 16 | 64 bits | +---+------+-----------+--------+--------------------+ |FP | TLA |IPv4 Addr | SLA ID | Interface ID | |001|0x0002| | | | +---+------+-----------+--------+--------------------+

All such addresses, therefore, start with 2002. The abbreviations used above have the following meaning: 

FP: Format prefix



TLA: Top level aggregator



IPv4 Addr: Globally unique IPv4 address (converted to Hex format)



SLA ID: Site level aggregator ID

The other end of the tunnel needs to be capable of dealing with the packets—taking the IPv6 packet out of the IPv4 packet and then routing it within the IPv6 network. To facilitate the use of IPv6, the IPv4 anycast address 192.88.99.1 is used to reach the nearest 6to4 relay router. Depending on your network topology, you need to do one of the following:

266



“Configure a 6to4 Tunnel on a Host” on page 267



“Connect the Network behind your 6to4 Gateway” on page 268



“Install and Configure radvd” on page 268



“Add a Route to Your 6to4 Gateway” on page 269


Version 1


Configure a 6to4 Tunnel on a Host

Assuming a unique IPv4 address of 1.2.3.4, the steps to configure a 6to4 tunnel are as follows: 1.

Make sure there is a sit0 device visible in the output of ip link show; if not, load the sit kernel module:

da10:~ # ip link show 1: lo: mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:11:11:c2:35:f4 brd ff:ff:ff:ff:ff:ff da10:~ # modprobe sit da10:~ # ip link show 1: lo: mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:11:11:c2:35:f4 brd ff:ff:ff:ff:ff:ff 3: sit0: mtu 1480 qdisc noop link/sit 0.0.0.0 brd 0.0.0.0 2.

Calculate the IPv6 address corresponding to your IPv4 address. The following command can be used:

da10:~ # ipv4="1.2.3.4"; printf \ "2002:%02x%02x:%02x%02x::1" ècho $ipv4 | tr "." " "` 2002:0102:0304::1 3.

Create a new tunnel device. In the example below it is called tun6to4, but you could use some other name for it as well:

da10:~ # ip tunnel add tun6to4 mode sit ttl 63 remote any \ local 1.2.3.4 4.

Bring the interface up and set the MTU:

da10:~ # ip link set dev tun6to4 mtu 1280 up 5.

Add your local IPv6 address to the tunnel interface using a prefix length of 16:

da10:~ # ip -6 addr add 2002:0102:0304::1/16 dev tun6to4

Version 1


267






6.

Add a route to the global IPv6 network using the IPv4 anycast address for all 6to4 routers:

da10:~ # ip -6 route add 2000::/3 via ::192.88.99.1 dev tun6to4 7.

Test the connection using ping6 to an IPv6-enabled site. (http://www.ipv6.org/) has a link to a list with such sites. (At the time of this writing www.ipv6.org itself also has an IPv6 address.)

Connect the Network behind your 6to4 Gateway

If you have a second NIC on your host acting as your 6to4 gateway and want to IPv6enable the network connected to that NIC, there are a few additional steps you need to take. 

Install and Configure radvd



Add a Route to Your 6to4 Gateway

Install and Configure radvd

When connecting a network to the second NIC of your 6to4 gateway, that host takes the function of a router. The Router Advertisement Daemon radvd distributes the autoconfiguration information the clients need to configure their IPv6 addresses automatically. The Router Advertisement Daemon is contained in the radvd package, which can be installed with the command yast -i radvd. Its configuration is contained in the /etc/radvd.conf file and looks similar to the following: interface eth0 { AdvSendAdvert on; # # # #

These settings cause advertisements to be sent every 3-10 seconds. This range is good for 6to4 with a dynamic IPv4 address, but can be greatly increased when not using 6to4 prefixes. MinRtrAdvInterval 3; MaxRtrAdvInterval 10;

# # # # #

You can use AdvDefaultPreference setting to advertise the preference of the router for the purposes of default router determination. NOTE: This feature is still being specified and is not widely supported! AdvDefaultPreference low;

# Disable Mobile IPv6 support # AdvHomeAgentFlag off; # example of a standard prefix #

268


Version 1


prefix 2002:0102:0304:1234:/64 { AdvOnLink on; AdvAutonomous on; AdvRouterAddr off; }; };

The above example is suitable for a fixed IPv4 address. The configuration file that is contained in the radvd package also includes an example on how to deal with dynamic IP addresses that change every time a new connection is established with the ISP. Before starting radvd, it is necessary to turn on IPv6 forwarding. This is done with the following command: da10:~ # echo 1 > /proc/sys/net/ipv6/conf/all/forwarding

If you want IPv6 forwarding to be turned on every time the system boots, set the variable IPV6_FORWARD in the /etc/sysconfig/sysctl file to yes: ## Type: yesno ## Default: no # # Runtime-configurable parameter: forward IPv6 packets. # IPV6_FORWARD="yes"

After IPv6 forwarding is turned on, you can start radvd using the command rcradvd start. Add a Route to Your 6to4 Gateway

For packets to be routed properly, the following route has to be set on your gateway host: da10:~ # ip -6 route add 2002:0102:0304:1234:/64 dev eth0

1234 in the above command (and in the radvd.conf file) is the site level aggregator; you can choose this according to your local networking needs. NOTE: After the above steps are complete, all machines in your network can access IPv6 hosts in the Internet and all machines in your network are accessible from the Internet using IPv6. You should set appropriate ip6tables filter rules to prevent attacks on the hosts within your network.

In case you are connected to the Internet using a DSL connection, edit the /etc/ radvd.conf file according to the comments in that file that cover dynamic Internet connections.

Version 1


269






When using DSL, you can include the commands to set up the 6to4 tunnel in the /etc/ ppp/ip-up.local file: # /etc/ppp/ip-up.local # Build IPv6 Tunnel /sbin/modprobe sit # $4 contains the local IP on the ppp interface. /sbin/ip tunnel add tun6to4 mode sit ttl 63 remote any \ local $4 /sbin/ip link set dev tun6to4 mtu 1280 up # $4 contains the local IP on the ppp interface. /sbin/ip -6 addr add $(printf \ "2002:%02x%02x:%02x%02x::1/16" ècho $4 | tr "." " "`) \ dev tun6to4 /sbin/ip -6 route add 2000::/3 via ::192.88.99.1 dev \ tun6to4 # Reload Router Advertisement Daemon to make it advertise # the new prefix. /usr/sbin/rcradvd reload # Set IPv6 route accordingly. ip -6 route add $(printf "2002:%02x%02x:%02x%02x:1234::/64" ècho $4 | tr "." " "`) dev eth0

The /etc/ppp/ip-down.local file would include the commands to take the tunnel down when the DSL connection is disconnected: # /etc/ppp/ip-down.local # Take down the tun6to4 tunnel /sbin/ip -6 route flush dev tun6to4 /sbin/ip link set dev tun6to4 down /sbin/ip tunnel del tun6to4

6in4-Tunneling

Another approach to access IPv6-based Internet hosts is to enlist the services of a tunnel broker. In this case, a point-to-point connection is established to the IPv6 network using an IPv4 UDP-based tunnel. The advantages of this method are that no unique IPv4 address is required and it works from behind a NAT gateway as well. A nonprofit provider that offers IPv6 tunnels and the needed software for various operating systems including Linux to interested end users is http://www.sixxs.net/ (http://www.sixxs.net/). There are certainly other providers that offer a similar service. 6in4 tunneling is not covered in this course. Before you use it, make sure that you have the agreement of your network administrator, as building tunnels through firewalls often violates existing security policy.

270


Version 1


Exercise 6-1

Configure IPv6 In this exercise, you configure and use different aspects of IPv6. You will find this exercise in the workbook.

(End of Exercise)

Version 1


271






Summary Objective

Summary

Understand IPv6 Theory

IPv6 addresses are 128 bits long. Depending on the network prefix, different kinds of address types exist, such as link local or global unicast addresses. The host part of the address can be set automatically, using the MAC address of the NIC, or manually.

Configure IPv6 on SLE 11

SLE 11 supports IPv6. In a private network, radvd allows easy assignment of IPv6 addresses. Even if your ISP does not assign you a native IPv6 address, 6to4 tunneling allows you to access IPv6 addresses.

272


Version 1


SECTION 7


In this section, you learn to analyze performance on a SUSE Linux Enterprise Server 11 system and what you can do to prevent bottlenecks. Because of the complexity of today's IT systems and infrastructure, performance bottlenecks are sometimes not easy to find. All components interact with each other, and different kinds of server types require different measures to improve system performance. In this section, you learn about monitoring utilities that help you find the component having performance problems. You also get some tips for solving performance problems. Remember that the solutions for your problems need to be based on the result of your performance analysis and depend on your system type. No matter what measures you choose, make sure that all changes are well tested before you enable them on the actual production system. Changes to the kernel parameters need to be tested very carefully. Objectives

Version 1

1.

“Find Performance Bottlenecks” on page 274

2.

“Reduce System and Memory Load ” on page 286

3.

“Optimize the Storage System” on page 291

4.

“Tune the Network Performance” on page 296


273






Objective 1

Find Performance Bottlenecks If you need to tune system performance, it is usually because the system is somehow too slow. Before you make any changes, you need to identify the bottleneck that is causing the performance problem. Complaints from users or customers about a slow system are normally of a general character and do not provide detailed information about the cause of a problem. Before you start to troubleshoot a system, you should ask for more information to gain a better overview of the situation. The following is a list of questions that can help you to find the performance bottleneck: 

What kind of server is affected? This includes information about the hardware and the purpose of the server.



What are the exact symptoms of the problem? The more information you have, the more likely you are able to determine the cause of the problem.



Does the problem occur at specific times of the day or the week? For example, performance problems might occur in the morning when people start to work or after lunch when people return to work.



When and how did the problem start? Did the problem occur quickly or slowly over several days or months?



Who is experiencing the problems? Does just one person have the problem or is it a group of people who are using the same file server?



Can the problem be reproduced? This can be very helpful when you are analyzing the system.

When you have gathered enough information, you can start to analyze the system by doing the following; 

“Analyze Processes and Processor Utilization” on page 274



“Analyze Memory Utilization and Performance” on page 275



“Analyze Storage Performance” on page 278



“Analyze Network Utilization and Performance” on page 281

Analyze Processes and Processor Utilization When you have a performance problem, you should look at the processor utilization first. If the processor is not fast enough to run all of your applications at a reasonable speed, this is the bottleneck you have to work on. One way to measure processor utilization is the system load. The load value can be displayed with various monitoring tools such as top or uptime. On a multiprocessing operating system like Linux, multiple processes can run virtually simultaneously. Since one processor can run only one process at a time, the Linux kernel splits the available processing time of a CPU into short slices that are assigned to the running processes.

274


Version 1


To assign the CPU time, the kernel puts the running processes into a queue. Depending on the priority of a process and the time since it was executed last, the kernel decides which process should be executed next. The load value is the average number of waiting processes in the process queue in a specific amount of time. Therefore, programs like top or uptime display load values for the last 1, 5, and 15 minutes. On a system with a single processor, an average load value of 1 means that the full processing capacity is used by applications and the operating system. If the value is lower than 1, some capacity is not used. If the average value is higher than 1, the processor is not fast enough to handle all currently running processes. NOTE: On a multiprocessor system, the load value can be higher. As a rule of thumb, the load value should not be higher than the number of processors installed in the system.

A process that is started on a system does not always require CPU time. Depending on the kind of process it is running, the CPU spends quite a lot of time to waiting for I/O processes to be finished. For example, an I/O process can be user input or data that is read from or written to disk. During these times, the processes are not waiting in the kernel's process queue and do not influence the load value of a system. This means that an application can be slow, but CPU time is not the reason for it. The following is a list of monitoring utilities that can be used to display the current CPU utilization and the average load values: Table 7-1

Monitor CPU Utilization Program

Description

Gnome System Monitor

Displays a graphical representation of the system load.

mpstat

Can be used to display the utilization of each installed processor on multiprocessor systems.

KDE System Guard

Displays a graphical representation of the system load.

top

Displays a sorted list of applications and the three values for the average load values in the last 1, 5, and 15 minutes. When you find that your system has a high load value, top can also be very helpful to find out which application is actually producing it.

uptime

Can also be used to display the system load in the last 1, 5, and 15 minutes.

Analyze Memory Utilization and Performance Another bottleneck for system performance can be caused by system memory. Applications have to be loaded into memory before they can be executed by the CPU.

Version 1


275






The memory is also used by the Linux kernel itself and for caching I/O operations like network or storage access. Memory is controlled by the memory management system of the Linux kernel. Every application has to ask the kernel to allocate memory, and every application is allowed to write only into its own memory space. There are two different kinds of memory available on a Linux system: 

Physical (random access): Memory that is actually installed in the system in the form of memory bars or chips. Access to this kind of memory is usually very fast.



Swap (virtual): A Linux system should have access to at least one swap partition. The space on this partition is used to free parts of the physical memory by copying temporarily unused memory pages. Access to swap memory is very slow compared to physical memory.

You can view the utilization of the physical and swap memory with the free command. The output looks like the following: da10:~ # free total used Mem: 1916464 1060988 -/+ buffers/cache: 237568 Swap: 2104472 0

free 855476 1678896 2104472

shared 0

buffers 44924

cached 778496

The output contains a headline with three lines of information: 

Mem: Contains information about the physical memory: 



used: Amount of memory that is used for applications cached data.



free: Memory that is not used and available at the moment.





total: Total amount of available physical memory, in KBs. The number is lower than the installed physical memory, since the kernel itself uses a small part of the memory.

Shared/buffers/cached: More detailed information about how the memory is used.

-/+ buffers/cache: Some of the memory on a Linux system is used to cache data for applications or devices. Parts of this memory can be freed when it is needed for other purposes. The free column displays the buffer adjusted line, which shows the memory that would be used and available if the buffer and the cache were freed.



Swap: Shows informations about the utilization of the swap memory. The information includes the amount of total, used, and free available memory.

As accessing the hard disk is much slower than accessing physical memory, the performance of the whole system is affected when a lot of swap space has to be used. Usually this happens when there is not enough physical memory to perform the desired functionality of a system. It can also happen if an application requests much more memory than it actually needs.

276


Version 1


One reason for this could be an application crash, but it also happens during normal operation, when the implementation of a program is faulty. In this case, the application has a memory leak. You can use the top command to find programs that use a lot of memory. By default, top sorts the process list by CPU utilization. By typing F, n, and then pressing the Enter key, you can change the column used for sorting to memory utilization. This way, the top memory consumers can be found at the top of the list. If a lot of used swap memory is displayed in free, this can indicate a performance bottleneck caused by a lack of physical memory. But this is not always the case. Sometimes a lot of memory is copied to the swap partition but is never touched again. The performance of the system is affected only when the swap memory is actually accessed. You can use the vmstat command to display the activity of swap memory, as in the following: vmstat 1 The option 1 lets vmstat repeat its output every second. This way, the usage of swap memory can be displayed over a period of time. You can terminate the program pressing Ctrl+C. The output of vmstat looks like the following: procs r b 0 0 0 0 0 0 0 0 0 0 0 0

--------memory---------- -swap- --io-- -system- ----cpu---swpd free buff cache si so bi bo in cs us sy id wa 4 6728 34464 244744 0 0 447 42 1216 384 15 3 74 7 4 6728 34464 244744 0 0 0 0 1186 222 1 1 98 0 4 6760 34464 244744 0 0 0 0 1282 299 3 0 97 0 4 6696 34532 244744 0 0 0 68 1139 147 1 1 97 1 4 6696 34532 244744 0 0 0 0 1105 123 0 0 98 0 4 6696 34532 244744 0 0 0 0 1117 131 0 0 98 0

The output in the columns si and so are of interest in this case. si stands for swap in, which means that data is transferred to the main memory from the swap space. so stands for swap out, which means that data is transferred to the swap space from the main memory. In the example above, there is no activity for the swap space. The first line of the output displays the average values since the system was started. The lines that follow show the average values since the last output.

Version 1


277






The following output of vmstat is captured on a different system which ran out of memory and shows a lot of activity in swap memory: procs r b 0 3 1 3 1 2 0 3 0 4 0 5

--------memory-----swpd free buff cache 167880 608 4592 93400 169316 1072 4044 90352 170268 2520 4088 89416 170652 1484 4020 90136 171380 1848 3544 92424 171576 1352 3504 91984

-- -swap- --io-- -system- -----cpu-----si so bi bo in cs us sy id wa 340 188 2588 196 1223 1315 7 3 0 90 300 1768 5968 1868 1233 1222 36 5 0 59 288 1104 1388 1224 1260 442 23 2 0 75 364 668 1844 808 1260 1142 12 3 0 85 100 868 4400 940 2491 2458 11 8 0 81 552 388 1592 388 1248 1195 15 3 0 82

In this example, there is much more activity in the si and so columns than before. The number displayed represents the amount of memory that is copied to or from swap memory. A system that shows a constant vmstat output like this has a performance bottleneck caused by a lack of physical memory. The following are commands and an application you can use to display memory utilization: Table 7-2

Monitor Memory Utilization Program

Description

free

Displays the current utilization of the physical and swap memory.

KDE System Guard

Offers the capability to display memory usage. Select the System Load tab to follow the memory usage over a period of time.

vmstat

Monitors the activity of swap memory and can also be used to display other system parameters.

Analyze Storage Performance The performance of the storage system can be an issue, especially on systems that face heavy hard disk utilization like FTP, Web, or other kinds of file servers. Before you analyze the hard disk performance and utilization, you should make sure that you don’t have any problems with a too high system load or a lack of physical memory. Systems with disk performance problems usually show a low network and CPU utilization but a high activity of the installed disks, which is not caused by memory paging or swapping. In this case, you can use the vmstat command to display the activity of the disk subsystem. You start vmstat by entering the following: vmstat 1

278


Version 1


The program should be started on the system when the performance problem occurs. The following is the output of a system with almost no disk operations: procs --------memory------- --swap-- -----io-- --system-- ---cpu--r b swpd free buff cache si so bi bo in cs us sy id wa 0 0 4 6728 34464 244744 0 0 447 42 1216 384 15 3 74 7 0 0 4 6728 34464 244744 0 0 0 0 1186 222 1 1 98 0 0 0 4 6760 34464 244744 0 0 0 0 1282 299 3 0 97 0 0 0 4 6696 34532 244744 0 0 0 68 1139 147 1 1 97 1 0 0 4 6696 34532 244744 0 0 0 0 1105 123 0 0 100 0 0 0 4 6696 34532 244744 0 0 0 0 1117 131 0 0 100 0

In this example, the columns of interest are bi and bo. They display the number of blocks that are read from (bi) or written to (bo) the disk subsystem. The following shows a system with a high utilization of the disk subsystem: procs r b 1 2 0 3 1 2 1 0 1 2 0 2 0 2

---------memory------- --swap-- ----io--- --system-- ---cpu--swpd free buff cache si so bi bo in cs us sy id wa 52 5680 6100 221688 0 0 0 36160 1273 1655 42 58 0 0 304 6896 1232 225672 0 256 4 22160 1586 1127 31 40 0 28 304 5936 1252 226540 0 0 0 28400 1487 460 15 23 0 62 304 7792 1276 224404 0 0 0 43328 1342 408 20 29 0 51 304 6256 1624 224648 0 0 0 88260 1205 439 24 42 0 35 476 6648 1672 224112 0 172 4 45452 1149 8015 29 54 0 17 476 7672 1720 223184 0 0 8 36940 1168 8310 23 44 0 33

As you can see in the bo column, the system has to deal with a lot of writing activity to the disk subsystem. However, a lot of data read from or written to the disk does not necessarily mean that the disk subsystem is too slow. Depending on the available disk types and the disk configuration, a disk load that totally blocks one system can be easily handled by another system. A performance problem that is caused by the disk subsystem usually occurs when a process has to wait for data being delivered from or written to the disk. You can use the iostat command (package sysstat) to determine the average time a program has to wait for data from the disk. The following command displays information about the disk device /dev/sda: iostat -x 1 /dev/sda The option -x enables the output of some additional information. 1 sets the interval in which iostat repeats its output to one second. The device name specifies the disk that should be monitored. If no disk is specified on the command line, all disks that are used by the system are monitored.

Version 1


279






The output of iostat looks like the following: da10:~ # iostat -x 1 /dev/sda Linux 2.6.27.13-1-xen (da10) avg-cpu:

_i686_

%nice %system %iowait 0,00 0,26 2,72

%steal 0,00

Device: rrqm/s wrqm/s r/s avgrq-sz avgqu-sz await svctm %util sda 1,46 58,84 7,71 38,68 1,81 99,28 2,95 5,36

w/s

rsec/s

wsec/s

10,44

146,13

556,12


%steal 0,00

%idle 99,34


w/s

rsec/s

wsec/s

1,00

0,00

16,00

avg-cpu:

avg-cpu:

%user 0,70

05.03.2009

%user 0,00

%user 0,00


%steal 0,00


w/s 0,00

%idle 96,33

%idle 100,00 rsec/s

wsec/s

0,00

0,00

Every output contains two blocks of information. The first block displays information of the CPU utilization, like top or uptime. The second block shows the information about the requested disk device. The first output represents the average values since the system was started. All following lines show the average values since the last update period. The block that displays the device information shows first some details about the amount of data that is read from or written to the device. To find out if the disk subsystem has a performance bottleneck, focus on the following columns: 

await: Average time, in milliseconds, an application has to wait until its I/O request is performed.



svctm: Average time, in milliseconds, that an I/O request needs to be performed.

As you can see in the iostat output on the previous page, the concerned system is not really busy. The average await time since the system was booted (first line starting with “Device:”) is 99.82 milliseconds and the average svctm time is 2.95 milliseconds. As you can see in the last “Device:” line, the current disk utilization is even far below the average with await and svctm times of 0 milliseconds.

280


Version 1


Compare this with the following output of a system with a higher I/O load: da10:~ # iostat -x 1 /dev/sda Linux 2.6.27.13-1-xen (da10) avg-cpu:

_i686_


%steal 0,01


w/s

rsec/s

wsec/s

13,27

2532,94

4802,18


%steal 0,00

%idle 28,57


w/s

avg-cpu:

avg-cpu:

%user 0,66

05.03.2009

%user 2,86

%user 1,81

%idle 93,04

rsec/s

wsec/s

72,00 26432,00 71680,00


%steal 0,00


w/s

%idle 54,75 rsec/s

wsec/s

81,00 16168,00 81920,00

As you can see, the average await time on this system is close to 300 milliseconds and the svctm time is higher than before. The following is an overview of commands that you can use to analyze disk utilization: Table 7-3

Monitor Disk Utilization Command

Description

iostat

Displays how long I/O requests from applications take.

vmstat

Monitors the amount of data that is read from or written to disk.

Analyze Network Utilization and Performance On server systems, the network connection can be a performance bottleneck. There are many different parameters that can interfere with the network connection. There are different tools you can use to monitor the network utilization. We cover one tool from Gnome and one from KDE:

Version 1



“Gnome System Monitor” on page 282



“KDE System Guard” on page 282


281







The Gnome System monitor can be started by selecting Computer > More Applications > System > Gnome System Monitor or by entering the gnomesystem-monitor command at a command line. The network utilization can be viewed on the resources tab, as shown in the following: Figure 7-1


The other tabs offer information on the system in general, the running processes with the possibility to send signals to the processes by right-clicking a process and choosing from a context menu, the file system, and hardware. KDE System Guard

The KDE System Guard can be started from the command line by typing ksysguard. NOTE: Although the KDE System Guard is a KDE application, it can also be used with the Gnome Desktop. The application is included in the kdebase4-workspace package.

282


Version 1


The following is a screenshot of the KDE System Guard: Figure 7-2

KDE System Guard

The default view does not show any information on the network performance. You can, however, add sensors on a new sheet. Click New Worksheet and in the dialog that appears, change the title of the worksheet and the number of rows and columns as needed. The new sheet looks like the following: Figure 7-3

KDE System Guard

On the right side of the window, you can browse the available monitoring sensors. To monitor a network interface, browse to Network > Interfaces > Interface_you_want_to_monitor.

Version 1


283






Two different blocks of sensors are available: 

Receiver: Information about the received network data.



Transmitter: Information about the sent network data.

The following describes some of the available sensors you can use to analyze network problems: Table 7-4

Network Monitoring with KDE System Guard Sensor

Description

Collisions

This sensor is available only for the transmitter. Collisions usually occur more frequently when too many hosts share the same Ethernet domain (such as hosts that are connected with a hub instead of a switch). Too many collisions can have a negative impact on the overall network performance.

Data/Packets

Amount of data or packets sent or received by the interface. If performance problems occur during a high network load, the network connection or type might be too slow for the purpose of the server.

Dropped Packets

Number of packets that are either dropped when they are received by the host or by other network components like routers on their way to the destination. Too many dropped packets can have a bad influence on the network performance. The following are some reasons for dropped packets:

Errors



Network components are running at a different speed. For example, the server runs at 100 Mbps, but the router at only 10 Mbps.



The network or system load of a server is too high to handle all received network packets properly.



A network component runs with a misconfigured packet filter that drops network packets.

An error occurs when a packet is transmitted but the content of the packet is corrupted. This can be caused by a bad physical connection or faulty network adapters.

There is also protocol specific information under Network > Sockets. Besides problems that are caused by the network or network setup itself, some network services can interfere with the overall system performance. These network services might not even be running on the same host that actually experiences performance problems. The following are examples of this: 

284

DNS: Many applications or services rely on the name resolution of the DNS system. If a DNS server is not working properly, the application is waiting for the response, which slows down its operation.


Version 1




Proxy: Applications that connect to a service using a proxy server suffer from bad performance of this system.



NFS: Applications or services that access data that is mounted using NFS can be blocked completely if the NFS service is not available.

The following are tools that you can use to monitor the network: Table 7-5

Version 1

Network Monitoring Tools Program

Description

ip -s link show

Status of an interface as well as transmission errors.

KDE System Guard

Network utilization and different kinds of transmission errors.

Traffic-vis

Analyis of network connections to specific hosts. You need to install the traffic-vis package in order to use this tool.


285






Objective 2

Reduce System and Memory Load If you have determined that your performance problem is caused by a high system load, you can do the following to reduce the load: 

“Analyze CPU-Intensive Applications” on page 286



“Run Only Required Software” on page 286



“Keep Your Software Up to Date” on page 288



“Optimize Swap Partitions” on page 288



“Change Hardware Components” on page 289

Analyze CPU-Intensive Applications A high system and memory load is often caused by a single application. You can use the top utility to find out which process uses the most resources on your system. Sometimes a process uses a lot of system resources because of a faulty implementation. Usually you can determine this by restarting the process. If the process does not use the same amount of resources after it has been restarted, a likely cause is a faulty implementation. In this case, you should try to get more information about the issue by searching the Internet and the Web site of the vendor or the OpenSource project. If the process starts to utilize the same amount of system resources after it has been restarted, the system is probably not fast enough to run the process. Refer to “Run Only Required Software” below for details on how to solve this issue.

Run Only Required Software The easiest but most effective way to reduce the system load is to run only the software that is required to fulfill the purpose of a system. This includes the following methods: 

“Run a Server System without X” on page 286



“Reduce the Number of Daemon Processes” on page 287

Run a Server System without X

Usually it is not necessary to run an X-Server on a server system. Most administrative tasks, including those done in YaST, can be done on the text console or remotely with SSH or SUSE Linux Remote Administration. Preventing the X-Server from being started saves memory and CPU utilization. To do so, you can switch to runlevel 3 manually by entering the following: init 3

286


Version 1


You can also set the default runlevel to 3 to boot the system to runlevel 3 automatically. To change the default runlevel, you need to open the /etc/inittab file with a text editor. In the file, look for a line like the following: id:5:initdefault:

By changing 5 to 3, you can change the default runlevel from 5 (multiuser, network, graphical login) to 3 (multiuser, network). After the change, the line looks like the following: id:3:initdefault:

Reduce the Number of Daemon Processes

In most cases, a server offers only a few services but some more daemons are actually running. By reducing the number of running daemon processes, you can reduce the processor and the memory load. To get an overview of the current service configuration, you can use the chkconfig command by entering the following: chkconfig -l The -l option lists all services and their configuration in each runlevel. For example, the following is the output for the Apache Web server: da10:~ # chkconfig -l ... apache2 0:off ...

1:off

2:off

3:on

4:off

5:on

6:off

As you can see, apache2 is enabled for runlevels 3 and 5. Review the list and make sure that only the needed services are running in the default runlevel of your server. If you find a service that is not necessary, you can prevent it from starting up at boot time by removing its start script from the init process. Use a command like the following to remove a service from the init process: chkconfig apache2 off In this example, apache2 is disabled in all runlevels. To re-enable a service, use a command like the following: chkconfig apache2 3 In this example, apache2 is enabled in runlevel 3. Changing the runlevel configuration does not affect the currently running instance of a service. If you don’t want to reboot your system with the new configuration, you need to stop a running service by calling its rc script manually.

Version 1


287






The command in the following example stops a running instance of apache2: rcapache2 stop

Keep Your Software Up to Date There are many reasons to keep your software up to date. Besides possible security issues caused by outdated software, up-to-date software can improve performance. Implementation errors that lead to a high utilization of system resources might be fixed in a newer release. And newer, faster algorithms might be used. However, there might be exceptions to the rule. For this reason, you should test new releases carefully before using them in a production environment.

Optimize Swap Partitions On a system with a lot of swapping, you should usually add more physical memory (RAM) to enhance the performance. However, if you can't do so, optimizing the swap partitions can help. First, you should make sure that you have enough available swap space. The old rule that you should have double the size of the physical memory as swap space is a bit outdated but still a reasonable starting point. The key to speeding up the swap performance is to spread swap space over several disks. This works only on systems that have more than one installed disk. Every swap partition has an entry in the /etc/fstab file that looks like the following: /dev/sda1

swap

swap

defaults

0 0

You can use more than one swap partition by creating partitions and adding these to / etc/fstab, as in the following: /dev/sda1 /dev/sdb1 /dev/sdc1

swap swap swap

swap swap swap

pri=1 pri=1 pri=1

0 0 0 0 0 0

In this example, three partitions are used on three different disks. The additional parameter pri=1 assigns the same priority to all swap partitions. With a priority 1 assigned to all swap partitions, the kernel can use the partitions in parallel. This leads to a higher overall performance of swapping operations. The drives that hold swap partitions should run at the same speed. If you have drives with different speeds, you can assign the swap partitions on the faster ones a higher priority, such as pri=10. Swap partitions with a higher priority are used first, and only when there is no free swap space available anymore is the swap space of a partition with lower priority used.

288


Version 1


Change Hardware Components If the above methods to reduce the system load do not lead to a lower resource utilization, you should consider upgrading the following hardware: 

“Upgrade the CPU” on page 289



“Upgrade the Memory” on page 289

Upgrade the CPU

If your system shows a high system load but all other parameters such as memory, network, and storage load or utilization are not significantly high, you should consider upgrading the CPU. However, you need to consider the following before upgrading the CPU: 

Are there significantly faster CPUs available for the type of system you are using (socket type, BIOS support)?



Are the rest of the system components fast enough for the new CPU? (Otherwise, you could work on one bottleneck and create a new one.)



Is the system going to be replaced in the near future?



Are other, faster systems available in your organization that could be used instead of the current system?

Depending on the answers to these questions, you might decide to replace the whole system instead of just the CPU. In some cases, this might be even more economical than just a CPU upgrade in the long run. Upgrade the Memory

Upgrading the memory usually means installing more physical memory. The first question you might ask is how much additional memory you should install. A way to answer this question is to look at the amount of swap space that is used by the system when the performance problems occur. Adding double the amount of used swap space might be a good starting point. But you should also compare the cost of a memory upgrade with the cost of installing a new system. Remember that if you add additional physical memory, you should also add additional swap space. However, in most cases, more than 1 GB of swap space does not increase performance significantly.

Version 1


289






Exercise 7-1

Reduce Resource Utilization In this exercise, you analyze system performance and learn how to reduce the resource utilization of a SUSE Linux Enterprise Server 11 system. You will find this exercise in the workbook. (End of Exercise)

290


Version 1


Objective 3

Optimize the Storage System There are many different ways to optimize the performance of your storage systems, including the following: 

“Configure IDE Drives with hdparm” on page 291



“Tune Kernel Parameters” on page 292



“Tune File System Access” on page 294



“Change Hardware Components” on page 295

Configure IDE Drives with hdparm You can use the hdparm tool to tune some settings of IDE hard drives. Entering the following command displays the current settings of a drive: da10:~ # hdparm -i /dev/sda /dev/sda: Model=ST380815AS , FwRev=3.AAA , SerialNo= 6QZ2FW3T Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% } RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4 BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=?16? CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=156301488 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4 DMA modes: mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 AdvancedPM=no WriteCache=enabled Drive conforms to: Unspecified: ATA/ATAPI-1,2,3,4,5,6,7 * signifies the current active mode

In this example, the settings of the device sda are listed. The most important setting you can change with hdparm is DMA (direct memory access). With DMA, data from a disk can be written directly to the main memory of a system without CPU utilization. This enhances performance in two ways: 

The transfer itself is much faster than with disabled DMA



The CPU is not utilized and can be used for other tasks

By default, DMA should be enabled for IDE hard disks, as in the above example (udma6). However, if you experience a weak disk performance, you should check the setting. DMA can also be enabled for CD/DVD drives, which increases performance, especially for large data transfers. You can change the DMA value using hdparm. NOTE: Because changing DMA or other values might cause a loss of data, back up your data first before experimenting with it. The manual page for hdparm lists the options and the caveats.

Version 1


291






hdparm also provides an option to measure the transfer performance of a hard disk, as in the following command for the device hda: da10:~ # hdparm -t /dev/sda /dev/sda: Timing buffered disk reads:

222 MB in

3.00 seconds =

73.94 MB/sec

In this example, the disk offers a buffered disk read rate of about 74 Mbps. To achieve valid results, you should repeat the test several time and compare the results. In general, the test should be run at a low system and storage load. All changes that are made with hdparm are active only until the next reboot. To make sure hdparm commands are executed every time the system boots, you can add them to the /etc/init.d/boot.local file.

Tune Kernel Parameters The components of the Linux kernel that are responsible for hard disk access offer some parameters that can be changed at runtime. None of these parameters is saved permanently. If you want to set them every time the system starts up, you can add a command to set a parameter in the /etc/ init.d/boot.local file. Tunable parameters let you do the following: 

“Tune the IO Scheduler” on page 292



“Change the Read-Ahead Parameter” on page 293



“Change the Swappiness Parameter” on page 293

Tune the IO Scheduler

Because Linux is a multitasking operating system, more than one process at a time might need to access the hard disk. For this reason, the Linux kernel contains a component called the I/O Scheduler. This scheduler collects requests from the processes and hands them over to the hardware driver that is responsible for the drive. The SUSE Linux Enterprise Server 11 I/O Scheduler has one parameter that you can use to tune the I/O performance. The parameter is stored in the /sys/block/ device/queue/iosched/quantum file. The parameter determines how many I/O requests are stored in a queue before they are handed over to the driver. By queuing the requests, the scheduler can optimize the order of the requests.

292


Version 1


When you use this parameter, there is a trade-off between data throughput and latency. Use the following guidlines: 

Lower value = Shorter latency but lower data throughput



Higher value = Longer latency but higher data throughput

The default value for SUSE Linux Enterprise Server 11 is four requests. You can set the value of the parameter with a command similar to the following: echo 6 > /sys/block/hda/queue/iosched/quantum When you change the value, you should always benchmark your application to measure the success of the change. Changes to the I/O Scheduler parameters might not lead to performance enhancements on general-purpose servers. However, on systems with a high disk utilization like database servers, it can be useful to experiment with this setting. Change the Read-Ahead Parameter

Another kernel parameter lets you determine how much data should be used for the read-ahead. Read-ahead basically means that more data from a file is read than requested by an application. This is done because an application usually wants to read all data from a file, not just the data at the beginning. You can set the read-ahead parameter in the /sys/ block/device/queue/read_ahead_kb file. The value determines how much data (in KB) is read ahead from file. The default value on SUSE Linux Enterprise Server 11 is 128 KB. Larger values can lead to a better overall throughput, with the drawback of a higher latency. You can change the value with the following command: echo 256 > /sys/block/device/queue/read_ahead_kb Change the Swappiness Parameter

The swappiness parameter affects both the memory and the I/O performance. It basically determines when a system starts to swap out data to the disk, and it can be set in the /proc/sys/vm/swappiness file. You can set the parameter value from 0 and 100. The higher the value, the more the system will swap. The default value for SUSE Linux Enterprise Server 11 is 60. You can set the parameter with a command like the following: echo 40 > /proc/sys/vm/swappiness The parameter determines how much you value the page cache over program memory.

Version 1


293






Tune File System Access To achieve a performance advantage for an application, you can control the way the kernel accesses the file system by doing the following: 

“Disable atime Update” on page 294



“Implement File System-Dependent Tuning Options” on page 294

Disable atime Update

For every file, Linux stores the following information: 

When the inode was changed (ctime)



When the file content was last modified (mtime)



When the file was last accessed (atime)

To keep the atime information up to date, the kernel needs to update the atime attribute every time a file is accessed. Updating the atime means that the kernel needs to perform a write access, which causes additional load for the hard disk. If the atime attribute is not important to you, you can mount a data partition with the noatime option. This might be especially useful on laptops. The following shows an fstab entry for the partition /dev/sda2 that uses the noatime option: /dev/sda2

/data

ext3

acl,user_xattr,noatime

1 1

Implement File System-Dependent Tuning Options

Beside the general disk tuning options, you can also configure the file system to do the following: 

“Configure the Journaling Mode of Ext3” on page 294



“Mount a Reiser File System with the notail Option” on page 295

Configure the Journaling Mode of Ext3

The ext3 file system offers journaling functionality. In journaling, every file system transaction is logged in a special area of a partition, called the journal. The data in the journal helps to restore a consistent file system in case of a system crash or a power failure. The ext3 file system offers three journaling modes that also affect the disk performance:

294



data=journal: Logs the transaction data and the file metadata in the journal. This is the most secure option for data security.



data=ordered: Stores only the file metadata in the journal. However, it forces the file data to be written to disk before the metadata.


Version 1


This option is a good compromise between speed and reliability, and it is the default for SUSE Linux Enterprise Server 11. 

data=writeback: Fastest journaling option. Metadata is logged to the journal, but file data is not treated in a special way. However, you still have the advantages of a journaling file system when a crash or a power failure occurs.

You can use these options with the -o option of the mount command, or add them to the /etc/fstab, as in the following: /dev/sda2

/data

ext3

acl,user_xattr,data=writeback

0 0

Mount a Reiser File System with the notail Option

On traditional UNIX files systems, small files or the remainder of a big file (the tail) use a full block of the file system, although they don’t really fill the block. Reiserfs can store this data much more efficiently in the file system internal structure. However, this costs some performance. You can use the mount notail option to disable this feature. The drawback is a less space-efficient data storage. You can use the notail option either with the -o option of mount or in the /etc/ fstab file, as in the following: /dev/sda3

/data2

reiserfs

acl,user_xattr,notail

0 0

Change Hardware Components If all of the above-mentioned options do not improve disk performance, you might need to consider upgrading your hardware. From a performance perspective, a true SCSI hardware RAID system might be the best choice. But upgrading to a newer IDE or SCSI disk can produce some of the same results. However, you have to compare the costs and the estimated advantages of an upgrade with the purchase of a new system. A hardware upgrade always has the risk of creating a new performance bottleneck somewhere else in the system.

Version 1


295






Objective 4

Tune the Network Performance There are several different approaches to tuning the network performance of your Linux system. Because of the nature of networks, this sometimes includes not only your system but the whole network infrastructure. The following are two ways you can tune network performance: 

“Change Kernel Network Parameters” on page 296



“Change Your Network Environment” on page 297

Change Kernel Network Parameters The Linux kernel lets you change some network parameters during runtime. This makes sense on systems that have to deal with a lot of parallel connections (such as Web servers). The parameters can be set with the sysctl command. To use this command, you have to be the root user, because changing kernel parameters is not permitted for regular users. The most important command line parameter of sysctl is -w. With this option, you can write a value into a kernel configuration parameter. You can also access the kernel parameters from the proc file system, which is mounted under /proc. You change the parameters by writing them into the corresponding files in the /proc directory. The following lists several sysctl commands and their effect on network performance: Table 7-6

Tuning the Network Performance Using sysctl sysctl command

Effect

sysctl -w net.ipv4.tcp_tw_reuse=1 sysctl -w net.ipv4.tcp_tw_recycle=1

When a TCP connection has been closed, the corresponding socket stays in the TIMEWAIT status for a while. Setting these two parameters enables the reuse of these sockets for new connections. On a system with many TCP connections, this can reduce the number of open connections and the utilization of system resources.

296


Version 1


sysctl command

Effect

sysctl -w net.ipv4.tcp_keepalive_time=900

TCP connections are usually kept alive for a specific amount of time. After this time period, a system probes to see if the connection partner is still reachable. If not, the connection is closed and the used resources are freed. The default time for SUSE Linux Enterprise Server 11 is 7200 seconds (two hours). By reducing this time, you can reduce the number of opened but unused connections.

To set values at boot time, the values need to be added to the /etc/sysctl.conf file. Its syntax is token = value, as shown below in a sample /etc/ sysctl.conf file: # Disable response to broadcasts. # You don't want yourself becoming a Smurf amplifier. net.ipv4.icmp_echo_ignore_broadcasts = 1 # enable route verification on all interfaces net.ipv4.conf.all.rp_filter = 1 # enable ipV6 forwarding #net.ipv6.conf.all.forwarding = 1 # increase the number of possible inotify(7) watches fs.inotify.max_user_watches = 65536 # avoid deleting secondary IPs on deleting the primary IP net.ipv4.conf.default.promote_secondaries = 1 net.ipv4.conf.all.promote_secondaries = 1

Change Your Network Environment Because networking involves more than one system, you should consider which changes to other hosts or your network infrastructure can improve the network performance. The following are some suggestions for improving network performance: 

Monitor all other system components: Before you change your network infrastructure, you should make sure that your problem is really caused by the network connection. Monitor all other components carefully over a longer period of time, especially the CPU and memory utilization.



Limit the collision domain: If you see a lot of collisions when you monitor your system's network interface, there are probably too many systems that share the same Ethernet collision domain. In this case, you should restructure your network or use switches instead of hubs.



Version 1

Check cable quality: If you see a lot of transmission errors when you monitor a network interface, you might have a problem with your network cable. Replace the network cable and monitor the interface again.


297








Check both sides of a connection: If your server has connectivity problems with a specific client and all other clients are working correctly, you should check the connection from the client side.



Change network adapters: In some cases, a driver for a network adapter can be faulty and cause a performance bottleneck. Try switching to an adapter from a different vendor and monitor the system to see if performance improves.



Upgrade to a faster network type: If other measures do not lead to improved performance, upgrading to a faster network technology (such as Gigabit Ethernet) might help. However, you must make sure that the other components of your system (such as the chipset) can handle this speed.

298


Version 1


Summary Objective

Summary

Find Performance Bottlenecks

To find performance bottlenecks, you should monitor the following components of your system: 

CPU: Value of the CPU load is measured by the average number of process that are waiting to be executed. The load can be displayed with uptime or top. top can also be used to display the processes that cause the highest CPU utilization.



Memory: Lack of physical memory is a very common performance bottleneck. When the system needs to page out memory pages to swap memory, the overall system performance is affected. You can display the paging and swapping activities with the vmstat tool.



Storage System: A good indicator for the storage load of a system is the time that an application needs to wait for an I/O request and the amount of time an average I/O request takes. Both values can be displayed with the iostat tool.



Reduce System and Memory Load

Version 1

Network components: KDE System Guard displays various parameters of network utilization such as packets, errors, and collisions.

To reduce the system and memory load, you can do the following: 

Determine which processes utilize most of the processing power. Determine whether this is a failure or part of normal operation.



Run only software that is required to fulfill the purpose of the system.



Keep your software up to date.



Optimize swap memory by spreading it over multiple disks.



Upgrade the CPU and the physical memory.


299






Objective

Summary

Optimize the Storage System

To enhance the performance of the storage system, you can do the following:

Tune the Network Performance

300



Use hdparm to ensure an optimal configuration of your hard disks.



Set kernel parameters to optimize disk access.



Tune access to the file systems on your disks.



Change slow components of your storage system.



Adapt the network parameters of the Linux kernel for your needs.



Reconfigure your network environment. This includes the following: 

Reduce the collision domain of Ethernet networks.



Check the physical quality of the connection (such as cables and plugs).



Check both sides of a faulty network connection.



Replace or upgrade your network equipment.


Version 1


SECTION 8


Bash scripts play a key role in the administration of SUSE Linux Enterprise 11. All start scripts in the /etc/init.d/ directory, for instance, are Bash scripts. As a Linux system administrator, you are often faced with recurring tasks that consist of commands that have to be called in a certain order. By combining these commands into a script, you can make your job a lot easier. This section covers the basic elements of shell scripts to help you understand existing shell scripts in your Linux system and to help you write shell scripts of your own that fit your needs. When writing shell scripts, you usually have many different options to solve a problem. Please note that our project will not necessarily use the most efficient way of coding. The purpose here is, first of all, to introduce you to the elements of Bash scripting and to use examples that are easy to understand. Objectives 1.

“Bash Basics” on page 302

2.

“Use Basic Script Elements” on page 307

3.

“Understand Variables and Command Substitution” on page 312

4.

“Use Control Structures” on page 316

5.

“Use Arithmetic Operators” on page 325

6.

“Read User Input” on page 328

7.

“Use Arrays” on page 331

8.

“Finalize the Course Project” on page 334

9.

“Use Advanced Scripting Techniques” on page 337

10. “Learn about Useful Commands in Shell Scripts” on page 341

Version 1


301






Objective 1

Bash Basics The default Linux shell Bash (Bourne Again SHell) can control the system with commands, perform file operations, or start applications. It can be used interactively on the command line, or you can create a file that includes several shell commands and start this file like an application. Before diving into shell scripting, let’s review some of the features of Bash: 

“Bash Command Line” on page 302



“Bash Variables” on page 304



“Return Values” on page 306

All the elements covered in this objective for interactive use of Bash can be employed within shell scripts as well.

Bash Command Line A command entered on the command line consists of the command and optional arguments: geeko@da10:~> cp -a Photos /tmp geeko@da10:~>

On the left there is the command prompt, geeko@da10:~>. The command cp is followed by arguments—in this case, the option -a and the parameters Photos and /tmp. After pressing Enter, the command is executed. As there is no error message, the command was successful. Each element in the command line above is called a word. A word (also called a token) is a sequence of characters considered as a single unit by the shell. Words are separated from each other by spaces, tabs, or one of the following characters: | & ; ( ) < >. Depending on the type of command or its options, some messages appear on the screen. Messages that indicate normal or expected behavior are written to the file descriptor 1, Standard Out (stdout) which, in interactive use of Bash, is connected to the terminal where you entered the command: geeko@da10:~> cp -av Photos /tmp "Photos/vacation/beach.jpg" -> "/tmp/Photos/vacation/beach.jpg" ...

When there is an error message, this message is written to the file descriptor 2, Standard Error (stderr) which, in interactive use is also connected to the terminal where you entered the command: geeko@da10:~> cp -av Fotos /tmp cp: cannot stat `Fotos': No such file or directory geeko@da10:~>

302


Version 1


While within a terminal, stdout and stderr look the same, but they are indeed different, as you can see when you redirect them to a file. To redirect stdout to a file, you use the > operator (or >> to append to a file): geeko@da10:~> cp -av Photos /tmp > output.txt geeko@da10:~> cat output.txt "Photos/vacation/beach.jpg" -> "/tmp/Photos/vacation/beach.jpg" ...

It is also possible to redirect stderr to a file. This is especially useful if there are a lot of error messages or some error messages in a lot of normal output. Redirecting stderr allows you to view the messages using a pager like less. To redirect stderr, you use the 2> operator: geeko@da10:~> cp -av Fotos /tmp 2> error.txt geeko@da10:~> cat error.txt cp: cannot stat ’Fotos’: No such file or directory geeko@da10:~>

As you can see in both examples, when stdout and stderr are redirected, no output is written to the terminal. You can also redirect stdout and stderr to separate files in one command line: geeko@da10:~> cp -av Fotos Photos /tmp > output.txt 2> error.txt geeko@da10:~>

It is also possible to redirect stdout and stderr to one file, using the 2>&1 operator, which has to appear after the redirection of stdout on the command line: geeko@da10:~> cp -av Fotos Photos /tmp > out-err.txt 2>&1 geeko@da10:~>

In addition to stdout and stderr, by default there is a third file descriptor, Standard In (stdin, file descriptor 0). In interactive use, this is usually connected to the keyboard. But it can be redirected to a file as well, and the operator to redirect stdin is <: geeko@da10:~> mail -s "Output and Errors" geeko < out-err.txt geeko@da10:~>

In Linux, a typical program will open these three file descriptors (Standard In, file descriptor 0; Standard Out, file descriptor 1; Standard Error, file descriptor 2) when it starts.

Version 1


303






If you want to process the output of one command by another command, you could write the output of the first program to a file and use that file as input for the second command, as shown in the above example for the mail command. However, you can use the output of one command directly as the input for another command using the pipe operator |: geeko@da10:~> cp -av Fotos Photos /tmp Errors" geeko geeko@da10:~>

2>&1 | mail -s "Output and

Instead of reading from a file, the shell can be instructed to read from the current source with a so-called here document, using the << redirector, as illustrated in the following example: geeko@da10:~> cat << EOF > This is printed after > writing EOF in a single line. > EOF This is printed after writing EOF in a single line.

The text after the cat << EOF line is printed once the same string (EOF in the example above) appears in a line with no trailing whitespace. This syntax is often used in scripts to write several lines to the screen. NOTE: For a full explanation of redirection, see man bash and search for “redirection”.

Bash Variables A variable is a label assigned to a location in computer memory that holds an item of data. Bash variables are not typed. They are essentially character strings, but some arithmetic operations are possible when the variable contains only digits. Variables can serve different purposes. The following types of variables exist, although the differentiation is to some extent arbitrary, because positional parameters, for instance, could also be included under shell variables: 

“Shell Variables” on page 304



“Positional Parameters” on page 305



“Environment Variables” on page 305

Shell Variables

Shell variables are used to control the behavior of the shell itself. Some of them are assigned default values by Bash, and some can be assigned values by the startup

304


Version 1


scripts Bash reads when it starts (such as /etc/profile or ~/.bashrc). These include the following: 

IFS: Internal Field Separator. A list of characters that separate fields and are used to determine the beginning and end of a word (token).



PS1: Primary Prompt String. The string that determines how your normal prompt in a terminal window looks like.



BASH: The full path name used to execute the current instance of Bash.



HISTSIZE: The maximum number of commands kept in the history list.

NOTE: For a full explanation of shell variables, see man bash and search for “Shell Variables”.

Positional Parameters

When a command or script is called, the $0 parameter is assigned the command or script name. The first parameter after this is $1, the second $2, and so on. If you want to refer to all positional parameters, you would use $* (all positional parameters seen as one single word) or $@ (all positional parameters seen as separate words). The following should give you an idea how they can be used: geeko@da10:~> cat script.sh echo The command itself: "$0" echo The first parameter: "$1" echo The second parameter: "$2" echo All parameters '($*)': "$*" echo All parameters '($@)': "$@" geeko@da10:~> ./script.sh first second The command itself: ./script.sh The first parameter: first The second parameter: second All parameters ($*): first second All parameters ($@): first second geeko@da10:~>

Environment Variables

Every process has an environment, which consists of variables that it may reference and which can be used by the process to influence its execution. This is true for the shell as well. Environment variables can be used to regulate the behavior of Bash. They are usually set by the scripts Bash reads when it starts, including /etc/profile, ~/ .bashrc and others. Environment variables include the following: 

Version 1

USER: User who invoked the shell.


305








MANDIR: Directories to search for manual pages



LS_COLORS: Colors used for the output of the ls command.

By default, various environment variables are set. You can view them and their content with the export and set commands.

Return Values Every command returns a value to the calling shell that indicates whether the program terminated normally (return value 0) or there were errors (return value not 0). The return value of the last process run by Bash is stored in the $? variable. Using the echo command, you can view the content of this variable: geeko@da10:~> ls -ld Desktop drwxr-xr-x 2 geeko users 440 13. Jan 15:57 Desktop geeko@da10:~> echo $? 0 geeko@da10:~> ls -ld abcd ls: cannot access abcd: No such file or directory geeko@da10:~> echo $? 2 geeko@da10:~>

Using the return value, you can make the execution of a second command dependant on the outcome of the first. The operators to use are && (the second command is executed if the first one returns 0) or || (second command is executed if the first command returns a value different from 0). This command displays the content of the message.txt file if it exists: test -f message.txt && cat message.txt This command installs the package sysstat if it is not installed: rpm -q sysstat || yast2 -i sysstat Within a script, decisions on how to proceed are frequently based on the return value of a command.

306


Version 1


Objective 2

Use Basic Script Elements An important but sometimes neglected task is the backing up of files. As shell scripting is best understood and learned by actually writing scripts, we will develop in this section a Bash script to back up your home directory. Usually backups are written to external media, like external hard drives or tape drives. As you probably don’t have such a drive at your disposal in your study environment, in the script we will back up the files to different directories on your hard drive. Once you have understood the scripting basics covered in this section, you should be able to adapt what you have learned to other environments, such as your personal backups at home, or the backups in your company to safeguard company information. To write a simple shell script, you have to understand the following: 

“Elements of a Shell Script” on page 307



“A Simple Backup Script” on page 308



“Debug Options” on page 310

Elements of a Shell Script A shell script is basically an ASCII text file containing commands to be executed in sequence. To allow this, it is important that permissions for the script file are set to r (readable) and x (executable) for the user that runs it. However, the execute permission is not granted by default to newly created files. To assign this permission, you need to use a command such as the following: chmod +x script.sh NOTE: You can also execute the script from another shell with a command such as the following: bash script.sh In this example, it is not necessary to make the script executable. On SUSE Linux Enterprise 11, /bin/sh is a link to /bin/bash. When invoked as sh script.sh, some Bash features are not available and your script might not work as intended if it relies on some of these features.

If you want to be able to run the script by using its name alone, the directory where the script is located must be listed in the $PATH variable. If there is a bin directory in the home directory of a user, this directory is included in $PATH by default in SUSE Linux Enterprise 11. Shell scripts in a directory that is not listed in $PATH must be started with the full path name or a relative path name such as ./script.sh.

Version 1


307






When naming script files, it is a good idea to add an .sh extension to the filename. Linux doesn’t require it, but it ensures that the file can easily be recognized by the system administrator as a shell script. If you do not add the suffix, you need to make sure the filename is not identical to existing commands. For example, a common mistake is to name a script “test” which interferes with the test command line tool. Within a script, empty lines and lines starting with a # character are ignored. The # character is used to add comments to your script. As a general practice, you should add a comment in the beginning giving a brief overview what the script is supposed to do, and also add comments throughout your script to explain what a line or section does. This makes it much easier for you and others to understand the script when you go back to it after some time to modify it. The first line of a script defines the shell used to execute the script. This line is sometimes referred to as the she-bang line. Only this first line is interpreted despite the fact it starts with a # character. It has the following syntax: #!/bin/bash

All subsequent lines of the script are either comments (starting with a # character) or actual commands.

A Simple Backup Script The core command that we will use to make the backups is rsync. rsync allows to efficiently copy files from one directory to another or from one machine over the network to another. Its main advantage is that when updating a backup, only the differences between files are copied, not the entire files, speeding up the update remarkably. rsync can be controlled with various options. Therefore, even if our script contains only one command, it can save some typing as there is no need to type the options each time it is invoked. What the script is supposed to do is to copy the user’s home directory to the /backup directory. The elements you need are the she-bang line, a comment that explains what the script does, and the rsync command itself. The script could look like the following: #!/bin/bash # # simple-backup1.sh # Back up geeko’s home directory to /backup using rsync rsync -a --no-whole-file /home/geeko /backup

The -a (archive) option ensures the permissions are kept and directories are copied recursively. The --no-whole-file option makes sure only the changed parts of the files are updated, not the whole files copied. This does not make a difference on the initial copy, but speeds up updates.

308


Version 1


When you execute this script, you might get an error similar to the following: geeko@da10:~/bin> simple-backup1.sh rsync: writefd_unbuffered failed to write 4 bytes [sender]: Broken pipe (32) rsync: mkdir "/backup" failed: Permission denied (13) rsync error: error in file IO (code 11) at main.c(576) [receiver=3.0.4] rsync: connection unexpectedly closed (9 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(632) [sender=3.0.4]

The reason is that the directory /backup doesn’t exist and, as a normal user, you are not allowed to create files or directories in /. We will integrate some error handling later; for now, just create (as root) the directory /backup with the command mkdir -m 1777 /backup and run the script again as a normal user. When you execute the script, there is no output, which is consistent with the usual behavior of Linux command line programs of “no message = success.” However, if you want to see some information, you can add a message to the script: #!/bin/bash # # simple-backup2.sh # Backup geeko’s home directory to /backup using rsync echo "Backing up /home/geeko to /backup/" rsync -a --no-whole-file /home/geeko /backup

The echo command can be used to output text to the terminal, which is enclosed in double quotes. The option -e lets echo interpret backslash sequences. These can be used to format the output to some extent. The following is a list of other backslash sequences that can be used with echo and what they output:

Version 1



\\ Backslash



\a Alert (beep tone)



\b Backspace



\c Trailing new line



\f Form feed



\n New line



\r Carriage return



\t Horizontal tab



\v Vertical tab


309






Debug Options It is probably more the exception than the rule that a script does exactly what you want it to do at once. If it does not do what you want you have to find the error. There are several ways you can instruct the shell to output more information that helps you to find the error:

310



#!/bin/bash -x: Add -x to the first line of your script.



bash -x script.sh: Start the script in a separate shell with the -x option. The advantage of this approach is that you don’t have to change the script itself.



set -x: Using set -x in the current shell turns on the additional output for all scripts started from this shell. You can turn this off again with set +x. No changes to the script itself are necessary.


Version 1


Exercise 8-1

Create a Simple Shell Script In this exercise, you create your first shell script. You will find this exercise in the workbook. (End of Exercise)

Version 1


311






Objective 3

Understand Variables and Command Substitution Variables are an important component of all programming languages. You can understand variables as containers that hold data. Instead of the data itself, the variable is used in the program code. Look at the following example: #!/bin/bash # # variables1.sh NAME="Geeko" echo "Hello, my name is ""$NAME"

The string “Geeko” is assigned to the variable NAME. Then the variable NAME, with a $ character in front, is used in the echo command. There are a few things to be aware of: 

When you assign a variable, you use just the name of the variable. When you access the data of a variable, you put a $ before the variable name.



When you assign data to a variable, there must be no spaces between the variable name, the = character, and the data.



If the string you assign to the variable contains spaces you need to enclose the string in quotation marks (“). To ensure proper processing of the spaces you should enclose the variable ($NAME in the example above) in quotation marks as well. If you forget that, you can get unexpected results, as your string might get processed as several words although you didn’t intend that.

The following is the output of the example script: geeko@da10:~/bin> variables1.sh Hello, my name is Geeko

We use $NAME in the echo line and the variable is replaced with its content. The advantage of the use of variables is that you define them at one point and then use them throughout the rest of the script. If you have to change the variable, you change it at one point, not throughout the script. With this, you can improve the backup script by using a variable to hold the user’s name, as shown in the following: #!/bin/bash # # variables2.sh # Back up someone's home directory to /backup using rsync USERNAME="geeko" echo -e "Backing up /home/""$USERNAME" to /backup/" rsync -a --no-whole-file /home/"$USERNAME" /backup

312


Version 1


Variables can contain not only strings but also numbers. By default, a variable in a shell script can hold any kind of data. However, it is possible to limit a variable to a specific type (for example a string) with the declare command. So far, we have assigned only static values to variables, but it’s also possible to assign the output of a command to a variable or to use a command directly where the output is needed. This is called command substitution. This basically means that the output of a command is used in a shell command line or a shell script. In the following example, the output of the date command is used to generate the output of the current date: #!/bin/bash # #command_subs1.sh echo "Today's date is ""$(date ’+%m/%d/%Y’)"

An alternate syntax for the last line includes the use of backticks (` ... `), as shown below; however, the version using $(...) is the recommended one. echo "Today's date is `date ’+%m/%d/%Y’`"

Instead of printing the output of a command to the screen with echo, it can also be assigned to a variable, as in the following: #!/bin/bash # #command_subs2.sh TODAY="$(date ’+%m/%d/%Y’)" echo "Today's date is ""$TODAY"

In this case, the output of date is assigned to the variable TODAY, and then the content of the TODAY variable is printed to the screen with echo. Again, make sure that there are no spaces before or after the equal sign. The output is the same in both cases: geeko@da10:~/bin> command_subs1.sh Today's date is 03/12/2009 geeko@da10:~/bin> command_subs2.sh Today's date is 03/12/2009 NOTE: Try command_subs2.sh without the quotes when assigning the value to the TODAY variable, and spaces instead of the slashes, as in the following: TODAY=$(date +%m %d %Y). You will see that the quotes do make a difference.

Now improve your backup script with what you have learned. Change the script so that a log file that contains the filenames of the backed-up files is written every time the script is run. The log file contains date and time as part of its filename.

Version 1


313






The script could look like the following: #!/bin/bash # # command_subs3.sh # # Back up someone's home directory to /backup using rsync # # Write a log file in the format backup-log_YYYYMMDD-hhmm # that contains the names of the files backed # # # Variables: # USERNAME="geeko" NOW="$(date ’+%Y%m%d-%H%M’)" # # The backup: # echo -e "Backing up /home/""$USERNAME"" to /backup/" rsync -av --no-whole-file /home/"$USERNAME" /backup > \ /backup/backup-log_"$NOW" NOTE: Instead of setting USERNAME within the script, you could use the $USER environment variable in the echo and rsync commands. This would make the script more flexible, as the user calling the script would back up his home directory, without having to edit the script.

314


Version 1


Exercise 8-2

Use Variables and Command Substitution In this exercise, you use variables and command substitution. You will find this exercise in the workbook. (End of Exercise)

Version 1


315






Objective 4

Use Control Structures With the scripting techniques you have learned so far, you can develop only scripts that run sequentially from the beginning to the end. In this objective, you learn how to use control structures to make the execution of parts of your script dependent on certain conditions or to repeat script parts. In this objective we will cover the following; 

“Create Branches” on page 316



“Create Loops” on page 320

Create Branches A branch in a script means that a part of your script is executed only under a certain condition. The two control structures used for this purpose are the following: 

“The if Control Structure” on page 316



“The case Control Structure” on page 319

The if Control Structure

A very common control structure for this uses the if command: if commandA then commands fi

If commandA returns true (0), then one or more commands are executed. In many cases, commandA is a test for some condition, but it can be any command. Note the closing fi word which ends the if control structure. The if statement can be extended with an optional else statement, as shown in the following example: if commandA then command1 else command2 fi

316


Version 1


In this case command2 is executed when the if condition is not true (i.e.. the return value of commandA is not 0). Now add an if structure to our backup script. Test for the return value of the rsync command, and if it is non-zero, have the script send a mail to geeko. This is especially useful for scripts that are executed regularly by the cron daemon, because errors (such as no space left on the backup device) can remain unnoticed if the user is not informed of the failure. The script could look like the following: #!/bin/bash # # control_struc1.sh # # This script does the following: # - Back up someone's home directory to /backup using rsync # - Write a log file in the format backup-log_YYYYMMDD-hhmm # and that contains the names of the files backed # - Send log files per mail # # Variables: # USERNAME="geeko" NOW="$(date ’+%Y%m%d-%H%M’)" # # The backup: # echo -e "Backing up /home/""$USERNAME"" to /backup/" rsync -av --no-whole-file /home/"$USERNAME" /backup > /backup/backuplog_"$NOW" 2>/backup/backup-errorlog_"$NOW" # # Send log files per mail to user # if test "$?" -eq 0 then mail -s "Backup successful" "$USERNAME" < /backup/backup-log_"$NOW" else mail -s "Some error occurred during backup" "$USERNAME" < /backup/ backup-errorlog_"$NOW" fi

The test command is used to check if the return value of the previous command is equal to 0. If this is true, test returns the value 0; otherwise, the value is 1. Almost all command line tools have a return value. 0 always means something like “true” or “everything is OK.” Otherwise a value different from 0 is returned. An if condition is true when the program used for testing returns 0.

Version 1


317






test can also be used for many things other than checking if one number is equal to another. The following is an overview of the most important the test options: 

test “STRING1” = “STRING2”: Strings are equal



test “STRING1” != “STRING2”: Strings are not equal



test INTEGER1 -eq INTEGER2: INTEGER1 is equal to INTEGER2



test INTEGER1 -lt INTEGER2: INTEGER1 is less than INTEGER2



test INTEGER1 -gt INTEGER2: INTEGER1 is greater than INTEGER2



test -e FILE. FILE exists

NOTE: For a complete list of all test options, see the test man page.

When you look at scripts written by someone else, you will also see a different syntax for test. Instead of test “$?” -eq 0, you can also leave out the test command and put the expression in square brackets like [ “$?” -eq 0 ]. Please note the space after the [ bracket and the space before the ] bracket. Without these spaces, you get an error message when executing the script. One other thing you might have noticed is that the lines after then and else are indented. This is not required but is a very common method to identify logical blocks and to make the code more readable. With if you can create even more complex structures in your script, using an optional elif statement, as shown in the following example: if commandA then command1 elif commandB then command2 else command3 fi

With elif, you add more conditions in case the one in the initial if statement was not true. In this case, command2 is executed in case the return value of commandA is false (not 0) and the return value of commandB is true. command3 is executed only if commandA and commandB have a non-zero return value. You can have several elif sections within an if control structure.

318


Version 1


The case Control Structure

Another way to create multiple branches is to use case. In a case statement, the expression contained in a variable is compared with a number of expressions. Commands are executed for the first expression that matches. A case statement has the following syntax: case $variable in expression1) command1;; expression2) command2;; esac

case statements are often easier to understand than if/elif/else statements, but they can have the same functionality, as shown in the following two examples: if [ "$number" -eq 10 ] then echo "The value is 10" elif [ "$number" -eq 20 ] then echo "The value is 10" else echo "I don't know" fi case "$number" in 10) echo "The value is 10";; 20) echo "The value is 20";; *) echo "I don't know";; esac

The variable $number is compared with 10, 20 and *. * matches for every value and is, therefore, the default action of the case statement.

Version 1


319






Exercise 8-3

Use an if Control Structure In this exercise, your expand the backup script with the use of an if control structure. You will find this exercise in the workbook.

(End of Exercise)

Create Loops Another common control structure is the loop. A loop is often used when a certain task has to be repeated more than once. Instead of repeating the same code in the script, a loop structure can be implemented. There are a several options for implementing a loop in shell scripts. The for Loop

The syntax of the for loop looks like the following: for variable in element1 element2 element3 do commands done

The line starting with “for” defines how many times the code between “do” and “done” has to be executed. For each pass of the loop, the variable “variable” has one of the values defined in the list after “in”. Here is an example: #!/bin/bash # # for_loop1.sh for i in 1 2 3 do echo "$i" done

The list after “in” contains three elements: the numbers 1, 2, and 3 separated by spaces. This means that the code between “do” and “done” is executed three times, and each time the variable i has a different value from 1 to 3. When you run this script, it simply outputs 1 2 3: geeko@da10:~/bin> for_loop1.sh 1 2 3

The list defined after “in” is not necessarily static. The for loop is very often used to go through a list of files. An easy way to do this is to use * after “in”:

320


Version 1


#!/bin/bash # # for_loop2.sh for i in * do lower="$(echo "$i" | tr [:upper:] [:lower:])" echo mv "$i" "$lower" done

This script loops through all files in the current working directory and (after removing the echo in front of mv which is included to test the script without actually affecting any files) renames the files from upper to lower case. * is expanded to a list of all these files by the shell. For every pass of the loop, the variable $i contains one filename. The filename is converted to lower case and stored in the variable lower. Then the original file is renamed with mv to lower case. NOTE: This is just a demo script. For a production script, you would have to add some code that makes sure that an existing lowercase file is not accidentally overwritten.

Another way of creating a list is a command substitution: #!/bin/bash # # for_loop3.sh for i in $(find -name "*.mp3") do echo rm "$i" done

This script uses find to create a list of all .mp3 files in the current directory and all subdirectories. These files are deleted in the for loop (after removing the echo included for testing purposes). There is a special syntax that can be used with for in case you want to iterate through the loop a specific number of times: #!/bin/bash # # for_loop4.sh for ((i=1;i<=10;i++)) do echo "$i" done

With syntax, the variable i is set to 1 (i=1) for the first run through the loop and then increased by one (i++) on each subsequent run. This is done as long as the condition in the middle (i<=10) is true.

Version 1


321






The while and until Loops

The while loop has the following syntax: while condition do commands done

Very similar to the while loop is the until loop: until condition do commands done

Both loop types depend on a condition. In a while loop the commands are executed as long as the condition is true; in an until loop, the commands are executed until the condition becomes true. We will use a while loop to allow the user to add additional directories or files he wants to back up in addition to his home directory. One way to iterate through the positional parameters $1, $2, etc., from the command line is to use the shift command. After calling shift, $2 becomes $1, $3 becomes $2, and so on. One possible way to solve the task is shown in the following script: #!/bin/bash # # while_loop1.sh # This script does the following: # - Back up directories or files listed on the command line # - Back up someone's home directory to /backup using rsync # - Write a log file in the format backup-log_YYYYMMDD-hhmm # and that contains the names of the files backed # - Send log files per mail # # Variables: # USERNAME="geeko" NOW="$(date ’+%Y%m%d-%H%M’)" # # The backup of the directories listed on the command line # while test -n "$1" do echo -e "\nBacking up ""$1"" to /backup/" rsync -av --no-whole-file "$1" /backup shift done #

322


Version 1


# The backup of the home directory: # echo "Backing up /home/""$USERNAME"" to /backup/" rsync -av --no-whole-file /home/"$USERNAME" /backup > /backup/backuplog_"$NOW" 2>/backup/backup-errorlog_"$NOW" ...

The test command checks if the value of the $1 parameter has a non-zero string length. If so, then the commands between “do” and “done” are executed. The shift command moves $2 to $1, and the new $1 value is tested. If there is no $2 value, the new $1 is empty and the processing of the loop is stopped. If you omit the shift command, an endless loop is created; in this case, you have to interrupt the processing of the script with Ctrl+c. It is possible to nest an if control structure between “do” and “done” and leave the while loop in case a certain condition is met. The command to interrupt the processing of the while loop is break, as shown in the following: while conditionA do commands if conditionB then break fi done

It is also possible to skip further processing of the loop and to enter the next iteration, using the continue command, as shown in the following: while conditionA do commands if conditionB then continue fi more commands done

Version 1


323






Exercise 8-4

Use a while Loop In this exercise, you use a while loop to iterate through the positional parameters included on the command line. You will find this exercise in the workbook. (End of Exercise)

324


Version 1


Objective 5

Use Arithmetic Operators Shell scripts often use values assigned to variables for calculation. There are several ways to implement this. The Bash shell comes with built-in support for arithmetic operations, but there are some limitations to this. Specifically, the arithmetic capabilities of Bash are limited in the following ways: 

Only operations with whole numbers (integers) can be performed.



All values are signed 64-bit values. Thus, possible values range from -263 to +263-1.

So when using Bash, you might need to use external commands, such as bc, for floating-point calculations. The following paragraphs list all possible methods and formats for arithmetic operations. All of them are based on this sample operation: B=5 A=B+10 

Use the external command expr (Bourne shell compatible) A=$(expr $B + 10)

Since an external command is used, this method will also work with the traditional Bourne shell. Scripts using external commands will always perform slower than those relying on built-in commands. 

Use the Bash built-in command let let A="$B + 10"

In Bash, you can use the let command to perform an arithmetic expression. 

Use arithmetic expressions inside parentheses or brackets (two different formats) A=$((B + 10))

or A=$[B + 10]

Arithmetic expressions can be enclosed in double parentheses or in brackets for expansion by Bash. Both $((. . .)) and $[. . .] are possible, but the latter is considered deprecated and should be avoided. 

Use the built-in command declare declare -i A declare -i B A=B+10

This declares a variable as an integer. If all variables involved in a calculation have previously been declared as integers through declare -i, arithmetic evaluation of these variables happens automatically when a value is assigned to them.

Version 1


325






This means that the variable B, for example, does not have to be prefixed with the $ to be evaluated. With the expr command, only the following five operators are available: + - * / and % (modulo, remainder of a division). Additional operators (which are identical to those of the C programming language) can be used with all of the above Bash formats. NOTE: For a complete list, consult the man page for Bash.

We can use an arithmetic operator to modify the backup script to change the condition of the while loop. Instead of testing for the content of $1, we can count down the number of positional parameters until all are processed. The while loop in the script could look like the following: count=1 PARAMNUM="$#" # # The backup of the directories listed on the command line # while test "$count" -le "$PARAMNUM" do echo -e "\nBacking up ""$1"" to /backup/" rsync -av --no-whole-file "$1" /backup count=$(($count + 1)) shift done

We create the count variable and assign the value 1 to it. The variable PARAMNUM is set to the number of parameters included on the command line ($#). In the while loop, the value of count is increased by one each time the loop is run through. When the value of count is greater than PARAMNUM the processing of the loop ends. Instead of count=$(($count + 1))

the following syntax could be used as well: ((count++))

326


Version 1


Exercise 8-5

Use Arithmetic Operators In this exercise, you use arithmetic operators. You will find this exercise in the workbook. (End of Exercise)

Version 1


327






Objective 6

Read User Input One way to read user input is to use the read command. The read command takes a variable as an argument and stores the read input in the variable. The variable can then be used to process the user input. The following example reads user input into the variable with the name VARIABLE: read VARIABLE

The script pauses at this point, waiting for user input, until the Enter key is pressed. To tell the user to enter something, you need to print (echo) a line with some information, such as the following: echo "Please enter a value for the variable:" read VARIABLE

If you do not add a variable name after “read”, the user input is assigned to the variable REPLY. You can also specify more than one variable, like in the following example: read FIRST SECOND REST

In this example, the first word entered is assigned to the variable FIRST, the second to the variable SECOND, and all subsequent words to the variable REST. If only one word is entered, the variables SECOND and REST are assigned empty values. If you want to change the backup script to inform the user that he can back up additional directories and ask for them, instead of expecting them on the command line, a possible solution could look like this: #!/bin/bash # # read_input1.sh # # This script does the following: # - Back up directories or files entered by user # - Back up someone's home directory to /backup using rsync # - Write a log file in the format backup-log_YYYYMMDD-hhmm # and that contains the names of the files backed # - Send log files per mail # # Variables: # USERNAME="geeko" NOW="$(date ’+%Y%m%d-%H%M’)" DIRECTORIES="" # # Get input from user # cat <
328


Version 1


as well as any files and directories you specify here. Type their names separated by spaces, then press Enter. If you do not want to back up additional directories, just press Enter. EOF read DIRECTORIES # # Back up the directories entered by user # for i in $DIRECTORIES do echo -e "\nBacking up ""$i"" to /backup/" rsync -av --no-whole-file "$i" /backup done ...

The for loop is entered for each element contained in the DIRECTORIES variable (which may not be enclosed in quotation marks in the line starting with for, to keep the directories entered by the user as separate directories). If the variable is empty, the for loop is not run through. NOTE: This approach does not work for files or directories with spaces in their names.

Version 1


329






Exercise 8-6

Read User Input In this exercise, you read user input and process the input in your script. You will find this exercise in the workbook. (End of Exercise)

330


Version 1


Objective 7

Use Arrays Arrays are basically variables that can hold more than one value. To identify a value in an array, a numerical index is used. The index is written in square brackets after the array name. lines[0]="Hello World"

This line assigns the string “Hello World” to the index 0 of the array with the name lines. To access a value in an array, you have to specify an index and put braces around the array name: echo ${lines[0]}

Arrays are very useful to store list data like a list of files, names, or similar data. We can use an array to store the files or directories the user wants to back up. He enters one after the other, which makes it easier to deal for instance with space characters. The first part would be to fill an array with the filenames; the second part would be to back up those files. Look at the following modifications of the backup script (from now on we will list only those parts of the code that have been modified): DIRECTORY="" counter=0 # # Get input from user # cat <
Version 1


331






# Process user input, then prompt again while test -n "$DIRECTORY" do TOBACKUP[$counter]="$DIRECTORY" ((counter++)) DIRECTORY="" read DIRECTORY done fi # # Back up the directories entered by user # for i in ${TOBACKUP[@]} do echo -e "\nBacking up ""$i"" to /backup" rsync -av --no-whole-file "$i" /backup done # # # The same, a bit more complicated: # #for ((i=0;i<${#TOBACKUP[@]};i++)) #do # echo -e "\nBacking up ${TOBACKUP[$i]} to /backup" # rsync -av --no-whole-file "${TOBACKUP[$i]}" /backup #done

In the while loop, the requests are stored into the array TOBACKUP. The variable counter, which is initialized at the start of the script and is used as an index, is incremented in every cycle of the while loop. In the for loop, the content of the array is integrated into an rsync command. In the second example (lines starting with a comment character) a different syntax for the for loop is used, which is similar to the for loop in the C programming language. for ((i=1;i<${#TOBACKUP[@]};i++)) means that the loop runs as long as the variable i is less than (<) the number of elements in the array TOBACKUP. ${#TOBACKUP[@]} is a way to access the number of elements in an array. The index variable i is initially set to 0 and incremented with every cycle of the for loop.

332


Version 1


Exercise 8-7

Use Arrays In this exercise, you use arrays. You will find this exercise in the workbook. (End of Exercise)

Version 1


333






Objective 8

Finalize the Course Project Sometimes you do not need the last version of a file, but rather the version of the file from a day, a week, or a month ago. You could of course simply make a separate full backup of your home directory every few hours, but that would consume a lot of storage space. rsync has a feature that is probably not so well known that allows to create backups to different directories—but instead of creating a copy of an unchanged file, only a hard link to the file in the earlier backup is created. This feature allows you to keep many earlier versions of files, as only those files actually changed or added get copied, saving storage space. What you need: 

An initial first backup This can be done with the rsync command we used so far; however, you should use a directory name for your backup that is based on date and time. NOW="$(date ’+%Y%m%d-%H%M’)" # # If there is no directory /backup/YYYYMMDD-hhdd then this is # probably the first run of the script. # # Creation of the first backup: ls -d /backup/20??????-???? > /dev/null 2>&1 || rsync -a \ /home/"$USERNAME" /backup/"$NOW"



An rsync command that creates a backup in a separate directory with links against the previous backup. # # Establish the last backup directory # LAST_BACKUP_DIR="$(basename $(ls -d /backup/20*-* | sort | \ tail -1))" # # Backup linked against the previous backup # rsync -aA --link-dest=/backup/"$LAST_BACKUP_DIR" \ /home/"$USERNAME" /backup/"$NOW"



334

A command that deletes the oldest version of the backups.


Version 1


# # Remove past backup directories # cd /backup || exit 2 # Let's keep a maximum of 100 past backups/versions if [ "$(ls -d 20*-* | wc -l)" -gt 100 ] ; then rm -r $(ls -d 20*-* | sort | head -1) fi 

A cron job that runs the backup as often as you need it, such as every two hours during work hours, daily, or weekly. Using the crontab -e command, you could define the following cron job: 10 */2 * * * /home/geeko/bin/versioned-backup1.sh

With the topics covered in this section, you could add several additional features to the script:

Version 1



A list of files that should not be backed up, such as those in the browser cache directory (for instance, using a here document to write a temporary file from the script, using the --exclude-from= option of rsync, and deleting the file at the end of the script).



Use of the trap command to delete the temporary file despite the fact the user ended the script with Ctrl+c.



Log files and mail messages as covered previously.


335






Exercise 8-8

Use rsync to Keep Versions of Files In this exercise, you use rsync to keep past versions of your files. You will find this exercise in the workbook. (End of Exercise)

336


Version 1


Objective 9

Use Advanced Scripting Techniques In this objective, you learn about the following advanced scripting techniques, which will help you solve common script development problems: 

“Use Shell Functions” on page 337



“Read Options with getopts” on page 338

Use Shell Functions Sometime you need to perform a task multiple times in a shell script. Instead of writing the same code again and again, you can use functions. Shell functions act like script modules because they make an entire script section available under a single name. Shell functions are normally defined at the beginning of a script. You can store several functions in a separate file and include this file whenever the functions are needed in your current script using the command source /path/filename

There are two ways to declare a function in a script. The following is the basic syntax of a function: functionname () { commands commands }

The following generates a function with the function command: function functionname { commands commands }

The name of the function can be composed of any regular character string. The following is a simple function that creates a directory and then changes to that directory: # mcd: mkdir + cd; creates a new directory and # changes into that new directory right away mcd (){ mkdir $1 cd $1 }

After having been created, this function can be called in a shell script, as in the following: ... mcd /tmp/new_directory ...

Version 1


337






The parameter /tmp/new_directory is called an argument. Within a function, arguments can be accessed with the variables $1, $2, $3, and so on, depending on the number of arguments passed to the function. The following function can be used to create a pause in a script. The script resumes only after the Enter key is pressed: # pause: causes a script to take a break pause (){ echo "To continue, hit RETURN." read q }

You can also create functions that stop their processing from within, similar to exiting a loop (iteration), with the break and continue commands. To exit a function, use the return command. If return is called without an argument, the return value of the function is identical to the exit status of the last command executed in that function. Otherwise, the return value is identical to the one supplied as an argument to return. NOTE: The command typeset -f shows the functions defined in the current shell.

Read Options with getopts With the shell built-in command getopts, you can extract the options supplied to a script on the command line. The shell interprets command line arguments as command options only if they are prefixed with a - (the default when using the shell interactively). This makes it possible to place options in different positions on the command line and to supply them in an arbitrary order. This means that the command: cp -dpR *.txt texts/ achieves the same thing as the command cp -R *.txt -d texts/ -p getopts recognizes options in the same way. The following is the getopts syntax: getopts optionstring variable The optionstring describes all options to be recognized. For instance, getopts abc declares a, b, and c as the options to be processed. If a parameter is expected for the option (such as -m maxvalue), the corresponding option must be followed by a : in the string (as in getopts m:). The option string is followed by a variable which all the command line options specified are assigned to as a list.

338


Version 1


The getopts command is most frequently used in a while loop together with case to define which command to execute for a given option, as in the following: while getopts abc:d:e variable do case $variable in a ) echo "The option -a was b ) echo "The option -b was c ) option_c="$OPTARG" echo "Option c has been d ) option_d="$OPTARG" echo "Option d has been e ) echo "the option -e was esac done echo

used." ;; used." ;; set to $option_c." ;; set to $option_d." ;; used." ;;

If the option -a , -b, or -e is used, the script prints out a message that the corresponding option was used. If the option -c value is used, the value is assigned to the variable option_c and printed on the screen, same with option -d and the variable option_d. The parameter of an option can be accessed with the variable OPTARG. NOTE: When no parameter is supplied to an option that expects one, the result can be unexpected. For instance if the user enters -d -e in the above example, the OPTARG variable for -d contains -e, and -e is not recognized as an option of its own.

Version 1


339






Exercise 8-9

Use Shell Functions In this exercise, you learn how to use shell functions. You will find this exercise in the workbook. (End of Exercise)

340


Version 1


Objective 10

Learn about Useful Commands in Shell Scripts This objective gives you an overview of useful commands that are frequently used in shell scripts. This objective discusses the following: 

“Use the cat Command” on page 341



“Use the cut Command” on page 341



“Use the date Command” on page 342



“Use the grep and egrep Commands” on page 342



“Use the sed Command” on page 343



“Use the test Command” on page 345



“Use the tr Command” on page 347

Use the cat Command When combined with the here operator (<<), the cat command is a good choice to output several lines of text from a script. In interactive use, the command is mostly run with a filename as an argument, in which case cat prints the file contents on standard output.

Use the cut Command The cut command is used to cut out sections of lines from a file so that only the specified section is printed on standard output. The command is applied to each line of text as available in a file or on standard input. You can use cut -f to cut out text fields. cut -c works with the specified characters. You can specify single sections (characters or fields) or several sections. The default delimiter to separate fields from each other is a tab, but you can specify a different field separator with the -d option. The following are some examples of using cut: geeko@da10:~> cut -d : -f1 /etc/passwd root bin daemon lp mail news

Version 1


341






The above command specifies that the field separator should be a colon. In every line of /etc/passwd, the field that comes before the first colon is taken and printed to stdout: geeko@da10:~> ls -l somedir/ | cut -c 27- | sort -n 687 Sep 20 17:06 file2 2199 Sep 20 17:05 file1 6593 Sep 20 17:06 file3

The above command takes the output of the ls command and cuts out everything from the twenty-seventh character. This is piped to sort, so the final output is sorted according to file size.

Use the date Command You can use the date command whenever there is a need to obtain a date or time string for further processing by a script. Without any options specified, the command’s output looks like the following: geeko@da10:~> date Sat Mar 14 15:58:46 CET 2009

The date command lets you change the output format in almost every detail. With the -I option (as in the following), date prints the date and time in ISO format (which is the same as if the options had been +%Y-%m-%d): geeko@da10:~> date -I 2009-03-14 geeko@da10:~> date "+%m-%d %H:%M" 03-14 16:01 geeko@da10:~> date date "+%D, %r" 03/14/09, 04:02:34 PM geeko@da10:~> date +%d.%m.%y 14.03.09 geeko@da10:~> date +%d.%m.%Y 14.03.2009 geeko@da10:~> date "+%e.%-m.%y, %l.%M %p" 14.3.09, 4.05 PM geeko@da10:~> date "+%A, %e. %B %Y" Saturday, 14. March 2009 geeko@da10:~> date

To view a list with all the possible format options for date, see man date. You should be able to customize the output to exactly match the requirements of your script.

Use the grep and egrep Commands The command grep and its variant egrep are used to search files for certain patterns, and they use the following syntax:

342


Version 1


grep searchpattern filename ... The command prints lines that contain the given search pattern. You can specify several files, from which grep will print the matching line and the corresponding filenames. Several options are available to specify that only the line number should be printed, for instance, or that the matching line should be printed together with leading and trailing context lines. Search patterns can be supplied in the form of regular expressions, although the grep command is limited in this regard. To search for more complex patterns, use the egrep command, which accepts extended regular expressions. As a simple way to deal with the difference between the two variants, make sure you use egrep in all of your shell scripts. The regular expressions used with egrep need to be in accordance with the standard regex syntax. To avoid having special characters in search patterns interpreted by the shell, enclose the pattern in quotation marks, as in the following: geeko@da10:~> egrep (b|B)lurb file* bash: syntax error near unexpected token geeko@da10:~> egrep "(b|B)lurb" file* file1:blurb file2:Blurb

|

Use the sed Command The sed program is a stream editor, used from the command line rather than interactively. sed performs text transformations on a line-by-line basis. You can specify sed commands either directly on the command line or in a special command script loaded by the program on execution. The following is the syntax for the sed command: sed editing-command filename The available editing commands include single-character arguments such as the following: 

d: Delete



s: Substitute (replace)



p: Output line



a: Append after

As with other commands, the output of sed normally goes to standard output, but it can also be redirected to a file. Apart from the single-character commands for text transformations, you can also specify options to influence the overall behavior of the sed program.

Version 1


343






The following are some important command line options for sed: 

-n, --quiet, --silent: By default, sed will print all lines on standard output after they have been processed. This option suppresses the output so sed prints only those lines for which the p editing command has been given to explicitly reenable printing.



-e command1 -e command2 ...: This option is necessary when specifying two or more editing commands. It must be inserted before each additional editing command.



-f filename: With this option, you can specify a script file from which sed should read its editing commands.

Each sed command must be preceded by an exact address or address range specifying the lines to which the editing command applies. One of the more frequently used address labels is $, which stands for the last line. The following are two examples of the sed command: 

sed -n

’1,9p’ somefile

This command prints only lines 1 through 9 on stdout. 

sed ’10,$d’ somefile This command deletes everything from line 10 to the end of the file and also prints the first 9 lines of somefile.

You can use a regular expression to define the address or address range for an editing command. Regular expressions must be enclosed in forward slashes. If an address is defined with such an expression, sed processes every line that includes the given pattern. The following is an example of using regular expressions: sed -n ’/Murphy.*/p’ somefile This example prints all lines that have the pattern Murphy.* in them. If you want sed to perform several editing commands for the same address, you need to enclose the commands in braces, as in the following: sed ’1,10{command1 ; command2}’ The following lists the most important editing commands available for sed: Table 8-1

344

sed Commands Command

Example

Editing Action

a

sed ‘a\text\text’ file

Insert text before the specified line.

c

sed ‘2000,$c\text ‘ file

Replace specified lines with the text.

d

sed 10,$d file

Delete line.

i

sed ‘i\text\text’ file

Replace specified lines with the text.


Version 1


Command

Example

Editing Action

s

sed s/x/y/option

Search and replace. The search pattern x is replaced with pattern y. The search and the replacement pattern are regular expressions in most cases, and the search and replace behavior can be influenced through various options.

y

sed y/abc/xyz/

Replace every character from the set of source characters with the character that has the same position in the set of destination characters.

You can use the following options with the s command (search and replace): 

I: Do not distinguish between uppercase and lowercase letters.



g: Replace globally wherever the search pattern is found in the line (instead of replacing only the first instance).



n: Replace the nth matching pattern only.



p: Print the line after replacing.



w: Write the resulting text to the specified file rather than printing it on stdout.

The following are some examples of using the s command: 

sed ’s/:/ /’ /etc/passwd This replaces the first colon in each line with a space.



sed ’s/:/ /g’ /etc/passwd This replaces all colons in all lines with a space.



sed ’s/:/ /2’ /etc/passwd This replaces only the second colon in each line with a space.



sed -n ’s/$[aeiou]$/\1\1/Igp’ This replaces all single vowels with double vowels. The example shows how matched patterns can be referenced with “\1” if the search pattern is given in parentheses (which have to be escaped). The I option ensures that sed ignores the case. The g option causes characters to be replaced globally. The p option tells sed to print all lines processed in this way.

Use the test Command The test command exists both as a built-in command and as an external command. It is used to compare values and to check for files and their properties (whether a file exists, whether it is executable, and so on). If a tested condition is true, test returns an exit status of 0; if the condition is not true, the exit status is 1. In shell scripts, test is used mainly to declare conditions to influence the operation of loops, branches, and other statements. The following is the test syntax:

Version 1


345






test condition or [ condition ] You can use the test command to do the following: 

test Options for Files

Table 8-2



Option

Description

-d

File exists and is a directory

-e

File exists

-f

File exists and is a regular file

-x

File exists and is an executable file

Compare two files. Following are some of the available operators: test Options for Files

Table 8-3



Option

Description

-ef

Refers to the same inode (such as a hard link)

-nt

Newer than

-ot

Older than

Compare two integers. The available operators are: test Options for Integers

Table 8-4



346

Test whether a file exists. Following are some of the available options:

Option

Description

-eq

Equal to

-ge

Greater than or equal to

-gt

Greater than

-le

Less than or equal to

-lt

Less than

-ne

Not equal to

Test strings. Following are some of the available operators:


Version 1


test Options for Strings

Table 8-5

Option

Description

test -z string

Exit status is 0 (true) if the string has zero length (is empty)

test string

Exit status is 0 (true) if the string has nonzero length (consists of at least one character)

(same as test -n string)



Table 8-6

test string1 = string2

Exit status is 0 (true) if the strings are equal

test string1 != string2

Exit status is 0 (true) if the strings are not equal

Combine tests. Following are some of the available operators: test options for Conditions Option

Description

test ! condition

Exit status is 0 (true) if the condition is not true.

test condition1 -a condition2

Exit status is 0 (true) if both conditions are true.

test condition1 -o condition2

Exit status is 0 (true) if either condition is true.

NOTE: For more detailed information about test, in a terminal window enter help test or man test (the built-in test command and the external one have identical features).

Use the tr Command The tr command translates (replaces) or deletes characters. It reads from standard input and prints the result on standard output. With tr, you can replace regular characters or sequences of such characters and special characters like \t (horizontal tab) or \r (return). A complete list of all special characters handled by tr is included in the man page of the program. The following is the standard syntax of tr: tr set1 set2 The characters included in set1 are replaced with the characters included in set2. The following is an example of using the tr command: cat text-file | tr a-z A-Z

Version 1


347






This command causes all lowercase characters in a file to be changed to uppercase, and the result is printed to stdout. You can use tr to delete characters from the first set by entering the following: tr -d set1 This will not translate anything; it only deletes the characters included in set1, printing the rest to standard output. The following is another example of using the tr command: VAR=’echo $VAR | tr -d %’ In this example, tr deletes the percent sign from the original value of VAR and the result is assigned as a new value to the same variable. By entering a command like tr -s set1 char you can also use tr to replace a set of characters with a single character.

348


Version 1


Summary Objective

Summary

Bash Basics

The Bourne Again SHell (Bash) is the default shell in SUSE Linux Enterprise 11. On the command line, you enter the command and optional parameters. The output of a command can be redirected to a file using the > (or >>) operator. Error messages can be redirected to a file using the 2> operator. Use 2>&1 to redirect error messages to file descriptor 1 instead of 2. The output of one command can be used as input of another command using the pipe (|) operator. Variable are used to store and access data in memory during the execution of a program. Based on the return value of a program, decisions can be made regarding the next steps to be take within a script.

Use Basic Script Elements

A shell script is basically an ASCII text file containing commands to be executed in sequence. To allow this, it is important that permissions for the script file are set to r (readable) and x (executable) for the user that runs it. Any command you use at the command line can also be used in a shell script. A shell script always starts with a line like #!/bin/ bash to indicate the interpreter of the script.

Understand Variables and Command Substitution

Variables are an important component of all programming languages. You can consider variables as containers that hold data. Instead of the data itself, the variable is used in the program code. When you assign a variable, you use just the name of the variable. When you access the data of a variable, you put a $ before the variable name. The term command substitution basically means that the output of a command is used in a shell command line or a shell script. The commands are included in $(...).

Use Control Structures

Control structures are used to make the execution of parts of a script dependent on certain conditions or to repeat parts of a script. Branches can be created with if or case. Loops are implemented with while, until, or for.

Version 1


349






Objective

Summary

Use Arithmetic Operators

Shell scripts often use values assigned to variables for calculation. There are several ways to implement this. The Bash shell comes with built-in support for arithmetic operations, but there are some limitations to this. The arithmetic capabilities of Bash are limited in the following ways: 

Only operations with whole numbers (integers) can be performed.



All values are signed 64-bit values. Thus, possible values range from -263 to +263 -1.

For flaoting point operations you need to use external commands, such as bc, when working with bash. Read User Input

One way to read user input is to use the read command. The read command takes one or several variables as arguments and stores the read input in the variable or variables. The variables can then be used to process the user input. The following example reads user input into the variable with the name VARIABLE: read VARIABLE

Use Arrays

Arrays are basically variables that can hold more than one value. To identify a value in an array, a numerical index is used. The index is written in square brackets after the array name. lines[1]=”Hello World” This line assigns the string “Hello World” to the index 1 of the array with the name lines. To access a value in an array, you have to put braces around the array name: echo ${lines[1]}

Finalize the Course Project

In this objective, you created a backup script that keeps versions of files.

Use Advanced Scripting Techniques In this objective, you learned how to create and use shell functions and how to evaluate command line options.

350


Version 1


Version 1

Objective

Summary

Learn about Useful Commands in Shell Scripts

Useful commands that can be used in shell scripts include the following: 

cat



cut



date



grep



sed



test



tr


351






352


Version 1


SECTION 9


This section explains how to deploy SUSE Linux Enterprise 11 (SLE11), which refers to both SUSE Linux Enterprise Server 11 (SLES11) and SUSE Linux Enterprise Desktop 11 (SLES11). Which deployment method you choose will depend to a large degree on the number of desktops or servers you want to deploy. The installation of hundreds of machines requires a different approach than the installation of just one or a few. Objectives

Version 1

1.

“Introduction to AutoYaST” on page 354

2.

“Installation Server: Setup and Use” on page 358

3.

“Set Up PXE Boot for Installations” on page 371

4.

“Create a Configuration File for AutoYaST” on page 381

5.

“Perform an Automated Installation” on page 385


353






Objective 1

Introduction to AutoYaST This objective covers the basic concept of automated installation. Later objectives go into the details of setting up an environment that makes automated installations easy and explains how to configure the AutoYaST control file. To get a better idea what automated installations are about on SUSE Linux Enterprise 11, you need to understand the following: 

“Autoinstallation Basics” on page 354



“Installation Options and Deployment Strategies” on page 355

Autoinstallation Basics AutoYaST is the tool for automated installations of SUSE Linux Enterprise 11. All information needed during installation (e.g., partitioning or software selection) is provided by a control file in XML format. No manual intervention is necessary during the installation process. If you have to install several systems with the same setup, you can save time by automating the installation. Depending on your requirements, you can ensure all systems are set up with the same configuration or configure systems individually with specific control files. You should not confuse auto installation with cloning or imaging. An automated installation is a regular installation where answers to questions asked during the installation are contained in the control file. The hardware detection is still done so that the same control file can be used on diverse hardware. Imaging or cloning generally requires identical hardware of source and target of the image. AutoYaST is optimally used in conjunction with an installation server also providing a TFTP and a DHCP server. The advantages to this are the following: 

To start the installation, you only have to insert a suitable boot disk. If you are using PXE boot-enabled network interface cards, not even a boot disk is required.



The computer receives all information necessary for the installation via the network.



Even on-site attendance of an administrator is unnecessary for the installation if the network card supports Wake on Lan.

The installation server can be accessed via the NFS, HTTP, FTP, and CIFS/SMB protocols. This results in a highly simplified installation of a large number of individually configured computers. AutoYaST can also be used to copy additional files into the installed system, and it can include scripts which are executed at the end of the installation. It is possible to create a control file at installation time. In the last menu of the installation process, you can select the Clone This System option. This will create an

354


Version 1


autoinst.xml file in the home directory of the root user (/root). The creation of an AutoYaST control file using the YaST AutoYaST module is covered later in this section.

Installation Options and Deployment Strategies For a single machine, a manual installation using the installation DVD is certainly the best option. However, alternatives are needed when the number of machines to install increases. The installation can be started using the SUSE Linux Enterprise Desktop or Server 11 DVD, a PXE capable network card, or boot floppy disks. The installation source can be the DVD itself as well as an installation server in the network. The supported protocols for accessing the repository on the installation server are NFS, HTTP, FTP, and SMB/CIFS. To find the optimum solution for your needs, you have to understand the following: 

“Installation Options” on page 355



“Deployment Strategies” on page 356

Installation Options

SUSE Linux Enterprise 11 can be installed in various ways. There are three aspects you need to consider: 

“Boot Media” on page 355



“Installation Source” on page 356

Boot Media

To install a machine, you have to choose a boot medium to boot the machine. 

Installation DVD The installation DVD is bootable and can be used to start the installation or to boot a rescue system. Different kernel parameters can be set if there is trouble with the default parameters. For example, it is possible to disable ACPI or local APIC or to use safe settings.



PXE capable network card If the machine is equipped with a PXE capable network card, it can load the boot image from a TFTP server in the network. If the network card also supports Wake on Lan, a completely remote installation is possible.



Floppy or USB disk If your hardware supports it, you can use floppy disks or an USB device to boot the machine. However, current computers are generally not equipped with floppy drives any more, and not all BIOSes allow booting from USB devices.

Version 1


355






To create boot floppy disks or make a USB stick bootable, run the mkbootdisk command in the boot/i386 directory of the installation DVD. mkbootdisk -help displays the needed options and syntax. Installation Source

You can use different installation sources: 

Installation DVD The installation DVD contains all files needed to install SUSE Linux Enterprise Desktop or Server 11.



Installation Server The files needed for installation can be stored on a server in the network. Protocols that can be used are HTTP, FTP, NFS, or SMB/CIFS. SLP can be used to advertise the installation server in the network.

Deployment Strategies

Your deployment strategy will depend to a large degree on the number of machines to deploy. Let’s consider three different orders of magnitude: 

“Deploy up to 10 Workstations” on page 356



“Deploy up to 100 Workstations” on page 356



“Deploy More than 100 Workstations” on page 357

Deploy up to 10 Workstations

If you have to deploy only a few workstations, it might not be worth the effort to set up an installation server, much less to create an AutoYaST control file. The approach that takes the least preparation is a manual installation using the installation DVD. As an installation server is very convenient and does not take long to set up, you might still consider using one. Additional installations will be facilitated and also adding software to existing installations later will not require the installation DVD to be at hand. Setting up an installation server is covered in ““Installation Server: Setup and Use” on page 358. Deploy up to 100 Workstations

If you have to deploy more than 10 workstations, an installation server and the use of the remote installation capabilities of SUSE Linux Enterprise 11 greatly facilitate the task. While physical access to the machines is still required to boot them, you do not need to sit in front of each machine during the whole installation. Using remote access via VNC or SSH, the administrator can control the installation of different machines at the same time from his workstation.

356


Version 1


Setting up DHCP and TFTP servers in addition to the installation server makes it unnecessary to physically access the machines to boot them, provided the hardware allows booting from the network as well as Wake on Lan. Without AutoYaST, you would still have to configure them manually via the network. The more machines you have to install, the more worthwhile it becomes to avoid the manual configuration. The effort to create and test workable AutoYaST control files is outweighed by the reduced time spent on configuring individual machines. Deploy More than 100 Workstations

With so many machines, walking from machine to machine to install them all is no longer an option. Even remote configuration becomes cumbersome. The roll-out of a large number of machines is facilitated by AutoYaST. AutoYaST controls the installation with an XML file which contains the machine specific information, like IP address, hostname, partitioning, etc. Manual intervention during the installation process is unnecessary. AutoYaST allows you to create profiles containing all configuration information. As the hardware detection of YaST is used during installation, the same file can be used to install machines with dissimilar hardware. If the differences in hardware are significant, it is also possible to create rules that determine which of several AutoYaST files should be used for the hardware found. Not only the hardware can serve as criteria, but other parameters like IP addresses can be used as well. You could create different profiles for development workstations and for workstations used in HR, and then base the decision of which profile to use for installation on the IP address the workstation gets via DHCP.

Version 1


357






Objective 2

Installation Server: Setup and Use An installation server offers the files needed for the installation of SUSE Linux Enterprise Desktop or Server 11 via the network. To provide such a server in your network, you need to understand how to do the following: 

“Set Up an Installation Server” on page 358



“Use the Installation Server” on page 369

Set Up an Installation Server The installation repository requires the same layout of directories and files as the layout on the installation DVD. The most convenient way to set up such an installation repository is to use SUSE Linux Enterprise Server 11 and its YaST Installation Server module. This module creates the necessary directory structure, prompts to insert the DVD to copy its content to the proper directories, and sets up the server (NFS, HTTP, FTP) used to distribute the files. NOTE: Using SUSE Linux Enterprise Desktop 11 as an installation server is also possible, but you have to set up the server manually because there is no YaST module for this purpose included in the Desktop distribution.

The following steps are required: 

“Fill the Installation Repository” on page 358



“Make Add-on-Products Available” on page 359

Fill the Installation Repository

First create a directory where you want to store the installation repository, such as / srv/install-repo/sled11 for SLED11, using the command mkdir -p / srv/install-repo/sled11. Filling the repository is very simple: Just insert the SUSE Linux Enterprise Desktop 11 installation DVD and copy all files on it to the repository: cp -a /media/SUSE_SLED-11-0-0.001/* /srv/install-repo/ sled11 NOTE: The same procedure is used for SUSE Linux Enterprise 11 service packs, as they replace the original installation media.

358


Version 1


Make Add-on-Products Available

In addition to the packages available for installation on the DVD, it is possible to make further packages available. The directory structure described in the following can be used for updates, add-on products, or RPM packages of your own. You can set up the add-on products repository using the YaST Add-On Creator module or command line commands. To access the add-on products repository during the automatic installation, you can either include a pointer to it in the AutoYaST control file or add an add_on_products.xml file to the root of your product installation repository. This manual covers the following two approaches: 

“Yast Add-On-Creator Module and autoinst.xml” on page 359



“Manual Creation of Repository and add_on_products.xml file” on page 365

Yast Add-On-Creator Module and autoinst.xml

The YaST Add-On Creator module guides you through the steps necessary to create a repository with the correct layout of directories and files. Take the following steps to create an add-on repository and to modify your control file: 1.

(Conditional) If you have not created a gpg key pair, in a terminal window (as root) enter the command gpg --gen-key and follow the prompts to create your own key pair.

Version 1

2.

Copy the RPM files you want to include in your add-on repository to a temporary directory, such as /tmp/repo-files.

3.

Start YaST and select Miscellaneous > Add-On Creator.


359






The following dialog appears: Add-On Product Creator

Figure 9-1

To create an add-on repository from scratch, select Create an Add-On from the Beginning and click Next. 4.

360

In the Add-On Product Creator dialog that appears, fill in the text boxes with the name and version of your repository and the directory that holds your RPM files.


Version 1


The dialog will look similar to the following. Figure 9-2

Add-On Product Creator

To continue click Next.

Version 1


361






A Product Definition dialog appears, as shown in the following: Product Definition

Figure 9-3

5.

In the Product Definition dialog, select Vendor and click Edit. In the dialog that appears, enter a vendor name, such as your company name or the name of the provider of the RPM files. In the Product Definition dialog click Next. The Package Descriptions dialog appears.

6.

The Package Descriptions dialog lists the packages that are part of your add-on repository. To continue click Next. The Editor for Patterns dialog appears.

7.

362

In the Editor for Patterns dialog, you can create Patterns for your add-on products. To continue click Next.


Version 1


The Output Settings dialog appears, as shown in the following: Output Settings

Figure 9-4

8.

In the Path to Output Directory text box, type the directory where you want your add-on product repository to reside. To continue click Next. A Signing the Add-On Product dialog appears.

9.

In the GPG Key ID text box, type the ID, such as the e-mail address you entered during the creation of your key pair, of the GPG key you want to use to sign the content file in the root of the repository. Type the passphrase to unlock the private key and click Next to continue. An Overview dialog appears.

10. In the Overview dialog review your settings and click Finish.

Version 1


363






An Add-On Creator Overview dialog appears, as shown in the following: Figure 9-5

Add-On Creator Configuration Overview

11. In the Add-On Creator Overview, click Build.

(Optional) If a message appears that informs you that the obs-productconverter package needs to be installed, click Install. The directory structure for the repository is created, the RPMs are copied to their correct location and content files in the root of the repository are created and signed. 12. Click Finish to close the Add-On Creator module. 13. Open the AutoYaST profile used to install machines in an editor and add the

following lines below the line starting with nfs://172.17.8.1/srv/install-repo/Add-On My Add-Ons / My Add-Ons 14. In the AutoYaST profile, look for the line false

364


Version 1


Change the value from false to true. The line should look like the following: true

Save the file and close the editor. NOTE: The creation of an AutoYaST profile is explained in “Create a Configuration File for AutoYaST” on page 381.

Manual Creation of Repository and add_on_products.xml file

Instead of using YaST, you can also use command line tools to create the repository layout and files. If you want to use an add_on_products.xml file in the root directory of the product installation repository, you have to sign a file containing a checksum of the add_on_products.xml file and to include the GPG public key in the initial ramdisk used during installation. NOTE: When you use an add_on_products.xml file as described in the following steps it is not necessary to add an ... section to the AutoYaST profile used to install the individual machines.

Take the following steps to set up your repository and use the add_on_products.xml file during installation: 1.

(Conditional) If you have not created a gpg key pair, in a terminal window (as root) enter the command gpg --gen-key and follow the prompts to create your own key pair.

2.

Install the inst-source-utils package if it is not yet installed by entering the following as root in a terminal window: rpm -q inst-source-utils || yast -i inst-source-utils

3.

Run the following command with the root of your installation repository as argument:

da10:~ # create_update_source.sh /srv/install-repo/sled11/ Creating /srv/install-repo/sled10//updates.....

This will create the updates and yast directories with several subdirectories and files within your installation repository. NOTE: Despite the fact that the directory created is named updates, it can be used for add-on products as well. 4.

Version 1

Using the mkdir -p command, create the updates/suse/ architecture/ directory and copy any RPM files you want to make available to that directory.


365






NOTE: The following steps have to be repeated every time you change the content of this directory (i.e., add or delete files to it). 5.

Change to the updates/suse directory and run the following command:

da10:/srv/install-repo/sled11 # cd updates/suse da10:/srv/install-repo/sled11/updates/suse # da10:/srv/install-repo/sled11/updates/suse # create_package_descr -x setup/descr/EXTRA_PROV using settings: datadirs: . languages: english output dir: ./setup/descr/ is not a directory: ignoring extra_provides: setup/descr/EXTRA_PROV done processed 1 packages now recoding to UTF-8: packages packages.DU packages.en da10:/srv/install-repo/sled11/updates/suse #

This creates the packages, packages.DU, and packages.en files in the updates/suse/setup/descr directory. 6.

Change to the directory updates/suse/setup/descr and create an updated directory.yast file:

da10:/srv/install-repo/sled11/updates/suse/setup/descr # ls > \ directory.yast 7.

Change back to the updates directory and run the create_sha1sums -x -n command. The result is a contents file that contains SHA1 hashes for the files created in the previous step:

da10:/srv/install-repo/sled11/updates/ # create_sha1sums -x -n da10:/srv/install-repo/sled11/updates/ # cat content CONTENTSTYLE 11 ... SUMMARY SUSE Linux Enterprise Server VENDOR SUSE LINUX Products GmbH, Nuernberg, Germany VERSION 11 META SHA1 b907a3d5593c3a2f0108f9ba27e3c5b8ef0121d5 packages META SHA1 4a0c3656cd8c61a68cccf2c75ec83f1f132556ec packages.DU META SHA1 94e8d1bf3d7b53fd7c8ce32d6f6ea70cf47ede87 packages.en 8.

366

Create an add_on_products.xml file in the root of your installation repository that points to the servers and directories with add-on products:


Version 1


SLED11 Add-on nfs://172.17.8.1//srv/install-repo/sled11/ updates / false true 9.

Create a file containing the SHA1 sum of the add_on_products.xml file. With SLE 11, every file on the installation source needs a checksum in a content or a SHA1SUMS file, and those files have to be digitally signed. These signatures are checked during installation. For your own repositories, you need to sign them and make the signing key available during installation. Run the sha1sum command to create the checksum:

da10:/srv/install-repo/sled11/ # sha1sum add_on_products.xml > SHA1SUMS da10:/srv/install-repo/sled11/ # cat SHA1SUMS e13af51a0b1993bf20d597408c457681aea382c0 add_on_products.xml 10. Sign the SHA1SUMS file with the gpg command: da10:/srv/install-repo/sled11/ # gpg -b --sign --armor SHA1SUMS NOTE: If you have several private keys, use the -u username option to specify the key.

This command creates the SHA1SUMS.asc file that contains the digital signature. Every time you change the add_on_products.xml file, you have to create a new SHA1SUMS file and digitally sign it again. 11. Sign the content file you created in Step 7 with gpg as well. 12. The key to verify the signatures has to be available in the root of the installation

repository. You also have to update the directory.yast file in the root directory of your installation repository.

Version 1


367






Run the following commands: da10:/srv/install-repo/sled11/ # gpg --export --armor \ your_keyid > SHA1SUMS.key da10:/srv/install-repo/sled11/ # ls > directory.yast 13. The last step is to include your public key in the initrd.

In addition to the root directory of the installation repository, the key used to verify the signatures (SHA1SUMS.key from the previous step) has to be available with a .gpg file extension in the root (/) directory of the initrd used during installation. The initrd is in the /boot/i386/loader/ directory on the installation DVD. Copy the initrd and my-key.gpg to a directory of your choice, such as / tmp, and add the my-key.gpg file to the initrd as shown in the following: da10:/srv/install-repo/sled11/ # cp SHA1SUMS.key /tmp/my-key.gpg da10:/srv/install-repo/sled11/ # cd /tmp/ da10:/tmp/ # mv initrd initrd.gz da10:/tmp/ # gunzip initrd.gz da10:/tmp/ # find my-key.gpg | cpio -o -A -F initrd -H newc da10:/tmp/ # gzip initrd da10:/tmp/ # mv initrd.gz initrd

The modified initrd file can be used on your tftp server for PXE booting. When your add-on repository is set up, you can specify any RPM file that is contained in it for installation in an AutoYaST control file.

368


Version 1


Use the Installation Server To use the installation server, you have to specify the server when the initial boot screen shows up. With the Down key, move to Installation, then press F4. From the menu, select the installation server type you want to use: Figure 9-6

Installation via NFS

Another dialog opens where you have to specify the hostname of the server and the directory on the server. Depending on the server type, there might be additional parameters to specify. Instead of selecting NFS from the menu and specifying the IP address and path in the dialog, you can type install=nfs://IP_address/path/to/ repository/ in the Boot Options field. After pressing Enter, the installation system connects to the installation server and loads all files needed for installation over the network.

Version 1


369






Exercise 9-1

Set Up an Installation Server In this exercise, you copy the files of the installation DVD to a directory and make this directory accessible over the network using NFS. Then you prepare the installation repository to provide additional RPMs that are not part of the installation media. You will find this exercise in the workbook. (End of Exercise)

370


Version 1


Objective 3

Set Up PXE Boot for Installations PXE (Preboot Execution Environment) is a procedure to boot a computer system over the network. This is independent of the local storage media or operating system. The firmware of the network card sends out bootp requests and receives an IP address as well as information on where to retrieve a boot loader image from a bootp/DHCP server. It downloads the boot loader image based on that information using TFTP. The image is transferred from the server and loaded into RAM. The control of the boot process passes from the network card to the boot loader. This boot loader then fetches the kernel and initrd from the TFTP server and passes the control to the kernel. In addition to a PXE-capable network card on the client side, the following packages are needed on the server side: 

tftp: TFTP Server



syslinux: Contains the bootloader pxelinux



dhcpd: DHCP Server

A DHCP server is available only on SUSE Linux Enterprise Server 11, not on the Desktop distribution. However, you can add the SUSE Linux Enterprise Server 11 DVD to the installation sources to be able to install a DHCP server on SUSE Linux Enterprise Desktop 11 as well. To set up PXE boot, you need to understand how to do the following: 

“Install and Configure tftp” on page 371



“Configure pxelinux” on page 372



“Install and Configure the DHCP Server” on page 375

Install and Configure tftp To begin, install the tftp package with the yast -i tftp command. The TFTP server needs a directory for the files it is supposed to distribute, which is created by the mkdir /tftpboot command.

Version 1


371






As the TFTP server is started via xinetd, it is necessary to edit /etc/xinet.d/ tftp. It should look similar to the following example: # default: off # description: tftp service is provided primarily for # booting or when a router needs an upgrade. Most sites # run this only on machines acting as "boot servers". service tftp { socket_type = dgram protocol = udp wait = yes user = root server = /usr/sbin/in.tftpd server_args = -s /tftpboot -r blksize # disable = yes }

To access the TFTP server, it is necessary to start xinetd with the rcxinetd start command. If a client contacts the TFTP server port (69), xinetd starts the TFTP server and hands the connection over to that server. If you want xinetd to start during system boot, add it to the proper runlevel directories with the insserv xinetd command.

Configure pxelinux The syslinux package contains the files the client needs to boot via the network. To configure pxelinux for network boot, you have to understand the following: 

“pxelinux Files and Directories” on page 372



“Configure pxelinux” on page 373

pxelinux Files and Directories

The first step is to install the syslinux package (if it isn’t installed already) using the yast -i syslinux command. Then copy the /usr/share/syslinux/ pxelinux.0 file to /tftpboot/. In addition to the files from the syslinux package, the kernel and initrd of the system you want to install are needed in the /tftpboot directory. From the SUSE Linux Enterprise Server 11 installation DVD, copy the linux, initrd, and message files from the /mountpoint/boot/i386/loader/ directory to /tftpboot/. If you want to be able to install different products, like Desktop and Server, rename the files accordingly (such as initrd_sled11, initrd_sles11, linux_sled11, etc.) to avoid naming conflicts.

372


Version 1


Configure pxelinux

pxelinux expects its configuration in the /tftpboot/pxelinux.cfg/ directory. To configure pxelinux, you have to understand the following: 

“Configuration Filename Convention” on page 373



“Configuration File Content” on page 373

Configuration Filename Convention

As more than one system may be booted from the same server, the configuration filename depends on the IP address of the booting machine. In this way, it is possible to have different configurations for different machines. pxelinux will search for the configuration file on the boot server in the following way: 

First it will search for a configuration file based on the MAC address of the NIC of the client in lower hexadecimal notation, and the ARP type (Ethernet: ARP type 1). For example, if the MAC address is AA:BB:CC:11:22:33, the corresponding filename will be 01-aa-bb-cc-11-22-33.



Next it will search for the configuration file using the IP address of the client in hexadecimal notation; the address 172.17.8.1, for example, corresponds to AC110801. The gethostip program from the syslinux package can be used to calculate this value.



If that file is not found, it will remove one hexadecimal digit and try again (AC11080 in the above example). If no success, another hexadecimal digit is removed with each try, until a file is found (AC1108,AC110, AC11, and so on, in the above example).

If no file with one of these names is found, pxelinux searches for a file named default. Configuration File Content

The content of the file defines which kernel and initrd are loaded. Together with the message file, it is possible to display a menu on the client side where the administrator can select which files to load. For example, you can implement such a menu when you want to offer a choice of which system to install (SLED11, SLES11, etc.), or for different boot options. The content of the file could look like the following (the options after “append” need to be in one line): default harddisk # SLED11 label SLED11 kernel linux_sled11 append initrd=initrd_sled11 ramdisk_size=65536 insmod=e100 netdevice=eth0 install=nfs://172.17.8.1/srv/install-repo/sled11 vga=0x317 # SLES11 label SLES11

Version 1


373






kernel linux_sles11 append initrd=initrd_sles11 ramdisk_size=65536 insmod=e100 netdevice=eth0 ... # hard disk (default) label harddisk localboot 0 implicit 0 display message prompt 1 timeout 100

The options that can be used in the file are described in /usr/share/doc/ packages/syslinux/syslinux.txt. Those used here have the following significance: 

default value: The default option defines which label is used in case the user does not enter anything. In the example above, the computer boots from harddisk.



label value: Under each label, it is possible to define which kernel to load and which options to append. The parameters listed after “append” are kernel parameters or linuxrc key=value combinations. A list of keys can be found in /usr/share/doc/packages/linuxrc/README.linuxrc after installing the linuxrc package from the SUSE Linux Enterprise Server 11 DVD. The location of files has to be specified relative to the directory where pxelinux.0 resides. In the example above, linux and initrd are in the same directory as pxelinux.0; therefore, no path has to be set.



implicit 0|1: If the value is 0, a kernel image is not loaded unless it is explicitly named in a label statement.



display filename: The filename that contains the information to display to the user.



prompt 0|1: If the value is 1, always display the boot: prompt.



timeout timeout: The number of 1/10 seconds after which the default is loaded automatically.

In a message file, you can include an explanation of each possible choice, as in the following example: To boot from harddisk, just press . Available boot options: SLED11 - AutoYaST-Installation of SLED11 SLES11 - AutoYaST-Installation of SLES11

To install SLED11, enter SLED11 at the prompt.

374


Version 1


Install and Configure the DHCP Server This section covers only the main configuration options relevant for an installation server; it does not cover the DHCP configuration in detail. To install the DHCP server, select the YaST Software Management module and then in the Software Management dialog, search for “dhcp”, select dhcp-server on the right, and then click Accept. There are two configuration files that need to be edited: 

“/etc/sysconfig/dhcpd” on page 375



“/etc/dhcpd.conf” on page 376

/etc/sysconfig/dhcpd

The /etc/sysconfig/dhcpd file contains configuration options which are submitted as parameters to the DHCP daemon by the /etc/init.d/dhcpd start script. The first parameter defines the interfaces which the DHCP server listens on for requests. For example, if the DHCP server listens on the two interfaces eth0 and eth1, set the variable DHCPD_INTERFACE to the following DHCPD_INTERFACE="eth0 eth1"

The DHCP server will listen only to the interfaces specified here. Two other variables enhance the security of the server: DHCPD_RUN_CHROOTED="yes"

and DHCPD_RUN_AS="dhcpd"

The first of these variables configures the DHCP server processes to run in a chroot environment. The new root directory for all DHCP server related processes is /var/ lib/dhcp. The second variable defines the user to be used for running the processes. Normally there is no reason to change the default settings of these variables. The DHCP server can read additional configuration files that are included in the main configuration file. As the server processes are running in a chroot environment, these additional configuration files have to be copied into the chroot environment too. The files will be copied automatically when the DHCP server is started if they are listed in /etc/sysconfig/dhcpd. The following is an example: DHCPD_CONF_INCLUDE_FILES="/etc/dhcpd.conf.shared /etc/dhcpd.conf.d”

As shown here, the name of a directory can also be provided. All files located in this directory will be included.

Version 1


375






/etc/dhcpd.conf

The configuration file for the DHCP server is /etc/dhcpd.conf. Global definitions are made at the top of the configuration file. The parameters defined here apply to all subsequent sections unless they are explicitly overwritten in the respective sections. The entries in the configuration file belong to two categories: 

Parameter statements: These describe the following: 







How to do something (for example, define the length of time an IP address remains valid without renewal) Whether to do something (for example, whether IP addresses should be assigned to unknown clients) Which parameters should be provided to clients (for example, the IP address of the default gateway)

Declarations: Describe the topology of the network, describe the clients, or provide the address ranges to serve clients from.

Each statement has to be terminated using the semicolon (;). In the case of an error in the configuration file, dhcpd will not start but will print out an error message. This message can be used to locate the error in the configuration file. SUSE Linux Enterprise Server 11 ships with a sample configuration file for the DHCP server. You will not need all the configuration statements that are provided with this sample file. It is better to start with an empty configuration and to enter only those statements you really need. Comments can be used at any location in the configuration file. They start with the hash sign (#). The rest of the line after the hash sign will be ignored. Starting with DHCP server version 3, dynamic updates of a DNS server are possible. This means when the DHCP server assigns an IP address to a client, it can update the corresponding information on the DNS server. The statement describing how to do this dynamic update (ddns-update-style) is mandatory. If no dynamic update is done (as in this example), specify none as the parameter to this statement: # # /etc/dhcpd.conf # ddns-update-style none;

The following are statements regarding the lease times (the validity period for assigned IP addresses): # # specify default and maximum lease time # default-lease-time 86400;max-lease-time 86400;

When a client requests an IP address without providing any information on the desired lease time, the IP address will be assigned for the specified default lease time (in this example, 86400 seconds, which is one day).

376


Version 1


NOTE: You can enter a maximum of 231-1 seconds for the lease time. That is about 68 years.

Shortly before the assigned IP address expires, the client will request a renewal of the address. Normally, the lease time for this address will be extended. Depending on its configuration, a client can request a specific lease time. Normally, this specific lease time request is accepted. You have to distinguish two cases: 

If the requested lease time is shorter than the default lease time, the DHCP server will assign the IP address for the requested time.



If the requested lease time is longer than the default lease time and if no maximum time has been specified, the DHCP server will accept it. If the maxlease-time statement is present, this time will be the longest available.

In the example above, both times are the same. Setting a maximum lease time prohibits clients from requesting an infinite lease time (resulting in a permanent IP address). The following section of dhcpd.conf shows how to provide information on the DNS domain to be used: # # What is the DNS domain and where is the name server? # option domain-name "digitalairlines.com"; option domain-name-servers 172.17.8.1, 172.17.8.10;

These configuration options start with the keyword option. If a list of name server addresses (separated by commas) is provided, the list reflects the order of preference for contacting a name server. As the last parameter, specify the addresses of routers in the subnet: # # This is a router # option routers 172.17.8.1;

If several routers are specified here (separated by commas), the list reflects the order of preference for using these routers. The first router is the default gateway. There are several options that are needed to enable booting using PXE: allow bootp; next-server 172.17.8.1; server-name "da1.digitalairlines.com"; filename "pxelinux.0";

The bootp flag is used to tell dhcpd whether or not to respond to bootp queries. next-server specifies the machine to get the boot loader image from, and filename specifies its name. The server-name statement can be used to inform the client of the name of the server it is booting from.

Version 1


377






Finally, define the range of addresses that can be used for assigning IP addresses to clients. This declaration starts with the keyword subnet and specifies the subnet and corresponding network mask: # # Which IP addresses may be assigned to the clients? # subnet 10.0.0.0 netmask 255.255.255.0 { range 10.0.0.101 10.0.0.120; }

When a client requests an IP address, it will be assigned a free address from this range. Starting with version 3 of the DHCP server, assignment will start with the highest addresses (in the case above, 10.0.0.120). If no parameters are defined inside this subnet declaration, all globally defined parameters will be used. There can be more than one range statement inside a subnet declaration. It is possible to configure specific hosts as well. Hosts are identified by their MAC address. In the following example, the host with the MAC address specified after “hardware ethernet” is assigned the IP address 10.0.0.150: # # Host specific configuration # host da150 { fixed-address 10.0.0.150; hardware ethernet 00:11:22:33:44:55; }

The man pages for dhcp-options and dhcpd.conf provide more information on the available configuration options. After the configuration has been completed, start the DHCP server with the rcdhcpd start command. If there are any mistakes in your configuration, there will be error messages pointing you to a line in the configuration file near the mistake. Fix it and try again to start the server. If you want the server to start automatically at system start, add the proper links to the runlevel directories with the insserv dhcpd command. You are now ready to test your setup. In the same network as your DHCP and TFTP server, boot a machine that has a PXE-capable network card. (It might be necessary to change the BIOS of that machine to include the network card as a boot medium.) The machine should get an IP address from your DHCP server and briefly after that, you should see the information from your message file. In this SUSE Linux Enterprise Server 11 Administration course manual, we explained a simple DHCP configuration that supports PXE. More information on the configuration of a DHCP server is available at several locations: 

The man pages on your local system: 

378

man dhcpd (DHCP server)


Version 1








man dhcpd.conf (configuration file)



man dhcp-options (configuration options)

In directories on your local system: 

/usr/share/doc/packages/dhcp/



/usr/share/doc/packages/dhcp-server/

On the Web: 



In books: 

Version 1

http://www.isc.org/software/dhcp/ The DHCP Handbook by Ralphs Droms and Ted Lemon (Sams Publishing)


379






Exercise 9-2

Set Up PXE Boot for Installations In this exercise, you set up a TFTP server, fill the /tftpboot directory with the files needed for PXE boot, and set up a DHCP server. You will find this exercise in the workbook. (End of Exercise)

380


Version 1


Objective 4

Create a Configuration File for AutoYaST The easiest way to create a configuration file for AutoYaST is to use the YaST Autoinstallation module. Select Computer > Yast > Miscellaneous > Autoinstallation, or log in as root and enter yast2 autoyast in a terminal window. This module starts with the following dialog:

Figure 9-7

Autoinstallation Configuration

The left part of the window contains the YaST groups you know from the left frame of the YaST dialog. The center frame contains the YaST modules available in the group. The right frame lists the settings made in this module for the autoinstallation. NOTE: At the beginning, default values based on the current system configuration are listed in the right frame.

You do not need to configure every single aspect of the machines to be installed, because the automated installation makes use of the hardware detection capabilities of YaST. For example, you do not need to provide the type of network card because the hardware detection will take care of this. Clicking Edit opens the same YaST configuration dialogs as those you see when installing or administering SUSE Linux Enterprise 11. However, the configuration information is written to the AutoYaST control file. Nothing is changed on the installation you work on.

Version 1


381






You would usually define disk layout, software selection, language settings, network parameters, and root password. Depending on your needs, you can specify other items, such as users and their passwords, NFS client configuration, or printer configuration. If you want to perform completely unattended installations, in the General Options module in the System group of AutoYaST, select Edit. Click Next in the Mouse Configuration dialog, and uncheck Confirm Installation in the Other Options dialog. The default is to confirm installation to avoid recursive installs when the system schedules a reboot after initial system setup. You should also be aware that this might cause inadvertent installations under certain circumstances. After you have completed the configuration, select File > Save as. A dialog box opens with the default directory for AutoYaST configuration files, /var/lib/ autoinstall/repository/. Type a name for the file (hostname.xml, for example). You can change the default directory for AutoYaST configuration files via the File > Settings menu. If you do not want to begin from scratch, you can use the current machine as a template. Select Tools > Create Reference Profile. The following dialog appears: Figure 9-8

AutoYaST Reference Control File

The reference profile is created by reading information from the system you work on. To add other necessary information for your machine, select the check boxes in the main window.

382


Version 1


NOTE: Be sure to examine any resulting control file carefully before using it to autoinstall a new system.

To view the configuration created, select View > Source: Figure 9-9

AutoYaST XML Code

After you have completed your configuration, save it by selecting File > Save as as described above. You can also create the control file using an editor of your choice. The advantage of the YaST module is that it saves a lot of typing and the XML syntax of the resulting file is correct. Another approach is to create a control file with YaST and then use an editor for minor changes and additions. On a system that was installed using AutoYaST, the control file used during installation is stored as /var/adm/autoinstall/cache/ installedSystem.xml. NOTE: More information on AutoYaST can be found in /usr/share/doc/packages/ autoyast2/html/index.html.

Version 1


383






Exercise 9-3

Create an AutoYaST Control File In this exercise, you create an AutoYaST control file. You will find this exercise in the workbook. (End of Exercise)

384


Version 1


Objective 5

Perform an Automated Installation To start the automated installation, make the AutoYaST control file available on the machine to be installed. This can be combined with any installation method, be it from the installation media or an installation server in the network. To perform automated installations, you need to do the following: 

“Provide the Control File” on page 385



“Boot and Install the System” on page 385

Provide the Control File Various ways exist to make the control file available. One is to copy the file to a floppy disk containing a FAT file system format. NOTE: Do not use a floppy disk with Ext2 file system format.

If you name the file on the floppy disk autoinst.xml and insert the floppy, it will be automatically used. If you use a different name, you have to add the following to the kernel command line at the boot prompt of the installation: autoyast=floppy:///myconfig.xml Another way to make the control file available is via the network. That is especially useful in combination with an installation server. In this case, the kernel command line would look similar to the following: autoyast=nfs://172.17.8.1/srv/install-repo/sled11/ay/ myconfig.xml

Boot and Install the System Once you have your control file created and tested, you have several options to install machines with it: 

“Boot and Install from DVD” on page 385



“Boot from DVD, Install from an Installation Server” on page 386



“Boot via PXE, Install from an Installation Server” on page 386

Boot and Install from DVD

It is possible to use a control file (on a floppy disk or on an exported file system) in combination with the installation DVD to boot and install the computer.

Version 1


385






However, for larger deployment, this is not really efficient. While it saves the typing of configuration information, you still have to walk from computer to computer, insert the media, and start the installation manually. Later, you have to come back to remove the installation media again. Boot from DVD, Install from an Installation Server

Even when using the DVD or floppy disks to boot, an installation server has the advantage that you can remove the boot media as soon as the actual installation has started. Provided you have a DHCP server running which provides all network information during installation, the steps are as follows: 1.

Insert the installation DVD into your machine and start the boot process.

2.

On the first boot screen, select Installation (be sure to do this within 10 seconds; otherwise, the system starts from harddisk).

3.

Provide the necessary information for an automated installation with AutoYaST. At the boot prompt, enter the following parameters (we assume here that the installation repository is available via NFS from 172.17.8.1/srv/ install-repo/sled11/, and that the control file is available at the same location): autoyast=nfs://172.17.8.1/srv/install-repo/sled11/ay/ autoinst.xml install=nfs://172.17.8.1/srv/installrepo/sled10 splash=verbose The last parameter switches to the detailed display during the boot process, so you can easily look at the boot messages.

After a short time, YaST starts. At this point, you can remove the boot medium. The installation proceeds as usual but, because of the control file, no user interaction is necessary. After some checks, the packages are copied from the NFS server. The system is rebooted at the end of the installation process. After the reboot, you may log in as root without a password if no password was set in the AutoYaST configuration file. In this case, you should immediately set a password for root.

Boot via PXE, Install from an Installation Server

The advantage of using PXE for installation is that you do not have to bring a separate boot medium to the computer. With a suitable configuration, you can offer a menu to select what to install. In fact, if the network card supports Wake on Lan, you do not have to walk to the machine at all.

386


Version 1


The setup to support booting via the network is described in “Configure pxelinux” on page 372. To integrate AutoYaST, an additional entry is needed in the append line of the pxelinux configuration file: ... # SLED11 label SLED11 kernel linux append initrd=initrd ramdisk_size=65536 insmod=e100 netdevice=eth0 install=nfs://172.17.8.1/srv/install-repo/sled11 autoyast=nfs:// 172.17.8.1/srv/install-repo/sled11/ay/autoinst.xml vga=0x317 ...

When you now enter SLED11 at the message prompt, the computer is automatically installed. You could go one step further and make this entry the default: default SLED11 # SLED11 label SLED11 ...

In this case, the computer gets installed unless a user chooses a different option. This configuration is probably useful only in initial rollouts in combination with Wake on Lan, for these reasons: 

Until you remove the pxelinux configuration file, there is an installation loop— after each reboot, the installation starts all over again.



If a user turns on the computer, it will get installed from scratch.

Do this as a workaround: 1.

Create a file /tftpboot/pxelinux.cfg/default that contains the menu options that you want to offer in the PXE menu once the computers are installed. This could be to boot from harddisk only, or also contain additional entries allowing installations when the user selects them.

2.

Create another file, /tftpboot/pxelinux.cfg/install, that contains the installation as default. The name of the file is not important, as long it is not a filename pxelinux looks for as described in “Configuration Filename Convention” on page 373.

3.

Create links within the /tftpboot/pxelinux.cfg/ directory to the / tftpboot/pxelinux.cfg/install file according to the pxelinux file name convention. For example for the IP address 10.11.12.13, the command would be ln -s install 0A0B0C0D

Version 1

4.

Using Wake on Lan, turn on the machine.

5.

Watch the TFTP log file, using the command


387






tail -f /var/log/xinetd.log It will show an entry when a computer connects to the TFTP server. You could also watch /var/log/messages for entries indicating that the respective client has mounted the installation server directory. 6.

When the computer you turned on using Wake on Lan has fetched the necessary files via TFTP according to the log file, remove the corresponding link in the directory /tftpboot/pxelinux.cfg/: rm 0A0B0C0D When the computer reboots during the installation or later in the course of normal production, the file fetched by pxelinux is /tftpboot/ pxelinux.cfg/default. As the default in this file is to boot from harddisk, the computer starts normally unless the user chooses a different option.

388


Version 1


Exercise 9-4

Perform an Automated Installation of SUSE Linux Enterprise Server 11 In this exercise, you perform an automated installation of SUSE Linux Enterprise Server 11. You will find this exercise in the work the workbook (End of Exercise)

Version 1


389






Exercise 9-5

Activate PXE Booting and Install SUSE Linux Enterprise Server (Conditional, depending on hardware support) In this exercise, you work with a fellow student to boot your machine using PXE and start the installation of SUSE Linux Enterprise Server 11. You will find this exercise in the workbook. (End of Exercise)

390


Version 1


Summary Objective

Summary

Introduction to AutoYaST

SUSE Linux Enterprise 11 can be deployed using manual installation with the installation media or an installation server, or automated installation with an AutoYaST control file. To boot the computer for installation, you can use the DVD, boot floppies, or PXE-capable network cards in conjunction with a boot loader image distributed via TFTP.

Installation Server: Setup and Use

Setup of an installation server consists of copying the content of the installation DVD to a directory and configuring NFS to provide access to that directory to clients.

Set Up PXE Boot for Installations

To boot a computer via the network using PXE, you need a boot loader image distributed by TFTP. The syslinux package contains the pxelinux.0 boot loader image. The tftp package contains a TFTP server that is started by xinetd when a client accesses port 69. The files needed by the clients are usually stored in the / tftpboot directory A DHCP server is contained in the dhcp-server package.

Create a Configuration File for AutoYaST

To create a configuration file for AutoYaST, use the YaST module Autoinstallation: yast2 > Miscellaneous > Autoinstallation or start the module directly from the command line with yast2 autoyast The default directory for AutoYaST configuration files is /var/lib/autoinstall/repository/.

Perform an Automated Installation

The control file for automated installation can be made available by various means, including a floppy disk, an USB device, or a network share. A DHCP server, which provides all network information, and an installation server simplify the installation. If combined with PXE completely, unattended installations are possible.

Version 1


391






392


Version 1


SECTION 10


SUSE Linux Enterprise Server 11 comes with built-in virtualization support through the Xen virtual machine monitor. In this section, you learn about the Xen virtualization technology in SUSE Linux Enterprise Server 11. Objectives

Version 1

1.

“Understand How Virtualization with Xen Works” on page 394

2.

“Install Xen” on page 398

3.

“Manage Xen Domains with Virt-Manager” on page 409

4.

“Manage Xen Domains from the Command Line” on page 415

5.

“Understand Xen Networking” on page 422


393






Objective 1

Understand How Virtualization with Xen Works Virtualization technology separates a running instance of an operating system from the physical hardware. Instead of running on a physical machine, the operating system runs in a so-called virtual machine. Multiple virtual machines share the resources of the underlying hardware. Virtualization allows you to run multiple virtual systems on one physical machine.

Figure 10-1

Physical Machine and Virtual Machines

In comparison with non-virtualized physical hardware, virtualization provides the following advantages: 

Efficient hardware utilization: Often systems are not using the full potential of their hardware. When multiple virtual machines are run on the same hardware, the resources are used more efficiently.



Reduced downtime: Virtual machines can be migrated to a new physical host system. This reduces downtime in case of a hardware failure.



Flexible resource allocation: Hardware resources can be allocated on demand. When the resource requirements of a virtual machine change, resource allocation can be adjusted or the virtual machine can be migrated to a different physical host.

SLES11comes with a virtualization technology called Xen. Xen allows you to run multiple virtual machines on a single piece of Intel x86-based hardware. To understand how Xen works, you need to do the following:

394



“Understand Virtualization Methods” on page 395



“Understand the Xen Architecture” on page 396


Version 1


Understand Virtualization Methods You should understand the following virtualization methods: 

Para-Virtualization: Instead of emulating a full virtual machine, paravirtualization software provides an Application Programming Interface (API) which is used by the guest OS to access hardware resources. The guest OS must be aware that it runs in a virtual machine and must know how to access the API. Para-Virtualization

Figure 10-2

Para-virtualization provides better performance because it does not emulate all hardware details. However, the guest OS needs to be modified to run with paravirtualization; therefore, only open source operating systems like Linux or BSD can be installed. One exception is NetWare, which has been adjusted by Novell to run in a Xen virtual machine. Another advantage of para-virtualization is the flexible resource allocation. Because the guest OS is aware of the virtual environment, Xen can, for example, change the memory allocation of a virtual machine on the fly without requiring a reboot of the virtual machine. 

Version 1

Full Virtualization. In this case, the virtualization software emulates a full virtual machine, including all hardware resources. The operating system running in the virtual machine (guest OS) communicates with these resources as if they were physical hardware. VMware Workstation is a popular full virtualization software.


395






Full Virtualization

Figure 10-3

Xen supports full virtualization on specialized x86 hardware developed by Intel and AMD. Intel and AMD extended the x86 Standard to support virtualization. Full virtualization works with unmodified guest operating systems, including Microsoft Windows, but generates more overhead, resulting in a weaker performance.

Understand the Xen Architecture Xen consists of the following three major components: 

Virtual Machine Monitor: The virtual machine monitor forms a layer between physical hardware and virtual machines. In general, this kind of software is called a hypervisor.



Xen kernel: The modified Linux kernel for Xen para-virtualization. It can be used for Domain 0 as well as for Domain U (see below).



Xen tools: The Xen tools are a set of command line and graphical applications that are used to administer virtual machines.

The virtual machine monitor must be loaded before any of the virtual machines are started. When working with Xen, virtual machines are called domains. The Xen virtual machine monitor includes neither any drivers to access the physical hardware of the host machine nor an interface to communicate directly with an administrator. These tasks are performed by an operating system running in the privileged Domain 0 (Dom0).

396


Version 1


The following is an illustration of a Xen system with three domains: Figure 10-4

Xen Domains

Xen plus the privileged Domain 0 can also be referred to as a Virtual Machine Server. An unprivileged domain is called Domain U (DomU) in the Xen terminology, and is also known as a Virtual Machine. A process called xend runs in the Dom0 Linux installation. This process is used to manage all Xen domains running on a system and to provide access to their consoles. SUSE Linux Enterprise Server 11 can be used for privileged (Dom0) and unprivileged (DomU) Xen domains.

Version 1


397






Objective 2

Install Xen A complete Xen installation includes the following tasks: 

“Install a Xen Server” on page 398



“Install a Xen Virtual Machine” on page 400

Install a Xen Server To set up a Xen server, which is a system capable of hosting Xen virtual machines, you need to install the Xen kernel and additional Xen packages on top of a SUSE Linux Enterprise Server 11 installation. You have two choices: 

“Install Xen during Installation of SUSE Linux Enterprise 11” on page 398



“Install Xen on an Installed SUSE Linux Enterprise Server 11” on page 400

Install Xen during Installation of SUSE Linux Enterprise 11

To install Xen as part of the SUSE Linux Enterprise Server 11 installation, in the dialog presented in the first stage of the installation, select the Xen Virtual Machine Host Server pattern. This installation on the physical hardware will be your future Domain 0 (Dom0). The other Xen domains (DomUs) are installed later in physical partitions or file system images. If you plan to use physical partitions, make sure that the initial SUSE Linux Enterprise Server 11 installation is not using all of the available disc space. For maximum flexibility, use the logical volume manager (LVM) for a Xen system. As a general rule, you should run services (such as a Web server, a database, or Novell services like iFolder) in a DomU, not in Dom0. Therefore, it is not necessary to select the respective patterns during the installation of Dom0. The following packages have to be installed in the initial SUSE Linux Enterprise Server 11 installation:

398



xen: Contains the Xen virtual machine monitor (Hypervisor).



xen-libs: Contains the libraries used to interact with the Xen virtual machine monitor.



xen-tools: Contains xend and a collection of command line tools to administer a Xen system.



vm-install: Contains Python scripts used to define a Xen virtual machine, and to cause an operating system to begin installing within that virtual machine.



xen-doc-*: (Optional) Contains Xen documentation in various formats.



virt-manager: Provides a graphical interface to manage virtual machines.


Version 1




virt-viewer: Provides a graphical console client for connecting to virtual machines.



bridge-utils: Contains utilities to configure Linux ethernet bridges, which are used to connect the domains to each other and to the physical network interface.



kernel-xen: Contains a modified Linux kernel that runs in a Xen domain, both Dom0 and DomU.

Except for the last package, kernel-xen, these are all part of the Xen pattern. The installation of the kernel-xen package automatically adds an entry like the following into the /boot/grub/menu.lst bootloader configuration file. ###Don't change this comment - YaST2 identifier: Original name: xen### title Xen -- SUSE Linux Enterprise Server 11 - 2.6.27.19-5 root (hd0,1) kernel /boot/xen.gz module /boot/vmlinuz-2.6.27.19-5-xen root=/dev/disk/by-id/ataST380815AS_6QZ2FW3T-part2 insmod=e100 resume=/dev/disk/by-id/ataST380815AS_6QZ2FW3T-part1 splash=silent crashkernel= showopts vga=0x317 module /boot/initrd-2.6.27.19-5-xen

The entry in menu.lst adds a new option to the boot menu of your system. When you select this entry, the Xen virtual machine monitor is loaded (kernel /boot/ xen.gz) which starts SUSE Linux Enterprise Server 11 in Dom0 (see the lines starting with module). Before rebooting your system with the Xen option, you should check if the automatically generated entry is correct. Make sure that 

The line root (hd0,1) points to the partition which contains the Xen virtual machine monitor and the Kernel of the Linux installation for Dom0. For example, hd0,1 designates the second partition on the first hard drive in the system. Also check if the parameter root= in the first module line points to the root partition of the Dom0 installation.



The Xen version of the Linux kernel and the initrd are loaded in the module lines. The names of the image files should end in “-xen.”

After checking the bootloader configuration file, you can reboot your system and select the Xen option from the bootloader menu. In the early stages of the boot process, you will see some messages of the Xen virtual machine monitor on the screen. Then the Dom0 Linux operating system is started. If the system is not booting properly, you can switch back to a non-virtualized system by selecting the regular SUSE Linux Enterprise Server 11 boot option.

Version 1


399






Install Xen on an Installed SUSE Linux Enterprise Server 11

You can easily add Xen to an existing installation of SUSE Linux Enterprise Server 11 using the YaST module created for this purpose. In YaST, select Virtualization > Install Hypervisor and Tools. The required Xen packages are installed. The necessary changes are made to /boot/grub/menu.lst as described in “Install Xen during Installation of SUSE Linux Enterprise 11” on page 398 and a default network bridge is configured. Reboot the machine and select the Xen kernel from the boot menu. To boot the Xen kernel by default, edit the default entry in /boot/grub/menu.lst: # Modified by YaST2. Last modification on Thu Apr default 0 timeout 8 gfxmenu (hd0,1)/boot/message ##YaST - activate

2 17:27:29 CEST 2009

###Don't change this comment - YaST2 identifier: Original name: xen### title Xen -- SUSE Linux Enterprise Server 11 - 2.6.27.19-5 ...

default 0 boots the first entry by default, default 1 the second, and so on. If you want to find out which kernel is currently in use, enter uname -a in a terminal window: da10:~ # uname -a Linux da10 2.6.27.19-5-xen #1 SMP 2009-02-28 04:40:21 +0100 i686 i686 i386 GNU/Linux

Install a Xen Virtual Machine After you have installed Xen and the Xen tools, you can use vm-install to create unprivileged Xen domains. vm-install can be started directly from the command line or by starting YaST and selecting Virtualization > Create Virtual Machines. This tool guides you step by step through the creation of a Xen domain on your system.

400


Version 1


The first dialog looks like the following: Figure 10-5

Virtual Machine Installation

This first page gives some information on the creation of a virtual machine. Selecting Forward opens a dialog where you have a choice between a new installation of an operating system and the use of an existing image.

Version 1


401






If you decide to install an operating system, the following dialog appears: Figure 10-6

402

Virtual Machine Installation: OS Type


Version 1


Your choice of the type of operating system determines the suggested values in the next dialog: Figure 10-7

Virtual Machine Installation: Summary

It is necessary to specify the installation medium. Other values, such as the size of the virtual hard disk, can be changed as needed. To change a setting, select the blue headline. We recommend switching to a fixed MAC address for Linux virtual machines.

Version 1


403






Select Network Adapter on the Summary page to edit the suggested values or to add another virtual network adapter. Select Edit on the Network Adapters page to open the following dialog: Figure 10-8

Virtual Machine Installation: Network Adapter

Selecting Randomly generated MAC address causes a new MAC address to be created each time the virtual machine is started. With this setting and SLES11 as the operating system within the virtual machine, the interface name within the virtual machine changes each time the virtual machine is started. To avoid this, select Specified MAC address. The vendor string for Xensource is 00:16:3e. Enter hex values in the spaces provided, making sure they are unique within your network. Click Apply to return to the previous dialog.

404


Version 1


In the Summary dialog, select Disks to change hard disk parameters or to add a hard disk or a CDROM drive. The following dialog appears: Figure 10-9

Version 1

Virtual Machine Installation: Disks


405






Select Edit to change the highlighted entry. The following dialog appears: Figure 10-10

Virtual Machine Installation: Virtual Disk

Here you can specify a different image file and change its size. When you select Create Sparse Image File, the image file does not immediately use the specified amount of disk space on the storage medium, but grows as space is actually used within the virtual machine. It is also possible to specify a block device like /dev/sda5 instead of a file. Select OK to return to the Disks dialog. Select Apply in the Disks dialog to return to the Summary page. The dialog for the CDROM drive is almost identical.

406


Version 1


To specify an installation medium, in the Summary dialog select Operating System Installation. The following dialog appears: Figure 10-11

Virtual Machine Installation: OS Installation

In the Network URL text box, you can specify an installation source located in the network, such as nfs://172.17.8.101/data/install/SLES11. Select Apply to return to the Summary dialog. To start the installation, select OK in the Summary dialog. A VNC window appears that allows you to control and configure the operating system installation. When you install SUSE Linux Enterprise Server 11 in a virtual machine, the device name for the first hard disk within the virtual machine is /dev/xvda, the device name for the second disk is /dev/xvdb, and so on. Apart from this detail, a virtual installation is almost identical to an installation on real hardware.

Version 1


407






Exercise 10-1

Install a Xen Server and an Unprivileged Domain In this exercise, you learn how to install Xen and configure Dom0, and how to install SUSE Linux Enterprise Server 11 in a Xen guest domain using vm-install. You will find this exercise in the workbook. (End of Exercise)

408


Version 1


Objective 3

Manage Xen Domains with Virt-Manager Virt-Manager is a graphical tool used to manage virtual domains. It can be started by entering the virt-manager command or by selecting Virtualization > Virtual Machine Manager in YaST.

Figure 10-12

Version 1

Virt-Manager


409






Double-click a virtual machine entry to open a VNC window: Figure 10-13

DomU

In the screenshot above, the virtual machine is running. You could pause the machine or shut it down using the respective buttons. Closing the VNC window as such does not affect the state of the machine. It continues to run and you can attach to the VNC session again by double-clicking the respective entry in Virt-Manager. If you double-click an entry of a virtual machine that is not currently running, the window appears empty and you can start the machine by clicking the Run button. To release the mouse cursor from the VNC window, press Ctrl+Alt.

410


Version 1


When you select an entry in the Virtual Machine Manager window with the right mouse button and then select Details, another dialog appears: Figure 10-14

DomU: Utilization

The Overview tab shows a graph of CPU and memory usage.

Version 1


411






The Hardware tab allows you to view and change certain hardware parameters: Figure 10-15

DomU: Hardware Details

You can add or remove virtual processors, change the memory currently used, or add and remove hard disks and CDROM/DVD drives. Removing and adding the CDROM drive is necessary when changing a CDROM in the drive. Currently, CDROM drives appear as hard disks within the virtual machines and media changes are not detected automatically. Due to a bug at the time of this writing, adding and removing CDROM drives in VirtManager is not possible. You have to use the xm command to access the content of a CDROM/DVD or to change it. (The xm command will be covered in more detail in “Use the xm Tool” on page 416.) To change a DVD or CDROM in a virtual machine, do the following: 1.

Put the CDROM or DVD in the DVD drive. It will be mounted automatically in Dom0.

2.

Open a terminal window, su - to root, then add the drive with the command xm block-attach domainID dev_in_Dom0 dev_in_DomU r for instance xm block-attach sles11 phy:/dev/sr0 /dev/xvdb r

412


Version 1


3.

Within DomU, mount the device (/dev/xvdb in the example above). When you want to change the CDROM/DVD, unmount the device in DomU.

4.

In Dom0, find out the ID for the CDROM entry and then remove this entry from the virtual machine with the xm commands as shown below:

da10:~ # xm block-list sles11 Vdev BE handle state evt-ch ring-ref BE-path 51712 0 0 4 16 8 /local/domain/0/backend/vbd/ 1/51712 51728 0 0 4 18 897 /local/domain/0/backend/vbd/ 1/51728 da10:~ # xm block-detach sles11 51728 da10:~ # 5.

Version 1

Change the CDROM/DVD in the drive and attach the device again as explained in Step 2.


413






Exercise 10-2

Change Memory Allocation of a Guest Domain In this exercise, you learn how to change the memory allocation of a guest domain using the Virtual Machine Manager. You will find this exercise in the workbook. (End of Exercise)

414


Version 1


Objective 4

Manage Xen Domains from the Command Line In this objective, you learn how to manage Xen domains at the command line. To do this, you need to 

“Understand Managed and Unmanaged Domains” on page 415



“Understand a Domain Configuration File” on page 415



“Use the xm Tool” on page 416



“Use the virsh Tool” on page 418



“Automate Domain Startup and Shutdown” on page 420

Understand Managed and Unmanaged Domains In Xen version 2, all DomUs were configured by a configuration file. You can still use configuration files with Xen version 3. Virtual domains that are configured by configuration files only are referred to as unmanaged domains. Unmanaged domains appear in Virt-Manager or in the output of the xm list command (covered later in this objective) only when they are running. With Xen version 3, configuration details can be stored in the Xenstore database located in /var/lib/xenstored/tdb. One advantage is that the virtual machines always appear in virt-manager, even when not running, and can be started as described in the previous objective. Virtual machines that have their configuration in the Xenstore database are referred to as managed domains. You can use the xm new configfile command to move configuration information from a configuration file into the Xenstore database. Currently it is not possible to export a configuration from the Xenstore database to a configuration file. To remove configuration information from the Xenstore database, use the xm delete vm_name command. This command removes only the configuration information from the database; the disk image files remain unchanged. When a virtual machine is created with vm-install, the configuration is written to / etc/xen/vm/vm_name and to the Xenstore database simultaneously. Later changes to the configuration file have no effect on the information in the Xenstore database. To change the configuration in the Xenstore database, delete the configuration from the database with xm delete vm_name, edit the configuration file in /etc/ xen/vm/, and integrate the new configuration in the database with xm new configfile.

Understand a Domain Configuration File The configuration files for domains created with vm-install are located in /etc/ xen/vm/.

Version 1


415






A configuration file contains several keywords which configure different aspects of a Xen domain. A configuration file created by vm-install during the installation of a virtual machine could look like the following: name="sles11" uuid="3eb65cbd-ae8e-2a79-cf1e-89189489d085" memory=512 maxmem=512 vcpus=2 on_poweroff="destroy" on_reboot="restart" on_crash="destroy" localtime=0 keymap="en-us" builder="linux" bootloader="/usr/bin/pygrub" bootargs="" extra=" " disk=[ 'file:/var/lib/xen/images/sles11/disk0,xvda,w', 'phy:/dev/ sr0,xvdb:cdrom,r', ] vif=[ 'mac=00:16:3e:31:24:13,bridge=br0', ] vfb=['type=vnc,vncunused=1']

Under /etc/xen/examples/, you find example files which can be used to create a configuration from scratch. The comments in these files (lines starting with a # sign) give more information on the available options and the required syntax. NOTE: A good source for detailed documentation and HOWTOs about Xen and the domain configuration files is the Xen wiki at: http://wiki.xensource.com/ (http://wiki.xensource.com/).

Use the xm Tool The xm command line uses the following format: xm subcommand [options] [arguments] [variables] xm is the administration command line tool for Xen domains. xm communicates with the xend management process running on the Dom0 Linux installation. You can get a complete list of the xm subcommands by entering xm help. The xm manual page contains information on the available options for each of the subcommands. This manual covers only the more frequently used subcommands. You can use the create subcommand to start an unmanaged virtual machine: xm create -c -f /data/xen/SLES11-WebServer.conf The -c option lets xm connect to the terminal of the started domain, so that you can interact with the system. To disconnect from the terminal and return to the original command line, enter the key combination Ctrl-]. The -f option specifies the configuration file of the domain that should be started.

416


Version 1


The list command displays information about all managed Xen domains and the currently running unmanaged Xen domains: da10:~ # xm list Name ID Mem VCPUs Domain-0 0 1481 2 sles11 1 512 2

State r-----b----

Time(s) 298.3 23.0

The output of the list command contains the following fields: 

name: Name of the domain as specified in the configuration file.



ID: Numeric, consecutive domain ID, which is automatically assigned when the domain starts.



Mem: Amount of memory assigned to the domain.



VCPUs: Number of virtual CPUs utilized by this domain.



State: Current state of the domain. This could be:  



r: Domain is running. b: Domain has been created but is currently blocked. This can happen when a domain is waiting for I/O or when there is nothing to do for a domain.



p: Domain is paused. The state of the domain is saved and can be restored.



s: Domain is in the process of being shut down.



c: Domain has crashed due to an error or misconfiguration.

Time: Total run time of the domain as accounted for by Xen.

An alternative to list is the command top, which displays domain information updated in realtime. To start a managed domain, use the following command: xm start vm_name The console command connects you with the terminal of a running domain: xm console domain_id The command takes the domain id as a parameter, which can be determined with the list command (field: ID). The name (field: Name) works as well. As mentioned before, use the key combination Ctrl-] to disconnect from a terminal. With the pause command, you can interrupt the execution of a domain temporarily: xm pause domain_id A paused domain is not completely shut down. The current state is saved and the execution of the domain can be continued with the unpause command: xm unpause domain_id

Version 1


417






To shut down a domain, use the shutdown command: xm shutdown domain_id This is equivalent to using the appropriate command within the virtual machine (shutdown -h now in Linux). If the domain is not responding anymore, you can force the shutdown of the domain with the destroy command: xm destroy domain_id This is equivalent to pulling the plug on a physical machine. To save the state of a domain for a longer time (for example, over a reboot of Dom0) you can use the save command: xm save domain_id filename The domain can be restored from the resulting file with the restore command: xm restore filename Another commonly used command is mem-set, which allows you to change the memory allocation of a domain: xm mem_set domain_id amount_of_memory The amount of memory is specified in megabytes. Block devices can be added to DomUs with the xm block-attach command:. xm block-attach domainID dev_in_Dom0 dev_in_DomU r/w To remove the device again, first use xm block-list to find out what DeviceID to use in the xm block-detach command: xm block-list domainID xm block-detach domainID DeviceID

Use the virsh Tool The virsh command is similar to the xm command. The basic structure of the virsh command is as follows: virsh subcommand [options] virsh can be used to administer Xen domains. The options are similar to those of the xm command, however there are also some options that are different. You can get a complete list of the virsh subcommands by entering virsh help. The virsh manual page contains information on the available options for each of the subcommands. This manual covers only the more frequently used subcommands.

418


Version 1


You can use the create subcommand to start an unmanaged virtual machine, using a configuration file in xml format: virsh create /data/xen/da-xen.xml The console subcommand connects you with the terminal of a running domain: virsh console domain_id The command takes the domain id as a parameter, which can be determined with the xm list command (field: ID). The name (field: Name) works as well. Use the key combination Ctrl-] to disconnect from a terminal. The virsh list command displays information about running Xen domains, however the xm list command gives you more information, as it also lists managed domain that are not currently running. To start a managed domain, use the following command: virsh start vm_name With the suspend subcommand, you can interrupt the execution of a domain temporarily: virsh suspend domain_id A suspended domain is not completely shut down. The current state is saved and the execution of the domain can be continued with the resume subcommand: virsh resume domain_id To shut down a domain, use the shutdown subcommand: virsh shutdown domain_id This is equivalent to using the appropriate command within the virtual machine (shutdown -h now in Linux). If the domain is not responding anymore, you can force the shutdown of the domain with the destroy command: virsh destroy domain_id This is equivalent to pulling the plug on a physical machine. To save the state of a domain for a longer time (for example, over a reboot of Dom0) you can use the save subcommand: virsh save domain_id filename The domain can be restored from the resulting file with the restore subcommand: virsh restore filename Another commonly used subcommand is setmem, which allows you to change the memory allocation of a domain: virsh setmem domain_id amount_of_memory

Version 1


419






The amount of memory is specified in kilobytes. Block devices can be added to DomUs with the disk-attach subcommand:. virsh attach-disk domainID dev_in_Dom0 dev_in_DomU To remove the device again, use in the detach-disk subcommand: virsh detach-disk domainID dev_in_DomU

Automate Domain Startup and Shutdown When you start, shut down, or reboot the Dom0 of a Xen system, other running Xen domains are also affected. The other Xen domains cannot operate without a running Dom0. SUSE Linux Enterprise Server 11 comes with a start script called xendomains which is included in the xen-tools package. The script, which should be installed on Dom0, does the following: 

When Dom0 is booted, all domains with configuration files located under / etc/xen/auto/ are started. It is recommended to create a symbolic link in this directory pointing to the actual configuration file in /etc/xen/vm/.



When Dom0 is shut down or rebooted, running Xen domains are shut down automatically.

NOTE: If you have a configuration file for a domain that is also in the Xenstore database, the automatic start uses the information in the configuration file and ignores the information in Xenstore, which may be different from that in the configuration file.

To start and stop managed domains automatically you can create a start script based on the /etc/init.d/skeleton file, using the applicable xm commands, such as xm start vm_name and xm shutdown vm_name. The xendomains script has configuration options that can be adjusted in the file / etc/sysconfig/xendomains. The configuration variables in this file are explained in accompanying comments. One interesting option is to migrate domains automatically to a different host when a Dom0 is shut down. This can be configured in the variable XENDOMAINS_MIGRATE. The variable has to be set to the IP address of the target machine. When the variable is empty, no migration is performed. Migration of virtual machines is not covered in this course, though.

420


Version 1


Exercise 10-3

Automate Domain Startup In this exercise, you learn how to start up domains automatically when the system is booted. You will find this exercise in the workbook. (End of Exercise)

Version 1


421






Objective 5

Understand Xen Networking Usually the network connection of Xen domains works out of the box. However, if you would like to change the configuration, networking with Xen can be a bit tricky. The following should give you an overview of how Xen domains are connected to the physical network. You need to 

“Understand Bridging” on page 422



“Understand the Xen Networking Concept” on page 423

Understand Bridging When you install Xen using the YaST Install Hypervisor and Tools module, the network configuration is changed by YaST to include a network bridge. Bridging basically means that multiple network interfaces are combined to one. Traditionally, this technique is used to connect two network segments. In the context of Xen, it is the default mechanism to connect virtual and physical interfaces in Dom0. You can consider the bridge as a kind of virtual switch which virtual and physical interfaces are connected to. The physical interface connects to the physical network and the DomUs connect to the virtual interfaces, thus allowing DomUs to access the physical network. In a setup without a bridge, the configuration for the eth0 interface is contained in the /etc/sysconfig/network/ifcfg-eth0 file. With the change to a bridge, this file is deleted and a /etc/sysconfig/network/ifcfg-br0 file created. Its content looks similar to the following: da10:~ # cat /etc/sysconfig/network/ifcfg-br0 BOOTPROTO='dhcp' BRIDGE='yes' BRIDGE_FORWARDDELAY='0' BRIDGE_PORTS='eth0' BRIDGE_STP='off' STARTMODE='onboot' USERCONTROL='no'

The IP address is no longer assigned to the interface eth0 as before, but to the bridge (in this case using dhcp). The interface that actually connects to the physical network is attached to the bridge (BRIDGE_PORTS=’eth0’) but does not have an IP address of its own.

422


Version 1


This is reflected in the output of the ip command: da10:~ # ip address show 1: lo: mtu 16436 qdisc noqueue state UNKNOWN ... 2: eth1: mtu 1500 qdisc pfifo_fast state DOWN qlen 1000 link/ether 00:80:c8:f6:88:9f brd ff:ff:ff:ff:ff:ff inet6 fe80::280:c8ff:fef6:889f/64 scope link valid_lft forever preferred_lft forever 3: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 100 link/ether 00:19:d1:9f:17:87 brd ff:ff:ff:ff:ff:ff inet6 fe80::219:d1ff:fe9f:1787/64 scope link valid_lft forever preferred_lft forever 4: br0: mtu 1500 qdisc noqueue state UNKNOWN link/ether 00:19:d1:9f:17:87 brd ff:ff:ff:ff:ff:ff inet 172.17.8.1/16 brd 172.17.255.255 scope global br0 inet6 fe80::219:d1ff:fe9f:1787/64 scope link valid_lft forever preferred_lft forever

The command to configure network bridges is brctl. It can be used to list the current setup, as in the following example: da10:~ # brctl show bridge name bridge id br0 8000.0019d19f1787

STP enabled no

interfaces eth0

Other brctl commands include the following: 

brctl addbr name: Creates a new bridge named name.



brctl delbr name: Deletes the bridge named name. The network interface corresponding to the bridge must be down before it can be deleted.



brctl addif brname ifname: Adds the interface ifname to the bridge brname.



brctl delif brname ifname: Deletes the interface ifname from the bridge brname.

Understand the Xen Networking Concept In a Xen setup, the xend management process in Dom0 controls the physical network interfaces of a host system. When a DomU starts up, the /etc/xen/scripts/ network-bridge script takes care of the virtual interface needed to connect the new DomU to the physical network via the bridge. When a new Domain U is created, the following changes to the network configuration are made (simplified):

Version 1

1.

Xen provides a virtual network device to the new domain. Within that domain, that device will appear as ethx.

2.

xend creates a new virtual interface in Dom0.


423






3.

The virtual interface in Dom0 and the virtual network device in the unprivileged domain are connected through a virtual point-to-point connection.

4.

The virtual interface in Dom0 is added to the bridge with the physical interface.

These steps affect only the general network connectivity. The IP configuration inside the unprivileged domain is done separately with DHCP or a static network configuration. The following graphic illustrates the relationship of the various interfaces involved: Figure 10-16

Xen Networking

The output of ip a s shows the new interface: da10:~ # ip address show 1: lo: mtu 16436 qdisc noqueue state UNKNOWN ... 2: eth1: mtu 1500 qdisc pfifo_fast state DOWN qlen 1000 ... 3: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 100 ... 4: br0: mtu 1500 qdisc noqueue state UNKNOWN link/ether 00:19:d1:9f:17:87 brd ff:ff:ff:ff:ff:ff inet 172.17.8.1/16 brd 172.17.255.255 scope global br0 inet6 fe80::219:d1ff:fe9f:1787/64 scope link valid_lft forever preferred_lft forever 5: vif1.0: mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 32 link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff inet6 fe80::fcff:ffff:feff:ffff/64 scope link valid_lft forever preferred_lft forever

The new interface is added to the existing bridge, as shown in the output of brctl: da10:~ # brctl show bridge name bridge id br0 8000.0019d19f1787

424

STP enabled no


interfaces eth0 vif1.0

Version 1


The naming scheme is vifdomain_number.interface_number For example, the counterpart for eth0 in domain number 2 is vif2.0. The /etc/xen/scripts directory contains additional scripts that can be used to set up NAT or routing instead of the default bridge setup. In the /etc/xen/xendconfig.sxp file you can configure which network scripts are used by xend. NOTE: Because of the complexity of the Xen network setup, the default firewall (SuSEFirewall2) is not working correctly in Dom0. We recommend that you disable SuSEFirewall2 and then set up a customized firewall script if needed.

Version 1


425






Exercise 10-4

Check the Network Configuration In this exercise, you learn how to use the brctl show command to view the bridge setup and changes to it. You will find this exercise in the workbook. (End of Exercise)

426


Version 1


Summary Objective

Summary

Understand How Virtualization with Xen Works

Virtualization technology separates a running instance of an operating system from the physical hardware. Instead of running on a physical machine, the operating system runs in a so-called virtual machine. Multiple virtual machines share the resources of the underlying hardware. There are two different kinds of virtualization: 

Full virtualization



Para-virtualization

Para-virtualization requires modifications to the operating system running in the virtual machine. Install Xen

To use Xen, you have to install the Xen hypervisor, a kernel that is aware of Xen, and the Xen management tools in the SLES 11 installation running on the physical hardware (the virtual machine server). After booting the Xen kernel, you can install virtual machines using the vm-install tool.

Manage Xen Domains with VirtManager

Virt-Manager can be used to manage Xen domains. Virt-Manager allows you to start virtual domains, open a VNC window to view the graphical interface, and change virtual hardware parameters such as available RAM or hard disk space. Virt-Manager displays all managed domains (running or not) and running unmanaged domains.

Manage Xen Domains from the Command Line

xm is the command line administration tool for xen domains. To start a virtual machine, the create subcommand is used for unmanaged machines, while start is used for managed machines: xm create -c -f /etc/xen/vm/SLES11.conf xm start sled11 Other frequently used xm subcommands are shutdown, stop, new, and delete. Use xm help for a complete list of available commands.

Version 1


427






Objective

Summary

Understand Xen Networking

Domain 0 (Dom0) is the central point to configure the network connections on a Xen system. The configuration in Dom0 determines what virtual network hardware is available within a domain U (DomU). All unprivileged domains are connected with the physical network through Dom0. A network bridge in Dom0 is used as a virtual switch. This bridge is controlled by xend. The IP configuration of virtual network cards is done from within the unprivileged domains.

428


Version 1


SECTION 11


In this section, you work through the following scenarios to prepare for the Novell CLP (Certified Linux Professional) 11 practicum exam: 1.

“Install a Xen Environment” on page 430

2.

“Configure a Web Server” on page 431

3.

“Configure a Samba File Server” on page 432

4.

“Automate System Tasks” on page 433

Remember that skills from all three Novell CLP courses might be necessary to fulfill the required tasks. NOTE: There might be not enough time to complete all of the objectives in this section on the last day of the course. We recommend you complete the remaining parts at home.

Scenario

DigitalAirlines is planning on deploying SUSE Linux in its IT infrastructure. During the first phase, SUSE Linux Enterprise Server 11 will be used on the back-end systems like file, Web, and network-infrastructure servers. As the network administrator for your DigitalAirlines office, you (along with the management) have designed a migration plan which includes the following services to be migrated to SUSE Linux Enterprise Server 11: 

Intranet Web server



File and print services for Windows clients.

Both services should run on the same physical system in separate Xen domains. You decide to start by installing and testing these services on a computer in the test lab.

Version 1


429






Objective 1

Install a Xen Environment To create a base for the Samba and the Apache system, it’s required to reinstall your physical machine and to set up three Xen domains. One domain0 and two domainUs. Set up your system according to the following guidelines:

430



Delete the existing installation on your system and reinstall SUSE Linux Enterprise Server 11.



During the installation, create a partition which has a enough space to hold the file system image files of two SUSE Linux Enterprise Server 11 Xen installations. Mount this partition under /xen in domain0.



Install Xen and boot into domain0 of the Xen system.



Create two Xen domains with YaST and install SUSE Linux Enterprise Server 11. Make sure that the file system image files are stored under /xen.



Make sure that networking works in domain0 and in the two domainU systems.


Version 1


Objective 2

Configure a Web Server Your DigitalAirlines office runs an internal Web server which provides vital information for employees. The server hosts a general portal site and a virtual host for every department. Because the Web server needs to be migrated to SUSE Linux Enterprise Server 11, you decide to create a prototype system for the general portal site and two departments (accounting and marketing) in one of the Xen domains (domainU). Set up the prototype system using the following guidelines: 

Install and configure an Apache Web server that hosts the general portal site and two virtual hosts for the departments accounting and marketing.



Use the Apache example pages as demo content.



The virtual host from accounting should run under SSL and should be accessible only to the users in the accounting group.



Make additional entries in the file /etc/hosts to test the virtual host setup.



From each department, one user should be allowed to log in using SSH on the server to change the content of the virtual host. Create the users JNelson and SRife on your system. JNelson should be responsible for the marketing department and SRife for the accounting department.



Version 1

All pages which you have to migrate end in .htm. Create a shell script which replaces the .htm with .html.


431






Objective 3

Configure a Samba File Server As part of the SUSE Linux migration plan for your DigitalAirlines office, you need to move file and print services to a Samba server running on SUSE Linux Enterprise Server 11. You decide to test this migration for the marketing department on the other Xen domain (domainU). Set up the Samba server using the following guidelines:

432



Install the Samba server and client software.



Configure a marketing workgroup.



Create a UNIX group named marketing.



Create two normal users (PSmith and JWattson) who are members of the accounting group and are included in the smbpasswd file.



Create one shared folder for the group accounting.



Test your shares (you can use smbclient).


Version 1


Objective 4

Automate System Tasks In order to make the administration of the SUSE Linux Enterprise Server 11 system as convenient as possible, certain task should be automated with shell scripts. Do the following: 

On domain0, develop a shell script which can be used to start and stop the Web server and the Samba server domains. The scripts should simply take the parameters start and stop. Every call of the scripts should be documented by sending a mail to the root user. First, develop a script for the Web server domain. When this script works properly, make a copy and adjust it for the Samba server domain. Both scripts should be installed in the ~/bin directory of the root user.



On the Samba server, develop a script that searches for Windows executables in the shared folder of the accounting department. Use the file command to determine whether a file is a Windows executable or not. When a file is detected as a Windows executable, it should be moved to a quarantine directory in root’s home directory. Additionally, a mail should be sent to the root user for every executable found. The mail should include information about the filename and the location where the file was found.



Version 1

On the Web server domain, develop a backup script that makes an incremental backup of the /srv/www/ directory. Status information about the backup should be mailed to the root user when the backup has been completed.


433






434


Version 1


Index

Index

Symbols /etc/apache2/ 8-230 /etc/auto.master 4-32 /etc/cups/cupsd.conf 5-105–5-106 /etc/cups/ppd/ 5-94 /etc/cups/printers.conf 5-100 /etc/dhcpd.conf 12-376 /etc/exports 4-24 /etc/group 6-122 /etc/init.d/ntp 4-47 /etc/nsswitch.conf 6-146 /etc/passwd 6-122 /etc/printcap 5-102 /etc/samba/smb.conf 7-179 /etc/samba/smbpasswd 7-192 /etc/shadow 6-122 /etc/sysconfig/clock 4-38 /etc/sysconfig/dhcpd 12-375 /etc/sysconfig/ntp 4-49 /etc/xen/vm/ 13-415 /etc/xinetd.conf 4-56 /etc/xinetd.d/ 4-57 /srv/www/htdocs 8-225 /var/lib/autoinstall/repository/ 12-382 /var/log/ntp 4-49 /var/spool/cups/ 5-99

Numerics 6in4 tunnel 9-270 6to4 tunnel 9-266

A accept 5-94 add_on_products.xml 12-359, 12-365 Add-On Creator 12-359 add-on product 12-359 adjtimex 4-37 Allow from 8-238 Apache 8-224 access control 8-237 configuration 8-229

Version 1

installation 8-226 PHP 8-248 SSL 8-241 apache2ctl configtest 8-231 arithmetic operations 11-325 array 11-331 attribute 6-130 autofs 4-32 automated installation 12-385 AutoYaST 12-354 Create configuration file 12-381 reference profile 12-382

B Backup Domain Controller 7-211 Bash 11-301–11-302 BDC 7-211 bind= 4-25 bottleneck 10-274 bridge 13-422

C cancel 5-93 case 11-319 certificate 8-243 chkconfig xinetd 4-59 CIDR 9-256 cifs 7-204 classless interdomain routing 9-256 CMOS clock 4-36 command substitution 11-313 common name 6-135 Common UNIX Printing System 5-73 container objects 6-128 context 6-134 control structures 11-316 country object 6-129 create_package_descr 12-366 create_sha1sums 12-366 create_update_source.sh 12-365 crossmnt 4-25


15-435



CUPS 5-73 access log 5-102 access restrictions 5-107, 5-109 Berkeley style commands 5-91 browsing 5-106 classes 5-115 configuration 5-74 configuration file 5-105 documentation 5-115 error log 5-104 page log 5-104 print queues 5-100 System V style commands 5-91 web interface 5-113 cups policies 5-109 cupsd, start and stop 5-97 cupsdisable 5-94 cupsenable 5-94 cupsomatic 5-99 cut 11-341

D DAP 6-126 date 4-37, 11-342 Deny from 8-238 deployment strategy 12-356 DHCP Server 12-371 DIB 6-125 Directory Access Protocol 6-126 Directory Information Database 6-125 Directory Information Shadowing Protocol 6-127 Directory Information Tree 6-126 Directory System Agent 6-126 Directory System Protocol 6-127 Directory User Agent 6-126 DISP 6-127 Displays 10-275 distinguished name 6-135 DIT 6-126 document root 8-225 Dom0 13-396 domain managed 13-415 unmanaged 13-415 Domain 0 13-396 domain component objects 6-128 domain controller 7-207, 7-210

15-436

domain database 7-210 Domain U 13-397 domains 7-210 DomU 13-397 drift 4-42 DSA 6-126 DSP 6-127 DUA 6-126

E egrep 11-342 encryption 8-241 exportfs 4-26

F file descriptor 11-303 File Transfer Protocol 4-63 for loop 11-320 free 10-277 fsid=0 4-25 FTP 4-63 active 4-64 anonymous 4-66 passive 4-64 protocol 4-63 FTP server 4-64 full virtualization 13-395 function 11-337

G gethostip 12-373 getopts 11-338 GMT 4-37 Gnome System Monitor 10-282 Greenwich Mean Time 4-37 grep 11-342 groupadd 6-155 groupdel 6-155 groupmod 6-155

H hardware clock 4-36 HTML 8-224 htpasswd2 8-239 HTTP headers 8-226


Version 1


Index

Request method 8-225 HTTPS 8-226 hwclock 4-37–4-38 Hyper-Text Markup Language 8-224

I IETF 9-255 if 11-316 installation automated 12-354, 12-385 deployment strategy 12-356 options 12-355 installation repository 12-358 installation server 12-358 inst-source-utils 12-365 Internet Engineering Task Force 9-255 Internet Printing Protocol 5-73 Internet Protocol Version 6 9-255 iostat 10-279 ip 9-265 IPP 5-73 IPv6 9-255 address types 9-257 addresses 9-256 autoconfiguration 9-261 features 9-256 host address 9-259 ip command 9-265 network addresses 9-258 unicast addresses 9-258

J jitter 4-42

K KDE System Guard 10-275, 10-282

L LDAP 6-122, 6-127 LDAP Browser 6-145 LDAP browser 6-165 LDAP client, installation 6-145 LDAP Data Interchange Format 6-156 LDAP Directory Tree 6-127 LDAP server, installation 6-136 LDAP, root entry 6-145

Version 1

LDAP, user management in YaST 6-159 ldapadd 6-157 ldapdelete 6-159 ldapmodify 6-158 ldapsearch 6-155 LDIF 6-156 leaf objects 6-128 Lightweight Directory Access Protocol 6-122, 6-127 link local address 9-258 local master browser 7-209 local time 4-37 lp 5-91 lpadmin 5-89 lpoptions 5-92, 5-95 lpq 5-92 lpr 5-91 lprm 5-93 lpstat 5-92

M machine accounts 7-215 master browser 7-209 memory 10-275 mount 7-204

N NetBIOS 7-174 NetBIOS name 7-175 NetBIOS Suffix 7-175 netdate 4-37, 4-39 Network Basic Input/Output System 7-174 Network File System 4-18 network prefix 9-257 Network Time Protocol 4-36 NFS 4-18 client options 4-30 Configuration 4-21 Manual server configuration 4-24 Server Configuration with YaST 4-21 nmbd 7-177 nmblookup 7-177, 7-202 no_root_squash 4-25 no_subtree_check 4-25 NTP 4-36, 4-40 configuration with YaST 4-43 control server 4-49 server 4-43


15-437



R

server monitoring 4-50 stratum 4-40 terms 4-42 ntpd 4-37, 4-41 ntpdate (deprecated) 4-49 ntpq 4-51 ntptrace 4-50

O object 6-130 object, property 6-130 objects, types of 6-130 OpenLDAP 6-121 openssl 8-244 Order deny,allow 8-238 organizational units 6-128

P para-virtualization 13-395 passwd 6-155 PDC 7-210 performance 10-273 PHP 8-248 installation 8-248 phpinfo 8-250 pipe operator 11-304 portmapper 4-19 Preboot Execution Environment 12-371 Primary Domain Controller 7-210 print queues 5-100 printer add with YaST 5-76 printing process 5-99 privileged Domain 13-397 processor utilization 10-274 property 6-130 PureFTPd 4-64 authorized users 4-68 configuration 4-66 installation 4-65 logs 4-70 user management 4-69 virtual hosts 4-67 pure-pw 4-69 PXE 12-371 pxelinux 12-372

15-438

RAM 10-276 rccups 5-97 rcnfsserver 4-26 rcnmb 7-179 rcntp 4-50 rcsmb 7-179 read 11-328 Real Time Clock 4-36 reject 5-94 relative distinguished name 6-135 Remote Procedure Call 4-19 return value 11-306 root_squash 4-25 RPC 4-19 rpcbind 4-19 rpcinfo 4-34 rsync 11-308, 11-334 RTC 4-36 rules of containment 6-133

S Samba 7-174 client tools 7-202 configuration with YaST 7-185 configurationtest 7-185 domain controller 7-207 domain controller configuration 7-211 global section 7-180 homes section 7-181 LDAP as user database 7-193 manual configuration 7-179 printers 7-183 user database 7-192 Samba authentication 7-192 schema 6-130, 6-133 Secure Socket Layer 8-241 sed 11-343 Server Message Block 7-174 set -x 11-310 share 7-174 configuration 7-182 printers 7-183 she-bang 11-308 shell 11-301 shell script 11-307 shell scripts 11-301 showmount 4-34


Version 1


Index

SMB 7-174, 7-176 SMB commands 7-176 smbclient 7-177, 7-202 smbd 7-177 smbpasswd 7-192 sntp 4-50 SSL 8-241 Standard Error 11-302 Standard In 11-303 Standard Out 11-302 stderr 11-302 stdin 11-303 stdout 11-302 stratum 4-40 subtree_check 4-25 swap partition 10-276 syslinux 12-372 system memory 10-275 system time 4-36

virtual host 8-233 configuration 8-234 virtualization 13-395 vm-install 13-400 vmstat 10-277–10-278

W while loop 11-322 winbind 7-177 Windows domain 7-210 Windows domain membership 7-219 Windows Internet Naming Service 7-175 WINS 7-175 WINS server 7-175 workgroup 7-180, 7-207 workstation machine account 7-215

X

T test 11-317, 11-345 testparm 7-185 TFTP server 12-371 top 10-274 tr 11-347 trust 7-211 trust relationships 7-211 tunnel broker 9-270

U UNC 7-174 Uniform Resource Locator 8-226 Universal Naming Convention 7-174 Universal Time Coordinated 4-37 until loop 11-322 uptime 10-274 URL 8-226 useradd 6-155 userdel 6-155 usermod 6-155 UTC 4-37 utilization 10-274

X.500 6-125 X.500 Directory 6-125 Xen 13-393 Xen networking 13-422 Xen server 13-398 Xen virtual machine 13-400 Xen virtual machine installation 13-401 xend 13-397 xinetd 4-53 access control 4-59 configuration defaults 4-56 configuration with YaST 4-53 log file 4-61 manual configuration 4-55 xm 13-415

Y YaST IPv6 9-262 YaST LDAP browser 6-165 YaST module Autoinstallation 12-381

V variable 11-304, 11-312 virt-manager 13-409

Version 1


15-439



15-440


Version 1


3103 Manual

Recommend Documents