Turning off Syntax Highlighting in vim

Today my screen is a bit dark – or rather, the office is bright, what with all the sun outside. This makes some of the colors of vim’s syntax highlighting hard to read. How do you turn this on or off?

After you open a file, and press ESC. With:

:syntax off

you can turn the highlighting off; with:

:syntax on

you can turn it on again.

If you want to do this permanently, you can edit (or create) the file .vimrc to include the line:

syntax off

I know this is a tiny thing, but I can now read my text files again. 😉

Enabling SSL in Apache2 on Ubuntu

I’m using my server for various admin interfaces and so want to SSL encrypt all traffic to the web server. This is easy enough to add to the default vhosts.

First, we need an SSL certificate. Create it by running:

openssl req -new -x509 -days 3650 -nodes
-out /etc/ssl/certs/apacheserver.pem
-keyout /etc/ssl/private/apacheserver.pem

This generates a self-signed certificate. For tests this is good enough; for production sites you WILL want to use a real purchased certificate. Since one of the jobs of SSL is not only to encrypt, but also to authenticate a site to the user, a self-signed certificate will cause browsers to pop up a warning. Users can (permanently) accept this for your site, but it’s probably not the impression you want to leave.

Ubuntu’s Apache2 will come with the SSL module installed by default, but it’s not used. As our next step, we need to enable it:

a2enmod ssl

Finally, we need to create an SSL virtual host. In my case, I want all http traffic to be simply redirected to https. Find the file /etc/apache2/sites-enabled/000-default and edit it.

Change the existing vhost to listen to Port 443; edit the “VirtualHost” line so it reads:

<VirtualHost *:443>

(Where […] is of course the rest of your vhost configuration)

Now, inside the VirtualHost definition we’ll need to enable SSL and tell it where the certificate resides:

<VirtualHost *:443>
SSLEngine on
SSLCertificateFile /etc/ssl/certs/ephesus.pem
SSLCertificateKeyFile /etc/ssl/private/ephesus.pem

Finally, add a new vhost for redirection:

<VirtualHost *:80>
RedirectPermanent / https://server.example.org/

Naturally, https://server.example.org/ should point to your machine’s name.

Restart Apache:

/etc/init.d/apache2 restart

And that’s all. If you go to http://server.example.org/ you should now be redirected to https://server.example.org

For final reference, here’s my configuration. Note that I commented out the Ubuntu documentation (No need to make this available to the big wide world) and cgi-bin (I’m not using this).

<VirtualHost *:80>
RedirectPermanent / https://ephesus.pandemonium.de/

<VirtualHost *:443>
SSLEngine on
SSLCertificateFile /etc/ssl/certs/ephesus.pem
SSLCertificateKeyFile /etc/ssl/private/ephesus.pem

ServerAdmin webmaster@localhost

DocumentRoot /var/www
<Directory />
Options FollowSymLinks
AllowOverride None
<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all

#ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
#<Directory “/usr/lib/cgi-bin”>
# AllowOverride None
# Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
# Order allow,deny
# Allow from all

ErrorLog ${APACHE_LOG_DIR}/error.log

# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn

CustomLog ${APACHE_LOG_DIR}/access.log combined
# Alias /doc/ “/usr/share/doc/”
# <Directory “/usr/share/doc/”>
# Options Indexes MultiViews FollowSymLinks
# AllowOverride None
# Order deny,allow
# Deny from all
# Allow from ::1/128
# </Directory>


Moving eJabberd

If you need to migrate ejabberd, you need to be aware that -at least on Debian/Ubuntu- it uses your machine name as the default nodename, or to be more precise, ejabberd@hostname. This can be controlled in /etc/default/ejabberd but unless you already knew about it, it’s a done deal already.

So, my naive approach of just copying files did not work. However you can use the method to migrate ejabberd data files documented in the -gasp!- manual.

You also need to be aware of the fact that your jabber domain – in my case jabber.pandemonium.de – is stored as part of the user names in your roster file, so testing it with a parallel host/domain won’t do you much good. You’d have to at least simulate it with /etc/hosts entries on both client and server.

SVN Stalling

I had this weird problem where my svn would upload a few MB and then stall and timeout. At first I of course suspected a problem with either svn on the server, the apache, or tortoisesvn. I tried CPU affinity settings, Apache settings – nothing I did helped, including updating to latest patchlevel etc. After some trial and error, I found out that restarting my OpenVPN – which transports my svn traffic to ensure it is encrypted – seemed to help for a few moments.

After the timeouts, there were actually moments where I couldn’t connect to my server at all. Restarting the OpenVPN connection alleviated that problem.

So checking the log, I found that the openvpn reconnected when it timed out, and I saw this message:

Apr 3 01:14:15 corinth ovpn-server[1050]: MULTI: new connection by client ‘ghostwheel’ will cause previous active sessions by this client to be dropped. Remember to use the –duplicate-cn option if you want multiple clients using the same certificate or username to concurrently connect.

Aha! What IP was I coming in from?

Apr 3 01:14:15 corinth ovpn-server[1050]: MULTI: Learn: -> ghostwheel/

And that resolves to an DTAG hostname:

# host domain name pointer tmo-098-92.customers.d1-online.com.

So the solution of the problem was after all quite simple: Another machine was basically kicking me out of my VPN. And yes, I remembered that my girlfriend borrowed my Samsung NC 10 – and she probably left it running when she went to work. I hadn’t remembered that I had just copied the VPN config including certificate when I set up my home PC, but of course it was easy to fix.