On Monday, January 26, 2015 at 4:31:39 PM UTC+2, jcbollinger wrote:
[snip] > I see three main alternatives: > > 1) Use custom facts to determine the chosen UIDs, and accept that it will > take two runs for your configuration to converge. > > 2) Use an Exec resource around a custom script to manage [the relevant > part of] your auditd configuration. > > 3) Pre-assign the needed UIDs. > > A few additional words about (3): > o As a threshold issue, any ability to pre-assign UIDs depends on having a > reserved range of UIDs on which you can draw. It is conventional on Linux > for the lowest-number UIDs (up to 99 or sometimes 499) to be reserved for > system accounts, which is a reasonable characterization of the accounts in > question, so perhaps you can choose UIDs there. > o Having chosen UIDs, you would use Puppet to manage the corresponding > users. Ensure that each user is managed *before* the corresponding > package, at least when you are ensuring the package present. In all > likelihood, the packages will not create a new account if a suitably-named > one already exists. > o Do test out this approach manually (i.e. that the packages are willing > to use an existing account) before writing Puppet code around it, just to > be sure. > Thank you John. It is a master-less setup, I forgot to mention. This clarifies several misunderstandings I had. Giovanni -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/fb03058b-ec59-42d8-9d41-29046b91329b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
