Full_Name: Ondrej Kuznik Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120319-back-config-slapmodify.tgz Submission from: (NULL) (62.168.56.1) For slapmodify to be usable on a database, that database needs to implement the bi_tool_dn2id_get and bi_tool_entry_modify functions, which is not the case of the back-config. I've put together a minimal (and maybe too naive) implementation of these for back-config and back-ldif at the above link. Currently, there is no validation whether the modification passes back-config checks since config_modify_internal takes a modify operation, while bi_tool_entry_modify receives only the new version of the entry to be modified. Also, for slapmodify to be really useful, it would have to allow entry deletion, for which there is no tool mode callback. To implement deletes, do you think it is better that deletion of an entry with children fail or delete the entire subtree? While the former seems both easier to implement and more sensible to me, I would like your know opinion. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Acision. Acision has not assigned rights and/or interest in this work to any party. I, Ondrej Kuznik am authorized by Acision, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2012 Acision Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/20/2012 11:11 AM, ondrej.kuznik@acision.com wrote: > For slapmodify to be usable on a database, that database needs to > implement the bi_tool_dn2id_get and bi_tool_entry_modify > functions, which is not the case of the back-config. I've put > together a minimal (and maybe too naive) implementation of these > for back-config and back-ldif at the above link. Ok, nevermind for now, the implementation was too naive and would break some other things (the slapadd in test005). - -- Ondrej Kuznik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+IMUkACgkQ9GWxeeH+cXtodQCeJdq8IQvH+hWEYTTMt3hn+6UC K20An0uaLb/lmDo6zBJtHm3RL9FMXezq =xnVE -----END PGP SIGNATURE----- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/13/2012 04:00 PM, ondrej.kuznik@acision.com wrote: > On 03/20/2012 11:11 AM, ondrej.kuznik@acision.com wrote: >> For slapmodify to be usable on a database, that database needs >> to implement the bi_tool_dn2id_get and bi_tool_entry_modify >> functions, which is not the case of the back-config. I've put >> together a minimal (and maybe too naive) implementation of these >> for back-config and back-ldif at the above link. > > Ok, nevermind for now, the implementation was too naive and would > break some other things (the slapadd in test005). I prepared an updated version of the patches below, patches 1-4,8-12 add this support and introduce a new testcase, temporarily assigned to the currently free position 007 which will ignore errors, if encountered during slapmodify invocation. ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120423-slapmodify-support.tgz - -- Ondrej Kuznik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+VfbEACgkQ9GWxeeH+cXsfNgCfcbPewsqwd5kSW3tHCzqCBfn1 G7gAn3mRB0UoG50F1ezbBLSAzsFDRIhX =J2sk -----END PGP SIGNATURE----- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/23/2012 06:06 PM, ondrej.kuznik@acision.com wrote: > On 04/13/2012 04:00 PM, ondrej.kuznik@acision.com wrote: >> On 03/20/2012 11:11 AM, ondrej.kuznik@acision.com wrote: >>> For slapmodify to be usable on a database, that database needs >>> to implement the bi_tool_dn2id_get and bi_tool_entry_modify >>> functions, which is not the case of the back-config. I've put >>> together a minimal (and maybe too naive) implementation of >>> these for back-config and back-ldif at the above link. > >> Ok, nevermind for now, the implementation was too naive and >> would break some other things (the slapadd in test005). > > I prepared an updated version of the patches below, patches > 1-4,8-12 add this support and introduce a new testcase, temporarily > assigned to the currently free position 007 which will ignore > errors, if encountered during slapmodify invocation. > > ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120423-slapmodify-support.tgz I > forgot to include the IPR Notice for the above patch series: The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Acision. Acision has not assigned rights and/or interest in this work to any party. I, Ondrej Kuznik am authorized by Acision, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2012 Acision Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. - -- Ondrej Kuznik A: Because it destroys the flow of the conversation. Q: Why is it bad? A: No, it's bad. Q: Should I top post in replies to mailing lists or on Usenet? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+Vfs4ACgkQ9GWxeeH+cXvwDgCeNPRxiAxBZgzX0XDeToxPz71S YTcAoIiwPVXu5zg0TG+o/tdIFlKqd/fO =thvs -----END PGP SIGNATURE----- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.
Hi Ondrej, With current git master, "slapcat -b cn=config" triggers an assertion after it finishes its output. git-bisect blames slapmodify patch for introducing that. Would you mind taking a look? See ITS#7894. thanks, Ryan
changed notes changed state Open to Release moved from Incoming to Software Enhancements
added to master added to RE25
changed notes changed state Release to Closed