Fresh releases! puppet-ipa, puppet-nfs, puppet-gluster

I’ve been a little slow in making release announcements, so here’s some news:

I’ve just released the third stage of my puppet-ipa module. At the moment it now supports installation, managing of hosts, and managing of services. It integrates with my puppet-nfs module to allow you to easily setup and run an NFSv4 kerberized server and client.

While we’re at it, that’s some more news: I’ve just released a puppet-nfs module to make your /etc/exports management easier. It’s designed to manage other security types, or even to work without kerberos or any authentication at all, but I haven’t tested those.

Back to puppet-ipa for a moment. I’d like you to know that I went to great lengths to make this a very versatile module. Some users probably want certain resources managed by puppet, and others not. With the included features, you can even specify exclusion criteria so that a certain pattern of hosts aren’t touched by puppet. This is useful if you’re slowly converting your ipa setup to be managed by puppet.

You can use $watch and $modify, two special parameters that I added to precisely control what kind of changes you want to allow puppet to make. These are kind of complicated to explain, but suffice it to say that this module should handle whatever situation you’re in.

For the security minded folks, puppet-ipa, never transfers or touches a keytab file. It will securely and automatically provision your hosts and services without storing secret information in puppet. The module isn’t finished, but it’s built right.

Gluster users might find this particular trio useful for offering gluster backed, kerberized, NFS exports. Here’s an example that I made just for you.

Since you sound like you’re having fun deploying servers like crazy, it’s probably useful to have a puppet-cobbler module. I’ve released this module because it’s useful to me, however it really isn’t release ready, but I think it’s better than some (most?) of the other puppet-cobbler code that’s out there. One other warning is that I have a large rearchitecturing planned for this module, so don’t get too attached. It’s going to get better!

So that’s your lot for today, have fun, and

Happy Hacking!

James

PS: If you’re in a giving mood, I’m in the need for some x86_64 compatible test hardware. If you’re able to donate, please let me know!

IPMI for linux professionals

The nostalgia of serial console servers, kvm’s and switched PDU’s is hopefully no longer visible in your server room. If not, you must definitely start playing catch up. Please forgive my ignorance, but these things might still be common for big windows shops, however if that’s the case, you’ve got an entirely different set of problems ;)

IPMI is an IP based protocol that allows you to talk directly to a little computer, usually built in to your server. It lets you remotely manage power (on, off, reboot, cycle…) get a serial console, collect sensor readings like temperatures, and do other magical things too if you care to figure them out.

The web talks a lot about all this. I’ll give you the short “need to know” list to get you going.

  1. It probably makes sense to have the IPMI device of your DHCP server (or whatever network dependencies you have) set statically, so that this works if DHCP is down. I’ve actually never heard of anyone who had this problem, but it seems logical enough that I figured I’d mention it.
  2. Set an IPMI password and put the device on a separate layer two network behind your router and firewall. Most servers bond the IPMI device to your “eth0” by default (at layer2), or let you split it off to a separate physical interface if so desired. Do the split and plug it into your management network. Remind me to talk about my dual router topology one day.
  3. When you use cobbler to kickstart your machines, you’ll need this in your kopts:
    console=ttyS1,115200
    Don’t bother wasting your time configuring that manually when anaconda takes care of this for you :)
  4. Almost all server hardware uses the second serial device (ttyS1) as the one that is linked to the IPMI hardware. In some insane default BIOS’es you might have to enable this.
  5. Once installed, the kopt will usually know to have added the correct magic to grub, and also to whatever spawn’s your serial tty. Feel free to grep to see what your $OS did.
  6. ipmitool -I lanplus -H <ip address of ipmi device> -U ADMIN sol activate
    if ever this gets stuck, run a ‘deactivate’ first.
  7. Learn the ~. disconnect sequence. If you’re connected over ssh to your ipmi client (which I always am since it’s my router) you’ll need to “~~” to skip “through” the ssh escape character, and then period “.”, exactly how ssh disconnects. Similarly the same logic applies if you’re insane and run screen -> ssh -> screen.
  8. You might need to do a “reset+clear” if the bios throws crap down the wire at you. I haven’t found a way to avoid this. It’s generally not a big problem for me, because this only happens if I’m watching the bios at boot, which only really happens if I’m bored on first install.

Happy Hacking!

James