|
Donnerstag, 25. März 2010
Um Jira4 mit SSL im Tomcat und selbstsigniertem Zertifikat ans Laufen zu bringen war ein bisschen knobeln angesagt.
SSl selbst geht ja erstmal einfach: http://wiki.blackslash.de/software/ssl
Allerdings meldet das Jira dann den Fehler "Error loading gadget: org.apache.shindig.gadgets.GadgetException: Unable to retrieve gadget xml. HTTP error 500". Das Problem dabei ist, dass Jira dem selbst signierten Zertifikat ersteinmal vertrauen muss, bevor Inhalte inkludiert werden.
usermod -d /var/lib/tomcat-6 -s /bin/bash tomcat
su - tomcat
keytool -export -alias tomcat -file /tmp/cert.crt
exit
usermod -s /sbin/nologin tomcat
keytool -import -file /tmp/cert.crt -alias jiratomcat -keystore /etc/java-config-2/current-system-vm/jre/lib/security/cacerts
keytool -import -file /tmp/cert.crt -alias jiratomcat -keystore /etc/java-config-2/current-system-vm/jre/lib/security/cacerts
Enter keystore password:
Owner: CN=jira.fem.tu-ilmenau.de, OU=Technik Team, O=Forschungsgemeinschaft elektronische Medien e.V. (FeM e.V.), L=Ilmenau, ST=Thueringen, C=DE
Issuer: CN=jira.fem.tu-ilmenau.de, OU=Technik Team, O=Forschungsgemeinschaft elektronische Medien e.V. (FeM e.V.), L=Ilmenau, ST=Thueringen, C=DE
Serial number: 4baacb63
Valid from: Thu Mar 25 03:33:07 CET 2010 until: Sat Mar 24 03:33:07 CET 2012
Certificate fingerprints:
MD5: CF:3B:BB:54:29:7E:41:D7:D8:95:33:66:12:87:AF:1B
SHA1: 0F:22:52:9F:1C:DB:83:31:26:DD:C2:8C:4C:E3:37:12:43:B8:8C:FC
Signature algorithm name: SHA1withRSA
Version: 3
Trust this certificate? [no]: yes
Certificate was added to keystore
Mittwoch, 21. Oktober 2009
Seit fast drei Jahren arbeite ich nun mit Maven. Vor kurzen habe ich jedoch erst die Software Sonatype Nexus entdeckt - ein Proxy und Artifaktmanager für Maven-Artefakte.
Wolf-u.li bescheibt die Installation von Nexus unter Gentoo.
Da mir die beschriebene manuelle Installation zu langwierig ist, habe ich dazu mal ein EBuild [1] gebaut. Dieser ist im Gentoo-FeM-Overlay zu finden, welchen man idealerweise mit Layman benutzt. Die Einrichtung des FeM-Overlays ist in diesem Beitrag erklärt.
Anschließend kann man Nexus mit folgendem Kommando installieren:
emerge nexus -avt
[1] http://subversion.fem.tu-ilmenau.de/repository/fem-overlay/trunk/dev-java/nexus/
Dienstag, 23. Juni 2009
Manchmal kommt man doch unfreiwillig in die Gelegenheit eine svn+ssh Verbindung für ein Subversion-Repository verwenden zu müssen. Wenn ich nun unter Windows per Kommandozeile ein paar Subversion-Kommandos absetzen will, dann kommt folgende Fehlermeldung (unter Linux würde das jetzt natürlich sofort funktionieren  ):
trunk>svn diff -r3102:head
svn: Kann Tunnel nicht erzeugen: Das System kann die angegebene Datei nicht finden.
In meinem Fall (Vista) muss ich dazu in die C:\Users\$user\AppData\Roaming\Subversion\config folgenden Eintrag hinzufügen:
ssh = "C:/Program Files/TortoiseSVN/bin/TortoisePlink.exe"
Es muss ein Pfad zu einem Putty plink.exe angegeben werden, bzw. in meinem Fall lieber die TortoisePlink.exe vom TortoiseSVN. Anschließend werden die Daten der gespeichertern Plink-Verbindung genutzt und man kann sich das Diff nun ohne Fehlermeldung ansehen. 
Donnerstag, 18. Juni 2009
Sowohl auf dem Hostsystem als auch im Gastsystem kommt bei mir die Amd64-Architektur zum Einsatz und sollte somit mehr als 4GB RAM untersützen.
Jedoch erscheint folgende Fehlermeldung:
Xen version: 3.3.1 (preserve-AD)
------------[ cut here ]------------
kernel BUG at arch/x86/xen/enlighten.c:836!
invalid opcode: 0000 [1] SMP
...
Kernel panic - not syncing: Attempted to kill init!
Nach ein bischen googlen sind wir auf diesen Bug gestoßen. Der Fehler scheint nur bei der Kombination eines 2.6.27 Kernels und einer 64bit domU aufzutreten.
Die Lösung ist es in der DomU einen aktuellen Gentoo-Kernel zu verwenden. Da diese aber aktuell noch nicht als stable markiert ist, muss dieser entmaskiert werden:
echo "=sys-kernel/gentoo-sources-2.6.30-r1 ~amd64" >> etc/portage/package.keywords
emerge gentoo-sources -avt
danke an pegro und mape
Donnerstag, 18. Juni 2009
Ich verwende XEN 3.3.1 und nen aktuellen 2.6.30-gentoo-r1 kernel. Wenn ich mit "xm console maschinenname" auf die Konsole einer virtuellen Maschine zugreifen möchte, erscheint nach der Ausgabe "Starting local..." keine weitere Ausgabe.
Das liegt daran, dass die bei der Paravirtualisierung-Supports des Kernels der Konsolenname umbenannt wurde, diese aber in meinem Betriebsystem noch nicht berücksichtigt ist.
Um den Fehler zu beheben, muss man folgendes tun:
In der Datei /etc/inittab folgende Zeilen auskommentieren:
#c1:12345:respawn:/sbin/agetty 38400 tty1 linux
#c2:2345:respawn:/sbin/agetty 38400 tty2 linux
#c3:2345:respawn:/sbin/agetty 38400 tty3 linux
#c4:2345:respawn:/sbin/agetty 38400 tty4 linux
#c5:2345:respawn:/sbin/agetty 38400 tty5 linux
#c6:2345:respawn:/sbin/agetty 38400 tty6 linux
und stattdessen folgende Zeile hinzufügen:
c1:12345:respawn:/sbin/agetty 38400 hvc0 linux
Nun fehlt nur noch ein Eintrag in der /etc/securetty:
hvc0
Nach einem Neustart der VM sollte man sich nun auf der Xen Console einloggen können.
Sonntag, 3. Mai 2009
Zusätzlich zum Gentoo-Standard-Portage werden zahlreiche "Overlays" angeboten, welche die verfügbare Software erweitern kann. Man kann auch seinen eigenen Overlay betreiben und diesem eBuilds hinzufügen, was die Installation von häufig benötigter Software vereinfacht und wiederholbar macht.
Layman installieren:
Zur Verwaltung von Overlays bietet sich die Software "layman" an. Da viele Overlays in einem Subversion-Repository verwaltet werden, wird subversion benötigt.
echo "app-portage/layman subversion" >> / etc/portage/package.use
emerge layman -avt
Den Gentoo-Fem-Overlay hinzufügen:
layman --overlays=http://subversion.fem.tu-ilmenau.de/overlay.xml -L -a fem-overlay
Nachdem man das erste Overlay hinzugefügt hat, muss man noch einen Eintrag in die make.conf machen, damit die zusätzlichen Ebuilds gefunden werden:
echo "source /usr/local/portage/layman/make.conf" >> / etc/make.conf
Montag, 12. Januar 2009
Das Verhalten von Cocoon läßt sich sowohl in Spring und Avalon-Konfigurationsdateien, als auch über Properties steuern.
In welcher Reihenfolge nach Property-Dateien gesucht wird, ist hier beschrieben.
Mittwoch, 7. Januar 2009
In Cocoon 2.2 einen Dateiupload zu realisieren ist relativ trivial. Jedoch sind die dazu nötigen Parameter recht spärlich dokumentiert, sodass ich schon eine Weile suchen musste, bis der Upload funktionierte.
So muss man in einer beliebig benannten properties-Datei im Verzeichnis META-INF/cocoon/properties folgende Eigenschaften setzen:
org.apache.cocoon.uploads.enable=true
org.apache.cocoon.uploads.maxsize=10000000
Anbei ein Minimalbeispiel: cocoon-uploaddemo.zip
Donnerstag, 18. Dezember 2008
Wenn man sich mit Hibernate [1] eine Datenstruktur erzeugen lässt, dann haben die Foreignkeys standardmäßig kryptische Namen. Das liegt daran, dass normalerweise einfach ein Hash über den Tabellen- und Spaltennamen gebildet wird. Möchte man andere Namen verwenden, etwa um eine mögliche Fehlermeldung besser deuten zu können, so kann man diese mit einer Annotation [2] festlegen.
@ForeignKey(name="FK_PARENT")
[1] http://www.hibernate.org
[2] http://www.hibernate.org/hib_docs/annotations/reference/en/html/entity.html#entity-hibspec-singleassoc
Montag, 8. Dezember 2008
Für Java gibt es ein interessantes Projekt namens urlrewrite [1], welches das bekannte mod_rewrite für den Apache Webserver nachzubilden versucht.
Mit diesem Filter, ist es möglich, eine Java-Webanwendungen nachzurüsten und beliebige URLs umzuschreiben.
Ein Beispiel habe ich hier hinterlegt.
[1] http://code.google.com/p/urlrewritefilter/
Donnerstag, 30. Oktober 2008
Mit Vista kann man mit Boardmitteln auf einen Sharepoint-Server per Webdav zugreifen. Dumm ist nur, wenn der Sharepoint aus unerfindlichen Gründen kein HTTPS anbietet. Vista unterbindet standardmäßig den Zugriff auf ungesicherte Verbindungen. Wenn man aber, wie in meinem Fall, nur mal kurz ein paar GB Fotos herunterkopieren will, dann ist Webdav schon recht nützlich, im Vergleich zur Sharepoint-Weboberfläche, auf der man jedes Foto einzeln anklicken muss.
Um auch HTTP-Verbindungen zuzulassen, muss man zunächst erst einmal einen RegistryKey ändern:
HKLM\SYSTEM\CurrentControlSet\Services\WebClient\Parameters\BasicAuthLevel
von DWORD 1 auf 2
Nach einem Neustart des WebClient-Dienstes kann man sich die Resource dann mounten:
net stop webclient
net start webclient
net use x: "http://dokumentenserver/Fotos/Image%20Library" /user:fem\deka
Dienstag, 28. Oktober 2008
Nach einem Update von openssh 4.6 auf 5.1 erschien beim Login auf meinem Server immer die MessageOfTheDay (motd) und die Lastlogin-Zeile doppelt. Grund dafür ist eine Änderung am Paket pam, die beides neuerdings selbst ausgibt.
Die Lösung ist nun entweder in der /etc/ssh/sshd_config
PrintMotd no
PrintLastLog no
zu setzen oder in der /etc/pam.d/system-login die Zeilen
session optional pam_lastlog.so
session optional pam_motd.so motd=/etc/motd
auszukommentieren.
Montag, 27. Oktober 2008
Möchte man mit einem Java Webservice auf einen anderen Webservice über eine HTTPS-Verbindung zugreifen (z.B. von einem Jira zu einem Fisheye), dann muss man zunächst das Serverzertifikat im Truststore vom Client installieren.
Solange das Zertifikat nicht installiert ist, meldet der Client:
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target when trying to open an SSL connection to a host using JSSE
Zur Installation des Zertifikats hat Andreas Sterbenz [1] ein nettes kleines Tool namens "InstallCert" [2] geschrieben, was den Vorgang etwas vereinfacht. Zunächst muss man das Tool herunterladen und kompilieren:
wget http://blogs.sun.com/andreas/resource/InstallCert.java
javac InstallCert.java
Danach wird das Tool ausgeführt und das Zertifikat wird in einen lokalen Truststore installiert:
java InstallCert subversion.meinserver.de
Eine Datei namens "jssecacerts" wird erstellt. Anschließend muss man sein Javaprogramm nur mit einem weiteren Systemproperty mit dem Pfad zum Truststore aufrufen und der Zugriff über HTTPS kann nun erfolgen:
-Djavax.net.ssl.trustStore=/etc/java-config-2/jssecacerts
Verbindung erfolgreich.
[1] http://blogs.sun.com/andreas/entry/no_more_unable_to_find
[2] http://blogs.sun.com/andreas/resource/InstallCert.java
Freitag, 24. Oktober 2008
Möchte man die Dependency Injection von Spring nutzen, muss man mittweilen die zu injizierenden Resourcen mit der Annotation javax.annotation.Resource markieren.
Nach dem Umstieg von Eclipse 3.3 (Europa) auf Eclipse 3.4 (Ganymede) begrüßten mich in meinen Projekten viele der folgenden Fehlermeldungen: "Access restriction: The type Resource is not accessible due to restriction on required library <jre_path>/lib/rt.jar". Das Projekt ließ sich nicht kompilieren.
Nach einigen Recherchen fand ich heraus, dass derartige Fehlermeldungen vom Eclipse JDT erzeugt werden, falls man Nicht-API Klassen [1] wie sun.* verwendet. Dummerweise wird diese Fehlermeldung in diesem Fall fälschlicherweise auch erzeugt.
Um Weiterarbeiten zu können kann man die Fehlererzeugung für diesen Fehler abschalten:
Window -> Preferences -> Java -> Compiler -> Errors/Warnings -> Deprecated and restricted API -> Forbidden reference (access rules) -> Warning
[1] http://java.sun.com/products/jdk/faq/faq-sun-packages.html
Mittwoch, 22. Oktober 2008
Um EJB3 und Spring Komponenten gemeinsam zu verwenden, und ggf. gegenseitig auf sich zugreifen zu lassen, müssen diese auf einem Server gemeinsam installiert (deploy-t) werden. Da es keinen Sinn macht, für jede Spring Anwendung die kompletten Bibliotheken zu hinterlegen (und damit mehrfach auf dem Server), haben Ales Justin [1] und mittlerweile 78 weitere Entwickler einen JBoss-Spring-Deployer [2] gebaut.
Um diesen zu verwenden, muss man sich zunächst den JBoss Application Server installieren. Dazu läd man von [3] den aktuellen JBoss 5.0.0.CR2 herunter und entpackt diesen.
Den JBoss-Spring-Deployer kann man in der aktuellen Version 3.1 von [2] (jboss-spring-3.1.deployer) beziehen. Die Datei muss lediglich im Verzeichnis jboss-5.0.0.CR2/server/default/deployers hinterlegt werden.
So weit so gut: Prinzipiell könnte man jetzt die erste Spring-Anwendung deploy-en.
Spring-Archive können als normale JAR-Datei gepackt werden. Der JBoss-Spring-Deployer sucht nach Spring-Konfigurationsdateien nach dem Muster *-spring.xml. Es empfiehlt sich eine solche Datei im Verzeichnis META-INF der Anwendung zu hinterlegen. Findet der Deployer eine solche Datei, werden die darin definierten Beans in einem Spring-Kontext geladen.
ABER (was mich mal wieder einen Nachmittag gekostet hat): Beim JBoss 5 CR2 hat sich eine Schnittstelle [4] geändert, sodaß man noch eine Anpassung machen muss, bevor der Deployer [5] funktioniert. Man muss zunächst mit einem Packprogramm die Datei jboss-spring-3.1.deployer entpacken und die Datei META-INF/spring-deployers-beans.xml zu META-INF/spring-deployers-jboss-beans.xml umbenennen. Fertig.
Bleibt nur noch zu klären, ob es Wechselwirkungen mit dem Cocoon-Spring-Configurator [6] gibt...
[1] http://java.sys-con.com/node/180386
[2] http://sourceforge.net/project/showfiles.php?group_id=22866&package_id=161914
[3] http://www.jboss.org/jbossas/downloads/
[4] https://jira.jboss.org/jira/browse/JBAS-5803
[5] http://www.jboss.com/index.html?module=bb&op=viewtopic&t=143666
[6] http://cocoon.apache.org/subprojects/configuration/1.0/spring-configurator/2.0/1304_1_1.html
|
