[Zope-dev] Directory layout.

Andreas Kostyrka andreas@mtg.co.at
Mon, 28 Jun 1999 12:39:54 +0200 (CEST)


Hi!

I've been wondering if there is a standard for INSTANCE_HOME layout?
The only thing I've found are
IH/var                    -> Obj. Database.
IH/lib/python/Products    -> Instance products. (Did the Instance product
                             patch make it into Z2.0?)

Philosophing a bit, I'd think that a more organized structure might help,
because there exist some categories:
*) file based Zope Configuration. At the moment this is only the
   access file. I'd propose to put Zope generic configuration into IH/etc/
*) file based Product Configuration. To seperate this exactly, I'd propose
   IH/etc/ProductName/
*) data. Like the object base, gadfly tables, etc. IH/var/
*) runtime information. Like the pid and socket files of pcgi, etc.
   Either IH/var/ or IH/var/run/ by default. Actually most of this is
   anyway configured to follow local system administration principles.
*) Binaries. Some products may come with helper scripts, this should all
   land in IH/bin/ (or if the product is installed in the Zope
   installation, then it should be in ZI/bin/ *hmmm, does this make
   sense? Shouldn't be all helpers available in the installation home?*)

What for file based Product Configuration? For anything dangerous. For
example Zope as such stores it root passwd in a file, and makes it
explicitly not editable from the web. Another example: SpoolQueues: As
they allow arbitrary commands to be executed with the Zope process
context, it is not a good thing to allow some of your customers to enter
the commands. Much better to have the queue definition (containing all the
commands needed for queue management) in an external file. (You can't
really edit it easily without a direct view of the server filesystem. And
you may need to write helper scripts to do the exact task you want them to
do.)

Andreas
-- 
Win95: n., A huge annoying boot virus that causes random spontaneous system
     crashes, usually just before saving a massive project.  Easily cured by
     UNIX.  See also MS-DOS, IBM-DOS, DR-DOS, Win 3.x, Win98.