Archive for December, 2007

Another year over…

I’ve read a few “this was my year” blog posts in the last day or so; no doubt I’ll read a few more in coming days. I honestly can’t remember much of positive significance happening this year, compared to last year (which was huge). For a few reasons though, I am glad that this year is nearly over and that a new one is about to begin.

I can’t say I’m disappointed about 2007, although I do feel I would like to have “achieved” more. From a work perspective, I did no conferences, and I wrote no papers. I did keep some servers from failing, though, and helped a few folks with some problems they had.

I think it’d be great to understand why folks attach so much significance to the change of the calendar. The symbolism of “turning a new page” happens every day; why do we disregard that and think only of the new Year? It’s no wonder so many folks fail in their New Years Resolutions — the intimidation of having to keep to a promise you make yourself for a whole year is enormous! And we never choose anything simple, do we? Resolutions are always “lose thirty kilos in time for Gracie’s wedding” or “stop smoking” or “try and be a better person”. Achievability is sacrificed in the face of having to make a huge gesture in the face of tons of brightly-coloured explosives going off in the air above us (or on the television in front of us).

So, for me this year, I am making one New Year’s Resolution: to not make any New Year’s Resolutions. I’ll be making New Days Resolutions instead — every day, I will think of something I can do with that day. When I do it, I’ll be able to enjoy a little celebration of having achieved my Resolution. But what to resolve? Well, little things that add up to something big. Fixing my corrupted LDAP database, for example (for Susan to get her address book entries back). Taking myself out of the house and walking (to improve my health). Cooking dinner for the family (without being asked). Ringing family and friends for a chat, without having a reason.

The best part of this plan is that by the end of January, when I’m surrounded by miserable folks bemoaning the demise of their New Years Resolutions, I’ll have celebrated thirty-one Resolutions and be feeling great! :)

Some of you reading this are saying “hang on, those ‘Resolutions’ are all stuff that people do every day, how can you make Resolutions out of that?”. Well I’m sure many people do these things daily, but they’re not me. Everyone’s life is what they make of it, and many of us (me included) need to realise that a little effort trying to do big things doesn’t work — what’s needed is a big effort on the little things.

The best thing about 2007 for me was feeling signs that I’m getting better — getting my head out of whatever place it’s been in the past few years. Work still sucks, and is actually getting worse, but that’s not the crushingly depressing thing it would have been two years (or even twelve months) ago. If 2008 holds more of the same improvement then that’ll be fine with me.

Happy New Year, readers… Best wishes for prosperity and happiness, wherever you are and whatever you wish for!

PoE again: this time, success!

I had pretty much forgotten about improving on the Power over Ethernet progress I mentioned previously. A couple of weeks ago I bought another 7970 that I successfully converted to SIP to run in the study, and I was considering buying a few 7961s or Linksys PoE-capable phones to use in other places. However, I got an e-mail from a reader whose success at using a hacked cable with his 7960G prompted me to have another go.

While I did a heap of research about PoE and IEEE 802.3af, the hints I got about using a hacked cable with a standard 802.3af switch to power a Cisco phone came almost exclusively from the voip-info.org wiki. Everything I’d seen about this trick relied on the use of a crossover cable to fix the problem where the phone using the Cisco pre-standard expects the power in the opposite polarity to that delivered by 802.3af.

When I’d had a go previously, the info I had told me that I had to get power onto the spare pairs in the Ethernet cable, because the Cisco pre-standard used the spare pairs for power and not the data pairs. This was a problem as my switch provided Type A PoE, which is power-over-data-pairs. In the end I figured that I’d have to come up with some kind of electronics to get the power off the data pairs and onto the spare pairs.

My friendly reader informed me, however, that Cisco pre-standard phones take power from the data pairs as well as the spare pairs! Nothing I’d seen indicated that this was a possibility. So I pulled out the hacked-up cable I’d used previously and gave it another try… but it didn’t work.

I tried a bunch of alternatives that I probably tried before as well. I tried putting the sense resistor across the spare pairs instead of the data pairs, I tried switching the spare pairs around. But, since others had only ever reported success with a crossover cable, it had never occurred to me to try a straight cable instead. A bit of resoldering later, another try, and it worked!

Tried it with all my 7960s and it worked fine. So it looks like some 802.3af switches put power on the pairs in the opposite polarity to others (which is not a problem usually, as 802.3af devices have a bridge rectifier that allows them to handle either polarity).

