On 18/05/16 08:41, David Lang wrote:
On Wed, 18 May 2016, John Crispin wrote:
On 18/05/2016 09:04, David Lang wrote:
The first question I would have is if we are going to the system users
in an essentially random order (as needed so two systems with the same
packages installed in a different order have different user->uid
mapping) or if we are going to define service accounts distro wide so
they are always going to be the same.
what would be the pros and cons for either of those ?
If you have static user allocations then LEDE needs to maintain a
central repository of userids and a way for applications to be
registered with it.
If you have dynamic user allocations, then the package installer
scripts need to have more complexity to request the userids on the fly
and make everything they install have the correct permissions. (most
distros take this approach)
In the case of LEDE, we generally aren't running install scripts for
the packages on a running system, all this happens at compile time
when you don't have a way to run various tools to lookup and allocate
users and set the file permissions, so I think there's a good argument
that the static allocation approach would work better here.
The other place where this bites people is when they have multiple
systems that then need to start working together (mounting a network
drive and sharing info, think high availability and similar, or
copying files from one system to another and trying to use them
there). The 'normal' answer is that you then need to start managing
users with some new tool (Chef, Puppet, Ansible, Salt, etc) that
pre-allocates the users onto the systems before the install scripts
run and/or overrides the package defaults.
As I say, the common choice is dynamically allocated uids, but lede
has to do this at compile/image creation time instead of on a running
system.
I believe that during the root filesystem generation, scripts are run
and some information is available. Dependencies and ordering may be an
issue.
Conor
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
