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 -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>).

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>

---

-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users

Juan Asensio Sánchez wrote:

Hi

The package 389-ds-console-1.2.3 is not available in EPEL Testing:

http://download.fedora.redhat.com/pub/epel/testing/5/i386/

Just version 1.2.0 in EPEL Stable:

http://download.fedora.redhat.com/pub/epel/5/i386/

Regards.

https://bugzilla.redhat.com/show_bug.cgi?id=588541

Unfortunately, I do not have commit rights to 389-ds-console in EPEL, so I cannot submit the new package, but I have 389-ds-console 1.2.3 for EPEL ready to go, and it is in Fedora (non-epel) testing currently.

Michael, how soon can we get a build of 389-ds-console 1.2.3 into epel testing?

2010/6/23 Rich Megginson <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>
> <mailto: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

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@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>
> <mailto: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

Juan Asensio Sánchez wrote:

And how will replication behave? Will this change be propagated to the rest of the servers, or will it be overriden with the definition that thare is now in the rest of the servers?

Hmm - ok - if you want it to replicate, then make the change using ldapmodify while the server is running. Just replace the current definition with your new one.

Can I change directly the 99user.ldif without restarting the server and then reload the schema using teh script for that?

Yes, but if you want it to work with replication, use ldapmodify instead.

Regards.

2010/6/25 Rich Megginson <rmeggins@redhat.com mailto:rmeggins@redhat.com>

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@redhat.com
<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>
>     <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>
>     <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>>
>     > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>
<mailto: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>>
>     >     <mailto: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>>
>     >
>    
<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>
>     <mailto: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>
>     <mailto: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
<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