Dear Maintainer,

I would like to use "dh-sysuser" in order to clean up my prerm/postinst
scripts.

But I am struggling to apply dh-sysuser in the context of the following
postinst script:
https://git.hack-hro.de/grouprise/grouprise/-/blob/master/debian/grouprise.postinst#L25

A few actions in that specific postinst script rely on the existence of
the user account (e.g. chown for directories).
Thus I would need to move the `#DEBHELPER#` marker to the top of the
postinst script.  But this would lead to related services being
restarted (via the other debhelper snippets) before the directory
permissions are configured.

Maybe it would be desirable to allow dh-sysuser to inject its snippet
into "preinst" instead of "postinst"?

Or maybe my postinst script is just not well designed?

Thank you for your time!

Cheers,
Lars

On Thu, 07 Jan 2021 00:16:08 +0100 Lars Kruse <devel@sumpfralle.de> wrote:


Hi,

Sorry for late response, I've been quite busy.
Quickly looking at your script one thing that you can try is to use an
interface like systemd-tmpfiles or a standalone like opentmpfiles to
to do an equivalent of the following (it should be possible but i'm not
100% sure)

 # protect sensitive content (e.g. database credentials)
    chown "root:$PKG_GROUP" /etc/grouprise/settings.py
    chmod 640 /etc/grouprise/settings.py

    mkdir -p "$DIR_LOGS"
    chown "$PKG_USER:adm" "$DIR_LOGS"

    mkdir -p "$DIR_MEDIA" "$DIR_STATIC"
    chown "$PKG_USER:$PKG_GROUP" "$DIR_MEDIA" "$DIR_STATIC"


Debhelper will handle tmpfiles, so at that point the order should be
correct (and if not i'll fix it). Anyway if you need to perform actions
that are not supported by debhelper your problem can't be solved this
way..

I can think about this, but i likely need a discussion on
Debian Devel first.
Anyway this can happen only after Bullseye release, or maybe in
experimental, but not right now.

Regards,
Lorenzo

On Thu, 07 Jan 2021 00:16:08 +0100 Lars Kruse <devel@sumpfralle.de> wrote:


Hi,

Sorry for late response, I've been quite busy.
Quickly looking at your script one thing that you can try is to use an
interface like systemd-tmpfiles or a standalone like opentmpfiles to
to do an equivalent of the following (it should be possible but i'm not
100% sure)

 # protect sensitive content (e.g. database credentials)
    chown "root:$PKG_GROUP" /etc/grouprise/settings.py
    chmod 640 /etc/grouprise/settings.py

    mkdir -p "$DIR_LOGS"
    chown "$PKG_USER:adm" "$DIR_LOGS"

    mkdir -p "$DIR_MEDIA" "$DIR_STATIC"
    chown "$PKG_USER:$PKG_GROUP" "$DIR_MEDIA" "$DIR_STATIC"


Debhelper will handle tmpfiles, so at that point the order should be
correct (and if not i'll fix it). Anyway if you need to perform actions
that are not supported by debhelper your problem can't be solved this
way..

I can think about this, but i likely need a discussion on
Debian Devel first.
Anyway this can happen only after Bullseye release, or maybe in
experimental, but not right now.

Regards,
Lorenzo

Hi,

I just stumbled across the same problem: Creating a package which
creates a system user and then gives this user ownership of a directory.
Currently this is not possible as the user is created in the postinst
script at the very last point.

The logical approach would be:

- create the system user (preinst)
- install all files and directories ("inst")
- transfer ownership (postinst)

In your last email you said you wanted to discuss this matter on Debian
Devel. So could you please be so kind? I really like the idea of your
package, but currently it does not really help me.

Thank you,

Christopher

Hi Christopher,

Well, you can write your code after the #DEBHELPER# token.. but I guess
this doesn't work for your use case?
Do you have the same problem as Lars -
" move the `#DEBHELPER#` marker  to the top of the postinst script.
But this would lead to related services being restarted (via the other
debhelper snippets) before the directory permissions are configured. "

or there is another use case where the current order does not work?
If you have another example I'm interested in hearing it.

Yeah that was the idea, but then I realized that writing in preinstall
doesn't work with this package design: the preinstall snippet will
call sysuser-helper which is not guaranteed to be installed yet :(

So far I can think of the following:

1. The code can be written entirely in the preinstall but this defeats
 the idea of having the code in a separate binary (sysuser-helper) which
 has drawbacks like this bug but also has other advantages that I would
 like not to give up; maybe there can be a specific option to do this?

2. dh-sysuser can grow an interface similar to systemd-tempfiles but
 less complex and specialized in changing mode and ownership to
 files and dirs and makes sure that the snippet in postinstall is run
 after the creation of the user (I'm not particularly eager to do
 this..)

3. declare that for such cases systemd-tmpfiles is mandatory (but I
 still need to check that the order is correct)

In case 1. is not feasible, do you dislike 2? Would it work for your use
case?

I neglected a bit this package during the last cycle, hopefully I'll
manage to do better in this cycle

Regards,
Lorenzo

Hi,

Exactly. The use case is:

- create a system user
- chown a directory (e.g. for logs)
- start the service

The DEBHELPER token expands into too many tasks including starting the
service which would fail if the directory does not have the correct
permissions.

Yes - same problem.

Ah, because it is an extra package.

The clearest solution to me would be to ship sysuser-helper with the
debhelper package. That would make sure the needed helper script is
already installed and can be called in DEBHELPER - voila!

I also like the idea of putting the code to create a new user into a
separate binary so that all packages which use this method can directly
benefit from it.
includes the optional information which files or directories should get
chown'ed this task could also be taken over by the helper which then
would guarantee the right order of execution.

I still think the best solution would be to include the helper script in
debhelper. Then you would move creating the user in preinst. You could
also add the chown of files and/or directories into postinst. Doing it
this way should enable all package maintainers the maximum flexibility.

But for me options 1 and 2 would also work.

Thank you for your work!

Cheers,

Christopher