Category: Technology

Whilst testing out some PostgreSQL replication scenarios, I needed to have multiple instances of Postgres running under my user. I could have used multiple Docker machines with ports exposed, but I opted for another solution. Here’s how I did it.

First, I created /home/user/pgdata to hold the data directories, and /tmp/postgres to hold the UNIX socket files.

Then, it’s just a case of running /usr/lib/postgresql/12/bin/initdb /home/user/pgdata/1 -E UTF-8 to create a data directory, then editing postgresql.conf and changing the TCP port from 5432 to, say, 50432, and unix_socket_directories to /tmp/postgresql.

To start the server, run /usr/lib/postgresql/12/bin/pg_ctl -D /home/user/pgdata/1 -l logfile start, and to stop it, replace "start" with "stop". The final step is to create a postgres user with /usr/lib/postgresql/12/bin/createuser -drs postgres -h localhost -p 50432 and you’re away.

Some use cases I can think of for this are:

• An isolated Postgres instance for integration testing
• Trying out a new version of Postgres in parallel with your existing version
• Verifying your disaster recovery procedures

There are probably more.

I have a Philips Hue bridge which lets me control the lights in my flat in a variety of useful ways. It’s a good bit of kit, but with one major problem – it assumes you’re running PAT (Port Address Translation), and that your Hue bridge and the device you access https://account.meethue.com/bridge both access the Internet from the same source IP address. If not, even though the devices may be in the same broadcast domain and the same IPv4 subnet, you won’t be able to link your Hue to your account.

Despite tweeting for assistance, I ended up crying shibboleet and reverse-engineering the method of linking they’re using. Here’s what I found out, in the hope it’ll save somebody else a lot of time.

My Internet services are through the excellent A&A, and I can’t recommend them highly enough. I have a public IPv4 subnet, and each of my devices accesses the Internet without any address translation. Inbound connectivity is restricted – there are only a few things I need accessible from the Internet. (As an aside, I have two DSL lines, with my IPv4 subnet routed down each – load balancing and resilience)

My Hue bridge connects to https://discovery.meethue.com/, and that service makes a note of an inventory that the bridge sends to it. Here’s where the problem is – visiting discovery.meethue.com only returns the devices that registered from the IP address you’re connecting from. That’s fine if all your devices go through address translation and appear to come from a single external IP address, but useless for me – my mobile device uses an entirely different IPv4 address, as does my desktop and laptop. The Hue app reports that no devices were found.

After some frustrating interactions on Twitter, I solved the problem myself. I set up IP Masquerade – essentially port address translation behind the router’s external IPv4 address – for my Hue bridge and my mobile device, so they’d appear to be coming from the router’s external IP address. Rebooting the Hue, disabling one of the PPP connections on my router (necessary since they both have an IP address assigned, and my outbound traffic is load-balanced per TCP connection) and linking the device from my mobile phone then worked. Rolling it all back and rebooting the Hue again leaves the device linked to my account.

What a mess. Adding a “Enter the IP address of your Hue then when prompted, press the button” on the device linking page would have been a whole load easier. Not everyone’s Internet connection is the same, nor is everyone as experienced in network engineering as I am… yet still it took me three days to work out a fix.

In summary: buy Hue devices – they’re good, but beware if you’re doing anything that possibly deviates from the common case.

Every time we added this, an error cropped up:

A project I’m working on requires a Kerberos and LDAP infrastructure. Most technology projects are easy to do badly, and more difficult to do well – and documented.

We use LetsEncrypt to issue a certificate to each server, and OpenLDAP can take the certificate and use it to encrypt and authenticate connections from other LDAP servers.

One of the problems I encountered was when setting up replication between servers. We use SaltStack to build and maintain our server estate, so deployment and configuration needs to be automated. This normally means spending a week automating a process which you’ll only do twice – once when you install it, and once again when you’re rebuilding the server and have forgotten everything you’ve done.

To secure OpenSSL, 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

Every time we did this, a vague error popped 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, the LDAP daemon, with full debugging showed nothing, neither did running the daemon through strace.

Several days of painful troubleshooting followed. We eventually found the issue – the LDAP daemon wasn’t able to access the TLS certificates! AppArmor was blocking access to the files under /etc/letsencrypt, and so we did two simple things.

First, we used setfacl to give the openldap user ‘rx’ permissions on /etc/letsencrypt/live and /etc/letsencrypt/archive:

$ sudo setfacl -m user:openldap:r-x /etc/letsencrypt/live
$ sudo setfacl -m user:openldap:r-x /etc/letsencrypt/archive

This lets the LDAP daemon read and following the symbolic links in the live directory to the actual files.

Next, we needed to tell AppArmor to let the LDAP daemon, slapd, access the files themselves. It’s as easy as creating a file called /etc/apparmor.d/local/usr.sbin.slapd with the following:

/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 a mistake – if you don’t include it, AppArmor won’t install the rule. I won’t admit how long it took us to realise this!

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.