should recipes not come with their own systemd/user/group info?

should recipes not come with their own systemd/user/group info?

[Robert P. J. Day]

  style question here, but i'm perusing an OE/YP (actually wind river,
but effectively the same thing) layer that was handed to me, and i'm
puzzled by how the internally-written systemd-controlled services are
implemented.

  on the one hand, there are reasonable recipes that each represent
some service to be managed by systemd, and they all install their
executables in the right places and so on. however, rather than each
recipe also providing its own service file, there is a totally
separate recipe (call it "systemd-services.bb") which contains under
its files/ directory dozens and dozens of service files for all of
those recipes, and is responsible for installing all of them.

  in short, someone decided that -- for whatever reason -- all of the
systemd service files should be collected all in one place, and
installed en masse. is this ... normal? i would have thought that it's
the responsibility of each recipe to mannage all the content related
to it, and that would of course include the systemd service file to be
installed for it. i don't know the rationale for this, and it strikes
me as a recipe for disaster in trying to keep all these things synced
up. is there some rationale for doing it this way that i'm unaware
of?

  and closely related, the same trick was used when defining all the
new users and groups that would own these services. rather than each
service looking after itself, there is a recipe file (call it
"new_users_and_groups.bb") which is hundreds of lines of USERADD_PARAM
and GROUPADD_PARAM lines that define precisely (numerically) all the
new user and group accounts to be associated with all sorts of
services, whereupon i ask the same question -- isn't it more typical
that each service look after its own user and group info?

  in this second case, it *might* be that all of these values need to
be hard-coded to be consistent with, i don't know, something else i'm
unaware of, but it still looks strange.

  thoughts? the above actually works for the time being, but it does
seem a but unnatural.

rday

Re: [OE-core] should recipes not come with their own systemd/user/group info?

[Khem Raj]

On Thu, Aug 5, 2021 at 4:01 AM Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>
>
>   style question here, but i'm perusing an OE/YP (actually wind river,
> but effectively the same thing) layer that was handed to me, and i'm
> puzzled by how the internally-written systemd-controlled services are
> implemented.
>
>   on the one hand, there are reasonable recipes that each represent
> some service to be managed by systemd, and they all install their
> executables in the right places and so on. however, rather than each
> recipe also providing its own service file, there is a totally
> separate recipe (call it "systemd-services.bb") which contains under
> its files/ directory dozens and dozens of service files for all of
> those recipes, and is responsible for installing all of them.
>
>   in short, someone decided that -- for whatever reason -- all of the
> systemd service files should be collected all in one place, and
> installed en masse. is this ... normal? i would have thought that it's
> the responsibility of each recipe to mannage all the content related
> to it, and that would of course include the systemd service file to be
> installed for it. i don't know the rationale for this, and it strikes
> me as a recipe for disaster in trying to keep all these things synced
> up. is there some rationale for doing it this way that i'm unaware
> of?

Usually its better to keep them with recipes/components that helps you
with managing multiple devices which may use different packages better
however in many places component owners are not interested in maintaining
the startup or life cycle management of component and its done by some
central platform team and they may create a single component to manage
the device because it fits there workflow because they don't have to go and
commit these scripts to multiple repos etc, I do not encourage such setup
although there could be some policies which could be implemented via
just systemd scripts and they may live together but if it becomes one place
for all unit files perhaps not ideal.

>
>   and closely related, the same trick was used when defining all the
> new users and groups that would own these services. rather than each
> service looking after itself, there is a recipe file (call it
> "new_users_and_groups.bb") which is hundreds of lines of USERADD_PARAM
> and GROUPADD_PARAM lines that define precisely (numerically) all the
> new user and group accounts to be associated with all sorts of
> services, whereupon i ask the same question -- isn't it more typical
> that each service look after its own user and group info?
>
>   in this second case, it *might* be that all of these values need to
> be hard-coded to be consistent with, i don't know, something else i'm
> unaware of, but it still looks strange.
>
>   thoughts? the above actually works for the time being, but it does
> seem a but unnatural.
>

same logic I would say

> rday
>
> 
>

Re: [OE-core] should recipes not come with their own systemd/user/group info?

[Mark Hatle]

On 8/5/21 6:01 AM, Robert P. J. Day wrote:
> 
>   style question here, but i'm perusing an OE/YP (actually wind river,
> but effectively the same thing) layer that was handed to me, and i'm
> puzzled by how the internally-written systemd-controlled services are
> implemented.
> 
>   on the one hand, there are reasonable recipes that each represent
> some service to be managed by systemd, and they all install their
> executables in the right places and so on. however, rather than each
> recipe also providing its own service file, there is a totally
> separate recipe (call it "systemd-services.bb") which contains under
> its files/ directory dozens and dozens of service files for all of
> those recipes, and is responsible for installing all of them.
> 
>   in short, someone decided that -- for whatever reason -- all of the
> systemd service files should be collected all in one place, and
> installed en masse. is this ... normal? i would have thought that it's
> the responsibility of each recipe to mannage all the content related
> to it, and that would of course include the systemd service file to be
> installed for it. i don't know the rationale for this, and it strikes
> me as a recipe for disaster in trying to keep all these things synced
> up. is there some rationale for doing it this way that i'm unaware
> of?

For a 'product' (as in, this is only for one implementation and nobody will ever
re-use it), I've see this type of thing before.  But for anything intended to be
re-used, it's simply broken.

The service files belong with the recipes providing the services.

>   and closely related, the same trick was used when defining all the
> new users and groups that would own these services. rather than each
> service looking after itself, there is a recipe file (call it
> "new_users_and_groups.bb") which is hundreds of lines of USERADD_PARAM
> and GROUPADD_PARAM lines that define precisely (numerically) all the
> new user and group accounts to be associated with all sorts of
> services, whereupon i ask the same question -- isn't it more typical
> that each service look after its own user and group info?

The same is true here, if you are creating a singular product that has a number
of defined users and groups, sure you can do it in a recipe like this.  But it's
not the right way to do it.  Users/groups should be associated with their users.
 If these are just general administrative usages then they COULD be done this
way, but more people do it at image generation time.

>   in this second case, it *might* be that all of these values need to
> be hard-coded to be consistent with, i don't know, something else i'm
> unaware of, but it still looks strange.

If you need to 'adjust' users and groups, you should be using the existing
mechanisms, useradd-staticids for instance.

--Mark

>   thoughts? the above actually works for the time being, but it does
> seem a but unnatural.
> 
> rday
> 
> 
> 
> 
>