Hide Forgot
Description of problem: I'm having issues setting up a slave server using two different archs (x86 master, ia64 slave): # arch ia64 # ypwhich test1240.test.redhat.com # ./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) <snip> 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): ypserv-2.8-0.AS21E How reproducible: 100% 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
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.
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.
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?
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...?
I have been unable to replicate this bug with FC5. Please re-open if the bug is present in FC5.