Apache + Tomcat + FS4.2

[rene_charbonnea]

Hallo zusammen,

ich habe heute einen zweiten Versuch gestartet um Firstspirit vollständig über Port 80 verfügbar zu machen.

Der Grund dafür wurde schon mal in 2 anderen Posting (unter anderem von mir) angedeutet:

https://community.e-spirit.com/message/1684#1684

https://community.e-spirit.com/message/1818#1818

Denn anders ist es nicht (sinnvoll) möglich Firstspirit (insbesondere beim Einsatz über https) nach aussen über die Firewall freizuschalten und für externe zugänglich zu machen (Port 8000 ist ja nicht gerade dafür bekannt in vielen Unternehmensfirewalls freigeschaltet zu sein!).

Ich habe also heute ein frisches Debian Squeeze (x64) aufgesetzt und dort Apache2, Tomcat6 und libapache2-mod-jk über apt-get install <Paketname> installiert.

Grund dafür: Damit die Pakete auch über den Paketmanager mit Bugfixes, Sicherheitsupdates usw. versorgt werden...

So machen wir das im übrigen auch intern bei anderen Applikationen (wie z.B. unser Wiki) die einen Tomcat als AppServer unterstützen.

Falls übrigens jemand interesse an der Apache Konfig hat (die ist meines erachtens deutlich einfacher als mit mod_proxy_ajp), dann meldet euch!

Nach der Installation von Firstspirit (wie in der Install Doku beschrieben) startete Firstspirit auch erfolgreich mit Jetty auf Port 8000.

Anschließend habe ich mich dann (nach einigen Initialen Konfig Einstellungen) durch die Admin Doku gelesen um die Tomcat Konfiguration vorzunehmen.

Schlussendlich hat auch alles geklappt und Firstspirit ist nun über die Kombination Apache httpd + Apache Tomcat vollständig via Port 80 erreichbar.

Leider aber nicht ganz sauber.

Ich habe folgende offene Punkte die ich gerne versuchen würde hier zu klären:

1)

Um den Tomcat-Manager zur Status-Überwachung zu aktivieren, in der Datei tomcat/conf/tomcat-users.xml ein Benutzerkonto für die Rolle "manager" des Tomcat-Managers einfügen:

<?xml version='1.0' encoding='utf-8'?>

<tomcat-users>

<role rolename="manager"/>

<user username="Admin" password="tomcat-password" roles="manager"/>

</tomcat-users>

Die Datei tomcat/conf/Catalina/localhost/manager.xml mit folgendem Inhalt zum Aktivieren des Tomcat-Managers anlegen:

<Context docBase="${catalina.home}/webapps/manager"

privileged="true" antiResourceLocking="false"

antiJARLocking="false">

<ResourceLink name="users" global="UserDatabase" type="org.apache.catalina.UserDatabase"/>

</Context>

Wenn ich das jedoch mache, dann erhalte ich eine Meldung, dass ein Verzeichnis nicht existiert bzw. lesbar ist. Ist dieser Eintrag notwendig? Wozu dient er überhaupt?

2)

Die Datei tomcat/lib/log4j.properties mit folgendem Inhalt erstellen, um das Logging der FirstSpirit-Web-Anwendungen in eine eigene Datei umzuleiten:

log4j.rootCategory=INFO, fs # change INFO in the following line to DEBUG # for detailed FirstSpirit logging: log4j.logger.de.espirit=INFO

log4j.logger.org.mortbay=WARN log4j.logger.org.apache.catalina=INFO log4j.logger.org.apache.jasper=WARN log4j.logger.org.apache.log4j.jmx=ERROR log4j.logger.org.apache.commons.httpclient=INFO

log4j.appender.fs=org.apache.log4j.RollingFileAppender log4j.appender.fs.File=${catalina.home}/logs/firstspirit.log log4j.appender.fs.MaxFileSize=10MB log4j.appender.fs.MaxBackupIndex=9 log4j.appender.fs.layout=org.apache.log4j.PatternLayout log4j.appender.fs.layout.ConversionPattern=[%d] %t %c %-5p - %m%n

