TIPPS um einen WebCheck-Server mit JBoss 4.0.3 einzurichten

(dieses Dokument: ..internal/intranet/docs/WebCheck-Einrichtung.html)

Dies ist ein inoffizielles Dokument ohne Anspruch auf Vollständigkeit und Richtigkeit

Alle hier aufgeführten Anleitungen und Bemerkungen zum JBoss gelten nur für die Version 4.0.3.
Beachte: Beim JBoss AS7 ist leider alles anders.

Vers. 16.01.2012, ArtCom GmbH Bremen


  1. TIPPS um einen WebCheck-Server einzurichten
    1. Vorbemerkungen
    2. WebCheck-Server einrichten
    3. JBoss installieren
    4. JBoss konfigurieren
      1. Netzwerk Zugriffprobleme
      2. Speicherprobleme: "Exception java.lang.OutOfMemoryError: Java heap space"
    5. JBoss Admin Zugang mittels Passwörter absichern
      1. (1) Direkte Änderung
      2. (2) Benutzung des Archivs-Files
      3. Passwort ändern
      4. Admin Konsole: GET/POST Blockierung auf alle HTML-Requests ausdehnen
      5. JMX-Invoker mit admin-Passwort sichern
      6. HTTP-Invoker entfernen
    6. JBoss auf einen anderen Port als 8080 setzen (Tomcat Connector)
    7. JBoss Serverstart
    8. Log-Files
    9. WebCheck-Paket (ArtNet.ear) deployen (installieren)
    10. Schreib-Rechte
    11. Kundenspezifische Konfiguration der WebCheck-Server
      1. Allgemein
      2. Aktivierung von Firmen- und/oder Kundenlogos
    12. Externer Zugang
    13. WebCheck-Server auf der Impose2000 Seite (ANserver)
    14. Mailing
    15. Beteiligte WebCheck relevante Konfigurationsdateien
    16. Mehrere Instanzen von JBoss, mehrere WebCheck Versionen parallel
    17. Apache Konfiguration, sofern notwendig

Vorbemerkungen

Die Namen "ArtNet" und "WebCheck" sind gleichwertig. Das gilt insbesondere für Paket- und
Verzeichnisnamen. Offizieller Produktname ist "WebCheck"

Dieses Dokument ist als Hilfe zur Installation zu sehen, nicht als offizielle Dokumentation.

WebCheck-Server einrichten

Eine 'normale' WebCheck Installation besteht aus einem WebCheck - Serverrechner und
einem oder mehreren angeschlossenen (per Netzwerk erreichbaren) Impose2000-Server Rechnern.
 
Ausgehend von einem frisch eingerichteten Web-Server Rechner müssen folgende Schritte
durchgeführt werden die unten genauer beschrieben werden:
Unter Sicherheitsaspekten sind evtl. folgende Dinge zu beachten:

JBoss installieren


ab SuSE 10 ist der JBoss nur noch in der SuSE-Enterprise-Version mit dabei. Dieser muß also direkt
von http://www.jboss.com/downloads/index beschafft werden.
Aktuelle Version dort ist momentan JBoss 4.2.0
Vgl. ggf. auch: http://www.jboss.com/docs/index für Dokumentationen.

Wir haben gute Erfahrungen mit der Version 4.0.3RC1 gemacht, dieses Paket findet sich als
/ftp/pub/webcheckJBoss/jboss-4.0.3RC1-installer.jar bzw.
/ftp/pub/webcheck/JBoss/jboss-4.0.3RC1.tar
auf unserem FTP Server

Dieses Paket und JBoss allgemein benötigt Java 1.5 bzw. Java 5 oder höher.

Installation JBoss:

JBoss konfigurieren

Netzwerk Zugriffprobleme

In einem einzelnen Fall, wo ein JBoss 4.0.3RC1 installiert wurde, gab es Probleme mit dem Netzwerkzugriff
auf den Rechner auf dem der JBoss lief. Ca. 50% der Pakete gingen verloren. In anderen Fällen
trat dieses Problem nicht auf, weil hier das Multicasting aus anderen Gründen (Fehler) nicht aktiviert
wurde.

Als letztendliche Ursache wurde folgendes festgestellt (Auszug aus einer Mail):

...da das Problem anscheinend durch die von JBoss verschickten Multicast-Pakete
ausgelöst wird, haben wir nun auf JBoss-Rechner in der JBoss-Konfiguration das
Multicasting abgeschaltet. Das Multicasting wird wohl nur gebraucht, wenn man
mehrere JBoss-Server hat. Konkret sind die zwei Dateien

/usr/local/jboss-4.0.3RC1/server/default/deploy/ejb3-clustered-sfsbcache-service.xml
/usr/local/jboss-4.0.3RC1/server/default/deploy/ejb3-entity-cache-service.xml

zu ändern und jeweils ip_mcast="true" durch ip_mcast="false" zu ersetzen.

Unsere Änderung scheint geholfen zu haben. Ein ping <IP-Nummer> zeigt jetzt
keine Aussetzer mehr, auch wenn der JBoss läuft.

Dieser Schritt sollte bei allen Installationen durchgeführt werden.

Speicherprobleme: "Exception java.lang.OutOfMemoryError: Java heap space"

Standardmäßig ist der JBoss bzw. die daraus gestartete Java VM mit einer Heap-Size von 128MB
definiert. Dann wenn im WebCheck eine größere Anzahl von Benutzern gleichzeitig eingeloggt sein
werden, reicht diese Größe u.U. nicht mehr aus. Die Konfiguration eines höheren Wertes kann durch
Änderung in der JBoss Konfigurationsdatei 'run.conf' erfolgen:
/usr/local/jboss-4.0.3RC1/bin/run.conf:
#
# Specify options to pass to the Java VM.
#
if [ "x$JAVA_OPTS" = "x" ]; then
   JAVA_OPTS="-server -Xms128m -Xmx128m"
fi
Hier kann der Maximalwert auf 1024 gesetzt werden, also "-Xmx1024m",
abhängig von der Größe des verfügbaren Speichers.
Hierbei ist zu beachten, das diese Statements nur ausgeführt werden, wenn
JAVA_OPTS vor Aufruf von 'run.sh' noch nicht an anderer Stelle gesetzt wurden.
Auf der JBoss Web Console kann die Änderung dieses Wertes nach JBoss Neustart kontrolliert werden.

JBoss Admin Zugang mittels Passwörter absichern

Leider ist der JBoss Server nach der Installation zunächst einmal 'offen', d.h. ein Zugang über die
Oberfläche ist auf der JMX- und web- (Management-)Konsole ohne User-ID und Paßwortabfrage
möglich.

Aus Sicherheitsgründen sollten zumindest diese Zugänge unbedingt passwortgeschützt werden.

