On 2011-08-15 16:37, Pete Houston wrote:
On Mon, Aug 15, 2011 at 10:16:29AM -0400, Ben Timby wrote:
In the above way, the administrator could delegate control of portions
of the configuration to a user without the overhead of an .htaccess
file. Also, you could include a file which in turn includes other
files. Thus, the administrator could delegate via httpd.conf a config
file to the user which in turn could delegate to a set of files. This
would give you localized management in a set of files.
There are two problems with this which I can see.
Firstly, from the web server manager's point of view this is a bad idea,
because all it would take would be for the user to construct a conf file
with a syntax error and the whole server is taken down. Too much of a
risk on a shared server.
Secondly, from the user's point of view, they make their change to the
conf file, but it will only become active when the server is restarted
to pick up the changes, so probably daily or worse weekly. With a
.htaccess file the changes are instantaneous.
True, as far as it goes.
However, while there is no way to limit what an Include file contains,
you can restrict what users are allowed to put in htaccess files.
This coincides with what you're describing in that changes to Include
files should be tested before restarting apache with apachectl
configtest, and disabling or (re)moving offending Include files.
This would be the responsibility of the server admin.
The use of htaccess files can be quite wide-ranging but it doesn't have
to be, and the depth of manipulation the OP wanted to achieve is best
split up between these two mechanisms.
Moreover, he obviously wasn't allowing end-users to manipulate htaccess
files at all, as he explicitly stated this was a fix for an
"inconvenience" in configuration differences between development and
production.
Both of these are the server admin's responsibility, and one assumes
that the server admin is paying attention when deploying new
configurations to production.
So, while it's nice in theory, there are practicalities which mean that
it is unlikely to happen in a shared server scenario.
In a shared HOSTING environment, you're absolutely correct.
The OPs stated goal had nothing to do with shared hosting, although he
generalized the request to extend that far.
Perhaps I should have made more plain that I am in no way claiming this
feature - or any feature - should not be implemented, or discussed; I am
not an apache developer so I wouldn't have much to say about it one way
or the other.
That's not at all my point - my point was that HIS goal does not need
any kind of new feature implementation.
--
J.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
" from the digest: users-digest-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
