Thanks to all who replied.
Acually, my original message was not too well written. I was not concerned
about the port mapping issue. Thats not a big deal. We already have that
issue with other processes, such as Apache, which runs as user nobody.
Our issue is where to install Orion, what permissions each file should
have, what user Orion should run as and so on. We would prefer Orion not
run as root (we don't let Apache run as root either) and that its files not
all be world writable by default (which is what happens when we unzip it
onto our Debian system).
Mostly, we need to know what directories Orion needs to write in, what ones
it does not, which files it needs to edit and so on. Below is a note from
the guy who has been working on this. He explaines our problem and the
partial solution he worked up in detail:
Jim,
I figured out most of the pieces needed to do it, but we
still have a problem.
This all applies to Orion 1.3.8 running on Debian Linux 2.2 "Potato" with
a 2.2.14 (patched) kernel and IBM JDK 1.3.0 build cx130-20000815.
1. The main issue these people are discussing on the list is how to get
the server to listen on port 80, which is not our issue. On Unix, only
"root" can connect to ports below 1024. This is actually a trivial
problem, since the solution is to have the Orion server listen on some
other port, like 8080, and have a simple shim running as root that proxies
port 80 to that other port.
2. What was causing us grief was exactly what I thought was causing us
grief. The file structure is Windows-like, and it has to be shoehorned
into a proper Unix structure. Basically, I split the Orion directory
structure into a bunch of things that Orion itself should never have write
permission for, which is now in /usr/local/share/orion and is owned by
"root," and into a bunch of things that Orion itself does need write
permission for, which is now in /var/local/orion and is mostly owned by
the new "orion" user. It is necessary to edit the XML files in
/usr/local/share/orion/config to account for this.
What actually must be moved to /var/local/orion is only three directories:
guardian:~$ ls -l /var/local/orion
drwxr-sr-x 3 orion orion 4096 Jul 5 14:40 application-deployments
drwxr-sr-x 4 root staff 4096 Sep 28 16:03 default-web-app
drwxr-sr-x 2 orion orion 4096 Sep 28 03:44 log
drwxr-sr-x 3 orion orion 4096 Jun 5 14:38 persistence
I also moved "default-web-app" here, although only the "WEB-INF" directory
below it needs to be writable to the server:
guardian:~$ ls -l /var/local/orion/default-web-app/
drwxr-sr-x 3 orion orion 4096 Sep 28 16:11 WEB-INF
drwxr-sr-x 8 root staff 4096 Jun 5 14:38 examples
-rw-r--r-- 1 root staff 2044 Sep 28 16:03 index.html
(Note that the Orion server does not seem to handle CRLF end-of-line
conventions, and I had to convert "index.html" to LF-only in order to get
things working without errors. Of course, that is a very minor problem,
but it explains why the timestamp on the file is recent.)
In the "WEB-INF" directory, the "classes" subdirectory does not appear to
need to be writable by the server:
guardian:~$ ls -l /var/local/orion/default-web-app/WEB-INF/
drwxr-sr-x 9 root staff 4096 Jun 5 14:38 classes
-rw------- 1 orion orion 386 Sep 28 15:37 web.xml
3. Now, this arrangement ALMOST works. The first time a particular JSP
file is invoked the server tries to create directores below
/var/local/orion/application-deployments/default/defaultWebApp/persistence/
examples/jsp
such as "checkbox" for the checkbox example and "num" for the numberguess
example, and then it tries to create xxxxx.jsp.jspCache files in these
subdirectories (where "xxxxx" is the base name of the JSP file). This
works only if the server is started by the "root" user, but not if the
server is started by the "orion" user. Since the entire tree from
/var/local/orion/application-deployments down is owned by the "orion" user
who has full permissions, this makes no sense:
guardian:~$ ls -l
/var/local/orion/application-deployments/default/defaultWebApp/persistence/
examples/
drwx------ 4 orion orion 4096 Sep 28 17:46 jsp
Once the directory and the xxxxx.jsp.jspCache file have been created by
invoking the JSP file the first time with the server started by the "root"
user, ownership of this directory and its contents can be changed manually
to the "orion" user and the server can then be started as the "orion"
user. At that point, any JSP for which the appropriate xxxxx.jsp.jspCache
file already exists will work.
My guess is that the server is somehow trying to drop privilege or
otherwise change its euid when it does whatever it does to build the
xxxxx.jsp.jspCache files. When this fails, we get an error message (in
the browser from which the JSP invocation was attempted) like this:
500 Internal Server Error
Error parsing JSP page /examples/jsp/dates/date.jsp
IO Error: __jspPage0_examples_jsp_dates_date_jsp.java (Permission denied)
Since Java has no real notion of a uid at all, it is not clear to me what
is really happening here, nor how this could happen at all in an
application which is 100% pure Java which I understand Orion to be. On
the other hand, this could be something really foolish, such as asking for
the wrong file mode on open. Because of this, I suspect it may be a bug
in Orion, or -- much worse -- in the IBM JVM.
