Re: Soymail not working with WASD

ultradwc@xxxxxxxxx wrote:
On Sep 27, 8:40 am, Mark Daniel <mark.dan...@xxxxxxxxxx> wrote:

HTTPD$MAP contains exec /cgi-bin/* /cgi-bin/*

$ show log /full cgi-bin
"CGI-BIN" [exec] = "$1$DKA0:[HT_ROOT.CGI-BIN.]" [concealed]
(LNM$SYSTEM_TABLE)
= "$1$DKA0:[HT_ROOT.AXP-BIN.]" [concealed]

correct ...


and you can therefore $ dir cgi-bin:[000000]soymail


correct ...

I'd suggest the 404 indicates there is no SOYMAIL.EXE located in
CGI-BIN:[000000] where it is being told to activate it from. The
instructions

well. it is actually in the [.axp-bin] directory because that
is where

$ @INSTALL INSTALL WASD

put it ...

Excellent.

A 404 can also indicate the server account does not have permission to access the file entry in the parent directory and therefore does not 'see' it during the directory search.

With a script, such as soyMAIL, it can also indicate an error originating from within the script itself. For instance, soyMAIL refuses to access private VMS Mail unless the request provides an authenticated username. Though soyMAIL uses 403s (forbidden) to report such conditions.

Once authentication is going I suspect we may be back to analysing the originally reported 404 error.

the installation went fine and soymail.exe exists because

$ dir cgi-bin:[000000]soymail

shows it there, and purveyor can run it ...

It's interesting that the two server environments can access the same executable when the standard WASD security environment explicitly prohibits any account other than those holding a specific rights identifier.

$ dir /sec cgi-bin:[000000]soymail.exe

Directory CGI-BIN:[000000]

SOYMAIL.EXE;4697 682KB 18-AUG-2007 12:58:06.94 [SYSTEM]
(RWED,RWED,,)
(IDENTIFIER=WASD_HTTP_NOBODY,ACCESS=READ+EXECUTE)
(IDENTIFIER=*,ACCESS=NONE)

Total of 1 file, 682KB

$ dir /sec ht_root:[000000]axp-bin.dir

Directory HT_ROOT:[000000]

AXP-BIN.DIR;1 9KB 21-OCT-2002 02:43:55.54 [SYSTEM]
(RWED,RWED,,)
(IDENTIFIER=WASD_HTTP_SERVER,ACCESS=EXECUTE)
(IDENTIFIER=WASD_HTTP_NOBODY,ACCESS=READ+EXECUTE)
(IDENTIFIER=*,ACCESS=NONE)

(IDENTIFIER=WASD_HTTP_NOBODY,OPTIONS=DEFAULT,ACCESS=READ+EXECUTE)
(IDENTIFIER=*,OPTIONS=DEFAULT,ACCESS=NONE)
(DEFAULT_PROTECTION,SYSTEM:RWED,OWNER:RWED,GROUP:,WORLD:)

Total of 1 file, 9KB


Have you granted either of the the above identifiers to the Purveyor account? If not I wonder how Purveyor is accessing CGI-BIN:[000000]SOYMAIL.EXE?

Please provide the results to the above and following commands.

$ show log /full cgi-bin
"CGI-BIN" [exec] = "$1$DKA0:[HT_ROOT.CGI-BIN.]" [concealed] (LNM$SYSTEM_TABLE)
= "$1$DKA0:[HT_ROOT.AXP-BIN.]" [concealed]

Then list the Purveyor CONFIGxx.DB directive(s) that map(s) Purveyor into the above CGI-BIN:[000000] directory.

the startup_server is there with the /sysuaf=ssl (another type error)


after applying the rule ["soymail_access"=VMS] I now get the
login box, but it fails and does not log me in ... remember, for
private access I have

bob/*/BOB

This is in the soyMAIL not WASD configuration. If the user authentication step by WASD fails then the request stops there. Well before attempting to activate the script itself.

Now, this *is* the browser username/password dialog (just checking)?

and the login still fails (Iam keying in my vms password correctly)

There are other characteristics of an account that WASD takes into consideration before granting access.

http://wasd.vsm.com.au/ht_root/doc/htd/htd_1600.html#hd_auth_sysuaf

For example; is the password expired? Any access time restrictions? Extended privileges? Which now that it is mentioned may be an issue with a BOB account (I would not be surprised if this account had additional privileges). As described above; by default WASD does not permit privileged accounts to be used for authentication. You can explicitly override that restriction using the startup /SYSUAF qualifier keyword RELAXED.

http://wasd.vsm.com.au/ht_root/doc/htd/htd_1600.html#hd_auth_policy

You are already using the SSL keyword. So you would need to modify your HTTPD$STARTUP_SERVER logical value to be "/SYSUAF=(SSL,RELAXED)" and then $ HTTPD/DO=RESTART

