RE: Broken Red Hat 7.0 support

[Tim Sellar]

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 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Joshua Jackson Sent: 04 April 2001 17:51 To: [EMAIL PROTECTED] Subject: Broken Red Hat 7.0 support I am not posting this message to the bugs list as I want to make sure that I am simply not missing something.  It appears that the Red Hat 7.0 support is far from complete...   I have installed both FreeVSD 1.4.6 and 1.4.7 on 3 seperate Red Hat 7.0 machines, all with the same results.  In each case, the xinetd.conf modification have no effect due to the fact that the service definition files in the /etc/xinetd.d/ directory are not removed.  This prevents FTP, telnet, ssh, and pop3 from functioning properly.   Once these files are removed, everything with the exception of FTP works fine.  The FTP service now reports the following:   421 service not available   As for the "main" host, FTP is totally broken due to the fact that /usr/sbin/proftpd does not exist (Red Hat 7.0 uses wu-ftpd). I would be more than happy to help with this issue, but as a suggestion, you might want to include some simply flowcharts on the actions taken by the various virtualized servers (namely the virtuald daemon)... this would save those of us admins the time of actually having to "use the source, Luke".   As a seperate note, if the host system does not have X and Gnome installed, the freevsd-pkgs RPMs will fail to install during skel generation due to the fact that there are missing deps for the ssh-askpass-gnome RPM (why are you including X apps for the VS's anyway?).  This will produce a few messages about the inability to install ssh-askpass-gnome, but give you no other indication that your skel structure is unusable (missing su, ls, etc commands).   Last, but not least, a small gripe/suggestion... why in the world do you default to using the vsdredirect method for web port redirection.  I understand the security issues of running apache on port 80, but shouldn't you default to using the ipchains/iptables NAT redirections?  I can't think of any situation where I wouldn't care if all of the traffic to my site was logged as coming from the VS itself... not to mention the fact that this makes attempts to use banner ads as a source of revenue pointless as you won't get paid for all of your hits coming from the same host.   Joshua Jackson