Posted on

IPv6

After playing around with IPv6 just for fun, I think it is time to really reconfigure the whole network now.

1) As I don’t have native IPv6 access yet, I need a tunnel broker to connect my hosts to the IPv6 network.
According to Wikipedia there are only two of them who have PoPs in Europe:

  • SixXS
  • Hurricane Electric

In order to make things a bit more complicated, I want to connect two sites together with some external servers.
Further all IPv4 stuff needs to work as well, so I need a dual stack solution.

The following is a list of problems that I am trying to solve step by step.

1.1) tunnel one from SixXS
1.2) local tunnel endpoint one
1.3) routable subnet one from SixXS
1.4) tunnel two from SixXS
1.5) local tunnel endpoint two
1.6) routable subnet two from SixXS

1.11) tunnel one from Huricane Electric
1.12) local tunnel endpoint one
1.13) routable subnet one from Hurricane Electric
1.14) tunnel two from Huricane Electric
1.15) local tunnel endpoint two
1.16) routable subnet two from Hurricane Electric

1.20) check IPv6 availability for external server at Hetzner
1.21) check IPv6 availability for external server at Strato
1.22) check IPv6 availability for external server at Server4You

2) configure external server
2.1) configure connectivity for external server at Hetzner
2.2) configure connectivity for external server at Strato
2.3) configure connectivity for external server at Server4You

3) configure services
3.1) bind
3.2) DNS resolving
3.3) apache
3.4) exim4
3.3) inn2
3.6) ssh
3.7) nagios
3.8) nfs
3.9) openafs
3.10) xen
3.11) ftp
3.11) openvpn

4) configure home network
4.1) automatic configuration for all hosts
4.2) dynamic default route
4.3) manually routing of special networks
4.4) configure services from list in 3)

Let’s start the journey …

Posted on

DTPOM: lots of stuff for Debian Med

April has been the month of new packages. I had a look at the task list of Debian Med and tried to finish some (older) packages or created some new ones.

Finally the following packages made it first to “unstable” and after the release of Wheezy, they migrated to “testing” as well:
– uc-echo – error correction algorithm designed for short-reads from NGS
– python-clips – Python module to interface the CLIPS expert system shell library
– visionegg – Python library for 2D/3D visual stimulus generation
– qrisk2 – cardiovascular disease risk calculator

Further there are still some packages waiting in the NEW-queue
– treeview – Java re-implementation of Michael Eisen’s TreeView
– proalign – Probabilistic multiple alignment program

The month of May will be under the banner of bug fixing and new upstream releases. But in case any other package shall be part of Debian, just send an email to blog@alteholz.eu.

Posted on

BOM: openAFS

February and March have been the months of openAFS bug squashing. I sent in patches for #660622 and #639475, helped on an issue with building modules for amd64 kernels on an i386 architecture and opened bug #702018 in package dkms which is the reason for openafs bug #620014.

This has been great fun.

Posted on

DOPOM: scheme48 – A simple, modular, and lightweight Scheme implementation

Some years ago I heard about Scheme and was fascinated by the (at that time at least for me) strange syntax. As this was not yet the time of WWW, I even bought a book to learn more about it.
Unfortunately priorities changed and I needed to spend my time on other things. As I now found that orphaned package I would like to give it a second try and at least keep it rolling.

Posted on

bind configuration

Today I had to do some bind9 configuration and here are the results for my future self.

Nowadays the Debian bind package is prepared to use IPv6. In case your server has no IPv6 connectivity yet, lots of errors appear in the logs. Most of them can be ignored, but at least they look ugly. So if you know that you do not need IPv6 add ‘-4’ to the OPTIONS-line in /etc/default/bind9.

If you get an error like “refused notify from non-master” and the IP of non-master is your own host, you need to accept notifies from yourself. Just add something like ‘allow-notfy { n.m.o.p; };’ to the options{}-section (n.m.o.p should be your own IP). On Debian systems this is in /etc/bind/named.conf.options.

Posted on

UUCP sys file

This is just another reminder for my future self:

Do not forget /usr/sbin/rsmtp in /etc/uucp/sys:commands line in case you activate rsmtp in exim4 config.

Posted on

HowTo build a kernel

I write this article mainly to be able to remember all steps in a few months.

– Get kernel: git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
This is the main kernel repository. Other repositories can be found at http://git.kernel.org/
For example the development of /dev/random takes place in git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random.git

