Preinstall requirements may break 64 Centos 6.3

A

Aza

Verified User
Joined
Feb 6, 2013
Messages
25
Location
Washington DC
The basic 64 bit Centos 6.3 distro loads fine as of this writing (February 7, 2012).

However "yum update" breaks the Internet communications services. "ping" will work fine but "lists" and "yum install" will fail because they are unable to access the Internet properly.

Running "yum --exclude=glibc* update" on a fresh distro installation works just fine. Actually, I added the exclude statement to the yum configuration file because I didn't want a dependency triggering a defective update and breaking the system.

BUT, pre-installation for DirectAdmin requires:

"yum install wget gcc gcc-c++ flex bison make bind bind-libs bind-utils openssl openssl-devel perl quota libaio libcom_err-devel libcurl-devel gd zlib-devel zip unzip libcap-devel cronie bzip2 db4-devel cyrus-sasl-devel perl-ExtUtils-Embed"

This pre-installation fails for want of glibc-devel at version 2.2.90-12 or later.

So now I'm chasing my tail. I am certain that updating glibc will break the installation. DirectAdmin threatens to force a glibc update. Any suggestions for resolving this conundrum?
 
Hello,

glibc is the core library for system commands and is used by almost everything.
http://www.gnu.org/software/libc/

Has anyone else run into these same issues?

A glibc update error is fairly major... and more to the point "rare"... so I'm not sure if it's an issue specific to this box.. or perhaps the repository being used.
You could check /etc/yum.repos.d/CentOS-Base.repo to see which values are being used..
If it is a repo bug, chances are it would be sorted out quickly.

As almost everything uses it, for many cases, if it's updated, it's a good idea to ensure that other things that use it are updated too (yum will take care of that for you)
For any DA compiled services like apache, php, dovecot.. it's a good idea to recompile them as well.

As for DA's requirements, it needs working compilers (gcc, g++, c++), libraries, headers and a few other programs, listed in the above yum common.
It's not too concerned how they get there, just as long as they are.
The "how" is left to yum.. with regards to matching up proper versions, dependencies, etc.. we're not too familiar with issues below yum.

I'm not sure if this is really useful for you, but may help clarify things.

John
 
glibc woes

I'm baffled too, John.

Our testing process was to start with clean hard drives on a local server and do a CentOS-6.3-x86_64-netinstall.iso electing to make custom partitions (very much like the DirectAdmin suggestions) and install the offered "Web Server" configuration.

After making that installation with no errors we rebooted and tested the Internet communications with "ping centos.org", "links centos.org" and "yum install xxxx". All tests worked as expected.

After "yum upgrade", "ping centos.org" worked as expected, but "links centos.org" and "yum install xxxxx" failed. Rebooting changed nothing.

If we cleaned the hard drives and reinstalled using the same CentOS-6.3-x86_64-netinstall.iso as before, but updated with "yum --exclude="glibc*" upgrade" all the "ping centos.org", "links centos.org" and "yum install" tests would work.

I asked a colleague to repeat this two step test on a second clean server. His testing had the same results: Failure, unless "glibc" package members were excluded when updating a fresh Web Server installation.

OK, by excluding "glibc" from the update we have a compiler and library but they're older. The compiler is a pretty stable package that's been around for a while so its age may not matter. Let's see what happens if we bar any further action on the "glibc" packages in the yum configuration file and go ahead with the DirectAdmin pre-install.

Alas, the pre-install errored out because "glibc-devel" at version 2.2.90-12 or later is not installed. That's not surprising considering that yum is barred from working on any of the "glibc" package.

I suppose we could repeat the lengthy CentOS-6.3-x86_64-netinstall.iso reinstallation and updating test excluding only the compiler or library and see what happens. But in the end all we have is a messy kludge -- hardly what should be on a remote production server.

I posted the problem on the CentOS forum a few days ago but thus far there's been no reaction beyond suggesting that I make sure the communication services are running.

I believe the services on our local test server are good and running. "/etc/sysconfig/network-scripts/ifcfg-eth0" conforms to the DHCP suggestions at http://wiki.centos.org/FAQ/CentOS6 and "ifconfig confirms eth0 is alive and well.

So it sounds like the 64 bit CentOS 6.3 repo system is indeed broken at the moment because of something related to the default "glibc" repositories. Unfortunately I don't know how to work around it or climb the ivory tower to get the guidance of the lofty CentOS developer/maintainer gods.

Perhaps I need to look for a more stable server OS?
 
