I agree about the Apache and mod_perl installs too. Foolishly I thought that the versions supplied with the distribution would work. Think again! Even the Perl that was installed by my distribution was not good. So I ended up building EVERYTHING from scratch using sources. After a few false starts I finally got Perl. Apache and mod_perl/nod_ssl/OpenSSL to all work the way they should.

I have also tried some of the other packaging and installing scripts/modules and found none of them truly successful. I genuinely look forward to seeing what you come up with!

jdtoronto

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.

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
[download]

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 ---
[download]

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?

You can't rely on doing live CPAN.pm runs at install time. It puts you at the mercy of the internet, and every time a new module release comes out your software might no longer install successfully. We fixed this in a couple places by hard-coding versions into the script, but that will only work until the author deletes them!

Although probably not a useful solution for your situation, one neat way around this problem is to create your own mini-CPAN that just contains the modules you need. No worries about running old/new versions that cause problems. No worries about modules being deleted from underneath you. The bonus of having a central location to distribute new versions when necessary.

It's relatively easy to build Apache/mod_perl from source in a portable manner but very hard to use an existing install. This should make supporting more platforms easier.

You might want to look at Apache Toolbox as a starting point.

So, what am I missing?

Documenting a standard mechanism for the user of your application to rebuild with the latest module / apache / whatever if necessary. There's nothing worse than knowing that there is a gaping security hole in Foo and not having an easy way to update. Obviously, you'll be releasing a new version too - but us paranoid types like to sort it ASAP :-)

I'd also consider Module::Build as base for your build/installation system. Very flexible and easy to extend - much easier to hack than E:MM.

Although probably not a useful solution for your situation, one neat way around this problem is to create your own mini-CPAN that just contains the modules you need.

That might be a good idea. I need to figrue out if it has enough added value versus a directory of tar-balls to be worth the effort.

You might want to look at Apache Toolbox as a starting point.

Thanks, I hadn't seen that before. Definitely worth a look.

Documenting a standard mechanism for the user of your application to rebuild with the latest module / apache / whatever if necessary.

Definitely on the todo list. I'll probably do this as part of the specification process for the new system.

-sam

Every step you do for the end user, adds responsibility. If your apache install opens a security hole, it is your problem. If they don't setup apache properly, it is their problem. (Security issues rarely result in _OUR_ problem).

Not knowing the total scope of your application, but having a large app of my own, things I run into are:

• Make upgrades easy (preserve previous settings)
• Be able to compare the installation/configuration on a client "test" machine to a client "production" machine.
• Watch out for Windows boxes

Ship with required modules and install them locally.

By including the module distributions we can be sure we have working versions and installation can proceed much more quickly. Installing them into an application local directory means that we won't get unintended changes when the user installs a module at the system level. It also makes it easier to support uninstalls, and allows multiple versions of the application with different module requirements to run on the same machine.

Although this idea would work great when using a dedicated apache/mod_perl setup, if the users decides to run your app on a apache/mod_perl setup that is shared with other apps, then your module versions may interfere with what the other applications expect.

mod_perl will only allow one version of a module to be running at one time, and the first one that gets loaded wins. So if you have two apps that have different INC paths with different versions of the same module, the one that gets loaded will depend on which app is 'requested' first on the server (unless you are already preloading the modules in perl_startup.pl). This could lead to some difficult to trace problems that only occur on server restarts...

But I guess if the user is willing to spend the time to get the app working on a shared apache/mod_perl setup then you can probably expect them to install the modules you require in the main INC tree and not require the privately installed module tree. It's just a matter of giving some extra INSTALL docs.

Those troublesome authomatic installations come mainly from programs that are very expensive to be seen in intimacy.

So they have to be totally automatically installed, and if you don't have someone that pays you to study all the possibilities it would always fail somewhere.

But it would be better to do a simple form where people might fill in all the fields. Every field highly documented by some wiki at www. And some default values for people that might not be able to answer every question.

Then you have your desired installation and the rest would install well because the one that does the installation would be responsible of the results.

It would be helpful if there where some wiki: structured to answer questions about PM troubleshooting issues and related subjects.

What I don't understand is why is it necessary to authomate all the installing.

I suppose it's not strictly necessary, merely highly desireable. There will always be a documented do-it-yourself method; it's the one that developers will use to bootstrap a CVS checkout into a working installation. But it will be much too hard for the average systems administrator to manage, requiring knowledge of Perl, Apache and database installation.

The rest of your message made very little sense to me... What do you mean by 'seen in intimacy'? What do 'structured to answer questions about PM' have to do with this topic?

-sam