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

["Mark Hatle" <mark.hatle@kernel.crashing.org>]

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
> 
> 
> 
> 
>