New Samba Features Improve Interoperability

Last week was maintenance week here in the labs, and one of the top items on my to-do list was upgrading Samba to the latest release. Recent changes to the network topology brought on some thorny inter-domain trust and cross-subnet browsing problems that needed ironing out, and "upgrade to the latest release" is practically an industry-wide prerequisite for getting any further assistance. So I did my duty and upgraded from 3.0.2 to 3.0.23C as a first effort.

As far as version increments go, that's a pretty small jump, and folks might assume that the differences between the releases probably only amount to a handful of modest bug fixes. But not in this case--there are several hundred bug fixes in the latest package (including some I needed), as well as some significant new functionality. All of this cumulatively makes Samba much more useful and usable on heterogeneous networks.

For starters, there are some significant improvements to the core Samba service, such as new support for BUILTIN/Users and BUILTIN/Administrators groups that make Samba more closely mimic traditional Windows security models. Samba also now has a gateway service that makes UNIX daemons appear as Windows services, thereby allowing administrators to use Windows management tools to start and stop UNIX services as needed. Another compelling feature in the current Samba release is the ability to map UNIX log files into Windows-style event logs, thereby allowing administrators to use Windows management tools to monitor systems and critical services from afar more easily.

What's most interesting about those latter two features in particular is that neither of them have much to do with traditional file-and-print services, which has long been Samba's bailiwick. Instead, they seek to make Samba look and feel more like a full-fledged member of the network by elevating less-critical but still-important secondary services. And for the most part, it works. However, much of this code seems to be in development and getting some of this stuff to work can be a bit challenging. But having said that, these are important and worthwhile advances, and folks should check them out.

Service Control

One of the more interesting new features in the newer Samba releases is the ability to map UNIX services into the Windows service model. In this setup, Samba uses UNIX "init" scripts to start, stop, and probe UNIX services, and then reports the status of those services back to Windows management stations via the Windows networking Service Control API. Once this is properly configured, you can manipulate UNIX services just like you can manipulate services running on Windows systems, and you can do so by using the same tools.

This is illustrated in the screenshot below, which shows a handful of UNIX services running on a Samba server, as seen from the Services applet provided with Windows XP.

Getting this setup is a multi-step process that is fairly straightforward, although long-winded.

First, you need to decide which UNIX services you want to make available. The only real requirement here is that the service must be controllable via an init script of some kind (on Linux systems these scripts are usually located in the /etc/init.d/ directory, but the Samba model also allows for private scripts).

Each service that you want to publish has to be listed in the "svcctl list" entry in the Global section of your smb.conf file. In my case, I have an entry that reads as follows:

When Samba is restarted, it will look for init scripts that match each of the listed items. However, Samba does not use the /etc/init.d/ directory for this purpose, but instead uses the /usr/lib/Samba/svcctl directory (or your system-specific equivalent). Therefore, you will probably want to create symbolic links from the original init scripts to that directory (see screenshot below), or you can also create whole new scripts and services in the Samba-specific directory too if you want.

Once the scripts are listed insmb.conf, the links are in place, and when Samba is restarted, administrators can connect to the server and manipulate the daemons using (almost) any of the Windows management tools they already have.

This works pretty well for letting you keep an eye on critical UNIX services, although there are a couple of rough spots in the behavior. For one, the service names and descriptions are not always accurate or complete, although this can be corrected by pointing regedit to the Samba server and modifying the entry names that way (these details are stored separately from the smb.conf boot data). Furthermore, the state of a service may not always be accurately reflected--as can be seen in the first screen shot, above, at top the "Status" field for the Apache2 service is null and empty, when the service has actually just been stopped.

Overall, the setup is more complicated than it needs to be too, and is somewhat prone to error. But it definitely works, and it's remarkably simple to use once it's configured and working, and this is especially true for network managers who work with Windows servers more than UNIX servers. The logfile mapping feature is also very tight and useful, and just as difficult to configure. In this model, Samba stores event log data in local databases, and then publishes that data via normal network interfaces, which Windows management tools can then access. This lets administrators view the UNIX system and application logs with the same tools that they use to monitor their Windows servers.

The screenshot below shows what this looks like, using the Event Viewer applet to examine a handful of log files from a local Samba server.

As with the service control feature, the first step is to determine which log sources you want to make available, and then itemize those sources in an "eventlog list" entry in the Global section of smb.conf. The entry I used for the example above is shown below:

Each of the named event logs refers to a specific eventlog database. Each of the eventlog databases stores data in the Windows eventlog format, and does not use the typical line-oriented logging found on UNIX, so some kind of conversion is usually required on the back end. Unfortunately, getting the data into the final binary form can be fairly complicated.

For one thing, you need to generate the binary data that Windows systems expect to see. The Samba package includes a utility called eventlogadm that can be used for this purpose, but that utility expects to get pre-formatted, multi-line ASCII log data that it will convert to binary form. You can generate this data yourself if needed, but there is also a parselog.pl Perl script available that can be used to convert rudimentary UNIX log files to the necessary multi-line format. Essentially this means that you can perform a two-stage conversion on existing syslog output--first by piping the data through parselog.pl, and then piping its output through eventlogadm--to ultimately get the data into a binary database suitable for use by Windows.

For example, the following command continuously reads "/var/log/dhcpd" and produces binary eventlog data that is readable by the Windows Event Viewer applet:

As with the Service Control feature, there are some rough spots here, apart from the frailty introduced by the unnecessary complexity. For starters, the parselog.pl script is only meant to provide an example, and its not really suitable for all kinds of log files (it had some confusion with Squid access logs in my testing, for example, and produced misleading data). Along the same lines, all of the events produced by parselog.pl have the same source, category, user, event, and severity identifiers, which makes it difficult to filter and watch for specific kinds of problems.

Once the data is generated, you also need a client-side DLL for Event Viewer to know how to parse the event data. Otherwise you end up with "The description for Event ID (1000) in Source (Syslog) cannot be found" errors tagged to all the entries; you can see this output in the screenshot above. All in all, this solution is really more of a starting point than anything, but it still quite useful, and much easier for Windows administrators to use than traditional UNIX logfile tools.