Archive for the ·


· Category...

Raspberry Pi headless install

Comments Off

The minimal “lite” image of Debian 8 (Jessie) is an excellent choice for a headless Raspberry Pi. After downloading to the SD card, these notes from Dmytro Bobkov covers the basic initial setup, while wifi setup from the command line is explained here. More details on CLI wifi on Debian in a previous post here.

If there is no screen or keyboard available, the SD card have to be prepared before the initial boot. Mainly to make sure SSH is running, so you can log in. This discussion covers the topic. However, if things are not working at once, a few debug statements can help. E.g., add as needed in the config file (change the IP as needed to your laptop or machine):

echo "$_IP" | nc 10100

echo "ssh has started" | nc 10100

On the other end, receive the messages by:

while true; do nc -l 10100; done

Finally, you might want to add a few extra packages, based on what you want to use the device for. These might come in handy:

apt-get update
apt-get upgrade

apt-get install htop itop atop git tig tree autossh nmap rsync lynx links emacs

Comments Off

Upgrading Debian Wheezy 7 to Jessie 8

Comments Off

Upgrading from Debian 7 to 8 is reasonably straight forward, following the official instructions. These shorter summaries are also useful references.

Very briefly then, make sure you have backup.
dpkg --get-selections "*" > dpkg_selections.txt
tar zcvf upgrade_backup.tar.gz /etc /var/lib/dpkg /var/lib/apt/extended_states /etc/mysql/my.cnf /etc/fuse.conf /etc/ssh/ssh_config

Update /etc/apt/sources.list, and replace all occurrences of wheezy with jessie.
sed -i 's/wheezy/jessie/g' /etc/apt/sources.list

If VirtualBox is installed, update to the new key:
wget -q -O - | sudo apt-key add -

Then comes the upgrade dance, with a few prompts, warnings, questions.

apt-get update
apt-get upgrade
apt-get dist-upgrade

After the upgrade, it is recommended to purge unused packages
apt-get purge $(dpkg -l | awk '/^rc/ { print $2 }')
apt-get autoremove

It is also recommended to install the linux-image-* metapackage, e.g. for AMD CPUs
apt-get install linux-image-amd64

Finally, cross your fingers and reboot.

Comments Off

Let’s Encrypt TLS certificate setup for Apache on Debian 7

Comments Off

Through Let’s Encrypt, anybody can now easily obtain and install a free TSL (or SSL) certificate on their web site. The basic use case for a single host is very simple and straight forward to set up as seen here. For multiple virtual hosts, it is simply a case of rinse and repeat.

On older distributions, a bit more effort is required. E.g. on Debian 7 (Wheezy), the required version of the Augeas library (libaugeas0, augeas-lenses) is not available, so the edits to the Apache config files have to be managed by hand. Furthermore, for transitioning from an old HTTP based server, you need to configure the redirects for any old links which still might hard code “http” in the URL. Finally, there’s some security decisions to consider when selecting which encryption protocols and ciphers to support.

Installation and setup

Because the installer has only been packaged for newer distributions so far, a manual download is required. The initial execution of the letsencrypt-auto binary will install further dependencies.

sudo apt-get install git
git clone /usr/local/letsencrypt
cd /usr/local/letsencrypt
./letsencrypt-auto --help

To acquire the certificates independently of the running Apache web server, first shut it down, and use the stand-alone option for letsencrypt-auto. Replace the email and domain name options with the correct values.

apache2ctl stop
./letsencrypt-auto certonly --standalone --email -d -d

Unless specified on the command line as above, there will be a prompt to enter a contact email, and to agree to the terms of service. Afterwards, four new files will be created:


If you don’t have automated regular backup of /etc, now is a good time to at least backup /etc/letsencrypt and /etc/apache2.

In the Apache config for the virtual host, add a new section (or a new file) for the TSL/SSL port 443. The important new lines in the HTTPS section use the files created above. Please note, this example is for an older Apache version, typically available on Debian 7 Wheezy. See these notes for newer versions.

# This will change when Apache is upgraded to >2.4.8
# See
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/
SSLCertificateKeyFile /etc/letsencrypt/live/
SSLCertificateChainFile /etc/letsencrypt/live/

To automatically redirect links which have hard coded http, add something like this to the old port *.80 section.

