Perhaps the Linux muse was smiling on me when I did my previous install of Bricolage on a linux box. I say this because it was so easy that I decided to not write about it in any detail. Of course there was some mucking about, but having just followed the instructions and got a reasonable install out of the deal, I figured "Why Bother".
That little phrase will haunt me for at least two weeks, after which I'll forget the troubles (and details) involved in my latest venture -- installing bricolage on a Linux box using Fedora's installed modules. Luckily, I have a little time to write about it now before the scarring in my brain tissues numbs the nerves that hold the details.
First, let us review the concept of GIGO. It's a geeky computer acronym which stands for Garbage In, Garbage Out. It is related to the non geek phrase, "you get what you pay for". In this case, GIGO refers to the fact that the default install of any highly technical set of code is complete garbage and will trash your install of other highly technical code that depends on it.
To sum it up, DO fix what appears to be NOT broken. Perl needs to be installed a specific way, Apache needs to be configured just right, and of course Postgresql's default install can be tweeked to fit, but there's scant detail as to exactly what config file needs to be modified with the cryptic variable assignment.
The finer points for a Bricolage install are all located at David Wheeler's site. The Bric::Admin API browser has the step by step instructions. Here's the easy way to get to them.
Please note that due to an odd quirk in the way his page is set up, the user entry fields (yellow boxes) do not always fully encapsulate the code. This can result in missing some critical variable assignment. Either have your screen set really wide, or be sure to scroll right to make sure you have everything selected before copy/pasting your way to a good install.
These are notes on MY particular install. It was done following David's instructions with variations based on bits of knowledge gleaned during previous installs. You may want to read his page simultaneously for many sections of this page, as they interrelate closely, and I'm not going to spend huge amounts of time reproducing his page here.
The -Dinstallusrbinperl option will wipe out the default perl binary located in /usr/bin/perl, and make it a symlink to the new Perl you are about to install in /usr/local/bin. If you are attached to it, or think you might mess something up and need to use a non damaged copy of Perl, it is best to copy /usr/bin/perl to /usr/bin/perl-bak before starting the install.
It's optional. I never install it. Open SSL, Apache SSL, Mod SSL. Yes, if you want your web production system to be MORE secure, you can make it so with a few additional hours of frustration as modules load modules that need modules... etc. As for myself, I just have my production server behind a firewall on a weird port using basic username and password security. no, the password is NOT my birthday.
Remember to install the Mod Perl module first. THEN do the Apache install. The Mod Perl install refers to the Apache installer directory (../apache_1.3.*/src) in the makefile.PL command. be sure your apache install is there, and not in some other directory.
The Apache install is easy, just be sure to get ALL the variable definitions in the .configure line. This one is particularly long, and rolls of the screen.
The install instructions state "Don't forget to install the Apache::Session and Apache::Request perl modules now" I found this to be a pain in the butt, and eventually unnecessary, as both the Bric::Bundle and the main Bricolage install will install these modules. You can choose to try and install these, but I suggest you don't, as their required prerequisite bundles have required prerequisites etc. Instead, just continue on to the Postgresql install.
Remember GIGO? Here's a chance to ignore GIGO. If you have Postgres installed, "all you need to do to get it ready for use with Bricolage is edit your postgresql.conf file (run locate postgresql.conf to find it) and turn on the tcpip_socket option: tcpip_socket = true"
Don't do that! I did that with this install, and it didn't work. The version of Postgres that came with Fedora 3 didn't have a tcpip_socket variable listed in the postgresql.conf. When I added it, it didn't make any difference, and bricolage constantly died trying to install when I pointed it to the default Postgres install. I just checked the postgresql.conf file for my WORKING version of postgres, and it TOO does not have a tcpip_socket variable defined.
There ARE symlinks, but you have to read the man page first.
Speaking of MAN pages, the last step in installing postgres is to install the documents. Earlier versions of the postgres installer had a docs directory. The one I downloaded has a doc directory. Note the lack of 's' at the end of doc. The new one works just like the old one. In my case, the doc installer may have updated the MANPATH variable, but did not update /etc/man.config. In this config file, you will find a block of lines that start with MANPATH. Add 'MANPATH /usr/local/pgsql/man' after them, and you'll still be able to read documentation on Postgres after logging out and re-booting.
Just when you thought you were done with Postgres, you're not. You need to install the startup script. This is the time to make postgres run when you reboot. Go to the contrib/start-scripts directory and copy the appropriate startup script (mine was named linux) to /etc/init.d/postgres. set the permissions to ug+x, and verify the filepaths in the script. It is frustrating to have to figure out how to start a critical component or three when you have to reboot the machine for some reason.