action-jackson.de

Möchte man seine Webanwendung, welche mit Maven gebaut wird und das Jetty Plugin nutzt, in Eclipse debuggen, so muss man der JVM ein paar VM agruments mitgeben. Man hat nun zwei Möglichkeiten das Maven Goal jetty:run zu starten:

• via der Konsole.
• in Eclipse via m2eclipse

Konsole:
$ export MAVEN_OPTS="-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n"

Eclipse:
Run -> Run Configurations… -> Maven Build
Im Reiter Main das Goal jetty:run eintragen und im Reiter JRE bei VM arguments -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n

Nun muss man in Eclipse noch den Debugger konfigurieren. Hierfür geht man wie folgt vor:
Run -> Debug Configurations… -> Remote Java Application
Im Reiter Connect trägt man bei Connection Properties Host: localhost und Port: 8787 ein – welchen man bei address angegeben hat.

Nachdem man jetty:run ausgeführt hat, kann man sich mit dem Eclipse Debugger auf den Jetty verbinden und wie gewohnt seine Anwendung debuggen.

Manchmal ist es ganz nützlich, wenn man Backups macht – keine Frage – jedoch sollte man auch mitberücksichtigten, dass das Medium, auf welchem die Backups liegen verschwinden können. Worst-Cases: Es brennt, jemand bricht in die Wohnung ein etc… – in einem solchen Fall wäre es ganz nett, wenn man noch an einer anderen Location ein Backup hat
Ich möchte hiermit einen Weg aufzeigen, mit welchem man sein SVN-Server an eine andere Location sichern kann:

• Auf dem Server der anderen Location ein neues Repository anlegen:
  $ svnadmin create dest
• Um mit svnsync ein Repository zu synchronisieren muss man noch eine neue Hook anlegen, die es dem svnsync-User erlaubt das Repository zu synchronisieren:
  $ cat < dest/hooks/pre-revprop-change
#!/bin/sh
USER="$3"
if [ "$USER" = "svnsync" ]; then exit 0; fi
echo "Only the svnsync user can change revprops" >&2
exit 1
EOF
$ chmod +x dest/hooks/pre-revprop-change
• Nun kann man die initiale Synchronisation anstoßen:
  
$ svnsync init file://`pwd`/dest \ svn+ssh://sourcesvnserver/source/repos
Copied properties for revision 0
$

• Danach kann das Repository einmal komplett synchronisiert werden:
  
$ svnsync sync file://`pwd`/dest
Committed revision 1.
Copied properties for revision 1.
Committed revision 2.
Copied properties for revision 2.
Committed revision 3.
Copied properties for revision 3.
...


Kurze Notiz am Rande: In diesem Beispiel wird svn+ssh genutzt. Hierzu ist es angebracht, sich mit einem Key-File anzumelden. Des Weiteren sollte noch ein Cron-Job eingerichtet werden, um in einem bestimmten Zeitabschnitt das Repository zu synchronisieren.

Falls man sich in ein CISCO-VPN einwählen möchte gibt es dazu des Öfteren schon eine fertige Konfiguration (*.pcf). Leider kann vpnc damit nicht direkt umgehen und man muss das pcf-File umwandeln. Hier kommt das Programm pcf2vpnc ins Spiel.

~$ sudo apt-get install vpnc # falls nicht installiert
~$ /usr/share/vpnc/pcf2vpnc ~/cisco-vpn-konfiguration.pcf > ~/cisco-vpnc.conf
~$ sudo vpnc cisco-vpnc # VPN starten

Falls man das normale Eclipse nutzt und zusätzlich noch ein paar Features der Spring IDE nutzten möchte sollte man vorher sicherstellen, dass man die AJDT (AspectJ Development Tools) in Eclipse installiert hat. Sonst kommt immer eine unschöne Fehlermeldung aka

requires ‘bundle org.eclipse.ajdt.ui 0.0.0′ but it could not be found Cannot satisfy dependency

Dies kann man schnell fixen, einfach AJDT nachinstallieren und mit dem Spring Kram weitermachen.

Eclipse Update Site zu AJDT:

• Eclipse 3.6 : http://download.eclipse.org/tools/ajdt/36/update
• Eclipse 3.5 : http://download.eclipse.org/tools/ajdt/35/update

Nachdem man sich den SSH-Zugang zum esxi freigeschalten hat, könnte man ja auch auf die Idee kommen, ein paar Jobs via crond zu schedulen.
Hierzu einfach seine Jobs in /var/spool/cron/crontabs/root schreiben, crond killen und nochmal neu ausführen.

Kleine Notiz am Rande:

• esxi kann nur 512 Zeichen in der /var/spool/cron/crontabs/root verarbeiten!
• Alle Jobs in /etc/rc.local festhalten, damit diese nach einem Neustart wieder hier /var/spool/cron/crontabs/root eingetragen werden.
• /var/log/messages checken, ob crond richtig gestartet wurde

Heute kam ein Arbeitskollege zu mir und meinte, er braucht unbeding einen Microsoft Windows 2008 Cluster anstatt seinem alten Windows 2003 Cluster – beides unter VMware. Gesagt getan … kurz zwei VMs deploeyd und den Cluster under 2008 konfiguriert … extra auf einen ESX drauf, um die Shared Disk von Hand anzulegen … die mit dem LSI Logic Controller. Naja beide Nodes haben die Shared Disk gesehen, aber leider wollte der Cluster-Manager die Disk nicht finden … dann hab ich ein bisschen im Netz gesucht und bin drauf gestossen, dass auf 2008 keine SCSI Disks mehr als Shared Disk unterstuetzt werden! Na toll .. auf dem VMware Infrastructure 3 kann ich noch keinen LSI SAS Controller in die VM packen. Zum Glueck standen schon ein paar Blades mit VMware vSphere bereit, hier kann man den LSI SAS Controller in eine VM packen … und nun laeuft auch der Cluster wie ne eins

