Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Fedora Directory (http://www.linux-archive.org/fedora-directory/)
-   -   389-users Digest, Vol 86, Issue 9 (http://www.linux-archive.org/fedora-directory/682403-389-users-digest-vol-86-issue-9-a.html)

Spolti 07-11-2012 12:05 PM

389-users Digest, Vol 86, Issue 9
 
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@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@lists.fedoraproject.org>

Send 389-users mailing list submissions to

* * * * 389-users@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@lists.fedoraproject.org



You can reach the person managing the list at

* * * * 389-users-owner@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@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@vovan.nl>

To: 389-users@lists.fedoraproject.org

Subject: [389-users] setting ACI to countryCode attribute

Message-ID: <1341930517.3558.58.camel@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@redhat.com>

To: "General discussion list for the 389 Directory server project."

* * * * <389-users@lists.fedoraproject.org>

Subject: Re: [389-users] setting ACI to countryCode attribute

Message-ID: <4FFC3E3C.8090106@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@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@redhat.com>

To: "General discussion list for the 389 Directory server project."

* * * * <389-users@lists.fedoraproject.org>

Subject: Re: [389-users] setting ACI to countryCode attribute

Message-ID: <4FFC3E76.6050205@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@vovan.nl>

To: Rich Megginson <rmeggins@redhat.com>

Cc: "General discussion list for the 389 Directory server project."

* * * * <389-users@lists.fedoraproject.org>

Subject: Re: [389-users] setting ACI to countryCode attribute

Message-ID: <1341931723.3558.60.camel@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@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@CIO" <Cary.Anderson@State.ca.gov>

To: 'Rich Megginson' <rmeggins@redhat.com>, 'General discussion list

* * * * for the 389 Directory server project.'

* * * * <389-users@lists.fedoraproject.org>

Subject: Re: [389-users] Question regarding Combining ObjectClasses to

* * * * add attributes

Message-ID:

* * * * <8E433F62879B78449F9FF77C24ED7535985D40221C@MDTSSW ECCR14.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@redhat.com]

Sent: Monday, July 09, 2012 9:14 AM

To: General discussion list for the 389 Directory server project.

Cc: Anderson, Cary@CIO

Subject: Re: [389-users] Question regarding Combining ObjectClasses to add attributes



On 07/09/2012 09:44 AM, Anderson, Cary@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/
//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@lists.fedoraproject.org<mailto:389-users@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@redhat.com>

To: "Anderson, Cary@CIO" <Cary.Anderson@State.ca.gov>

Cc: "'General discussion list for the 389 Directory server project.'"

* * * * <389-users@lists.fedoraproject.org>

Subject: Re: [389-users] Question regarding Combining ObjectClasses to

* * * * add attributes

Message-ID: <4FFC4E24.8060800@redhat.com>

Content-Type: text/plain; charset="utf-8"; Format="flowed"



On 07/10/2012 09:01 AM, Anderson, Cary@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@redhat.com]

> *Sent:* Monday, July 09, 2012 9:14 AM

> *To:* General discussion list for the 389 Directory server project.

> *Cc:* Anderson, Cary@CIO

> *Subject:* Re: [389-users] Question regarding Combining ObjectClasses

> to add attributes

>

> On 07/09/2012 09:44 AM, Anderson, Cary@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/
//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@lists.fedoraproject.org *<mailto:389-users@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@potsdam.edu>

To: 389-users@lists.fedoraproject.org

Subject: [389-users] Password policy questions

Message-ID: <4FFC4339.3080303@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@redhat.com>

To: "General discussion list for the 389 Directory server project."

* * * * <389-users@lists.fedoraproject.org>

Subject: Re: [389-users] Password policy questions

Message-ID: <4FFC6752.6060509@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_Manageme nt-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@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@hp.com>

To: "389-users@lists.fedoraproject.org"

* * * * <389-users@lists.fedoraproject.org>, * *"Cary.Anderson@State.ca.gov"

* * * * <Cary.Anderson@State.ca.gov>

Subject: Re: [389-users] Question regarding Combining ObjectClasses to

* * * * add attributes

Message-ID:

* * * * <B70713EB4E55C84C963B37DE9E63011B50DD3F0F@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@lists.fedoraproject.org [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Rich Megginson


Sent: Tuesday, July 10, 2012 8:46 AM

To: Anderson, Cary@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@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@redhat.com]

Sent: Monday, July 09, 2012 9:14 AM

To: General discussion list for the 389 Directory server project.

Cc: Anderson, Cary@CIO

Subject: Re: [389-users] Question regarding Combining ObjectClasses to add attributes







On 07/09/2012 09:44 AM, Anderson, Cary@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/
//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@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@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@gmail.com
(34)9679-2388


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


All times are GMT. The time now is 10:33 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.