I was honoured to be on the ETech 07 programme committee. Alas, I can't get there this year due to the very enjoyable reason of recent parenthood. Nevertheless, here are some of the talks I'd earmarked to attend.
Creating Addictive User Experiences (Kathy Sierra)Is it possible to say too many good things about Kathy Sierra? Any project or product built with attention to her advice about empowering users gets a huge head start to popularity and success. I was fortunate enough to spend a day with Kathy last year on a training course, and it was great to see the passion and commitment from her writing runs through her as a person, even behind the scenes.Applied Web Heresies (Avi Bryant)I'd go to this one out of insatiable curiosity. I believe that web conventions enable rapid application design (c.f. REST in Rails) but here's an argument that not following them also reaps rewards. Attend this talk prepared for involvement. I've never met a Squeaker without attitude.
Making Offline Web Applications a Reality (Zimbra)A short product talk, but taking web apps offline is an area to watch. Even if you don't think offline is that important to you, many of the same principles apply to application mobility. Take that key app data off onto your phone, watch or memory stick.Collective Intelligence, Indeterminacy, and the Illusion of Control (Charles Armstrong)More user-facing stuff. How do you give a user of a large nondeterministic piece of social software the idea that they're in control? This is an important topic to me: note how many pieces of social software fall by the wayside right away. For some, it's lack of utility, but that's influenced too by the degree of engagement and control a user feels.
No Program Left Behind: Liberating TV from the Tyranny of the Ephemeral (Tom Loosemore)There is no good reason not to listen to Tom Loosemore. Especially when he feels strongly about something. The idea of this talk is a "vision of a cheap consumer device sitting under your TV that will capture, store, and share all TV, forever." The TV industry sure needs its visionaries.
Patterns: From Fabrics to Fabrication (Dale Dougherty)Dale was responsible for getting my XML career off the ground, and you can find him at work behind some of the smartest things O'Reilly's done over the years. Make magazine was one of those, and now he's moving on to Craft. Design patterns for, er, real designs.RFID Guardian: A Personal Platform for RFID Privacy Management (Melanie Rieback)
Jamming bad RFIDs. Having just taken delivery of an RFID-enabled passport, this is starting to come home to me.Super Ninja Privacy Techniques for Web App Developers (Marc Hedlund)Despite the cute title, lots of good stuff here. Expectnation is going to end up with a truck load of user registrations, and their privacy is important to me. I imagine there'll be some good debate in the Q&A session for this talk.JavaScript: It's Happening All Over Again! (James A. Duncan)I've recently got the JS bug, thanks to JQuery. It's actually a fun and malleable language to work in. I'd go to this talk looking for fellow travellers and hints, though I'm a bit skeptical about Zimki itself.

• ETech 2007 registration
  

Here are some scenarios for ways that I want to use Debian on semi-embedded and embedded devices. So far there's not a good way to accomplish most of these, and each scenario needs at best a different approach, from flashybrid to Embdebian to ADS root builder to hand hacked images. That will change, I hope, if the grand unified scheme I'm plotting comes to fruition. If some of these scenarios interest you, please check out the design at http://wiki.debian.org/RootSync. openmoko First, install Debian to a 2 gb microSD card in the phone, using d-i. Bog-standard Debian install (except for it being g-i running on a cell phone!), standard partitioning. Boot the install and use it for a while. Install more stuff and tweak the system. Now you want to remove that microSD card, to save power. So, unmount it, and remove it. Debian continues running; all the files you normally use, including everything needed to boot the system, have already been copied over to the flash. If the flash gets too full, just delete any files you don't need right now. If you later find you're missing a file, just plug the microSD back in, mount it, and you can access the file again. This is also an easy way to do a backups, a simple command can sync your changes up to the microSD card. Also the microSD card can be plugged into a different openmoko phone, chrooted into, a command run, the phone rebooted, and it's been taken over, now running the same Debian install. Great party trick. ;-) slug with a 32 mb USB stick This is my sister's nslu2 box, that only does one thing, really: Dial up to the internet and route packets to the access point. It's also nice to get Debian security updates from time to time. And I don't want to have a noisy hard drive on it, so it runs from a small USB stick. The initial install is done to USB drive, then I add the USB stick to the picture, boot the nslu2 up, configure ppp, run it, and I can remove the drive, it's ready to run in embedded mode from the USB stick. Later I need to apply a security update, so I plug in the USB drive, mount it, run aptitude, and I'm done, just unmount the USB drive again, and the USB stick now has updated versions of the necessary files. true embedded system development A company is creating a real embedded arm system, it needs to run from 64 mb of flash, with a fair chunk for their own application, and a fair chunk free for user data. An engineer is using his development system to work on creating the jffs2 filesystem that will go on the production hardware. He starts by untarring the Debian armel port to a drive, and copies in the custom application. Then he sets up an empty jffs2 filesystem on mtdblockN. After rebooting the system, the jffs2 contains the files needed to boot Debian on its own. The engineer runs the custom application, and the jffs2 is now ready to run that too. But it's getting a bit tight for space on the jffs2. Time for busybox. He runs "busybox install [long list of busybox commands]", replacing lots of core commands with their smaller busybox versions. After a few reboots, all the init scripts are hacked up to work with the busybox stuff. (Argh.. Debian should work with it by default. Anyone want patches?) Maybe he goes on to run mklibs or do something with uclibc. This might take a few iterations to get right, but he doesn't worry about screwing up the system -- he knows that at any point he can delete all the files on the jffs2, reboot, and be back to his unmodified system on the disk drive. Once everything is ready, he can load the jffs2 onto production hardware and the new embedded system is ready to be tested and qualified. slug thick client My nslu2 box, used for handling some USB devices like my UPS, security camera, etc. When the network is up, and the storage server is up, it can nfs mount root, but that doesn't work when the power goes out and the server needs to come down. I want it to keep working in that case, as a kind of detached thick client. After hacking nfs root support into d-i at some future point :-) I have it booting with nfs root already. There's around 3 mb of unused flash on the slug, so I set up a jffs2 partition using that, and through some trial and error get the right files on there to let the system keep running in a degraded mode when the nfs mount goes down. 3 mb does fill up pretty quickly if the camera notices motion, but it's good enough, so I decide not to put a USB stick on the box.

The Finnish parliamentary elections are very soon. I kinda like my candidate’s flyer (no, I did not take part in its design): The text reads: Geek to Parliament! Basic rights must be preserved on the Internet and elsewhere. Technology for nature and people. What is the fate of MP3?

From the po-debconf language ranking page: Afterwards, I will rest.

From the po-debconf language ranking page: Afterwards, I will rest. (I’m going after the 12th position. Three weeks ago I had fewer than 2800 strings translated. Not bad for a language you didn’t even know existed).

I wonder why I have such a better feeling about the OpenMoko than the Nokia n800. I feel that I know the OpenMoko already just by reading Harald's blog and browsing its wiki. It's a pretty stock arm system, boots with uboot, system in jffs2 flash, interesting interface to the necessarily proprietary cell phone stuff, all the hardware will work with only lightly modified linux kernels and the kdrive X server. Major downside of no wifi, though bluetooth is available, and if there's power, a USB wifi dongle could be used. Afrer putting in a similar amount of time googling for info about the n800, I'm still left in the dark on a number of points. I don't know what the boot loader is, what kernel or X modifications are needed, whether non-free drivers might be needed for some hardware, etc. IIRC the n700 had some issues along those lines. Of course, the reason I care about this stuff is that I can't conceive of owning a linux PDA or cell phone and not putting Debian on it, and I don't mean running Debian in a chroot, which is as far as I've heard of people getting with either the n800 or the n700. The GUI stuff for both these is pretty nice, and would make nice Debian packages. I, however, want to use ion. Note: See discussion for some notes based on feedback.