Unter Debian befindet sich ja das <TOMCAT_HOME> unter /var/lib/tomcat6/. Leider existiert dort nirgends ein Verzeichnis "lib" wo ich die Datei "log4j.properties"  ablegen könnte. Könnt ihr mir bitte sagen wo ich die Datei ansonsten ablegen kann/soll?

3) Tomcat und Firstspirit laufen hier bei uns (vom Prinzip her ja auch sinnvoll!) unter 2 verschiedenen Usern. Tomcat bringt von Haus aus die Gruppe und den User Tomcat6 mit. Firstspirit wiederum die Gruppe und den User fs4.

Wenn ich nun Tomcat das erste mal starte, dann erhalte ich die Meldung, dass "/opt/firstspirit4/web/ROOT" nicht existiert bzw. lesbar sei.

Auch das ist richtig, da alles unterhalb von "/opt/firstspirit" ja den User fs4 als Owner hat!

Dieses Problem konnte ich umgehen (da ja nur von "lesend" die Rede war), indem ich den User "tomcat6" in die Gruppe "fs4" gesteckt habe. Damit verschwand die Fehlermeldung und ich konnte Firstspirit das erste mal über Port 80 bewundern.

Meine Frage: Gibt es hier einen eleganteren Weg?

4) Beim starten des Tomcat erhalte ich noch die Information, dass das Verzeichnis "/opt/firstspirit4/web/fs4webedit/preview_cache" nicht schreibbar ist (ähnliches/gleiches Problem wie 3.). Das Problem hier ist aber, dass die Gruppe fs4 hier ebenfalls keine Schreibrechte hat!

19.04.2011 13:52:40 org.apache.catalina.core.ApplicationContext log

SCHWERWIEGEND: StandardWrapper.Throwable

java.lang.IllegalStateException: directory /opt/firstspirit4/web/fs4webedit/preview_cache is not writeable!

    at de.espirit.firstspirit.io.servlet.PreviewServlet.init(PreviewServlet.java:145)

    at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1173)

    at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:993)

    at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4350)

    at org.apache.catalina.core.StandardContext.start(StandardContext.java:4659)

    at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)

    at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)

    at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:546)

    at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041)

    at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964)

    at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502)

    at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277)

    at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:321)

    at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)

    at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)

    at org.apache.catalina.core.StandardHost.start(StandardHost.java:785)

    at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)

    at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:445)

    at org.apache.catalina.core.StandardService.start(StandardService.java:519)

    at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)

    at org.apache.catalina.startup.Catalina.start(Catalina.java:581)

    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

    at java.lang.reflect.Method.invoke(Method.java:597)

    at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)

    at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)

19.04.2011 13:52:40 org.apache.catalina.core.StandardContext loadOnStartup

SCHWERWIEGEND: Servlet /fs4webedit threw load() exception

java.lang.IllegalStateException: directory /opt/firstspirit4/web/fs4webedit/preview_cache is not writeable!

    at de.espirit.firstspirit.io.servlet.PreviewServlet.init(PreviewServlet.java:145)

    at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1173)

    at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:993)

    at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4350)

    at org.apache.catalina.core.StandardContext.start(StandardContext.java:4659)

    at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)

    at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)

    at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:546)

    at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041)

    at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964)

    at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502)

    at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277)

    at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:321)

    at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)

    at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)

    at org.apache.catalina.core.StandardHost.start(StandardHost.java:785)

    at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)

    at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:445)

    at org.apache.catalina.core.StandardService.start(StandardService.java:519)

    at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)

    at org.apache.catalina.startup.Catalina.start(Catalina.java:581)

    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

    at java.lang.reflect.Method.invoke(Method.java:597)

    at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)

    at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)

Ich habe mir nun mehrere Sachen überlegt zur Lösung:

1) Die Besitzer für das Verzeichnis "/opt/firstspirit4/web/fs4webedit/preview_cache" von fs4 auf tomcat6 ändern

2) Der Gruppe fs4 Schreibrechte auf das Verzeichnis geben

3) Die gesamte Firstspirit Installation unter dem User tomcat6 laufen lassen und die Berechtigungen rekursiv ändern (für Gruppen und Besitzer)

