All posts by bigpresh

Dancer web framework

Dancing in the cloud – deploying Dancer apps to dotcloud

Marco Fontani wrote up an excellent blog post on deploying Dancer apps to DotCloud’s beta.

DotCloud is a PaaS (platform as a service) hosting platform currently in beta, running on Amazon EC2. It promises dead-easy deployment of Perl web applications. (DotCloud announced Perl support as CaaS (Camel as a Service) recently.)

Marco’s write-up shows that it is indeed simple; push your Dancer app to DotCloud, and it figures out the dependencies, installs them, and starts it up. As the little meerkat would say, “simples!”.

Programming

Creating and pushing new remote git branch

A note for my own reference, as I always forget how to create a remote branch then work with it later:

Create a new remote branch topic/add_awesomeness with, e.g.:


git push origin :origin:refs/heads/topic/add_awesomeness

Create a new local branch to track it:


git checkout --track -b add_awesomeness origin/topic/add_awesomeness

The unintuitive way to delete a remote branch is:


 git push origin :heads/topic/doc_cleanup

(There must be a better way than that…)

Linux, System Administration

Incremental backups with rdiff-backup

3 Comments

My current backup solution is using rdiff-backup to do incremental backups. I’d previously been using plain rsync, but I wanted snapshots too, so I could retrieve a file as it looked at some point in the past (as Sod’s law guarantees that if a file was mistakenly deleted/clobbered, rsync will run between that happening and you noticing, so the backup will be clobbered too).

My setup involves the backup box running rdiff-backup, connecting to the machine to be backed up via SSH, using a passwordless SSH key for authentication. The entry in ~/.ssh/authorized_keys on the machine to be backed up allows that key to be used only to run rdiff-backup, nothing else, and only from the backup host, to provide as much security as possible.

I thought I’d document my setup here, both for easy future reference for myself when adding other boxes to back up, and for anyone else who may find it useful.

So, the steps I use are as follows:
Continue reading Incremental backups with rdiff-backup →

Gaming, Non-geeky

A bit of nostalgia with DOSbox…

For a bit of nostalgia, I decided to use DOSbox to run a few old DOS games on my laptop.

Here’s “The Incredible Machine”, from way back in 1993:

I have fond memories of US Navy Fighters, a rather impressive for the time flight-sim (way back in 1994)…

I did chuckle when installing it, when the installation program tells you that the Full Install option requires 16MB of disc space – “use this if you have plenty of disc space” :)

Just not the same with the keyboard though – may have to try to get DOSbox to work with a USB joystick at some point!

Perl, System Administration

Nagios plugin to monitor 3ware/LSI RAID

5 Comments

I wrote a basic Nagios plugin named nagios_3ware_raid_check to monitor the status of RAID arrays on 3ware/LSI hardware RAID controllers, but it was pretty limited.

Today I got a chance to improve it as I needed it for some machines at work; it now automatically figures out which card(s) are present, and checks the status of each RAID array on it. This means you don’t need to configure it to know which card number and unit to monitor, it just Does The Right Thing.

It uses the tw_cli utility available from the LSI website, which supports a wide range of 3ware/LSI RAID cards.

Example:

[dave@rasputin:~]$ /usr/local/bin/nagios_3ware_raid_check -v
Card 6 is a 8006-2LP
Unit u0 on card6 is a RAID-1 array of 931 GB and is OK
RAIDCHECK OK - Card 6 unit u0 RAID-1 OK (931GB)

When actually using it from Nagios, don’t use the -v (verbose) option – just use something like the following in nrpe_local.cfg:

# Monitor RAID status
command[check_raid]=/usr/local/bin/nagios_3ware_raid_check
Perl, System Administration

Configuring CPAN.pm to use sudo to install

2 Comments

For security, I like to run CPAN.pm as a normal user so building & testing modules are all performed as a user rather than root, but of course the final installation needs to be done as root so that files can be copied to paths not writeable by normal users.

I always forget the options I need, so for my future reference as well as anyone else who finds it useful:

o conf make_install_make_command 'sudo make'
o conf mbuild_install_build_command 'sudo ./Build'

That means that the actual installation gets run via sudo, with everything else just being done as the user you started the CPAN client as.

(Of course, these days, you could also use cpanm (cpanminus) with its –sudo option…)

Linux, System Administration

Slow SSH connections – hanging at GSSAPI auth

14 Comments

A particular box at $work had been slow to SSH to for a while, and I finally wanted to spend the time to find out why.

Running ssh -v thatmachine showed that it was hanging whilst attempting to authenticate with GSSAPI, with the slow section looking like:

debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found
debug1: Unspecified GSS failure.  Minor code may provide more information
debug1: Next authentication method: publickey
debug1: Offering public key: /home/davidp/.ssh/id_rsa
# authentication by public key then proceeded quickly

SSHing to the machine by IP instead, i.e. ssh -v 10.1.1.192, produced slightly different output:

debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: An invalid name was supplied
Cannot determine realm for numeric host address
debug1: An invalid name was supplied
Cannot determine realm for numeric host address
debug1: An invalid name was supplied
debug1: Next authentication method: publickey
# authentication by public key then succeeded quickly

It’s clear that it’s trying to authenticate using GSS-API (Kerberos), failing, then moving on to public key auth.

The fix is simple – disable attempts to use GSS-API by adding the following to ~/.ssh/config:

GSSAPIAuthentication no

Before adding that:

[davidp@columbia:~]$ time ssh 10.1.1.192 touch /dev/null | grep real
real	0m15.512s

After adding it:

[davidp@columbia:~]$ time ssh 10.1.1.192 touch /dev/null | grep real
real	0m0.611s

Problem solved.