The work done and the text written by Geoff Gibbs; presentation by myself. The manifests and method files are available for download.
We use Postfix rather than Sendmail. It now supports NIS+ as standard.
When we moved our mail server to Solaris 10 I wanted to have the mail system properly under the control of Greenline (SMF).
The mail system consists of several dependant parts, with some indication of the dependencies shown with the indentation :-
Postfix Mail Transfer Agent saslauthd authorization daemon Amavisd-new mail filter glue (Spamassassin) Spam scorer ClamAV Anti-virus daemon Sophie Anti-virus daemon GLD Greylist daemon MySQL database used by GLD Pop-before-smtp database of remote users machines Freshclam update virus database mstats collect mail stats
Amavisd-new and Spamassassin are both written in Perl, and Amavis includes Spamassassin into its own address space, so that Spamassassin does not show up as a separate process or service.
SMF will bring up services in the correct order, according to the dependencies. These dependencies have to be explicitly declared. For each item that we want controlled there are two files which we create, an XML manifest and a shell script method. The manifest defines the dependencies and the method provides ways to start, refresh and stop the service. The files are located :-
manifests /var/svc/manifest methods /lib/svc/method
The methods were the simplest place to start as they tend to be similar to the /etc/init.d start-up scripts and I started with Postfix itself and soon had a working method file.
The manifest took a little more work. The directory is divided into :-
application, device, milestone, network, platform, site, system
I decided to place the files which I produced into the site directory. However, as a starting point I copied the sendmail manifest, which lives in the network sub-directory. In fact all of these services were to end up as network services, but the files were to be kept in the site directory.
Sendmail was set-up to be an instance of smtp, so I followed this and made Postfix an instance of smtp with the Sendmail instance disabled.
The manifest file defines the services on which our new service is itself dependant (dependencies). This can include files, typically its own configuration files. It also defines which services are dependant on this new service (dependants). This allows us to avoid modifying existing manifests.
Starting with the Sendmail manifest gives a good start at listing the dependencies for Postfix, as they do the same job and require the same services. It is the most complicated of the manifests which I produced as it is an instance (of smtp). There are dependencies of smtp and of Postfix. Thus smtp depends on the name services :-
<dependency
name='name-services'
grouping='require_all'
restart_on='refresh'
type='service'>
<service_fmri value='svc:/milestone/name-services' />
</dependency>
while Postfix depends on its configuration files :-
<instance name='postfix' enabled='true'>
<dependency
name='main-file'
grouping='require_all'
restart_on='refresh'
type='path'>
<service_fmri
value='file://localhost/etc/postfix/main.cf' />
</dependency>
In the manifest we define the start/stop/refresh methods :-
<exec_method
type='method'
name='start'
exec='/lib/svc/method/smtp-postfix start'
timeout_seconds='10' />
as well as a section (template) with helpful information such as its name and the location of the man pages.
The collection of manifests and methods are provided, but they would not be usable immediately without checking file paths etc.
When the manifest was ready, it was necessary to import it into SMF. The overall process looked like this :-
# cp /lib/svc/method/smtp-sendmail /lib/svc/method/smtp-postfix and edit it! # cp /var/svc/manifest/network/smtp-sendmail.xml /var/svc/manifest/site/smtp-postfix.xml and edit it! # svccfg svc:> help General commands: help set repository end Manifest commands: inventory validate import export archive Profile commands: apply extract Entity commands: list select unselect add delete Snapshot commands: listsnap selectsnap revert Property group commands: listpg addpg delpg Property commands: listprop setprop delprop editprop Property value commands: addpropvalue delpropvalue setenv unsetenv svc:> help import Usage: import file Import a manifest into the repository. svc:> import /var/svc/manifest/site/smtp-postfix.xml svc:> end
or you can just import it in one go:
# /usr/sbin/svccfg -v import /var/svc/manifest/site/smtp-postfix.xml # svcs [lots of output showing which services are running...]
Inevitably, errors were made on the way. "svcs -xv" is useful to see an explanation of services which have problems, e.g. :-
# svcs -vx postfix svc:/network/smtp:postfix (postfix SMTP mail transfer agent) State: online since Wed Feb 09 11:05:04 2005 See: man -M /etc/postfix/man -s 1 postfix See: /var/svc/log/network-smtp:postfix.log Impact: None.
I found that the easiest way to correct a fault in the manifest was to edit the file, then delete the entry and re-import the file. :-
svcadm -v disable svc:/network/smtp:postfix svccfg -v delete svc:/network/smtp:postfix svccfg -v import /var/svc/manifest/site/postfix.xml
Notice that svcadm is used for manipulating a service, while svccfg is used for importing its configuration. You can use the full URL to describe the service, or you can use abbreviations. You need to disable a service before you can delete it!
The other services were set up, not as instances of something else, but as a service with a default instance. The difference in the XML manifest is fairly small. There is no instance tag :-
<instance name='postfix' enabled='true'>
with its own dependencies. Rather there are two self contained tags :-
<create_default_instance enabled='true' /> <single_instance />
Notice the "/>" closing off the tags.
I created the manifest for amavisd-new from the postfix one. In replacing the instance tags I made a mistake in that the template tag near the end should now be the last tag within the service tag rather than the last within the instance tags. Simply changing the instance tags leaves the template tag in the wrong place. If you need to check the order, then the manifest for sshd in the network subdirectory makes a good model. When this was sorted out it all worked smoothly.
The last phase was looking after the services which were run by inetd. In this context these were the various pop and imap daemons. The technique was to put the lines required by inetd into a separate file and then feed this file to the "inetconv" command :-
# inetconv -o /var/svc/manifest/site/ -i /people/ggibbs/postfix/imap.inetd
this read in the file imap.inetd and placed the required manifests into our site directory and imported the services into SMF.