Archive for the ‘Computing’ Category

FreeBSD filesystem snapshots

Monday, November 10th, 2008 in Computing, FreeBSD

I’ve been looking at filesystem snapshots on FreeBSD lately and I have to say I wasn’t too impressed. Yes, the functionality is there, but the interface sucks. For UFS you have to create a snapshot, which takes a while, and which appears as a file within the filesystem you’re snapshotting. Then you have to use an md device to mount it. ZFS is easier, but different. What we need is a simple and standard interface to both.

Fortunately I discovered Ralf Engelschall’s snapshot management utilities. He’s written a couple of tools that make creating and managing snapshots really easy.

Using cron one can schedule creation of hourly, daily and weekly snapshots for filesystems. You can specify that you want 3 hourly snapshots, 2 daily and 1 weekly for a given filesystem. The system takes care of everything else. And by using amd (the FreeBSD automounter) these snapshots can automatically be made available through a given mount point. It couldn’t get any easier!

Well, actually, it could get slightly easier. Currently these tools are available from Ralf’s site or from the FreeBSD ports collection. It strikes me that something as useful and fundamental as this should really make its way in to the base system.

Update: Whilst this worked well in testing, once I applied it to my server with a large (approx, but not over, 2TB) filesystem it hung the machine completely, even on the console. I haven’t investigated further yet.

Update 2: Well, I have to say I’m disappointed. Ralf’s scripts worked great, but the snapshotting of large UFS filesystems in FreeBSD is as good as broken. When it takes hours to create a snapshot, locking out the filesystem (and maybe even the machine) for hours, it might as well not be there. There seems to be an attitude of “just accept it”, which I’m not impressed about either. Roll on ZFS… (yes – I know it’s there now, but I’d like it to mature just a little more :-) ).

  • Share/Bookmark

FreeBSD with Netgear WG311T

Saturday, November 8th, 2008 in Computing, FreeBSD

A few days I wrote about my new Soekris net5501 router. In that post I mentioned that the only thing left to sort out was the wireless card. It turned out to be simpler to do than I thought.

I decided to go for a Netgear WG311T. It’s a 802.11b/g PCI card that’s compatible with FreeBSD through the Atheros chipset and ath driver, and it fits in the net5501 just fine. As expected I had to remove the net5501 board from the case to attach the card, but that only involved undoing a handful of screws.

Getting it working on FreeBSD was trivial. I added the following lines to my kernel configuration (they’re already there in GENERIC, I believe, but I built my own kernel because of the net5501):

device wlan
device wlan_ccmp
device wlan_scan_ap
device wlan_scan_sta
device wlan_xauth
device ath
device ath_hal
device ath_rate_sample

Then it was a simple case of initialising the card in /etc/rc.conf:

ifconfig_ath0="inet 1.2.3.4 netmask 255.255.255.0 ssid myssid mode 11g mediaopt hostap"
ipv6_ifconfig_ath0="1:2:3::4 prefixlen 64"

And I also added ath0 to rtadvd_interfaces and dhcpd_interfaces.

With that done the final step was to configure hostapd through /etc/hostapd.conf:

interface=ath0
debug=1
ctrl_interface=/var/run/hostapd
ctrl_interface_group=wheel
ssid=myssid
country_code=GB
wpa=2
wpa_passphrase=my passphrase
wpa_key_mgmt=WPA-PSK
wpa_pairwise=CCMP

This enables WPA2 using AES (rather than TKIP).

Connecting clients was no problem. My laptop and my squeezeboxes all connected fine.

One concern I had doing this was whether a PCI wireless card would have the same signal strength as a purpose access point. I seem to be getting the same signal power from this new setup as I did from my old 3com 802.11b access point. What does that tell me? I’m not sure. I would have expected technology to have come on a bit over the years. Maybe it has, but the fact that the card is lower powered balances it out? Regardless, it covers my whole house, so it’s not an issue.

So now I’m done. I’ve switched off my last piece of old equipment. My power draw has dropped significantly, the noise levels have decreased, and I’m a happy geek with a cupboard full of shiny new stuff. :-)

  • Share/Bookmark

