Once installer, as a non-root user you can just:

mkdir mnt
sshfs username@server.domain.com:/path mnt

Then you can access it, copy files etc (both directions) as if it were a local directory

ls mnt

When finished this disconnects it:

fusermount -u mnt

Found at http://home.prea.net/hacking/X2200/NFS

clocksource/0: Time went backwards: ret=18f26176a5 delta=-8292949932632971 shadow=18e9e0b4b9 offset=880c4ce

This message wasn’t “harmless” – it caused TCP connections to break, so ssh was practically unusable.

The immediate solution: using the XenCenter console, forcefully reboot the affected VM. That’s “force shutdown”, followed by “start”. I tried the simple “reboot” option, but it wouldn’t shut down (probably because it was confused over the time). VMs are now back up and there’s no sign of time going backwards.

It seems this was triggered by suspending & resuming machines running the Debian Lenny kernel. Other VMs which are still running the 2.6.18 based XenSource kernels survived suspend/resume ok.

The actual cause is documented here, here, here & here. I think I’ll be following that advice and decoupling my VM clocks from the host (using NTP to keep them all in sync the old-fashioned way).

Here’s my working configuration on the Cisco 877:

ip cef
ip wccp web-cache

interface Vlan1
ip wccp web-cache redirect in

This tells the router that web traffic coming into the Vlan1 interface is a candidate for caching. With WCCP, web-caches register themselves with the router, then the router forwards requests to them. This means that if the cache disappears, the router will forward web requests directly to the internet.

I’m using Debian, so I added this to /etc/network/interfaces (replace 1.2.3.4 with the router identifier shown on the cisco by “show ip wccp”. In my case this is the external internet-facing IP address):

auto gre1
iface gre1 inet static
address 127.0.0.2
netmask 255.255.255.255
pre-up ip tunnel add gre1 mode gre remote 1.2.3.4 local 10.0.20.1 dev eth1
post-down ip tunnel del gre1

And I added this line to my firewall script. You could add it to rc.local if you don’t have anywhere else to put it:

iptables -t nat -A PREROUTING -i gre1 -d 0/0 -p tcp –dport 80 -j DNAT –to-destination 10.0.20.1:3128

The only thing left now is the squid configuration. I specified the internal address of the cisco 877 here (10.0.20.254):

wccp2_router 10.0.20.254
wccp2_rebuild_wait on
wccp2_forwarding_method 1
wccp2_return_method 1
wccp2_assignment_method 1
wccp2_service standard 0
wccp2_address 10.0.20.1

Useful links:

• http://www.usenet-forums.com/squid-users/247645-wccp-gre-redirect-target-failed-solution.html
• http://wiki.squid-cache.org/SquidFaq/InterceptionProxy
• http://www.cisco.com/public/news_training/itsnews/tech/chalktalk/200806.html

Upgrading the userland is identical to a physical server – instructions are contained within the Debian Lenny release notes.

To use the Debian packaged 2.6.26 kernel, several minor changes have to be made as per this form post:

1. Install the linux-image-2.6-xen-686 package (which depends on the latest xen kernel)
2. Re-order the kernels in /boot/grub/menu.lst so the Debian 2.6.26 kernel is the first (and therefore the default)
3. Add “console=hvc0″ to the end of the 2.6.26 kernel line in /boot/grub/menu.lst, so it reads “kernel /boot/vmlinuz-2.6.26-1-xen-686 root=/dev/xvda1 ro console=hvc0“
4. edit /etc/inittab, find the line that looks like “1:2345:respawn:/sbin/getty 38400 tty1″ and add another line: “0:2345:respawn:/sbin/getty 38400 hvc0″

Then reboot the system, it should boot the new kernel.

Xensource doesn’t display the grub menu, it just seems to boot straight into the default option (even though I have “timeout 10″ specified in the config).  There must be a secret keypress or something to make it show the menu, but I don’t know what it is because the last step just worked for me!

Edit: Theoretically you shouldn’t need to use the -xen kernel variant, as the -686-bigmem kernel also supports running paravirtualised in domU.  With Xensource 5.0 this boots fine, but Xensource’s xen-tools refuse to start so XenCenter reports the status as “unknown”.  With the -xen kernel xen-tools start fine.

I found the solution, it’s a simple change in Putty’s settings (Connection -> Data -> Terminal-type string).  By default this is set to “xterm” but changing it to “linux” fixes the home and end keys.

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.

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!

Here is the configuration BEFORE:

• /dev/hda partitioned into hda1 (10GB), hda2 (1GB), hda3 (175GB)
• /dev/hdc partitioned into hdc1 (10GB), hdc2 (1GB), hdc3 (175GB)
• RAID-1 array md0 composed of hda1 and hdc1, mounted as /
• RAID-1 array md1 composed of hda2 and hdc2, mounted as swap
• RAID-1 array md2 composed of hda3 and hdc3, mounted as /home

