Compaq Secure Web Server (Apache) problem

[Yakov Pekar]

Greetings,

I am trying to get Compaq Secure Web Server T2.0 (Apache) set up on
OpenVms 7.3-1 and get the following error:

PROMPT11> @SYS$STARTUP:APACHE$STARTUP "START"
[Wed Dec 17 18:47:50 2003] [error] (6)no such device or address: error
assigning channel to control mailbox APACHE$SWS_CONTROL_MBX

Any clues on where to look for what is causing this?

Thank you in advance.

Yakov Pekar

[Jairo Alves]

Really old post, not sure if I should just start a new one.. but since no answers, maybe it's something trivial.

[Wed Oct 14 15:10:15 2020] [error] (6)no such device or address:
error assigning channel to control mailbox APACHE$SWS_CONTROL_MBX\n

Post by Yakov Pekar
[Wed Dec 17 18:47:50 2003] [error] (6)no such device or address: error
assigning channel to control mailbox APACHE$SWS_CONTROL_MBX

My case: OpenVMS 8.4 (Update V15)
Just installed today:
HP I64VMS VMS84I_UPDATE V15.0
HP I64VMS HPBINARYCHECKER V1.2-1
HP I64VMS SSL1 V1.0-2L
HP I64VMS VMS84I_MANAGE V2.0

Everything seemed to be ok, but Apache wouldn't come back.
I was thinking it had to do with SSL1 maybe messing up some mod_ssl things on CSWS..

Tried seeing the logs, but found nothing.

Tried finding the mailbox for Apache, but it was not created.
Curiously, the mailbox for SMH Apaches is created, but not the CSWS one.


MBxs:
"ACP$BADBLOCK_MBX" = "MBA4:"
"APACHE$smh_CONTROL_MBX" = "MBA81:"
"CDI$MBX" = "MBA27:"
"DECW$MBX_X11_00003C17_0000" = "MBA78:"
"DNS$_ADSR_MBX" = "MBA21:"
"DNS$_ADTOCO_MBX" = "MBA20:"
"DNS$_CLLOG_MBX" = "MBA22:"
"DNS$_COTOAD_MBX" = "MBA19:"
"LANACP$MBX-SET" = "MBA11:"
"LANACP_MBX-SHOW" = "MBA12:"
"TCPIP$FTP_IMBX" = "MBA50:"
"TCPIP$FTP_RMBX" = "MBA49:"
"TCPIP$FTP_TMBX" = "MBA51:"
"USB$UCM_CLIENT_REQUEST_MBX" = "MBA5"
"USB$UCM_DRIVER_MBX" = "MBA7"
"USB$UCM_SERVER_RESPONSE_MBX" = "MBA6"

Any hints?

[Jairo Alves]

Apache version is:

HP I64VMS CSWS22_UPDATE V1.0
HP I64VMS CSWS V2.2

I'm not sure how to troubleshoot if it won't even startup.

On ucx netstat, I can see the 2381 Apache port for SMH,
but not 80, nor 8080 nor 443.

[Stephen Hoffman]

Post by Jairo Alves
HP I64VMS CSWS22_UPDATE V1.0
HP I64VMS CSWS V2.2

VSI is based on Apache 2.4, and with updated security.

If you want to wade through this, verify the Apache configuration file, ...

apachectl configtest

... and rummage for any Apache-created startup logs.

http://h30266.www3.hpe.com/odl/axplp/opsys/sws22/csws_iguide_22.htm#gol_s

NB: SMH is known to be quite insecure. All versions for OpenVMS. Last
version of SMH for OpenVMS was V2.2-3, IIRC.

[Jairo Alves]

Dear Hoff,

I understand you imply I should just upgrade CSWS to VSI's CSWS version, is that correct?

Post by Stephen Hoffman
If you want to wade through this, verify the Apache configuration file, ...
apachectl configtest

This is the output I get from configtest:

httpd configtest
[Thu Oct 15 07:52:56 2020] [crit] (57)socket is not connected : alloc_listener: failed to get a socket for 0.0.0.0
Syntax error on line 14 of /apache$root/000000/conf/httpd.conf:
Listen setup failed

So I looked it up, line 14:

Listen 80

Weel, I guess the "failed to get a socket" is preventing Apache from starting to listen. But from that, I'm not sure where to look into.

[Volker Halle]

Jairo,

does this (14 year old entry) help ?

https://community.hpe.com/t5/operating-system-openvms/csws-listen-setup-failed-message/td-p/3876150#.X4g6CeZxfcs

Volker.

[Jairo Alves]

Post by Volker Halle
does this (14 year old entry) help ?

Thanks for the tip, I tried the Listen 80 vs 8080 swap suggested, it didn't change the error.

checked the Login.com ACL and protection,
looked into the Apache$WWW Authorize once more.

All semmed to be ok.

I renamed the apache logs because they were in theGB scale, I cant even read them. But no new logs are
getting created since the app can't finish starting up.

I believe VSI is my next stop here.

[Volker Halle]

Did you try $ UCX SHOW DEV/PORT=80 ? If there is a bgxxx device shown, try $ SHOW DEV/FULL bgxxx

This might tell you, if some other software is still using port 80.

Volker.

[Jairo Alves]

Post by Volker Halle
Did you try $ UCX SHOW DEV/PORT=80 ? If there is a bgxxx device shown, try $ SHOW DEV/FULL bgxxx
This might tell you, if some other software is still using port 80.
Volker.

Yeah, I thought thatmight be the case,
but I checked with
$ pipe ucx netstat -an | sea sys$input 80
and there was noone listening there.

The curious thing is, I'm thinking maybe SSL1 or even 8.4Update V1500 were not the root cause,
but maybe the required reboot after U1500. We've seen that there was no permission, ACLs or privilege
errors, but at least there was a disk quota problem. As Apache logs were over 20 GB,
its disk usage went over the Permanent Quota for the APACHE$WWW user. Overdraft was just 100, so
I'm not sure if this alone was the issue starter.

Solving the Quota problem was not enough, though, we're working on the MOD_SSL now,
trying to understand why it's not being well liked by Apache.

[Stephen Hoffman]

...Solving the Quota problem was not enough, though, we're working on
the MOD_SSL now,trying to understand why it's not being well liked by
Apache.

The HPE mod_ssl wasn't tied to the installed SSL kit, per what I was
told by then-HP an aeon or two ago.

It's possible that some of the SSL logical names are getting tangled.

Very few folks use storage quotas, so it is also distinctly possible
that something got snarled and derailed in mid-write and now isn't
recovering well.

[Jairo Alves]

Post by Stephen Hoffman
The HPE mod_ssl wasn't tied to the installed SSL kit, per what I was
told by then-HP an aeon or two ago.

Yes, that seems to be spot on. Here's verbatim what the VSI engineer told me:
CSWS V2.2 UPDATE 2 kit did not utilize SSL1. It was linked against SSL V1.4-467 / OpenSSL V0.9.8w.
The module that shipped with CSWS V2.2 UPDATE 2, is the MOD_SSL.EXE V2.2.

Post by Stephen Hoffman
It's possible that some of the SSL logical names are getting tangled.

Most probably spot on again, see below.

.

Now, the problem was solved. Here's all the things I'd like to leave
here to assist anyone having this issue in the future (mostly compiled VSI support suggestions):

1) Check APACHE$WWW user, premissions, privileges, etc.
2) Check APACHE$COMMON:[MODULES] for ownership and file protection anomalies.
3) In case any module is being rejected, check its .EXE checksum, for example, in my case it was the MOD_SSL.EXE
$ checksum/algo=md5 mod_ssl.exe
$ show sym checksum$checksum
CHECKSUM$CHECKSUM = "C5ABD27B597AE9C5A0DF5E884467D6FB"

Also (optionally) check the link date and other characteristics of the file:
$ show image APACHE$COMMON:[MODULES]mod_ssl.exe

4) Check that no duplicated modules exist on APACHE$SPECIFIC:[modules] that also exist on APACHE:COMMON:[modules]

5) If you changed anything, like copying a new module image, as I did copy a fresh MOD_SSL.EXE
adjust the protection of on APACHE$COMMON:[MODULES] with /prot=(S:RWED,O:RWED,G:RE,W:RE).

Also change ownership to APACHE$WWW if needed.

6) In my case, it was recommended to run

$ @SYS$MANAGER:APACHE$LOGICALS "" "" UNINSTALL
and then
$ @SYS$MANAGER:APACHE$LOGICALS "" "" INSTALL

7) If all went well, by now Apache may be ok again.
$ @SYS$STARTUP:APACHE$STARTUP.COM

In my case, I suppose some Apache logicals got confused,
also, disk quotas were over, but as the server do not need to create a log file except at startup
maybe it just stopped writing log, may some other behaviour, it's not clear.

Thanks everyone that helped over here too.

[Dennis Boone]

Do the assorted VMS TCP/IP stacks implement SO_REUSEADDR correctly?
Early versions of Apache didn't use this, resulting in restart
failures due to connections in CLOSE_WAIT or thereabouts.

De

[Craig A. Berry]

Post by Jairo Alves
Dear Hoff,
I understand you imply I should just upgrade CSWS to VSI's CSWS version, is that correct?

If you are still using SMH, upgrading to Apache 2.4 will break it. Been
there, done that, and ended up uninstalling 2.4 and reinstalling 2.2.
Have you tried shutting down SMH and restarting Apache? They could be
tangling with each other somehow.

[Jairo Alves]

Have you tried shutting down SMH and restarting Apache? They could be
tangling with each other somehow.

I think I don't need SMH really.
Turned it off now, it didn't help Apache SWS,
but I think I'll leave it off for a while.

I've started a support ticket with HPE today, will keep it updated here with the solution.

[Stephen Hoffman]

Post by Jairo Alves
Dear Hoff,
I understand you imply I should just upgrade CSWS to VSI's CSWS version, is that correct?

You're on a dead-end OpenVMS version from a vendor that's ending their
new-patch support in less than three months and exceedingly unlikely to
release an updated Apache, and you're running with an Apache
configuration and a TLS configuration both known to have security
issues, and the only path to newer software and to newer patches is by
acquiring VSI OpenVMS and VSI Apache port and related. 😫

VSI SSL111 is the current kit and the first with TLSv1.3 support and
based on the version of OpenSSL that's currently getting patches and
updates and mitigations from upstream. SSL1 and SSL are not, and lack
TLSv1.3. And the version of Apache 2.0 offered by HPE is equally dicy.
The VSI port is based on Apache 2.4, and offers TLSv1.3. This all on
VSI OpenVMS V8.4-2L1, or variously later.

Post by Jairo Alves

Post by Stephen Hoffman
If you want to wade through this, verify the Apache configuration file, ...
apachectl configtest

httpd configtest
alloc_listener: failed to get a socket for 0.0.0.0
Listen setup failed
Listen 80
Weel, I guess the "failed to get a socket" is preventing Apache from
starting to listen. But from that, I'm not sure where to look into.

That can mean there's something still hanging onto that port. Try
altering that file and temporarily listening on TCP port 8080 as a
quick test, for instance.

If port 8080 works and port 80 does not, figure out what's holding TCP
port 80. Either parts of a previous Apache run left dangling, or some
other LP.

Or reboot the box. Yes, I know that's sacrilege around (some) OpenVMS
folks. But it's also a fast test, and (usually) a fast way to clear off
anything dangling on TCP Port 80. Barring an app that grabs TCP port 80.

Some versions of Apache were sensitive to file formats and required the
stream LF file organization. No, I don't recall off-hand which
versions, and I'm not running anything as old as that Apache and V8.4.

See if switching the file to Stream LF resolves that, if the
configuration file is not already Stream LF.

And as mentioned above, this whole configuration is far past its
sell-by date, whether your management wants to hear that or not.