Das kann entweder direkt geändert werden oder es können bereits geänderte Dateien aus einem tar-Archiv
verwendet werden.

(1) Direkte Änderung

Dazu ist folgendermaßen vorzugehen (Auzug aus einem Dokument:
Vgl. http://jboss.org/community/docs/DOC-12190 für ausführlichere Informationen)

In einem Shell-Fenster folgendes machen (Beachte $JBOSS_HOME ist bei uns /usr/local/jboss-4.0.3RC1,
also zunächst...):

export JBOSS_HOME=" /usr/local/jboss-4.0.3RC1"

oder statt "$JBOSS_HOME" jeweils den Pfad verwenden, dann:

vi $JBOSS_HOME/server/default/deploy/jmx-console.war/WEB-INF/web.xml

uncomment the security-constraint block
and add a <login-config> block after the end of the <security-constraint> block:
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>JMXConsole</realm-name>
</login-config>

vi $JBOSS_HOME/server/default/deploy/jmx-console.war/WEB-INF/jboss-web.xml
Uncomment the security-domain block. Make sure the JNDI name maps to the realm name (i.e. JMXConsole)

vi $JBOSS_HOME/server/default/conf/props/jmx-console-users.properties
change the password for admin

vi $JBOSS_HOME/server/default/deploy/management/console-mgr.sar/web-console.war/WEB-INF/web.xml
uncomment the security-constraint block and add a <login-config> block after the end of the <security-constraint> block:
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>JMXConsole</realm-name>
</login-config>

vi $JBOSS_HOME/server/default/deploy/management/console-mgr.sar/web-console.war/WEB-INF/jboss-web.xml
Uncomment the security-domain block. Make sure the JNDI name maps to the realm name (e.g. JMXConsole)

vi $JBOSS_HOME/server/default/conf/login-config.xml
Change the path to the web-console-users.properties and the web-console-roles.properties as follows (add props/ to the front of the path)
<module-option name="usersProperties">props/web-console-users.properties</module-option>
<module-option name="rolesProperties">props/web-console-roles.properties</module-option>

cp $JBOSS_HOME/server/default/deploy/management/console-mgr.sar/web-console.war/WEB-INF/classes/web-console-*.properties $JBOSS_HOME/server/default/conf/props
edit as needed

cp $JBOSS_HOME/server/default/conf/props/jmx-console-roles.properties $JBOSS_HOME/server/default/conf/props/web-console-roles.properties
edit as needed

edit $JBOSS_HOME/server/default/conf/login-config.xml, find the jmx-console and web-console application-policy, and set the name to jmx-console and web-console, respectively. That is make sure that the application policy name maps to the realm name (i.e. JMXConsole)

restart jboss


Nach diesen Änderungen wird bei Anklicken der JMX- oder web-Konsole nach einer Benutzer-ID
und einem Passwort gefragt. Benutzer-ID ist 'admin', das Passwort kann (sollte) individuell
vergeben werden (s.u.)

(2) Benutzung des Archivs-Files

Die bereits angepaßten JBoss Konfigurationsdateien finden sich auch in einem Archiv
/ftp/pub/webcheck/JBoss/security-update-JBoss-4.0.3RC1-artcom.tar
auf unserem FTP-Server

das security-update-JBoss-4.0.3RC1-artcom.tar auspacken:

security-update-JBoss-4.0.3RC1-artcom.tar bspw. in /tmp:

Passwort ändern

In beiden Fällen muß jetzt noch das 'admin' Passwort individuell angepaßt werden:
dort dann jeweils das admin=<mysecretpassword> mit dem gewünschtem Passwort versehen
(also den Rechts vom '=' stehenden Teil "<mysecretpassword>" entsprechend ersetzen)
Da die Passwörter hier im Klartext stehen, sollten die Dateien entsprechende Zugriffsrechte-
Einschränkungen haben. Z.B. '640'

Admin Konsole: GET/POST Blockierung auf alle HTML-Requests ausdehnen

In /usr/local/jboss-4.0.3RC1/server/default/deploy/jmx-console.war/WEB-INF/web.xml
in der 'security-constraint' Sektion die Zeilen
        <http-method>GET</http-method>
        <http-method>POST</http-method>
entfernen, und danach den JBoss neu gestarten. Jetzt werden alle HTML-Request Zugriffe auf
die AdMin Konsole geblockt

JMX-Invoker mit admin-Passwort sichern

(optional, kein Muß)

Diese Invoker werden z.B. angesprochen um den JBoss-Server herunterzufahren und für ähnliche
externe Anfragen. Diese könnten so konfiguriert werden das sie nur mit Passwort möglich sind.
Diese Anfragen/Aktionen sind allerdings nicht über die JBoss-Oberfläche möglich, deshalb ist
eine Absicherung nicht zwingend notwendig. Falls gewünscht folgendes machen:

vi /usr/local/jboss-4.0.3RC1/server/default/deploy/jmx-invoker-service.xml

den Textblock von

            <!-- Uncomment to require authenticated users
            <descriptors>
               <interceptors>
                  <interceptor code="org.jboss.jmx.connector.invoker.AuthenticationInterceptor"
                     securityDomain="java:/jaas/jmx-console"/>
               </interceptors>
            </descriptors>
            -->

in
            <!-- Uncomment to require authenticated users
               -->
            <descriptors>
               <interceptors>
                  <interceptor code="org.jboss.jmx.connector.invoker.AuthenticationInterceptor"
                     securityDomain="java:/jaas/jmx-console"/>
               </interceptors>
            </descriptors>
            <!-- -->

ändern / einkommentieren (beachte die zusätzlichen "-->" und "<!--").

Jetzt ist das Runterfahren des Servers nur mittels Angabe von ID und Passwort möglich. Z.B.

./shutdown.sh -S -u admin -p <mysecretpassword>

"<mysecretpassword>" entsprechend einsetzen (s.o.)

das bisher mögliche ./shutdown.sh -S liefert ab sofort einen Fehler

HTTP-Invoker entfernen

(optional, kein Muß, evtl. sogar schädlich weil gewollte HTTP Zugriffe nicht mehr möglich sind)

Die HTTP-Invoker gestatten es prinzipiell, das von Außen auf den JBoss-Serverrechner zugegriffen
werden kann. Wird diese Zugangsmöglichkeit nicht benötigt, so kann der HTTP-Invoker entfernt werden.
Dazu folgendes machen:

das Verzeichnis /usr/local/jboss-4.0.3RC1/server/default/deploy//http-invoker.sar entfernen.

Immerhin ist der HTTP-Invoker durch die oben genannte Passwort Absicherung ebenfalls mit einem
Passwort versehen, sodaß der Zugriff nicht mehr ganz ungeschützt ist.

JBoss auf einen anderen Port als 8080 setzen (Tomcat Connector)

Soll/muß das WebCheck unter einer anderen als der Portnummer 8080 aufrufbar sein, so ist folgendermaßen
vorzugehen (wir favorisieren 8080):

Aus Sicherheitsgründen sollte der Standard HTTP Port 80 nur nach anderweitiger Absicherung als
WebCheck Server-Port benutzt werden.

Darüber hinaus ist zu beachten, das bei Portnummern unterhalb von 1024 der JBoss-Server unter root-ID
laufen muß, was aus Sicherheitsgründen ebenfalls nicht empfohlen werden kann.

Es ist dringend angeraten den WebCheck Serverrechner (auch ArtCom-"cube" etc.) nicht direkt am Internet
und am Port 80 zu betreiben. Wenigstens muß der Rechner dann mittels Firewall und URL Rewriting, z.B.
über einen vorgeschalteten 'Apache' HTTP-Server oder Proxy abgesichert sein.
Siehe dazu auch Kapitel "Externer Zugang"

JBoss Serverstart

Starten PER Hand: als root folgendes machen: AUTO (für SuSE): als root in etwa folgendes machen
AUTO (für UBUNTU/Debian): als root in etwa folgendes machen


Log-Files

Das Log-File des JBoss Servers findet sich unter
/opt/jboss/server/default/log
Dort: server.log bzw. ggf. auch boot.log. Alle WebCheck Aktivitäten werden in server.log protokolliert

WebCheck-Paket (ArtNet.ear) deployen (installieren)

ein aktuelles Paket liegt auf unserem FTP-Server unter
/ftp/pub/webcheck/ArtNet.ear

Dieses ArtNet.ear Paket deploy'en, d.h. nach
"/opt/jboss/server/default/deploy"
unter dem Namen ArtNet.ear kopieren.

Ggf. Log in "/opt/jboss/server/default/log/server.log" beobachten

Jetzt sollte sich nach Eingabe von

http://localhost:8080/artnet

im Browser bereits die WebCheck Oberfläche öffnen ('localhost' ggf. durch den realen
Web-Servernamen ersetzen)

Schreib-Rechte

Im Arbeitsverzeichnis der WebCheck Applikation
(s.o. /opt/jboss/server/default/tmp/deploy/tmp48606ArtNet.ear-contents/ArtNet.war)
müssen die von der Applikation erzeugten Auftragsverzeichnisse, in der auch alle Temporärdaten,
z.B. Übersichtsbild-PDFs, abgelegt werden,  Schreibrechte von dem ANserver auf den Impose2000
Rechnern aus  haben. Das wird normalerweise von der WebCheck-Java-Applikation gewährleistet.

Kundenspezifische Konfiguration der WebCheck-Server

Allgemein

Auf dem WebCheck-Server Rechner muß ein /customer Verzeichnis mit Schreib-/Leserechten
für alle eingerichtet werden.

Auf dem WebCheck-Server Rechner sollte ein Benutzer 'user' mit den selben Einstellungen
wie der allgemeine Benutzer 'user' auf den Impose2000-Servern eingerichtet werden.
Sie können auch einen anderen Standarduser als 'user' verwenden. Z.B. könnte dieser
'artcom', 'op' etc. heißen. Es ist lediglich wichtig das dieser User dann auch auf dem
WebCheck-Web-Server genauso eingerichtet wird.
Unter diesem Benutzernamen (Accout) erfolgt die interne Kommunikation zwischen den
Impose2000 Servern und dem WebCheck Server per ssh. Deshalb muß ssh-Zugang
mit dieser User-ID (also z.B. 'user' oder 'artcom') vom Impose2000-/Workflow-
Server zum WebCheck-Server ohne weitere interaktive Abfrage (z.B. Passwort etc.)
 möglich sein. Stichwort "ssh-keys"

Für den Anschluß bzw. die Bekantgabe der Impose2000 Serverrechner zuständig ist die
Datei /customer/artnet-server.cfg (auf dem Web-Serverrechner)

Beispiel (findet sich auch im unter Punkt "Beteiligte WebCheck relevante Konfigurationsdateien"
beschriebenem Paket):


##############################################################################
# S M T P - S e r v e r  - Eintrag:
# Lediglich der Name des Servers oder dessen IP-Nummer. Dieser
# muss vom WebCheck-WEB-Serverrechner erreichbar sein.
#
# Format:
#
# SMTP_SERVER = {
#      NAME = "<smtpservername>";
#      AUTH_USER = "<smtp_auth_user>";   (optional, only if needed)
#      AUTH_PWD = "<smtp_auth_pwd>";     (optional, only if needed)
# }
#
# Beschreibung:
#    <smtpservername>: Name des SMTP-Mail Servers
#    <smtp_auth_user>: (optional entry) if your SMTP-Mail server needs Auth-
#                      tentification place the user id here.
#    <smtp_auth_pwd> : (optional entry) if your SMTP-Mail server needs Auth-
#                      tentification place the password here.
#
# S o f t p r o o f  - Eintrag:
# Einstellungen, die das Softproof betreffen. Wenn dieser Abschnitt
# fehlt, gibt es kein Softproof.
#
# Format:
#
# SOFTPROOF = {
#    MODE = <mode>;                      (optional)
# }
#
# Beschreibung:
#    <mode>: (optional angebbar) Modus, in dem WebCheck ausgefuehrt werden soll
#             Moegliche Werte sind derzeit:
#             1: webcheck (default)
#             2: softproof (noch nicht implementiert)
#             3: webcheck+softproof
#
# A N - S e r v e r  - Eintraege
# Mapping von (Eingangs-)URLs auf die anzusprechenden WebCheck-
# Server-Rechner. Fuer erfolgreiches 'matching' reicht es aus
# das die hier eingetragenen <proxy-URL>-Segmente (mit Proxy)
# bzw. die <URL> Segmente (keine Proxy) in der zu testenden
# URL vorkommen. Gleichheit ist dazu nicht erforderlich.
# Das erste 'matching' gewinnt.
# Es koennen eMail-Adressen angegeben werden, die von der WebCheck-
# WEB-Seite benutzt wird um Mitteilungen des End-Users ueber Auftraege
# und deren Seiten etc. an die Impose2000-Bearbeiter zu senden.
# Es kann ein alternativer Port angegeben werden, dieser
# muss auf der Serverseite entsprechend konfiguriert sein.
# Ist kein Port angegeben (sollte der Default sein), so wird
# der Standard-Port des WebCheck-Servers benutzt.
#
# Format:
#
# AN_SERVER = {
#    URL = "<URL>";
#    PROXY_URL = "<proxy-URL>";          (optional, sonst "" setzen)
#    NAME = "<servername>";
#    DESC = "<serverdesc>";              (optional)
#    MASTER = "true"                     (optional)
#    EMAIL = "<email-adr>";              (optional)
#    PORT = <port>;                      (optional)
#    DEBUG = <debuglevel>;               (optional)
#    COMPANY_LOGO = "<logo-file>";       (optional)
#    SCALE_LOGO = true|false;            (optional)
#    DONT_OVERLAP_LOGO = true;           (optional)
#    MAX_UPLOAD_SIZE = <in MB>;          (optional)
#    UPLOAD_CONTENT_TYPES = <Mime Types> (optional)
#    REPLACEMENT_FROM = "<from-adr>";    (optional)
#    LOGIN_LOGO = "<logo-file2>";        (optional)
# }
#
# Beschreibung:
#    [<active>] <URL> <proxy-URL> <servername> [<serverdesc>] <email-adr>...
#            ... <port> [<debuglevel>] [<logo-file>] [<in MB>] [<Mime Types>]
#
#    <active> (optional angebbar): true|false Aktivierung/Deaktivierung des
#            Eintrags. Default (wenn nicht vorhanden) ist 'Aktiv'
#    <master> (optional angebbar): true|false Gilt als Master fuer Abfrage von
#            bestimmten Eigenschaften. Stellvertreter fuer alle Server
#
#    <URL>: Das ist die URL (bzw. der vordere Teil der URL), die der
#           WebCheck-Benutzer in seinem Browser eintippt, z.B.
#                 https://www.mycompany.de          oder
#                 https://80.81.82.82:8080/artnet   oder
#                 http://www.mycompany.de/artnet    etc.
#    <proxy-URL>: (optional, ansonsten "" setzen )
#           Beachte: Wird dieser Eintrag benutzt (also Werte ungleich ""),
#           so muss eine entsprechende Behandlung auch im Bereich Apache/Proxy
#           erfolgen!!
#           Dies hier bezeichnet den vom Proxy zu benutzenden benutzte
#           WebCheck-Server-Hostnamen wenn obige URL vom Endbenutzer eingegeben
#           wurde. Also bei einem vorgeschalten Rewriting der URL (Apache)
#           Z.B. "webcheck-server" aber auch "127.0.0.1" etc.
#           Dieser Wert haengt also ab von der Proxykonfiguration des
#           Netzwerks in dem die Server stehen und ist i.d.R. nicht nach
#           aussen sichtbar. Leerstring bedeutet: kein Proxy (Default)
#    <servername>: Server auf dem der I2K-ANserver Prozess laeuft, der
#           von dieser URL angesprochen werden soll.
#           Beachte: Im Multiserverbetrieb gibt es mehrere Serversektion mit der
#           selben URL aber jeweils unterschiedlichen <servername>.
#    <serverdesc>: (optional angebbar): Ein beschreibender Name des
#           Servers der durch die URL angesprochen wird. Dieser Name
#           wird u.U. dem Benutzer im WEB-Interface als Maschinenname
#           praesentiert. Dieser Eintrag sollte nicht zu viele Zeichen
#           enthalten.
#           *** Wird nicht mehr benoetigt *** Obsolet, nicht mehr benutzen.
#    <email-adr>: (optional angebbar)
#           EMail Adresse an die Korrekturmails etc. der Browserbenutzer
#           geschickt werden. Dies ist die Mailadresse der I2K-Bediener
#           Hier kann fuer jeden Impose2000 Server eine andere Adresse
#           eingetragen werden.
#           *** Wird nicht mehr benoetigt *** Die Mailadressen kommen jetzt
#                                direkt aus der WebCheck Benutzerverwaltung
#    <from-adr>: Ersatz 'from'-Mailadresse, die bei Korrekturmails an
#           die Impose2000-Bediener _immer_ statt der aus der WebCheck-
#           Benutzerverwaltung kommenden benutzt werden soll. Das Ganze
#           ist fuer den Fall da, das ausgehende Mails in ihrer 'from'
#           Zeile gefiltert werden und dort nur bestimmte Mail-Addressen
#           akzeptiert werden, die Mail ansonsten zurueck gewiesen
#           werden. Um das zu verhindern kann mittels diesem Parameter
#           eine gueltige, durchgangsfaehige Mail Adresse definiert
#           werden.
#           Leerstring: normale email Addresse aus der Benutzer-
#           verwaltung als 'from'-Eintrag in Korrekturmails verwenden
#    <port>: (optional angebbar) Alternativer Port ueber den eine
#           Verbindung zum Impose2000-ArtNet-Server aufgebaut werden kann.
#           Wenn nicht angegeben dann Default (=5620)
#    <debuglevel>: (optional angebbar): Hiermit koennen Debug-Ausgaben des
#           Servers von 'aussen' gesteuert werden:
#           Wenn nicht vorhanden: Default-Logging Einstellungen;
#           Wenn vorhanden: Werte <= 0: Debugging AUS,
#                           Werte >  0: Debuglevel (sinnvoll: 2 oder 3)
#    <logo-file>: (optional angebbar): Moeglichkeit zur Spezifikation
#           eines Firmenlogo-Bilddatei fuer den anzusprechenden ANserver.
#           Dieses Datei wird dann im Seitenkopf jeder auszugebenden Seite
#           ausser der Login-Seite, montiert .
#           Ist keine Logodatei angegeben, so wird ein WebCheck-Defaultlogo
#           verwendet. Notwendige Spezifikation:
#                * Typ: JPG, GIF, PNG
#                * die Datei sollte unter /customer liegen, dann reicht der
#                  bloße Name aus, z.B. "banner.jpg" Bei einer anderen
#                  Position im Filesystem muss ein absoluter Pfad angegeben
#                  werden.
#    <logo-file2>: (optional angebbar): Moeglichkeit zur Spezifikation
#           einer Server-/URL-spezifischen LoginLogo-Bilddatei fuer den
#           anzusprechenden ANserver. Wird dieses angegeben, so uebersteuert
#           dies eine Datei in /customer.
#    <scalelogo> (optional angebbar): true|false: Logo wird skaliert statt
#           rechts Auffuellen mit Weiss. bzw. Beschneiden (Default: false)
#    <dontoverlaplogo> (optional angebbar): true: Logo wird nicht durch
#           Karteikartenreiter ueberlagert (Default: false)
#    <in MB>: (optional angebbar): ganzahliger Wert in MB. Bei Uploads werden
#             Dateien, die groesser sind als dieser Wert zurueckgewiesen.
#             Defaultwert ist momentan 1 GB. Dieser Wert muss unterhalb von
#             2 GB liegen! Hoehere Werte werden ignoriert.
#    <Mime Types>: <MIME type>{,<MIME type>
#    <MIME Type>: (optional angebbar) Uploadbare Dateiformate. Werden hier
#             _zusaetzliche_ MIME Types angegeben, so werden diese zusaetzlich
#             zu dem internen Defaultwert akzeptiert. Interner Default ist
#             momentan "application/pdf,image/jpeg,image/tiff" und Archiv-
#             formate  "application/x-tar, application/zip"
#             D.h. es werden PDF, JPGs und Tiffs akzeptiert. Daneben gibt es
#             noch die Moeglichkeit bestimmte Archivformate hochzuladen
#             Anzugeben ist entweder ein einzelnes Format oder eine per ','
#             verkettete Liste unterschiedlicher MIME Types.
#
# L o g i n  - Logo (per "/customer/artnet_login_logo.jpg"):
# Unabhaengig von den Firmenlogo-Eintraegen (s. "<logo-file>") in den
# Serversektionen gibt es noch die Moeglichkeit ein Login-Logo festzulegen.
# Dieses erfolgt jedoch nicht innerhalb der Server-Konfigurationsdatei,
# sondern durch Platzierung einer Datei in /customer:
#   Wird im /customer - Verzeichnis eine Bilddatei "artnet_login_logo.jpg"
#   abgelegt, so wird diese als Login-Logo in dem Login-Formular platziert.
#   Das dermassen definierte Login-Logo erscheint NUR auf der Login-HTML.
#   NACH einem Login erscheint dann im Seitenkopf der folgenden Formulare
#   das konfigurierte  K u n d e n  - Logo des jeweiligen Servers (bzw. das
#   WebCheck-Defaultlogo wenn keine Kundenlogos konfiguriert sind).
# L o g i n  - Logo (per "<logo-file2>" in Serversektion):
# Hiermit kann fuer jede URL ein gesondertes Login-Logo definiert werden:
#   Dies uebersteuert ein generell definiertes Login-Logo welches per
#   "/customer/artnet_login_logo.jpg" definiert wurde (s. oben).
#   Es wird der erste gefundene Eintrag fuer eine bestimmte URL benutzt, also
#   i.d.R. der des Masterservers. Somit ist das nicht echt Serverabhaengig,
#   sondern eigentlich an die URL gekoppelt
#
# F i r m e n  - Logo (per "<logo-file>" in Serversektion):
# Wie oben beschrieben wird das Firmenlogo fuer den (I2K-)ANserver in der
# jeweiligen Serversektion angegeben. Dieses erscheint am Kopf jeder Seite
# und kennzeichnet den der aktuellen ArtNet-Sitzung zugeordeten Firmenrechner.
#
# K u n d e n  - Logo (per I2K-WebCheck-Benutzerverwaltung):
# Das Kundenlogo kann in der WebCheck-Benutzerverwaltung des jeweiligen
# Impose2000-Rechners (ANserver-Rechner) jeweils einem Benutzer zugeordnet
# werden. Sofern fuer die jeweiligen Benutzer ein Kundenlogo eingetragen ist,
# wird dieses zusammen mit dem Firmenlogo, links neben diesem, also ebenfalls
# im Seitenkopf angezeigt. Aus diesem Grund sollte die Groesse Kundenlogos
# relativ beschraenkt bleiben.
# Im Seitenkopf wird das Kundenlogo linksbuendig und das Firmenlogo
# rechtsbuendig platziert. Vertikal wird jeweils mittig im Gesamtlogobereich
# ausgerichtet.
##############################################################################
# Beispiel:
#
# AN_SERVER = {
#     URL = "https://www.mycompany.de";
#     PROXY_URL = "webcheck-server";
#     NAME = "i2k_server1";
#     DESC = "mycompany";
#     EMAIL = "i2k-team@mycompany.de";
#     PORT = 5620;
#     DEBUG = 3;
#     COMPANY_LOGO = "mycompany-logo.jpg";
#     MAX_UPLOAD_SIZE = 100;
#     UPLOAD_CONTENT_TYPES = "image/tiff";
#     LOGIN_LOGO = "mylogin-logo.jpg";
# }
#
# SMTP_SERVER = {
#    NAME = "mailhost";
# }
#
# #Ende Konfigurationsdatei

AN_SERVER = {
     URL = "https://www.mycompany.de/artnet/";
     PROXY_URL = "";
     NAME = "i2k_server-1";
     COMPANY_LOGO = "customer_logo.jpg";
     DEBUG = 2;
}

AN_SERVER = {
     URL = "https://www.mycompany.de/artnet/";
     PROXY_URL = "";
     NAME = "i2k_server-2";
     COMPANY_LOGO = "customer_logo.jpg";
     MAX_UPLOAD_SIZE = 100;
}

SMTP_SERVER = {
     NAME = "mailhost";
}
# Ende

Die genannten Logo-Datein sollten in /customer liegen oder müssen mit absolutem Pfad genannt sein.
Wir empfehlen die Ablage in /customer

Beachte: Beim Neuaufsetzen eines Web-Servers sollten alle optional angebbaren Schalter zunächst
              einmal weggelassen werden. Diese werden dann intern mit sinnvollen Defaults versehen.
              Gleiches gilt für die angebbaren Kunden- und Firmenlogos.

Aktivierung von Firmen- und/oder Kundenlogos

Da es hier diverse Einstellmöglichkeiten gibt hier eine Kurzbeschreibung.

Firmen-Logos werden in der WebCheck-Server-Konfigurationsdatei /customer/artnet.server.cfg auf dem
(WebCheck-)WEB-Server-Rechner konfiguriert. Hierzu ist ein entsprechenden Bild im Format JPEG (alternativ
gingen auch PNG oder GIF) zu erzeugen, z.B. customer_logo.jpg oder banner.jpg etc.
Dieses ist dann, mit 'world'-Leserechten zu versehen und wie oben angegeben in der Serversektion einzutragen.

Kunden-Logos werden in der WebCheck-Benutzerverwaltung den Impose2000-Server-Rechnern den
einzelnen Kunden (User) Logins zugeordnet. Zulässig sind hier nur JPG/PNG mit bis zu 100 Pixel
in der Breite/Höhe

Der Normalfall:
  1. Ist das Firmen-Logo eine JPG-/PNG-Datei, und ist ein Kunden-Logo definiert, so wird das
    Kunden-Logo linksbündig und das Firmen-Logo rechtsbündig im Kopf aller Seiten platziert.
  2. Ist das Firmen-Logo definiert, aber fehlt das Kunden-Logo, so wird nur das Firmen-Logo
    rechtsbündig platziert.
  3. Ist das Firmen-Logo nicht definiert aber ein Kunden-Logo, so wird nur das Kunden-Logo
    linksbündig platziert.
  4. Ist weder ein Firmen-Logo definiert noch ein Kunden-Logo definiert, so wird ein WebCheck-Default
    Seitenkopf verwendet.

Externer Zugang

Beispielsweise gilt:
Per https://www.mycompany.de/artnet/ landet man auf dem Web-Server in der WebCheck-Applikation.
Dazu macht der Apache-Server auf dem Internet-Gateway-Rechner eine Weiterleitung auf den eigentlichen
WebCheck-Server-Rechner. Z.B. von https://www.mycompany.de/artnet/*
nach http://mycompanyproxy:8080/artnet/* ("mycompanyproxy" ist ein Alias für den eigentlichen
WebCheck-Server).

Dazu ist folgendes in /etc/apache2/sites-available/www.mycompany.de konfiguriert. Zunächst werden in
der Konfiguration für Port 80 (http) Zugriffe nach https umgeleitet. (Unverschlüsselte Verbindungen sind
ein Sicherheitsrisiko!)

ACHTUNG: Der Slash in der linken Seite der RewriteRule darf auf gar keinen Fall vergessen oder absichtlich weg gelassen werden. Dadurch könnten beliebige Server aus einem internen Netz außen zugänglich werden. Siehe auch CVE-2011-3368. 

# Requests an den WebCheck-Server werden in https umgeschrieben:
RewriteRule ^/artnet$     https://www.mycompany.de/artnet/   [L]
RewriteRule ^/artnet/(.*) https://www.mycompany.de/artnet/$1 [L]
In der Konfiguration von Port 443 (https) erfolgt die Weiterleitung auf den webcheck-Server im internen Netz: 
# Requests an den WebCheck-Server:
RewriteRule ^/artnet$     https://www.mycompany.de/artnet/   [L]
RewriteRule ^/artnet/(.*) http://mycompanyproxy:8080/artnet/$1 [P,L]

Der WebCheck-Server kann anhand des Rechnernamens - mycompanyproxy - erkennen, für welchen
Impose2000Server (sofern mehrere) das Login erfolgen soll, und entsprechend anders reagieren.

WebCheck-Server auf der Impose2000 Seite (ANserver)

In unserem Beispiel:
Auf dem WebCheck-Server Rechner sind momentan i2k_server-1 und i2k_server-2 als Impose2000-
Server konfiguriert.


Diese Server müssen über eine WebCheck-(ArtNet-)Lizenz verfügen. Ggf. ist auch noch eine
SoftProof Lizenz notwendig (SoftProof Funktionalität erst ab ArtCom-Softwareversion 18.2)
Für die Benutzung der neuesten WebCheck-Version wird auf den angeschlossenen Impose2000
Servern ein Softwarestand von 18.2 oder neuer benötigt.


Von diesen Servern aus müssen ssh Verbindungen mit der ID des Standard-Users, also z.B. 'user' oder 'artcom'
zu dem WebCheck-Server zulässig sein. Nochmals: ssh-Zugang mit dieser User-ID muß vom Impose2000-/
Workflow-Server zum WebCheck-Server ohne weitere interaktive Abfragen (z.B. Passwort etc.) möglich sein.
Stichwort ist hier "ssh-keys"
 
ANserver Start konfigurieren:

Auf dem Impose2000- bzw. Workflow-Server muß der ANserver - Demon unter der selben Standard-User-ID,
also beispielsweise 'user' oder 'artcom', gestartet werden. Der Start dieses Demon muß/sollte über das
init-System konfiguriert sein, damit dieser immer automatisch mit/wieder gestartet wird.

Hinweise wie das zu machen ist, finden sich in folgenden Dateien:
     bitslib/env/etc_event.d_template_anserver  für upstart (z.B. UBUNTU)
     bitslib/env/etc_inittab_template           für klassisch initd (SuSE)
Beachte:
 
ANserver-Binary und WebCheck Baustein existieren nur bei vorhandener WebCheck/ArtNet-Lizenz.


Auf diesen Serverrechnern müssen:

  • WebCheck, Impose2000, Auftragsfreigabe global eingeschaltet werden:
         "I2K" - "Ansicht" - "globale Voreinstellungen" dort Karte "Modi" - "Auftragsfreigabe über ArtNet"

  • WebCheck Benutzer und Firmen definiert werden "I2K" - "Extras" - "ArtNet-Benutzerverwaltung"
        Beachte: die hier zu definierenden Benutzer sind nur für den Zugriff über das WebCheck-Web auf
       die Impose2000 Aufträge bzw. Workflows zuständig und werden auch nur dort benutzt. Sie müssen
       (besser: dürfen) keine Entsprechung mit auf dem Servern vorhandenen normalen Benutzer-Accounts
       wie 'user' oder 'artcom' etc. haben. Hier sind beliebige Namen/Kürzel und Passwörter möglich, die
       über die ArtNet-Benutzerverwaltung erzeugten User müssen auch keine Accounts auf den
       Serverrechnern haben.

       Aus Sicherheitsgründen sollten hier auch keine Benutzer und/oder Passwörter Kombinationen
       definiert werden, die irgendwelchen Accounts auf den Servern oder allgemein im Intranet
       entsprechen.

  • per WebCheck zu überwachende Aufträge entsprechend freigeschaltet werden:
          "I2K": Auftrag anwählen dann "Datei" - "ArtNet-Zuordnung"

  • WebCheck, Workflow Aktivierung: Wenn eine gültige WebCheck Lizenz vorhanden ist, ist im Workflow-
       Manager ein "ArtWeb-Check" Baustein auswählbar. Innerhalb dieses Bausteins können dann weitere
       Konfigurationen bzgl. WebCheck, wie Benutzer etc. gemacht werden.


    • Mailing

    Vorgehen um den Bereich "EMail" im WebCheck Bereich funktionabel zu machen (Auszug aus
    einem issue - Eintrag):


    ** WebCheck-Server (WEB-/Browser-)Seite):

       Hiermit wird der Versand von Korrekturmails der Browserbenutzer in Richtung
       des Impose2000-Servers, also i.d.R. an die I2K-Bediener, definiert.
       

       - der Eintrag "EMAIL" in der Serverkonfigurationsdatei braucht nicht mehr
         eingetragen zu werden. Diesen am besten wegmacheni, da diese Information
         jetzt aus der Impose2000-WebCheck Benutzerverwaltung kommt.
         Diese Adresse wurde früher für Korrekturmails den End-(Browser-)
         Benutzers an den I2K-Operator benutzt.

       - es muß ein gültiger SMTP-Mailhost eingetragen werden


    ** Impose2000:

       Mails über fürs WebCheck freigegebene Aufträge, zur Beurteilung bereitstehender Seiten
       eines Auftrags, zur Wiedervorlage bereitstehende Seite etc. Also Mails von den
       I2K-Bedienern bzw. aus der Impose2000-Anwendung/ArtRobot an die Browserbenutzer.
     
       (1) Unter "Extras"-"ArtNet Benutzerverwaltung"
     
         - ...können in der oberen Hälfte des Formulars die Firmen und für
           diese die End-(Browser)-Benutzer eingetragen werden, die Zugriff
           auf Aufträge haben sollten.
           Diese werden mit ihrem Namen und EMail-Adresse eingetragen. 
           Diese EMail-Adressen werden für die "Der Auftrag xy wurde für Sie
           freigegeben..." etc. Mails benutzt.

         - Im unteren Teil des Formulars werden die I2K-Operatoren eingetragen,
           an die die Korrekturmails der End-(Browser-)Benutzer gehen, definiert.
           hier könnten unter einem symbolischen I2K-Operatornamen mehrere
           Adressen eingetragen werden.

       (2) "Mailhost" und "SMTP-Server" im unteren Teil des Formulars. generelles
            Vorgehen:
            
            Es werden keine Mails gewünscht:

                Feld "Mailhost" leer lassen
                Feld "SMTP-Server" leer

            Mails erwünscht:

                Feld "Mailhost": 'localhost' eintragen
                Feld "SMTP-Server": einen funktionierenden SMTP-Mailhost eintragen (Normalfall)
                               oder wenn leer dann werden Mails nur lokal zugestellt (Ausnahme)

       (3) Unter "Datei"-"ArtNetZuordnung" werden die Email-Adressen von
           I2K-Operator und End-(Browser-)Benutzer dann für einen Auftrag
           quasi zusammengeführt:
      
         - hier kann dann für eine ausgewählten Auftrag der "Kunde" (=Firma)
           definiert werden. Dessen eingetragenen End-(Browser-)Benutzer
           erhalten dann jene besagten "Der Auftrag xy wurde für Sie..." etc.
           Mails.
         
         - Darüber hinaus wird der zuständige I2K-Operator ("Impose-Op")
           eingetragen, dieser erhält alle Korrekturmails von den End-(Browser-)
           Benutzern an die in (1) eingetragene(n) Adresse(n)

         - Zusätzlich kann noch ein BCC-Adressat eingetragen werden. Dieser
           erhält ebenfalls alle Mails. Dies war ein Kunden-Wunsch
           für Kontroll-/Überwachungsaufgaben. Hier können, für den Endbenutzer
           unsichtbar, alle Korrekturmails etc. gesammelt werden usw.

         - Daneben wird in diesem Formular noch das Upload-Verzeichnis für diesen
           Auftrag festgelegt sofern Uploads durch den End-(Browser-)Benutzer
           möglich sein sollen. Wird hier ein Verzeichnis definiert, so wird
           auf der WebCheck-Web Seite für diesen Auftrag ein Upload-Knopf sichtbar
           mit dem Dateien auf den Impose2000 Server geladen werden können.


    Beteiligte WebCheck relevante Konfigurationsdateien

    Beispieldateien finden sich in einem Paket artnet-configuration-examples.tar auf unserem
    FTP Server:
    /ftp/pub/webcheck/artnet-configuration-examples.tar


    webcheck-server:

    /customer
           artnet-server.cfg   ...Server Konfigurationsdatei, Anschluß der Impose2000 Server
           artnet-userprefs/      ...leer, wird vom WebCheck gefüllt. Einstellungen der einzelnen Benutzer
           artnet-mail-template_DE.cfg   ...für Korrekturmails an Impose2000-Bediener
           artnet-mail-template_EN.cfg   ...ist in verschiedenen Sprachen konfigurierbar
           artnet-mail-template_ES.cfg
           CMYKSource.icc ...ICC Quell-Beispielprofil für Softproof Modus
           CMYKDest.icc ...ICC Ziel-Beispielprofil für Softproof Modus
           ENABLE_SOFTPROOF   ...ohne Inhalt, nur Flag. SOFTPROOF-Fkt. für Workflow-Anzeige
           artnet-env.cfg   ...globale Einstellungen für das WebCheck (z.B. Sprache im Loginfenster etc.)

    impose2000-server:

    $AC_CUSTOMER/

        webcheck/production/mail-templates/* ...sprachabhängige Templates für Impose2000 Mails an die Browserbenutzer.
    Hier gibt es eine feste Namenskonvention:
        checkRequest_EN.cfg
        corrected_EN.cfg
        forCorrection_EN.cfg
        order_EN.cfg
        pages_EN.cfg
        webcheck/preprint/mail-templates/ ...sprachabhängige Templates für Impose2000 Mails an die Browserbenutzer
    können hier definiert werden. Die Basisnamen der templates sind frei wählbar, weil die Zuordnung zu den
    in preprint.cfg definiert werden. Lediglich das Sprachkürzel (s.u.) und der Suffix (.cfg) sind fest.

        ArtNet.users    ...berechtigte Benutzer, wird von der Impose2000 Benutzerverwaltung gefüllt

    Zulässige andere Sprachkürzel sind  "_DE": deutsch, "_EN": englisch, "_FR": franz., "_ES": spanisch,
    "_PT": portugiesisch, "_IT": italienisch


    Mehrere Instanzen von JBoss, mehrere WebCheck Versionen parallel

    Unter speziellen Gegebenheiten ist es notwendig mehrere JBoss Instanzen parallel betreiben zu können.
    In diesem Abschnitt wird beschrieben wie der Betrieb mehrerer JBoss- und damit WebCheck-Instanzen
    auf einem Server einzurichten ist. Die Ansteuerung der unterschiedlichen Instanzen erfolgt z.B. über die
    Benutzung unterschiedlicher URLs. Hierzu sind ggf. weitere Konfigurationsarbeiten außerhalb der
    JBoss - Installation zu machen. Bspw. Redirecting in der Apache Konfiguration u.ä.

    Verschiedene Instanzen des JBoss werden über verschiedene (JBoss-)Server Konfigurationsverzeichnisse
    unterhalb des JBoss Basisverzeichnisses, also in unserem Beispiel unterhalb von "/usr/local/jboss-4.0.3RC1/server"
    definiert.

    Ausgehend von einer bereits laufenden 'single'-JBoss Installation ist folgendes zu machen:

    (1) Kopieren des 'default' Konfigurationsverzeichnisses nach 'default2'

    cd /usr/local/jboss-4.0.3RC1/server
    mkdir default2 ; chmod 777 default2
    cd default ; tar cf - * | (cd ../default2 ; tar xvf -)

    (2) Konfiguration der zweiten Instanz anpassen:

    cd /usr/local/jboss-4.0.3RC1/server/default2/conf
    vi jboss-service.xml

    dort nach der Sektion "ServiceBindingManager" suchen. Diese ist bei bisheriger Standardkonfiguration
    des JBoss auskommentiert und muß jetzt aktiviert werden. Dazu bspw. die Sektion kopieren und unterhalb
    des Kommentares platzieren.

    Zu Ändern ist folgendes:

        <attribute name="StoreURL">file:../server/port-bindings.xml</attribute>

    die dermaßen bezeichnete Datei werden wir gleich herstellen. Diese definiert das Mapping der Ports
    auf die neuen Instanzen.

    "jboss-service.xml" sichern und Editor verlassen.

    (3)  Erzeugung der Port-Mapping Datei:

    Diese findet sich als Beispieltemplatedatei bereits vorkonfiguriert innerhalb des JBoss Verzeichnisses

    cd     /usr/local/jboss-4.0.3RC1/server
    cp ../docs/examples/binding-manager/sample-bindings.xml ports-bindings.xml

    da diese bereits vorkonfiguriert ist, sind keine weiteren Änderungen an der Datei notwendig.

    (4) Portnummern:

    Nach wie vor ist die erste Instanz 'default' unter der Portnummer 8080 ansprechbar.
    Die zweite Instanz hat die Portnummer 8180 die dritte hätte 8280 usw., sofern das
    vordefinierte Mapping in "ports-bindings.xml" nicht verändert wird. Für die https-
    sowie alle anderen JBoss Ports gilt entsprechende Hochzählung gleichermaßen.
    Also bspw. 8443 (HTTPS der ersten Instanz), 8543 (HTTPS der zweiten Instanz) usw.

    (5) Deploy, Log & Co.:

    Bzgl. Log-Datei, Deployen etc. gilt das selbe wie für den Einzelinstanzbetrieb, nur das statt
    /usr/local/jboss-4.0.3RC1/default eben /usr/local/jboss-4.0.3RC1/default2 benutzt werden
    muß. Insbesondere können aber jetzt unterschiedliche WebCheck-Pakete in die jeweiligen
    'deplo' Verzeichnisse deploy't werden. Da auch sämtliche während der Betriebs des WebCheck
    benötigten Temporärdaten/-dateien unterhalb dieser Verzeichnisse verwaltet werden, sind
    die Instanzen komplett logisch getrennt betreibbar. Gemeinsam sind ihnen lediglich die
    Konfigurationsdateien in /customer, bspw. "artnet-server.cfg" oder die Logo- und Mailtemplate-
    Dateien.

    (6) Zweite JBoss Instanz starten:

    cd /    usr/local/jboss-4.0.3RC1/bin
    ./run.sh -c default2

    (7) Zweite JBoss Instanz stoppen:

    cd /usr/local/jboss-4.0.3RC1/bin
    ./shutdown.sh -s jnp://localhost:1199

    ...auch bei dieser (Name-Binding-)Portnummer gilt der 100er Offset, d.h. die erste Instanz wäre
    mit 1099, die Zweite eben mit 1199, die Dritte mit 1299 usw. zu stoppen.

    Das Hoch- und Runterfahren der unterschiedlichen Serverinstanzen kann auch über /etc/init.d
    erfolgen. Dann wird das auch beim Booten des Servers automatisch gemacht.
    (Vgl. Abschnitt "JBoss Serverstart"-"Auto")
    Für den Mehrinstanzbetrieb gibt es hier bei uns ein speziell angepaßtes Script "jboss" zur
    Benutzung  über /etc/init.d
    Sie    he:  /opt/artcom/current/env/etc_init.d_artcom-jboss_multiserver_template

    Apache Konfiguration, sofern notwendig


    Das folgende ist ein Text von Heiko (und Peter):

    Die Apache-Konfiguration ist jetzt meiner Meinung nach fertig.
    Es sei denn, der Kunde möchte sich seinen SSL-Key noch zertifizieren lassen. Wenn man eine http-URL benutzt,
    wird man nun automatisch nach https umgeleitet. Folgendes musste ich tun, damit das funktioniert:
     
    sudo -s
    cd /etc/apache2/mods-enabled
         ln -s ../mods-available/proxy.conf
    ln -s ../mods-available/proxy_http.load
    ln -s ../mods-available/proxy.load
    ln -s ../mods-available/rewrite.load
    ln -s ../mods-available/ssl.conf
         ln -s ../mods-available/ssl.load
    vi /etc/apache2/sites-available/webcheck
         # Weitgehend von Printer Barcelona geguttenbergt.
         # Nur den Abschnitt für Port 80 musste ich neu erfinden.
         cd /etc/apache2/sites-enabled
         ln -s ../sites-available/webcheck
         rm 000-default
         mkdir /etc/apache2/ssl
         cd /etc/apache2/ssl
         openssl genrsa -des3 -out server.key 1024
         # Pass phrase: xyz (hier das richtig benutzen)
         openssl rsa -in server.key -out server.pem
         # Pass phrase eintippen
         openssl req -new -key server.key -out server.csr
         # Pass phrase eintippen
         # Daten in den Certificate request eintippen. Da bin ich immer unsicher,
         # wo man was hinschreiben muss. Die diversen Akzente im Unternehmensnamen
         openssl x509 -req -days 1825 -in server.csr -signkey server.key -out server.crt
         # Pass phrase eintippen
         chmod 600 *
         /etc/init.d/apache2 stop
         /etc/init.d/apache2 start

    Nach einer Änderung der /customer/artnet-server.cfg und dem danach nötigen Neustart des jboss mittels
    sudo /etc/init.d/jboss restart
    war es mir möglich, mich einzuloggen.

    Für das Einloggen aus dem internen Netz ist vermutlich ein weiterer Eintrag in /customer/artnet-server.cfg erforderlich,
    bei dem dann eine weitere 127.0.0-er Nummer (nicht 127.0.0.1 !!) als PROXY_URL benutzt werden muss.


    Beispiel site-Datei von Printer Portugesa (Beachte: Domainnamen sind modifiziert):

     
    NameVirtualHost *:80
    NameVirtualHost *:443


    ## LogLevel debug

    <VirtualHost *:80>
        ServerName www.webcheckmycompany.com
        RewriteEngine On
        RewriteRule ^/(.*) https://www.webcheckmycompany.com/$1 [R,L]
        RewriteLog /var/log/apache2/rewrite.log
        ProxyVia on
    </VirtualHost>

    <VirtualHost *:443>
        ServerName www.webcheckmycompany.com

        SSLEngine on
        SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
        SSLCertificateFile /etc/apache2/ssl/server.crt
        SSLCertificateKeyFile /etc/apache2/ssl/server.pem

        RewriteEngine On
        RewriteRule ^/(.*)  http://127.0.0.1:8080/artnet/$1 [P,L]

        ErrorLog  /var/log/apache2/error.log
        CustomLog /var/log/apache2/access.log combined
        <Location />
            Order allow,deny
            Allow from all
        </Location>
        SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
    </VirtualHost>
    ** Dokumentende **