PreshBlog

I had a problem with VLC, using outdated proxy settings rather than connecting directly, even with no proxy configured in VLC’s settings (and even when trying to override it using command-line options).

(It would show that it was trying to use a proxy:

[0x134b4b0] main access error: connection failed: Connection refused
[0x134b4b0] access_http access error: cannot connect to supernova:3140

(supernova:3140 was the proxy setting it was picking up.)

After using strace to follow the execution of VLC when trying to play a network stream, I realised it was getting the settings via gconf; I needed to execute gconf-editor, navigate to system, http_proxy, then untick use_http_proxy – and also edit the value of the host setting to an empty string (without doing this, VLC ignored the use_http_proxy setting being false, and tried to use the proxy anyway!).

I could have done the same using gconftool-2 with:

gconftool-2 -s /system/http_proxy/use_http_proxy --type bool false
gconftool-2 -s /system/http_proxy/host --type string ''

Blogging for my own future reference, and for anyone else who’s using vlc on XFCE and wondering where it was getting the proxy settings. I’ve used Gnome 2 on this machine before, and I think that system proxy setting was set by Chromium (Google Chrome).

One thing that’s annoyed me for some time is .svn dirs interfering with smooth tab-completion in Bash when I’m in a Subversion checkout.

Finally annoyed me enough to do something about it – the solution is easy:

export FIGNORE=".svn"

I whacked the above in my .profile, and job done.

A quick post for my own easy reference more than anything else.

Generating a 2048-bit key:

openssl genrsa -des3 -out www.example.com.key 2048

Generating a certificate signing request:

openssl req -new -key www.example.com.key -out www.example.com.csr

I’ve been updating my Nagios monitoring to make sure I’m carefully monitoring my server hardware, including temperature, fan speeds and hard drives, and I wanted to use S.M.A.R.T. monitoring to monitor drives on a 3ware RAID controller for signs of imminent failure.

I already monitor the status of the RAID array itself using my nagios_3ware_raid_check Nagios plugin (which I previously blogged about), but I wanted to use SMART monitoring to look for signs of imminent drive trouble, rather than simply finding out when a drive has just failed.

After installing smartmontools, I was able to edit /etc/smartd.conf, disabling the default of scanning for devices, and listing devices explicitly, as follows:

# Monitor the drives on our RAID array; schedule self tests for Sundays.
/dev/twa0 -d 3ware,0 -a -s L/../../7/02
/dev/twa0 -d 3ware,1 -a -s L/../../7/04

The above monitors both drives of a RAID-1 mirrored pair on a 3ware controller card; the -s option schedules a long self-test every Sunday, starting between 2-3am and 4-5am respectively.

I’m still looking for a good way to monitor via Nagios, though; the (poorly-named) check_ide_smart plugin doesn’t support the ability to monitor drives on other interfaces as far as I can see. I found a couple of Perl scripts such as Check-SMART-status-modified, but they had issues.

Trying to start another Xen guest domain, and getting an error indicating that there are no loop devices left, like the following? :

Error: Device 51714 (vbd) could not be connected. Failed to find an unused loop device

Increase the number of loop devices that the loop kernel module will create, by editing/creating /etc/modprobe.d/local-loop containing something like:

(continue reading…)

I recently upgraded my laptop (a Dell 17R / N7010) to Ubuntu 11.04 (Natty), and since then, it has been randomly freezing when I come back to it after leaving it for a while.

I see my X session exactly as I left it, and can move the mouse around, but nothing seems to respond to mouse/keyboard events. The system is still alive, I can SSH to it from another box, or switch to a different virtual terminal (e.g. Ctrl + Alt + F1), and I can kill Xorg (sudo pkill X) at which point gdm immediately gets restarted, and I can log back in.

It seems to only strike when the laptop has been left unattended for some time. I can close the lid, wait ten seconds and re-open it, and everything is fine. I can also trigger the screensaver by locking the screen with Ctrl + Alt + L, then unlock, and all is also fine.

I’ve done some Googling, and I’m certainly not the only person experiencing this:

Bug 772925 – Screen freezes after laptop lid closed for more than 1 minute
Bug 781402 – Ubuntu 11.04 / Unity freezing when screen is ‘woken up’
a discussion of bug 781402 on fossplanet.com
Bug 740126 – Disabling an output can cause vblank events to be missed

I’m using ‘Ubuntu Classic’, i.e. using GNOME rather than Unity, but the reports of the problem I’ve seen are split between both.

I’ve found a suggestion of a possible fix – installing compizconfig-settings-manager then disabling Sync to vblankon ubuntuforums.org.

I’ve just tried that out; I’ll update this post when I know whether it has worked or not.

EDIT: I’ve checked logs for anything illuminating and found little, but I did just spot the following in /var/log/Xorg.0.log.old:

[437515.524] (EE) intel(0): [DRI2] DRI2SwapComplete: bad drawable

I’ve no idea if it’s related to the problem or not.

EDIT 2: So far, it would seem that disabling “Sync to vblank” as mentioned above has fixed the problem, for me. (It’s also possible that it was fixed in one of the updates since, but I haven’t spotted any package updates that looked relevant.)

If you’re having the same problem, feel free to comment here on whether the “Sync to vblank” change stopped the freezes for you.

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…)

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

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…)

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.