This is very useful for me. Thanks for posting this ...
Frank
On Friday, September 29, 2000 3:43 AM, Jim Archer [SMTP:[EMAIL PROTECTED]] wrote:
> 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.
>
>
>
