Migrating calendars from horde to zarafa

Recently I had to migrate a bunch of calendars from horde to zarafa. At the time of this writing (spring 2013) caldav access to horde is still just on the roadmap of horde. So basically, I had to log in for every users and export their calendars to ical files by hand. I named them username.ical.
Fortunatly, importing into zarafa can be automated. After importing a file, I realized that recurring events where off by 2 hours. In the ical files, the times were correct, but after importing them, recurring events startet and ended two hours later. So I had to modify the ical files. I did that with the following python script: Note that I used python icalendar 3.3, which exposed this issue. I made a temporary fix (see link), but with icalendar 3.4 and later this should be resolved.
So after the recurrence timing had been corrected, I imported all ical files with

Postfix: local mail only for some users

If you want to allow some users to send "local" mail only, the following postfix configuration will do the trick. With local I mean within the organisation, for which your postfix is configured to receive mail.

In your smtpd_recipient_restrictions, rather at the top of the restriction list, add

        check_sender_access hash:/etc/postfix/access-sender-local_mail_only,

where the file /etc/postfix/access-sender-local_mail_only contains a list of senders which are restricted:

usera@example.com       localmailonly
userb@example.com       localmailonly
userc@example.com       localmailonly

So here we have defined that these users are subject to the restriction class "localmailonly", which we will have to define:

smtpd_restriction_classes = localmailonly
localmailonly = permit_auth_destination,reject

Here we have defined a new restriction class, and have assinged rules to this class. Namely, we only permit authorized destinations (thats the destinations we accept mail for), and otherwise reject the message. In order for this configuration to take effect, we need to convert /etc/postfix/access-sender-local_mail_only to a .db file, and reload postfix (to read the changes to main.cf):

postmap /etc/postfix/access-sender-local_mail_only
service postfix reload

Check ssl certificates with a shell oneliner

If you want to check the details of a ssl certificate, you can do it with something like this:

for a local certificate file. If you want to check the certificate that specific services servers, use servicename should be a service which translates into a portnumer via /etc/services.

Faster ssh on virtual machines

A problem with virtual machines is that they have trouble finding entropy. Because they have no real hardware to get entropy from, the tend to have rather low entropy availabe. You can check with

 cat /proc/sys/kernel/random/entropy_avail

A typical virtual machine will be in the low hundreds. If this is the case, you will probably frequently experience unusual long waiting times when loggin in with ssh, or even hangs .... This is because the system uses entropy to for the encryption. So because there is not much, it might wait for it to be generated.

Fortunatly, there is a tweek, which will speed up things: rng-tools (props to my fellow Stephan Seitz who explained this to me). It really is meant for gathering entropy from special hardware devices, but can be tweeked to use /dev/urandom. Please note that this will increase the available entropy, but not probably decrease the strength of the encryption. If you are more knowledgeble about this, I would be happy to hear from you.

Here is my setup on a ubuntu 12.04 server: Edit /etc/default/rng-tools, so that it contains

RNGDOPTIONS="--rng-device=/dev/urandom --fill-watermark=90% --feed-interval=1"

 (only that, the rest should be comments). This will tell rng-tools to use /dev/urandom. Now the problem with this is, that the init script will check if the device is a real hardware device. So we need to edit /etc/init.d/rng-tools as well. Find the following line

START="${START} -- -r ${HRNGDEVICE} ${RNGDOPTIONS}"

and replace it with

START="${START} -- ${RNGDOPTIONS}"

Now restart rng-tools, and you should have much more entropy available:

cat /proc/sys/kernel/random/entropy_avail
3968

Switching OpenLDAP from cn=config to slapd.conf

For a project with a client I needed to set up an OpenLDAP server, configured via traditional slapd.conf. Nowadays most linux distros ship their OpenLDAP servers preconfigured with a cn=config style configuration. That is, the server config itself is stored in a seperate branch of the directory. This makes things like replication much easier, but poses a burden on the admin, who needs to learn the new way of configuring OpenLDAP. So, in order to make my client happy, I switched the config style. It took me a little to figure it out, so here I repost my solution:

service slapd stop # stop the service
mv /etc/ldap/slapd.d /root # move the cn=config configuration
cp /usr/share/slapd/slapd.conf /etc/ldap/ # get new sample config
# make changes to sample config so that it can work
sed -i "s/@BACKEND@/hdb/" /etc/ldap/slapd.conf
sed -i "s/@SUFFIX@/dc=acme,dc=org/" /etc/ldap/slapd.conf
sed -i "s/# rootdn/rootdn/" /etc/ldap/slapd.conf
# manually execute "slappasswd" on the command line to generate a root pw
# then add the following line (without "#") after rootdn
# rootpw <crypted password>
sed -i "s/@ADMIN@/cn=admin,dc=acme,dc=org/" /etc/ldap/slapd.conf
mv /var/lib/ldap/* /root # remove old config database
service slapd start # start service again

Further configuration will be nessessary, e.g. TSL configuration and server tuning (make sure to define your indexe attributes). Also, I need to remember to user fqdns in the client request, as I learned from this post.

OpenAM with OpenLDAP as user store (on ubuntu 12.04)

I am using OpenAM 10.0 on ubuntu 12.04. I want to user OpenLDAP as a user store (for the configuration I am using the OpenAM internal store). Unfortunatly, OpenAM does not provide an out of the box plugin for LDAP. Fortunatly, there is a book about OpenAM, and even better, the relevant chapter for integrating OpenLDAP is available for free, together with the nessessary schema.

For your convenience (and my personal documentation), I will show all the steps I took to get things working. First, I downloaded the above mentioned resources from packt publishing.

Setting up OpenLDAP

Bevor installing open ldap, think about the suffix you want your install to have and take apropriate action.

Then install openldap:
 
apt-get install slapd ldap-utils

Then add a suffix and a manager account to the directory:

slapadd -l /tmp/init_suffix.ldif

with the following as content of /tmp/init_suffix.ldif:dn: ou=people,dc=opensso,dc=java,dc=net
objectClass: top
ou:people
objectClass: organizationalUnit
dn: ou=groups,dc=opensso,dc=java,dc=net
ou:groups
objectClass: top
objectClass: organizationalUnit
dn: cn=amadmin,ou=people,dc=opensso,dc=java,dc=net
objectclass: inetuser
objectclass: organizationalperson
objectclass: person
objectclass: top
cn: amadmin
sn: amadmin
uid: amadmin
userPassword: secret124
dn:cn=defaultGroup,ou=groups,dc=opensso,dc=java,dc=net
objectclass: top
objectclass: groupofnames
member:cn=amadmin,ou=people,dc=opensso,dc=java,dc=net
cn:default1

dn: dc=opensso,dc=java,dc=net
objectClass: top
objectClass: dcObject
objectClass: organization
o: opensso
dc: opensso
structuralObjectClass: organization

Make sure you have the dc=java,dc=net set to the values of your directory.

Add the OpenSSO4OpenLDAP.schema as provided by packt (under "Downloads"). You will need to convert it to an ldif file, as has been explained here(read untill the end, it was usefull for me).

Then add some more data:

 ldapadd -Y EXTERNAL -H ldapi:/// -f template.ldif

with

dn: ou=people,dc=opensso,dc=java,dc=net
objectClass: top
ou:people
objectClass: organizationalUnit

dn: ou=groups,dc=opensso,dc=java,dc=net
ou:groups
objectClass: top
objectClass: organizationalUnit

dn: cn=amadmin,ou=people,dc=opensso,dc=java,dc=net
objectclass: inetuser
objectclass: organizationalperson
objectclass: person
objectclass: top
cn: amadmin
sn: amadmin
uid: amadmin
userPassword: secret124
dn:cn=defaultGroup,ou=groups,dc=opensso,dc=java,dc=net
objectclass: top
objectclass: groupofnames
member:cn=amadmin,ou=people,dc=opensso,dc=java,dc=net
cn:default1

in your template.ldif file. Again, make sure your distinguished names (dn) are matching your setup.

Setting up tomcat7

After installing tomcat7 via

 apt-get install tomcat7-docs tomcat7-examples tomcat7-admin\ tomcat7

you need to provide more memory to OpenAM then the default tomcat install on ubuntu does. This is done by creating a script called setenv.sh in /usr/share/tomcat7/bin:

root@tih1:/usr/share/tomcat7/bin# cat setenv.sh
#!/bin/bash

export CATALINA_OPTS="-Xmx1024m -XX:MaxPermSize=256m"

Then the apropriate rights should be set

chmod 755 setenv.sh

chown tomcat7:tomcat7 setenv.sh

Then start (or restart, depending on the previous state) tomcat:

 service tomcat7 start

Note that if you redeploy OpenAM (maybe because you screwed up your setup), restarting tomcat is a good idea. I am not much of a tomcat expert, but when fiddling around I found that restarting tomcat solved a lot of strange problems for me.

Also, in my fresh installation both apache and tomcat were listening on port 8080, and when connection to http://<myserver> , I only saw the default apache page. So I had to configure on of tomcat and apache to listen on a different port. I changed the tomcat port to 8081, which can be configured in

/etc/tomcat7/server.xml

There is a line which reads  <Connector port="8080" protocol="HTTP/1.1"
Which port you choose depends on what you want, there is no specific reason for my choice of 8081 other then making it different from apaches 8080.

Also, check the access rights for tomcat.

Deploying OpenAM

Read the instructions of the official installation guide. Read it carefully, it will save you time and trouble (Skip the section "To Configure OpenAM With Defaults (For Testing)", it won't help with OpenLDAP). Then read on, then execute the deployment.

A few things I found to be different then described: The ports for the configuration store are set to -1, which should be fine according to the offical docs. It did not work on my box, so I assigned random ports above 1023:

Now comes the whole point of this post: Integrating OpenLDAP. For the user store, choose OpenDJ, and enter the data and credentials for your ldap server:

Finish the configuration Dialog, and you should be set up with OpenLDAP as a user store in your OpenAM. In Theory. In Practise, there is a bit more of configuration to be done in OpenAM bevore your ldap users will be ready for use.

Configuring OpenAM

Under "Access Control", "/ (Top Level Realm)","Authentication":

• Under "Authentication Chaining", choose "ldapService", change "DataStore" to "LDAP". Save, and back

If you allready have accounts in your OpenLDAP directory, and can't find them in OpenAM (e.g. "Access Control", "Top level realm","subjects" - should have a listing of your users ), try the following:
"Access Control", "Top level realm","DataStore", there should be a listing of configured data stores. If you followed the steps above, there should be only one called "OpenDJ". This is your OpenLDAP DataStore. Klick it, and scroll down to "User Configuration". At the very end of that section, there are two fields, called

"LDAP People Container Naming Attribute" and "LDAP People Container Value". These probably contain values such as "ou" and "people". Void both.

Make OpenAM reload safe

Allthough its supposed to only happen with JBoss, it also happend with tomcat to me: openam lost its configuration after restart/reload. Follow the steps described in the link to get things back on track, just replace JBoss with Tomcat.

Clarity

These are notes I took over the course of some days. If anything is not so clear, please let me know and I will try to be more accurate.

tomcat7 on Ubuntu 12.04 - access rights need change

After setting up tomcat, I deployed openam. The  initial configuration screen gave me "Configurator does not have write access to /usr/share/tomcat". It turns out that the user tomcat7 (who runs tomcat) has his home in /usr/share/tomcat7 (have a look at /etc/passwd). For some reason (bug?), this directory is owned by root, which made it unwritable for tomcat7. The fix is an easy (as root)

chown -R tomcat7:tomcat7 /usr/share/tomcat7