Post by David Froble Post by Stephen Hoffman Post by email@example.com
Recent I installed the web server, I would like run it under an
existing account. But it looks like apache$www is everywhere in the
configuration, startup and shutdown script. looks like you have to use
the default account - apache$www. Is there a way to change this default
I certainly hope not. I'd use the default install, and would set up
identifiers and would use file and directory ACLs to allow specific
users or groups or identifier-holders to have read or read-write access
in the web-related directories.
Never used the product, so I don't know details.
It sure would be nice for the web server stuff to use a logical, or
rooted logical, and then one logical name definition would suffice for
putting it wherever you desired.
I'd generally rather have a preferences file associated with the app
bundle and not logical names defined somewhere random and then used as
a run-time configuration mechanism. Certainly locating the web server
data files somewhere other than the system disk is reasonable.
Interestingly, that's also a standard part of the Apache configuration
No need for a logical name there, either. But as for the Apache files
and the Apache configuration files and related not-user-populated
directories? Preferably those are in the same spot on all systems, and
with no supported means to relocate those.
Running under a different username, not so much. Particularly around
web server security. Though there is the chroot directive available
via mod_unixd, though whether mod_unixd has been ported to or even
works with OpenVMS, as it's not listed as part of the HPE distro.
Really not fond of the idea of using some other random username here
though, and this chroot looks like the best bad compromise for the OP.
But no mod_unixd in the default install (unless VSI has added it), so
no chroot, and OpenVMS has no chroot jail, etc. Running under a
different username on OpenVMS? Wouldn't expect that to work right, nor
to upgrade reliably across arbitrary versions.
(page 35 for module list)
Post by David Froble Post by Stephen Hoffman
Why not? Okay, OpenVMS is generally way, way, way too willing to
expose this sort of stupid-flexibility to end-users, which makes
creating the associated procedures and the testing far, far, far, far
more difficult than it should be, and often exposes this flexibility
for absolutely zero gain. The developers think they're providing
something useful, when they're really either trying to avoid making a
decision, or they're making the effort required of the end-users and
third-party developers harder. This sort of flexibility makes the
associated VSI and third-party and end-user command procedures — if
they even support this sort of customization, or support installing
somewhere weird, or otherwise — more complex to test, and to support.
I've always considered the flexibility in VMS to be a strength, not a
weakness. Perhaps in some situations, and opinions, it's not.
UI flexibility for a good cause is can be good thing. Flexibility
that just works, without requiring the end-user or the developer to
deal with or know about the flexibility is even better.
UI flexibility just for the sake of flexibility, or because the
designer or the developer didn't want to or wasn't able to spend the
time to learn about what problems folks had — which can be very
different from what problems folks tell you they have — or the designer
or developer didn't want to make a UI decision, or didn't want to think
through the actual benefits and ramifications of the flexibility, or —
worse — didn't want to force third-parties to make code changes that
they really need to make, not so much. The more that can be pulled
out of a user interface design and particularly the default UI, the
better it'll serve folks.
Post by David Froble
Now, if the web server became part of the OS, then yes, just as with
the rest of the OS, run it as provided. Just hope whoever sets up the
standard stuff did a decent job.
Ok, perhaps look at electrical service in the US. Everyone get 110
volts, 60 cycle. The electric company doesn't give you the option of
voltage and such.
Perhaps I'm an old dinosaur, and perhaps I'll soon be joining them,
but, for me, I still think the flexibility is a strength.
Makes for more testing, more documentation and more permutations and
for more support costs, too. (How many tools correctly deal with
<directory> syntax, for instance? For some years, I deliberately set
my login directory and the system configurations to use that syntax,
and it blew up parts of OpenVMS, and more than a little of the add-on
apps and third-party code for OpenVMS. Don't get me started on the
utter disaster of manual directory parsing necessary in DCL, either.)
Much like compatibility, flexibility is theoretically wonderful.
Unfortunately, profligate use of either compatibility or of flexibility
leads to pain. To security pain. Support pain. Upgrade pain.
Third-party where-the-heck-are-the-web-configuration-files pain.
Splattering-files-all-over-the-system pain. To user interfaces that
The more I have to add onto the system and dink around with and to
manage and patch and upgrade separately, and the more I have to
special-case, the more the costs accrue.
or software primacy aside, of getting from this UI:Loading Image...
something closer to this:Loading Image...
Pure Personal Opinion | HoffmanLabs LLC