On Thursday, October 5, 2017 at 1:45:59 PM UTC-4, Ryan Whitehurst wrote:
>
> On Thu, Oct 5, 2017 at 10:35 AM, James Perry <jjpe...@gmail.com
> <javascript:>> wrote:
>
>> I'm using the saz/sudoers as well and it removes, say ERPM10-20, when I
>> remove the user from the host, exactly as expected.
>>
>> What doesn't happen is the user ERPM10-20 isn't removed from the server.
>>
>> Let me try to see if I can put it another way to make it clearer.
>>
>> Say I have ERPM01-01, ERPM01-22 and ERPM02-09 defined. Here is a scenario.
>>
>> Server Mapping:
>> ERPM01-01: servera, serverb, serverc
>> ERPM01-22: servera, serverc
>> ERPM02-09: serverb, serverc
>>
>> ERPM User mapping to ERPM accounts based on AD credentials to access
>> ERPM.
>>
>> ERPM01-01: Foo
>> ERPM01-22: Bar
>> ERPM02-09: Baz
>>
>> So to get access to servera, serverb or serverc, Foo logs into ERPM with
>> AD credentials. Then ERPM's hosting server then handles providing the
>> username (ERPM01-01) to the host and the password. Foo never knows the
>> password so they can't ever access the account outside of ERPM.
>>
>> Now Baz was supporting a DB on serverc, but is moved to another team. We
>> get a request to remove ERPM02-09 from serverc.
>>
>> In Foreman we go to the host, pull that class off serverc. Since Baz is
>> still on serverb, we can't set ensure => absent on the Puppet user block in
>> class ERPM02-09 as that will lock him out of serverb. When Puppet runs on
>> serverc the sudoers module removes the sudoers.d/erpm02-09.conf file.
>>
>> Unfortunately the user ERPM02-09 is still on the host.
>>
>> What I wanted to code up would be to iterate through the ERPMXX-YY
>> classes to see if any of the classes are absent. If so it then calls a user
>> block to do ensure => absent for ERPM02-09 on serverc and servera while
>> serverb will still have the user and sudoers definitions.
>>
>>
> If you're managing all the non-system users with puppet, you can use the
> resources type with purge, something like
>
> resources { 'user':
> purge => true,
> unless_system_user => true,
> }
>
> See https://docs.puppet.com/puppet/latest/types/resources.html
>
>
I looked at that as an option, but we have users on the server that aren't
managed by puppet.
> What I don't know how to do is to find where I can access the Puppet state
>> for classes which are absent.
>>
>>
> You can't, at least not safely or reliably. If you can't use the resources
> type with purge, the other option would be to have an "ensure" parameter on
> the class which propagates down to the underlying user resource and instead
> of removing the class, set that parameter to absent.
>
This was one option I looked into this via a class parameter that would be
overridden on the hosts were the class was assigned, but with 200+ hosts,
that became tedious and error prone.
>
>> I hope this is a better explanation of what I'm trying to do here.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to puppet-dev+...@googlegroups.com <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/puppet-dev/bac6a93f-c2b8-4ad7-b8c4-c8fda5383df3%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/puppet-dev/bac6a93f-c2b8-4ad7-b8c4-c8fda5383df3%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
Thanks for the input. I guess I'm back to my original thoughts of making a
script that looks for all ERPM* user accounts to check them against the
puppet resource user output. Any that don't have a resource entry are
removed from the host.
The overrides work, but don't scale up well.
As these hosts are using ERPM for user access compliance audits, I need to
work out a way to clean that specific set out without squishing any other
users. I had hoped get lucky and find there was a hidden way to trigger
puppet to do specific actions when a class is no longer present on the next
time compiles the catalog.
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/46730062-3d19-4752-b3be-4d95c65223a2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
