Forum OpenACS Development: Re: Reference Platforms and Supported Platforms

Collapse
Posted by Joel Aufrecht on
This is turning into a standardized test problem: given these constraints, how must the paths be organized? :) I think we need two lists, the contraints and the recommendation. Here are all of the constraints I've heard:
  • The user under which a process runs should not have write access to the nsd binary, for security
  • Different instances of OpenACS on one machine should each run under a different user, and should not be able to access each other's files, for security for multi-hosted setups
  • All of the config files (nsd config file, ssl certificates, analog config file, daemontools directory) should be together, for ease of backup and version control
  • The site content (the five directories in site root, plus a recent database backup file) should be backed up in sync with each other and with matching config files
  • The error and traffic logs should go in a seperate location so that they can be on their own partition (this begs the question: how does aolserver behave when there is no space on the log partition?)

It seems to me that we can satisfy all of this by doing this (basically Jun's setup):

/web/sitename
             /etc
             /log
             /tcl
             /packages
             /content-repository-content-files
             /www
             /bin
             /database-backup

All of this secured so that only a dedicated "sitename" user, under whose authority the instance ran, had access.

/etc is for config files, including any subdirs that aolserver demands (I too remember nsopenssl failing if it didn't have a particular subdirectory relative to the binary's location - that may require an ugly workaround).

Do we need to move the database data files, too? I don't think so; the backup files are more useful for recovery, so those should go into our tree, but (at least in PostGreSQL) the data directory has restrictive permissions. By the way - since we don't use passwords, how are we authenticating? How are we securing the postgresql install?