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!

First of all, re-install the MacPorts.dmg. After that, check what packages you’ve got installed and activated:

$ port installed | grep -i active

You can save this list by redirecting it’s output via > to any file. Next, clean up the ports:

$ sudo su -
Password:
# port clean all

Next, uninstall *all* installed (even not activated) ports:

# sudo port -f uninstall installed

And last but not least, look at your list, check what software you still need and re-install it:

# port install

You could try to automate the re-installation by something like:

# port install $(cat ./file_containing_list.txt | awk ‘{ print $1 }’ | while read line; do echo -n “$line “; done)

Although I would not recommend it, since you’d like to install different variants on some ports.

Enjoy.

First of all, we defined our scenario. Let’s assume that we’d like to have a cluster of two servers, both running the latest CentOS (5.4), both up-to-date, both using the very same partitioning and both using DRBD and GFS(2). On most SuSE or Debian systems, the installation would be pretty straight-forward: You install the base system, set up the DRBD, format it with some OCFS and make Heartbeat monitor everything. So far so good. On RHEL/CentOS it seems to work a bit different, due to the different tools they’re using. When installing the installation-group “Cluster Storage” for example, yum fetches packages named openais and cman – tools you’ve probably never heard of, when you come form the Debian corner (as I do). But before I describe those in detail, let’s just configure our plain base-installation.

What do we need to do first? What’s one of the most important things on two systems that should run “symmetrically” and have the very same data available, with every change that’s being made every second? Exactly, the time would be one of those things. We need to assure that both systems use the very same time. Mostly, you’ll be using some x86_64 hardware for such setups, where the problems start: On 64-bit hardware, the timekeeping with TSC doesn’t run that perfect, which is why we should just deactivate it and leave HPET do its job alone. After installing ntpd we need to open our grub.conf and add the notsc option to our kernels. It should looks something like this:

===================================================================
RCS file: /etc/grub.conf,v
retrieving revision 1.1
diff -u -r1.1 /etc/grub.conf
— /etc/grub.conf 2009/11/13 13:30:26 1.1
+++ /etc/grub.conf 2009/11/13 13:32:26
@@ -13,9 +13,9 @@
hiddenmenu
title CentOS (2.6.18-164.6.1.el5)
root (hd0,0)
- kernel /vmlinuz-2.6.18-164.6.1.el5 ro root=LABEL=/
+ kernel /vmlinuz-2.6.18-164.6.1.el5 ro root=LABEL=/ notsc
initrd /initrd-2.6.18-164.6.1.el5.img
title CentOS (2.6.18-164.el5)
root (hd0,0)
- kernel /vmlinuz-2.6.18-164.el5 ro root=LABEL=/
+ kernel /vmlinuz-2.6.18-164.el5 ro root=LABEL=/ notsc
initrd /initrd-2.6.18-164.el5.img

Now, we can shutdown the ntpd and set its drift-file to 0.000. After that, simply reboot and check the dmesg for the HPET-lines and of course also check the time on both systems to be identically.

Now, what else should we configure until we start building our actual cluster? Probably, we should take a look into the system-config-securitylevel-tui tool. Depending on what environment you plan your cluster to run in, you either want to open each port by port manually in the firewall and configure your SELinux to allow CMAN/OpenAIS and DRBD to work properly – or you simply turn of those “toys” and configure the network-segment to be secure by itself. It depends to you and I’m not going to write how to reconfigure the firewall or your SELinux-environment. For my tests, I simply turned both off. Especially the combination of CMAN/OpenAIS and SELinux can become pretty tricky, when SELinux runs in any other mode than “Disabled”.

Now, let’s finally please our inner kid and install some software:

# yum groupinstall “Cluster Storage”
…
# yum install drbd83 kmod-drbd83
…

I’ve chosen to use drbd83 since it’s the next stable release and already obsoletes drbd82 in CentOS 5.4 – and drbd is simply just too old. Of course, upgrades might become tricky when using explicitly versioned packages, but on DRBD it’s always a bit tricky, since there could be configuration changes which would have to be implemented manually on future versions.

However, now let’s create the infamous and poorly documented /etc/cluster/cluster.conf. For testing, we could simply use something like this:

