Michal,<br><br>you've completely missed my invitation to talk about packaging standardization:<br>was it intentional?<br><br>@Stan: would you have some time to talk about it too?<br><br><div class="gmail_quote">2011/4/21 Michal Hlavinka<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>> > That way, slower shell scripts<br>
> >>> only execute once when the system administrator changes the<br>
> >>> configuration, and systemd would read those generated files.<br>
> >>><br>
> >><br>
> >> Still the same question, what do you want/need that script for?<br>
> >><br>
> ><br>
> > Maybe it's just a convenience that we don't really need. Arnaud?<br>
> ><br>
><br>
> I can't say it's a convenience, at least not more or less than the files it<br>
> tries to replace.<br>
> whatever the number of init script / service files, we need to instruct the<br>
> system which NUT components it has to start.<br>
> And having a way to do it the same across systems is worth IMHO.<br>
><br>
> that being said, the shell approach doesn't satisfy me much, but was a good<br>
> compromise for a first round.<br>
> part of the work around the configuration, we might consider a config<br>
> accessor, like:<br>
> $ nut-config --get-mode<br>
><br>
> @Michal: would that suit systemd way of life?<br>
<br>
</div>I probably don't understand what is it supposed to help with?</blockquote><div><br>- standardisation: one way (ie root source of setting, not way to obtain the setting) for all systems, whatever distro, whatever init<br>
- simplicity: you set one "var", instead of 2 in you system.<br><br>just remember that, part of the roadmap, there is a configuration tools planned. and the above "nut-config" is the CLI side.<br>having to manage bagazillion of different package names, binaries paths, user names, init config, (...) has refrained such efforts until now.<br>
<br>many other effort would greatly benefit from an overall standardization of NUT distribution!<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
If we use<br>
shell script "one for all" starting everything needed (based on MODE in nut.conf),<br>
it'd be equal to option 3) from first email. Getting required mode from nut-config<br>
compared to getting it from nut.conf is no better from systemd's POV. Option<br>
"3)" is not prefered compared to option 4), but there's no enforcement policy<br>
about this. So, they won't like us, but we can ignore their grumbling :o)<br>
btw, systemd supports:<br>
EnvironmentFile=/some/config/file (containing ABC=foo)<br>
ExecStart=/sbin/daemon -abc $ABC<br>
<br>
but it does not support /some/config/file containing ABC=$(get-config --abc)<br>
nor ExecStart=/sbin/daemon -abc $(get-config --abc)<br></blockquote><div><br>do not confuse splitting services into separate files (we are all ok with option 4)<br>and triggering or conditioning service startup.<br> <br>
the former can be linked to package splitting, ie upsmon is part of nut-client along with its service file.<br>while drivers/upsd are part of the core.<br><br>the latter is related to nut.conf and... well, I still fail to see how systemd provides this.<br>
you've mentioned /etc/sysconfig/ups removal, but no replacement mechanism!<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>
> a side question: what is the status of Augeas (still RH sponsored project)<br>
> in Fedora / RedHat?<br>
<br>
</div>It's installable on Fedora and it's still actively developed, but I don't know about<br>
anything using it.<br>
</blockquote></div><br>mcollective seems to be a first step toward something useful.<br>I'm astonished that RH guys have not started converting system-config-* to augeas, nor developed infrastructure tools!<br>or did I miss something?<br>
<br>cheers,<br>Arno<br>