Re: [gentoo-user] looking for a couple of systemd units

["Canek Peláez Valdés" <caneko@gmail.com>]

On Tue, Aug 27, 2013 at 10:39 AM,  <covici@ccs.covici.com> wrote:
> Canek Peláez Valdés <caneko@gmail.com> wrote:
>
>> On Tue, Aug 27, 2013 at 9:41 AM,  <covici@ccs.covici.com> wrote:
>> > Canek Peláez Valdés <caneko@gmail.com> wrote:
>> >
>> >> On Tue, Aug 27, 2013 at 2:46 AM,  <covici@ccs.covici.com> wrote:
>> >> > Canek Peláez Valdés <caneko@gmail.com> wrote:
>> >> >
>> >> >> On Tue, Aug 27, 2013 at 1:10 AM,  <covici@ccs.covici.com> wrote:
>> >> >> > Canek Peláez Valdés <caneko@gmail.com> wrote:
>> >> >> >
>> >> >> >> On Mon, Aug 26, 2013 at 11:06 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>> >> >> >> > On Mon, Aug 26, 2013 at 10:52 PM,  <covici@ccs.covici.com> wrote:
>> >> >> >> >> Hi.  I am looking for a couple of systemd units which I have not been
>> >> >> >> >> able to find -- one for mailman and one for innd which is a shell script
>> >> >> >> >> by itself.
>> >> >> >> >>
>> >> >> >> >> Thanks in advance for any suggestions.
>> >> >> >> >
>> >> >> >> > I use this one in production for mailman with Gentoo:
>> >> >> >> >
>> >> >> >> > ----------------------------------------------------------------
>> >> >> >> > [Unit]
>> >> >> >> > Description=Mailman mailing list service
>> >> >> >> > After=network.target
>> >> >> >> >
>> >> >> >> > [Service]
>> >> >> >> > Type=forking
>> >> >> >> > ExecStart=/usr/lib/mailman/bin/mailmanctl -s start
>> >> >> >> > ExecStop=/usr/lib/mailman/bin/mailmanctl stop
>> >> >> >> > User=mailman
>> >> >> >> > Group=mailman
>> >> >> >> >
>> >> >> >> > [Install]
>> >> >> >> > WantedBy=multi-user.target
>> >> >> >> > ----------------------------------------------------------------
>> >> >> >> >
>> >> >> >> > I don't have any for innd.
>> >> >> >>
>> >> >> >> If innd is the one from net-nntp/inn, then the following should work:
>> >> >> >>
>> >> >> >> ----------------------------------------------------------------
>> >> >> >> [Unit]
>> >> >> >> Description=The Internet News daemon
>> >> >> >> Documentation=man:innd(8)
>> >> >> >> ConditionPathExists=/var/run/news
>> >> >> >>
>> >> >> >> [Service]
>> >> >> >> Type=simple
>> >> >> >> ExecStart=/usr/lib/news/bin/rc.news
>> >> >> >> ExecStop=/usr/lib/news/bin/rc.news stop
>> >> >> >> User=news
>> >> >> >> Group=news
>> >> >> >>
>> >> >> >> [Install]
>> >> >> >> WantedBy=multi-user.target
>> >> >> >> ----------------------------------------------------------------
>> >> >> >>
>> >> >> >> If the binary rc.news forks itself (and there is no option to force it
>> >> >> >> to run in the foreground), use Type=forking. The former is preferred
>> >> >> >> over the latter. Also, to guarantee that the directory /var/run/news
>> >> >> >> always is present, add the following to a new file
>> >> >> >> /etc/tmpfiles.d/innd.conf:
>> >> >> >>
>> >> >> >> ----------------------------------------------------------------
>> >> >> >> d    /var/run/news   0755 news news 10d -
>> >> >> >> ----------------------------------------------------------------
>> >> >> >>
>> >> >> >> You can replace 10d with - (hypen), so the directory is never cleaned
>> >> >> >> automatically. If you try this unit and it works as expected, please
>> >> >> >> let us know.
>> >> >> >>
>> >> >> >
>> >> >> > OK, thanks again.  I have one question which this brings up -- and this
>> >> >> > applies to openrc as well -- I never have let it migrate /var/run to
>> >> >> > /run  and /var/lock likewise because I have directories in those which
>> >> >> > are owned by various users, etc. and the packages themselves almost
>> >> >> > never create such -- is putting things in  /etc/tmpfiles.d the correct
>> >> >> > way to fix this?
>> >> >>
>> >> >> tmpfiles.d is from systemd:
>> >> >>
>> >> >> http://www.freedesktop.org/software/systemd/man/tmpfiles.d.html
>> >> >>
>> >> >> However, I think OpenRC developers were thinking about supporting it.
>> >> >> I don't know if that actually happened.
>> >> >>
>> >> >> With systemd in Gentoo, /var/run is bind mounted from /run, and it's a
>> >> >> tmpfs dir, so everything there goes away after a reboot. The config
>> >> >> files in tmpfiles.d allows the creation (and automatic removal) of
>> >> >> directories and files there.
>> >> >>
>> >> >> I don't know if it's the "correct" way to fix anything; but it works.
>> >> >>
>> >> > Can I use the d action to change the permissions of an existing
>> >> > directory and if not, how can I do this?
>> >>
>> >> I don't think so. The contents of /run (and /var/run before it) are,
>> >> by definition, used only at run time. They are not intended to be
>> >> preserved, and they actually should be cleaned from time to time
>> >> (hence the age field in tmpfiles.d). Therefore tmpfiles.d only deals
>> >> with creation (and cleaning up) of files/directories, not "updating"
>> >> them, since they should not be even present when the system boots up.
>> >>
>> >> The files in /etc/tmpfiles.d are used by the systemd-tmpfiles-* units,
>> >> and (AFAIU) they only create files/directories at boot time, and then
>> >> only clean afterwards.
>> >>
>> >> My /run directory is really empty. When my systems boot up, systemd
>> >> mounts a tmpfs on it:
>> >>
>> >> # mount | grep "on /run"
>> >> tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
>> >>
>> >> Then the var-run.mount unit binds mount /run into /var/run. So no
>> >> file/directory there is actually written into any physical disk ever.
>> >
>> > But I need to change the permissions of /var/lock to 777, if I can't use
>> > tmpfiles.d how can I do this?
>>
>> chmod 777 /var/lock? I don't understand the question. What program do
>> you need that requires universal writing access for /var/lock? In my
>> systems, /var/lock is either bind mounted from /run/lock, or a soft
>> link to /run/lock, and /run/lock is root:root and 755.
>>
>
> I need regular users to put files in /var/lock and it is annoying to
> have to change the permissions and so I have it on a file system and
> never need to touch it.

OK; you need to mask var-lock.mount (systemctl mask var-lock.mount),
and then I think you only need to do chmod 777 /var/lock once. Just be
aware that this is not how it should work in systemd, it's not
supported, and any unnecessary world-writable directory is generally a
bad idea.

http://lists.freedesktop.org/archives/systemd-devel/2011-March/001823.html

So, in a few words, if it breaks you get to keep both pieces.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México