TIPS for the setup of a WebCheck server with JBoss 4.0.3

(this document: ..internal/intranet/docs/WebCheck-Einrichtung.html)

This is an unofficial document without making claim to be complete or correct

The guildlines for the JBoss installation here in this doc are valid for the JBoss 4.0.3 only.
Note: the JBoss AS7 installation is different from 4.0.3.

Vers. January, 16, 2012, ArtCom GmbH Bremen


  1. TIPS for the setup of a WebCheck server
    1. Preliminary remarks
    2. Setting up a WebCheck server
    3. Installing JBoss
    4. Configuring JBoss
      1. Network access problems
      2. Problems with heap size: "Exception java.lang.OutOfMemoryError: Java heap space"
    5. Securing JBoss Admin access with passwords
      1. (1) Direct change
      2. (2) Using the archive file
      3. Changing the password
      4. Admin console: extend the GET/POST-request blocking to all HTML-requests
      5. Saving the JMX Invoker with admin password
      6. Deleting the HTTP-Invoker
    6. Setting JBoss to another port than 8080 (Tomcat Connector)
    7. Starting the JBoss server
    8. Log files
    9. Deploying (installing) the WebCheck package
    10. Write permissions
    11. Customer-specific configuration of the WebCheck server
      1. General notes
      2. Activating company and/or customer logos
    12. External access
    13. WebCheck server on the Impose2000 side (ANserver)
    14. Mailing
    15. Involved configuration files relevant to WebCheck
    16. Several instances of JBoss, several versions of WebCheck in parallel
    17. Apache Konfiguration, if needed

Preliminary remarks

The names "ArtNet" and "WebCheck" are identical. This is true especially for the folder names.
The official name of the product is "WebCheck"

This document is intended to help you with the installation and no official documentation.

Setting up a WebCheck server

A 'normal' WebCheck installation consists of a WebCheck computer, a server computer and one or more (via network)
 connected Impose2000 server computers.
 
Based on a newly set up Web server computer you have to carry out the following steps that are described in more
detail below:

for security reasons you may want to keep an eye on the following aspects:

Installing JBoss


Starting with SuSE 10 you find JBoss only in the SuSE Enterprise version.As a result you have to download it
directly from http://www.jboss.com/downloads/index.
The current version is JBoss 4.2.0
Check http://www.jboss.com/docs/index for ducumentation.

We have made good experiences with version 4.0.3RC1, you can also find this package at
/ftp/pub/webcheckJBoss/jboss-4.0.3RC1-installer.jar or
/ftp/pub/webcheck/JBoss/jboss-4.0.3RC1.tar
on out FTP server

This package and JBoss in general need Java 1.5 or Java 5 or higher.

Installing JBoss:

Configuring JBoss

Network access problems

There has been just one single case when JBoss 4.0.3RC1 was installed and problems with the network access
occured with the computer that JBoss was installed on. About 50% of the packages were lost. This problem did
not occur in other instances, because the multicasting hat not been activated for other reasons (error).

In the end the actual reason was discovered as follows (excerpt from an e-mail):

...since the problem has obviously been caused by the multicast packages sent by JBoss 
we have now disabled the multicasting on the JBoss computer in the JBoss configuration.
The multicasting is only necessary if you have several JBoss server. It all boils down
to these two files:
/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
There you have to replace ip_mcast="true" with ip_mcast="false".
Our changes appear to work. A ping <IP number> shows no more failures even
with JBoss running.

This step should be taken for all installations.

Problems with heap size: "Exception java.lang.OutOfMemoryError: Java heap space"

By default the heap spike of JBoss or the Java VM started from it is defined with 128MB. When several users are
logged into the WebCheck this amount may not be sufficient. You can configure a higher amount by changing the
JBoss configuration file 'run.conf': 

/usr/local/jboss-4.0.3RC1/run.conf:

#
# Specify options to pass to the Java VM.
#
if [ "x$JAVA_OPTS" = "x" ]; then
JAVA_OPTS="-server -Xms128m -Xmx128m"
fi


This is where you can set the maximum value to 512 or 1024, i. e. "-Xmx1024m", depending on the size of the
available memory. You have to consider that these statements are only carried out if JAVA_OPTS has not been
set at another position before run.sh has been called. On the JBoss Web Console you can control the change of
this value after restarting JBoss.

