Managing System Services Many programs run on your system to provide an assortment of services to you as a local user and to remote users contacting your system. These services range from obvious things (such as terminal services that allow you to connect to your machine from remote locations and file-sharing services) to less obvious but still useful services (such as the ones that provide wall-clock time information and remote machine status information). Programs that provide service for all users on a machine are generally started by one of two different mechanisms. Either they are started at machine startup, by a series of shell scripts that execute programs during boot, or they are executed by a daemon that waits for requests for service and starts the appropriate program to handle the request. Traditional Unixes manage most system services through inetd and/or xinetd. Early releases of Mac OS X used inetd and SystemStarter as the primary mechanisms for managing system services. Starting with Mac OS X 10.3, xinetd and SystemStarter were the primary mechanisms. Starting with Mac OS X 10.4, launchd has become the primary mechanism for managing system services. However, vestiges of xinetd and SystemStarter remain in Tiger. In this section, we will take a look at the basic files involved in stopping and starting services, the services used to stop and start services, and commands used to stop and reboot the machine itself. Starting and Stopping Services: launchd New with Tiger is the launchd service. This is Apple's own home-grown service-control daemon, and xinetd, discussed in a later section, is becoming a legacy-support option. For new services support, and for older services that have been tested with the new launch configuration, Apple is gravitating toward the use of launchd. Understanding Files in /System/Library/LaunchDaemons The system stores the information that launchd needs for determining what services to start in /System/Library/LaunchDaemons. This directory now contains files for a number of services that were previously controlled either by SystemStarter or xinetd. The following is a listing of the /System/Library/LaunchDaemons directory: dogbone:/System/Library/LaunchDaemons joray$ ls bootps.plist finger.plist com.apple.KernelEventAgent.plist ftp.plist com.apple.atrun.plist login.plist com.apple.mDNSResponder.plist nmbd.plist com.apple.nibindd.plist ntalk.plist com.apple.periodic-daily.plist org.isc.named.plist com.apple.periodic-monthly.plist org.postfix.master.plist com.apple.periodic-weekly.plist org.xinetd.xinetd.plist com.apple.portmap.plist printer.plist com.apple.syslogd.plist shell.plist com.apple.xgridagentd.plist smbd.plist com.apple.xgridcontrollerd.plist ssh.plist com.vix.cron.plist swat.plist eppc.plist telnet.plist exec.plist tftp.plist
These services are described in Table 16.3. Table 16.3. Typical Items in the /System/Library/LaunchDaemons DirectoryFile | Description |
|---|
bootps.plist | bootp is a way of transmitting network configuration information to clients. Chances are you'll use DHCP for this, if you have the need to do so, although it's possible that Mac OS X server could use bootp for netboot clients. Formerly started out of xinetd. | com.apple.KernelEventAgent.plist | Starts the kernel event agent. This is an undocumented service. Perhaps it involves communication between parts of the kernel. Formerly started out of SystemStarter. | com.apple.atrun.plist | Starts atrun, which runs jobs queued for later execution by at, which is usually invoked by cron. | com.apple.mDNSResponder.plist | Starts the multicast DNS Responder, the part of the Bonjour system that listens for and responds to DNS-format query packets. Formerly started out of SystemStarter. | com.apple.nibindd.plist | Starts the NetInfo binder, which is responsible for finding, creating and destroying NetInfo servers. | com.apple.periodic-daily.plist | Runs periodic system functions daily. These actions usually occur daily at 3:15 a.m.. It is intended to be called by cron. | com.apple.periodic-monthly.plist | Runs periodic system functions monthly. These actions occur on the first day of the month at 5:30AM. It is intended to be called by cron. | com.apple.periodic-weekly.plist | Runs periodic system functions weekly. These actions occur on Saturdays at 3:15 a.m It is intended to be called by cron. | com.apple.portmap.plist | Provides connectivity between remote machines and services on your machine that don't have defined TCP/IP ports that they run on. Formerly started out of SystemStarter. | com.apple.syslogd.plist | Starts the system logging daemon. Formerly started out of SystemStarter. | com.apple.xgridagentd.plist | Starts xgridagentd, the service then connects to an xgrid controller. xgrid is the Apple product that sets up a cluster of machines for distributed computing. The product is similar to the Sun Grid Engine. | com.apple.xgridcontollerd.plist | Starts the xgrid controller service, which controls how xgrid jobs are handled. | com.vix.cron.plist | A service that starts various programs at specified times or specified intervals. Formerly started out of SystemStarter. | eppc.plist | Starts the Apple Event Server, which handles incoming AppleEvents. AppleEvents are communications between applications and the system. Originally started out of SystemStarter and then out of xinetd in 10.3. | exec.plist | Starts rexecd, a service that allows for the remote execution of parts of programs. Apple claims that it isn't known to be useful, but a programmer can make good use of this service to perform distributed processing tasks by sending parts of the programs to many different machines. Of course, it is a security risk. Originally run out of inetd and then xinetd. | finger.plist | The fingerd daemon allows external users to finger a user ID and find out whether the ID exists; if it does, how recently, and on what terminals the ID has been logged in. Originally started out of inetd and then xinetd. | ftp.plist | The ftpd daemon provides an FTP (File Transfer Protocol) server. Originally started out of inetd, and then xinetd. You can find more information on ftpd in Chapter 22. | login.plist | Provides service for the rlogin remote login terminal program. Don't turn this on. Originally started out of inetd and then xinetd. | nmbd.plist | The NetBIOS name server provides NetBIOS over IP naming services to clients. It is a part of the samba suite. Formerly started out of xinetd. You can find more information on providing Windows services in Chapter 27. | ntalk.plist | The ntalk (new protocol talk) daemon provides for real-time chat services. If you're familiar with ICQ, iChat or IRC, this service is somewhat similar. Originally started out of inetd and then xinetd. | org.isc.named.plist | Starts the name server. Previously started out of SystemStarter. | org.postfix.master.plist | Starts the postfix mail server. Previously started out of SystemStarter. | org.xinetd.xinetd.plist | A service that starts and controls other services. It is a more secure replacement for the traditional inetd, and it first entered the Mac OS X distribution with 10.2. Commonly used on many Unix platforms, but is being phased out of Mac OS X. Previously started out of SystemStarter. | printer.plist | Starts the CUPS (Common Unix Printing Service) line printer daemon printing service that provides some legacy printing support. For more information on printing, see Chapter 6. | shell.plist | Starts rshd, a service that provides remote shell access. This service is required to use certain remote services, such as remote tape archive storage. Because Apple hasn't provided all the software necessary to make full use of these services, we suggest that this be left off as well; it's almost as large a security risk as rlogin and telnet. Originally started out of inetd and then xinetd. | smbd.plist | Provides printing and file share services to Windows clients. Originally started out of SystemStarter and then xinetd. You can find more information on providing Windows services in Chapter 27. | ssh.plist | Starts SSH, the secure shell service. This service provides remote terminal access over an encrypted channel. Originally started out of SystemStarter and then xinetd. For more information on SSH, see chapter 21. | swat.plist | Starts swat, the Samba Web Administration Tool. Previously started out of xinetd. You can find more information on providing Windows services in Chapter 27. | telnet.plist | Provides the telnet daemon to allow remote telnet terminal access. Don't turn this on. | tftp.plist | tftp is trivial file transfer protocol and is one of the methods of providing file service to completely diskless network clients. You won't need to enable this service unless you're providing network boot services for diskless Unix clients. |
Because the FTP server is one that you might consider replacing, we will look at the default ftp.plist. Listing 16.1 shows a sample plist file from this directory. NOTE The numbers shown in Listing 16.4 are shown here to make the description of the file easier to follow. The line numbers are not and should not be in the actual file. This is also the case for all the listings in this chapter with line numbers. |
Listing 16.4. The Default /System/Library/LaunchDaemons/ftp.plist File 1 <?xml version="1.0" encoding="UTF-8"?> 2 <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com  /DTDs/PropertyList-1.0.dtd"> 3 <plist version="1.0"> 4 <dict> 5 <key>Disabled</key> 6 <true/> 7 <key>Label</key> 8 <string>com.apple.ftpd</string> 9 <key>Program</key> 10 <string>/usr/libexec/ftpd</string> 11 <key>ProgramArguments</key> 12 <array> 13 <string>ftpd</string> 14 <string>-l</string> 15 </array> 16 <key>inetdCompatibility</key> 17 <dict> 18 <key>Wait</key> 19 <false/> 20 </dict> 21 <key>Sockets</key> 22 <dict> 23 <key>Listeners</key> 24 <dict> 25 <key>SockServiceName</key> 26 <string>ftp</string> 27 <key>Bonjour</key> 28 <true/> 29 </dict> 30 </dict> 31 </dict> 32 </plist>
From this file we learn the following: Lines 5 6 show that the Disabled key is true. Because the default for the Disabled key is false, when a service has been enabled, the Disabled key is removed. Lines 7 8 show how the program will be listed when you list all the jobs loaded into launchd. This one will be listed as com.apple.ftpd. Lines 9 10 list where the service is located. In this case, the default ftpd is in /usr/local/libexec/ftpd. This is the equivalent of the sixth column of an /etc/inetd.conf file's ftp line. Lines 11 15 list how the program will be run, including any runtime options. This is equivalent to the final column in an /etc/inetd.conf file. In lines 16 20, the inetdCompatibility key indicates to launchd that the service expects to be run as though it were launched from inetd. The Wait flag for that key is set to false, which is the equivalent of the nowait enTRy in /etc/inetd.conf. Lines 21 28 are the Sockets section, which specifies launch on demand sockets that can be used to let launchd know when to run the job. The ftp entry tells launchd to connect to the ftp service. The Bonjour key enables the FTP server to be found via Bonjour.
Understanding launchd There are various ways to start services that run via launchd. First try /sbin/service. For example, to replace the default ftpd with a new one, stop the FTP server using /sbin/service, if it was already running. Keep a copy of your original ftp.plist, and then edit the file with appropriate changes for the new FTP server. Start the ftp service with /sbin/service. As long as you keep the ftp.plist name for your new FTP server, you can also start and stop the FTP server via launchd by using the Sharing preferences pane. If /sbin/service does not work for you, you can try to unload the old ftp job, if it was already loaded, and then load your new ftp job. Note that you must be root or use sudo to do this. localhost:/System/Library/LaunchDaemons root# launchctl list com.apple.KernelEventAgent com.apple.launchd_helperd com.apple.mDNSResponder com.apple.nibindd com.apple.portmap com.apple.syslogd com.openssh.sshd com.apple.ftpd localhost:/System/Library/LaunchDaemons root# launchctl unload /System/Library/ LaunchDaemons/ftp.plist localhost:/System/Library/LaunchDaemons root# launchctl list com.apple.KernelEventAgent com.apple.launchd_helperd com.apple.mDNSResponder com.apple.nibindd com.apple.portmap com.apple.syslogd com.openssh.sshd localhost:/System/Library/LaunchDaemons root# launchctl load /System/Library/ LaunchDaemons/ftp.plist localhost:/System/Library/LaunchDaemons root# launchctl list com.apple.KernelEventAgent com.apple.launchd_helperd com.apple.mDNSResponder com.apple.nibindd com.apple.portmap com.apple.syslogd com.openssh.sshd com.apple.proftpd
What we have done here is, as root, we have looked at what jobs are loaded into launchd already with launchctl list. In this case, the default FTP server was running. With the launchctl unload command, we removed the current FTP server job and then we verified with launchctl list that the job was indeed removed. Next we edited the ftp.plist file (not shown). Included in our edits was a change in the job name, so that we could tell at a glance which FTP server is running. With launchtl load, we loaded our new ftp.plist, and then verified that the new job was loaded with launchctl list. Listing 16.5 shows an example of a modified ftp.plist that enables proftpd as the default FTP server. In this example, the Disabled key could have been omitted. Please note that you should probably more properly store your modified ftp.plist in /Library/StartupItems/, to ensure that system updates do not overwrite your modified file, but you might not be able to start and stop the FTP server from the Sharing preferences pane. Listing 16.5. A Modified /System/Library/LaunchDaemons/ftp.plist <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs /PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Disabled</key> <false/> <key>Label</key> <string>com.apple.proftpd</string> <key>Program</key> <string>/usr/local/sbin/proftpd</string> <key>inetdCompatibility</key> <dict> <key>Wait</key> <false/> </dict> <key>Sockets</key> <dict> <key>Listeners</key> <dict> <key>SockServiceName</key> <string>ftp</string> <key>Bonjour</key> <true/> </dict> </dict> </dict> </plist>
If you decide to run a new FTP server via xinetd rather than launchd, stop the current FTP server, if you have it running. Then move the default ftp.plist file elsewhere, such as /System/Library/LaunchDaemons-disabled/. We find that moving ftp.plist completely out of its default location makes everything work together better. Create your /etc/xinetd.d/ftp control file, and then start the FTP server with /sbin/service. Please note that if you decide to run the replacement FTP server via xinetd, the Sharing preferences pane FTP control can no longer be used. If you do decide to replace your FTP server, we recommend running it out of xinetd rather than launchd. At this time, you have a lot more control over the FTP server through xinetd. Command documentation for launchd is included in Table 16.4, and select command documentation is included for launchctl in Table 16.5. Be sure to take a look at the launchctl documentation table. It suggests a couple ways that you could probably start and stop jobs via launchctl. Table 16.4. Command Documentation for launchdlaunchd | Systemwide and per-user daemon/agent manager. | launchd [-vsx] | launchd manages daemons, both for the system as a whole and for individual users. Ideal daemons can launch on demand based on criteria specified in their respective XML property lists specified in the Files section. | During boot, launchd is invoked by the kernel to run as the first process on the system and to further bootstrap the rest of the system. | Extra Options When Run as PID 1 | -s | Single-user mode. Instructs launchd to give a shell prompt before booting the system. | -v | Verbose mode. | -x | Safe mode. Instructs the system to boot conservatively. | Files | ~/Library/LaunchAgents | Per-user agents provided by the user. | /Library/LaunchAgents | Per-user agents provided by the administrator. | /Library/LaunchDaemons | Systemwide daemons provided by the administrator. | /System/Library/LaunchAgents | Mac OS X per-user agents. | /System/Library/LaunchDaemons | Mac OS X systemwide daemons. |
Table 16.5. Select Command Documentation for launchctllaunchctl | Interfaces with launchd. | launchctl interfaces with launchd to load, unload daemons/agents and generally control launchd. launchctl supports taking subcommands on the command line, interactively, or even redirected from standard input. These commands can be stored in $HOME/.launchd.conf or /etc/launchd.conf to be read at the time launchd starts. | load [-w] <paths> | Loads the specified configuration files or directories of configuration files. The optional -w removes the disabled key and write the configuration files back out to disk. | unload [-w] <paths> | Unloads the specified configuration files or directories of configuration files. The optional -w add the disabled key and write the configuration files back out to disk. | start <joblabels> | Starts the specified jobs by label. | stop <joblabels> | Stops the specified jobs by label. Jobs may restart automatically if demand driven. | list | Lists all the jobs loaded into launchd. | limit [cpu | filesize | data |stack | core | rss | memlock | maxproc | maxfiles] [both [soft | hard]] | With no arguments, this command prints all the resource limits of launchd as found via getrlimit. When a given resource is specified, it prints the limits for that resource. With a third argument, it sets both the hard and soft limits to that value. With four arguments, the third and forth argument represent the soft and hard limits respectively. See setrlimit. | shutdown | Tells launchd to prepare for shutdown by removing all jobs. | help | Prints out a quick usage statement. |
Starting and Stopping Services: SystemStarter The only mechanism for starting and stopping services that has been included with Mac OS X since its inception is SystemStarter. This mechanism is being phased out, but is still persists in the Tiger release. In this section, we will look at some of the important files associated with SystemStarter and how to use it. Understanding /etc/hostconfig As mentioned earlier, /etc/hostconfig is an important configuration file for a Mac OS X machine. It configures variables that are primarily used by services that start via SystemStarter. The values in the /etc/hostconfig come partly from settings in the System Preferences panes and partly from manual modification (even though the file says that it should be touched only by the controls). The /etc/hostconfig on your machine should look similar to Listing 16.6. Listing 16.6. A Typical /etc/hostconfig File 1 AFPSERVER=-NO- 2 AUTHSERVER=-NO- 3 AUTOMOUNT=-NO- 4 CUPS=-AUTOMATIC- 5 NFSLOCKS=-YES- 6 NISDOMAIN=-NO- 7 TIMESYNC=-YES- 8 QTSSERVER=-NO- 9 WEBSERVER=-NO- 10 SMBSERVER=-NO- 11 SNMPSERVER=-NO- 12 SPOTLIGHT=-YES- 13 ARDAGENT=-YES- 14 CRASHREPORTER=-YES-
Briefly, the lines in this listing specify the following information: Line 1 indicates that the machine isn't providing AppleShare Filing Protocol services, which are necessary for serving files via AppleShare. Line 2 specifies that the machine isn't providing authentication services. Line 3 controls whether the NFS Automounter will run. If you're not using NFS, it seems to make no difference. We aren't fans of NFS automounting for normal Unix installations and aren't sure what to think of it on Mac OS X. You learn more about NFS in Chapter 20. Line 4 controls whether the machine has printing services running. Line 5 controls whether or not NFS locking support is available for the machine, but when it functions as an NFS client and as an NFS server. Line 6 specifies which, if any, NIS domain the machine belongs to. NIS is the traditional Unix way of distributing user ID and password information to multiple machines in a cluster. If you have an existing Unix installation, you can subscribe your Mac OS X machine to the Unix machine's account information. Line 7 determines whether the machine should use a remote time server to synchronize its clock. Line 8 specifies whether the machine functions as a QuickTime streaming server. This technology is detailed in Chapter 25, "Darwin Streaming Server and QuickTime Broadcaster." Line 9 controls whether the machine functions as a web (HTTPD) server. How to enable and configure your machine as a high-powered web server is covered in Chapter 23, "Creating a Web Server." Line 10 configures whether the machine can serve files to Windows machines. How to enable and configure your machine to serve a Windows network is covered in Chapter 27, "Working with Windows-Based Systems." Line 11 configures whether the machine runs SNMP (Simple Network Management Protocol). This protocol is used to manage network devices, such as routers. Line 12 sets whether the machine has Spotlight, the new searching technology, running. Details on Spotlight can be found in Chapter 1, "Managing the Tiger Workspace." Line 13 configures whether the machine functions as an Apple Remote Desktop client. Chapter 21, "Accessing and Controlling Tiger Remotely," has more details on Apple Remote Desktop. Line 14 determines whether the machine reports crashes.
NOTE We've abbreviated the language in the preceding list a bit. The first few entries are worded correctly the file literally sets the values of variables, and these variables are used elsewhere to configure the properties of the system described. Later items that state that the line controls something should be read to mean that it sets a variable that is used by a program elsewhere to control the item. |
Understanding Files in /System/Library/StartupItems Many of the variables configured in /etc/hostconfig are used by files in /System/Library/StartupItems. Services that need to be continuously present, such as the software that configures and maintains network connections, are started from startup scripts. These startup scripts are kept in subdirectories of the /System/Library/StartupItems directory and are simply shell scripts (such as you learned about in Chapter 15, "Shell Configuration and Programming (Shell Scripting)") that perform simple logic to make sure that everything is right with the system and start the appropriate software. NOTE Remember that, in Unix, if you can type it at the command line, you can write it into a shell script. Anything you find that you want to run whenever the system is running can simply be placed in a shell script and that script executed at system startup. |
As shipped, your Mac OS X machine should have a complement of items in the StartupItems folder similar to that shown in Table 16.6. Don't worry if your /System/Library/StartupItems/ doesn't contain exactly these items. Depending on what installation options you've chosen, and whether any additional software has been installed by the time you're reading this, your system might display some differences. Table 16.6. Typical Items in the /System/Library/StartupItems/ DirectoryApache | The web server. | AppServices | Assorted support services for the overall GUI interface. | AppleShare | AppleShare file sharing. | AuthServer | User authentication services. | CrashReporter | Reports system crashes to Apple, if desired. | Disks | Controls disk operations. | FibreChannel | Updates system settings for fibre channel controllers and targets. | IFCStart | Controls ifcstart, the daemon responsible for rebuilding file caches used by international components of the operating system. | IPServices | Controls some services related to TCP/IP networking. | Metadata | Starts the Spotlight service. | NFS | Controls use of and access to the NFS (Network File System) Unix file sharing protocol. | NIS | Starts NIS (Network Information Service). | NetworkTime | Interacts with the network time server. | PrintingServices | Starts the CUPS (Common Unix Printing System) printing service. | RemoteDesktopAgent | Starts the Apple Remote Desktop Client. | SNMP | Starts the SNMP (Simple Network Management Protocol) service. This protocol is used to manage network devices, such as routers. |
Each of these directories contains a number of items typically a file named after the name of the directory, a directory named Resources, and a file named StartupParameters.plist (which, oddly, isn't an XML file it uses the old NeXT-style plist format). The file named after the directory (and service) is the actual shell script that is run at system boot time. The Resources directory typically contains directories of "resource-like" information, such as files that contain language-replacement strings for language localization. The StartupParameters.plist contains a collection of variables and associated values that affect the operation of the service started. To add your own startup script, you need only the startup script itself and a StartupParameters.plist file. Listing 16.7 shows a simple StartupItems shell script this one starts the Apache web server. Listing 16.7. The Apache StartupItems Shell Script 1 #!/bin/sh 2 3 ## 4 # Apache HTTP Server 5 ## 6 7 . /etc/rc.common 8 9 StartService () 10 { 11 if [ "${WEBSERVER:=-NO-}" = "-YES-" ]; then 12 echo "Starting Apache web server" 13 if [ ! -e /etc/httpd/httpd.conf ] ; then 14 cp -p /etc/httpd/httpd.conf.default /etc/httpd/httpd.conf 15 fi 16 apachectl start 17 if [ "${WEBPERFCACHESERVER:=-NO-}" = "-YES-" ]; then 18 if [ -x /usr/sbin/webperfcachectl ]; then 19 echo "Starting web performance cache server" 20 /usr/sbin/webperfcachectl start 21 fi 22 fi 23 fi 24 } 25 26 StopService () 27 { 28 if [ -x /usr/sbin/webperfcachectl ]; then 29 echo "Stopping web performance cache server" 30 /usr/sbin/webperfcachectl stop 31 fi 32 echo "Stopping Apache web server" 33 apachectl stop 34 } 35 36 RestartService () 37 { 38 if [ "${WEBSERVER:=-NO-}" = "-YES-" ]; then 39 echo "Restarting Apache web server" 40 apachectl restart 41 if [ "${WEBPERFCACHESERVER:=-NO-}" = "-YES-" ]; then 42 if [ -x /usr/sbin/webperfcachectl ]; then 43 echo "Restarting web performance cache server" 44 /usr/sbin/webperfcachectl restart 45 fi 46 fi 47 else 48 StopService 49 fi 50 } 51 52 RunService "$1"
In this listing, items starting with the # sign are comments. The meaning of the lines in the script can be summarized in a simple manner: Line 7 sources the script /etc/rc.common, where many systemwide definitions are made. Line 9 starts the section for the StartService case. Line 11 checks for the value of the variable WEBSERVER, and determines whether the value is YES or NO. This value is actually extracted from the /etc/hostconfig file shown in Listing 16.3. If Line 11 finds a yes, line 12 sends a message to the console that says Starting Apache web server. Furthermore, line 13 checks for the nonexistence of /etc/httpd/httpd.conf. If it does not exist the default /etc/httpd/httpd.conf.default is copied to /etc/httpd/httpd.conf. Line 15: fi is if backwards, and it terminates the conditional expression started by the if on line 13. Line 16 executes the program apachectl with the argument start. apachectl is actually another shell script, specific to the Apache installation, which handles all the real work of starting the service. Line 17 checks for the value of the variable WEBPERFCACHESERVER, and determines whether the value is YES or NO. This value is actually extracted from the /etc/hostconfig file shown in Listing 16.3. Mac OS X server includes this variable in /etc/hostconfig. If Line 17 finds a yes, line 18 starts the process of looking for whether an executable called /usr/sbin/webperfcachectl exists. If Line 18 finds that the file exists, line 19 sends a message to the console that says Starting web performance cache server. Line 20 executes the program /usr/sbin/webperfcachectl with the argument start. webperfcachectl is included in Mac OS X Server. Line 21 terminates the conditional expression started by the if on line 19. Line 22 terminates the conditional expression started by the if on line 17. Line 23 terminates the conditional expression started by the if on line 11. Line 26 starts the section for the StopService case. Line 28 checks for the existence of an executable file called /usr/sbin/webperfcachectl. If line 28 finds a yes, then line 29 sends a message to the console that says Stopping the web performance cache server. Line 30 actually executes webperfcachectl stop to stop the web performance cache server. Line 31 terminates the conditional expression started by the if on line 28. Line 32 displays a message that says Stopping Apache web server. Line 33 actually executes apachectl stop to stop the Apache web server. Line 36 starts the section for the RestartService case. Line 38 checks for the value of the variable WEBSERVER, and determines whether the value is YES or NO. If Line 38 finds a yes, line 39 sends a message to the console that says Restarting Apache web server. Line 40 actually executes apachectl restart to restart the Apache web server. Line 41 checks for the value of the variable WEBPERFCACHESERVER, and determines whether the value is YES or NO. If line 41 finds a YES, line 42 starts the process of looking for whether an executable called /usr/sbin/webperfcachectl exists. If line 42 finds that the file exists, line 43 sends a message to the console that says Restarting web performance cache server. Line 44 executes /usr/sbin/webperfcachectl restart to restart the web performance cache server. Line 45 terminates the conditional expression started by the if on line 42. Line 46 terminates the conditional expression started by the if on line 41. If line 38 finds a NO, line 47 starts the else section for what to do instead. Line 48 goes to the StopService case. Line 49 terminates the conditional expression started by the if on line 38. Line 52 specifies that RunService execute the first command-line argument it receives. For this line to make more sense, it is helpful to look at the RunService section of /etc/rc.common, where you can see that the expected options are start, which executes StartService; stop, which executes StopService; and restart, which executes RestartService. If none of the expected arguments is given, it returns a response that the argument is an unknown argument. Listing 16.8 shows the RunService section of /etc/rc.common.
Listing 16.8. The RunService section of /etc/rc.common RunService () { case $1 in start ) StartService ;; stop ) StopService ;; restart) RestartService ;; * ) echo "$0: unknown argument: $1";; esac }
The StartupParameters.plist file for Apache is shown in Listing 16.9. The StartupParameters.plist file for Apache makes use of three of the types of available key types: Description, Provides and Uses. As you might guess, the Description is a brief description of the service. The Provides key lists what kind of service the service provides, and the Uses key lists any other services that this service may use. The services that it uses should start before it does, but they are not necessarily required for this service to start. For more information on the StartupParameters.plist file, see http://developer.apple.com/documentation/MacOSX/Conceptual/BPSystemStartup/Tasks/CreatingStartupItems.html. Listing 16.9. The StartupParameters.plist File for Apache 1 { 2 Description = "Apache web server"; 3 Provides = ("Web Server"); 4 Uses = ("Disks", "NFS"); 5 }
In Chapter 22, "Creating an FTP Server," it is mentioned that you could choose to run the new FTP server as a standalone FTP server by adding a startup script to your system. You will need to create a directory to store your startup script. We recommend something like /Library/StartupItems/ProFTPD/. As we have seen in this section, the startup script would have to be called ProFTPD for this example. Include a line in the script that starts the new FTP server. Also required is a StartupParameters.plist file. Recommended ownership for items in /Library/StartupItems/ is to have the items owned by root, in group admin. The startup script, ProFTPD, should be executable. Reboot the machine to test that the new FTP server does indeed start at startup. Here is a listing of our files: localhost:/Library/StartupItems joray$ ls -l total 16 -rwxr-xr-x 1 root admin 115 Feb 7 11:25 ProFTPD -rw-r--r-- 1 root admin 216 Feb 7 11:29 StartupParameters.plist
Listing 16.10 shows our sample startup script, and Listing 16.11 shows our sample StartupParameters.plist for the replacement FTP server. Listing 16.10. Sample /Library/StartupItems/ProFTPD/ProFTPD #!/bin/sh . /etc/rc.common ## # Start up ProFTPD ## ConsoleMessage "Starting ProFTPD" /usr/local/sbin/proftpd
Listing 16.11. Sample /Library/StartupItems/ProFTPD/StartupParameters.plist { Description = "ProFTPD"; Provides = ("proftpd"); Requires = ("Resolver"); OrderPreference = "None"; Messages = { start = "Starting ProFTPD"; stop = "Stopping ProFTPD"; }; }
Unfortunately, the Apache web server, like many of the services in /System/Library/StartupItems, does not have a Resources directory. The English language locale configuration for the CrashReporter StartupItems (CrashReporter/Resources/English.lproj/Localizable.strings) is shown in Listing 16.12. Listing 16.12. The English Language Locale Configuration for the CrashReporter StartupItems <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist SYSTEM "file://localhost/System/Library/DTDs/PropertyList.dtd"> <plist version="0.9"> <dict> <key>Starting crash reporter</key> <string>Starting crash reporter</string> </dict> </plist>
This XML file specifies a key, the expression Starting crash reporter, and a local (English) replacement string for that expression Starting crash reporter. If everything works as intended, whenever the program attempts to print the key value, the system instead outputs the replacement string value. Because this isn't quite obvious from the English example, Listing 16.13 shows the Italian.lproj version of the Localizable.strings file. Listing 16.13. Italian.lproj Version of the Localizable.strings File for the CrashReporter Service <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs /PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Starting crash reporter</key> <string>Avvio resoconto blocco sistema</string> </dict> </plist>
Here, it is more obvious that the localization file is requesting a search to find Starting crash reporter and replacing it with the Italian equivalent. Understanding SystemStarter SystemStarter is used for starting and stopping services whose controls are located in /System/Library/StartupItems or /Library/StartupItems. If you need to manually start, stop, or restart one of these services, the SystemStarter utility may be used. Basic syntax is SystemStarter <action> <service>
The action can be start, stop or restart, and the service is whatever is listed as the Provides variable in the StartupParameters.plist file. For example, dogbone:~ joray$ sudo SystemStarter restart "Web Server" Password: Restarting Apache web server /usr/sbin/apachectl restart: httpd restarted
restarts the Apache web service. If you have any trouble with SystemStarter, try sending the action you want to occur directly to the startup script with this basic syntax: <startup-script> <action>
For example, you can restart the Apache web service by running: dogbone:~ joray$ sudo /System/Library/StartupItems/Apache/Apache restart Password: Restarting Apache web server /usr/sbin/apachectl restart: httpd restarted
This latter syntax is common in certain flavors of Unix and can therefore be useful to you outside Mac OS X. Depending on the startup script, even the latter syntax might not work properly. In that case, try manually executing the appropriate command from the section of the appropriate portion of the script. For something that requires detailed configuration, you might have to properly configure the service before you get the desired results. Table 16.7 includes command documentation for SystemStarter. Table 16.7. Syntax and Selected Options for SystemStarterSystemStarter | Starts, stops and restarts system services. |
|---|
SystemStarter [-gvxdDqn] [<action> [<service>]] | The SystemStarter utility can be used to start, stop, and restart system services, which are described in /Library/StartupItems/ and /System/Library/StartupItems/ paths. | The optional <action> argument specifies which action SystemStarter performs on the startup items. | The optional <service> argument specifies which startup items to perform the action on. If no service is specified, all startup items are acted on; otherwise, only the item providing the service, any items it requires, or any items that depend on it will be acted on. | Actions | start | Starts all items, or starts the item that provides the specified <service> and all items providing services it requires. | stop | Stops all items, or stops the item that provides the specified <service> and all items that depend on it. | restart | Restarts all items, or restarts the item providing the specified <service>. | Options | -g | Graphical startup. | -x | Safe mode startup (runs only Apple-provided items). | -n | Doesn't actually perform action on items (no-run mode). |
Starting and Stopping Services: inetd and xinetd In traditional Unixes, inetd is the service that starts other services. The inetd service is typically available on any Unix system. Mac OS X 10.0 and 10.1 included inetd. However, some administrators choose to install xinetd, the extended Internet services daemon, as a replacement for inetd. Mac OS X 10.2 included both inetd and xinetd as equivalent peers. Starting with Mac OS X 10.3, inetd was not included, but xinetd ran in inetd-compatibility mode. In Mac OS X 10.4, xinetd is included, and can run in inetd-compatibility mode. Although the current release of Mac OS X does not use xinetd much, we still feel that a discussion of both types of configuration files is important. Understanding the basic format of those files will mostly be helpful in dealing with third-party applications that might prefer to run out of xinetd. The launchd documentation also includes some dire warnings regarding certain actions that services could take, which would break the launchd system, so xinetd might remain the only option for some network services. If you are thinking about replacing a default service that can be run out of xinetd rather than launchd, pick xinetd as the startup mechanism. If the service will have so much traffic that you feel it should be a constantly running service, run it out of /System/Library/StartupItems. In this section we will take a look the basic configuration files used for inetd and xinetd and how to start services through xinetd. Controlling inetd/xinetd Managed Processes As mentioned earlier, the inetd service, configured by the /etc/inetd.conf file, actually is a service that starts and controls other services. It's not practical to start an unlimited number of some types of network services and leave them running, right from startup. Depending on the use of your machine, some services might be needed in great numbers; for example, the ftpd FTP server processes, if you serve particularly interesting data and have many people connecting simultaneously. Others might be used hardly at all, such as the sprayd network diagnostic daemon. Or, on your system, the use pattern might be the opposite but regardless of the use, patterns are likely to vary over time. For many of these types of services, the system relieves you of the task of trying to provide the right number of these servers in some manual configuration process, by using the inetd daemon to configure and run them on an as-needed basis. NOTE If you want to learn much more about network services in general, you're invited to check out Que Publishing's Special Edition Using TCP/IP (ISBN 0-7897-1897-9), another book by John Ray. |
The inetd.conf file is the file that tells inetd which services it should start and how. Starting with Mac OS X 10.3, however, Apple no longer provides an inetd service, but the provided xinetd runs in inetd compatibility mode. The /etc/inetd.conf file can still be used, but instead it can configure xinetd. The default inetd.conf file as it comes from Apple is shown in Listing 16.14. The # symbol in front of each item indicates that the line is commented out and will not be run. Many of the services that run out of inetd/xinetd are security holes. Listing 16.14. A Typical /etc/inetd.conf File 1 # WARNING 2 # 3 # Mac OS 10.2 and forward uses xinetd instead of the traditional inetd. 4 # See xinetd.conf(5) if you need to add a service to run out of xinetd. 5 # Please use /sbin/service to interface over editing the shipped files 6 # in /etc/xinetd.d directly. For example: 7 # /sbin/service telnet start 8 # /sbin/service telnet stop 9 # /sbin/service --list 10 # 11 # Internet server configuration database 12 # 13 # @(#)inetd.conf 5.4 (Berkeley) 6/30/90 14 # 15 # Items with double hashes in front (##) are not yet implemented in the OS. 16 # 17 #finger stream tcp nowait nobody /usr/libexec/tcpd fingerd -s 18 #ftp stream tcp nowait root /usr/libexec/tcpd ftpd -l 19 #login stream tcp nowait root /usr/libexec/tcpd rlogind 20 #nntp stream tcp nowait usenet /usr/libexec/tcpd nntpd 21 #ntalk dgram udp wait root /usr/libexec/tcpd ntalkd 22 #shell stream tcp nowait root /usr/libexec/tcpd rshd 23 #telnet stream tcp nowait root /usr/libexec/tcpd telnetd 24 #uucpd stream tcp nowait root /usr/libexec/tcpd uucpd 25 #comsat dgram udp wait root /usr/libexec/tcpd comsat 26 #tftp dgram udp wait nobody /usr/libexec/tcpd tftpd /private/tftpboot 27 #bootps dgram udp wait root /usr/libexec/tcpd bootpd 28 ##pop3 stream tcp nowait root /usr/libexec/tcpd /usr/local/libexec/popper 29 ##imap4 stream tcp nowait root /usr/libexec/tcpd /usr/local/libexec/imapd 30 # 31 # "Small servers" -- used to be standard on, but we're more conservative 32 # about things due to Internet security concerns. Only turn on what you 33 # need. 34 # 35 #chargen stream tcp nowait root internal 36 #chargen dgram udp wait root internal 37 #daytime stream tcp nowait root internal 38 #daytime dgram udp wait root internal 39 #discard stream tcp nowait root internal 40 #discard dgram udp wait root internal 41 #echo stream tcp nowait root internal 42 #echo dgram udp wait root internal 43 #time stream tcp nowait root internal 44 #time dgram udp wait root internal 45 # 46 # Kerberos (version 5) authenticated services 47 # 48 ##eklogin stream tcp nowait root /usr/libexec/tcpd klogind -k -c -e 49 ##klogin stream tcp nowait root /usr/libexec/tcpd klogind -k -c 50 ##kshd stream tcp nowait root /usr/libexec/tcpd kshd -k -c -A 51 #krb5_prop stream tcp nowait root /usr/libexec/tcpd kpropd 52 # 53 # RPC based services (you MUST have portmapper running to use these) 54 # 55 ##rstatd/1-3 dgram rpc/udp wait root /usr/libexec/tcpd rpc.rstatd 56 ##rusersd/1-2 dgram rpc/udp wait root /usr/libexec/tcpd rpc.rusersd 57 ##walld/1 dgram rpc/udp wait root /usr/libexec/tcpd rpc.rwalld 58 ##pcnfsd/1-2 dgram rpc/udp wait root /usr/libexec/tcpd rpc.pcnfsd 59 ##rquotad/1 dgram rpc/udp wait root /usr/libexec/tcpd rpc.rquotad 60 ##sprayd/1 dgram rpc/udp wait root /usr/libexec/tcpd rpc.sprayd 61 # 62 # The following are not known to be useful, and should not be enabled unless 63 # you have a specific need for it and are aware of the possible implications. 64 # 65 #exec stream tcp nowait root /usr/libexec/tcpd rexecd 66 #auth stream tcp wait root /usr/libexec/identd identd -w -t120
Briefly, the intent of the services on each line is as follows: Lines 1 9 This section provides a comment that Mac OS X now uses xinetd by default and lists the syntax for using /sbin/service to enable and disable services through xinetd. Line 17 The fingerd daemon allows external users to finger a user ID and find out whether the ID exists; if it does, how recently, and on what terminals the ID has been logged in. Line 18 The ftpd daemon provides an FTP (file transfer protocol) server. Line 19 The login service provides service for the rlogin remote login terminal program. Don't turn this on. Line 20 The nntp service is a Usenet newsgroups server. If your machine is configured to receive news from other servers, you can point your newsreader to your local machine to read news. Line 21 The ntalk (new protocol talk) daemon provides for real-time chat services. If you're familiar with ICQ, iChat, or IRC, this service is somewhat similar. Line 22 Provides remote shell service another way to remotely access machines. This service is required to use certain remote services, such as remote tape archive storage. Because Apple hasn't provided all the software necessary to make full use of these services, we suggest that this be left off as well; it's almost as large a security risk as rlogin and telnet. Line 23 Provides the telnet daemon to allow remote telnet terminal connections. Don't turn this on. Line 24 The uucpd service implements the Unix-to-Unix Copy Protocol. This is an antiquated method for networking Unix machines that can't always be connected to the network. Essentially, it allows network traffic between two sites to be queued until both sites are available on the network and then exchanges the data. This service is of limited utility today and presents a significant security risk because it hasn't really been maintained since the days of 1200-baud modems. Line 25 The comsat daemon provides notification of incoming mail to mail-reader clients. Line 26 tftp is trivial file transfer protocol and is one of the methods of providing file service to completely diskless network clients. You won't need to enable this service unless you're providing network boot services for diskless Unix clients. Line 27 bootp is a way of transmitting network configuration information to clients. Chances are you'll use DHCP for this, if you have a need to do so, although it's possible that Mac OS X Server could use bootp for netboot clients. Line 28 pop3 is a POPmail (Post Office Protocol Mail) server. In the file, Apple indicates that this service is not yet available. Line 29 imap4 is an IMAP mail server. Again, this service is not available as of the 10.4 release. Lines 35 42 Provide a number of network and network-software diagnostic servers. Unless you are performing network diagnosis and specifically need these, leave them off. They do not cause any known security problems, but if you're not using them, they occupy resources needlessly. Lines 43 and 44 Provide the time service (some servers require both stream and datagram connectivity, and these must be defined on separate lines). If you want your machine to be a time server, these can be turned on. Lines 48 51 Start a number of Kerberos (security authentication) related servers, but most are unavailable from Apple as of the 10.4 release. The krb5_prop service (starting krpropd) is the server that propagates a master Kerberos server's database to slave servers. Line 55 The rstatd daemon allows systems to connect through the network and get machine status information. Line 56 The rusersd daemon allows systems to connect through the network and to find information about this system's users. This is generally considered to be a bad idea. Line 57 The walld daemon allows users to write to the screens of all users on the system. This facility is nice if you're root and need to tell your users that the machine is going to go down for maintenance. It's annoying if one of your users starts using it to incessantly ask anyone connected to the machine for help with trivial Unix problems. Line 58 The pcnfsd daemon provides service for a PC network filesystem product named pcnfs. Almost everybody uses samba instead nowadays. Line 59 The rquotad daemon provides disk quota information to remote machines so that they can enforce quotas that your machine specifies on disks that it is serving to them. Line 60 sprayd is another network diagnostic server. Simply put, it responds as rapidly as it can to packets placed on the network by some other machine's spray process, which places packets on the network as fast as it can. This one would be nice if Apple provided it in a later release because it can be useful for finding problem hardware in your network. Line 65 The rexecd daemon allows for the remote execution of parts of programs. Apple claims that it isn't known to be useful, but a programmer can make good use of this service to perform distributed processing tasks by sending parts of programs to many different machines. Of course, it is also a security risk. Line 66 Another service that Apple considers to be of no practical use. The identd daemon provides a method for a remote machine to verify the identity of a user causing a connection, inasmuch as any identity can be verified over the network. The service was created because it is easy for a user accessing, for example, a remote FTP site, to pretend to be a different user on your system and potentially cause trouble for the person he is pretending to be.
The service specification lines consist of a set of fields separated by tabs or spaces. The fields that must occur on each line are shown in the following list, with a brief description of the data that belongs in them. Service name (used to look up service port in NetInfo services map) Socket type (stream, dgram, raw, rdm, or seqpacket) Protocol (tcp or udp, rpc/tcp, or rpc/udp) Wait/nowait (for dgrams only all others get nowait; should the socket wait for additional connections) User (user to run the service as) Server program (actual path to binary on disk) Server program arguments (how the command line would look, if typed, including server name)
Listing 16.15 shows an inetd.conf file from a running machine, with a few useful network services enabled. Listing 16.15. An inetd.conf File from a Running Machine, with a Few Useful Network Services Enabled # # Internet server configuration database # # @(#)inetd.conf 5.4 (Berkeley) 6/30/90 # # Items with double hashes in front (##) are not yet implemented in the OS. # #finger stream tcp nowait nobody /usr/libexec/tcpd fingerd -s ftp stream tcp nowait root /usr/libexec/tcpd ftpd -l #login stream tcp nowait root /usr/libexec/tcpd rlogind #nntp stream tcp nowait usenet /usr/libexec/tcpd nntpd ntalk dgram udp wait root /usr/libexec/tcpd ntalkd #shell stream tcp nowait root /usr/libexec/tcpd rshd #telnet stream tcp nowait root /usr/libexec/tcpd telnetd #uucpd stream tcp nowait root /usr/libexec/tcpd uucpd comsat dgram udp wait root /usr/libexec/tcpd comsat #tftp dgram udp wait nobody /usr/libexec/tcpd tftpd /private/tftpboot #bootp dgram udp wait root /usr/libexec/tcpd bootpd ##pop3 stream tcp nowait root /usr/libexec/tcpd /usr/local/libexec/popper ##imap4 stream tcp nowait root /usr/libexec/tcpd /usr/local/libexec/imapd
Because this machine doesn't provide many network services to the outside world, the majority of the services are turned off. Only the ftpd (ftp server), ntalkd (talk daemon, provides chatlike services), and comsat (provides new mail notification service) are turned on. To turn on additional services, simply uncomment (remove the # sign) the line and restart xinetd: kill -HUP <xinetd_pid> killall -HUP xinetd
We strongly recommend that you leave your telnet daemon and rlogin daemon disabled because these are both significant security risks. You're already familiar with the ssh (Secure Shell) programs for connecting to remote machines. Chapter 21, "Accessing and Controlling Tiger Remotely," covers configuring the sshd daemon on your own machine, and this service provides a secure replacement for the functionality of the telnet and shell daemons. For any services that currently start via launchd, see the section on launchd for some additional advice on starting xinetd if it is not already running. Notice that according to the file format definition given earlier, the program started by many of the lines is exactly the same: /usr/libexec/tcpd. This is part of a security mechanism, whereby xinetd doesn't start the actual service, but instead starts yet another service, which starts the desired final service. The intermediate service, the program /usr/libexec/tcpd, is the TCP Wrappers program. This program can be configured to intercept requests for network services and allow them to continue only if the request comes from an authorized remote host. TCP Wrappers lives as an intermediate service between the xinetd service and the end services that it delivers because the xinetd-to-end-service method of providing network services was well established before the magnitude of potential Internet security problems was discovered. It turned out to be easier to sneak a wrapper around the end service, and not worry about modifying the model or about having to add security-conscious code to each and every possible service. Chapter 28, "Implementing Server Security and Advanced Network Configuration," covers how to configure TCP Wrappers to increase your system security. Table 16.8 shows select runtime options available for xinetd. In Mac OS X, it runs by default with the -inetd_compat and -pidfile options: xinetd -inetd_compat -pidfile /var/run/xinetd.pid. The -inetd_compat option is an especially interesting option. With this option enabled, xinetd can also read the /etc/inetd.conf file. It processes /etc/xinetd.conf first and then /etc/inetd.conf. For users who prefer the /etc/inetd.conf file, this is a way to use a familiar file without any extra work. Table 16.8. Select Runtime Options for xinetdOption | Description |
|---|
-d | Enables debug mode. | -syslog <syslog_facility> | Enables syslog logging of xinetd-produced messages using the specified syslog facility. The following syslog facilities can be used: daemon, auth, user, local[0-7]. Ineffective in debug mode. | -filelog <log_file> | Specifies where to log xinetd-produced messages. Ineffective in debug mode. | -f <config_file> | Specifies which file to use as the config file. Default is /etc/xinetd.conf. | -pidfile <pid_file> | Writes the process ID to the file specified. Ineffective in debug mode. | -stayalive | Tells xinetd to stay running even if no services are specified. | -inetd_compat | Causes xinetd to read /etc/inetd.conf in addition to the standard xinetd config files. /etc/inetd.conf is read after the standard xinetd config files. |
The default /etc/xinetd.conf file that comes with Mac OS X 10.4 is shown again in Listing 16.16. Listing 16.16. The default /etc/xinetd.conf File 1 # man xinetd.conf for more information 2 3 defaults 4 { 5 instances = 60 6 log_type = SYSLOG daemon 7 log_on_success = HOST PID 8 log_on_failure = HOST 9 cps = 25 30 10 } 11 12 includedir /etc/xinetd.d
The /etc/xinetd.conf file looks different from the /etc/inetd.conf file. This file has two major sections: a defaults section and a services section. The defaults section has controls that are basic defaults for the services. Each service has further controls and can also override or augment controls listed in the defaults section. Briefly, the intent of the lines of this file is as follows: Line 3 labels the defaults section of the file. Line 4 starts the configuration for the defaults section of the file. Line 5 sets the first defaults attribute, instances, which specifies the limit of servers for a given service, to 60. Line 6 sets the log_type attribute to the SYSLOG facility at the daemon level. Line 7 sets the log_on_success attribute to HOST, which logs the remote host's IP address, and PID, the process ID of the server. Line 8 sets the log_on_failure attribute to HOST, which logs the remote host's IP address. Line 9 sets the cps attribute, the one that limits the connections per second, to 25 connections per second. When this limit is reached, the service disables itself for the number of seconds specified in the second argument, 30 seconds in this case. Line 10 ends the defaults configuration section. Line 12 starts the services section by using the includedir directive to specify that every file in the /etc/xinetd.d directory, excluding files containing . or ~, is parsed as an xinetd configuration file. The files are parsed in alphabetical order according to the C locale.
Already you can tell that xinetd has more functionality than the traditional inetd. For instance, inetd cannot limit the number of connections per second. The items listed in this default /etc/xinetd.conf file are not the only ones that can be listed in this section, nor are the default values necessarily the only possible values. Table 16.9 shows a listing of select attributes for xinetd. Notice that xinetd can be set to restrict access based on hosts and even time, redirect services, and display banners. Table 16.9. Select Attributes for xinetdAttribute | Description |
|---|
id | Used to uniquely identify a service. Useful for services that can use different protocols and need to be described with different entries in the configuration file. Default service ID is the same as the service name. | type | Any combination of the following can be used: RPC: Specifies service as an RPC service. INTERNAL: Specifies service as provided by xinetd. TCPMUX/TCPMUXPLUS: Specifies a service that is started according to the RFC 1078 protocol on the TCPMUX well-known port. UNLISTED : Specifies that the service is not listed in a standard system file, such as /etc/services or /etc/rpc. | flags | Any combination of the following can be used: INTERCEPT: Intercepts packets or accepted connections to verify that they are coming from acceptable locations. Internal or multithreaded services cannot be intercepted. NORETRY: Avoids retry attempts in case of fork failure. IDONLY: Accepts connections only when the remote end identifies the remote user. Applies only to connection-based services. NAMEINARGS: Causes the first argument to server_args to be the name of the server. Useful for using TCP Wrappers. NODELAY: For a TCP service, sets the TCP_NODELAY flag on the socket. Has no effect on other types of services. DISABLE: Specifies that this service is to be disabled. Overrides the enabled directive in defaults. KEEPALIVE: For a TCP service, sets the SO_KEEPALIVE flag on the socket. Has no effect on other types of services. NOLIBWRAP: Disables internal calling of the tcpwrap library to determine access to the service. SENSOR: Replaces the service with a sensor that detects accesses to the specified port. Does not detect stealth scans. Should be used only on services you know you don't need. Whenever a connection is made to the service's port, adds the IP address to a global no_access list until the deny_time setting expires. IPv4: Sets the service to an IPv4 service. IPv6: Sets the service to an IPv6 service. REUSE : The REUSE flag is deprecated. All services now implicitly use the REUSE flag. | disable | Has a value of yes or no. Overrides the enabled directive in defaults. | socket_type | Has a value of stream, dgram, raw, or seqpacket. | protocol | Specifies the protocol used by the service. Protocol must exist in /etc/protocols. If it is not defined, the default protocol for the service is used. | wait | Specifies whether the service is single-threaded or multithreaded. If yes, it is single-threaded; xinetd starts the service and stops handling requests for the service until the server dies. If no, it is multithreaded; xinetd keeps handling new service requests. | user | Specifies the UID for the server process. Username must exist in /etc/passwd. | group | Specifies the GID for the server process. Group must exist in /etc/group. If a group is not specified, the group of the user is used. | instances | Determines the number of simultaneous instances of the server. Default is unlimited. The value can be an integer or UNLIMITED. | nice | Specifies server priority. | server | Specifies the program to execute for this service. | server_args | Specifies arguments to be passed to the server. Server name should not be included, unless the NAMEINARGS flag has been specified. | only_from | Specifies to which remote hosts the service is available. | no_access | Specifies the remote hosts to which this service is not available. | access_times | Specifies time intervals when the service is available. An interval has the form: hour:min-hour:min. Hours can range from 0 23; minutes can range from 0 59. | log_on_success | Specifies what information is logged when the server is started and exits. Any combination of the following can be specified: PID: Logs the server process ID. HOST: Logs the remote host's address. USERID: Logs remote user ID using RFC 1413 identification protocol. Available for multithreaded stream services only. EXIT: Logs the fact that the server exited along with the exit status or termination signal. DURATION: Logs the duration of the server session. trAFFIC : Logs the total bytes in and out for a redirected service. | log_on_failure | Specifies what is logged when a server cannot start, either from lack of resources or access configuration. Any combination of the following can be specified: HOST: Logs the remote host's address USERID: Logs remote user ID using RFC 1413 identification protocol. Available for multithreaded stream services only. RECORD: Logs as much information about the remote host as possible. ATTEMPT : Logs the fact that a failed attempt was made. Implied by use of any of the other options. | env | Value of this attribute is a list of strings of the form <name>=<value>. These strings are added to the server's environment, giving it xinetd's environment as well as the environment specified by the env attribute. | passenv | Value of this attribute is a list of environment variables from xinetd's environment to be passed to the server. An empty list implies passing no variables to the server except those explicitly defined by the env attribute. | port | Specifies the service port. If this attribute is listed for a service in /etc/services, it must be the same as the port number listed in that file. | redirect | Allows a TCP service to be redirected to another host. Useful for when your internal machines are not visible to the outside world. Syntax is redirect = <IP address or host name> <port> The server attribute is not required when this attribute is specified. If the server attribute is specified, this attribute takes priority. | bind | Allows a service to be bound to a specific interface on the machine. | interface | Synonym for bind. | banner | Name of the file to be displayed to the remote host when a connection to that service is made. The banner is displayed regardless of access control. | banner_success | Name of the file to be displayed to the remote host when a connection to that service is granted. Banner is displayed as soon as access to the service is granted. | banner_fail | Name of the file to be displayed to the remote host when a connection to a service is denied. Banner is printed immediately on denial of access. | per_source | Specifies the maximum number of connections permitted per server per source IP address. May be an integer or UNLIMITED. | cps | Limits the rate of incoming connections. | groups | Takes either yes or no. If yes, the server is executed with access to the groups to which the server's effective UID has access. If no, server runs with no supplementary groups. Must be set to yes for many BSD-flavored Unixes. | enabled | Takes a list of service names to enable. Note that the service disable attribute and DISABLE flag can prevent a service from being enabled despite its being listed in this attribute. | include | Takes a filename in the form of include /etc/xinetd/service. File is then parsed as a new configuration file. May not be specified from within a service declaration. | includedir | Takes a directory name in the form of includedir /etc/xinetd.d. Every file in the directory, excluding files containing . or ending with ~, is parsed as an xinetd.conf file. | rlimit_cpu | Sets the maximum number of CPU seconds that the service may use. May either be a positive integer or UNLIMITED. | deny_time | Sets the time span when access to all services to an IP address are denied to someone who sets off the SENSOR. Must be used in conjunction with the SENSOR flag. Options are FOREVER: IP address is not purged until xinetd is restarted. NEVER: Just logs the offending IP address. <number> : A numerical value of time in minutes. A typical time would be 60 minutes, to stop most DoS attacks while allowing IP addresses coming from a pool to be recycled for legitimate purposes. |
Mac OS X no longer has any default configuration files in /etc/xinetd.d. Traditionally, services that require two lines in /etc/inetd.conf, such as time, require two files in /etc/xinetd.d. Now that Apple has gone to using launchd as a replacement for inetd/xinetd, we do not see this phenomenon. In Chapter 22, we mention that one of the options you can use to replace the default FTP server is to have the new one start via the xinetd service. Mac OS X no longer comes with a default /etc/xinetd.d/ftp file, but we have included a basic one that you could use, shown in Listing 16.17. Listing 16.17. A Sample /etc/xinetd.d/ftp 1 service ftp 2 { 3 disable = no 4 socket_type = stream 5 wait = no 6 user = root 7 server = /usr/local/sbin/proftpd 8 groups = yes 9 flags = REUSE 10 }
Let's take a brief look at this sample /etc/xinetd.d/ftp file: The third line sets the first attribute, disable, to no. This enables the FTP service. In the /etc/inetd.conf file, this is equivalent to uncommenting the ftp line. The fourth line sets the socket_type attribute to stream. This was the second item in the ftp line of /etc/inetd.conf. The fifth line sets the wait attribute to no. This was the third item in the ftp line of /etc/inetd.conf. The sixth line sets the user attribute to root. This was the fourth item in the ftp line of /etc/inetd.conf. The seventh line sets the server attribute to /usr/local/sbin/proftpd. This was the fifth item in the ftp line of /etc/inetd.conf. In the default /etc/inetd.conf file, the default ftpd starts with the -l argument. If we wanted to include an argument for the replacement FTP server, we would use the server_args attribute, set to whatever arguments we wanted. For the default ftpd, we would assign -l to the attribute. The eighth line sets the groups attribute to yes. This is required for BSD-flavored Unixes. Because this attribute is required for all your xinetd services, you could also move it to the defaults section of /etc/xinetd.conf and then remove it from the individual service files. Finally, the ninth line sets the flags attribute to REUSE, which according to the man page is actually deprecated because all services use this flag.
Perhaps one of the most notable differences between the default /etc/inetd.conf file and this /etc/xinetd.d/ftp file is that the server is set to /usr/libexec/tcpd in the inetd.conf file, but in the ftp file, it is set to the new FTP server's binary, /usr/local/sbin/proftpd. Because inetd is not as configurable, it is important to use TCP Wrappers. However, you can configure host access information directly in xinetd without having to use TCP Wrappers. We recommend that you use that built-in capability. If you want to enable any of the default services controlled by xinetd or enable a service that you are adding, using only the xinetd configuration files, run /sbin/service <service> start. To start any service that otherwise runs out of launchd using xinetd instead, see some additional details in the launchd section before running the command. If you prefer a more manual method, change the disable enTRy to no and restart xinetd by sending it a HUP signal using either of the following methods: kill -HUP <xinetd_pid> killall -HUP xinetd
If you are running a service using /etc/inetd.conf rather than /etc/xinetd.d/, start xinetd, after looking at comments in the launchd section. The /sbin/service command already takes care of this for services running out of xinetd. If you want to change any of the configuration files in /etc/xinetd.d/, simply restart xinetd to have the changes take effect. Restarting and Shutting Down: shutdown, reboot, halt After you have played quite a bit with starting and stopping services, you can sometimes have your machine so confused about your services that it is necessary to reboot. To do so from the command line, you can use the shutdown command. It is a convenient command to use to shut down the machine or to reboot, especially when users are on the system. The shutdown command notifies users that the system is about to go down and gives them the opportunity to save what they are doing. Additionally, it does not allow logins five minutes before shutdown, or immediately, if the impending shutdown is in less than five minutes. The two most common uses of shutdown are shutdown -r <time> shutdown -h <time>
The -r option reboots the machine, and -h option halts the machine. The specified <time> can be now or in minutes or a specific date. Table 16.10 shows the command documentation for shutdown. Table 16.10. Command Documentation for shutdownshutdown | Closes down the system at a given time. | shutdown [-] [-h|-r|-k] [-o [-n]] <time> [<warning_message>] | shutdown provides an automatic way for the superuser to nicely notify users of an impending shutdown. | -h | Halts the system at the specified <time>. | -r | Reboots the system at the specified <time>. | -k | Kicks everybody off. The -k option does not actually halt the system, but does leave the system multiuser with logins disabled for all users except the superuser. | -o | If one of the -h, -p, or -r is specified, shutdown executes halt or reboot instead of sending signal to init. | -n | Prevents normal sync before stopping. | <time> | The time when the system is to be brought down. <time> can be the word now for immediate shutdown, or a future time in one of two formats: <+number> or <yymmddhhmm>, where the year, month, and day may be defaulted to the current system values. The first form brings the system down in <number> minutes and the second at the absolute time specified. | <warning_message> | Any other arguments comprise the warning message that is broadcast to users currently logged on the system. | - | Reads the warning message from standard input. |
In addition to shutdown, halt and reboot can also be used to halt or reboot the system, as appropriate. The shutdown command is more polite for the users and is therefore the recommended command to use. However, if you do end up using halt or reboot, they are traditionally invoked in combination with sync, as follows: sync;sync;sync;reboot sync;sync;sync;halt
The sync command forces the completion of disk writes. halt, reboot, and shutdown also do this before closing down the machine. However, the wisdom of defying tradition is left to you. Table 16.11 shows command documentation for halt and reboot. Table 16.11. Command Documentation for halt and reboothalt | Stops the system. | reboot | Restarts the system. | halt [-lnq] | reboot [-lnq] | The halt and reboot utilities flush the system cache to disk, send all running processes a SIGTERM and subsequently a SIGKILL and, respectively, halts or restarts the system. The action is logged, including adding a shutdown record into the login accounting file. | -l | Does not log the halt or reboot to the system log. Intended for applications, such as shutdown, that call reboot or halt and log this themselves. | -n | Does not flush the file system cache. This option probably should not be used. | -q | Quickly and ungracefully halts/restarts the system, and only flushes the file system cache. This option probably should not be used. | Normally, shutdown is used when the system needs to be halted or restarted to warn users of their impending doom and to cleanly terminate specific programs. |
|
