Endlich. Der viel zu selten benutze Desktop PC lief seit Jahren auf Ubuntu 6.06 (Dapper Drake). Doch seit geraumer Zeit ist bereits Version 8.04 (Hardy Heron) verfügbar. Die Aktualisierung benötigt jedoch etwas Aufsicht. Viele Manuell angepasste Konfigurationsdateien werden (zum Glück) nicht automatisch überschreiben. Leider gibt es keine Option „alle Konfigurationen“ beibehalten. So muss man in geraumen Zeitabständen zur Maus greifen. Ansonsten läuft alles reibungslos. Nur der WLAN-Schlüssel will noch gut verpackt werden.

Wichtiger Hinweis: Nach dem Update auf Hardy Heron funktioniert die Testversion von SAP NetWeaver 2004 nicht mehr. Dies liegt daran, dass die darunterliegende Datenbank MaxDB 7.5.x für den Start die Umgebungsvaraible LD_ASSUME_KERNEL=2.4.1 zwingend benötigt. Diese, ich nenne Sie mal Kernel-Sicht, wird in Hardy Heron nicht mehr unterstützt! Siehe auch Problembeschreibung im Ubuntu-Forum.

Update: Die neuen 2.6er Kernel unterstützen das neuere pThread Modell NTPL (native posix thread library). Die „alte“ LinuxThread-Implementierung ist obsolet. Dies ist der Grund, warum die Angabe LD_ASSUME_KERNEL=2.4.1 nicht mehr funktioniert. Allerdings gibt es ein Update für MaxDB, dessen Support wieder an SAP übergeben wurde. Das MaxDB Update ist über das SAP Development Network beziehbar (MaxDB Community Edition). Nachdem das tar Archiv geladen und entpackt wurde, kann mit dem Tool SDBINST das Update durchgeführt werden (z.B. SDBINST -d sdb -u control,control). Danach ist das Testsystem auf Hardy wieder einsatzfähig. Einziger Wehrmutstropfen: SAP hat das Lizenzmodell für Evaluation Software überarbeitet. Die Ernuerung der Testlizenz für NW4 ist nicht mehr möglich (Hierzu auch der entsprechende Eintrag aus dem SDN Forum).

Meine Diplomarbeit aus dem Jahre 2005 jetzt herunterladen.

SAP vertreibt über den SAP Knowledge Shop ein SAP NetWeaver TestDrive auf DVD. Die entsprechenden Positionen findet Ihr unter SAP Knowledge Shop > General > SAP NetWeaver > SAP NetWeaver. Zügig nach dem Absetzen der Bestellung waren die DVDs auch im Postkasten. Für eine lauffähige Installation auf Ubuntu Linux 6.06 sind allerdings ein paar Vorraussetzungen zu erfüllen. Beachtet man diese nicht, wird die Installation zu einer zeitraubenden Angelegenheit:

Pakete

rpm

Zur Installation der rpm von der Installations DVD wird der Systemfremde Redhat Package Manager (RPM) benötigt, die der Systemeigene Paketmanager synaptic gerne als Alien package manager beschreibt.

libstdc++2.10-glibc2.2

Die alte C++ Laufzeitumgebung wird zwingend benötigt. Das Vorhandensein der neueren Bibliotheken (libstdc++5 oder libstdc++6) reicht nicht aus! Aus Komptibilitätsgründen muss das alte Paket installiert werden!

csh

Einige Skripte des NetWeaver TestDrive sind in CSH Syntax geschrieben, daher ist die Installation der C Shell notwendig.

Java RE (Sun)

Das JRE sollte von SUN kommen und in der neusten Version installiert werden. Das mit Ubuntu ausgelieferte GCJ kann nicht verwendet werden. Nach der Installation des JRE von SUN sollte daher über update-alternatives die Standard-VM auf das JRE von Sun umgebogen werden. 

dialog (Optional)

Wer das mitgelieferte Installationsscript install.sh benutzen möchte, der muss dialog oder kdialog installieren um einfache Fensterelemente aus dem Shellskript anzuzeigen. Bei der Benutzung von dialog ist darauf zu achten, dass das ausführende Shell-Fenster mindestens die Größe 25×80 aufweist.

Locales de_DE.ISO-8859-1 und en_US.ISO-8859-1

Auch dieser Schritt ist zur Vorbereitung der SAP NetWeaver 04 TESTDRIVE Installation unumgänglich, denn SAP verweist auf die Codepages ISO-8859-1 in Englischer und Deutscher Ausprägung. Da Ubuntu 6.06 ein Unicode basiertes System ist, müssen diese Codepages erst entsprechend erzeugt werden:

localedef --no-archive -v -c -i de_DE -f ISO-8859-1 de_DE.ISO-8859-1

localedef --no-archive -v -c -i en_US -f ISO-8859-1 en_US.ISO-8859-1

