Re: smf manifests in pkgsrc

["Paul B. Henson" <henson%acm.org@localhost>]

On Sun, Jan 11, 2015 at 08:48:10AM +0000, Jonathan Perkin wrote:

> This would require a large rewrite of how SMF is handled and how
> variables are substituted, would break a lot of users who already
> depend on the current naming scheme, would require the addition of
> hard-coded FMRIs, and would remove the ability for users to have
> separate SMF prefixes (e.g. if they want to have multiple branches
> installed).

Hmm. You make this sound much more complicated than I anticipated :).

I will grant you transition headache if a user had a package with one
FMRI and an update resulted in another. OTOH, at Joyent you strongly
recommend against updating in favor of just reprovisioning with a new
dataset, so it wouldn't be an issue for your customers ;). Given such a
transition would only matter if FMRI's changed, I'm going to shelve that
problem for now to be revisited later if need be.

In the case of the current postfix manifest, it defines the FMRI as
'@SMF_PREFIX@/@SMF_NAME@', and '<create_default_instance enabled="false" />',
which turns into svc:/pkgsrc/postfix:default on the system.

What if instead the FMRI was set to svc:/network/smtp, and rather than a
default instance, a specifically name instance was created:

<instance name='@SMF_PREFIX@-@SMF_NAME@' enabled='false'>

Unless I'm (quite possibly) missing something, that simple change would
result in exactly what I suggested "svc:/network/smtp:pkgsrc-postfix",
with zero changes to code. It would also continue to allow multiple
installations with separate SMF prefixes:

svc:/network/smtp:pkgsrc-postfix
svc:/network/smtp:pkgsrc2-postfix
svc:/network/smtp:pkgsrcblah-postfix

This would of course break on services which are restricted to a single
instance, but that's solved by simply not doing it this way for them :).

Yes, the FMRI svc:/network/smtp would be hardcoded. Why is that *bad*?
Arguably, that seems *good*. On all SMF using operating systems I know
of, the mail system out of the box uses svc:/network/smtp as the FMRI.
If you want to install postfix, why wouldn't you want everything else on
the system to recognize it as the mail system? There are many hardcoded
FMRI's in the existing postfix manifest, such as svc:/system/system-log,
svc:/milestone/name-services, etc; they are hardcoded because they *are*
the standard FMRI for the service.

For example, let's say I install postfix and syslog-ng out of pkgsrc,
with the intention of replacing the OS implementations. While syslog-ng
doesn't currently have an SMF manifest in pkgsrc, presumably if one were
added, the FMRI would be svc:/pkgsrc/syslog-ng:default.

So here I am, trying to run pkgsrc postfix with pkgsrc syslog-ng. You'd
think that would work out of the box, right? Nope, pkgsrc postfix would
refuse to start because its hardcoded dependency on
svc:/system/system-log isn't met. What then? I'd have to either use the
system syslog, or mangle either the pkgsrc postfix or syslog-ng
manifests to kludge it to work.

Whereas with my suggestion it would "just work" :). pkgsrc postfix would
recognize svc:/system/system-log:pkgsrc-syslog-ng as a valid provider of
the svc:/system/system-log service. And anything else that wanted a mail
system running would be happy with svc:/network/smtp:pkgsrc-postfix to
provide it...

Thanks...