(inline)
On Tue, Mar 04, 2014 at 10:50:34AM -0800, Stephen Ward wrote:
> Hi!
> In our environment servers have admin user accounts created locally by
> puppet. However, we also have accounts (which use the same user name but
> different id) in LDAP/AD etc. This is not normally an issue as most
> servers only use local authorisation.
> However, in a couple of cases servers allow authorisation via other
> sources (think - public file servers and the like). This is an issue when
> users are created or deleted via puppet as puppet will not add a local
> user with the same name as an LDAP one and will try to delete accounts
> that only exist in read only LDAP.
> I know one option would be to change local user names but the scope of
> this change and institutional policy would make this difficult at best, so
> I am looking for other solutions.
Oh dear. I have ungentle advice (gentle advice to follow):
Your institutional policy is incorrect. Maintaining common usernames across
different authentication backends with different userids is a recipe for
failure (my horrible past experience). Be very diligent about documenting these
issues to your management and put the evidence that you've done so somewhere
safe, because when the failure happens you will need the evidence that they've
signed off on this mess.
It seems that puppet uses the default system calls to get user information, so
you will never use standard puppet resource types to manage these mixed users:
[root@mail55c40 puppet]# grep -r getpwnam /usr/lib/ruby/site_ruby/1.8/puppet
/usr/lib/ruby/site_ruby/1.8/puppet/util/posix.rb: when :pw, :user, :passwd;
return :getpwnam
/usr/lib/ruby/site_ruby/1.8/puppet/provider/user/hpux.rb: ent =
Etc.getpwnam(resource.name)
[root@mail55c40 puppet]# grep -r getpwgrp /usr/lib/ruby/site_ruby/1.8/puppet
[root@mail55c40 puppet]# grep -r getgrnam /usr/lib/ruby/site_ruby/1.8/puppet
/usr/lib/ruby/site_ruby/1.8/puppet/util/posix.rb: when :gr, :group; return
:getgrnam
> Another solution would be widespread use of LDAP etc, but this would put
> us in an awkward position if we had to, say, fix an LDAP server not to
> mention other dependancy and complexity issues, also not an option.
> Not managing admin users via puppet is not a viable option.
> Currently I use workarounds (generous name for them):
> * Disable LDAP during commissioning (ie in a separate environment)meaning
> that accounts are created fine, but if we need to add new staff etc then
> this will cause issues.
> * Alter userdel to first check if the UID is less than the smallest
> LDAP/AD assigned UID
> Another option I have considered would to replace the standard user type
> usage to an exec that could do some checking, but even in it's simplest
> form it would be messy. ie instead of
> user {username: ensure=> present;
> otheruser: ensure=>absent;}
> something like:
> exec{usercreate:command=>'/usr/sbin/createuser';
> userdelete:command=>'/usr/sbin/deleteuser';}
> file{/usr/sbin/createuser: content=>"for each member of an ldap
> group/list, Check if user exists in /etc/passwd;if not, find next
> available in range uid and create";
> /usr/sbin/deleteuser: content=>"for each member of an ldap
> group/list, check if user exists in /etc/passwd; if so delete by uid";}
>
> Can anyone suggest a better solution?
Gentler:
Custom providers/types to fit your very custom setup.
And more gentle:
You have a very custom setup, and we've all seen how accrued corporate habit
can override even not-best-just-mediocre practice. Since you already know what
to do (use different userids for local and ldap users) but corporate policy
prohibits the sensible path, it's time to punt.
Prepare alternatives in the standard "it'll cost us, we need to figure out how
much" format, along the lines of:
1) Maintain your current kludge with the risk of problems like you've outlined.
2) Split your usernames into local/ldap.
3) Develop a set of custom providers/types for puppet yourself.
4) Hire puppet labs or another outsourced element to develop custom
providers/types.
Include in each option:
a) risk level of failures
b) ongoing costs of maintaining the desired solution
c) time/money required for each
Then ask your management to figure out how important this is to them in terms
of dollars and risk and see which solution fits best.
Good luck!
**Replicated ldap is easier than you think, especially if you puppetize the
replicas. Check out how Debian bootstraps a cn=config ldap daemon and go from
there.
http://www.openldap.org/doc/admin24/replication.html
> --
> 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 [1]puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
>
> [2]https://groups.google.com/d/msgid/puppet-users/24e69eca-410e-4776-a668-47673306bf92%40googlegroups.com.
> For more options, visit [3]https://groups.google.com/groups/opt_out.
>
> References
>
> Visible links
> 1. mailto:puppet-users+unsubscr...@googlegroups.com
> 2.
> https://groups.google.com/d/msgid/puppet-users/24e69eca-410e-4776-a668-47673306bf92%40googlegroups.com?utm_medium=email&utm_source=footer
> 3. https://groups.google.com/groups/opt_out
--
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/20140304194327.GA19991%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/groups/opt_out.