Current Cost Electricity Meter

Wednesday, November 5th, 2008 in Computing, General

It seems to be the “in thing” to do at the moment; get a Current Cost electricity meter and produce pretty graphs. I couldn’t resist, so I picked one up with a USB cable to connect it to my server.

The system itself is trivial to install. There’s a box with a clamp that attaches to your mains supply (your side of the house meter), and a display which can be placed anywhere in your house (within the wireless range of the two units). Turn it on and it just works. I adjusted the electricity prices, but it’s not clear how accurate that’ll be given the multiple tiers of pricing we have.

So even without connecting it to a PC it’s a pretty useful device. Although I am developing a habit of running around looking for what’s caused the usage to jump up. Hopefully that’ll pass :-)

Connecting it to my FreeBSD server took a bit of effort. It needed the ucom module, but (I think) because I had ugen built in to the kernel it was using that instead. A kernel rebuild to include both fixed it. I also got some strange issues connecting to the device. On the first connect I got the expected XML output, but on the second connect I got messed up output. Turns out not to happen when I use my script to parse the data, so I don’t think I’ll worry about it.

I did the graphing using rrdtool. I’d like to take the credit for doing that, but I just stole all of Paul’s work. Thanks Paul :-)

The excitement has gone now, but I’m sure over time the data will prove to be interesting and useful.

  • Share/Bookmark

A new router (Soekris, Draytek and NanoBSD)

Wednesday, November 5th, 2008 in Computing, FreeBSD

A few months back I wrote about building a new server. It turned out to be more complicated than I thought, but 5 months on it’s still working well. Over the last few weeks I’ve been working on my next project – replacing my router.

The old router was an old dual CPU Pentium 3 machine with a couple of small SCSI hard disks in it. It was a full tower case and took up a lot of room and made a lot of noise. And, surprisingly, the power consumption was pretty similar to the server I recently built (which has way more in it). It even still had the original Speedtouch USB modem that BT once gave to me. So it had to go.

I spent quite some time deliberating the way forward. I could have gone for a domestic router like most other people do, but I’m a geek, and I like the flexibility of doing it myself. But at the same time, a small sized unit, with low power requirements, and no noise, is what I wanted. The solution came in the form of a Soekris net5501.

I went for the net5501-70 which has a 500Mhz CPU and 512MB of RAM. Not a lot by today’s standards, but more than sufficient for what I needed. And incidently, it’s quicker than the old router. I got the model with a case, and got the mounting brackets for a hard drive (which although I don’t intend to use at this stage, it was cheaper to get it now than later). I also purchased a pair of 4GB SanDisk Extreme III Compact Flash cards to run the thing from. It’s worth noting that Soekris recommend SanDisk CF cards, and they’re peanuts at play.com.

The next point to consider was how to connect to the ADSL line. I could have stuck with the USB modem, but the drivers were aging, I wasn’t sure if it was the cause of the odd disconnections and failures to reconnect that I’d been getting. I looked at internal ADSL cards, but it seemed to be a bit of a gamble as to how they worked and if I’d be able to get the right drivers. In the end I settled on the Draytek Vigor 110.

The Vigor 110 is basically just a PPPoA to PPPoE bridge. PPPoE isn’t widely used in the UK, but is in other parts of the world, so the support in FreeBSD was good (via ppp and the ng_pppoe module). It worked perfectly. It really was just a case of plugging it in and pointing ppp at it – no configuration required! And, just like the USB modem, it gives the router IP directly to the PC, so there’s no messing around to get that working either.

Longer term I plan to fill the net5501’s PCI slot with a wireless card, but I haven’t decided which to go for yet. This would turn the unit in to my wifi access point as well, but for now I’ll just stick with the separate one. I’d welcome advice on cards that are supported by FreeBSD.

So, that’s hardware all sorted. Next came the software. If you’ve been following my other posts you’ll know I’m a big fan of FreeBSD, so it’s pretty clear what route I was going to take here. But given the use of CF cards I had to approach things differently. I also wanted to be able to power the system off without causing any filesystem problems, so this required the card to be mounted read-only.

