plesk 9.5 + centos 5.6, and "correct"yum repos to use?

[humpy]

Hi, wasnt sure whether to put this in the yum forum or the plesk forum so thought would start here anyway..

I unfortunately have a recurring illness that takes me out of circulation regularly, and whilst out of action, I have a couple of mates that admin my server. Since returning from the last bout , unfortunately, one of them appears to have changed repos ( both pointing the finger..) and now if i try a yum update ( or more seriously, try to re installing php-ion-loader which i need, i get major issues...
eg "snip"
1:php-ioncube-loader-4.0.5-1.el5.art.x86_64 from atomic has depsolving problems
--> Missing Dependency: libc.so.6(GLIBC_2.3)(64bit) is needed by package 1:php-ioncube-loader-4.0.5-1.el5.art.x86_64 (atomic)
Error: Missing Dependency: libc.so.6(GLIBC_2.2.5)(64bit) is needed by package 1:php-ioncube-loader-4.0.5-1.el5.art.x86_64 (atomic)
Error: Missing Dependency: libc.so.6(GLIBC_2.3)(64bit) is needed by package 1:php-ioncube-loader-4.0.5-1.el5.art.x86_64 (atomic)
Error: Missing Dependency: libc.so.6()(64bit) is needed by package 1:php-ioncube-loader-4.0.5-1.el5.art.x86_64 (atomic)
etc etc
i had another ( more trusty admin) have a quick look , but he said he didnt want to get stuck in to much, in case he broke it further, but was of the opinion there was a "conflict using multiple repos" as a good place to start looking at fixing the issue ...
I am running centos 5.6
Linux 2.6.18-028stab062.3 on x86_64

current repo list is
* atomic: www6.atomicorp.com
* base: hpc.arc.georgetown.edu
* extras: mirror.cogentco.com
* rpmforge: apt.sw.be
* updates: mirror.ash.fastserv.com

Suggestions on what should be (and shouldnt be) in the repo list?
any other suggestions and help re the above glibc issues, also greatly appreciated....

ta
W.

[scott]

How on earth did you break glibc like that? Im surprised the system even boots

[humpy]

i have no idea... i came back from being sick to find this disaster... normally i can muddle my way out of issues... this has me totally stumped.... its my live server too... ##(#&* waaa!
I am just vastly relieved the system is at least 99% running and not crashed in a smoking ruin.......

ta
W

[hostingguy]

lol dont reboot!

is glibc still installed?

glibc-2.5-58.el5_6.2
glibc-common-2.5-58.el5_6.2
glibc-headers-2.5-58.el5_6.2
glibc-2.5-58.el5_6.2
glibc-devel-2.5-58.el5_6.2

[humpy]

[root@vps01 ~]# rpm -qa | grep glib
vzdummy-glibc-1.0-1.swsoft
glib2-2.12.3-4.el5_3.1
glibc-headers-2.5-58
avahi-glib-0.6.16-10.el5_6
glibc-2.5-58
glibc-common-2.5-58
glib-1.2.10-20.el5
glib-devel-1.2.10-20.el5
glib2-devel-2.12.3-4.el5_3.1
jakarta-taglibs-standard-1.1.1-7jpp.1
dbus-glib-0.73-10.el5_5
glibc-devel-2.5-58

[humpy]

[root@vps01 downloads]# rpm -Uvh glibc-2.5-58.x86_64.rpm
Preparing... ########################################### [100%]
package glibc-2.5-58.x86_64 is already installed
file /sbin/ldconfig from install of glibc-2.5-58.x86_64 conflicts with file from package glibc-2.5-58.i686
file /sbin/sln from install of glibc-2.5-58.x86_64 conflicts with file from package glibc-2.5-58.i686
file /usr/sbin/iconvconfig from install of glibc-2.5-58.x86_64 conflicts with file from package glibc-2.5-58.i686

sigh

[faris]

This is probably a 64bit-v-32bit issue, and probably with a twist.

I'm guessing that you have both the 64bit and 43bit packages installed. So if you are going to install manually using RPM, try doing both the x86_64 and non-x86_64 at the same time. (but please test somewhere first in case this makes things worse).

Oddly, when I do an rpm -qa glibc* it doesn't specifically list the x86_64 version - it just listes glibc twice (obviously one is the 64bit version).

I had to use rpm -qa --qf "%{n}-%{arch}\n" glibc* to see things properly.

[humpy]

Ok I am now horribly confused... i hassled the people who originally provided my VPS, and got this reply...

There are no 64-bit packages on this VPS as it is a 32-bit VPS. 64-bit packages will not function correctly on it.
Linux vps01.servermasters.net 2.6.18-028stab062.3 #1 SMP Thu Mar 26 14:46:38 MSK 2009 i686 i686 i386 GNU/Linux
You will need to use i686/i586/i386 packages

all i have ever done since first having it deployed is yum update/yum install etc,

shouldnt this have worked fine?

this is why i was pondering whether the repo's were causing the problem,,, apart from scort art repo, what other repo(s) should a plesk/centos server have enabled at minimum? if i cut them down maybe it may help?

ta for all advices so far...

[Highland]

1:php-ioncube-loader-4.0.5-1.el5.art.x86_64 from atomic has depsolving problems

You're trying to install the 64 bit version onto your 32 bit box, then. Couple of suggestions
1. Clean your yum cache
2. Check your /etc/yum.repos.d/atomic.repo file and make sure it didn't get manually pointed to the 64 bit repo

[scott]

Or maybe some deeper issue, the config uses a variable ($basearch) to determine if its i386 or x86_64. More VPS shennigans might be at play here

[faris]

[root@vps01 downloads]# rpm -Uvh glibc-2.5-58.x86_64.rpm
Preparing... ########################################### [100%]
package glibc-2.5-58.x86_64 is already installed

Wow! I'd double-check on that 32-bitness. On the first line you are trying to manually install the 64-bit glibc, then yum is then saying that it is already installed.

Why were you trying to install the 64bit version? Was it because you knew there was a 64-bit version already installed (and logically you would then want to update that to try to resolve the problem), or ?

In any case this may be the main cause of your problems. I don't know what would happen if you tried to manually install the 64-bit glibc using rpm on a 32-bit only system. I wonder if it would refuse to install or not. I'm going to assume not, as otherwise it wouldn't be installed! In theory this might mean that having the 64bit glibc installed on a 32bit machine would not do any harm and might somehow be desirable in some situations (errrr....), but obviously something has at some point done some harm to something.

I'm afraid I'm lost here. Sorry

[humpy]

I was trying to force install the 64bit stuff, as doing standard yum installs at some stage had put a lot of 64bit stuff on, and when i asked an a mate with far more linux experience than me ( which is not saying much) to take a look, he advised me it was a 64 bit system. And as it seemed to be wanting 64 bit libraries i was trying to get them on. Now i find out from the actual VPS suppliers it should be all 32 bit! trusting them more than him, I am now a tad stumped as to why the server was installing 64 bit stuff ( without issues being seen at the time of install ) in the first place.
Hence my original ask about what everyone thinks are best repos to use for a centos 5.3 machine running plesk 9.54?, and I will make my repo list conform, as other people/admins I have help me from time to time seem to have added new repos in the past few months, and so that is only way I can think that it may have started this issue by installing the wrong packages in the first place.
If anyone can think of any other reasons yum started this original mixup i am all ears!
Being fairly linux dumb ( i been try to learn limux for years but have an illness that makes memory rentention difficult unfortunately.. --very very frustrating believe me) , so at the moment I still " only know enough to be dangerous" as they say, but previously I have used yum for years without ever having it do anything this weird.

[hostingguy]

My understanding of 32v64 is

Run the command

Code: Select all

uname -a

if you get somethign back that mentinos x86_64 then your running a 64 bit kernel, and thus would need 64 bit packages.

My understanding gets a little fuzzier when dealing with VPS through something like Virtuozzo where you can have a 32 bit VPS running with the main VZ 64bit kernel.

[humpy]

that may have been what confused my mate too

2.6.18-028stab062.3 #1 SMP Thu Mar 26 14:46:38 MSK 2009 x86_64 x86_64 x86_64 GNU/Linux

and yes that is under virtuozzo... sigh.. my head hurts.

[scott]

well the CPU is certainly 64-bit. Maybe they forced 32-bit to save memory.