LARTC - Apr 2006 - X86_64, Groupinstall KDE fails

I have an Athlon/64, 1 GB RAM, 80 GB IDE system and I'm intending to use it 
for combination workstation/Dev server duties. 

I've gotten a consistent failure when I try to groupinstall KDE. After 
grinding through all the deps, it comes up with the below: 

Install    228 Package(s)
Update       0 Package(s)
Remove       0 Package(s)
Total download size: 331 M
Is this ok [y/N]: y
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
  file /usr/share/man/man5/fonts-conf.5.gz from install of fontconfig-2.2.3-7 
conflicts with file from package fontconfig-2.2.3-7

It appears that packages openssl and fontconfig are conflicting with 
themselves! (?!?) 

This is a clean, minimal install of CentOS 4.3/64, (installed with all 
optional packages unchecked, so only disk 1 was needed) I haven't even done
a
yum update, but that doesn't change anything when I try it. (I've now
wiped
it twice to try to figure out what I'm missing. Both packages are already 
installed, with the versions complained about... 

I've tried running rpm --rebuilddb, and yum clean all to no positive change.

What's going on here? What can I try from here? 

-Ben 
-- 
"The best way to predict the future is to invent it."
- XEROX PARC slogan, circa 1978

> It appears that packages openssl and fontconfig are conflicting with
> themselves! (?!?)
Yes, they are. You're suffering from x86 vs x86_64. You need to
exclude i386 in your yum configs
> This is a clean, minimal install of CentOS 4.3/64, (installed with all
> optional packages unchecked, so only disk 1 was needed) I haven't even
done a
> yum update, but that doesn't change anything when I try it. (I've
now wiped
> it twice to try to figure out what I'm missing. Both packages are
already
> installed, with the versions complained about...
>
> I've tried running rpm --rebuilddb, and yum clean all to no positive
change.
>
> What's going on here? What can I try from here?
create a ~/.rpmmacros file containing:
%_query_all_fmt %%{name}-%%{version}-%%{release}.%%{arch}

and this will clue you into when i386 packages are conflicting with
x86_64 packages.


--
Any sufficiently advanced technology is indistinguishable from magic.
-Arthur C. Clarke

Greetings Alan,

 : I have a mail server (and a test program as well) that binds to 
 : an address on eth1, and tries to connect to an address on eth0''s 
 : network. Connections just time out.  I''ve tested connections 
 : where I did not bind to a specific interface and I can make the 
 : connection.
 : 
 : I''ve set ip_forward=1, and rp_filter=0 on all interfaces, and 
 : still cannot get a connection from eth1''s address to something 
 : off of eth0''s networks.  Firewalls are disabled on the host.

Well....I don''t think you should need to remove rp_filter unless you 
are performing policy routing in addition to the simple routing 
configuration you describe.

 : Is there additional voodoo that needs to be set to allow traffic 
 : to cross from one interface to the other?

Did you pay your semi-annual chicken-sacrificing bill?  If not, I 
may not be able to help you.

OK, seriously, I have just tested exactly this sort of connection on 
a similarly configured network.  It works exactly as you want it to.  
I''m guessing that you have some packet filter somewhere which is 
interfering.  How would you be able to tell?  First, watch traffic 
to see if it is ever leaving your router, and watch on your 
mailserver to see that traffic is arriving:

      router# tcpdump -nn -i eth0 host $MAILSERVER_IP
  mailserver# tcpdump -nn -i eth0 host $ROUTER_IP_0 or host $ROUTER_IP_1
  
Now, make those connections from your router (with your TCP testing 
tool of choice):

      router# socat - TCP4:$MAILSERVER_IP:$SERVICE,bind=$eth0_IP
      router# nc -vvs $eth1_IP  $MAILSERVER_IP  $SERVICE

If you don''t see any traffic leaving your router, is it possible 
that you have a strange POSTROUTING rule which does not refer to 
output interface?

Good luck,

-Martin

-- 
Martin A. Brown             
http://linux-ip.net/

Martin A. Brown wrote:
> Did you pay your semi-annual chicken-sacrificing bill?  If not, I 
> may not be able to help you.
>   
That bill is paid, but my ticket on the clue train isn''t...

Hour after I wrote that, I realized there''s not return path for 
packets.  At least to that source address.
Have a potential solution working using SNAT.  Thanks for indulging me.
-Alan

-- 
Alan Sparks, UNIX/Linux Systems Integration and Administration
<asparks@doublesparks.net>