Obwohl der letzte Parameter laut manpage den Verzeichnisnamen der locale bezeichnet, wird dieser nicht in der angegebenen Form angelegt, sondern in der Form de_DE.ISO88591. Daher muss ein entsprechender Symbolischer Link erzeugt werden:

ln -s /usr/lib/locale/de_DE.ISO88591 /usr/lib/locale/de_DE.ISO-8859-1

ln -s /usr/lib/locale/en_US.ISO88591 /usr/lib/locale/en_US.ISO-8859-1

Installation über Skript vs. Handarbeit

Meine Empfehlung lautet eindeutig die wenigen Installationsschritte von Hand durchzuführen, denn das ausgelieferte Skript wurde für ältere Suse und Redhat Systeme geschrieben und funktioniert nur eingeschränkt. Außerdem werden die CD und DVD Laufwerke unter Ubuntu meist mit der Option noexec gemountet, weshalb mindestens die Kopie des Skripts in das Dateisystem notwendig wird.

1. Einrichten eines Virtuellen Netzwerkknotens

Die NW4 Installation benötigt ein virtuelles Netzwerkinterface auf das später ein vorgegebener Hostname konfiguriert wird, der auf jeden Fall auf eine gültige Lokale Netzwerkadresse zeigt, aber auf keinen Fall auf eine Loopback Adresse! Zunächst die Datei /etc/network/interfaces ergänzen:

auto eth1:0iface eth1:0 inet static  \
address 192.168.100.100  \
netmask 255.255.255.0

Anschließend in der Datei /etc/hosts die Namensauflösung für den Hostnamen nw4host ergänzen:

192.168.100.100 nw4host

Im letzten Schritt muss der Hostname in /etc/hostname auf den entsprechenden Eintrag nw4host abgeändert werden. Dieser Schritt ist notwendig, da aus einem mir bisher nicht bekannten Grund beim Systemstart der ursprüngliche Hostname und nicht der des Virtuellen Netzwerkinterfaces benutzt wird, welcher auf die Loopbackadresse 127.0.0.1 zeigt, was das SAP System auf keinen Fall akzeptiert (Hinweise 520568 und 1054467 aus dem SAP Support Portal).

2. RPMs installieren

Auf der DVD befinden sich vier Packete, die in der angegebenen Reihenfolge installiert werden müssen, wobei das letzte Paket die längste Zeit benötigt (20 Min. einplanen).

1. rpm -ivh --nodeps --force \
/dvd/server/rpms/i386/sapj2ee-srv-sapdb-6.40-2.i386.rpm
2. rpm -ivh --nodeps --force \
/dvd/server/rpms/i386/sapdb-7.5-2.i386.rpm
3. rpm -ivh --nodeps --force \
/dvd/server/rpms/i386/sapdb-db-log-7.5-2.i386.rpm
4. rpm -ivh --nodeps --force \
/dvd/server/rpms/i386/sapdb-db-files-7.5-2.i386.rpm

3. Benutzereinstellungen anpassen

Während der Installation werden drei Benutzer angelegt: nw4adm, sqdnw4, sdb. Alle Benutzer bekommen Standardmäßig die C-Shell zugewiesen. Über die Systemadministration der Benutzer und Gruppen kann dies entsprechend verändert werden. Vorschlag: /bin/bash. Da für den reibungsfreien Systemstart einige Umgebungsvariablen gesetzt werden müssen, muss das Login-Skript für den Benutzer nw4adm angepasst werden:

nw4host> sudo su
Password:
nw4host> su nw4adm
nw4host> vi ˜/.bashrc

Folgende Zeilen ergänzen:

export LANG=de_DE.ISO-8859-1
export LC_ALL=de_DE.ISO-8859-1
export LC_CTYPE=de_DE.ISO-8859-1
# alias for the hostname binary
alias hostname='echo nw4host'
# necessary to get hostname without domain (AIX, OS/390 and NOT sun)
case `uname` in  AIX* | OS/390*)
       alias hostname='hostname -s';;
esac
# SAP environment
if [ -f $HOME/.sapenv_`hostname`.sh ]; then
     . $HOME/.sapenv_`hostname`.sh
elif [ -f $HOME/.sapenv.sh ]; then
     . $HOME/.sapenv.sh
fi
# APO environment
if [ -f $HOME/.apoenv_`hostname`.sh ]; then
     . $HOME/.apoenv_`hostname`.sh
fi
# JAVA environment
if [ -f $HOME/.j2eeenv_`hostname`.sh ]; then
     . $HOME/.j2eeenv_`hostname`.sh
fi
# XI environment
if [ -f $HOME/.xienv_`hostname`.sh ]; then
     . $HOME/.xienv_`hostname`.sh
