Alexander Leidinger

Just another weblog


Sta­tus crypto cards HOWTO: prob­lems with the card reader (sup­port could be better)

After hours (spread over weeks) I come to the con­clu­sion that there is a lot of poten­tial to improve the doc­u­men­ta­tion of card read­ers (but I doubt the card reader ven­dors will do it) and of the pcsc doc­u­men­ta­tion. It is not easy to arrive at a point where you under­stand every­thing. The com­pat­i­bil­ity list does not help much, as the card read­ers are partly past their end of life and the mod­els which replace them are not listed. Respec­tively the one I bought does not sup­port all the fea­tures I need. I even ported the dri­ver to FreeBSD (not com­mit­ted, I wanted to test every­thing first) and a lot of stuff works, but one crit­i­cal part is that I can not store a cer­tifi­cate on the crypto card as the card reader or the dri­ver  does not sup­port extended APDUs (needed to trans­fer more than 255 bytes to the card reader).

Well, the sta­tus so far:

  • I have a HOWTO what to install to use crypto cards in FreeBSD
  • I have a HOWOT what to install / con­fig­ure in Windows
  • I have a HOWTO regard­ing cre­at­ing keys on a openpgp v2 card and how to use this key with ssh on FreeBSD (or any other unix-like OS which can run pcsc)
  • I have a card reader which does not sup­port extended APDUs
  • I want to make sure what I write in the HOW­TOs is also suit­able for the use with Win­dows / PuTTY
  • it seems Win­dows needs a cer­tifi­cate and not only a key when using the Win­dows CAPI (using the ven­dor sup­plied card reader dri­ver) in PuTTY-CSC (works at work with a USB token)
  • the pcsc pkcs11 Win­dows DLL is not suit­able yet for use on Win­dows 8 64bit
  • I con­tacted the card reader ven­dor if the card reader or the dri­ver is the prob­lem regard­ing the extended APDUs
  • I found prob­lems in gpg4win / pcsc on Win­dows 8
  • I have send some money to the devel­op­ers of gpg4win to sup­port their work (if you use gnupg on Win­dows, try to send a few units of money to them, the work stag­nated as they need to spend their time for paid work)

So either I need a new card reader, or have to wait for an update of the linux dri­ver of the ven­dor… which prob­a­bly means it may be a lot faster to buy a new card reader. When look­ing for one with at least a PIN pad, I either do not find any­thing which is listed as sup­ported by pcsc on the ven­dor pages (it is incred­i­ble how hard it is to nav­i­gate the web­sites of some com­pa­nies… a lot of buzz­words but no way to get to the real prod­ucts), or they only list updated mod­els where I do not know if they will work.

When I have some­thing which works with FreeBSD and Win­dows, I will pub­lish all the HOW­TOs here at once.

GD Star Rat­ing
GD Star Rat­ing


More dri­vers avail­able in the FreeBSD-kernel doxy­gen docs

Yes­ter­day I com­mit­ted some more con­figs to gen­er­ate doxy­gen doc­u­men­ta­tion of FreeBSD-kernel dri­vers. I mechan­i­cally gen­er­ated miss­ing con­figs for sub­di­rec­to­ries of src/sys/dev/. This means there is no depen­dency infor­ma­tion included in the con­figs, and as such you will not get links e.g. to the PCI doc­u­men­ta­tion, if a dri­ver calls func­tions in the PCI dri­ver (feel free to tell me about such depen­den­cies).

If  you want to gen­er­ate the HTML or PDF ver­sion of some sub­sys­tem, just go to src/tools/kerneldoc/subsys/ an run “make” to get a list of tar­gets to build. As an exam­ple, “make dev_sound” will gen­er­ate the HTML ver­sion for the sound sys­tem, “make pdf-dev_sound” gen­er­ates the PDF ver­sion. The sound sys­tem is prob­a­bly the most “nice” exam­ple, as it includes a page with TODO items, and has even some real API docs instead of just the call-graphs and such auto­mat­i­cally gen­er­ated information.

