<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 02/09/2015 12:13 PM, Chris Mohler
wrote:<br>
</div>
<blockquote cite="mid:54D906E7.2080003@oberlin.edu" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 02/09/2015 11:19 AM, Rich
Megginson wrote:<br>
</div>
<blockquote cite="mid:54D8DE08.2010002@redhat.com" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 02/09/2015 08:26 AM, Chris
Mohler wrote:<br>
</div>
<blockquote cite="mid:54D8D19E.1080703@oberlin.edu" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 02/09/2015 09:48 AM, Rich
Megginson wrote:<br>
</div>
<blockquote cite="mid:54D8C8B5.2080102@redhat.com" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 02/08/2015 08:23 PM, Chris
Mohler wrote:<br>
</div>
<blockquote
cite="mid:CAOBT0Fkj+96YbQk=y2T0bxGE1Fd5Jtkrk55rh9qK0LTLRSAkoQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>Thanks for the reply and the link Rich!<br>
<br>
</div>
<div>dbmon.sh is a handy tool indeed. <br>
</div>
<div><br>
</div>
I read the instructions and upped my entry cache size
to 2gb because I have enough ram. <br>
</div>
Everything went well until <br>
<pre><code>service dirsrv restart
</code></pre>
<pre><code>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/<a moz-do-not-send="true" href="http://1.2.11.15">1.2.11.15</a> 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
</code></pre>
<pre><code>Oddly enough everything appears to be working. Are these messages safe to ignore?
</code></pre>
</div>
</blockquote>
<br>
This is definitely not related to the cache size.<br>
<br>
<code>Not sure what the problem is - looks like something
has done an override of the standard schema definition of
dc. <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://tools.ietf.org/html/rfc4519">http://tools.ietf.org/html/rfc4519</a>
defines it with syntax 1.3.6.1.4.1.1466.115.121.1.26.<br>
<br>
rpm -q 389-ds-base<br>
<br>
find /etc/dirsrv -name \*.ldif -exec grep
0.9.2342.19200300.100.1.25 {} /dev/null \;<br>
<br>
<br>
</code>
<blockquote
cite="mid:CAOBT0Fkj+96YbQk=y2T0bxGE1Fd5Jtkrk55rh9qK0LTLRSAkoQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<pre><code>Another run of dbmon.sh shows that my entry cache was increased.
</code><code></code></pre>
<pre><code>Thanks,
</code></pre>
<pre><code>-Chris
</code></pre>
<pre><code>
</code></pre>
<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sun, Feb 8, 2015 at 5:58 PM,
Rich Megginson <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:rmeggins@redhat.com" target="_blank">rmeggins@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>
<div class="h5">
<div>On 02/07/2015 11:25 AM, Chris Mohler
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<pre>Hi Everyone. I'm trying to troubleshoot some issues I'm having. I want to increase the entry cache size
</pre>
<pre>I'm trying to follow the directions here
</pre>
<pre>/usr/lib/mozldap/ldapmodify -D "cn=directory manager" -w secret -p 389
dn: cn=<em><code>database_name</code></em>, cn=ldbm database, cn=plugins, cn=config
changetype: modify
replace: nsslapd-cachememsize
nsslapd-cachememsize: 20971520
</pre>
<pre>Is this the correct way to do this? How do I find out what the "
cn=<em><code>database_name" is supposed to be?
</code></em></pre>
</div>
</blockquote>
<br>
</div>
</div>
<code><em>see </em></code><a
moz-do-not-send="true"
href="https://github.com/richm/scripts/wiki/dbmon.sh"
target="_blank">https://github.com/richm/scripts/wiki/dbmon.sh</a>
- the script will tell you what the names of your
databases are.<br>
<blockquote type="cite">
<div dir="ltr">
<pre><em><code>
</code></em></pre>
<pre><em><code>Thanks,
</code></em></pre>
<pre><em><code>-Chris
</code></em></pre>
</div>
<br>
<fieldset></fieldset>
<br>
</blockquote>
<br>
</div>
<br>
--<br>
Manage your subscription for the Freeipa-users
mailing list:<br>
<a moz-do-not-send="true"
href="https://www.redhat.com/mailman/listinfo/freeipa-users"
target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a><br>
Go To <a moz-do-not-send="true"
href="http://freeipa.org" target="_blank">http://freeipa.org</a>
for more info on the project<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
Thanks again Rich,<br>
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.<br>
<blockquote type="cite"><code>Not sure what the problem is -
looks like something has done an override of the standard
schema definition of dc. <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://tools.ietf.org/html/rfc4519">http://tools.ietf.org/html/rfc4519</a>
defines it with syntax 1.3.6.1.4.1.1466.115.121.1.26.</code></blockquote>
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.<br>
</blockquote>
<br>
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?<br>
<br>
<blockquote cite="mid:54D8D19E.1080703@oberlin.edu" type="cite">
<br>
<blockquote type="cite"><code>rpm -q 389-ds-base</code></blockquote>
<code><font face="sans-serif">389-ds-base-1.2.11.15-48.el6_6.x86_64</font><br>
<br>
</code>
<blockquote type="cite"><code>find /etc/dirsrv -name \*.ldif
-exec grep 0.9.2342.19200300.100.1.25 {} /dev/null \;</code><br>
</blockquote>
<code><br>
</code>/etc/dirsrv/slapd-PKI-IPA/schema.bak/00core.ldif:attributeTypes:
( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )<br>
/etc/dirsrv/slapd-PKI-IPA/schema/00core.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )<br>
/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'
)<br>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote cite="mid:54D8D19E.1080703@oberlin.edu" type="cite">
/etc/dirsrv/schema/00core.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )<br>
/etc/dirsrv/slapd-CS-OBERLIN-EDU/schema.bak/00core.ldif:attributeTypes:
( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )<br>
/etc/dirsrv/slapd-CS-OBERLIN-EDU/schema/00core.ldif:attributeTypes:
( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )<br>
<br>
Thanks again,<br>
-Chris<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<blockquote type="cite">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?</blockquote>
"what did you do?" Made me smile. <br>
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<br>
<br>
#Disable the compat plugin<br>
$ipa-compat-manage disable<br>
<br>
#Restart the dirservice<br>
$service dirsrv restart<br>
<br>
#Enable Migration<br>
$ipa config-mod --enable-migration=TRUE<br>
</blockquote>
<br>
Are you supposed to do --enable-migration=FALSE or
--disable-migration after migration is complete? Perhaps during
migration the schema is relaxed<br>
<br>
Can any IPA or DogTag developer comment about this schema issue?<br>
<br>
<blockquote cite="mid:54D906E7.2080003@oberlin.edu" type="cite"> <br>
#Run the migration script<br>
$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"
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="ldap://cs.oberlin.edu:389">ldap://cs.oberlin.edu:389</a><br>
<br>
#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.<br>
<code class="bash plain">$getent </code><code class="bash
functions">passwd</code> <code class="bash plain">| </code><code
class="bash functions">cut</code> <code class="bash plain">-d :
-f 1 > </code><code class="bash functions">passwd</code><br>
<br>
#And copy this passwd file, which now contains a list of every
user, to the IdM.<br>
#Then, run the following on the IdM to copy until compl$ cp passwd
missing<br>
$ touch present<br>
$ 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" <a moz-do-not-send="true"
class="moz-txt-link-freetext" href="ldap://cs.oberlin.edu:389">ldap://cs.oberlin.edu:389</a><br>
$ 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" <a moz-do-not-send="true"
class="moz-txt-link-freetext" href="ldap://cs.oberlin.edu:389">ldap://cs.oberlin.edu:389</a>;
E=$?; doneete:<br>
<br>
<code class="bash plain">Groups were processed a similar way.<br>
<br>
getent group > </code><code class="bash functions">groups<br>
<br>
</code><code class="bash keyword">while</code> <code class="bash
functions">read</code> <code class="bash plain">line; </code><code
class="bash keyword">do</code> <code class="bash plain">ipa
group-add-member `</code><code class="bash functions">echo</code>
<code class="bash plain">$line | </code><code class="bash
functions">cut</code> <code class="bash plain">-d : -f 1` --</code><code
class="bash functions">users</code><code class="bash plain">=`</code><code
class="bash functions">echo</code> <code class="bash plain">$line
| </code><code class="bash functions">cut</code> <code
class="bash plain">-d : -f 4`; </code><code class="bash
keyword">done</code> <code class="bash plain">< </code><code
class="bash functions">groups<br>
<br>
Of course I am not the sys adm that did the migration I am
working off some old notes.<br>
<br>
</code>Recently I tried to add a replica and the replica install
asked me to run the following on the master. Which I did. <br>
copy-schema-to-ca.py<br>
#! /usr/bin/python2<br>
<br>
"""Copy the IPA schema to the CA directory server instance<br>
<br>
You need to run this script to prepare a 2.2 or 3.0 IPA master for<br>
installation of a 3.1 replica.<br>
<br>
Once a 3.1 replica is in the domain, every older CA master will
emit schema<br>
replication errors until this script is run on it.<br>
<br>
"""<br>
<br>
import os<br>
import sys<br>
import pwd<br>
import shutil<br>
<br>
from ipapython import ipautil, dogtag<br>
from ipapython.ipa_log_manager import root_logger,
standard_logging_setup<br>
from ipaserver.install.dsinstance import DS_USER, schema_dirname<br>
from ipaserver.install.cainstance import PKI_USER<br>
from ipalib import api<br>
<br>
try:<br>
from ipaplatform import services<br>
except ImportError:<br>
from ipapython import services # pylint:
disable=no-name-in-module<br>
<br>
SERVERID = "PKI-IPA"<br>
SCHEMA_FILENAMES = (<br>
"60kerberos.ldif",<br>
"60samba.ldif",<br>
"60ipaconfig.ldif",<br>
"60basev2.ldif",<br>
"60basev3.ldif",<br>
"60ipadns.ldif",<br>
"61kerberos-ipav3.ldif",<br>
"65ipacertstore.ldif",<br>
"65ipasudo.ldif",<br>
"70ipaotp.ldif",<br>
"05rfc2247.ldif",<br>
</blockquote>
<br>
This is the file. I guess DogTag needs the relaxed schema
definition for some reason?<br>
<br>
<blockquote cite="mid:54D906E7.2080003@oberlin.edu" type="cite"> )<br>
<br>
<br>
def add_ca_schema():<br>
"""Copy IPA schema files into the CA DS instance<br>
"""<br>
pki_pent = pwd.getpwnam(PKI_USER)<br>
ds_pent = pwd.getpwnam(DS_USER)<br>
for schema_fname in SCHEMA_FILENAMES:<br>
source_fname = os.path.join(ipautil.SHARE_DIR,
schema_fname)<br>
target_fname = os.path.join(schema_dirname(SERVERID),
schema_fname)<br>
if not os.path.exists(source_fname):<br>
root_logger.debug('File does not exist: %s',
source_fname)<br>
continue<br>
if os.path.exists(target_fname):<br>
root_logger.info(<br>
'Target exists, not overwriting: %s',
target_fname)<br>
continue<br>
try:<br>
shutil.copyfile(source_fname, target_fname)<br>
except IOError, e:<br>
root_logger.warning('Could not install %s: %s',
target_fname, e)<br>
else:<br>
root_logger.info('Installed %s', target_fname)<br>
os.chmod(target_fname, 0440) # read access for dirsrv
user/group<br>
os.chown(target_fname, pki_pent.pw_uid, ds_pent.pw_gid)<br>
<br>
<br>
def restart_pki_ds():<br>
"""Restart the CA DS instance to pick up schema changes<br>
"""<br>
root_logger.info('Restarting CA DS')<br>
services.service('dirsrv').restart(SERVERID)<br>
<br>
<br>
def main():<br>
if os.getegid() != 0:<br>
sys.exit("Must be root to run this script")<br>
standard_logging_setup(verbose=True)<br>
<br>
# In 3.0, restarting needs access to api.env<br>
(options, argv) =
api.bootstrap_with_global_options(context='server')<br>
<br>
add_ca_schema()<br>
restart_pki_ds()<br>
<br>
root_logger.info('Schema updated successfully')<br>
<br>
<br>
main()<br>
<br>
<br>
<blockquote type="cite">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.<br>
</blockquote>
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? <br>
<br>
-Chris<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
</body>
</html>