Description of problem: When trying to connect to Spacewalk as PAM user using LDAP I get 503 service temporaly unavailable. Version-Release number of selected component (if applicable): Spacewalk nightly spacewalk-backend-1.1.49-1.el5 spacewalk-schema-1.1.30-1.el5 tomcat5-5.5.23-0jpp.7.el5_3.2 How reproducible: Always Steps to Reproduce: 1. Start LDAP server 2. Create LDAP user (USER, PASS) 3. Create Spacewalk user (USER, PASS) with PAM toggled 4. Try to connect to Spacewalk using XML-RPC - client.auth.login(USER, PASS) Actual results: <ProtocolError for my_server/rpc/api: 503 Service Temporarily Unavailable> Expected results: sessionKey Additional info:
Description of problem: Same problem here ... Version-Release number of selected component (if applicable): Spacewalk 1.1 spacewalk-backend-1.1.50-1.el5 spacewalk-schema-1.1.31-1.el5 tomcat5-5.5.23-0jpp.9.el5_5 How reproducible: Always Steps to Reproduce: 1. add in /etc/rhn/rhn.conf ... pam_auth_service = rhn-satellite 2. create file /etc/pam.d/rhn-satellite #%PAM-1.0 auth required pam_env.so auth sufficient pam_ldap.so auth required pam_deny.so account required pam_ldap.so 3. configure /etc/ldap.conf to connect to ldap server: ... host auth-01.example.it auth-02.example.it base dc=example,dc=it nss_base_passwd ou=People,dc=example,dc=it nss_base_shadow ou=People,dc=example,dc=it nss_base_group ou=Groups,dc=example,dc=it ssl start_tls tls_cacertdir /etc/openldap/cacerts pam_password md5 3. Create Spacewalk user (USER, PASS) with PAM toggled 4. try to login on Spacewalk login page Actual results: Error message in /var/log/tomcat5/catalina.out ... java: ../../../libraries/libldap/extended.c:133: ldap_extended_operation_s: Assertion `( (ld)->ld_options.ldo_valid == 0x2 )' failed. and server hang Expected results: succesfull login Additional info: This configuration was working well till 1.0 -> 1.1 upgrade; after that, I' m not able to login with my ldap account
There is a possible solution in spacewalk-user ML, in a mail from Christoph Sievers (https://www.redhat.com/archives/spacewalk-list/2010-August/msg00177.html): change /etc/rhn/rhn.conf from hibernate.connection.driver_proto=jdbc:oracle:oci to hibernate.connection.driver_proto=jdbc:oracle:thin I've done the change above, and now I'm able to login with my ldap account ...
(In reply to comment #3) > There is a possible solution in spacewalk-user ML, in a mail from Christoph > Sievers > (https://www.redhat.com/archives/spacewalk-list/2010-August/msg00177.html): > > > change /etc/rhn/rhn.conf > > from > hibernate.connection.driver_proto=jdbc:oracle:oci > to > hibernate.connection.driver_proto=jdbc:oracle:thin > > > I've done the change above, and now I'm able to login with my ldap account ... Please note that we really do not want to do this if possible, as the OCI driver allows us to do TNS resolution and other stuff.
By any chance, were there some AVC denials logged in /var/log/audit/audit.log on this system?
I've restored original configuration (hibernate.connection.driver_proto=jdbc:oracle:oci) and restarted Spacewalk; only error message in /var/log/audit/audit.log is: type=ANOM_ABEND msg=audit(1284100567.049:1437): auid=0 uid=91 gid=91 ses=275 pid=32309 comm="java" sig=6 Let me know if you need more informations ...
I've reproduced the error both on x86_64 and on i386 architectures.
Confirmed. Same problems. Workaround addressed issue.
Taking.
Fixed in Spacewalk master, f5a5bb16292d33bf63941d5d45d361ebb2f39975. We LD_PRELOAD openldap library to override the symbols in Oracle's .so, as that causes conflicts and segfaults. The updated package oracle-lib-compat-10.2-23 should hit the nightly repos shortly.
Package is in the nightly compose, moving ON_QA.
RHEL5 version is ok, but Fedora13 version still makes SIGSEGV.
I've filed bug 633805 against Fedora's tomcat6.
The fix as written did not work when openldap-devel was not installed. We now lookup via pam_ldap.so. Spacewalk master 3e5fd863b076ab611d0beb53a295b2d8e08f3ae0.
*** Bug 641884 has been marked as a duplicate of this bug. ***
Thanks Michael for finding my duplicate and marking it as such. Any chance this fix is backported to spacewalk 1.1 where it initially showed up?
Installed the package oracle-lib-compat-10.2.0.25 on 1.1 and everything worked fine.
Moving ON_QA. Please use the Spacewalk 1.2 release candidate yum repo at http://koji.spacewalkproject.org/spacewalk/split/spacewalk-5E/server/spacewalk-5E-1.2/$basearch/os http://koji.spacewalkproject.org/spacewalk/split/spacewalk-f12/server/spacewalk-f12-1.2/$basearch/os http://koji.spacewalkproject.org/spacewalk/split/spacewalk-f13/server/spacewalk-f13-1.2/$basearch/os http://koji.spacewalkproject.org/spacewalk/split/spacewalk-f14/server/spacewalk-f14-1.2/$basearch/os (depending on your OS) to verify the bugzilla.
With Spacewalk 1.2 released, marking as CLOSED CURRENTRELEASE. https://www.redhat.com/archives/spacewalk-list/2010-November/msg00111.html