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

Re: Re[2]: Virtual Domains & LDAP

Firstly I've replied to this with the list CC'd as I think that other 
people are likely to benefit from the answers and it seems that there is 
nothing secret being discussed.  I hope you don't mind.

On Tuesday 12 June 2001 17:25, you wrote:
> RC> No, searches would be fast.
> :)
> RC> For each user you will have an attribute that you will use as the
> key for RC> your searches, typically uid or cn.  If you do a search for
> RC> "uid=user_company.com" then it'll require a single search operation
> on a RC> single index which should be quite fast.
> Does LDAP use some sort of hash algorithm for this?  If it did, then it

The OpenLDAP server uses some sort of hash, it uses the GNU DBM library 
or equivalent libraries for indexing each attribute separately.

Other LDAP servers may do things differently, but most LDAP servers have 
taken code from the University of Michigan LDAP server (which is what 
OpenLDAP was based on).

> really wouldn't matter how I build my DIT; it would just be for my own
> organizational purposes.  I would think with some sort of tree
> traversal algo, that searches would still suffer a little. And would
> uid=user@company.com be viable?  I don't know if that '@' would cause
> any problems with other software.

@ sign has no inherant problems, but some software might not like it.

> RC> Searching for the complete DN of "uid=user_company.com,
> ou=company.com, RC> o=my_org" is also a single search of a single
> index.
> This could work for local searches, but I don't think I could configure
> proftpd for instance to do this on a global config level, so the former
> would be better.

Proftpd will do a search of "attribute=$1" where $1 is what the user 
enters at the Name: prompt.  Then it will read the userPassword attribute 
of that entry or bind as that DN depending on how it's configured.

> RC> Searching for "uid=user_company.com" with a search base of
> RC> "ou=company.com, o=my_org" requires searching through two indexes
> which RC> isn't as fast.  But if the uid attribute has a unique value
> (which it RC> will have if it is the user-name concatenated with the
> company name) then RC> you can just search by the attribute value.
> Ok.  This is where I lose you, unless you meant uid=user.  And then to

No.  I mean making the UID include the company.  So within the 
"company.com" domain we have an account named "user".  This is the only 
way to do it with proftpd!

> search within the base of "ou=company.com, o=my_org".  Because with the
> uid=user_company.com, I'm still searching on a single attribute.  I
> would think if anything, it would be quicker, because I would already
> be searching within the correct ou.  If you could elaborate a little
> more, I would be most gracious. Likewise, I don't have a great
> understanding of how index eq and index pres, and what have you works. 
> I realize it's pretty LDAP distrib specific, but I don't see much
> documentation for OpenLDAP in this regards.
> Btw, sorry you got the cross-post.  I've scoured the archives for
> debian-isp. Has the debian schema files been produced yet?  I was
> looking at using the allowedService attribute you drafted up quickly,
> to give users access to different services (duh?).

I've produced a few drafts but so far no-one has responded to my requests 
for comments on them.  So we are all waiting for some input from people 
who know about LDAP and schema...

> Also, do you use proftpd by chance?  I would like to do virt hosting,

Yes.  One of my clients recently paid for enhancements to Proftpd for 
better support of this.

> but I don't feel like killing the IP pool :-P  I suppose a
> user_company.com system would work, but that'd be unnatural to users,

Why?  I've worked for two ISPs doing bulk commercial hosting with that 
scheme and no problems...

> whereas an email address like naming scheme wouldn't be too bad.  But

Not sure if an @ sign will be accepted by proftpd.  Never tried it.

> realistically, should I just follow in the steps of ISPMan, and allow
> ftp access to one user per domain?

No, that sucks.

http://www.coker.com.au/bonnie++/     Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/       Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/     My home page

Reply to: