make cpan fails, what can I do?make install exit with the error 'Missing or empty inst/bricolage.sql!'?make install exit with the error 'Unable to set bricolage.conf variable APACHE_BIN to "/usr/local/apache/bin/httpd"'?make install exit with the error 'IDENT authentication failed for user "postgres"'?<html><head></head></html> or nothing at all. There are no errors in the error log or the access log. What's wrong?Bric::FAQ - Bricolage Frequently Asked Questions
$Revision: 1.7.2.17 $
$Date: 2004/04/16 15:58:23 $
This document tries to answer questions asked frequently on the mailing list or other questions that people might have when starting out with or evaluating Bricolage.
This section answers questions that someone evaluating Bricolage might have.
Currently only PostgreSQL support is maintained. There is an Oracle driver, but it's old and not known to work. David says there is also a MySQL driver somewhere, though I don't see it in the sources.
Many people have asked whether Bricolage will support MySQL. The problem used to be that MySQL didn't support transactions; now it can, but there is no support in Bricolage for it yet. Patches are welcome.
I dunno. [compare to mod_perl, CGI, static, other CMSs ... ?]
It has received praise for being as good as or better than commercial alternatives. For example, see http://www.eweek.com/article2/0,3959,652977,00.asp
Some that we know of are:
The PIRT Group - http://thepirtgroup.com/
World Health Organization - http://www.who.int/
DFA - http://dfafunds.com/
Macworld - http://www.macworld.com/
MacCentral - http://www.maccentral.com/
Ad Council - http://www.adcouncil.org/
Open Forum Europe - http://www.openforumeurope.org/
Yes. Kineticode, founded by Bricolage maintainer and lead developer David Wheeler, offers a range of technical support and templating support options, as well as Bricolage consulting services. Learn more at http://kineticode.com/services/.
You are very fortunate, because mod_perl 1.x is just not too stable as a DSO. Weird things tend to happen. That's not to say that some haven't set it up as a DSO and just had it work, but we've seen all sorts of unexplainable problems just evaporate when users have switched from a DSO to a static mod_perl. And it's not Bricolage so much as Mason where the problems are noticed. The Mason site (http://www.masonhq.com/) has a couple of FAQs that mention the issue:
You can also search the Mason Users list archives (http://marc.theaimsgroup.com/?l=mason) and the mod_perl Users list archives (http://marc.theaimsgroup.com/?l=apache-modperl) for some discussions of this issue.
This section contains questions about error messages output by Bricolage.
make cpan fails, what can I do?Bricolage depends heavily on CPAN modules. The purpose of make cpan is to verify that the required CPAN modules exist and, if not, fetch and install them from CPAN, whenever possible. In the worst case where it cannot handle the an error automatically, it gives instruction on how to do it manually. Usually, the instruction tell you to
perl -MCPAN -e shell
look package::module
perl Makefile.PL
make
make test
make installwhere package::module is the name of the file to look for.
Sometimes, it will exit with a error without telling you what to do. Read the last few lines of the output. See which package::module caused the error. Then manually install the module using the procedure outlined above. If, when carrying out the procedures described above, make test fails, you might still want to go ahead with make install nonetheless. However, bear in mind that the module might not be installed properly. After this, rerun make cpan.
For an example, at this writing (2 August 2003), Apache::ConfigFile can cause a permission problem. make cpan will report a strings of
cannot set uid=88nnnn, gid=nnnnnRead a few line before the error message to determine the actual location of the download file, it is usually something like /root/.cpan/sources/authors/id/N/NW/NWIGER/Apache-ConfigFile-0.14.gz. cd into the /root/.cpan/sources/authors/id/N/NW/NWIGER/ directory and untar the tar.gz file:
tar -zxvf Apache-ConfigFile-0.14.tar.gzYou will get the same error messages. Note, however, that untar is successful and the directory Apache-ConfigFile-0.14 is created. cd into this directory and run
perl Makefile.PL
make
make test
make installThis should succeed. After this, rerun make cpan again. More information can be founded in http://bugzilla.bricolage.cc/show_bug.cgi?id=435.
Sometimes, make cpan reports that a CPAN module is not found. This could be because it is trying to get an older version of the CPAN module which CPAN no longer hosts because your CPAN index file is out-of-date and needs to be refreshed. To refresh your CPAN index file,
perl -MCPAN -e 'reload index'and repeat make cpan.
Sometimes you might need to update your CPAN bundle, itself:
perl -MCPAN -e 'install Bundle::CPAN'make install exit with the error 'Missing or empty inst/bricolage.sql!'?You downloaded Bricolage from CVS and didn't run make dist. Do something like this:
# make dist
[lots of output...]
# cd bricolage-1.5.0
# make installmake install exit with the error 'Unable to set bricolage.conf variable APACHE_BIN to "/usr/local/apache/bin/httpd"'?Most likely it's because you're installing Bricolage on Red Hat 8 or later and haven't got 'round to reading README.RedHat. In fact, a fair number of Perl modules will fail to install or test properly with Perl 5.8 on Red Hat 8. This is because Red Hat is configured such that it defaults to a Unicode character set. Bricolage prefers this, of course, since all Bricolage data is stored in the database in Unicode. However, it does require that you set the LANG environment variable on Red Hat 8, like this:
export LANG=en_USFrom what we've heard, LANG must not include "utf8". Presumably you should set LANG to a value for your local language. At any rate, you'll need to make sure that this is set in your shell in order to install Bricolage and all of its modules, and you may need to include it in your httpd.conf file, as well:
PerlSetEnv LANG en_USWe've also heard that you can set the LANG environment variable globally in the /etc/sysconfig/i18n file. Then you wouldn't need to worry about it anywhere else.
make install exit with the error 'IDENT authentication failed for user "postgres"'?I'm not sure why the IDENT fails. In inst/db_grant.pl, we switch EUID to that of 'postgres'. Maybe more things need to be set in order to convince postgresql that you're logging in as 'postgres' instead of 'root'?
I worked around the problem by ignoring it; in pg_hba.conf,
#local all all ident sameuser
#host all all 127.0.0.1 255.0.0.0 ident sameuser
local all all trust
host all all 127.0.0.1 255.0.0.0 trust
host all all 0.0.0.0 0.0.0.0 rejectA Short introduction to pg_hba.conf can be found in Bric::DBA, and it is more thoroughly documented at http://www.postgresql.org/docs/current/interactive/client-authentication.html.
[error] [client 127.0.0.1] Error executing AccessHandler: Bric::App::Session -- /usr/local/lib/perl5/site_perl/5.8.0/Bric/App/Session.pm -- 236
Difficulties tie'ing the session hash to file '/tmp/bricolage/session'Most likely it is because one or more files or directories in your Bricolage temp directory are no longer writable by the Apache user. You need to chown the temp file directories and restart Bricolage:
sudo chown -R nobody:nobody /tmp/bricolage
sudo bric_apachectl restart<html><head></head></html> or nothing at all. There are no errors in the error log or the access log. What's wrong?I've seen this a couple of times, but the cause was different each time. On one occasion, there was a FilesMatch directive in a separate VirtualHost directive in httpd.conf that was preventing Mason from seeing any of the Bricolage UI components. The directive that caused the problem looked like this:
<FilesMatch "\.mas">
SetHandler perl-script
PerlHandler Bric::App::Handler
</FilesMatch>I have no idea why this would have caused a problem, but when it was removed, Bricolage started working again.
On another occasion, a user noticed that the files comp/login/dhandler and comp/login/welcome.html were empty. This caused the equivalent of a "Document Contains No Data" error, only it didn't. In fact, in my tests, under these circumstances, the browser had no HTML source at all (although I was later told that a Mozilla setting can force the <html><head></head></html> to be added). At any rate, the problem was fixed by reinstalling Bricolage (a make upgrade would probably do the trick, too), but it's likely that simply copying these two files from the Bricolage source directories to your installed component root will correct the problem. Holler on the bricolage-general mail list if it doesn't.
Look in your Apache error_log file. If you find an error along the lines of
cannot login ...Then you need to update your pg_hba.conf file as described in the section "Why does make install exit with the following error?". In fact, as David Wheeler suggested in one of the email in the bricolage-general mailing list, if you issue the following command on the command line:
/usr/local/pgsql/bin/pgsql -U bric bricyou will get
IDENT authentication failed for user "bric"Thus demonstrating that you're dealing with a PostgreSQL configuration issue, rather than a Bricolage issue.
This is a known issue with PostgreSQL's pg_dump utility -- it's not smart enough to handle circular dependencies. The PostgreSQL developers are aware of the issue. See this bug report for details: http://archives.postgresql.org/pgsql-bugs/2002-09/msg00278.php.
In the meantime, the workaround is to edit your SQL dump file so that the Bricolage database will load properly. In your SQL dump file, search for and remove the line containing the string 'CONSTRAINT "ck_usr__login"'. This should remove the creation of the constraint that uses the login_avail() function before the function is created. Next, go to the very end of the SQL dump file and add these lines:
ALTER TABLE usr ADD CONSTRAINT ck_usr__login
CHECK (login_avail(LOWER(login), active, id));This will add the constraint at the very end of the load, when both the "usr" table and the login_avail() function have been created. Now you should be able to load the database and get back to work!
I'm going to go out on a limb here and guess that you're using Safari on Mac OS X. Safari has a JavaScript bug wherein it doesn't know the name of a window. The "Click here to start" link opens a new named window, but since Safari doesn't know that it's named, Bricolage's JavaScript can't tell that it's named, either, and so keeps trying to get you to open a window with the correct name. It'll never happen. Apple should be aware of this issue, as I've filed a bug report for it using Safari's bug reporting interface, and have reported it again via Apple's official bug database (Bug # 3485193).
Until Apple fixes the bug, there are two ways to resolve this issue: First, don't use Safari. This is the preferred solution, and since there are some other great Browsers for Mac OS X (notably Camino, Firebird, and Mozilla), it's a real option for most Bricolage users. The second solution is to disable the named window by adding the undocumented configuration directive NO_TOOLBAR to your bricolage.conf file with a false value. The downside of this approach, however, is that all users of Bricolage will now be using Bricolage in a window with the back button, and this can potentially lead to problems with the state of story objects while you're editing them. However, if you never use the back button, it should be fine.
Fields cannot have the same name, even if they've been deleted. This is because you might have older stories around that use the old name, and still republish them to templates that use the old name.
The solution is to give the new version of the field a different name, but make the "Label" the same. So you might have a name like "new_paragraph" and the label "Paragraph". Just remember to change any references to the old field name in your templates to use the new field name.
This section contains questions that didn't fit in the other sections.
Click on the Bricolage log in in the UI to see the "About" section of the online help.
[In the beginning there was chaos....]
Read the README document in the directory where you unpacked Bricolage to learn about other documents on specific things like Bricolage administration, usage, or hacking. The project's web site is http://www.bricolage.cc/. The web site lists information about mailing lists.
Not really, no. We'll likely write some one of these days. in the meantime, you might find some use in a presentation given at the 2000 OSCON by Ian Kallen, in which he discussed what Salon needed out of a CMS (including workflow) and how he came to select the tools to use the CMS that was the proof-of-concept for Bricolage. The article is at http://www.arachna.com/edu/talks/iswp/index.html.
This behavior is intentional. The search interface goes directly into an SQL query, and thus support SQL wild card characters. Unless you query for a string at the beginning of a column, the index on that column won't be used. So we default to only searching at the beginning of a field in order to take advantage of the speed provided by an index.
However, you can get around this functionality in two ways. You can by put a '%' in front of your search string, thereby forcing the SQL query to be a full substring query. Or you can enable on the "FULL_SEARCH" bricolage.conf directive and restart Bricolage. But know that either of these methods will a lot slower (though you probably won't notice much until you have 1000s of documents).
Deleted template profiles don't actually get deleted but instead marked inactive in the database. This prevents creating a new template with the same name in them same category in the same output channel. In a future release, an easy way to reactivate deleted template profiles will be integrated in the GUI.
In the meantime, deleted (that is, deactivated) template can be brought back by using a updating the database directly and querying against the output channel ID and the template's file name:
psql -U [username] -d [databasename] -c \
"UPDATE formatting SET active = 1 WHERE output_channel__id = [ocid] \
AND file_name = '[path]'"The arguments in brackets above are:
The username for your Bricolage PostgreSQL user. This is the username the Bricolage installer created for you, and which is listed as the DBI_USER bricolage.conf directive.
The name of the Bricolage database. This is the database the Bricolage installer created for you, and which is listed as the DB_NAME bricolage.conf directive.
The ID of the output channel that the template is in.
The full URI path name of the template. This is a combination of the category path and the name of the template, usually constructed from the element for which it is created. For example, a Mason template created for the "Book Review" element in the category "/reviews/books" would be called /reviews/books/book_review.mc.
Scott Lanning <slanning@theworld.com>
David Wheeler <david@kineticode.com>
README, http://bricolage.cc/, Bric::Admin