New PKGBUILD - Can I make modifications to config, tmpfiles, systemd?

lquidfire · 2024-06-11 08:10:19

Hi all,

I recently wrote a new PKGBUILD for OpenARC. There is also a corresponding Wiki page that I submitted.

As I was attempting to present a perfect package, and while corresponding with someone who is already using the software, I ran into questions that I did not know the answer to. Could you all please provide some light? I did compare this issue with the OpenDKIM packing in the repo, which did not always satisfy my curiosity. Thank you for your help!

I have the following questions:

On Following Upstream: Is the Archlinux way to simply provide upstream software via the AUR, perhaps patched to make it run, but with no modifications? And any modifications can be recommended on the Wiki? Or is it okay to make some modifications to the files (see the next points) and then posting that to the AUR? I am talking about changes to tmpfiles, the systemd unit file (seel below).
How to best create directories with specific user, group, and file permissions?
1. E.g. I would like to create a directory /etc/openarc with user openarc and group openarc and file permissions 0750. Upstream does not have this in the tmpfiles. Should I add it? Is there another way? Or should the Wiki page specify that not only does the dir "need" (one does not have to to make it run, of course) to be created, but then also user group and permissions should be changed (if so desired, I guess)?
2. And what if I wanted to suggest also making a directory /etc/openarc/keys with the same user group and file permissions? Or should this not be mentioned at all, and left to the owner of the system on where they want to store keys, and whether those should be locked down a but with file permissions?
3. Also, I have seen PKGBUILDS that use tmpfiles, and then some use "RuntimeDirectory" in a service file for a particular directory; but that means that some directories/files are created via tmpfiles, and others through the service file, which I think is messy and confusing (the SysAdmin will now have to look in two places to find out what is happening). Is there consensus which should take preference?
Should I change the systemd service file, or - again - only make suggestions on the wiki? The upstream systemd service file is over 9 years old. At first I took my inspiration from the OpenDKIM service file. Then I also looked around at other distro's and came up with some more modifications. My question is: Is it correct to just present these modifications in the AUR package, or should that be suggested in the Wiki?

I am clearly lacking some bigger insight into how to package for Archlinux, hence the confused, all-over-the-place questions. I hope to learn how to do this correctly so that any contributions by me will be helpful.

Thank you for your time and help!

Awebb · 2024-06-11 09:04:26

Opinions:

If you want to provide a specific patch set on the AUR, then let the name reflect that. I personally dislike overly patched software under the base name.
1. Have a look at jellyfin-server in Extra.
2. I can only speak from an AUR user's standpoint, but since all changes you'll make will be transparently visible in the PKGBUILD and permissions are mostly for some sort of hardening, I'd not think twice when reading it.
3. Personal preference again: If it's clearly visible from the PKGBUILD, I'm fine with it. I tried googling for consensus and couldn't find any.
If it doesn't fundamentally change the way the package works and creates unexpected side effects, I'd gladly accept some updated service file.

Trilby · 2024-06-11 12:29:02

1. I share AWebb's opinion, but the AUR guidelines put no constraints on this. Generally, official packages in arch are intended to stay as close to upstream as practical. But there are ample exceptions in the main repo, and for the AUR this standard just doesn't even exist. So you can patch as much as you want, but if any patches change the software's behavior beyond just getting it to run properly in arch linux, then a package-name suffix would be a good idea.

2. Why tmpfiles at all?? If your package should contain an /etc/openarc then you just create the directory under $pkgdir with the proper permissions. tmpfiles are for temp-files: they're freshly created at boot up. If this /etc/openrc is meant to be only temporary and recreated at each boot up, then it really shouldn't be under /etc/ as that directory is meant for static configuration files.

3. Is your service file better? You say there's is old - but that's no reason to change it. If it doesn't work properly, then that is a good reason to change it whether upstream last modified it 9 years ago or 9 hours ago.

lquidfire · 2024-06-11 13:09:36

Thank you, AWebb and Trilby, for your swift replies!

Ad 1) The reason for the patches as introduced with the openarc package on AUR are to avoid build-time warnings (a patch was also submitted to upstream, but they seem very (very!) slow in merging PR's), and to fix some bugs (there are longstanding PR's for those as well by others, but they have not yet been merged).

There are quite a number of other PR's on upstream's github that add features (usually similar to what is available to OpenDKIM, which is by the same author), but I left those out so as not to change the package feature-wise from upstream's OpenARC. I think I will upload a separate package for that (something like "openarc-unofficial-patches"), because they do improve the usability of openarc.

Ad 2) Thank you for pointing out the jellyfin-server PKGBUILD. I have taken some inspiration from it in terms of style and explanatory comments.

Thank you for pointing out that tmpfiles (what's in a name...) is really the wrong tool for creating a directory in /etc.

Incidentally, the jellyfin-server package has the following tmpfiles included (emphasis mine):

d /var/cache/jellyfin 0750 jellyfin jellyfin
d /var/lib/jellyfin 0750 jellyfin jellyfin
d /var/log/jellyfin 0750 jellyfin jellyfin
[b]d /etc/jellyfin 0750 jellyfin jellyfin
f /etc/jellyfin/jellyfin.env 0640 jellyfin jellyfin
f /etc/jellyfin/logging.json 0640 jellyfin jellyfin[/b]

It also has the following lines in the PKGBUILD:

...

# systemd integration
  install -vDm644 jellyfin.service -t "$pkgdir/usr/lib/systemd/system"
  install -vDm644 "$srcdir/sysusers.conf" "$pkgdir/usr/lib/sysusers.d/$_pkgname.conf"
  install -vDm644 "$srcdir/tmpfiles.conf" "$pkgdir/usr/lib/tmpfiles.d/$_pkgname.conf"
  install -vDm640 jellyfin "$pkgdir/etc/$_pkgname/$_pkgname.env"
  install -vDm640 logging.json -t "$pkgdir/etc/$_pkgname"
...

Am I understanding correctly that this is double? I think that the install lines in the PKGBUILD will create the directories and files first, since the tmpfiles will only be run by a pacman hook after the package was installed. Is this correct? Shouldn't the tmpfiles file be amended (remove at least the creation of the directory in /etc)? Or am I missing something?

Ad 3) The changes are to harden the service. However, it also adds a "Restart" line. There is a PR upstream to change the Type from 'forking' to 'simple' to avoid a PID race in some conditions, but this I have not implemented, as I do not know what possible side effects that might have.

