You’ll probably find numerous links that tell you to delete
/var/lib/puppet/yaml/[fqdn].yaml
in puppetmaster, node or both.
None of those solved my problem.
Upgradeing to puppet-2.7.25 didn’t help either .
On my puppet client, in /var/lib/puppet deleting
rm -fr state/ lib/ facts/ client*
at least let me run puppet again, but next run gives that 400 error again …
note to self: get back to this post when I get time to further debugging this really annoying issue
As a kind of followup on my previous post, I’ve been increasingly annoyed by how puppet agent update on my Centos hosts takes a looong time. F.example I’m up in 120 seconds for my LAMP puppet profiles.
I suspected yum to be the slowdown, but my previous post from today gave me a hint that maybe puppet does something IPv6’ish stuff too .
I had a look at
# tcpdump -vvvvv 'port 53'
while doing a puppet update, and I see a lot of:
[myhostname].42349 > ns1.[mydomain].domain: [bad udp cksum 5599!] 18560+ AAAA? puppet.[mudomain]. (36)
15:09:33.326822 IP (tos 0x0, ttl 64, id 61459, offset 0, flags [none], proto UDP (17), length 133)
ns1.[mydomain].domain > [myhostname].42349: [udp sum ok] 18560 q: AAAA? puppet.[mydomain]. 0/1/0 ns: [mydomain]. [50m40s] SOA ns1.[my SOA]. hostmaster.[my SOA]. 1378837114 14400 3600 777600 3600 (105)
So those AAAA request does indeed look like some IPv6 lookups are happening.
Looking at the resolv.conf man page, and with help from wiki.echochat.org I tried adding to
resolv.conf:
[...] options single-request-reopen [...]
and suddenly puppet agent update took roughly 3 seconds, instead of 120 seconds …
Cool ! 🙂
I’ve got some perl webapps that tend to have ‘wrong’ directory setup when I checkout the code from github. We use puppet to take care of these things for us (I will always forget these settings on at least 1 node for every upgrade) .
I noticed puppet may complain about :
[...]ensure: change from directory to link failed: Could not remove existing file
You solve this easily with the:
force => true
directive in your puppet config .
The puppet documentation is extensive, though I find it a bit cumbersome everytime I need a fast lookup for some minor detail.
Thanks to groups.google.com I found this solution quick !
(But puppet already tried to tell me that with : “: Not removing directory; use ‘force’ to override”, but I’m slow :p)
I recently noticed a puppet managed server installed a package that wasn’t supposed to be available …
The thing is, we’re running Tinderbox to build our own packages from ports, it’s kind of normal when using FreeBSD and it’s ‘rolling release, source based software package system (ports)’ .
Anyway, we’ve setup all servers with a global PACKAGESITE variable pointing to our local repo, so that pkg_add and portmaster will pull packages from there.
We distribute config files and so on via puppet, and what happened was that when running puppet initially it will push out the global /etc/csh.cshrc config which contains the magic PACKAGESITE setup, but at the same time it will start installing a bunch of packages without actually source’ing the /etc/csh.cshrc … So actually PACKAGESITE is empty the first time puppet runs, and that means pkg_add will default to the official FreeBSD packagesite …
This is not how I want it, because for instance a FreeBSD 8.3-RELEASE with an empty PACKAGESITE will pull packages from a spesific ports ‘freeze’ around the 8.2-RELEASE, and that’s a long time ago today … Next time I install any extra packages on that system, it’ll use our internal PACKAGESITE, and now our system has a mix of our lates ports and the original ports from RELEASE, and stuff start to get complicated ….