Re: [Puppet Users] Managing local + LDAP users and groups

2011-06-14 Thread Denmat
Just FYI, I use a fact that checks authconfig --test for ldap enabled. Then I 
exclude my user base create run in puppet based on the existence if this fact. 

For services and apps I include their user account creation in the module 
managing the service. Therefore they are no effected by the ldap fact.

Cheers,
Den
On 15/06/2011, at 3:57, Jacob Helwig  wrote:

> On Tue, 14 Jun 2011 07:45:44 -0700, bradejr wrote:
>> 
>> Our environment (mostly RHEL) uses LDAP for user and group
>> administration. Unfortunately, we have some cases where (broken)
>> software insists on  local users and groups. I'm guessing it's
>> checking the files directly instead of using the proper system calls.
>> 
>> Our current process is to create the local user/group matching the
>> LDAP entries. How are people handling this case? Puppet won't create
>> the user locally, as it sees the user as already existing. We are
>> currently using exec to call the local versions of the commands
>> (luseradd, lusermod, etc), but that's something of a hack and makes
>> for more complex classes. Does anyone have a graceful way to handle
>> this in puppet?
>> 
>> Thanks,
>> Rob
>> 
> 
> Seems like it would be reasonable to make an luseradd provider for the
> user type along the same lines as the existing useradd one.
> 
> Thanks for already opening a ticket for this!
> http://projects.puppetlabs.com/issues/7911
> 
> -- 
> Jacob Helwig

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Managing local + LDAP users and groups

2011-06-14 Thread Jacob Helwig
On Tue, 14 Jun 2011 07:45:44 -0700, bradejr wrote:
> 
> Our environment (mostly RHEL) uses LDAP for user and group
> administration. Unfortunately, we have some cases where (broken)
> software insists on  local users and groups. I'm guessing it's
> checking the files directly instead of using the proper system calls.
> 
> Our current process is to create the local user/group matching the
> LDAP entries. How are people handling this case? Puppet won't create
> the user locally, as it sees the user as already existing. We are
> currently using exec to call the local versions of the commands
> (luseradd, lusermod, etc), but that's something of a hack and makes
> for more complex classes. Does anyone have a graceful way to handle
> this in puppet?
> 
> Thanks,
> Rob
> 

Seems like it would be reasonable to make an luseradd provider for the
user type along the same lines as the existing useradd one.

Thanks for already opening a ticket for this!
http://projects.puppetlabs.com/issues/7911

-- 
Jacob Helwig


signature.asc
Description: Digital signature


RE: [Puppet Users] Managing local + LDAP users and groups

2011-06-14 Thread Kinzel, David

>Our environment (mostly RHEL) uses LDAP for user and group
>administration. Unfortunately, we have some cases where (broken)
>software insists on  local users and groups. I'm guessing it's
>checking the files directly instead of using the proper system calls.
>
>Our current process is to create the local user/group matching the
>LDAP entries. How are people handling this case? Puppet won't create
>the user locally, as it sees the user as already existing. We are
>currently using exec to call the local versions of the commands
>(luseradd, lusermod, etc), but that's something of a hack and makes
>for more complex classes. Does anyone have a graceful way to handle
>this in puppet?

I'm with you on that. My current path is using luseradd to bootstrap the
user, and then let puppet manage it from there (usermod on local+ldap
seems to work fine). Same goes for groups. Solaris is even worse for
this as there isn't (afaik) a 'luseradd' equivalent, so the bootstrap
process would be modifying the files directly and then letting puppet
manage the user from there.

>
>Thanks,
>Rob
>

This email communication and any files transmitted with it may contain 
confidential and or proprietary information and is provided for the use of the 
intended recipient only.  Any review, retransmission or dissemination of this 
information by anyone other than the intended recipient is prohibited.  If you 
receive this email in error, please contact the sender and delete this 
communication and any copies immediately.  Thank you.
http://www.encana.com

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.