FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 10-04-2012, 06:47 PM
Tom Gundersen
 
Default systemd conversion

On Thu, Oct 4, 2012 at 8:31 PM, Matthew Monaco <dgbaley27@0x01b.net> wrote:
> Is there a general strategy as far as reusing /etc/conf.d/? A lot of units can
> use those as environment files to work as drop-in replacements for the rc.d
> scripts, but there's probably more systemd-ish ways of configuring most units.

The general strategy is "don't do that". The reason being that such a
service file would never be acceptable upstream, as /etc/conf.d/ is
arch-specific. This means that we will likely have to change it again
in the future and it seems more natural to have the break now rather
than at random times later.

The ideal way to set things up is: don't use EnvironmentFile unless
you must. If you can, set up the service file so that it can give a
reasonable default out-of-the-box without further configuration.
Moreover, prefer configurations to happen in the native config files
of the service if they exist, rather than on the commandline. Lastly,
the expectation should be that in case the user/admin needs to tweak
the service file, this can be done by copying it to /etc/systemd/ and
editing it there, rather than editing a config file.

To be a bit less abstract:

* An example of where I could see no way but use EnvironmentFile is
for domainname.service in yp-tools.
* An example of where one might argue that an EnvironmentFile would
be useful, but where I think I found a reasonable way to avoid it is
transmission-cli.

Cheers,

Tom
 
Old 10-04-2012, 06:57 PM
Daniel Isenmann
 
Default systemd conversion

On Thu, 2012-10-04 at 20:27 +0200, Tom Gundersen wrote:
> On Thu, Oct 4, 2012 at 8:16 PM, Tom Gundersen <teg@jklm.no> wrote:
> > Hi guys,
> >
> > Thanks to everyone who converted their packages to use native systemd
> > service files since my last email.
> >
> > There are stil 66 packages remaining in our TODO however (10 from
> > extra and the rest from community):
> > https://www.archlinux.org/todo/178/.
>
> I got a request from a user eager to help to post the full list (our
> TODO lists are password protected, mostly by accident I think):

> x86_64 Extra mono 2.10.8-1 daniel Incomplete
> x86_64 Extra xsp 2.10.2-3 daniel Incomplete

Hi,

feel free to do the above packages. I'm totally busy with my real life
right now and don't have time to do it at the moment.

- Daniel
 
Old 10-04-2012, 06:57 PM
Daniel Isenmann
 
Default systemd conversion

On Thu, 2012-10-04 at 20:27 +0200, Tom Gundersen wrote:
> On Thu, Oct 4, 2012 at 8:16 PM, Tom Gundersen <teg@jklm.no> wrote:
> > Hi guys,
> >
> > Thanks to everyone who converted their packages to use native systemd
> > service files since my last email.
> >
> > There are stil 66 packages remaining in our TODO however (10 from
> > extra and the rest from community):
> > https://www.archlinux.org/todo/178/.
>
> I got a request from a user eager to help to post the full list (our
> TODO lists are password protected, mostly by accident I think):

> x86_64 Extra mono 2.10.8-1 daniel Incomplete
> x86_64 Extra xsp 2.10.2-3 daniel Incomplete

Hi,

feel free to do the above packages. I'm totally busy with my real life
right now and don't have time to do it at the moment.

- Daniel
 
Old 10-04-2012, 06:58 PM
Matthew Monaco
 
Default systemd conversion

On 10/04/2012 12:47 PM, Tom Gundersen wrote:
> On Thu, Oct 4, 2012 at 8:31 PM, Matthew Monaco <dgbaley27@0x01b.net> wrote:
>> Is there a general strategy as far as reusing /etc/conf.d/? A lot of units can
>> use those as environment files to work as drop-in replacements for the rc.d
>> scripts, but there's probably more systemd-ish ways of configuring most units.
>
> The general strategy is "don't do that". The reason being that such a
> service file would never be acceptable upstream, as /etc/conf.d/ is
> arch-specific. This means that we will likely have to change it again
> in the future and it seems more natural to have the break now rather
> than at random times later.
>
> The ideal way to set things up is: don't use EnvironmentFile unless
> you must. If you can, set up the service file so that it can give a
> reasonable default out-of-the-box without further configuration.
> Moreover, prefer configurations to happen in the native config files
> of the service if they exist, rather than on the commandline. Lastly,
> the expectation should be that in case the user/admin needs to tweak
> the service file, this can be done by copying it to /etc/systemd/ and
> editing it there, rather than editing a config file.
>
> To be a bit less abstract:
>
> * An example of where I could see no way but use EnvironmentFile is
> for domainname.service in yp-tools.
> * An example of where one might argue that an EnvironmentFile would
> be useful, but where I think I found a reasonable way to avoid it is
> transmission-cli.
>
> Cheers,
>
> Tom
>

