Re: OpenLDAP Planning
by Gavin Henry
<quote who="Daniel Gibby">
> Hi,
Hi,
>
> We are somewhat new to OpenLDAP and are planning on how we'll use it for
> our business.
This thread may be more suitable for the general LDAP mailing list:
http://www.umich.edu/~dirsvcs/ldap/mailinglist.html
Nothing, as yet, seems directly related to OpenLDAP since you appear to be
at the "understanding LDAP" stages.
>
> We have a few different uses we plan on, but one in particular that I
> have a question about.
>
> We already have our email server setup to run virtual domain and aliases
> with a MySQL backend.
> We have a few thousand email addresses at one domain and we pretty much
> won't need more meta-information related to them besides what is already
> in our database.
>
> A spam firewall appliance sits in front of our email server. The spam
> firewall supports an LDAP lookup for email addresses.
>
> Since we already use MySQL for the backend of our email addresses, what
> would be the ways we should consider integrating OpenLDAP to support the
> spam firewall appliance?
Switch MySQL out for OpenLDAP. Put your virtual domains and aliases in
there and then point your Spam/Firewall appliance at it.
>
> I'm wary of using back-sql since all I ever see when searching through
> the OpenLDAP archives are somewhat old issues and lack of support.
Not lack of support, mainly inproper use of back-sql or misunderstanding
its intended purpose...
> If I'm wrong about shying away from that, let me know.
>
> It seems to me that we need a very simple implementation for this part
> of our business. Our schema only needs to include the email address,
> that's it.
>
> For other areas of our business we'd want to setup something more
> extensive on another server, but what would you see as options for
> setting up what we be required for this appliance lookup?
>
> Thanks for your input! I'll post questions about our other uses or
> issues of OpenLDAP in another thread.
>
Again, these discussion items are better suited to the general LDAP list:
http://www.umich.edu/~dirsvcs/ldap/mailinglist.html
Thanks,
Gavin.
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
15 years, 11 months
Re: OpenLDAP Planning
by Gavin Henry
<quote who="Daniel Gibby">
> Let me narrow the focus of my question a bit more. This isn't a general
> LDAP question. This is a question specific to OpenLDAP, since I'm
> looking for people with experience in OpenLDAP and for ways they solved
> the same problem I'm having with OpenLDAP and MySQL.
This is better ;-)
>
> I understand why what you are saying is better to migrate to an LDAP
> back-end. I understand why it is faster, more light-weight and elegant.
As well as centralised data with standards based access, etc. etc.
> Yet, the solution to move completely to LDAP and get away from a DB
> back-end always ignores the fact that our business already has
> everything working with MySQL.
Understood.
> We already have many applications setup
> to use the DB. We already have what we need except for an LDAP lookup on
> it. We just need advice on setting up OpenLDAP with a
> super-simple-schema, and suggestions on how to best interface OpenLDAP
> with MySQL for that schema. I would think that having support for this
> in OpenLDAP would help the community to grow. Adoption would happen at a
> much higher rate, since many businesses have a need for such a use of
> OpenLDAP. That can only be mostly good news for LDAP and OpenLDAP.
Hmmm, if you are merely setting up a directory server for your appliance
because it can "do" LDAP lookups, then that seems the wrong way to go
about it. In fact, it just seems like data duplication and management
overhead to me.
> So let me narrow the focus of this question more. I don't want to move
> away from a MySQL database. I'm open to exporting it to LDIF or to using
> back-sql, or to some other solution I don't know of that uses MySQL and
> OpenLDAP. I want someone who has experience using one of those methods
> to comment on resources they know of on how to get it to work, or with
> gotchas they found along the way.
man slapd-sql is very good and should answer most questions, using a 2.4.X
release.
>
> If we only had the time, we'd look into X.500 server commands and LDAP
> protocol and build a server that solely runs a ODBC back end and would
> only support a few limited LDAP commands. It wouldn't really be a full
> LDAP server, and would only support the Bind and Search commands. No
> Update, TLS, etc. is needed. It would only be used for this limited
> purpose.
>
> I do appreciate your input. I should have been more clear as to what I'm
> looking for with OpenLDAP, as I could have anticipated that my first
> response would have been to just move solely to an LDAP backend.
There is good information at:
http://www.openldap.org/doc/admin24/backends.html#SQL
http://www.openldap.org/doc/admin24/intro.html#LDAP%20vs%20RDBMS
>
> Gavin Henry wrote:
>> <quote who="Daniel Gibby">
>>
>>> Hi,
>>>
>>
>> Hi,
>>
>>
>>> We are somewhat new to OpenLDAP and are planning on how we'll use it
>>> for
>>> our business.
>>>
>>
>> This thread may be more suitable for the general LDAP mailing list:
>>
>> http://www.umich.edu/~dirsvcs/ldap/mailinglist.html
>>
>> Nothing, as yet, seems directly related to OpenLDAP since you appear to
>> be
>> at the "understanding LDAP" stages.
>>
>>
>>> We have a few different uses we plan on, but one in particular that I
>>> have a question about.
>>>
>>> We already have our email server setup to run virtual domain and
>>> aliases
>>> with a MySQL backend.
>>> We have a few thousand email addresses at one domain and we pretty much
>>> won't need more meta-information related to them besides what is
>>> already
>>> in our database.
>>>
>>> A spam firewall appliance sits in front of our email server. The spam
>>> firewall supports an LDAP lookup for email addresses.
>>>
>>> Since we already use MySQL for the backend of our email addresses, what
>>> would be the ways we should consider integrating OpenLDAP to support
>>> the
>>> spam firewall appliance?
>>>
>>
>> Switch MySQL out for OpenLDAP. Put your virtual domains and aliases in
>> there and then point your Spam/Firewall appliance at it.
>>
>>
>>> I'm wary of using back-sql since all I ever see when searching through
>>> the OpenLDAP archives are somewhat old issues and lack of support.
>>>
>>
>> Not lack of support, mainly inproper use of back-sql or misunderstanding
>> its intended purpose...
>>
>>
>>> If I'm wrong about shying away from that, let me know.
>>>
>>> It seems to me that we need a very simple implementation for this part
>>> of our business. Our schema only needs to include the email address,
>>> that's it.
>>>
>>> For other areas of our business we'd want to setup something more
>>> extensive on another server, but what would you see as options for
>>> setting up what we be required for this appliance lookup?
>>>
>>> Thanks for your input! I'll post questions about our other uses or
>>> issues of OpenLDAP in another thread.
>>>
>>>
>>
>> Again, these discussion items are better suited to the general LDAP
>> list:
>>
>> http://www.umich.edu/~dirsvcs/ldap/mailinglist.html
>>
>> Thanks,
>>
>> Gavin.
>>
>>
>
15 years, 11 months
OpenLDAP Planning
by Daniel Gibby
Hi,
We are somewhat new to OpenLDAP and are planning on how we'll use it for
our business.
We have a few different uses we plan on, but one in particular that I
have a question about.
We already have our email server setup to run virtual domain and aliases
with a MySQL backend.
We have a few thousand email addresses at one domain and we pretty much
won't need more meta-information related to them besides what is already
in our database.
A spam firewall appliance sits in front of our email server. The spam
firewall supports an LDAP lookup for email addresses.
Since we already use MySQL for the backend of our email addresses, what
would be the ways we should consider integrating OpenLDAP to support the
spam firewall appliance?
I'm wary of using back-sql since all I ever see when searching through
the OpenLDAP archives are somewhat old issues and lack of support.
If I'm wrong about shying away from that, let me know.
It seems to me that we need a very simple implementation for this part
of our business. Our schema only needs to include the email address,
that's it.
For other areas of our business we'd want to setup something more
extensive on another server, but what would you see as options for
setting up what we be required for this appliance lookup?
Thanks for your input! I'll post questions about our other uses or
issues of OpenLDAP in another thread.
15 years, 11 months
rewrite searchDN based on filter
by Finn Blucher
I know this was discussed recently but there didn't seem to be a real answer so I'd like to kick if off again.
I would like to be able redirect user searches to two different LDAP servers depending on UID, so:
if a process searches for userA with a base of o=container, then the request is sent to ldap://10.0.0.1/ou=subA,o=container
if a process searches for userB with a base of o=container, then the request is sent to ldap://10.0.0.2/ou=subB,o=container
I'd appreciate any information relating to weather I should be using the ldap or meta backend to achieve this. Mostly I'm having trouble understanding the best way to rewrite the searchDN based on the contents of the searchFilter.
Cheers,
Finn.
15 years, 11 months
ACL with group???
by Gémes Géza
Hi,
Sorry if it sounds a newbie question/problem, but:
Could anybody send me a working example of how can I use an ACL
containing a by group part, I'we found a few examples on the net but a
part of it rendered any of the by lines which followed the group one
ignored, others have crashed slapd immediately on startup.
(My slapd is version 2.3.38 and I stil use slapd.conf file based
configuration)
Thanks in advance
Geza Gemes
15 years, 11 months
Re: logging
by Gavin Henry
<quote who="Joseph Dickson">
> Reposting for Gavin -- doesn't seem to have gone to the list..
Thanks.
<snip>
I don't have the energy to repeat myself about contributing etc., so
please search the archives for my thoughts on bashing our documentation.
> In general, I just wanted to remind everyone that OpenLDAP's
> documentation isn't great, and saying that it is doesn't really help.
> Compare to the documentation of other projects (for example, Postgres),
http://www.postgresql.org/about/history ;-)
Umm Postgres started in 1986, a good 12 years before OpenLDAP was created,
but not really an excuse.
> I think we can agree that there's quite a bit of room for improvement.
> I know it would be better for me to step up and begin writing rather
> than rubbing salt in the wound, as it were, but sadly my free time is
> already devoted to other things so the best I can do at this point is
> try to remind people that there is work to be done on the documentation.
Would you be so humble as to spare the time to list improvements or topics
that aren't covered, or in fact the "work to be done on the
documentation", as it's very hard to guess. That would be ever so kind.
I know it's not finished (Admin Guide), but input (whether content or
direction) from the community is always appreciated.
Gavin.
15 years, 11 months
Re: logging
by Gavin Henry
<quote who="Howard Chu">
> Joseph Dickson wrote:
<snip>
I'd like to reply to the orignal post by the author. Did it go to the list?
Thanks,
Gavin.
15 years, 11 months
Re: logging
by Gavin Henry
> Same old story. You get perfectly good (and usually accurate) docs bundled
> with the source code. Why people start by searching the web, which is only
> going to return inaccurate/outdated cruft, written by people who aren't
> intimately familiar with the subject matter, just doesn't make any sense,
> and
> it really discourages/frustrates/pisses off those of us writing the docs
> (and
> the code).
+1
> Ignorance isn't a particular crime of course, nobody can know everything.
> But
> for the most part, LDAP is for sysadmins, and sysadmins have to have
> problem
> solving skills to be able to perform their jobs. It's not about knowing
> everything, it's about knowing how to find out what you need to know. That
> means knowing efficient processes for finding answers - knowing where to
> look,
> how to look, or how and what to ask.
Basic problem solving.
> Life is short, time is limited for every one of us. Make the most of the
> time
> available to you, don't waste it.
Don't we know it.
15 years, 11 months
Re: 2.4.6 prov/con, delta-syncrepl and auditContext
by Gavin Henry
<quote who="Pierangelo Masarati">
> Gavin Henry wrote:
>> <quote who="Aaron Richton">
>>> In the spirit of starting with the obvious, do you find auditContext
>>> under
>>> cn=Subschema?
>>
>> I'll check ;-)
>>
>> But why would this attribute get into the normal data dir?
>
> that attribute is added to the producer to provide a pointer to the
> database that contains the log. The attributeType itself is defined by
> slapo-accesslog(5), so the overlay should be present (but does not need
> to be instantiated; just compiled in or, if built as module, loaded) in
> the consumer in order to have that attribute defined.
Why would I need to load the accesslog overlay on the consumer? I never
have before.
The only thing that mentions accesslog is the normal delta-syncrepl
directives:
logbase="cn=accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
syncdata=accesslog
etc.
I'm confused here. Is it a 2.4 change?
15 years, 11 months
