W: GPG error: http://updates.xensource.com etch Release: The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY 841D6D8DFE3F8BB2
W: You may want to run apt-get update to correct these problems

This is because the GPG key Xensource use to sign their packages hasn’t been added to the VM’s apt keyring, and here’s how to fix it:

wget -q http://updates.vmd.citrix.com/XenServer/5.5.0/GPG-KEY -O- | apt-key add -

(From tiri.li).

Vista allows you to configure which hardware sources can wake up the system from sleep, so for example you can enable or disable Wake On Lan.  It also allows software to schedule a wakeup, and Media Centre is one such beast.  Ever since I started playing with Media Centre, the system has randomly woken up from sleep (and not returned to sleep afterwards), which kinda defeats the purpose of sleep!

It’s quite easy to find out the source of the most recent wakeup (powercfg /lastwake), but this lists all software sources as “RTC”.  It doesn’t identify *which* process (or scheduled task) was responsible.

I found one solution over at thegreenbutton (thanks to mxcrowe):

If you do this, your computer will not auto-wake for any reason (s/w reason – I suppose WOL etc. will still work).  This info was given to me by another poster here on the Green Button:

1. Open a CMD prompt
2. powercfg -setacvalueindex scheme_current sub_sleep bd3b718a-0680-4d9d-8ab2-e1d2b4ac806d 0
3. powercfg -setdcvalueindex scheme_current sub_sleep bd3b718a-0680-4d9d-8ab2-e1d2b4ac806d 0
4. powercfg -setactive scheme_current

This changes and applies a new power scheme that stops the machine from being woken from sleep. In my case, I have a desktop system and probably didn’t need to set the DC option, but I did both anyway.

Vyatta Virtual PC boot error

The solution is to pass the linux kernel boot argument noreplace-paravirt.  This is done on the live CD by typing “live noreplace-paravirt” and pressing enter (instead of simply pressing enter or waiting for the CD to automatically boot).

When you’ve installed to the virtual hard disk (using the install-system command), you’ll find it displays the same error.  To boot the first time you’ll need to press Escape to access the grub menu, then press “e” to edit the default entry.  Add the word noreplace-paravirt to the end of the line (after “console=tty0″) and press ctrl-x to boot.

When you get the login prompt, you can log in as root and edit the grub config file (nano /boot/grub/grub.cfg) to add the option to the command line permanently.

Being a Windows Mobile handset, it came loaded with all the expected Microsoft applications… except one! It seems Orange have decided to remove the MSN Messenger client, presumably because they’re worried it’ll dent their extremely profitable SMS revenue. And Microsoft no longer makes the client available for download (”ask your operator for MSN access”).

After several hours of trawling through forums, I found the nice chaps at xda-developers have many builds of the mobile msn client available for download (although you need to register to get access). Most are for the full PocketPC (PDA) OS, but the file attached to post #202 works on SmartPhones like the i200.

As expected, Pocket Outlook’s Microsoft Exchange synchronisation works seamlessly, so I now have real-time push email, contacts and calendar sync. And it’s actually usable as a phone too!

Vista keeps a log of application and kernel crashes in Control Panel -> Problems Reports and Solutions -> View problem history:

Double clicking on the latest Windows “shut down unexpectedly” shows the blue screen details. These don’t give much useful information, for example which driver was responsible:

Clicking on “View a temporary copy of these files” opens an explorer window with the crash dump file, which you can copy to your own directory.

To analyse the crash dump you’ll need to install the Microsoft Windows Debugging Tools (17MB msi).  This adds a whole set of command line tools under “C:\Program Files\Debugging Tools for Windows (x86)”.  Use the dumpchk.exe tool to analyse the crash file:

And there’s the culprit: “Probably caused by: eacfilt.sys”.  This is the driver used by Nortel’s Contivity VPN client.  I’m using the “vista friendly” version, which worked fine before I applied Vista SP1, but I guess SP1 broke its driver.  The solution to all my problems? Uninstall it!

Hurrah! My T61’s suspend and hibernate work again!

For help with this and other Vista problems, these books may be useful:

I found a solution on the lenovo forum, apparently the T61’s UPEK fingerprint reader driver 1.9.2.99 can be responsible. I’ve installed version 1.9.2.111 (download directly from UPEK), but I still get blue screens if I hibernate.

Other drivers known to be incompatible with SP1 are listed on Microsoft KB 948343, but I’m pretty sure I’m not running any of them. Any ideas?

Update (16th May 2008): The problem turned out to be Nortel’s Contivity VPN client.  They don’t appear to have released an updated version since SP1 was released.  I no longer have a need for this VPN client, so I simply uninstalled it.  Problem solved!

While I was trying to get to the bottom of this I read many suggestions.  Dodgy memory seems to be a common cause, and this can be checked by booting memcheck and leaving for a few hours.

Jan 20 02:59:21 drevil sshd[12803]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:24 drevil sshd[12806]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:27 drevil sshd[12816]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:30 drevil sshd[12820]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:34 drevil sshd[12827]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:37 drevil sshd[12830]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:40 drevil sshd[12833]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:44 drevil sshd[12836]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:47 drevil sshd[12840]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:51 drevil sshd[12843]: error: PAM: Authentication failure for illegal user root from 213.136.100.86

There are several simple ways of reducing the chance of a break-in through this method:

1. Use strong passwords

This is an obvious place to start. The vast majority of these attacks come from automated scanning tools. These attempt to log in using passwords from a commonly used “dictionary”, so avoid simple words like “password”. Using a combination of letters, lower and upper case letters, and even symbols (!”£$%^&*) will give a password that is unlikely to be listed in a “common passwords” dictionary.

