[Nut-upsdev] RFC: nut and systemd

Thu May 12 07:26:38 UTC 2011

Hi Michal,

first, I know understand where our "disagreement" comes from:
in Debian, we have a generic ups-monitor role provided by several packages.
the shutoff (final ups poweroff) hook is located in the package's
initscript, and is called from halt.
whereas, in RH/Fedora, you don't have this generic role (afaik), nor the
hook in the package's initscript.

which means that NUT initscript in RH only has to deal with
start/stop/restart, which are the standard conditions.
I'll have to think more about that, but for the time being, you may want to
progress with your previously mentioned approach (4).

I'm anyway releasing the below draft answers, which clarifies a few points,
and may serve anyway.

@Stan: I'd like to hear your point of view here.

2011/4/26 Michal Hlavinka <mhlavink at redhat.com>

> > you've completely missed my invitation to talk about packaging
> > standardization:
> > was it intentional?
>
> nope. AFAIK packaging is already standardized on all distributions,

I don't think we're talking about the same things!

Here are the packages on Suse (@Stan: nothing missing?)
- nut (provided by either nut-classic or nut-hal iirc)
- nut-cgi
- nut-classic
- nut-devel
- nut-drivers-net
- nut-hal
- libupsclient1

On RH/Fedora:
- nut
- nut-cgi
- nut-client
- nut-devel
- nut-hal
- nut-xml

Here are the one on Debian and its derivatives:
- nut
- nut-cgi
- nut-hal-drivers
- nut-powerman-pdu
- nut-snmp
- nut-xml
- libupsclient1
- libupsclient1-dev

On Debian, several new packages will appears:
- nut-doc (+ nut-doc-html and nut-doc-pdf)
- nut-client (for moving upsmon and base clients)

Things like libupsclient has been extracted from the nut package to satisfy
3rd party tools, like collectd, nut-cgi and wmnut in case there is no local
NUT for example.
Moreover, things like the SNMP agent resurrection, discovery and
configuration tools, integrated power management (feed upower), (...) may
impact the way NUT is packaged.

So, we can say that there are similarities.
But certainly not that "packaging is already standardized on all
distributions"!

so only
> new changes needs to be standardized and that is exactly why I sent
> this email instead of just doing it Fedora way in Fedora.
>

thanks for that, this is very much appreciated, Michal.
lowering the barrier between upstream and downstream (ie distros) has been
part of my todo list for an eternity.
so packagers help and discussion are always welcome.

 > > > >  That way, slower shell scripts
> > > > >>> only execute once when the system administrator changes the
> > > > >>> configuration, and systemd would read those generated files.
> > > > >>>
> > > > >>
> > > > >> Still the same question, what do you want/need that script for?
> > > > >>
> > > > >
> > > > > Maybe it's just a convenience that we don't really need. Arnaud?
> > > > >
> > > >
> > > > I can't say it's a convenience, at least not more or less than the
> files
> > > it
> > > > tries to replace.
> > > > whatever the number of init script / service files, we need to
> instruct
> > > the
> > > > system which NUT components it has to start.
> > > > And having a way to do it the same across systems is worth IMHO.
> > > >
> > > > that being said, the shell approach doesn't satisfy me much, but was
> a
> > > good
> > > > compromise for a first round.
> > > > part of the work around the configuration, we might consider a config
> > > > accessor, like:
> > > > $ nut-config --get-mode
> > > >
> > > > @Michal: would that suit systemd way of life?
> > >
> > > I probably don't understand what is it supposed to help with?
> >
> >
> > - standardisation: one way (ie root source of setting, not way to obtain
> the
> > setting) for all systems, whatever distro, whatever init
>
> well in distro A all services are configured the same way, so I think it's
> quite easy to configure nut when that task is similar to configuring
> smartd,
> httpd,... I don't think systemd & nut is going to scare users when they
> already understand systemd thanks experience with httpd,dovecot,
> smartd,....  So I think it's questionable whether to do everything the same
> way for one package on all systems OR handle package the same way as all
> other packages on system XYZ. If I have experience with Fedora/Debian/
> OpenSUSE/Mandriva/... and I want to find out how to set up nut on my
> system,
> I'd appreciate more when it's done the same way as all other sw on my
> system
> then when it's done the same way on all systems. So I think standardization
> is good (where I can find config file X, documentation,....), but I find
> init
> system little bit different. I don't think nut&systemd configuration must
> be the same as nut&SysV or nut&upstart, it just seems that systemd is
> going to be adopted by other distributions (definitely not by all of them),
> so I'd like to standardize nut&systemd the way which does not need to be
> 100 % compatible with SysV init system (at least from my POV).
>

AFAICT, sysV init and upstart can work with MODE (and "external" settings).
systemd seems to have a more simple approach, that doesn't allow condition,
nor external settings, nor any other hook than start/stop/restart.
do you know if there any plan for such non standard actions/hooks for
systemd?

> > - simplicity: you set one "var", instead of 2 in you system.
>
> afaik for upsdrvctl, upsd and upsmon the first two should work together
> always and the third one is independent. So there are two "groups"
> A=upsdrvctl&upsd  and B=upsmon
>

