mrisher's questions

In my Puppet (2.6) module definition, I create user accounts by declaring them as virtual resources; today they take the form @useraccount('name'=>'joe') and @useraccount('name'=>'mary') within a single class, which then gets include-ed when I want to realize them all (i.e. include useraccounts followed by Useraccount <| |>).

I would like to move these individual @useraccount definitions into separate files so I can better manage users individually. But it doesn't appear that the include command allows for a wildcard (i.e. include useraccounts/* where I would then maintain one file per user in the useraccounts subdir)

Is there a better way to do this?

Thank you.

We use Puppet for installing the base level OS and packages, but our own application packages are deployed manually by individual developers.

I'm looking for a web dashboard to view/monitor the package versions across all machines. Has anyone come across something that achieves this? The puppet-dashboard project is interesting, but it gives a node-centric view, whereas I'd like to see at the class level, e.g.

          Server 1 | Server 2 | Server 3 
   pkg1   v1.2     | v1.2     | *v1.3*
   pkg2   v.09     | v.09     | v.09

Thank you!

all: We have just started using an existing Cat5e cable to run 100Base-T to a new office, but unfortunately, machines in the new office see link but receive an APIPA address (169.254.x.x).

I brought the same computer into the network closet and plugged it directly into the hub and everything works okay, so it must be the wiring through the walls.

Can I use Wireshark or some other (Mac) software to confirm this? Or is there an inexpensive hardware test, short of pulling the cable back through the walls?

Thank you, /m

How can I migrate our existing puppet clients to point to a new puppetmaster server? I'd rather not manually go to each client box and generate a new certificate.

When trying the obvious -- rsync all the files from /etc/puppet and /var/lib/puppet to the new server -- we got the certificate error

/etc/init.d/puppetmaster start 
* Starting puppet master                
Could not run: Retrieved certificate does not match private key; please remove certificate from server and regenerate it with the current key

I was able to work around that by copying the /var/lib/ssl/certs and /var/lib/ssl/private_key files from old_hostname to new_hostname, which is basically what's suggested in migrating puppet clients to a new puppet master (old puppet master server gone, only using backup)

Unfortunately, my clients still know there's something amiss, and give me the following error:

sudo puppetd --test --server newservername.example.net --noop 
info: Retrieving plugin
err: /File[/var/lib/puppet/lib]: Failed to generate additional resources using 'eval_generate': hostname was not match with the server certificate
err: /File[/var/lib/puppet/lib]: Could not evaluate: hostname was not match with the server certificate Could not retrieve file metadata for puppet://newservername.example.net/plugins: hostname was not match with the server certificate
err: Could not retrieve catalog from remote server: hostname was not match with the server certificate
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run

So I'm guessing the client certificates still know the hostname they're associated with, and aren't happy about a switch.

Is there a way to use puppet (pointing to the legacy puppetmaster) to deploy new certificates, or somehow automate the signing process?

SUMMARY: Two solutions were presented: 1) turn on autosign on the master, thus skipping certification entirely, or 2) set the old CNAME to point to the new master, since certificates are bound to the master's hostname. I chose #2 because autosign felt like it was just turning off security (albeit for a limited time).

We build .deb packages and host them in a local Debian APT Repository, which we then use Puppet to manage installs from.

However, there is surprisingly little written about building or managing an apt repository, so I fear we're overlooking some beautiful open-source solution. What do other startups use? Do they just scp the raw files from server to server? If so, how do they keep things tidy?

Or is this a question that Rails handles internally (e.g. as gems) so we're the only ones facing it? ;)

Hi: I'm trying to configure Puppet on Ubuntu, and strangely I am never able to generate a certificate because my server never shows any pending certificate requests.

Put differently, on the server I am running puppetmasterd and on the client I am able to connect to the server, but the client continues printing

notice: Did not receive certificate
warning: peer certificate won't be verified in this SSL session

and yet the server never sees the request

mrisher@lab2$ puppetca --list                        
[nothing shows up]
mrisher@lab2$ puppetca --sign clientname.domain.com
clientname.domain.com
err: Could not call sign: Could not find certificate request for clientname.domain.com

Edit: There was a suggestion that autosign was happening, but that does not seem to be it. There is no autosign.conf file, and when I run puppetmasterd --no-daemonize -d -v I receive the following output: info: Could not find certificate for 'clientname.domain.com' every time the client says notice: Did not receive certificate

I checked the certs on the server and there don't seem to be any:

mrisher@lab2:~$ puppetca --list --all
mrisher@lab2:~$ sudo puppetca --list --all
+ lab2.domain.com          // this is the server (master)
mrisher@lab2:~$ sudo puppetca --list      
[blank line]
mrisher@lab2:~$

Note: This is mostly running the default install from Ubuntu, if that gives any leads.

Thanks for any help out there.

EDIT It appears this was due to inconsistently running puppetd as different users. For reasons I don't really understand for a daemon, puppet stores some of its settings -- including the certificates -- in ~/.puppet rather than a central directory like /var/lib/puppet, and thus it matters if you're testing as yourself versus sudo.