I am having the same issue, and am running about the same stack. CentOS 5.5
facter (1.5.8) fastthread (1.0.7) passenger (2.2.15) puppet (2.6.2) puppet-module (0.3.0) rack (1.1.0) rake (0.8.7) stomp (1.1.6) On Tue, Nov 9, 2010 at 2:50 PM, Kent <kentmshu...@gmail.com> wrote: > Patrick, thanks for the speedy reply once again. > > I'm using RHEL5 and Puppet 2.6.1, Passenger 2.2.7, Rack 1.1.0. > > From what I've read in this group and in Puppet Labs docs/wikis, > Debian/Ubuntu users do seem to have an easier time generally than > CentOS/Red Hat :-\ > > Can I pass my command-line options to Puppetmasterd in the config.ru > file? > > -Kent > > On Nov 9, 10:53 am, Patrick <kc7...@gmail.com> wrote: > > On Nov 9, 2010, at 9:34 AM, Kent wrote: > > > > > > > > > > > > > > > > > > > > > > > > > On Nov 8, 11:07 am, Patrick <kc7...@gmail.com> wrote: > > >> On Nov 8, 2010, at 9:10 AM, Kent wrote: > > > > >>> Hi all, > > > > >>> I'm a new puppet user and new to the forum. > > > > >>> I just switched my Puppetmaster to running inside Apache (via > > >>> Passenger). When I make a change to a resource on the master, it > > >>> sometimes takes a given node TWO runs before the master will realize > > >>> the resource has changed and recompile a new catalog version for the > > >>> node. For example, say my puppetmaster is serving configuration > > >>> version '123' to a node. I change the file permissions for a file > > >>> resource that's part of that catalog and then do a puppet run on the > > >>> node. If I'm running with Passenger, the master serves config version > > >>> '123' one more time (the agent makes no changes). The next time I run > > >>> the node's agent, the master compiles new catalog version '456' and > > >>> the agent makes the permission change. > > > > >>> A few items of note: > > > > >>> 1. This is not a problem with all changes to puppet module content. > > >>> For example, if I change the source contents of a file in the 'files' > > >>> directory of a module, the master will notice this immediately and > the > > >>> puppet agent on the node will grab the new file on the first run > > >>> following the change on the master. > > > > >> Fact: > > >> Files sent using "source" aren't part of the catalog. Instead, the > client asks the server for them while the client is using the catalog and > not during the compilation done on the server. > > > > >> Speculation: > > >> I would guess this is because the problem you are having is happening > during the compilation on the server. > > > > >>> 2. At first I thought maybe this was a timing issue (e.g. I was > doing > > >>> the puppet run too quickly after making the resource change) but it's > > >>> not; whether I wait 5 seconds or 5 minutes before making the first > > >>> puppet run, the master still doesn't notice the change. I set the > > >>> 'filetimeout' setting in /etc/puppet/puppet.conf to 0 and it didn't > > >>> help. > > > > >>> Any ideas on what's going on here? (thanks in advance for your help) > > > > > Ahh, Ok, that makes sense. The source files are not part of the > > > manifests, just pointed to by them. > > > > > However, I am still having a problem with changed manifests not > > > getting "noticed" by the Puppetmaster until the second run after it's > > > been changed. This is only a problem when running puppetmaster as a > > > rack app inside Apache. Of course, if I restart Apache it will serve > > > up the most recent manifests on the first puppet run that connects to > > > it, but it would be irritating to have to restart httpd every time I > > > want to make a change to a module/manifest. > > > > > I also tried setting the puppet.conf option 'ignorecache = true' to no > > > avail. (side note: on the "servertype" option in puppet.conf, official > > > documentation still states that the only valid modes are 'webrick' and > > > 'mongrel'. What is the appropriate mode for running with passenger?) > > > > My puppetmaster is working fine and that option isn't set which means > it's defaulting to webrick. > > > > > Final note: The puppetmaster always logs that it has compiled a > > > catalog and expired the cached one, even on the first runs where the > > > new manifest does not yet take effect. (and annoyingly, puppetmaster > > > under passenger now logs to /var/log/messages instead of /var/log/ > > > puppet/puppetmaster.log; > > > > I don't know how to fix this, but this doesn't happen under Ubuntu. > > > > > it seems puppetmaster as a rack application > > > does not look at /etc/sysconfig/puppetmaster - so I can't add options > > > like verbosity, etc.) > > > > Correct. Files in /etc/sysconfig are red when a service starts. When > using passenger, the service is apache and puppetmaster is one of it's > subprocesses. > > > > The equivalent file is config.ru. It's in the folder you specify in the > apache config file. Just do a "find / -name config.ru". > > > > That said, you really shouldn't need to change it if puppetmaster is > managing to startup at all. > > > > > To me, it seems like there needs to be better Puppet Labs > > > documentation on the differences between running Puppetmaster > > > "normally" (e.g. with /etc/init.d/puppetmaster) versus as a Rack > > > application. > > > > What distro are you using? > > > > What version of puppet are you using? (puppet --version) > > > > How did you install puppet? > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com<puppet-users%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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.