Securing JBoss Admin access with passwords

Unfortunately the JBoss server is 'open' after the installation, i. e. it is possible to access the JMX and web
(management) console without entering user ID and password.

For security reasons at least these access options should be password protected.

You can do this either directly or use already edited files from a tar archive.

(1) Direct change

To this end you have to take the following steps (excerpt from a document:
cf. http://jboss.org/community/docs/DOC-12190 for more detailed information)

In a shell window you should do the following (Attention: $JBOSS_HOME is in our case
/usr/local/jboss-4.0.3RC1, so first of all:

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

or use instead of "$JBOSS_HOME" the path and then:

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


Once you have made these changes and click on the JMX or web console, you are asked for a
user ID and a password. The user ID is 'admin' and the the password should be assigned
individually (see below).

(2) Using the archive file

You find the already adjusted JBoss configuration files in an archive
/ftp/pub/webcheckJBoss/security-update-JBoss-4.0.3RC1-artcom.tar
on our FTP server

unpack the security-update-JBoss-4.0.3RC1-artcom.tar:

security-update-JBoss-4.0.3RC1-artcom.tar e. g. to /tmp:

Changing the password

In both cases you have to customize the 'admin' password:

Then you have to replace the admin=<mysecretpassword> with the desired password, i. e. Replace
the part to the right of '=' („<mysecretpassword>“) with the desired password). Set the access
rights for these files to '640'

Admin console: extend the GET/POST-request blocking to all HTML-requests

In /usr/local/jboss-4.0.3RC1/server/default/deploy/jmx-console.war/WEB-INF/web.xml
in the 'security-constraint' Section, remove the lines
        <http-method>GET</http-method>
        <http-method>POST</http-method>
and restart the JBoss. Now all HTML requests will be blocked on the admin console

Saving the JMX Invoker with admin password

(optional, no must)

These invokers are used to e. g. Shut down the JBoss server and similar externalqueries. You can
configure them in a way that they are only possible with a password. These queries/actions are also
not possible via the JBoss interface, as a result you do not have necessarily have to secure them.
If you do want to secure it, though, you have to do the following:

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

change / incomment the text block from

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

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

(take note of the additional "-->" and "<!--").

Now you can shut the server only down by entering an ID and a password, e. g.

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

"<mysecretpassword>" needs to be set accordingly (see above).

The previously possible ./shutdown.sh -S will cause an error.

Deleting the HTTP-Invoker

(optional, no must, probably harmful because desired HTTP accesses may not be possible anymore)

The HTTP-Invokers basically allow the access from the outside to the JBoss server computer. If this access
is not necessary, you can delete the HTTP-Invoker.
To this end you have to do the following:

delete the folder /usr/local/jboss-4.0.3RC1/server/default/deploy//http-invoker.sar

Setting JBoss to another port than 8080 (Tomcat Connector)

If you need to be able to access the WebCheck from another port number than 8080 you have to do the following
(we prefer 8080):


For security reasons you should use the default HTTP port 80 as the WebCheck server port only after
taking additional security measures.

In addition you have to be aware that port number below 1024 of the JBoss server need to be run under
the root ID which is not advisable for security reasons.

It is also highly recommended not to run the WebCheck server computer (also ArtCom „cube“, etc.) directly at
the internet or port 80. Least of all you should secure the computer with a firewall and URL Rewriting, e. g.
with an upstream 'Apache' HTTP server or a proxy.
See the chapter "External access"

Starting the JBoss server

Starting MANUALLY: do the following as root:

AUTO (for SuSE): do about the following as root:


AUTO (for UBUNTU/Debian): do about the following as root:



Log files

You find the log file of the JBoss server under
/usr/local/jboss-4.0.3RC/server/default/log
There: server.log or maybe boot.log. All WebCheck activities are logged in server.log.

Deploying (installing) the WebCheck package

A currently package is located on our FTP server under
/ftp/pub/webcheck/ArtNet.ear

Deploy this ArtNet.ear package, i. e. copy it to
"/usr/local/jboss-4.0.3RC1/server/default/deploy" .

If need be check in "/usr/local/jboss-4.0.3RC1/server/default/log/server.log"

Typing in

http://localhost:8080/artnet

should now open the WebCheck interface (maybe replace 'localhost' by the real web server name)

Write permissions

In the working folder of the WebCheck application
(see above /usr/local/jboss-4.0.3RC1/server/default/tmp/deploy/tmp48606ArtNet.ear-contents/ArtNet.war)
you have to store the working folders with all temporary data, e. g. overview PDF files, created by the
application.   The ANserver also needs write permissions on the Impose2000  computers. That is usually
guaranteed by the WebCheck Java application.

Customer-specific configuration of the WebCheck server

General notes

On the WebCheck server computer you need to create a /customer folder with write/read permissions
for everybody.

On the WebCheck server computer you should create a user 'user' with the same settings as the
general user 'user' on the Impose2000 servers.
You can also user another standard user as 'user', e. g. you could also call that user 'artcom', 'op', etc.
You just have to take care that this user is also created on the WebCheck web server.
With this user name (account) does the system carry out the internal communication between
the Imposer2000 servers and the WebCheck server via ssh. As a result the ssh access with this
user ID (e. g. 'user' or 'artcom') from the Impose2000 / workflow server to the WebCheck server
needs to be possible without any interactive query (e. g. Password, etc.). Keyword: „ssh-keys“.

The file /customer/artnet-server.cfg (on the web server computer) is responsible for
the connection or announcement of the Impose2000 server computer.

Example (you can find it also in the package described unter the point "Involved configuration files
relevant to WebCheck"):


##############################################################################
# S M T P s e r v e r  - Entry:
# Only the name of the server or its IP number. It must
# be within reach of the WebCheck-WEB server computer.
#
# Format:
#
# SMTP_SERVER = {
#      NAME = "<smtpservername>";
# }
#
# Description:
#    <smtpservername>: Name of the SMPT mail server

#
# S o f t p r o o f  - Entry:
# Settings refering to the Softproof. If this section does not exist
# there will be no Softproof.
#
# Format:
#
# SOFTPROOF = {
#    MODE = <mode>;                      (optional)
# }
#
# Description:
#    <mode>: (optional entry) Mode the WebCheck is to be run in
#             Currently possible values are:
#             1: webcheck (default)
#             2: softproof (not yet implemented)
#             3: webcheck+softproof
#
# A N s e r v e r  - Entries
# Mapping of (incoming)URLs on the WebCheck server computer
# to be accessed. Fpr a successful 'matching' it suffices that
# the <proxy-URL> segment (with proxy) or the <URL> segments (no
# proxy) are part of the URL to be tested.
# They do not have to be identical.
# The first 'matching' wins.
# You can use e-mail addresses that are used by the WebCheck
# WEB side to send end users messages about order and
# their pages, etc. to the Impose2000 user.
# You may enter an alternative port, though that has to
# be configured on the server.
# If no port is entered (this should be default, the system
# will use the default port of the WebCheck server.
#
# Format:
#
# AN_SERVER = {
#    URL = "<URL>";
#    PROXY_URL = "<proxy-URL>";          (optional, set "" otherwise)
#    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)
# }
#
# Description:
#    [<active>] <URL> <proxy-URL> <servername> [<serverdesc>] <email-adr>...
#            ... <port> [<debuglevel>] [<logo-file>] [<in MB>] [<Mime Types>]
#
#    <active> (optional entry): true|false Activation/deactivation of the
#            entry. Default (if not present) is 'active'
#    <master> (optional entry): true|false Is master when querying certain
#            settings. Substitute for all servers
#
#    <URL>: This is the URL (or the front part of the URL) that the
#           WebCheck user types into his browser, e. g.
#                 https://www.mycompany.de          or
#                 https://80.81.82.82:8080/artnet   or
#                 http://www.mycompany.de/artnet    etc.
#    <proxy-URL>: (optional, set "" otherwise)
#           Attention: Using this entry (i. e. values other than "")
#           you also have to use a corresponding setting in the
#           section Apache/Proxy!!
#           This refers to the WebCheck server hostname used by the
#           proxy when the URL above is entered by the
#           enduser. Such as with a prepended rewriting of the URL (Apache)
#           E. g. "webcheck-server" but also "127.0.0.1" etc.
#           This value also depends on the proxy configuration of the
#           network that the server is part of and is usually not visible
#           to the outside. Empty string means – no proxy (default)
#    <servername>: Server on the I2K-ANserver process is running that is
#           to be accessed by this URL.
#           Attention: In multi-server environments you have several server
#           sections with identical URL but different <servername>.
#    <serverdesc>: (optional entry): A descriptive name of the server
#           that is addressed by the URL. This name
#           may be presented to the user on the WEB interface as
#           machine name. This entry should not have too
#           many characters.
#           *** Not necessary anymore *** Obsolete, do not use anymore.
#    <email-adr>: (optional entry)
#           E-mail address that correctin e-mail etc are sent to to
#           the browser user. This is the e-mail addess of the I2K users
#           Here, you can enter different addesses for each
#           Impose2000 server.
#           *** Not necessary anymore *** The e-mail addresses now come
#                                directly from the WebCheck user administration
#    <from-adr>: Replaces the 'from' e-mail address that is to be used for
#           correction e-mail to the Impose2000 user instead of the one coming
#           from the WebCheck user administration. This has been introduced
#           for the case that outgoing e-mails are filtered by their 'from'
#           line and only certain e-mail addresses are accepted at the
#           receiver and the e-mail would otherwise be rejected.
#           In order to prevent that you can use this parameter to define
#           a valid, useful e-mail address.
#           Empty string: Use normal e-mail address from the user
#           administration as 'from' entry in correction e-mails
#    <port>: (optional entry) Alternative port to be used to establish
#           a connection to the Impose2000-ArtNet server.
#           If not entered, then default (=5620)
#    <debuglevel>: (optional entry): With this parameter you can control
#           debug output from 'outside':
#           If not exist: Default logging settings;
#           If exist: values <= 0: Debugging OFF,
#                           Values >  0: Debug level (useful: 2 or 3)
#    <logo-file>: (optional entry): Option to specify
#           a company logo image file for the ANServer to be addressed.
#           This file is then mounted on the page header of each page to be
#           output but the login page.
#           If no log file is defined the system will use a WebCheck default
#           logo. Necesary specification:
#                * Type: JPG, GIF, PNG
#                * the file should be located unter /customer, in which case
#                  you just need the name, e. g. "banner.jpg" In case of
#                  another position in the file system you have to enter
#                  the whole folder path.
#    <logo-file2>: (optional entry): Option to specify
#           a server/URL specific LoginLogo image file for the ANServer
#           to be addressed. Entering this will overwrite any file
#           in /customer.
#    <scalelogo> (optional entry): true|false: Logo is scaled instead of
#           fill up with white to right or trimming (default: false)
#    <dontoverlaplogo> (optional entry): true: Logo won't be overlayed
#           by top menu  (Default: false)
#    <in MB>: (optional entry): integer value in MB. Uploads with files
#             larger than this value are rejected.
#             Default value is currently 1 GB. This value must be smaller
#             than 2 GB! Higher values are ignored.
#    <Mime Types>: <MIME type>{,<MIME type>
#    <MIME Type>: (optional enrty) Uploadable file formats. If you enter
#             _additional_ MIME types, they will be accepted
#             in addition to the internal default value. Internal default
#             is currently "application/pdf,image/jpeg,image/tiff" and
#             archive formats  "application/x-tar, application/zip",
#             i. e. PDF, JPGs and Tiffs are accepted. In addition you have
#             the option to upload certain archive formats.
#             You have to enter either a single format or a list of
#             different MIME types linked with ','.
#
# L o g i n  logo (per "/customer/artnet_login_logo.jpg"):
# Independent of the company logo entries (s. "<logo-file>") in the
# server section you have the option to determine a login logo.
# This is not done in the configuration file, though,
# but by placing a file in /customer:
#   Saving in the folder /customer an image file "artnet_login_logo.jpg"
#   it will replace it as the login logo in the login form.
#   The login logo defined like this will ONLY appear in the login HTML.
#   AFTER the login you will see in the following forms
#   the configured   c u s t o m e r  logo of the respective servers (or
#   the WebCheck default logo, if no customer logo is defined).
# L o g i n  logo (per "<logo-file2>" in server section):
# With this you can defined a special login logo for each URL:
#   This overwrites a generally defined login logo that has been
#   defined by "/customer/artnet_login_logo.jpg" (s. above).
#   The system will use the first entry found for any URL, i. e.
#   usually the one of the master server. As a result it does not really depend
#   on the server but the URL
#
# C o m a n y  logo (per "<logo-file>" in server section):
# As described above you enter the company logo for the (I2K-)ANserver in the
# respective server section. This appears at the top of each page
# and denotes the actual company computer assigned to the ArtNet session.
#
# C u s t o m e r  logo (per I2K-WebCheck user administration):
# With the help of the WebCheck user administration of the respective
# Impose2000 computer (Anserver computer) you can assign the customer logo
# to a user. If a customer logo is entered for the respective user
# it is displayed to its left in the page header, too.
# For that reason you should limit the size of the customer logo.
# In the page header the system will place the customer logo left-aligned and
# the company logo right-aligned. In the overall logo section these logos are
# aligned in the middle vertically.
##############################################################################
# Example:
#
# 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";
# }
#
# #End of configuration file

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";
}
# End

The mentioned logo files should be located in /customer or must be mentioned with absolute paths. We
recommend saving under /customer.

Attention: When reinstalling a web server you should first of all leave out all optional function
              buttons. They will be furnished with useful default values internally.
              The same is valid for the optional customer and company logos.

Activating company and/or customer logos

As you have numberous settings available for this option, here only a short description.

Company logos are configured in the WebCheck server configuration file /customer/artnet.server.cfg on the
(WebCheck) WEB server computer. To this end you have to create an image in the format JPEG (as an alternative
also PNG or GIF), e. g. customer_logo.jpg or banner.jpg etc.
You then have to provide 'world' read permissions and enter them into the sever section mentioned above.

Customer logos are assigned to the individual customer (user) login in the WebCheck user administration on the
Impose2000 server computer. You may only use JPG/PNG with a height of up to 100 pixels.

The normal case:

  1. If the company logo is a JPG/PNG file and you have defined a customer logo, then the customer
    logo is left-aligned and the company logo is placed right-aligned in the header of all pages.

  2. If the company logo is defined but the customer logo is missing, then only the company logo is
    placed right-aligned.

  3. If the company logo is not defined but a customer logo, then only the customer logo is placed
    left-aligned.

  4. If neither a company logo nor a customer logo is defined, then the default WebCheck page header
    is used.

External access

The following example is valid:
With https://www.mycompany.de/artnet/ brings you to the web server in the WebCheck application. To this
end the Apache server on the internet gateway computer forwards to the actual WebCheck server computer,
e. g. from https://www.mycompany.de/artnet/*
to http://mycompanyproxy:8080/artnet/* ("mycompanyproxy" is an alias for the actual
WebCheck server).

