OTRS as a product is pretty cool and full of features, unfortunately from a technical aspect it’s pretty much of an unaesthetic “Perl hack” that’s, especially when you should try to integrate it into your existing environments and make it talk to your RADIUS or directly to your LDAP. Here, I would like to describe the basic configuration to get the latter working without any troubles.

Everything actually starts within the $OTRSHOME/Kernel/Config.pm. After you’ve set up your Apache to get you displayed the /otrs/index.pl and /otrs/customer.pl you’ll need to start hacking Perl in OTRS’ “config file”.
Let’s say, that we would want to authenticate against LDAP. And maybe not only for the agents (the people using index.pl) but also for the customers. So, let’s assume that we’re having a LDAP-tree containing our Base (“dc=something,dc=com”) and our “Users” OU (“ou=Users,dc=something,dc=com”). Also, we have a “Groups” OU (“ou=Groups,dc=something,dc=com”). I think that’s probably the most common built-up, regardless what names the OUs actually have.

Now, first of all, we need to know what user we could use to authenticate on our LDAP later and get the information we need. Here, I’m assuming it’s “cn=admin,dc=something,dc=com”. Let’s begin with the configuration for getting the agents authenticated:

    $Self->{'AuthModule'} = 'Kernel::System::Auth::LDAP';
    $Self->{'AuthModule::LDAP::Host'} = 'localhost';
    $Self->{'AuthModule::LDAP::BaseDN'} = 'dc=something,dc=com';
    $Self->{'AuthModule::LDAP::UID'} = 'uid';
    $Self->{'AuthModule::LDAP::GroupDN'} = 'cn=otrsagent,ou=Groups,dc=something,dc=com';
    $Self->{'AuthModule::LDAP::UserAttr'} = 'UID';
    $Self->{'AuthModule::LDAP::AccessAttr'} = 'memberUid';
    $Self->{'AuthModule::LDAP::Params'} = {
        port => 389,
        timeout => 120,
        async => 0,
        version => 3,
    };

The configuration should be pretty self-describing, though let’s sum it up: We’re connecting to the LDAP host “localhost” (since we probably tunnel the SSH port to the OTRS machine or have it running directly on that one – else you’d just need to specify another hostname/IP. BEWARE: When using an external LDAP with no tunnel you should use LDAPS!) and use our BaseDN. We define the user-id field being named “uid”, just like the user-attribute we’re going to look-up and we’ll be using the memberUid as access-attribute. Wait. memberUid? I lost you, right?

In this configuration, we’re also using a GroupDN that actually lets us “filter” which of our users might be allowed to use the OTRS as agents. For this, we’re accessing the group “otrsagent” within our “Groups”-OU and lookig up the memberUids.
At last but not least, the actual LDAP parameters like the port for example.

Now, you can test your login by browsing to your index.pl and enter the credentials of an LDAP-user being in your otrsagent-group. You should now be possible to authenticate. Nothing more. You won’t be able to login to your OTRS yet. Why? It’s simple: OTRS uses LDAP only for authentication but initially copies the user-data from LDAP into its own database backend. Therefor we need to set up the “AuthSyncModule”.

This module allows us to tell OTRS that we’d like to have our user data being synchronized with the LDAP database. Let’s take a look at the actual configuration:

    $Self->{'AuthSyncModule'} = 'Kernel::System::Auth::Sync::LDAP';
    $Self->{'AuthSyncModule::LDAP::Host'} = 'ldap://localhost/';
    $Self->{'AuthSyncModule::LDAP::BaseDN'} = 'dc=something, dc=com';
    $Self->{'AuthSyncModule::LDAP::UID'} = 'uid';
    $Self->{'AuthSyncModule::LDAP::UserAttr'} = 'UID';
    $Self->{'AuthSyncModule::LDAP::AccessAttr'} = 'memberUid';
    $Self->{'AuthSyncModule::LDAP::SearchUserDN'} = 'cn=admin,dc=something,dc=com';
    $Self->{'AuthSyncModule::LDAP::SearchUserPw'} = 'swordfish';

    $Self->{'AuthSyncModule::LDAP::UserSyncMap'} = {
        UserFirstname => 'givenName',
        UserLastname  => 'sn',
        UserEmail     => 'mail',
    };
    $Self->{'AuthSyncModule::LDAP::UserSyncInitialGroups'} = [
        'users',
    ];

