Last weekend I had the pleasure to equip my brother’s computer with a new 4GB RAM module. Just out of curiosity I thought I would use this opportunity to test the rarely-used PXE-boot installation, which already served memtest86+ v4.20.

As you might have guessed, I probably would not be writing this blog post if it would have went through flawlessly In other words the test failed and a journey of debugging several (unrelated) problems began.

The first thing I wanted to see is whether memtest86+ in general works. Hence, I immediately rebooted my Lenovo T440s in order to see that PXE-boot would not work at all. Fiddling around with the dnsmasq configuration I tried to make PXE aware of UEFI systems by adding the following

pxe-service=x86-64_EFI,EFI,efi/syslinux.efi,1.1.1.1
pxe-service=x86PC,Standard,pxelinux,1.1.1.1

where 1.1.1.1 of course stands for your tftp-server’s IP. Unfortunately this did not bring the success. It shall be noted that the tftp-server has to serve two files, once pxelinux.0 for the classical BIOS boot process and once syslinux.efi.0 (the 0 is automatically appended by dnsmasq). According to the syslinux documentation it is advisable to create two separate directories for the binaries as they both come with their own set of *.c32 files. As all this did not bring me closer to a working UEFI-PXE-boot setup I dismissed this plan and forced my notebook to boot in BIOS-mode.

Falling back to the BIOS-boot PXE worked as expected (Thinkpad bug?), but memtest86+ only showed a blue screen with a few pieces of information. Given the age of the initial PXE-configuration I thought that updating memtest86+ would be a good idea and quickly fetched the latest sources of version 5.01. Building was not a problem in a standard linux environment, although forerunners of immature code were already visible when make tried to install memtest86+ via scp to a hard-coded IP when executed with the target “all”. After removing the .bin prefix from the memtest executable it almost worked, but crashed immediately after starting testing. Having noticed that the makefile was already in a bad shape I should have come to this conclusion earlier, but after some time I started searching the databases of linux distributions which quite often ship patches for (almost) unmaintained software. And indeed, e.g., Fedora offers a set of patches that fix these problems. Applying the patches and deploying the new memtest then finally gave the first positive result of that day: a working memtest86+ 5.01 on my T440s

Back to the original problem, the said 4GB module, which was suspected to be faulty. I was immanently disillusioned that the failure was not due to memtest86+. In hindsight, I have to agree that this was a bit optimistic. Therefore, I bisected the problem and noticed that it was not even specific to that particular module. Realizing that the said mainboard (Asus M4A89GTD PRO) was a piece of hardware with advertised overclocking capabilities, the next step was to look for a smoking gun in that direction. And indeed, I got suspicious about the DDR3-RAM operating at 640 MHz instead of supported 666 MHz and a voltage slightly above 1.5V. A BIOS update then finally turned things to the good (maybe it even just resetted to the default values) and memtest86+ passed. The frequency is still reported to be around 640 MHz, but now it is at least working.

Inspired by the recent “E-Mail made in Germany”-initiative I had a look into how server to server encryption looks like in my postfix configuration. The latter is usually implemented using TLS and has been supported by postfix since version 2.2. Now, this was not the first time I had looked into the TLS configuration of postfix, since a while ago I had already managed to add my certificates to the postfix configuration

smtpd_tls_cert_file = /path/to/cert.pem
smtpd_tls_key_file = $smtpd_tls_cert_file
smtpd_tls_security_level = may

The main rationale behind this was back-then to allow mail clients like e.g. Thunderbird to use TLS/SSL in order to safely connect to the Mail Transfer Agent (MTA) — in our case postfix — such that internal mail would be at least transferred securely. Now, to my surprise I found out that this is already sufficient for other MTAs to send emails to my postfix instance securely, because they are also using the same protocol (SMTP) for the inter-MTA communication as the Thunderbird client does. The only difference is that Thunderbird does another authentication step, which then allows the user to take advantage of the relaying facilities of postfix.

So receiving emails via TLS was already working like a charm and also the corresponding configuration for allowing encrypted send was already present in my configuration

smtp_tls_security_level = may

Now you may ask: How does one notice that it is working? When receiving mails that were transferred over an TLS-encrypted channel one usually sees in the message source a remark like the following one:

Received: from mail.example.com (mail.example.com [1.1.1.1])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by example2.com (Postfix) with ESMTPS id XXXXXXXXXXX
	for <blubb@example2.com>; Tue, 29 Apr 2014 19:42:40 +0200 (CEST)

Update: As has been pointed out in the comments, one needs to have set smtpd_tls_received_header = yes for this to work.