Letzteres dürfte aber wohl die sinnvollste Idee sein, denn so MÜSSTE eine Änderung in der Datei "/etc/init.d/fs4" reichen (Parameter FSUSER) um das Problem 3 & 4 zu lösen.

Da ich aber sicher gehen wollte, dass dieses vorgehen keine anderen unerwarteten Seiteneffekte hat, wollte ich hier erst einmal das Feedback abwarten.

Es könnte ja (theoretisch) sein, dass der User "fs4" zwingend ist und eine Änderung nicht möglich.

Auch wenn ich das nicht glaube....

Wäre über jeden Vorschlag/Idee froh die die Probleme 1 - 4 lösen könnten.

Liebe Grüße aus Eschborn

René

P.S. Ist irgendwie absehbar wann ein 64Bit JDK auf dem Client unterstützt wird? Wir verteilen zwar beides (als 32 und 64 Bit JDK) auf unseren Windows 7 (x64) Clients, aber standardmäßig steht das 64 Bit JDK in der Suchreihenfolge VOR dem 32Bit JDK und somit fällt der Client beim start auf die Nase.

EDIT:

Ich habe ein weiteres "Problem" entdeckt. Auch der Zugriff über WebClient (Autorenumgebung) -> Mithras Energy (das Demoprojekt) schlägt fehl. Dort erhalte ich folgende Meldung im Browser:

Es ist ein interner Fehler aufgetreten.

Bitte setzen Sie sich mit dem WEBedit-Support Team in Verbindung.

Ich vermute, dass auch dieses Problem wie 3 & 4 mit den Berechtigungen zusammenhängen.

EDIT2:

Wenn ich ein Ticket eröffnen soll, dann sagt mir das. Ich wollte nur hier die Diskussion führen, da das auch sicherlich ein paar andere Leute interessieren dürfte. (Hoffe ich doch zumindest).

[feddersen]

1) Man braucht einen User mit der Role manager, damit man sich im Tomcat-Manager einloggen kann. Das ist in keiner Weise FirstSpirit spezifisch, sondern eine Standard Tomcat-Konfiguration. Eventuell gibt es unter Debian auch einen entsprechendes Paket um den Tomcat-Manager zu installieren und eine Best-Practice um solch einen Benutzer zu erstellen. Das Problem hört sich ebenfalls nach einem Berechtigungsproblem an, wahrscheinlich konnte der Tomcat keine Nutzer-DB schreiben.

2) Mit dpkg -S <PaketName> kann man sich alle Dateien/Verzeichnisse anzeigen lassen, dort sollte auch ein Hinweis auf das lib-Verzeichnis des Tomcats zu finden sein.

3) Wenn es nicht die gleichen Gruppen/Benutzer sein sollen, gibt es noch die Möglichkeit Access Control Lists zu verwenden. FirstSpirit muss natürlich nicht zwingend unter dem Benutzer fs4 laufen, dass ist nur der Standard.

4) Die Probleme sind alle eine Folge der falschen Rechtekonfiguration, genau wie das WebEdit Problem.

64-bit) Siehe Release-Notes zu R4, Kapitel 2.1.4.1 FirstSpirit-JavaClient

[rene_charbonnea]

Hallo Christoph (ich bin mal so frech und nehme mir das "Du" heraus),

danke zunächst schon mal für die Antworten. Ich habe allerdings noch ein paar Fragen.

1) Das der Tomcat Manager eigentlich zum "Standard" gehört ist mir bewusst. Unter Debian aber scheinbar nicht.
Mir war und ist auch bisher nie klar gewesen wozu der Manager überhaupt dient. Deswegen zielte meine Frage auch eher in die Richtung: Wird der für Firstspirit irgendwie benötigt? Wenn nein würde ich mir nämlich diese Konfiguration ersparen.

2) Danke für den Tipp. Habe das "lib" Verzeichnis gefunden. Ist unter "/usr/share/tomcat6/lib/" zu finden...

