OpenLDAP multiple database support under Ubuntu

My OpenLDAP slapd was working just fine, until I tried to run multiple databases. I had created multiple new directories under /var/lib/ldap and moved the original contents of /var/lib/ldap to one of these new subdirectories. In this setup, when starting slapd, it would fail and I would get the following error in the syslog:

[10871.644142] audit(1216392346.825:24): type=1503 operation="inode_create" requested_mask="w::" denied_mask="w::"
name="/var/lib/ldap/database1/DUMMY" pid=16406 profile="/usr/sbin/slapd" namespace="default"
/etc/ldap/slapd.conf: line 64: invalid path: Permission denied

The audit entry is an audit from AppArmor. It seems that in Ubuntu AppArmor is configured for slapd, and in such a way that it cannot support multiple databases. In the /etc/apparmor.d/usr.sbin.slapd file it says:

# the databases and logs
/var/lib/ldap/ r,
/var/lib/ldap/* rw,

The single * means everything except when it contains a / (excluding subdirectories). So in order to support multiple LDAP databases, one needs to rewrite the /var/lib/ldap/* rw entry as:

/var/lib/ldap/** rwk,

This will grant read/ write access to slapd on this directory and all subdirectories thereof. Another thing that I had to do is appending the k to rw, in order for slapd to be allowed to lock files as well (I got audit messages complaining about operation="file_lock"). After a restart of AppArmor, e.g. "/etc/init.d/apparmor restart", it is now possible to start slapd again and have multiple databases, e.g. /var/lib/ldap/database1, /var/lib/ldap/database2, etc.

Eclipse Ganymede ECF review

This post is one of a number of reviews of the Eclipse Ganymede release. It has been added to the Ganymede Around the World map. Donate and become a Friend of Eclipse!

One of the projects that is part of the Ganymede simultaneous release is the Eclipse Communication Framework (ECF). I had never done anything with it before, so writing a review is a great chance to actually do something with it. The update site for getting is ECF is:

http://download.eclipse.org/technology/ecf/2.0/3.4/updateSite/site.xml

One of the things you will get is a communication perspective. In this perspective, you have the following two buttons, the first one for connecting to an IM provider, the second one for connecting to a collaboration server. In this review I will focus on the XMPP connectivity available under the "Connect to Provider" button. XMPP is the protocol used by Jabber and GTalk, and I happen to have two GTalk users (one is for XMPP testing purposes for some components I made using the Smack API).

The "Connect to Provider" and "Connect Workspace to Collaboration Group" buttons

To connect to e.g. GTalk or another Jabber server, select the XMPP provider. This requires you to enter your user name, the XMPP server and the port number where the XMPP server resides. In the case of GTalk you will only have to enter username@gmail.com. It will then connect to the default port 5222 and authenticate with the given user name.

The "New XMPP Connection" dialog where you can enter the XMPP connection string

Once connected, you will see the the contacts view appear with the list of your GTalk buddies. Double click a buddy and you can happily start chatting from within Eclipse. One of the drawbacks that I see here is the fact that you must be in the communication perspective (or add the communication buttons to your Java perspective). The communication views themselves do not provide buttons for connecting and are just a gray area with some explanatory text. This is something that could be done better I think. I would expect a list of accounts and the ability to add accounts via a context menu in a view, much like the server view of the JEE tooling.

GTalk buddies in the contacts view

There is also no way of automatically connecting (see bug 181510), requiring me to continuously go through these steps in order to connect. Furthermore, the XMPP connect dialog only allows user@host for both the user name (used for authentication) and the server name. I can foresee problems here, as with Jabber/ XMPP the domain used for authentication is not necessarily the server name you connect to.

You can collaborate with your Jabber/ GTalk buddies via XMPP. You can send URL's, screen captures, files, etc. from within the contacts view by right clicking a buddy. Sending URL's via XMPP requires the receiver's permission before it is opened, which is a good thing in case a malicious user were to send out links to malicious websites. When using the ECF collaboration server, there are no such controls in place, causing the web site to immediately appear in the receiving Eclipse.

To share an editor via XMPP, right click in the editor, select "Share Editor With" and navigate to a buddy. The receiver is now asked permission and upon acceptance the shared editor is opened. Changes in one editor are propagated to the other. The following screen cast shows the simultaneous update of the two editors in action (or click here if it does not display):

Click the play button to see a screen cast of the two shared editors being updated in sync

Conclusion

ECF looks promising when using the XMPP provider. It allows you to use your existing IM accounts in Eclipse and provides collaboration features such as shared editors. This comes in handy for distributed teams or in case you deal with home workers (like I do). The ability to connect to your existing buddies and get all these collaboration features inside the IDE is nice.

Now for the bad: The way things are presented is IMO not the best and could use quite a bit of rework. It is usable, just not very user friendly yet. The way XMPP user names and server names are entered might cause problems for some Jabber installs, e.g. in case you have "username@some.group" as user ID and the server name is "myjabberserver.com". ECF uses the Smack API for XMPP connectivity, and that API does not support HTTP proxies yet (a request that is outstanding for quite some time now). This will require you to do some tunneling in case you are behind a firewall. Receiving screen captures does not require permission from the receiver.

Some of these issues are minor, some are not. There is a lot of room for improvement. The project has sparked my interest though, and I will follow its progress and hope to see those improvements in future releases.

Tunneling Eclipse Communication Framework and GTalk with proxytunnel

This article explains how you can use the GTalk connectivity of the Eclipse Communication Framework (ECF) via a HTTP tunnel (e.g. proxytunnel). This might come in handy in case you are behind a proxy that does not allow connections to talk.google.com, port 5222. Furthermore, ECF uses the Smack API, which does not support the use of a network proxy (yet). The article is targeted at a Unix audience.

Let us assume that our remote host to which we will connect using ssh on port 443 in order to setup the tunnel is called tunneltarget (e.g. IP address 1.2.3.4) and that the network proxy is called yourproxy and runs on port 80. Now our ~/.ssh/config would look like this:

host tunneltarget
    ProtocolKeepAlives 30
    ProxyCommand /location/of/proxytunnel -p yourproxy:80 -d 1.2.3.4:443
    LocalForward 5222 talk.google.com:5222

Obviously you will have to replace tunneltarget with whatever alias you would like, /location/of with the true location where you have installed proxytunnel and yourproxy:80 with the true hostname/ IP address and port number of you HTTP proxy. The LocalForward directive opens a socket on localhost that listens on port 5222 and forwards to talk.google.com, port 5222, via the tunneltarget (your ssh server). You can now start the tunnel (where userid is your user on your ssh server):

ssh userid@tunneltarget

Unfortunately this is not enough to be able to sign in to GTalk with ECF. ECF requires you to enter your GMail ID (e.g. youruser@gmail.com) and I think it uses this single string for both authentication and the GTalk server's hostname to connect to. This means that if you enter youruser@gmail.com, you will not be able to connect, and if you use youruser@localhost, you will not be able to sign in to GTalk. I could not get any combination (@localhost, @gmail.com, @talk.google.com) to work.

The only way I got it to work was by pointing talk.google.com to 127.0.0.1 in /etc/hosts. One could setup a "Location" (as it is called in Ubuntu) with specific network settings such as specific hosts file contents for that location. Once talk.google.com is rerouted to localhost, you can use the following connect string to connect ECF with GTalk:

youruser@gmail.com

This is a bit of a kludge, so lets hope the Smack API will have proxy support very soon.

IMSLP has opened again!!

The International Music Score Library Project (IMSLP) has reopened! The IMSLP is a huge database of musical scores that have become public domain. It currently holds more than 16000 musical scores. Although some of the scores are a bit dated, the IMSLP is a great resource to find that music score of that famous composer you always wanted to play. But there are numerous lesser known composers in the library as well, which makes the IMSLP a great place to discover hidden treasures in music.

Just to give a simple example of the vastness of the library, have a look at the Beethoven page! Or the Mozart page! Now that'll keep you busy for a while... This is a highly recommended resource for any musician or student!