Re: [aur-general] aur-general Digest, Vol 96, Issue 4

5 Oct 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@archlinux.org> wrote:
...
Send aur-general mailing list submissions to
        aur-general@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@archlinux.org
You can reach the person managing the list at
        aur-general-owner@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@0x01b.net>
To: aur-general@archlinux.org
Subject: Re: [aur-general] [arch-dev-public] [REMINDER] systemd
        conversion
Message-ID: <506DDC49.7050701@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@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
------------------------------
Message: 2
Date: Thu, 4 Oct 2012 21:10:46 +0200
From: Tom Gundersen <teg@jklm.no>
To: Matthew Monaco <dgbaley27@0x01b.net>
Cc: aur-general@archlinux.org
Subject: Re: [aur-general] [arch-dev-public] [REMINDER] systemd
        conversion
Message-ID:
        <CAG-2HqWeX0ivnKVP9sJfXRudk7mePeKCZv1sqU2OMXbdL_qL4w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
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
------------------------------
Message: 3
Date: Thu, 4 Oct 2012 15:12:26 -0400
From: "David J. Haines" <djhaines@gmx.com>
To: "Discussion about the Arch User Repository (AUR)"
        <aur-general@archlinux.org>
Subject: Re: [aur-general] [arch-dev-public] [REMINDER] systemd
        conversion
Message-ID: <20121004191226.GA19662@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@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
------------------------------
Message: 4
Date: Thu, 4 Oct 2012 21:19:00 +0200
From: Tom Gundersen <teg@jklm.no>
To: "Discussion about the Arch User Repository (AUR)"
        <aur-general@archlinux.org>
Subject: Re: [aur-general] [arch-dev-public] [REMINDER] systemd
        conversion
Message-ID:
        <CAG-2HqWG_L-9js0EGPAg3uO495UfyfoGXcnOS-bD6fmtt0KmPA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
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
------------------------------
Message: 5
Date: Thu, 4 Oct 2012 15:24:36 -0400
From: "David J. Haines" <djhaines@gmx.com>
To: "Discussion about the Arch User Repository (AUR)"
        <aur-general@archlinux.org>
Subject: Re: [aur-general] [arch-dev-public] [REMINDER] systemd
        conversion
Message-ID: <20121004192436.GB19662@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@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
------------------------------
Message: 6
Date: Thu, 4 Oct 2012 20:37:37 +0100
From: Leonidas Spyropoulos <artafinde@gmail.com>
To: "Discussion about the Arch User Repository (AUR)"
        <aur-general@archlinux.org>
Subject: Re: [aur-general] [arch-dev-public] [REMINDER] systemd
        conversion
Message-ID:
        <CAAeznTp8DrsMQ8=SRjdjMDurzzm_BR9mrmBLW+bEv1S7=yuw6Q@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
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","\x4c\x65\x6f\x6e\x69\x64\x61\x73");}
------------------------------
Subject: Digest Footer
_______________________________________________
aur-general mailing list
aur-general@archlinux.org
http://mailman.archlinux.org/mailman/listinfo/aur-general
------------------------------
End of aur-general Digest, Vol 96, Issue 4
******************************************

sammahar＠gmail.com

tags

participants (1)