- •Contents
- •Preface to second edition
- •1 Introduction
- •1.2 Applying technology in an environment
- •1.3 The human role in systems
- •1.4 Ethical issues
- •1.7 Common practice and good practice
- •1.8 Bugs and emergent phenomena
- •1.10 Knowledge is a jigsaw puzzle
- •1.11 To the student
- •1.12 Some road-maps
- •2 System components
- •2.2 Handling hardware
- •2.3 Operating systems
- •2.4 Filesystems
- •2.5 Processes and job control
- •2.6 Networks
- •2.7 IPv4 networks
- •2.8 Address space in IPv4
- •2.9 IPv6 networks
- •3 Networked communities
- •3.1 Communities and enterprises
- •3.2 Policy blueprints
- •3.4 User behavior: socio-anthropology
- •3.5 Clients, servers and delegation
- •3.6 Host identities and name services
- •3.8 Local network orientation and analysis
- •4 Host management
- •4.1 Global view, local action
- •4.2 Physical considerations of server room
- •4.3 Computer startup and shutdown
- •4.5 Installing a Unix disk
- •4.6 Installation of the operating system
- •4.7 Software installation
- •4.8 Kernel customization
- •5 User management
- •5.1 Issues
- •5.2 User registration
- •5.3 Account policy
- •5.4 Login environment
- •5.5 User support services
- •5.6 Controlling user resources
- •5.7 Online user services
- •5.9 Ethical conduct of administrators and users
- •5.10 Computer usage policy
- •6 Models of network and system administration
- •6.5 Creating infrastructure
- •6.7 Competition, immunity and convergence
- •6.8 Policy and configuration automation
- •7.2 Methods: controlling causes and symptoms
- •7.4 Declarative languages
- •7.6 Common assumptions: clock synchronization
- •7.7 Human–computer job scheduling
- •7.9 Preventative host maintenance
- •7.10 SNMP tools
- •7.11 Cfengine
- •8 Diagnostics, fault and change management
- •8.1 Fault tolerance and propagation
- •8.2 Networks and small worlds
- •8.3 Causality and dependency
- •8.4 Defining the system
- •8.5 Faults
- •8.6 Cause trees
- •8.7 Probabilistic fault trees
- •8.9 Game-theoretical strategy selection
- •8.10 Monitoring
- •8.12 Principles of quality assurance
- •9 Application-level services
- •9.1 Application-level services
- •9.2 Proxies and agents
- •9.3 Installing a new service
- •9.4 Summoning daemons
- •9.5 Setting up the DNS nameservice
- •9.7 E-mail configuration
- •9.8 OpenLDAP directory service
- •9.10 Samba
- •9.11 The printer service
- •9.12 Java web and enterprise services
- •10 Network-level services
- •10.1 The Internet
- •10.2 A recap of networking concepts
- •10.3 Getting traffic to its destination
- •10.4 Alternative network transport technologies
- •10.5 Alternative network connection technologies
- •10.6 IP routing and forwarding
- •10.7 Multi-Protocol Label Switching (MPLS)
- •10.8 Quality of Service
- •10.9 Competition or cooperation for service?
- •10.10 Service Level Agreements
- •11 Principles of security
- •11.1 Four independent issues
- •11.2 Physical security
- •11.3 Trust relationships
- •11.7 Preventing and minimizing failure modes
- •12 Security implementation
- •12.2 The recovery plan
- •12.3 Data integrity and protection
- •12.5 Analyzing network security
- •12.6 VPNs: secure shell and FreeS/WAN
- •12.7 Role-based security and capabilities
- •12.8 WWW security
- •12.9 IPSec – secure IP
- •12.10 Ordered access control and policy conflicts
- •12.11 IP filtering for firewalls
- •12.12 Firewalls
- •12.13 Intrusion detection and forensics
- •13 Analytical system administration
- •13.1 Science vs technology
- •13.2 Studying complex systems
- •13.3 The purpose of observation
- •13.5 Evaluating a hierarchical system
- •13.6 Deterministic and stochastic behavior
- •13.7 Observational errors
- •13.8 Strategic analyses
- •13.9 Summary
- •14 Summary and outlook
- •14.3 Pervasive computing
- •B.1 Make
- •B.2 Perl
- •Bibliography
- •Index
378 |
CHAPTER 9. APPLICATION-LEVEL SERVICES |
9.10 Samba
Samba is a free software solution to the problem of making Unix filesystems available to Windows operating systems. Windows NT uses a system of network file sharing based on their own SMB (Server message block) protocol. Samba is a Unix daemon-based service which makes Unix disks visible to Windows NT. Samba maps usernames, so to use Samba we need an account with the same name on the NT server and on the Unix server. It maps usernames textually, without much security. Samba configuration is in Unix style, by editing the text-file /etc/smb.conf. Here is an example file. Note carefully the ‘hosts allow’ line which restricts access to disks to specific IP addresses, like TCP wrappers.
[global] printing = bsd
printcap name = /etc/printcap load printers = yes
guest account = nobody invalid users = root workgroup = UNIX hosts allow = 128.39.
[homes]
comment = Home Directories browseable = no
read only = no create mode = 0644
[printers]
comment = All Printers browseable = no
path = /tmp printable = yes public = no writable = no create mode = 0644
Once the Samba server is active, the disks are available for use with the net use command, e.g.
C:\> net use F: \\host\directory
This example maps the named directory on the named host to NT drive letter F:. The reverse problem of mounting NT filesystems on a Unix host works only for GNU/Linux hosts at present:
gnulinux% smbmount //nthost/directory /mountpoint -U administrator
9.11. THE PRINTER SERVICE |
379 |
9.11 The printer service
Printing services vary from single printers coupled to private workstations to huge consolidated spooling services serving large organizations [329, 251].
Host print services need to be told about available printers by registering the printers in a local database. In BSD-like print servers this database is kept in a flat file called /etc/printcap. In System V print servers, a program called lpadmin is used to register printers and it’s anyone’s guess what happens to that information.
The way in which we register printers thus depends on
•What kind of operating system we are using
•Whether we are running any special network printer software.
The main difference is between BSD-like systems and System V. Recently a replacement print service was introduced for a generic heterogeneous network. Called LPRng, this package preserves the simplicity of the BSD system while providing superior functionality to both [243]. Another alternative is the Common Unix Printing System (CUPS).
In order to register a printer with a BSD-like printer service, we do the following:
•Think of a name for the printer.
•Decide whether it is going to be connected directly to a host or stand alone on the network.
•Register the printer with the printing system so that the daemons which provide the print service know how to talk to it. This can include manually making a ‘spool’ directory for its queue files. This normally lies under var/spool or /usr/spool.
mkdir /var/spool/ printer-name
•Most Unix systems assume the existence of a default printer which is referred to by the name ‘lp’. If you do not specify a particular printer when printing, your data are sent to the default printer. It is up to us to name or alias one of our printers ‘lp’. Each printer may have several names or aliases.
With some print spoolers, we also need to decide whether to send all data to a common central server, or whether to let each host handle its own negotiations for printing. If we are interested in maintaining a record of how many pages each user has printed, then a centralized solution is a much simpler option. The downside of this is that, if there is a large user base, the traffic might present a considerable load for one host. A central print spooler must have sufficient disk space to temporarily store all the incoming print jobs.
9.11.1CUPS/LPRng
The Common Unix Print System (CUPS) has emerged in the last few years as the favored printing solution on many desktops. It reads information from traditional Unix format files.
380 |
CHAPTER 9. APPLICATION-LEVEL SERVICES |
LPRng is a rival attempt that is configured quite simply in a manner very similar to (but not identical to) the old Berkeley printcap system.
Suggestion 12 (Unix printing). Install LPRng on all hosts in the network. Forget about trying to understand and manage the native printing systems on system V and BSD hosts. LPRng can replace them all with a system which is at least as good. Another alternative system is the Common Unix Printing System.a
aThe author’s experience with CUPs is that it is not yet a robust alternative.
If one follows this suggestion there is only a single printer system to worry about. Note that most GNU/Linux distributions (e.g. Debian) have packages for this system, so it will not need to be installed from scratch.
The software uses a printcap file and two other optional files called lpd.conf and lpd.perms. The printcap file is like a regular printcap file but without the backslash continuation characters. LPRng provides effectively both lpr, lpd, lpq and lprm commands from Berkeley and lp, lpstat and cancel commands from System V. The daemon reads the three configuration files and handles spooling. The configuration is challenging but straightforward and there is extensive documentation. Here is a simple example for a network printer (with its own IP address) which allows logged on users to start and delete their own printjobs:
# /etc/printcap (lprng)
myprinter|lp
:if=/local/bin/lpf # LF/CR filter :af=/var/spool/lpd/acctfil :lf=/var/spool/lpd/printlog :sd=/var/spool/myprinter :lp=xxx.yyy.zzz.mmm%9100
:rw
:sh
The IP address of the printer is xxx.yyy.zzz.mmm and it must be written in numerical form. The percent symbol marks the standard port 9100. The lpd.conf file is slightly mysterious but has a number of useful options. Most, if not all, of these can be set in the printcap file also, but options set here apply for all printers. One nice feature for instance is the ability to reject printouts of binary (non-printable) files. This can save a few rain forests if someone is kind enough to dump /bin/ls to the printer.
#
#lpd.conf
#Purpose: name of accounting file (see also la, ar) af=/var/spool/lpd/acctfil
#Purpose: accounting at start (see also af, la, ar)
9.11. THE PRINTER SERVICE |
381 |
as=jobstart $H $n $P $k $b $t
# Purpose: check for nonprintable file check_for_nonprintable
#Purpose: default printer default_printer=local
#Purpose: error log file (servers, filters and prefilters) lf=/var/adm/printlog
#Purpose: lpd lock file lockfile=/var/spool/lpd/lpd.lock.%h
#Purpose: lpd log file
logfile=/var/spool/lpd/lpd.log.%h
#Purpose: /etc/printcap files printcap_path=/etc/printcap
#Purpose: suppress headers and/or banner page sh
The lpd.perms file sets limits on who can access the printers and from where, unlike the traditional services which are open to everyone.
#
#lpd.perms
#allow root on server to control jobs ACCEPT SERVICE=C SERVER REMOTEUSER=root
#allow anybody to get status ACCEPT SERVICE=S
#reject all others, including lpc commands permitted by user_lpc REJECT SERVICE=CSU
#allow same user on originating host to remove a job
ACCEPT SERVICE=M SAMEHOST SAMEUSER
#allow root on server to remove a job ACCEPT SERVICE=M SERVER REMOTEUSER=root REJECT SERVICE=M
#All other operations disallowed
DEFAULT REJECT |
# orACCEPT |
LPRng claims to support Berkeley printcap files directly. However, in trials its behavior has been quirky, with some things working and others not. In any event, LPRng is a highly welcome piece of software which works supremely well, once configured.