Peter's Solaris Zone

Setting up Postfix under Greenline (SMF)

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 :-

                <service_fmri value='svc:/milestone/name-services' />

while Postfix depends on its configuration files :-

        <instance name='postfix' enabled='true'>

                            value='file://localhost/etc/postfix/' />

In the manifest we define the start/stop/refresh methods :-

                        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.

Peter's Home | Zone Home