On Jun 24, 9:13 am, Nathan Clemons <nat...@livemocha.com> wrote:
> I'm wondering if the User provider has the capability to look up accounts
> via NIS. It's been a long time since I've used NIS, however, so I don't know
> if this is the problem for sure.

The default provider for RedHat / Fedora / CentOS does not recognize
NIS users.  I don't know about other providers, but I suspect that
most don't recognize them.  I use a custom provider here that assumes
the "compat" scheme for specifying NIS users in /etc/passwd.  If
you're using NIS the other (default) way then no User provider can
manage NIS users because there is no local representation to manage.

With that said, it's not obvious that any User provider is involved at
all.  A provider would come into the mix if you were managing the
"nagios" user itself, but it doesn't look like you're doing that.
Perhaps since user 'nagios' is unmanaged, however, Ssh_authorized_key
is using the default User provider to check for its existence.  That's
not exactly right, but I can't think of anything better.

If it is a provider issue and you're using NIS in the default manner,
then you could perhaps write a simple(-ish) povider that enumerates
existing users without any ability to modify them or create new ones.
You would then add this to your manifest:

user { "nagios":
  provider => "nisuser",
  ensure => "present",
  before => Ssh_authorized_key [ "nagios@login2" ]
}

That's a significant amount of work, however, especially given that it
is not clear whether it would actually solve the problem.  But if
you've been itching to try creating a custom provider then here's an
excuse.


John

-- 
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.

Reply via email to