Older blog entries for richdawe (starting at number 130)

4 Nov 2007 (updated 19 Jul 2008 at 12:07 UTC) »

File::ExtAttr 1.06, mab2ldif

I released File::ExtAttr 1.06 to fix building on Mac OS X. File::ExtAttr provides an interface to extended file attributes (meta-data) that's consistent across Linux, Mac OS X, *BSD, Solaris.

I also released mab2ldif, which takes a Mork-format address book (e.g.: as used by Thunderbird) and converts it into an LDIF file. You can import the LDIF file into Thunderbird. I wrote this to recover my old Thunderbird address book from an old computer that died. You can actually export the address book from Thunderbird into LDIF, but if Thunderbird won't run, you'll need this tool to get your data back.

Syndicated 2007-11-04 10:45:11 (Updated 2008-07-19 11:18:24) from richdawe

4 Nov 2007 (updated 19 Jul 2008 at 12:07 UTC) »

richdawe @ 2007-11-04T10:23:00

I saw on Adam Leventhal's blog that Apple ship a DTrace provider for Perl with Leopard:

"Not only did Apple port DTrace, but they've also included a bunch of USDT providers. Perl, Python, Ruby -- they all ship in Leopard with built-in DTrace probes that allow developers to observe function calls, object allocation, and other points of interest from the perspective of that dynamic language."

It's also mentioned on Unix Technology page for Leopard.

I had a quick look to see if Apple had released any patches. I didn't find any -- at some point I should dig around their open source section, to see if it's included in that.

I did find OpenSolaris Bug ID 6355891 asking for Perl support to be added to DTrace.

Syndicated 2007-11-04 10:40:34 (Updated 2008-07-19 11:19:03) from richdawe

Women in Tech/Biz

I read a few interesting articles about women and tech/biz recently:

On an unrelated note, I found Judith Donath's talk at Google "Signals, Truth and Design (with an emphasis on information and fashion)" interesting.

Syndicated 2007-10-28 18:17:57 from richdawe

The War of Art

I recently read The War of Art by Steven Pressfield. It's a book about overcoming creative blocks and other factors that prevent you from being creative, called Resistance.

I found it to be an entertaining, quick read (~2 hours). I didn't actually find it as useful as I was expecting. I originally bought it to try to get past some blocks, but I overcame them naturally. In fact, at one point I was procrastinating so much that I thought about reading this book, rather than doing anything else -- and that spurred me to stop procrastinating and just do something. One of the key ideas in the book is that by just starting something, you will overcome the blocks.

At a few points the author talked about difficult parts of his life, which seemed to be key to him forming his idea of Resistance (in all its manifestations). I felt there wasn't quite enough detail at these points (and there isn't much more on his website). It would have been useful to understand his journey. That said, it didn't really detract from the presentation of the ideas.

A lot of the ideas in this book are quite simple. But it's easy to lose track of them, when you are being distracted. And the book contains some good quotes. So I think I would turn to this book, if I were in the middle of a creative funk.

Syndicated 2007-09-08 12:32:34 (Updated 2007-09-08 12:34:04) from richdawe

postfix config-o-rama

I spent a lot of today finally setting up e-mail for my domain, phekda.org. My goals were:

  • Set up an SMTP SUBMIT server (running on port 587), so that I can send mail from @phekda.org addresses from anywhere.
  • Require mail to be submitted over TLS.
  • Authenticate the client by requiring that the client presents a certificate issued by my private certificate authority (CA). Since I'm only going to issue certificates to people/machines I trust, possession of a certificate is implicit authentication.

TinyCA

I used TinyCA2 to set up my own personal CA. It's really easy to use. I created a CA for phekda.org. I also created a "bad" CA for testing that my postfix box would only accept certificates issued for phekda.org.

Here's what I generated in total:

  • CA cert for phekda.org
  • Server cert for mail.phekda.org, signed by CA phekda.org
  • Client cert for my desktop machine, signed by CA phekda.org
  • CA cert for bad.ca
  • Client cert for my desktop machine, signed by CA bad.ca (for testing)