Ok, that said:

This will do what rc.d/webfsd does with conf.d/webfsd:
webfsd.service ---------------------------------------------------------
[Unit]
Description=webfsd
Documentation=man:webfsd(1)
After=network.target

[Service]
ExecStart=/usr/bin/webfsd -p 8080 -u nobody -R /srv/http -f index.html -F

[Install]
WantedBy=multi-user.target


But I think an EnvironmentFile is useful for this service as it only takes
config on the command line.
webfsd@.service --------------------------------------------------------
[Unit]
Description=webfsd
Documentation=man:webfsd(1)
After=network.target

[Service]
EnvironmentFile=/etc/webfs/%i.conf
ExecStart=/usr/bin/webfsd $WEBFSD_ARGS -F

[Install]
WantedBy=multi-user.target
 
Old 10-04-2012, 07:00 PM
Thomas Bächler
 
Default systemd conversion

Am 04.10.2012 20:39, schrieb Andreas Radke:
> Am Thu, 4 Oct 2012 20:27:37 +0200
> schrieb Tom Gundersen <teg@jklm.no>:
>
>> x86_64 Extra xorg-xfs 1.1.2-1 jgc,
>> andyrtr Incomplete
>
> We will drop xorg-xfs completely from the repos. It's useless now.
>
> -Andy

Please mark it as Complete on the list then. I would consider this as
equivalent to "Not Applicable".
 
Old 10-04-2012, 07:10 PM
Tom Gundersen
 
Default systemd conversion

On Thu, Oct 4, 2012 at 8:58 PM, Matthew Monaco <dgbaley27@0x01b.net> wrote:
> This will do what rc.d/webfsd does with conf.d/webfsd:
> webfsd.service ---------------------------------------------------------
> [Unit]
> Description=webfsd
> Documentation=man:webfsd(1)
> After=network.target
>
> [Service]
> ExecStart=/usr/bin/webfsd -p 8080 -u nobody -R /srv/http -f index.html -F
>
> [Install]
> WantedBy=multi-user.target
>
>
> But I think an EnvironmentFile is useful for this service as it only takes
> config on the command line.
> webfsd@.service --------------------------------------------------------
> [Unit]
> Description=webfsd
> Documentation=man:webfsd(1)
> After=network.target
>
> [Service]
> EnvironmentFile=/etc/webfs/%i.conf
> ExecStart=/usr/bin/webfsd $WEBFSD_ARGS -F
>
> [Install]
> WantedBy=multi-user.target

It depends on the service/daemon of course, so there might be a case
for doing this. I would say to keep it simple in general (the first
file you pasted), but if it turns out that there is no way to make it
generic enough (e.g., in the case of domainname literally every admin
would need to tweak the file), then using EnvFile might make sense.

I would, however, really resist using instances of config files as you
did here, unless that is really a common scenario (I don't know this
software at all, so might be). Let's keep it simple :-)

-t
 
Old 10-04-2012, 07:12 PM
"David J. Haines"
 
Default systemd conversion

On Thu, Oct 04, 2012 at 02:47:34PM -0400, Dave Reisner wrote:
> On Thu, Oct 04, 2012 at 12:31:39PM -0600, Matthew Monaco wrote:
> > On 10/04/2012 12:27 PM, Tom Gundersen wrote:
> > > On Thu, Oct 4, 2012 at 8:16 PM, Tom Gundersen <teg@jklm.no> wrote:
> > >> Hi guys,
> > >>
> > >> Thanks to everyone who converted their packages to use native systemd
> > >> service files since my last email.
> > >>
> > >> There are stil 66 packages remaining in our TODO however (10 from
> > >> extra and the rest from community):
> > >> https://www.archlinux.org/todo/178/.
> > >
> > > I got a request from a user eager to help to post the full list (our
> > > TODO lists are password protected, mostly by accident I think):
> > >
> >
> >
> > It's not password protected if you navigate to it from archlinux.org.
> >
> > Is there a general strategy as far as reusing /etc/conf.d/? A lot of units can
> > use those as environment files to work as drop-in replacements for the rc.d
> > scripts, but there's probably more systemd-ish ways of configuring most units.
>
> Environment files from /etc/conf.d are not to be used. We provide sane
> defaults in the unit file we ship (a conflation of the /etc/rc.d script
> and the options in the /etc/conf.d file) and let users override in /etc
> if needed.
>
> d