fi
# RDBMS environment
# @(#) $Id: //bc/640-1/src/ins/SAPINST/impl/tpls/ind/ind/DBSRC.SH#3 $ SAP
if [ -f $HOME/.dbenv_`hostname`.sh ]; then
     . $HOME/.dbenv_`hostname`.sh
elif [ -f $HOME/.dbenv.sh ]; then
     . $HOME/.dbenv.sh
fi
# JREexport LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:\
/usr/local/jre1.6.0_05/lib/i386:\
/usr/local/jre1.6.0_05/lib/i386/server
# MaxDB 7.5 does not support NPTL
# See: http://lists.mysql.com/maxdb/26186
export LD_ASSUME_KERNEL=2.4.1

4. DB Passwordfiles erzeugen

Im Installationsskript befinden sich zwei Abschnitte zur Erzeugung der Passwortdateien für die DB Verbindung. Die Abschnitte beginnend mit dem Befehl cat > ${temp_file} << EOF3 müssen bis zum entsprechenden End Of File Deskriptor in eine Terminalsitzung kopiert werden. Dann löscht man als Superuser zunächst die Dateien /sapmnt/home/nw4adm/.XUSER.62 und /sapdb/home/sqdnw4/.XUSER.62. Anschließend meldet man sich als nw4adm bzw. sqdnw4 an und lässt je den Befehl /sapdb/programs/bin/xuser -b ${temp_file}; ablaufen.

5. Systemstart

nw4host> su nw4adm
nw4host> startsap nw4host

Wer von OSX aus auf NFS Freigaben zugreifen möchte, muss ein paar administrative Schritte auf dem Linux System durchführen, um schnell und einfach auf das entfernte Dateisystem zuzugreifen. Sind beide Systeme vorbereitet, kann der Zugriff bequem vom Finder des Apple Rechners ausgeführt werden:

Bedingung für den Zugriff auf das Entfernte Dateisystem ist ein funktionsfähiger NFS Server. Der Dienst kann bei den gängigen Linux Distributionen als Binary aus dem jeweiligen Paketmanager installiert werden. Läuft der NFS-kernel-server auf dem Linux host, müssen die NFS Freigaben eingerichtet werden. Das Problem dabei ist, dass in jedem NFS Request Benutzerinformationen mitgeschickt werden, damit niemand Fremdes auf das Dateisystem zugreift. Vorraussetzung ist also, dass UID/GID des jeweiligen Benutzers auf beiden Systemen gleich sind. Dazu kann man die Benutzer auf beiden Systemen entsprechend einrichten, oder natürlich einen Verzeichnisdienst (z.B. LDAP) installieren. Da mir das für den Heimgebrauch aber zu aufwendig ist, habe ich die einfache, allerdings nicht so sichere Variante gewählt. NFS bietet nämlich die Möglichkeit jeden Zugriff auf eine Freigabe auf einen generischen Benutzer umzubiegen. Dazu sind in der Datei /etc/exports folgende Ergänzungen bei den Freigaben einzutragen:


# /etc/exports: the access control list for filesystems which may be exported
# to NFS clients. See exports(5).
/nfs-freigabe 192.168.100.0/255.255.255.0(rw,all_squash, \
anonuid=1000,anongid=1000,insecure)


Sicherheitsexperten rollen sich an dieser Stelle die Fingernägel hoch, da wirklich jeder, der auf diese Freigabe von extern zugreift, unter den Rechten des Benutzers mit UID/GID 1000 hantiert. Mich stört das aber wenig, da mein Heimnetz durchaus über zusätzliche Zugangsbeschränkungen verfügt. Außerdem lässt der Parameter insecure zu, dass Ports außerhalb der Reservierten System Ports bis 1024 benutzt werden. Somit sind auf beiden Systemen keine Admin Rechte notwendig. Die Lösung ist einfach, schnell und pragmatisch.

Nach dem Eintrag des NFS Export und einem Neustart des NFS-kernel-servers, erreicht man die neue Freigabe einfach und bequem über das Finder Menu: Gehe zu … > Mit Server verbinden … > nfs://192.168.100.12/nfs-freigabe.

Mehr Infos dazu gibt’s im Artikel Using Automount on Mac OS X.

Wer unter OSX nach der bekannten UNIX /etc/hosts Datei sucht, wird diese zwar finden, neue Einträge in der Datei werden allerdings ignoriert. OSX stellt für die Namensauflösung den NetInfo Manager als System Zubehör bereit. Über den NetInfo Manager kann man, um einen lokalen, virtuellen Host neben localhost einzurichten, eine Kopie von localhost im Ordner machines erstellen und diesen dann entsprechend anpassen. Dies gelingt einem nur, wenn man über die nötigen administrativen Rechte verfügt. Der Parameter name legt dabei den Namen des neuen Hosts fest. Der übergeordnete Ordner lässt sich nicht umbenennen.