Reduced the work queue after the nice weekend on CLT, I have some time to write a summary. After 2 years I was able to be there again, cause I blocked the weekend early in my timetable.
The event was organized quite well like it was all the time before. We stayed over night in a gym with round about 100 men and 5 women, really interesting, no more details! :)
The CLT was visited really good and there was many folks at debian booth. The range of questions did vary from rookie to advanced. Anyways … the question when etch will be released did hit us quite often.
The talks I visited was really good and very interesting. I did count 6 talks and one workshop held by debian folks.
The social event was a lot of fun and the buffet was nice. Debian scrounged, supported by team(ix) folks, at the game … the task was, to find linux commands in a text. We got place one, tree and the consolation prize. We found more commands than the organization committee, but we missed “ssh” .. what a blame … ;)
In summary I meet really interesting people, the event was quite well and I got too less spleep. Hopefully see you again there next year. Debian, opensource, planet

Last weekend I had great fun during my first cal otada with my Friends in Picamoixons, very near Valls in Tarragona. While it's already a tradition for my friends, this was the first time I went there, after having missed many other opportunities probably due to my overcommitment to triathlon training a few years ago. So on Friday we drove up North to Catalunya, and arrived quite late to Frago's house in the center of the town, where we slept in two packed rooms and the terrace after getting some beers in Dune. Early next morning we met Frago's friends and bought the necessary vegetables and wine for our great lunch, and soon after we were in the middle of some olive field outside Picamoixons, where we prepared a big fire and the cal ots. A cal ot is a special type of onion which grows in the area, which ends up being very long and thin. After cutting part of the green leaves, they are cooked over the flames, which carbonises the first few layers of the onion, but leaves the inner part ready for consumption. After this, you just need to pull from the inner leaves to get rid of the burnt stuff and eat the rest with a delicious and typical sauce for cal ots. So far, so good. What if your group of friends has extended the tradition, allowing for extra fun bits? In our cal otades, after you've peeled the cal ot, you keep the carbonised stuff. It's valuable ammo, which will soon be thrown at others' faces. Trying to remain clean is futile, you soon are covered by sauce and black stuff all over your head and clothes. This was real fun! After eating part of the group went up a mountain to visit an arab tower, which helped me not to get totally drunk before the night. When it got dark, we were all back to our positions around the fire, chatting and listening to varied music, while we waited for the lunar eclipse. The eclipse was impressive, seen from the country side, with absolutely no luminic contamination. My friend Jordi carefully prepared his camera to do a good photograph series of the event, and the results were impressive. When the eclipse was about to be full, it was great to see a miriad of stars appear in the sky, previously hidden by the perfect full moonlight. We were just too lucky that the weather fixed up just on time to have a completely clear sky.

The lunar eclipse, as seen from the Catalan countryside. Pics by Jordi Jover. Many were quite tired by 3 or so, so we started setting up tents and went to sleep by 4. Sunday was a slow day, dedicated to cleaning up our stuff and eating leftovers cooked on a new fire. We were back in Val ncia at 8PM or so and even after showering and cleaning my hair with shampoo, my head still smelled like smoke. Actually, I think it might still smell a tiny bit today. In short, a lovely weekend, which I hope to repeat next year. Too bad the lunar eclipse bit will be missing for quite a few more years. :)

