Here are my experience with the Bubba Two NAS so far. Below are some performance numbers.
Write locally:
lks@bubba:~$ dd if=/dev/zero of=bigfile bs=1M count=1K
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 96.8614 seconds, 11.1 MB/s
Testing raw network traffic:
lks@bubba:~$ iperf -c 192.168.1.10
------------------------------------------------------------
Client connecting to 192.168.1.10, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.3 port 54697 connected with 192.168.1.10 port 5001
[ 3] 0.0-10.0 sec 76.4 MBytes 64.1 Mbits/sec
Write over NFS (exported with UDP):
root@titan:/mnt/lks# dd if=/dev/zero of=bigfile bs=1M count=1K
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 174.882 s, 6.1 MB/s
During the test, the CPU clocks in at about 70%. Since the disk can deliver almost the double of that, I guess the bottleneck is the bus.
Downloading over ftp give around 7-8MB/s (~55-65Mbits/s). Samba around 5-6MB/s (~40-48Mbit/s).
These numbers are more than adequate for most of my multimedia needs. A 720p HD film encoded in MPEG2 needs around 20Mbits/s (~2.4MB/s). But since most films are encoded using MPEG4 (or similar) - a proper encoded 1080p movie will only require around 2-3MB/s.
25 Aug 2010
23 Aug 2010
The Bubba Two NAS
My balcony server finally died on my the other day. It has been running 24/7 for four years in all kinds of weather. I wasn't very surprised - in fact I've been waiting for it to happen. The motherboard had died. I've replaced the motherboard, and its back up. But for how long before a disk or something else fails?
I have backup of (mostly) everything here and there, but I would like to have everything on a separate NAS box. One of the most exciting NAS boxes on the market right now is something called Bubba|Two.
Bubba Two is produced by the Swedish company Excito. Its basically a small Linux server with a big disk. You can use the slick web-interface, or you can ssh into the NAS and treat it like an ordinary Linux-server. It is a LAMP server with SSH running Debian Etch. Samba, proftpd and Mediatomb (upnp) provide the box with file-server capabilities. It even have Squeezecenter installed if you have a Squeezebox (which I happen to have).
Its a ARM processor clocked at 333MHz with 256MB RAM and a 2TB disk. It uses ridiculous low amount of power (max 12W). There is no fan, so the only noise is from the HDD itself - which is barely audible.
Since the default apt-repositories are no longer working (Etch is too old), I change sources.list to:
deb http://archive.debian.org/debian/ etch main
I can now proceed to install NFS-server, Munin-node and Bind. A couple of minutes later, and its all running smoothly. Too easy.
I have backup of (mostly) everything here and there, but I would like to have everything on a separate NAS box. One of the most exciting NAS boxes on the market right now is something called Bubba|Two.
Bubba Two is produced by the Swedish company Excito. Its basically a small Linux server with a big disk. You can use the slick web-interface, or you can ssh into the NAS and treat it like an ordinary Linux-server. It is a LAMP server with SSH running Debian Etch. Samba, proftpd and Mediatomb (upnp) provide the box with file-server capabilities. It even have Squeezecenter installed if you have a Squeezebox (which I happen to have).
Its a ARM processor clocked at 333MHz with 256MB RAM and a 2TB disk. It uses ridiculous low amount of power (max 12W). There is no fan, so the only noise is from the HDD itself - which is barely audible.
Since the default apt-repositories are no longer working (Etch is too old), I change sources.list to:
deb http://archive.debian.org/debian/ etch main
I can now proceed to install NFS-server, Munin-node and Bind. A couple of minutes later, and its all running smoothly. Too easy.
6 Jun 2010
A professional looking resume made in Latex
Some time ago, I needed an updated resume (and no, I could not "just send a Linkedin link"). I started editing it in OpenOffice, and was (again) struck by how terrible it is to edit, format and align a nice layout. I wanted to use something else - something like Latex.
I've been trying out some Latex resume templates, but none have been good enough (they often have terribly layout). I stumbled across the resume to Martin Michlmayr, and immediately spotted that it was created using Latex. It was nice, clean and looked professional - just what I was looking for. One email later, and he sent me the template he used. He has used and modified res, originally developed by someone else (Michael DeCorte in 1988 according to the header).
If you're interested, you can find the files here:
Update: I also need to check out the ModernCV Latex template: http://www.ctan.org/tex-archive/macros/latex/contrib/moderncv/
Update: I've added support for a profile picture (April 2011).
I've been trying out some Latex resume templates, but none have been good enough (they often have terribly layout). I stumbled across the resume to Martin Michlmayr, and immediately spotted that it was created using Latex. It was nice, clean and looked professional - just what I was looking for. One email later, and he sent me the template he used. He has used and modified res, originally developed by someone else (Michael DeCorte in 1988 according to the header).
If you're interested, you can find the files here:
- Latex template from Martin: http://www.larsstrand.no/CV/res.cls
- Latex resume (slightly modified): http://www.larsstrand.no/CV/LarsStrand-resume.tex
- The compiled resume in PDF: http://www.larsstrand.no/CV/LarsStrand-resume.pdf
Update: I also need to check out the ModernCV Latex template: http://www.ctan.org/tex-archive/macros/latex/contrib/moderncv/
Update: I've added support for a profile picture (April 2011).
19 Apr 2010
How to make wine
My soon-to-be-wife and I are brewing delicious fortified wine. We do everything ourselves; we pick various berries, prepare and tap on bottles. This weekend we held a wine-tasting party, and I held a presentation of the whole wine-making-process.
Read more here (8.4MB, Norwegian): http://larsstrand.no/writings/pres/201004-Vin/Hjemmelaget-vin-2010.pdf
Read more here (8.4MB, Norwegian): http://larsstrand.no/writings/pres/201004-Vin/Hjemmelaget-vin-2010.pdf
6 Jan 2010
Network Weathermap
In my last post I used MRTG to monitor the network equipment. MRTG works great with SNMP, but it only present a graph per network port of the switch/router. So, unless you are the network guy, these graphs do not make much sense.
It would be nice to plug in the data from MRTG into a Network Weathermap of some sort. After searching around and trying different weathermaps, the choice fell on "PHP Network Weathermap". It is actively developed, has good documentation and works great for small/medium-sized networks (the map is hand crafted).
The weathermap can use sources from RRDtool which is the backend used by software like Munin, Cacti and MRTG (if enabled) or from the "original" MRTG (comments on the html-pages generated by MRTG). I'll be using the latter datasource - but I'll be sure to try this weathermap with Munin 1.4 another time.
The configuration for each "map" you create is a text-file. This text file can be created using a (simple) editor or manually hand-crafted. Once you know the (simple) syntax and have an overview of the network, a map is easy to create.
Let's go:
1. First you need MRTG up and running
See my previous blog post.
2. Download and install
3. Create a new map
The weathermap comes with a (rudimentary) map editor, but I found it much easier to edit the configuration file myself while I consult the reference manual.
The config file for each map consist of three main parts:
In the global section we define the size of the map, title, and so forth. I also define some additional fonts and template for NODE and LINKS.
#
# PHP Weathermap config
#
# Map: Company Name Core Network
#
#
# The size of the map and title
WIDTH 1100
HEIGHT 740
HTMLSTYLE overlib
TITLE Company Name - Core Network Weathermap
TITLEPOS 10 20
TITLEFONT 14
# The output of the map
HTMLOUTPUTFILE company-core-network.html
IMAGEOUTPUTFILE company-core-network.png
# Information about of the newest and oldest data used from MRTG (freshness of the data)
TIMEPOS 10 690 Created: %d %b %Y %H:%M:%S
MAXTIMEPOS 10 710 Newest data: %d %b %Y %H:%M:%S
MINTIMEPOS 10 730 Oldest data: %d %b %Y %H:%M:%S
# We define some additional fonts
FONTDEFINE 8 /var/www/html/weathermap/docs/example/Vera.ttf 8
FONTDEFINE 9 /var/www/html/weathermap/docs/example/VeraBd.ttf 8
FONTDEFINE 10 /var/www/html/weathermap/docs/example/VeraBd.ttf 10
FONTDEFINE 12 /var/www/html/weathermap/docs/example/Vera.ttf 12
FONTDEFINE 14 /var/www/html/weathermap/docs/example/VeraBd.ttf 14
# Here we define the legend
KEYPOS DEFAULT 300 670 Traffic Load
KEYTEXTCOLOR 0 0 0
KEYOUTLINECOLOR 0 0 0
KEYBGCOLOR 255 255 255
KEYFONT 8
KEYSTYLE horizontal
BGCOLOR 255 255 255
TITLECOLOR 0 0 0
TIMECOLOR 0 0 0
SCALE DEFAULT 0 0 192 192 192
SCALE DEFAULT 0 1 255 255 255
SCALE DEFAULT 1 10 140 0 255
SCALE DEFAULT 10 25 32 32 255
SCALE DEFAULT 25 40 0 192 255
SCALE DEFAULT 40 55 0 240 0
SCALE DEFAULT 55 70 240 240 0
SCALE DEFAULT 70 85 255 192 0
SCALE DEFAULT 85 100 255 0 0
SET key_hidezero_DEFAULT 1
# TEMPLATE-only NODEs:
NODE DEFAULT
MAXVALUE 100
LABELFONT 9
LABELOUTLINECOLOR none
# TEMPLATE-only LINKs:
LINK DEFAULT
BANDWIDTH 1G
#Use "BWLABEL percent" if you want link utilization in percent
BWLABEL bits
WIDTH 3
BWSTYLE angled
BWFONT 8
# NOTE! The next three lines should be on *one* line
NOTES Current bandwidth utilization (in bits):
IN {link:this:bandwidth_in:%0.2k} of {link:this:max_bandwidth_in:%0.2k} ({link:this:inpercent:%0.2f}%)
OUT {link:this:bandwidth_out:%0.2k} of {link:this:max_bandwidth_out:%0.2k} ({link:this:outpercent:%0.2f}%)
# MRTG graph specific sizes
OVERLIBWIDTH 500
OVERLIBHEIGHT 135
# Arrow comments
COMMENTFONT 8
COMMENTSTYLE edge
COMMENTPOS 50 50
# End of global section
3.2 Next, we define some nodes (switches, routers, servers, ..)
We're plotting both the placement, label, icon and - if any - a "info-link" on each node. The "info-link" is:
NODE Internet
LABEL Internet
LABELFONT 12
ICON images/Cisco-network.png
POSITION 400 100
NOTES Internet connection - ISP-name
LABELOUTLINECOLOR none
LABELBGCOLOR 255 233 170
NODE 10.1.1.1.
LABEL 10.1.1.1 [1]
LABELOFFSET S
INFOURL http://mrtg/10.1.1.1.html
ICON images/Cisco-Catalyst-access-gw.png
POSITION 400 400
NOTES Cisco 6500 [1] - Core Switch
# Additional nodes goes here..
...
3.3 Once all the nodes are defined, we add links between them.
Each link fetches its network utilization from MRTG. So we only need to point each link to the corresponding link in MRTG.
# Internet
LINK 10.1.1.1-Internet
NODES 10.1.1.1 Internet
OVERLIBGRAPH mrtg/10.1.1.1/10.1.1.1_241-day.png
# This gives a nice "mouse-over" graph
INFOURL http://mrtg/10.1.1.1/10.1.1.1_241.html
# .. or add the Munin page
TARGET /var/www/html/mrtg/10.1.1.1/10.1.1.1_241.html
BANDWIDTH 10G
# Additional links go here..
...
4. We run weathermap to generate the map
$ cd /var/www/html/weathermap
$ /weathermap --config configs/company-core-network.conf
You can now point your web browser to the newly created html-file (defined in the global section).
5. The last thing we'll do it to up a cron-job so that the map is updated every five minutes
We let it run one minute after MRTG, so that we get most fresh data:
1-59/5 * * * * weather /var/www/html/weathermap/weathercron.sh
This script just execute the same commands as in 4).
6. Hints and some nice features
Examples (with "SET screenshot_mode 1"):
It would be nice to plug in the data from MRTG into a Network Weathermap of some sort. After searching around and trying different weathermaps, the choice fell on "PHP Network Weathermap". It is actively developed, has good documentation and works great for small/medium-sized networks (the map is hand crafted).
The weathermap can use sources from RRDtool which is the backend used by software like Munin, Cacti and MRTG (if enabled) or from the "original" MRTG (comments on the html-pages generated by MRTG). I'll be using the latter datasource - but I'll be sure to try this weathermap with Munin 1.4 another time.
The configuration for each "map" you create is a text-file. This text file can be created using a (simple) editor or manually hand-crafted. Once you know the (simple) syntax and have an overview of the network, a map is easy to create.
Let's go:
1. First you need MRTG up and running
See my previous blog post.
2. Download and install
- Download the latest from here: http://www.network-weathermap.com/download
- Unpack under /var/www/html/weathermap
- Read the manual if you need additional assistance.
3. Create a new map
The weathermap comes with a (rudimentary) map editor, but I found it much easier to edit the configuration file myself while I consult the reference manual.
The config file for each map consist of three main parts:
- Global section
- Node section and
- Link section (between the nodes)
In the global section we define the size of the map, title, and so forth. I also define some additional fonts and template for NODE and LINKS.
#
# PHP Weathermap config
#
# Map: Company Name Core Network
#
#
# The size of the map and title
WIDTH 1100
HEIGHT 740
HTMLSTYLE overlib
TITLE Company Name - Core Network Weathermap
TITLEPOS 10 20
TITLEFONT 14
# The output of the map
HTMLOUTPUTFILE company-core-network.html
IMAGEOUTPUTFILE company-core-network.png
# Information about of the newest and oldest data used from MRTG (freshness of the data)
TIMEPOS 10 690 Created: %d %b %Y %H:%M:%S
MAXTIMEPOS 10 710 Newest data: %d %b %Y %H:%M:%S
MINTIMEPOS 10 730 Oldest data: %d %b %Y %H:%M:%S
# We define some additional fonts
FONTDEFINE 8 /var/www/html/weathermap/docs/example/Vera.ttf 8
FONTDEFINE 9 /var/www/html/weathermap/docs/example/VeraBd.ttf 8
FONTDEFINE 10 /var/www/html/weathermap/docs/example/VeraBd.ttf 10
FONTDEFINE 12 /var/www/html/weathermap/docs/example/Vera.ttf 12
FONTDEFINE 14 /var/www/html/weathermap/docs/example/VeraBd.ttf 14
# Here we define the legend
KEYPOS DEFAULT 300 670 Traffic Load
KEYTEXTCOLOR 0 0 0
KEYOUTLINECOLOR 0 0 0
KEYBGCOLOR 255 255 255
KEYFONT 8
KEYSTYLE horizontal
BGCOLOR 255 255 255
TITLECOLOR 0 0 0
TIMECOLOR 0 0 0
SCALE DEFAULT 0 0 192 192 192
SCALE DEFAULT 0 1 255 255 255
SCALE DEFAULT 1 10 140 0 255
SCALE DEFAULT 10 25 32 32 255
SCALE DEFAULT 25 40 0 192 255
SCALE DEFAULT 40 55 0 240 0
SCALE DEFAULT 55 70 240 240 0
SCALE DEFAULT 70 85 255 192 0
SCALE DEFAULT 85 100 255 0 0
SET key_hidezero_DEFAULT 1
# TEMPLATE-only NODEs:
NODE DEFAULT
MAXVALUE 100
LABELFONT 9
LABELOUTLINECOLOR none
# TEMPLATE-only LINKs:
LINK DEFAULT
BANDWIDTH 1G
#Use "BWLABEL percent" if you want link utilization in percent
BWLABEL bits
WIDTH 3
BWSTYLE angled
BWFONT 8
# NOTE! The next three lines should be on *one* line
NOTES Current bandwidth utilization (in bits):
IN {link:this:bandwidth_in:%0.2k} of {link:this:max_bandwidth_in:%0.2k} ({link:this:inpercent:%0.2f}%)
OUT {link:this:bandwidth_out:%0.2k} of {link:this:max_bandwidth_out:%0.2k} ({link:this:outpercent:%0.2f}%)
# MRTG graph specific sizes
OVERLIBWIDTH 500
OVERLIBHEIGHT 135
# Arrow comments
COMMENTFONT 8
COMMENTSTYLE edge
COMMENTPOS 50 50
# End of global section
3.2 Next, we define some nodes (switches, routers, servers, ..)
We're plotting both the placement, label, icon and - if any - a "info-link" on each node. The "info-link" is:
- a link to the MRTG page of the network switch/router, or if its a server,
- a link to the munin page for that sever.
NODE Internet
LABEL Internet
LABELFONT 12
ICON images/Cisco-network.png
POSITION 400 100
NOTES Internet connection - ISP-name
LABELOUTLINECOLOR none
LABELBGCOLOR 255 233 170
NODE 10.1.1.1.
LABEL 10.1.1.1 [1]
LABELOFFSET S
INFOURL http://mrtg/10.1.1.1.html
ICON images/Cisco-Catalyst-access-gw.png
POSITION 400 400
NOTES Cisco 6500 [1] - Core Switch
# Additional nodes goes here..
...
3.3 Once all the nodes are defined, we add links between them.
Each link fetches its network utilization from MRTG. So we only need to point each link to the corresponding link in MRTG.
# Internet
LINK 10.1.1.1-Internet
NODES 10.1.1.1 Internet
OVERLIBGRAPH mrtg/10.1.1.1/10.1.1.1_241-day.png
# This gives a nice "mouse-over" graph
INFOURL http://mrtg/10.1.1.1/10.1.1.1_241.html
# .. or add the Munin page
TARGET /var/www/html/mrtg/10.1.1.1/10.1.1.1_241.html
BANDWIDTH 10G
# Additional links go here..
...
4. We run weathermap to generate the map
$ cd /var/www/html/weathermap
$ /weathermap --config configs/company-core-network.conf
You can now point your web browser to the newly created html-file (defined in the global section).
5. The last thing we'll do it to up a cron-job so that the map is updated every five minutes
We let it run one minute after MRTG, so that we get most fresh data:
1-59/5 * * * * weather /var/www/html/weathermap/weathercron.sh
This script just execute the same commands as in 4).
6. Hints and some nice features
- If you do a mouse-over on each link, you'll get the day graph from MRTG in a popup.
- If you click on a node, you get either the MRTG page or Munin page for that node.
- You get a timestamp for both the oldest and newest data used on the map
- If you want additional icons, you can get them from Dia. Dia has a lot of really nice network (Cisco) icons and can export to a large number of formats.
Examples (with "SET screenshot_mode 1"):
26 Nov 2009
Network monitoring with MRTG
If you work with any kind of networks, the chances are you've heard of, or even used, MRTG. There are not active development of MRTG today, but bugfix patches are still being added now and then.
So why are we still using it? MRTG just works. It stable and robust. And it does what it is supposed to do and nothing else. This makes MRTG still king of monitoring network equipment over SNMP. Well, that is, until Munin 1.4 is released in a couple of days. Munin 1.4 have (better) SNMP support - they are aiming at MRTG.
So until Munin 1.4 is released and stabilizes, I'll use MRTG in production. I've added some minor wrappers around MRTG so that adding and removing nodes gets dead easy. This way, other people can add/remove equipments without knowing too much about MRTG.
Every Linux distribution out there have MRTG in their repository. If yours don't, change distribution or compile MRTG yourself.
1. First of all, we add all our network equipment in a text file:
$ cat /etc/mrtg/network.cfg
#
# SNMP capable switches goes here
#
# After adding hosts here, run
#
# /etc/mrtg/mrtgmaker.sh
# /etc/mrtg/indexer.sh
#
# Format (community is optional) and override default
#
# [community]@IP description
#
# Example:
# 192.168.1.1 Core Network Router 1 (Location A)
# secret@10.0.0.1 Core Network Router 2 (Location B)
10.1.1.1 Cisco 6500 08/09 Core Network Router 1
192.168.1.1 Cisco 4948 09/09
2. I create a small script that reads the network equipment from the text-file and generate mrtg.cfg:
$ cat /etc/mrtg/mrtgmaker.sh
#!/bin/bash
#
# This should be run every time you add a SNMP capable
# switch under /etc/mrtg/network.cfg
#
[ -r /etc/mrtg/network.cfg ] || exit 1
ALL=""
while read switch
do
if `echo $switch | grep -q ^#` || `echo $switch | grep -q "^$"`; then
continue
fi
HOST=`echo $switch | awk ' { print $1 }'`
ALL="$ALL $HOST"
done < /etc/mrtg/network.cfg
echo "Harvesting SNMP info from $ALL"
/usr/bin/cfgmaker --snmp-options=:::::2 --show-op-down --global 'AddHead[_]: ' --global 'Options[_]: growright, bits' --global 'HtmlDir: /var/www/html/mrtg' --global 'ImageDir: /var/www/html/mrtg' --global 'LogDir: /var/lib/mrtg' --global 'ThreshDir: /var/lib/mrtg' --community=SECRET --output=/etc/mrtg/mrtg.cfg --subdirs=HOSTNAME $ALL
echo "Config file: /etc/mrtg/mrtg.cfg"
echo "You should now run /etc/mrtg/indexer.sh"
3. Then we need to add a script to update the HTML
4. We add a stylesheet to make thing a little prettier:
$ cat /var/www/html/mrtg/mrtg.css
body {
background-color: #EFEFEF;
color: #000000;
font-family: sans-serif;
font-size: 12px;
}
h1 {
background-color: #CCCCCC;
font-family: sans-serif;
font-size: 18px;
font-weight: bold;
}
h2 {
font-family: sans-serif;
font-size: 16px;
font-weight: bold;
}
a {
text-decoration: none;
}
5. We test:
# /etc/mrtg/mrtgmaker.sh
Harvesting SNMP info from 10.1.1.1 192.168.1.1
Config file: /etc/mrtg/mrtg.cfg
You should now run /etc/mrtg/indexer.sh
# /etc/mrtg/indexer.sh
Indexing 10.1.1.1
Indexing 192.168.1.1
We are then presented with an overview page then takes us to each switch/router:
So why are we still using it? MRTG just works. It stable and robust. And it does what it is supposed to do and nothing else. This makes MRTG still king of monitoring network equipment over SNMP. Well, that is, until Munin 1.4 is released in a couple of days. Munin 1.4 have (better) SNMP support - they are aiming at MRTG.
So until Munin 1.4 is released and stabilizes, I'll use MRTG in production. I've added some minor wrappers around MRTG so that adding and removing nodes gets dead easy. This way, other people can add/remove equipments without knowing too much about MRTG.
Every Linux distribution out there have MRTG in their repository. If yours don't, change distribution or compile MRTG yourself.
1. First of all, we add all our network equipment in a text file:
$ cat /etc/mrtg/network.cfg
#
# SNMP capable switches goes here
#
# After adding hosts here, run
#
# /etc/mrtg/mrtgmaker.sh
# /etc/mrtg/indexer.sh
#
# Format (community is optional) and override default
#
# [community]@IP description
#
# Example:
# 192.168.1.1 Core Network Router 1 (Location A)
# secret@10.0.0.1 Core Network Router 2 (Location B)
10.1.1.1 Cisco 6500 08/09 Core Network Router 1
192.168.1.1 Cisco 4948 09/09
2. I create a small script that reads the network equipment from the text-file and generate mrtg.cfg:
$ cat /etc/mrtg/mrtgmaker.sh
#!/bin/bash
#
# This should be run every time you add a SNMP capable
# switch under /etc/mrtg/network.cfg
#
[ -r /etc/mrtg/network.cfg ] || exit 1
ALL=""
while read switch
do
if `echo $switch | grep -q ^#` || `echo $switch | grep -q "^$"`; then
continue
fi
HOST=`echo $switch | awk ' { print $1 }'`
ALL="$ALL $HOST"
done < /etc/mrtg/network.cfg
echo "Harvesting SNMP info from $ALL"
/usr/bin/cfgmaker --snmp-options=:::::2 --show-op-down --global 'AddHead[_]: ' --global 'Options[_]: growright, bits' --global 'HtmlDir: /var/www/html/mrtg' --global 'ImageDir: /var/www/html/mrtg' --global 'LogDir: /var/lib/mrtg' --global 'ThreshDir: /var/lib/mrtg' --community=SECRET --output=/etc/mrtg/mrtg.cfg --subdirs=HOSTNAME $ALL
echo "Config file: /etc/mrtg/mrtg.cfg"
echo "You should now run /etc/mrtg/indexer.sh"
3. Then we need to add a script to update the HTML
$ cat /etc/mrtg/indexer.sh
#!/bin/bash
#
# This should be run every time you add a SNMP capable
# switch under /etc/mrtg/network.cfg
#
echo '<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>MRTG @ Company Name</title>
<meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1">
<meta http-equiv="Refresh" content="300">
<meta http-equiv="Cache-Control" content="no-cache">
<meta http-equiv="Pragma" content="no-cache">
<meta name="robots" content="noarchive">
<link href="favicon.ico" rel="shortcut icon">
<link rel="stylesheet" type="text/css" href="mrtg.css">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<h1>MRTG @ Company Name</h1>
<img src="company_logo.png" height="135" width="130" align="right" alt="Company Name logo"/>
<blockquote>
' > /var/www/html/mrtg/index.html
while read switch
do
if `echo $switch | grep -q ^#` || `echo $switch | grep -q "^$"`; then
continue
fi
IP=$(echo $switch | cut -d" " -f1)
IP=${IP#*@}
DESC=$(echo $switch | cut -d" " -f2-40)
DATE=$(date)
DNSNAME=$(dig +short -x $IP 2> /dev/null)
echo "Indexing $IP"
/usr/bin/indexmaker --nolegend --subtitle='<h2><a href="../">Back home</a></h2>' \
--pageend="<em>MRTG @ Company Name - generated on $HOSTNAME</em>" \
--addhead='<link rel="stylesheet" type="text/css" href="/mrtg.css">' \
--output /var/www/html/mrtg/$IP.html --filter name=~$IP \
--title="Network utilitization for $DNSNAME ($IP)" /etc/mrtg/mrtg.cfg
if [ -z $DNSNAME ]
then
echo "<font size="+1">⇒ <a href="$IP.html">$IP</a> — $DESC</font> <br>" >> /var/www/html/mrtg/index.html
else
echo "<font size="+1">⇒ <a href="$IP.html">$IP</a>, $DNSNAME — $DESC</font> <br>" >> /var/www/html/mrtg/index.html
fi
done < /etc/mrtg/network.cfg
echo "
</blockquote>
<p>MRTG is also used as datasource for our Network Weathermap — <a href="http://weathermap/">http://weathermap</a>
<hr>
<em><font size=\"-1\">More info: <a href=\"http://wiki/mediawiki/index.php/MRTG\">
http://wiki/mediawiki/index.php/MRTG</a></font><br></em>
<em><font size=\"-1\">Generated by $HOSTNAME:$0</font></em>
</body>
</html>" >> /var/www/html/mrtg/index.html
4. We add a stylesheet to make thing a little prettier:
$ cat /var/www/html/mrtg/mrtg.css
body {
background-color: #EFEFEF;
color: #000000;
font-family: sans-serif;
font-size: 12px;
}
h1 {
background-color: #CCCCCC;
font-family: sans-serif;
font-size: 18px;
font-weight: bold;
}
h2 {
font-family: sans-serif;
font-size: 16px;
font-weight: bold;
}
a {
text-decoration: none;
}
5. We test:
# /etc/mrtg/mrtgmaker.sh
Harvesting SNMP info from 10.1.1.1 192.168.1.1
Config file: /etc/mrtg/mrtg.cfg
You should now run /etc/mrtg/indexer.sh
# /etc/mrtg/indexer.sh
Indexing 10.1.1.1
Indexing 192.168.1.1
We are then presented with an overview page then takes us to each switch/router:
27 Aug 2009
Slackware 13 released!
Slackware 13 was released yesterday. It's the oldest currently maintained Linux distribution out there, and with good reason. It is clean, simple and without the "bells and whistles" that clobbers up so many other distributions.
Slackware was for myself (and for many of my friends and colleagues) my first encounter with Linux. I used Slackware for many years, and still do on occasions. Its a great distribution to really learn Linux and not learn a Linux distribution. I will say that if you really know Linux (and Slackware), you will know most Linux distributions as well.
You would think Slackware was abandoned for other more popular distributions nowadays, but there is still a large active Slackware community and user base out there. It is in fact, one of the most downloaded Linux distributions (in both MB and number of hits) for Norway's largest ftp-site:
http://ftp.uio.no/stats/usage_200907.html#TOPURLS
Slackware was for myself (and for many of my friends and colleagues) my first encounter with Linux. I used Slackware for many years, and still do on occasions. Its a great distribution to really learn Linux and not learn a Linux distribution. I will say that if you really know Linux (and Slackware), you will know most Linux distributions as well.
You would think Slackware was abandoned for other more popular distributions nowadays, but there is still a large active Slackware community and user base out there. It is in fact, one of the most downloaded Linux distributions (in both MB and number of hits) for Norway's largest ftp-site:
http://ftp.uio.no/stats/usage_200907.html#TOPURLS
16 Jun 2009
Quick and strong file-encryption with OpenSSL
To quickly encrypt a file with a password of your choice you can use OpenSSL. OpenSSL supports a whole range of ciphers, including government approved encryption algorithms. The encryption algorithm AES is the only accepted open confidentiality algorithm here in Norway (read more here). AES is the new algorithm replacing DES. You can read all about AES and DES elsewhere.
To encrypt a file using AES with a 256 bit key-length:
$ openssl enc -e -aes-256-cbc -salt -in filename.odp -out filename.odp.enc
enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:
The encrypted file is now found as filename.odp.enc
Since symmetric block ciphers process one block of data at the time (AES uses a block length of 128 bits), it is important that we use CBC mode. CBC prevents repeating plaintext to create the same (repeating) ciphertext. Use option -p to have OpenSSL print out the salt, key and IV used:
$ openssl enc -e -aes-256-cbc -salt -p -in filename.odp -out filename.odp.enc
enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:
salt=92BCA2EA0EABCA62
key=1BCE6E251E86A6379066B634FD20CD3090981B50CDF3FF5634C49DCF4A1812A5
iv =9604DF84236BB3965083830396277636
To decrypt the file: Note! If you type in the wrong password, you'll get garbled output since there is no way to check if the password is correct.
$ openssl enc -d -aes-256-cbc -in filename.odp.enc -out filename.odp
enter aes-256-cbc decryption password:
And the decrypted file is found as filename.odp
For example: You can encrypt a file with a password of your choice. Send the file to the receiver, and then communicate to him over another secure communication channel what the password is (and that you've used "aes-256-cbc").
To encrypt a file using AES with a 256 bit key-length:
$ openssl enc -e -aes-256-cbc -salt -in filename.odp -out filename.odp.enc
enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:
The encrypted file is now found as filename.odp.enc
Since symmetric block ciphers process one block of data at the time (AES uses a block length of 128 bits), it is important that we use CBC mode. CBC prevents repeating plaintext to create the same (repeating) ciphertext. Use option -p to have OpenSSL print out the salt, key and IV used:
$ openssl enc -e -aes-256-cbc -salt -p -in filename.odp -out filename.odp.enc
enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:
salt=92BCA2EA0EABCA62
key=1BCE6E251E86A6379066B634FD20CD3090981B50CDF3FF5634C49DCF4A1812A5
iv =9604DF84236BB3965083830396277636
To decrypt the file: Note! If you type in the wrong password, you'll get garbled output since there is no way to check if the password is correct.
$ openssl enc -d -aes-256-cbc -in filename.odp.enc -out filename.odp
enter aes-256-cbc decryption password:
And the decrypted file is found as filename.odp
For example: You can encrypt a file with a password of your choice. Send the file to the receiver, and then communicate to him over another secure communication channel what the password is (and that you've used "aes-256-cbc").
19 May 2009
Encrypted swap, tmp and home partition in Ubuntu 9.04
I really would like to have an encrypted swap, tmp and home partition on my laptop. In case it gets stolen or if I should forget it somewhere, I can be sure that no-one would be able to read my private files. In this mini-howto I set my home partition using LVM, but using a regular partition should work just fine. This howto should also work, with minor modification, if you use another distribution than Ubuntu.
Updated:
May 2009: Updated for Ubuntu 9.04. Added encrypted /tmp.
May 2008: Init for Ubuntu 8.04.
Note! Both the "server" and "alternate" Ubuntu ISO-images provide the option to encrypt your home directory (but in a different way using eCryptfs. Swap and /tmp are not encrypted). It might be an easier solution if you find this page too hard to follow. The difference? They are two different implementations. eCryptfs is file level encryption, LUKS is block device (/dev/sda3). Think of it like SSL vs. IPSec. Both have their advantages and drawbacks. Read more here and here
By using Linux Unified Key Setup (LUKS) setting up encrypted partition in Linux is done in no time.
Prerequisites
Install required packages:
# apt-get install lvm2 cryptsetup libpam-mount
The device-mapper should be active (if not, reboot):
$ ls -l /dev/mapper/
total 0
crw-rw---- 1 root root 10, 61 2009-05-19 15:39 control
..with support for crypto:
# dmsetup targets | grep crypt
crypt v1.6.0
Good. Now we're ready.
Part I: Setting up encrypted swap
Step 1: Disable your current swap partition.
# swapoff /dev/sda2
Step 2: Fill your swap with random data.
# dd if=/dev/urandom of=/dev/sda2 bs=1M
1954+0 records in
1953+0 records out
2048094208 bytes (2.0 GB) copied, 529.177 s, 3.9 MB/s
As you see, this might take some time depending on your swap size. So go grab a coffe.
Step 3: Configure encrypted swap.
Add this to your /etc/crypttab
# cat /etc/crypttab
...
cryptoswap /dev/sda2 /dev/urandom cipher=aes-cbc-essiv:sha256,size=256,hash=sha256,swap
Why /dev/urandom and not /dev/random? The latter blocks until it got enough entropy to continue, urandom don't. So if you use random instead urandom you might have to wait during boot until enough entropy is collected. (It does help to type your keyboard and move the mouse.) Use /dev/random if you're really paranoid.
Next, change your swap entry in /etc/fstab to this:
# cat /etc/fstab
...
/dev/mapper/cryptoswap swap swap sw 0 0
For every time we boot, swap will be encrypted with a different encryption key.
Step 4: Test it.
Reboot to test.
We now have an encrypted swap:
# cat /proc/swaps
Filename Type Size Used Priority
/dev/mapper/cryptoswap partition 2000084 0 -1
# cryptsetup status cryptoswap
/dev/mapper/cryptoswap is active:
cipher: aes-cbc-essiv:sha256
keysize: 256 bits
device: /dev/sda2
offset: 0 sectors
size: 4000185 sectors
mode: read/write
Good. Now we're safe right?
Part II: Dealing with /tmp
To protect /tmp, we have two choices. 1) we can encrypt it like we did with swap or 2) we can create a ramdisk. The content of a ramdisk don't survive a reboot and /tmp rarely is used for any big files, its is also a good option. But, paranoid as we are, we choose option 1)
The setup is almost identical as for swap:
Step 1: Setting up a tmp partition using LVM.
If you use a regular partition, you can easily skip this step.
# pvcreate /dev/sda3
Physical volume "/dev/sda3" successfully created
# vgcreate vg_storage /dev/sda3
Volume group "vg_storage" successfully created
# vgchange -a y vg_storage
0 logical volume(s) in volume group "vg_storage" now active
# lvcreate -L500M -nlv_tmp vg_storage
Logical volume "lv_tmp" created
For more details on how to use LVM, please check out the excellent LVM HOWTO.
Step 2: Fill the partition with random data.
# dd if=/dev/urandom of=/dev/vg_storage/lv_tmp
1024001+0 records in
1024000+0 records out
524288000 bytes (524 MB) copied, 139.983 s, 3.7 MB/s
Step 3: Add entry in /etc/crypttab
# cat /etc/crypttab
...
cryptotmp /dev/vg_storage/lv_tmp /dev/random cipher=aes-cbc-essiv:sha256,size=256,hash=sha256,tmp
Now, since /tmp is encrypted with a new key every time, the filsystem must be created every time as well. The option "tmp" fixes that for us and calls mkfs before mount. Since it is created with filesystem ext2, we add in fstab:
# cat /etc/fstab
...
/dev/mapper/cryptotmp /tmp ext2 defaults 0 0
Step 4: Test it.
Reboot to test.
We now have an encrypted /tmp partition as well. Great!
# cryptsetup status cryptotmp
/dev/mapper/cryptotmp is active:
cipher: aes-cbc-essiv:sha256
keysize: 256 bits
device: /dev/mapper/vg_storage-lv_tmp
offset: 0 sectors
size: 1024000 sectors
mode: read/write
Part III: Creating and setting up an encrypted home partition
Step 1: Setting up a home partition using LVM.
If you use a regular partition, you can easily skip this step.
# lvcreate -L20G -nlv_home vg_storage
Logical volume "lv_home" created
Step 2: Fill your soon-to-be home partition with random data.
# dd if=/dev/urandom of=/dev/vg_storage/lv_home
20481+0 records in
20480+0 records out
21474836480 bytes (21 GB) copied, 5554.23 s, 3.9 MB/s
This will take even longer than the swap partition. So go for lunch or something.
Step 3: Initialize the partition and set initial key.
Remember, if you use a weak password, your screwed. If you forget the password, its game over.
# cryptsetup -c aes-cbc-essiv:sha256 -y -s 256 luksFormat /dev/vg_storage/lv_home
WARNING!
========
This will overwrite data on /dev/vg_storage/lv_home irrevocably.
Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:
Command successful.
We use cipher "aes-cbc-essi", since the default is vulnerable to Watermarking attack.
Step 4: Create a device mapping.
# cryptsetup luksOpen /dev/vg_storage/lv_home cryptohome
Enter LUKS passphrase:
key slot 0 unlocked.
Command successful.
This will create a device mapping, as can bee see under:
$ ls -l /dev/mapper/
total 0
crw-rw---- 1 root root 10, 61 2009-05-19 15:39 control
brw-rw---- 1 root disk 252, 4 2009-05-19 15:52 cryptohome
brw-rw---- 1 root disk 252, 1 2009-05-19 15:39 cryptoswap
brw-rw---- 1 root disk 252, 2 2009-05-19 15:39 cryptotmp
brw-rw---- 1 root disk 252, 3 2009-05-19 15:52 vg_storage-lv_home
brw-rw---- 1 root disk 252, 0 2009-05-19 15:39 vg_storage-lv_tmp
Note that LVM also uses the device-mapper (that is why LVM volumes also are listed).
Or, you can use the command "dmsetup ls" to list the mapped devices:
$ dmsetup ls
cryptoswap (252, 1)
vg_storage-lv_tmp (252, 0)
cryptotmp (252, 2)
vg_storage-lv_home (252, 3)
cryptohome (252, 4)
Step 5: Create a filesystem.
We now have an encrypted partition. To use it, we need to create a filesystem on it:
# mkfs.ext4 -j -m 1 -O dir_index,filetype,sparse_super /dev/mapper/cryptohome
mke2fs 1.41.4 (27-Jan-2009)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
1310720 inodes, 5242623 blocks
52426 blocks (1.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
160 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 28 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
Step 6: Testing!
We start by closing and reopen the encrypted partition before we mount it:
# cryptsetup luksClose cryptohome
# cryptsetup luksOpen /dev/vg_storage/lv_home cryptohome
Enter LUKS passphrase:
key slot 0 unlocked.
Command successful.
# mkdir -p /mnt/cryptohome
# mount /dev/mapper/cryptohome /mnt/cryptohome
# touch /mnt/cryptohome/testfile
# ls /mnt/cryptohome/
lost+found testfile
We can also confirm that it works by issuing the command:
# cryptsetup status cryptohome
/dev/mapper/cryptohome is active:
cipher: aes-cbc-essiv:sha256
keysize: 256 bits
device: /dev/mapper/vg_storage-lv_home
offset: 2056 sectors
size: 41940984 sectors
mode: read/write
Now would be a good time to move your current home to this partition.
Finally we umount:
# umount /mnt/cryptohome
# cryptsetup luksClose cryptohome
Step 7: Cryptohome mounted at boot or at login?
Now you have to take a choice. A) You can enable the partition at boot time, but then the boot sequence is interrupted asking you for the LUKS password. B) If you want the partition automatically mounted when you login, skip to the next section.
Instead of manually typing in password, you can have the key stored externally - for instance on a usb-stick. Read more about that here.
You want to enable mounting at boot time? Then update /etc/crypttab:
# cat /etc/crypttab
...
cryptohome /dev/vg_storage/lv_home none luks
And /etc/fstab:
# cat /etc/fstab
...
/dev/mapper/cryptohome /home/ ext4 relatime,errors=remount-ro 0 2
When you now reboot, the boot process is interrupted asking you for the LUKS password. If you type it correctly, the home partition is mounted. When you now log in, you will have an encrypted home partition ready waiting for you.
Part IV: Automatically mount when logging in.
A more elegant solution would be to automatically mount the home partition the same time you log in. This require that you use the same password for login as for the encrypted partition. (Actually that is not entirely true. You may have the password stored on file somewhere. But in this howto, we assume you have the same password for both.)
Step 1: Remove home partition from /etc/fstab
If there is an entry to your (encrypted) home partition in /etc/fstab, remove it
# cat /etc/fstab
...
/dev/mapper/cryptohome /home ext4 relatime,errors=remount-ro 0 2 # this gotta go
Step 2: Update /etc/crypttab
Make sure the you have a line in /etc/crypttab that reads as follows:
# cat /etc/crypttab
...
cryptohome /dev/vg_storage/lv_home noauto luks
Step 3: Configure pam_mount
Add the following entry in /etc/security/pam_mount.conf.xml. This file is heavily commented, and it may be useful to read the comments.
# cat /etc/security/pam_mount.conf.xml
...
Step 4: Configure PAM
No longer necessary. As of 9.04 all options already included.
Step 5: Test!
Log out and back in. You should now have an encrypted home:
$ df -h
...
/dev/mapper/_dev_mapper_vg_storage-lv_home
20G 296M 20G 2% /home
Congratulation, you now have an encrypted swap, tmp and home partition!
A final advice: Take regular backups.
Useful links:
Updated:
May 2009: Updated for Ubuntu 9.04. Added encrypted /tmp.
May 2008: Init for Ubuntu 8.04.
Note! Both the "server" and "alternate" Ubuntu ISO-images provide the option to encrypt your home directory (but in a different way using eCryptfs. Swap and /tmp are not encrypted). It might be an easier solution if you find this page too hard to follow. The difference? They are two different implementations. eCryptfs is file level encryption, LUKS is block device (/dev/sda3). Think of it like SSL vs. IPSec. Both have their advantages and drawbacks. Read more here and here
By using Linux Unified Key Setup (LUKS) setting up encrypted partition in Linux is done in no time.
Prerequisites
Install required packages:
# apt-get install lvm2 cryptsetup libpam-mount
The device-mapper should be active (if not, reboot):
$ ls -l /dev/mapper/
total 0
crw-rw---- 1 root root 10, 61 2009-05-19 15:39 control
..with support for crypto:
# dmsetup targets | grep crypt
crypt v1.6.0
Good. Now we're ready.
Part I: Setting up encrypted swap
Step 1: Disable your current swap partition.
# swapoff /dev/sda2
Step 2: Fill your swap with random data.
# dd if=/dev/urandom of=/dev/sda2 bs=1M
1954+0 records in
1953+0 records out
2048094208 bytes (2.0 GB) copied, 529.177 s, 3.9 MB/s
As you see, this might take some time depending on your swap size. So go grab a coffe.
Step 3: Configure encrypted swap.
Add this to your /etc/crypttab
# cat /etc/crypttab
...
cryptoswap /dev/sda2 /dev/urandom cipher=aes-cbc-essiv:sha256,size=256,hash=sha256,swap
Why /dev/urandom and not /dev/random? The latter blocks until it got enough entropy to continue, urandom don't. So if you use random instead urandom you might have to wait during boot until enough entropy is collected. (It does help to type your keyboard and move the mouse.) Use /dev/random if you're really paranoid.
Next, change your swap entry in /etc/fstab to this:
# cat /etc/fstab
...
/dev/mapper/cryptoswap swap swap sw 0 0
For every time we boot, swap will be encrypted with a different encryption key.
Step 4: Test it.
Reboot to test.
We now have an encrypted swap:
# cat /proc/swaps
Filename Type Size Used Priority
/dev/mapper/cryptoswap partition 2000084 0 -1
# cryptsetup status cryptoswap
/dev/mapper/cryptoswap is active:
cipher: aes-cbc-essiv:sha256
keysize: 256 bits
device: /dev/sda2
offset: 0 sectors
size: 4000185 sectors
mode: read/write
Good. Now we're safe right?
Part II: Dealing with /tmp
To protect /tmp, we have two choices. 1) we can encrypt it like we did with swap or 2) we can create a ramdisk. The content of a ramdisk don't survive a reboot and /tmp rarely is used for any big files, its is also a good option. But, paranoid as we are, we choose option 1)
The setup is almost identical as for swap:
Step 1: Setting up a tmp partition using LVM.
If you use a regular partition, you can easily skip this step.
# pvcreate /dev/sda3
Physical volume "/dev/sda3" successfully created
# vgcreate vg_storage /dev/sda3
Volume group "vg_storage" successfully created
# vgchange -a y vg_storage
0 logical volume(s) in volume group "vg_storage" now active
# lvcreate -L500M -nlv_tmp vg_storage
Logical volume "lv_tmp" created
For more details on how to use LVM, please check out the excellent LVM HOWTO.
Step 2: Fill the partition with random data.
# dd if=/dev/urandom of=/dev/vg_storage/lv_tmp
1024001+0 records in
1024000+0 records out
524288000 bytes (524 MB) copied, 139.983 s, 3.7 MB/s
Step 3: Add entry in /etc/crypttab
# cat /etc/crypttab
...
cryptotmp /dev/vg_storage/lv_tmp /dev/random cipher=aes-cbc-essiv:sha256,size=256,hash=sha256,tmp
Now, since /tmp is encrypted with a new key every time, the filsystem must be created every time as well. The option "tmp" fixes that for us and calls mkfs before mount. Since it is created with filesystem ext2, we add in fstab:
# cat /etc/fstab
...
/dev/mapper/cryptotmp /tmp ext2 defaults 0 0
Step 4: Test it.
Reboot to test.
We now have an encrypted /tmp partition as well. Great!
# cryptsetup status cryptotmp
/dev/mapper/cryptotmp is active:
cipher: aes-cbc-essiv:sha256
keysize: 256 bits
device: /dev/mapper/vg_storage-lv_tmp
offset: 0 sectors
size: 1024000 sectors
mode: read/write
Part III: Creating and setting up an encrypted home partition
Step 1: Setting up a home partition using LVM.
If you use a regular partition, you can easily skip this step.
# lvcreate -L20G -nlv_home vg_storage
Logical volume "lv_home" created
Step 2: Fill your soon-to-be home partition with random data.
# dd if=/dev/urandom of=/dev/vg_storage/lv_home
20481+0 records in
20480+0 records out
21474836480 bytes (21 GB) copied, 5554.23 s, 3.9 MB/s
This will take even longer than the swap partition. So go for lunch or something.
Step 3: Initialize the partition and set initial key.
Remember, if you use a weak password, your screwed. If you forget the password, its game over.
# cryptsetup -c aes-cbc-essiv:sha256 -y -s 256 luksFormat /dev/vg_storage/lv_home
WARNING!
========
This will overwrite data on /dev/vg_storage/lv_home irrevocably.
Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:
Command successful.
We use cipher "aes-cbc-essi", since the default is vulnerable to Watermarking attack.
Step 4: Create a device mapping.
# cryptsetup luksOpen /dev/vg_storage/lv_home cryptohome
Enter LUKS passphrase:
key slot 0 unlocked.
Command successful.
This will create a device mapping, as can bee see under:
$ ls -l /dev/mapper/
total 0
crw-rw---- 1 root root 10, 61 2009-05-19 15:39 control
brw-rw---- 1 root disk 252, 4 2009-05-19 15:52 cryptohome
brw-rw---- 1 root disk 252, 1 2009-05-19 15:39 cryptoswap
brw-rw---- 1 root disk 252, 2 2009-05-19 15:39 cryptotmp
brw-rw---- 1 root disk 252, 3 2009-05-19 15:52 vg_storage-lv_home
brw-rw---- 1 root disk 252, 0 2009-05-19 15:39 vg_storage-lv_tmp
Note that LVM also uses the device-mapper (that is why LVM volumes also are listed).
Or, you can use the command "dmsetup ls" to list the mapped devices:
$ dmsetup ls
cryptoswap (252, 1)
vg_storage-lv_tmp (252, 0)
cryptotmp (252, 2)
vg_storage-lv_home (252, 3)
cryptohome (252, 4)
Step 5: Create a filesystem.
We now have an encrypted partition. To use it, we need to create a filesystem on it:
# mkfs.ext4 -j -m 1 -O dir_index,filetype,sparse_super /dev/mapper/cryptohome
mke2fs 1.41.4 (27-Jan-2009)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
1310720 inodes, 5242623 blocks
52426 blocks (1.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
160 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 28 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
Step 6: Testing!
We start by closing and reopen the encrypted partition before we mount it:
# cryptsetup luksClose cryptohome
# cryptsetup luksOpen /dev/vg_storage/lv_home cryptohome
Enter LUKS passphrase:
key slot 0 unlocked.
Command successful.
# mkdir -p /mnt/cryptohome
# mount /dev/mapper/cryptohome /mnt/cryptohome
# touch /mnt/cryptohome/testfile
# ls /mnt/cryptohome/
lost+found testfile
We can also confirm that it works by issuing the command:
# cryptsetup status cryptohome
/dev/mapper/cryptohome is active:
cipher: aes-cbc-essiv:sha256
keysize: 256 bits
device: /dev/mapper/vg_storage-lv_home
offset: 2056 sectors
size: 41940984 sectors
mode: read/write
Now would be a good time to move your current home to this partition.
Finally we umount:
# umount /mnt/cryptohome
# cryptsetup luksClose cryptohome
Step 7: Cryptohome mounted at boot or at login?
Now you have to take a choice. A) You can enable the partition at boot time, but then the boot sequence is interrupted asking you for the LUKS password. B) If you want the partition automatically mounted when you login, skip to the next section.
Instead of manually typing in password, you can have the key stored externally - for instance on a usb-stick. Read more about that here.
You want to enable mounting at boot time? Then update /etc/crypttab:
# cat /etc/crypttab
...
cryptohome /dev/vg_storage/lv_home none luks
And /etc/fstab:
# cat /etc/fstab
...
/dev/mapper/cryptohome /home/ ext4 relatime,errors=remount-ro 0 2
When you now reboot, the boot process is interrupted asking you for the LUKS password. If you type it correctly, the home partition is mounted. When you now log in, you will have an encrypted home partition ready waiting for you.
Part IV: Automatically mount when logging in.
A more elegant solution would be to automatically mount the home partition the same time you log in. This require that you use the same password for login as for the encrypted partition. (Actually that is not entirely true. You may have the password stored on file somewhere. But in this howto, we assume you have the same password for both.)
Step 1: Remove home partition from /etc/fstab
If there is an entry to your (encrypted) home partition in /etc/fstab, remove it
# cat /etc/fstab
...
/dev/mapper/cryptohome /home ext4 relatime,errors=remount-ro 0 2 # this gotta go
Step 2: Update /etc/crypttab
Make sure the you have a line in /etc/crypttab that reads as follows:
# cat /etc/crypttab
...
cryptohome /dev/vg_storage/lv_home noauto luks
Step 3: Configure pam_mount
Add the following entry in /etc/security/pam_mount.conf.xml. This file is heavily commented, and it may be useful to read the comments.
# cat /etc/security/pam_mount.conf.xml
...
Step 4: Configure PAM
No longer necessary. As of 9.04 all options already included.
Step 5: Test!
Log out and back in. You should now have an encrypted home:
$ df -h
...
/dev/mapper/_dev_mapper_vg_storage-lv_home
20G 296M 20G 2% /home
Congratulation, you now have an encrypted swap, tmp and home partition!
A final advice: Take regular backups.
Useful links:
- "dm-crypt: a device-mapper crypto target": http://www.saout.de/misc/dm-crypt/
- "dm-crypt HOWTO for Debian unstable and testing": http://www.saout.de/tikiwiki/tiki-index.php?page=HOWTO
23 Apr 2009
Sharing Internet connection over bluetooth in Ubuntu
Me and my girlfriend are staying in a hotel here in Sha Tin, Hong Kong. Since the hotel only allow one computer per room connected to the Internet at the time - I found out it would be a nice time to look into Internet connection sharing over bluetooth. There are some documentation on how to set up PAN in Linux, so the prosess should be pretty straightforward. One posting I found mention some software called "Blueman". Turns out Blueman can do all the work for me with the click of a button.
It's even in Launchpad, so I can install it using apt. I start the applet, go into "Local Services", enable NAP, and.. it just works! This is getting too easy!
It's even in Launchpad, so I can install it using apt. I start the applet, go into "Local Services", enable NAP, and.. it just works! This is getting too easy!
Mass EXIF date and time manipulation
I'm out traveling and I forgot to change the timezone on my camera again. So the EXIF time stored in the pictures are all wrong. My first though was to write another Perl script to fix this (se earlier post). But I found out that the program jhead can do all sort of magic EXIF manipulation. To mass change EXIF dates, just do a:
$ jhead -ta+7:00 *.JPG
Modified: IMG_1708.JPG
Modified: IMG_1709.JPG
Modified: IMG_1710.JPG
...
This add seven hours to the EXIF stored time. Nice and easy.
$ jhead -ta+7:00 *.JPG
Modified: IMG_1708.JPG
Modified: IMG_1709.JPG
Modified: IMG_1710.JPG
...
This add seven hours to the EXIF stored time. Nice and easy.
8 Apr 2009
Memory usage by user
A short little script I stumbled across when cleaning my $HOME. I do not think I wrote it myself - at least I can't recall that I did. Quite handy and it's small and compact using the commands ps, awk, sort and head:
ps aux --no-headers | awk '
{
name[$1] += $1;
pros[$1] += $4;
mem[$1] += $5
}
END {
for (var in name) {
print mem[var]" "var" "pros[var]
}
}' | sort -nr | head
The result is a top ten list of the users that consume the most memory:
741012 root 9.3
238152 bjorn 3.8
119380 thomasez 1.2
105332 krav 1.9
100804 lars 0.6
95916 ingvar 1.6
89720 kjetilho 1.5
78044 jo 1
74232 espen 0.8
73460 michael 0.4
There I am - at number five...
ps aux --no-headers | awk '
{
name[$1] += $1;
pros[$1] += $4;
mem[$1] += $5
}
END {
for (var in name) {
print mem[var]" "var" "pros[var]
}
}' | sort -nr | head
The result is a top ten list of the users that consume the most memory:
741012 root 9.3
238152 bjorn 3.8
119380 thomasez 1.2
105332 krav 1.9
100804 lars 0.6
95916 ingvar 1.6
89720 kjetilho 1.5
78044 jo 1
74232 espen 0.8
73460 michael 0.4
There I am - at number five...
7 Apr 2009
First RFC 40 years old
The first request for comments (RFC 1) was published 40 years ago today (7. April 2009). RFCs are standard documents published by the Internet Engineering Task Force (IETF). Today over 5000 RFCs have been published by IETF. Stephen Crocker, the author of RFC1, recollect some thoughts of the early days:
http://www.nytimes.com/2009/04/07/opinion/07crocker.html
http://www.nytimes.com/2009/04/07/opinion/07crocker.html
1 Feb 2009
Secure password management using CPM
There are numerous articles on the importance of creating strong secure passwords that are hard to guess and break. However, the harder the password, the harder it is to memorize. Another problem arises when we have several different passwords, usually one for each device or service. How can we store and manage the increasing number of passwords? Console Password Management (CPM), created by Harry Brueckner, does a great job for exactly that.
I worked as a system administrator for a medium sized Norwegian company. Our department was administering a large number of network devices and Unix/Linux servers. The company had two international offices each with different network security zones. This complex network topology combined with a severe strict password policy, made it impossible to memorize all different passwords.
We solved this by equipping each administrator with their own Palm with an approved secure password application. These Palms had to be manually fed, which meant in practice that they never were in sync. The authoritative password "database" was a green folder with sheets upon sheets of paper combined with post-it notes scribbled all over. In other words, it was a mess. The only up-turn was that this folder was stored in a huge fire-proof safe.
We decided to clean this up. First, we wanted an online central password database, stored as secure as possible, and running on Linux. I found dozens upon dozens of password applications. However, most of these could be placed in one of two categories (and in some cases both):
Fortnunately, there was one application that caught my eye. It did not fit any of these conditions above.
Console Password Management
CPM is one of those rare applications that have done many things right when it comes to secure passwords storage. At startup it checks
Installation
Installing CPM from source can be a little hassle unless you are familiar with compiling your own software. On Debian, you can just add CPM's apt source and install it using Debian's own package manager. You'll find instructions on CPM's homepage. Unfortunately, I did not find updated packages for Fedora/Red Hat Enterprise. I know that the developer is busy updating CPM and that a static binary is high on his priority list. A static binary would ease the installation tremendously.
Note that CPM is installed SUID root (mode 4755), meaning that CPM will be executed with root privileges regardless whether root executes the application or the user. This is necessary to enable memory locking and protection from strace/ptrace attacks. The root privilege is dropped right after memory locking.
GnuPG
Before we start using CPM, we need to have an asymmetric keypair generated by GnuPG. GnuPG is a free implementation of the commercial PGP and is included in most Linux distributions. Since CPM relies so heavily on GPG, it is imperative that you and your co-users have a grip on GnuPG. If you plan to have more than one user accessing the same CPM database, you need to create a GnuPG "web-of-trust", which basically is signing each others keys. If you are the only users of CPM, this is not necessarily.
If you don't already have a GnuPG keypair, you can create one:
$ gpg --gen-key
You'll be asked some questions, where you safely can choose the default options. Be sure to type in your name and email address when asked so. Choose a really good passphrase! This will be the only password you'll have to remember. But do remember it! If you forget this, there is no way to recover the password database.
You can now list your newly created key:
$ gpg --list-keys
Good! Lets get started using CPM.
Configuration and usage
First, we need to configure CPM. Copy /etc/cpm/cpmrc to ~/.cpmrc
$ cp /etc/cpm/cpmrc ~/.cpmrc
Open this file with the editor of your choice. In this file, you need to set the "EncryptionKey" variable. Its value would be the GnuPG email-address you typed in when you generated the GnuPG keys. So for me, that would be:
EncryptionKey "lars.strand@linpro.no"
Save and exit. Start CPM with a security test:
$ cpm --security
You should now get an output like the one in the image above. It looks like we're secure enough. The first time we start CPM, we get an error telling us that it can't find any database. That's ok, since we haven't created one yet. There is no host added, so you'll be greeted with an empty CPM as shown in the image below.
You populate the database by pressing Ctrl-A. Enter the hostname, and press enter. Selecting the host and pressing enter, enables you to add one or more services for this host. Each service can have one or more username/password pairs linked to it. Every host, service or username/password can have a comment associated with it. See the image below.
Install the password checker cracklib, and CPM also warns you if you enter a weak password. See figure:
Every entry has a timestamp indicating when it was updated and by which GnuPG key. This way, we can see which user has updated this particular entry.
Finally, save by pressing Ctrl-W. If this is the first time you run CPM, we'll be prompted for our GnuPG password. Otherwise we're asked for the password at startup - else CPM is not able to read our database. Quit by pressing ESC. The database is now saved in ~/.cpmdb in our home directory:
$ file ~/.cpmdb
/home/lars/.cpmdb: PGP armored data message
This file is just an encrypted and compressed XML-file. We can easily decrypt the content by issuing the command:
$ gpg --decrypt ~/.cpmdb | gzip -cd > cpm-decrypted.xml
$ file cpm-decrypted.xml
cpm-decrypted.xml: XML document text
CPM also provides command line search. Here I search for every entry containing "trinity:
$ cpm valhall
enter your passphrase (try #1)
Lars Strand
login root@valhall secretpassword3
1 match found.
This is quite useful when I'm in a hurry.
More than one user
If you plan to use CPM with several users, be sure that everyone has grip on GnuPG and how to proper handle their keys. You also want to store the database somewhere else. Your home directory is not a good place! Create a directory /var/lib/cpm/ and call the database cpmdb. Create a group called "cpm" and populate it with users of CPM. Then make sure the directory is (only) readable by that group. If CPM is running on a high trusted host, you've come a long way to see the security officer in your company smile.
You need to consult the GnuPG documentation on how to sign each others GnuPG keys to create a "web-of-trust".
If there is more than one user accessing CPM at the same time. Only the first user has read-write access. All other users will have read-only.
Conclusion
CPM does one thing, and it does it really well. It stores passwords securely. If you and your co-workers know how to handle GnuPG, it is way better than most other solutions out there.
This article originally appeared in Linux+DVD magazine in the January 2009 issue.
I worked as a system administrator for a medium sized Norwegian company. Our department was administering a large number of network devices and Unix/Linux servers. The company had two international offices each with different network security zones. This complex network topology combined with a severe strict password policy, made it impossible to memorize all different passwords.
We solved this by equipping each administrator with their own Palm with an approved secure password application. These Palms had to be manually fed, which meant in practice that they never were in sync. The authoritative password "database" was a green folder with sheets upon sheets of paper combined with post-it notes scribbled all over. In other words, it was a mess. The only up-turn was that this folder was stored in a huge fire-proof safe.
We decided to clean this up. First, we wanted an online central password database, stored as secure as possible, and running on Linux. I found dozens upon dozens of password applications. However, most of these could be placed in one of two categories (and in some cases both):
- The application is designed for one user. Many of these applications are pretty usable, some even with a nice graphical user interface. A familiar example; both Firefox and Thunderbird allow you to save username and passwords. When enabling the Master password, you should, these passwords are encrypted on disk. However, these passwords are only available to the user of the application. The desktop managers GNOME and KDE both have the ability to save passwords securely.
- The application is fundamentally flawed. For example, the application allows core dumps or being swapped to disk. One password application I found even stored the passwords in clear(!) text in a SQL database. Really dumb.
Fortnunately, there was one application that caught my eye. It did not fit any of these conditions above.
Console Password Management
CPM is one of those rare applications that have done many things right when it comes to secure passwords storage. At startup it checks
- whether core dumps are disabled,
- whether memory is locked from paging,
- whether the application is protected from ptrace spying,
- whether the application has environment checks enabled, and
- whether it's running without root privileges.
Installation
Installing CPM from source can be a little hassle unless you are familiar with compiling your own software. On Debian, you can just add CPM's apt source and install it using Debian's own package manager. You'll find instructions on CPM's homepage. Unfortunately, I did not find updated packages for Fedora/Red Hat Enterprise. I know that the developer is busy updating CPM and that a static binary is high on his priority list. A static binary would ease the installation tremendously.
Note that CPM is installed SUID root (mode 4755), meaning that CPM will be executed with root privileges regardless whether root executes the application or the user. This is necessary to enable memory locking and protection from strace/ptrace attacks. The root privilege is dropped right after memory locking.
GnuPG
Before we start using CPM, we need to have an asymmetric keypair generated by GnuPG. GnuPG is a free implementation of the commercial PGP and is included in most Linux distributions. Since CPM relies so heavily on GPG, it is imperative that you and your co-users have a grip on GnuPG. If you plan to have more than one user accessing the same CPM database, you need to create a GnuPG "web-of-trust", which basically is signing each others keys. If you are the only users of CPM, this is not necessarily.
If you don't already have a GnuPG keypair, you can create one:
$ gpg --gen-key
You'll be asked some questions, where you safely can choose the default options. Be sure to type in your name and email address when asked so. Choose a really good passphrase! This will be the only password you'll have to remember. But do remember it! If you forget this, there is no way to recover the password database.
You can now list your newly created key:
$ gpg --list-keys
Good! Lets get started using CPM.
Configuration and usage
First, we need to configure CPM. Copy /etc/cpm/cpmrc to ~/.cpmrc
$ cp /etc/cpm/cpmrc ~/.cpmrc
Open this file with the editor of your choice. In this file, you need to set the "EncryptionKey" variable. Its value would be the GnuPG email-address you typed in when you generated the GnuPG keys. So for me, that would be:
EncryptionKey "lars.strand@linpro.no"
Save and exit. Start CPM with a security test:
$ cpm --security
You should now get an output like the one in the image above. It looks like we're secure enough. The first time we start CPM, we get an error telling us that it can't find any database. That's ok, since we haven't created one yet. There is no host added, so you'll be greeted with an empty CPM as shown in the image below.
You populate the database by pressing Ctrl-A. Enter the hostname, and press enter. Selecting the host and pressing enter, enables you to add one or more services for this host. Each service can have one or more username/password pairs linked to it. Every host, service or username/password can have a comment associated with it. See the image below.
Install the password checker cracklib, and CPM also warns you if you enter a weak password. See figure:
Every entry has a timestamp indicating when it was updated and by which GnuPG key. This way, we can see which user has updated this particular entry.
Finally, save by pressing Ctrl-W. If this is the first time you run CPM, we'll be prompted for our GnuPG password. Otherwise we're asked for the password at startup - else CPM is not able to read our database. Quit by pressing ESC. The database is now saved in ~/.cpmdb in our home directory:
$ file ~/.cpmdb
/home/lars/.cpmdb: PGP armored data message
This file is just an encrypted and compressed XML-file. We can easily decrypt the content by issuing the command:
$ gpg --decrypt ~/.cpmdb | gzip -cd > cpm-decrypted.xml
$ file cpm-decrypted.xml
cpm-decrypted.xml: XML document text
CPM also provides command line search. Here I search for every entry containing "trinity:
$ cpm valhall
enter your passphrase (try #1)
Lars Strand
login root@valhall secretpassword3
1 match found.
This is quite useful when I'm in a hurry.
More than one user
If you plan to use CPM with several users, be sure that everyone has grip on GnuPG and how to proper handle their keys. You also want to store the database somewhere else. Your home directory is not a good place! Create a directory /var/lib/cpm/ and call the database cpmdb. Create a group called "cpm" and populate it with users of CPM. Then make sure the directory is (only) readable by that group. If CPM is running on a high trusted host, you've come a long way to see the security officer in your company smile.
You need to consult the GnuPG documentation on how to sign each others GnuPG keys to create a "web-of-trust".
If there is more than one user accessing CPM at the same time. Only the first user has read-write access. All other users will have read-only.
Conclusion
CPM does one thing, and it does it really well. It stores passwords securely. If you and your co-workers know how to handle GnuPG, it is way better than most other solutions out there.
This article originally appeared in Linux+DVD magazine in the January 2009 issue.
Subscribe to:
Posts (Atom)