RE: smf manifests in pkgsrc

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

No further thoughts on this? I'm currently working on updating the openntpd
package to the latest version, and as part of that plan to add an smf
manifest for it. I'd really like to make the FRMI for that
svc:/network/ntp:pkgsrc-openntpd so it can cleanly replace the bundled
operating system service. As I described below, it seems that could be
easily accomplished within the existing infrastructure simply by shuffling
around where the substitution variables are in the manifest, but I feel I am
missing something given your warning that changing the FMRI's would be a
complicated process requiring code rewrite.

Thanks much.

> -----Original Message-----
> From: Paul Henson
> Sent: Sunday, January 11, 2015 8:37 PM
> To: tech-pkg%NetBSD.org@localhost
> Subject: Re: smf manifests in pkgsrc
> 
> 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...