– As I don’t want to manually handle entries in grub, I want to use make-kpkg to build Debian packages.

– The package needs to be built as root, ‘–rootcmd fakeroot’ does not always work. Maybe there is some time to check this issue.

– Working with original sources instead of the Debian source package results in a plus sign added to the kernel version. This is done by one of the kernel scripts (scripts/setlocalversion)
For more info see comment at end of that script. I avoid this ‘+’ by doing something like: ‘export LOCALVERSION=”-ta-1″

– As /tmp nowadays is a bit small, you need to do somehting like ‘export TEMPDIR=/home/tmp’ or whatever suits your system

– Target ‘buildpackage’ calls ‘clean’ + ‘binary’
‘binary’ -> ‘binary-indep’ + ‘binary-arch’
‘binary-indep’ -> ‘kernel_source’, ‘kernel_manual’, ‘kernel_doc’
‘binary-arch’ -> ‘kernel_headers’, ‘kernel_image’

So for a normal builds, call ‘make-kpkg –initrd binary-arch’ or at least ‘make-kpkg –initrd kernel_image’

– In case of several cores call ‘make-kpkg -j 4 –initrd binary-arch’
(the blank between ‘j’ and ‘4’ is important)
The best results will be obtained if the given number equals the number of cores

– The old Laptop needs the following times to build the package:
make-kpkg –initrd binary-arch 91 minutes
make-kpkg -j 3 –initrd binary-arch 78 minutes
make-kpkg -j 4 –initrd binary-arch 59 minutes
make-kpkg -j 4 –initrd binary-arch &> log 57 minutes

– Check version of package in automatically build debian/changelog
The debian-directory can be rebuild by ‘make-kpkg debian’

– Move kernel package to Xen VM (grub-legacy should be installed, otherwise pygrub on wheezy dom0 is not able to start domU)
– dpkg -i
– edit /boot/grub/menu.lst (again a pygrub issue with some entries)

Posted on

Random numbers from Linux kernel

The Linux kernel provides two devices that create some random data:

  • /dev/random
  • /dev/urandom

In this article I would like to sched some light on their usability.

Getting data

In a first step I totally neglect their mode of operation but just concentrate on their output. Doing something like

dd if=/dev/random of=random.1k bs=1 count=1000

for 1k, 10k and 100k with kernel 2.6.25, 2.6.32 and 3.2.0 on /dev/random and /dev/urandom should result in 18 files with data.

Unfortunately creating these files takes some time:


------------------------------------------------------------------
Kernel 2.6.25
/dev/urandom
1000+0 records in
1000+0 records out
1000 bytes (1.0 kB) copied, 0.00850279 seconds, 118 kB/s
10000+0 records in
10000+0 records out
10000 bytes (10 kB) copied, 0.0789053 seconds, 127 kB/s
100000+0 records in
100000+0 records out
100000 bytes (100 kB) copied, 0.804752 seconds, 124 kB/s

/dev/random
1000+0 records in
1000+0 records out
1000 bytes (1,0 kB) copied, 188,884 seconds, 0,0 kB/s
10000+0 records in
10000+0 records out
10000 bytes (10 kB) copied, 6109,87 seconds, 0,0 kB/s
100000+0 records in
100000+0 records out
100000 bytes (100 kB) copied, 80509,7 seconds, 0,0 kB/s

------------------------------------------------------------------
Kernel 2.6.32
/dev/urandom
1000+0 records in
1000+0 records out
1000 bytes (1.0 kB) copied, 0.0110714 s, 90.3 kB/s
10000+0 records in
10000+0 records out
10000 bytes (10 kB) copied, 0.111313 s, 89.8 kB/s
100000+0 records in
100000+0 records out
100000 bytes (100 kB) copied, 1.10515 s, 90.5 kB/s
1000000+0 records in
1000000+0 records out
1000000 bytes (1.0 MB) copied, 11.1315 s, 89.8 kB/s

/dev/random
1000+0 records in
1000+0 records out
1000 bytes (1.0 kB) copied, 62.7861 s, 0.0 kB/s
10000+0 records in
10000+0 records out
10000 bytes (10 kB) copied, 41183.7 s, 0.0 kB/s

