FAQ
Hi all,

I have this problem I can't figure out. I have a very simple define to
deploy SSH keys to certain LDAP users:

define sshkeys::install () {
file{"/home/${title}":
ensure => directory,
owner => "${title}",
group => "ldapgroup",
}
}

which I then call using:

sshkeys::install{["user1","user2","user3"]:}

When I run puppet from the command line works just fine. It creates the
home directories and and deploys the ssh keys (not shown in the example).
However, puppet also runs as a deamon every 30 minutes and this time it
always fails with "Could not find user XXXX". Can you think on any cause
for this?

I'm using puppet 2.7.5 on RH 5.6 with nss_ldap

Thanks

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

Search Discussions

  • Pattryn at May 31, 2012 at 7:36 am
    It seems that it works if "nscd" is running. It'll do me for now...
    On Tuesday, 29 May 2012 10:06:24 UTC+1, pattryn wrote:

    Hi all,

    I have this problem I can't figure out. I have a very simple define to
    deploy SSH keys to certain LDAP users:

    define sshkeys::install () {
    file{"/home/${title}":
    ensure => directory,
    owner => "${title}",
    group => "ldapgroup",
    }
    }

    which I then call using:

    sshkeys::install{["user1","user2","user3"]:}

    When I run puppet from the command line works just fine. It creates the
    home directories and and deploys the ssh keys (not shown in the example).
    However, puppet also runs as a deamon every 30 minutes and this time it
    always fails with "Could not find user XXXX". Can you think on any cause
    for this?

    I'm using puppet 2.7.5 on RH 5.6 with nss_ldap

    Thanks
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/9S4LfxBwz8sJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Jo Rhett at May 31, 2012 at 8:34 pm
    Sounds like you changed nsswitch.conf but haven't restarted puppet daemon. So puppet has no idea how to see those users. VFAQ ;-)
    On May 29, 2012, at 2:06 AM, pattryn wrote:
    I have this problem I can't figure out. I have a very simple define to deploy SSH keys to certain LDAP users:

    define sshkeys::install () {
    file{"/home/${title}":
    ensure => directory,
    owner => "${title}",
    group => "ldapgroup",
    }
    }

    which I then call using:

    sshkeys::install{["user1","user2","user3"]:}

    When I run puppet from the command line works just fine. It creates the home directories and and deploys the ssh keys (not shown in the example). However, puppet also runs as a deamon every 30 minutes and this time it always fails with "Could not find user XXXX". Can you think on any cause for this?

    I'm using puppet 2.7.5 on RH 5.6 with nss_ldap

    Thanks

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/Sm_12va2_aAJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
    --
    Jo Rhett
    Net Consonance : net philanthropy to improve open source and internet projects.



    --
    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+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Pattryn at Jul 18, 2012 at 1:58 pm
    Nope.

    Curiously it works if I enable the nscd daemon but it's not very reliable
    and I would prefer not to use it.

    On Thursday, 31 May 2012 21:33:10 UTC+1, Jo wrote:

    Sounds like you changed nsswitch.conf but haven't restarted puppet daemon.
    So puppet has no idea how to see those users. VFAQ ;-)

    On May 29, 2012, at 2:06 AM, pattryn wrote:

    I have this problem I can't figure out. I have a very simple define to
    deploy SSH keys to certain LDAP users:

    define sshkeys::install () {
    file{"/home/${title}":
    ensure => directory,
    owner => "${title}",
    group => "ldapgroup",
    }
    }

    which I then call using:

    sshkeys::install{["user1","user2","user3"]:}

    When I run puppet from the command line works just fine. It creates the
    home directories and and deploys the ssh keys (not shown in the example).
    However, puppet also runs as a deamon every 30 minutes and this time it
    always fails with "Could not find user XXXX". Can you think on any cause
    for this?

    I'm using puppet 2.7.5 on RH 5.6 with nss_ldap

    Thanks

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


    --
    Jo Rhett
    Net Consonance : net philanthropy to improve open source and internet
    projects.


    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/6O9UIq4pP1IJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Krish at Jul 18, 2012 at 2:09 pm

    On Wed, Jul 18, 2012 at 7:28 PM, pattryn wrote:
    Nope.

    Curiously it works if I enable the nscd daemon but it's not very reliable
    and I would prefer not to use it.

    nscd is kinda required to read your passwd database and such. AFAIK,
    puppet relies on it to read if a user/group exist <-- Can someone
    re-confirm? :)

    If you want to manage nscd, to feel be in control.. you could take a
    look at https://github.com/cernops/puppet-nscd



    --
    Krish
    Hey! Checkout my new startup * www.toonheart.com *
    Like Us if you Like Us! - facebook.com/toonheart

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Jcbollinger at Jul 18, 2012 at 7:09 pm

    On Wednesday, July 18, 2012 9:09:12 AM UTC-5, krish wrote:
    On Wed, Jul 18, 2012 at 7:28 PM, pattryn wrote:
    Nope.

    Curiously it works if I enable the nscd daemon but it's not very reliable
    and I would prefer not to use it.

    nscd is kinda required to read your passwd database and such.

    Not so. Nscd is an entirely optional service. Many people don't use it.
    Some Linux distros don't even install it by default.

    AFAIK,
    puppet relies on it to read if a user/group exist <-- Can someone
    re-confirm? :)
    No, because that's not true either. How Puppet determines which users and
    groups exist depends on which User and Group "providers" are chosen, which
    depends on the OS and the available tools, but nscd is not relevant -- it
    doesn't operate at the level of the system tools Puppet uses.


    John

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/GPJ3lsd21tAJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Jeff Goldschrafe at Dec 12, 2012 at 11:19 pm
    Sorry to be a thread-necromancer, but we're seeing the same problem on a
    tiny subset of our hosts. We saw the problem on a CentOS 5 x86_64 host,
    then it mysteriously went away, and now we're consistently seeing it on a
    CentOS 5 i386 host. As with pattryn, the resource applies successfully when
    run from the command line with *puppet apply*, but does not when Puppet is
    running with *puppet agent -t*. SELinux is in permissive mode. Things work
    fine when nscd is running, but like many CentOS 5 users, we'll never touch
    that thing in production.

    We saw this behavior originally on the 2.7 client, upgraded to the 3.0
    client, and are still seeing the issue.

    Anyone have any ideas?

    -Jeff
    On Wednesday, July 18, 2012 3:09:07 PM UTC-4, jcbollinger wrote:


    On Wednesday, July 18, 2012 9:09:12 AM UTC-5, krish wrote:

    On Wed, Jul 18, 2012 at 7:28 PM, pattryn <pat...@gmail.com <javascript:>>
    wrote:
    Nope.

    Curiously it works if I enable the nscd daemon but it's not very reliable
    and I would prefer not to use it.

    nscd is kinda required to read your passwd database and such.

    Not so. Nscd is an entirely optional service. Many people don't use it.
    Some Linux distros don't even install it by default.

    AFAIK,
    puppet relies on it to read if a user/group exist <-- Can someone
    re-confirm? :)
    No, because that's not true either. How Puppet determines which users and
    groups exist depends on which User and Group "providers" are chosen, which
    depends on the OS and the available tools, but nscd is not relevant -- it
    doesn't operate at the level of the system tools Puppet uses.


    John
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/fDItE2r_wA0J.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Jcbollinger at Dec 13, 2012 at 2:22 pm

    On Wednesday, December 12, 2012 4:44:54 PM UTC-6, Jeff Goldschrafe wrote:
    Sorry to be a thread-necromancer, but we're seeing the same problem on a
    tiny subset of our hosts. We saw the problem on a CentOS 5 x86_64 host,
    then it mysteriously went away, and now we're consistently seeing it on a
    CentOS 5 i386 host. As with pattryn, the resource applies successfully when
    run from the command line with *puppet apply*, but does not when Puppet
    is running with *puppet agent -t*. SELinux is in permissive mode. Things
    work fine when nscd is running, but like many CentOS 5 users, we'll never
    touch that thing in production.

    We saw this behavior originally on the 2.7 client, upgraded to the 3.0
    client, and are still seeing the issue.

    Anyone have any ideas?
    Did you ever have nscd running on the affected system? Nscd is rather
    deeply integrated with the C library, such that depending on how it is
    configured, you may need to restart the system after disabling or
    reconfiguring it.


    John

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedMay 29, '12 at 9:08a
activeDec 13, '12 at 2:22p
posts8
users5
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase