The personal blog of Peter Hicks
When working on a project in Java, I like to name my integration and unit tests separately. Integration tests end ‘-IT’, and unit tests don’t.
This makes it really easy to run just unit or integration tests in IntelliJ by using one of these two patterns:
Make sure the Run configuration has the Test Kind set to Pattern, and searches for tests in the whole project.
A project I’m working on requires a Kerberos and LDAP infrastructure. As with most tech, it’s easy to do something quickly, but much harder to do it properly and get it documented.
One of the biggest problems I encountered was when setting up replication between LDAP servers. We use SaltStack to build and maintain our server estate, so deployment and configuration needs to be automated.
Using LetsEncrypt to issue a certificate to each server, OpenLDAP can take the certificate and use it to encrypt and authenticate connections from other LDAP servers. It’s meant to be simple – add this LDIF file to your directory:
dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/letsencrypt/live/ldap1.example.com/fullchain.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/letsencrypt/live/ldap1.example.com/cert.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/letsencrypt/live/ldap1.example.com/privkey.pem
This error kept cropping up:
$ sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f ./ssl.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=config"
ldap_modify: Other (e.g., implementation specific) error (80)
Restarting slapd with all debugging switched on resulted in nothing, and strace-ing the daemon whilst running was similarly fruitless.
Cutting to the chase, the problem was that the openldap user didn’t have access to the certificate symlinks, nor the certificates either, and that AppArmor was blocking access to the files under /etc/letsencrypt.
So how do we solve it?
First, using setfacl, give the openldap user rx permissions on /etc/letsencrypt/live and /etc/letsencrypt/archive. This will allow slapd to follow read and follow the symbolic links to the actual files in the archive directory. Next, add the following to /etc/apparmor.d/local/usr.sbin.slapd:
/etc/letsencrypt/live/{{ grains.id }} r,
/etc/letsencrypt/archive/{{ grains.id }} r,
/etc/letsencrypt/archive/{{ grains.id }}/** r,
The trailing comma on the last line isn’t an error – this will stop AppArmor blocking slapd access to the certificate symlink and the actual certificate, as above. Remember to restart AppArmor afterwards.
And that’s it.
I took delivery of a shiny HP LaserJet wireless printer recently. Setting it up on the office network was fairly easy once I’d connected it via a cable (and then disconnected it afterwards) – except it kept broadcasting an open wireless network (SSID) which anyone could use.
That’s not awesome, but on HP’s Support Forum, I found these instructions from a user who worked out how to disable the network:
When I was inexperienced in Java, I wrote a lot of tests using assert(), rather than using assertEquals().
Revisiting code today, I wanted to update many test suites to use assertEquals(), which requires I flip the expected and actual values around. Too difficult to do quickly by hand, so I used the following regular expression:
Find: assert \((.+)\)\.equals\((.+)\)\);
Replace: assertEquals($2, $1));
It worked like a treat.
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 host.example.com --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/host.example.com/privkey.pem -in config/live/host.example.com/cert.pem
The .pfx file can then be uploaded to the printer and it’ll use it immediately.
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!
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.
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.
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?
I’m documenting this in public because I am likely not alone in disliking Ubuntu 16.04’s network interface naming scheme.
All I had to do was pass these kernel parameters when installing to end up with my network interface named ‘eth0’:
biosdevname=0 net.ifnames=0
Simple!