Ryan Dooley
2007-May-17 22:12 UTC
Puppet not honoring alternate path to namespaceauth.conf
Greetings, I''ve two questions for y''all. 1) I''ve setup an alternate installation path for puppet in a site local directory outside of ''the usual places''. Puppetd seems to insist that /etc/puppet/namespaceauth.conf exists despite setting :authconfig in both puppet and puppetd. As a result part of my installation now includes a symlink to point /etc/puppet at the new installation root /foo/conf/puppet. Any ideas why that would be? 2) Despite having a symlink in place from #1, evertime puppet runs, it unlinks /etc/puppet and recreates this as an actual directory. Now for some facts behind the install: This is the gem installation at version 0.22.4 My default class does manage files for /foo/conf/puppet/* to make sure we''re consistent. Verbose and debugging output right before puppet fails looks like this: info: Starting handler for Runner info: Starting server for Puppet version 0.22.4 info: Listening on port 8139 notice: Starting Puppet client version 0.22.4 info: Facts have changed; recompiling info: Caching configuration at /foo/var/lib/puppet/localconfig.yaml notice: Starting configuration run notice: //default/bmc/Exec[enable-alt-sysrq]/returns: executed successfully notice: Reparsing /etc/puppet/puppetd.conf Any clues? Cheers, Ryan
Ryan Dooley
2007-May-17 22:28 UTC
Re: Puppet not honoring alternate path to namespaceauth.conf
I''ve been able to work around things by specifying all the puppet and puppetd options on the command line. That works for now even it if it seems a little heavy handed (that''s what config files are for ;-) I''ll see if I can figure out why things are not being honored next week (deadlines and all) Cheers, Ryan> I''ve two questions for y''all. > > 1) I''ve setup an alternate installation path for puppet in a site local > directory outside of ''the usual places''. Puppetd seems to insist that > /etc/puppet/namespaceauth.conf exists despite setting :authconfig in both > puppet and puppetd. > > As a result part of my installation now includes a symlink to point > /etc/puppet at the new installation root /foo/conf/puppet. > > Any ideas why that would be? > > 2) Despite having a symlink in place from #1, evertime puppet runs, it > unlinks /etc/puppet and recreates this as an actual directory. > > Now for some facts behind the install: > > This is the gem installation at version 0.22.4 > > My default class does manage files for /foo/conf/puppet/* to make sure we''re > consistent. > > Verbose and debugging output right before puppet fails looks like this: > > info: Starting handler for Runner > info: Starting server for Puppet version 0.22.4 > info: Listening on port 8139 > notice: Starting Puppet client version 0.22.4 > info: Facts have changed; recompiling > info: Caching configuration at /foo/var/lib/puppet/localconfig.yaml > notice: Starting configuration run > notice: //default/bmc/Exec[enable-alt-sysrq]/returns: executed successfully > notice: Reparsing /etc/puppet/puppetd.conf > > Any clues?
Luke Kanies
2007-May-18 01:22 UTC
Re: Puppet not honoring alternate path to namespaceauth.conf
On May 17, 2007, at 5:28 PM, Ryan Dooley wrote:> I''ve been able to work around things by specifying all the puppet and > puppetd options on the command line. That works for now even it if > it seems > a little heavy handed (that''s what config files are for ;-) > > I''ll see if I can figure out why things are not being honored next > week > (deadlines and all)If that''s fixing it, then it seems likely that the config file is getting parsed after the value you''re talking about is being used, so you''ve got some kind of race condition. I''ll look at it tomorrow. -- I can win an argument on any topic, against any opponent. People know this, and steer clear of me at parties. Often, as a sign of their great respect, they don''t even invite me. -- Dave Barry --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Luke Kanies
2007-May-21 18:16 UTC
Re: Puppet not honoring alternate path to namespaceauth.conf
On May 17, 2007, at 6:12 PM, Ryan Dooley wrote:> Greetings, > > I''ve two questions for y''all. > > 1) I''ve setup an alternate installation path for puppet in a site > local > directory outside of ''the usual places''. Puppetd seems to insist that > /etc/puppet/namespaceauth.conf exists despite setting :authconfig > in both > puppet and puppetd. > > As a result part of my installation now includes a symlink to point > /etc/puppet at the new installation root /foo/conf/puppet. > > Any ideas why that would be?As I mentioned earlier, this sounds like some kind of race condition between parsing the config files and setting the cli parameters, but I can''t think of where the race is. Does this fail on the first startup, or only when the files are reparsed? The usage of the authconfig file comes significantly after the main config file is parsed, so it seems like it should work fine. I just tested, and the puppetd in svn (which is similar to but not exactly the same as the released puppetd) seems to work fine if I set authconfig differently in puppet.conf (in the puppetd section; see the config consolidation stuff).> 2) Despite having a symlink in place from #1, evertime puppet runs, it > unlinks /etc/puppet and recreates this as an actual directory.Puppet does what it can to make sure it''s always able to run. Part of this is making sure that all of its directories exist. There''s no good compromise between allowing you to do what you want to these dirs/files and enabling Puppet to make itself able to run, so the best option is to use the defaults whenever possible. If you don''t want to do that, the only good option I know of is to set confdir on the cli on each run. I could possibly look at finding a way to make sure the config file is parsed before anything happens, but you''re always going to have race conditions then, as you do now. I''m unlikely to spend much time on this without the work being funded, since I think it''s kind of a bad idea. I''m no DJB, but defaults are good.> info: Starting handler for Runner > info: Starting server for Puppet version 0.22.4 > info: Listening on port 8139 > notice: Starting Puppet client version 0.22.4 > info: Facts have changed; recompiling > info: Caching configuration at /foo/var/lib/puppet/localconfig.yaml > notice: Starting configuration run > notice: //default/bmc/Exec[enable-alt-sysrq]/returns: executed > successfully > notice: Reparsing /etc/puppet/puppetd.confAre you using puppetd.conf, or is that value getting reset somehow? Does the failure only happen on reparsing? -- Measure with a micrometer. Mark with chalk. Cut with an axe. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Ryan Dooley
2007-May-21 19:51 UTC
Re: Puppet not honoring alternate path to namespaceauth.conf
Any ideas why that would be?> > As I mentioned earlier, this sounds like some kind of race condition > between parsing the config files and setting the cli parameters, but > I can''t think of where the race is. Does this fail on the first > startup, or only when the files are reparsed? The usage of the > authconfig file comes significantly after the main config file is > parsed, so it seems like it should work fine.On startup. Right now my invocation from a modified init script looks like this: /foo/bin/puppetd --server=puppetmaster --listen --authconfig /foo/conf/puppet --ssldir /foo/conf/puppet/ssl --vardir /foo/var/lib/puppet --classfile /foo/conf/puppet/classes.txt --rundir /foo/var/run/puppet> I just tested, and the puppetd in svn (which is similar to but not > exactly the same as the released puppetd) seems to work fine if I set > authconfig differently in puppet.conf (in the puppetd section; see > the config consolidation stuff).*nod* ... Hmm. Okay, I''ll have to try it again when I get a test master and client I can abuse.> I could possibly look at finding a way to make sure the config file > is parsed before anything happens, but you''re always going to have > race conditions then, as you do now. I''m unlikely to spend much time > on this without the work being funded, since I think it''s kind of a > bad idea. I''m no DJB, but defaults are good.That sounds like a good plan, load the defaults, parse the site''s puppetd.conf that has the overrides from the defaults and then start do useful things.>> info: Starting handler for Runner >> info: Starting server for Puppet version 0.22.4 >> info: Listening on port 8139 >> notice: Starting Puppet client version 0.22.4 >> info: Facts have changed; recompiling >> info: Caching configuration at /foo/var/lib/puppet/localconfig.yaml >> notice: Starting configuration run >> notice: //default/bmc/Exec[enable-alt-sysrq]/returns: executed >> successfully >> notice: Reparsing /etc/puppet/puppetd.conf > > Are you using puppetd.conf, or is that value getting reset somehow?At present, I''m not relying on puppetd.conf getting parsed (see that command line above).> Does the failure only happen on reparsing?So far that''s the only time I''ve seen it. Cheers, Ryan
Luke Kanies
2007-May-21 20:07 UTC
Re: Puppet not honoring alternate path to namespaceauth.conf
On May 21, 2007, at 3:51 PM, Ryan Dooley wrote:> > On startup. Right now my invocation from a modified init script > looks like > this: > > /foo/bin/puppetd --server=puppetmaster --listen --authconfig > /foo/conf/puppet --ssldir /foo/conf/puppet/ssl --vardir /foo/var/ > lib/puppet > --classfile /foo/conf/puppet/classes.txt --rundir /foo/var/run/puppetI don''t think anything in this process has changed since the release of 0.22.4, so I can''t see why it''s failing for you but not for me. Looks like you''re specifying a directory for the authconfig; is that right?>> I could possibly look at finding a way to make sure the config file >> is parsed before anything happens, but you''re always going to have >> race conditions then, as you do now. I''m unlikely to spend much time >> on this without the work being funded, since I think it''s kind of a >> bad idea. I''m no DJB, but defaults are good. > > That sounds like a good plan, load the defaults, parse the site''s > puppetd.conf that has the overrides from the defaults and then > start do > useful things.For the record, this is basically what I''m doing, it''s just that I can''t necessarily guarantee that absolutely nothing is done before the config is parsed. If you look at puppetd, you''ll see that it parses its config right after the CLI options are set, and before anything at all is done.> At present, I''m not relying on puppetd.conf getting parsed (see > that command > line above).Maybe you''re the only one resetting the value of authconfig and maybe it''s weird in some way, but I don''t think it''s different than the others, which makes me think there''s something we''re missing.>> Does the failure only happen on reparsing? > > So far that''s the only time I''ve seen it.It happens on startup, or on reparsing? Above you say it happens on startup, I thought. -- If computers get too powerful, we can organize them into a committee -- that will do them in. -- Bradley''s Bromide --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Ryan Dooley
2007-May-21 22:46 UTC
Re: Puppet not honoring alternate path to namespaceauth.conf
On 5/21/07 1:07 PM, "Luke Kanies" <luke@madstop.com> wrote:> On May 21, 2007, at 3:51 PM, Ryan Dooley wrote: >> >> On startup. Right now my invocation from a modified init script >> looks like >> this: >> >> /foo/bin/puppetd --server=puppetmaster --listen --authconfig >> /foo/conf/puppet --ssldir /foo/conf/puppet/ssl --vardir /foo/var/ >> lib/puppet >> --classfile /foo/conf/puppet/classes.txt --rundir /foo/var/run/puppet > > I don''t think anything in this process has changed since the release > of 0.22.4, so I can''t see why it''s failing for you but not for me. > > Looks like you''re specifying a directory for the authconfig; is that > right?Correct. That was the only way I could get it to work. Even though puppetd.conf has a path to namespaceauth.conf, the install insisted on looking in /etc/puppet and wouldn''t start otherwise.> > Maybe you''re the only one resetting the value of authconfig and maybe > it''s weird in some way, but I don''t think it''s different than the > others, which makes me think there''s something we''re missing.I''m crazy like that :-D I agree, I''m missing something here.> It happens on startup, or on reparsing? Above you say it happens on > startup, I thought.I thought I did say only startup. It''s only start up. Cheers, Ryan
Luke Kanies
2007-May-24 15:43 UTC
Re: Puppet not honoring alternate path to namespaceauth.conf
On May 21, 2007, at 5:46 PM, Ryan Dooley wrote:>> Looks like you''re specifying a directory for the authconfig; is that >> right? > > Correct. That was the only way I could get it to work. Even though > puppetd.conf has a path to namespaceauth.conf, the install insisted on > looking in /etc/puppet and wouldn''t start otherwise.Right, but what I mean is, authconfig should point to a file, not a directory, but your example had --authconfig /etc/puppet, which is a directory, not a file. Was that just a typoed example? -- That was just a drill of the emergency y2k system. Had this been a real emergency, we would''ve also dumped a bucket of spiders on you and yelled out "civilization is collapsing!" --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com