2. Restrict the users who can connect via ssh

OpenSSH has the capability to specify a “white list” of allowed users and deny all others. Simply add this line to your /etc/sshd_config and restart the sshd service:

AllowUsers dave mike sarah

This will block attempts to connect as any of the common system users (root, postfix, mysql etc), EVEN if the attacker guesses the correct password. If this list is kept as small as possible, it is much easier to verify these users have strong passwords.

3. Rate limit new ssh connections

A simple iptables script can be used to rate limit new incoming connection attempts. There are two ways of doing this, using the limit and recent iptables modules. Here’s the limit solution:

iptables -N NEW_SSH
iptables -A INPUT -p tcp –dport 22 -m state –state NEW -j NEW_SSH
iptables -A NEW_SSH -s 10.0.0.0/24 -j ACCEPT
iptables -A NEW_SSH -m limit –limit 3/min –limit-burst 3 -j ACCEPT
iptables -A NEW_SSH -j DROP

The third line ensures that connections from the internal network (in this example 10.0.0.0/24) are not subject to rate-limiting. The weakness of this approach is that while an attack is underway, ALL new ssh connections from outside are blocked. The recent module allows a slightly different approach (taken from debian administration):

iptables -N NEW_SSH
iptables -A INPUT -p tcp –dport 22 -m state –state NEW -j NEW_SSH
iptables -A NEW_SSH -s 10.0.0.0/24 -j ACCEPT
iptables -A NEW_SSH -m recent –set
iptables -A NEW_SSH -m recent –update –seconds 60 –hitcount 4 -j DROP
iptables -A NEW_SSH -j ACCEPT

This module “blacklists” IP addresses that exceed the rate limit, while still allowing other IP addresses to connect. If a connection makes it past this rate limiting, we accept it (last line).

4. Run your ssh server on a different port

The automated scanners look for ssh services on the default port (22), so if you move your sshd to a non-standard port less scanners will find you. It’s worth noting that this approach doesn’t improve security at all against a determined attacker. Personally I don’t use this technique, my SSH servers run on port 22.

My old laptop is a Dell D600, so I’m looking at the equivalent D630. When I bought the D600 there were two display options: XGA (1024×768) or SXGA+ (1400×1050). I went with the higher resolution option, and it’s been fantastic.

Reading the product pages, the D630 also has two options: WXGA (1280×800) or WXGA+ (1440×900). I can live with the slightly lower widescreen resolution of 1440×900, but 1280×800 is just too much of a step down.

Unfortunately, this display option is missing from the UK “customise and buy your laptop” section. Only one option is listed, and it’s the low-res one:

A visit to the Dell USA website shows the option exists over there:

I don’t really want the hassle of ordering a laptop over there, getting it shipped over here, replacing the USA keyboard with a UK one…

Ah well, there must be plenty of other laptop manufacturers who WILL give me a high-res screen…

Dec 3 06:53:49 drevil named[2765]: zone 20.0.10.in-addr.arpa/IN: serial number (61) received from master 10.0.20.10#53 < ours (62)
Dec 3 07:03:48 drevil named[2765]: zone 20.0.10.in-addr.arpa/IN: serial number (61) received from master 10.0.20.10#53 < ours (62)
Dec 3 07:11:26 drevil named[2765]: zone 20.0.10.in-addr.arpa/IN: serial number (61) received from master 10.0.20.10#53 < ours (62)
Dec 3 07:21:24 drevil named[2765]: zone 20.0.10.in-addr.arpa/IN: serial number (61) received from master 10.0.20.10#53 < ours (62)
Dec 3 07:29:18 drevil named[2765]: zone 20.0.10.in-addr.arpa/IN: serial number (61) received from master 10.0.20.10#53 < ours (62)
Dec 3 07:37:54 drevil named[2765]: zone 20.0.10.in-addr.arpa/IN: serial number (61) received from master 10.0.20.10#53 < ours (62)
Dec 3 07:47:10 drevil named[2765]: zone 20.0.10.in-addr.arpa/IN: serial number (61) received from master 10.0.20.10#53 < ours (62)
Dec 3 07:56:11 drevil named[2765]: zone 20.0.10.in-addr.arpa/IN: serial number (61) received from master 10.0.20.10#53 < ours (62)

The solution is simple: Log onto the windows server, open the DNS management console, find the zone and click “increment” a couple of times on the serial number (SOA). But it’s very annoying, especially when the damn thing reboots itself every month for patch Tuesday!

It seems this was a documented problem in Windows Server 2000 (fixed in SP4): http://support.microsoft.com/kb/304653, but I can’t find any reference to the same problem in Server 2003.

drevil:~# dmidecode -t memory
# dmidecode 2.8
SMBIOS 2.3 present.

Handle 0×1000, DMI type 16, 15 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: None
Maximum Capacity: 4 GB
Error Information Handle: Not Provided
Number Of Devices: 2

Handle 0×1100, DMI type 17, 23 bytes
Memory Device
Array Handle: 0×1000
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 256 MB
Form Factor: DIMM
Set: None
Locator: DIMM_1
Bank Locator: Not Specified
Type: SDRAM
Type Detail: Synchronous
Speed: 333 MHz (3.0 ns)

Handle 0×1101, DMI type 17, 23 bytes
Memory Device
Array Handle: 0×1000
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 256 MB
Form Factor: DIMM
Set: None
Locator: DIMM_2
Bank Locator: Not Specified
Type: SDRAM
Type Detail: Synchronous
Speed: 333 MHz (3.0 ns)

Thanks to MJ Ray and Stuart Langridge, hopefully this will save me getting the screwdriver out in future!