Category Archives: Linux

Website version control with Git

Some notes on using git to manage development and production versions of a website on a Linux server, based on Using Git to manage a web site. There seem to be several web pages with similar ideas out there: I don’t know who wrote it down first. And also with reference to Version Control with Git by Jon Loeliger.

I’ve adapted those ideas for the way I like to do things:

I SSH in to the server, and do the editing there, using vim.
I have separate domains for development and production versions of my sites. For the purposes of these notes, they’re called dev.example.org and www.example.org. So the development version is also an active real-world website: my nginx configuration makes it only visible to me.
The document roots are /var/www/website and /var/www/website-dev respectively.
The ‘bare’ production git repository can be anywhere on the server. I’ll put it at /var/www/website.git. It’s a git convention to use the .git extension for bare repositories.

The steps for setting it up are as follows. I’ll leave the setting of suitable permissions and use of sudo as an exercise for the reader.

Put some web pages in /var/www/website-dev.

mkdir /var/www/website
cd /var/www/website-dev
git init
git add <all the appropriate files and directories>

Create a .gitignore file, and add everything that shouldn’t be transferred to production, such as configuration files that specify the development database and debug settings. For a WordPress site, that probably includes most of the WordPress stuff.

git commit -a -m "a message"
mkdir /var/www/website.git
cd /var/www/website.git
git --bare init

Create /var/www/website.git/hooks/post-receive containing:

#!/bin/bash
GIT_WORK_TREE=/var/www/website git checkout -f

In the following, I’ve used ‘live’ as an alias for the production environment; you could use ‘prod’ or whatever you fancy.

chmod +x /var/www/website.git/hoots/post-receive
cd /var/www/website-dev
git remote add live file:///var/www/website.git
git push live +master:refs/heads/master
git push --set-upstream live master
git push live

And, as if by magic, the files from the master branch of /var/www/website-dev are now in /var/www/website.
Then whenever you’ve got new code ready to into production, all that’s required is:
```
git push live
```

Self-signed multiple-domain SSL certificates

2 Replies

I’ve finally worked out how to create self-signed SSL certificates for multiple domain names with openssl.

These notes relate to Debian GNU/Linux, but the principles will apply to other operating systems.

The first step to make the process easier and repeatable in the future is to copy the default configuration file from /etc/ssl/openssl.cnf to a working directory where you can adapt it

Let’s assume that you’ve copied /etc/ssl/openssl.cnf to ~/project-openssl.cnf. Edit the new file and set the various default values to the ones that you need — that’s better than having to respond to openssl’s prompts every time you run it.

For real non-self-signed certificates, you would generate a certificate signing request (.csr) file, ready for a certificate authority to sign it for you. In that case, you need to follow the instructions at http://wiki.cacert.org/FAQ/subjectAltName.

But for a self-signed certificate, the subjectAltName has to go in a different place. Make sure you’ve got this line present and un-commented in the [req] section of the config file:

[req]
...
x509_extensions = v3_ca

and then this goes at the end of the [v3_ca] section:

[v3_ca]
...
subjectAltName = @alt_names
[alt_names]
DNS.1 = example.com
DNS.2 = www.example.com
DNS.3 = example.co.uk
DNS.4 = www.example.co.uk

There is (apparently) a limit to the number (or total length) of the alternate names, but I didn’t reach it with 11 domain names.

It’s also possible to add IP addresses to the alt_names section like this:

IP.1 = 192.168.1.1
IP.2 = 192.168.69.14

Then to create the key and self-signed certificate, run commands similar to these:

openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout project.key -out project.crt -config ~/project-openssl.cnf
cp project.crt /etc/ssl/localcerts/
mv project.key /etc/ssl/private/

Note that I move (rather than copy) the key to the private directory to avoid leaving a copy of it lying around unprotected.

You can check that the certificate contains all the domains that you added by running this:

openssl x509 -in project.crt -text -noout | less

Alternative approach

I haven’t tried this, but according to http://apetec.com/support/GenerateSAN-CSR.htm it’s also possible to create a CSR and then self-sign it like this:

openssl x509 -req -days 3650 -in project.csr -signkey project.key
 -out project.crt v3_req -extfile project-openssl.cnf

References:

W8 Mail App vs Exim and Dovecot

Leave a Reply

The Windows 8 Mail ‘app’ is fussy about who it will talk to, and gives absolutely no clues about what it thinks is wrong. It just refers the user to their system administrator.

But, with help from Eric Lee Green’s blog, I finally cracked it.

I have a Debian server running Exim4 (for SMTP) and Dovecot (IMAP).

Firstly I needed up-to-date self-signed SSL certificates for each of these (which I should have had anyway, but email clients such as Thunderbird are much less fussy).

For Exim, that means running

# bash /usr/share/doc/exim4-base/examples/exim-gencert

Debian hides the certificate-generating script for Dovecot in the .deb package, so you have to run

# rm /etc/dovecot/dovecot.pem
# rm /etc/dovecot/private/dovecot.pem
# dpkg-reconfigure dovecot-core

The next operation is to get the public certificate files (not the ones in private directories, obviously), i.e. exim.crt and dovecot.pem onto the Windows 8 machine. I used psftp to copy them to the desktop. Rename dovecot.pem to dovecot.crt so that Windows knows what to do with it. Then, for each one in turn:

right-click on it, and choose ‘Install Certificate’
choose ‘Current User’ (unless you know better), and click on ‘Next’
choose ‘Place all certifcates in the following store’, and browse to select ‘Trusted Root Certification Authorities’.
click on ‘Next’, then ‘Finish’. It will ask if you’re sure — it’s up to you to be sure that you’ve got the right certificate.

Finally the Mail app should now let you set up an account. Make sure that the server names you use match the ones in the certificate. To check, run this (back on Debian):

# openssl x509 -in /etc/exim4/exim.crt -text -noout
# openssl x509 -in /etc/dovecot/dovecot.pem -text -noout

and examine the output.

A final note: W8 Mail, being the half-baked toy that it is, doesn’t offer STARTTLS as a connection option, only the ‘obsolete’ (according to Hazel) SSMTP protocol — what the app refers to as simply ‘SSL’. So you’ll have to set up Exim to do that.

Trying to do SSL on port 587 (i.e. expecting STARTTLS), I get:

2013-12-15 12:42:47 SMTP protocol synchronization error (input sent without waiting for greeting): rejected connection from H=example.org.uk [1.2.3.4] input="\026\003\00
2013-12-15 12:42:47 TLS error on connection from example.org.uk [1.2.3.4] (recv): A TLS packet with unexpected length was received.                                     
2013-12-15 12:42:47 TLS error on connection from example.org.uk [1.2.3.4] (send): The specified session has been invalidated for some reason.

even after applying the alleged fix at https://bugs.launchpad.net/ubuntu/+source/gnutls13/+bug/1007231.