Bug 98027 (IT_36784) - cross-arch slave servers are not possible (at least x86 <-> ia64)
Summary: cross-arch slave servers are not possible (at least x86 <-> ia64)
Alias: IT_36784
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: ypserv
Version: 2.1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Chris Feist
QA Contact: Jay Turner
Depends On:
Blocks: 132992
TreeView+ depends on / blocked
Reported: 2003-06-25 16:11 UTC by Ben Levenson
Modified: 2015-01-08 00:05 UTC (History)
6 users (show)

Clone Of:
Last Closed: 2006-09-29 21:05:32 UTC

Attachments (Terms of Use)

Description Ben Levenson 2003-06-25 16:11:07 UTC
Description of problem:
I'm having issues setting up a slave server using two different archs 
(x86 master, ia64 slave):

# arch

# ypwhich

# ./ypinit -s test1240.test.redhat.com
We will need a few minutes to copy the data from test1240.test.redhat.com.
Transferring mail.aliases...
Trying ypxfrd ...rpc.ypxfrd doesn't support the needed database type
call to rpc.ypxfrd failed: RPC: Can't decode result
 (failed, fallback to enumeration)
./ypinit: line 22: 17076 Segmentation fault      $YPBINDIR/ypxfr -f -h $MASTER
-c -d $DOMAIN $map
YPINIT: WARNING: Couldn't exec /usr/lib/yp/ypxfr -f -h test1240.test.redhat.com
-c -d test.redhat.com mail.aliases
Transferring protocols.bynumber...
Trying ypxfrd ...rpc.ypxfrd doesn't support the needed database type
call to rpc.ypxfrd failed: RPC: Can't decode result
 (failed, fallback to enumeration)
and so on, and so on ...

Running 'ypinit -s <ia64 master>' from the ia64 slave works as expected.  
x86 master -> x86 slave also works as expected.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. set up master server
2. try to initialize slave server w/ ypinit -s <master>
Actual results:
see above

Expected results:
clean transfer with no errors or warnings

Comment 4 Chris Feist 2004-11-30 20:08:09 UTC
This problem is caused because ypserv/rpc.ypxfrd uses GDBM as a
backend database.  GDBM files are not binary compatible across
different architectures (ie. 32bit x86 vs. 64bit ia64), but ypxfr
attempts to send the GDBM files between master & slave servers which
causes the failure.

Fixing this bug will either require fixing GDBM (and potentially
making it binary incompatable w/ previous versions of GDBM) or by
fixing rpc.ypxfrd to extract the data from the GDBM database on the
master, transfer it to the slave, and then enter the data into the
database on the slave.

I'm examining the code to try to estimate how long it will take to fix
the bug.

Comment 9 Chris Feist 2005-01-26 17:43:30 UTC
On my machines it appears that although it fails you see this messages

 (failed, fallback to enumeration)

Which means transfering the binary transfer of the database failed,
but transferring each entry in the database one at a time succeeded.

Comment 14 Michael Belanger 2005-04-25 21:42:53 UTC
This bug also exists between x86_64 Fedora Core 2 and i386 machines.
Does anyone know if this problem is in both directions?  Say.. if I made the
x86_64 machine the primary NIS, would my rh9 i386 system receive the maps correctly?

Comment 22 steve harp 2006-04-04 03:22:18 UTC
This exact problem persists in FC4 and has been noted in Debian and Ubuntu
recently as well: https://launchpad.net/distros/ubuntu/+source/nis/+bug/23182 
The "fallback to enumeration" would be hopeful except on my 64-bit opteron
system it is cut short in a segfault:  *** glibc detected ***
/usr/lib64/yp/ypxfr: free(): invalid pointer: 0x0000003421b310f8 ***  etc etc
Given that this appears to be a design oversight, is it time to start planning
the move to LDAP...?

Comment 23 Chris Feist 2006-09-29 21:05:32 UTC
I have been unable to replicate this bug with FC5.  Please re-open if the bug is
present in FC5.

Note You need to log in before you can comment on or make changes to this bug.