Is there now any equivalent to .pacnew files for what would have been
configuration files in /etc/conf.d? That is to say, if before a user
edited /etc/conf.d/<some file> and that file received a newer version in
its package, a .pacnew file would be left behind, indicating that the
user should set about merging his/her custom configuration into the
newer "stock" configuration. Very useful, that. Now, however, it would
seem that the user will never see such a message (even though
potentially critical changes have been made to the unit file) because
the custom unit file in /etc/systemd/... won't be tracked by pacman.

Is there a good solution for detecting such changes, so that users can
once again merge their necessary changes into the systemd equivalents of
/etc/conf.d files?

--
David J. Haines
djhaines@gmx.com
 
Old 10-04-2012, 07:19 PM
Tom Gundersen
 
Default systemd conversion

On Thu, Oct 4, 2012 at 9:12 PM, David J. Haines <djhaines@gmx.com> wrote:
> Is there now any equivalent to .pacnew files for what would have been
> configuration files in /etc/conf.d? That is to say, if before a user
> edited /etc/conf.d/<some file> and that file received a newer version in
> its package, a .pacnew file would be left behind, indicating that the
> user should set about merging his/her custom configuration into the
> newer "stock" configuration. Very useful, that. Now, however, it would
> seem that the user will never see such a message (even though
> potentially critical changes have been made to the unit file) because
> the custom unit file in /etc/systemd/... won't be tracked by pacman.
>
> Is there a good solution for detecting such changes, so that users can
> once again merge their necessary changes into the systemd equivalents of
> /etc/conf.d files?

Using Includes rather than copying the full service file reduces this
problem somewhat. Moreover, there is the systemd-delta tool which is
quite useful (it shows you the "diff" between the shipped service file
and the actual one that you are using).

-t
 
Old 10-04-2012, 07:24 PM
"David J. Haines"
 
Default systemd conversion

On Thu, Oct 04, 2012 at 09:19:00PM +0200, Tom Gundersen wrote:
> On Thu, Oct 4, 2012 at 9:12 PM, David J. Haines <djhaines@gmx.com> wrote:
> > Is there now any equivalent to .pacnew files for what would have been
> > configuration files in /etc/conf.d? That is to say, if before a user
> > edited /etc/conf.d/<some file> and that file received a newer version in
> > its package, a .pacnew file would be left behind, indicating that the
> > user should set about merging his/her custom configuration into the
> > newer "stock" configuration. Very useful, that. Now, however, it would
> > seem that the user will never see such a message (even though
> > potentially critical changes have been made to the unit file) because
> > the custom unit file in /etc/systemd/... won't be tracked by pacman.
> >
> > Is there a good solution for detecting such changes, so that users can
> > once again merge their necessary changes into the systemd equivalents of
> > /etc/conf.d files?
>
> Using Includes rather than copying the full service file reduces this
> problem somewhat. Moreover, there is the systemd-delta tool which is
> quite useful (it shows you the "diff" between the shipped service file
> and the actual one that you are using).
>
> -t

Nice. Thanks!
--
David J. Haines
djhaines@gmx.com
 
Old 10-04-2012, 07:37 PM
Leonidas Spyropoulos
 
Default systemd conversion

