On 8/18/2012 4:07 AM, O. Hartmann wrote: > My setups on all boxes using OpenLDAP, the port > net/opendldap24-client/server has security/cyrus-sasl2 enabled. > I use nsswitch and nascd. > > The problem: > I can not anymore install or reinstall (using portmaster, patched for > pkgng) the ports > > security/cyrus-sasl2 > net/openldap24-client > > When performing an update (no matter which one), The installation > process dies when installing the packages (see error for openldap-cleint > below, it is proxy for cyrus-sasl2 also). > > After a failed installation, close to all binaries I touch start to > coredump in a mustang way. ls(1) works, but ls -la dumps core (resolving > the ownership-issue?). > > The only way to "save" the box is to copy missing libldap_r-2.4.so.8 or > libsasl2.so.2 to /usr/local/lib/ from another, compatible box or from a > backup. > > It is impossible to me to update/reinstall either net/openldap24-client > or security/cyrus-sasl2. > > ===> Installing for openldap-sasl-client-2.4.32_1 > ===> Generating temporary packing list > Segmentation fault (core dumped) > *** [install-mtree] Error code 139 > What happens if you disable both LDAP and cache support from NSS before upgrading either of those two packages? Installing files certainly must invoke functions that need to translate owners/groups to uid/gid so perhaps something related to that suddenly fails during an attempt to replace the library. It sounds like if your LDAP support becomes corrupt, then it leaves a gaping hole in the NSS critical path that many parts of the system must be using. When you run into this situation and can resolve it easily by replacing the old ldap library, is the old one corrupt? Missing? Can you save a copy for evaluation? Does your system break in a similar manner simply by renaming the LDAP library, or does it behave worse only if there is a faulty LDAP library being used by nss_ldap?Received on Sat Aug 18 2012 - 18:31:45 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:29 UTC