Securing an HP LaserJet printer with LetsEncrypt

The fantastic Let’s Encrypt service lets you issue SSL/TLS certificates to devices without charge. It’s not everything you may want at the enterprise level, but for the professional in their home environment, it’s great.

I wanted to replace the self-signed certificate on an HP printer I had, but it wasn’t an easy process. I’ve documented it here so it can be useful to others too.

First, use certbot to generate your certificate. Run the command as follows:

certbot -d --manual --preferred-challenges dns certonly

This will instruct you to add a TXT record to the DNS record for the host for authentication, after which you’ll receive your certificate.

To convert this in to a PKCS#12 file, suitable for loading on to the printer, use the following command:

openssl pkcs12 -export -out certificate.pfx -inkey config/live/ -in config/live/

The .pfx file can then be uploaded to the printer and it’ll use it immediately.

Ubuntu 16.04LTS

I will freely admit that I’ve been putting off upgrading my Ubuntu 14.04LTS boxes to 16.04LTS. In a previous post, I wrote about my battle with getting the Ubuntu desktop to be usable in the way I wanted it. Having tried this out on 16.04LTS, I realised that I’d have to change the way I work.

I am two weeks in to running the new upgraded system and I wish I’d gone through the pain earlier. Making the Unity Launcher smaller, getting used to the menu bar in the top row of windows, and the close, minimise and maximise buttons landing in the top left of the screen when maximised – none of those took particularly long to get past.

On previous installs, I’ve wanted shortcuts to the common applications at the top of the screen by the clock, but I’ve locked these in to the Unity Launcher – and there’s more space for them.

The only irritation that’s still there is resizing terminal windows. It takes a while to re-learn that I don’t have to be precise with the cursor positioning to change the window size. And that’s it.

Ubuntu 16.04LTS, you are forgiven – I thought you were going to be a nightmare, but you’re lovely. And when I unplug one of my monitors from the graphics card, you put everything back on the screen still plugged in. That’s awesome!

Citrix Receiver and CA support

On installing an Ubuntu 16.04 desktop from scratch and putting Citrix Receiver on it, I found I couldn’t connect to one of the servers that I need to for work. The strange error suggested that the Citrix client doesn’t trust the VeriSign Class 3 Public Primary Certification Authority – G5.

This seemed confusing at first – I have the CA certificate in /usr/share/ca-certificates/mozilla. A quick look at where Citrix Receiver installed itself quickly found what was going on.

Citrix Receiver only has a handful of CA certificates installed in /opt/Citrix/ICAClient/keystore/cacerts, so if you’re connecting to a server with an SSL certificate other than the dozen or so in here, simply copy the .crt or .pem file and you’re sorted.

On mainframes and freedom

Last week, CIO Magazine reported on the shortfall in mainframe skills.

It reminded me of a situation I faced a couple of years ago. My team was preparing to write software which integrated with an IBM z/OS system, and I knew literally nothing about it. I didn’t need to know all the details, but I wanted to be able to talk to the system programmers coherently and be taken seriously. I didn’t know much about CICS, nor RACF, and I’d not even heard of RACF. I wanted to learn.

I am a self-starter, and I want to get my hands on the technology I’m going to use in my work life. From learning perl, PHP and SQL in the late 1990s so I could capture ISDN call log data over RADIUS, to buying a bunch of older Cisco equipment to bring me up to speed on VoIP, it’s worked stunningly well. I wanted to do the same with z/OS – not to become an overnight expert, but to be able to bridge the gap between Java developers and the people who ran the mainframe we were going to be using. It would make the whole project happen with much less friction.

After no more than an hour or so’s research, I found IBM wanted $900-or-so a year, on top of buying dedicated PC hardware just so I could run z/OS and spend a bit of time becoming familiar with it. But why? I can download any number of GNU/Linux distributions without charge, or evaluate most Microsoft products for several months without any hassle. Why can’t I do that with z/OS? There were several sites offering TSO and CICS access, but that was only from a user’s perspective. I wanted to peer inside and see what made it tick.

Luckily, the project succeeded and I learnt a fair amount about z/OS in the process, but it wasn’t as quick or easy as if I’d been able to spend some of my own time learning. In fact, when I was given access to a non-production CICS region with the software on the other side of our interface, I spent several hours of after-work time getting to know it, and came away being able to help our developers write an even better product than if I’d stayed in my pure consultancy role.

If IBM want to change the perception that mainframes are an enigma understood only by the balding and bearded stalwarts at large companies, they need to get people hooked. Make the latest release of z/OS and a suitable emulator available for download, and let the world see how great your software is.

Enterprise IT Onboarding

I visited a customer site last week to collect a building access card and get set up on their email system. I managed to get both done within 30 minutes.

The impressive thing was that my Inbox already contained instructions on how to set up remote access to Webmail and my desktop via Citrix. All I needed was Google Authenticator or similar on my phone and that was it.

Why can’t all Enterprise IT departments be this efficient?

Novell RPL Boot under VirtualBox

One of my recent retrocomputing projects was to set up a Novell NetWare 4.11 server and boot clients from it. Remote boot, or Remote Initial Program Load, was a common method for booting network clients over the LAN before IP became commonplace.

RPL requires a boot ROM on the network card which finds a nearby server, connects to it and downloads a disk image which it then executes. By today’s standards, it’s trivial – but by late 1990s standards, it was anything but.

Skipping past the reminiscing, I spent a few hours trying to get VirtualBox to do RPL boot. Etherboot doesn’t appear to support RPL, so I tracked down a ROM image on Intel’s website. Intel deprecated RPL around 2005, but they’ve kept an old version of their drivers available which contains a boot ROM image supporting RPL.

After uncompressing the download with 7z (using 7z x PRORPL.exe), I was left with two interesting looking files with the extension FLB. One of these is 63,488 bytes, and the other is 139,264 bytes. Installing these in a VirtualBox machine is straightforward but unfortunately undocumented:

vboxmanage setextradata "vmName" VBoxInternal/Devices/pcbios/0/Config/LanBootRom romLocation

Configuring the virtual machine to use the smaller of the two image was fruitless – VirtualBox didn’t complain at all, but instead ran ‘default’ iPXE code. Only when looking in the Log Viewer did I see a reference to the ROM filename and a strange error such as rc=VERR_TOO_MUCH_DATA.

Trial and error showed that the ROM size must be a few kilobytes below the 64kb limit, and a couple more hours searching uncovered AMD’s website which has a file named "Generic BootRom Utility" which contains a 16kb file, RBOOT.ROM, which is a working RPL boot ROM for AMD PCnet network cards, including the PCnet-FAST III card in my virtual machine.

Re-running the vboxmanage command above with the path to the newly discovered boot ROM works a treat. I can now boot a virtual machine straight off a virtual NetWare server – the details of how to do that are coming in a future blog post.

The curious case of the IP Alias

Trying to log on to Skype earlier in the week on my MacBook Pro didn’t work. For some reason it simply wouldn’t connect – it just timed out. Everything else worked absolutely fine, no issues.

Figuring it was an IPv6 issue, I unbound IPv6 from en0 and tried again. Nothing. It wasn’t my Cisco ASA firewall playing games either, although logging on to it showed a vast number of packets dropped from 192.168.1.x on its inside interface (reverse path check, I don’t use 192.168.1.x internally). How could this be?

It turns out that I had a 192.168.1.x bound to en0 from when I was testing out some locally connected kit. Skype saw this as the first IP address it could use and bound to it – whereas everything else worked fine letting the OS choose. Unbinding this address made Skype leap in to action.

Cleanweb, February 2015

Yesterday evening, I gave a talk on Open Rail Data at Cleanweb. I wished I could have stayed longer – there were plenty of discussions to be had, but after a busy Open Data Day on Saturday, the call of my bed was stronger than the call of the pub.

If you missed the presentation, or if you noticed I rattled through the last slides a little too quickly (and I always seem to need five more minutes than I have available!) and want to re-read them, I’ve uploaded them in PDF format.

If you want to continue the discussion, join the openraildata-talk mailing list and come chat.

The end is near…

It doesn’t seem like five years, but it is. Five years since I wanted the API to National Rail Enquiries’ Live Departure Board web service to be available for everyone so they can innovate and do great things.

We’ve come a heck of a long way in those five years – as from this week, you can sign up for the Open Live Departure Boards Web Services. A round of applause, please!

So, is that the end? Unfortunately not – there’s even more data to unlock, even more value to be created and stories to be told – but I think it’s been demonstrated that open and permissive trumps closed and expensive.

I get the feeling it’s going to be a smoother ride from here on.