[talk] classifying BSD init

Patrik Lundin patrik at sigterm.se
Sun Aug 30 17:29:44 EDT 2015


On Sun, Aug 30, 2015 at 03:30:55PM -0400, Brian Coca wrote:
> >
> > Is there a plan to manage this in some way? Maby move these functions
> > into some central location instead so they can be called by separate
> > modules? This is a relevant question both for a unified bsdinit
> > module, as well as having one module per project.
> 
> shared module code lives in lib/ansible/module_utils, this is where i
> was planning to move shared code from the current service module.
> 

This sounds like a nice way forward :).

> > On a more specific OpenBSD note:
> > Calling the OpenBSD module "rcctl" might be misleading, given that
> > this only applies to versions of OpenBSD new enough to actually have
> > that utility (older versions use the /etc/rc.d scripts directly).
> > Given that the package manager is called "openbsd_pkg", maby calling
> > it "openbsd_rc" or "openbsd_service" would be better (as well as not
> > dependant on the "service manager of the day")?
> > I guess the main drawback of this naming convention would be if
> > another OS decided to port the OpenBSD rcctl utility, however, this
> > begs the question if the "rcctl" module would be separate from a
> > "openbsd_rc.d" utility for the older OpenBSD systems.... ugh... :).
> >
> 
> This also depends a lot on how they port, if it is 100% compatible my
> guess is that having an rcctl package will work for both OpenBSD and
> whatever system it was ported to.
> As for detection, I'll amend it to look for the rcctl binary and
> default to rcconf if otherwise.
> 
>         elif self.facts['system'] == 'OpenBSD':
>                 if module.find_bin('rcctl'):
>                     self.facts['service_mgr'] = 'rcctl'
>                 else:
>                     self.facts['service_mgr'] = 'rcconf'
>

This can work, rcconf then needs to be aware of what OS it is running on
since OpenBSD uses a different approach than FreeBSD and NetBSD (it does
not use the YES/NO boolean flags).

For example, enabling a service (configuring that it should start at boot)
is not possible on OpenBSD when the rcctl utility is missing because of
this. This basically means "rcconf" will not actually be able to modify
rc.conf.local on OpenBSD, but only call rc.d scripts directly to
start/stop services.

Under any circumstances, I would be happy to help out on the OpenBSD
side of things if/when this gets going.

Seems the cleanest way forward would be to remove classes from the
service module in a step-by-step fashion as new modules are ready to
take over.

-- 
Patrik Lundin



More information about the talk mailing list