On 05/31/2017 04:39 PM, John Lewis wrote:
On Wed, 2017-05-31 at 15:07 -0400, Prentice Bisbal wrote:
On 05/31/2017 02:55 PM, Howard Chu wrote:
Prentice Bisbal wrote:
On 05/31/2017 12:37 AM, John Lewis wrote:
This sounds like the wrong tool for this job.
Really? Can you give a point by point comparison against what you
think is the "right" tool for the job?
That's the wrong question to ask, since I never made any claim as to
what the right tool is. A better question to ask would be why I think
this is the wrong tool. So here's my reply to that: It doesn't seem like
this is a job LDAP was designed for. To me, LDAP is really just a
standardized database interface that make certain type of DB looks up
easy, and most importantly, standardized.I would think a more general
purpose database interface would be better for this.
Unfortunately, I'm not a database expert, so I can't give you the
"point-by-point argument you requested.
Now your turn - why would OpenLDAP be a good fit for this over other
databases?
--
Prentice
Yes, LDAP is really just a standardized database interface. That is the
point. I want my logs available through an IETF standardized protocol so
I can reuse tools so I don't have to maintain as many tools.
OpenLDAP would be a good fit over other databases because Michael, and
Howard, and the other contributers to OpenLDAP did most of the work for
me.
Fair enough answer. How would you store and retrieve your results? Are you
creating/using a schema specifically for this? If so, what does it look like.
I'm still having trouble seeing the performance benefits, though. The data is
still stored in a backend DB, right? Let's say that backend is some sort of
SQL DB. You write your ldapsearch query, and then LDAP converts that to SQL,
and then the DB returns the results to LDAP, which then translated the results
to LDIF and returns them to you. Isn't there performance hits every time you
traverse the LDAP layer?
I suppose this might still be faster than reading a plain-text log file. Is
that the point I'm missing?