|
As for the xinetd.conf... it appears it reads
things first to last and the first entry for a given service wins. Since
the Red Hat 7.0 xinetd.conf includes the xinetd.d directory prior to the addon
VSD options, they win. (This assumption is from experience, not from reading the
source... your mileage may vary).
I have managed to get the FTP services working for
the virtual hosts... the 421 error is due to the fact that the ServerType
directive in the proftpd.conf file is incorrect (it reads standalone and should
read inetd). This needs to be fixed in the skel and any VS's that have been
created.
As for the hosting server, I will look into
installing an unmodified version of ProFTPd...
As for the port redirection, I am using the last
suggestion in combination with the 2.4 kernels. (You didn't need to go into
such detail, as per my original message, I understand the security issues
:-) I have not looked into allowing Apache to run on port 80, but used the
following statement for each VS:
iptables -t nat -A PREROUTING -p tcp -d
123.123.123.123 --dport 80 -j REDIRECT --to-port 8080
Where 123.123.123.123 is the IP for the VS and 8080
is the port that the VS's apache is listening on. (The IP has also been removed
from the listen directive in httpd.conf).
----- Original Message -----
Sent: Wednesday, April 04, 2001 3:37
PM
Subject: RE: Broken Red Hat 7.0
support
Firstly, apologies for the inconvenience. It would
appear the RH7 rpms have been produced incorrectly which is unacceptable even
if RH7 support is considered 'beta'...
A
correctly built RH7 rpm will be posted tomorrow. This should remove the
ssh-askpass-gnome dependency, and also the unnecessary vince
references...
The
failure of the vsd-install.pl script to correctly update the xinted
configuration is not something I am aware of. I thought changes to a
foobar.conf file should override the configuration held in the matching
foobar.d directory structure. But I may be mistaken. I will see if I can
reproduce the problem.
You
state that FTP on the hosting server is broken by the freevsd installation.
This is because freeVSD uses a patched version of proftp within virtual
servers and amends inetd/xinetd configuration accordingly. You must install
proftpd on the hosting server if you wish to gain ftp access. The
vsd-install.pl script is intended to get less experienced users off the ground
quickly. To do so, it makes a good deal of assumptions, one of which is that
for the sake of simplicity ftpd is going to be broken on the hosting server.
freeVSD is not an out-of-the-box ISP solution. It still requires system
administration knowledge to be used effectively and tailored to individual
circumstances, and probably always should.
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. 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.
Tim
| 