Juan Asensio S?nchez wrote: > Hi again > > What will happen if I modify the schema, creating a new aattribute > without specifying any matching rule? Will the directory use the > default rules for for the attribute syntax? Yes. > > Anuyway, how can I change now the matching rules for the existing > attributes that gives that warning? In the console, when i edit the > attribute in the schema, i don't see any option to change the matching > rule. Please file a bug about the matching rules and the console. For now, the only way to do it is to shutdown the server, edit 99user.ldif, then start up the server. > > Regards and thanks in advance. > > > 2010/6/23 Rich Megginson <rmeggins at redhat.com > <mailto:rmeggins at redhat.com>> > > Juan Asensio S?nchez wrote: > > Hi > > > > I have upgraded our test server(from version 1.2.5, > > 389-ds-base-1.2.6-0.7.rc2.el5.i386 and > > 389-admin-1.1.11-0.5.rc1.el5.i386), and when running > > "setup-ds-admin.pl <http://setup-ds-admin.pl> > <http://setup-ds-admin.pl> -u", i get many messages > > like this (all about custom attributes): > > > > [22/Jun/2010:10:24:58 +0200] 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 [XXXXXXXX] > > > > Attribute is defined as this: > > > > ( 1.3.6.1.XXXXXXXXXXXXXXXX NAME 'XXXX' DESC 'XXXXXXX' EQUALITY > > caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} > X-ORIGIN > > 'user defined' ) > Where does this attribute come from? It's kind of strange that the > syntax is DirectoryString which is essentially any valid UTF-8 string, > but the matching rule is caseIgnoreIA5Match which is for comparison of > 7-bit ASCII strings. Why not caseIgnoreMatch? > > At any rate, the message is really just a warning. There's really no > way to figure out all possible combinations of syntaxes and matching > rules that may be in use. It was my hope that this message would > cause > these issues to be reported to the 389 team so that we could > address them. > > > > Although the messages, the script finishes fine: > > > > Registering the directory server instances with the configuration > > directory server . . . > > Beginning Admin Server reconfiguration . . . > > Registering admin server with the configuration directory server > . . . > > Updating adm.conf with information from configuration directory > server > > . . . > > Exiting . . . > > Log file is '/tmp/setupbXoREC.log' > > > > But then I try access to the console, and click on "Directory > Server", > > i get this error: > > > > "Failed to install a local copy of 389-ds-1.2.3.jar or one of its > > supporting files. Please ensure that the appropriate console package > > is installed on the Administration Server. 389-ds-1.2.3.jar not > found > > at https://XXXXXXXXXXXXXX:2000/";. > > > > Is the error about the attribute critical? Why is the client console > > requesting 1.2.3 version of the jars? > Because 389-ds-base now handles DN escaped values within other DNs > correctly, and requires 389-ds-1.2.3 (389-ds-console-1.2.3) which also > has support for DN escaped values in within DNs. 389-ds-console-1.2.3 > should be available from the testing repos. > > > > Regards. > > > > > > 2010/6/16 Rich Megginson <rmeggins at redhat.com > <mailto:rmeggins at redhat.com> > > <mailto:rmeggins at redhat.com <mailto:rmeggins at redhat.com>>> > > > > The 389 team is pleased to announce the availability of Release > > Candidate 1 of version 1.2.6. This release a couple of bug > fixes. > > > > ***We need your help! Please help us test this software.*** > It is a > > release candidate, so it may have a few glitches, but it has > been > > tested > > for regressions and for new feature bugs. The Fedora system > > strongly encourages packages to be in Testing until verified and > > pushed > > to Stable. If we don't get any feedback while the packages > are in > > Testing, the packages will remain in limbo, or get pushed to > Stable. > > > > The more testing we get, the faster we can release these > packages to > > Stable. See the Release Notes for information about how to > provide > > testing feedback (or just send an email to > > 389-users at lists.fedoraproject.org > <mailto:389-users at lists.fedoraproject.org> > > <mailto:389-users at lists.fedoraproject.org > <mailto:389-users at lists.fedoraproject.org>>). > > > > The packages that need testing are: > > * 389-ds-base-1.2.6.rc1 - 389-ds-base > > * 389-admin-1.1.11.rc1 - 389-admin > > > > There are some new console/java packages too, and there is a new > > version > > of the 389-ds "meta" package - 1.2.1 > > > > * Release Notes - http://port389.org/wiki/Release_Notes > > * Install_Guide - http://port389.org/wiki/Install_Guide > > * Download - http://port389.org/wiki/Download > > > > === Bugs Fixed === > > This release contains a couple of bug fixes. The complete > list of > > bugs > > fixed is found at the link below. Note that bugs marked as > MODIFIED > > have been fixed but are still in testing. > > * Tracking bug for 1.2.6 release - > > > https://bugzilla.redhat.com/showdependencytree.cgi?id=543590&hide_resolved=0 > <https://bugzilla.redhat.com/showdependencytree.cgi?id=543590&hide_resolved=0> > > > <https://bugzilla.redhat.com/showdependencytree.cgi?id=543590&hide_resolved=0 > <https://bugzilla.redhat.com/showdependencytree.cgi?id=543590&hide_resolved=0>> > > > > > ------------------------------------------------------------------------ > > > > -- > > 389 users mailing list > > 389-users at lists.fedoraproject.org > <mailto:389-users at lists.fedoraproject.org> > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > -- > 389 users mailing list > 389-users at lists.fedoraproject.org > <mailto:389-users at lists.fedoraproject.org> > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > ------------------------------------------------------------------------ > > -- > 389 users mailing list > 389-users at lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users