Unfortunately the mail stored in the “Sent” directory of your mail client does not contain any information on that regard and one has to consult the maillog to see that sending via TLS has happened.

In principle this is already enough to obtain server to server encryption, but it may be not really satisfactory, since it does not really prevent man-in-the-middle attacks. Therefore, I started playing around a bit with the smtp_tls_policy_maps option

smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
smtp_tls_CApath = /path/to/certs/

where the tls_policy file contains for example

t-online.de    secure ciphers=high
gmx.net        secure ciphers=high
freenet.de     secure ciphers=high
web.de         secure ciphers=high

This basically ensures that every mail to the listed domains is only sent encrypted with a high-quality cipher. The four given domain certificates are all (indirectly) signed by the Telekom Root Certificate, which one can e.g. download here and then place in the certs path. It should also be mentioned that after every change to the tls_policy file one should execute

postmap hash:/etc/postfix/tls_policy

and for every change on the certificates

c_rehash /path/to/certs

A more intricate issue I haven’t had the time to look at yet is how to ensure that postfix only receives mail securely from the listed servers. This way one might already come pretty close to what the partners in the “E-Mail made in Germany”-initiative do. In this context I have also been asking myself whether there is a list of participating servers in this program that are using a certificate derived from the Telekom Root CA? Using this list as the tls_policy file one would at least in one direction become a defacto member of the alliance. Sadly, the website of the initiative does not seem to contain any valuable information on that regard.

For everybody else who is planning to fiddle around with the postfix TLS details I can highly recommend the documentation on the postfix webpage.

After playing around with server to server encryption I have to conclude that it is probably a nice feature, but there are still things missing:

• Is there a way to ensure that outgoing mail is encrypted? I think I read somewhere that Lavabit had such a feature.
• It is not necessarily user-friendly if you have to dig in the logs/message-source to find out whether the mail was transferred securely.

At last it is left to say that this is and will never be a substitution for end-to-end encryption but it may at least help a bit e.g. when the web traffic between two servers is routed over a foreign country with extended wire-taping capabilities.

Many people who need a duplex ADF scanner come across the Fujitsu ScanSnap S1500 and so did I. After giving it some thought it ended up being my preferable choice, altough the successor ScanSnap iX500 was already available. This decision was mostly due to the fact that there were reports that indicated SANE-support for S1500, which was unclear for the iX500.

My demands on an ADF scanner setup basically were:

• It should work together with CentOS 6.
• There should be a one-button setup that saves the scanned A4 pages to a predefined Samba share.
• Optimally it should autodetect whether it needs to be run in duplex mode.
• Automatic OCR embedded in the pdf as an optional nice feature.

Regarding the CentOS 6 setup one can say, that the scanner works out of the box. The only minus point is that, as has been indicated here, one has to pass the “-B” option to scanimage in order to fix some I/O errors in case of colored duplex mode.

For the one-button setup I used scanbuttond. There seems to be a “successor” scanbd, but I didn’t get it working. As scanbuttond is not provided in any CentOS repository you have to compile it on your own: I downloaded the latest 0.2.3 version, which apparently does not have support for the ScanSnap S1500 since the project is orphaned. Fortunately the Debian project provides a set of patches, where one of them adds support for the scanner.

So in principle one now could write a working one-button-to-pdf script. The missing part with automatically deciding on whether to scan in duplex mode is more tricky and it ended up with a small script I found here, which does some sort of auto white page removal. At the moment it is a viable solution, though not a very fast one.

The last point with the automatic OCR is still missing since CentOS does not come with any decent OCR in the repositories. In one way or another it will probably be some combination of tesseract / Ocropus / cuneiform with hocr2pdf, but this is still under investigation.

In the end the script that gets called within buttonpressed.sh is the following:

#!/bin/bash
 
CURDIR=`pwd`
TMPDIR=`mktemp -d`
OUT_DIR=/sambashares/
 
cd $TMPDIR
 
echo "Starting Scan:"
echo "=============="
echo ""
 
scanimage -b -B --resolution 150 --batch=scan_%03d.tiff --format=tiff \
	--mode Color --device-name "fujitsu:ScanSnap S1500:111111" \
	-x 210 -y 297 --brightness +10 \
	--page-width 210 --page-height 297 \
	--sleeptimer 1 --source "ADF Duplex"
 
echo ""
echo "Checking for blank pages:"
echo "========================="
echo ""
 
if [ -f "scan_001.tiff" ]; then
 
