World: r3wp

When Cheyenne has access to this directory, but only for reading, 
it quits silently. -vvvv doesn't even provide a clue what went wrong

When it gets write access, it produces a crash.log under the new 
user name, showing that it switched. But it had already produced 
a normal log under the root name, and doesn't adapt its ownership. 
This is indeed what the crash.log then warns about

Ah, the problem is the -vvvv itself. When I start Cheyenne with extra 
logging, it creates the log earlier, so that it ends up being owned 
by root

Running as non-root is very tricky. I've stabilized it until the 
introduction of 'access-os. I will make more tests today.

This is both against the structure of Unix and modern Windows systems.


UNIX filesystem layout usage are not identical. Here are the Apache 
error log location in just 3 UNIX flavours (among dozens):

* RHEL / Red Hat / CentOS / Fedora Linux Apache error file location 
- /var/log/httpd/error_log

* Debian / Ubuntu Linux Apache error log file location - /var/log/apache2/error.log

* FreeBSD Apache error log file location - /var/log/httpd-error.log

and here are the possible locations of configuration file:
* /usr/local/etc/apache22/httpd.conf
* /etc/apache2/apache2.conf
* /etc/httpd/conf/httpd.conf


Notice how the file name changes too (both for the log and conf files). 
BTW, I personnally prefer the GoboLinux approach ;-).


One the Windows front, it is barely better. The registry database 
is fine for storing parameters (name/value couples), but not a REBOL 
dialect file. A common way is to store files created at runtime in 
%USER%/AppData/Local/<appname>/. Cheyenne stores all his files (including 
config file) either in the local folder or in %ALL_USERS%/Cheyenne/. 
Storing them in %USER% hierarchy should be better.


Taking into account every OS specificities (or oddities) is not always 
a good choice for a cross-platform product. I know that Cheyenne 
needs to be gentle with the OS best practices, so I am willing to 
improve it whenever it is possible, but without sacrificing the default 
behaviour (because that is the way I want it to work for me).


BTW, I am also willing to test the centralized logging approach, 
but it has to be a cross-platform solution. So an abstraction layer 
needs to be built with connectors for UNIX syslog daemon and Windows 
Event Logger (they are two types to support: pre-Vista system and 
new Vista/7 one). Has anyone already worked on such wrappers with 
REBOL?


I personnaly need that the log files be exactly in the same format 
and if possible at the same place across platforms to make my life 
easier, so this will keep being the default anyway. The current -f 
internal Cheyenne command line (Windows specific currently) could 
be extended to work on UNIX too (and no Max, this one cannot go into 
the config file, because it indicates where the config file is located 
;-)).

I don't mean the specific implementation of the structure of different 
system, but the general principle. Most areas of the general structure 
are applicable to Cheyenne:

- Program and accompanying files such as libraries in the source 
version (may have different subareas)

- Configuration data. The httpd.cfg file

- User data. The websites. May be segmented over multiple user accounts 
or a global area

- Log files

Cheyenne currently just does and dumps everything in the directory 
that happens to be current. Only for site data are options to put 
them elsewhere

Access logs can be redirected to any folder.

PID file can be redirected as well.

This is awkward because these areas have distinctly different characteristics. 
These walls will be run into as soon as you try to implement standard 
security practices

The only files that can't move (on UNIX) are: httpd.cfg and "error 
log" files.

And there is my current problem, because these have very different 
access privileges

It's not hard to solve. We just need configurable locations for these 
parts

Can you list me the "standard security practices" that you have in 
mind that can't be implemented using current behaviour?

The list I gave above of the main functional areas of any significant 
application

These need to be located and given access privileges according to 
the conventions of the system

As I understand it, this looks like Cheyenne will need a per-UNIX 
system install script? Or will we let users spread the files acrosse 
the filesystem as they want and use options to redirect properly 
each file classes to the right folders?

Not at all. As I said, we just need configurable locations

The only things really missing are paths to the configuration file 
and the main logs area

The way to set them in non-default situations is the responsibility 
of the system integrator

A clear way to set the path to the UniServe library in the source 
version would also be good. I patched the Cheyenne source for that 
so far

Let me clarify that. The path not just to UniServe, but to all support 
libraries, modules and such

You mean when running %cheyenne.r from a remote location?

Remote from its support files, yes, but just on one machine

Here's the structure in Syllable:

Packages:

/resources/

/resources/Cheyenne/

/resources/UniServe/

Structure of a package:

programs/cheyenne for the binary version

framework/libraries/ for support programs

data/ for other support files

Structure in the system:

etc/httpd.cfg Ugly legacy Unix name, and currently impossible. Would 
like Cheyenne to use any location and name

/var/log/ Ugly legacy Unix name, but standard place for logs. Currently 
only possible by starting Cheyenne source version from /var/. Impossible 
with binary version

/users/Kaj/tryrebol.esperconsultancy.nl/ Sites can be anywhere

Software conforming to general open source and GNU conventions has, 
often standardised, options to appoint all these locations, at build 
time or at run time

Thanks for the detailed review. I think I will need to work on an 
abstraction layer for files location in all possible cases: sources/binary 
x platforms.

I'd hope it would be quite simple, but I don't how the encapper works

don't know

It is absolutely not simple:
- Cheyenne binaries use a memory-based virtual file system.

- When run from sources, files internal relative paths depends on 
where the REBOL binary is run from.

- REBOL on Windows has 2 different working folders (one for REBOL, 
one for the system), while on UNIX, it seems that there is only one 
(from the REBOL POV).


Make a cross product of items and you'll have all possible combinations 
to manage.

Bummer

I would like to take this opportunity to clean up things and hide 
the low-level mess under a unique abstraction layer.

I think I will make a new virtual filesystem for Cheyenne that will 
abstract all files accesses (including web sites). This would have 
the additional benefit of allowing to encap web sites files too (a 
feature I wanted to have since a long time).

This is quite a big change, so will need several steps to complete. 
I will first just patch the current way to allow relocating config 
and error files for UNIX users.