<?xml version=”1.0″?>
<cluster alias=”cluster-setup” config_version=”1″ name=”cluster-setup”>
<rm log_level=”4″/>
<fence_daemon clean_start=”1″ post_fail_delay=”0″ post_join_delay=”3″/>
<clusternodes>
<clusternode name=”server-1.cross” nodeid=”1″ votes=”1″>
<fence>
<method name=”2″>
<device name=”LastResortNode01″/>
</method>
</fence>
</clusternode>
<clusternode name=”server-2.cross” nodeid=”2″ votes=”1″>
<fence>
<method name=”2″>
<device name=”LastResortNode02″/>
</method>
</fence>
</clusternode>
</clusternodes>
<cman expected_votes=”1″ two_node=”1″/>
<fencedevices>
<fencedevice agent=”fence_manual” name=”LastResortNode01″ nodename=”server-1.cross”/>
<fencedevice agent=”fence_manual” name=”LastResortNode02″ nodename=”server-2.cross”/>
</fencedevices>
<rm/>
<totem consensus=”4800″ join=”60″ token=”10000″ token_retransmits_before_loss_const=”20″/>
</cluster>

Configuring OpenAIS this way isn’t actually the best way… it’s not even “good”. But for testing (and understanding how stuff works) it should be enough. Those rules expect manual intervention when one of the two server should become unavailable and needs to be brought back into the cluster.

The domain “.cross” is expected to be a hostname.domainname entry within the /etc/hosts of each server and defines the direct cross-cable-connection from one server to another. We need this connection to shrink down network latency and provide a way for OpenAIS and (in this example) also DRBD to directly communicate with each other. A better setup would be to set the heartbeat on top of a serial-line, since it would be most fault-tolerant.

Okay, next. What’s left? Exactly, the actual DRBD – so let’s set it up:

global { usage-count yes; }
common { syncer { rate 100M; } }
resource the-disk {
protocol C;
startup {
wfc-timeout 20;
degr-wfc-timeout 10;
# become-primary-on both; # Uncomment this only after tested!
}
net {
cram-hmac-alg sha1;
shared-secret “i4m501337″;
allow-two-primaries;
}
on server-1 {
device /dev/drbd1;
disk /dev/sdb;
address 10.100.0.1:7789;
meta-disk internal;
}
on server-2 {
device /dev/drbd1;
disk /dev/sdb;
address 10.100.0.2:7789;
meta-disk internal;
}
disk {
fencing resource-and-stonith;
}
handlers {
#outdate-peer “/sbin/handler”;
}
}

This configuration defines our two servers and tells DRBD to use /dev/sdb on both for the actual data. Our meta-disk will be internal and with address we defined – guess what? – the IP addresses of our two servers. Those are the .cross-domain addresses!

Next, we initialize our meta-disks (on both nodes), set our generation identifier, start the actual DRBD service and check the roles it currently runs in:

# drbdadm create-md the-disk
…
# drbdadm — 6::::1 set-gi the-disk
…
# service drbd start
…
# drbdadm role all
Secondary/Secondary

If all those steps succeed, we can try to promote both nodes to primary:

# drbdadm primary all
# drbdadm role all
Primary/Primary

And if this now worked out properly, we can enable the automatic promotion from within our drbd.conf:

# rcsdiff -u /etc/drbd.conf
===================================================================
RCS file: /etc/drbd.conf,v
retrieving revision 1.2
diff -u -r1.2 /etc/drbd.conf
— /etc/drbd.conf 2009/11/13 10:34:23 1.2
+++ /etc/drbd.conf 2009/11/13 15:16:26
@@ -9,7 +9,7 @@
startup {
wfc-timeout 20;
degr-wfc-timeout 10;
- # become-primary-on both; # Uncomment this only after tested!
+ become-primary-on both; # Uncomment this only after tested!
}
net {
cram-hmac-alg sha1;

Great. So we’re set up now? Nope. We’re not. Next, we need to change DRBDs boot order in order for it to work properly with the GFS auto-mounting on boot:

# rcsdiff -u /etc/init.d/drbd
===================================================================
RCS file: /etc/init.d/drbd,v
retrieving revision 1.1
diff -u -r1.1 /etc/init.d/drbd
— /etc/init.d/drbd 2009/11/13 10:57:15 1.1
+++ /etc/init.d/drbd 2009/11/13 10:58:15
@@ -1,6 +1,6 @@
#!/bin/bash
#
-# chkconfig: 345 70 08
+# chkconfig: 345 22 75
# description: Loads and unloads the drbd module
#
# Copright 2001-2008 LINBIT Information Technologies

And let it run on boot:

# chkconfig –level 345 drbd on

Great! So, now we are set up, right? Nope, wrong. We have a running DRBD setup now, but we still lack of a cluster-able file-system. GFS2 is a pretty good choice for such a task, so let’s try to format the DRBD-device on one of our nodes with it:

# mkfs.gfs2 -p lock_dlm -t cluster-setup:mycluster /dev/drbd1 -j 2

Before we can try to mount the device, we need to have OpenAIS/CMAN running, in order to manage our GFS consistency. Let’s start the cman service therefor (on both nodes!):

# service cman start

Starting cman and starting fenced could take several seconds, be patient. If you installed both servers identically and followed this documentation step by step everything should work out just fine.

At last, we can now mount our DRBD device into some folder (on both nodes) and start playing around with our fresh setup:

# mount -t gfs2 /dev/drbd1 /mnt/somefolder

I hope everything worked out for you and I also hoped that this brief summary helped you getting a bit easier into the actual setup of such a cluster setup. Feel free to ask any questions or provide feedback in any form.

Enjoy!

export EZMWLUCENE_HOME=/opt/lucene/server
/usr/lib/jvm/java-6-sun-1.6.0.12/jre/bin/java -Dezmwlucene.home=$EZMWLUCENE_HOME -Djava.io.tmpdir=$TMP -cp $EZMWLUCENE_HOME/ezmwlucene.jar:$EZMWLUCENE_HOME/lib/jetty-6.1.14.jar:$EZMWLUCENE_HOME/lib/jetty-util-6.1.14.jar:$EZMWLUCENE_HOME/lib/servlet-api-2.5-6.1.14.jar:$EZMWLUCENE_HOME/lib/commons-codec-1.3.jar:$EZMWLUCENE_HOME/lib/commons-httpclient-3.1.jar:$EZMWLUCENE_HOME/lib/commons-logging.jar:$EZMWLUCENE_HOME/lib/FontBox-0.1.0-dev.jar:$EZMWLUCENE_HOME/lib/lucene-core-2.4.0.jar:$EZMWLUCENE_HOME/lib/lucene-highlighter-2.4.0.jar:$EZMWLUCENE_HOME/lib/PDFBox-0.7.3.jar:$EZMWLUCENE_HOME/lib/poi-3.5-beta3-20080926.jar:$EZMWLUCENE_HOME/lib/poi-scratchpad-3.5-beta3-20080926.jar net.sourceforge.ezmwlucene.service.EzMwLuceneService

Those two lines can be packed-up within a shell-script, which then gets ran by a proper /etc/init.d-script. For me, it now just works perfectly.

Enjoy!

First of all, let’s have a look at the drive itself. It’s plain. Really plain. No holes, no screws, nothing. How the f*ck shall we open this thing. Let’s take a look under its gum-feet. Nah, not even there. What he hack? So, as it seems, this drive can’t be opened. Wrong! Yes we can!

What do we need therefor?

A cloth, for not scratching the gloss

A strong thread

A modified paperclip

Okay, now we’re all set up. First of all, take the hard drive and turn it upside-down. Place it on the cloth to not scratch its lickable, glossy exterior.

Place it on the cloth

Next, take the thread and try to run it through the holes on the case’s bottom, so that you have something to pull the hard disk out of the case. Now try to bend the sides of the plastic-case out carefully and pull drive out piece for piece. You could also use some credit card or other thin piece of plastic (not metal, it will kill the plastic-borders!) for doing this. Warning, this could cause serious damage to your credit card!

Do the credit card-thing on the front-side, the left- and right-side. When pulled it out some millimeters on each of those side, take all the pieces of your thread and try to pull out the drive to the back (e.g. rotation of 90 degrees around the drive’s back-side). On the back, there’s the button for turning it on and off, so you won’t be able to pull it out vertically. If you’ve successfully managed to pull out the drive, the whole scenario should look similar to this:

Pulled out the drive

Pulled out the drive

Now, you can see the actual hard drive which is mounted to the bottom-part of the whole case. After inspecting the construction you can see that there were to glueing-points or any hooks we broke while opening the drive. This means, that if you’ve done it right, you won’t see that anything ever changed on that drive.

Now, I can finally get myself a 750GB (or even 1TB?) hard-drive and build that in.

Happy trying!

//btw: As you notice, LaCie builds in Hitachi Deskstars on these drives. These drives cost something around 50 bucks nowadays. The complete case is around 90 bucks.

iPod Stand

This evening I saw the bunch of old business cards I still have from my former employer lying on my table, and I was wondering whether to throw the majority away or what else I could do with them. I still have over fifty of these tiny little pieces of carton here and just experimented a bit… and well, this is what I came out with.

I was searching for quite a long time to get some kind of stand for my iPod, since I’m already using it as alarm clock and would also love to have it running the “Flip Clock” App on my bedside table at night. Of course, there are stands for the iPhone and the iPod, but I’m not crazy spending over twenty bucks on a dumb stand. A piece of wood or aluminum, whose only purpose is to hold a device. Not connect it to another device (e.g. your Mac or your stereo) – just to hold it. 

However, maybe you like the idea and try it out yourself sometime.

Enjoy!

So simple. Mac.

conn nat-t
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyingtries=1
keyexchange=ikev2
authby=secret
left=192.168.10.193
leftsubnet=10.1.0.0/24
leftfirewall=yes
right=%defaultroute
rightid=client@example.com
rightsourceip=10.100.0.2
auto=add

We added a new virtual IP (rightsourceip) for the client. The network of this IP will be defined on the server’s configuration. We need this for the whole scenario to work out, even if the client/Roadwarrior is behind a NAT. As rightid (client-id) we use the client’s e-mail address.
Server config:

config setup
plutostart=no

conn nat-t
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyingtries=1
keyexchange=ikev2
authby=secret
left=10.1.0.4
leftsubnet=10.1.0.0/24
leftid=192.168.10.193
leftfirewall=yes
right=%any
rightid=client@example.com
rightsubnetwithin=10.100.0.0/24
auto=add


Here, we also defined the client’s e-mail address as rightid, defined that the right side could be anything (“%any”) and told the server to serve the virtual network 10.100.0.0/24 for the right side. By that, the configuration can be applied to different clients and the actual IP configuration is provided on the client’s side. Yet, I did not find out whether there’s a possibility to set up some DHCP server and provide connecting clients a dynamic address automatically.
However, this setup now also works with Roadwarriors that are behind NATs, what means that the actual setup could look like this:

[roadwarrior]—-[nat]—internet—[nat]—[server]—network

Isn’t this cool?
Enjoy.

We’re in a network (in my example 192.168.10.0/24) and there are two components we focus on: One client (a Linux laptop, 192.168.10.184) and a VMware Server (192.168.10.193). On this server, we have a VMware NAT-Network (10.1.0.0/24), where the gateway is has the 10.1.0.2 and our JumpHost has the 10.1.0.4. The client (our laptop) now wants to be able to simply connect other hosts within our 10.1.0.0/24 network. Besides, it would be nice to have some kind of security in bewteen these connections. So what would be better than using a VPN?

Of course, we could use simple SSH tunnels or some OpenVPN setup – but this would be boring. So, we decide to to use IPsec. In detail, we’re using strongS/WAN to setup the whole scenario.

Now first of all we have two problems: First of all, we have a NAT (from the view of IPsec/IKE: NAT-Traversal) through which we can’t tunnel layer 3 protocols. The only thing we can do, is to teach our VMware Server to forward UDP or TCP ports to Guests.

The second thing that might become a problem is the fact, that we’re not using the IPsec daemon within the VM to distribute another network – instead we are distributing his own network. But however, enough with the talk, let’s do the work.

Thanks to Tobias Brunner and Daniel Röthlisberger, strongS/WAN experienced in 2006 the implementation of the NAT-T feature. This feature, allows to “tunnel” IPsec (a layer 3 protocol) through layer 4 (UDP). So the first thing we need to do, is to tell our VMware Server to forward the UDP ports 500 and 4500 to our JumpHost-VM. After we’ve done this, we can start setting up the strongS/WANs on the client and the JumpHost himself.

In this scenario I used Debian SID on both systems, since Debian’s current stable release provides only an very old version of strongS/WAN. So:

aptitude install strongswan

… on both systems. After that, we open the /etc/ipsec.secrets on both hosts and insert the following line:

%any : PSK "abcdefghijklmnopqer"

Of course, you can replace the key by your own one. After that, we take the ipsec.conf of the client and insert our configuration:

config setup
plutostart=no

conn nat-t
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyingtries=1
keyexchange=ikev2
authby=secret
left=192.168.10.193
leftsubnet=10.1.0.0/24
leftfirewall=yes
right=192.168.10.184
rightsubnet=192.168.10.0/24
auto=add

As mentioned in the title, we use IKEv2. To simplify the scenario, we use the secret we just configured as authentication method. The configuration should be adaptable pretty easy for certificate usage.
On the server we now also insert our configuration into the ipsec.conf:

config setup
plutostart=no

conn nat-t
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyingtries=1
keyexchange=ikev2
authby=secret
left=10.1.0.4
leftsubnet=10.1.0.0/24
leftid=192.168.10.193
leftfirewall=yes
right=%any
auto=add

After restarting both daemons, executing ipsec up nat-t and also ipsec route nat-t you should be able to ping the hosts on our 10.1.0.0/24 network.

The tricky part in this setup is the leftid= parameter in out server’s configuration. Without that option the whole authentication procedure doesn’t work out, because the daemon will complain to not have any configuration for “[192.168.10.184]…[192.168.10.193]” and because of that not let the client connect. The reason for this is, that the client only sees the NAT-Router (our VMware Server, .193) and of course tries to sets up the connection using his IP. The NAT-Router then forwards the requests to the actual strongS/WAN daemon (10.1.0.4) which of course says “Wtf?! I’m the 10.1.0.4, what should I do with this package I received for 192.168.10.193?”. And this where the leftid= parameter comes in.

However, I think the stuff should be more clear now. If there are any questions left, feel free to ask. Enjoy!

Anyway, so that’s actually the whole setup.

hosts: files dns
networks: files

protocols: db files
services: db files
ethers: db files
rpc: db files

netgroup: nis

Btw: Don’t forget to put your secret into /etc/pam_ldap.secret! Anyway, let’s go on…
/etc/pam.d/common-account:

account sufficient pam_unix.so
account sufficient pam_ldap.so
account required pam_deny.so

/etc/pam.d/common-auth

auth sufficient pam_unix.so
auth sufficient pam_ldap.so use_first_pass
auth required pam_deny.so

/etc/pam.d/common-password

password sufficient pam_unix.so nullok md5 shadow use_authtok
password sufficient pam_ldap.so use_first_pass use_authtok md5
password required pam_deny.so

The common-session doesn’t need to be changed on the setup we need. Now, edit /usr/share/migrationtools/migrate_common.ph and change the domain to yours. With the tools (migrate_base, *_passwd, *_group) contained in that directory you can migrate your actualy existing /etc/passwd and /etc/group to your ldap. Or you just create these entries manually. However, now let’s load the apache modules:

a2enmod ldap
a2enmod authnz_ldap

… and reconfigure our WebDAV VirtualHost:

...
DAV On
AuthType Basic
AuthName "WebDAV"
AuthBasicProvider ldap
AuthLDAPURL "ldap://127.0.0.1/ou=people,[your base here]"
AuthLDAPRemoteUserIsDN off
ForceType text/plain
Require valid-user
Require ldap-filter &(uid=*)
...

And last but not least, let’s restart all servics:

/etc/init.d/slapd restart
/etc/init.d/nscd restart
/etc/init.d/apache2 restart

Voila! The authentication of your WebDAV against LDAP should be working now. Now the only thing that’s left to do, is to remove the user www-data from the shadow group again. And maybe you’d like to change your LDAP-user’s passwords:

ldappasswd -x -D cn=admin,[your base here] -W uid=[username],ou=people,[your base here] -S

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

SSLEngine On
SSLCertificateFile /etc/apache2/ssl/my.serv.er.crt
SSLCertificateKeyFile /etc/apache2/ssl/my.serv.er.key
DocumentRoot /var/www/
<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>

ErrorLog /var/log/apache2/error.log
LogLevel warn
CustomLog /var/log/apache2/access.log combined
ServerSignature On
</VirtualHost>

The certificate-folder needs to be created and the certificates need to be generated:

~# mkdir /etc/apache2/ssl
~# openssl genrsa -out /etc/apache2/ssl/my.serv.er.key 1024
~# openssl req -new -days 365 -key /etc/apache2/ssl/my.serv.er.key -x509 -out /etc/apache2/ssl/my.serv.er.crt

Next, we add the WebDAV/PAM settings to our SSL-VHost, while /home/pub is the folder we’d like to publish:

...
DAVLockDB /var/lib/apache2/DAVLockDB
Alias /pub /home/pub/
<Location /pub>
DAV On
AuthType Basic
AuthName "WebDAV"
AuthPAM_Enabled On
#AuthPAM_FallThrough Off
AuthUserFile /etc/shadow
ForceType text/plain
Require valid-user
</Location>
...

And last but not least, we (unfortunatelly) need to add the user www-data to the group shadow:

adduser www-data shadow

Now we can restart our Apache and enjoy the pleasure of WebDAV. If it should not work, check the permissions you set for the directory you’re publishing.
And what could this be used for? For example, as self-made iDisk.
Enjoy.

My Idea of the Perfect Terminal-Server Infrastructure. Click to download the PDF.

Some time ago I was involved in a project at work that made me think a bit about the infrastructure companies use and how they could look like, in a perfect world. It became clear, that many companies tried and still try to move their infrastructure to free software – modern web-services with Apache and Mono, virtualization with Xen (at least before Citrix was there), desktop-virtualization with VirtualBo…errr.. Sun’s xVM, and so on. Unfortunatelly, these things actually do not bring many advantages to the end-user but maybe giving them a better feeling because of not-throwing monopolists the company’s money into their throats. The fact is, that the low-brow-user doesn’t really care or even see whether there’s a KVM or a VMware running as host for the server he’s just working on. So, how about bringing free software to the enterprise desktop? I’m not talking about buying a SLED license-box. I’m talking of opensource service on which end-users can actually do their daily work.

Correct me if I should be wrong, but as far as I noticed nowadays Citrix is one of the widest spread solutions when it comes to terminal-servers – how should it be else as inventor of the Independent Computing Architecture. And of course, there are good reasons why Citrix covers the market in that area: it is a great product which allows many different users to work at the same time on one (or more) Windows Servers and, besides of that, also supports redundancy – what is the non-plus-ultra when it comes to enterprise. And in theory, everything works out great with no SPF (Single Point of Failure) and the highly compressed ICA protocol allows comfortable working, even over thin lines. Though, in practice, it doesn’t work out as smooth as it’s read in the brochure. For example, I don’t like how redundancy is being solved in the ICA/Citrix Terminal-Server solutions. In my opinion, the client’s configuration is not the place to store what terminal-servers are available, and it should not be left to the client to decide to which it connects. As soon as you slacken your infrastructure and allow employees to connect using clients on their own managed workstations, you lose control about the redundancy configuration and what is more important, you also lose control about load-balancing. When an employee only configures one terminal-server, the client will always connect to this one, regardless whether it’s fully crowded while the second one is twirling one’s thumbs.

Besides, I find it pretty hard to administer two or more identical Windows Servers, since the installation-routines of each tiny little software under Windows works in a different way than the others before. You can’t just Keyboardcast each installation-command to each of the two (or how many Terminal-Servers are being used) Servers and verify that everything installed fine afterwards. I’m not saying that a Unix or a Linux is the perfect Terminal-Server, but in my opinion a Windows is really hard to manage – and more than one are a disaster. Of course, there are tools and services which provide you the feature of distributing a software onto many windows machines “with one click“, but usualy they require some pre-configuration and testing, until it works out really smooth. What, in the end, costs more time (and by that also money) than just executing the according aptitude, zypper or yum command on each of the <variable> servers.

My idea was, to set up the whole terminal-server infrastructure that’s usually provided by some Citrix Metaserver Product (or whatever) using simple and free tools. In this example, I based the whole scenario on Linux as server system and NoMachine as desktop protocol. In my opinion, NoMachine isn’t perfect (in no way, never), but it definitely is the best opensource-equivalent to ICA that’s available nowadays.
Unfortunately, you can’t make up an enterprise-ready terminal-server solution just by taking these two (Linux, NoMachine) products and throw them together. For example, the setup would be totally missing the one thing I just complained about before at Citrix’s solution: Redundancy. NoMachine (short, NX) itself is no terminal-server solution, just to clearify that. And it’s not described like that anywhere. NX provides remote desktop access over very thin lines with comfortable quality and speed. Period. And this explains why the redundancy of NX is quite limited. But let’s go into greater detail:

When a NX Client connects to a remote desktop, the machine running that desktop usually contains of three core services: One NX Server, one NX Node and one SSH daemon. The Client connects to the SSH daemon using a special NX-user and the SSH key that has been exchanged at the installation. From there, it authenticates against the NX Server using the credentials passed to the NX Client. If the authentication succeeds, the NX Server then forwards the connection to the NX Node, which does the actual desktop management (starting the GNOME or whatever desktop and transmitting the information to the client, etc.).
NoMachine now supports the nice feature of redundancy and load-balancing between the NX Server and the NX Node(s). For example, you could outsource the NX Node service on another machine, then clone that machine (of course, change things like the IP, Hostname, etc.) and afterwards configure the NX Server to forward connections to the newly created NX Node-Machines. The NX Server then decides where each client connects to, by paying attention to the load of each node and periodically checking its availabillity. So, if node A would already run one connection, the NX Server would send the second incoming client to node B. If node A would break down, the Server would notice that and send newly incoming connection only to node B, until it “sees” node A online again.

Now, with these informations in mind we could already create a very simplistic Linux/NoMachine Terminal-Server. But, as I was saying before, we would be missing full redudancy. In the described scenario, the NX Server would be our SPF, and we could not change that since the NoMachine configuration doesn’t provide such a feature. It would not even be possible to provide it – unless we add one more service in between the client and the server. And this is what I’ve done in the scenario I made up (see the picture, click to download the PDF). I called that service the “Rendezvous NoMachine Proxy”, because it uses the zeroconf services to communicate with the clients. Like I said at Citrix’s solution before, I don’t like configuring the available terminal-server statically within each client – of course, it doesn’t bring complexity, but it brings many other disadvantages. However, the RNP would contain a list of all available NX Servers and be able to dynamically decide whether a client is allowed to connect to one specific server or not (-> implementation of simple ACLs). The clients would use Zeroconf to find all available RNP servers and randomly take one to ask for an NX Server to connect to. The RNP would then check the NX Servers’ statuses and by that decided which server to return to the client. The client would then continue the regular procedure of authenticating against the NX Server and pass over to the NX Node, if successful.

But what are the actual advantages of this idea? Okay, to summarize them up: First of all, the whole solution would have complete redundancy. Each service would be available two or more times. The second advantage of this built-up is, that by using an extra service (RNP), the NoMachine software itself doesn’t need to be modified or even rewritten. The only modification that’s needed to be done would affect the NX Client. Instead of just connecting to the IP given in the configured session, the client would need to ask for an NX Server IP through the RNP before the regular login procedure could be started. And this would just need a hook and no modification of the whole client that would make it unmaintainable. The NX Node/Server components already provide configurable hooks for scripts that get executed before the actual connection starts, so it should not take more than a feature-request for that to get implement into the client, too.
However, another big advantage would be the centalization of the actual remote desktop services and the outsource-abillity of the clients. For example, the NX Servers and Nodes would be located centrally at a datacenter, while the clients could be located in many different places, subdivided in little groups. At each place at least two RNPs should be running, which check where the clients are allowed to connect to. So, to visualize the scenario a bit: The group sitting in Boston is responsible for development. A Client wants to connect and asks one RNP for a NX Server address. The RNP then notices that it’s a developer who requests a NX Session, so he will look up his ACL and summarize the NX Server to which a developer is allowed to connect. Then, the RNP checks the NX Servers’ statuses and returns a session-configuration to the client which is then used to connect.
From the group based in Miami and responsible for finances, some employee requests a terminal-server session. Again, the RNP there looks up what NX Servers are configured and where the guy’s allowed to connect to and returns the session-configuration.

There are many more advantages of such a built-up. To detail each would take me too much time and just flood this Blog entry, heh.

At last but not least, there’s one part I didn’t mention up to now: The “Internet”-area displayed in the PDF. That one contains of two Citrix Windows Terminal-Servers. Now you might be asking.. wtf? I thought we wanted to opensource and crap?!… well. In a perfect world, the last portion of the document wouldn’t be needed. But in real life, Windows is an important part and in the majority of cases it can’t be just be cut out of the infrastructure. As long as companies need to work with solutions like SAP or other Windows-Only software it is not possible to get rid of it. And this would be the only neat possibility of combining both worlds, in my opinion.

However, feel free to comment on my idea, improve and even try to implement it. I would really like to see this (or something similar) working someday. It shouldn’t be pretty hard to build the needed service and make the modifications needed for this to work.

Btw: The theming documentation on Splashy is crap! I’m searching for a way to include an animated GIF into my Splashy-theme for two hours now and can’t find anything about that. *grml*

http://www.youtube.com/watch?v=8I8f2xLnJzg

PS: I’ve uploaded some photos of my construct, you can find them in my gallery.

First of all: You cannot tunnel RDP directly through a proxy. RDP doesn’t speak any HTTP(S) to make the proxy connect to the RDP-Server or anything else. So you’ll need an application, that surrounds this RDP datachannel with HTTP, prefferable HTTPS. I found prtunnel for my Mac on DarwinPorts. This software allows you to tunnel anything you want through an http/socks proxy by connecting to the proxy, making it connect (by sending HTTP commands) to the preffered host and open a local port for the application (e.g. rdesktop) to connect. Good, so let’s connect using prtunnel to myrdpmachine.com:3389 and be happy! – NAH. As soon as you’ll try that you’ll see that it’s not that simple. Most http-proxies do not allow CONNECTs to other ports than 80/443. So you can either set up your RDP daemon to use that port – never found that option in Windoze – or you can use an SSH jumphost, since it’s pretty simple to change the SSH port to 443. So, you connect with prtunnel to your SSH machine on port 443, where the SSH daemon runs, open an SSH tunnel through that machine to the myrdpmachine.com port 3389 and connect with your RDP client on localhost:. Okay, let’s stop the theory and begin with the practice:

Open three terminals and execute the following command on the first one:

prtunnel -V -t http -H 'proxy address' -P 'proxy port' \
'port on local machine' 'remote host to connect to over proxy' \
'remote port, put SSHd on 443'

Then, terminal #2 gets the following command: ssh -L’local tunneling port’:'destination host’:'destination port’ -p ‘local port to connect to, the same given at prtunnel’ ‘user’@localhost
After that you can hapily run your rdesktop localhost:’local tunneling port’ and start RDPing. To make the stuff even more clear, here a concrete example:

prtunnel -V -t http -H 192.168.111.2 -P 3128 13337 192.168.111.3 443
ssh -L13338:192.168.111.24:3389 -p 13337 root@localhost
rdesktop localhost:13338

That’s all the magic. Though, you need to pay attention when selecting your ports, because of course only free ports will work and you really should try to keep them higher than 1024 unless you want to become root. Also you need to remember that running an RDP session over HTTP(S) might get the attention of a firewall or whatever monitoring application is available in that network. “Abnormal behaviour” – you’d never get such an 50:50 up- and downtraffic unless you run some peer-2-peer application or remote desktops.

But of course you can modify the commands and use it to be able to connect to let’s say Jabber from a network where only 80/443-outgoing is available – all you need is a jumphost.

And abracadabra, your Smeg menu editor is installed and can be run by executing /usr/bin/smeg.
Have fun while editing your menu!

NOP sleds (“No Operation sleds”) are big arrays (or “sleds”) which contain a defined number of NOPs, a shellcode and an return address. Some of you may now ask, what “NOPs” are. Well, “NOPs” are nothing more than Null-Operations (Hex-Value: 0×90) which on a x86 architecture do… well… just nothing. On the Sparc architecture for example, NOPs are used for instrucation-pipelining.
So, however, to make things a bit clearer let’s take a closer look to the built-up of a NOP sled:

While executing such an array, the EIP (“Extended Instruction Pointer”) will be set to the start of the sled. Then, he just executes every NOP and increments by one, what means that he keeps moving on forward to the shellcode. When he arrives there, the EIP executes the shellcode and returns after that to the return address given at the end of the sled. This whole thing may sound pretty complicated for a novice, but it really isn’t. Let’s make it clearer by using an example programm:

The code can be compiled with the following command line:

After that, the executable needs to be set to the owner “root” and made sticky:

Now the real attack starts. By using perl we generate a shellcode and write this into the file “shellcode”:

Then we pass our program the perl-generated NOP sled, followed by the shellcode loaded from our “shellcode”-file and ended by the return address:

Abracadabra, we have root access and we can do whatever we want on the box. But what exactly happend, that we now have root-rights?

• A shellcode has been created, which is made of hexadecimal assembler-code that spawns a new shell.
• A NOP sled has been generated, which has been added for 202 times.
• The return address has been added for 88 times.

Some people may now wonder, where all these numbers come from. Why 202 NOP sleds, why 88 returns addresses? Well, these are no guessed numbers, they are exactly calculated:
The number of bytes in the NOP sled plus the one in the shellcode have to be divisible by four. When the shellcode is (like in our example) 46 bytes long and you would add a NOP sled which is for example only 200 bytes long, then the result of the addition would be 246. The problem is now, that 246 bytes are not divisible by 4, unlike 248 which is. These 2 missing bytes can simply be added to the NOP sled, since the NOP sled itself has no special function which depends its size. Because we now also have to add the return address, we first need to now its length and the number of times that the return address would fit into the buffer till the 600th byte. Our return address is 4 byte long and the free space that remaind averages 352 byte ([size of the buffer] – [size of the NOP sled + size of the shellcode]). Now we divide 352 by the site of the return address (4 byte) and we get 88. So, now we have the number of return addresses we’d have to add at the end.

The exploitation of programs by using the command-line provides more flexibillity which can be a big advantage. For example it questionable if the previous example really needs 600 bytes to exploit the test program. By exploiting with the command-line we can test that pretty fast and simple:

Now, you need to paint the border around your shape. For this, take the color you want to use for your bubble. I used a darken yellow/orange.

After that, we need a gradient on our shape. This gradient should start on the bottom with a darker value of the color we used for our border and end on the top with a brighter value. If you do this correctly, you’ll have the color you wanted to use for your shape in the middle of the gradient.

Now, for the next step you need to copy your shape and paste it into your document. Then, remove it’s border and create a new gradient on it. The gradient should start on the bottom of your shape with white (opacy: 85%) and end at about 75% of your shape with complete transparency. After you have created this gradient, move your pasted shape exactly onto your basic shape.

After you’ve done that, the hardest step begins. You need a shape which looks on it’s top like the top of your basic shape but which is around 25% of it and ends at the bottom like a box with rounded corners. This kind of shape you can create on two ways: You create a new box with rounded corners and form the top of it the way you need it, or you copy your shape, cut it after 25% from the top and then, round the corners. You must decide how you do this, it’s better to look first, how the easiest way would be.
After we got our new shape, we need another gradient. Now the gradient starts on the top with white (opacy: 90%) and ends on the new shape’s bottom with white (opacy: 20% or 10%). Then, move the shape to the top of your basic shape.

Yay, now you’re done and your lickable plastic speech-bubble is ready for usage! This principe works with every kind of shape and every kind of colors. You easily can change your shape’s color by changing the gradient- and bordercolor of your basic shape.