The reason for the changes would, in this case, be to improve the service, but not change its working. I think the changes would improve the service file; but it comes back to the original question whether that belongs in the AUR package, or on the Wiki page as a suggestion to each and every local SysAdmin. Both of you answered that there are no guidelines and that, as long as the software does not deviate in terms of behaviour, patches should be fine, so I think I will leave the few hardening improvements to the service file.

Lone_Wolf · 2024-06-11 13:35:20

lquidfire wrote:

Am I understanding correctly that this is double? I think that the install lines in the PKGBUILD will create the directories and files first, since the tmpfiles will only be run by a pacman hook after the package was installed. Is this correct? Shouldn't the tmpfiles file be amended (remove at least the creation of the directory in /etc)? Or am I missing something?

d /etc/jellyfin 0750 jellyfin jellyfin
f /etc/jellyfin/jellyfin.env 0640 jellyfin jellyfin
f /etc/jellyfin/logging.json 0640 jellyfin jellyfin

During building only user root and group root are allowed, as the PKGBUILD has no way to know what other users/groups will exist on the system at install time.
Those 3 lines change owner and group AFTER they have been created (usually through sysusers ).

Trilby · 2024-06-11 13:43:54

Perhaps I am mistaken. This may be the new "systemd" way of doing things. Its an absurdly complex new way of doing something that has always been quite simple - and at that level seems completely absurd - but this is right on par with modern systemd OSs.

lquidfire · 2024-06-11 14:05:51

Oh! I had not considered the timing of the creation of users and groups.

Wouldn't it be easier to create a user and group during prepare(), and then do 'chown' and 'chmod' after creating the directory (I have never seen this, so it can't be right...)? That way the directory would not be ephemeral?

Although, despite the name (tmpfiles), it would seem that if the 'Age' is set to '-', that the directories and files are not ephemeral after all? In fact, the files in my /etc/openarc directory are still there after a reboot; so I don't think that tmpfiles actually re-created that directory upon boot? In that vein: Changing ownership and file permissions on a directory via tmpfiles.d would then not be an ephemeral thing, but persistent as well?

I found the following on the tmpfiles.d(5) man-page:

System daemons frequently require private runtime directories below /run/ to store communication sockets and similar. For these, it is better to use RuntimeDirectory= in their unit files (see systemd.exec(5) for details), if the flexibility provided by tmpfiles.d is not required.
The advantages are that the configuration required by the unit is centralized in one place, and that the lifetime of the directory is tied to the lifetime of the service itself.
Similarly, StateDirectory=, CacheDirectory=, LogsDirectory=, and ConfigurationDirectory= should be used to create directories under /var/lib/, /var/cache/, /var/log/, and /etc/.
tmpfiles.d should be used for files whose lifetime is independent of any service or requires more complicated configuration.

So, the folks at Systemd seem to think that mostly all configuration should be in the unit files (at least it would be in one place!), but that anything that should outlive the service itself, should be done via tmpfiles.d.

From systemd.exec(5):

In case of RuntimeDirectory= the innermost subdirectories are removed when the unit is stopped. It is possible to preserve the specified directories in this case if RuntimeDirectoryPreserve= is configured to restart or yes (see below). The directories specified with StateDirectory=, CacheDirectory=, LogsDirectory=, ConfigurationDirectory= are not removed when the unit is stopped.
...
tmpfiles.d(5) provides functionality that overlaps with these options. Using these options is recommended, because the lifetime of the directories is tied directly to the lifetime of the unit, and it is not necessary to ensure that the tmpfiles.d configuration is executed before the unit is started.

I feel like I need a walk to wrap my head around this and will go make a cup of tea!

Trilby · 2024-06-11 14:13:21

tmpfiles, if configured properly, can change the ownership of files / directories which seems to be what you are looking for. But those directories should already be created by the package itself. It seems this may be the "proper" way to do this now on systemd OSs.

Arch Linux

#1 2024-06-11 08:10:19

New PKGBUILD - Can I make modifications to config, tmpfiles, systemd?

#2 2024-06-11 09:04:26

Re: New PKGBUILD - Can I make modifications to config, tmpfiles, systemd?

#3 2024-06-11 12:29:02

Re: New PKGBUILD - Can I make modifications to config, tmpfiles, systemd?

#4 2024-06-11 13:09:36

Re: New PKGBUILD - Can I make modifications to config, tmpfiles, systemd?

#5 2024-06-11 13:35:20

Re: New PKGBUILD - Can I make modifications to config, tmpfiles, systemd?

#6 2024-06-11 13:43:54

Re: New PKGBUILD - Can I make modifications to config, tmpfiles, systemd?

#7 2024-06-11 14:05:51

Re: New PKGBUILD - Can I make modifications to config, tmpfiles, systemd?

#8 2024-06-11 14:13:21

Re: New PKGBUILD - Can I make modifications to config, tmpfiles, systemd?

Board footer