Installation tip for CentOS 4.1

Situation:

I ran into this as I was installing for the first time. This is on a clean installation using CentOS 4.1 x86_64, Custom (Minimum) installation.

When running the installer, as it was attempting to install MySQL, I ran into errors (and I don’t have the exact text now, darn it) where libstdc++ and libgcc would indicate that newer versions were already installed, and the installation would end.

Solution:

Install MySQL prior to running the iworx script by using the following command line:

yum install mysql mysql-server mysql-devel

This was taken directly from the installation script. It may also be handy to run:

yum install zlib

(Not entirely sure if that helped, but it was something I did on an earlier run when the installation script complained.)

After this has been done, start the installation script again, and it should coast through to basic completion, which took about four minutes, download included.

Thanks for the notes Martin.

I’ve done a slew of CentOS 4 installs and I must say that I see odd things about 50% of the time and they vary. We’ve had issues with yum wanting to install both the i386 and x86_64 versions of MySQL, openssl and other odds and ends. I can always work around the problem as you did but it’s frustrating to say the least.

We’ve tried to compensate with our yum.conf that the installer uses but as of yet we can’t seem to nail down all the oddness with the 64 bit version of CentOS 4.x. That said I’ve never had a problem once the install is done, just with the initial install.

I’ve spent more time that I want to say checking out the i386/x86_64 issues and to be frank I don’t have a failsafe solution for the install. It decides to be a pain sometimes and other times it’s fine.

If anyone has issues with CentOS 4.1 x86_64 installing IWorx-CP we are more than happy to help you out and we won’t charge the install fee.

Chris

Happy to help whenever I can. It’s refreshing to see a panel community that doesn’t instantly respond with “RTFM N00b!!!” and where the devs actively participate. Huge points in favor of you guys, even aside from the technical aspects.

On that note, I just did a “yum list mysql*” and found that the i386 version of mysql had been installed. I’m going to play with that in a little bit (working on WebMin config and some firewall stuff) and I’ll let you know how it goes.

I uninstalled mysql.i386, and everything seems OK. No issues came up.

Perhaps the script can run a check for the presence of *.i386 at key points, and then use yum to remove them? You’re already checking for whether it’s 64-bit, so that doesn’t seem like a huge jump to me.

Perhaps the script can run a check for the presence of *.i386 at key points, and then use yum to remove them? You’re already checking for whether it’s 64-bit, so that doesn’t seem like a huge jump to me.

I wish it were that easy. To ‘yum remove’ openssl 1/2 way through would cause major issues since it pulls with it a ton of other packages. And then to put it back on ideally we’d like to “yum install” (without having to 'yum install openssl.x86_64). To this point we’ve only seen issues with CentOS 4. They put the i386 packages in their for compatibility I assume but their openssl x86_64 and i386 package conflict with each other even (the man page) so it’s not an ideal solution :(.

Glad kill the i386 MySQL didn’t hurt anything, we could probably remove it without problems and I’m glad you didn’t hit the openssl install issue, it’s a pain.

Chris

No, no, no. I was just referring to MySQL. I’m less willing to try and break OpenSSL. :slight_smile:

:).

Martin, can you run a “yum update” and see if it wants to update MySQL with the i386 version?

We’ve been seeing that under some circumstances the x86_64 version will be “upgraded” to the i386 version. Sometimes even when the i386 version is older than the x86_64 version.

Chris

I’ve already done that, and it didn’t want to upgrade it. However, when I ran the original ‘yum install’ I didn’t specify the x86_64 version, so I think that’s why it installed both. Since there’s a functional version installed, I think that’s why it’s skipping it. Might be something updated in the version that comes with 4.1 that handles things differently than 4.0.

Adding a note in for IMAP

One of the MOST frustrating things I’ve had to deal with had to do with IMAP. I use it for one of my mailboxes, and it’s used for Horde (/webmail) and Squirrelmail, though I did not know this at the time.

When logging in through Horde, I would get repeatedly turned back to the login page. Squirrelmail presented the oh-so-helpful “ERROR: Connection dropped by imap-server” which told me just about zero. When I finally realized that the Outlook issue and the webmail issue are both related to IMAP, I went looking in /var/log/imap4. Here’s an example of what I found:

@4000000042d0e02028d890dc tcpserver: status: 1/40
@4000000042d0e02028daf624 tcpserver: pid 2930 from 69.166.244.120
@4000000042d0e02028db7edc tcpserver: ok 2930 euler.illuminus.com:216.171.167.192:143 :69.166.244.120::16607
@4000000042d0e02028e3376c INFO: Connection, ip=[69.166.244.120]
@4000000042d0e0202bbb1374 /usr/lib/courier/authlib/authvchkpw: No such file or directory
@4000000042d0e0202bbd132c tcpserver: end 2930 status 256
@4000000042d0e0202bbd1afc tcpserver: status: 0/40