Last weekend I had great fun during my first cal otada with my Friends in Picamoixons, very near Valls in Tarragona. While it's already a tradition for my friends, this was the first time I went there, after having missed many other opportunities probably due to my overcommitment to triathlon training a few years ago. So on Friday we drove up North to Catalunya, and arrived quite late to Frago's house in the center of the town, where we slept in two packed rooms and the terrace after getting some beers in Dune. Early next morning we met Frago's friends and bought the necessary vegetables and wine for our great lunch, and soon after we were in the middle of some olive field outside Picamoixons, where we prepared a big fire and the cal ots. A cal ot is a special type of onion which grows in the area, which ends up being very long and thin. After cutting part of the green leaves, they are cooked over the flames, which carbonises the first few layers of the onion, but leaves the inner part ready for consumption. After this, you just need to pull from the inner leaves to get rid of the burnt stuff and eat the rest with a delicious and typical sauce for cal ots. So far, so good. What if your group of friends has extended the tradition, allowing for extra fun bits? In our cal otades, after you've peeled the cal ot, you keep the carbonised stuff. It's valuable ammo, which will soon be thrown at others' faces. Trying to remain clean is futile, you soon are covered by sauce and black stuff all over your head and clothes. This was real fun! After eating part of the group went up a mountain to visit an arab tower, which helped me not to get totally drunk before the night. When it got dark, we were all back to our positions around the fire, chatting and listening to varied music, while we waited for the lunar eclipse. The eclipse was impressive, seen from the country side, with absolutely no luminic contamination. My friend Jordi carefully prepared his camera to do a good photograph series of the event, and the results were impressive. When the eclipse was about to be full, it was great to see a miriad of stars appear in the sky, previously hidden by the perfect full moonlight. We were just too lucky that the weather fixed up just on time to have a completely clear sky.

The lunar eclipse, as seen from the Catalan countryside. Pics by Jordi Jover. Many were quite tired by 3 or so, so we started setting up tents and went to sleep by 4. Sunday was a slow day, dedicated to cleaning up our stuff and eating leftovers cooked on a new fire. We were back in Val ncia at 8PM or so and even after showering and cleaning my hair with shampoo, my head still smelled like smoke. Actually, I think it might still smell a tiny bit today. In short, a lovely weekend, which I hope to repeat next year. Too bad the lunar eclipse bit will be missing for quite a few more years. :)

