Forum OpenACS Development: Move openacs4.tcl AOLserver config file to real location

Joel's latest install docs are already suggesting that admins install their AOLserver config file beneath the root of the OpenACS checkout, e.g. in /web/service0/etc. I think this is an excellent convention to recomend and adopt.

I further suggest that in OpenACS CVS, we move the sample OpenACS AOLserver config file from: packages/acs-core-docs/www/xml/files/openacs4.tcl.txt to: etc/openacs4.tcl

The file doesn't have all that much history in CVS, but it'd still probably be better to copy the /cvsroot/openacs-4/packages/acs-core-docs/www/xml/files/openacs4.tcl.txt,v repository file over to the new location.

Comments? Yeahs, nays?

First, openacs4.tcl has been made obsolete by config.tcl.txt.

Second, the standard has been to put everything into /files and then move it around later.

Third, I already broke the tradition by creating a subdirectory for all the tutorial files.

Despite that, I think it's simpler to keep as much as possible in a flat directory and put the structure in the instructions.

Just where is this new config.tcl.txt file exactly? It does not exist anywhere at all on the CVS Head as far as I can see.

Secondly, it certainly is not simpler to "put the structure in the instructions" than it is to provide the correct structure in the first place.

Improvements to the AOLserver config file are easier and more likely to me when you can actually run the file as provided. The currently provided config file is good in its simplicity, but is far from an example of best practices. It is quite feasible to greatly improve it while still keeping it simple.

config.tcl.txt is at /openacs-4.6.2/packages/acs-core-docs/files in the 4.6.2 final tarball. CVS seems to be down so I can't check that right now.

What I mean by "put the structure in the instructions" is that the files in acs-core-docs/files go into various different places, including but not limited to /etc/ and /web/service/etc. And those places may not be the same on different machines and different flavors of OS. So the text of the instructions currently provides the mapping from the catch-all /files directory to the right place in the final install. Since the new "right way" has been vetted only by a few forum threads, I was hesitant to impose that into the file structure. If there's consensus on new file structure that works in most cases, then I agree we should implement it.

Have a look at the new config.tcl.txt (it seemed to be the convention to tack on a .txt to all the various files - perhaps some of them were accidentally interpreted at some point and the convention has outlasted its need? Should we dump the .txt?) - I would love feedback on how it can be improved. I tweaked it a bit to accomodate nsopenssl, and to increase the number of access logs kept so that people don't lose log files before they get around to realizing they need them and where they are, and to put everything in the /web/service structure.

Responding in this thread
I think any attempt to move this to the "right" location will backfire.  There are so many best practices and traditions which different apps/platforms use. for example:

/etc/openacs.tcl seems logical for a single app on a machine
/etc/openacs/appname.tcl seems logical if you have more than one instance on a machine.
/usr/local/aolserver/nsd.tcl is the default for aolserver
/web/appname/config/nsd.tcl is a common tradition
/data/servers/appname/config/ is also common in my company.

The list goes on, there's no way to please everyone so putting it in /files with instructions and letting people put it where they like makes sense to me.  Bottom line is it really doesn't matter where it lives, as long as the path is given as as arg to the nsd binary.

Ivan, you've misunderstood what we're talking about here.

We are neither mandating nor even suggesting putting anything into /etc/, /usr/, or anywhere else in particular in the user's file system. What we are discussing, is where to locate the AOLserver config file in the OpenACS CVS repository. Joel and I seem to have agreed that etc/nsd.tcl or etc/config.tcl or something like that is the best place.

If we do that, what it means for the user, is that when a user checks out OpenACS from CVS, or downloads and untars the OpenACS release tarball, he can put it anywhere he wants. But if he, say, untars OpenACS into /web/mysite/, then /web/mysite/etc/nsd.tcl will already be there, in the suggested and immediately useable location. There is no reason that he should have to manually copy the nsd.tcl we give him from some other random location into /web/mysite/etc/. He can move thigns around if he wants to. But the new docs are going to recomend using that location for the AOLesrver config file, so we might as well actually put it there.

For the vast majority of people who will be happy with the standard OpenACS AOLserver config file and it's standard location, it's much easier and simpler to just have it there ready to go right out of the tarball. That way, those folks automatically get the benefit of OpenACS best practices. And for the minority who want to do it there own way, they can, this change makes absolutely no difference to them. But there's no reason to force people to "roll their own", which is what we're doing now.


My bad, I understand now.  What you are suggesting sounds good to me.


This is in progress in HEAD, and probably accidentally in 4.6.3 (CVS branches kick my ass daily).  We have /etc/config.tcl and /etc/analog.cfg.  I planning to wait until after 4.6.3 to add /etc/daemontools/run.  I don't see any reason to create empty /log and /database-backup directories since the permissions will have to be tweaked anyway so might as well just create them, plus cvs and tar weirdness with empty directories.
Joel, I think you should create the /log and /database-backup directories (perhaps with a file named ".keepme" to keep cvs happy). Even if you have to tweak permissions you could just chown -R your /web/service directory, and if we can assume /log and /database-backup already exist we can program the run scripts properly so that OpenACS runs "out of the box".