bug#63082: [PATCH v3 05/16] services: mpd: Obsolete the 'group' field.

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi Liliana,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> Hi Maxim,
>
> Am Sonntag, dem 07.05.2023 um 14:12 -0400 schrieb Maxim Cournoyer:
>> My focus on this series was making sure the configuration is easy(er)
>> to reason with and that it works out of the box for the most part.
> Obsoleting the group field does imho not significantly ease its use.
> It rather makes its non-ootb use harder, because you now have to edit
> two operating-system fields, without changing anything for the ootb
> use.

If you haven't tried that already, I'd like to give you the following
challenge: with the current MPD service, are you able to configure it so
that it works as your user, touching the minimum amount of configuration
switches (as you'd do if you were a new MPD service user getting
started?).

With this series I opinionated on the side that less is better, coming
from the realization that configuring a working MPD was already quite
the challenge (less after this series, if it succeeds at its goal).  In
my opinion, the main two use cases for configuring the services
user/group probably are:

1. you want to run it as an existing user
2. you want it to run as its own user

The defaults cover 2, while for 1 you don't have a need to configure a
group for it, since an existing user will also already have an existing
group (and the <user-account> captures such group).

>> It puts the issue aside; if you can't configure a mismatched group,
>> you can't shoot yourself in the foot.
> No, it doesn't: Since it pulls in the groups field into "stuff you need
> to worry about when editing your MPD service", it actually exacerbates
> the issue.  Yes, the API is awkward, but it does help making mpd-
> service-type self-contained.

The thing is that the 'group' field of mpd-service-type has a default,
which is easy to forget (because it's duplicated from a <user-account>
object and you may reasonably expect the service to default to the
specified user-account's group).  But that's not easy to achieve.  I
tried.

>> I think it's a serious issue because the permissions configured in
>> the start slot may be wrong, and the service could fail to run
>> because of it.
> What is "it" here: the fact that you can make a group with (system? #f)
> or the error in accounts-service-type that has been demoted to a
> warning?

I was thinking about the first one, although 2 would have been a nice
sanity check to avoid ending in a strange state where your existing user
is now in a different group that it ought to, for example.

I hope all this text helps furthering our common understanding :-).

-- 
Thanks,
Maxim