NanoBSD to the rescue! NanoBSD is a script that builds an image containing FreeBSD that can be written directly to a CF card (or anything else, really). It’s customisable, and I wrote a few bits to pull down the packages I wanted, and to make some configuration tweaks. It has a read-only root filesystem on the card, and uses memory-backed filesystems for /var and /etc. Config is stored in a separate partition on the disk and is copied to the memory-backed /etc during the boot process. But the best bit is the way it handles upgrades.

Upgrades are neatly done by having two root filesystems on the card. When you’re running off one you’re free to upgrade the other. NanoBSD generates two images; one for the entire card, and one that can be written to a single root filesystem. It also provides a script to write the image to the card and update the boot loader to boot from the right partition. So upgrading is as simple as re-running the NanoBSD script, writing the new image to the “other” partition, and rebooting. It can all be done live, and the only downtime is the time taken for a reboot (which is under a minute).

Of course, to use NanoBSD you need another system to do the builds on. Fortunately I’ve got a nice beefy server that can handle the job (although it took a few hacks to build the i386 image on an amd64 system). I’ve also got a nice Tinderbox setup which I already use for testing ports and which provided a nice supply of up-to-date packages.

So I’m happy, at last. Apart from my wifi access point I’ve managed to replace all my aging, power hungry, noisy equipment with nice new stuff. I guess I’ll be doing it all again in a few years :D .

  • Share/Bookmark

Dovecot is a neat piece of software

Friday, October 17th, 2008 in Computing, Work

For many years now (since before I started working at the University) we’ve been using University of Washington’s IMAP and POP daemons. They worked well, and (through an old bit of unsupported code) also allowed our MH users to access their email.

As time went on people wanted to do more than UW’s software could offer. Things like nested folders, and server-side caching. That’s when we started running Courier IMAP in parallel. This worked, but required users to use a non-standard set of port numbers.

At the time we looked at Dovecot, but it was fairly new, and we were unsure about trusting it with all our users’ email. That was a few years ago, so I decided this week to take another look. This was mainly driven by demand for faster IMAP access to the Maildir folders served by Courier IMAP.

My first impressions were good. I read through much of the stuff on the Dovecot wiki, and I kept thinking and saying to my colleagues “wow, that’s really neat”. Dovecot came across as a well thought out and well structured program, with a vast amount of useful tips and configuration ideas on their website. The level of customisation was good too, right down to allowing you to write a shell script to put in-line and tweak configuration to meet your exact needs.

After a few days of fiddling around I’ve managed to get a setup working that can replace both of our ageing Courier IMAP and UW IMAP installations. It should be a fairly seemless transition for our users, but I’m sure it won’t be that simple in practice. I’ve written a shell script that automatically detects at runtime where a user’s mail might be and sets the configuration accordingly. The script also allows the user to override the mail location and turn on debugging options.

And then there’s the performance issues. One of my colleagues has been having issues with the speed of Courier IMAP, and so far he’s impressed with Dovecot. The main gain here was the ability to store indexes in a separate location. Our mail is stored on an NFS server which becomes a performance bottleneck when using Maildir. Dovecot works around this by storing indexes and caches on a local disk making response times better.

Finally, there’s support. I hit a couple of issues getting things set up so I made use of the Dovecot mailing list. The response times in both cases were brilliant, and in both cases I got an answer to my problem straight away (maybe I asked common or stupid questions? :-) ).

So Dovecot comes highly recommended from me. Give it a try!

(And what about the MH users? Thankfully most have moved on to other things like Maildir & Thunderbird.)

  • Share/Bookmark

“Disc quota exceeded”

Friday, September 12th, 2008 in Computing, Work

Today we saw a strange problem on our Solaris hosts that NFS mount VxFS filestore from our Veritas cluster. The users were seeing “Disc quota exceeded” messages, whilst the quota command wasn’t showing they’d hit their limit. After some digging on the cluster node we found the following error message:

Sep 12 11:04:33 bes vxfs: [ID 702911 kern.warning]
        WARNING: msgcnt 10 mesg 089: V-2-89:
        quotas on /cluster/ResFS invalid;
        disk usage for group id 2805 exceeds 2147483646 sectors

Ah-ha! Group quota! We hadn’t even set group quotas, but it appears the system tracks the usage anyway when you mount with -o quota. Some googling turned up the following document:

http://seer.entsupport.symantec.com/docs/277535.htm

So it turns out there’s a 1TB maximum limit when using quotas. Since we weren’t using group quotas the simple option was to disable them:

vxquotaoff -gv /cluster/ResFS

Then I edited the Mount resource and changed the quota mount option to usrquota.

This only alleviates the problem for a while. Eventually someone will need to use 1TB of storage for themselves, but hopefully that’s a little way off yet. Maybe we’ll be using ZFS by then anyway :-)

  • Share/Bookmark

“Any idea WTF is going on?”

Wednesday, July 16th, 2008 in Computing, Work

“Any idea WTF is going on?” is what I read on my phone as I stumbled out of bed this morning. It was from one of my colleagues who, for some reason I can’t understand, seems to like getting in to work at a ridiculous hour in the morning.

Still half asleep I plodded through to my desk and sat down at my computer. I tried to check my email but nothing was responding. Then I saw the message “NFS server resfs.fs.cs not responding”… and woke up rather quickly. This meant either our network was shafted, or more likely, the cluster had blown up again.

I discovered one of the cluster nodes was offline and marked as failed, and the service group that manages our filestore was also marked as failed. That was odd, but it had happened before. I dug a bit further and found a screenful of SCSI errors. This was bad – something must have gone wrong with the storage.

Next I checked the arrays. The first one I checked had numerous errors on it; failed disks, missing disks, and drive not ready messages. I can’t stress enough how important this data is – it holds files, email and shared areas for all the staff and researchers in our department, and I really didn’t want to explain to them that we’d lost it all (well, we do have backups…). I nervously moved on to check the second array – they were mirrored, so as long as one was OK we’d be fine – and I was delighted to find no error messages.

So, now I knew that the likely cause of the problems was an array failing. It turned out later on to be the controller in this array, which was a good thing because Sun managed to send the wrong disks anyway. The next steps were to get the array fixed and to get things back online. I asked my colleague, who was already in the office, to disconnect the fibres from the failed array (to keep it completely out of the loop whilst it was fixed) and get on to Sun to fix it. Whilst he did that I, still at home, not dressed, and without breakfast, got on with getting things back online.

This, in theory, should have been the easy part. We had a mirrored setup so the plan was to just bring the volume back online with only half of the mirror. No problem, I thought. Except when it wouldn’t come online. When the initial problem had occured the cluster software (VCS) had failed to unmount the disk from the node it was on. It had decided that it needed to do this to bring it online on another node (little did it know that it wouldn’t work on any other node either), so as a last resort it asked the machine to panic. This is something akin to asking it to commit suicide. It duely did it’s job, but in the process left the disks in an odd state.

When I tried to mount these disks on one of the other nodes I got errors from the volume manager telling me a split brain had occured (this happens when a live cluster splits in two, but neither half can see the other). I knew that wasn’t the case, so I tried to force the mount. That failed with write errors. After a lot of head scratching I realised it was probably the I/O fencing stopping this node from accessing the disk. Whilst frustrating, it was nice to see the software behaving as it should – in a real split brain situation this is exactly what you want.

A while later I figured out how to clear the SCSI3 reservations on the disks (-o clearreserve option to vxdg import). This was nearly enough. Another issue with the split brain was that the configuration data stored on the disks didn’t quite match (I’m not 100% sure why, but I believe the node that paniced hadn’t managed to consistently update the metadata). After dumping the configuration it was clear that they were identical, bar a revision number, so by using -o selectcp we were able to get the diskgroup imported.

vxdg -fC -o clearreserve -o selectcp=1128804183.107.qetesh \
    import ResFS

Success! The diskgroup was online. From here it was just a case of waiting for fsck to confirm everything looked OK and then unleashing VCS to bring the service group back online.

