Mailing List Archive

On Sat, 1 Apr 1995, Randy Terbush wrote:
>
> The other implementation I have seen sets a CGI environment
> variable to SERVER_ROOT which requires an index.cgi to
> be in the toplevel document directory. Seems like all of those
> execs could add up to a lot of overhead.

Having your homepage be a cgi script might have some deleterious effect
on performance... to be, the obvious way of handling this case would be
to allow the user to specify the local address to bind to in the
configuration file, and start several daemons each listening on a
different port. That way, all the extra effort takes place upfront

Simon // This Message Composed By Voice

> I have this running now :-) I can upload diffs this weekend. Basically
> stuff like:
>
> <VirtualHost www.jellybean.com>
> ServerAdmin webmaster@www.jellybean.com
> DocumentRoot /usr/local/etc/httpd/htdocs/jellybean.com
> ServerName www.jellybean.com
> ErrorLog logs/jellybean.com-error_log
> TransferLog logs/jellybean.com-access_log
> </VirtualHost>
>
> gets added to httpd.conf.
>
> Works great :-). The reason I have not uploaded this yet is there is a
> wierd thing with the logs. The logs in my scheme are opened after the fork,
> but they need to be opened before any fork.

Sounds nice. I would be happy to help you find a solution to
this problem if you would like to make the patch available.

So, what happenned at Sun yesterday? The web site appears unchanged.

I have this running now :-) I can upload diffs this weekend. Basically
stuff like:

<VirtualHost www.jellybean.com>
ServerAdmin webmaster@www.jellybean.com
DocumentRoot /usr/local/etc/httpd/htdocs/jellybean.com
ServerName www.jellybean.com
ErrorLog logs/jellybean.com-error_log
TransferLog logs/jellybean.com-access_log
</VirtualHost>

gets added to httpd.conf.

Works great :-). The reason I have not uploaded this yet is there is a
wierd thing with the logs. The logs in my scheme are opened after the fork,
but they need to be opened before any fork.

Cliff

There is also the other way of changeing the httpd to only listen
on one IP address instead of any. This way you can have 5 deamons
on port 80 if you wish. I used to do this before I started running
an httpd that messed with document root.

BTW since each connection sets the vars, persistent children shoudl not
have any problem.

From: Randy Terbush <randy@zyzzyva.com>

I was just beginning to hack on multi-homed support.
The changes are fairly minor and I wanted to ask the group
what their thoughts are about implementation.

The direction I would like to take would be to reset
'DocumentRoot' based on the answering IP address
(ie the IP that the server is answering for). I see
it being much like 'ScriptAlias' such that if the
IP contacted is 200.100.50.1, DocumentRoot gets
set to /www/docs/200.100.50.1.

Comments?

Hmmm... there are a lot of multi-homed support patches out there, and
I haven't looked at any of 'em, so take this with a grain of salt:

My own personal preference would be to add some sort of conditional
Alias, rather than zorching DocumentRoot. This may be a matter of
taste though; the only concrete reason I can think of for the
preference has to do with going to a persistent-child-process model,
in which you'd have to be fairly careful to set DocumentRoot *back*,
even in the face of unanticipated errors, or Bad Things Might Happen.

(Conditional aliases would require some mods to the alias data
structures in http_access.c, to hold the conditions, but you wouldn't
have to modify anything on the fly).

The other implementation I have seen sets a CGI environment
variable to SERVER_ROOT which requires an index.cgi to
be in the toplevel document directory. Seems like all of those
execs could add up to a lot of overhead.

This does seem a bit extreme...

rst

>
> So, what happenned at Sun yesterday? The web site appears unchanged.
>

'twas an April fool that failed on me, and everyone else by the
sound of it.