Day 19 of 60: Running Sendmail in the zones (pt 1)

Now that Sendmail is building and correctly installing in to a custom directory it's time to start looking at how I get my version of Sendmail used instead of the version that's supplied with Solaris.

For that, I need to delve in to the Solaris Service Management Facility (SMF).



At the risk of oversimplifying, the SMF is the replacement for the SysV-style startup process.

Instead of having a collection of shell scripts that live in /etc/init.d, and symlinks to /etc/rcX.d with names sorted in ASCIIbetical order to control ordering, you now have a collection of services. Each service has its configuration which describes what commands are necessary to run the service, how logging should happen, whether the service has dependencies on other services, and so on.

Services can be made persistent with svc.startd(1M), which watches the running services, and will automatically start and restart services that are supposed to be persistent.

So I'm going to poke around one of my configured zones and see how to use my local Sendmail build.

Logging in to a zone

The first thing to do is log in to the zone. I could connect to the zone's console with zlogin -C external-zone, but that only works as root. However, since for all intents and purposes the zone behaves like another host I can just ssh in to it.

% ssh external-zone
The authenticity of host 'external-zone (192.168.0.102)' can't be established.
RSA key fingerprint is 87:39:e8:06:06:ab:f7:71:97:27:d2:7b:f2:46:48:38.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'external-zone,192.168.0.102' (RSA) to the list of known hosts.
Last login: Fri Jul 28 15:47:54 2006 from 192.168.0.23
Sun Microsystems Inc. SunOS 5.11 snv_40 October 2007

Checking service details

To see the details for a particular service use svcs(1). If I run just that command it lists all the services that are configured (which is not the same thing as all the services that are running). If I want to specify a particular service I have to use what Sun calls a Fault Management Resource Identifier (FMRI). These look like URIs, but with a svc protocol. Some examples from smf(5).

svc://localhost/system/system-log:default
svc:/system/system-log:default
system/system-log:default

You don't need to provide the full FMRI to svcs(1), so on a hunch I just try "smtp", and am rewarded with:

% svcs smtp
STATE STIME FMRI
online 12:40:44 svc:/network/smtp:sendmail

which looks promising (and has also told me the full FMRI). And if I try and connect to the running Sendmail:

% telnet localhost smtp
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 external-zone.nothing-going-on.org ESMTP Sendmail 8.13.6+Sun/8.13.6; Fri, 28 Jul 2006 15:59:20 +0100 (BST)
quit
221 2.0.0 external-zone.nothing-going-on.org closing connection
Connection to localhost closed by foreign host.

The man page for svccfg(1M) suggests that I can use the export subcommand to export the definition for any service I'm interested in, so

% svccfg export smtp





...


a total of 60 lines of XML.

Hmm.

Now I'm not one to automatically start frothing at the mouth at the sight of XML. I've even been known to write an application or two that uses it, and I've been involved in projects that have involved manipulating large amounts of XML.

And XML does solve a lot of problems. It's regular. There are well known libraries for parsing it. i180n issues are, by and large, solved.

It's just not especially human readable. There aren't widely deployed tools for managing them, and you can't sling a line of XML through a pipeline involving grep, sed, and awk in the same way you can a line from /etc/passwd (for instance).

So the support tools need to be up to scratch.

Grovelling through the XML generated by the "export" command above I found this section.

...

...


...

So we've got an element called exec_method with various attributes, one of which, exec looks like what I need.

Poking through the documentation it turns out that this isn't, despite the name, a method. It's a "property group". The command line to run to extract this without wading through the XML Is:

% svccfg -s sendmail listprop start/exec
start/exec astring "/lib/svc/method/smtp-sendmail start"

That's relatively simple, and the output's easy to follow, so I'm not too annoyed about that. The method/property discrepency is a little annoying though.

Digging deeper in to the startup

The output from that svccfg(1) command shows that /lib/svc/method/smtp-sendmail is where to go digging for the commands that start Sendmail.

Out of habit, I check before blindly running it through $PAGER.

% file /lib/svc/method/smtp-sendmail
/lib/svc/method/smtp-sendmail: executable /sbin/sh script

So far so good. Sadly, it all goes downhill from there.

I'd been hoping that the startup script might contain a single prefix definition near the top, and then reference all the Sendmail binaries using that. Adjusting the prefix would be sufficient to change the Sendmail that it runs.

Unfortunately, it's got hardcoded /usr/lib/sendmail and the like all over the place. So it looks like I'm going to have to take that script as a starting point, amend it to allow more customisation, and then adjust the service method^H^H^H^H^H^Hproperty to use it.

Rats. That'll have to wait until later.