Hi folks I''m checking puppet out on a gentoo test box at this point, using the same box for both client and server. Looking through the docs, I see that the manifests are to be located (by default) in /etc/puppet/manifests; so far so good. I have added the recommended bare bones manifests to just see what is going on, setting it up such that there is a sudo class that indicates permissions on sudoers should be 0440. After manually changing the permissions on sudoers to 0640, and restarting both the puppetmasterd and puppetd services, I expected to see the permissions change back to 0440. They did not, after a good 10 minute wait. Evidently, I am missing something, but all I am able to turn up in the dcoumentation (thorough though much of it is) is a whole slew of potential manifest recipes, etc. I can''t seem to find any indication of how frequently puppet should kick off and check against what the server thinks should be there, or any difference between pupptd and puppetmasterd config files (i.e. which ones are which, so that I know what should be impacted when I make a change, etc.) Can anybody help me out and point me in the right direction? Thanks! --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Once puppet is running on clients, they will check against the central server every 30 minutes, so you''ll have to wait a little longer! On Mon, Jul 28, 2008 at 2:26 PM, Justin <rjustinwilliams@gmail.com> wrote:> > Hi folks > > I''m checking puppet out on a gentoo test box at this point, using the > same box for both client and server. > > Looking through the docs, I see that the manifests are to be located > (by default) in /etc/puppet/manifests; so far so good. > > I have added the recommended bare bones manifests to just see what is > going on, setting it up such that there is a sudo class that indicates > permissions on sudoers should be 0440. > > After manually changing the permissions on sudoers to 0640, and > restarting both the puppetmasterd and puppetd services, I expected to > see the permissions change back to 0440. They did not, after a good > 10 minute wait. Evidently, I am missing something, but all I am able > to turn up in the dcoumentation (thorough though much of it is) is a > whole slew of potential manifest recipes, etc. I can''t seem to find > any indication of how frequently puppet should kick off and check > against what the server thinks should be there, or any difference > between pupptd and puppetmasterd config files (i.e. which ones are > which, so that I know what should be impacted when I make a change, > etc.) > > Can anybody help me out and point me in the right direction? > > Thanks! > > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Bless you! That''s one part I have been missing... patience is another... Running puppet -v /etc/puppet/manifest/site.pp, all works as it should, so, I can only hope that it will continue to work on its timed schedule. Thank you & will keep you posted on it! On Jul 28, 3:01 pm, "Ashley Penney" <apen...@gmail.com> wrote:> Once puppet is running on clients, they will check against the central > server every 30 minutes, so you''ll have to wait a little longer! > > On Mon, Jul 28, 2008 at 2:26 PM, Justin <rjustinwilli...@gmail.com> wrote: > > > Hi folks > > > I''m checking puppet out on a gentoo test box at this point, using the > > same box for both client and server. > > > Looking through the docs, I see that the manifests are to be located > > (by default) in /etc/puppet/manifests; so far so good. > > > I have added the recommended bare bones manifests to just see what is > > going on, setting it up such that there is a sudo class that indicates > > permissions on sudoers should be 0440. > > > After manually changing the permissions on sudoers to 0640, and > > restarting both the puppetmasterd and puppetd services, I expected to > > see the permissions change back to 0440. They did not, after a good > > 10 minute wait. Evidently, I am missing something, but all I am able > > to turn up in the dcoumentation (thorough though much of it is) is a > > whole slew of potential manifest recipes, etc. I can''t seem to find > > any indication of how frequently puppet should kick off and check > > against what the server thinks should be there, or any difference > > between pupptd and puppetmasterd config files (i.e. which ones are > > which, so that I know what should be impacted when I make a change, > > etc.) > > > Can anybody help me out and point me in the right direction? > > > Thanks!--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
2008/7/28 Justin <rjustinwilliams@gmail.com>:> > Hrm... no joy... > > Had it running since 15:07 local, and still none of the expected > results. Of course, I have had, apparently, 3 or 4 instances of > puppetd running side by side, so, that might account for something; > not sure what but something...Multiple puppets running simultaneously -can- clash on the lock file, but one of them should win. I assume you''re using the node default {} syntax to do the sudoer testing. On the target machine (which could be the puppetmaster), use puppetd --test --noop and see what happens. --test gives you a bit of debug output, --noop stops anything from actually happening. --debug engages more client-side debugging. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
That pinpointed the problem; thank you! The puppet was looking for a machine called "puppet" to be the puppetmaster. I re-ran puppetd with the --server option specifying localhost, and it was happy as a clam. Now I get to hunt up where to make that a permament change... Thanks again! On Jul 29, 4:21 am, "Duncan Hill" <bajand...@googlemail.com> wrote:> 2008/7/28 Justin <rjustinwilli...@gmail.com>: > > > > > Hrm... no joy... > > > Had it running since 15:07 local, and still none of the expected > > results. Of course, I have had, apparently, 3 or 4 instances of > > puppetd running side by side, so, that might account for something; > > not sure what but something... > > Multiple puppets running simultaneously -can- clash on the lock file, > but one of them should win. > > I assume you''re using the node default {} syntax to do the sudoer testing. > > On the target machine (which could be the puppetmaster), use puppetd > --test --noop and see what happens. --test gives you a bit of debug > output, --noop stops anything from actually happening. --debug > engages more client-side debugging.--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
It''s official; I''m a doofus... I never noticed the one-line difference between the puppetmaster''s puppet.conf file and the puppet''s puppet.conf file as found on http://gentoo-wiki.com/Puppet. Adding the "server=localhost" line to puppet.conf made the difference. Presumably, puppetmaster will recognize itself as localhost, and not confuse itself by having what it is likely to consider an unnecessary line in the config file, but, worth asking those of you who have been using puppet for more than 24 hours... ;-) On Jul 29, 4:21 am, "Duncan Hill" <bajand...@googlemail.com> wrote:> 2008/7/28 Justin <rjustinwilli...@gmail.com>: > > > > > Hrm... no joy... > > > Had it running since 15:07 local, and still none of the expected > > results. Of course, I have had, apparently, 3 or 4 instances of > > puppetd running side by side, so, that might account for something; > > not sure what but something... > > Multiple puppets running simultaneously -can- clash on the lock file, > but one of them should win. > > I assume you''re using the node default {} syntax to do the sudoer testing. > > On the target machine (which could be the puppetmaster), use puppetd > --test --noop and see what happens. --test gives you a bit of debug > output, --noop stops anything from actually happening. --debug > engages more client-side debugging.--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---