Having a process that spawns children of itself it can be hard to only find the parents … this command is pretty weird looking, but actually works. You can achieve the same much easier if you want to use ‘ps -ef | grep …’, but I wanted to stick with pgrep, so:

pgrep boe_crprocd.bin | egrep -v "$(pgrep boe_crprocd.bin -P "$(pgrep boe_crprocd.bin -d ",")" -d "|")"

Preparing the DB2 Client

On Windows

After the initial installation, to be able to connect using the command line, just run:

db2cmd -i -w db2clpsetcp

On Unix

Source the db2profile

. $HOME/sqllib/db2profile

Accessing a Remote Database

To be able to access a remote database you have to catalog the node and the database.

db2 "catalog tcpip node remote remote remotehost server 50000"
db2 "catalog database testdb as remotedb at node remote authentication server"

As an example for our internal DB2 test instance:

db2 "catalog tcpip node usphlesx remote usphlesxcab04.pgdev.sap.corp server 50000"
db2 "catalog database sample as cab04smp at node usphlesx"

Once you did that, you can list the open catalogs:

db2 "list node directory"
db2 "list database directory"

To uncatalog the node/database run:

db2 "uncatalog database remotedb"
db2 "uncatalog node remote"
Further reading

Lots of people may know the famous rdesktop bug that keeps you from transferring files from mapped drives on your local machine. The error shown is:

{% highlight bash %}
Path is not accessible. You might not have permission to use this
network resource. Contact the administrator of this server to find
out if your have access permissions.

Attempt to access an invalid address.
{% endhighlight %}

While there is a patch for rdesktop since 2009, it doesn’t seem to make it into the major distributions. At least not into Ubuntu (11.04 as I’m speaking).

So, I’m patching it myself … Here are the steps:

Install all build dependencies

{% highlight bash %}
apt-get build-dep rdesktop
{% endhighlight %}

Get the source package

{% highlight bash %}
mkdir /var/tmp/rdesktop-build
cd /var/tmp/rdesktop-build
apt-get source rdesktop
{% endhighlight %}

Patch it

{% highlight bash %}
sudo patch -p0 </home/user/Downloads/fix-2022945.patch
{% endhighlight %}

Build the package

{% highlight bash %}
cd rdesktop-1.6.0/
sudo dpkg-buildpackage -rfakeroot -b
{% endhighlight %}

Install the package

{% highlight bash %}
cd ..
sudo dpkg -i rdesktop_1.6.0-3ubuntu4.1_amd64.deb
{% endhighlight %}

Done. Now rdesktop is working with Windows Server 2008.

OK, so it skipped the bundle. But why? Alright, diving deeper I had a look at the ‘installd’ process while running the installation:

    # First find the PID
    ps -ef | grep installd
    # Now trace it
    sudo dtruss -p <pid>
    # Now run the installation again

Right, a lot of tracing information. However, 2 files that I was suspicious about:

    open("/var/db/receipts/se.bzero.Vico.plist\0", 0x601, 0x1
         = 5 0
    open("/var/db/receipts/se.bzero.Vico.bom\0", 0x601, 0x1B6)
         = 5 0

Alright, let’s clear them (they were also present in /tmp):

    sudo rm /var/db/receipts/se.bzero.Vico.plist 
    sudo rm /var/db/receipts/se.bzero.Vico.bom
    sudo rm /tmp/se.bzero.Vico.plist 
    sudo rm /tmp/se.bzero.Vico.bom

But not enough, the install still showed the same problem. And even more annoyingly, every installation attempt created the files again … what I had to do was to restart ‘installd’ and the Mac Appstore Management Process ‘storeagent’:

    sudo killall installd storeagent

Now, relaunching the Mac Appstore I could finally install Vico without any further issues …

Given that this was really annoying – it’s also what I love about MacOS. You may have a partly malfunctioning Mac Appstore, an App Developer that may have not payed attention to what files to leave where – but in the end – you get it working. Thanks Apple! And hey – please make the Appstore more of a Mac Experience … soon.

Apple has started its annual Black Friday Sale! The major models (iMac, MacBook Pro, MacBook Air) have the most discounts, however, not the kind of discount you’d wait a whole year for.

I finally ordered myself a Magic Trackpad to make use of all the new multi-touch gestures in OS Lion on my iMac.

The sale is on in (as far as I know) all countries, so not limited to the U.S. and/or UK. So make use of it as long as it lasts!

This morning Thunderbird greeted me with the following Error:

 > [server address:443] uses an invalid security certificate. The certificate is not trusted because the issuer certificate is unknown.
 > (Error code: sec_error_unknown_issuer)

As you see from the port it’s not the IMAP nor the LDAP interface of our internal Exchange Server that’s being accessed, it’s the Exchange Data Provider for Lightning I use.

To trust the certificate (given you know that you want to trust that server) click “Display Certificate” and navigate to the Advanced tab to Export Certificate. You then go to your Thunderbird Settings, Advanced, Security. In the Servers Tab you import the newly exported certificate. Click on it and select Edit Trust to select Trust this server certificate.

Should be sorted! It would really be too easy to place a “Trust certificate” button next to “Cancel” button …

To find out the Bind-DN for your Windows Active Directory User just execute the following from any logged-in Windows Box:

    dsquery user dc=example,dc=com -name user1*

Where example.com is your domain and user1 is your username. Useful if you need a correct Bind DN to connect to the AD LDAP interface or similar.

Also, a good resource can be found at the following Symantec Website

Having my iMac setup for TimeMachine I wanted to do the same for the new Macbook Air. While I don’t want to run around with TimeMachine Backup drive all the time (used to do that for my last MacBook, bad decision) I wanted to setup TimeMachine Backup to my iMac on the same external HDD.

Here’s the link that helped me doing that: Ease Time Machine networked backups

The workflow:

On the iMac
  1. Connect the TimeMachine Drive
  2. Under System Preferences, Sharing share the drive
On the Macbook Air
  1. Connect to the shared drive
  2. Setup TimeMachine to use the drive
  3. Start a backup
  4. When “Preparing backup …” turns into the actual backup, Cancel
  5. Mount the newly created sparsebundle file by double-clicking
  6. Open DiskUtility and select the sparsebundle file
  7. Select the Partition tab
  8. Shrink the size of your Time Machine destination as needed
  9. Click Apply

Alright, now the Macbook Air is backing up to the Disk via the sparseimage file and over the network. Now the tricky part begins. Getting the iMac to backup to a sparseimage file locally won’t work. You have to follow these steps:

On the Macbook Air
  1. Connect the external drive to the Macbook Air
  2. In System Preferences select Sharing
  3. Turn on File Sharing and select the external drive to be shared
On the iMac
  1. Connect to the newly created share and navigate to the Time Machine drive
  2. Open Time Machine preferences and select the Time Machine Share
  3. Let Time Machine create another sparsebundle file for the iMac
  4. Once that’s done cancel the backup again and mount the bundle to shrink it (see top)
On the Macbook Air
  1. Turn off File Sharing to disconnect the drive
  2. Connect the drive to the iMac again
On the iMac
  1. Open Time Machine Preferences
  2. Choose Backup Disk and select the local disk
  3. Happy Time Machine’ing! The sparsebundle on the disk will be used even though it’s attached locally!