I forgot the PIN of my card recently, I dug into the "safe place where the PIN is written" and found that ... (let's say) I don't have it there anymore.

I went to the bank determined to reset my PIN and go on with my life. Here is a short version of the dialog:

- Hello. Your ATM has blocked my card. I would like it back.
- Ok, here you have it, but first, please tell my the secret word you wrote on the form when you made the card.
- Of course... [blabla]
- Ok. The card is unblocked, you will be able to use it in about 15 min.
- Well, yes. I would like to reset my PIN number since I forgot it.
- What kind of card do you have?
- Maestro
- I am sorry, for this type of card, we can't reset the PIN number. We will have to make another card.
- I am sorry, I think there is a misunderstanding here. Are you telling me that I have to make another card just because I want to reset my PIN?
- Yes, for this type of card is not possible to reset the PIN. We have to make another one. We don't have the list of PIN numbers for this kind of cards, so we can't reset the PIN.

[That sounds like "for other types of cards, we have the PIN numbers for every card out there listed on a tally sheet, but we don't for the type of card you have", put in another form. Spooky, huh?]

... If you had the PIN you could change it at the ATM, but we can't do that since we don't have the PIN number.

- Didn't you think that resetting the PIN is a feature useful enough to have?
- [here the broken recorder model enters the scene] For your type of card we can't reset he PIN, we will have to....

[more question from my side trying to understand why is it not possible to just ignore the old PIN and overwrite the information on the card were, of course, fruitless]

[after some time, I gave up]
- OK, how much will it take for the new card to be created?
- Two weeks.
- What? Anyway... how much will that cost?
- 7 RON (approx. 2 or 2.5$)
- OK. Can I withdraw now money from my account?
- Yes
- OK, good, at least that. I would like 500RON. Also, I would like to start the card change procedure.
- Of course.
[The guy gives me the money and starts to look into the system to start the "new card" procedure. Before giving me the money, I asked if he needed my ID or something, but I am not sure if he would have had asked me by himself, if I didn't...]
- There is a small problem...
- Oh, really? Let me guess, it is not possible to start the procedure from this sales point and I will have to go to another one...
- Yes. This card was created at the sales point in Calea Doroban ilor, through a corporate contract and I don't have access to that contract from here... Actually, if I think of it... your employer made that card for you, isn't it?
- Yes.
- In that case you will have to go to your employer and ask for a new card...

GREAT!

On the positive side, at least I can withdraw money from my account... OTOH, I didn't ask if having the card with me would be necessary to withdraw money, so I am not sure if, in the case I will have to give the card to my employer, I will be able to get any cash from the bank...

It’s still in a very early stage (I’ve started coding it yesterday), but it’s basic functionality is already there: You can query the BTS, filter the list of bugreports in realtime by typing something and view the full bugreports in HTML. You can even provide additional information for existing bugs or create new bugreports. It currently only supports icedove and mutt as mailclient but adding other clients is very easy. This tool is not designed to replace reportbug, it rather aims for the newbie users feeling uncomfortable typing their mails in vi and would rather have something to point and click. Maybe I can merge the code with reportbug, but after a quick look at it’s code it seems that this will not be as easy as I thought in the beginning. The code is available here. You’ll need python-qt3 to run it. Update: The screencast was created with byzanz via
$ byzanz-record -c -l -d 45 reportbug-ng.gif
Hint: Best to switch the desktop resolution to something like 800×600 before recording — resizing the gif afterwards is very expensive (cpu- and memory wise).

Christian is talking about problems with suspend-to-RAM and suspend-to-disk and the major cause of issue being the non-free Conexant HSF modem driver.

Since I got my new laptop I had my share of issues with suspend-to-*.

At the beginning everything worked fine, out of the box. Then (I think) I realized that my video card (damned ATI) was not working in accelerated mode, so I decided to fix that and since the card is too new to be even listed as existing on radeon driver's support page, I had to use fglrx.

Then I made the DRI work but suspend-to-ram ceased to work (after a few testing->experimental; experimental--> upstream updates, both ways); I started using the experimental driver (8.31.5-1) which proved to be stable enough (this time) just for suspend-to-disk, if it had dri enabled, or suspend-to-ram, if not having DRI enabled.

I even made a patch to help the maintainer update faster the package (I added a get-orig-source rule in debian/rules).

Now I have ported the patches in the debian package and updated it to 8.33.6 and I am running that. Problems include: consoles are not accessible, but suspend-to-ram and dri work. I will submit a bug with the patch to updated fglrx package.

I expect that I'll try soon to update to 8.34.8 in the hope that I will get all the things working: suspend-to-*, consoles, dri.

I recently wrote an article or two about distributed version control systems.

I've been using Darcs since 2005. I switched to Darcs, in fact, 10 days after the simultaneous founding announcements of git and Mercurial.

Overall, I have been happy. I continue to believe that it is the most distributed of the distributed VCSs, which is a Good Thing.

However, I have lately started having trouble with Darcs hanging while working on my Debian packages. My post to the Darcs user list drew out a few other people whith this problem, which is a design flaw of Darcs.

So I revisited the VCS landscape. I re-examined git, Mercurial, and bzr. I eventually decided to give Mercurial a try. I avoided git because I write some code that is portable to Windows, and git isn't (or isn't very well). Also, git is complex to pick up for me, and I certainly don't want to force something complex onto my contributors. bzr seemed to still have some strange behaviors that it's had for awhile, and I couldn't find even one advantage of it over Mercurial. So off I went with Mercurial.

I quickly learned a bit of a philosophical difference from Darcs to Mercurial.

Darcs avoids conflicts at all costs. Mercurial makes handling conflict easy and, in many cases, automatic.

It is exactly this Darcs behavior that permits both is excellent "darcs send" feature (still unmatched in any other VCS), but also causes its hang problems.

I found Mercurial quite pleasant to work with, and *fast*. It seems to be edging out git in speed tests sometimes these days.

It is easy to get started with Mercurial. The mq system -- similar to quilt or other patch-management programs -- is really quite an amazing hybrid between patch management and version control. I frankly don't see any need for other patch-management tools anymore.

Mercurial has a "patchbomb" feature where you can select a range of changesets to send off, and it will generate nice emails with one changeset per email, and send them to your selected destination, optionally with an introductory message. The normal way of interacting with other Mercurial users is via the hg export/import commands, which send around simple unified diffs plus some additional header information, optionally in the git extended diff format.

I am happy with Mercurial and am in the process of converting my Debian repositories from Darcs to Mercurial. I'm going to keep my personal code in Darcs for the moment because "darcs send" is still easier than "hg email", but that may change before long, depending on how my experience goes.

I'd encourage others to give Mercurial a try. The community is also very nice and helpful.

I have contributed patches to Tailor to make it make exact copies of Darcs repos into Mercurial, which are now in its Darcs repo. There is also a thread on the Mercurial list with some of my initial questions/concerns coming from a Darcs perspective.

This morning there were two or three classes from a local primary school on board my tram taking up all the seats (mostly three children to a seat).

So to answer some email and write blog entries I had to sit in a stair-well. Melbourne trams are symmetrical so that they can just change direction at the end of the line (unlike some other trams - the Amsterdam tram line 10 that I used to catch has a circle at each end of the line for the tram to turn). Being symmetrical means that the doors on the left side of the tram are used for passengers to get on and off, and the doors on the right are locked - so the right stairwell is a place you can sit to use a laptop if all the seats are taken.

While I was sitting on the floor some women started talking about me, I heard comments such as "he's answering his email", "it must save a lot of time, he could do half an hour of email on the way to work", and "he must work for an Internet company - look at his shirt" (I was wearing an Intel shirt given out at LCA 2007). At that point I decided to briefly explain the work I do, there's a limit to the amount of time I can refrain from joining the conversation when people are standing around me and talking about me.

They didn't seem to understand enough to enable me to explain anything about Linux.

A reminder on why we do Free Software Some months ago I needed to find out if proper forward-only cursors were implemented in the ODBC driver for MySQL. I didn't go very far with the documentation, but I've been diving in its source code and within 30 minutes I knew everything there was to know about the subject. Now, after years I haven't touched proprietary software at all, I've been asked to port dballe to use the Oracle ODBC driver. I had a similar problem: find out how to use scrollable cursors with Oracle's ODBC driver. The release notes (a file called ODBCRelnotesUS.htm that I probably can't put online without their consent) say that they're implemented since ages, but SQLSetStmtAttr always tells me that the driver does not support it. Maybe I have to enable it somewhere? Maybe it's a bug? I could have found out with one hour browsing this driver's source code, but that wasn't available. Instead, I had to spend a whole day of trial and error, google searching with all sort of keyword combinations, looking at strings output on the .so libraries, and in the end I still don't know. That porting project is now stuck indefinitely, and my customers had to pay for a full day of fruitless work. So, here's the reminder: If you base on 3rd party proprietary software, you can't provide a serious service.

