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.
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:
svcctl list = apache2 clamd dhcpd ldap named pa postfix squid xntpd
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.