indeed. which doesn't implies to have 2 configuration files.

change from:
> chkconfig ups on
> to
> systemctl enable ups.service
> or
> systemctl enable ups.service; systemctl enable upsmon.service
>
> does not make that big difference and I think this behavior is
> expected (at least in Fedora/RHEL).
>

just ask yourself the question:
do users want to know that they need to start upsdrvctl / upsd / upsmon?
and the way they have to do it on every different system they might have.
or do they want to select a use case that matches their needs, like:
- [manual and none] special cases,
- standalone setup
- network server (master),
- network client (slave),
- pm (power management ; only implies driver(s) in pm-mode, feeding upower,
+ upsd)
- supervision (only implies driver(s) + upsd)

Note that the 2 latter were missing, and the last is the one that answers
your question on not starting upsmon.

 > just remember that, part of the roadmap, there is a configuration tools
> > planned. and the above "nut-config" is the CLI side.
> > having to manage bagazillion of different package names, binaries paths,
> > user names, init config, (...) has refrained such efforts until now.
> >
> > many other effort would greatly benefit from an overall standardization
> of
> > NUT distribution!
> >
> > If we use
> > > shell script "one for all" starting everything needed (based on MODE in
> > > nut.conf),
> > > it'd be equal to option 3) from first email. Getting required mode from
> > > nut-config
> > > compared to getting it from nut.conf is no better from systemd's POV.
> > > Option
> > > "3)" is not prefered compared to option 4), but there's no enforcement
> > > policy
> > > about this. So, they won't like us, but we can ignore their grumbling
> :o)
> > > btw, systemd supports:
> > > EnvironmentFile=/some/config/file (containing ABC=foo)
> > > ExecStart=/sbin/daemon -abc $ABC
> > >
> > > but it does not support /some/config/file containing ABC=$(get-config
> > > --abc)
> > > nor ExecStart=/sbin/daemon -abc $(get-config --abc)
> > >
> >
> > do not confuse splitting services into separate files (we are all ok with
> > option 4)
> > and triggering or conditioning service startup.
> >
> > the former can be linked to package splitting, ie upsmon is part of
> > nut-client along with its service file.
> > while drivers/upsd are part of the core.
> >
> > the latter is related to nut.conf and... well, I still fail to see how
> > systemd provides this.
> > you've mentioned /etc/sysconfig/ups removal, but no replacement
> mechanism!
>
> MODE can give only 4 possibilities (afaik)
> A on | on | off | off
> B on | off | on | off
>
> A=upsd+upsdrvctl
> B=upsmon
>
> and this can be achieved very easily with just two standard configuration
> commands and thanks splitting nut to 2(3) service files they will work just
> out of the box. I can (will) add simple scriptlet in rpm %post so services
> are
> configured (on/off) initialy when upgrading from sysv version with
> etc/sysconfig/ups to systemd version.
>
> Anyway, when 2 services and MODE in etc/sysconfig/ups kept, what should
> happen, when:
> MODE=A+B, A is running, B stopped and user restarts A?
> MODE=A, A+B is running, user restarts A?
> ...
> basically should it stop running service? restart only running? start
> missing? Or simply should it ignore systemd's configuration or should it
> ignore MODE= ? Whatever way it would be, it'd require some ugly hacks
> and script wrapper around executables or auto modification of service
> files (what if user changed anything in service file, should we touch
> that file and break his configuration or ignore MODE=?). It seems to me
> doing it the same way as other services on specific system/distribution
> to be better way than trying to have systemd compatible with
> sysv/upstart. Anyway, it's not expected that user changes his init systemd
> as simple update process, but only on system upgrade OR it'll require some
> manual changes.
>

well, were talking about an exception case here.
services registration / activation is a point.
what we are talking about, once more, is what is done inside of these
scripts.

As an obvious (and probably the most basic) example with NUT:
how will you handle the "poweroff" target of the NUT sysV init script?

      if upsmon -K >/dev/null 2>&1 ; then
        if upsdrvctl shutdown ; then

(Note: this is where I stopped and understand our issue, as explained as an
introduction to this mail...)

 >
> > > a side question: what is the status of Augeas (still RH sponsored
> project)
> > > > in Fedora / RedHat?
> > >
> > > It's installable on Fedora and it's still actively developed, but I
> don't
> > > know about
> > > anything using it.
> > >
> >
> > mcollective seems to be a first step toward something useful.
> > I'm astonished that RH guys have not started converting system-config-*
> to
> > augeas, nor developed infrastructure tools!
> > or did I miss something?
>
> http://fedoraproject.org/wiki/Features/FMCI (Ignore target release=Fedora
> 15,
> it's not valid.) This project is combined with (extension to) matahari
> ( https://fedorahosted.org/matahari/ ). Current status is that they are
> working to finish backend (dbus and cli) which should be completed for
> Fedora
> 16. Work on gui should start after that.
>

interesting, thanks for the pointers.

cheers,
Arnaud
-- 
Linux / Unix Expert R&D - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20110512/3c087ecf/attachment.htm>