The way to think about getting commands to run during the apply phase is either by using exec resource (which basically don't have a return value so don't allow you to access the data you want) or with providers.
In your example, if you wrote a custom notify provider, then instead of using the generate() method you could have the new provider run the `id` command as part of its functionality, and that could be used in the output. The user resource would be evaluated -> the user resource provider would create the user -> the notify would be evaluated -> the notify provider would run `id` and print the id of the user. The openstack world makes heavy use of custom types & providers for this reason, and I can highly recommend O'Reilly's "Puppet Types and Providers" book to get started. -Hunter On Tue, Jan 27, 2015 at 10:47 PM, Giovanni Torres <git...@gmail.com> wrote: > > > 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 > <https://groups.google.com/d/msgid/puppet-users/fb03058b-ec59-42d8-9d41-29046b91329b%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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/CAJaQvGBxtV_OdedNX4oku33gbv1pmpJeJgqhtoxfV3Pvek3a9w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