Yeah, I'm not sure what to do with SMH, if you really need that. That's
unlikely to be provided by VSI. VSI WebUI, maybe? And again, there are
some wonderful SMH attacks available for versions as far back as
OpenVMS is running.

[Craig A. Berry]

Post by Stephen Hoffman
Yeah, I'm not sure what to do with SMH, if you really need that. That's
unlikely to be provided by VSI. VSI WebUI, maybe?

As far as I can see from the release notes (haven't tried it yet) WebUI
does not plug into any of the SNMP widgets that SMH does, so it really
doesn't fill the same function. It's a software management facility
rather than a hardware monitoring facility.

Post by Stephen Hoffman
And again, there are some wonderful SMH attacks available for
versions as far back as OpenVMS is running.

SMH has performed wretchedly on VMS since it first became available, and
the security holes make running it dodgy, but I have yet to encounter
anything else that gives an easy overview of the hardware health of the
system. There is/was that thing from HPE that requires the purchase of
an extra Windows server in order to monitor the VMS server, but that's
not something that could happen where I live.

[Stephen Hoffman]

Post by Craig A. Berry

Post by Stephen Hoffman
Yeah, I'm not sure what to do with SMH, if you really need that. That's
unlikely to be provided by VSI. VSI WebUI, maybe?

As far as I can see from the release notes (haven't tried it yet) WebUI
does not plug into any of the SNMP widgets that SMH does, so it really
doesn't fill the same function. It's a software management facility
rather than a hardware monitoring facility.

IIRC, SMH is (was?) the home of part of the OpenVMS SNMP agent support,
and not within OpenVMS nor TCP/IP Services. That SNMP agent
implementation did shuffle around over time, though.

There's been little discussion of SNMP for a while too, and the OpenVMS
support was SNMPv2 when last I checked. Which is insecure.

Post by Craig A. Berry

Post by Stephen Hoffman
And again, there are some wonderful SMH attacks available for versions
as far back as OpenVMS is running.

SMH has performed wretchedly on VMS since it first became available,
and the security holes make running it dodgy, but I have yet to
encounter anything else that gives an easy overview of the hardware
health of the system.

Zabbix might be a remote-management option, and there is a Zabbix agent
port around for OpenVMS.

Post by Craig A. Berry
There is/was that thing from HPE that requires the purchase of an extra
Windows server in order to monitor the VMS server, but that's not
something that could happen where I live.

Yeah, that all pre-dated HP, as well as HPE. Compaq was fond of
requiring a Windows system for various purposes, too. The expectation
of a Windows system for AlphaServer GS1280 management was certainly
controversial.

I'd expect the developers implementing the monitoring and remote
management and fault management support preferred to offer one SNMP
manager with one display UI app. That for Windows. With SNMP agents
elsewhere.

[Jairo Alves]

Post by Stephen Hoffman
Zabbix might be a remote-management option, and there is a Zabbix agent
port around for OpenVMS.

Just for the record, in case anyone need advice on Zabbix
for OpenVMS I've been using it for like 7 years with good customization, not only agent items.
If anyone need to talk about that, I may be able to help somehow.

Regarding the Apache issue, I'm happy to report that HP(VSI really) support is great,
as always, very knowledgeable and helpful overall.
We didn’t get to solve the actual problem today, but we're most probably headed in the right path.

[Grant Taylor]

Post by Jairo Alves
I'm not sure how to troubleshoot if it won't even startup.

I have no idea if this is a problem on OpenVMS or not, but I have had
Apache (in all of it's incarnations) occasionally give me a panic
attack. After making a very minor and routine change, try to restart
Apache. It will stop, but not start.

I eventually learned that it was not starting because some of the
sockets that it had been using were still open.

I reluctantly came to the conclusion to go get a cup of coffee (3-5
minutes) and try starting it again. Almost all the time it would start
after 3-5 minutes. I had very few times when I had to wait more than 5
minutes.

If this is what was happening to you, I expect that it has started for
you by now.