3) - N) Ich habe befürchtet, dass es mit den Rechten zusammen hängt. Deswegen habe ich heute morgen einen Snapshot der Maschine gezogen und mal zum Spaß im Startskript (/etc/init.d/fs4) den FSUSER Parameter von fs4 auf tomcat6 geändert sowie die Rechte für das "/opt/firstspirit4" mit "chown -R tomcat6 /opt/firstspirit4" und ""chgrp -R tomcat6 /opt/firstspirit4" abgeändert.

Nach dieser Änderung startete Firstspirit per "/etc/init.d/fs4 start" jedoch gar nicht mehr an. Es wurden nicht einmal Logs unter "/opt/firstspirit4/log" erstellt. Eine Fehlerausgabe auf der Konsole erfolgte ebenfalls NICHT.

Es scheint also doch etwas komplexer zu sein als ich erwartet habe. Mit ACL habe ich bisher noch überhaupt nicht gearbeitet und würde das auch eigentlich gerne vermeiden. Schöner wäre es, wenn ich Firstspirit einfach dazu bekäme mit dem Tomcat User zu laufen. Damit wären ja dann eigentlich alle Spatzen gefangen.

Ich würde ja normalerweise auch einfach auf einen "von Hand" installierten Tomcat zurück greifen, aber seit Debian Squeeze gibt es ENDLICH einen Tomcat6  "out of the box" von den Debian Paket Maintainern. Das heisst, dass ich relativ einfach und schnell an die neuen Security Fixes heran komme und mir auch beim Distribution Upgrade keine Sorgen über irgendwelche Inkompatibilitäten mehr machen.

Deswegen wollte ich diese charmante Lösung eigentlich gerne nutzen. Hoffe das kann man nachvollziehen.

Übrigens auch danke für den Hinweis auf die Release Notes. Aber genau um die native 32Bit Geschichte ging es mir ja. Gibt es da schon eine grobe Timeline wann diese harte Abhängigkeit aufgelöst wird? Ist zwar kein Killerkriterium, aber ich falle regelmäßig über diese Baustelle wenn es um den User Support geht.

Nochmal vielen Dank für die Infos.

Liebe Grüße aus Eschborn

René

[feddersen]

1) Nein, der Tomcat-Manager wird nicht gebraucht. Das ist nur ein Webinterface um Applikationen zu installieren/deinstallieren/starten/stoppen zu können. Bei Debian muss man den über ein extra Paket installieren tomcatX-admin

3-N) Vermutlich werden da noch irgendwo die Rechte falsch sein. Vielleicht die Befehle der Startsequenz einfach mal per Kommandozeile ausführen.

64-bit) 64-bit Support ist vor allem mit dem integrierten Browser für die Vorschau und dem AppCenter problematisch. So gibt es ja z.B. noch keinen 64-bit Flash-Player und auch kein Adobe Acrobat Plugin. 64-bit muss man ja komplett durchhalten, was momentan noch schwierig ist. Per se kann der FirstSpirit Client natürlich 64-bit. Nur je nach integriertem Browser und der darin verwendeten Plugins kann es zu Problemen kommen. Wann sich das ändert, liegt nicht in unserem Einflussbereich, wir beobachten die Entwicklung aber.

[rene_charbonnea · Accepted solution]

Ah okay, in dem Fall lasse ich den Tomcat Manager weg. Denn ehrlich gesagt bin ich wenig begeistert von solchen Webinterfacen (genauso wie von einer GUI auf einem Server ).

Das mit den Rechten ist mir noch immer ein Rätsel. Ich habe nun mehrere Varianten gestern ausprobiert und nichts hilft. Sobald ich den User im FS4-Startskript ändere läuft gar nichts mehr. Ohne auch nur einen Hinweis zu bekommen...

Ich war schon kurz davor mit ACLs anzufangen als ich den entschluss gefasst habe nach dem K-I-S-S Prinzip zu handel.

Ich habe ein "chmod -R g+w /opt/firstspirit4/" abgesetzt und damit war/ist das Thema mit den Rechten erledigt.
Da ich nämlich den User tomcat6 bereits in die Gruppe fs4 gepackt habe, konnte durch das hinzufügen der Schreibrechte für die Gruppe die Rechteprobleme gelöst werden.