------------------------------------------------------------------
Kernel 3.2.0
/dev/urandom
1000+0 records in
1000+0 records out
1000 bytes (1.0 kB) copied, 0.00949647 s, 105 kB/s
10000+0 records in
10000+0 records out
10000 bytes (10 kB) copied, 0.127453 s, 78.5 kB/s
100000+0 records in
100000+0 records out
100000 bytes (100 kB) copied, 0.988632 s, 101 kB/s
1000000+0 records in
1000000+0 records out
1000000 bytes (1.0 MB) copied, 10.3351 s, 96.8 kB/s

/dev/random
1000+0 records in
1000+0 records out
1000 bytes (1,0 kB) copied, 188,692 s, 0,0 kB/s
10000+0 records in
10000+0 records out
10000 bytes (10 kB) copied, 1238,26 s, 0,0 kB/s
100000+0 records in
100000+0 records out
100000 bytes (100 kB) copied, 49876,2 s, 0,0 kB/s

So as a first result, not every machine is able to create enough random numbers from /dev/random within a reasonable timeframe. /dev/urandom is able to deliver much more data.

Quality of data

In order to analyse the quality of all those data, I am using software from the Debian package ent. The output from this program is:

  • entropy (8 bits per byte is random)
  • compression rate (0% is random)
  • arithmetic mean value of data bytes (127.5 is random)
  • error of Monte Carlo value for Pi (0% is random)
  • serial correlation coefficient (0.0 is random)

I will compare the output of the device files with data extracted from a real random number generator. It is an entropy key from Simtec Electronics. This device is very well supported in Linux and has an own package in Debian.

filename bytes of random data entropy compression rate [%] mean value Pi error [%] serial correlation
kernel-2.6.25-random.1k 1000 7.805056 2 122.2400 1.82 -0.009945
kernel-2.6.25-random.10k 10000 7.982797 0 128.3138 0.19 0.019648
kernel-2.6.25-random.100k 100000 7.998234 0 127.4827 0.20 -0.003984
kernel-2.6.25-urandom.1k 1000 7.809595 2 127.0670 5.85 -0.014163
kernel-2.6.25-urandom.10k 10000 7.983436 0 126.2238 2.18 0.002686
kernel-2.6.25-urandom.100k 100000 7.998327

0 127.5812 0.42 0.000916
kernel-2.6.25-urandom.1m 1000000 7.999830 0 127.4333 0.02 -0.000883
kernel-2.6.32-random.1k 1000 7.793478 2 128.0320 2.01 -0.012834
kernel-2.6.32-random.10k 10000 7.981851 0 126.4048 0.04 -0.010927
kernel-2.6.32-urandom.1k 1000 7.816192 2 125.9590 4.31 0.018713
kernel-2.6.32-urandom.10k 10000 7.981499 0 127.1751 1.03 -0.004903
kernel-2.6.32-urandom.100k 100000 7.998210 0 127.8787 1.20 0.002980
kernel-2.6.32-urandom.1m 1000000 7.999809 0 127.4078 0.04 0.001283
kernel-3.2.0-random.1k 1000 7.821790 2 129.0400 3.36 0.039336
kernel-3.2.0-random.10k 10000 7.983251 0 127.3707 1.72 -0.008163
kernel-3.2.0-random.100k 100000 7.998081 0 127.1491 0.23 -0.005288
kernel-3.2.0-urandom.1k 1000 7.786879 2 127.8330 5.85 -0.067891
kernel-3.2.0-urandom.10k 10000 7.981188 0 127.8730 3.02 -0.006596
kernel-3.2.0-urandom.100k 100000 7.998690 0 127.6806 0.09 -0.001264
kernel-3.2.0-urandom.1m 1000000 7.999840 0 127.4574 0.17 -0.000390
ekg.1k 1000 7.829743 2 127.0100 4.89 -0.021692
ekg.10k 10000 7.982590 0 128.5926 0.96 -0.018205
ekg.100k 100000 7.998119 0 127.3629 0.52 0.000735
ekg.1m 1000000 7.999819 0 127.4686 0.22 -0.001522

So as a first conclusion, there is not much difference between /dev/urandom, /dev/random and an EKG. Up to now I would not mind to use /dev/urandom for example to generate short living session keys in an https-connection. But I am sure that there are more sophisticated tests to get the quality of randomness, so expect more to come in this blog. Of course any hints and tipps are always welcome.