Technological Wanderings - linux

iPhone 3.0 tethering with Linux

techuser — Sat, 20 Jun 2009 08:32:23 +0000

Keywords:

iPhone tethering uses standard Bluetooth protocols, so you can tether from Linux. I'm not aware of how you'd do this over USB - for my situation (using the iPhone as connectivity for my CarPC) Bluetooth is ideal.

First install Bluetooth utilities on Linux and ensure you are running a kernel with all Bluetooth support compiled in or otherwise available as modules.
Make sure you have something on Linux that'll prompt you for the PIN - kbluetooth or similar for graphical desktops. Pair the phone and the computer - I did this from the iPhone end - and enter the same PIN on each end. Ensure tethering is enabled and switched on on the iPhone.

You can get the iPhone's address on Bluetooth using 'hcitool scan' while the iPhone is in discovery mode.

On Linux:
modprobe bnep pand --connect [IPHONE_ADDRESS] --service NAP --autozap

You should now see a new interface connected:
ifconfig bnep0

Depending on your Linux distribution, it may automatically run DHCP (this is how the iPhone gives your computer a NAT'd IP). Otherwise:
dhclient bnep0

(or whatever you use normally)

All done, have fun with Internet everywhere :-)

London Stock Exchange

techuser — Tue, 16 Sep 2008 20:55:40 +0000

Keywords:

linux

microsoft

Microsoft: Get the Facts on the London Stock Exchange:
http://www.microsoft.com/uk/getthefacts/lse.mspx

Well, a few months ago the LSE was sending out incorrect data. Trading data was wrong. The graphs on the BBC were showing random static instead of value data.

Now it's completely fell apart, on possibly one of the most important trading days of the year (bye bye another big bank):
http://news.bbc.co.uk/1/hi/business/7603981.stm

Ah, lovely, somebody has a grab of one of the MS adverts on the LSE:
http://tipotheday.com/2008/09/08/microsofts-foot-in-mouth-london-stock-e...

Microsoft pushing f**king reliability... Jesus... I changed my job recently and a big thing is not being woken at 3am whenever Microsoft deliberately cause a failure on an Server 2003 machine (aka enforced Windows updates reboot).
Or the mornings after a MS update is pushed out to client machines and two dozen of our customers lose their email or file store or whatever MS have f**ked up that time.
Still, it ensures the client is more willing to pay an extra couple of grand for the support contract to keep their machines running (or at least, running most of the time). MS at least cause movement of money.

Now I work with Linux, BSD and Mac. So much happier.

Recovering Linux RAID5 with mdadm

techuser — Sat, 07 Jun 2008 09:11:06 +0000

Keywords:

If a Linux box has hardware troubles and you temporarily loose a disk or two on a RAID5, you might get into a state where mdadm --assemble does not work. This might happen with a controller failure, or if you have faulty cabling.
You're seeing stuff like:
mdadm: failed to run array /dev/md7: Input/output error md: pers->run() failed
Don't panic yet!
First step, ensure you have good backups and use dd or another tool to clone the hard disks.

What you need to do is recreate the RAID. This will work in most cases to get your data back, but need to be done carefully to ensure you don't destroy it in the process.

This doesn't really matter for RAID1, as your data is always consistent on both disks - you can put one disk in and resync everything from that to any other disk.

For RAID5, the data is held across all disks. The thing to realise here is that the order of the disks in the array really matters. The trick to recreating a RAID5 and having it work is to get the order right.

Problems:
1. What if the order is not obvious?
2. Resyncing.

If you add the disks in the wrong order and start the array in a working state, it will perform an initial sync of the array. This will destroy your data as RAID5 starts to write checksum data across it.
There may be a trick with mdadm to determine the correct order, but I do not know it (yet).

You must create the array in a degraded state with a disk missing. This will allow you to mount the disk, but will not cause a resync attempt.

So, here's the scenario. There are three disks in an array, hda, hdd, hdg. One failed completely (hdg) a while ago and you had to wait for new disks to be delivered. While waiting, there was an IDE failure and another disk was lost temporarily. Oh dear, we've got a broken array.

