Monthly Archives: March 2014

Integrate OpenLDAP groups and Gerrit 2.8.3

There had been a few changes regarding group organisation in the Gerrit’s schema after version 2.4, so versions newer than 2.5 will not have the “ldap” type in ls-groups search:

gerrit@continuum $ ssh -p 29418 gerrit ls-groups –type system
Anonymous Users
Project Owners
Registered Users

gerrit@continuum $ ssh -p 29418 gerrit ls-groups –type ldap
fatal: “ldap” is not a valid value for “–type”

This affects the searches in the WebGUI, too, and also implicates that a slightly different organisation of groups is necessary in Gerrit, starting from version 2.5. Tune your [ldap] section for OpenLDAP, so you could use groups from OpenLDAP as groups in Gerrit:

server = ldaps://
sslVerify = false
referral = follow
username = cn=gerritproxy,ou=people,dc=example,dc=com
accountScope = subtree
accountBase = ou=people,dc=example,dc=com
accountPattern = (&(objectClass=person)(cn=${username}))
accountFullName = ${givenName} ${sn}
accountEmailAddress = mail
accountSshUserName =
groupScope = subtree
groupBase = ou=groups,dc=example,dc=com
groupPattern = (&(objectClass=groupOfNames)(cn=${groupname}))
groupMemberPattern = (member=${dn})

If the groups are read, once you start typing the name of the group from OpenLDAP, prefixed by “ldap/…”, the group name completion will be offered by Gerrit, just like it is for internal and system groups:

Screenshot from 2014-03-31 06:09:31

With this, the groups should be usable through Gerrit, and the only problem I found with version 2.8.3 is inability to somehow pull and populate the username from any of the OpenLDAP data, thus the accountSshUserName had to be unset (as can be seen above on the excerpt from the gerrit.config) so the user has to set it on the first log-in. Otherwise, no “account_external_ids” would be written in the database, and the user couldn’t use ssh and https access, even with the rest of the data in place.


P.S. if you play with asterisks, as discussed here, make sure you actually made what you intended: asterisks in Gerrit’s searches are happily expanded to the max, allowing everyone do everything, which is hardly acceptable!

Prepare Eclipse for

There are a few things that should be done before Eclipse is ready for communication with The http.sslVerify = false directive shoud be add in ~/.gitconfig, either directly editing ~/.gitconfig:

vanja@ip:~> grep -B 1 sslVerify ~/.gitconfig
sslVerify = false

or changing the file using the appropriate tool:

vanja@ip:~> git config –global http.sslVerify false

If a firewall is blocking Gerrit port 29418, and the set up allows only http/https combination, communication with Gerrit can be achieved through a proxy over https. First, log into Gerrit and generate an http password under settings.

I used a Tor/polipo combination to simulate a necessity for proxy here:

vanja@ip:~> netstat -an -A inet | grep LISTEN | egrep ‘9050|8123’
tcp        0      0*               LISTEN
tcp        0      0*               LISTEN

and started Eclipse after exporting proxy variables:

vanja@ip:~> cat Scripts/
export http_proxy=”″
export https_proxy=”″
./bin/Eclipse/eclipse/eclipse &

Use http_proxy and https_proxy variables of your proxy there. For the address in Import >> Git >> Projects from Git >> URI menu use:$REPONAME.git

and for user name and password use your LDAP username and the password you generated in Gerrit. Finally, add the commit-msg and set the value of gerrit.createchangeid to true in Eclipse:

Screenshot from 2014-03-28 18:08:51  Screenshot from 2014-03-28 20:23:22

Notice that for test1.git, Eclipse should push to refs/heads/*:refs/for/*

That should be all for initial preparations of Eclipse for Plenty of other settings could be fine-tuned, but the above-mentioned are specific and necessary for Eclipse to reach repos at over https, if ssh is not available.

Self-signed certificates for diaspora pods

Installation of a diaspora pod for OpenBSD 5.4 went rather smoothly, considering the fact that there are still no instructions at Diaspora foundation wiki. I skimmed through instructions for FreeBSD, tried (and gave up on) PostgreSQL and installed with MySQL backend, following rather simple text on installation.

On creation of the first few accounts, a “500 server error” would pop up, but the accounts were accessible immediately after a reload of the front page. At first I thought this was a sign that diaspora’s code is still in its infancy, but I was wrong – it was my admin’s skills that are slowly degenerating: after I reckoned it has to be my mistakes, logs proved that Webrick wasn’t able to communicate with redis over UNIX socket. I changed the connection type to TCP, and the “500 error” was gone.

Adding contacts from another pod was yet another problem. The logs showed that my pod had no trust in other pod’s SSL certs, and kind people on #diaspora channel at explained to me that ‘certificate_authorities’ in config/diaspora.yml should point to a CA cert that people can trust, and my self-signed cert isn’t one of those.

Install p5-Mozilla-CA for OpenBSD and point your ‘certificate_authorities’ there, and you’ll be able to communicate with those who use ‘official’ [sic!] certificates to sign their communications.

Since a cert authority file is not a binary, but a text file, would it work if I simply add another self-signed cert on top of the existing ones, in my CA.pem, and the peer does the same? Probably! I am currently looking for a partner in such a ‘crime’, to test the solutions we can come with regarding the self-signed certificates. Finally, I concatenated my server.crt to Mozilla’s, in hope that it might work. I’ll happily write down the findings here, once I have more on this… annoying bug.

For those willing to try, the cert is here:


Add it to your CA.crt, search for “” and let me know if it worked. If your pod has the self-signed cert, like, remember that I have to add that key to my CA.crt, too, in order to try the workaround.