Hi, I just read about the virtual DIT views in the Red Hat Directory Server Deployment Guide. I was wondering how well the virtual DIT views work compare to an hierarchical DIT structure? Generally speaking is it better to have a flat DIT and virtual DIT views than an hierarchical DIT?

-----Original Message----- From: fedora-directory-users-bounces(a)redhat.com [mailto:fedora-directory-users-bounces@redhat.com] On Behalf Of Mike Jackson Sent: Friday, June 24, 2005 12:10 PM To: Sam Tran; General discussion list for the Fedora Directory server project. Subject: Re: [Fedora-directory-users] Virtual DIT views vs hierarchical DIT Now, if you put them in seperate branches, then you can scope the queries accordingly, and the scoping actually has some effect on search response time.

If you put them all in the same branch, e.g. the root, then scoping your search to the virtual branches does not help to speed things up at all, afaik. Also, you can exceed the lookthrough limits easier, which can make things really slow.

The law of directory maintenance is that the deeper the hierarchy, the more likely it is to change. Because of this, I like to stay relatively flat, not more than 2 levels deep in most cases.

However, I still would never design a flat DIT because I believe that it takes away flexibility of some management applications, mostly third-party. And with third party applications, you don't have the possibility to modify them to be "view compatible".

-----Original Message----- From: fedora-directory-users-bounces(a)redhat.com [mailto:fedora-directory-users-bounces@redhat.com] On Behalf Of Mike Jackson Sent: Friday, June 24, 2005 1:03 PM To: General discussion list for the Fedora Directory server project. Subject: Re: [Fedora-directory-users] Virtual DIT views vs hierarchical DIT Pete Rowley wrote: > > Usually you give a third party application a base dn, that base dn can > be a view. Views were designed such that the client need not know it > is using a view based dit so compatibility isn't much of an issue for most clients. > And when the application needs to create it's own arbitrarily named sub branches? I'm talking about applications like Tivoli User Manager, etc.

-----Original Message----- From: fedora-directory-users-bounces(a)redhat.com [mailto:fedora-directory-users-bounces@redhat.com] On Behalf Of Mike Jackson Sent: Friday, June 24, 2005 1:38 PM To: General discussion list for the Fedora Directory server project. Subject: Re: [Fedora-directory-users] Virtual DIT views vs hierarchical DIT Pete Rowley wrote: > > > You mean a sub-branch in the view? That should work without issue. > Do you have an example where compatibility like this is definitely broken? I haven't tested it yet. I was just wondering if it's possible for an application which knows nothing about view attributes to create branches under a virtual branch. Does the server alter the entry to be added, by adding view attributes to it, and storing it under the root, or what?

A) they currently have no internet draft or RFC, and to my knowledge no other server impliments them - only you can tell if this matters

D) Entry DN's are not disguised, that is views does not try to make the entry DN of the returned entries look like they physically exist in the view hiearchy. It is possible that this might fool some clients that do DN manipulation - most won't care however.

-----Original Message----- From: fedora-directory-users-bounces(a)redhat.com [mailto:fedora-directory-users-bounces@redhat.com] On Behalf Of Sam Tran Sent: Friday, June 24, 2005 12:40 PM To: General discussion list for the Fedora Directory server project. Subject: Re: [Fedora-directory-users] Virtual DIT views vs hierarchical DIT On 6/24/05, Jeff Clowser <jclowser(a)unitedmessaging.com&gt; wrote: > Pete Rowley wrote: > >D) Entry DN's are not disguised, that is views does not try to make > >the entry DN of the returned entries look like they physically exist > >in the view hiearchy. It is possible that this might fool some > >clients that do DN manipulation - most won't care however. > > > > > I think this matters most for apps that modify the directory - esp > those that try to create entries. If they try to modify it using the > virtual view, things could get ugly. FWIW, chaining and/or referrals > can run into similar issues - if you have one hierarchy and use > referrals or chaining to split that across servers, you're generally > ok, but if you use referrals/chaining to "remap" some branch/tree to > some other structure or place in the tree (or another tree), you start > getting into trouble.

