BEWARE: This page is somewhat outdated
Whatever webserver you use on OpenVMS, you will have to so some mapping, in one form or another.
My experience is mainly SWS (AKA Apache, but the HP version is fairly different it some points) and WASD, and I know a bit on OSU, but far too little to give any good advice for that. But I guess the main issues hold for OSU as well.
To begin: get a copy of Allan Winston’s book “OpenVMS with Apache, OSU and WASD – the NonStop Webserver (Digital Press, 2003, ISBN 1-55558-264-8). For today’s versions of APACHE and WASD it is somewaht outdated but nevertheless – it still is the best you can get.
There is at least one advice you should follow, because it makes your life so much easier:
Have your webs be located on their own directory.
I have a number of webs (“virtual hosts” in SWS, “services” on WASD):
“PUBLIC” – what’s accesable by “the public”, that is : everyone.
“PRIVATE” – what’s not accesable by “the public” unless they have the rights to access the pages. It means a login is needed.
“MAIL” – speaks for itself.
to name a few.
The document root of any web is outside the webserver environment, each has its own root. This makes moving a web, or moving from one server to the other very easy.
HTTPD$MAP.CONF reflects this distinction, by including the web’s particular configuration – I haven’t coded all in one file, but made a configuration for each of the webs. Reason: each configuration can be tested and adjusted in a separate, closed environment before making it public.
So, for public, I have a configuration file www.conf, included in HTTPD$MAP.CONF.
This file looks like:
[[www.grootersnet.nl:80]]
#[[192.168.0.12:82]]
# BASIC
[IncludeFile] HT_ROOT:[LOCAL]basic.conf
[IncludeFile] HT_ROOT:[LOCAL]help.conf
# SYSMGR blog
redirect /sysblog/ /sysblog/index.php?
redirect /sysblog/**/ /sysblog/*/index.php?
exec /sysblog/**.php (cgi_exe:phpwasd.exe)/sysblog/*.php \
ods=5 script=syntax=unix script=query=none map=once
pass /sysblog/* /sysblog/* ods=5 search=none
# TRIPS,TRACKS and TRAVELS blog
redirect /tracks/ /tracks/index.php?
redirect /tracks/**/ /tracks/*/index.php?
exec /tracks/**.php (cgi_exe:phpwasd.exe)/tracks/*.php \
ods=5 script=syntax=unix script=query=none map=once
pass /tracks/* /tracks/* ods=5 search=none
# BOOTCAMP 2007 blog
redirect /bc2007/ /bc2007/index.php?
redirect /bc2007/**/ /bc2007/*/index.php?
exec /bc2007/**.php (cgi_exe:phpwasd.exe)/bc2007/*.php \
ods=5 script=syntax=unix script=query=none map=once
pass /bc2007/* /bc2007/* ods=5 search=none
# Public web
pass /* /webdisk2/public/*
pass / /webdisk2/public/
exec /cgi-bin/* /cgi-bin/*
set * map=root=/webdisk2/public/
As you can see, I have split up the original expample configuration into some parts: basic and help, and I can easily add and remove parts when needed and applicable. (Phyton for instance, isn’t part of basic yet, but when I’m happu with setting up moinmoin, it might be).
The blogs are a development of their own. Take SYSBLOG (this one) as an example.
All the WORDPRESS PHP-code is stored in a single directory tree, refered to by logical WORDPRESS :
$ sho log wordpress/full
"WORDPRESS" [exec] = "webdisk2:[private.wordpress.]" [concealed] (LNM$SYSTEM_TABLE)
(not publicly accesable)
SYSBLOG is another location, referered to by logical SYSBLOG – but it;s a seachlist:
$ sho log sysblog/full
"SYSBLOG" [exec] = "webdisk2:[public.sysmgr.log.weblog.]" [concealed] (LNM$SYSTEM_TABLE)
= "webdisk2:[private.wordpress.]" [concealed]
$
The first location just holds the wordpress configuration script, telling where the database is (in a separate file on a location that cannot be retrieved from the web) , and upload directory tree when needed Nothing else. The rest is taken from the WORDPRESS directory tree.
All directories containing executable code are READONLY; where WRITE access is possible, files will be read only as they are – never executed.
Some time later, the rquirement of testing and updating new WordPress versions made me create a logical configuration in stead of a physical one. It just means that the WordPress base is installed in its own subdirectory: WP263: for WP 2.6.3, WP265: for WP.2.6.5 and so on. That leaves just the definition of the logical for the blog to be changed – and when I choose or need to do so, I can use different WordPress versions side by side.