OpenLDAP default search base

Although it's possible to specify a search base on the client when doing an ldapsearch, it's often nicer if the server can have it set correctly already. I noticed there's an olcDefaultSearchBase attribute for olcDatabase entries, however you can only use it on entry -1, the frontend database. This makes sense, because for one LDAP server instance you can only have a single default search base.

The following LDIF will set the default search base to dc=denc,dc=nl:

dn: olcDatabase={-1}frontend,cn=config
changetype: modify
add: olcDefaultSearchBase
olcDefaultSearchBase: dc=denc,dc=nl

Works like a charm for me!

Recovering from glue objects in OpenLDAP

After some syncing issues and a few transfers of /var/lib/ldap between servers, our company LDAP database had lost it's root organization entry. Doing a slapcat resulted in the entry listed with objectClass glue and all of it's attributes gone. However, this was the same at all of our servers.

The first thing that came to mind to fix this issue was doing an ldapmodify on the entry, however ldapmodify would return ldap_modify: No such object (32). The logical next step would then be to add the object, since ldapmodify complains it's not there... However, that would result in ldap_add: Already exists (68)! Amazing, one program telling me the object can't be modified because it's not there, the other telling me I can't add it because it exists.

I did some searching, but couldn't find a proper solution or anyone with a similar issue. I could of course start from scratch, but that would destroy the sync status, modified timestamp, modifier's name, create timestamp and creators name and perhaps even more, so that wouldn't really be an option in my humble opinion.

During my (re)search I did come across slapadd. slapadd can be used to do offline database edits (at least additions to the database). So I stopped slapd, and fired up slapadd and entered my LDIF... Same issue! The entry exists, so it can't be added. slapadd doesn't seem to support modify either (I'm not complaining, just stating the facts), so I had to figure out something else...

Suddenly I had it all figured out. slapadd and slapcat are similar tools in that they operate directly on the database instead of talking to slapd. Thus if you slapcat your database you can give the output back to slapadd!

# slapcat -n 1 > entries.ldif
# slapadd -n 1 -l entries.ldif

Of course this very simple code example will result in similar errors, because all your entries are already there. Besides, it would also be nice to edit the broken entry while we're at it, which will result in the following list of commands to complete it all (code assumes broken tree is database number 1, replace with your database index if it's not the first database):

1. # cp -ar /var/lib/ldap{,.bak}
2. # slapcat -n 1 > entries.ldif
3. # rm -r /var/lib/ldap
4. # mkdir -p /var/lib/ldap/bdb
   This line assumes a BDB database, you can probably replace bdb with hdb if you're using HDB
5. Now edit entries.ldif so your entry makes sense again. Just fix the objectClass (be sure to create a correct objectClass chain, i.e. top, dcObject, organization), structuralObjectClass and attributes required by the newly set objectClasses (i.e. dc, o).
6. # slapadd -n 1 -l entries.ldif

Now your entry should be back again, with a proper objectClass and related attributes. If you get errors along the way, make sure there aren't more entries with attributes that aren't available in the schema files. Just remove the incorrect attributes (and probably incorrect objectClasses accompanying the attributes) from the LDIF and repeat the database delete and add steps (or remove everything earlier in the LDIF and just add the new entries using slapadd, of course!)

The last step would be to index the database. I don't know if it's required (slapd will run fine without), but before starting slapd run the following:

# slapindex -n 1

Now your LDAP tree should be back to a proper state again!

There's just one issue left... If you didn't change contextCSN attributes, slapd won't sync the entry to other servers because they will all think the entry never changed (and thus the other servers will keep the broken entry). There's an easy solution: just use ldapmodify to change an attribute and the contextCSN will update and the change will propagate to the other servers. The real fix would be to change the contextCSN for the rid of the server you're editing to the current time, however this is more prone to mistakes and the result should be the same (unless using delta syncrepl, where it is possible that only the change will get propagated.)

This was my not-so-short introduction to LDAP disaster recovery without losing contextual information. I'm hoping you enjoyed reading this post and that it helped you to recover from long-standing errors.

