Category: linux

Posted on

Installing Debian (Jessie) on an Intel NUC D54250WYK

Product – D54250WYK / boxd54250wykh3 – via e.g. Ballicom or eBuyer

It’s an Intel i5 4250U processor (dual core, laptop processor). Supports up to 16gb of RAM and the Intel 5000 graphics thing in it.

The box itself is really small – and silent. A laptop size hard disk can fit into it (2.5″ hdd).

Issues :

  1. BIOS needs updating before it can be installed (apparently); See Intel’s website – currently here – it’s just a case of downloading the .BIO file and sticking it on a USB stick and pressing F7 on boot and following through the prompts.
  2. Most Linux distros do not yet support the network card (Intel 559/I218-V) – I had to netboot a Debian unstable netboot iso image (from here )

Good things –

  1. BTRFS root filesystem + booting etc just worked with Jessie.
  2. X configuration just works – even though it’s quite a new graphics chipset.
  3. Boot time is VERY fast – currently <5 seconds.
Posted on

ipmi / linux / dell poweredge SC1435

We recently bought two Dell SC1435 servers off eBay. They seemed cheap and quite well specced (dual 4 core CPUs, plenty of RAM for us) – perhaps ideal for redundant mail servers.

Anyway, they’re IPMI 2.0 compliant – meaning they should be controllable remotely (e.g serial console, forceful power cycling etc without the need for some sort of graphical KVM console or DRAC card.).

(A few years later, I bought a Dell t300 from Ebay; the below works for it too)

Here are some notes on setting up/configuring IPMI support and how it can be used – :

Continue reading “ipmi / linux / dell poweredge SC1435”

Posted on

Fail2ban filter for WordPress

With the annoying brute force wordpress hack going round, one way to protect your site(s) would be to use fail2ban, with a configuration something like (which I’ve shamelessly lifted from http://blog.somsip.com/2011/12/protecting-apache-webservers-from-wordpress-admin-login-dictionary-attacks/ ).

The below seems to be working, and given it’s relative simplicity it’s obvious how you’d go about changing to protect other POST based scripts from brute force attacks.

As with all fail2ban rules, it’s not going to work if the attacker changes IP often (but from scanning the logs so far, it doesn’t seem to be the case that they are).

Obvious caveats :

  1. Users who can’t remember their password(s) will get blocked.
  2. It’s not going to protect you from a distributed attack (multiple IPs) very well
  3. You may want to perform other counter-measures (like putting Apache http authentication in for URLs matching /wp-login.php)

 

In /etc/fail2ban/jail.conf :

[apache-wp-login]
enabled = true
port = http,https
filter = apache-wp-login
logpath = /var/www/vhosts/*/statistics/logs/access_log
maxretry = 5
findtime = 120

And In /etc/fail2ban/filter.d/apache-wp-login.conf :

[Definition]
failregex = <HOST> - - .* "POST /wp-login.php HTTP/.*" 200

ignoreregex =

Where a “hacking” access.log entry looks a bit like :

107.21.107.144 - - [02/Feb/2014:12:50:01 +0000] "POST /wp-login.php HTTP/1.0" 200 4344 "-" "-"
Posted on

Script to fix NFS (Debian Squeeze + Backports bits)

I have a NFS server running Debian Squeeze. Additionally it’s using the 3.2.x kernel from backports, and the nfs-kernel-server from backports too.

Sometimes NFS breaks, and gives helpful messages like :

mount.nfs: connection timed out

or just:

Stale NFS handle on clients.

 

While I’m confident that my /etc/exports and other configuration files are correct, it still insists on misbehaving.

Below is a random shell script I seem to have created to fix the NFS server –

#!/bin/bash
set -e
/etc/init.d/nfs-kernel-server stop
/etc/init.d/nfs-common stop
/etc/init.d/rpcbind stop

rm -Rf /var/lib/nfs
mkdir /var/lib/nfs
mkdir /var/lib/nfs/v4recovery /var/lib/nfs/rpc_pipefs

for f in /var/lib/nfs/etab \
/var/lib/nfs/rmtab \
/var/lib/nfs/xtab; do
[ -e $f ] || touch $f
done

/etc/init.d/rpcbind start
sleep 2
/etc/init.d/nfs-common start
sleep 2
/etc/init.d/nfs-kernel-server start

echo "NFS may now work"

exportfs -f

Yes… “NFS may now work” … that sums it up about right.

Posted on

Virtualbox 4.2 VM autostart on Debian Squeeze & Wheezy

One new feature of VirtualBox 4.2 is that it has support for auto-starting vm’s on bootup of the host server (via init etc). This means I can remove my hackish ‘su – vbox -c “VBoxHeadless –startvm VMName &”‘ additions in /etc/rc.local, and the VM’s will also hopefully be terminated gracefully on shutdown.

The docs/guides online which I could find were a bit cryptic, or incomplete, so here’s what I ended up doing :

Continue reading “Virtualbox 4.2 VM autostart on Debian Squeeze & Wheezy”

Posted on

Migrating an ext3 filesystem to ext4 (Debian Squeeze)

Interestingly (well, perhaps not really) this is very easy.

In my case, I’m hoping that the migration will lead to faster fsck times (currently it’s taking about an hour, which is somewhat excessive, each time the server crashes for whatever reason).

In my case, the filesystem is /dev/md0 and mounted at /home – change the bits below as appropriate.
Continue reading “Migrating an ext3 filesystem to ext4 (Debian Squeeze)”

Posted on

Debian Squeeze (NFS broken with backports kernel)

Our office server has been running the Squeeze-Backports kernel for some time – without issue – until today. Amongst the things it ‘should’ do, is act as an NFS server for the office computers (giving us a common /home directory).

Every so often, NFS breaks for some reason. Perhaps in some way, the NFS server feels a need to keep a hold over me.
Continue reading “Debian Squeeze (NFS broken with backports kernel)”

Posted on

Fixing REMOTE_ADDR when behind a proxy/varnish server

I had an annoyance where varnish proxy infront of a LAMP server and the LAMP server therefore thought all clients were from the varnish proxy – rather than the client’s real IP address – i.e. $_SERVER[‘REMOTE_ADDR’] was set to the IP address of the Varnish proxy and not that of the client’s actual IP address.

Obviously, Varnish adds the X_HTTP_FORWARDED_FOR HTTP header in when a connection comes through it; so my initial thought was to just overwrite PHP’s $_SERVER[‘REMOTE_ADDR’] setting. A bit of a hack and annoying – as I’d need to fix all sites, or have some sort of global prepend file (which is horrible).

I then discovered something which sorts the problem out  – RPAF

  • apt-get install libapache2-mod-rpaf
  • Edit /etc/apache2/mods-enabled/rpaf.conf and ensure your proxy server’s IP address is listed on the RPAFproxy_ips line (e.g. RPAFproxy_ips 127.0.0.1 89.16.176.x).
  • Restart Apache, and you’ll then find that the $_SERVER[‘REMOTE_ADDR’] value will be correct.