Bug 98027 (IT_36784)
Summary: | cross-arch slave servers are not possible (at least x86 <-> ia64) | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 2.1 | Reporter: | Ben Levenson <benl> |
Component: | ypserv | Assignee: | Chris Feist <cfeist> |
Status: | CLOSED WORKSFORME | QA Contact: | Jay Turner <jturner> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 2.1 | CC: | cfeist, mrb, sharp, srevivo, steved, tao |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-09-29 21:05:32 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 132992 |
Description
Ben Levenson
2003-06-25 16:11:07 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. 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. |