Oct
3
Beating Bugzilla into submission on OS X
Filed Under Computers & Tech, System Administration on October 3, 2005 at 12:47 pm
I had been warned that Bugzilla was a pain to install but when I read the instructions on their webpage I thought it all looked pretty simple, turns out it WAS a pain to install!
The trouble was caused by two things:
- CPAN modules refusing to build on OS X
- Bugzilla making ridiculous assumptions that just don’t stand up to reality, namely:
- You will always want to use /usr/bin/perl
- sendmail will always be in /usr/lib/sendmail
For details on how I resolved these issues read on.
Firstly, getting Perl to behave itself. The simplest solution to this problem is not to use Perl that comes with OS X but to use DarwinPorts or Fink to get Perl in order. I used DarwinPorts because I have had bad experiences with Fink and really like DarwinPorts. Anyway, it worked like a charm, all the modules I needed were available via DarwinPorts and installed with no issues at all. One thing to note is that this does not patch up the Perl in /usr/bin but rather installs a whole new Perl in /opt/local/bin. One slight annoyance was that to get DBI::MySQL I also had to install a copy of MySQL from DarwinPorts. This is fine because you don’t actually have to USE it, just have it there. As it happens the guys at MySQL have an excellent binary distribution of the MySQL server these days so there is no need to get it from DarwinPorts. I also already had other databases installed and running on my MySQL install so I was in no humor to have a second MySQL server running just for Bugzilla! The one complication here is that the default location for the MySQL socket in the DarwinPorts Perl is the location the DarwinPorts MySQL server uses and not the one the default MySQL server uses. Since I am not using this MySQL I had to tell Bugzilla not to use the default socket but the one I was actually using. You do this by editing localconfig. In my case I had to set the following:
$db_sock = '/private/tmp/mysql.sock';
Now, you can probably imagine how using DarwinPorts’ Perl caused the first of the assumptions made by the Bugzilla installer to break down. The Perl that comes with OS X is at /usr/bin/perl and is used by loads of stuff on the system (so I can’t replace it with a symlink to the right Perl), the Perl from DarwinPorts is at /opt/local/bin/perl. Although I explicitly ran the installer for Bugzilla with this Perl in the hope that it would be smart and realise that it should use that Perl for everything, it still set all the shebang lines to #!/usr/bin/perl and hence although Bugzilla passed the installer’s tests with flying colours, it crashed in a heap when you tried to use it because it went running off to the wrong Perl!
I figured that if the shebang lines were not generated by setting them to the Perl running the installer then there MUST be a configuration option to allow you to specify what Perl should be used. I tried looking really hard but with no joy. I looked on the online documentation, no joy, I tried their mailing list, not even a reply so I took the bull by the horns and wrote my own Perl script to change all the shebang lines for me:
#!/opt/local/bin/perl
use strict;
print "\n\n";
# get the files in the directory
opendir(THISDIR, ".");
my @files = readdir(THISDIR);
closedir(THISDIR);
#loop through the files
foreach my $file (@files){
# skip files that are not cgi files
next unless $file =~ m/\.cgi$/;
print "Processing file: $file\n";
# get the contents
open(CGIFILE, "$file");
my @contents = <CGIFILE>;
close(CGIFILE);
# write it back out but with the correct shebang line
open(CGIFILE, ">$file");
if($contents[0] =~ m/^\#\!/){
print CGIFILE "#!/opt/local/bin/perl\n";
}else{
print CGIFILE $contents[0];
}
for(my $i=1;$i < scalar(@contents); $i++){
print CGIFILE $contents[$i];
}
close(CGIFILE);
}
print "\n\n";
This got Bugzilla up and running and talking ot the DB but desepite the fact that I had sendmail up and running on the server Bugzilla now had a hissy-fit each time you tried to add a bug or do anything that caused it to try to send an email. This is where the second retarded assumption made by the Bugzilla peeps was the culprit. firstly, their error reporting sucks donkey dick and was of no use at all so into the code I dived. After some poking around inside the source tree I figured the problem must lie within Bugzilla/BugMail.pm and sure enough in the last function of that file (line 868 of 876) I found this:
open(SENDMAIL, "|/usr/lib/sendmail $sendmailparam -t -i")
Yup, they had hard-coded in the location of sendmail! Again, there is no way to set the location of sendmail in any config file I could find so I had to manually edit this line to look like this:
open(SENDMAIL, "|/usr/sbin/sendmail $sendmailparam -t -i")
Once that was done all was fine and Bugzilla is now working but I really shouldn’t have had to jump through so many hoops to get it working!