Tip: You can generate password-free keys with TinyCA2. To do this you create the key as normal, specifying the password. When you export the key into a PEM file, you can choose to export without the password.

Server-side postfix configuration

My server is running postfix 2.3.8 on Debian 4.0. The server-side config was split into two halves: general TLS configuration in main.cf, and the config to turn on an SMTP daemon on port 587 with TLS enabled.

Here's the config I added to main.cf:

smtpd_tls_req_ccert = yes
smtpd_tls_session_cache_database = sdbm:/etc/postfix/smtpd_scache

smtpd_tls_CAfile = /etc/postfix/CAcert.pem
smtpd_tls_cert_file = /etc/postfix/server-cert.pem
smtpd_tls_key_file = /etc/postfix/server-key.pem

# Log TLS info, in logs and headers.
smtpd_tls_loglevel = 2
smtpd_tls_receivedheader = yes

Note that these entries in main.cf don't actually enable TLS. smtpd_tls_req_ccert requires SMTP clients to use STARTTLS, when TLS is enabled. The smtpd_tls_*file entries set up everything that's needed on the server-side for TLS encryption. I turned on the last couple of options for debugging purposes.

Here's the line I added to master.cf, split over multiple lines for clarity. You won't need the backslashes, when you recombine them into one line.

587       inet  n       -       n       -       -       smtpd \
-o smtpd_enforce_tls=yes \
-o smtpd_tls_req_ccert=yes \
-o smtpd_recipient_restrictions= \
  permit_mynetworks, \
  permit_tls_all_clientcerts, \
  reject_unauth_destination

smtpd_recipient_restrictions allows clients with authenticated certificates to relay, in addition to local users. Although I'm not sure why a local user would relay through port 587.

Server-side testing

I tested this using OpenSSL's s_client, to set up a client SMTP session using the client certificates I generated with TinyCA2. You fire up openssl s_client with appropriate options, then enter SMTP commands as normal, e.g.:

ehlo fred
mail from:<me@my.domain.example>
rcpt to:<someone@somewhere.else.example>
data
Subject: just a test

.

You need to go all the way, to check that the message can actually be delivered.

  • Connection should be accepted, because the client is using a certificate issued by the CA for phekda.org:

    openssl s_client -connect mail.phekda.org:587 -starttls smtp \
      -CAfile phekda.org-cacert.pem \
      -key katrina.phekda.gotadsl.co.uk-key.pem \
      -cert katrina.phekda.gotadsl.co.uk-cert.pem
  • Connection should not be accepted, because the client is using a certificate not issued by the CA for phekda.org:

    openssl s_client -connect mail.phekda.org:587 -starttls smtp \
      -CAfile phekda.org-cacert.pem \
      -key mail.bad.ca-key.pem \
      -cert mail.bad.ca-cert.pem

    And a slight variation:
    openssl s_client -connect mail.phekda.org:587 -starttls smtp \
      -CAfile bad.ca-cacert.pem \
      -key mail.bad.ca-key.pem \
      -cert mail.bad.ca-cert.pem

Tip: One thing to beware of is that OpenSSL will do a TLS renegotiation if you use "RCPT TO", so use "rcpt to" instead.

Client-side postfix configuration

I have several e-mail accounts. I want to keep sending from my old domain @phekda.gotadsl.co.uk, but I also want to be able to send from @phekda.org. These messages would be sent via the same postfix server running on my desktop machine.

Before making the changes, all my mail was smart-hosted through my ISP's mail server -- i.e.: all my mail went through my ISP's mail server. Afterwards, my @phekda.org was routed over TLS to mail.phekda.org on port 587, and the rest of the mail was smart-hosted.

To achieve what I wanted, I set up sender-based routing (SBR). Normally mail is routed by recipient address -- SBR overrides the recipient-based routing. Configuring sender-based routing was the hardest part to achieve, because postfix's documentation of SBR and its sender_dependent_relayhost_maps configuration format is a little, uh, brief. Fortunately the postfix source code is readable, and I figured it out from that.