By this point Sun had sent out an engineer and parts to fix the other array (we get a good service from them, thankfully). That’s currently resyncing its disks, which will take a day or two. Once that’s done we’ll hook it back in to the fibre fabric and bring things back online. It’ll take just as long again to resync the data, but all I have to do is sit and watch :-)

Finally, after hours of investigation I finally found out the cause of all the problems. We’ve just ordered a newer, bigger array. The old ones are just jealous.

(And a quick thanks to Pete for his help in debugging things this morning :-) )

  • Share/Bookmark

FreeBSD stuff

Wednesday, July 16th, 2008 in Computing, FreeBSD

I’ve done a bit of work on my FreeBSD ports lately. Firstly, after building my new server, I got round to upgrading from SlimServer to SqueezeCenter. This also meant sorting out ports for all the plugins I use. This didn’t take too long, and you can find them all over here. So far I’m liking SqueezeCenter, and I’d highly recommend it (and a SqueezeBox, of course).

I also maintain a port for a suite of software called KRoC. KRoC is written and maintained where I work, so apart from making it available to FreeBSD users I also have an interest in supporting the work done by our department. I’ve been waiting some time for a 1.5.x release of KRoC, but I finally got impatient. I automated the production of snapshots from their stable branch, and updated the port to build from that. I also run a FreeBSD 7 machine in their buildbot system to further test KRoC on my favourite operating system :-)

And in other FreeBSD news, I cast my vote in the FreeBSD Core elections. It’s hard to know who to vote for, but I gave their statements a good read and made a decision. Good luck to them all!

  • Share/Bookmark

“I’ll build a new server; it’s got to be easier than patching up the old one…”

Thursday, June 19th, 2008 in Computing, FreeBSD

A few weeks back I started having problems with my file server at home. This machine is fairly important to us; it holds all our photos, music and other files. For years I’ve been bodging it together with various old parts scavenged from other machines and some new parts when needed. But, once again, it’d started to break. Disks were dropping out of the RAID unexpectedly, and the replacements were refusing to rebuild. Unsure of where the problem was I uttered the fateful words “I’ll build a new server; it’s got to be easier than patching up the old one…”. My colleagues were sceptical, but I ploughed on anyway. Maybe I should have listened to them?

It took the best part of a week to work out what I wanted. There were so many decisions to make: which RAID card, disks, motherboard, CPU, RAM, case, etc. I researched each one as much as I could, but there’s a bottomless pit of information on the Internet. Eventually I settled on a 3ware 9690SA RAID card with 4 Seagate ST31000340NS disks. The other bits were fairly decent to make sure the machine would have a good life, but not excessive.

The reason for choosing a hardware RAID solution over software RAID was simple – reliability. Now, I’m not knocking software RAID in principal (look at ZFS, for example), but the implementations for RAID 3-5 on FreeBSD aren’t great (yes, it has ZFS, but I’m not in the mood for trailblazing this time round). I wanted to stick with FreeBSD so I opted for the well known reliablity that 3ware cards provide. And the 5 year warranty on Seagate disks made them an attractive choice.

The purchasing process wasn’t as simple as it could have been. I ordered from dabs.com, span.com (they specialise in storage stuff) and overclockers.co.uk. I’ve used all three companies before, so I wasn’t too concerned about problems. The bulk of it was ordered from Dabs – it looks like they’re back to being competitive on prices. The problems started almost immediately; Dabs held my order over an issue with my address. It’s happened once before and that put me off Dabs for some time, but we use them all the time at work, so I had hopes they’d be better now. It took a working day to resolve that issue… and then next day I get an email to say my credit card company has declined the order. On the phone to them and through to their security department; seems buying lots of stuff online is unusual… not for me it isn’t. Anyway, that was resolved and then I had more waiting for Dabs to try the transaction again. Eventually I got impatient and tried their online chat thing and the matter was resolved in minutes. Meanwhile the parts ordered from the other two suppliers were sitting on my desk.

