Syncing a fork with git/github

  • Configure a remote
    git remove -v
    # git remote add <name> <url>
    git remote add upstream
    git remove -v
  • Pull “upstream”
    # git fetch <name>
    git fetch upstream
  • Checkout the master
    git checkout master
  • Merge “upstream” master to local master
    # git merge <name>/<branch>
    git merge upstream/master
  • (optional) Delete old branch
    # git push origin :<branch>
    git push origin :foobar
    git branch -d foobar


mutt: daily use (still in progress)

Tag messages matching
shift-t -> “search string”

Limit messages matching (pattern)
l > ~T (tagged)
l > ~A (all)
l > ~N (new)
l > ~U (unread)
l > ~F (flagged)
l > “search string”

Random commands
;d > Delete tagged messages
s > Move message
;s > Move tagged messages
b > Bounce messages
w/W > Set/Clear Flag
:source /path/to/muttrc > Reload mutt configuration

“No Java compiler available” on SLES11SP1 and tomcat6

On one of my two sle11 machines i had a java exception which i could not explain.

java.lang.IllegalStateException: No Java compiler available
# rpm -qa tomcat6

Oracle Java JDK 1.6.0_27

After i compared both, i’ve found some missing links on the second one.

# ln -s /usr/share/java/commons-collections-tomcat5.jar /usr/share/tomcat6/lib/
# ln -s /usr/share/java/commons-dbcp-tomcat5.jar /usr/share/tomcat6/lib/
# ln -s /usr/share/java/commons-pool-tomcat5.jar /usr/share/tomcat6/lib/
# ln -s /usr/share/java/ecj.jar /usr/share/tomcat6/lib/

Restart the tomcat and be happy 🙂

openssl with version information under sles11sp1

If you getting errors like this one

$ /path/to/program
/usr/lib/ no version information available

you need a and a with version information.

Here are some information about the problem.

openssl has evolved to a very important library in Linux distribution. A
lot of cryptographic applications link to it including system libraries
like pam modules and apache modules. Now it becomes more and more
difficult to get all the binaries and libraries to link to the same
version of openssl. This leads to situations where an application uses
some libraries where on links to openssl 0.9.7 and another one to
version 0.9.8. Since the symbols of the libraries are not yet versioned
this leads to severe segfaults.

Install source package from the repository

$ zypper in -t srcpackages openssl

Create patches

diff -Naur openssl-0.9.8h/Configure openssl-0.9.8h-new/Configure
--- openssl-0.9.8h/Configure	2008-05-02 01:11:30.000000000 +0200
+++ openssl-0.9.8h-new/Configure	2011-02-22 15:30:05.000000000 +0100
@@ -1327,6 +1327,8 @@

+$shared_ldflag .= " -Wl,--version-script=openssl.ld";
 open(IN,'$") || die "unable to create $$!\n";
diff -Naur openssl-0.9.8h/engines/openssl.ld openssl-0.9.8h-new/engines/openssl.ld
--- openssl-0.9.8h/engines/openssl.ld	1970-01-01 01:00:00.000000000 +0100
+++ openssl-0.9.8h-new/engines/openssl.ld	2011-02-22 15:31:41.000000000 +0100
@@ -0,0 +1,4 @@
+OPENSSL_0.9.8 {
+    global:
+       *;
diff -Naur openssl-0.9.8h/Makefile openssl-0.9.8h-new/Makefile
--- openssl-0.9.8h/Makefile	2008-05-28 10:48:27.000000000 +0200
+++ openssl-0.9.8h-new/Makefile	2011-02-22 15:30:59.000000000 +0100
@@ -140,9 +140,9 @@
 LIBS=   libcrypto.a libssl.a
+SHARED_LDFLAGS=-m64 -Wl,--version-script=openssl.ld

 GENERAL=        Makefile
 BASENAME=       openssl
diff -Naur openssl-0.9.8h/openssl.ld openssl-0.9.8h-new/openssl.ld
--- openssl-0.9.8h/openssl.ld	1970-01-01 01:00:00.000000000 +0100
+++ openssl-0.9.8h-new/openssl.ld	2011-02-22 15:31:48.000000000 +0100
@@ -0,0 +1,4 @@
+OPENSSL_0.9.8 {
+    global:
+       *;


--- openssl.spec	2011-02-22 17:00:26.000000000 +0100
+++ openssl-new.spec	2011-02-22 16:59:58.000000000 +0100
@@ -32,7 +32,7 @@
 Version:        0.9.8h
-Release:        30.30.1
+Release:        30.30.1.custom
 Summary:        Secure Sockets and Transport Layer Security
 Source:         http://www.%{name}.org/source/%{name}-%{version}.tar.bz2
@@ -67,6 +67,7 @@
 Patch26:        bug608666.patch
 Patch27:        CVE-2010-3864.patch
 Patch28:        CVE-2010-4180.patch
+Patch29:	openssl-version-patch.patch
 BuildRoot:      %{_tmppath}/%{name}-%{version}-build

@@ -222,6 +223,7 @@
 %patch26 -p1
 %patch27 -p1
 %patch28 -p1
+%patch29 -p1
 cp -p %{S:10} .
 # lib64 installation fixes
 for i in engines/Makefile; do
@@ -433,6 +435,8 @@

+* Tue Feb 22 2011
+- added for rsa usage the version information.
 * Tue Dec  7 2010
 - fix bug [bnc#657663]

Patch the spec file

$ cd /usr/src/packages/SPEC/
$ patch -i openssl.spec.patch
patching file openssl.spec

Build the new rpm packages

$ rpmbuild -bb /usr/src/packages/SPECS/openssl.spec

Create a shared disk for VMware ESX guests

To create a shared disk between two or more VMs, login into one of your ESX hosts and create a disk image.

cd /vmfs/volumes/#volume-name#/#vm-name#/;
vmkfstools -d thick -a lsilogic -c 50G shareddisk.vmdk;

Add the new hardrive to the guest(s) and select a new SCSI bus (like SCSI 2:0). VMware create a new SCSI controller. Set SCSI Bus Sharing = Physical or Virtual and have fun 🙂

Apache Tomcat & logrotate

Some linux distribution are shiped without a config for the catalina.out (Tomcat application server) 😉

$ cat /etc/logrotate.d/tomcat
/var/log/tomcat/base/catalina.out {
	create 644 tomcat tomcat
	rotate 30
	size 4M

The catalina.out will be rotated after 4 mb and stored for 30 days (/var/log/tomcat/base/catalina.out.1; /var/log/tomcat/base/catalina.out.2.gz and so on)

SLES11, SLES10 SP3, grml64 on HP DL360-G6

Wozu gibt es zertifizierte Hardware(listen), wenns dann doch nicht geht ?

Ein HP DL360-G6 mit einer NetXtreme BCM5709 Netzwerkkarte soll unter SLES10 (SP3) und SLES11 (GM) funktionieren (Quelle: HP und Novell). Aber irgendwie gehts dann doch nicht 🙁 Selbst mit dem HP ProLiant Support Pack (Version 8.30) ging es nicht. Auch die md5sum vom bnx2.ko Modul, die HP angibt, stimmt.

Als letzter Versuch war dann noch grml64 2009.10 (x86_64 & i386) dran, nur leider ging es hier auch nicht. Alle melden nur “Firmware not running. Aborting…” Super! Ich muss leider zugeben, ich konnte auch nicht alles testen z.B. Firmware patchen konnte ich nicht, da es nur eine Leihgabe aus einem anderen Fachbereich war.

Mal sehen wann ich wieder eine in die Finger bekomme….