Juan Asensio Sánchez wrote:Yes.
> 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?
>Please file a bug about the matching rules and the console. For now,
> 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.
the only way to do it is to shutdown the server, edit 99user.ldif, then
start up the server.
> <mailto:rmeggins@redhat.com>>
> > <mailto:rmeggins@redhat.com <mailto:rmeggins@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@redhat.com
> <mailto:rmeggins@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@lists.fedoraproject.org
> <mailto:389-users@lists.fedoraproject.org>
> > <mailto:389-users@lists.fedoraproject.org
> <mailto:389-users@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@lists.fedoraproject.org
> <mailto:389-users@lists.fedoraproject.org>
> > https://admin.fedoraproject.org/mailman/listinfo/389-users
>
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> <mailto: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