The unattended-upgrades package used on Debian is based on the one from Ubuntu. It is generally pretty safe in my opinion but I only ever enable it for security upgrades.

Installation

# apt-get install unattended-upgrades apitcron

unattended-upgrades handles the actual updates, apticron is used for emailing you of available updates - it is not required but I like it.

Configuring unattended-upgrades

Open up /etc/apt/apt.conf.d/50unattended-upgrades and change it to the content below.

APT::Periodic::Enable "1";
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::AutocleanInterval "7";
APT::Periodic::Unattended-Upgrade "1";
Unattended-Upgrade::Mail "YOUR_EMAIL_HERE";

// Automatically upgrade packages from these (origin, archive) pairs
Unattended-Upgrade::Allowed-Origins {

"${distro_id} stable";
"${distro_id} ${distro_codename}-security";

};

// Automatically reboot *WITHOUT CONFIRMATION* if a
// the file /var/run/reboot-required is found after the upgrade
Unattended-Upgrade::Automatic-Reboot "false";

So lets explain the above. As you can see we enable periodic updates, enable update package lists (triggers an apt-get update), enable autoclean to clean out the local package repository every 7 days, enable the actual unattended update and finally you can set your email address so that you will get an email when an update has happened.
Next up we configure the origins to update from, as you can see we've only enabled security and as a very final step we make sure we've disabled automatic reboots - you probably don't want your server randomly rebooting to update the running kernel, this means you will have to reboot when convenient after a kernel update.

Your unattended update will happen every day, triggered by cron.daily. Next time your cron.daily has triggered, look inside /var/log/unattended-upgrades/unattended-upgrades.log, you should see something like this

2012-01-28 06:54:04,730 INFO Initial blacklisted packages:
2012-01-28 06:54:04,730 INFO Starting unattended upgrades script
2012-01-28 06:54:04,731 INFO Allowed origins are: ["('Debian', 'squeeze-security')"]
2012-01-28 06:54:05,952 INFO No packages found that can be upgraded unattended

If you installed apticron in the above step and want to configure it and use it then continue reading, if not then congratulations everything is done.

Configuring apticron

Open up /etc/apticron/apticron.conf, all you need to change is the EMAIL option.

EMAIL="YOUR_EMAIL_HERE"

Now each day you will receive an email when cron.daily runs with all available package updates.

I finally stopped being lazy and decided to create an HTTPS version of this blog. I know it's not at all required but I decided it could/would be a good thing to do anyway.

For now due to the blog software being crappy it's showing an invalid certificate due to including resources that are not secured - I'll work on fixing that.

It's IPv6 address is: 2a01:7e00::f03c:91ff:fe93:505a

Installation

To install we need to run the following command:

# apt-get install -y sks

Now we build the key database:

# sks build

And change the permissions for the sks user:

# chown -R debian-sks:debian-sks /var/lib/sks/DB

Next we need to make sks start from init, open up /etc/default/sks in your favourite editor and initstart to look like below:

initstart=yes

Now we can start the service with:

# /etc/init.d/sks start

Your keyserver will now be up and running on port 11371.

Web interface

We'll need to create a web folder within sks with the following command:

# mkdir -p /var/lib/sks/www/

Change it's permissions so the sks user can access it.

# chown -R debian-sks:debian-sks /var/lib/sks/www

And finally we need create a single HTML file for the interface, I have provided that too.

# wget http://syslog.tv/downloads/sks-index.html -O /var/lib/sks/www/index.html

Now your PGP server should be accessible from a web browser at http://YOUR_SERVER:11371/ and it should look like mine http://syslog.tv:11371/

First up we'll need to install git and some Python tools to get Gitosis installed.

Where # is used it means you need to either run the command as a superuser with sudo or as root.

# apt-get install -y git-core gitweb python-setuptools

Next we have to clone gitosis from it's git repository and install it.

cd /tmp

git clone git://eagain.net/gitosis.git

cd gitosis

# python setup.py install

Adding your git user

# adduser --system --shell /bin/sh --gecos 'git version control' --group --disabled-password --home /home/git git

The above command creates a new system user with /bin/sh as it's shell with no password and a homedir of /home/git/ and also creates a group with the same name.

Initialising gitosis

You'll need an SSH key for this, if you have one simply copy the contents of it to your new git server, if you do not have one then you can generate one on your machine using

ssh-keygen

And then copy the contents to your server.

My file was copied to /tmp/kura.pub so to initialise I used

sudo -H -u git gitosis-init < /tmp/kura.pub

This command MUST be run as sudo.

You need to do the same but replacing kura.pub with your own key, it has to end in .pub

A note on key format

One of my users (@gump) had an issue where Gitosis would complain about his username having invalid characters

gitosis.init.InsecureSSHKeyUsername: Username contains not allowed characters

This is because Gitosis expects your key to have a username and host at the end of the base64 string like below

ssh-rsa AAAAB3NzaC1yc2EA ... NOHgpPwEBzpnw== kura@odin

Configuring and controlling gitosis

Now that git and gitosis are working on your server, from your local machine you now need to clone your gitosis admin and do all your changes locally, pushing them back to the git server where gitosis will automatically pick them up.

So you need to run

git clone git@YOUR_SERVER:gitosis-admin.git

If everything worked correctly you should have a copy on your local machine now, if you run ls you'll see 1 file and a directory.

1. gitosis.conf
2. keydir

Unsurprisingly gitosis.conf is where gitosis is configured and keydir contains public keys for your users. Each user needs their own public key and it must end in .pub.

So open up gitosis.conf in your favourite editor and add the following:

[gitosis]
gitweb = yes

[group admins]
writable = gitosis-admin test1
members = kura

[repo gitosis-admin]
description = Gitosis admin repository
gitweb = yes

So lets separate that in to parts.

Part 1 - we simply tell gitosis to enable gitweb support.

Part 2 - we configure a group called admins, the admins group has write permissions to 2 repositories; gitosis-admin and test. The test repository will automatically become available once we push this configuration back to gitosis later. We also define a user called kura which you should replace with your own username, each user must have a public key in the keydir with the same name as the user with .pub suffix. E.g. the kura user has a key called kura.pub

Part 3 - We create a repository section which is only really used for gitweb to tell it to display that repository publicly via a browser.

If you do not want your repositories to be public then I advice you skip the parts with gitweb = yes above and also uninstall gitweb and skip the gitweb section below. Or you could lock your gitweb via HTAUTH.

Now the changes have been made you need to commit them to git.

git add *

git commit -m "Initial configuration"

And push them back to the server

git push origin master

Now that is done you can test your access to the test repository created earlier.

git clone git@YOUR_SERVER:test.git

cd test

echo "Hello world" > hello

git add hello

git commit -m "Test"

git push origin master

If the above works then congratulations, everything is good.

Adding users and repositories

Users

To add a user to gitosis you need to add them to a group and put a public key with username.pub as the naming format in to keydir.

Repositories

You simply need to name it in a writable section of a group and it'll instantly be accessible. If you want to make it public in gitweb then you'll need to a [repo] section as shown above.

Configure gitweb

Open up /etc/gitweb.conf in your favourite editor and change $projectroot to

$projectroot = "/home/git/repositories/"

You will also need to add the Apache user to the git group

usermod -G www-data,git www-data

By default Debian and Ubuntu will symlink in an Apache2 config to /etc/apache2/conf.d/gitweb which is accessible from a browser on http://YOUR_SERVER/gitweb

It is possible to configure your kernel to panic when OOM is spawned, which in itself is not useful but, coupled with a kernel option for auto-rebooting a system when the kernel panics it can be a very useful tool.

Think before implementing this and use at your own risk, I take zero responsibility for you using this.

sysctl vm.panic_on_oom=1

sysctl kernel.panic=X # X is the amount of seconds to wait before rebooting

DO NOT FORGET TO CHANGE X

This will inject the changes in to a system that is currently running but will be forgotten on reboot so use the lines below to save permanently.

echo "vm.panic_on_oom=1" >> /etc/sysctl.conf

echo "kernel.panic=X" >> /etc/sysctl.conf

X is the amount of seconds to wait before rebooting. DO NOT FORGET TO CHANGE X

Testing

You can test the changes with a simple C program. Please note if you run this you do so at your own risk.

#include
#include
#include

#define MB 10485760

int main(int argc, char *argv[]) {

void *b = NULL;
int c = 0;

while(1) {

b = (void *) malloc(MB);

if (!b) {

break;

}

memset(b, 10, MB);
printf("Allocating %d MB\n", (++c * 10));

}

exit(0);

}

Compilation

You can download the source from here.

To compile run the command below

gcc -O2 oom.c -o oom

Or download a pre-compiled version here.

Usage

And simply run it using

./oom

After a short period of time allocating and using 10MB chunks of memory your system should run out and restart.

First we need to make sure we have all the stuff we need to compile mk livestatus and run it

apt-get install make build-essential xinetd ucspi-unix

MK Livestatus

Grab the mk livestatus source from here, currently it's version 1.1.10p3 but update the commands below to match your version.

wget http://mathias-kettner.de/download/mk-livestatus-1.1.10p3.tar.gz

tar -xvzf mk-livestatus-1.1.10p3.tar.gz

cd mk-livestatus-1.1.10p3

./configure

make && make install

Xinetd

Now that it's compiled we need to write a xinetd config for it, create a new file called /etc/xinetd.d/livestatus and put the following in it

service livestatus
{

type = UNLISTED
port = 6557
socket_type = stream
protocol = tcp
wait = no
cps = 100 3
instances = 500
per_source = 250
flags = NODELAY
user = nagios
server = /usr/bin/unixcat
server_args = /var/lib/nagios3/rw/live
only_from = 127.0.0.1 # modify this to only allow specific hosts to connect, currenly localhost only
disable = no

}

Now we restart xinetd using

/etc/init.d/xinetd restart

Nagios3

Now we need to open up /etc/nagios3/nagios.cfg and add the following 2 lines

event_broker_options=-1
broker_module=/usr/local/lib/mk-livestatus/livestatus.o /var/lib/nagios3/rw/live

Now we need to restart Nagios

/etc/init.d/nagios3 restart

If you take a look in /var/log/nagios3/nagios.log

tail -n 100 /var/log/nagios3/nagios.log

you should see something like below

[1318547328] livestatus: Livestatus 1.1.10p3 by Mathias Kettner. Socket: '/var/lib/nagios3/rw/live'
[1318547328] livestatus: Please visit us at http://mathias-kettner.de/
[1318547328] livestatus: Hint: please try out OMD - the Open Monitoring Distribution
[1318547328] livestatus: Please visit OMD at http://omdistro.org
[1318547328] Event broker module '/usr/local/lib/mk-livestatus/livestatus.o' initialized successfully.

Also, we can ls the newly created socket

ls -lah /var/lib/nagios3/rw/live

srw-rw---- 1 nagios www-data 0 2011-10-14 00:08 /var/lib/nagios3/rw/live

We can test is by creating a test file called host_query with the following content

GET hosts

And run the following command

unixcat < host_query /var/lib/nagios3/rw/live

If all worked you should see output.

The whole point of this is to get as much load off of Apache as possible to keep the server running nice and smoothly.

Configuration

The configuration below will mean that nginx will serve basically everything;

• static files
• uploaded files and
• cached content

server {

listen 80;
server_name DOMAIN_HERE;access_log /var/log/nginx/access.DOMAIN_HERE.log;

gzip on;
gzip_disable msie6; # disable gzip for IE6
gzip_static on;
gzip_comp_level 9; # highest level of compression
gzip_proxied any;
gzip_types text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;

proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass_header Set-Cookie;root /PATH/TO/WORDPRESS;

# default location, used for the basic proxying
location / {

# if we're requesting a file and it exists, return it and bail out
if (-f $request_filename) {

break;

}

client_max_body_size 2m; # increase this to increase file upload size
proxy_pass http://localhost:APACHE_PORT;

}

# handle uploaded files
location ~* files/ {

root /PATH/TO/WORDPRESS/blogs.dir/BLOG_ID/;

}

# handle static files
location ~* \.(jpg|png|gif|jpeg|js|css|mp3|wav|swf|mov|doc|pdf|xls|ppt|docx|pptx|xlsx|txt|htm|html)$ {

# if the static file doesn't exist, handle it with Apache
if (!-f $request_filename) {

break;
proxy_pass http://localhost:APACHE_PORT;

}

}

set $supercache_file "";
set $supercache_uri $request_uri;

# reset cache URI if POSTing - bypass cache
if ($request_method = POST) {

set $supercache_uri "";

}

# bypass cache if there's a query string
if ($query_string) {

set $supercache_uri "";

}

# bypass cache if one of the cookies below is set
if ($http_cookie ~* "comment_author_|wordpress|wp-postpass_") {

set $supercache_uri "";

}

# if the URI is still set (rules above don't trigger) then set our file location!
if ($supercache_uri ~ ^(.+)$) {

set $supercache_file /wp-content/cache/supercache/$http_host$1index.html;

}

# rewrite the request to the cached HTML file
if (-f $document_root$supercache_file) {

rewrite ^(.*)$ $supercache_file break;

}

# if file exists, return it - will bypass back to Apache if not
if (-f $request_filename) {

break;

}

}

Install

apt-get install pound

Configuration

The default configuration should be pretty good for most purposes, but feel free to tweak as you require.

HTTP

We'll first look at load balancing HTTP, in case you don't want or need HTTPS load balancing.

We'll need delete all the content within ListenHTTP  block, once done it should look like this

ListenHTTP

End

Now we add an address and port to listen on and finally a line to remove an HTTP header

ListenHTTP

Address 0.0.0.0 # all interfaces
Port 80
HeadRemove "X-Forwarded-For"

End

This is a basic configuration, for each backend we want to load balance we'll need to add a service within that listener.

You'll notice we're removing incoming headers called X-Forwarded-For, this is to make sure someone doesn't try to craft them in to a request and abuse them.

ListenHTTP

Address 0.0.0.0 # all interfaces
Port 80
HeadRemove "X-Forwarded-For"

Service

BackEnd

Address 10.0.0.1
Port 80
Priority 1

End
BackEnd

Address 10.0.0.2
Port 80
Priority 1

End

End

End

Here I've added 2 BackEnds that connect to port 80, it's all pretty simple. Add as many as you want/need.

Pound will pass correct HTTP headers through to the backends so you configure those just like you normally would.

HTTPS

HTTPS is basically exactly the same as HTTP except for one fantastic option - SSL termination! Which means we can do the SSL decryption within Pound and talk to our backend servers over standard unencrypted HTTP - this should only be done on a private network.

So, we'll create an HTTPS listened like the one above but with extra options.

ListenHTTPS

Address 0.0.0.0 # all interfaces
Port 443
AddHeader "X-Forwarded-Proto: https"
HeadRemove "X-Forwarded-Proto"
HeadRemove "X-Forwarded-For"
Cert "/path/to/certificate.pem

Service

BackEnd

Address 10.0.0.1
Port 80
Priority 1

End
BackEnd

Address 10.0.0.2
Port 80
Priority 1

End

End

End

You'll notice a few changes here, first we tell the HTTPS listener to listen on port 443 - SSL port.

We add a header to pass back to our backend servers called X-Forwarded-Proto, this is so that on our backend we can inspect this header and use it if required to know we're secure.

We also remove incoming headers called X-Forwarded-Proto and X-Forwarded-For, this is to make sure someone doesn't try to craft them in to a request and abuse them.

Finally is the certificate which needs to be a PEM file with all certificates and keys within it and without passphrases.

Done

Once configured, reload Pound.

/etc/init.d/pound reload

That really was simple.

This is effective because most spam servers are configured not to retry the send whereas real mail servers generally will retry. This sadly does not protect against spam coming from comprised mail servers or accounts like on Hotmail.com.

Installation

apt-get install postgrey

Configuring Postgrey

By default Postgrey runs on 127.0.0.1:60000, which is the local loopback interface so it is not exposed to the outside world.

If you open up /etc/default/postgrey and modify the POSTGREY_OPTS line you can configure how long to grey list for.

--delay=60

would greylist the sending server for 60 seconds (the default value is 300 second, 5 minutes), if a retry was attempted after 60 seconds the sender would automatically become whitelisted, by default this sender is whitelisted for 35 days but can be changed using the --max-age option

--max-age=10

would whitelist for 10 days.

They can be combined as below.

POSTGREY_OPTS="--inet=127.0.0.1:60000 --delay=60 --max-age=10"

Once you're satisfied save and closed and restart Postgrey.

/etc/init.d/postgrey restart

Configuring Postfix

Open up /etc/postfix/main.cf and add the following within smtpd_receipient_restrictions

check_policy_service inet:127.0.0.1:60000

This is best added after your SASL and sender domain checks but before SPF and blacklists, see below for an example

smtpd_recipient_restrictions = permit_mynetworks,

permit_sasl_authenticated,
reject_unauth_destination,
reject_unknown_sender_domain,
check_policy_service inet:127.0.0.1:60000

Now reload Postfix

/etc/init.d/postfix reload

Testing

Now if you tail your mail.log you will see your Postgrey instance rejecting incoming email like below.

Sept 24 22:26:18 heimdall postfix/smtpd[4256]: NOQUEUE: reject: RCPT from example.com[xxx.xxx.xxx.xxx]: 450: Recipient address rejected: Greylisted for 300 seconds (see http://isg.ee.ethz.ch/tools/postgrey/help/spammed.com.html); from=to=proto=ESMTP helo=<example.com>