in reply to Installation System Design for a Large Apache/mod_perl Application

Sam Tregar said:

Unless you expect your users to dedicate an entire server box to your application, they may not want to install a second mod_perl server on a single box.

And they may have discarded the Apaches that came with their distribution a long time ago.

I run a fly-weight apache, an apache+mod_ssl, and two separate apache+mod_perl servers (one mission critical, one not) on a single box.

IMHO, having an interactive script generating the appropriate Apache config bits and bobs would go a long way to addressing the issues of getting an installation right.

  • Comment on Re: Installation System Design for a Large Apache/mod_perl Application

Replies are listed 'Best First'.
Re: Re: Installation System Design for a Large Apache/mod_perl Application
by samtregar (Abbot) on Nov 16, 2003 at 04:04 UTC
    Unless you expect your users to dedicate an entire server box to your application, they may not want to install a second mod_perl server on a single box.

    They don't have to, I'll do it for them! Basically, you install the app, call it x3000. You start x3000 thus:

    /usr/local/x3000/bin/x3000_ctl start

    Unless you peek under the covers you won't even know it's using Apache. All you need to know is that when you go to the address and port you configured for x3000 you get the x3000 web interface. This is true for Bricolage too, actually. In both cases the user doesn't interact with Apache unless they choose to.

    But to answer your question directly, no the app doesn't need its own server, just two ports (one for HTTP and one for FTP).

    And they may have discarded the Apaches that came with their distribution a long time ago.

    That's an excellent reason not to try to use it. If they compiled their own how am I to know how it's setup? Oh, parse the config you say? Been there, done that, currently running like hell.

    IMHO, having an interactive script generating the appropriate Apache config bits and bobs would go a long way to addressing the issues of getting an installation right.

    It sounds great, but I know how badly it works in practice. That's exactly how Bricolage works. In practice there's just too many ways to setup an Apache install. Trying to adapt to them all automatically, even with a bunch of configuration options, is an endless game of whack-a-mole. I'm determined to find something better.

    -sam

      Tregar said:

      It sounds great, but I know how badly it works in practice. That's exactly how Bricolage works. In practice there's just too many ways to setup an Apache install. Trying to adapt to them all automatically, even with a bunch of configuration options, is an endless game of whack-a-mole. I'm determined to find something better.

      I'm not understaning why you don't just create a conf file that sets up a name virtual server and add

      # --- added by Bricolage configurator --- Include /htc/httpd/bricolage.conf # --- added by Bricolage configurator ---
      at the end of their apache server config.

      And, we can find easy answers to answers to general "where do I put this?" questions for alll the major distros.

      OTOH, if they don't have a competently installed Apache, sending a package that builds one from source would be a blessing to them. Why not give them the option to migrate from their distro apache to a "good" apache?

      And finally, I'd feel concerned about the consequences of your apache forking 30 children on a heavily used site: If the admins lack enough clue to install Apache from source, they won't know what hit them. Then again, a mod_perl site used that heavily would have a more competent sysadmin, I think.

      Who's your target audience: have they clue or not?

        I'm not understaning...

        I don't know to explain it to you any better than to say that it doesn't work very often. If you need proof, just check out Bricolage and then take a look at Bricolage's bug database under 'Installation'.

        And finally, I'd feel concerned about the consequences of your apache forking 30 children...

        That's strange. 30 processes is nothing to a modern Linux or BSD system with reasonable hardware. I'll be sure to tell people how much resource usage to expect, but I doubt it will be enough to put a dent in anyone's load average. This application is a development tool, like Bricolage, and not a front-end web service.

        Who's your target audience: have they clue or not?

        I think an installation system should target people with enough Unix experience to enter a few commands at a shell prompt and edit a text file. I've come to learn that expecting more is expecting too much.

        -sam