JBoss im Produktivbetrieb

Transkript

1 Kapitel 9 KAPITEL 9 JBoss im Produktivbetrieb In diesem Kapitel: Die Management-Konsolen absichern Den JMX-Invoker schützen Die HTTP-Invoker entfernen Die JMS-Invoker konfigurieren Hypersonic entfernen Die Tomcat- Konnektoren konfigurieren Eine Web- Anwendung als Wurzel einstellen Den Class- Download-Service entfernen JBoss kommt in einem außerordentlich entwicklerfreundlichen Zustand zu Ihnen. Kein Installer und keine zusätzlichen Konfigurationen sind erforderlich, um JBoss zu starten. In den meisten Fällen benötigt auch Ihre Anwendung keine JBoss-spezifische Konfiguration für das Deployment und für den Betrieb. Die Default-Konfiguration umfasst bereits die am meisten benötigten Services, die bereits laufen und in einem Zustand sind, in dem leicht auf sie zugegriffen werden kann. Für Entwickler ist dies alles ideal, aber wenn die Zeit naht, Ihre Anwendung in den Produktionsbetrieb zu überführen, wird Ihnen die Freundlichkeit Ihres Anwendungsservers nicht mehr ganz so gefallen. Sie werden die verfügbaren Services auf jene beschränken wollen, die wirklich benötigt werden, und dies gilt besonders, wenn diese Services der Außenwelt mögliche Angriffspunkte für den Zugriff auf den Server bieten. Außerdem werden Sie sicherstellen wollen, dass die übrigen Services so konfiguriert sind, dass sie sich für den produktiven Betrieb eignen. In diesem Kapitel werden wir die standardmäßige JBoss-Installation durchgehen und sehen, mit welchen Anpassungen wir eine JBoss-Instanz darauf vorbereiten, dass sie der Außenwelt präsentiert wird. Bedenken Sie, wenn wir die einzelnen Services durchgehen, dass Sie diese Arbeit nur einmal ausführen müssen. In Kapitel 1 haben Sie gelernt, wie man eine neue Server-Konfiguration anlegt. Wir empfehlen Ihnen, eine eigene Server-Konfiguration für Ihre Deployment-Umgebung anzulegen. Diese können Sie als Ausgangspunkt für jede Installation nehmen, die Sie ausführen. Damit stellen Sie sicher, dass jeder Rechner identisch konfigurierte Services hat. 144

2 Die Management-Konsolen absichern Über das ganze Buch hinweg haben Sie die JMX-Konsole und die Web- Konsole nicht intensiv benutzt. Angesichts der Tatsache, dass Sie eine JBoss-Instanz mit Hilfe dieser Anwendungen komplett steuern können, wird es Ihnen vielleicht etwas merkwürdig vorgekommen sein, dass Sie niemals einen Benutzernamen und ein Passwort eingeben mussten, um sie zu benutzen. Jeder, der auf Ihren Server zugreifen kann, hat auch Zugriff auf diese Anwendungen. Wenn Sie vorhaben, diese Anwendungen zu benutzen, sollten Sie sie durch einige Konfigurationsschritte darauf vorbereiten. Aus Konsistenzgründen arbeiten wir auch in diesen Beispielen weiterhin mit der Default-Konfiguration. Wie mache ich das? Bevor wir beginnen, sollte Ihnen Folgendes klar sein: Wenn Sie die Management-Konsolen nicht benötigen, können Sie diese auch leicht loswerden. Dann brauchen Sie sich keine Gedanken mehr darüber zu machen, ob entfernte Benutzer auf sie zugreifen können. Die JMX-Konsole befindet sich in deploy/jmx-console.war und die Web-Konsole in deploy/management. Entfernen Sie diese beiden Verzeichnisse, und JBoss vergisst alles, was er über die Management-Anwendungen weiß. Wenn Sie die Verzeichnisse entfernen, verlieren Sie leider auch die Möglichkeit, den Server über die Konsolen zu verwalten. In manchen Fällen kann dies durchaus sinnvoll sein, aber wir glauben, dass die Management-Konsolen so nützlich sind, dass es sich lohnt, sie zu behalten. Wenn Sie sich entschließen, die Management-Konsolen weiterzuverwenden, müssen Sie sie mit einer Security-Domain verknüpfen und die Web- Anwendungen genau so absichern, wie Sie es schon von der ToDo-Anwendung kennen. Um dies zu vereinfachen, bietet JBoss vorkonfigurierte Sicherheitsdeklarationen, die auskommentiert sind und nur aktiviert werden müssen. Bearbeiten Sie die Datei WEB-INF/web.xml im Verzeichnis jmx-console. war, und kommentieren Sie den folgenden Security-Constraint aus: <security-constraint> <web-resource-collection> <web-resource-name>htmladaptor</web-resource-name> <description> An example security config that only allows users with the role JBossAdmin to access the HTML JMX console web application </description> Die Management-Konsolen absichern 145

3 <url-pattern>/*</url-pattern> <http-method>get</http-method> <http-method>post</http-method> </web-resource-collection> <auth-constraint> <role-name>jbossadmin</role-name> </auth-constraint> </security-constraint> Dies beschränkt die gesamte JMX-Konsole auf Benutzer mit der Rolle JBossAdmin. Wenn Sie sich noch an die Behandlung der Sicherheitsaspekte in Kapitel 5 erinnern, wissen Sie, dass Sie außerdem noch eine Verknüpfung zu der Security-Domain in WEB-INF/jboss-web.xml herstellen müssen: <jboss-web> <security-domain>java:/jaas/jmx-console</security-domain> </jboss-web> Diese Security-Domain ist bereits in das Deployment einbezogen: <application-policy name="jmx-console"> <authentication> <login-module code="org.jboss.security.auth.spi.usersrolesloginmodule" flag="required"> <module-option name="usersproperties"> props/jmx-console-users.properties </module-option> <module-option name="rolesproperties"> props/jmx-console-roles.properties </module-option> </login-module> </authentication> </application-policy> In Kapitel 5 haben Sie gesehen, wie man Security-Domains ersetzt und anpasst. Hier wollen wir uns mit dem Mechanismus begnügen, der Properties-Dateien verwendet. Die beiden erwähnten Dateien jmx-consoleusers.properties und jmx-console-roles.properties liegen im Verzeichnis conf/props. Wenn Sie die Dateien nicht im Verzeichnis der Web-Anwendung, sondern an einem Ort mit gemeinsamem Zugriff aufbewahren, machen Sie es möglich, dass die Benutzerinformationen später zusammen mit der Web-Konsole verwendet werden können. In den beiden Properties-Dateien ist ein Benutzer mit dem Namen admin und dem Passwort admin deklariert. Nehmen Sie sich jetzt gleich die Zeit, und ändern Sie dies. Wenn Sie den vorgegebenen Namen und das Passwort für die JMX-Konsole beibehalten, ist dies nicht viel besser, als sie überhaupt nicht zu schützen. 146 Kapitel 9: JBoss im Produktivbetrieb

4 Für die JMX-Konsole ist dies alles, was zu tun ist. Nun nehmen wir noch dieselben Änderungen für die Web-Konsole vor. Um die Konfigurationsdateien für die Web-Konsole zu finden, müssen Sie bis zu management/ console-mgr.sar/web-console.war/web-inf hinuntergehen. Kommentieren Sie den Security-Constraint in der web.xml aus, und legen Sie eine Security-Domain in jboss-web.xml fest. Anstatt die zurzeit referenzierte Security-Domain java:/jaas/web-console auszukommentieren, setzen Sie die Security-Domain auf java:/jass/jmx-console. Dies hat zur Folge, dass beide Anwendungen durch dieselbe Security-Domain authentifiziert werden und es nicht zwei separate Logins für die Anwendungen gibt. Sie können jetzt ein erneutes Deployment der Anwendungen vornehmen, um die Änderungen wirksam zu machen; am schnellsten geht es aber, wenn Sie den Server neu starten. Was ist gerade geschehen? Sie haben die beiden Management-Konsolen abgesichert. Wenn Sie eine von ihnen aufrufen, fordert JBoss Sie nun dazu auf, sich anzumelden. Die Authentifizierungsinformationen werden den Dateien jmx-console-users. properties und jmx-console-roles.properties im Verzeichnis conf/props entnommen, aber Sie können die Einzelheiten zur Authentifizierung in login-config.xml abändern. Es gibt aber noch ein Problem: Wenn Sie auf die Management-Konsolen über normales HTTP zugreifen, werden Ihr Benutzername und Ihr Passwort im Klartext übertragen. Sie sollten SSL aktivieren, wie in Kapitel 5 gezeigt, und auf diese Anwendungen immer über HTTPS zugreifen, sofern Sie sich nicht über ein vertrauenswürdiges Netzwerk verbinden. Den JMX-Invoker schützen Die Management-Konsolen sind nicht der einzige Zugang zum Inneren des Systems. Die Skripten Shutdown und Twiddle sind Programme, die mit JBoss auf der Management-Ebene kommunizieren. Allerdings laufen sie nicht über die Web-Anwendungen, sondern interagieren mit dem JMX- Invoker. Ein Invoker ist ein JBoss-Service, der Invocations entgegennimmt; dies sind Anfragen von externen Clients nach Aktionen, die vom Server auszuführen sind. Zur Interaktion mit dem JMX-Microkernel wird der JMX- Invoker verwendet. Den JMX-Invoker schützen 147

5 Immer wenn Sie auf den Begriff Invoker stoßen, sollten Sie sich sofort fragen, ob Sie wirklich den jeweiligen Typ von Anfragen aus der Außenwelt akzeptieren müssen. Wenn dies nicht der Fall ist, ist es normalerweise das Beste, den Invoker einfach zu entfernen. So können Sie auch den JMX-Invoker entfernen, wenn Sie niemals von einem anderen Rechner aus den Server herunterfahren oder eine andere Art des entfernten programmgesteuerten Managements ausführen müssen. Andererseits sind diese Management-Aktionen auch recht nützlich, daher glauben wir, dass es besser ist, den JMX-Invoker zwar aktiv zu lassen, ihn aber abzusichern. Wie mache ich das? Der Service JMX-Invoker ist in deploy/jmx-invoker-service.xml konfiguriert und kann recht einfach abgesichert werden. Der Invoke-Operation in der Managed-Bean (MBean) jboss.jmx:type=adaptor,name=invoker muss ein Authentifizierungs-Interceptor hinzugefügt werden, der sie mit der zutreffenden Security-Domain verknüpft. Das klingt nicht ganz einfach, aber der richtige Interceptor steht bereits in der Datei und wartet nur darauf, auskommentiert zu werden: <descriptors> <interceptors> <interceptor code="org.jboss.jmx.connector.invoker.authenticationinterceptor" securitydomain="java:/jaas/jmx-console"/> </interceptors> </descriptors> Dieser Interceptor verlangt, dass der Benutzer durch die Security-Domain java:/jaas/jmx-console authentifiziert werden muss, bevor er Management-Operationen entfernt ausführen kann. Um sicher zu sein, dass der Interceptor funktioniert, versuchen Sie einmal, den Server mit dem Shutdown-Befehl herunterzufahren: [bin]$./shutdown.sh -S Exception in thread "main" java.lang.securityexception: Failed to authenticate principal=null, securitydomain=jmx-console at org.jboss.jmx.connector.invoker.authenticationinterceptor.invoke( AuthenticationInterceptor.java:76) at org.jboss.mx.server.invocation.invoke(invocation.java:74) at... Wenn Sie keinen gültigen Benutzernamen mit Passwort angeben, scheitert das Skript. Mit den Argumenten -u und -p können Sie diese Informationen angeben: [bin]$ sh./shutdown.sh -S -u admin -p admin Wenn Sie bereits den Benutzer admin entfernt oder sein Passwort verändert haben, denken Sie daran, hier die korrekten Daten anzugeben. 148 Kapitel 9: JBoss im Produktivbetrieb

6 Was ist gerade geschehen? Sie haben den JMX-Invoker gegen nicht-authentifizierte Zugriffe abgesichert, indem Sie ihm einen Authentifizierungs-Interceptor zugeordnet haben. Der Interceptor ist mit der Security-Domain java:/jaas/jmx-console verknüpft. Dies ermöglicht es Ihnen, dieselben administrativen Benutzernamen und Passwörter zu benutzen, die Sie bereits für die JMXund die Web-Konsole definiert haben. Die HTTP-Invoker entfernen Aktive HTTP-Invoker zu haben, ist generell bedrohlich, denn sie eröffnen der Außenwelt eine Zugangsmöglichkeit zu Ihrem Server. Wenn sie richtig abgesichert sind, müssen sie Ihnen keine großen Sorgen bereiten, aber es ist für Sie wichtig zu wissen, dass sie da sind. Denn nur dann können Sie dafür sorgen, dass sie abgesichert sind. Invoker, die an einem bestimmten Port auf entfernte Verbindungen warten, sind leicht aufzuspüren. Standardmäßige Netzwerk-Tools wie nmap, lsof und netstat können Ihnen sagen, welche Ports an einem Rechner in Benutzung sind. Weniger leicht kann man Invoker finden, die über andere Protokolle tunneln, und dabei ist HTTP der Hauptverdächtige. HTTP-Invocations sind wichtig. Häufig beschränken übereifrige Netzwerkadministratoren den Zugriff zwischen zwei Netzwerken auf Port 80. Das zwingt Sie, den Entwickler, Möglichkeiten zum Tunneln von Anwendungszugriffen über diesen einen Port zu finden. JBoss kann jede Art entfernten Zugriffs über Port 80 ausführen: JNDI, JMX-Invocations, EJB-Invocations usw. Standardmäßig ist JBoss so konfiguriert, dass er Zugriffe über HTTP zulässt, aber die meisten Anwendungen müssen nicht über Port 80 getunnelt werden. In diesem Fall stellt die Existenz des HTTP-Invokers eher eine Belastung dar, und dann ist es das Beste, wenn Sie ihn einfach entfernen. Wie mache ich das? Die HTTP-Invoker können Sie leicht entfernen, denn sie werden durch einen einzigen Service verwaltet, und zwar http-invoker.sar. Entfernen Sie einfach dieses gesamte Verzeichnis aus dem deploy-verzeichnis. Damit ist für Sie alles klar, denn Sie können sicher sein, dass kein entfernter Client mehr durch die Hintertür des HTTP-Invokers zugreifen kann. Schon wieder dieser»invoker«. Komisches Wort. Die HTTP-Invoker entfernen 149

7 Die JMS-Invoker konfigurieren In der ToDo-Anwendung benutzen wir es zwar nicht, aber trotzdem ist das Messaging ist ein wichtiger Bestandteil vieler Enterprise-Anwendungen. JBoss unterstützt JMS, den Java Message Service, und bietet eine vollständig spezifikationskonforme JMS-Implementierung, die sogar Invoker für den Zugriff auf JMS-Destinationen außerhalb des Anwendungsservers umfasst. Glücklicherweise ist das Aufsetzen von JMS für den produktiven Betrieb recht einfach. Sie müssen nur zwei Dinge wissen: ob Ihre Anwendung JMS benutzt und ob externe Anwendungen Ihr JMS verwenden. Mit diesen beiden Informationen können Sie die JMS-Invoker konfigurieren. Wie mache ich das? Alle JMS-Services werden unterhalb des Verzeichnisses deploy/jms konfiguriert. Wenn Sie überhaupt kein JMS verwenden, müssen Sie nichts weiter tun, als das gesamte Verzeichnis jms zu löschen. Damit werden nicht nur die JMS-Invoker, sondern das gesamte JMS-Subsystem entfernt. Wenn Sie keine Messaging-Anwendung schreiben, besteht auch keine Notwendigkeit, wertvollen Speicherplatz und knappe Prozessorzeit für diese Dienste in Anspruch zu nehmen. Da aber JMS so weit verbreitet ist, wollen wir es nicht dabei belassen. Falls Sie doch das Messaging benötigen, müssen Sie entscheiden, welche JMS-Invoker erhalten bleiben sollen. Die Services, die sich im jms-verzeichnis befinden, sind die JMS-Invoker. Der erste ist jvm-il-service.xml. Die Invocation-Schicht wird nur innerhalb des Anwendungsservers verwendet. Er bietet keinerlei Zugriffsmöglichkeit für die Außenwelt, daher brauchen Sie sich darüber keine Sorgen zu machen und können ihn einfach stehen lassen. Der nächste Invoker ist jbossmq-httpil.sar. Dies ist der HTTP-Invoker für JMS. Wenn Sie externe Clients haben, die über HTTP tunneln müssen, kann Ihnen dieser Invoker das Leben retten. Aber wahrscheinlich benötigen Sie ihn nicht, also entfernen Sie diesen Service und müssen sich auch keine weiteren Sorgen mehr machen. Der letzte Invoker ist uil2-service.xml. Falls es Sie interessiert: Der Name steht für»unified Invocation Layer, Version 2«. Er ermöglicht Ihnen den Zugriff auf die JBoss-Messaging-Queues. Wenn keine externen Clients auf Ihre Destinationen zugreifen sollen, können Sie auch diesen Service ruhig entfernen. Andernfalls müssen Sie ihn stehen lassen und sicherstellen, dass Ihre Destinationen korrekt abgesichert sind. 150 Kapitel 9: JBoss im Produktivbetrieb

8 Die Destinationen werden durch jbossmq-destinations.xml im Verzeichnis deploy/jms abgesichert. Hier ist die Konfiguration für ein Topic: <mbean code="org.jboss.mq.server.jmx.topic" name="jboss.mq.destination:service=topic,name=testtopic"> <depends optional-attribute-name="destinationmanager"> jboss.mq:service=destinationmanager </depends> <depends optional-attribute-name="securitymanager"> jboss.mq:service=securitymanager </depends> <attribute name="securityconf"> <security> <role name="guest" read="true" write="true"/> <role name="publisher" read="true" write="true" create="false"/> <role name="durpublisher" read="true" write="true" create="true"/> </security> </attribute> </mbean> Das Attribut SecurityConf definiert die Rechte für jede logische Rolle, an der Sie interessiert sind. Die Rechte read und write entsprechen der Erlaubnis, Nachrichten von einer Destination zu lesen bzw. an eine Destination zu senden. Das Recht create ist die Erlaubnis, dauerhafte Abonnements zu einer Destination anzulegen. Das Attribut SecurityManager stellt eine Verknüpfung zu dem in jbossmqservice definierten Security-Interceptor dar: <mbean code="org.jboss.mq.security.securitymanager" name="jboss.mq:service=securitymanager"> <attribute name="defaultsecurityconfig"> <security> <role name="guest" read="true" write="true" create="true"/> </security> </attribute> <attribute name="securitydomain">java:/jaas/jbossmq</attribute> <depends optional-attribute-name="nextinterceptor"> jboss.mq:service=destinationmanager </depends> </mbean> Der Security-Manager definiert sowohl die vorgegebene Sicherheitskonfiguration für den Fall, dass keine jbossmq-destinations.xml definiert ist, als auch die Security-Domain, die zur Verifikation der JMS-Rechte verwendet wird. java:/jaas/jbossmq ist bereits in login-config.xml definiert: <application-policy name="jbossmq"> <authentication> <login-module code="org.jboss.security.auth.spi.databaseserverloginmodule" flag="required"> Die JMS-Invoker konfigurieren 151

9 <module-option name="unauthenticatedidentity"> guest </module-option> <module-option name="dsjndiname">java:/defaultds</module-option> <module-option name="principalsquery"> SELECT PASSWD FROM JMS_USERS WHERE USERID=? </module-option> <module-option name="rolesquery"> SELECT ROLEID, 'Roles' FROM JMS_ROLES WHERE USERID=? </module-option> </login-module> </authentication> </application-policy> Dies ist das standardmäßige DatabaseServerLoginModule. Wie es konfiguriert wird, haben Sie in Kapitel 5 gesehen. Interessant an dieser Konfiguration ist die Verwendung der Option unauthenticatedidentity. Ihr zufolge wird den nicht authentifizierten Benutzern die Rolle guest zugewiesen. In der Kombination mit der DefaultSecurityConf des JMS-Security-Managers besagt dies, dass jedermann auf Ihre JMS-Destinationen zugreifen kann. Sie sollten also die Rechte für die Rolle guest entfernen, wenn Sie entfernten Zugriff auf JMS erlauben. Was ist gerade geschehen? Sie haben die Schritte gesehen, die zur JMS-Konfiguration eines Produktionssystems erforderlich sind. Wenn Sie diesen Service nicht benutzen, entfernen Sie ihn komplett. Andernfalls müssen Sie wählen, welchen der drei Invoker Sie benötigen. Um entfernte JMS-Clients zuzulassen, müssen Sie den UIL2-Service behalten; in diesem Fall ist es jedoch erforderlich, der Sicherheitskonfiguration große Aufmerksamkeit zu schenken. Hypersonic entfernen Hypersonic ist eine großartige Datenbank, wenn es um das Testen von Anwendungen geht, aber es ist nicht für den produktiven Betrieb geeignet. In Kapitel 4 haben Sie gesehen, wie Sie auf eine andere Datenbank umschalten. Wenn Sie Hypersonic nicht benutzen, können Sie den kompletten Service entfernen. Wenn Sie es nicht anders eingerichtet haben, wartet Hypersonic nicht auf Verbindungen von der Außenwelt, daher brauchen Sie sich keine Gedanken über die Absicherung zu machen. Aber vielleicht wollen Sie nicht, dass eine weitere Datenbank Speicherplatz verbraucht? Zwar ist Hypersonic recht leichtgewichtig, trotzdem dürfte es für Sie vorteilhaft sein, wenn Sie es loswerden. 152 Kapitel 9: JBoss im Produktivbetrieb

10 Wie mache ich das? Die Datei hsqldb-ds.xml konfiguriert nicht nur die Hypersonic-Datenquellen, sondern hat auch die MBeans, die den gesamten eingebetteten Datenbank-Service steuern. Wenn Sie diese Datei entfernen, verschwindet Hypersonic spurlos. Das klingt trivial, und es wäre auch trivial, wenn nicht verschiedene andere Services von Hypersonic abhängig wären. Wir gehen nun die Änderungen durch und nehmen dabei an, dass Sie eine MySQL-Datenbank wie in Kapitel 4 beschrieben angelegt haben und dass die ToDo-Anwendung bereits auf die Verwendung dieser Datenbank umgestellt ist. Der erste Service ist der EJB-Timer-Service in ejb-deployer.xml. Darin sollten Sie den Verweis auf DefaultDS durch eine Referenz auf die korrekte Datenquelle ersetzen. In Kapitel 4 wählten wir den Namen MySqlDS. Diese Änderung ist einfach: <!-- A persistence policy that persists timers to a database --> <mbean code="org.jboss.ejb.txtimer.databasepersistencepolicy" name="jboss.ejb:service=ejbtimerservice,persistencepolicy=database"> <!-- DataSource JNDI name --> <depends optional-attribute-name="datasource"> jboss.jca:service=datasourcebinding,name=mysqlds </depends> <!-- The plugin that handles database persistence --> <attribute name="databasepersistenceplugin"> org.jboss.ejb.txtimer.generalpurposedatabasepersistenceplugin </attribute> </mbean> Auch für JMS müssen Änderungen an der Persistenz vorgenommen werden. Wenn Sie JMS nicht verwenden und sich entschlossen haben, es aus Ihrer Konfiguration zu entfernen, können Sie an dieser Stelle aufhören. Andernfalls gehen Sie in das Verzeichnis deploy/jms und suchen nach den Dateien hsqldb-jdbc2-service.xml und hsqldb-jdbc-state-service.xml. hsqldb-jdbc2-service.xml steuert die Persistenz der Nachrichten. Sie können die Datei komplett entfernen und durch eine datenbankspezifische Datei aus docs/examples/jms ersetzen. Für MySQL kopieren Sie mysqljdbc2-service.xml in das Verzeichnis jms. Mit hsqldb-jdbc-state-service.xml geht das nicht ganz so einfach, da es hierfür keine datenbankspezifischen Vorlagen gibt. Sie müssen die Abhängigkeit von der Datenquelle also manuell anpassen: <mbean code="org.jboss.mq.sm.jdbc.jdbcstatemanager" name="jboss.mq:service=statemanager"> <depends optional-attribute-name="connectionmanager"> jboss.jca:service=datasourcebinding,name=mysqlds </depends> Hypersonic entfernen 153

11 <! > </mbean> Diese Referenz auf eine Datenquelle muss dieselbe sein wie die auf die Datenquelle, die Sie oben, in der Security-Domain jbossmq in login-config. xml gesehen haben. Das sollten Sie jetzt auch anpassen: <application-policy name="jbossmq"> <authentication> <login-module code="org.jboss.security.auth.spi.databaseserverloginmodule" flag="required"> <module-option name="unauthenticatedidentity">guest </module-option> <module-option name="dsjndiname">java:/mysqlds</module-option> <module-option name="principalsquery"> SELECT PASSWD FROM JMS_USERS WHERE USERID=? </module-option> <module-option name="rolesquery"> SELECT ROLEID, 'Roles' FROM JMS_ROLES WHERE USERID=? </module-option> </login-module> </authentication> </application-policy> Die letzte Abhängigkeit von DefaultDS besteht in uuid-key-generator. sar. Wenn Sie den UUID-Schlüsselgenerator von JBoss nicht verwenden, können Sie diesen Service aus dem deploy-verzeichnis entfernen. Andernfalls müssen Sie die Datei META-INF/jboss-service.xml so ändern, dass sie die von Ihnen präferierte Datenquelle referenziert: <mbean code="org.jboss.ejb.plugins.keygenerator.hilo. HiLoKeyGeneratorFactory" name="jboss:service=keygeneratorfactory,type=hilo"> <! > <depends optional-attribute-name="datasource"> jboss.jca:service=datasourcebinding,name=mysqlds </depends> <! > </mbean> Leider wird dieser Service nicht in expandierter Form geliefert, daher müssen Sie das Archiv erst entpacken, um dorthin zu gelangen. Was ist gerade geschehen? Sie haben Hypersonic entfernt und die davon abhängigen Services angepasst oder entfernt. Alle persistenten Services schreiben nun ihre Tabellen in die neue Datenbank. Wenn Sie die Services behalten und JBoss neu gestartet haben, sollten Sie jetzt verschiedene neue Tabellen in Ihrer externen Datenbank vorfinden: 154 Kapitel 9: JBoss im Produktivbetrieb

12 mysql> show tables in jbossdb; Tables_in_jbossdb Comment HILOSEQUENCES JMS_ROLES JMS_SUBSCRIPTIONS JMS_TRANSACTIONS JMS_USERS TIMERS Task jms_messages rows in set (0.14 sec) Sie hätten sich einige Mühe ersparen können, wenn Sie die DefaultDS ersetzt hätten. Dann wäre es nicht nötig gewesen, alle Referenzen auf die Datenquellen zu verändern. Es ist jedoch wichtig, bei der Konfiguration eines Produktionsrechners für Klarheit zu sorgen. Zu wissen, dass alle Ihre persistenten Services korrekt konfiguriert sind, ist ungemein beruhigend, und das sollte Ihnen die zusätzliche Mühe wert sein. Die Tomcat-Konnektoren konfigurieren Die Konnektoren von Tomcat machen es möglich, dass überhaupt Web- Anfragen aus der Außenwelt hereinkommen. Konzeptionell ähneln sie den Invokern, die Sie zuvor in diesem Kapitel kennen gelernt haben, allerdings nehmen sie HTTP-Anfragen für Web-Anwendungen an und nicht allgemeine Anfragen für JBoss-Services. HTTP-Konnektoren sind nicht harmlos, wenn es um Web-Anwendungen wie den HTTP-Invoker geht, der HTTP-Anfragen in Service-Invocations übersetzt. Trotzdem sollen Sie sich keine Gedanken wegen der HTTP-Konnektoren machen, sondern sich um die Web-Anwendungen kümmern, die hinter ihnen stehen. An den Konnektoren ist nur interessant, ob die richtigen aktiviert sind und ob sie an den richtigen Ports horchen. Wie mache ich das? In jbossweb-tomcat55.sar/server.xml sind zwei Konnektoren definiert. Der erste ist der AJP-Konnektor, der auf Anfragen wartet, die von einem Apache-Server mit installiertem mod_jk weitergeleitet werden: <!-- A AJP 1.3 Connector on port > <Connector port="8009" address="${jboss.bind.address}" Die Tomcat-Konnektoren konfigurieren 155

13 Wenn Sie einen Unix-Rechner haben und den Port auf einen Wert unter 1024 ändern wollen, müssen Sie JBoss unter root laufen lassen. emptysessionpath="true" enablelookups="false" redirectport="8443" protocol="ajp/1.3"/> Dieser Konnektor horcht am Port 8009; diesen sehen die externen Clients aber nicht, und daher muss er auch nicht verändert werden. Wenn Sie mod_jk nicht verwenden, können Sie diesen Konnektor entfernen und damit Ressourcen sparen. Der normale Tomcat-Service wartet auf HTTP-Anfragen an Port Der Konnektor sieht folgendermaßen aus: <Connector port="8080" address="${jboss.bind.address}" maxthreads="250" strategy="ms" maxhttpheadersize="8192" emptysessionpath="true" enablelookups="false" redirectport="8443" acceptcount="100" connectiontimeout="20000" disableuploadtimeout="true"/> Wenn Ihr Server direkt von der Außenwelt aus sichtbar ist, werden Sie den Standard-Port 80 verwenden wollen, sofern Sie keinen Load-Balancer als Frontend haben, der den Standard-Port 80 auf den Port 8080 Ihres Rechner umleiten kann. Zu diesem Zweck ändern Sie das Attribut port auf 80. Es gibt noch einen dritten Konnektor, den Sie vielleicht hinzufügen möchten, und zwar den SSL-Konnektor. Kapitel 5 hat Ihnen gezeigt, wie Sie SSL aktivieren; dort haben Sie aber Port 8443 benutzt. Standardgemäß ist der HTTPS-Port 443, daher sollten Sie die Portnummer für diesen Konnektor entsprechend ändern. Der SSL-Konnektor sieht so aus: <Connector port="443" address="${jboss.bind.address}" maxthreads="100" strategy="ms" maxhttpheadersize="8192" emptysessionpath="true" scheme="https" secure="true" clientauth="false" keystorefile="${jboss.server.home.dir}/conf/ssl.keystore" keystorepass="mypassword" keyalias="testkey1" sslprotocol="tls" /> Wenn Sie einen anderen SSL-Port verwenden, müssen Sie darauf achten, dass der Redirect-Port des HTTP-Konnektors der SSL-Port (443) ist. Sowohl der HTTP- als auch der AJP-Konnektor haben ein Attribut redirectport, das auf den richtigen Wert gesetzt werden muss: <Connector port="80" address="${jboss.bind.address}" maxthreads="250" strategy="ms" maxhttpheadersize="8192" emptysessionpath="true" enablelookups="false" redirectport="443" acceptcount="100" connectiontimeout="20000" disableuploadtimeout="true"/> Starten Sie JBoss neu, damit diese Änderungen wirksam werden. Sie sollten nun in der Lage sein, den Server unter zu erreichen, wobei in der URL jetzt keine Portnummer mehr aufgeführt ist. 156 Kapitel 9: JBoss im Produktivbetrieb

14 Was ist gerade geschehen? Sie haben gesehen, wo die Tomcat-Konnektoren konfiguriert werden, und Sie haben die Ports geändert, die Tomcat für HTTP-Anfragen benutzt. Bezüglich der Konnektoren haben sich keine direkten Sicherheitsbedenken ergeben. Es war nichts weiter zu tun, als die richtigen Konnektoren an den richtigen Ports verfügbar zu machen. Und was ist, wenn Sie den Server nicht über Port 80 erreichen können? Prüfen Sie das Konsolenprotokoll auf Fehler beim Hochfahren. Möglicherweise läuft bereits ein anderer Webserver auf Ihrem Rechner am Port 80, oder der Benutzer, unter dessen Namen der Server läuft, hat nicht das Recht, auf einen privilegierten Port wie Port 80 zuzugreifen. Die Protokollmeldungen können Ihnen dabei helfen herauszubekommen, was JBoss an der Benutzung des Ports 80 hindert. Eine Web-Anwendung als Wurzel einstellen Wenn Sie erstmalig auf JBoss zugreifen, stellt Ihnen JBoss eine vorgegebene Wurzelanwendung zur Verfügung, die in Abbildung 9-1 dargestellt ist. Im Produktionsbetrieb sollte besser Ihre eigene Anwendung den Wurzelkontext bedienen. Wie mache ich das? Die Einstellung des Kontexts einer Web-Anwendung ist unterschiedlich bei WAR-Dateien, die sich beim Deployment innerhalb einer EAR-Datei befinden, und bei einzeln in Betrieb genommenen WAR-Dateien. EAR-Dateien enthalten einen J2EE-Standardmechanismus für die Festlegung der Kontexte von Web-Anwendungen. Das Element context-root eines Web-Moduls in application.xml bestimmt die Wurzel-Web-Anwendung. Indem Sie den Wurzelkontext auf / setzen, platzieren Sie eine Anwendung in den Wurzelkontext. Bei der ToDo-Anwendung sieht dies folgendermaßen aus: <application xmlns=" version="1.4" xmlns:xsi=" xsi:schemalocation=" /xml/ns/j2ee Wenn Sie nicht den HTTP-Port auf 80 gestellt haben, achten Sie darauf, dass Sie / verwenden. Eine Web-Anwendung als Wurzel einstellen 157

15 <display-name>todo-anwendung zum JBoss-Entwicklerheft</display-name> <description>todo-anwendung zum JBoss-Entwicklerheft</description> <module> <ejb>todo.jar</ejb> </module> <module> <web> <web-uri>todo.war</web-uri> <context-root>/</context-root> </web> </module> </application> JBoss beschwert sich nicht, wenn Sie mehrere Anwendungen haben, die den Wurzelkontext bedienen wollen, aber nur die zuletzt in Betrieb genommene Anwendung ist aktiv. Abbildung 9-1: Die vorgegebene Wurzelanwendung Wenn Sie diese Änderung vornehmen und ein erneutes Deployment der Anwendung vornehmen, bringt Sie ein Zugriff auf direkt zur ToDo-Anwendung. Bei einer selbstständigen WAR-Datei muss das Element context-root in jboss-web.xml eingetragen werden. Wir kommen noch einmal auf die Zitatmaschinen-Web-Anwendung aus Kapitel 2 zurück. Legen Sie in quote/src/metadata eine Datei jboss-web.xml an, die folgendermaßen aussieht: <!DOCTYPE jboss-web PUBLIC "-//JBoss//DTD Web Application 2.4//EN" " 158 Kapitel 9: JBoss im Produktivbetrieb

16 <jboss-web> <context-root>/</context-root> </jboss-web>. Danach können Sie ein erneutes Deployment der Anwendung vornehmen. Gehen Sie nun zu und Sie sehen, dass dort die Zitat-Anwendung läuft. Was ist gerade geschehen? Sie haben gesehen, wie Sie eine Anwendung so einstellen, dass sie in JBoss den Wurzelkontext bedient. Bei EAR-Dateien kann die Deklaration der Kontextwurzel in einer vom Anwendungsserver unabhängigen Weise vorgenommen werden. Bei einer eigenständigen WAR-Datei müssen Sie jedoch die Datei jboss-web.xml verwenden, um den Kontext zu deklarieren. Den Class-Download-Service entfernen Der letzte Service, um den wir uns noch Gedanken machen müssen, ist der Class-Download-Service. Er ermöglicht es RMI-Clients, Java-Klassen vom Server herunterzuladen. Dies ist an sich eine nette Idee, denn dann müssen Sie Ihre Server-Klassen nicht an Ihre externen Clients verteilen. Allerdings wird alles offen gelegt, was sich im Klassenpfad des Servers befindet, wenn Sie den Class-Download-Service laufen lassen. Versuchen Sie einmal, auf oder (noch schlimmer) auf zuzugreifen, und Sie erkennen das potenzielle Problem dieses Service. Wie mache ich das? Um die Möglichkeit, Klassendateien herunterzuladen zu deaktivieren, bearbeiten Sie conf/jboss-service.xml und entfernen die MBean jboss:service=webservice. Dies sieht folgendermaßen aus: <!-- ================================================== --> <!-- Class Loading --> <!-- ================================================== --> <mbean code="org.jboss.web.webservice" name="jboss:service=webservice"> <attribute name="port">8083</attribute> <!-- Should resources and non-ejb classes be downloadable --> <attribute name="downloadserverclasses">true</attribute> Den Class-Download-Service entfernen 159

17 <attribute name="host">${jboss.bind.address}</attribute> <attribute name="bindaddress">${jboss.bind.address}</attribute> </mbean> Wenn Sie wirklich den Class-Download-Service für entfernte Clients benötigen, sollten Sie wenigstens DownloadServerClasses auf false setzen und somit den Service darauf beschränken, nur EJB-bezogene Klassen zu liefern. Was ist gerade geschehen? Sie haben gesehen, wie man den Class-Download-Service entfernt. Wenn Sie den Class-Download-Service wirklich benötigen, um die Verwaltung von externen Clients zu erleichtern, sollten Sie DownloadServerClasses auf false setzen, um den Umfang der den Clients gegenüber offen gelegten serverseitigen Information zu begrenzen. 160 Kapitel 9: JBoss im Produktivbetrieb