I am no longer even nearly homeless, having just started renting an appartment. Because I’d be lonely on my own, I’m sharing with another Googler, Carlo Contavalli. Here’s the weird thing. We were chatting over lunch and it turns out that, unbeknown to either of us, we are both Debian Developers. Only in Google could this happen.

This post is here becuase Matt Brown got a job with google, so I'll probably end up sitting two desks away from him, or something. His Wordpress instance and the Uni's proxy don't get along... Snap! I'm looking forward to meeting you, I start in July. Seems the time of year for this sort of thing. The word I have is that I get relocation paid for, but I'm moving me and a laptop over the Irsh sea, rather than a house from New Zealand... Well done!

After asking for useable CA Software, I have finally settled on using EasyRSA. This is what I did to come across the packaging shortcomings of EasyRSA in Debian. Storing your CA Be sure that your CA is stored in a secure place. Don’t store it online, and make it accessible only to yourself. In my opinion, storing the the CA in a cryptoloop container file on a small 32 MB USB stick is a good idea. Cryptloop is rather easy today and available in the stock Linux kernel. I commonly use grml-crypt to manage the crypto loopback stuff:

sudo grml-crypt start /media/usb4/cryptoloop $MOUNTPOINT

Gotcha: don’t confuse sudo’s “password” prompt with grml-crypt’s “Enter LUKS passphrase” prompt, the cryptoloop password won’t bring you anywhere on the sudo prompt. Preparing the CA directory For the CA, create a dedicated directory in the mounted cryptoloop file system. You’re originally supposed to copy the entire EasyRSA directory tree in there, but I’d recommend to only link the files from your system’s EasyRSA directory to automatically take advantage of distribution updates. You’ll need at least these links:

lrwxrwxrwx 1 mh mh   56 Dec 25 23:23 openssl.cnf -> /usr/share/doc/openvpn/examples/easy-rsa/2.0/openssl.cnf
lrwxrwxrwx 1 mh mh   52 Dec 25 23:22 pkitool -> /usr/share/doc/openvpn/examples/easy-rsa/2.0/pkitool
lrwxrwxrwx 1 mh mh   60 Dec 25 23:23 whichopensslcnf -> /usr/share/doc/openvpn/examples/easy-rsa/2.0/whichopensslcnf

ln -s /usr/share/doc/openvpn/examples/easy-rsa/2.0/openssl.cnf .
ln -s /usr/share/doc/openvpn/examples/easy-rsa/2.0/pkitool .
ln -s /usr/share/doc/openvpn/examples/easy-rsa/2.0/whichopensslcnf .

Configuring your CA The only thing you cannot link is the vars file which contains your CA’s local settings:

export EASY_RSA=“$(pwd)”
export OPENSSL=“openssl”
export PKCS11TOOL=“pkcs11-tool”
export GREP=“grep”
export KEY_CONFIG=$($EASY_RSA/whichopensslcnf $EASY_RSA)
export KEY_DIR=“$EASY_RSA/keys”
# Issue rm -rf warning
echo NOTE: If you run ./clean-all, I will be doing a rm -rf on $KEY_DIR
export KEY_SIZE=1024
export CA_EXPIRE=3650
export KEY_EXPIRE=3650
export KEY_COUNTRY=“DE”
export KEY_PROVINCE=“”
export KEY_CITY=“”
export KEY_ORG=“Zugschlus.de”
export KEY_EMAIL=“mh+easyrsa-mh-openvpn@zugschlus.de”
export PKCS11_MODULE_PATH=“dummy”
export PKCS11_PIN=“dummy”

Comments have been removed from this file. Better copy the file from /usr/share/doc/openvpn/examples/easy-rsa/2.0/vars and edit it to your needs. I added the two PKCS11 variables since you won’t otherwise be able to issue certificate requests. Creating the CA Next, decide on a shell instance where you will do most operations, and source vars in there. Next, run /usr/share/doc/openvpn/examples/easy-rsa/2.0/clean-all. If you do this in a directory of an already-in-use EasyRSA CA, you’ll need to restore your backup. To actually initialize the CA, run pkitool --initca --pass. If you do not give the --pass parameter, you’ll create a CA that can issue certificates without asking for a passphrase, which might not be a brilliant idea. Choose a reasonably secure pass phrase. Creating Certificates - the simple and suboptimal way You can now simply proceed to create an arbitrary number of pairs of “private” keys and associated certificate by simply calling pkitool <clientname> and/or pkitool --server <servername>. Depending on your security policy, you can mandate the private keys to be protected by a passphrase (adding --pass to the command lines), but you’ll have the expense of being asked for the passphrase every time you start a new openvpn daemon. Creating Certificates the Right Way I have put the “private” in quotes since the keys created this way are not really private: The key was created on the box hosting the CA, was stored on the local (crypted) file system and needs to be moved to the target system via a secure channel. Doing so the right way is harder than expected, so it is usually the better way to keep the private key really private by creating it directly on the target system. On the target system, you need OpenVPN installed, and openssl. After the certificate was created, you can remove openssl again. Creating a private key is part of a key-pair generation process that also leaves a certificate request. The contents of the certificate request is public, and you can safely move it to the CA box and convert it to a certificate by signing the request. You only need to make sure that nobody exchanges your target system’s certificate request for her own before you sign it as you might end up certifying a wrong identity. For the rest of this document we’re going to assume that you have ssh access to the target system and have verified the ssh host key, so that you can be reasonably sure to be connected to the right system. To create a certificate request, you can use this script, which I have called create-easyrsa-cert-req:

#!/bin/bash
set -u
TMPDIR=“/tmp”
export OPENSSL=“openssl”
export PKCS11TOOL=“pkcs11-tool”
export GREP=“grep”
export KEY_CONFIG=“/usr/share/doc/openvpn/examples/easy-rsa/2.0/openssl.cnf”
export KEY_DIR=“$TMPDIR/keys.$$”
mkdir -p $KEY_DIR
export KEY_SIZE=1024
export KEY_EXPIRE=3650
export KEY_COUNTRY=“DE”
export KEY_PROVINCE=“”
export KEY_CITY=“”
export KEY_ORG=“Zugschlus”
export KEY_OU=“$(hostname --fqdn)”
export KEY_EMAIL=“mh+$(hostname)-ovpn-cert@zugschlus.de”
export DEBUG=1
umask 077
if [ “$ 1:-foo ” != “server” ]; then
  /usr/share/doc/openvpn/examples/easy-rsa/2.0/pkitool --csr $(hostname)
else
  /usr/share/doc/openvpn/examples/easy-rsa/2.0/pkitool --csr --server $(hostname)
fi
mv $TMPDIR/keys.$$/* .
rm -rf $TMPDIR/keys.$$

When called without parameters, it creates a certificate request for an OpenVPN client certificate, and when you call it with “server” as parameter, it will create a server certificate request. In any case, it will leave two files in the current directory. They are named after the current host name, and have the extensions .csr and .key. The .key file is your private key. keep it private! The .csr file is the certificate request which you can now move to the keys subdirectory of your CA directory via scp or other means such as an USB stick. To do the actual signing, invoke pkitool --sign <hostname> and enter the CA passphrase. You can ignore the error message that there was no .key file to chmod. Gotcha, when signing a server certificate, use pkitool --server --sign <hostname>. Move Certificate to the target host You can now move the certificate to the target system. Since you’re probably going to need the root certificate and the certificate revocation list as well, you can move the .key file (if created on the CA system), the .crt file, and ca.crt to the target system. These files are public, so there is no need for a secure channel. Revoking Certificates Since an OpenVPN server’s only means of authentication is to check whether the certificate presented by a client is signed by the “right” CA, the only way to revoke VPN access is to revoke the certificate. This is also done on the CA system by calling /usr/share/doc/openvpn/examples/easy-rsa/2.0/revoke-full <client-name>. This creates a crl.pem file which contains a list of all revoked certificates. You need to have a mechanism to distribute that list to all systems that might need it, and it is recommended to have this automated. Remember, if you do not distribute the .crl file, the systems are not going to know about revoked certificates.

Description: SMTP command-line test tool
 swaks (Swiss Army Knife SMTP) is a command-line tool written in Perl
 for testing SMTP setups; it supports STARTTLS and SMTP AUTH (PLAIN,
 LOGIN, CRAM-MD5, SPA, and DIGEST-MD5). swaks allows to stop the SMTP
 dialog at any stage, e.g to check RCPT TO: without actually sending a
 mail.
 .
 If you are spending too much time iterating “telnet foo.example 25”
 swaks is for you.

A very important tool which makes debugging e-mail a breeze. A must for every mail admin.