Author: Sophie

Zweite Vorsitzende des Hemio – Verein für freie Kommunikation. Contact: sophie AT hemio.de.

Preseeding with Consequences

For VM installs, we use a preseed which sets the debconf priority to  critical. This disables questions from the installer, where we agree to the default anyways (or we have set an appropriate default via preseed).

After using this method since ages (literally) Mika noted that on the installed machines the debconf priority is still critical. This implies that apt-get installs did not asked us much. For example, MySQL/MariaDB is installed having a root user with empty password! Especially since the notion of critical seems to be a bit inconsistent between packages, this might be a serious pitfall.

Probably this didn’t had bad effects on our systems, but we have switched to priority medium (dpkg-reconfigure debconf).

WordPress 4.1

Finally, WordPress 4.1 with virtual host support is running on Debian Jessie with custom WP_CONTENT_DIR. As default, wp-content/themes is symlinked to /var/lib/wordpress/wp-content/themes/ which can be replaced if using custom themes.

Let’s see how long this lasts. WordPress is changing it’s folder structure and config options for upload stuff quite frequently.

PostgreSQL and SSL authentication

General principle. PostgreSQL allows authentication via X.509 certificates. The certificate common name (CN) has to equal the PostgreSQL user (i.e. role) name. The certificate has to be signed by a CA that the PostgreSQL server trusts.

How-to. You probably want to run your own CA to sign certificates for PostgreSQL clients. There are many step by step articles around for doing this with OpenSSL. Hence I will focus on the PostgreSQL part.

  1. Configure your PostgreSQL server to trust your CA only. This is done by setting ssl_ca_file= to the path of your CA cert in your postgresql.conf config. Note that it must be readable by the postgresql user.
  2. Adjust your pg_hba.conf to “TYPE” hostssl instead of host and set the “METHODE” to cert.
  3. Generate a key + CSR (certificate signing request) on the client and sign the request with our CA. Place the key and the certificate in ~/.postgresql/ as postgresql.key and postgresql.crt on the client.
  4. You should be able to connect for example with psql. Depending on the client, you may adjust the client settings via parameter key words. Relevant are the keys sslmode, sslcert and sslkey.

What you get. The use of SSL/X.509 authentification has two advantages:

  1. Private key authentication: You don’t use a password that a man in the middle attacker could steel.
  2. Your secret for authentication is nicely separated from the rest of your configuration etc.
  3. Your communication is encrypted, but …

A man in the middle might steel informations that you send or retrieve from the server.

Verifying the server. You can use the same private CA for this purpose. Generate key + CSR for the server and sign it. Use the ssl_cert_file and ssl_key_file options in the servers postgresql.conf to point so key/crt. Place the root certificate of your CA in ~/.postgresql/root.crt on the client or use the sslrootcert parameter key on your client. I would recommend to specify sslmode=verify-ca to force the verification. Syntax for testing via psql:

psql postgres://<user>@<host>/<dbname>?sslmode=verify-ca