I did a locate authvchkpw and found it was actually located at /usr/lib64/courier/authlib/authvchkpw. My quick solution, since I checked various Courier-related configuration files, was to run the following:

mkdir -p /usr/lib/courier/authlib/
ln -s /usr/lib64/courier/authlib/authvchkpw /usr/lib/courier/authlib/authvchkpw

And all was well.

On a side note, I probably should have opened a ticket and saved myself a couple of hours of frustration, but the last one I opened was really pretty dumb, and I didn’t want to get a reputation for opening lame tickets at the drop of a hat. I’ve now worked in three datacenters, and I know how annoying some customers are seen after a few of those coming in. Besides, how is one supposed to learn if answers are spoon-fed all the time? Trial and error is a wonderful teacher.

OK, time to go learn about explosives. :wink:

Thanks for the note Martin, this needs to be fixed on our end as well. I’ve seen the directory living in both lib and lib64 in 64 bit installs and the symlink will fix for each scenerio.

Chris

I’m actually having the same problem as the user above with one of my domains, It just times out right away and returns me to the main page.

New fix out? Should i open a ticket?

We are trying to install Interworx on a CentOS 4.3 x86_64 server. I’m getting some conflicts with openssl. As it happens even if I simply type “yum install openssl” I get the same errors. As described above, attempting to remove it indicates that it has 72 dependencies that will also be removed.

If there’s a thread I’ve missed containing the workaround, please point me in the right direction. Otherwise I could use whatever help I can get.

Here are the actual errors I get at the end:

Transaction Summary

Install 47 Package(s)
Update 0 Package(s)
Remove 0 Package(s)
Total download size: 71 M
Downloading Packages:
Running Transaction Test
Finished Transaction Test

Transaction Check Error: file /usr/share/man/man1/asn1parse.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package openssl-0.9.7a-43.8
file /usr/share/man/man1/nseq.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package openssl-0.9.7a-43.8
file /usr/share/man/man1/s_client.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package openssl-0.9.7a-43.8
file /usr/share/man/man1/s_server.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package openssl-0.9.7a-43.8
file /usr/share/man/man1/sslpasswd.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package openssl-0.9.7a-43.8
ERROR: InterWorx-CP could not be installed.

As I mentioned, I get the same output (starting at “Transaction Check Error”) if I simply type “yum install openssl”.

Tips would be appreciated!

Download and force install the i686 version of the openssl RPM (some of the man pages will conflict but it won’t hurt anything). Then re-try the installation kryptx.

Chris

Download and force install the i686 version of the openssl RPM (some of the man pages will conflict but it won’t hurt anything). Then re-try the installation kryptx.

Chris

Thanks, Chris. That got me past the install problems and Interworx says it’s installed. I get the Interworx apache test screen okay (“This page is used to test the proper operation of the Apache Web server after it has been installed on this InterWorx-CP server. If you can read this page, it means that the Apache Web server installed on this server and is working properly.”) but when I visit the nodeworx URL I get a blank screen. Is this related to the openssl issue, or is it something else?

Any direction is appreciated, though I’ll keep digging on my own. :slight_smile:

edit: forgot to mention, I get this output in the command prompt when starting the iworx service:

Stopping InterWorx-web: [ OK ]
Stopping InterWorx-db: [ OK ]
Starting InterWorx-db: [ OK ]
Starting InterWorx-web: [ OK ]
license file not found
Binding IP Aliases: [FAILED]

Hello-

Have you run /home/interworx/bin/goiworx.pex and applied the license key yet?

–Dustin

Apparently I didn’t thoroughly read the documentation. No, I hadn’t done that, and that seems to have me up and running. Thanks for walking me through it! :smiley:

Glad we could help :slight_smile:

–Dustin

One of the CentOS devs in this thread
http://bugs.centos.org/print_bug_page.php?bug_id=1356

suggests adding this to your yum.conf
“exclude=*.i386 *.i586 *.i686”

We had the same issue while installing InterWorx-CP (CentOS 4.3) on a [SIZE=2]x86_64[/SIZE] system last weekend:

 
Transaction Check Error: file /usr/share/man/man1/asn1parse.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package openssl-0.9.7a-43.8
file /usr/share/man/man1/nseq.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package openssl-0.9.7a-43.8
file /usr/share/man/man1/s_client.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package openssl-0.9.7a-43.8
file /usr/share/man/man1/s_server.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package openssl-0.9.7a-43.8
file /usr/share/man/man1/sslpasswd.1ssl.gz from install of openssl-0.9.7a-43.8 conflicts with file from package openssl-0.9.7a-43.8

The solution (thanks to Socheat) was:

 
yum install zlib
yum install krb5-libs
rpm -ivh --force <a href="http://updates.interworx.com/centos/4.3/os/i386/CentOS/RPMS/openssl-0.9.7a-43.8.i686.rpm">http://updates.interworx.com/centos/4.3/os/i386/CentOS/RPMS/openssl-0.9.7a-43.8.i686.rpm</a>

-R?mon