To this end the following is defined in /etc/apache2/sites-available/www.mycompany.de.
First of all the configuration forwards accesses to port 80 (http) to https. (Unencrypted connections are a safety
risk!) 

# Requests to the WebCheck server are changed to https:
RewriteRule ^/artnet$     https://www.mycompany.de/artnet/   [L]
RewriteRule ^/artnet/(.*) https://www.mycompany.de/artnet/$1 [L]

The configuration of port 443 (https) controls the forwarding of the WebCheck server to the internal net: 

# Requests to the WebCheck server:
RewriteRule ^/artnet$     https://www.mycompany.de/artnet/   [L]
RewriteRule ^/artnet/(.*) http://mycompanyproxy:8080/artnet/$1 [P,L]

The WebCheck server is able to identify the computer name – mycompanyproxy – for which Impose2000
server (if several are present) the login is to be carried out and reacts accordingly.

WebCheck server on the Impose2000 side (ANserver)

In out example:
On the WebCheck server computer you currently have configured i2k_server-1 and i2k_server-2
as Impose2000 servers.


These server must have a valid WebCheck (ArtNet) license. If need be you also need a
SoftProof license (SoftProof functionality only with ArtCom software version 18.2 or above)
In order to use the latest WebCheck version on a connected Impose2000 server you need
a software version of 18.2 or later.


