"W." <[EMAIL PROTECTED]> wrote: > Let's suppose we want the server to keep performing well and we decide to > have a maximum of 500 domains per server. ( should repeat here that the > intention is to use username1.site.tld, username2.site.tld, etc. and that > these will be very small sites with static html pages.) > > My question was what happens if you have 1.000 or 10.000 users? We'll need > more servers (if we supposedly stick to the 500 per server maximum). > But > what does that mean in view of point # 2 (could things like a username and > password be used to *automatically* create a virtual website).
I understand your concern now. Yes, if multiple servers will be used to host the customer sites it does introduce some complexities to the software you'll need to build. But there are several good solutions. Unless you need to be able to manage the users and sites via the GUI, the project is somewhat simpler. What you need is an automated way to generate DNS records, make changes to Apache configuration files on the appropriate server in real time and then restart DNS and Apache to load the changes. Personally, I'd recommend some kind of mechanism to limit participation by users who will abuse the system. A good start is to require a valid email address and the best way to do so is to send a code or unique URL to the user and to only setup their site after they enter the code on a designated page or visit the uniquie URL. At a minimum you'll need a single database (I'd choose between MySQL and PostgreSQL depending on which is a better fit) to store the user/site info., available machines (which you could add as needed), and a way for the target machine to modify the appropriate files and restart the appropriate services. One solution is to run a script every X minutes on each target machine via cron which queries the database and determines if action needs to be taken. If no site needs to be generated nothing is done, otherwise the script modifies httpd.conf, access.conf, records, etc. and the database record is updated to flag the record as complete so when it's queried next the process isn't repeated for it. There are other solutions and variations to this process. When I build systems like this myself I always ask the client a number of questions and make sure he/she is aware of the pros/cons of each so that the client can choose the appropriate solution. There are other mechanisms that should be considered for security purposes, load monitoring and abuse. That's really outside the scope of this list so I'd recommend discussing with someone with experience in designing and building systems like this. -- Steve Werby President, Befriend Internet Services LLC http://www.befriend.com/ _______________________________________________ cobalt-developers mailing list [EMAIL PROTECTED] http://list.cobalt.com/mailman/listinfo/cobalt-developers
