lelutin.ca

When a client of yours is moving a web site between two servers, of course the best option is to plan some time during which modification is prohibited and everything is moved as fast as possible. This ensures that you do only one operation and that everything follows.

However, in some cases, the client can desire to move more slowly in order to rearrange the new site or to filter out content prior to making it available on the new server, or there might be some transition issues that she doesn't want to revisit. In such cases, the web site will need to be available from two locations at once for some time.

In that case, you can help out by reverse proxying to the new server.

You have put your puppet master behind Passenger and that lasted for some time. But now that you're beginning to have quite a good number of hosts that checkin to your master regularly, performance has started to become an issue. What can be done about it?

There are multiple answers. The first and simplest would be to put more space between your puppet runs. Say you're currently running puppet every 30mins on each client, you could change that period to 45mins or 1h.

It's also possible to distribute runs via a central scheduler that would ensure to run every node before going back to square one. One such solutions is the "puppetcommander.rb" script that R.I. Pienaar wrote to use mcollective as the run scheduler.

Another method (that you can use in conjunction with the above) is to cache the responses that come from the puppet master.

A friend of mine found out an interesting plugin for those admins out there that use ViM. It makes it easier for you (and your colleages) to see when you are editing a file that is managed by puppet:

http://blog.mricon.com/2012/04/puppet-eyes.html

This module will only work when your editor has root privileges, since the file it parses, state.yaml, is accessible only to root (for relatively evident reasons). When you try to modify a file that is currently managed by puppet, you will see a white on red warning telling you "This file is managed by Puppet":

I personally have difficulty with GUIs and with how every one of them seems to approach the same problem differenlty. Mastered point-and-click is not as useful as the CLI because it's generally less direct. (e.g. you slide your mouse up there on the menu, click to open it, slide down, click to choose the option, click on a field in the newly opened window, type in the new value, slide down and click on the OK button. whereas with CLI you type in your command and pass in your arguments for the new values, and you're done)

I love Tomboy for how simple it is and how you can sync notes with ssh and other methods. However, I personally don't like how note management is achieved. It is very easy for newcommers, but lets no room for power users to get faster / better.

So, I've built a CLI interface to Tomboy. I called it Scout (after being advised to change name from Tomtom -- which was a slang synonym for Tomboy. Scout comes from the character from "To kill a mockingbird". She's that tomboy girl that likes to pick up a fight with other students when they make fun of her father).

Everything is done through the D-Bus API exposed by Tomboy. Luckily, Gnote (a port of Tomboy to C++ that became an entirely separate project) exposes the same API functions; this means Scout supports Gnote, too!

Long story short: both my 2.5" Caviar blue disks failed some days apart (GAH!). So I had to send them both back to WD for an RMA. But since all my stuff in there was accessible as-is, and also since I didn't have any other device to wipe out the disks (actually one had failed beyond the point where I could wipe out the disk even if I wanted to), I had to consider every ssh key, puppet SSL cert, passwords, etc, as compromised (double-GAH!!). Who knows what happens to the data after your disk is refurbished... I don't trust WD to wipe them out before shipping them to new clients.

Luckily, I had a recent backup of the entire /etc/puppet directory from the puppet master, and I was able with this to rebuild all VMs. Friends don't let friends run computers without a proper, regularly updated backup!

So! I decided I would add an encryption layer to the new disks, and since I don't have a screen plugged into the mini-ITX, I needed a way to delay the system from asking the password for decrypting the disk.

Sometimes, it's relevant to iterate through all ip adrresses on a host to emit configuration for each one. Facter has a useful bunch of facts for this:

• interfaces => lo,eth0,eth0_0,eth1
• ipaddress_lo => 127.0.0.1
• ipaddress_eth0 => 192.168.0.200
• ipaddress_...
• ... and so on

This is nice, but how can you use this in an ERB template?

I just listened to this presentation by Avery Pennarun about how Python can be very fast if you use the appropriate techniques, and how those techniques are actually graceful ones.

I've just had to fight a DDoS on a server, and I used a bash one-liner to have a very rough overview of the picture from the logs.

Once you know you've got a DDoS on your back, here's a quick reminder of how to count, in the last 1000 requests (number is arbitrary, but provides an interesting view when there are many requests), which IPs are doing the most requests

There are a bunch of best practices that can be followed to make your life easier with Puppet. The above diagram (full size available here)is a visual representation of how I place files on a puppet master to follow a couple of best practices that I've found interesting.

Here's a quick list of points that I follow when placing files on a puppet master

Well, all the howtos I could find about this were telling me to download boot.img.gz, zcat it to the usb key's device, then mount it and copy debian's ISO file in it.

It dosen't work [anymore] !

Here's a quick rectification howto on how to create a Debian squeeze installation USB key