Wishlist

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff Clowser wrote:

> Rich Megginson wrote:
>
>> Jeff Clowser wrote:
>>
>>> suppose that might be more clearly stated in the X.501 spec?).  
>>> Sounds like I am stepping into an LDAP/X.50x holy war :)
>>
>>
>> I'm sure the folks on the ldap umich list will be happy to provide 
>> their interpretations :-)
>
>
> Heh :)
>
>> I propose the creation of a new objectclass that will be AUXILIARY 
>> and also be a subclass of posixAccount.  This objectclass will 
>> contain the "host" attribute (other attributes?).  In order to make 
>> host based access restriction work, you would simply add this 
>> objectclass and host attribute to any existing user, even if they 
>> already have the posixAccount objectclass.  I'm not sure what a good 
>> name for this objectclass would be - perhaps posixAccountExt or ???  
>> At any rate, applications that use the search filter 
>> (objectclass=posixAccount) to get entries that contain the host 
>> attribute would continue to work.  This would simplify new account 
>> creation because you could just use the new objectclass instead of 
>> posixAccount and it would inherit all of the posixAccount attributes.
>>
> Are you proposing this simply as "lets all agree on this list on 
> something", as "a schema extension that comes with FDS", or as a new 
> standard oc, with properly registered OIDs and all?  If a new standard 
> oc, how hard is it to do that - not something I've ever done.  I would 
> like the third mainly because it makes it easier for for 
> interoperability, but I can live with either of the other two.  Would 
> make sense to discuss if there are other attributes to add while we're 
> at it.

I would like it to be a standard as well, but at the same time, solve 
the existing problems our users have.  Perhaps there is even enough time 
to get the "host" attribute added to rfc2307 bis.  If not, then this 
specification would go through the RFC track, as either a Proposed 
Standard or an Informational RFC.  http://www.ietf.org/tao.html#6

>
> - Jeff
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3312 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20050826/47d6fddf/attachment.bin 


[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux