5:18 p.m.
I personally wouldn't move to a sql backend.. I've recommended against it.
This is what the boss wants though so here we are. :-)
Any ideas?
Thanks.
On Jan 5, 2015 8:03 PM, "Quanah Gibson-Mount" <quanah(a)zimbra.com> wrote:
--On Monday, January 05, 2015 7:27 PM -0500 thelastknowngod <
tlkg.me(a)gmail.com> wrote:
I've finished moving my existing LDAP user data into MySQL
>
Why would you move to SQL for an LDAP server?
for use with
> back-sql on my testing machine and everything is working perfectly.
>
back-sql is entirely experimental and generally unsupported.
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
8:37 p.m.
New subject: back-sql deployment woes
I would explain to your boss that this is an extremely bad idea.
--Quanah
On Jan 5, 2015, at 5:18 PM, Nick Atzert <tlkg.me(a)gmail.com>
wrote:
I personally wouldn't move to a sql backend.. I've recommended against it. This
is what the boss wants though so here we are. :-)
Any ideas?
Thanks.
> On Jan 5, 2015 8:03 PM, "Quanah Gibson-Mount" <quanah(a)zimbra.com>
wrote:
> --On Monday, January 05, 2015 7:27 PM -0500 thelastknowngod <tlkg.me(a)gmail.com>
wrote:
>
>> I've finished moving my existing LDAP user data into MySQL
>
> Why would you move to SQL for an LDAP server?
>
>> for use with
>> back-sql on my testing machine and everything is working perfectly.
>
> back-sql is entirely experimental and generally unsupported.
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Platform Architect
> Zimbra, Inc.
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
3:17 a.m.
New subject: back-sql deployment woes
Nick Atzert wrote:
I personally wouldn't move to a sql backend.. I've
recommended against it.
This is what the boss wants though so here we are. :-)
I'm pretty sure your boss don't want you to use components which are not
actively maintained anymore. back-sql is not maintained in the same way like
back-mdb. You have to expect that some features (e.g. overlays) you may want
to use later do not work the same way.
Ciao, Michael.
12:39 p.m.
New subject: back-sql deployment woes
I am not sure if I should interpret this as "sql-backend is a second class
citizen that shouldn't be used in production environments (i.e. think of
virtual directories) because of its experimental stage" or take it as an
overstatement been made on purpose mostly to discourage new users from
considering an sql based engine for their main ldap database backend.
I hadn't had the chance to use sql backend in production or test it as much
as I would like, thus it would be interesting to hear from others in the
list, their practical experience of sql backend in read-only or read-write
deployments.
On Tue, Jan 6, 2015 at 1:17 PM, Michael Ströder <michael(a)stroeder.com>
wrote:
Nick Atzert wrote:
> I personally wouldn't move to a sql backend.. I've recommended against
it.
> This is what the boss wants though so here we are. :-)
I'm pretty sure your boss don't want you to use components which are not
actively maintained anymore. back-sql is not maintained in the same way
like
back-mdb. You have to expect that some features (e.g. overlays) you may
want
to use later do not work the same way.
Ciao, Michael.
12:52 p.m.
New subject: back-sql deployment woes
--On Tuesday, January 06, 2015 10:39 PM +0200 Nikos Voutsinas
<nvoutsin(a)gmail.com> wrote:
I am not sure if I should interpret this as "sql-backend is a second
class citizen that shouldn't be used in production environments (i.e.
think of virtual directories) because of its experimental stage" or take
it as an overstatement been made on purpose mostly to discourage new
users from considering an sql based engine for their main ldap database
backend.
As noted in the manual page, back-sql is entirely experimental. It has no
dedicated maintainer, and has seen virtually no work in 2-3 years. You use
it at your own extreme risk, and should not expect help if you hit issues
with it.
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
1 p.m.
New subject: back-sql deployment woes
It's pretty messy and convoluted IMO. That's with a fairly pedestrian view
of the project. Considering it's (apparently) unmaintained I'd assume it's
the same for development. The biggest issue I've been having is mostly with
understanding error logs when things break or deviate from a really basic
config.. that may just be me though.
I hope I'm not coming of as accusatory toward the OpenLDAP/back-sql devs. I
like OpenLDAP a lot.. you guys do a great job. I know this is a really bad
way to go about storing the data and I've definitely voiced my objections
on this issue. Sometimes you just have to CYA and do it anyway though.
That's the unfortunate situation I find myself in at the moment.
In any case, thank you guys for taking a look even if you couldn't help. I
do appreciate it.
On Jan 6, 2015 3:39 PM, "Nikos Voutsinas" <nvoutsin(a)gmail.com> wrote:
I am not sure if I should interpret this as "sql-backend is a
second class
citizen that shouldn't be used in production environments (i.e. think of
virtual directories) because of its experimental stage" or take it as an
overstatement been made on purpose mostly to discourage new users from
considering an sql based engine for their main ldap database backend.
I hadn't had the chance to use sql backend in production or test it as
much as I would like, thus it would be interesting to hear from others in
the list, their practical experience of sql backend in read-only or
read-write deployments.
On Tue, Jan 6, 2015 at 1:17 PM, Michael Ströder <michael(a)stroeder.com>
wrote:
> Nick Atzert wrote:
> > I personally wouldn't move to a sql backend.. I've recommended against
> it.
> > This is what the boss wants though so here we are. :-)
>
> I'm pretty sure your boss don't want you to use components which are not
> actively maintained anymore. back-sql is not maintained in the same way
> like
> back-mdb. You have to expect that some features (e.g. overlays) you may
> want
> to use later do not work the same way.
>
> Ciao, Michael.
>
>
3 p.m.
New subject: back-sql deployment woes
If what you are looking for is a backend for your main ldap database then,
as has been said previously, avoid sql by all means, not just the specific
openldap implementation, all kind of sql backends. Relational databases can
not match the requirements of the ldap protocol. It would be like trying to
use GmailFS for general purpose filesystem.
If you need just an "ldap view" to an existing relational database then the
right keyword for this is "Virtual Directory". The sql backend of Openldap
could have been an opensource alternative but now this goes off the list. I
am not aware of any other reliable opensource implementations there are few
commercial though.
Nikos
On Tue, Jan 6, 2015 at 11:00 PM, Nick Atzert <tlkg.me(a)gmail.com> wrote:
It's pretty messy and convoluted IMO. That's with a fairly
pedestrian view
of the project. Considering it's (apparently) unmaintained I'd assume it's
the same for development. The biggest issue I've been having is mostly with
understanding error logs when things break or deviate from a really basic
config.. that may just be me though.
I hope I'm not coming of as accusatory toward the OpenLDAP/back-sql devs.
I like OpenLDAP a lot.. you guys do a great job. I know this is a really
bad way to go about storing the data and I've definitely voiced my
objections on this issue. Sometimes you just have to CYA and do it anyway
though. That's the unfortunate situation I find myself in at the moment.
In any case, thank you guys for taking a look even if you couldn't help. I
do appreciate it.
On Jan 6, 2015 3:39 PM, "Nikos Voutsinas" <nvoutsin(a)gmail.com> wrote:
> I am not sure if I should interpret this as "sql-backend is a second
> class citizen that shouldn't be used in production environments (i.e. think
> of virtual directories) because of its experimental stage" or take it as an
> overstatement been made on purpose mostly to discourage new users from
> considering an sql based engine for their main ldap database backend.
>
> I hadn't had the chance to use sql backend in production or test it as
> much as I would like, thus it would be interesting to hear from others in
> the list, their practical experience of sql backend in read-only or
> read-write deployments.
>
> On Tue, Jan 6, 2015 at 1:17 PM, Michael Ströder <michael(a)stroeder.com>
> wrote:
>
>> Nick Atzert wrote:
>> > I personally wouldn't move to a sql backend.. I've recommended
against
>> it.
>> > This is what the boss wants though so here we are. :-)
>>
>> I'm pretty sure your boss don't want you to use components which are not
>> actively maintained anymore. back-sql is not maintained in the same way
>> like
>> back-mdb. You have to expect that some features (e.g. overlays) you may
>> want
>> to use later do not work the same way.
>>
>> Ciao, Michael.
>>
>>
>
5:16 p.m.
New subject: back-sql deployment woes
On Jan 06, 2015, at 16.00, Nick Atzert <tlkg.me(a)gmail.com>
wrote:
It's pretty messy and convoluted IMO. That's with a fairly pedestrian view of the
project. Considering it's (apparently) unmaintained I'd assume it's the same
for development. The biggest issue I've been having is mostly with understanding error
logs when things break or deviate from a really basic config.. that may just be me though.
i'd offer that it's really not even about this. the sql backend was/is not
intended to be included in consideration for use as the backend when setting up a new
directory service with its own data. rather, the intent was to offer the potential to
expose data [in a limited capacity, as you can see] from an existing sql database, via
ldap. others in more authoritative roles will correct me if this is inaccurate, but it
being messy/convoluted/unmaintained/undeveloped/etc should be considered an indication of
its intent, rather than abandonment of what was once intended to become some comprehensive
slapd backend.
i think you'll also find that sentiment reflected in the archives of this mailing
list. my experience has been that when someone asks for help with slapd-sql(5) thinking
they've cleverly figured out a great way to set up their new openldap server, folks
aren't generally sympathetic to the cause. conversely, when the question posed is
"i'm stuck with this sql database, but would like to make some of its data
available via ldap", often times responses are quite magnanimous and accommodating.
-ben
12:59 a.m.
New subject: back-sql deployment woes
Am Tue, 6 Jan 2015 22:39:18 +0200
schrieb Nikos Voutsinas <nvoutsin(a)gmail.com>:
I am not sure if I should interpret this as "sql-backend is a
second
class citizen that shouldn't be used in production environments (i.e.
think of virtual directories) because of its experimental stage" or
take it as an overstatement been made on purpose mostly to discourage
new users from considering an sql based engine for their main ldap
database backend.
I hadn't had the chance to use sql backend in production or test it
as much as I would like, thus it would be interesting to hear from
others in the list, their practical experience of sql backend in
read-only or read-write deployments.
You may use back-sql as a read only subordinate database, but
performance is limited to the sql engine. Be aware that your
are on your own risk.
At some time i had a postgresql database with a few thousand objects
and a back-relay attached as subordinate database in read only mode.
-Dieter
On Tue, Jan 6, 2015 at 1:17 PM, Michael Ströder <michael(a)stroeder.com>
wrote:
> Nick Atzert wrote:
> > I personally wouldn't move to a sql backend.. I've recommended
> > against
> it.
> > This is what the boss wants though so here we are. :-)
>
> I'm pretty sure your boss don't want you to use components which
> are not actively maintained anymore. back-sql is not maintained in
> the same way like
> back-mdb. You have to expect that some features (e.g. overlays) you
> may want
> to use later do not work the same way.
>
> Ciao, Michael.
>
>
--
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E
10 a.m.
New subject: back-sql deployment woes
On Wed, Jan 07, 2015 at 09:59:28AM +0100, Dieter Klünter wrote:
You may use back-sql as a read only subordinate database, but
performance is limited to the sql engine. Be aware that your
are on your own risk.
Another option would be to use back-sock and write a separate server process to
translate between the back-sock protocol (extended LDIF) and SQL.
You should get better performance (if your server programming is good)
and if something goes wrong there is less code to debug: back-sock has under
1500 lines of C, where back-sql has over 11000...
There are still many caveats though: limited ACLs, fundamental mismatch in data
model, poor performance and resource usage when compared with back-mdb etc...
Andrew
--
-----------------------------------------------------------------------
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/ +44 1628 782565 |
-----------------------------------------------------------------------
10:27 a.m.
New subject: back-sql deployment woes
Andrew Findlay wrote:
On Wed, Jan 07, 2015 at 09:59:28AM +0100, Dieter Klünter wrote:
> You may use back-sql as a read only subordinate database, but
> performance is limited to the sql engine. Be aware that your
> are on your own risk.
Another option would be to use back-sock and write a separate server process to
translate between the back-sock protocol (extended LDIF) and SQL.
You should get better performance (if your server programming is good)
and if something goes wrong there is less code to debug: back-sock has under
1500 lines of C, where back-sql has over 11000...
There are still many caveats though: limited ACLs, fundamental mismatch in data
model, poor performance and resource usage when compared with back-mdb etc...
And some security aspects like avoiding SQL injection
Ciao, Michael.
3061
days inactive
3070
days old
openldap-technical@openldap.org
10 comments
7 participants
participants (7)
-
Andrew Findlay -
btb＠bitrate.net -
Dieter Klünter -
Michael Ströder -
Nick Atzert -
Nikos Voutsinas -
Quanah Gibson-Mount