Nightly upcp keeps installing i386 package on x64 system

[mtindor]

CentOS 4.5 x86_64 with applicable rpm updates
WHM 11.2.0 cPanel 11.10.0-R16448
CENTOS Enterprise 4.5 x86_64 - WHM X v3.1.0

I noticed recently that I many packages which are installed twice (the i386 package version and the x86_64 package version).

In attempt to clean things up, I removed all of i386 packages after figuring out all of their dependencies (or lack thereof in almost all cases). Finally had all x86_64 installed packages (except for Frontpage - which wasn't package specific but required the i386 version of expat).

Last night during UPCP I see that rpm updates were automatically made which installed the i386 versions of many packages which were already installed as x86_64 packages on the server.

Can anybody give me an idea why Cpanel wants to continue to install the i386 version of packages that are already installed x86_64 packages?

For instance - compat-glibc (i386) is not needed by any other installed RPMs but yet Cpanel obviously has some requirement for it. And for each new i386 RPM that needs installed, Yum then decides that more i386 RPMs need installed to meet dependencies.

It's a pain in the neck removing the i386 versions - since after removing them you have to 'rpm -ivh --force' the x86_64 versions again so that some files (that are shared between i386 and x86_64) are again installed after removing the i386 version.

Any suggestions?

Mike

Updating /scripts...
Sync Source: http://httpupdate.cpanel.net/RELEASE-x86_64/scripts
Fetching
http://httpupdate.cpanel.net/cpanelsync/RELEASE-x86_64/scripts/.cpanelsync.lock
(0)[email protected]
Fetching
http://httpupdate.cpanel.net/cpanelsync/RELEASE-x86_64/scripts/.cpanelsync.bz2
(0)[email protected]%...53%...80%...100%......Done
...Done

<snip>
Setting up Install Process
Setting up repositories
Reading repository metadata in from local files
Excluding Packages in global exclude list
Finished
Excluding Packages from CentOS-4 - Updates
Finished
Excluding Packages from CentOS-4 - Base
Finished
Reducing CentOS-4 - Plus to included packages only
Finished
Parsing package install arguments
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Package glibc-devel.i386 0:2.3.4-2.36 set to be updated
---> Downloading header for compat-glibc to pack into transaction set.
---> Package compat-glibc.x86_64 1:2.3.2-95.30 set to be updated
---> Package libgcc.i386 0:3.4.6-8 set to be updated
---> Downloading header for compat-gcc-32 to pack into transaction set.
---> Package compat-gcc-32.x86_64 0:3.2.3-47.3 set to be updated
---> Downloading header for compat-glibc to pack into transaction set.
---> Package compat-glibc.i386 1:2.3.2-95.30 set to be updated
--> Running transaction check
--> Processing Dependency: compat-glibc-headers = 1:2.3.2-95.30 for package:
compat-glibc
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Downloading header for compat-glibc-headers to pack into transaction set.
---> Package compat-glibc-headers.x86_64 1:2.3.2-95.30 set to be updated
--> Running transaction check

Dependencies Resolved

=============================================================================
 Package                 Arch       Version          Repository        Size 
=============================================================================
Installing:
 compat-gcc-32           x86_64     3.2.3-47.3       base              3.2 M
 compat-glibc            i386       1:2.3.2-95.30    base              1.0 M
 compat-glibc            x86_64     1:2.3.2-95.30    base              1.5 M
 glibc-devel             i386       2.3.4-2.36       base              1.9 M
 libgcc                  i386       3.4.6-8          base               63 k
Installing for dependencies:
 compat-glibc-headers    x86_64     1:2.3.2-95.30    base              463 k

Transaction Summary
=============================================================================
Install      6 Package(s)         
Update       0 Package(s)         
Remove       0 Package(s)         
Total download size: 8.1 M
Downloading Packages:
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction

<snip>

Installing system packages and perl modules...portsentry is up to date (Wed Mar 10
00:21:21 2004)
Using newyum support...
Setting up Install Process
Setting up repositories
Reading repository metadata in from local files
Excluding Packages in global exclude list
Finished
Excluding Packages from CentOS-4 - Updates
Finished
Excluding Packages from CentOS-4 - Base
Finished
Reducing CentOS-4 - Plus to included packages only
Finished
Parsing package install arguments
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Package openssl.i686 0:0.9.7a-43.16 set to be updated
---> Package gd.i386 0:2.0.28-5.4E set to be updated
---> Package openssl-devel.i386 0:0.9.7a-43.16 set to be updated
---> Package gamin.i386 0:0.1.7-1.2.EL4 set to be updated
---> Package libxml2.i386 0:2.6.16-10 set to be updated
---> Package bind-libs.i386 20:9.2.4-27.0.1.el4 set to be updated
---> Package freetype.i386 0:2.1.9-6.el4 set to be updated
--> Running transaction check
--> Processing Dependency: libz.so.1 for package: gd
--> Processing Dependency: libglib-2.0.so.0 for package: gamin
--> Processing Dependency: libz.so.1 for package: freetype
--> Processing Dependency: libjpeg.so.62 for package: gd
--> Processing Dependency: libz.so.1 for package: libxml2
--> Processing Dependency: libXpm.so.4 for package: gd
--> Processing Dependency: libkrb5.so.3 for package: openssl
--> Processing Dependency: libgssapi_krb5.so.2 for package: openssl
--> Processing Dependency: libk5crypto.so.3 for package: openssl
--> Processing Dependency: libz.so.1 for package: openssl
--> Processing Dependency: libcom_err.so.2 for package: openssl
--> Processing Dependency: libpng12.so.0 for package: gd
--> Processing Dependency: libX11.so.6 for package: gd
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Package glib2.i386 0:2.4.7-1 set to be updated
---> Package xorg-x11-libs.i386 0:6.8.2-1.EL.19 set to be updated
---> Package e2fsprogs.i386 0:1.35-12.5.el4 set to be updated
---> Package zlib.i386 0:1.2.1.2-1.2 set to be updated
---> Package libjpeg.i386 0:6b-33 set to be updated
---> Package libpng.i386 2:1.2.7-3.el4 set to be updated
---> Package krb5-libs.i386 0:1.3.4-49 set to be updated
--> Running transaction check
--> Processing Dependency: libfontconfig.so.1 for package: xorg-x11-libs
--> Processing Dependency: libGL.so.1 for package: xorg-x11-libs
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Package fontconfig.i386 0:2.2.3-7.centos4 set to be updated
---> Package xorg-x11-Mesa-libGL.i386 0:6.8.2-1.EL.19 set to be updated
--> Running transaction check

Dependencies Resolved

=============================================================================
 Package                 Arch       Version          Repository        Size 
=============================================================================
Installing:
 bind-libs               i386       20:9.2.4-27.0.1.el4  update            569 k
 freetype                i386       2.1.9-6.el4      update            763 k
 gamin                   i386       0.1.7-1.2.EL4    base              111 k
 gd                      i386       2.0.28-5.4E      base              119 k
 libxml2                 i386       2.6.16-10        base              620 k
 openssl                 i686       0.9.7a-43.16     base              1.1 M
 openssl-devel           i386       0.9.7a-43.16     base              1.6 M
Installing for dependencies:
 e2fsprogs               i386       1.35-12.5.el4    base              772 k
 fontconfig              i386       2.2.3-7.centos4  base              117 k
 glib2                   i386       2.4.7-1          base              476 k
 krb5-libs               i386       1.3.4-49         update            482 k
 libjpeg                 i386       6b-33            base              127 k
 libpng                  i386       2:1.2.7-3.el4    update            155 k
 xorg-x11-Mesa-libGL     i386       6.8.2-1.EL.19    update            383 k
 xorg-x11-libs           i386       6.8.2-1.EL.19    update            2.7 M
 zlib                    i386       1.2.1.2-1.2      base               44 k

Transaction Summary
=============================================================================
Install     16 Package(s)         
Update       0 Package(s)         
Remove       0 Package(s)         
Total download size: 10 M
Downloading Packages:
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction

 

[cPanelKenneth]

yum is installing those dependencies. All cPanel doing is something like 'yum install glibc-compat'

 

[mtindor]

yum is installing those dependencies. All cPanel doing is something like 'yum install glibc-compat'

However, 'yum check-update' from the commandline doesn't reveal any new packages that need installed or anything like that, and 'yum update' doesn't update any packages.

The only time this happens is after I've cleaned out the i386 crap and Cpanel UPCP nightly stuff happens.

For instance, let's say I go in and remove all teh duplicate packages (the i386 versions). When I'm done I do a 'yum check-update' (which reveals nothing) and a 'yum update' (which does nothing).

Why when UPCP runs does it find packages that are missing dependencies because I removed those packages earlier? All packages that I remove do not have dependencies on them according to yum.

For instance, right now I have a bunch of duplicate packages (including i386 and x86_64 versions of bind-libs).

--> Populating transaction set with selected packages. Please wait.
---> Package bind-libs.i386 20:9.2.4-27.0.1.el4 set to be erased
--> Running transaction check

Dependencies Resolved

=============================================================================
 Package                 Arch       Version          Repository        Size 
=============================================================================
Removing:
 bind-libs               i386       20:9.2.4-27.0.1.el4  installed         1.4 M

Transaction Summary
=============================================================================
Install      0 Package(s)         
Update       0 Package(s)         
Remove       1 Package(s)         
Total download size: 0

As you can see, when attempting to remove the i386 version of bind-libs, it shows there are no dependencies. If I remove bind-libs.i386 using 'yum remove bind-libs.i386' it will remove just fine. So there really is no dependency on bind-libs.i386 according to teh RPM database. So I'm not sure why when UPCP nightly run happens it ends up running Yum in such a way that Yum determines there are dependencies which require that package.

Mike

 

[mtindor]

Removing:
expat i386 1.95.7-4 installed 147 k
glibc i686 2.3.4-2.36 installed 14 M
Removing for dependencies:
frontpage i386 2002-SR1.2 installed 30 M

It seems the only Frontpage package available for CentOS 4.5 and Cpanel (and Im guessing one that Cpanel installed during its initial install process) is an i386 version. And it depends upon glibc.i686 and expat.i386 and installs them. Then it's a chain event, with a bunch of .i386 packages being installed all because frontpage.i386 is installed.

Is there any way around this? This was a barebones install, so I'm making the assumption that Cpanel installed that as part of it's install process. But in the end it causes about 20 i386/i686 versions of other RPMs to be installed on the system to meet its dependencies. If it weren't for Frontpage, yum wouldnt' keep insisting on reinstalling all these i386 package I think.

Mike

 

[cPanelKenneth]

As long as FrontPage is "needed" by your server, you'll see this.

 

[mtindor]

As long as FrontPage is "needed" by your server, you'll see this.

If we can make the assumption that none of my users wants Frontpage (i know - we can already make the assumption that they dont NEED it rofl), then what would be the proper method of removing FP support?

If it comes installed by default on Cpanel (I don't remember an option of checking it or not), then if I remove the RPM what happens?

Will I also need to re-compile Apache without Frontpage support as well, or will the previously built apache continue to operate and serve sites without a problem as long as they aren't Frontpage sites?

And is Cpanel smart enough to know when Frontpage is not installed/wanted and thus not offer that option to click upon in the customer's Cpanel?

Mike

 

[h4f]

What is the outcome of this discussion ?

It seem to me that also on CentOs 5.1 this is a big issue.

I can't run Easyapache anymore because of duplicate installed packages.

I can't remove the wrong glibc because 100 other packages are depending on it (even Exim was compiled against i386 library)

And when trying to upgrade to centos 5.2 (yum upgrade) I get also:
Error: No Package Matching glibc.i686

We have never enabled frontpage and we are never going to enable it but still upcp installs libraries and i386 version that we have excluded in /etc/yum.conf

In this time I do not think that any serieus hosting company is using non x86_64 platform, so please prevent WHM to install such libraries automatically and provide us a solutions for the problems that we are facing today.

Yum update doesn't work anymore because of this and while in the future Cpanel can claim that it isn't their problem that allot of WHM servers are hacked due outdated versions of files, it is WHM that is causing this.

I just have seen that you dropped support for Fedora and other linux distro's I hope that the time and resources that this saves is going to be invested in a better support of CentOS.

 

[nickp666]

In this time I do not think that any serieus hosting company is using non x86_64 platform, so please prevent WHM to install such libraries automatically and provide us a solutions for the problems that we are facing today.

I wouldnt be so sure of that tbh, the first generation Intel Core Duo's are 32-bit and didnt move to 64 till Core 2 Duos