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, <[email protected]> wrote: > Send aur-general mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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 <[email protected]> > To: [email protected] > Subject: Re: [aur-general] [arch-dev-public] [REMINDER] systemd > conversion > Message-ID: <[email protected]> > 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 <[email protected]> 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. > [email protected] -------------------------------------------------------- > [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 <[email protected]> > To: Matthew Monaco <[email protected]> > Cc: [email protected] > Subject: Re: [aur-general] [arch-dev-public] [REMINDER] systemd > conversion > Message-ID: > <cag-2hqwex0ivnkvp9sjfxrudk7mepekczv1squ2omxbdl_q...@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Thu, Oct 4, 2012 at 8:58 PM, Matthew Monaco <[email protected]> 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. >> [email protected] -------------------------------------------------------- >> [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" <[email protected]> > To: "Discussion about the Arch User Repository (AUR)" > <[email protected]> > Subject: Re: [aur-general] [arch-dev-public] [REMINDER] systemd > conversion > Message-ID: <[email protected]> > 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 <[email protected]> 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 > [email protected] > > > ------------------------------ > > Message: 4 > Date: Thu, 4 Oct 2012 21:19:00 +0200 > From: Tom Gundersen <[email protected]> > To: "Discussion about the Arch User Repository (AUR)" > <[email protected]> > Subject: Re: [aur-general] [arch-dev-public] [REMINDER] systemd > conversion > Message-ID: > <cag-2hqwg_l-9js0egpag3uo495ufyfogxcnos-bd6fmtt0k...@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Thu, Oct 4, 2012 at 9:12 PM, David J. Haines <[email protected]> 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" <[email protected]> > To: "Discussion about the Arch User Repository (AUR)" > <[email protected]> > Subject: Re: [aur-general] [arch-dev-public] [REMINDER] systemd > conversion > Message-ID: <[email protected]> > 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 <[email protected]> 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 > [email protected] > > > ------------------------------ > > Message: 6 > Date: Thu, 4 Oct 2012 20:37:37 +0100 > From: Leonidas Spyropoulos <[email protected]> > To: "Discussion about the Arch User Repository (AUR)" > <[email protected]> > Subject: Re: [aur-general] [arch-dev-public] [REMINDER] systemd > conversion > Message-ID: > <CAAeznTp8DrsMQ8=SRjdjMDurzzm_BR9mrmBLW+bEv1S7=yu...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Thu, Oct 4, 2012 at 7:27 PM, Tom Gundersen <[email protected]> wrote: >> On Thu, Oct 4, 2012 at 8:16 PM, Tom Gundersen <[email protected]> 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 > [email protected] > http://mailman.archlinux.org/mailman/listinfo/aur-general > > > ------------------------------ > > End of aur-general Digest, Vol 96, Issue 4 > ******************************************
