Rich Megginson wrote: > On 02/09/2015 12:13 PM, Chris Mohler wrote: >> On 02/09/2015 11:19 AM, Rich Megginson wrote: >>> On 02/09/2015 08:26 AM, Chris Mohler wrote: >>>> On 02/09/2015 09:48 AM, Rich Megginson wrote: >>>>> On 02/08/2015 08:23 PM, Chris Mohler wrote: >>>>>> Thanks for the reply and the link Rich! >>>>>> >>>>>> dbmon.sh is a handy tool indeed. >>>>>> >>>>>> I read the instructions and upped my entry cache size to 2gb >>>>>> because I have enough ram. >>>>>> Everything went well until >>>>>> |service dirsrv restart >>>>>> >>>>>> | >>>>>> |I Got the following errors: >>>>>> [06/Feb/2015:10:07:35 -0500] - slapd stopped. >>>>>> [06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the EQUALITY >>>>>> matching rule [caseIgnoreIA5Match] is not compatible with the syntax >>>>>> [1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc] >>>>>> [06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the SUBSTR >>>>>> matching rule [caseIgnoreIA5SubstringsMatch] is not compatible with the >>>>>> syntax [1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc] >>>>>> [06/Feb/2015:10:07:37 -0500] - 389-Directory/1.2.11.15 >>>>>> <http://1.2.11.15> B2014.314.1342 starting up >>>>>> [06/Feb/2015:10:07:37 -0500] - slapd started. Listening on All >>>>>> Interfaces port 7389 for LDAP requests >>>>>> [06/Feb/2015:10:07:37 -0500] - Listening on All Interfaces port 7390 for >>>>>> LDAPS requests >>>>>> >>>>>> | >>>>>> |Oddly enough everything appears to be working. Are these messages safe >>>>>> to ignore? >>>>>> | >>>>> >>>>> This is definitely not related to the cache size. >>>>> >>>>> |Not sure what the problem is - looks like something has done an >>>>> override of the standard schema definition of dc. >>>>> http://tools.ietf.org/html/rfc4519 defines it with syntax >>>>> 1.3.6.1.4.1.1466.115.121.1.26. >>>>> >>>>> rpm -q 389-ds-base >>>>> >>>>> find /etc/dirsrv -name \*.ldif -exec grep >>>>> 0.9.2342.19200300.100.1.25 {} /dev/null \; >>>>> >>>>> >>>>> | >>>>>> |Another run of dbmon.sh shows that my entry cache was increased. >>>>>> >>>>>> ||| >>>>>> |Thanks, >>>>>> | >>>>>> |-Chris >>>>>> | >>>>>> | >>>>>> | >>>>>> >>>>>> >>>>>> On Sun, Feb 8, 2015 at 5:58 PM, Rich Megginson >>>>>> <rmegg...@redhat.com <mailto:rmegg...@redhat.com>> wrote: >>>>>> >>>>>> On 02/07/2015 11:25 AM, Chris Mohler wrote: >>>>>>> Hi Everyone. I'm trying to troubleshoot some issues I'm having. I >>>>>>> want to increase the entry cache size >>>>>>> I'm trying to follow the directions here >>>>>>> /usr/lib/mozldap/ldapmodify -D "cn=directory manager" -w secret -p >>>>>>> 389 >>>>>>> >>>>>>> dn: cn=/|database_name|/, cn=ldbm database, cn=plugins, cn=config >>>>>>> changetype: modify >>>>>>> replace: nsslapd-cachememsize >>>>>>> nsslapd-cachememsize: 20971520 >>>>>>> >>>>>>> Is this the correct way to do this? How do I find out what the " >>>>>>> cn=/|database_name" is supposed to be? >>>>>>> |/ >>>>>> >>>>>> |/see /|https://github.com/richm/scripts/wiki/dbmon.sh - the >>>>>> script will tell you what the names of your databases are. >>>>>>> /| >>>>>>> |/ >>>>>>> /|Thanks, >>>>>>> |/ >>>>>>> /|-Chris >>>>>>> |/ >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Manage your subscription for the Freeipa-users mailing list: >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>> Go To http://freeipa.org for more info on the project >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> Thanks again Rich, >>>> I have been having an abundance of issues with my FreeIPA server >>>> lately. I'm not surprised that error is not related. I was not sure >>>> as It has not surfaced in my logs before I changed the entry cache >>>> size. Possibly this will be the clue to get me on the road to recovery. >>>> >>>>> |Not sure what the problem is - looks like something has done an >>>>> override of the standard schema definition of dc. >>>>> http://tools.ietf.org/html/rfc4519 defines it with syntax >>>>> 1.3.6.1.4.1.1466.115.121.1.26.| >>>> I migrated from OpenLdap about a year ago. So my install is a >>>> migration. I also recently tried to add a replica. Which prompted me >>>> to update the schema on the master before it would replicate. >>> >>> What exactly did you do? You should not have migrated the standard >>> schema from openldap. Did you have to override the definition of >>> 'dc' for some reason? >>> >>>> >>>>> |rpm -q 389-ds-base| >>>> |389-ds-base-1.2.11.15-48.el6_6.x86_64 >>>> >>>> | >>>>> |find /etc/dirsrv -name \*.ldif -exec grep >>>>> 0.9.2342.19200300.100.1.25 {} /dev/null \;| >>>> | >>>> |/etc/dirsrv/slapd-PKI-IPA/schema.bak/00core.ldif:attributeTypes: ( >>>> 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) >>>> /etc/dirsrv/slapd-PKI-IPA/schema/00core.ldif:attributeTypes: ( >>>> 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) >>>> /etc/dirsrv/slapd-PKI-IPA/schema/05rfc2247.ldif:attributeTypes: ( >>>> 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) DESC >>>> 'Standard LDAP attribute type' EQUALITY caseIgnoreIA5Match SUBSTR >>>> caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 >>>> SINGLE-VALUE X-ORIGIN 'RFC 2247' ) >>> >>> This definition is wrong. Both RFC 2247 and RFC 4519 define 'dc' as >>> syntax 1.3.6.1.4.1.1466.115.121.1.26 - that is, 7-bit ASCII only. Do >>> you have some application that requires 8-bit or unicode characters >>> (syntax 1.3.6.1.4.1.1466.115.121.1.15) in domain component names? If >>> it is absolutely required that dc accepts unicode, then you'll have >>> to change the matching rules as well, to be unicode compatible: >>> EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch - that is, >>> just get rid of the IA5. >>> >>> >>>> /etc/dirsrv/schema/00core.ldif:attributeTypes: ( >>>> 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) >>>> /etc/dirsrv/slapd-CS-OBERLIN-EDU/schema.bak/00core.ldif:attributeTypes: >>>> ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) >>>> /etc/dirsrv/slapd-CS-OBERLIN-EDU/schema/00core.ldif:attributeTypes: >>>> ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) >>>> >>>> Thanks again, >>>> -Chris >>>> >>>> >>>> >>> >>> >>> >>> What exactly did you do? You should not have migrated the standard >>> schema from openldap. Did you have to override the definition of >>> 'dc' for some reason? >> "what did you do?" Made me smile. >> I dug up my notes from the install and migrate from openldap. After >> ipa-server-install was successful I had a messy migration. I did the >> following >> >> #Disable the compat plugin >> $ipa-compat-manage disable >> >> #Restart the dirservice >> $service dirsrv restart >> >> #Enable Migration >> $ipa config-mod --enable-migration=TRUE > > Are you supposed to do --enable-migration=FALSE or --disable-migration > after migration is complete? Perhaps during migration the schema is relaxed
Migration mode just relaxes the pre-hashed password requirement and is a trigger to SSSD to try to migrate the password. We recommend to disable the compat plugin prior to migration to avoid slowing things down considerably. It's ok to re-enable it post-migration. I don't know where the schema errors came from but AFAIR we don't touch the schema for dogtag. rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