Again, from top to bottom: We tell OTRS what LDAP host, what BaseDN, what UID/UserAttr/AccessAttr, what search user and what password to use. Then, we need to define what’s needed to be synchronized. Here, we only sync the most important data: First name, last name and e-mail. Note: Without the mail entry this won’t work!
After that, we define what OTRS-groups the user should initially be in.

Now you should be able to authenticate and login with your LDAP user.

Next, customer authentication.

The customer authentication needs to be configured separately and also starts with basic LDAP information:

    $Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::LDAP';
    $Self->{'Customer::AuthModule::LDAP::Host'} = 'localhost';
    $Self->{'Customer::AuthModule::LDAP::BaseDN'} = 'dc=something,dc=com';
    $Self->{'Customer::AuthModule::LDAP::UID'} = 'uid';
    $Self->{'Customer::AuthModule::LDAP::GroupDN'} = 'cn=otrscustomer,ou=Groups,dc=something,dc=com';
    $Self->{'Customer::AuthModule::LDAP::UserAttr'} = 'UID';
    $Self->{'Customer::AuthModule::LDAP::AccessAttr'} = 'memberUid';
    $Self->{'Customer::AuthModule::LDAP::SearchUserDN'} = 'cn=admin,dc=something,dc=com';
    $Self->{'Customer::AuthModule::LDAP::SearchUserPw'} = 'swordfish';
    $Self->{'Customer::AuthModule::LDAP::Params'} = {
        port => 389,
        timeout => 120,
        async => 0,
        version => 3,
    };

I think I don’t need to comment this section once again. Next:

    $Self->{CustomerUser} = {
      Name => 'LDAP Datasource',
      Module => 'Kernel::System::CustomerUser::LDAP',
      Params => {
         Host => 'localhost',
         BaseDN => 'dc=something,dc=com',
         SSCOPE => 'sub',
         UserDN => 'cn=admin,dc=something,dc=com',
         UserPW => 'swordfish',
         Params => {
            port => 389,
            timeout => 120,
            async => 0,
            version => 3,
         },
      },
      CustomerKey => 'uid',
      CustomerID => 'mail',
      CustomerUserListFields => ['sn', 'cn', 'mail'],
      CustomerUserSearchFields => ['uid', 'cn', 'sn', 'mail'],
CustomerUserSearchPrefix => '',
       CustomerUserSearchSuffix => '*',
       CustomerUserSearchListLimit => 250,
       CustomerUserPostMasterSearchFields => ['mail'],
       CustomerUserNameFields => ['givenname', 'sn'],
       CustomerUserExcludePrimaryCustomerID => 0,
       AdminSetPreferences => 0,
       Map => [
           [ 'UserSalutation', 'Title',      'title',           1, 0, 'var', '', 0 ],
           [ 'UserFirstname',  'Firstname',  'cn',              1, 1, 'var', '', 0 ],
           [ 'UserLastname',   'Lastname',   'sn',              1, 1, 'var', '', 0 ],
           [ 'UserLogin',      'Username',   'uid',             1, 1, 'var', '', 0 ],
           [ 'UserEmail',      'Email',      'mail',            1, 1, 'var', '', 0 ],
           [ 'UserCustomerID', 'CustomerID', 'mail',            0, 1, 'var', '', 0 ],
           [ 'UserPhone',      'Phone',      'telephonenumber', 1, 0, 'var', '', 0 ],
           [ 'UserAddress',    'Address',    'postaladdress',   1, 0, 'var', '', 0 ],
           [ 'UserComment',    'Comment',    'description',     1, 0, 'var', '', 0 ],
       ],
    };

This is theoretically the same we’ve also set up for the agents and will let OTRS synchronize the customer data into its own database. I think the whole mapping should be pretty clear when read carefully, so I’m not going to explain every setting in detail.

However, after you’ve hacked together your basic configuration in this kinda way, also the customer.pl authentication should be working against your LDAP.

There’s one more thing that’s left to be mentioned. When you authenticate your agents against the LDAP, OTRS will try to authenticate root@localhost against it – what probably won’t work anymore then. Of course, you won’t need to go without an administrative user now. Simply pick one of your LDAP users, add him to the otrsagent group, log in to the web-interface and then adding an entry into the group_user table of OTRS’ database, containing the user_id of your LDAP user (get it from the “users” table) and the group_id “1″, with the permission_key “rw” and the permission_value “1″. After that, the user should have administrative rights.

And the next time, I’ll show you how to build an automatic back-scratcher using a wall, some glue and a cat. Enjoy!

The actual reason, why I upgraded was KVM. Lenny seems to be getting more and more stable and by that usable as server system. Of course, it’s not etch yet, but since I’m trying to migrate from VMware (-Server) to KVM I’m actually forced to use Lenny. There are no KVM packages available for Etch, besides the ones from Backports.org. Unfortunatelly, even those are only available at version 28-4, what’s not that usable on a productive system.

However, so like I said, today I s/etch/lenny/g on my APT sources.list and ran an aptitude dist-upgrade. I was pretty surprised how fluent the upgrade worked out, the only thing it broke was the Roundcubemail I have installed on the machine for checking the Maildir via HTTP(S). Apache still works fine, Courier also runs, Fetchmail, and all the other stuff I had configured upgraded with nearly no problems.

Unfortunately, the upgrade still caused problems regarding my everyday-work. The most annoying thing is the fact, that I’m forced to use Icedove as mail client from now on, at least until some strange bug regarding the SSL authentication has been fixed in Evolution. The curious thing is, that with the previous version of Courier, Evolution worked just fine. I don’t know, what exactly the Courier developers changed, but it caused evolution to not be able anymore to authenticate against it. Some might say, it sounds like an Courier bug, but to be honest, I know how things are being implemented into Evolution and I don’t believe it’s Courier’s fault.

It’s pretty much a bummer, because I actually liked working with Evolution. Not because it’s fast – it’s not. And not because it’s light – it’s neither. And not even because it works perfectly in the infrastructure I’m sitting in – it definitely did not. But Evolution unfortunatelly is the only mail reader for the GNOME desktop environment, which really integrates into the desktop. I could always take a quick look at the meetings/appointments I have for a specific test, by just clicking the the clock on my menubar. Also, it was integrated into GNOME’s keyring, so that my mail-account password was just getting unlocked after the login.

However, this tiny, integrative features enhanced the usability of Evolution a lot, even if everything else might just suck. Now I’m trying to find out which bugreport documented the problem I’m experiencing, to put myself on CC. I’m really wondering when this will be fixed. If it takes as long as fixing problems regarding shared folders or caldav, then I guess I’ll just try to say Hello! to my future e-mail client Icedove.

Meh.

Don’t get my wrong, I’m not saying that VirtualBox is crap, because it’s not. As OpenSource and “easy to use” desktop-virtualization it is great. You install it, hope that the setup builds you the kernel-modules the right way and just run it. After that you can easily create a new Windows XP guest and just use it over an NAT-interface to communicate with your other infrastructure from within the xVM. But heaven forbit if you’d like to join your xVM Windows XP to a Windows Domain – happy bridging!

VirtualBox is still too much fussing around with Operating System low-levels, what is completely user-unfriendly and doesn’t make things for an experienced person easier.

Still, I’m waiting for KVM to advance.

The kernel version running is the same as the one being installed

You are attempting to install a kernel version that is the same as the version you are currently running (version 2.6.18-6-686). The modules list is quite likely to have been changed, and the modules dependency file /lib/modules/2.6.18-6-686/modules.dep needs to be re-built. It can not be built correctly right now, since the module list for the running kernel are likely to be different from the kernel installed. I am creating a new modules.dep file, but that may not be correct. It shall be regenerated correctly at next reboot.

I repeat: you have to reboot in order for the modules file to be created correctly. Until you reboot, it may be impossible to load some modules. Reboot as soon as this install is finished (Do not reboot right now, since you may not be able to boot back up until installation is over, but boot immediately after). I can not stress that too much. You need to reboot soon.