--On Tuesday, February 21, 2017 1:04 PM +0000 Frank Swasey Frank.Swasey@uvm.edu wrote:
Years ago, I had code that did that and then I got a version of Net::LDAP that sent null attributes across the wire. Even back then OpenLDAP was upset by such behavior. I quickly updated my code to check if (in your case) @eduPersonAffiliation had zero entries and issue a proper $entry->delete('eduPersonAffiliation') call in that case. I've not had any issues since. Perhaps, your Net::LDAP module version has changed and it is sending what is being logged across the wire instead of the delete you are expecting.
Interesting... It would still be good for OpenLDAP to not crash in that case, however. ;)
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On 2/21/17, 11:04, "Quanah Gibson-Mount" quanah@symas.com wrote:
--On Tuesday, February 21, 2017 1:04 PM +0000 Frank Swasey Frank.Swasey@uvm.edu wrote:
> Years ago, I had code that did that and then I got a version of Net::LDAP > that sent null attributes across the wire. Even back then OpenLDAP was > upset by such behavior. I quickly updated my code to check if (in your > case) @eduPersonAffiliation had zero entries and issue a proper > $entry->delete('eduPersonAffiliation') call in that case. I've not had > any issues since. Perhaps, your Net::LDAP module version has changed and > it is sending what is being logged across the wire instead of the delete > you are expecting.
Interesting... It would still be good for OpenLDAP to not crash in that case, however. ;)
I obviously was not paying enough attention. I didn't realize OpenLDAP was crashing. I agree, that shouldn't happen - it should fail the update (IMHO) because null values for attributes are not legal.
- Frank
openldap-technical@openldap.org
-
Frank Swasey -
Quanah Gibson-Mount