You bring the disk back online but the array won't auto-reassemble and mdadm --assemble isn't working. So we move on to recreating.

What you will do is attempt to create the array using two disks. The other will be marked as missing (even though we now have the replacement sitting on the workbench ready).
But we don't know what order the disks belong in the array - maybe we'll get lucky and they are alphabetical, maybe we won't.

This is what we'll do:
$ mdadm --create /dev/md7 --level=5 --raid-devices=3 -f /dev/hda1 /dev/hdd1 missing $ cat /proc/mdstat md7 : active raid5 hda1[2] hdd1[1] 240121472 blocks level 5, 64k chunk, algorithm 2 [3/2] [_UU]

So far so good, the RAID5 is running and has not touched the data by any resync attempt. So try to mount it readonly and see what happens.

It if worked, great. Backup your data and carry on your life. If not, stop the array try another order. Treat 'missing' like any other disk and move it around also. Perhaps get out a bit of paper and work out all the possible combinations to try.
$ mdadm -S /dev/md7 $ mdadm --create /dev/md7 --level=5 --raid-devices=3 -f /dev/hda1 missing /dev/hdd1

Keep repeating this until the array successfully mounts your file system.

When it has finally worked, and you've backed up, you can add your new disk back in. The array will resync your data across all three disks (or whatever number you have) and everything will be back to normal.

Dell Poweredge 1950 with Intel Quad Port Ethernet

techuser — Wed, 19 Mar 2008 19:57:37 +0000

Keywords:

I've spent the last couple of days configuring a batch of new Dell servers, 1950 rackmounts. A couple of them have Intel four port cards fitted (PRO/1000 Quad Port) and need to run Linux (the rest, FreeBSD).

The servers were bought from Dell on the understanding that they'd be immediately compatible with a bog-standard Linux install.

Well, I've been bitten by that before. Do NOT let sales people to spec a computer. Do NOT trust Windows users to spec a Linux machine.

Before we get to the add-in card, let's look at the internal pair of ethernet ports. With FreeBSD these were fine - FreeBSD's driver support is surprisingly robust. Something for Linux developers to take a look at perhaps?

Under Linux I had a significant problem: they did not work.
To cut a long and arduous tale short (this was a WHOLE day wasted):

1. The Dell machines ship with TOE (traffic offload engine) enabled. No good. Firstly, it doesn't work with Linux. Secondly, when they do work, it's with binary drivers. Thirdly, when your machine is going to be a firewall, you don't want some feature-sparse hardware taking over from the highly tuned Linux firewall stack you're using.

To disable TOE is fairly simple: pop the top off the machine, and somewhere around where the power plugs into the motherboard is a little dongle, a little like an ethernet jack. Remove it. The hardware is built into the motherboard, but somehow we seem to have been sold the dongles - I assume they're like licenses.

2. The ports are reversed! eth0 attaches to port 2, eth1 to port 1. I can see this being a support issue in years to come.

Onwards to the add in card: again, did not work. Thank you Dell, I suppose zero out of two isn't bad really. It could have exploded when I plugged it in?

There is no support in the Linux kernel for this new Intel card. Intel's own site takes you to the e1000 driver modules. Well, I thought - maybe that's because they're an updated version compared to the e1000 in the latest 2.6.24 kernel patches? No. Still did not work.

Eventually I find my way here: http://sourceforge.net/projects/e1000
Sourceforge.net has a newer version of Intel's own e1000 driver, .5 verses .4!
But also I find that there is a new driver for the newest gigabit hardware: igb. Aha, maybe this is what I need? Yes, one rapid download and 'make install' later, the ports fire into life. "igb" is the driver to try if you have a new Intel quad port card. Hopefully this will make its way into the kernel otherwise supporting the machine with kernel upgrades is bound to fail eventually when someone forgets to put the drivers back on - thankfully this is part of a high-availability firewall, using Heartbeat (and lots of bash/ifconfig/ip/tc/iptables scripting). An identical second machine will come online within seconds when the first fails.