My desktop box is running postfix 2.4.3 on Fedora 7. The client-side postfix config is split into three parts: routing and TLS configuration in main.cf; sender-based routing (SBR) map file, sender_dependent_relayhost; TLS policy map file, smtp_tls_policy.

Firstly, here's the configuration in main.cf:

# Smart-host via Nildram...
relayhost = [smtp.gotadsl.co.uk]

# ...except for certain senders, who we relay through other boxes.
sender_dependent_relayhost_maps = hash:/etc/postfix/sender_dependent_relayhost

# TLS configuration for sending mail to phekda.org
smtp_tls_CAfile = /etc/postfix/CAcert.pem
smtp_tls_cert_file = /etc/postfix/client-cert.pem
smtp_tls_key_file = /etc/postfix/client-key.pem

smtp_tls_loglevel = 1

smtp_tls_policy_maps = hash:/etc/postfix/smtp_tls_policy

Here is /etc/postfix/sender_dependent_relayhost_maps:

#
# Regenerate using:
#   postmap hash:sender_dependent_relayhost < sender_dependent_relayhost
#

# phekda.org sender should be submitted to mail.phekda.org.
@phekda.org	[mail.phekda.org]:587

It wasn't clear how I could configure all phekda.org subdomains to be routed in the same way. It looks like I would have to specify them all manually. Any domains not configured in this file are routed using the normal mechanisms, which in this case ends up being the smarthost specified by relayhost.

Here is /etc/postfix/smtp_tls_policy:

#
# Regenerate using:
#   postmap hash:smtp_tls_policy < smtp_tls_policy
#

phekda.org	secure
[mail.phekda.org]:587	secure

These configuration files need building into .db files before postfix can use them -- this is done using postmap. I wrote a simple Makefile to automate that.

Client-side testing

I tested sending to my gmail account using @phekda.gotadsl.co.uk and @phekda.org addresses. I did this using plain ol' telnet. From the postfix log in /var/log/maillog, I could see where the messages were being routed to. E.g.:

Sep  1 20:30:38 katrina postfix/smtp[27281]: 3225BD: to=<richdawe@gmail.com>,
relay=smtp.gotadsl.co.uk[195.112.4.54]:25, delay=8.6, delays=8.2/0.19/0.11/0.09,
dsn=2.0.0, status=sent (250 Ok: queued as 3501A2BAE63)

Sep  1 20:51:31 katrina postfix/smtp[27374]: 9E258D: to=<richdawe@gmail.com>,
relay=mail.phekda.org[80.68.89.241]:587, delay=25, delays=24/0.13/1.1/0.15,
dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 0E501803B)

It was easy to see when the config was broken.

Syndicated 2007-09-01 20:36:23 (Updated 2007-09-01 20:39:07) from richdawe

20 Jul 2007 (updated 1 Sep 2007 at 21:06 UTC) »

Perl and DTrace

I finally got DTrace working on Perl, as described in Alan Burlison's blog post on how to DTrace Perl. I have a patch to add DTrace support to Perl, which includes some instructions and example scripts.

I'm giving a talk on DTrace and Perl next Wednesday evening at Birmingham Perl Mongers.

Syndicated 2007-07-20 11:44:29 (Updated 2007-09-01 20:38:36) from richdawe

Got me some OpenID

I finally signed up for an OpenID identity with MyOpenID. I'd been meaning to try out a single sign-on scheme for a while. OpenID hits all the right buttons for me: open, lots of implementations, low barrier to entry (compare that with Microsoft Passport).

I found the following blog post and sites helpful:



The process was pretty straightforward, with one twist. I wanted my OpenID name to be rich.phekda.org, i.e.: to delegate from my personal domain/host to the actual OpenID server. OpenID is designed to support this.

