Main Stories
Slash Boxes

Slash Open Source Project

Slashcode Log In

Log In

[ Create a new account ]

So What is Needed to Make Hosting Multiple Slashsites Easier?

posted by Krow on 03:27 PM January 10th, 2001   Printer-friendly   Email story
So, as we head in to Bender being beta one of the questions I am wondering about is how hard is it to host multiple slashcode sites?
A lot of work as been put into making it much easier to install slashcode with Bender but I imagine that hosting services have found a number of problems setting up their systems. What were they? Have you looked at bender and decided how difficult it will be to maintain multiple sites?
With three hosting companies now and I imagine more on the way, what can be done to make it easier on you?
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login
Loading... please wait.
  • Note that you still have a separate slashd for each site; each is just started by the init.d script.
  • by Anonymous Coward
    For those who care: drupal [drop.org] has support for multiple vhosts.

    Drupal is a full-featured content management/discussion engine suitable to setup a news-driven community or portal site just like Slashdot/Slashdot. It is released under terms of GNU Public License.

    Very much as slashcode is used for slashdot, drupal is used for drop.org [drop.org]. See drupal's documentation page [drop.org] for more information.

  • Well then perhaps stuff should be taken out of http.conf and per my suggestion put everything technically possible within the ~ of the user. the article was posted and i replied to it, don't gripe at me for participating please. it's a simple fact that as long as you have to modify global stuff on a server (http.conf for example) big hosting firms are *not* going to offer slash support.
  • For Internationalization? <ducks>

    Sorry, couldn't resist... :-)

    --


    "How about you interface with my ass? By biting it!" --Bender
  • by Anonymous Coward
    i think the most important thing to keep in mind is to reduce as much as is possible the number of things that need to be done as root to set up and/or run slash, or more specifically out of the uid of the person running the slash site, as is possible. the reason is most hosting companies give you your own uid and support perl and give you db access and so on. you do with it what you want. but when you start needing customizations to the OS in a global regard, for example httpd.conf modifications and so on, that is going to be the problem. it would be nice if there was a way to install and run slash within a user account and have slash not use *anything* outside of it. have it use it's own local copy of lib files, etc.
  • I believe right now we need a separate slashd daemon for every virtual host (am I wrong?) and therefore a different entry in the system startup/reboot section.

    It would be great (and a better use of resources) if a single slashd would iterate over all configuration files and update all hosts.

    --

    "It is more complicated than you think" -- The Eighth Networking Truth from RFC 1925

    --

    Check out the Slash in Italian Project [kenobi.it]

  • I must agree with pudge: Slash is such a big beast and an important service on the VirtualHost (usually it forms 100% of the web site structure) that has to be properly configured in httpd.conf.

    But... What about providing a clean structure that can be Included in httpd.conf? I use this solution with my web provider and then you can split duties within service provider and user (i.e. Slash site webmaster)
    --

    "It is more complicated than you think" -- The Eighth Networking Truth from RFC 1925

    --

    Check out the Slash in Italian Project [kenobi.it]

  • Another thing that could be optimized is the portald behaviour and database: now every site has its own blocks tables with portald blocks, usually from RSS channels. So a host with n Slash sites connects n times per hour to slashdot.org and keeps n copies of latest headlines, slightly different.

    Since you cannot join two databases under MySql/PostgreSql, a new shared database for portald can come handy - maybe it's more complicated that it sounds at first.
    --

    "It is more complicated than you think" -- The Eighth Networking Truth from RFC 1925

    --

    Check out the Slash in Italian Project [kenobi.it]

  • Now that is an interesting thought. I had thought to put in a mySlash theme at some point with a starting point of cheesy portal. I have an RSS system I use on other sites that might actually work for this.
    A shared RSS system certainly would be handy though. The only thing that I think local systems would need is a way to either list certain portals or not. It would also be very possible via SOAP to make it so that any slashsite could use the portal system from one central site.
    We have also been discussing how to expand the entire portald system so that it is much easier to add other types beyond RSS.
    --

    --
    You can't grep a dead tree.
  • This is already addressed in bender. There's one script that runs on startup and launches and setuids the slashd for each site. It seems to work well in the alpha version.
    global = useless
    --
    global = useless
  • Well, this behavior (if existed) would have to be configurable. slashd DOES need to be rewritten (not for 2.0, though ... maybe 2.2 or 2.4), so it is something we can revisit later. But some sites might want to customize their slashd (as we do on several of our own sites).
  • by Anonymous Coward
    Yes but remember the essence of a project that works well in a virtual host environment is that which isn't global, but rather per uid. Just make sure 1 user's slash install/site doesn't touch/interfere *at all* with that of another user's.
  • Yes, I see no way around changing the httpd.conf. If for no other reason, because you need to get permission to run it! But technically speaking, Slash is married to Apache (even moreso than it was before). It ties in to specific portions of the Apache request cycle, and there is no way to do this without going through the httpd.conf.

    As to having something that can be included in httpd.conf ... good idea! Krow finished that up earlier this week. :-) There is on main Include file, and then each slas
  • I've said it before, and I will say it again. :-) There is a good reason why root is required for the steps in the installation process: they are things that can drastically change a system, break it, or do other bad things. Even if we could make it so you could get along without making changes to httpd.conf, for instance (which we cannot do), we wouldn't want to. At least I wouldn't. Sysadmins would hate us for it.

    It is possible to run it without root access. If root gives you access to an httpd.conf Include file, for instance. But root still needs to do it. You could always build your own httpd / perl / mysql in your home directory, too. But again, the reason why only root can make changes to stuff like httpd.conf is because it is dangerous to run stuff without root's approval. I see no reason to circumvent that.
  • If needed I have a simple script that I use to start all of my slashd processes on slashhosting. I could provide this if needed. Email me. You can find an address on slashhosting.com.