+3. configure the perms.sh file if neccessary -- IMPORTANT! READ THIS!
+We provide a script that sets all files' and direcories' permissions to
+a quite reasonable state. This script gets automagically called by
+ant after compilationl. The most important thing you have to do after
+compiling Mir is to ensure that the log files -- especially
+dbentity.log -- are not readable by users that could compromise
+system security, because all passwords and the like will be logged here.
+
+ cp perms.sh-dist perms.sh
+
+Now, change the install directory and group in perms.sh
+
+ edit perms.sh
+
+4. There is NO step 4!!
+
+5. compile. For this step, you have to make sure that the TOMCAT_HOME
+environment variable is set to the root of your tomcat installation.
+The build.xml compile target will give up if this is not set.
+
+Do this as root so the permissions script is able to set
+the permissions and owners correctly.
+
+ ant
+
+
+6. Link in the webapps directory of tomcat to the install directory (the
+directory is in mir/bin/mir (Here and in the rest of this document,
+we assume you called the link "Mir", but this could be named anything.)
+ cd ${TOMCAT_HOME}/webapps
+ ln -s /path/to/mir/bin/mir Mir
+
+with tomcat 4.0.x, you could dynamically reload and stop the Mir webapp without
+restarting tomcat by using the "Manager App" with the following url:
+
+http://localhost:8080/manager/stop?path=/Mir
+
+This is practical if you are running several installations of mir on one
+tomcat or other webapps and can't afford to shutdown all of them.
+See the tomcat documentation to learn how to enable and use the manager app.
+
+7. Copy any dynamic library files ending with ".so" (so far only the JAI native
+acceleration library found in the JAI package tarball or zip from sun) to your
+$JAVA_HOME/jre/lib/i386 directory (where the other ".so" files live). Or, you
+can skip the whole thing and live without "native" acceleration for image
+manupulation.
+
+8a. create a new database
+The database name should be the same as in config.properties. Please look at
+the section "Database.*" to look up the names or change them to your needs.
+
+It is wise in terms of system seurity to use an unprivileged user for this
+task instead of the superuser. This is because if Mir uses the superuser to
+connect to the database and anybody manages to find out the password Mir
+uses to connect, the attacker can take over the complete database. So, in
+the following examples, we assume that the database name is "Mir", the
+database user will be "joe" and the password is "joshua". Please note that
+this particular password is far from being a good one. Watch "Wargames" for
+details. =B)
+
+
+To access the database as the database superuser, you either have to log in
+as postgres on Unix level (which we don't recommend because you will need
+another user to have a login shell and a password which makes system
+penetration more likely) or you have to tell PostgreSQL with each
+application call that you want to connect as a specific user. In the
+following example we'll create the mir database as postgreSQL user
+"pete".
+
+ cd mir/dbscripts
+ su postgres
+ ./createmirdb.sh mir pete joe joshua
+
+8b. Apply neccessary changes to config.properties
+
+Please open config.properties and look for the lines that begin with
+"Database.". The interesting properties are "Username", "Password", "Host"
+and "Name". Change these properties so that they reflect the settings you
+used to create the database and the user.