OVH Community, your new community space.

Squeezing a bit more out of your Kimsufi mKS 2G

21-11-2012, 19:39
Works great thanks

17-11-2012, 17:12
Quote Originally Posted by ExW
Thanks for the tips again, I have a question tho, say that i have more than one of these servers and shorewall on them. Is there some easy way to push new rules to them or do i have to login to each and manually do it?
There is You can indeed use a single server to manage Shorewall on several other servers with the help of Shorewall Lite.

Remote Setup

First, on the remote server you install Shorewall Lite (and optionally Shorewall6 Lite for IPv6) with:

apt-get install shorewall-lite shorewall6-lite
The next step is to allow Shorewall(6) Lite to start at boot time. On that remote server, you edit /etc/default/shorewall-lite and /etc/default/shorewall6-lite, changing the startup option:

(.. existing configuration ..)

Master Setup

I refer to the "master" as the server that will be managing all other Shorewall(6) Lite servers. If you already have Shorewall installed on this server, then you do not need to install anything else. Otherwise, refer to little How-To earlier.

First create a directory for your exports, as well as the one with the "base" configuration:

mkdir -p /etc/shorewall/exports/base
The base configuration will contain some basic rules and configurations that you will make it easier to add new remote servers later. The easiest way you can start, is by copying your master's current configuration, ie.:

cp /etc/shorewall/* /etc/shorewall/exports/base
After copying, you must edit the /etc/shorewall/exports/base/shorewall.conf file, and change the following options:
(.. existing configuation ..)


Any other settings, including base rules, is up to you (though SSH would be required, as I'll touch on later).

Shorewall and SSH

Shorewall(6) will use SSH and SCP to send commands and transfer files to the remote server. This means your master Shorewall server must be able to communicate with the remote over SSH.

You can change how Shorewall uses SSH/SCP by editing the Master's /etc/shorewall/shorewall.conf file and changing these two configuration variables:
(.. existing configuration ..)
RSH_COMMAND='ssh ${root}@${system} ${command}'
RCP_COMMAND='scp ${files} ${root}@${system}:${destination}'
For example, you can add "-4" to it, to force it to only use IPv4.

If you have setup to disallow root login with passwords on your remote server, or you simply do not want to be asked for a password on each action Shorewall needs to perform on that remote, then I suggest setting up an SSH key pair. On the master, you use:

ssh-keygen -t rsa
Then you copy the contents of ~/.ssh/ to the remote server and add it to the list of those authorized to access the server as root:

cat >> /root/.ssh/authorized_keys

Adding/editing a remote

Now that you have setup the basics, it will be fairly easy to add a remote. First create an export directory specifically for that host, and copy the base configuration to it. For example:

mkdir /etc/shorewall/exports/server-b
cp /etc/shorewall/exports/base/* /etc/shorewall/exports/server-b
Now edit the files in /etc/shorewall/exports/server-b as required. Keep in mind, that you need to know what the interfaces on the remote server are called. For example, is it "eth0" or "venet0"?

Once you're ready, let Shorewall compile the configuration and load it to the remote server with:

shorewall load /etc/shorewall/exports/server-b
This assumes the remote server is (SSH-)accessible via

If all went well, you should be able to issue the following command on the remote server and see all the rules in action:

shorewall-lite show
Next time you edit the shorewall configuration for this remote server, you use the reload command instead of load, ie:

shorewall reload /etc/shorewall/exports/server-b


On the remote server, you do not have the commands shorewall or shorewall6, but have shorewall-lite and shorewall6-lite respectively, providing a limited amount of options including start and stop.

The above setup works exactly the same for IPv6, though keep in mind to use the /etc/shorewall6/... directory on the master, and the /etc/shorewall6/exports/base/shorewall6.conf file needs to be adjusted as following:

(.. existing configuration ..)


Edit: More details can be found at

17-11-2012, 13:41
Thanks for the guide, I used it on my mKS 2G ubuntu desktop!

17-11-2012, 13:25
Thanks for the tips again, I have a question tho, say that i have more than one of these servers and shorewall on them. Is there some easy way to push new rules to them or do i have to login to each and manually do it?

16-11-2012, 03:20
Hush RTM!

Here's another little tip. The RTM cron-job leaves a lot of messages in the syslog. Personally, I didn't want to see any of these lines:

Nov 16 02:32:01 x /USR/SBIN/CRON[6204]: (root) CMD (/usr/local/rtm/bin/rtm 17 > /dev/null 2> /dev/null)
Nov 16 02:33:01 x /USR/SBIN/CRON[6246]: (root) CMD (/usr/local/rtm/bin/rtm 17 > /dev/null 2> /dev/null)
Nov 16 02:34:01 x /USR/SBIN/CRON[6289]: (root) CMD (/usr/local/rtm/bin/rtm 17 > /dev/null 2> /dev/null)
Nov 16 02:35:01 x /USR/SBIN/CRON[6334]: (root) CMD (/usr/local/rtm/bin/rtm 17 > /dev/null 2> /dev/null)
So, with rsyslog (default on Debian and Ubuntu) this is an easy fix:

cat > /etc/rsyslog.d/01-hushrtm.conf <
This simply adds file /etc/rsyslog.d/01-hushrtm.conf that contains an option to checks if a message (msg) contains (root) CMD (/usr/local/rtm/bin/rtm and orders to filter it (~).

"... wrong length 56"

You could do the above with any other syslog messages, if you wish, but the first course of action would be to try and solve it of course. And on that note, let's say you have IPv6 enabled on the server and are seeing a lot of the following lines:

kernel: IPv6 addrconf: prefix with wrong length 56
This can be solved with the following:

echo "net.ipv6.conf.eth0.autoconf = 0" >> /etc/sysctl.conf
sysctl -p
Please note the DOUBLE greater than sign! The downside with this, is that you need to manually add the IPv6 gateway. However, that should be the case now anyway, as OVH is gradually disabling this option on their routers.

Repeating syslog messages

Another option to quiet down things a little within your syslog is to enable the RepeatedMsgReduction option, which in some distros is disabled by default. On Debian/Ubuntu, this is as simple as the following:

echo "\$RepeatedMsgReduction on" > /etc/rsyslog.d/01-repeatedmsg.conf
service rsyslog restart
Yes, that dollar-sign needs to be escaped. Now rsyslog will keep track of the messages it has just added to the log, and if it notices the message is being repeated, it will simply write a "Last line repeated n times" message ( (triggered by a different kind of message waiting to be added, so n could be 2 or 200).

These are little tricks, but can be helpful when you need to go through your log files to diagnose an issue.

13-11-2012, 09:21
Thank you for the guide!

03-11-2012, 11:27
i just got my mks changed from a old 2g as its a few pounds cheaper then the old ks-2g.

i manged to get a atom n2800 (dualcore with ht) 1.8gz not a bad lillte bad chip.

thanks for the tips on ram .

03-11-2012, 01:39
Very informative, thank you

03-11-2012, 00:28
I've acquired a Kimsufi mKS 2G to play with. As with all servers I use, I record what changes I make, for future reference. I figured some of these might help others get a little more out of the server, so here goes:


The first thing I did was re-partition the server, as by default it creates a separate partition for /home. For me, this is pointless, particularly because in my case more will end up on /var (it's a server, not a desktop). So I created two partitions: one using ext-4 on the root (/) for 498000 MB and the remainder (2000 MB) as swap. You could use parted for this, but might as well use the OVH manager for this - the server is new anyway.

Package list

I've added the squeeze-backport repository to the package sources using:

echo "deb squeeze-backports main" >> /etc/apt/sources.list
and ran an update & upgrade:

apt-get update && apt-get upgrade
The reason for adding the backport repository is because I wanted to use the 3.x version of the kernel, which will come handy in one of the following steps. Ubuntu 12.x already uses these kernels, so you don't have to do so there.

Replacing Bind9

The server was already using quite a bit of memory (comparatively speaking), and this is because OVH installs the Bind9 DNS server by default, to help speed up DNS lookups. But if that's all the DNS server is being used for, one might as well use a much lighter alternative: DNSMasq. So I've replaced it:

apt-get purge bind9 lwresd && apt-get install dnsmasq
I've updated the DNSMasq configuation file to disable its DHCP functions, as I didn't need them. Then further restricted it to listen to local requests only:

(... existing configuation ...)



Remove mdadm

Since the server has only one HDD, there's no reason to run the mdadm monitor (soft-raid), though by default it is. This was quickly removed with:

apt-get purge mdadm
This saved some more memory, which on a machine with only 2GB of RAM is quite welcome!

Change kernel

In Debian 6, the regular repository uses the 2.x range of the linux kernel. I wanted to use the 3.x range (more on that later), so that's why I have added the squeeze-backport repository earlier. I installed the kernel with:

apt-get -t squeeze-backports install linux-image-amd64
It will ask you a few questions along the way, simply select the default answers. For the rest, I followed the same instructions as in Standard Kernels with Ubuntu / Debian.

The server is now humming along with the latest 3.x kernel:

# uname -a
Linux soopadoopa 3.2.0-0.bpo.3-amd64 #1 SMP Thu Aug 23 07:41:30 UTC 2012 x86_64 GNU/Linux


ZRam in its simplest terms is compressed RAM. Although the CPU in the Kimsufi isn't extremely powerful (I ended up with an Atom 230, by the way), I rather have more RAM. And with ZRam, you can create a RAM-based swap disk. At first thought, this sounds a bit pointless, but what happens is when memory needs to be swapped out, it first goes to the ZRam and attempt to compress it. If it still fits in RAM at this point, this is where it will stay. If not, it will revert to the original disk-based swap partition, which is obviously much slower.

ZRam is a kernel module, which is not available in Debian's 2.x range, hence I wanted to use the 3.x range. You could use the modprobe conf file to load the module, or you can use the following handy script as I have done:

wget -O /etc/init.d/zram
chmod +x /etc/init.d/zram
update-rc.d zram defaults
Update 10/3/2013: Different versions of the ZRAM module take different parameters, so you may have to edit the /etc/init.d/zram file accordingly. Please see for the differences.

Before you run the above, I highly recommend you double check the contents of that file (so as not to run anything malicious, in case someone decided to alter that file). The original contents of that file is as following, in case you need it:

PHP Code:
# Provides: zram
# Required-Start:
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Increased Performance In Linux With zRam (Virtual Swap Compressed in RAM)
# Description: Adapted from systemd scripts at

start() {
# get the number of CPUs
num_cpus=$(grep -c processor /proc/cpuinfo)
# if something goes wrong, assume we have 1
"$num_cpus!= ] || num_cpus=1

# set decremented number of CPUs
decr_num_cpus=$((num_cpus 1))

# get the amount of memory in the machine
mem_total_kb=$(grep MemTotal /proc/meminfo grep ---only-matching '[[:digit:]]+')
mem_total=$((mem_total_kb 1024))

# load dependency modules
modprobe zram zram_num_devices=$num_cpus

# initialize the devices
for i in $(seq 0 $decr_num_cpus); do
    echo $((
mem_total num_cpus)) > /sys/block/zram$i/disksize

# Creating swap filesystems
for i in $(seq 0 $decr_num_cpus); do
mkswap /dev/zram$i

# Switch the swaps on
for i in $(seq 0 $decr_num_cpus); do
swapon -p 100 /dev/zram$i

stop() {
# get the number of CPUs
num_cpus=$(grep -c processor /proc/cpuinfo)

# set decremented number of CPUs
decr_num_cpus=$((num_cpus 1))

# Switching off swap
for i in $(seq 0 $decr_num_cpus); do
    if [ 
"$(grep /dev/zram$i /proc/swaps)" != "" ]; then
    sleep 1

    sleep 1
    rmmod zram

"$1" in
        sleep 3
"Usage: $0 {start|stop|restart}"
When you reboot the server, or use the following command:

service zram start
You should see that it creates one or more new swap devices, depending on the amount of CPUs/threads your server has:

# swapon -s
Filename				Type		Size	Used	Priority
/dev/sda2                               partition	2047516	0	-1
/dev/zram0                              partition	1025472	0	100
/dev/zram1                              partition	1025472	0	100
And this is also reflected in your available swap memory:

# free -m
             total       used       free     shared    buffers     cached
Mem:          2002         90       1912          0          5         32
-/+ buffers/cache:         52       1950
Swap:         4002          0       4002

Locking /tmp down

I always lock down the /tmp directory using tmpfs, which prevents things from being executed within that directory (a favorite for hackers). There can be some drawbacks to this, as some applications need to be able to execute from within that directory, or store gobs-and-gobs of data in here - for server environments, this shouldn't be a problem in most cases though.

echo "tmpfs /tmp tmpfs noatime,noexec,nodev,nosuid,size=20%,mode=1777  0 0" >> /etc/fstab

cat > /etc/apt/apt.conf.d/50tmp-mount <
The "size=20%" above limits it to 20% of available memory, which you can adjust (or even omit) if you wish. The /etc/apt.conf.d/50tmp-mount file give the apt package manager temporary "exec" access to the /tmp directory, necessary to perform certain upgrades.


Shorewall remains my favourite tool to manipulate iptables to create a firewall. One should also keep in mind that iptables, or the regular Shorewall for that matter, does NOT protect you from IPv6 traffic. You should use ip6tables / Shorewall6 for this.

First install Shorewall6 (which includes the IPv4 version):

apt-get install shorewall6
And here's a very basic configuration for both Shorewall (IPv4) and Shorewall6 (IPv6):


Cut & paste base configuration in shell:

cat > /etc/shorewall/interfaces < /etc/shorewall/zones < /etc/shorewall/policy < /etc/shorewall/rules <
The above allows SSH and PING (ICMP) from the WAN-side (which is the public internet side) to the fw-side (which is the server/firewall itself). Anything else is dropped - so this means you need to add rules for things like a web or FTP server. The base configuration above should make it a little simpler to do so, but for additional help, visit Anything that's dropped can be seen in your /var/log/syslog file.


The configuration for IPv6 is very similar to the IPv4 version, with the most obvious exception the use of IPv6 addresses (provided you specifically use them).

One thing is to keep in mind is that the TC_ENABLED setting has to be the same for both IPv4 and IPv6, which in Debian had to be adjusted:

(... existing configuration ...)

And once again, a copy & paste base configuration:

cat > /etc/shorewall6/interfaces < /etc/shorewall6/zones < /etc/shorewall6/policy < /etc/shorewall6/rules <
At this point you can (re)start Shorewall (don't do this via /init.d/ or the service command):

shorewall restart
shorewall6 restart
Before you disconnect from SSH, double-check you can still log in! Simply open a 2nd connection to see if it's working. A ping to your server should also still work. If neither is the case, something went wrong with the configuration

If everything works fine, ensure that the firewalls start at boot time:

/etc/default/shorewall6 and /etc/default/shorewall:
(... existing configuration ...)


Lock-down SSH

Also remember to lock down SSH a bit. The first thing you should really do is change the root password that was given to you by OVH.

You can use SSH key-pairs, and then add the public key to the server's .ssh/authorized_keys file. You can create the key-pair inside PuTTy, or using ssh-keygen -t rsa in Linux (skip the keyphrase for ease of use). If you do this, modify /etc/ssh/sshd_config:

(... existing code ...)
PermitRootLogin without-password
This will allow you to login via SSH as root using only the key-pair. People that do not have this key-pair will still be asked for a password, but is simply to thwart them and won't allow you to login (even with the correct password).

If you want to avoid login in as root all together, or want to safeguard against a lost private key, you can add a sudo user (although rescue mode will help as well). In the default install of Debian, sudo is not installed, which can be done with:

apt-get install sudo
Then simply create a user, and add him/her to the sudo group:

adduser johndoe
adduser johndoe sudo
Do make sure to use a sensibly strong password, as it would otherwise defeat the purpose

So, with the above you've given the server basic security, saved a few megabytes of memory, potentially increased the performance a bit and avoided the headache of running out of disk space as most the available space was allocated to /home!