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 "|")"
After the initial installation, to be able to connect using the command line, just run:
db2cmd -i -w db2clpsetcp
Source the db2profile
. $HOME/sqllib/db2profile
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"
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:
{% highlight bash %}
apt-get build-dep rdesktop
{% endhighlight %}
{% highlight bash %}
mkdir /var/tmp/rdesktop-build
cd /var/tmp/rdesktop-build
apt-get source rdesktop
{% endhighlight %}
{% highlight bash %}
sudo patch -p0 </home/user/Downloads/fix-2022945.patch
{% endhighlight %}
{% highlight bash %}
cd rdesktop-1.6.0/
sudo dpkg-buildpackage -rfakeroot -b
{% endhighlight %}
{% 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 …
If you want to be able to login to your machine using the input devices from your Synergy Server, you’ll have to run Synergy before actually logging in to the machine.
Here’s How to do it.
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
Recently had my CrashPlan Backup stuck in status Waiting for connection. Thankfully I discovered the following support document which resolved it for me (restarting CrashPlan Engine):
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:
sparsebundle file by double-clickingsparsebundle fileAlright, 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:
sparsebundle file for the iMacsparsebundle on the disk will be used even though it’s attached locally!