Hi,
Here are my 2cts.
You have two routes: keep all in one directory-tree / partition (easy to backup an
restore) or spread
it out the UNIX way. I would go for the latter one.
The original setup for the filestructure in the UNIX world was based, amongst others,
on where the
files where used for, how often they changed and how much they might grow (and what
happens when
that partition was full, hey Eddie!). Agreed this was all in the days you had hard
disks of sizes less then
100Mb, but some of it still makes sense.
Relative static data I would store on one partition, which doesn't need to be stored
off-line that often.
All orion files are candidate to that, except of course the config files and the
deployment directory.
I assume that you use in deployment and other database then hsql. If you use hsql to
some extend
you'll have to move the hsql files as well.
For the static stuff you could consider a directory /usr/public/orion and export that
one for NFS usage
by other platforms. For a production system you can consider a read-only mount. Some
people will call
you paranoid though, but it is no effort at all.
All config files can be moved to /etc/ which is sort of there natural place on UNIX.
These are the files -you-
write. So orion can read them, but certainly can not write them. These files can be
monitored using Tripwire
or whatever.
The deployment directory and the hsql database files (if necessary) can go to /usr/,
/home/ or even /var/.
These are the files the systems writes. Would someone gain access under the orion
account, these files
are wide open.
The directory with the applications (the ear-files) could be part of the deployment
directory structure. These
file could/should have different permissions to let the application assembler drop a
new version for production.
The fine tuning depends a bit on the division of tasks within your organisation.
The database is a separate subject.
On ports: I guess it is relative straigth forward:
- 80 for HTTP
- 413 for HTTPS
- 9217 for jms (and clustering).
- 23791for ORMI which is an implementation of RMI.
- Something for your database ... (only accessible within your DMZ).
These are defaults and I would change them and check for port scanning in your DMZ.
Port scanning in your
DMZ zone means high security allert!!!
Check the docs about rmi.xml / jms.xml / default-website.xml for the port settings and
setup a firewall that forwards
all the above default ports to the port you defined using masquerade.
You can always get in, but he doesn't know how!
FE
[You can always get in, but -he- doesn't know how!]
On Friday, March 23, 2001 6:02 AM, elephantwalker [SMTP:[EMAIL PROTECTED]] wrote:
> Dear group,
>
> The www.orionsupport.com site has an good reference for using orion on a
> linux or unix machine. However, one important part of system management is
> where to locate the orion files and the application/website files, and this
> is missing. By choosing the location of these files, we can effectively
> integrate common backup strategies and other important system management
> tasks.
>
> Programs and even Apache are usually stored somewhere in the /usr directory.
> However, I feel that this is the wrong place for Orion, since there are a
> significant number of configuration files for the Orion server which do not
> make sense in the /usr directory. Other appservers and even database servers
> use thier own slice and dice file structure: Weblogic has its own directory
> off of root, Oracle has four or more different directories one each for the
> program, database, data and transaction logging.
>
> If we are to make an application safe from careless or malicious corruption,
> we need to make some use of user ownership and access control on the Orion
> file structure. I have found the ownership and permission instructions here
> http://www.orionsupport.com/articles/unixprocess.html to be very effective
> at preventing un-authorized tampering with the application server. On linux,
> the ipchains directives effectively solve the port 80 problem.
>
> For where to locate the directory, I use a strategy that is based upon a
> separate directory for the application server (much like Weblogic or
> Oracle), but the actual data for the web site or application being in the
> "volatile" directories, or directories which change a lot. In addition, the
> Orion application should be in its on "partition" so that any massacre of
> Orion through an un-known assualt (hackers are smart people too), or simple
> mistake by the orionuser could be effectively walled off from the rest of
> the system, including all of our datafiles. By simply wiping the partition
> (easy enough without harming the rest of the file system) and reinstalling
> after corruption. In this scenario, all we would have to do is keep a safe
> copy of the configuration files and log files, and even they can be located
> in volatile directories.
>
> My web applications, default applications, and all web data files are kept
> in /home/webdev/webdata directories. This makes some sense, because many of
> these files are actually developed and stored by users over a network, and
> the ../webdata directory is open to be written by a group called
> webdeveloper. Thus they can change webfiles...but the actual configuration
> changes are left only to the orionuser group. As part of the /home
> directory, these directories are treated by most back up schemes as the most
> volatile data that should be backed up.
>
> We can similarly keep the deployment directory with its serialization
> directories (those directories creating for each application under the
> deployment directory) in the /home/orion/deployment directory for the orion
> user.
>
> Why did I write this? We are ready for deployment soon, and we have had to
> solve all of these problems to create our website. What have we left out?
>
> One thing that concernse me is we don't have a complete list of ports which
> orion listens to. Oh, I know they are sprinkled throughout all of the
> configuration files, but it would be nice if there was a consise list
> somewhere. This would useful in configuring any firewall strategy for
> blocking access to rmi, ormi, etc.
>
> regards,
>
> Elephantwalker
>
>
>
>
>
>