Kerberos SSH logins on Mac OS X

As a testing step of our Kerberos / Mac OS X integration I was testing SSH using a Kerberos ticket. At first it didn't seem to work. However, SSH can easily provide some more detailed debugging information, which I could compare with debugging information from a Linux machine which would successfully login with a Kerberos ticket. Turned out GSSAPI authentication is disabled by default for SSH on Mac OS X, you can enable it by editing /etc/ssh_config:

Host *
GSSAPIAuthentication yes

or by passing the option to SSH on every connection:

$ ssh -o GSSAPIAuthentication=yes <host>

Mac OS X and OpenLDAP

At work we had some issues trying to join Mac OS X machines into our Samba Windows domain. Turned out Mac OS X was doing a search with scope base and empty base, which is meant to return some information that can be used for compatibility or some global knowledge about the LDAP tree. This object is the RootDSE object. In our case that search would return nothing, instead of the descriptive entry.

After quite a while we noticed closed bug #427842 on Launchpad. The bug describes some missing access control rules that can lead to this problem. Although this bug is closed, it can still show up when migrating data from an older release, which was also the case for us. The bug also has the required ldif, which I'll copy here for future reference:

dn: olcDatabase={-1}frontend,cn=config
changetype: modify
add: olcAccess
olcAccess: to dn.base="" by * read
olcAccess: to dn.base="cn=subschema" by * read

You can feed this to ldapmodify or ldapadd (yes, ldapadd can also do modifies). A quick ldapsearch will reveal if it worked:

$ ldapsearch -x -b '' -s base

This should return an object of the OpenLDAPRootDSE objectClass (and empty distinguished name).

