However, the encryption of the pen-drives themselves has been a problem ever since we started to follow this policy. Devices like Kingston DataTraveler Vault are Windows only and alternative solutions are rare.

Fortunately I recently discovered the Corsair Padlock devices which might be a solution for people who need platform independent encrypted USB storage.

When testing one of those devices I thought about securing my laptop kernels with such a thing, because this would remove or at least reduce the attack option (unencrypted kernel and initrd) left in my encrypted laptop drive setup.

Well this is where the problem started and where one oft the best software support in the world (this of the linux kernel) was again
able to solve it by just sending a few mails around the globe.

So here comes the whole story:

Quite a lot of BIOS are unable to boot from a so called Superfloppy device (no partition at all). For this reason I just added one to my Padlock2 device. Unfortunately this device could not be detected by Linux but worked fine in M$-Windows.

Sending an error report and some debug output to the usb-storage mailing-list revealed some strange bug (or just a tricky windows only workaround to enable hardware encryption?) in the Padlock device not showing the correct partition Information on the first read by the OS. Windows reads a bunch of stuff before looking at the
partition data so the problem does not arise there.

And here comes the real beauty of FOOS. I got a patch which worked around the problem just a couple of hours later from somebody a thousand kilometeres away (credits go to Alan Stern) and fortunately this patch will go into Linux 3.0.1.

Problem solved

This is not the first time something like this happened. I’m a 100% certain that something like this would never be possible in a closed source world which is all about workarounds in application Software because it is just impossible to send an email to the maintainer of a particular piece of OS code.

A few weeks ago a few austrian mappers contacted me because we are now allowed to us the WMS server at http://geoimage.at/ for mapping.

Unfortunately the data is currently only available in an austrian koordinate system (EPSG:31287). With EPSG:4326 beeing unavailable this is in fact a violation of the WMS spec

This could however be easily fixed using UMN-Mapserver as WMS-proxy, but unfortunately we are not allowed to do this at wms.openstreetmap.debecause we are not permitted to set up a cascading WMS based on their rules.

Anyway, with my wms.openstreetmap.de setup already using the python wsgi-interface (apache mod_wsgi) I thought that a standalone UMN-Mapserver based WMS-server should be very easy to hack, given the fact, that all the difficult stuff is already available in python and mapscript. Well, my presumption proved to be true

So here is my standalone WMS-server written in roughly 100 lines of python code.

As far as geoimage.at is concerned, there are already other solutions at the OSM-Wiki page, but this was fun to hack and might be useful for other purposes as well. An advantage of my solution is that it is possible to use the Austrian GIS-grid file for reprojection to achieve the highest possible accuracy. For this purpose the proj4-definition for EPSG:31287 (defined in /usr/share/proj/epsg on Linux) must look like this:

<31287> +proj=lcc +lat_1=49 +lat_2=46 +lat_0=47.5 +lon_0=13.33333333333333 +x_0=400000 +y_0=400000 +ellps=bessel +units=m +nadgrids=/path/to/GIS_GRID_austria.gsb +no_defs

I would be interested in feedback on how to get this to work on Windows as well. Talking about Linux this has only been a matter of typing apt-get install python-mapscript and adjusting the proj4 definition file to use the GIS-grid.

As usual in recent years the kernel.org people just fixed it silently without mentioning in the commit log that this is a mayor security fix.

People like me which are still running kernel.org kernels and which are actually the people reporting bugs in recent kernels are actually drawing the shortest straw here now

IMO it is a shame that there is still no 2.6.35.5 Kernel available which fixes this flaw.

So what I will need to do now is trying to repair this by merging the fix from git.kernel.org to 2.6.35.4…

While socketcan itself has been in mainline for quite a while, there where no drivers for actual real-world hardware. This has now changed and I will therefore be able to run a Kernel which is one step closer to mainline.

Unfortunately however some kind of unioning filesystem is still missing.

Anyway, back to Controller–area network!

Since I wrote my own CAN device driver as a character device a couple of years ago I started thinking about a CAN-bus driver beeing implemented as a Network device. I wrote my own driver in the first place, because I needed concurrent access which is (needless to say) also possible with socketcan.

Fortunately two guys at Volkswagen Research finally started doing exactly this. Thank you to the socketcan people for providing such a nice piece of software!

So here is a mini HOWTO for getting it up and running.

What you need:

• A GNU/Linux machine
• A decent Kernel (2.6.31-rc1 or higher)
• git and subversion
• A supported CAN-bus card. I’m using one sold by EMS Wünsche, but a lot of other SJA1000 based cards may also work.
• The simple userland utilities from svn://svn.berlios.de/socketcan/trunk/can-utils
• A decent Version of iproute2 (not yet available in current GNU/Linux distributions at the time of writing)

How to get it up and running:

First of all compile and boot a Kernel where all CAN-related support is enabled either as a module or build into the Kernel.
Afterwords check out the userland utilities from subversion (svn checkout svn://svn.berlios.de/socketcan/trunk/can-utils) and compile them by just typing make.
Same goes for iproute2 (git clone git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git); just type make as well. Copy all the resulting binaries to an appropriate place (e.g. /usr/local/bin). Do not use make install at least in iproute2 sourcetree, because this will replace your systems ip command.

Now all you need to do ist to enable you can0 interface by means of the following command:

ip link set can0 up txqueuelen 1000 type can bitrate 1000000

Use another value than 1000000 for different bitrates.

The txqueuelen might not be needed in your case if you don’t have peak traffic like I do.

OK, that`s it! You can now connect your bus to some device and use candump for watching your raw CAN pakets on the bus.

For integration into Debian GNU/Linux you may use something like the following in /etc/network/interfaces for automatically starting up your can0 device on system boot:


--cut--
auto can0
iface can0 inet manual
# bitrate 1MBps
# increase TX queue length because of the pulsed nature of
# the traffic we generate
up /usr/local/bin/ip link set can0 up txqueuelen 1000 type can bitrate 1000000
down /sbin/ifconfig $IFACE down
--cut--


See Documentation/networking/can.txt inside your Kernel tree for further documentation.

Langer Rede kurzer Sinn, die aktuelle Version 4.0.x der Linux Standardshell hat nun zwei nette neue features, die ich natürlich gleich in meine .bashrc eingebaut habe.

Unterm Strich erspart man sich das häufige tippen der Kommandos cd und ssh.

Findet der Rechner einen unbekannten Befehl wird geschaut ob es ein Verzeichnis mit passendem Namen gibt, wenn ja wird in dieses Verzeichnis gewechselt. Wenn Nein wird nachgeschaut ob es einen passenden Rechnernamen gibt und wenn das der Fall ist erfolgt ein Remote Login über ssh auf diesem Rechner.

Das ganze sieht so aus:

# Auto-cd feature
shopt -s autocd

function command_not_found_handle() {
    host=$(echo $1 |sed -e 's/^.*@//g')
    # wenn hostname in .ssh/config, dann ssh dorthin
    if grep -q "Host $host" $HOME/.ssh/config; then
      ssh $*
    else
      if ! getent hosts $host >/dev/null; then
        echo "bash: $*: Kommando nicht gefunden."
      else
        ssh $*
      fi
    fi
}