Starting from this server you need to be able to connect with ssh with the ID of the default users, such as
'user' or 'artcom' to the WebCheck server. Again: ssh access with this user ID must be possible from the
Impose2000/workflow server to the WebCheck server without any additional interactive queries,
e. g. Password, etc. Keyword is here 'ssh-keys'.
 
Configuring start of ANserver:

On the Impose2000 or workflow server you have to start the ANserver demon with the same default user ID,
such as 'user' or 'artcom'. The start of this demon must/should be configured with the help of the init system,
in order to always start it automatically.

The following files offer information about how to do that:

     bitslib/env/etc_event.d_template_anserver  for upstart (e. g. UBUNTU)
     bitslib/env/etc_inittab_template           for classical initd (SuSE)

Attention:
 Anserver binary and WebCheck element only exist with existing WebCheck/ArtNet license.


On these server computers:



Mailing

Procedure to bring the section „E-Mail“ in working condition (abstract from issue entry):

** WebCheck server (WEB/browser)side):
   With this you define the transmission of correction e-mails of the browser user
   to the Impose2000 servers, i. e. Usually to the I2K user.
   
   - the entry „EMAIL“ in the server configuration file does not have to be entered
     anymore. You should delete it because this information is taken from the
     Impose2000 WebCheck user administration.
     This address used to be taken for correction e-mails of the the end (browser)
     user to the I2K operator.
   - you need to enter a valid SMTP mailhost
