[Xapian-devel] Omega changes

[Richard Boulton]

On Sun, 2004-12-19 at 18:20 +0000, James Aylett wrote:
> On Fri, Dec 17, 2004 at 05:53:18PM +0000, Olly Betts wrote:
> > If you want to mix cgis and static content, nobody is forcing you to
> > put your omega.conf in the same directory.
> 
> Except at the moment, you can't. If someone wants to mix cgis and
> static content in a non-system installation, they have to put
> omega.conf in the same directory as the CGI.

I notice that the default apache configuration (for debian, and as
suggested in the apache 2.0 download) refuses to serve any files
beginning with ".ht".  I wonder if it would be worth making omega
check for .htomega.conf (before checking for omega.conf
and /etc/omega.conf), to take advantage of this default setting?

> > We can document that this is a bad idea in this situation.
> I'd be happy with that and:
> 
> > I wouldn't object to adding the environmental variable as an option
> > (perhaps even taking precedence over looking next to the cgi, although
> > that would be extremely annoying if the admin is using it in the server
> > configuration, so perhaps not...)
> 
> Yes, but you can always ask the admin to restrict that environment
> variable. SetEnv can be done at the directory level, for core server
> configuration, and if the admin chooses that all users must do things
> using the environment variable (with some mod_rewrite trickery you can
> auto-set $HOME/.omega.conf or something), then that's their choice.

Incidentally, I don't seem to be able to set environment variables in
the Debian (sarge) Apache 2.0 installation, but that could just be me
being stupid.  I haven't tried terribly hard, but mod_env seems to be
absent.

Okay, I think a good plan for this is:

1) Check environment variable.
2) Otherwise, check .htomega.conf
3) Otherwise, check omega.conf
4) Otherwise, check ${sysconfdir}/omega.conf (ie, /etc/omega.conf on
Linux)
5) Otherwise, default to the current defaults.

If any of the configuration files are present but invalid, or
permissions prevent them being read, omega should fail, and display a
"Script is misconfigured" error message in the browser, and send the
details of the error to stderr (which should get directed to the
webserver error log).  At present, it just tries the next configuration
file.

If there are no objections, I'll implement this later this week.

-- 
Richard Boulton <richard at tartarus.org>