I believe the hanging is being caused by vsdredirect so the solution is not
to use vsdredirect. We are working on this, but the present solutions have
already been outlined a number of times, see below:
With regard to vsdredirect, here is some background:
Running the Apache processes as root raises security issues in that it makes
certain root exploits possible. However, if the process does not run as
root, it is unable to allocate ports < 1024. Instead we make it allocate the
ports 8080 and 8443 and use vsdredirect to carry out simple port
redirection. Unfortunately, this means that some of the original ip-packet
information is lost. This can be seen in the problems with HTTPS and the
fact that Apache logs will show the connection ip address as being the local
machine rather than the actual connecting client. In order to resolve this
problem you need to be carrying out a much more sophisticated ip
masquerading rather then simple port redirection and this requires serious
programming at a very low (kernel) level. I don't believe this is practical.
We have investigated the problem that logging is affected and there is no
simple solution. Defaulting to an ipchains solution for port redirection
simply does not work on 2.2.x kernels. It results in all HTTP requests being
redirected to the first configured virtual server, which is no use at all.
I see the following options:
i) Allow Apache to start-up with root privilege and allocate ports 80 and
443 - Not good.
ii) Make do with limitations imposed under the current kernel and use
vsdredirect - (only practical if you do not need HTTPS or accurate Apache
logs)
iii) Upgrade your kernel to 2.4 and utilise iptables to carry out the
redirection - (incidentally upgrading to kernel 2.4 potentially removes the
problem anyway because process capabilities would allow Apache to be started
with only sufficient privilege to allocate port < 1024, without being given
all the other root privileges)
We default to using vsdredirect because it is presently the most reliable
method of providing the necessary port redirection and works on both 2.2.x
kernels (RH6.x) and 2.4.x kernels.
A possible workaround, recently discovered by Jimmy Koerting, is to redirect
to a different port on every virtual server. ie. 8080 on vsone, 8081 on
vstwo, 8082 on vsthree, etc.. I believe this has the problem that the Apache
configuration within each vs must be ammended accordingly and could get
complicated when virtual servers are created/deleted/migrated. I think this
will provide a better, if less elegant solution, than vsdredirect and may
become the default method. Given that workarounds exist, this has not been
made a priority. If there are sufficient calls for it to be done, we could
probably prioritise the work."
A recent post by Caleb, gives a recipe for implementing the variable port
number workaround:
http://www.freevsd.org/support/mail-archives/freevsd-support/2001/May/0023.h
tml
I believe the use of iptables will solve this problem once and for all and
this will come about when we implement full RH7.1 support following the
mid-May release.
Tim
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Ben Kennish
> Sent: 04 May 2001 12:05
> To: [EMAIL PROTECTED]
> Subject: Rebooting with WebAdmin scripts
>
>
> Has anyone found a resolution to the "reboot your VS" section not
> working properly with the WebAdmin scripts.
>
> I know that the VS is going down by clicking the button (e.g. my telnet
> session is "closed by remote host") but it rarely shows the results of
> the reboot (instead just stalling and giving a blank browser page.)
>
> Thanks all,
>
>
> ----
> Ben Kennish
> [EMAIL PROTECTED]