** Impose2000:
   E-Mails about orders cleared for the WebCheck, the evaluation of forthcoming pages
   of an order, the resubmission of forthcoming pages, etc. Also e-mails of the I2K
   users or the from the Impose2000 application/ArtRobot to the browser user.
   (1) Under "Extras"-"WebCheck user administration"
 
     - ...you can in the top half of the form enter the companies and for those the
       the end (browser) users that receive access to the orders.
       They are entered with their name and e-mail addresses. 
       These e-mail addresses are used for e-mail such as „The order xy has been
       cleared for you...", etc.
     - In the bottom part of the form you define the I2K operators, to which the
       correction e-mails to the end (browser) user is sent.
       Here, you can enter several addresses to a symbolic I2K operator name.
   (2) "Mailhost" and "SMTP server" in the bottom part of this form. General procedure:
        
        No e-mails desired:
            Leave field "Mailhost" empty
            Leave field "SMTP-Server" empty
        E-mails desired:
            Enter 'localhost' in field "Mailhost"
            Enter a working SMTP server in the field "SMTP-Server" (default procedure)
                           or if empty e-mails are only delivered locally (exception)
   (3) Under "File"-"WebCheck Assignment" you can merge the e-mail addresses
       I2K operator and end (browser) users for an order:
  
     - Here, you can define the „customer“ (=company) for a selected order. The end
       (browser) users entered for it receive the above mentioned „The order xy has
       been...“ etc. e-mails.
     
     - In addition, you enter the responsible I2K operator („Impose op“), who
       receives all correction e-mails from the end (browser) user to the address(es)
       entered at (1)
     - Furthermore, you can enter a BCC address that will also receive all e-mails.
       This was a customer desire for control/check tasks. This is where you can
       collect all correction e-mails, etc. without the end user noticing.
     - Also, you use this form to define the upload folder for this order if uploads
       are allowed for this end (browser) user. If you define a folder here, an upload
       button becomes visible on the WebCheck website for this order allowing the user
       to upload files to the Impose2000 server.

