On Monday, July 24, 2017 at 4:33:09 PM UTC-5, William Korb wrote: > > We have a rather non-standard requirement on our Puppet-managed Linux > systems, and I'm trying to figure out if/how Puppet can satisfy it. > [...] > The solution up to now was to use the same UID as generated by WINBIND to > add an entry to /etc/passwd. However, we don't want the encrypted stored > password to exist on every server, so we instead leave out the entry for > /etc/shadow, and WINBIND is smart enough to authenticate the user to AD for > us (and at boot time, the local presence of the oracle entry in /etc/passwd > is sufficient to allow the oracle stack to start properly). > > With that in mind, is there any way to get an "oracle" entry added to > /etc/passwd, create HOME directory and profiles, etc. without also ending > up with an /etc/shadow entry? > >
There is, but not straight out of the box via Puppet's User resource type. By default, Puppet uses the local tools on each machine for managing the properties associated with User resources. On Linux hosts, that generally means the useradd command and its siblings, or perhaps an analogous group of commands, and on systems that use a shadow file (which should be all of them) these commands manage entries in the passwd and shadow files together. Of course, it makes sense that Puppet doesn't serve your use case out of the box, because the setup you are trying to achieve is non-standard for the systems you are configuring. There are several ways you could approach it, among them: 1. Write a custom provider for the User resource type, and employ it to manage your shadow-less user(s) via User resources. This is probably the cleanest to use, but it is unquestionably the most work to implement. 2. Manage the oracle user via a User resource with the default provider, and also ensure via a separate resource that the corresponding line is removed from the shadow file when necessary. The file_line <https://forge.puppet.com/puppetlabs/stdlib#defined-types> resource of the puppetlabs/stdlib module can help with the latter. 3. Manage the passwd line for the oracle user by managing the passwd file directly, for instance by using a File_line instead of a User. Each of those approaches has both advantages and disadvantages. They are listed in descending order of complexity. Were I to choose, and supposing that this one user is a unique special case, I would probably choose (2). It is tremendously easier to do than (1), albeit a bit more complex than (3). Option (2) has the advantages over option (3) that - It will remove the unwanted shadow line if it (or a conflicting one) is added by other means. - It will notice and flag an error if you should happen to add another User resource for the oracle user to your manifest set. - It will be very clear to whomever comes after you (maybe future you) just what you're doing, and that avoiding the shadow line is intentional. John -- 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/ba682525-e651-4219-8a52-05ea5a074c3a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
