9.7. Remote Server Management
Windows provides a large number of remote management applications. You've already seen two examples of these: Server Manager and User Manager for Domains. Other tools provide the capability to manage file shares, stop and start services, search logfiles, and monitor system resources. Supporting tools familiar to Windows administrators can help to distribute the burden of server administration without requiring you to retrain your staff. In the following sections, we show you to configure Samba to support these types of remote management applications.
9.7.1. File Shares
Figure 9-14 shows a listing of shares on our server using the Microsoft Management Console. Our goal is to be able to manipulate new and existing shares using this application. To do so, we need to meet two requirements:
Figure 9-14. Using the Computer Management MMC plug-in to view available Samba shares
Granting the SeDiskOperatorPrivilege right allows a user or group to manage Samba's file shares, including changing a share's security ACL. The net rpc rights command should be very familiar by now. We'll continue to use Server Admins as our primary administrative group and grant it the necessary privilege with the following command:
$ net rpc rights grant 'ORA\Server Admins' SeDiskOperatorPrivilege \ -S stork -U cindy Password: <enter cindy's password> Successfully granted rights.
Samba provides three parameters referring to external commands that modify smb.conf whenever a file share is added, modified, or removed. The add share command is used to create a new file share to smb.conf. When called by smbd, it is passed the following five parameters:
The change share command updates basic share properties and is invoked with the same set of parameters as the add share command.
The delete share command removes a file share from smb.conf. The parameter list consists solely of:
An example share management program is distributed with Samba in examples/scripts/shares/perl. The modify_share_command.pl script is intended to be an example of how the various smb.conf share commands work, but it can be used in production. However, because it strips comments and reorders the configuration file (similar to SWAT), it may not be suitable for all servers.
The following excerpt from smb.conf shows how to integrate these new options into an existing configuration. The script uses the number of defined parameters to determine whether it should add/update a share or remove one, which allows us to use one program for all three commands.
[global] add share command = /etc/samba/scripts/modify_share_command.pl change share command = /etc/samba/scripts/modify_share_command.pl delete share command = /etc/samba/scripts/modify_share_command.pl
We can now use the MMC Shared Folders plug-in to create a new share named [graphics]. Figure 9-15 shows the Create A Shared Folder Wizard, which can be launched from the Action New File Share . . . menu option. The shared directory path must be entered as a DOS path, but is converted to a Unix path by smbd before passing it off to the add or change share parameters.
Figure 9-15. Creating a new Samba share from Windows
The resulting share created by the add share command is shown here:
[graphics] max connections = 0 comment = Graphic Art for Publishing Department path = /data/data/graphics
Creating shares using MMC or other RPC-based management tool does not give you access to the full range of smb.conf parameters. The parameter most notably absent is valid users. However, you can customize the share's security descriptor to achieve the same effect. Share permissions, stored in share_info.tdb, are independent of the filesystem ACLs discussed in Chapter 6 and are thus available even on systems without that feature. Figure 9-16 shows the share permissions for [graphics]. Here the ORA\artists group has been given full access, while all other users are granted only read access to the share.
Figure 9-16. Share permissions for graphics
The Windows Service Control API can be used to manage Unix daemons via the System V init script interface. Figure 9-17 lists configured services on a Samba host.
Figure 9-17. Listing services on the Samba host \\SLES9
The registry service is not linked to any configuration setting and therefore is always present. But a few of these services are handled internally by smbd or nmbd because they are linked to specific smb.conf parameters:
Of these four internal services, only the Print Spooler will accept start or stop commands. Its main purpose is to support the Microsoft Print Migrator tool (http://www.microsoft.com/printserver).
You can include additional services using the svcctl list parameter. The smb.conf setting corresponding to the listing in Figure 9-17 is:
[global] svcctl list = syslog nfs sshd postfix cron autofs \ centeris.com-agent apache2 cups centeris.com-evtlogd \ centeris.com-perfd centeris.com-evtweblogd
The svcctl list directive specifies the services that should be listed by the Windows Service Control Manager. To actually stop and start a service, you must add a SysV init script using the name listed in smb.conf to the svcctl folder of Samba's lib directory (e.g., /usr/local/samba/lib/svcctl). In most cases, adding a symbolic link to the operating system's init script in /etc/init.d is sufficient. This file listing shows symlinks for apache2, autofs, cron, nfs, postfix, sshd, and syslog:
$ ls -l total 8 drwxr-xr-x 2 root root 4096 Aug 10 23:35 . drwxr-xr-x 9 root root 4096 Aug 10 23:35 .. lrwxrwxrwx 1 root root 19 Jul 14 15:49 apache2 -> /etc/init.d/apache2 lrwxrwxrwx 1 root root 18 Jul 14 15:49 autofs -> /etc/init.d/autofs lrwxrwxrwx 1 root root 16 Jul 14 15:49 cron -> /etc/init.d/cron lrwxrwxrwx 1 root root 15 Jul 14 15:49 nfs -> /etc/init.d/nfs lrwxrwxrwx 1 root root 19 Jul 14 15:49 postfix -> /etc/init.d/postfix lrwxrwxrwx 1 root root 16 Jul 14 15:49 sshd -> /etc/init.d/sshd lrwxrwxrwx 1 root root 18 Jul 14 15:49 syslog -> /etc/init.d/syslog <...remaining output deleted...>
Samba expects the init script to support three command line options: start, stop, and status. For all three commands, smbd assumes that a nonzero return code indicates an error and that the service is not running. If your OS does not provide initialization scripts for service startup and shutdown, or does not obey Samba's assumptions, it will be necessary to write your own.
Each service has an assigned security descriptor, just like files or printers, which can be set to allow a specific user or group the right to stop and restart a service. By default, only members of the local Administrators group (S-1-5-32-544) are authorized to manage services. At least initially, it is necessary to create a group mapping entry for this SID. You could, however, change a service's ACL to allow members of the Web Admins group to restart Apache and restrict the Mail Admins group to managing Postfix. Sadly, Microsoft does not provide a graphical interface to manage service access lists. However, it is possible to use sc.exe utility shipped with Windows XP to set the ACL using its Security Descriptor Definition Language (SDDL). For more information on sc.exe, access the tool's help screen using the /? switch or search http://technet.microsoft.com.
Figure 9-18 shows service management in action as the Postfix Mail Server is launched by selecting Start from the context menu provided by a right click on the service name.
Figure 9-18. Starting Postfix from MMC
Table 9-6 summarizes the svcctl list option present in this section.
The Windows Event Viewer is limited, compared to many logging tools. It is, however, familiar to Windows admins and is distributed as part of the operating system. For this reason alone, it is worth investigating, as it allows existing EventLog API-based monitoring tools to audit both Unix hosts and their Windows counterparts.
The first step when enabling this feature is to configure the list of EventLogs that should be reported to Windows clients by defining the eventlog list global parameter in smb.conf. The following setting enumerates five logfiles: Application, System, Security, SyslogLinux, and WebServer:
eventlog list = Application, System, Security, SyslogLinux, Webserver
Samba does not parse system logfiles directly. Instead, it reads log records from an associated tdb stored in the eventlog folder of its lock directory (e.g., /var/lib/samba/eventlog). These tdb files are created by using an external tool to parse the system logfiles and then writing entries to the database using the eventlogadm tool. An example Perl script which is able to parse syslog-generated logfiles is included in the examples/scripts/eventlog directory of the Samba source distribution. To generate the Security EventLog tdb, pipe /var/log/secure through the parselog.pl script and then feed the output to the eventlogadm tool, giving the EventLog name as the single command-line argument:
# tail -f /var/log/secure | parselog.pl | eventlogadm Security
This command continuously feeds log messages into security.tdb, which is accessed by smbd to generate the log entries shown in Figure 9-19. Here you can see the successful SSH login by root from host 192.168.56.1.
Figure 9-19. Viewing a Unix host's /var/log/secure file in the Windows Event Viewer
Table 9-7 provides a short description of the eventlog list setting.
9.7.4. Performance Monitor
Our final management application falls more into the remote monitoring category. The Performance Monitor (perfmon.exe) utilizes the Windows registry interface to periodically poll a server for performance data such as CPU usage, disk utilization, and available memory. Similar to its relationship with EventLogs, Samba acts as a interface to performance data that has been collected by an external tool or daemon.
There are many ways to collect performance data. On Linux hosts, a great deal of information can be collected by reading files stored in /proc. An implementation based on this method is distributed in the examples/perfcounter directory of the Samba source tree. Build instructions and a simple Makefile are included as well. Once the daemon has been compiled, it can be launched to generate an example set of performance counters stored in the perfmon folder of Samba's lock directory (/var/lib/samba/perfmon). To launch the program as a daemon, run the following command as root:
# ./perfcount -d
This command creates two tdb files: names.tdb and data.tdb. Samba uses these files to service any requests to read from the HKEY_PERFORMANCE_DATA registry hive. Figure 9-20 displays a perfmon.exe session that is monitoring the System and User CPU usage on a Unix host during a software compile. It is interesting to compare the Performance Monitor data with the output from vmstat during the same period. You will find that the graph closely matches vmstat's CPU usage report:
Figure 9-20. Viewing System versus User CPU usage in the Windows perfmon.exe tool
$ vmstat 5 procs ----cpu---- r b <...> us sy id wa 1 0 <...> 2 4 93 2 1 0 <...> 11 89 0 0 1 0 <...> 10 89 0 0 1 0 <...> 10 90 0 0 1 0 <...> 11 89 0 0 1 0 <...> 11 88 1 1 0 1 <...> 12 87 0 1 1 0 <...> 11 58 21 10 0 1 <...> 3 16 80 1 1 0 <...> 13 80 0 6 1 0 <...> 14 86 0 0
Samba developers continue to support new remote management interfaces and improve existing ones. For the latest information on features related these and other tools, review the WHATSNEW.txt file included with the latest Samba release.