The master site has not been moved into a virtual server. If you execute 'ls -al /home/vsd/vsd' you will see that a softlink exists for the hosting server which loops back onto the root filesystem...
When a request for a service is received by inetd/xinetd it is first passed to virtuald. Virtuald will then chroot into the relevant virtual private server's filesystem and start the requested service. In the case of requests to the host server they too are passed to virtuald and chrooted into the 'loopback' virtual private server. The loopbacks filesystem is actually the hosting server's root filesystem hence the service is correctly started on the hosting server... This does mean that the same binarys must exist on the hosting server as in the skels. The default skels use ProFTPd whereas a default RedHat installation uses wu-ftp. This has the effect of 'breaking' ftp services for the hosting server unless ProFTP has been installed (or you could create a softlink which points to the wu-ftp binary). The same can happen for other services depending on how your hosting server is configured. The listening address of services (being run in daemon mode) on the hosting server can also cause a problem. Typically a Linux server is given multiple IP aliases on a network and would be expected to service requests on all the addresses. This is reflected by the default configuration of most services on the hosting server (ssh for example) to bind to all available IP addresses. This conflicts with the way VSD needs to work where each service should only bind to its specific IP address - otherwise the service on the hosting server will handle requests intended for a different instance of the service within the virtual private servers. On a different note, I have been considering producing a skel which dispenses with as many daemons as possible and instead runs all services through inetd/xinetd (this includes Apache and SSH which tend to be run as daemons at present). For low usage sites this should mean that less system resources are tied up in daemons which are not actually doing any work... I know triggering Apache via xinetd is generally frowned upon but I thought it may be useful for supporting higher numbers of low-usage sites. If people think it might be useful - let me know and I will have a go. I may even produce some performance comparisons.... Tim > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of River Hume > Sent: 18 January 2002 07:15 > To: [EMAIL PROTECTED] > Subject: the continuing saga... > > > First of all, thanx to everyone for all the help, and for bearing with me > through all these posts! > > I understand the apache issue now... everything is making a LOT > more sense, > and I actually have a virtual server running. My problems are now few and > succinct: > > 1. The master server is not functioning any longer. I understand > vsd needs > to redirect services, but while it works for new virtual servers, it did > not set up a functional virtual server that runs the original > master server > as it was. In fact, the master server domain/ip doesn't work at > ALL (won't > respond to any service requests, save for ssh, which is handled > outside of > vsd anyway). Ideally, I would like to run my master server NOT as > a virtual > server. Is the vs created for it supposedly exactly as the master server > was, with all the services and software installed, not based on a dumbed > down skel? > > 2. bevs is not working. I can't even get in to set the admin pass... > > [root@eatseek ganjuror]# bevs binaryaxiom > -- cannot read server map file: No such file or directory > > > Apart from these issues, I finally actually have this sucker up and > running! :) *WHEW!* It's taken a long time and a lot of work just > to get to > THIS point... > > Thanx again in advance! > -River > > ------------------------- The freeVSD Support List > -------------------------- > Subscribe: mailto:[EMAIL PROTECTED]?body=subscribe%20freevsd-support > Unsubscribe: mailto:[EMAIL PROTECTED]?body=unsubscribe%20freevsd-support Archives: http://freevsd.org/support/mail-archives/freevsd-support ---------------------------------------------------------------------------- - ------------------------- The freeVSD Support List -------------------------- Subscribe: mailto:[EMAIL PROTECTED]?body=subscribe%20freevsd-support Unsubscribe: mailto:[EMAIL PROTECTED]?body=unsubscribe%20freevsd-support Archives: http://freevsd.org/support/mail-archives/freevsd-support -----------------------------------------------------------------------------
