[0001]
[0002]
[0003]
[0004]
[0005]
[0006]
[0007]
[0008]
[0009]
[0010]
[0011]
[0012]
[0013]
[0014]
[0015]
[0016]
[0017]
[0018]
[0019]
[0020]
[0021]
[0022]
[0023]
[0024]
[0025]
[0026]
[0027]
[0028]
[0029]
[0030]
[0031]
[0032]
[0033]
[0034]
[0035]
[0036]
[0037]
[0038]
[0039]
[0040]
[0041]
[0042]
[0043]
[0044]
[0045]
[0046]
[0047]
[0048]
[0049]
[0050]
[0051]
[0052]
[0053]
[0054]
[0055]
[0056]
[0057]
[0058]
[0059]
[0060]
[0061]
[0062]
[0063]
[0064]
[0065]
[0066]
[0067]
[0068]
[0069]
[0070]
[0071]
[0072]
[0073]
[0074]
[0075]
[0076]
[0077]
[0078]
[0079]
[0080]
[0081]
[0082]
[0083]
[0084]
[0085]
[0086]
[0087]
[0088]
[0089]
[0090]
[0091]
[0092]
[0093]
[0094]
[0095]
[0096]
[0097]
[0098]
[0099]
[0100]
[0101]
[0102]
[0103]
[0104]
[0105]
[0106]
[0107]
[0108]
[0109]
[0110]
[0111]
[0112]
[0113]
[0114]
[0115]
[0116]
[0117]
[0118]
[0119]
[0120]
[0121]
[0122]
[0123]
[0124]
[0125]
[0126]
[0127]
[0128]
[0129]
[0130]
[0131]
[0132]
[0133]
[0134]
[0135]
[0136]
[0137]
[0138]
[0139]
[0140]
[0141]
[0142]
[0143]
[0144]
[0145]
[0146]
[0147]
[0148]
[0149]
[0150]
[0151]
[0152]
[0153]
[0154]
[0155]
[0156]
[0157]
[0158]
[0159]
[0160]
[0161]
[0162]
[0163]
[0164]
[0165]
[0166]
[0167]
[0168]
[0169]
[0170]
[0171]
[0172]
[0173]
[0174]
[0175]
[0176]
[0177]
[0178]
[0179]
[0180]
[0181]
[0182]
[0183]
[0184]
[0185]
[0186]
[0187]
[0188]
[0189]
[0190]
[0191]
[0192]
[0193]
[0194]
[0195]
[0196]
[0197]
[0198]
[0199]
[0200]
[0201]
[0202]
[0203]
[0204]
[0205]
[0206]
[0207]
[0208]
[0209]
[0210]
[0211]
[0212]
[0213]
[0214]
[0215]
[0216]
[0217]
[0218]
[0219]
[0220]
[0221]
[0222]
[0223]
[0224]
[0225]
[0226]
[0227]
[0228]
[0229]
[0230]
[0231]
[0232]
[0233]
[0234]
[0235]
[0236]
[0237]
[0238]
[0239]
[0240]
[0241]
[0242]
[0243]
[0244]
[0245]
[0246]
[0247]
[0248]
[0249]
[0250]
[0251]
[0252]
[0253]
[0254]
[0255]
[0256]
[0257]
[0258]
[0259]
[0260]
[0261]
[0262]
[0263]
[0264]
[0265]
[0266]
[0267]
[0268]
[0269]
[0270]
[0271]
[0272]
[0273]
[0274]
[0275]
[0276]
[0277]
[0278]
[0279]
[0280]
[0281]
[0282]
[0283]
[0284]
[0285]
[0286]
[0287]
[0288]
[0289]
[0290]
[0291]
[0292]
[0293]
[0294]
[0295]
[0296]
[0297]
[0298]
[0299]
[0300]
[0301]
[0302]
[0303]
[0304]
[0305]
[0306]
[0307]
[0308]
[0309]
[0310]
[0311]
[0312]
[0313]
[0314]
[0315]
[0316]
[0317]
[0318]
[0319]
[0320]
[0321]
[0322]
[0323]
[0324]
[0325]
[0326]
[0327]
[0328]
[0329]
[0330]
[0331]
[0332]
[0333]
[0334]
[0335]
[0336]
[0337]
[0338]
[0339]
[0340]
[0341]
[0342]
[0343]
[0344]
[0345]
[0346]
[0347]
[0348]
[0349]
[0350]
[0351]
[0352]
[0353]
[0354]
[0355]
[0356]
[0357]
[0358]
[0359]
[0360]
[0361]
[0362]
[0363]
[0364]
[0365]
[0366]
[0367]
[0368]
[0369]
[0370]
[0371]
[0372]
[0373]
[0374]
[0375]
[0376]
[0377]
[0378]
[0379]
[0380]
[0381]
[0382]
[0383]
[0384]
[0385]
[0386]
[0387]
[0388]
[0389]
[0390]
[0391]
[0392]
[0393]
[0394]
[0395]
[0396]
[0397]
[0398]
[0399]
[0400]
[0401]
[0402]
[0403]
[0404]
[0405]
[0406]
[0407]
[0408]
[0409]
[0410]
[0411]
[0412]
[0413]
[0414]
[0415]
[0416]
[0417]
[0418]
[0419]
[0420]
[0421]
[0422]
[0423]
[0424]
[0425]
[0426]
[0427]
[0428]
[0429]
[0430]
[0431]
[0432]
[0433]
[0434]
[0435]
[0436]
[0437]
[0438]
[0439]
[0440]
[0441]
[0442]
[0443]
[0444]
[0445]
[0446]
[0447]
[0448]
[0449]
[0450]
[0451]
[0452]
[0453]
[0454]
[0455]
[0456]
[0457]
[0458]
[0459]
[0460]
[0461]
[0462]
[0463]
[0464]
[0465]
[0466]
[0467]
[0468]
[0469]
[0470]
[0471]
[0472]
[0473]
[0474]
[0475]
[0476]
[0477]
[0478]
[0479]
[0480]
[0481]
[0482]
[0483]
[0484]
[0485]
[0486]
[0487]
[0488]
[0489]
[0490]
[0491]
[0492]
[0493]
[0494]
[0495]
[0496]
[0497]
[0498]
[0499]
[0500]
[0501]
[0502]
[0503]
[0504]
[0505]
[0506]
[0507]
[0508]
[0509]
[0510]
[0511]
[0512]
[0513]
[0514]
[0515]
[0516]
[0517]
[0518]
[0519]
[0520]
[0521]
[0522]
[0523]
[0524]
[0525]
[0526]
[0527]
[0528]
[0529]
[0530]
[0531]
[0532]
[0533]
[0534]
[0535]
[0536]
[0537]
[0538]
[0539]
[0540]
[0541]
[0542]
[0543]
[0544]
[0545]
[0546]
[0547]
[0548]
[0549]
[0550]
[0551]
[0552]
[0553]
[0554]
[0555]
[0556]
[0557]
[0558]
[0559]
[0560]
[0561]
[0562]
[0563]
[0564]
[0565]
[0566]
[0567]
[0568]
[0569]
[0570]
[0571]
[0572]
[0573]
[0574]
[0575]
[0576]
[0577]
[0578]
[0579]
[0580]
[0581]
[0582]
[0583]
[0584]
[0585]
[0586]
[0587]
[0588]
[0589]
[0590]
[0591]
[0592]
[0593]
[0594]
[0595]
[0596]
[0597]
[0598]
[0599]
[0600]
[0601]
[0602]
[0603]
[0604]
[0605]
[0606]
[0607]
[0608]
[0609]
[0610]
[0611]
[0612]
[0613]
[0614]
[0615]
[0616]
[0617]
[0618]
[0619]
[0620]
[0621]
[0622]
[0623]
[0624]
[0625]
[0626]
[0627]
[0628]
[0629]
[0630]
[0631]
[0632]
[0633]
[0634]
[0635]
[0636]
[0637]
[0638]
[0639]
[0640]
[0641]
[0642]
[0643]
[0644]
[0645]
[0646]
[0647]
[0648]
|1DECnet & OSU|
|^ |/&font-size:1.1em;."Imitation is the sincerest form of flattery"| |-| proverb
|note><|
WASD requires no additional configuration to support detached process-based
scripting.
|^- The following information applies only if DECnet-based scripting is desired.
|!note|
|^ By default WASD executes scripts within detached processes, but can also
provide scripting using DECnet for the process management. DECnet scripting is
not provided to generally supplant the detached process-based scripting but
augment it for certain circumstances:
|bullet|
|item| To provide an environment within WASD where OSU-based scripts (both CGI
and OSU-specific) may be employed without modification.
|item| To allow nodes without a full HTTP service to participate in providing
resources via a well-known server, possibly resources that only they have
access to.
|item| Load-sharing amongst cluster members for |/high-impact| scripts
or particularly busy sites.
|item| Provide user-account scripting.
|!bullet|
|0DECnet Performance|
|^ Any DECnet based processing incurs some overheads:
|simple#|
|item| connection establishment
|item| NETSERVER image activation
|item| NETSERVER maintenance (such as logs, etc.)
|item| activation of DECnet object image or procedure
|item| DECnet object processing
|item| activation by object of image or procedure
|item| DECnet object run-down
|item| NETSERVER image reactivation
|!simple|
|^ As of version 5.2 WASD provides reuse of DECnet connections for both CGI and
OSU scripting, in-line with OSU v3.3 which provided reuse for OSU scripts. This
means multiple script requests can be made for the cost of a single DECnet
connection establishment and task object activation. Note that the OSU task
procedure requires the definition of the logical name WWW_SCRIPT_MAX_REUSE
representing the number of times a script may be reused. The WASD startup
procedures can provide this.
|^ In practice both the WASD CGI and OSU scripts seem to provide acceptable
responsiveness.
|0Rule Mapping|
|^ DECnet-based scripts are mapped using the same rules as process-based
scripts, using the SCRIPT and EXEC rules
(|link%|../config/##Mapping User Directories++in++WASD Configuration||)
for general information on mapping rules). DECnet scripts have a DECnet node
and |/task specification string| as part of the mapping rule. There are minor
variations within these to further identify it as a WASD or an OSU script
(|link|User Scripts||).
|^ The specification string follows basic VMS file system syntax (RMS),
preceding the file components of the specification. The following example
illustrates declaring that paths beginning with FRODO will allow the execution
of scripts from the CGI-BIN:[000000] directory on DECnet node FRODO.
|code|
exec /FRODO/* /FRODO::/cgi-bin/*
|!code|
|^ In similar fashion the following example illustrates a script "frodo_show"
that might do a "SHOW SYSTEM" on node FRODO. Note that these rules are
case-insensitive.
|code|
script /frodo-showsys /frodo::/cgi-bin/showsys.com
|!code|
|^ Both of the above examples would use the WASD CGI DECnet environment (the
default if no task specification string is provided). By including task
information other environments, in particular the OSU scripting enviroment, can
be specified for the script to be executed within. The default task is named
CGIWASD and can also be explicitly specified (although this behaviour would be
the same as that in the first example)
|code|
exec /frodo/* /frodo::"task=cgiwasd"/cgi-bin/*
|!code|
|^ All task specification strings may also use zero as the task abbreviation.
|code|
exec /frodo/* /frodo::"0=cgiwasd"/cgi-bin/*
|!code|
|^ To execute a script within the OSU environment specify the standard OSU
task executive WWWEXEC, as in the following example:
|code|
exec /osu/* /FRODO::"task=wwwexec"/htbin/*
|!code|
|^ This would allow any URL beginning with "/osu/" to execute a script
in the OSU environment.
|0Scripting Account|
|^ By default the script process is created using the HTTPd scripting account
(usually HTTP$NOBODY, although versions prior to 8.1 have used HTTP$SERVER).
It is possible to specify alternate accounts for the scripts to be executed
within.
|^ The first examples are explicitly specifying an account in the script rule.
|code|
exec /frodo/* /FRODO"ACCOUNT"::"0=cgiwasd"/cgi-bin/*
script /frodo-whatever /FRODO"ACCOUNT"::/cgi-bin/whatever.com
|!code|
|^ It is also possible to have scripts that have been subject to SYSUAF
authorization executed within the authenticated account. The dollar symbol in
the following examples directs the server to substitute the authenticated
username into the access string.
|code|
exec /frodo/* /FRODO"$"::"0=cgiwasd"/cgi-bin/*
script /frodo-whatever /FRODO"$"::/cgi-bin/whatever.com
|!code|
|^ The |/set script=as=| rule used for PERSONA controlled process scripting can
also be applied to DECnet scripts. This includes explicitly specified
usernames as well as SYSUAF authenticated usernames. The server creates an
appropriate access string when the script is activated.
|code|
set /frodo* script=as=$
exec /frodo/* /FRODO::"0=cgiwasd"/cgi-bin/*
script /frodo-whatever /FRODO::/cgi-bin/whatever.com
|!code|
|^ User scripts can also be activated using these rules, either explicitly
specifying the "~" in an access string or using the |/set script=as=| mapping
rule.
|code|
exec /~*/cgi-bin/* /0"~"::/www_user/*/www/cgi-bin/*
exec /~*/htbin/* /0"~"::"0=wwwexec"/www_user/*/www/htbin/*
|!code|
|^ See |link|User Scripts| for more detail.
|0Local System|
|^ To specify any script to execute on the same system as the HTTP server
specify the node name as zero or SYS$NODE.
|code|
exec /decnet/* /0::"task=cgiwasd"/cgi-bin/*
exec /osu/* /sys$node::"task=wwwexec"/cgi-bin/*
|!code|
|^ Mapping rules are included in the examples
|link%=|/wasd_root/example/|WASD_ROOT:[EXAMPLE]|
providing this. After the DECnet environment has been started any CGI script
may be executed on the local system via DECnet by substituting "/decnet/" for
"/cgi-bin/" as the script path, and any OSU script available by using "/osu/".
Behaviour is indeterminate, though it shouldn't be catastrophic, if one is
invoked using the incorrect path (i.e. an OSU script using /decnet/ or a CGI
script using /osu/).
|2Script System Environment|
|^ The target system must have sufficient of the WASD server environment to
support the required CGI script activation and activity. If the target system
is actually the same system as the HTTP server then it already exists, or if
part of the local system's cluster, then providing this should be relatively
straight-forward. If the target system has none of the server environment then
at a minimum it must have the logical name CGI-BIN defined representing the
directory containing the required DECnet object procedure and scripts. The
following fragment illustrates this:
|code|
$ DEFINE /SYSTEM /TRANSLATION=(CONCEALED) CGI-BIN device:[dir.]
|!code|
In this directory must be located the WASDCGI.COM and WWWEXEC.COM procedures
required by the network task. Of course other parts of the environment may
need to be provided depending on script requirements.
|3Proxy Access|
|^ The local system must have |/proxy access| to each target scripting system
(even if that "target" system is the same system as the HTTP server). This
involves creating a proxy entry in each target hosts's authorization database.
The following example assumes the existance of a local HTTP$NOBODY account. If
it does not exist on the target node then one must be created with the same
security profile as the HTTP server's.
|note|
|0Caution!|
If unsure of the security implications of this action consult the relevant
VMS system management security documentation.
|!note|
|^ The zero represents the system the server is currently executing on.
|code|
$ SET DEFAULT SYS$SYSTEM
$ MCR AUTHORIZE
UAF> ADD /PROXY 0::HTTP$SERVER HTTP$NOBODY /DEFAULT
|!code|
|^ It is necessary to ensure the account has permission to write into
its home directory. A network process creates a NETSERVER.LOG (Phase-IV) or
NET$SERVER.LOG (DECnet-Plus) file in the home directory, and will fail to start
if it cannot!
|3DECnet Objects|
|^ To provide DECnet scripting DECnet |/object(s)| must be specified
for any system on which the scripts will be executed. The DECnet object is the
program or procedure that is activated at the target system inside of a
network-mode process to interact with the HTTP server.
|0DECnet-Plus (OSI/Phase-V)||
|^ DECnet-Plus uses the NCL utility to administer the network environment. The
following NCL scripting shows the creation of a network application for the
WASD CGI object:
|code|
$ MCR NCL
CREATE NODE 0 SESSION CONTROL APPLICATION CGIWASD
SET NODE 0 SESSION CONTROL APPLICATION CGIWASD ADDRESSES = {NAME=CGIWASD} -
,CLIENT = -
,INCOMING ALIAS = TRUE -
,INCOMING PROXY = TRUE -
,OUTGOING ALIAS = FALSE -
,OUTGOING PROXY = TRUE -
,NODE SYNONYM = TRUE -
,IMAGE NAME = CGI-BIN:[000000]CGIWASD.COM -
,INCOMING OSI TSEL =
|!code|
|^ To create a DECnet-Plus OSU WWWEXEC object:
|code|
$ MCR NCL
SET NODE 0 SESSION CONTROL APPLICATION WWWEXEC ADDRESSES = {NAME=WWWEXEC} -
,CLIENT = -
,INCOMING ALIAS = TRUE -
,INCOMING PROXY = TRUE -
,OUTGOING ALIAS = FALSE -
,OUTGOING PROXY = TRUE -
,NODE SYNONYM = TRUE -
,IMAGE NAME = CGI-BIN:[000000]WWWEXEC.COM -
,INCOMING OSI TSEL =
|!code|
|^ These must be executed at each system (or server) startup, and may be
executed standalone, as illustrated, or incorporated in the NCL script
SYS$STARTUP:NET$APPLICATION_STARTUP.NCL for automatic creation at each system
startup. Examples may be found in
|link%=|/wasd_root/example/|WASD_ROOT:[EXAMPLE]|
|0Phase-IV|
|^ DECnet Phase-IV uses the NCP utility to administer the network
environment. The following NCP commands may be used each time during server
startup to create the required DECnet objects. With Phase-IV the SET verb may
be replaced with a DEFINE verb and the commands issued just once to
permanently create the objects (a SET must also be done that first time to
create working instances of the DEFINEd objects).
|^ To create a DECnet CGI object:
|code|
$ MCR NCP
SET OBJECT CGIWASD NUMBER 0 FILE CGI-BIN:[000000]CGIWASD.COM
|!code|
|^ To create a DECnet OSU WWWEXEC object:
|code|
$ MCR NCP
SET OBJECT WWWEXEC NUMBER 0 FILE CGI-BIN:[000000]WWWEXEC.COM
|!code|
|^ Examples may be found in
|link%=|/wasd_root/example/|WASD_ROOT:[EXAMPLE]|
|3Reducing Script Latency|
|^ Script system network process persistance may be configured using NETSERVER
logical names. These can control the number and quiescent period of the server
processes. These logical names must be defined in the LOGIN.COM of the HTTP
server account on the target script system.
|bullet|
|item| |*NETSERVER$SERVERS_|/username| |-| |
This logical controls the number of network server processes that are kept
available at any one time. Defining this logical results in a minimum of the
specified number of quiescent server processes maintained. This can improve
script response latency by circumventing the need to create a process to
service the request, at the cost of cluttering the system with NETSERVER
processes.
|code|
DEFINE /JOB NETSERVER$SERVERS_HTTP$NOBODY 5
|!code|
|item| |*NETSERVER$TIMEOUT |-| |
This logical controls the duration a quiescent network process persists before
being deleted. The default period is five minutes. The following examples first
show reducing that to thirty seconds, the second increasing it to one hour.
Again, this can improve script response latency by circumventing the need to
create a process to service the request, at least during the period a
previously created process continues to exist.
|code|
DEFINE /JOB NETSERVER$TIMEOUT "0 00:00:30"
DEFINE /JOB NETSERVER$TIMEOUT "0 01:00:00"
|!code|
|!bullet|
|3DECnet/OSU Startup|
|^ The example STARTUP.COM and STARTUP_DECNET.COM procedures found in the
|link%=|/wasd_root/example/|WASD_ROOT:[EXAMPLE]|
directory provide the essentials for DECnet/OSU scripting. If the INSTALL.COM
startup environment is used setting the PROVIDE_DECNET symbol to 1 in
STARTUP.COM will create the DECnet scripting environment during server startup.
|2CGI|
|^ CGI scripts that use HTTP GET (the default) may be transparently executed
within the DECnet scripting environment. This means that the script is
executed within a network process, on the target system (which could be the
local system), instead of within a process on the local system. Other than
that the WASD DECnet CGI environment behaves identically to the standard
(sub)process CGI environment. CGIplus scripting is not supported and if
CGIplus-only scripts are executed the behaviour is indeterminate.
|^ Scripts that wish to use HTTP POST will need to read the request body from
the NET$LINK stream, rather than from HTTP$INPUT as with (sub)process based
scripts. End of body is indicated by an empty record rather than EOF. Scripts
may quite simply be made to function appropriately in both environments. The
following C code fragment illustrates this.
|code|
if (getenv ("NET$LINK") == NULL)
{
/* via process CGI */
while (ReadCount = fread (Buffer, 1, sizeof(Buffer), stdin))
{
/* processing, processing ... */
}
}
else
{
/* via DECnet CGI */
if ((stdin = freopen ("NET$LINK", "r", stdin)) == NULL)
exit (vaxc$errno);
while (fgets (Buffer, sizeof(Buffer), stdin) != NULL)
{
/* check for end of stream */
if (Buffer[0] == '\\n' && Buffer[0] == '\\0') break;
/* processing, processing ... */
}
}
|!code|
|^ An example of making the HELP database on a system other than that hosting
the HTTP server (using the CONAN script) would be done using the mapping rules
|code|
map /FRODO/help /FRODO/help/
script /FRODO/help/* /FRODO::/cgi-bin/conan/*
|!code|
and for the example DCL SHOW script
|code|
script /FRODO/show* /FRODO::/cgi-bin/show*
|!code|
|2OSU (DECthreads) Emulation|
|^ The WASD HTTP server provides an emulation of the OSU scripting
environment. This is provided so that OSU-based scripts (both CGI-style and
OSU-specific) may be employed by WASD with no modification. As this emulation
has been designed through examining OSU code and lots of trial and error its
behaviour may be incomplete or present errors. A list of OSU scripts known to
work with WASD is provided at the end of this section
(|link|Known Working Scripts||).
|^ Supported scripts include only those that depend on the OSU WWWEXEC object
and dialog for all functionality. Any script that uses other OSU-specific
functionality is not supported. Interactions between WASD's and OSU's
authentication/authorization schemes may be expected.
|^ OSU scripts expect to get the path information unmapped, whereas WASD
always additionally maps any path after the script component has been derived
from the request URI. It may be necessary to ensure OSU scripts are activated
with the associated path SET to provide what they expect. For example:
|code|
set /htbin/* mapONCE
set /osu/* mapONCE
|!code|
|^ The author would like to know of any OSU scripts the WASD emulation
|/barfs| on, and will attempt to address the associated limitation(s)
and/or problem(s).
|0OSU Setup|
|^ Software necessary for supporting the OSU scripting environment (e.g.
WWWEXEC.COM) and selected OSU scripts (mainly for testing purposes) have been
extracted from the OSU v3.4 package and included in the
|link%|/wasd_root/src/osu/|WASD_ROOT:[SRC.OSU]|
directory. This has been done within the express OSU licensing conditions.
|code|
Copyright 1994,1997 The Ohio State University.
The Ohio State University will not assert copyright with respect
to reproduction, distribution, performance and/or modification
of this program by any person or entity that ensures that all
copies made, controlled or distributed by or for him or it bear
appropriate acknowlegement of the developers of this program.
|!code|
|^ An example DECnet and OSU scripting startup may be found in
|link%|/wasd_root/example/|WASD_ROOT:[EXAMPLE]||.
This should be called from or used within the HTTP server startup. It includes
two logical definitions required for common OSU scripts. Other tailoring may
be required for specific OSU scripts.
|0OSU - General Comments|
|^ David Jones, the author of the DECthreads (OSU) HTTP server, outlines his
reasons for basing OSUs scripting on DECnet (reproduced from a USENET NEWS
reply to a comment this author made about DECnet-based scripting).
|code|
------------------------------------------------------------------------
From JONESD@er6.eng.ohio-state.edu (David Jones)
Organization The Ohio State University
Date 12 Aug 1997 09:04:11 GMT
Newsgroups vmsnet.sysmgt,comp.os.vms,comp.infosystems.www.servers.misc
Message-ID <5sp8ub$brs$1@charm.magnus.acs.ohio-state.edu>
------------------------------------------------------------------------
|/|...| some text omitted|
Since I was comfortable with DECnet, I based the scripting system
for the OSU server around it. The key reasons to use netserver
processes rather than spawning sub-processes:
1. DECnet automatically caches and re-uses netserver processes,
whereas there were well-known performance problems with spawning
sub-processes.
2. DECnet processes are detached processes, so you don't worry about
the effect of scripts consuming pooled quotas (e.g. bytlm) on
the HTTP server process.
3. Creation/connection with the DECnet server process is asynchronous
with respect to the server so other operations can proceed concurrently.
Spawning is done in supervisor mode, blocking the server's operation
until the child process is completely initialized.
4. With DECnet, scripts can be configured to run on different nodes
for load balancing.
5. In addition to the standard 'WWWEXEC' object, you can create
other 'persistent' DECnet objects that the server communicates with
as scripts. (this was implemented years before OpenMarket's FastCGI
proposal).
6. CGI is not the be-all end-all of scripting. The dialog phase of
OSU's scripting environment allows scripts to do things CGI
is incapable of, such as ask the server to translate an arbitrary
path and not just what followed the script name in the URL.
People grouse all the time about the installation difficulties caused by
it's reliance on DECnet, the reason shown above were cited to show that it
wasn't made so capricously.
|/|...| some text omitted|
David L. Jones \| Phone: (614) 292-6929
Ohio State Unviversity \| Internet:
2070 Neil Ave. Rm. 122 \| jonesd@kcgl1.eng.ohio-state.edu
Columbus, OH 43210 \| vman+@osu.edu
Disclaimer: Dogs can't tell it's not bacon.
|!code|
|^ The OSU server's DECnet scripting is not based on arbitrary considerations.
This author does not disagree with any of the concerns, and as may be seen from
WASD documentation the design of WASD also directly addresses points 1, 3 and 5
with the use of persistant processes and CGIplus. Certainly DECnet-based
scripting addresses the very legitimate point 4 (and also allows nodes with
specific resources to participate without installing full HTTP server
environments). Point 2 is not an issue with the use of detached scripting
processes, or for all practical purposes addressed by adjusting account quotas
to support the required number of subprocesses. Point 6 is only too true
(possibly at least until Java servers and |/servlets| become ubiquitous |=.:^)|
|0Known Working Scripts|
|^ The following is a list of OSU-specific scripts that the WASD
implementation has either been developed or tested against, and any
installation notes or other WASD specifics. The author would like to know of
any OSU scripts the WASD emulation has problems or works successfully with.
|bullet|
|item| All of the scripts, etc. provided in the
|link%|/wasd_root/src/osu/*.*|WASD_ROOT:[SRC.OSU]| directory.
|simple#|
|item| cgi_symbols
|item| cgi-mailto
|item| html_preproc
|item| set_dcl_env
|item| testcgi
|item| testform
|item| tmail
|item| vmshelpgate
|item| webbook
|!simple|
|item| |*helpgate|
|^ Comment out the |/Conan The Librarian| mappings for the
"/help" path and provide the following in WASD_CONFIG_MAP:
|code|
# first make "/help" into a script specification
map /help* /htbin/helpgate/help*
# general rule mapping "/htbin" to OSU DECnet scripts
exec /htbin/* /0::"0=wwwexec"/cgi-bin/*
# map the non-script part of the path back to just "/help"
pass /htbin/helpgate/help* /help*
|!code|
It is possible to support both HELP environments (although
|/helpgate| will not work without owning the "/help" path),
merely provide another mapping for |/Conan| with a slightly different
path, for example:
|code|
map /chelp /chelp/
script /chelp/* /cgi-bin/conan/*
|!code|
|item| |*HTML pre-processor|
|^ Yes, backward compatibility can be provided for those old OSU .HTMLX
files in your new WASD environment ;^) All that is needed is a file type
mapping to the script in the WASD_CONFIG_GLOBAL configuration file.
|code|
[AddType]
.HTMLX text/html /htbin/html_preproc OSU SSI HTML
|!code|
|!bullet|
|2User Scripts|
|^ The WASD DECnet environment provides a simple mechanism for executing
scripts within accounts other than the server's. This allows configured users
to write and maintain scripts within their own areas and have them execute as
themselves. Both standard CGI and OSU scripting may be provided for with this
facility.
|^ Of course there is always a down-side. Be careful to whom this capability
is granted. User scripts are executed within a user network-mode process
created by DECnet. Script actions cannot generally affect server behaviour, but
they can access any WORLD-readable and modify any WORLD-writable resource in
the system/cluster, opening a window for information leakage or
mischievous/malicious actions. Script authors should be aware of any potential
side-effects of their scripts and Web administrators vigilant against possible
destructive behaviours of scripts they do not author.
|^ User scripting is not enabled by default. To provide this facility mapping
rules into the user area must be provided in much the same way as for user
directories, see
(|link%|../config/##Mapping User Directories++in++WASD Configuration||).
|^ The "EXEC" rule provides a wildcard representation of users' script paths.
As part of this mapping a subdirectory specifically for the web scripts should
always be included. |*Never| map users' top-level directories. For instance if
a user's account home directory was located in the area WWW_USER:[DANIEL] the
following rule would potentially allow the user DANIEL to provide scripts from
the home subdirectory [.WWW.CGI-BIN] using the accompanying rules (first for
CGI, second for OSU scripts):
|code|
exec /~*/cgi-bin/* /0"~"::/www_user/*/www/cgi-bin/*
exec /~*/htbin/* /0"~"::"0=wwwexec"/www_user/*/www/htbin/*
|!code|
|^ Scripts located in these directories are accessible via paths such as the
following:
|code|
/~daniel/cgi-bin/cgi_symbols
/~daniel/htbin/osu_testcgi
|!code|
|0Proxy Access|
|^ For each user account permitted to execute local scripts proxy access to
that account must be granted to the HTTP server account.
|note|
|0Caution!|
If unsure of the security implications of this action consult the relevant
VMS system management security documentation.
|!note|
|code|
$ SET DEFAULT SYS$SYSTEM
$ MCR AUTHORIZE
UAF> ADD /PROXY <node>::HTTP$NOBODY <account>
|!code|
|^ For example, the following would allow the HTTP server to execute scripts
on behalf of the username DANIEL.
|code|
UAF> ADD /PROXY 0::HTTP$NOBODY DANIEL
|!code|