#Redirrect from http to https
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]

While editing the virtual site configuration, it can be useful to watch out for the logging format string. Typically the logging formatter “combined” is used. However, this does not indicate which protocol was used to serve the page. To show the port number used (which implies the protocol), change to “vhost_combined” instead. For example:

CustomLog ${APACHE_LOG_DIR}/example_com-access.log vhost_combined

To finish, optionally edit /etc/apache2/ports.conf, and add the following line to the SSL section. It enables multiple named virtual hosts over SSL, but will not work on old Windows XP systems. Tough luck.

<IfModule mod_ssl.c>
  NameVirtualHost *:443
  Listen 443

Finally, restart Apache to activate all the changes.

apache2ctl restart

Verification and encryption ciphers

SSL Labs has an excellent and comprehensive online tool to verify your certificate setup. Fill in the domain name field there, or replace your site name in the following URL, and wait a couple of minutes for the report to generate. It will give you a detailed overview of your setup, what works, and what is recommended to change.

Ideally, you’ll get a grade A as shown in the image below. However, a few more adjustments might be required to get there. It typically has to do with the protocols and ciphers the web server is configured to accept and use. This is of course a moving target as security and cryptography research and attacks evolve. Right now, there are two main considerations to make: All the old SSL protocol versions are broken and obsolete, so should be disabled. Secondly, there’s an attack on the RC4 cipher, but disabling that is a compromise, albeit old, between its insecurity and the “BEAST” attack. Thus, disabling RC4 now seems to be preferred.

Taking all this into account, the recommended configuration for Apache and OpenSSL as it stands excludes all SSL versions, as well as RC4 versions. This should result in a forward secrecy configuration. Again, this is a moving target, so this will have to be updated in the future.

To make these changes, edit the Apache SSL mod file /etc/apache2/mods-available/ssl.conf directly, or update the relevant virtual host site config file with the following lines.

SSLHonorCipherOrder on
SSLProtocol all -SSLv2 -SSLv3

Restart Apache, and regenerate the SSL Labs report. Hopefully, it will give you a grade A.


Final considerations

Even with all the configuration above in place, the all-green TSL/SSL security lock icon in the browser URL bar, as seen below right, might be elusive. Instead a yellow warning like the on in the image to left might show. This could stem from legacy URLs which have hard coded the http protocol, both to the internal site and external resources like images, scripts. It’s a matter of either using relative links, excluding the protocol and host altogether, absolute site links, inferring the protocol by not specifying it, or hard coding it. Examples:

<img src="blog_pics/ssl_secure.png">
<img src="/blog_pics/ssl_secure.png">
<img src="//">
<img src="">

On a blog like this, it certainly makes sense to put in some effort to update static pages, and make sure that new articles are formatted correctly. However, going through all the hundreds of old articles might not be worth it. When they roll off the main page, the green icon will also show here.


Comments Off

SPF and DKIM on Postfix

Comments Off

A recent post by Jody Ribton laments the fact that DIY mail servers are having a hard time not getting blocked or rejected in today’s email landscape. The ensuing Slashdot discussion dissected the problem, and came up with a few good pieces of advice also seen on this digitalocean guide:

  • Make sure the server is not an open mail relay.
  • Verify that the sender and server IP addresses are not blacklisted.
  • Apply a Fully Qualified Domain Name (FQDN) and the same host name as the PTR record.
  • Set a Sender Policy Framework (SPF) DNS record.
  • Configure DomainKeys Identified Mail (DKIM) on the sending server and DNS.

Sender Policy Framework (SPF)

“Sender Policy Framework (SPF) is a simple email-validation system designed to detect email spoofing by providing a mechanism to allow receiving mail exchangers to check that incoming mail from a domain comes from a host authorized by that domain’s administrators”. [Wikipedia]. It is configured through a special TXT DNS record, and further setup on the sending part is not required.

This guide outlines the parameters, and the easiest way to get started is actually this Microsoft provided online wizard. Given a domain, it will guide you through the settings and present you with the DNS record to add at the end. If the domain already has a SPF record, it will verify it, and also take the current settings into account through the steps.

DomainKeys Identified Mail (DKIM) on Postfix

