Bricolage on Linux: page 2
Bundle::Bricolage
After installing Postgres, there is a note about installing a DBD::Pg module before the section on Perl Modules. Once again, I found that it was easier to just skip this side note about installing another module, and go on to the next install. In this case, it was the Bundle::Bricolage perl module package, which attempts to install all the other loose end perl modules mentioned above.
Using the perl -MCPAN installer can be a little bit of a learning curve, but once you get it set up properly, it works really well. The CPAN.pm installer initally asks you for a bunch of data about your system. Most of the answers are already there, you're just verifying that you want to use the defaults, and that you don't prfere to use some other version of a tool MCPAN needs.
When CPAN.pm asks for a list of ftp sites to search for CPAN distributions, give it the ones you know work well. For example, I know that pair.com works well, and that some of the larger universities have good wide bandwidth connections, so I entered a list of numbers separated by spaces that reflected these sites.
Another critical bit to select is the follow option. At some point CPAN.pm will ask if you want to follow the the prerequisites for a given module, or to wait for your decision. DUH! Of course you want the thing to get all the prerequisites. You could be waiting in front of a computer forever, just to type 'yes'.
Once CPAN.pm is set up, it chugs along getting all the modules, and their prerequisites, and their prerequisites, etc. until it has all the parts together and installs them. There are a few modules that have a problem being installed with CPAN.pm. This is not a problem, as the Bricolage install will also go through and look for prerequisites and install them.
Bricolage
Finally, when you install the Bricolage package, it will ask you a bunch of questions about where your components, such as Apache, and Postgresql are. It may find some other install of these packages, so be sure to verify the locations of your newly installed components.
Bricolage will install everything it can, then give you a list of modules it could not install. These modules can be installed by calling the CPan.pm installer in the manner that the Bricolage installer asks you to.
Two of the modules I found to be problematic require leaps of faith. Apache::Request and Test::Class have odd quirks about them. Apache::Request needs to be installed by root, but Apache cannot spawn processes when called by root, so it cannot run its tests. Just assume the tests are unnecessary, and don't run them.
Test::class has a similar problem, which can be avoided by not testing the install. After all, either these modules work, or your install does not. If you can't get it to work, the errors should point you towards one of the bad modules. This sounds cavalier, but honestly, I could not get the install to work without taking this leap of faith. You could feasibly install the modules as some othe user, test them, then install them again as root, but it seems like a lot of work.
Once you've installed the troublesome modules for the Bricolage install, type make install again. The Bricolage installer will pick up where it stopped, and you should get the rest of the install done.
Porting a Database
The last time I set up Bricolage, I kept getting an error involving Postgres. What had happened was that Bricolage had not installed it's database. It could have been due to some missing config variable, or it could have been due to Bricolage not really using any database name other than 'bric', even if I selected another name. As such, I had to do some interesting work-arounds.
First, I determined that Pg.sql int he inst directory of the bric installer contained all the commands necessary to create the default bricolage databases. I needed them in Postgres. Instead of copy/pasting them one at a time, I decided to try using pipe "|" to get the data into the database. It worked like a charm. Here's the command:
This calls psql with the user postgres, and opens database bric, and sends it all the commands in the file Pg.sql. Cool, huh?
Because Bricolage had not set up the database, I was able to use pg_dump on my previous production system, and then use pg_restore to create/fill the new database with all my old data.
This time, however, Bricolage DID create its default database, which lead to a whole slew of headaches trying to use pg_restore. Either pg_restore could not find the database, or the database existed, and pg_restore would not overwrite it. After an hour of tinkering, I finally decided to do it the low tech way.
Having set up both file systems identically, it was easier to tar my old postgresql database, ftp it to my new machine, and untar it than to deal with pg_restore. I could do this because both databases were in the same location, had the same users and passwords, and refered to exterior items in the same directory structures.
This methodology also came in handy when I moved over my preview content from the old server. I really did not want to preview everything in bricolage to recreate all my includes, images, and website widgets, so I tarred and ftp'd my preview directory on my old server to my new server.
Conclusion -- for now
I'm sure that some of my solutions are complete hacks, but they work. It seems that each time I install Bricolage, I run into new and different issues that require unique solutions. Some are more out of the box than others, but all of them teach me something about how to administer a Linux/Unix system.
If you came here because your install has you pounding your head on the desk, then hopefully these notes have helped you get back on track. If your just here to read about Bricolage and determine if its worth installing, you should know that the effort I have gone through to create multiple installs of bricolage on a Mac OSX Laptop and two Redhat Fedora Linux boxes has beeen because the results are worth the effort.