for i in scan_*.tiff; do
  histogram=`convert "${i}" -threshold 50% -format %c histogram:info:-`
  white=`echo "${histogram}" | grep "white" | sed -n 's/^ *\(.*\):.*$/\1/p'`
  black=`echo "${histogram}" | grep "black" | sed -n 's/^ *\(.*\):.*$/\1/p'`
  blank=`echo "scale=4; ${black}/${white} < 0.005" | bc`
  echo `ls -lisah $i`
  if [ ${blank} -eq "1" ]; then
    echo "${i} seems to be blank - removing it..."
    rm "${i}"
  fi
done
 
OUTPUTNAME=scan_`date +%Y%m%d-%H%M%S`.pdf
 
tiffcp -c lzw scan_*.tiff allscans.tiff
tiff2pdf -z -p A4 allscans.tiff > out.pdf
gs      -q -dNOPAUSE -dBATCH -dSAFER \
        -sDEVICE=pdfwrite \
        -dCompatibilityLevel=1.3 \
        -dPDFSETTINGS=/screen \
        -dEmbedAllFonts=true \
        -dSubsetFonts=true \
        -dColorImageDownsampleType=/Bicubic \
        -dColorImageResolution=300 \
        -dGrayImageDownsampleType=/Bicubic \
        -dGrayImageResolution=300 \
        -dMonoImageDownsampleType=/Bicubic \
        -dMonoImageResolution=300 \
        -sOutputFile=$OUTPUTNAME \
        out.pdf
 
cp $OUTPUTNAME $OUT_DIR/$OUTPUTNAME
 
chown smbuser:smbuser $OUT_DIR/$OUTPUTNAME
 
fi
 
cd $CURDIR
 
rm -rf ${TMPDIR}

Just a few last remarks on the script:

• You have to get the scaner ID from “scanimage -L” and replace it accordingly in the scanimage call.
• Using the jpeg compression feature of tiff2pdf gives the picture a red color cast, which I cannot explain so far.
• In order to achieve a better compression ratio I also added the ghostscript call.

Due to my current occupation, which involves numerical computations, I have to deal with Fortran in its different flavors. Since in the past I have almost exclusively programmed C/C++ and never had used Fortan I ran into some nasty bugs, which I want to share, guessing that there are probably more people in the same situation. Most of these bugs are simply because of the fact, that one projects the known C-semantics onto Fortran. Or saying it differently: the bug sits between the keyboard and the chair

In this first post I want to start with the following example

subroutine bar()
 
implicit none
 
logical :: foo = .false.
! do other stuff
end subroutine

which is compared to:

subroutine bar()
 
implicit none
 
logical :: foo
foo = .false.
! do other stuff
end subroutine

Looks basically the same. Apparently it is NOT. The problem is that for Fortran every variable which is initialized at declaration is automatically marked saved, which, just to make it clear, corresponds to the static keyword in the C world. To make it even more precise the first example is the same as:

subroutine bar()
 
implicit none
 
logical, save :: foo = .false. ! foo's value is persistent across subroutine calls
! do other stuff
end subroutine

Or the same function in C:

void bar()
{
    static bool foo = false;
    // do other stuff
}

This is just a habit thing, since in C and C++ there is not a problem with initialization at declaration. When I experienced the bug above I luckily had a simple function and a unit test which helped to reveal the bug quite fast. Otherwise one probably could keep staring at code for some time, falsely assuming this part of the code being too simple to fail.

One of the things I wanted to have done for quite some time now was building a NAS from the ground up. Several weeks ago the two year old Buffalo Pro Duo capitulated such that I finally got my chance Over the time there have been some things I wanted to try, but which the Buffalo NAS due to several reasons wasn’t able to deliver. So there were certain requirements the new NAS would have to meet:

• Due to a misconception the Buffalo NAS was accessing the hard disks approximately every 20 seconds, which in the end probably led to the harddisk failure. Hence the new setup should use a SSD for the operating system partition in order to minimize the exposure of the mechanical parts.
• Although the initial setup will only use two harddisks, I want to have the possibility to expand the RAID5 array in the future.
• The processor should be powerful enough to handle a software RAID.

1

md5sum /dev/urandom

1

temp1_max = 70000, temp1_crit = 100000, temp1_crit_hyst = 97000

As the blog name suggests, this blog is about some random thoughts of mine. Given the fact that the entropy of these thoughts wouldn’t justify /dev/random, I found it appropriate to call it “/dev/urandom thoughts”.

Those hoping for random number, encryption or information theoretical related blog posts will probably be disappointed because I’m so far not planing any posts about these topics. The main topics I had in mind while setting up this blog are:

• KDE, especially kwin, related thoughts
• maybe some physics
• All the rest I haven’t thought about yet.

I hope you enjoy reading

Regards,

Philipp