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

#Run the migration script
$ipa migrate-ds --bind-dn="cn=linux,ou=LDAPauth,dc=cs,dc=oberlin,dc=edu" --base-dn="dc=cs,dc=oberlin,dc=edu" --group-container=ou=Group --user-container=ou=People --user-objectclass=\* --user-ignore-objectclass=inetLocalMailRecipient --user-ignore-attribute="mailHost" --user-ignore-attribute="mailRoutingAddress" --user-ignore-objectclass=organizationalPerson --user-ignore-objectclass=inetOrgPerson --user-ignore-attribute="givenName" --user-ignore-attribute="roomNumber" --user-ignore-attribute="displayName" --user-ignore-attribute="mail" --user-ignore-attribute="homePhone" ldap://cs.oberlin.edu:389

#You may find that the script exits after a while with an error stating that the LDAP server is down. This seems #to be an OpenLdap side thing. To work around this, do the following.
|$getent ||passwd| || ||cut| |-d : -f 1 > ||passwd|

#And copy this passwd file, which now contains a list of every user, to the IdM.
#Then, run the following on the IdM to copy until compl$ cp passwd missing
$ touch present
$ ipa migrate-ds --bind-dn="cn=linux,ou=LDAPauth,dc=cs,dc=oberlin,dc=edu" --base-dn="dc=cs,dc=oberlin,dc=edu" --group-container=ou=Group --user-container=ou=People --user-objectclass=\* --exclude-users=`cat present | tr '\n' ','` --user-ignore-objectclass=inetLocalMailRecipient --user-ignore-attribute="mailHost" --user-ignore-attribute="mailRoutingAddress" --user-ignore-objectclass=organizationalPerson --user-ignore-objectclass=inetOrgPerson --user-ignore-attribute="givenName" --user-ignore-attribute="roomNumber" --user-ignore-attribute="displayName" --user-ignore-attribute="mail" ldap://cs.oberlin.edu:389 $ E=1; while [ $E -gt "0" ]; do for i in `cat missing`; do ipa user-find --login=$i; if [ $? = "0" ]; then echo $i >> present; else echo $i >> missing1; fi; done; mv missing1 missing; ipa migrate-ds --bind-dn="cn=linux,ou=LDAPauth,dc=cs,dc=oberlin,dc=edu" --base-dn="dc=cs,dc=oberlin,dc=edu" --group-container=ou=Group --user-container=ou=People --user-objectclass=\* --exclude-users=`cat present | tr '\n' ','` --user-ignore-objectclass=inetLocalMailRecipient --user-ignore-attribute="mailHost" --user-ignore-attribute="mailRoutingAddress" --user-ignore-objectclass=organizationalPerson --user-ignore-objectclass=inetOrgPerson --user-ignore-attribute="homePhone" --user-ignore-attribute="givenName" --user-ignore-attribute="roomNumber" --user-ignore-attribute="displayName" --user-ignore-attribute="mail" ldap://cs.oberlin.edu:389; E=$?; doneete:

|Groups were processed a similar way.

getent group > ||groups

||while| |read| |line; ||do| |ipa group-add-member `||echo| |$line | ||cut| |-d : -f 1` --||users||=`||echo| |$line | ||cut| |-d : -f 4`; ||done| |< ||groups

Of course I am not the sys adm that did the migration I am working off some old notes.

|Recently I tried to add a replica and the replica install asked me to run the following on the master. Which I did.
copy-schema-to-ca.py
#! /usr/bin/python2

"""Copy the IPA schema to the CA directory server instance

You need to run this script to prepare a 2.2 or 3.0 IPA master for
installation of a 3.1 replica.

Once a 3.1 replica is in the domain, every older CA master will emit schema
replication errors until this script is run on it.

"""

import os
import sys
import pwd
import shutil

from ipapython import ipautil, dogtag
from ipapython.ipa_log_manager import root_logger, standard_logging_setup
from ipaserver.install.dsinstance import DS_USER, schema_dirname
from ipaserver.install.cainstance import PKI_USER
from ipalib import api

try:
    from ipaplatform import services
except ImportError:
    from ipapython import services  # pylint: disable=no-name-in-module

SERVERID = "PKI-IPA"
SCHEMA_FILENAMES = (
    "60kerberos.ldif",
    "60samba.ldif",
    "60ipaconfig.ldif",
    "60basev2.ldif",
    "60basev3.ldif",
    "60ipadns.ldif",
    "61kerberos-ipav3.ldif",
    "65ipacertstore.ldif",
    "65ipasudo.ldif",
    "70ipaotp.ldif",
    "05rfc2247.ldif",
)


def add_ca_schema():
    """Copy IPA schema files into the CA DS instance
    """
    pki_pent = pwd.getpwnam(PKI_USER)
    ds_pent = pwd.getpwnam(DS_USER)
    for schema_fname in SCHEMA_FILENAMES:
        source_fname = os.path.join(ipautil.SHARE_DIR, schema_fname)
        target_fname = os.path.join(schema_dirname(SERVERID), schema_fname)
        if not os.path.exists(source_fname):
            root_logger.debug('File does not exist: %s', source_fname)
            continue
        if os.path.exists(target_fname):
            root_logger.info(
                'Target exists, not overwriting: %s', target_fname)
            continue
        try:
            shutil.copyfile(source_fname, target_fname)
        except IOError, e:
root_logger.warning('Could not install %s: %s', target_fname, e)
        else:
            root_logger.info('Installed %s', target_fname)
        os.chmod(target_fname, 0440)    # read access for dirsrv user/group
        os.chown(target_fname, pki_pent.pw_uid, ds_pent.pw_gid)


def restart_pki_ds():
    """Restart the CA DS instance to pick up schema changes
    """
    root_logger.info('Restarting CA DS')
    services.service('dirsrv').restart(SERVERID)


def main():
    if os.getegid() != 0:
        sys.exit("Must be root to run this script")
    standard_logging_setup(verbose=True)

    # In 3.0, restarting needs access to api.env
    (options, argv) = api.bootstrap_with_global_options(context='server')

    add_ca_schema()
    restart_pki_ds()

    root_logger.info('Schema updated successfully')


main()


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.
I am only using FreeIPA to authenticate linux clients for user login via SSSD. Using Pam. I don't have any applications that would require 8-bit or Unicode characters. Is it possible to return to a standard definition?

-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

Reply via email to