Gruss,
Jo

In letzter Zeit hatte ich ziemlich viel mit dem VMware ESX4i zu tun – manchmal ist es auch ganz nützlich, wenn man sich via SSH auf den ESX einloggen kann (offiziell nicht supportet). Man muss als erstes mal kurz SSH aktivieren, dazu verbindet man sich via iLO/ DRACK usw. auf die Konsole (oder ganz altmodisch via Bildschirm und Tastatur am ESX) und drückt ALT F1 und gibt dann unsupported ein. Dann die /etc/inetd.conf öffnen und die beiden Zeilen, in denen ssh stream ... steht, die Kommentare entfernen. Kurz noch den inetd-Prozess killen und schon sollten man sich via SSH einloggen können.
So nun kommen wir zum Public Key Authentication. Wie gewohnt auf der Linuxbüchse mit ssh-keygen die Schlüssel erzeugen. Dann den Text des Public Keys kopieren und auf dem ESX4i die Datei /etc/rc.local öffnen. Dort fügen wir noch an das Ende folg. Code ein:

#public key authentification
mkdir /.ssh
touch /.ssh/authorized_keys
chmod 600 /.ssh
chmod 600 /.ssh/authorized_keys
echo "HIER STEHT DER PUBLIC KEY DER LINUXBÜCHSE" > /.ssh/authorized_keys

So, nun sollte man sich ohne lästiger Passworteingabe auf dem ESX einloggen können

Hier mal nen kleines Howto, wie man fuer DB2 seine Dev-Umgebung schnell unter Fedora aufsetzt:

Kurz die Software installieren:
[root@big db2]# yum -y install httpd php mysql mysql-server php-mysql  mysql-administrator php-pear-MDB2 php-pear-MDB2-Driver-mysql

Webserver und Datenbank starten
[root@big db2]# service httpd start
[root@big db2]# service mysqld start

Fuer MySQL noch dem Root-User ein Password geben
[root@big db2]# mysqladmin -u root password 'new-password'

Noch ein paar Default-Settings loeschen:
[root@big db2]# mysql -u root -p
[root@big db2]# mysql> DROP DATABASE test;
[root@big db2]# mysql> DELETE FROM mysql.user WHERE user = '';
[root@big db2]# mysql> FLUSH PRIVILEGES;

PHP-Files holen
[root@big db2]# wget http://www.smiffy.de/DB-IS-II/beispielcode/wwwenv.tgz
[root@big db2]# tar -xvf wwwenv.tgz

Noch die Mondial-Daten importieren
[root@big db2]# mysql -u root -p < wwwenv/daten/mondial-schema-mysql.sql
[root@big db2]# mysql -u root -p < wwwenv/daten/mondial-inputs-mysql.sql

$dsn sollte noch an den DB-Server angepasst werden und schon kann man mit dem TUT loslegen.
Von MySQL gibt es noch die Programme MySQL Administrator und MySQL Query Browser. Beide sind noch ganz praktisch, wenn man mit MySQL arbeitet.
[root@big db2]# yum install mysql-administrator mysql-query-browser

Bei kleineren Installation von VMware Server braucht man normalerweise kein Raw Device Mapping (kurz RDM), aber wenn es doch mal ein bisschen groesser werden sollte, dann kommt man um das RDM nicht drum rum!
Aber wie sieht das eigentlich bei dem VMware Server 2.0 aus? Seit der Version 2.0 des VMware Servers hat sich ja einiges getan. Es wird nun die Hardware Version 7.0 der virtuellen Maschinen unterstuetzt und es gibt nun zwei verschiedene GUIs, um den VMware Server zu administrieren.
Einmal das Webinterface und auf der anderen Seite den VMware Infrastructur Client, also das gleiche Interface, wie auch beim ESX.

So nun aber wieder zum Thema RDM zurueck. Beim VMware Server 1 ging das alles ueber die VMware Server Console und war einfach zu finden, naemlich ganz einfach dort, wo man auch eine Festplatte fuer die VM konfiguriert. Das hat sich nun eben ein bisschen geaendert. RDW kann man nur im Webinterface! konfigurieren und die VM sollte die Hardware Version 7.0 haben. Dann klappt das wunderbar, wenn man der VM mit “Add Hardware -> Passthrough SCSI Device” ein neues SCSI Device reinkonfiguriert. Hier kann dann einfach z.B. die LUN von einem Shared Storage ausgewaehlt werden und schon hat man diese direkt in der VM.

Leider war das im Benutzerhandbuch von VMware Server 2.0 nicht sonderlich gut dokumentiert … das laesst echt noch zu wuenschen uebrig!

kleine Notiz, wie man einen Windows Cluster auf nem ESX-Server aufsetzt:

• 2 Windows VMs deployen
• es muss nen zusaetzlicher SCSI-Controller rein .. hier so den von LSI und SCSI Bus Sharing auf Virtual setzten
• kurz via ssh auf den ESX drauf und nen Quorum und ne Shared-Disk anlegen:
  • vmkfstools -c 20G -a lsilogic -d thick ./shared_disk1.vmdk
  • vmkfstools -c 2G -a lsilogic -d thick ./quorum.vmdk
• Die zwei Disken den VMs hinzufuegen und darauf achten, dass sie am neuen SCSI-Controller dran sind
• Im Windows noch die Disken konfigurieren und nun kann man ueber den Cluster-Administrator den Rest einrichten