Aza said:
Perhaps I need to look for a more stable server OS?
Click to expand...
Generally RedHat Linux is considered about the most Stable there is. I'm guessing this will be fixed quickly; have you tried posting to any RedHat forum or mailing list?

Jeff
 
I don't know if this is the case here too. But some time ago I had some strange issues with a 64-bit only installation.
After doing some reading on the internet, the result was that there might be things still in need of some 32-bit support.

The solution was to install at least the 32-bit version of Glibc. This indeed fixed the problem.
So nowadays I always install the 32-bit glibc and glibc-devel packages default. It might not be needed, but won't do any harm either.

However, like I said... I don't know if this could be of help in this case too.

At the moment we got 3 Centos 64-bit servers (one is Centos 6.3) and we always update all our Centos 64-bit servers with "yum update" including glibc (also in january) and did not see any problems so far on any server.
 
Forcing 32 bit update

Richard G said:
The solution was to install at least the 32-bit version of Glibc. This indeed fixed the problem.
So nowadays I always install the 32-bit glibc and glibc-devel packages default.
Click to expand...

The initial installation claimed to be installing a x86_64 version of glibc and the associated library, Richard. Is it possible "yum update" didn't take the existing version as a cue for what to update?

BTW, how do you force a glibc update to use only 64 bit version 6.3 compatible? Presumably it's "yum update" followed by the complete designation of the package to use for updating, but how does one find out the repository name for the most recent stable update?

Aza
 
Specific update that may break 46 bit CentOS installation

We repeated the exercise of making a fresh install (this time of the "Basic Server" option and not the "Web Server" option) and then using "yum update"

As expected the update broke the communications in that same odd way where "links centos.org" fails but "ping centos.org" works fine.

Just for a hoot I thumbed in "links 72.232.294.262" (72.232.294.262 is the centos.org dot address). That worked just fine.

So, the odds are the issue is *not* glibc-2.12-1.80.el6_3.7.c86_64.rpm or glibc-common-2.12-1.80.el6_3.7.c86_64.rpm.

It looks like a name resolution issue (iPV4?) that "ping" may handle differently from "links" or "yum grouplist" (both of which fail). Perhaps the problem creeps in because something in the name resolution chain is impacted by a change in glibc. Alas I don't even have a good guess.

I raised this issue on the CentOS forum and have yet to get any useful reaction or comment.

Oh yeah, I figured out that "yum update glibc.x86_64" will force an update to a particular word width and version -- I musta had a Microsoft moment earlier....
 
I guess the important questions are: Am I going to be able to do a new CentOS 6 DirectAdmin installation this week or not? Do I need to wait until this is fixed?

Jeff
 
Go ahead and install 64 bit CentOS 6.3

nobaloney said:
I guess the important questions are: Am I going to be able to do a new CentOS 6 DirectAdmin installation this week or not? Do I need to wait until this is fixed?

Jeff
Click to expand...


Go ahead with the installation Jeff.

I am positive that my problem has to do with how our local server's name resolution is configured. We went ahead with the installation on a remote server and are now struggling with using da.cpanel.import.pl to convert a collection of individual CPanel site home backups into a form useable for initializing the new DirectAdmin server.

The remote server has a full complement of router support and server & gateway IPs outside the 192.168.XXX.XXX local addressing range. I firmly believe that our problems with the local server communications stem from the local range of addresses and an unanticipated interaction with our DNS & router.

And lemme know if you figure out how to migrate a bunch of sites from a CPanel server <g>

Aza
 
Aza said:
And lemme know if you figure out how to migrate a bunch of sites from a CPanel server <g>
Click to expand...
There should be information in these forums on how to do that; have you searched the forums? Since I've never used CPanel, and have only converted once, for a client, years ago, I have no special insight.

Jeff
 
Migrating CPanel to DirectAdmin

nobaloney said:
...[I've]only converted once, for a client, years ago, I have no special insight.
Click to expand...

Yeah, site migration is something you do only once in a while. There's no point in spending a lot of time learning something you're unlikely to use in the foreseeable future. This is a case where it pays to tap someone who doesn't have that big learning curve.

I had a heck of a time, however, finding the expertise. I tried one outfit that knew nothing. Another that took 2-4 hours for each information exchange and clearly had language problems. Yet another outfit made us pay for an hour only to tell us that our job was so massive (migrating a shocking 87 sites) that it would take them an additional 5 1/3 hours to do the job!

Finally I hit on an outfit (WebbyCart.com) that had the job done at what to me was a bargain price in less than 2 hours from the time I first contacted them!

Regards,

Aza
 
You must log in or register to reply here.
Back
Top