I'm able to specify rwm bindDN rules without password-policy enabled just fine, like this one:
rwm-rewriteContext bindDN rwm-rewriteRule "^([^=]+)=([^@]+)@olddomain.com(.+),dc=olddomain,dc=com$" "$1=$2@newdomain.com$3,dc=newdomain,dc=com" ":@"
However, when I enable password policy (which also works fine on its own), slapd segfaults. From doing a backtrace and stepping through the code, it looks like the crux of the issue is that the mdb_info struct ends up with garbage data:
struct mdb_info *mdb = (struct mdb_info *) op->o_bd->be_private;
mi_dbenv_home and mi_monitor have random stuff in them.
I'm mulling over how much additional time to spend on this. rwm is a very elegant solution to a current issue that could save me a bunch of time to set up additional LDAP servers with the renamed data. If this is an isolated bug for which a quick fix might be possible, I might investigate further.
But if it's a thorny issue or just the tip of the iceberg of things where rwm might break unexpectedly, then it may be better for me to consider other options. OpenLDAP developers, what do your instincts say on this?
Regards,
-Kartik
--On Thursday, June 23, 2022 5:21 PM -0400 Kartik Subbarao subbarao@computer.org wrote:
I'm able to specify rwm bindDN rules without password-policy enabled just fine, like this one:
rwm-rewriteContext bindDN rwm-rewriteRule "^([^=]+)=([^@]+)@olddomain.com(.+),dc=olddomain,dc=com$" "$1=$2@newdomain.com$3,dc=newdomain,dc=com" ":@"
However, when I enable password policy (which also works fine on its own), slapd segfaults.
I'm mulling over how much additional time to spend on this. rwm is a very elegant solution to a current issue that could save me a bunch of time to set up additional LDAP servers with the renamed data. If this is an isolated bug for which a quick fix might be possible, I might investigate further.
But if it's a thorny issue or just the tip of the iceberg of things where rwm might break unexpectedly, then it may be better for me to consider other options. OpenLDAP developers, what do your instincts say on this?
If slapd segfaults, an ITS with clear reproduction steps should generally be filed. I would note that you have not specified the OpenLDAP release on which you encountered this problem. There's been a lot of (relatively) recent work in fixing segfault items when using slapo-rwm, so it would be helpful to know what release you hit this on.
Regards, Quanah
On 6/23/22 4:29 PM, Quanah Gibson-Mount wrote:
[...] I'm mulling over how much additional time to spend on this. rwm is a very
elegant solution to a current issue that could save me a bunch of time to set up additional LDAP servers with the renamed data. If this is an isolated bug for which a quick fix might be possible, I might investigate further.
But if it's a thorny issue or just the tip of the iceberg of things where rwm might break unexpectedly, then it may be better for me to consider other options. OpenLDAP developers, what do your instincts say on this?
If slapd segfaults, an ITS with clear reproduction steps should generally be filed. I would note that you have not specified the OpenLDAP release on which you encountered this problem. There's been a lot of (relatively) recent work in fixing segfault items when using slapo-rwm, so it would be helpful to know what release you hit this on.
Sorry -- I'm running 2.4.57+dfsg-2ubuntu1.
Regards,
-Kartik
On 6/23/22 4:29 PM, Quanah Gibson-Mount wrote:
If slapd segfaults, an ITS with clear reproduction steps should generally be filed. I would note that you have not specified the OpenLDAP release on which you encountered this problem. There's been a lot of (relatively) recent work in fixing segfault items when using slapo-rwm, so it would be helpful to know what release you hit this on.
I found a quick way to reproduce this on 2.5.12 (a small edit to tests/scripts/relay and tests/data/slapd-relay.conf) and reported this as ITS#9871.
Regards,
-Kartik
openldap-technical@openldap.org
-
Kartik Subbarao -
Quanah Gibson-Mount