Here are the steps in getting it working:


  1. Read lots of web pages about OpenID. ;)

  2. Sign up for OpenID at MyOpenID.

  3. Test out my new OpenID richdawe.myopenid.com by using OpenIDEnabled's test page, and also by logging into LiveJournal with OpenID.

  4. Set up a virtual host on my web server for rich.phekda.org.

  5. Create a basic web page for rich.phekda.org.

  6. Set up the OpenID delegation. Add the link and meta tags to rich.phekda.org's web page, as described in "Use your own URL as an OpenID".

  7. Test out my new OpenID rich.phekda.org by using OpenIDEnabled's test page, and by posting on Wez's blog.



One thing I was hoping for is that I could log into LiveJournal with my OpenID, rather than my actual username. Currently there is no link between LJ account and an OpenID, so that isn't possible. The OpenID does allow people to authenticate themselves, so that comments can be tied to a particular OpenID.

Syndicated 2007-07-11 09:59:11 from richdawe

Some thoughts on the podcast of the "4-hour Workweek" at SXSW

A former colleague of mine sent me a link and some comments on the podcast of the  "4-hour Workweek" session by Tim Ferriss at SXSW. Here are my thoughts:

I have to admit that I was pleasantly surprised. I was expecting some  trivial fluff. It turned out that the book title over-trivialises his message (in my opinion), and that there's something for everybody.

I certainly noticed that checking e-mail two or three times a day does increase productivity a lot. But I hadn't thought about using an auto-responder to, er, "educate" people who expect instantaneous/quick responses (especially to counter the infamous "have you read my e-mail"  phone calls).

I think he hit the nail on the head with busyness vs. productivity. I found that in trying to engineer software that it's very easy to try to cover everything, which results in a long to-do list of loose ends (and hence crap tasks).

Deciding the importance of tasks is hard. His suggestion of using metrics is good, but I'm not sure how you apply that to small tasks. Maybe none of the small tasks are worth doing. He did also say that his answer was the quick one, so I'd be interested to know if he goes into more detail in the book.

I was hoping he'd say more about his comment about retirement: "What do you do when retirement not an option?". I'd come to the conclusion that I would work right up until the end in some capacity, probably not full time.

I'm not sure his strategy of employing lots of Indians would work in Software Engineering. I mean, if you outsourced 90% of your work to  Sierra Atlantic, say, how would you convince your employer to continue employing you rather than SA directly? I wonder if the technique could be more usefully applied to personal life, e.g.: "please manage my stock  portfolio", or "find me the best private medical health insurer".

Syndicated 2007-07-09 17:10:23 from richdawe

Test::YAML::Meta and Fedora 7

Following the last Birmingham Perl Mongers, I decided to add checking of the META.yml file to File::ExtAttr. There is a module to do this called Test::YAML::Meta.

Test::YAML::Meta is not packaged by Fedora (yet), so the first step was to package that. That required a newer version of Test::More. One nice thing about Fedora 7 is that the perl rpms have been split up, so now you can actually update core Perl modules smoothly -- no force installs, no conflicts, no verification failures. The resulting rpms are here: http://yum.phekda.org/fedora/F7/

Once that was done, it was pretty simple to create a test:

[rich@katrina File-ExtAttr]$ cat
t/04yaml-meta.t 
#!perl -w


use strict; use Test::More; eval "use Test::YAML::Meta"; plan skip_all => "Test::YAML::Meta required for testing META.yml" if $@; meta_yaml_ok();

VMware-server and Fedora 7

It turns out that VMware-server on Fedora 7 x86_64 is completely broken, due to an interrupt handling fix in kernel 2.6.21. My x86_64 hangs hard whenever I try to boot an OS in VMware.

One solution is to downgrade to 2.6.18 from FC6. I rebuilt the FC6 kernel source rpm on F7; resulting rpms here: http://yum.phekda.org/fedora/F7/x86_64/. Just install the kernel and kernel-devel rpms, and edit /etc/grub.conf to default to the 2.6.18 kernel (if you want). Everything has been peachy VMware-wise since installing those.

2.6.20 apparently also works, but I remember having hanging issues with that when I was running FC6 + updates.

121 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!