Now we're at it, let's add another useful gem for Mac OS X: altServer attributes. Mac OS X searches for altServer attributes in order to find other servers that should provide the same data, in case the server is down (although I don't know when this data is cached).

It's possible to add attributes to the OpenLDAPRootDSE object by creating an LDIF file and pointing the olcRootDSE attribute on the config object to the created LDIF file. Create the following file, place it at /etc/ldap/rootdse.ldif:

dn:
altServer: ldap://server2.domain.tld/dc=domain,dc=tld
altServer: ldap://server3.domain.tld/dc=domain,dc=tld

Now add the following LDIF to OpenLDAP:

dn: cn=config
changetype: modify
add: olcRootDSE
olcRootDSE: /etc/ldap/rootdse.ldif

You can add this one using ldapmodify again.

Another quick ldapsearch will verify the attributes are really there:

$ ldapsearch -x -b '' -s base "+"

This should present quite a list detailing some support, including the just added altServer attributes.

Now there's one last thing that we should add to offer our Mac OS X users (or better, ourselves as sys admins!) a more pleasant experience: an Avahi (bonjour/zeroconf) entry for our OpenLDAP server. This will make the server show up as an option in some dialogs, for instance when adding an LDAPv3 directory server for authentication or contacts. To do this, add the following service file to avahi, for instance as /etc/avahi/services/slapd.service:

<?xml version="1.0" standalone='no'?><!--*-nxml-*-->
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">

<service-group>
    <name replace-wildcards="yes">%h</name>
    <service>
        <type>_ldap._tcp</type>
        <port>389</port>
        <host-name>atlas.denc.nl</host-name>
    </service>
</service-group>

The only additional step to integrating OpenLDAP even more with Mac OS X would be by adding the Apple schemas and providing OpenDirectory support using OpenLDAP on Linux. I'll probably come to that later, but one thing I'll definitely post about is authentication against our existing OpenLDAP user tree.

Installing Alfresco 3.3 on Ubuntu Lucid Lynx LTS (10.04)

I happily reused my previous installing Alfresco post to provide you with a new post detailing the setup of the forthcoming Alfresco release on the forthcoming Ubuntu release.

I'm still trying to figure a proper way to format content, but it should be readable at all times.

Note that lines starting with a # (in typable commands) mean they should be executed as root. There's many ways to do this, my advice would be to prepend the commands with sudo. I'm trying to visually distuingish everything you need to type yourself (as opposed to shell output or existing file contents), but I'm human so I will make mistakes every now and then. Quick tip: if you can't write a file from vim because you opened as non-root, use :w !sudo tee % to write the file using sudo.

Start with updating your system:

# apt-get update

Install Tomcat, MySQL and mysql-connector:

# apt-get install tomcat6 mysql-server libmysql-java

Edit /etc/default/tomcat6:

...
JAVA_OPTS="${JAVA_OPTS} -XX:+UseConcMarkSweepGC"
JAVA_OPTS="${JAVA_OPTS} -Xms512m -Xmx512m"
...

In contrary to in Ubuntu 9.04, the Tomcat security manager is disabled by default in 10.04. I guess this means that the security manager is more of a problem than a solution, so I'm already feeling better about not using it.

Create the Alfresco directory tree:

# mkdir /opt/alfresco
# cd /opt/alfresco
# wget http://dev.alfresco.com/downloads/nightly/dist/alfresco-community-war-3.3.tar.gz
# tar xf alfresco-community-war-3.3.tar.gz

You can use something else instead of /opt, but it seems to me this is a desirable location.

I consider myself somewhat experienced with Alfresco, so I'm not downloading the sample extensions...

Create Alfresco database and user:

$ mysql -u root -p < extras/databases/mysql/db_setup.sql

Create Alfresco and Tomcat directories:

# mkdir -p /srv/alfresco/alf_data
# mkdir -p /var/lib/tomcat6/shared/classes

I'm using /srv as data root, I should also move the shared/classes to that location. In my previous guide I used /var/lib/tomcat6/shared/lib/ as base for additional JARs (in this case the mysql-connector), but the default config assumes that these JARs reside in /var/lib/tomcat6/shared/, so I'm not going to deviate from that assumption.

Add links to war files to tomcat webapps:

# ln -s /opt/alfresco/alfresco.war /var/lib/tomcat6/webapps/
# ln -s /opt/alfresco/share.war /var/lib/tomcat6/webapps/

Add mysql connector to path where tomcat finds it:

# ln -s /usr/share/java/mysql-connector-java.jar /var/lib/tomcat6/shared/

Setup Alfresco global settings:

# cp /opt/alfresco/extensions/extension/alfresco-global.properties /var/lib/tomcat6/shared/classes/

Edit the just copied file:

...
#dir.root=./alf_data
dir.root=/srv/alfresco/alf_data
...

It seems that in some cases it's necessary to also include the hibernate dialect in this config file. You can do so by adding the following line:

...
hibernate.dialect=org.hibernate.dialect.MySQLInnoDBDialect

Create the Alfresco extension root:

# mkdir -p /var/lib/tomcat6/shared/classes/alfresco/extension/

This directory is used to override alfresco configuration without changing the deployed WAR.

Setup logging in /var/lib/tomcat6/shared/classes/alfresco/extension/custom-log4j.properties:

log4j.rootLogger=error, File

log4j.appender.File=org.apache.log4j.DailyRollingFileAppender
log4j.appender.File.File=/var/log/tomcat6/alfresco.log
log4j.appender.File.Append=true
log4j.appender.File.DatePattern='.'yyyy-MM-dd
log4j.appender.File.layout=org.apache.log4j.PatternLayout
log4j.appender.File.layout.ConversionPattern=%d{ABSOLUTE} %-5p [%c] %m%n

Make sure permissions are reasonable:

# chown -R tomcat6:tomcat6 /var/lib/tomcat6 /srv/alfresco

Restart Tomcat and enjoy!

# /etc/init.d/tomcat6 restart

Now you should be able to reach Alfresco on [ip]:8080/alfresco and Alfresco Share on [ip]:8080/share.

Ubuntu Lucid on (X86) Mac Mini with EFI

I was gonna use my Mac Mini as replacement home server (uses less power than an idle Core 2 Duo + Geforce 8800GTS + 4 Harddisks), so I decided to put Ubuntu Lucid on it. Installation was really easy. I used the Lucid Lynx Beta 1 Server install CD, and installation went just fine. Press/hold c to boot from CD, be sure to create a seperate boot partition or keep some free space to create a seperate boot partition afterwards.

Just installing Ubuntu is no issue at all. You don't even need to create a seperate boot partition, because it'll boot just fine using the Mac's legacy booter. However if you're a Mac Mini owner and want to boot headless, there is only one solution (and a workaround that uses a 'dummy monitor dongle', which is not what I would want). This solution is making use of the EFI features of GRUB 2, which I'll detail in the rest of this post.

When the installation is done, install hfsplus and hfsprogs so you're able to create HFS+ volumes (you probably only need one of those, but it wasn't exactly clear for me which one to use and due to lack of time I haven't looked any further yet). Copy files from your boot partition to a temporary space, then unmount and format the boot partition as HFS+ (mine is /dev/sda2):

# mkfs.hfsplus -v boot /dev/sda2

Edit /etc/fstab to use the new boot partition as boot partition:

...
/dev/sda2 /boot hfsplus defaults 0 2
...

Unfortunately it seems UUID's can't be used for HFS+ volumes at the moment, so hardcode the device name in there.

After creating the volume mount it again and copy over all the files from your temporary space.

Now install grub-efi, this will automatically remove grub-pc. Generate a GRUB EFI executable using the following command:

# grub-mkimage -o /boot/grub/grub.efi -p /grub part_gpt hfsplus fat ext2 normal sh boot configfile linux

You actually don't even need the fat and ext2 modules and probably more can be stripped, but I haven't experimented with GRUB 2 a lot yet, that'll be for another day (and another post).

We're almost done, now it's on to getting the Mac to actually use our EFI enabled GRUB. First toggle the boot flag on your shiny HFS+ partition. Run parted (or any other GPT-aware partitioning tool) and type:

(parted) set 2 boot off

Parted will probably tell you the disk is in use and you need to reboot for the change to become effective, but it doesn't matter for us.

Now the final step is to tell the Mac (or actually, the filesystem) that our grub.efi is bootable so it'll show up in the Mac boot menu. There should be a utility call hfspbless, which allows you to do this from within Linux, however the first hit on Google doesn't seem to offer a quick guide, so I skipped this part. Instead, put in the Mac OS X install DVD. As soon as a menu bar shows up (I believe you have to click next at least once), fire up a terminal. In the terminal, enter the following:

# mkdir /Volumes/boot
# mount_hfs /dev/disk0s2 /Volumes/boot
# bless --folder=/Volumes/boot --file=/Volumes/boot/grub/grub.efi --label boot --setBoot

The bless command has now set some metadata on the HFS+ filesystem that the Mac uses to identify a native bootable image. I assumed label should set the label accordingly for the boot menu, however my entry showed up as 'EFI something' IIRC, but I can't care more or less since it's a server and I'll never see the menu anyway. Now reboot and enjoy!

This did the job for me, however there are a few issues I still have to take care of. The Mac created a fake MBR partition map for me, which I don't need and don't use. It now shows 'Windows' as option in the Mac boot menu, but luckily it starts Linux by default. Also, the MBR partition map is out of sync if you do stuff with the GPT partition table. I used rEFIt to resync the MBR table, but when I figure out how to remove the MBR that's what I'm going to do.

Also, there's a file called Volume Name Icon on my boot partition. I guess this is used for the Mac boot menu, so it probably can be changed easily too. However I have no clue what the format is, I'll have to look this up some day and change it for a genuine Tux!

Installing Alfresco on Ubuntu Jaunty (9.04)

Some of the information in here comes from http://wiki.alfresco.com/wiki/Installing_Alfresco_Community_WAR_on_Centos_5. Even though the guide is old, most of the information is still correct, albeit some file locations and names have changed and it's written for another distribution.

1. Start with updating your system

   
   # apt-get update




2. Install tomcat and mysql-connector

   
   # apt-get install tomcat6 libmysql-java




3. Edit tomcat startup settings

   
   

   # /etc/defaults/tomcat6
   
   #JAVA_OPTS="-Djava.awt.headless=true -Xmx128M"
   JAVA_OPTS="$JAVA_OPTS -Xms512m -Xmx512m"
   
   #TOMCAT6_SECURITY="yes"
   TOMCAT6_SECURITY="no"
   

   
   Take note of the fact I disabled security, otherwise you need to create a policy file with everything that is allowed in it. I guess it is not that hard, but I wanted to get Alfresco running at all first.




4. Create the Alfresco root

   
   # mkdir /opt/alfresco
# cd /opt/alfresco
# wget http://dl.alfresco.com/release/community/build-2440/alfresco-community-wcm-3.2r2.zip
# wget http://dl.alfresco.com/release/community/build-2440/alfresco-community-sample-extensions-3.2r2.zip
# wget http://dl.alfresco.com/release/community/build-2440/alfresco-community-war-3.2r2.zip
# unzip alfresco-community-war-3.2r2.zip

# mkdir wcm
# unzip http://dl.alfresco.com/release/community/build-2440/alfresco-community-wcm-3.2r2.zip -d wcm




5. Create Alfresco database and user

   
   $ mysql -u root -p < extras/databases/mysql/db_setup.sql




6. Create Alfresco and tomcat directories

   
   # mkdir -p /var/lib/alfresco/alf_data/
# mkdir -p /var/lib/tomcat6/shared/{classes,lib}




7. Add Alfresco and Alfresco share wars to tomcat

   
   # ln -s /opt/alfresco/alfresco.war /var/lib/tomcat6/webapps/
# ln -s /opt/alfresco/share.war /var/lib/tomcat6/webapps/




8. Add mysql connector to path where tomcat finds it

   
   # ln -s /usr/share/java/mysql-connector-java-1.5.6.jar /var/lib/tomcat6/shared/lib/mysql-connector-java.jar




9. Add extension sample files to tomcat

   
   # unzip alfresco-community-sample-extensions-3.2r2.zip -d /var/lib/tomcat6/shared/classes/




10. Setup Alfresco global settings

    
    cp /opt/alfresco/extensions/extension/alfresco-global.properties /var/lib/tomcat6/shared/classes/
    Edit the contents of the file:
    

    # /var/lib/tomcat6/shared/classes/alfresco-global.properties
    
    #dir.root=./alf_data
    dir.root=/var/lib/alfresco/alf_data





11. Add WCM bootstrap

    
    # cp wcm/wcm-bootstrap-context.xml /var/lib/tomcat6/shared/classes/alfresco/extension/




12. Setup catalina loader paths

    
    

    # /var/lib/tomcat6/conf/catalina.properties
    #shared.loader=
    shared.loader=${catalina.base}/shared/classes,${catalina.base}/shared/lib/*.jar





13. Fix permissions

    
    # chown -R tomcat6:tomcat6 /var/lib/{tomcat6,alfresco}




14. Do a first run so the wars get extracted

    
    # /etc/init.d/tomcat6 restart




15. Setup log file

    
    

     # /var/lib/tomcat6/webapps/alfresco/WEB-INF/classes/log4j.properties
    
    #log4j.appender.File.File=alfresco.log
    log4j.appender.File.File=/var/log/tomcat6/alfresco.log





16. Restart tomcat so log settings are re-read

    
    # /etc/init.d/tomcat6 restart

Now you should be able to reach Alfresco on [ip]:8080/alfresco and Alfresco Share on [ip]:8080/share.

Update:
Seems that Alfresco prefers to run on OpenJDK for me, getting out of memory errors when using Sun's JDK. However, if OpenJDK is installed on Jaunty, there's a symlink for rhino in /usr/lib/jvm/java-6-openjdk/jre/lib/rhino.jar, which prevents loading of rhino included in the Alfresco WAR and will result in errors in Alfresco Share (and probably other places too). A # rm /usr/lib/jvm/java-6-openjdk/jre/lib/rhino.jar fixes this.