[aur-general] aur-general Digest, Vol 96, Issue 4
sammahar at gmail.com
sammahar at gmail.com
Thu Oct 4 20:20:30 EDT 2012
Hey All,
If systemd is going into base, should the "systemadm" utility make its
way into repo from AUR? It is just a GUI wrapper but it may be a life
saver for the uninitiated.
-Sam
On Fri, Oct 5, 2012 at 5:37 AM, <aur-general-request at archlinux.org> wrote:
> Send aur-general mailing list submissions to
> aur-general at archlinux.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mailman.archlinux.org/mailman/listinfo/aur-general
> or, via email, send a message with subject or body 'help' to
> aur-general-request at archlinux.org
>
> You can reach the person managing the list at
> aur-general-owner at archlinux.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of aur-general digest..."
>
>
> Today's Topics:
>
> 1. Re: [arch-dev-public] [REMINDER] systemd conversion
> (Matthew Monaco)
> 2. Re: [arch-dev-public] [REMINDER] systemd conversion
> (Tom Gundersen)
> 3. Re: [arch-dev-public] [REMINDER] systemd conversion
> (David J. Haines)
> 4. Re: [arch-dev-public] [REMINDER] systemd conversion
> (Tom Gundersen)
> 5. Re: [arch-dev-public] [REMINDER] systemd conversion
> (David J. Haines)
> 6. Re: [arch-dev-public] [REMINDER] systemd conversion
> (Leonidas Spyropoulos)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 04 Oct 2012 12:58:17 -0600
> From: Matthew Monaco <dgbaley27 at 0x01b.net>
> To: aur-general at archlinux.org
> Subject: Re: [aur-general] [arch-dev-public] [REMINDER] systemd
> conversion
> Message-ID: <506DDC49.7050701 at 0x01b.net>
> Content-Type: text/plain; charset=UTF-8
>
> On 10/04/2012 12:47 PM, Tom Gundersen wrote:
>> On Thu, Oct 4, 2012 at 8:31 PM, Matthew Monaco <dgbaley27 at 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 at .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
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 4 Oct 2012 21:10:46 +0200
> From: Tom Gundersen <teg at jklm.no>
> To: Matthew Monaco <dgbaley27 at 0x01b.net>
> Cc: aur-general at archlinux.org
> Subject: Re: [aur-general] [arch-dev-public] [REMINDER] systemd
> conversion
> Message-ID:
> <CAG-2HqWeX0ivnKVP9sJfXRudk7mePeKCZv1sqU2OMXbdL_qL4w at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Thu, Oct 4, 2012 at 8:58 PM, Matthew Monaco <dgbaley27 at 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 at .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
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 4 Oct 2012 15:12:26 -0400
> From: "David J. Haines" <djhaines at gmx.com>
> To: "Discussion about the Arch User Repository (AUR)"
> <aur-general at archlinux.org>
> Subject: Re: [aur-general] [arch-dev-public] [REMINDER] systemd
> conversion
> Message-ID: <20121004191226.GA19662 at arch.phillips-angley.com>
> Content-Type: text/plain; charset=us-ascii
>
> 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 at 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 at gmx.com
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 4 Oct 2012 21:19:00 +0200
> From: Tom Gundersen <teg at jklm.no>
> To: "Discussion about the Arch User Repository (AUR)"
> <aur-general at archlinux.org>
> Subject: Re: [aur-general] [arch-dev-public] [REMINDER] systemd
> conversion
> Message-ID:
> <CAG-2HqWG_L-9js0EGPAg3uO495UfyfoGXcnOS-bD6fmtt0KmPA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Thu, Oct 4, 2012 at 9:12 PM, David J. Haines <djhaines at 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
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 4 Oct 2012 15:24:36 -0400
> From: "David J. Haines" <djhaines at gmx.com>
> To: "Discussion about the Arch User Repository (AUR)"
> <aur-general at archlinux.org>
> Subject: Re: [aur-general] [arch-dev-public] [REMINDER] systemd
> conversion
> Message-ID: <20121004192436.GB19662 at arch.phillips-angley.com>
> Content-Type: text/plain; charset=us-ascii
>
> 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 at 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 at gmx.com
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 4 Oct 2012 20:37:37 +0100
> From: Leonidas Spyropoulos <artafinde at gmail.com>
> To: "Discussion about the Arch User Repository (AUR)"
> <aur-general at archlinux.org>
> Subject: Re: [aur-general] [arch-dev-public] [REMINDER] systemd
> conversion
> Message-ID:
> <CAAeznTp8DrsMQ8=SRjdjMDurzzm_BR9mrmBLW+bEv1S7=yuw6Q at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Thu, Oct 4, 2012 at 7:27 PM, Tom Gundersen <teg at jklm.no> wrote:
>> On Thu, Oct 4, 2012 at 8:16 PM, Tom Gundersen <teg at 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","\x4c\x65\x6f\x6e\x69\x64\x61\x73");}
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> aur-general mailing list
> aur-general at archlinux.org
> http://mailman.archlinux.org/mailman/listinfo/aur-general
>
>
> ------------------------------
>
> End of aur-general Digest, Vol 96, Issue 4
> ******************************************
More information about the aur-general
mailing list