Some dri­vers already have (some) doxy­gen markup (I did just a quick grep for ‘/*[*!]’ to detect doxy­gen markup indi­ca­tors, no idea about the cov­er­age or qual­ity), namely:

There is more doc­u­men­ta­tion than only for those dri­vers, I just listed those as there are at least parts of doxy­gen doc­u­men­ta­tion inside.

GD Star Rat­ing
GD Star Rat­ing

Tags: , , , , , , , , ,

VDR ports docs

After a quick dis­cus­sion with nox@ I made a copy&paste of his “VDR is com­mit­ted now”-mail into the FreeBSD wiki. I also re-styled some small parts of it to fit bet­ter into the wiki. It is not per­fect, but already usable. Now inter­ested peo­ple can go and improve the docs there.

Thanks to Juer­gen for all his work in this area!

GD Star Rat­ing
GD Star Rat­ing

Tags: , , , ,

Doxy­gen stuff updated in 9-current

I com­mit­ted my patch for tools/kerneldoc/subsys. Except for not gen­er­at­ing the PDF part, this is now the same con­fig which I use to gen­er­ate the online ver­sion. While writ­ing the com­mit log I noticed that I did more changes than I thought…

So any­one who wants to gen­er­ate the Doxy­gen docs of some FreeBSD ker­nel sub­sys­tems on his own, can do it now. Adding more sub­sys­tems is easy, just make a copy of one the the exist­ing Doxyfile-* files — keep the same nam­ing scheme — and change the con­tents. Every­thing else is han­dled automatically.

I also added a link to the FreeBSD wiki. It is not at a promi­nent place (near the end of the main page), but at least some­one can find the link to the my FreeBSD-doxy­gen page there.

GD Star Rat­ing
GD Star Rat­ing

Tags: , , , , ,

HOWTO: “Blind” remote install of FreeBSD via tiny disk image

In this post I write how to install FreeBSD on a remote linux sys­tem by cre­at­ing a root image pre­pared for mir­ror­ing on a local sys­tem. There is no (free) access to the remote con­sole, only access via ssh.

Back­ground story

While I was at the uni­ver­sity, I worked remotely for an ISP (admin­is­tra­tion of sev­eral FreeBSD sys­tems). Dur­ing this time I started to use my own domain, and I was allowed to host it directly at the ISP for free. I tried to not use too much space on the hard­disk (at the end about 400 MB) and to not pro­vide some­thing which attracted too much peo­ple to keep the band­with on a sane level. After the uni­ver­sity I was still avail­able to answer ques­tions, and I was still allowed to host my web­site there for free. As the num­ber of ques­tions can be counted with IIRC one hand since then, I decided at some point (recently, to be exact — bet­ter late than never) to move my web­site to a dif­fer­ent place (I am still avail­able if they have some ques­tions — for free — but I do not expect to get much ques­tions from them).

At the same time my brother decided to move to a new server hoster, as his old one decided to increase the amount of money cus­tomers have to pay for the ser­vice. So we searched together a new ISP where he either could host his server, or get a root­server for a good price (the idea was to have my domain in a jail on a server of the com­pany of my brother, and we share the costs for it). We found Man­itu (the owner has even a blog about his busi­ness), which is even not far away from my place.

Unfor­tu­nately they do not pro­vide FreeBSD pre­in­stalled on their root­servers, but they offer a remote res­cue sys­tem (read: boot­ing a linux image… I assume via PXE or sim­i­lar) and we knew some­one who has some servers there, so I was able to get a rough idea what kind of hard­ware is used there (the hard facts like PCI IDs and such). The idea was to build a very small disk image, put it on the hard­disk over the net­work via the remote res­cue sys­tem, and then to con­fig­ure the remain­der of the harddisk(s) to use it. And here is how I did it (my brother thought “who is bet­ter suited to install a FreeBSD sys­tem remotely with­out access to the con­sole of the machine (the ISP offers to hook up a KVM switch, but only dur­ing busi­ness hours and you have to pay for it) than one of the devel­op­ers of FreeBSD…”).


In the title of this post I wrote “via a tiny disk image”. This is true for a suit­able def­i­n­i­tion of tiny.

What we have in the root­server are two 160 GB hard­disks. They shall be used in a soft­ware mir­ror (via gmir­ror). The root-FS shall have about 5 GB. This is more than needed, but as this is only 3% of one hard­disk, I pre­fer to keep it a lit­tle bit big­ger than too small after an remote update or two. The machine has 2 GB of RAM. We do not expect much ker­nel pan­ics (= crash dumps) there, so we do not really need >2 GB of swap (for­get the rule of hav­ing twice as much swap than RAM, with the cur­rent amount of RAM in a machine you are in “trou­ble” when you need even the same amount of swap than RAM). I decided to go with 1 GB of swap (mir­rored too, to pre­vent a hard­disk fail­ure to take down the machine), this is more than enough. The rest of the hard­disk will be used for jails, the distfiles/packages for/of the ports, and as WRKDIRPREFIX when build­ing ports.

Now, pushing/pulling a 160 GB image over the net­work to install a sys­tem is not really some­thing I want to do. I would pre­fer to trans­fer less than 500 MB (that is 0.3% of the entire disk) to get this job done, and this is fea­si­ble. Due to an error or two I had to trans­fer the image sev­eral times until every­thing was work­ing, so it was more in the area of maybe 2 GB (~1% of the entire disk).

First let us define some vari­ables in the shell, this way you just need to change the val­ues in one place and the rest is copy&paste:


Then change your cur­rent direc­tory to a place where you have enough space for the image. There we will cre­ate a con­tainer for the image, and make it ready for partitioning:

truncate -s ${ROOTFS_SIZE} ${FILENAME}
mdconfig -a -t vnode -f ${FILENAME}

Cre­ate the rootfs:

# create one active FreeBSD slice with $ROOTFS_SIZE GB
fdisk -e /dev/mdX
gmirror label ${ROOTFS_NAME} /dev/mdXsY
bsdlabel -w /dev/mirror/${ROOTFS_NAME}
# create an "a"-partition for everything
bsdlabel -e /dev/mirror/${ROOTFS_NAME}
newfs -U /dev/mirror/${ROOTFS_NAME}a

Mount the new rootfs to /mnt and install FreeBSD:

mount /dev/mirror/${ROOTFS_NAME}a /mnt
cd /usr/src
make buildworld >&! buildworld.log
make buildkernel >&! build_generic.log
make installworld DESTDIR=/mnt
make distribution DESTDIR=/mnt
make installkernel DESTDIR=/mnt

Now you need to cre­ate /mnt/etc/rc.conf (set the default­router, the IP address via ifconfig_IF (and do not for­get to use the right IF for it), the host­name, set sshd_enable to yes, add an user (I used “vipw –d /mnt/etc”) which is in the wheel group so you can login remotely, and maybe other things you are inter­ested in), /mnt/etc/resolv.conf, /mnt/etc/hosts. Finally, do not for­get to load the gmir­ror mod­ule, it will safe a lot of head-scratching (yes, an echo would be shorter, but WP con­verts the single-quotes to double-quotes), and add the rootfs to the fstab:

cat > /mnt/boot/loader.conf <<EOT
echo "/dev/mirror/root0a / ufs rw,noatime 1 1" >/mnt/etc/fstab

Now we are ready to install, the image can be unmounted:

umount /mnt

The final steps are to login into the res­cue con­sole (the­o­ret­i­cally you should be able to over­write even a run­ning sys­tem, but then you need to make sure there is a way to power-cycle the sys­tem remotely to force a reboot) of the new sys­tem and to install via a com­pressed ssh con­nec­tion (my remote res­cue sys­tem is a linux sys­tem, so linux-syntax has to be used). The login to the res­cue con­sole is not shown here, but the install from the remote sys­tem is sim­ple (this assumes the image resides on a sys­tem which is acces­si­ble from the new system):

ssh -C -o CompressionLevel=9 user@myhost cat /path/to/${FILENAME} | dd of=/dev/hda bs=1m

Alter­na­tively you can com­press it with bzip2 on your sys­tem and add an bunzip2 into the pipe above. This way you could even use an HTTP server to fetch the file from, but then the com­mand to fetch the file needs to have a way to out­put the file it down­loads on std­out. Both ways of trans­fer­ring the image depend upon the sta­bil­ity of the trans­fer. If the con­nec­tion is cut, the sys­tem can not boot any­more. So if you do not have a res­cue con­sole which is inde­pen­dent from the con­tent of the hard­disk, you bet­ter have a plan B.

If I did not make an error here (I did this some months ago, I hope I did not for­get to write down some impor­tant step and also cor­rected all steps which where not writ­ten down cor­rectly), you did every­thing cor­rectly too, and the remote sys­tem does not need other ker­nel mod­ules loaded, you can now reboot the new sys­tem, cross your fin­gers for some moments, and then login to the new system.

Post install TODO

Now you should have a basic sys­tem up and run­ning, and you can start to con­fig­ure it.

I added two more FreeBSD par­ti­tions, 1 GB for swap, and the rest of the hard­disk (I took care to not have the last par­ti­tion cover also the last sec­tor of the hard­disk, else gmir­ror will think it has to mir­ror the entire hard­disk and not only the last par­ti­tion) as one big par­ti­tion. For the sec­ond hard­disk I made the same par­ti­tion­ing as for the first harddisk.

Then I cre­ated two more gmir­rors, one mir­ror for the swap, and one for the rest of the space. The mir­ror for the swap I cre­ated with the option “-F”, to not syn­chro­nize the par­ti­tion after a power fail­ure (not nec­es­sary for swap). All two I also cre­ated with the “-n” option, to not sync the con­tents (there is noth­ing yet, so it does not mat­ter what is writ­ten there).

Now just a quick “bsd­la­bel” on the two mir­rors to cre­ate a “b”-partition for the swap and a “d”-partition for the large par­ti­tion. To add the swap it is just an “echo /dev/mirror/swap0b none swap sw 0 0 >/etc/fstab”. Do not for­get to add the big par­ti­tion to the fstab (after doing a “newfs” off course).

To be sure it will sur­vive a reboot, do a quick test of man­u­ally mount­ing the big par­ti­tion (use the easy man­ual way via “mount /place/where/it/is/mounted” after adding it to the fstab, not the com­plete man­ual way, this is meant to test the fstab entry too), and a “swapon –a” to test the swap. I also made a reboot test, just to be sure every­thing is ok.

The final step was to add the par­ti­tion on the sec­ond hard­disk to the rootfs (“gmir­ror insert ${ROOTFS_NAME} /dev/…”).

GD Star Rat­ing
GD Star Rat­ing

Tags: , , , , , , , , ,