Recently, I’ve been going all out on deploying LDAP and realising how much easier it would have made my life over the years. Fusion Directory has proven to be a good management interface for keeping things in check.

That’s the easy part though - now how do you go about making all your software to implement the features of LDAP and FusionDirectory? Sometimes with difficulty!

After a lot of mucking around, I’ve managed to get postfix working properly with LDAP as a source of email accounts, alias, forwards etc. We want to use the standard gosaMailDelivery flags to make life easy - and these are well documented for Fusion Directory.

Firstly, I’m going to assume that you already have openLDAP and Fusion Directory running. The documentation here is more than adequate to follow.

So now we’re down to postfix.

Firstly, we want to handle accounts that postfix needs to deliver mail to. Create a new file /etc/postfix/ldap-accounts.cf and use the following:

1
2
3
4
5
6
7
8

server_host             = ldap.example.com
search_base             = ou=people,dc=example,dc=com
scope                   = sub
bind                    = no
version                 = 3
 
query_filter            = (&(mail=%s)(objectClass=gosaMailAccount)(!(gosaMailDeliveryMode=[*I*])))
result_attribute        = mail

Now we want to handle aliases - so create /etc/postfix/ldap-aliases.cf:

1
2
3
4
5
6
7
8

server_host             = ldap.example.com
search_base             = ou=people,dc=example,dc=com
scope                   = sub
bind                    = no
version                 = 3
 
query_filter            = (&(gosaMailAlternateAddress=%s)(objectClass=gosaMailAccount)(!(gosaMailDeliveryMode=[*I*])))
result_attribute        = mail

Next step is forwards with delivery to the local account as well - create /etc/postfix/ldap-forward.cf:

1
2
3
4
5
6
7
8

server_host             = ldap.example.com
search_base             = ou=people,dc=example,dc=com
scope                   = sub
bind                    = no
version                 = 3
 
query_filter            = (&(|(gosaMailAlternateAddress=%s)(mail=%s))(objectClass=gosaMailAccount)(!(gosaMailDeliveryMode=[*I*])))
result_attribute        = mail,gosaMailForwardingAddress

And lucky last, we have forwards only - without a local delivery in /etc/postfix/ldap-forward-only.cf:

1
2
3
4
5
6
7
8

server_host             = ldap.example.com
search_base             = ou=people,dc=example,dc=com
scope                   = sub
bind                    = no
version                 = 3
 
query_filter            = (&(|(gosaMailAlternateAddress=%s)(mail=%s))(gosaMailDeliveryMode=[*I*])(objectClass=gosaMailAccount))
result_attribute        = gosaMailForwardingAddress

Once these files have been created, we can configure postfix. I use a full virtual delivery - so no user accounts exist on the mail server. Add the following to /etc/postfix/main.cf:

1
2

virtual_alias_maps = proxy:ldap:/etc/postfix/ldap-aliases.cf proxy:ldap:/etc/postfix/ldap-forward.cf proxy:ldap:/etc/postfix/ldap-forward-only.cf
virtual_mailbox_maps = proxy:ldap:/etc/postfix/ldap-accounts.cf

That is the bulk of the setup done.

As I’ve been using StartSSL for a long time to secure everything from SMTP / IMAP to this web site, I’ve gathered quite a few certificates. The scene has changed quite a bit these days with Lets Encrypt becoming available with free certs (but limited to 30 days).

StartAPI was introduced by StartSSL to do a lot of the same features, but gives you a 1 year certificate that you are able to manually place wherever you like. No custom software, no daemons etc. In my mind, this is what Lets Encrypt should have been.

I’ve created a few tools to assist in validating domains, and then retrieving certificates and am looking for people to help me test them before I release them to the general public.

If you already use StartSSL, I’d be happy to hear from you and get you to test what I’ve built up.

EDIT: After having a few people test it out and things work successfully, I’ve written some basic documentation and made it available on GitHub for testing / contribution.

Just wanted to write a quick note to explain why the current nightlies aren’t working.

The openwrt servers had an outage recently. As of now, svn.openwrt.org, downloads.openwrt.org and I think lists.openwrt.org are still down.

As the nightly builds feed from svn.openwrt.org, the builds won’t start again until svn.openwrt.org is restored. If you’ve just flashed an image, chances are that you can’t install things like luci at the moment - as those are stored on downloads.openwrt.org.

All in all, when things are back in working order, things should just magically start working again.

Quite a while ago, I applied to host Flight Radar 24 receiver at my place near Melbourne Airport, Australia (YMML). It started off with the ID F-YMML1 (being the first in Victoria), but a faulty unit saw the handle change to F-YMML4. With it, there was a massive boost in ASD-B reporting for Victoria - being the first receiver that could pick up aircraft on the ground and at the gate at YMML.

I always knew the coverage was fairly wide spread, but never really visualised it - until today. From my location, it covers high flight levels almost as far as Tasmania, and as north as the NSW border. In the attached screenshot, this plot shows all aircraft received by F-YMML4 in red. The normal FR24 feed shows in other colours. Rather good for a tiny receiver box.

Last night I made some changes to the build process of the generated images for the WD N600 and N750 routers.

Starting from r48362, the following changes are active:

1. The designated_driver_luci repository is enabled by default. This allows people to install luci by doing: opkg update && opkg install luci
2. Added an entry to /etc/opkg/distfeeds.conf that will point to that revisions base packages
3. Enabled building all KMODs for the openwrt kernel as packages. Combined with the above change, this allows auto-dependency resolution to work correctly.

As always, bug reports and comments are welcome.