Thanks to my friendly reader, I now have a way to power all my Cisco phones via PoE! Yay! The only caveat (one that I’ve only seen briefly mentioned anywhere) is the extra load placed on the cable by the 25kohm sense resistor — doubt it’s significant, but over a few phones it might add up.

Tags: , ,

pam_ssh

Ages ago, I read or saw something about using your SSH passphrase to log in to your system. Seemed like a good idea, but I never got around to implementing it. One of the methods available is a PAM module called pam_ssh. I just gave it a test on a Ubuntu Gutsy system, and it works surprisingly well (Edit: except for GNOME integration…).

On my Gutsy system it was a simple apt-get install libpam-ssh to install (it’s in Universe). Once installed, you need to enable it by changing your PAM configuration. The package provided a couple of sample files in the PAM configuration directory, pam-ssh-auth and pam-ssh-session. You can take these files and copy them into the relevant part of your config.

For the “auth” section I elected just to add the right line to config-auth. What is the right line for you depends on whether you want to still prompt for the Unix password or not (some folks seem to want to use pam_ssh as a supplementary login, a bit like two-factor authentication). For me I wanted to be able to log on with either SSH passphrase or Unix password, so I added a new line like this:

auth sufficient pam_ssh.so

and changed the “pam_unix” line to look like this:

auth sufficient pam_unix.so try_first_pass nullok_secure

The important change is to make sure that “required” on the pam_unix line is change to “sufficient” — this ensures that login can proceed with either the correct passphrase or the correct password.

For the “session” section I simply added the line as suggested by the package maintainers:

session optional pam_ssh.so

With PAM modified I jumped to a virtual console to try a TTY login:

Ubuntu 7.10 columbia tty1

columbia login: vicc
SSH Passphrase:

I entered my passphrase, and was warmly greeted with a command prompt. Hooray! The further test was yet to come…but it passed with flying colours. The ssh-agent that PAM started for me seemed to work a treat, as I was able to login to my servers without password or passphrase prompts.

Now to try a GDM login. I was expecting that there would be a problem with the ssh-agent automatically started by the GNOME login process. However, I was pleasantly surprised to find that GNOME didn’t start another ssh-agent, and my SSH logins from gnome-terminal were again password-prompt-free!

I tested to make sure that logins worked with either passphrase or password, and they do — the only difference is that (obviously) the SSH key is not added to the running ssh-agent when the password is used to log on instead of the passphrase.

I made one minor change from my first trials. I found that the “SSH Passphrase” prompt I saw on the console login also appeared on the GDM login panel. I looked cool to me, but since the machine I was using to test is my wife’s laptop I figured that I had better make the change as transparent as possible. So, I reversed the order of the “auth” lines to make pam_unix.so appear first. I had placed pam_ssh.so first originally in order to make sure that SSH was tried first, but it doesn’t make any difference to the results… and since PAM displays the prompt text from the first module in the order[1], putting pam_unix.so back to the top of the list gives a “normal” login box.

Once you’re logged on, if you made the PAM change as shown to the common config files (on Ubuntu, the common-* files, on others it may be system-auth for example) you can continue to use either password or passphrase for things like sudo prompts and screen saver unlocks. If you included the change in only a specific PAM config, your ability to use the SSH passphrase applies only to that application[2].

I’m keen to try this out on other systems, if only to eliminate the additional “ssh-add” run I currently have to do to get my key into an agent. I’m also keen to try it with KDE to see if it also doesn’t start its own ssh-agent.

While this module seems to work really well, you may have to check a couple of things for yourself before using it. One is that the project pages on Sourceforge appear to be dead: the last released version was in 2004 and there has been no developer response on the open bugs in the tracker. Secondly, while I had no trouble finding Ubuntu packages, a Gentoo ebuild, and documents about its inclusion in OpenSUSE/SLES, if you use RHEL I don’t believe it’s in a standard repository (in Fedora it’s in Fedora Extras which I think doesn’t bode well for RHEL).

Lastly, and probably the most serious point, is that if you decide to use pam_ssh and your current SSH key has a blank passphrase you should think VERY seriously about setting one. If you use your blank-passphrase key to log on to your computer, you are giving free access to anyone who walks up to your computer and enters your username — not only to that computer, but to every other computer that your SSH key provides access to. Admins of multi-user systems that use pam_ssh should make sure that “nullok” or “nullok_secure” doesn’t appear on the module line that prompts for the password, to ensure their system doesn’t create the opening for an exploit. Also, organisations that use SSH keys for authentication need to give some thought to either centralised generation of SSH keys for staff, or testing/verification of passphrase strength.