-----Original Message----- From: fedora-directory-users-bounces(a)redhat.com [mailto:fedora-directory-users-bounces@redhat.com] On Behalf Of Jeff Clowser Sent: Friday, June 24, 2005 1:17 PM To: General discussion list for the Fedora Directory server project. Subject: Re: [Fedora-directory-users] Virtual DIT views vs hierarchicalDIT Pete Rowley wrote: > Which sounds like a nice enhancement, redirect non-view entry creation > to > >some other part of the dit :) I think it is only the creation case >that really matters - clients that just do modify ops are much more >likely to use the dn of the returned entry than to try to construct one >(apps that do that would be very broken in any case). > > Well... Personally, I think administrative apps that create entries need to know the "real" DIT. I'm not sure how safe it would be to try to translate a view backwards (is it always safe/easy to translate back to the "right" place?) If you write DN based attributes (owner, manager, uniquemember) based on a view instead of the real tree, seems like a lot of ugliness can happen.

Jeff, Pete, So you would definitely go with hierarchical DIT and not flat DIT with views? Thanks for you comments.

I am tempted to go for a DIT that models our organisational chart.

Sam Tran wrote: >We have about 1,300 employees grouped by departments (Finance, HR, IT, >...) and some contractors and volunteers. > >Since we have the opportunity to redesign the DIT in a few months I >have been thinking on improving the DIT structure. > >Most of the applications that use our Directory for information >retrieval or authentication are UNIX based: SMTP, IMAP, FTP, RADIUS, >web based applications, ... Of course we also have a web interface for >users to perform Directory Searches (email, phone numbers, location, >...). > >As for the administration we have two set of Admins: >- the LDAP admins who have all rights on the Directory >- the Call Center who have limited rights: reset user passwords, >account creation, some attributes modification, ... > >As of today our DIT is 'simple' with ou=people, ou=group, ... etc. > >I am tempted to go for a DIT that models our organisational chart. I >am not sure yet if would be a significant improvement in our >situation. > > I would strongly recommend against this - what you already have is probably better. If you build based on your org chart, any change in that organization will break your DIT, and/or cause you to do a LOT of work to move things around, especially since you are not delegating administration beyond 2 global administrative levels (i.e. both your types of admins administer all users in some way). Even if your organizational chart does not change, if users move from one part of the org to another you have to move them, which is a pain, and may break a lot - consider the following: - You want to move a user from HR to marketing. I don't think FDS supports changing the DN (other than the rdn - i.e the left most DN component). - You try to create the user under marketing, then delete them under HR. But, you can't create it because of uid uniqueness. - Instead you delete the old entry then create the new entry. But... something happens between deleting and creating, and you could loose the entry (depends on how you do this - but if it's a web app that does this, recovering could be a pain). - When you delete a user, referential integrity removes them from all groups they are static members of. So, you have to figure out what groups they were part of first, then be sure to add the "new" user to the same groups. What I like to do is the following: 1. Have an objectclass (maybe more) for each application. i.e. you might have a mailuser objectclass, radiususer obejctclass, etc. Some apps might have multiple oc's (i.e. mail might have mailuser mailgroup, etc). 2. Each of these objectclasses may have additional attributes - for example, mailuser might define a mailhost, email address, delivery type, forwarding attributes, etc. Some (like radiususer) may define/require/allow no additional attributes. 3. Either via a filter (if at all possible) or an aci, set each app to only see resources it is supposed to see. For example, in your radius server, if you can add (objectclass=radiususer) to the filter the radius server uses to find users, you can limit who gets radius and who doesn't. Or, you can use aci's (or maybe views?) to limit the radius server to only see entries with objectclass=radiususer in ldap if you can't set the filter for finding users. Same for other apps. Depending on what you are using for mail, ftp, etc, the app may have already defined schema extensions for you to use. 4. For organizational hierarchy, define that in attributes - department, region, country, org unit, whatever, put these as attributes in the users entry (you may want to look at CoS if you want to populate a lot of info based on what department, region, etc they are in). You can filter searches on these attributes instead of by using a different basedn. Moving users between departments, regions, etc is simple. Also, users can be in multiple departments/regions/whatever, which they can't be in if your dit is how you define what groups/regions/whatever they are in. That's maybe an onversimplification of things and probably leaves a lot out, but it's sorta the basic idea.

-----Original Message----- From: fedora-directory-users-bounces(a)redhat.com [mailto:fedora-directory-users-bounces@redhat.com] On Behalf Of Jeff Clowser Sent: Friday, June 24, 2005 12:35 PM To: General discussion list for the Fedora Directory server project. Subject: Re: [Fedora-directory-users] Virtual DIT views vs hierarchicalDIT It's a nice feature of FDS to support these apps, but personally, I'd stay away from writing apps that depend on special views.