Involved configuration files relevant to WebCheck

Example files may be found in the package artnet-configuration-examples.tar on out FTP server:
/ftp/pub/webcheck/artnet-configuration-examples.tar


webcheck-server:

/customer
       artnet-server.cfg   ...Server configuration files, connection to Impose2000 server
       artnet-userprefs/      ...empty, filled in by WebCheck. Settings for single user
       artnet-mail-template_DE.cfg   ...for correction e-mails to Impose2000 users
       artnet-mail-template_EN.cfg   ...may be configured to different languages
       artnet-mail-template_ES.cfg
       CMYKSource.icc ...ICC source example profile for Softproof mode
       CMYKDest.icc ...ICC target example profile for Softproof mode
       ENABLE_SOFTPROOF   ...without contents, only flag. SOFTPROOF function for workflow display
       artnet-env.cfg   ...global settings for the WebCheck, e. g. Language in login window, etc.)

impose2000-server:

$AC_CUSTOMER/

    webcheck/production/mail-templates/*  ...language-dependent templates for Impose2000 e-mail to browser user
with fixed name convention:

    checkRequest_EN.cfg
    corrected_EN.cfg
    forCorrection_EN.cfg
    order_EN.cfg
    pages_EN.cfg

    webcheck/preprint/mail-templates/ ...language-dependent templates for Impose2000 e-mail to browser user
could be definied here. The base names are variable, the assignment to the e-mails could be done in the
configuration file preprint.cfg. But the language chars (see below) and the suffix (.cfg) are fixed


    ArtNet.users    ...allowed users, filled in by Impose2000 user administration

Other allowed language chars are  "_DE": german, "_EN": english, "_FR": french, "_ES": spanish,
"_PT": portugese, "_IT": italian

Several instances of JBoss, several versions of WebCheck in parallel

Under special circumstances it is necessary that you are able to run several instances of JBoss in parallel.
This section describes how to configure the handling of several Jboss and thus WebCheck instances on one
server. These different instances may be accessed e. g. by using different URLs. To this end you may be faced
with addition configuration work outside of the JBoss installation, such as redirecting in the Apache configuration,
etc.

You define different instances of JBoss in the different (JBoss) server configuration folders below the JBoss
base folder, e. g. In our example below "/usr/local/jboss-4.0.3RC1/server".

Based on one already running 'single' JBoss installation you have to do this::

(1) Copy the 'default' configuration folder to 'default2'

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

(2) Adjust the configuration of the second instance:

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

There, you have to look for the section "ServiceBindingManager". In case of a previous default configuration
of JBoss it is decommented and needs to be activated now. To this end you could e. g. Copy the section and
place it below the comment.

You have to change the following:

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

The labeled file will be created in a moment. It defines the mapping of the port to the new instances.

Save "jboss-service.xml" and exit the editor.

(3)  Creation of the port mapping file:

You can find it as an example templete file preconfigured in the JBoss folder

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

As this file is already preconfigured you do not need to change anything in the file.

(4) Port numbers:

As before the first instance is the 'default' unter the port number 8080. The second instance
receives the port number 8180, the third one 8280, etc, provided the predefined port mapping
in "ports-bindings.xml" has not been changed. For the https and all other JBoss ports this
consecutive numbering is also valid, such as 8443 (HTTPS of first instance), 8543 (HTTPS
of second instance) etc.

(5) Deploy, Log & Co.:

Regarding log file, deploying etc. the same is true as for the single-instance usage, the only
difference being that you have to use /usr/local/jboss-4.0.3RC1/default2 instead of
/usr/local/jboss-4.0.3RC1/default. In particular you can from now on deploy different
WebCheck packages to the respective 'deplo' folders. Since all temporary data/files needed
during the use of the WebCheck are managed below these folders you can handle all instances
completely indepentend from each other. They only have common configuration files in/customer,
e. g. "artnet-server.cfg" or the logo and e-mail template files.

(6) Start second JBoss instance now:

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

(7) Stop second JBoss instance:

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

...for this (name binding) port number you also have to use the 100 offest, i. e. You have to stop the
first instance 1099, the second one 1199, the third one 1299, etc.

You can also run and shutdown the different server instances via /etc/init.d. This will also cause the
automatic booting of the server.
(Compare section "JBoss server start"-"Auto")
For the use of several instances you find a special script "jboss"
  via /etc/init.d
Have a look at: /opt/artcom/current/env/etc_init.d_artcom-jboss_multiserver_template

Apache Konfiguration, if needed


the following is a copy of a text from Heiko (und Peter):

If the customer likes to certify his SSL-Key, we must do the following steps. if we use a http-URL,
we would automatically redirected to https. I did the following and after that it works:
 
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
 # copied form Printer Barcelona
 # only the part of  Port 80 is different
 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 (use the right one here)
 openssl rsa -in server.key -out server.pem
 # enter pass phrase
 openssl req -new -key server.key -out server.csr
 # enter pass phrase
 # enter data into Certificate request. I don't know exactly,
 # where to put it in. many diferent Akzente in the company name
 openssl x509 -req -days 1825 -in server.csr -signkey server.key -out server.crt
 # enter pass phrase
 chmod 600 *
 /etc/init.d/apache2 stop
 /etc/init.d/apache2 start

After changing the /customer/artnet-server.cfg and the nesccesary restart of jboss with
sudo /etc/init.d/jboss restart
was a login possible

To loggin in fron internal net (intranet) we need one more entry in /customer/artnet-server.cfg,
We must use another 127.0.0 number (not 127.0.0.1 !!) for the PROXY_URL.


  Example site-file from Printer Portugesa (Note: all domain names are modified):

 
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>


** End of document **