I started the ball rolling by failing one partition from each RAID array:

mdadm –fail /dev/md0 /dev/hdc1
mdadm –fail /dev/md1 /dev/hdc2
mdadm –fail /dev/md2 /dev/hdc3

Then I powered down the server, disconnected and removed hdc and added a new 500GB SATA disk to the SATA PCI card. It booted up fine with all three RAID arrays degraded. I used fdisk to partition the new SATA disk (/dev/sda) with identical sized partitions 1 and 2, and with the third partition taking up the remainder of the disk. I set all partition types to fd (linux raid auto-detect):

• sda1 (10GB), sda2 (1GB), sda3 (454GB)

Then one at a time I hot-added these partitions to the running RAID arrays. This causes a background reconstruction, so it’s worth waiting for each to finish before starting the next:

mdadm –add /dev/md0 /dev/sda1
mdadm –add /dev/md1 /dev/sda2
mdadm –add /dev/md2 /dev/sda3

When all three were completely synced (cat /proc/mdstat to see the progress), I edited /etc/mdadm/mdadm.conf to change all references from /dev/hdcx to /dev/sdax. I then re-built the initramfs so it knew how to start the arrays at boot time:

update-initramfs -k all -c -t

I then powered down the server again, removed the last IDE disk (hda) and added the second SATA disk (sdb). At this point the system is unbootable, so I started from a rescue CD (actually the Debian Etch netinst cd, starting with the “rescue” boot option). Once I got a command prompt (Alt-F2 and Alt-F3 virtual consoles), I installed grub:

mount /dev/sda1 /mnt
chroot /mnt /bin/bash
nano /boot/grub/device.map

I edited the device.map so it looked like this:

(hd0) /dev/sda
(hd1) /dev/sdb

Then installed grub on the first SATA disk:

grub-install /dev/sda

I rebooted and grub succesfully booted the server. As expected, all RAID arrays were in degraded mode. I used fdisk to re-partition the second SATA disk to match the first, then hot-added the mirrors to the RAID arrays (waiting for each re-sync to complete before starting the next):

mdadm –add /dev/md0 /dev/sdb1
mdadm –add /dev/md1 /dev/sdb2
mdadm –add /dev/md2 /dev/sdb3

Then I edited /etc/mdadm/mdadm.conf to update the partitions to (for example) sda1,sdb1. I re-build the initramfs again as above, and rebooted to test everything booted up cleanly. Also I checked /proc/mdstat after the reboot to check all arrays were fully functional.

So now the new disks are installed, but there’s no extra storage available because the ext3 partition is still set to the old size! I rebooted into single user mode, unmounted /home, then used resize2fs to expand the filesystem to use the whole partition:

e2fsck -f /dev/md2
resize2fs /dev/md2

One reboot later and voila, 455GB usable in /home.

Then I followed this guide to install grub on the second RAID disk in a bootable way.

Wordpress is a php package, so it’s architecture independant and has hardly any dependencies. In fact the only dependency that can’t be satisfied from stable is libphp-phpmailer: wordpress 2.2 needs a newer version of this library than shipped with etch. It’s possible to manually download those two packages from the testing distribution and install them manually, but there’s a better way.

Add the testing distribution to your /etc/apt/sources.list so it looks like this (the first two should already be in there):

deb http://ftp.uk.debian.org/debian/ etch main contrib non-free
deb http://security.debian.org/ etch/updates main contrib non-free
deb http://ftp.uk.debian.org/debian/ testing main

Then use apt-pinning to disable the testing distribution for all packages except the ones you want. Edit the /etc/apt/preferences file (you may have to create it if it doesn’t already exist) so it looks like this:

Package: *
Pin: release a=stable
Pin-Priority: 700

Package: *
Pin: release a=testing
Pin-Priority: -1

Package: wordpress
Pin: release a=testing
Pin-Priority: 800

Package: libphp-phpmailer
Pin: release a=testing
Pin-Priority: 800

The magic part of this is the preference of “-1″ for the testing distribution, which removes its packages from the available list. If you put a positive preference such as 500 (which is lower than the stable preference of 700), stable will still “win” for most packages but you’ll see some that aren’t in stable. The preference of 800 is assigned to the two packages we *do* want, and this makes them preferred over stable.

Now install wordpress 2.2:

apt-get update
apt-get install wordpress

If you already have wordpress 2.0 installed, “apt-get update; apt-get upgrade” will upgrade your 2.0 copy instead.

This technique can be used to cherry pick other packages from testing into a stable base system, but only if they don’t have significant dependencies (such as a newer c library version). In this case, backports.org is your friend.