As an Operations consultant, I always see people focus on redundancy on all levels... Except for documentation.
For some reason everyone says, there should be documentation, but never ends up being usable documentation. Either it's too much, too little or something else :)
I've been setting up automated (with puppet) graphing of a lot of servers, incl. graphs for applications like varnish, mysql, memcache etc. (using diamond graphite collector).
I created a graph over varnish hitrates and shared it with the developer of the site running behind that varnish-farm (at that time it was 67% and slowly decreasing).
Here's what happened then :)
I've often needed to seperate settings pr. a distros major relase in puppet.
f.ex. CentOs-6 is different than CentOs-5 - but there's no difference between v5.6 and 5.7.
there's no fact in puppet that gives this. I've had an $osversion fact -
which simply concat'ed $operatingsystem and $lsbmajdistrelease - but that last fact depends on lsbdistrelease - which depends on
lsb_release, which on Red Hat 6 is delivered by redhat-lsb package -
which pulls in ~90 packages!
Så fik jeg holdt mit foredrag hos DKUUG om system konfigurationsværktøjet Puppet - og der var forbavsende (for mig :) mange der mødte op.
Til dem der skulle have lyst så har jeg vedhæftet slides i PDF format og DKUUG vil vist have en video med foredraget oppe på et tidspunkt.
Today I found a sure-fire way to crash Google chrome (and probably chromium as well).
Try viewing this in Chrome: http://vsen.dk/files/chromecrash.html
The trick is to put a large file (f.ex. 3,8MB ) as the icon file.. :)
I had a problem with my previous script - often ssh-add would hang -executing echo continuously - which was marked as defunct :(
I figure I'd rewrite it in expect - to also make the script runnable outside of cron - and that proved a little bit challenging - but I got it solved, and figured I'd share it:
Using ssh-keys for access to servers can be very nice as one can use ssh-agent to temporarily store the unencrypted key - and thus work all day - without continuously entering your password for the key - and you can easily decide (using authorized_keys file on the server) which keys gets to login as which users - and what commands they may execute.
But - it's my experience that many (developers f.ex.) find a need to have an empty passphrase for their key - a bad thing to do - if you want a bit of security :)
Aptitude has an annoying bug, which will probably never be fixed upstream :( - but aptitude is the only tool that supports downgrading of package versions (with correct --force options) none-interactively (as done by f.ex. puppet).
If you want to install a package in a specific version (f.ex. for releasing site code in a specific version) - like this:
A neat script I pieced together - to send many commands (f.ex. deletion of objects etc.) to a box (using ssh) - input from a file (remember to atleast use a proper random name for the file etc. :)
I just hit a grave bug, while performance testing a customers drupal site - the apache segfaulted each and every time, after a few 100 requests at the most. The setup had long been plagued by random segmentation faults / complaints about canary problems from suhosin, which wasn't reproducible (or we hadn't spent the time to try), but this time it died consistently.