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).
1 Solution
Accepted Solutions
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é
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é
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é
Super, danke für die schnelle Rückmeldung und den (wie eigentlich immer) tollen Support.
