Installation Woes

Yesterday I was setting up a new Red Hat Enterprise Linux 4 server. It was my first time encountering this particular *nix flavor, so I was expecting some challenges. As it turns out, there is in fact a known bug installing MySQL on RHEL, involving SELinux.

I downloaded the MySQL 5.0 server and client rpms and tried to install them. Blah! Failed dependency on perl-DBI. I was reminded once again why I dislike rpms (as opposed to, say, the Debian package management system). So I downloaded the perl-DBI rpm, and when I tried to install it, I noticed that it was generating a NOKEY warning. I imported the fedora key, and downloaded and imported the MySQL key. I was now able to install perl-DBI and move on to MySQL.

The rpms seemed to install, but the daemon didn’t start. This was mystifying to me, as I have installed MySQL many times on a variety of systems and not encountered any problems. I tried starting the daemon manually, but it shut down immediately without any error messages. I checked /var/lib/mysql, and it contained the basic databases. I tried started the daemon in various different ways. I even read the help to see all the startup options. Still no luck. Finally, I found this bug report, which seemed similar to the problems I was experiencing. I hadn’t seen the message about MySQL failing to start, but I did have similar syslog messages. I decided to operate as if the installation had failed, and use the workaround from the bug report:

  1. uninstall MySQL rpms
  2. disable SELinux: /usr/sbin/setenforce Permissive
  3. install MySQL rpms (again)

This time, the installation completed and the daemon started automatically.

I am not impressed that the first time, the installation scripts failed silently. Nothing in the messages indicated that installation and setup had been unsuccessful. While there were messages in the syslog, they were rather cryptic. I think that error messages and log messages are some of the most important (and often overlooked) features of an application. Naturally you should make your application as robust as possible, but something is going to go wrong sooner or later, and it’s really helpful if the user can actually diagnose the problem based on the information provided.

It's only fair to share...
Share on FacebookGoogle+Tweet about this on TwitterShare on LinkedIn

Leave a Reply