Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Westi on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Apache / MySQL mess

Status
Not open for further replies.

Messmaster

Technical User
Mar 7, 2003
5
US
After working all weekend, I have a mess on my hands with trying to install WebEvent software. This program requires the perl module DBD Msql-Mysql. However I'm having serious difficulty getting this module to install because certain MySQL files (namely mysql.d and libmysqlclient.so) are not in the folders the module wants (usr/include and usr/shared). After many attemps to install the module (including using CPAN) and reading much documentation on this issue I determined that I would just uninstall MySQL and start over. I'm using RedHat 8 and Apache 2.0. This work is being done on a production server.

A bit of background....

First, I am only barely adequate in expertise when dealing with Linux/Apache. Everytime I go back to work on the server, I drag all my books and documentation with me. That being said, when I first installed MySQL, I compiled it from the binaries along with PHP. The database and the scripting language each worked fine. MySQL ended up being installed in usr/src/php-4.3.2/ext/mysql/blah. The mysql.d was in usr/sbin.

So, in trying to uninstall MySQL, I made my first mistake. I believe the lesson here is that binaries do not an rpm make. I used the command 'rpm --erase Mysql-blah' to get rid of MySQL. When I got the command prompt back with no errors, I thought I'd been successful. So I downloaded the rpms for MySQL server,client, and shared and since the RPM GUI kept freezing on me I installed them using the command line. I forget what happened that made me have to reboot but after rebooting, Apache didn't work. When I tried to restart it, it said httpd (pid 769) was already running. However, I knew it wasn't because it wasn't serving any pages. So I did a ps -aux (I think) to get the list of all the PIDs that were running and it said 769 was being used by MySQL. I also saw several other instances of MySQL in the PID list. In the end, I had to rename the mysql.d file in usr/sbin and reboot in order to get Apache to start.

So after all this, I still don't have the DBD Msql-Mysql module installed, and now I don't have MySQL working at all. I'm going backwards.

This is my plan.
1. To find out from this forum how, exactly, to get rid of all instances of MySQL from the system (binary and rpm flavors).
2. After re-installing MySQL and getting it running (again), I'm turning to the DBD/DBI forum to get help with that frustrating module.
3. Then I look to support for WebEvent to finally get their software installed. They have been trying to help me the past couple of days, but even though they require the two perl modules for their software to work, they don't seem to have very much expertise with installation issues concerning them.

If you folks have a better plan I'd sure be glad to listen as I'm seriously running out of ideas here. Thanks.

Carol Andrejak
Webmaster [rednose]
Delaware State University
 
I have suffered similar pains, though I don't quite know how to comment on your multiple installs/deletes.... (that may compound the issue).

The perl DBD-mysql source has always been my friend. The CPAN compile fails for 1 or 2 of the following reasons:
1) Fails to find the libraries,
2) Fails to complete the tests

I find that RedHat's .RPMs for the client, shared, and devel packages are sufficient (i.e. server not required) to compile the DBD-mysql

I also find that I can skip the test IF the code compiles without error (see lib issue).

In CPAN you can do 'force install DBD::mysql' which will ignore errors in the test step. Or, you can compile the source yourself (which is what CPAN does) and you can watch the output of the test.

You can attempt to accomodate the test by creating a database called 'test' with full, non-passworded rights. OR , you can modify a supporting compile file that contains the settings for performing the test against a real database with a real username and password.

Only in a few, rare instances have I had the test partially fail - perhaps 2 tests - against a real db. I installed anyway.

On the matter of the libs, I believe that you should be ok if you install a set of .RPMs from either RedHat (recommended for RedHat installs) or MySQL binaries (never really had a good experience installing them on RedHat since 3.23.33).

I hope this helps you out.
D.

ps. Remember that the RedHat and MySQL binaries probably hard-code different locations for the 'mysql.sock' file (/tmp vs. /var/run?) which can lead to disappointing results when using the mysql client OR the DBD-mysql perl module.

"Surfinbox Shares" - A fundraising program that builds revenue from dialup Internet users.
 
Thanks for the response. To elaborate a bit on the adventure with the perl DBD-mysql module, it failed on the fifth question where it was looking for the mysql.d file in /urs/include. So I copied it from where it was to that folder and tried the install again in which case it stopped on the very next question when it couldn't find the shared file in /usr/lib. I did a Find on the entire drive and the file didn't exist. So I tried the CPAN route which failed. Then tried to force install it but it still majorly failed and flat would not install. You mentioned the devel package and that one I had not installed so maybe that's something I need to do. I will keep that in mind when I start over.

Which still leaves me with my original question on what I need to do to get rid of the compiled version of MySQL. Can I get away with erasing the rpm's first and then delete all MySQL-related files that are left? Do you think I will cause great harm if I do that?

Carol Andrejak
Webmaster [rednose]
Delaware State University
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top