Summary: | app-emulations/vmware-server-1.0.4 vmware-authd is binary incompatible with gentoo's pam_ldap.so module (linked against openssl 0.9.8) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Daniel <deepee> |
Component: | New packages | Assignee: | Gentoo VMWare Bug Squashers [disabled] <vmware+disabled> |
Status: | RESOLVED DUPLICATE | ||
Severity: | major | CC: | cardoe |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Build instructions bundled in a shell script, used to compile a special libldap.so liblber.so to support vmware-authd against pam_ldap |
Description
Daniel
2007-10-21 21:25:51 UTC
Sorry Daniel, I realize it's a bug, but you seem quite aware that it's an upstream bug. How would you like us to help? We can possibly add a note at the end of the ebuild, but I'm not sure there's a very clean way of ensuring that openldap is compiled against the old openssl and that it's only done when you need ldap support through pam (and not just that you happen to have openldap, openssl and vmware installed on the same box). If you can think of a solution, we'd welcome it, but I don't really see what we can do? I'm going to mark this bug as UPSTREAM because we've really got our hands tied here, but if you disagree, please reply here and we'll reopen it... Created attachment 134144 [details]
Build instructions bundled in a shell script, used to compile a special libldap.so liblber.so to support vmware-authd against pam_ldap
I got vmware-server's vmware-authd (using gentoo's standard shipped pam_ldap) finally running. Therefore I adepted the idea and instructions behind the above mentioned blog posting. My changes:
1.) ssl config options are wrong, "--" should not be used (gentoo additionally uses "threads")
2.) CPPFLAGS are useless; used CFLAGS=... instead
3.) ln -s install command's are a little bit "reversed" or I didn't understood the paths ;-)
I build the latest (openldap 2.3.38) libldap.so and liblber.so which are compiled using openssl 0.9.7m header files. Testing this build client-binaries explicitly using the openssl-0.9.7-libs starting the also compiled ldapsearch command line tool:
LD_LIBRARY_PATH="PATH/TO/BUILD/LDAPLIBS" ldapsearch -x-Z -h "..." -D "..." -W
worked like a charm! ;-)
Attached to this message you'll find the shell script I used to compile libldap 2.3.38 against openssl and install the lib under vmware-server's library directory.
After the script has been run I manually extended the vmware-authd's xinetd-configuration file "/etc/xinetd.d/vmware-authd" by this line:
"env = LD_LIBRARY_PATH=/.../vmware/server/lib/lib/libldap-2.3.so.0:/.../vmware/server/lib/lib/liblber-2.3.so.0"
Opend a console, entered login and password ----> BINGO! ;-)
cat /etc/xinetd.d/vmware-authd
# default: on
# description: The VMware remote access authentification daemon, using
# custom openldap libs compiled against openssl 0.9.7 to allow usage of
# gentoo's ebuild-shipped "pam_ldap/nss_ldap" to authenticate/authorize
# against ldap directories:
service vmware-authd
{
disable = no
port = 902
socket_type = stream
protocol = tcp
wait = no
user = root
server = /opt/vmware/server/sbin/vmware-authd
env = LD_LIBRARY_PATH=/opt/vmware/server/lib/lib/libldap-2.3.so.0:/opt/vmware/server/lib/lib/liblber-2.3.so.0
type = unlisted
}
Open question:
How can (should?!) this workaraound be integrated into vmware-server ebuild (perhaps by (miss)using "USE=ldap")??? Or should this bug report including this tested workaround and the shell-script, be linked in a message that the ebuild prints after emerge has been run? I leave this decision completely up to you. ;-)
Best regards
Daniel
Ok thanks. I think at best we're going to mention that people looking for LDAP/pam support should see this bug. I hope that's ok with you, thanks for contributing your work back to the community... 5:) I've reOPENed this until I add it into the overlay or portage itself. Hey Daniel, Nice work. I've been on a similar crusade to get this fixed speaking with various product managers and such. I've been approaching it from another standpoint to attempt to get them to change the way they build their product. They need to prevent symbols from being exported for libraries that are being linked in as helper libs because when openssl 0.9.9 is released and vmware switches to 0.9.8, we'll have the same problem. Additionally, simply compiling openldap against Gentoo's latest 0.9.7 version (only one without security issues) didn't fix the problem for me. I had to actually compile it against the openssl libraries they provided. I'll check out the work you've done on this bug and report back. There was another similar bug to this about nss_ldap that was resolved but I can't remember what fixed it. (It could have been unrelated too.) This is probably obsolete by now? Actually, when Gentoo switches to 1.0.0 of OpenSSL, this issue will crop up again. (In reply to comment #6) > Actually, when Gentoo switches to 1.0.0 of OpenSSL, this issue will crop up > again. > Yes. I'm reading gentoo-dev too... :| Bug 328355 should handle the slotting, so I'm resolving this one here (slightly unconventinally) as its duplicate... *** This bug has been marked as a duplicate of bug 328355 *** |