On Thu, Oct 4, 2012 at 7:27 PM, Tom Gundersen <teg@jklm.no> wrote:
> On Thu, Oct 4, 2012 at 8:16 PM, Tom Gundersen <teg@jklm.no> wrote:
>> Hi guys,
>>
>> Thanks to everyone who converted their packages to use native systemd
>> service files since my last email.
>>
>> There are stil 66 packages remaining in our TODO however (10 from
>> extra and the rest from community):
>> https://www.archlinux.org/todo/178/.
>
> I got a request from a user eager to help to post the full list (our
> TODO lists are password protected, mostly by accident I think):
>
> x86_64 Community esekeyd 1.2.7-2 cbrannon Incomplete
> x86_64 Community espeakup 0.71-4 cbrannon Incomplete
> x86_64 Community mldonkey 3.1.3-1 cbrannon Incomplete
> x86_64 Community webfs 1.21-7 cbrannon Incomplete
> x86_64 Community gkrellm 2.3.5-2 daenyth Incomplete
> any Community lastfmsubmitd 1.0.6-5 daenyth Incomplete
> x86_64 Community noip 2.1.9-3 daenyth Incomplete
> x86_64 Extra mono 2.10.8-1 daniel Incomplete
> x86_64 Extra xsp 2.10.2-3 daniel Incomplete
> x86_64 Extra pdns 2.9.22.6-1 jgc Incomplete
> x86_64 Extra pdns-recursor 3.3-2 jgc Incomplete
> x86_64 Extra xorg-xfs 1.1.2-1 jgc, andyrtr Incomplete
> x86_64 Community boinc 7.0.25-1 jlichtblau Incomplete
> x86_64 Community boinc-nox 7.0.25-1 jlichtblau Incomplete
> x86_64 Community monit 5.5-1 jlichtblau Incomplete
> x86_64 Community quassel 0.8.0-1 jlichtblau, vesa Incomplete
> x86_64 Community partimage 0.6.9-2 lfleischer Incomplete
> x86_64 Community snort 2.9.3.1-1 lfleischer Incomplete
> x86_64 Extra at 3.1.13-1 romashka Incomplete
> x86_64 Extra net-snmp 5.7.1-3 romashka Incomplete
> any Community ajaxterm 0.11-5 spupykin Incomplete
> x86_64 Community bind-geodns 9.4.1-6 spupykin Incomplete
> x86_64 Community couchdb 1.2.0-4 spupykin Incomplete
> x86_64 Community dante 1.3.2-1 spupykin Incomplete
> x86_64 Community darkstat 3.0.715-2 spupykin Incomplete
> x86_64 Community dbmail 3.0.2-4 spupykin Incomplete
> x86_64 Community dictd 1.12.0-4 spupykin Incomplete
> any Community dkfilter 0.11-8 spupykin Incomplete
> x86_64 Community dspam 3.10.2-1 spupykin Incomplete
> x86_64 Community ejabberd 2.1.11-3 spupykin Incomplete
> x86_64 Community freeradius 2.2.0-2 spupykin Incomplete
> any Community gnump3d 3.0-6 spupykin Incomplete
> x86_64 Community gnunet 0.9.3-1 spupykin Incomplete
> x86_64 Community inputattach 1.24-5 spupykin Incomplete
> x86_64 Community ipsec-tools 0.8.0-3 spupykin Incomplete
> x86_64 Community ircservices 5.1.24-2 spupykin Incomplete
> any Community jmc 0.2.3-5 spupykin Incomplete
> x86_64 Community mcelog 1.0pre3-3 spupykin Incomplete
> x86_64 Community mediaproxy 2.5.2-2 spupykin Incomplete
> x86_64 Community opendkim 2.6.7-1 spupykin Incomplete
> x86_64 Community opensips 1.8.1-1 spupykin Incomplete
> x86_64 Community osiris 4.2.3-4 spupykin Incomplete
> x86_64 Community p3scan 2.3.2-6 spupykin Incomplete
> any Community postgrey 1.34-5 spupykin Incomplete
> x86_64 Community pound 2.6-2 spupykin Incomplete
> x86_64 Community pptpd 1.3.4-10 spupykin Incomplete
> any Community pyaimt 0.8.0.1-4 spupykin Incomplete
> any Community pyicqt 0.8.1.5-4 spupykin Incomplete
> any Community pymsnt 0.11.3-6 spupykin Incomplete
> any Community pyrss 0.9.9.1-9 spupykin Incomplete
> x86_64 Community ser2net 2.7-2 spupykin Incomplete
> x86_64 Community sysstat 10.1.1-1 spupykin Incomplete
> any Community trac 1.0-1 spupykin Incomplete
> x86_64 Community ultimate-ircd 3.0.2-5 spupykin Incomplete
> x86_64 Community unrealircd 3.2.9-2 spupykin Incomplete
> x86_64 Community xl2tpd 1.3.0-2 spupykin Incomplete
> x86_64 Community xmms2 0.8DrO_o-7 spupykin Incomplete
> any Community yahoo-t 0.4-4 spupykin Incomplete
> x86_64 Extra hpoj 0.91-17 tpowa Incomplete
> x86_64 Extra kexec-tools 2.0.3-1 tpowa Incomplete
> x86_64 Extra usermin 1.520-1 tpowa Incomplete
> x86_64 Extra vde2 2.3.2-1 tpowa Incomplete
> x86_64 Community tinc 1.0.19-2 tredaelli Incomplete
> x86_64 Community courier-authlib 0.64.0-2 Incomplete
> x86_64 Community courier-imap 4.10.0-1 Incomplete
> x86_64 Community courier-mta 0.68.1-1 Incomplete
>
> Cheers,
>
> Tom

There's this wiki page which might be useful. It contain at some
contributions to service files. Of course you should take extra care
to make sure the service files are correct. Some of the packages in
the list are in the wiki page.
For users it's on your discretion if you will use it (before the
package is upgraded)
For maintainers the files need testing and validation, but it's a start.

--
Caution: breathing may be hazardous to your health.

#include <stdio.h>
int main(){printf("%s","x4cx65x6fx6ex69x64x61x73");}
 

Thread Tools




All times are GMT. The time now is 09:31 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org