DKIM offers similar email spoofing protection, but also offers simple content signing. From Wikipedia: “DomainKeys Identified Mail (DKIM) is an email validation system designed to detect email spoofing by providing a mechanism to allow receiving mail exchangers to check that incoming mail from a domain is authorized by that domain’s administrators and that the email (including attachments) has not been modified during transport. A digital signature included with the message can be validated by the recipient using the signer’s public key published in the DNS.”

Configuration is quite straight forward on Postfix, and this guide shows a typical setup and some common pitfalls. If the same email server caters for multiple domains, an alternative configuration is required. This guide covers those details. Another DNS TXT record on the domain is also required. Finally, once the setup is complete, this tool can be used to verify the DNS record.

Verify the configuration

For both SPF and DKIM, the setup can also be verified by sending an email to In addition, an email can be sent to any Gmail account, and by viewing the original message and headers, an extra Authentication-Results header can be seen. See the last guide for further details.



Comments Off

Manual wifi config in Debian

Comments Off

Most modern GUI based distros handle setup and management of Wifi connections very well these days. However, sometimes you need to go the way of the command line. The following outlines the basics in Debian, plus some useful commands.

First, the Wifi device I had laying around was a Realtek based USB dongle similar to this. The driver for that is in the non-free repository, so I added the parts in bold to my /etc/apt/sources.list

deb wheezy main contrib non-free
deb wheezy-updates main contrib non-free

I could then install the driver:
apt-get update
apt-get install firmware-realtek

There are two config files to handle: The basic network configuration (/etc/network/interfaces), which also includes wired networks and the loopback, and the WPA wifi specific configuration (/etc/wpa_supplicant/wpa_supplicant.conf). Although it is also possible to specify wifi parameters in the network interfaces file, it is better handled by the wpa because then you can configure settings for multiple networks (e.g. home and work) as seen below.

/etc/network/interfaces contains the following:

# The loopback network interface
auto lo
iface lo inet loopback

# Wired ethernet
auto eth0
iface eth0 inet dhcp

# The primary network interface
auto wlan0
allow-hotplug wlan0
iface wlan0 inet dhcp
      wpa-driver nl80211
      wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

The loopback lo interface is configured, a wired eth0 port, and the wlan0 wifi. All networks are set to come up automatically, the last two use DHCP to get their address, and the Realtek nl80211 driver is specified as well as a reference to the WPA Supplicant config.

/etc/wpa_supplicant/wpa_supplicant.conf contains:


    psk="wifi passphrase"


Here two networks are configured: A home network with WPA encryption and its passphrase, and an open network for work.

To bring the wifi network up, simply run the following. If iterating on the configuration, it’s has to be stopped first.

ifdown wlan0 && ifup wlan0

Useful commands
Other useful commands while debugging this include:

For general network configuration and status:



For listing all available networks and their parameters. This works even before you have connected to a specific one, so it’s a good test to see if the wifi device is even working:
iwlist wlan0 scan

For starting the wpa supplicant manually and checking the wifi configuration. Notice the specific driver and interface name:
wpa_supplicant -B -Dnl80211 -iwlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf

Comments Off

Debian 7 – netinst

Comments Off

In search of a small simple GNU/Linux server setup, I started with a Debian 7 installation through a network based install – netinst. Using that image is simple, either by writing to a CD, or simply to a USB drive or memory card:
(Replace X with your flash drive, but be careful; everything will be overwritten, without any recovery option).

sudo dd if=debian-7.8.0-i386-netinst.iso.torrent of=/dev/sdX
The installation was straight forward, but it has to be hand-held since there are multiple prompts from various parts of the installation throughout. Unfortunately, the final step of writing out the GRUB configuration failed, since the install medium, the USB flash reader, was included in the GRUB device map. Removing it from /boot/grub/ fixed that, and a little rescue operation resolve the rest.

Once booted, there was a problem with the start-stop-daemon; for some reason, it was set to a fake mock implementation. That caused all services to not start. Swapping in with the real implementation took care of that:

mv /sbin/start-stop-daemon /sbin/start-stop-daemon.FAKE
ln -s /sbin/start-stop-daemon.REAL /sbin/start-stop-daemon

Finally, some essentials are always missing:

apt-get install emacs atop htop iftop iotop tree git tig sudo autossh iptables-persistent wpasupplicant cryptsetup smartmontools

Comments Off