I’m the kind of guy who likes to poke fun at people who “know just enough to be dangerous”. It makes me feel like I know more than they do and all kinds of fancy fuzzy stuff like that. But it looks like today karma is giving me a swift kick in the face because I’ve proven myself to be one of those people…
As I mentioned completing the steps that were outlined here did get my interworx installation up and running. I also was able to install MySQL 5, since we have some stored procedures that our application relies on, though of course Interworx would not allow me to manage it. After that, I followed the steps in the PHP5 thread and had that installed. Only problem I had at that point was that mysql couldn’t be managed from the control panel. Except there was this other problem, too – I couldn’t log in to phpMyAdmin. It was giving me some error about authentication methods not being supported by the server. I’ve seen this before – it happened when we upgraded PHP and not MySQL. So I figured that it was trying to use the wrong client libraries. I thought to myself, “I didn’t remove the mysql installation that Interworx installed for me. I don’t need that.”
Well, as you know, I DO need that. But I didn’t really realize that, so I removed it anyway, and when interworx wouldn’t start because there were lines in /etc/init.d/iworx trying to start the old database through iworx-db, rather than replacing mysql, I commented those lines. Then it said it couldn’t connect to the database. I created a hardlink to the real (mysql 5) socket in interworx’ directory where it was normally placed, ensured that mysql was indeed accepting connections on 2306 (like the old my.cnf I had so confidently deleted). changed all instances of the old socket to the new socket in iworx.ini, created a symlink to the /var/lib/mysql folder where interworx had been storing its tables, created the appropriate databases and ran the sql scripts in the sql folder against them, created an iworx user with permissions to those tables and with the password in the .ini file, and whatever else I thought needed to happen to make everything “transparent”. Any test script I wrote, attempting to emulate what interworx’s db_connect method might be doing (including using the iworx user/pass in the ini file, and trying both TCP and socket connections in both locations), was able to query a table in an iworx database in my MySQL5 installation and output a record to the screen, but for some reason the init.d script couldn’t connect at all.
Well, at this point I knew I’d blown it, and already with my tail between my legs for deleting things, didn’t really feel comfortable coming back here for help since the whole ordeal was my own fault. So I thought to myself… maybe I can just reinstall it using the shell script. Cut my losses and start over.
Well, then I ran into the mysql problem. Someone mentioned that they just installed it via yum beforehand, but no matter what, the iworx-cp-install script just kept on installing the i386 version even when the x86_64 version was already installed. I ran yum update under the same condition and it didn’t give me any of that nonsense.
This is where it gets really ugly… you might not want to have any small children reading the rest of this story. I decided to remove any reference to interworx throughout my system so that it’d be as if I was starting from scratch. This would not have been so bad if I hadn’t included in my crusade any and all packages in yum containing “iworx” in the version column. Now my system is pretty much disabled and I’m pretty much ready to give up.
Anyway, I hope my story was entertaining, and I hope I’m able to recover from this somehow. 