It’s actually pretty easy. On the client side you need to specify your hostname, your origin and the relay host. For example:

myhostname = dev.localnet.xen
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
#mydestination = dev.localnet.xen, dev, localhost
relayhost = [mail.localnet.xen]
mynetworks = 127.0.0.0/8

Mydestination must not be set otherwise mail will be delivered locally. Server side you need first rewrite the from field of every email coming from the satellite host. This is necessary in my case as I’m using a local domain that is unknown to the relay host and that will cause a rejection with “unknown domain”. Secondly you would need to rewrite the To field of the email to deliver it either locally of send it somewhere else.

in brief:

mydestination = dev.localnet.xen
[...]
canonical_maps = regexp:/etc/postfix/canonical.regex
virtual_alias_maps = hash:/etc/postfix/virtual

Mydestination is to accept the email from the satellite host, the canonical_maps is to rewrite the From and the virtual_maps are to rewrite the To field.

For the canonical maps I use a regexp to match all my satellite hosts at once and rewrite them to $user-$host@example.net . For example:

/^(.*)@(.*)\.localnet\.xen$/ $(1)-$(2)@example.net

I’ve been looking for a solution to this problem for a long time. Basically apache2 is not able to do name-based virtual hosting if you also want to use ssl. The reason for this problem is very simple. In order to know then hostname, apache2 I need to establish a secure channel, but to establish a secure channel, if I have more then one virtual host, then I need to know the hostname, that is, to provide the client the correct certificate. There is also a better explanation on the apache website [1].

There correct solution to this problem is to use the TLS extension called SNI [2]. This is provided by two different apache modules: mod_gnutls and mod_ssl.

There are two nice tutorials one for mod_ssl [3] and the other one for mod_gnutls [4] . If you are running lenny (debian testing at the time of writing), you can just install mod_gnutls. If you are running etch, then your best bet is to recompile apache with the mod_ssl patch to support SNI. The first tutorial [3] is about the latter option. The patch can be downloaded from this website [5] mentioned also in [3].

The tutorial explains how to recompile the package. The only thing I’ve done is to use pbuilder to automate the process. In particular, if you’re building the apache2 package in pbuilder, you need to recompile openssl first, then to install in your pbuilder image and then build apache. This is the command I’ve used to add the package.

sudo /usr/sbin/pbuilder --login --save-after-login --bindmounts /var/cache/pbuilder/

dpkg -i /var/cache/pbuilder/results/libssl*.deb /var/cache/pbuilder/results/openssl*.deb

so far so good. I’ve save myself an big headache.

:)

[1] http://httpd.apache.org/docs/2.1/ssl/ssl_faq.html#vhosts2

[2]http://en.wikipedia.org/wiki/Server_Name_Indication

[3]http://www.how2forge.org/enable-multiple-https-sites-on-one-ip-using-tls-extensions-on-debian-etch

[4]http://www.g-loaded.eu/2007/08/10/ssl-enabled-name-based-apache-virtual-hosts-with-mod_gnutls/

[5]https://dave.sni.velox.ch/

Today I spent large part of the day to configure a vpn to access our servers. Instead of leaving port 22 wide open, I prefer to use a vpn to access the internal network and to do ordinary administration tasks. This way I’ll also be able to use graphical tools that I don’t feel like to use over the internet.

The openvpn howto (http://openvpn.net/howto.html ) already has all the details I needed. The only complication was to use as server a public ip that is part of the restricted subnet I wanted to access. Moreover since I wanted to have a private subnet for my vpn, I also configured natting between the vpn network and my lan

This is my server conf file:

port 1194
local xxx.xxx.xxx.xxx
dev tun
tls-server
server 192.168.100.0 255.255.255.0

dh keys/dh1024.pem
ca keys/ca.crt
cert keys/server.crt
key keys/server.key
#duplicate-cn

mtu-test
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450

keepalive 10 120

#route to be established on the server
route-up "iptables -F; iptables -t nat -F; iptables -t mangle -F"
route-up "iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o eth0 -j MASQUERADE"
down "iptables -F; iptables -t nat -F; iptables -t mangle -F"

#route to push to clients
#we cannot push directly this route as the vpn server is on the same subnet.
#push "route xxx.xxx.xxx.0 255.255.255.0"
push "dhcp-option DOMAIN localnet.xen"
push "dhcp-option DNS xxx.xxx.xxx.1"

comp-lzo

persist-tun
persist-key

and this is on the client side :

port 1194 
dev tun
remote xxx.xxx.xxx.xxx

tls-client
ca keys/ca.crt
cert keys/client.crt
key keys/client.key

mtu-test
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450

pull
comp-lzo
verb 4

up ./up.sh
down ./down.sh

persist-tun
persist-key

The up and down scripts are used to set default routes to the lan I want to access.

#!/bin/sh
set -x

#./up.sh tun0 1500 1574 192.168.100.6 192.168.100.5 init

route add -net xxx.xxx.xxx.0 netmask 255.255.255.240 gw $5
route add -host vpn-server-ip eth1

I like openvpn… :)

Not a tutorial, just few lines to write down what I’ve done.

This command gives you information about all virtual groups

vgdisplay -v

Then, to create a logical group :

lvcreate -l 59581 -n data vg1

the -l option specifies the number of extent to allocate for this lv . You can see the number of available extents for a vg with the command above. This is useful to know when you want to create a lv using all the available space.

Then let’s create an xfs fs on this lv :

mkfs.xfs -l logdev=/dev/vg1/log1,size=128m -f /dev/vg1/data

I’m not going to specify any other esoteric settings to build the fs. The only important option here is to specify external log partition.

To mount the partition we need to give a log list of parameters.

mount -t xfs /dev/vg1/data ex -o noatime,nodiratime,nobarrier,logbufs=8,logdev=/dev/vg1/log1

There are a lot of threads around. This is a good pointer.

http://thias.marmotte.net/archives/2008/01/05/Dell-PERC5E-and-MD1000-performance-tweaks.html

Next jumbo frames !

This is data related with a dell 2950 + md1000 that I’m configuring. /dev/sda is the onboad raid controller with 3 300G sas disks (raid5). /dev/sdb is the md1000 with 5 1T sata disk (raid5). First when configuring the md1000 you must create the logical volume from the bios. I’ve created a fairly standard raid5 array using with all disks.

The crude data without any optimization is as follows:

promethium:~# hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   5872 MB in  2.00 seconds = 2940.90 MB/sec
 Timing buffered disk reads:  476 MB in  3.01 seconds = 158.36 MB/sec


promethium:~# hdparm -tT /dev/sdb

/dev/sdb:
 Timing cached reads:   6106 MB in  2.00 seconds = 3059.32 MB/sec
 Timing buffered disk reads:  192 MB in  3.03 seconds =  63.34 MB/sec

The web suggest to increase the read ahead associated to the linux block device (not the ra of the disk).

the magic incantation is:

/sbin/blockdev --setra 8192 /dev/sdb

and the result is pretty good:

promethium:~# hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   6492 MB in  2.00 seconds = 3253.12 MB/sec
 Timing buffered disk reads:  490 MB in  3.01 seconds = 162.88 MB/sec
promethium:~# /sbin/blockdev --setra 8192 /dev/sdb
promethium:~# hdparm -tT /dev/sdb

/dev/sdb:
 Timing cached reads:   5952 MB in  2.00 seconds = 2981.25 MB/sec
 Timing buffered disk reads:  472 MB in  3.01 seconds = 156.77 MB/sec

I’ve also used bonnie++ for my benchmarks with similar results.