Ist zwar nicht sonderlich elegant (ganz zu schweigen von potentiellen Sicherheitsproblemen) aber Aufwand und Nutzen sollen ja in einem sinnvollen Verhältnis stehen.

Ich spekuliere sowieso darauf, dass wir Ende diesen Jahres noch eine WAF erhalten. Mit der kann ich dann wohl dieses selbst verschuldete "Sicherheitsproblem" beseitigen.

Bezüglich der 64 Bit Thematik auch noch mal vielen Dank für die Aufklärung. An Acrobat bzw. Flash Plugins habe ich gar nicht gedacht (da sieht man mal wie wenig ich mit FS4 von Anwedungsseite zu tun habe. ). Das erklärt das Problem auch. Dann hoffe ich mal, dass Adobe in nächster Zeit endlich auf den 64 Bit Zug aufspringt.

Gruß
René

[rene_charbonnea]

Hallo zusammen,

ich möchte meine ursprüngliche Frage noch einmal um einen einzelnen Aspekt erweitern.

Ich habe heute (endlich) das offizielle SSL Zertifikat für den Server im Apache installiert.

Ich leite nun im Apache alle eingehenden Verbindungen von Port 80 nach 443 um.

Wenn ich mich nun am Firstspirit Server angemeldet habe (bis dahin läuft alles super!),

muss ich in den Verbindungseinstellungen MANUELL https aktivieren (für den Java Client).

Da wir jedoch im Hintergrund die Benutzer aus der der AD holen (bzw. dagegen authorisieren) möchte ich eigentlich Firstspirit so konfigurieren, dass https quasi als Standardprotokoll verwendet wird. Wenn möglich so, dass der User überhaupt nichts tun muss.

Kann ich das irgendwie hinkriegen? Gibt es einen Parameter mit dem ich ZENTRAL steuern kann, dass der Java Client standardmäßig https verwendet?

Gruß
René

[hoebbel]

Hallo René,

der entsprechene Parameter heißt

usehttps=1

Siehe auch das Handbuch für Administratoren, insbesondere wenn noch mehr Parameter, z.B. für einen Proxyserver, benötigt werden:

http://www.e-spirit.com/odfs42/media/dokumentation/dokumentation_admins/ADMI4xDE_FirstSpirit_AdminDo...

User: FIRSTDoku

Pass: FSdown_V2

Dieser Parameter kann entweder in den Verbindungseinstellungen des Benutzers (erreichbar über die FirstSpirit Startseite und gültig für den einzelnen Benutzer) oder über die Server-Eigenschaften (gültig für alle Benutzer, die keine eigenen Verbindungseinstellungen definiert haben) definiert werden.

Da Du das Letztere wünscht - es geht so:

- Öffne die Server- und Projektkonfiguration

- Öffne die Server/Eigenschaften

- Wechsle zu Webstart

- Definiere die gewünschten Parameter (u.a. http Protokoll benutzen) und aktiviere die Option HTTPS Protokoll verwenden oder trage unter den optionalen Parametern usehttps=1 ein.

Viele Grüsse aus Dortmund,

  Holger

[rene_charbonnea]

Danke, genau darüber bin ich eben auch gerade gestolpert.

Der Eintrag der folgenden Parameter in der fs-server.conf hat geholfen!

webstart.client.usehttps=1

webstart.admin.usehttps=1

Aber mal eine andere Frage. Ich habe kürzlich einige Abschnitte aus einer alten Server Konfiguration übernommen

quickstart.0.memory=0

quickstart.0.encryption=1

quickstart.0.connection=HTTP

usw.

Was haben die denn für einen Hintergrund? Ich konnte dazu nix in der Firstspirit Doku finden. Sind das eventuell Parameter aus einer alten FS Version die nicht mehr genutzt/unterstützt werden?

Gruß

René

[feddersen]

Das sind Einstellungen für die Schnellstart-Links auf der Startseite des FirstSpirit-Servers. Wahrscheinlich haben Sie auf dem neuen Server noch keine Schnellstart-Links definiert.

[rene_charbonnea]

Super, danke für die schnelle Rückmeldung und den (wie eigentlich immer) tollen Support.