Despite the negatives, I’m impressed by pam_ssh. It’s easy to set up — it’s taken me longer to write this blog post than get the module working! — and it works well.

[1] When use_first_pass is coded on second and subsequent “auth” lines, those modules will never prompt for a password themselves. With try_first_pass, a subsequent module might generate a prompt if the password that filters down is not correct and the module wants to get a new password to try.

[2] This page has an example of using pam_ssh for XDM only, by editing the PAM config for XDM only.

Edit: Turns out that by using “sufficient” in the PAM “auth” config things break. I was using sufficient as a short-circuit to avoid having to enter both SSH passphrase and normal password (for the case where the passphrase is different from the password). I ASSuMEd that all the PAM applications had no additional auth settings after the inclusion of config-auth, but I was wrong: the PAM setup for GDM has the config that brings in pam_gnome_keyring (the module that automatically unlocks the GNOME login keyring). By using “sufficient” in config-auth for the pam_ssh and pam_unix modules, the pam_gnome_keyring module doesn’t get invoked.

I could change “sufficient” to “required” again, but this will break (preventing an otherwise valid login) in the case where the user has no SSH key. Forcing all users to create an SSH key would get around this; possibly not hard to automate at userid creation time, but tedious for those with existing IDs.

What I think I need is something like the difference between “required” and “requisite”. Both “required” and “requisite” modules have to return ok in order for the entire stack to return ok, but if the module returns not-ok “required” allows subsequent modules to be executed whereas “requisite” exists immediately. “sufficient” seems to be like a kind-of affirmative “requisite”; I need an equivalent to “sufficient” that will pass control to later modules but not consider the failure of a later module as failure of the stack. I’m pretty sure I can do this with the extended control syntax but it might take some mucking about.

I also feel the need to restate something I mentioned in the original post about centralised generation of SSH keys. Much of the advice about using SSH keys for logging on to systems is written from the user perspective, and goes along the lines of “generate your own key, so that only you have the private key and no-one else has a copy”. I agree with this (and would fight for it) as a user of SSH, but as a system admin for systems that allow login via SSH key I tremble at the thought that my users might have SSH keys with no passphrase.

This is one of those areas where trust and responsibility are required on either side: sysadmins must trust their users not to do stupid things, and users must not abuse that trust by acting irresponsibly when creating keys. In my opinion as a sysadmin (and part-time commentator on things security), the convenience of interactive login using SSH keys is a privilege rather than a right, to be withdrawn if necessary to maintain the integrity of the system and the network.

I accept that SSH keys with no passphrase are a necessity for some system automation tasks. That’s why I said “interactive” in my previous statement. Enforcement of a good passphrase for a key used for interactive logins though is tricky. A modification to pam_ssh, to reject the use of an SSH key with a weak or empty passphrase — kind of a built-in pam_cracklib — might be one way. Regular sweeps of user home directories to look for keysets with no passphrase might be another (be careful to update any Acceptable Usage statement or equivalent, to ensure your users know upfront that they’d be subject to this however). It might just be as simple as making sure “nullok” is not coded for the pam_ssh module, as I mentioned originally.

WIP330 progress: it’s a… phone

A while back I posted about my grief with the Linksys WIP330 WiFi SIP phone (it doesn’t happen often, but it’s a surprise when the ONLY hit you get on Google about a problem is your own blog post discussing it).  The unit is still a bitter disappointment, but thanks to a firmware update it seems like it’s finally at least usable on my network.

My previous post talked about problems I was having with the network connection dropping out after an hour on a WPA-PSK network.  When last I checked, the most recent firmware was no improvement in that regard.  However, I checked again last week and a couple of new updates to firmware have been released.  You need to go to Linksys’ US site to download the recent firmware though (Australia only has the 1.02.12S version that is a problem for me, while 1.03.18S is on the US site).

I also had problems using the phone menus to do the upgrade.  The WIP330 has a menu selection that lets you enter a URL for the phone to download its own firmware update, but this didn’t work for me.  I suspect it’s because the Linksys site that the firmware is hosted on is using an expired SSL certificate…  Downloading the file to my desktop and uploading the firmware through the phone’s web page worked fine as an alternative method.

The phone has been on my WPA network all day continuously now, and it makes and receives calls without drama.  I’ve never had the problem that some folks report where the phone ignores incoming calls.  So, as a phone, it’s functional and I’ll be including it in my ring groups and queues now.  As a Wi-Fi device, though, it’s still short.  For something that’s supposedly built on Windows CE, there’s precious little PDA or network function in it.  