Eventually it all arrived and I took it home. Ruth wasn’t overly impressed when I cleared off the dining room table and covered it in computer parts, but I assured her it wasn’t for long. That was a couple of weeks ago – it’s all still there.

I spent a weekend putting things together and testing it all out. I routed every cable neatly and tied them carefully to the case to ensure nothing moved about. Airflow was good and the additional fans in the case were doing a great job of keeping things cool (not sure about their blue LEDs though…). All was looking good and I was enjoying the process.

Then I tried to use the RAID card. The first problems hit when I turned on the motherboard’s RAID, which I’d intended to use to mirror the system disks, whilst the 9690SA was plugged in. I’d gone for a Asus P5E3 and expected both RAID systems to work happily together, but sadly I was wrong. I experienced unusual problems such as the machine hanging on the Intel Matrix Storage (the onboard RAID) screen and disks randomly disappearing from both arrays. In the end I gave up and turned off the onboard RAID; I figured the FreeBSD RAID 1 (gmirror) is pretty solid, so I’d use that.

Thinking I’d got over the worst of the problems I moved on to setting up the 9690SA. Things looked good for a while; the interface was clear and everything was easy to set up. It wasn’t until I started trying to put data on that I noticed problems. Here’s a snippet from the error log (largely for the benefit of Google):

E=0200 T=08:26:00 : Cable CRC error
SATA Device. port = 0x0
task file written out : cd dh ch cl sn sc ft
                      : 00 70 00 00 00 1200 00
  task file read back : st dh ch cl sn sc er
                      : 00 00 00 00 00 8441 00
E=0200 T=08:26:00 P=0h: Soft reset drive
E=0200 T=08:26:00 P=0h: exitCode = 1013
Port retry not allowed
E=0200 T=08:26:00 P=0h: Prepare for command retry
exitCode = 1013

At first I wasn’t sure what to make of this. Maybe it was the cable or connection, but on all four drives? It was a special 4-in-1 (SFF8087) cable, but it still seemed odd. I logged the case with 3ware’s technical support and got back a response suggesting I try another cable. Well, duh, I could have figured that myself. I was hoping they might be able to point out any other less obvious potential causes.

So, I purchased another cable. It took a couple of days to arrive and did absolutely nothing to resolve the problem. Sigh. At the same time as this was going on I had another problem – it’s only with hindsight that I know to separate the two:

E=0204 T=18:34:36     : Port timeout (ext)
SATA Device. port = 0x2
task file written out : cd dh ch cl sn sc ft
                      : 00 04 00 00 00 00 00
Send AEN (code, time): 0x9, 06/10/2008 18:34:36
Drive timeout detected
(EC:0x09, SK=0x04, ASC=0x00, ASCQ=0x00, SEV=01, Type=0x71)
phy=6
  task file read back : st dh ch cl sn sc er
                      : 00 00 00 00 00 00 00
E=0204 T=18:34:36 P=2h: Soft reset drive
E=0204 T=18:34:36 P=2 : Inserting Set UDMA command
E=0204 T=18:34:36 P=2h: Check power cycles, initial=40, current=40
E=0204 T=18:34:36 P=2h: exitCode = 1013
Port retry not allowed
E=0204 T=18:34:36 P=2h: Prepare for command retry
exitCode = 1013
E=0204 T=18:34:36 U=0 : Retrying command

These errors happened less frequently, but eventually caused I/O to hang and the controller to reset. Again I logged this with 3ware’s technical support and got back a bunch of not so helpful responses. They suggested moving the card in the machine, testing the disks, checking the power supply, and so on. All valid points, but what annoyed me was they could only ask me to check one at a time… and they could only reply to me once a day. Plus I’d already done everything they suggested. It took a week to go through this nonsense.

In the mean time I spent a lot of time experimenting, fiddling, and web searching. Eventually I found the following two pages, although it took me a while to realise their significance:

http://www.3ware.com/KB/article.aspx?id=15385
http://www.3ware.com/kb/article.aspx?id=15171

