[389-users] 389-users Digest, Vol 86, Issue 9
Spolti
filippespolti at gmail.com
Wed Jul 11 12:05:52 UTC 2012
Today's Topics:
1. setting ACI to countryCode attribute (Elisseev V.)
2. Re: setting ACI to countryCode attribute (Rich Megginson)
3. Re: setting ACI to countryCode attribute (Rob Crittenden)
4. Re: setting ACI to countryCode attribute (Elisseev V.)
5. Re: Question regarding Combining ObjectClasses to add
attributes (Anderson, Cary at CIO)
6. Re: Question regarding Combining ObjectClasses to add
attributes (Rich Megginson)
7. Password policy questions (Greg Kuchyt)
8. Re: Password policy questions (Rich Megginson)
9. Re: Question regarding Combining ObjectClasses to add
attributes (Morris, Patrick)
10. Fedora 17 64 bits doesn't shutdown. (Spolti)
Good morning guys,
Yesterday i upgrade my fedora 16 to fedora 17, since then i need turn my pc
off by pressing the shutdown button only.
Anyone had this problem to?
Regards!.
2012/7/10 <389-users-request at lists.fedoraproject.org>
> Send 389-users mailing list submissions to
> 389-users at lists.fedoraproject.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://admin.fedoraproject.org/mailman/listinfo/389-users
> or, via email, send a message with subject or body 'help' to
> 389-users-request at lists.fedoraproject.org
>
> You can reach the person managing the list at
> 389-users-owner at lists.fedoraproject.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of 389-users digest..."
>
>
> Today's Topics:
>
> 1. setting ACI to countryCode attribute (Elisseev V.)
> 2. Re: setting ACI to countryCode attribute (Rich Megginson)
> 3. Re: setting ACI to countryCode attribute (Rob Crittenden)
> 4. Re: setting ACI to countryCode attribute (Elisseev V.)
> 5. Re: Question regarding Combining ObjectClasses to add
> attributes (Anderson, Cary at CIO)
> 6. Re: Question regarding Combining ObjectClasses to add
> attributes (Rich Megginson)
> 7. Password policy questions (Greg Kuchyt)
> 8. Re: Password policy questions (Rich Megginson)
> 9. Re: Question regarding Combining ObjectClasses to add
> attributes (Morris, Patrick)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 10 Jul 2012 16:28:37 +0200
> From: "Elisseev V." <vovan at vovan.nl>
> To: 389-users at lists.fedoraproject.org
> Subject: [389-users] setting ACI to countryCode attribute
> Message-ID: <1341930517.3558.58.camel at laptop>
> Content-Type: text/plain; charset="UTF-8"
>
> Hello,
>
> I'm trying to define ACI for "countryCode" attribute and getting an
> error "Attribute is not defined in the schema". However, i can create an
> entry with this attribute. Could somebody clarify what the problem is.
>
> Thank you in advance,
> Vlad.
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 10 Jul 2012 08:37:48 -0600
> From: Rich Megginson <rmeggins at redhat.com>
> To: "General discussion list for the 389 Directory server project."
> <389-users at lists.fedoraproject.org>
> Subject: Re: [389-users] setting ACI to countryCode attribute
> Message-ID: <4FFC3E3C.8090106 at redhat.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 07/10/2012 08:28 AM, Elisseev V. wrote:
> > Hello,
> >
> > I'm trying to define ACI for "countryCode" attribute and getting an
> > error "Attribute is not defined in the schema". However, i can create an
> > entry with this attribute. Could somebody clarify what the problem is.
> There is no countryCode attribute defined in the 389 schema. Are you
> perhaps creating an entry with objectclass: extensibleObject?
> >
> > Thank you in advance,
> > Vlad.
> >
> > --
> > 389 users mailing list
> > 389-users at lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 10 Jul 2012 10:38:46 -0400
> From: Rob Crittenden <rcritten at redhat.com>
> To: "General discussion list for the 389 Directory server project."
> <389-users at lists.fedoraproject.org>
> Subject: Re: [389-users] setting ACI to countryCode attribute
> Message-ID: <4FFC3E76.6050205 at redhat.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Elisseev V. wrote:
> > Hello,
> >
> > I'm trying to define ACI for "countryCode" attribute and getting an
> > error "Attribute is not defined in the schema". However, i can create an
> > entry with this attribute. Could somebody clarify what the problem is.
>
> It would help to see the aci you are trying to add.
>
> rob
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 10 Jul 2012 16:48:43 +0200
> From: "Elisseev V." <vovan at vovan.nl>
> To: Rich Megginson <rmeggins at redhat.com>
> Cc: "General discussion list for the 389 Directory server project."
> <389-users at lists.fedoraproject.org>
> Subject: Re: [389-users] setting ACI to countryCode attribute
> Message-ID: <1341931723.3558.60.camel at laptop>
> Content-Type: text/plain; charset="UTF-8"
>
> That's true... one of the values in the objectclass is extensibleObject.
>
> On Tue, 2012-07-10 at 08:37 -0600, Rich Megginson wrote:
> > On 07/10/2012 08:28 AM, Elisseev V. wrote:
> > > Hello,
> > >
> > > I'm trying to define ACI for "countryCode" attribute and getting an
> > > error "Attribute is not defined in the schema". However, i can create
> an
> > > entry with this attribute. Could somebody clarify what the problem is.
> > There is no countryCode attribute defined in the 389 schema. Are you
> > perhaps creating an entry with objectclass: extensibleObject?
> > >
> > > Thank you in advance,
> > > Vlad.
> > >
> > > --
> > > 389 users mailing list
> > > 389-users at lists.fedoraproject.org
> > > https://admin.fedoraproject.org/mailman/listinfo/389-users
> >
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 10 Jul 2012 08:01:01 -0700
> From: "Anderson, Cary at CIO" <Cary.Anderson at State.ca.gov>
> To: 'Rich Megginson' <rmeggins at redhat.com>, 'General discussion list
> for the 389 Directory server project.'
> <389-users at lists.fedoraproject.org>
> Subject: Re: [389-users] Question regarding Combining ObjectClasses to
> add attributes
> Message-ID:
> <
> 8E433F62879B78449F9FF77C24ED7535985D40221C at MDTSSWECCR14.rf01.itservices.ca.gov
> >
>
> Content-Type: text/plain; charset="utf-8"
>
> Thanks for the quick response.
>
>
>
> The RHN knowledgebase article I found was titled: "How to use "host"
> attribute to limit ldap users can be accessed by specified host?" kb# 65838
>
> https://access.redhat.com/knowledge/solutions/65838
>
>
>
> From: Rich Megginson [mailto:rmeggins at redhat.com]
> Sent: Monday, July 09, 2012 9:14 AM
> To: General discussion list for the 389 Directory server project.
> Cc: Anderson, Cary at CIO
> Subject: Re: [389-users] Question regarding Combining ObjectClasses to add
> attributes
>
> On 07/09/2012 09:44 AM, Anderson, Cary at CIO wrote:
>
> I have recently started working with the Director Server, and I have read
> the documents for both 389 and RHDS, but I am having some difficulties
> regarding ObjectClass types, and combining them in order to extend the
> available attributes for an object. The documents indicate that you can
> only have one Structural ObjectClass and multiple Aux. ObjectClasses, and
> I'm a bit hazy on the rules for Abstract ObjectClasses.
>
> If I take the example of needing to add the "host" attribute to a user
> object. A RHN knowledgebase article indicates to add the "hostobject"
> ObjectClass rather than the "Account" ObjectClass.
>
> Can you provide a link to this kbase article?
>
>
>
> My assumption was that "hostobject" was an Aux. ObjectClass, and that
> "Account" was Structural, but when I look at the two ObjectClasses via the
> administrative GUI, they both have "Top" listed as the parent ObjectClass.
> So I'm not certain why one is appropriate and the other is not.
> It would appear the console does not tell you if the objectclass is
> structural, auxiliary, or abstract. You cannot tell by just the
> inheritance - by default, all objectclasses have "top" as the superior
> unless otherwise specified.
>
> This is the official LDAPv3 description -
> http://www.ietf.org/rfc/rfc4512.txt
>
> An entry may have only one STRUCTURAL objectclass, and multiple AUXILIARY
> objectclasses. Chances are you will want to use AUXILIARY objectclasses
> for your extra attributes (like posixAccount) and just use one of the
> pre-defined objectclasses (like inetOrgPerson) as your STRUCTURAL
> objectclass.
>
>
>
> Moving forward I want to be able to combine ObjectClasses to extend
> available objects without introducing data integrity issues in my ldap
> directory. I am looking for some clarification of rules regarding
> structural objectclasses,
> See rfc4512
>
>
> and if there is an easy way via the admin gui to tell the difference
> between structural, auxillary, and abstract objectclasses.
> No. You'll have to search cn=schema to check:
> ldapsearch -xLLL -s base -b "cn=schema" "objectclass=*" objectclasses |
> perl -p0e 's/\n //g' | grep AUXILIARY
>
> Note that ldapsearch wraps the output, so you'll have to use perl (or sed)
> to unwrap - see http://richmegginson.livejournal.com/18726.html
>
>
> Also will the directory do some sort of intregrity checking if you attempt
> to combine improper objectclasses either via commandline or the admin gui?
> Yes, although by default 389 will allow an entry to have multiple
> structural objectclasses, but that will change in a future release, so
> don't rely on that behavior.
>
>
>
>
> Thanks
>
>
> Cary Anderson
> 916.464.5108
> Linux Support | Engineering Dept.
>
>
>
>
>
> --
>
> 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
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.fedoraproject.org/pipermail/389-users/attachments/20120710/7ff4c671/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 6
> Date: Tue, 10 Jul 2012 09:45:40 -0600
> From: Rich Megginson <rmeggins at redhat.com>
> To: "Anderson, Cary at CIO" <Cary.Anderson at State.ca.gov>
> Cc: "'General discussion list for the 389 Directory server project.'"
> <389-users at lists.fedoraproject.org>
> Subject: Re: [389-users] Question regarding Combining ObjectClasses to
> add attributes
> Message-ID: <4FFC4E24.8060800 at redhat.com>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> On 07/10/2012 09:01 AM, Anderson, Cary at CIO wrote:
> >
> > Thanks for the quick response.
> >
> > The RHN knowledgebase article I found was titled: "How to use "host"
> > attribute to limit ldap users can be accessed by specified host?" kb#
> > 65838
> >
> > https://access.redhat.com/knowledge/solutions/65838
> >
>
> It doesn't say anything about an "Account" objectclass.
>
> See also http://port389.org/wiki/Howto:Posix
>
> > *From:*Rich Megginson [mailto:rmeggins at redhat.com]
> > *Sent:* Monday, July 09, 2012 9:14 AM
> > *To:* General discussion list for the 389 Directory server project.
> > *Cc:* Anderson, Cary at CIO
> > *Subject:* Re: [389-users] Question regarding Combining ObjectClasses
> > to add attributes
> >
> > On 07/09/2012 09:44 AM, Anderson, Cary at CIO wrote:
> >
> > I have recently started working with the Director Server, and I have
> > read the documents for both 389 and RHDS, but I am having some
> > difficulties regarding ObjectClass types, and combining them in order
> > to extend the available attributes for an object. The documents
> > indicate that you can only have one Structural ObjectClass and
> > multiple Aux. ObjectClasses, and I'm a bit hazy on the rules for
> > Abstract ObjectClasses.
> >
> > If I take the example of needing to add the "host" attribute to a user
> > object. A RHN knowledgebase article indicates to add the "hostobject"
> > ObjectClass rather than the "Account" ObjectClass.
> >
> >
> > Can you provide a link to this kbase article?
> >
> >
> > My assumption was that "hostobject" was an Aux. ObjectClass, and that
> > "Account" was Structural, but when I look at the two ObjectClasses via
> > the administrative GUI, they both have "Top" listed as the parent
> > ObjectClass. So I'm not certain why one is appropriate and the other
> > is not.
> >
> > It would appear the console does not tell you if the objectclass is
> > structural, auxiliary, or abstract. You cannot tell by just the
> > inheritance - by default, all objectclasses have "top" as the superior
> > unless otherwise specified.
> >
> > This is the official LDAPv3 description -
> > http://www.ietf.org/rfc/rfc4512.txt
> >
> > An entry may have only one STRUCTURAL objectclass, and multiple
> > AUXILIARY objectclasses. Chances are you will want to use AUXILIARY
> > objectclasses for your extra attributes (like posixAccount) and just
> > use one of the pre-defined objectclasses (like inetOrgPerson) as your
> > STRUCTURAL objectclass.
> >
> >
> > Moving forward I want to be able to combine ObjectClasses to extend
> > available objects without introducing data integrity issues in my ldap
> > directory. I am looking for some clarification of rules regarding
> > structural objectclasses,
> >
> > See rfc4512
> >
> > and if there is an easy way via the admin gui to tell the difference
> > between structural, auxillary, and abstract objectclasses.
> >
> > No. You'll have to search cn=schema to check:
> > ldapsearch -xLLL -s base -b "cn=schema" "objectclass=*" objectclasses
> > | perl -p0e 's/\n //g' | grep AUXILIARY
> >
> > Note that ldapsearch wraps the output, so you'll have to use perl (or
> > sed) to unwrap - see http://richmegginson.livejournal.com/18726.html
> >
> > Also will the directory do some sort of intregrity checking if you
> > attempt to combine improper objectclasses either via commandline or
> > the admin gui?
> >
> > Yes, although by default 389 will allow an entry to have multiple
> > structural objectclasses, but that will change in a future release, so
> > don't rely on that behavior.
> >
> > Thanks
> >
> > * Cary Anderson*
> >
> > **916.464.5108
> >
> > *Linux Support**|****Engineering Dept**.*
> >
> >
> >
> >
> > --
> > 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
> >
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.fedoraproject.org/pipermail/389-users/attachments/20120710/3f8bac7e/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 7
> Date: 10 Jul 2012 10:59:05 -0400
> From: "Greg Kuchyt" <kuchytgj at potsdam.edu>
> To: 389-users at lists.fedoraproject.org
> Subject: [389-users] Password policy questions
> Message-ID: <4FFC4339.3080303 at potsdam.edu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> First off, I'm sorry if I missed a document somewhere that covers this,
> but after some searching I failed to find such a source that explicitly
> spells this out. In order to verify my findings in testing, I had a
> couple questions about the userPassword attribute and its relationship
> to the password policy.
>
> Is it accurate that the 389DS password policy only comes into effect
> when the LDAPv3 password modify operation is used (i.e. via ldappasswd)?
> I noticed that setting a default password hashing algorithm does not
> affect my ability to use any type of hash or clear text in the
> userPassword attribute or bind.
>
> We have historically managed the userPassword field like it is any other
> field and are looking to switch the hash type we use to store passwords.
> I was wondering what exactly switching the default password algorithm
> "does". From my testing it appears that it does not affect the existing
> data or manual changes to it. This leads me to believe it only comes
> into play during the password modify extended operation.
>
> Thanks for any help, and again my apologies if this is covered somewhere
> and I failed to find it.
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 10 Jul 2012 11:33:06 -0600
> From: Rich Megginson <rmeggins at redhat.com>
> To: "General discussion list for the 389 Directory server project."
> <389-users at lists.fedoraproject.org>
> Subject: Re: [389-users] Password policy questions
> Message-ID: <4FFC6752.6060509 at redhat.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 07/10/2012 08:59 AM, Greg Kuchyt wrote:
> > First off, I'm sorry if I missed a document somewhere that covers
> > this, but after some searching I failed to find such a source that
> > explicitly spells this out. In order to verify my findings in testing,
> > I had a couple questions about the userPassword attribute and its
> > relationship to the password policy.
> >
> > Is it accurate that the 389DS password policy only comes into effect
> > when the LDAPv3 password modify operation is used (i.e. via ldappasswd)?
>
> or an ldap MODIFY operation of the userPassword attribute.
>
> > I noticed that setting a default password hashing algorithm does not
> > affect my ability to use any type of hash or clear text in the
> > userPassword attribute or bind.
> >
> > We have historically managed the userPassword field like it is any
> > other field and are looking to switch the hash type we use to store
> > passwords. I was wondering what exactly switching the default password
> > algorithm "does". From my testing it appears that it does not affect
> > the existing data or manual changes to it. This leads me to believe it
> > only comes into play during the password modify extended operation.
>
> or an ldap MODIFY operation of the userPassword attribute.
> >
> > Thanks for any help, and again my apologies if this is covered
> > somewhere and I failed to find it.
> There is some info here -
>
> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/User_Account_Management.html#User_Account_Management-Managing_the_Password_Policy
>
> What you really want to do is only send cleartext passwords to the
> directory server, use only LDAP MODIFY or the password extop to change
> it, and use only the LDAP BIND operation to authenticate to the
> directory server. This will allow the directory server to internally
> hash it for storage and comparison.
> > --
> > 389 users mailing list
> > 389-users at lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
> ------------------------------
>
> Message: 9
> Date: Wed, 11 Jul 2012 00:22:13 +0000
> From: "Morris, Patrick" <patrick.morris at hp.com>
> To: "389-users at lists.fedoraproject.org"
> <389-users at lists.fedoraproject.org>, "
> Cary.Anderson at State.ca.gov"
> <Cary.Anderson at State.ca.gov>
> Subject: Re: [389-users] Question regarding Combining ObjectClasses to
> add attributes
> Message-ID:
> <
> B70713EB4E55C84C963B37DE9E63011B50DD3F0F at G4W3223.americas.hpqcorp.net>
>
> Content-Type: text/plain; charset="utf-8"
>
> The second link you provided (at port 389.org) specifically mentions
> using the “account” objectclass. I don’t have access to RHN to read the
> first link, though.
>
>
>
> From: 389-users-bounces at lists.fedoraproject.org [mailto:
> 389-users-bounces at lists.fedoraproject.org] On Behalf Of Rich Megginson
> Sent: Tuesday, July 10, 2012 8:46 AM
> To: Anderson, Cary at CIO
> Cc: 'General discussion list for the 389 Directory server project.'
> Subject: Re: [389-users] Question regarding Combining ObjectClasses to add
> attributes
>
>
>
> On 07/10/2012 09:01 AM, Anderson, Cary at CIO wrote:
>
> Thanks for the quick response.
>
>
>
> The RHN knowledgebase article I found was titled: "How to use "host"
> attribute to limit ldap users can be accessed by specified host?" kb# 65838
>
> https://access.redhat.com/knowledge/solutions/65838
>
>
> It doesn't say anything about an "Account" objectclass.
>
> See also http://port389.org/wiki/Howto:Posix
>
>
>
>
>
>
>
>
>
>
> From: Rich Megginson [mailto:rmeggins at redhat.com]
> Sent: Monday, July 09, 2012 9:14 AM
> To: General discussion list for the 389 Directory server project.
> Cc: Anderson, Cary at CIO
> Subject: Re: [389-users] Question regarding Combining ObjectClasses to add
> attributes
>
>
>
> On 07/09/2012 09:44 AM, Anderson, Cary at CIO wrote:
>
> I have recently started working with the Director Server, and I have read
> the documents for both 389 and RHDS, but I am having some difficulties
> regarding ObjectClass types, and combining them in order to extend the
> available attributes for an object. The documents indicate that you can
> only have one Structural ObjectClass and multiple Aux. ObjectClasses, and
> I'm a bit hazy on the rules for Abstract ObjectClasses.
>
> If I take the example of needing to add the "host" attribute to a user
> object. A RHN knowledgebase article indicates to add the "hostobject"
> ObjectClass rather than the "Account" ObjectClass.
>
>
> Can you provide a link to this kbase article?
>
>
>
>
>
> My assumption was that "hostobject" was an Aux. ObjectClass, and that
> "Account" was Structural, but when I look at the two ObjectClasses via the
> administrative GUI, they both have "Top" listed as the parent ObjectClass.
> So I'm not certain why one is appropriate and the other is not.
>
> It would appear the console does not tell you if the objectclass is
> structural, auxiliary, or abstract. You cannot tell by just the
> inheritance - by default, all objectclasses have "top" as the superior
> unless otherwise specified.
>
> This is the official LDAPv3 description -
> http://www.ietf.org/rfc/rfc4512.txt
>
> An entry may have only one STRUCTURAL objectclass, and multiple AUXILIARY
> objectclasses. Chances are you will want to use AUXILIARY objectclasses
> for your extra attributes (like posixAccount) and just use one of the
> pre-defined objectclasses (like inetOrgPerson) as your STRUCTURAL
> objectclass.
>
>
>
>
>
> Moving forward I want to be able to combine ObjectClasses to extend
> available objects without introducing data integrity issues in my ldap
> directory. I am looking for some clarification of rules regarding
> structural objectclasses,
>
> See rfc4512
>
>
>
>
> and if there is an easy way via the admin gui to tell the difference
> between structural, auxillary, and abstract objectclasses.
>
> No. You'll have to search cn=schema to check:
> ldapsearch -xLLL -s base -b "cn=schema" "objectclass=*" objectclasses |
> perl -p0e 's/\n //g' | grep AUXILIARY
>
> Note that ldapsearch wraps the output, so you'll have to use perl (or sed)
> to unwrap - see http://richmegginson.livejournal.com/18726.html
>
>
>
>
> Also will the directory do some sort of intregrity checking if you attempt
> to combine improper objectclasses either via commandline or the admin gui?
>
> Yes, although by default 389 will allow an entry to have multiple
> structural objectclasses, but that will change in a future release, so
> don't rely on that behavior.
>
>
>
>
>
>
> Thanks
>
>
>
>
>
> Cary Anderson
>
> 916.464.5108
>
> Linux Support | Engineering Dept.
>
>
>
>
>
>
>
>
>
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.fedoraproject.org/pipermail/389-users/attachments/20120711/0b97939f/attachment.html
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/x-pkcs7-signature
> Size: 6231 bytes
> Desc: not available
> URL: <
> http://lists.fedoraproject.org/pipermail/389-users/attachments/20120711/0b97939f/attachment.bin
> >
>
> ------------------------------
>
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
> End of 389-users Digest, Vol 86, Issue 9
> ****************************************
>
--
Atenciosamente,
______________________________________
Filippe Costa Spolti
Bacharel em Sistemas de Informação
Linux User n°515639 - http://counter.li.org/
filippespolti at gmail.com
(34)9679-2388
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20120711/c8971610/attachment.html>
More information about the 389-users
mailing list