However, *before* we do that let's use WATCH to determine *exactly* why it's failing.

http://wasd.vsm.com.au/ht_root/doc/htd/htd_2000.html

WATCH is a tool that if it doesn't indicate exactly the reason for any given server behaviour usually provides a very good hint. Well past time it was utilised. As described in

http://wasd.vsm.com.au/ht_root/doc/htd/htd_1900.html#hd_admin_no_config

we'll now activate it by you entering at the command-line

$ HTTPD/DO=AUTH=SKELKEY=_ROBERT:<any-old-password-string-of-your-own>

(underscore is significant). Then access

https://your.system.name/httpd/-/admin/

which should provide you with a browser username/password dialog box requesting authentication for "SKELKEY". Enter _ROBERT (underscore is significant) and the password string. You should now have the Server Administration menu

http://wasd.vsm.com.au/ht_root/doc/htd/admin.gif

Access the [WATCH] item in the bottom right and in that menu, in addition to the pre-checked items, check [x]Authorization.

Now you need a *completely separate* browser (*not* another window or tab on the current browser). So if you are using Mozilla then bring up Firefox or Opera or even (shudder) MSIE. If using (greater shudder) MSIE then bring up Mozilla, Firefox or Opera (etc). Or if only the one browser is available then on a second machine bring up a browser.

Now in the WATCH Report window hit the [WATCH] button.

In the second browser access

https://your.server.name/cgi-bin/soymail/~

A report page should begin to be generated. The [x]Authorization checkbox should produce output specifically related to authentication/authorization. My development system, set up specifically to replicate your suspected problem, shows output including (my news agent, VMS Mozilla, will munge this horribly)

|03:04:30.83 AUTH 1667 0001 AUTHORIZE AUTHENTICATE user:system realm:VMS|
|03:04:30.85 AUTHACME 0349 0001 AUTHORIZE ACME doi:"VMS" agent:"VMS" mapped:"SYSTEM" %X074A8001 %ACME-S-NORMAL, normal successful completion|
|03:04:30.86 AUTHVMS 0353 0001 AUTHORIZE GETUAI "SYSTEM" %X00000001 %SYSTEM-S-NORMAL, normal successful completion|
expire:(none) pwd:20-MAY-2007:11:20(730AFA6856AB92AE) pwd2:(none)(0000000000000000) life:180-00:00
flags:00B9D40C priv:<63-32>FFFFFFFF<31-00>FFFFFFFF
prime:00000060 netp:000000 nets:000000 remp:000000 rems:000000
|03:04:30.86 AUTHVMS 0743 0001 AUTHORIZE FAIL SYSUAF privileges|
|03:04:30.86 AUTH 2316 0001 AUTHORIZE CHECK realm %X0FFFFF5A DENIED_BY_LOGIN|
|03:04:30.87 ERROR 1072 0001 RESPONSE AUTH:3029 (detailed) 401(401) "Authentication failed."|

The significant report item in this example is

|03:04:30.86 AUTHVMS 0743 0001 AUTHORIZE FAIL SYSUAF privileges|

If it shows this then it's the issue described above and you need to use the RELAXED keyword with the /SYSUAF startup qualifier. If it's something else then include the relevant section in your next post.

Assuming it is the above 'privileges' issue then it's best you disable skeleton-key authorization by HTTPD/DO=AUTH=SKELKEY=0 before making any changes or restarts (you can always reenable it if necessary).

Again assuming the /SYSUAF=(SSL,RELAXED) allows you to authenticate and you have also included the previously suggested

["WASD Admin"=VMS]
/httpd/-/admin/* r+w,~bob

you won't need to go through the separate browser exercise again, you'll just access /httpd/-/admin/ and provide your VMS password if required and access the Server Administration items and WATCH in particular whenever your want/need.

Note I have now added a username restriction to the above authorization rule (the '~bob'). See section "Access Restriction Keywords" in

http://wasd.vsm.com.au/ht_root/doc/htd/htd_1600.html#hd_auth_file

You don't want just any old VMS account accessing the above resources!

also, how do you get soymail to come up directly without first
getting the construction site box?

I am unclear what is meant by 'construction site box'.

but more importantly, the login is failing ...

everything you described above is how soymail and I configured
the package ... the only change I had to make was the =VMS
rule ...
any other suggestions?

Most definitely - WATCH, WATCH, WATCH!

--
Sonja: Judgment of any system, or a priori relationship or phenomenon exists in an irrational, or metaphysical, or at least epistemological contradiction to an abstract empirical concept such as being, or to be, or to occur in the thing itself, or of the thing itself.
Boris: Yes, I've said that many times.
[Woody Allen; Love and Death]
.

Quantcast