Hi,
I am upgrading from 1.2.9.9 from 1.2.8.3 and I am getting the following error from setup-ds-admin.pl --update
[01/Mar/2012:08:52:51 -0500] - from ldbm instance init: line 0: unknown or invalid matching rule "integerOrderingMatch" in index configuration (ignored) [01/Mar/2012:08:52:51 -0500] - from DSE add: line 0: unknown or invalid matching rule "integerOrderingMatch" in index configuration (ignored)
There are several objects in dse.ldif with the above matching rule defined. I'm not sure what to do with this. Either find all instances of the matching rule reference and remove them or put back the matching rule (if i can locate it from another one of my servers).
Also, I get the following and I believe these are non-issues - we don't utilize selinux. Is there some way to disable the selinux config in setup-ds-admin.pl??? I have looked through the source code and don't see how to disable it.
libsepol.print_missing_requirements: piranha's global requirements were not met: type/attribute piranha_port_t libsemanage.semanage_link_sandbox: Link packages failed /usr/sbin/semanage: Could not add port tcp/9830
I am on RHEL5.7 (if that makes a difference).
Many thanks for Rich's help in the past. I am grateful for this mailing list and all the other resources on the net to help me with the few problems I have had bringing up 389 for my institution.
/mrg
As I have tried to learn more about this problem, it would appear there isn't an obvious way to address this from the various config files. This leaves me at a bit of a loss to determine whether or not I should proceed with this version of the software. I get this integerOrderingMatch error for each of 3 the databases I have… netscaperoot, userRoot and changelog. I do have intention of pointing provisioning software at the directory so search filters of (x<=nnn) will happen. I issued some of these searches by hand and they still execute quickly.
Should I worry about these errors or just ignore them?
Advice appreciated.
/mrg
On Mar 1, 2012, at 9:02, Michael R. Gettes wrote:
Hi,
I am upgrading from 1.2.9.9 from 1.2.8.3 and I am getting the following error from setup-ds-admin.pl --update
[01/Mar/2012:08:52:51 -0500] - from ldbm instance init: line 0: unknown or invalid matching rule "integerOrderingMatch" in index configuration (ignored) [01/Mar/2012:08:52:51 -0500] - from DSE add: line 0: unknown or invalid matching rule "integerOrderingMatch" in index configuration (ignored)
There are several objects in dse.ldif with the above matching rule defined. I'm not sure what to do with this. Either find all instances of the matching rule reference and remove them or put back the matching rule (if i can locate it from another one of my servers).
Also, I get the following and I believe these are non-issues - we don't utilize selinux. Is there some way to disable the selinux config in setup-ds-admin.pl??? I have looked through the source code and don't see how to disable it.
libsepol.print_missing_requirements: piranha's global requirements were not met: type/attribute piranha_port_t libsemanage.semanage_link_sandbox: Link packages failed /usr/sbin/semanage: Could not add port tcp/9830
I am on RHEL5.7 (if that makes a difference).
Many thanks for Rich's help in the past. I am grateful for this mailing list and all the other resources on the net to help me with the few problems I have had bringing up 389 for my institution.
/mrg
On 03/01/2012 08:10 PM, Michael R. Gettes wrote:
As I have tried to learn more about this problem, it would appear there isn't an obvious way to address this from the various config files. This leaves me at a bit of a loss to determine whether or not I should proceed with this version of the software. I get this integerOrderingMatch error for each of 3 the databases I have… netscaperoot, userRoot and changelog. I do have intention of pointing provisioning software at the directory so search filters of (x<=nnn) will happen. I issued some of these searches by hand and they still execute quickly.
Should I worry about these errors or just ignore them?
Can you provide your index entries that use integerOrderingMatch?
Advice appreciated.
/mrg
On Mar 1, 2012, at 9:02, Michael R. Gettes wrote:
Hi,
I am upgrading from 1.2.9.9 from 1.2.8.3 and I am getting the following error from setup-ds-admin.pl --update
[01/Mar/2012:08:52:51 -0500] - from ldbm instance init: line 0: unknown or invalid matching rule "integerOrderingMatch" in index configuration (ignored) [01/Mar/2012:08:52:51 -0500] - from DSE add: line 0: unknown or invalid matching rule "integerOrderingMatch" in index configuration (ignored)
There are several objects in dse.ldif with the above matching rule defined. I'm not sure what to do with this. Either find all instances of the matching rule reference and remove them or put back the matching rule (if i can locate it from another one of my servers).
Also, I get the following and I believe these are non-issues - we don't utilize selinux. Is there some way to disable the selinux config in setup-ds-admin.pl??? I have looked through the source code and don't see how to disable it.
libsepol.print_missing_requirements: piranha's global requirements were not met: type/attribute piranha_port_t libsemanage.semanage_link_sandbox: Link packages failed /usr/sbin/semanage: Could not add port tcp/9830
I am on RHEL5.7 (if that makes a difference).
Many thanks for Rich's help in the past. I am grateful for this mailing list and all the other resources on the net to help me with the few problems I have had bringing up 389 for my institution.
/mrg
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
dn: cn=changenumber,cn=index,cn=changelog,cn=ldbm database,cn=plugins,cn=confi g objectClass: top objectClass: nsIndex cn: changenumber nsSystemIndex: false nsIndexType: eq nsMatchingRule: integerOrderingMatch creatorsName: cn=Retro Changelog Plugin,cn=plugins,cn=config modifiersName: cn=Retro Changelog Plugin,cn=plugins,cn=config createTimestamp: 20111215194522Z modifyTimestamp: 20111215194522Z
dn: cn=entryusn,cn=index,cn=changelog,cn=ldbm database,cn=plugins,cn=config objectClass: top objectClass: nsIndex cn: entryusn nsSystemIndex: true nsIndexType: eq nsMatchingRule: integerOrderingMatch creatorsName: cn=ldbm database,cn=plugins,cn=config modifiersName: cn=ldbm database,cn=plugins,cn=config createTimestamp: 20111215194522Z modifyTimestamp: 20111215194522Z
dn: cn=entryusn,cn=default indexes,cn=config,cn=ldbm database,cn=plugins,cn=co nfig objectClass: top objectClass: nsIndex cn: entryusn nsSystemIndex: true nsIndexType: eq nsMatchingRule: integerOrderingMatch
dn: cn=entryusn,cn=index,cn=NetscapeRoot,cn=ldbm database,cn=plugins,cn=config objectClass: top objectClass: nsIndex cn: entryusn nsSystemIndex: true nsIndexType: eq nsMatchingRule: integerOrderingMatch creatorsName: cn=ldbm database,cn=plugins,cn=config modifiersName: cn=ldbm database,cn=plugins,cn=config createTimestamp: 20110817222255Z modifyTimestamp: 20110817222255Z
dn: cn=entryusn,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config objectClass: top objectClass: nsIndex cn: entryusn nsSystemIndex: true nsIndexType: eq nsMatchingRule: integerOrderingMatch creatorsName: cn=ldbm database,cn=plugins,cn=config modifiersName: cn=ldbm database,cn=plugins,cn=config createTimestamp: 20110722160718Z modifyTimestamp: 20110722160718Z
On Mar 1, 2012, at 22:26, Rich Megginson wrote:
On 03/01/2012 08:10 PM, Michael R. Gettes wrote:
As I have tried to learn more about this problem, it would appear there isn't an obvious way to address this from the various config files. This leaves me at a bit of a loss to determine whether or not I should proceed with this version of the software. I get this integerOrderingMatch error for each of 3 the databases I have… netscaperoot, userRoot and changelog. I do have intention of pointing provisioning software at the directory so search filters of (x<=nnn) will happen. I issued some of these searches by hand and they still execute quickly.
Should I worry about these errors or just ignore them?
Can you provide your index entries that use integerOrderingMatch?
Advice appreciated.
/mrg
On Mar 1, 2012, at 9:02, Michael R. Gettes wrote:
Hi,
I am upgrading from 1.2.9.9 from 1.2.8.3 and I am getting the following error from setup-ds-admin.pl --update
[01/Mar/2012:08:52:51 -0500] - from ldbm instance init: line 0: unknown or invalid matching rule "integerOrderingMatch" in index configuration (ignored) [01/Mar/2012:08:52:51 -0500] - from DSE add: line 0: unknown or invalid matching rule "integerOrderingMatch" in index configuration (ignored)
There are several objects in dse.ldif with the above matching rule defined. I'm not sure what to do with this. Either find all instances of the matching rule reference and remove them or put back the matching rule (if i can locate it from another one of my servers).
Also, I get the following and I believe these are non-issues - we don't utilize selinux. Is there some way to disable the selinux config in setup-ds-admin.pl??? I have looked through the source code and don't see how to disable it.
libsepol.print_missing_requirements: piranha's global requirements were not met: type/attribute piranha_port_t libsemanage.semanage_link_sandbox: Link packages failed /usr/sbin/semanage: Could not add port tcp/9830
I am on RHEL5.7 (if that makes a difference).
Many thanks for Rich's help in the past. I am grateful for this mailing list and all the other resources on the net to help me with the few problems I have had bringing up 389 for my institution.
/mrg
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
On 03/01/2012 08:57 PM, Michael R. Gettes wrote:
dn: cn=changenumber,cn=index,cn=changelog,cn=ldbm database,cn=plugins,cn=confi g objectClass: top objectClass: nsIndex cn: changenumber nsSystemIndex: false nsIndexType: eq nsMatchingRule: integerOrderingMatch creatorsName: cn=Retro Changelog Plugin,cn=plugins,cn=config modifiersName: cn=Retro Changelog Plugin,cn=plugins,cn=config createTimestamp: 20111215194522Z modifyTimestamp: 20111215194522Z
dn: cn=entryusn,cn=index,cn=changelog,cn=ldbm database,cn=plugins,cn=config objectClass: top objectClass: nsIndex cn: entryusn nsSystemIndex: true nsIndexType: eq nsMatchingRule: integerOrderingMatch creatorsName: cn=ldbm database,cn=plugins,cn=config modifiersName: cn=ldbm database,cn=plugins,cn=config createTimestamp: 20111215194522Z modifyTimestamp: 20111215194522Z
dn: cn=entryusn,cn=default indexes,cn=config,cn=ldbm database,cn=plugins,cn=co nfig objectClass: top objectClass: nsIndex cn: entryusn nsSystemIndex: true nsIndexType: eq nsMatchingRule: integerOrderingMatch
dn: cn=entryusn,cn=index,cn=NetscapeRoot,cn=ldbm database,cn=plugins,cn=config objectClass: top objectClass: nsIndex cn: entryusn nsSystemIndex: true nsIndexType: eq nsMatchingRule: integerOrderingMatch creatorsName: cn=ldbm database,cn=plugins,cn=config modifiersName: cn=ldbm database,cn=plugins,cn=config createTimestamp: 20110817222255Z modifyTimestamp: 20110817222255Z
dn: cn=entryusn,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config objectClass: top objectClass: nsIndex cn: entryusn nsSystemIndex: true nsIndexType: eq nsMatchingRule: integerOrderingMatch creatorsName: cn=ldbm database,cn=plugins,cn=config modifiersName: cn=ldbm database,cn=plugins,cn=config createTimestamp: 20110722160718Z modifyTimestamp: 20110722160718Z
This code has changed with 389-ds-base 1.2.10.2 - any chance you could try that version, in epel-testing?
On Mar 1, 2012, at 22:26, Rich Megginson wrote:
On 03/01/2012 08:10 PM, Michael R. Gettes wrote:
As I have tried to learn more about this problem, it would appear there isn't an obvious way to address this from the various config files. This leaves me at a bit of a loss to determine whether or not I should proceed with this version of the software. I get this integerOrderingMatch error for each of 3 the databases I have… netscaperoot, userRoot and changelog. I do have intention of pointing provisioning software at the directory so search filters of (x<=nnn) will happen. I issued some of these searches by hand and they still execute quickly.
Should I worry about these errors or just ignore them?
Can you provide your index entries that use integerOrderingMatch?
Advice appreciated.
/mrg
On Mar 1, 2012, at 9:02, Michael R. Gettes wrote:
Hi,
I am upgrading from 1.2.9.9 from 1.2.8.3 and I am getting the following error from setup-ds-admin.pl --update
[01/Mar/2012:08:52:51 -0500] - from ldbm instance init: line 0: unknown or invalid matching rule "integerOrderingMatch" in index configuration (ignored) [01/Mar/2012:08:52:51 -0500] - from DSE add: line 0: unknown or invalid matching rule "integerOrderingMatch" in index configuration (ignored)
There are several objects in dse.ldif with the above matching rule defined. I'm not sure what to do with this. Either find all instances of the matching rule reference and remove them or put back the matching rule (if i can locate it from another one of my servers).
Also, I get the following and I believe these are non-issues - we don't utilize selinux. Is there some way to disable the selinux config in setup-ds-admin.pl??? I have looked through the source code and don't see how to disable it.
libsepol.print_missing_requirements: piranha's global requirements were not met: type/attribute piranha_port_t libsemanage.semanage_link_sandbox: Link packages failed /usr/sbin/semanage: Could not add port tcp/9830
I am on RHEL5.7 (if that makes a difference).
Many thanks for Rich's help in the past. I am grateful for this mailing list and all the other resources on the net to help me with the few problems I have had bringing up 389 for my institution.
/mrg
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
I am in process of standing up a new directory service and will have to migrate many apps to the new service. Do you believe 1.2.10.2 is stable enough for production use? I would trust your assessment. I realize the caveats of any recommendation you might make.
Thanks!
/mrg
On Mar 1, 2012, at 23:16, Rich Megginson wrote:
This code has changed with 389-ds-base 1.2.10.2 - any chance you could try that version, in epel-testing?
On 03/01/2012 09:56 PM, Michael R. Gettes wrote:
I am in process of standing up a new directory service and will have to migrate many apps to the new service. Do you believe 1.2.10.2 is stable enough for production use? I would trust your assessment. I realize the caveats of any recommendation you might make.
It's hard to say - we have people using 1.2.10.2 in production on EL6 and Fedora - but none on EL5 that I'm aware of.
So, best to stick with 1.2.9.9 for production until we get some more feedback on 1.2.10.2
That being said, I was hoping you could try it out and see if it still has the problem.
Perhaps it is a schema problem?
grep -i changenumber /etc/dirsrv/slapd-INST/schema/* grep -i entryusn /etc/dirsrv/slapd-INST/schema/*
Thanks!
/mrg
On Mar 1, 2012, at 23:16, Rich Megginson wrote:
This code has changed with 389-ds-base 1.2.10.2 - any chance you could try that version, in epel-testing?
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
On Mar 2, 2012, at 9:21, Rich Megginson wrote:
On 03/01/2012 09:56 PM, Michael R. Gettes wrote:
I am in process of standing up a new directory service and will have to migrate many apps to the new service. Do you believe 1.2.10.2 is stable enough for production use? I would trust your assessment. I realize the caveats of any recommendation you might make.
It's hard to say - we have people using 1.2.10.2 in production on EL6 and Fedora - but none on EL5 that I'm aware of.
So, best to stick with 1.2.9.9 for production until we get some more feedback on 1.2.10.2
let me see how i can try it out… not sure given how we maintain things.
That being said, I was hoping you could try it out and see if it still has the problem.
Perhaps it is a schema problem?
grep -i changenumber /etc/dirsrv/slapd-INST/schema/* grep -i entryusn /etc/dirsrv/slapd-INST/schema/*
on 1.2.9.9
#grep -i changenumber * 02common.ldif:attributeTypes: ( 2.16.840.1.113730.3.1.5 NAME 'changeNumber' DESC 'Changelog attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 X-ORIGIN 'Changelog Internet Draft' ) 02common.ldif:objectClasses: ( 2.16.840.1.113730.3.2.1 NAME 'changeLogEntry' DESC 'LDAP changelog objectclass' SUP top MUST ( targetdn $ changeTime $ changenumber $ changeType ) MAY ( changes $ newrdn $ deleteoldrdn $ newsuperior ) X-ORIGIN 'Changelog Internet Draft' ) # grep -i entryusn * 01core389.ldif.rpmnew:attributeTypes: ( 2.16.840.1.113730.3.1.2096 NAME 'entryusn' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation X-ORIGIN 'Netscape' )
on 1.2.8.3
# grep -i changenumber * 02common.ldif:attributeTypes: ( 2.16.840.1.113730.3.1.5 NAME 'changeNumber' DESC 'Changelog attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 X-ORIGIN 'Changelog Internet Draft' ) 02common.ldif:objectClasses: ( 2.16.840.1.113730.3.2.1 NAME 'changeLogEntry' DESC 'LDAP changelog objectclass' SUP top MUST ( targetdn $ changeTime $ changenumber $ changeType ) MAY ( changes $ newrdn $ deleteoldrdn $ newsuperior ) X-ORIGIN 'Changelog Internet Draft' ) # grep -i entryusn * #
yep, that's nothing on entryusn
/mrg
Thanks!
/mrg
On Mar 1, 2012, at 23:16, Rich Megginson wrote:
This code has changed with 389-ds-base 1.2.10.2 - any chance you could try that version, in epel-testing?
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
On 03/02/2012 06:32 AM, Michael R. Gettes wrote:
On Mar 2, 2012, at 9:21, Rich Megginson wrote:
On 03/01/2012 09:56 PM, Michael R. Gettes wrote:
I am in process of standing up a new directory service and will have to migrate many apps to the new service. Do you believe 1.2.10.2 is stable enough for production use? I would trust your assessment. I realize the caveats of any recommendation you might make.
It's hard to say - we have people using 1.2.10.2 in production on EL6 and Fedora - but none on EL5 that I'm aware of.
So, best to stick with 1.2.9.9 for production until we get some more feedback on 1.2.10.2
let me see how i can try it out… not sure given how we maintain things.
That being said, I was hoping you could try it out and see if it still has the problem.
Perhaps it is a schema problem?
grep -i changenumber /etc/dirsrv/slapd-INST/schema/* grep -i entryusn /etc/dirsrv/slapd-INST/schema/*
on 1.2.9.9
#grep -i changenumber * 02common.ldif:attributeTypes: ( 2.16.840.1.113730.3.1.5 NAME 'changeNumber' DESC 'Changelog attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 X-ORIGIN 'Changelog Internet Draft' ) 02common.ldif:objectClasses: ( 2.16.840.1.113730.3.2.1 NAME 'changeLogEntry' DESC 'LDAP changelog objectclass' SUP top MUST ( targetdn $ changeTime $ changenumber $ changeType ) MAY ( changes $ newrdn $ deleteoldrdn $ newsuperior ) X-ORIGIN 'Changelog Internet Draft' ) # grep -i entryusn * 01core389.ldif.rpmnew:attributeTypes: ( 2.16.840.1.113730.3.1.2096 NAME 'entryusn' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation X-ORIGIN 'Netscape' )
The problem here seems to be that it is a *.rpmnew file. This is causing your schema to not be updated from the upgrade. Did you customize your 01core389.ldif file at some point?
Do a diff between 01core389.ldif and 01core389.ldif.rpmnew.
on 1.2.8.3
# grep -i changenumber * 02common.ldif:attributeTypes: ( 2.16.840.1.113730.3.1.5 NAME 'changeNumber' DESC 'Changelog attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 X-ORIGIN 'Changelog Internet Draft' ) 02common.ldif:objectClasses: ( 2.16.840.1.113730.3.2.1 NAME 'changeLogEntry' DESC 'LDAP changelog objectclass' SUP top MUST ( targetdn $ changeTime $ changenumber $ changeType ) MAY ( changes $ newrdn $ deleteoldrdn $ newsuperior ) X-ORIGIN 'Changelog Internet Draft' ) # grep -i entryusn * #
yep, that's nothing on entryusn
/mrg
Thanks!
/mrg
On Mar 1, 2012, at 23:16, Rich Megginson wrote:
This code has changed with 389-ds-base 1.2.10.2 - any chance you could try that version, in epel-testing?
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Yup. that did the trick. I never modified the file but I did inherit this project/configuration. The timestamps on the files are the same, so I am not sure what happened here.
THANK YOU SO MUCH for the help on fixing this problem!
/mrg
On Mar 2, 2012, at 13:32, Nathan Kinder wrote:
On 03/02/2012 06:32 AM, Michael R. Gettes wrote:
On Mar 2, 2012, at 9:21, Rich Megginson wrote:
On 03/01/2012 09:56 PM, Michael R. Gettes wrote:
I am in process of standing up a new directory service and will have to migrate many apps to the new service. Do you believe 1.2.10.2 is stable enough for production use? I would trust your assessment. I realize the caveats of any recommendation you might make.
It's hard to say - we have people using 1.2.10.2 in production on EL6 and Fedora - but none on EL5 that I'm aware of.
So, best to stick with 1.2.9.9 for production until we get some more feedback on 1.2.10.2
let me see how i can try it out… not sure given how we maintain things.
That being said, I was hoping you could try it out and see if it still has the problem.
Perhaps it is a schema problem?
grep -i changenumber /etc/dirsrv/slapd-INST/schema/* grep -i entryusn /etc/dirsrv/slapd-INST/schema/*
on 1.2.9.9
#grep -i changenumber * 02common.ldif:attributeTypes: ( 2.16.840.1.113730.3.1.5 NAME 'changeNumber' DESC 'Changelog attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 X-ORIGIN 'Changelog Internet Draft' ) 02common.ldif:objectClasses: ( 2.16.840.1.113730.3.2.1 NAME 'changeLogEntry' DESC 'LDAP changelog objectclass' SUP top MUST ( targetdn $ changeTime $ changenumber $ changeType ) MAY ( changes $ newrdn $ deleteoldrdn $ newsuperior ) X-ORIGIN 'Changelog Internet Draft' ) # grep -i entryusn * 01core389.ldif.rpmnew:attributeTypes: ( 2.16.840.1.113730.3.1.2096 NAME 'entryusn' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation X-ORIGIN 'Netscape' )
The problem here seems to be that it is a *.rpmnew file. This is causing your schema to not be updated from the upgrade. Did you customize your 01core389.ldif file at some point?
Do a diff between 01core389.ldif and 01core389.ldif.rpmnew.
on 1.2.8.3
# grep -i changenumber * 02common.ldif:attributeTypes: ( 2.16.840.1.113730.3.1.5 NAME 'changeNumber' DESC 'Changelog attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 X-ORIGIN 'Changelog Internet Draft' ) 02common.ldif:objectClasses: ( 2.16.840.1.113730.3.2.1 NAME 'changeLogEntry' DESC 'LDAP changelog objectclass' SUP top MUST ( targetdn $ changeTime $ changenumber $ changeType ) MAY ( changes $ newrdn $ deleteoldrdn $ newsuperior ) X-ORIGIN 'Changelog Internet Draft' ) # grep -i entryusn * #
yep, that's nothing on entryusn
/mrg
Thanks!
/mrg
On Mar 1, 2012, at 23:16, Rich Megginson wrote:
This code has changed with 389-ds-base 1.2.10.2 - any chance you could try that version, in epel-testing?
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
389-users@lists.fedoraproject.org
-
Michael Gettes -
Nathan Kinder -
Rich Megginson