By the way: this was a plain RPM install from puppet's yum repo ( RH EL6). Don't know if this directory permission stuff was intended and has to be manually aligned when using the RPM to run as a master...
Am Montag, 17. März 2014 12:56:33 UTC+1 schrieb bjoern pohl: > > Answering myself :) > Actualle the error message was a bit misleading: > Error: Could not request certificate: Error 400 on SERVER: Permission > denied - /etc/puppet/auth.conf > This was not because of the content IN the auth.conf , it was because of > missing file permissions: the /etc/puppet directory was not readable by the > puppetmaster which runs as the "puppet" user. > Everything solved now :) > > Just one thing unclear: My "danger-mode" auth.conf was in this directory > too, and worked for half a year on the dev system ( where I was able to > reproduce the problem)... strange... > > > > > Am Montag, 17. März 2014 09:45:02 UTC+1 schrieb bjoern pohl: >> >> Hi, >> i've got a strange problem with my server-side /etc/puppet/auth.conf. >> >> The auth.conf is out-of-the-box, so the cert stuff looks basically like >> this: >> >> # allow access to the CA certificate; unauthenticated nodes need this >> # in order to validate the puppet master's certificate >> path /certificate/ca >> auth any >> method find >> allow * >> >> # allow nodes to retrieve the certificate they requested earlier >> path /certificate/ >> auth any >> method find >> allow * >> >> # allow nodes to request a new certificate >> path /certificate_request >> auth any >> method find, save >> allow * >> >> # deny everything else; this ACL is not strictly necessary, but >> # illustrates the default policy. >> path / >> auth any >> >> Now, when a client connects to the server (for the first time, so it >> shoud be the cert request), I get "400 permission denied" for all clients. >> Network connectivity works, no iptables, 8140 is open and when I relax my >> auth.conf to something like this: >> >> path / >> auth any >> allow * >> >> clients can register and everything works. Now, this is nothing I want to >> have in production :) >> >> a debug run with the master ( puppet master --no-daemonize --debug >> --trace --verbose) gives me a lot of information, but not what makes the >> master throw a permission denied. (and especially what rule in the >> auth.conf makes him do so...) >> >> Any idea what might be wrong here? >> >> Master is a 3.4.3. >> >> thanks & best regards, >> Björn >> >> >> >> -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/ead76c8a-66f4-46eb-b01d-bd2bf2f3327f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
