Search:

Describe DaveEvans/UbuntuSetup here.

Installation on a modern Ubuntu server

Notes after trying out LukasLalinsky/UbuntuServerSetup on a "gutsy" server.

• apache-perl not available in gutsy, so let's try mod_perl 2

  • sudo apt-get install perl apache2 libapache2-mod-perl2 libapache-dbi-perl

• Use libpq-dev instead of postgresql-dev

• Add sudo apt-get install patch before trying to use patch

• Use libapache2-request-perl instead of libapache-request-perl

• Why install both String::Unicode::Similarity (our patched copy), and also String::Similarity?

  • Let's try using just String::Similarity (1.03): sudo cpan install String::Similarity

  • Looks like the codebase was patched for that long ago. So we don't need String::Unicode::Similarity any more

• The codebase now uses libossp-uuid-perl, so no need for UUID from CPAN

• apt-get install libjson-perl

So we'll need an mb_server patch for mod_perl 2.

TODO:

• memcached not started by default

• apt-get install apache2-mpm-prefork ("worker" mpm not good for mod_perl)

• avoid pgsql locale error by doing "env LANG=C apt-get install postgresql-8.2" ?

  • yes, this works. Then you just need to adjust pg_hba.conf to suit.

mod_perl 2

Moving to mod_perl 2 (i.e. changing the mb_server codebase so Apache2 is expected, not Apache(1)).

Running, but I need to test this to see if I got it right.

Split Apache configs

See http://bugs.musicbrainz.org/ticket/721

I'd like to change vh_httpd.conf so there's one apache config fragment for the front end (static content, mod_proxy, mod_rewrite) and another for the back end (mod_perl only). Currently the live apache-perl / apache2 config is VERY different from the SVN "vh_httpd.conf". We should be able to arrange things so that you only ever have to make minor adjustments to the SVN config (whether on dev, live, or elsewhere).

Related ideas:

• how to make it easy to use this under Ubuntu:

  • In development, we just use one apache: apache-perl

  • On live, we use two: apache-perl and apache2

  • However now I'm proposing using apache2, with two (or more) independent instances

  • Therefore we need a way to make it easy to run multiple, differently-configured apache2 instances on one server

  • e.g. this probably involves installing apache2, then cloning/modifying /etc/init.d/apache2 and /usr/sbin/apache2ctl

• More than two apaches?

  • I wonder if there's some mileage in separating out the back-end apaches:

    • front-end proxy (static content, mod_rewrite, mod_proxy)

    • back-end mod_perl (for Mason pages)

    • back-end mod_perl (for WS requests and /cgi-bin/*.pl)

    I suggest this because the two back-end mod_perl servers would have very different request profiles. Mason requests are relatively infrequent and for a relatively large variety of pages; WS requests are far greater in number and with much less variety.

If we provided three separate apache config fragments (say), it should be easy to flip between the following configurations:

• a single apache2 (mod_rewrite, mod_proxy, static content, mod_perl). The mod_perl part would probably be on a separate port, and the "front end" would proxy the requests through to itself on the "back end" port.

• two apache2s: front and back. Much like the live server is now, but with more SVN-based config.

• three apache2s: front, back (WS), back (Mason)

Multiple MPMs

It would be nice if the front end could run the "worker" mpm, and the back end(s) run the "prefork" mpm. However the Ubuntu packages are marked as conflicting with each other (apache2-mpm-prefork, apache2-mpm-worker). Both packages provide /usr/sbin/apache2.

You can use dpkg-divert and "dpkg --install --force-conflicts" to install both mpms (and divert one one of the "/usr/sbin/apache2"s elsewhere, e.g. "/usr/sbin/apache2.prefork". Not sure how "apt-get" then handles the fact that you've got two conflicting packages installed, though.

Failing that, other possibilities include:

• repackage so that the MPMs don't conflict (but this means keeping an eye on the mainstream packages, and rebuilding whenever the package changes)

• use the prefork MPM throughout

• put the front end on a separate box from the back end(s)