The two things I thought I could do with the unit (other than just use it as a phone) have both come up busted.  First was to use the “web cam” function to grab rain radar images from the Bureau of Meteorology — but the function only seems to work with actual web cams that generate a Windows Media stream, and not just an image that refreshes at intervals.  Next, when I found that you can use the web interface to upload and download data such as the phonebook, I thought I could write something that dumped my LDAP contact database into the right format to upload to it.  I still could, if I could hack the crappy VB/.NET encrypted file format they use on it.  Bah, humbug.

There’s talk on the ‘Net about folks who load CE device drivers and play with it from Windows, so maybe if I was a Windows user there would be more I could do with it.

One thing I will do with it is try it on public Wi-Fi.  That’s the only differentiator I can see between it and a normal cordless phone attached to an ATA — you certainly shouldn’t buy one of these just to use at home.  If it’s fairly easy to strap up to public Wi-Fi then it becomes much more useful (but then I have to wonder how often I’m near public Wi-Fi and needing to make a call I couldn’t make on a normal mobile… it might have been useful when I was stuck in Melbourne airport for three hours the other week though).

Now that it stays on the network I can use it as a phone.  Fine.  I still regret not knowing in advance about the iPod touch, because I would rather have put that money toward the touch…

Tags: , , , , ,

OpenSolaris on System z

It’s all the rage on YouTube, apparently…  posting video of a z/VM system booting something.  Only kidding, this is a good piece of tech.  If you search YouTube for “OpenSolaris System z” you’ll find a set of five videos that show an interview (recorded at the recent Gartner datacentre conference) with David Boyes of Sine Nomine Associates demonstrating OpenSolaris running on an IBM System z mainframe.  It’s a great achievement, and a fine piece of work — but there’s a catch.

I can’t stress enough what a great job David, Neale (Aussie, Aussie, Aussie!), Adam and everyone at SNA have done.  Networking is not there yet, but I trust it’s not far (need a hand fellas? (: ).  It must have been a hard slog, and for some (particularly Neale) perhaps brought some unpleasant memories (anyone remember Bigfoot?).  Congratulations are deserved.  I can see the lolcat now: I IS SUN. IM IN UR MANEFRAYM, KIKIN OUT YR PENGUINZ.  YA RLY!  Only joking!

The catch is, ironically, the aspect of the port that makes it most useful in the “real” world.  The guys have made the port dependent on z/VM.  Don’t get me wrong, it’s the right thing to do — without z/VM, you can’t play to the strengths of the System z platform and it’s capabilities for massive resource sharing in a virtualisation environment.  Many believe that Linux on System z should have been taken in the same direction, as other platforms (like System p) do big-single-Linux-footprint better than what System z does.

The twist is that by tying the OpenSolaris port to z/VM, they’ve eliminated a set of would-be hackers from contributing to the effort.  Those with motivation, time, skill, and a big Intel box who can get a couple of hundred MIPS out of Hercules.

There are, rightly or wrongly, a lot of people who think that Solaris is a good platform.  These are the kind of people I’m thinking of — maybe folks who have always derided the mainframe, but perhaps are now thinking “gee, well if it runs Solaris now, it can’t be all bad.  Maybe I’ll check it out”.

Obviously I can’t speak for Sun (nor for IBM or SNA), but I’m sure I read that one of the objectives of OpenSolaris was to get Solaris into more hands and to try and benefit from the “millions of set of eyes” effect that Linux enjoys.  It seems ironic then that the first “non-Sun” platform to which OpenSolaris has been ported is one that doesn’t contribute to that goal.

Not to worry.  David at SNA has stated that they are committed to releasing their work to the community.  This will be the point at which an interested party could look at the code and potentially rip out or rewrite the z/VM-specific bits and replace them.  It wouldn’t be impossible — even CMS was able to IPL standalone once upon a time — but it would be a huge piece of work (no doubt part of SNA’s reasoning was to let z/VM do a lot of heavy lifting for I/O and such tasks; that would have to be written for OpenSolaris).  Bags I not-it.  Likewise, our potential interested party would be very likely to turn away to Linux… or even away from System z entirely.

Meh, enough doom-talk.  I’ve downloaded three different flavours of OpenSolaris for x86 (NexentaOS which I had a brief look at previously, Solaris Express Developer Edition, and something that called itself the “Indiana Preview”) and I’m running them in VMware to have a poke around (but not all at the same time, they need a heap of memory).

I’ll be following this as close as I can (or as close as I’m allowed).  I think it will be really interesting to see how this progresses.  Good luck to all involved (and if you need a hand guys… ;-)

Tags: ,