The first of the articles explicitly mentions my controller card and drives, so it seemed to be the right thing to do. But I had the SN04 firmware on my drives and they wanted me to apply AN05. I asked both 3ware and Seagate to clarify the differences, but neither gave satisfactory answers. Seagate managed to give me the SN05 firmware to try, but it didn’t help. In slight desperation, and without anyone giving me much help, I decided to take a punt on the AN05 firmware.

IT WORKED!

There was a lot of tension for the next few hours whilst I continued testing, but eventually I was satisfied that the AN05 firmware solved the problem. Later attempts to clarify with Seagate why SN05, which they gave me, didn’t work and AN05, which 3ware pointed me at, did work, got nowhere. Seagate support actually admitted that they basically don’t know.

So on to the next issue. The second article suggested limiting the speed of the drives to work around the drive timeout issue. It’s definately a workaround, but it was worth a shot. I’d already removed the jumpers from the drives that limited them to 1.5 Gb/s, and they were a nightmare to do – I’ve never seen such small and fiddly jumpers on a disk… it was completely unnecessary given the available space. This time I decided to do the limiting in the 9690SA’s software.

ONCE AGAIN, IT WORKED!

So at this point I’m happy. Things are looking good. That last fix is definately a workaround, and I’ve told 3ware they need to fix it. It’s a bug, and bugs need fixing. I’m now using the array to store my data on, it’s nice and quick (a 512MB write cache helps!), and I have plenty of space. And Ruth might get the dining room table back soon… assuming I can work out how to lift this massive machine (did I mention the case was quite big?).

But I’d like to finish this post with a rant. It turned out that the solutions to my problems were both in the 3ware knowledge base. Now maybe I should have searched harder initially, but it took me some time to find these articles. But more to the point, 3ware support should definately have known about these issues and should have directed me straight to them. I wasted a week of my time messing around with them, and I’m not happy about it. The card is great (apart from the aforementioned bug), but the support sucks. It will seriously make me think twice about going with 3ware again.

I hope this post will fill in the whole story to those I’ve been ranting at recently, and maybe it’ll help someone else on the Internet out if/when they hit the same problem. That’s assuming they can read this lengthy post in less time that in takes to figure out the solution themselves ;-) .

Good night.

  • Share/Bookmark

Connecting to an LDAP server using Kerberos authentication in Perl

Friday, January 18th, 2008 in Computing

It took me a while to figure this code out, and there seemed to be a lack of complete examples on the web to do exactly this, so I thought I’d document it.

I needed to connect to an LDAP server using a Kerberos principal for authentication from within a Perl script. This meant that it needed to do it without any external input, so it couldn’t rely on a password being entered or someone doing a kinit first.

The code is fairly simple. It basically gets the right credentials using a pre-initialised keytab and then sets up the relevant objects and uses them to bind to an LDAP server.

#!/usr/local/bin/perl -w    

# How to connect to an LDAP server using GSSAPI Kerberos auth.    

use strict;    

use Net::LDAP;
use Authen::SASL qw(Perl);
# This module makes doing the kinit much easier
use Authen::Krb5::Easy qw(kinit kdestroy kerror);    

# Location of the keytab which contains testuser's key
# exported in kadmin by: ktadd -k /tmp/test.keytab testuser
my $keytab = '/tmp/test.keytab';
# Where to store the credentials
my $ccache = '/tmp/test.ccache';    

$ENV{KRB5CCNAME} = $ccache;    

# Get credentials for testuser
kinit($keytab, 'testuser@CS.UKC.AC.UK') || die kerror();    

# Set up a SASL object
my $sasl = Authen::SASL->new(mechanism => 'GSSAPI') || die "$@";    

# Set up an LDAP connection
my $ldap = Net::LDAP->new('ldap.cs.kent.ac.uk') || die "$@";    

# Finally bind to LDAP using our SASL object
my $mesg = $ldap->bind(sasl => $sasl);    

# This should say "0 (Success)" if it worked
print "Message is ". $mesg->code ." (". $mesg->error .").\n";    

# Clear up the credentials
kdestroy();

Hopefully this will help someone else out. Comments welcome :-)

  • Share/Bookmark