Hi all, as 2.4 has finally stabilised and the ITS list is getting shorter not longer (thanks to Quanah's tireless efforts), the project can finally tackle some of the long-standing pain points. So this post aims to outline where we are/want to move to as well as to start a discussion and hopefully get you, the community, more involved on the road to 2.5 and beyond.
We would love to welcome more people to participate in the project and make it more active and resilient. People of various skills and experience can make a difference, I am personally happy to assist anyone who wants to contribute with getting up to speed and start helping out, and for sure I'm not the only one. Also OpenLDAP is about more than just C programming and I'll try to outline the main areas where we want to focus our work in the short term here:
One of the pain points in the 2.4 release cycle was the level of testing done on the code before we have released. There are issues with the existing test suite that make testing hard and I will come to how this could be tackled in a later email. In the short term however, we could benefit from having the tests we have run more often and on more diverse environments. If you have a chance to run it regularly, in a loop and report issues picked up, that would be a definite help. If you could help extend the test suite to cover scenarios that are of interest to you and are not appropriately covered yet, even better.
Another issue frustrating both users and contributors to the project has been the existing jitterbugs bug tracker (a.k.a. ITS), which has by now outlived its usefulness. Plans to move to a project-hosted Gitlab instance + Bugzilla (via Gitlab's built in Bugzilla integration) are being made and this should make the issue tracker searchable again, help with triage as well as greatly improve the visibility into our release process. Especially after the migration, this would be another opportunity for anyone with just a bit of spare time to help by triaging open issues so we can make timely releases of better quality.
I'm sure everyone agrees our website could do with a redesign. We've started looking into this but it has been a slow process so far and if you can contribute here, that might speed things up. It doesn't need much, keeping it a collection of static html pages, just a slight reorganisation of the content that is more friendly to anyone visiting it for the first time plus a simplistic design along the lines of many other open source projects (openssl.org for example) would go a long way.
This leads to documentation, much of which is already hosted on the website. While I believe there is good work to be done on the admin guide, it is one of the better parts of our documentation. This is where user feedback on its usefulness is more important, please read it, have people on your team read it and show it people just getting started and report which parts are confusing, how they could be improved. We also intend to document our contributor guidelines in a more readable way.
The FAQ site however is on the opposite side of the spectrum and will be removed at some later point. There have been two suggestions how to replace it. We could use Gitlab internal wiki or a static webpage site based on Gitlab pages and we want to transfer over articles that are still relevant.
In general, moving to Gitlab should let us integrate CI much better, especially if there are people willing to integrate and manage external runners. As mentioned above, we could definitely do with more regular testing on non-Linux platforms, e.g. *BSD or Windows+MSYS2. Pull requests might then also be automatically tested.
Let us know what the pain points have been with OpenLDAP when you were just starting, right now and if you have a suggestion how to make it easier to start using it. Or if you wanted to contribute, has anything discouraged you? There are things we might not be able to influence easily (LDAP itself can be complex), but a fresh look might help direct efforts in the right direction.
Thanks ever so much for reading this far. This email is long enough already so I will follow up with another one about my long term plans to overhaul the test infrastructure and other tools that might be worth introducing to help with setting up and managing OpenLDAP deployments.
Regards,
On 7/24/19, Ondřej Kuzník ondra@mistotebe.net wrote:
[ ... ]
We would love to welcome more people to participate in the project and make it more active and resilient. People of various skills and experience can make a difference, I am personally happy to assist anyone who wants to contribute with getting up to speed and start helping out, and for sure I'm not the only one. Also OpenLDAP is about more than just C programming and I'll try to outline the main areas where we want to focus our work in the short term here:
I'm a long-time user, but have never really got myself involved at the source level, although I have ported the client tools to Plan 9, way back in 2.3 times(I checked 2.3.38 - I still use them "to keep me honest").
I'll be happy to help, although OpenLDAP, like just about anything that is not seriously mainstream that I've done is really just a hobby.
I've also been a very early adopter of Go, which is now my developing language of choice. That does define my philosophy (Plan 9, Go - should be quite revealing, NetBSD is my Posix preference, by far) and I am not at all ashamed of my "periphery" preferences.
I have only a very few valuable resources I can contribute, but a long history of not quite taking anything for granted.
My efforts keeping Graphviz running under Plan 9 were defeated by the adoption of a practically incompatible configuration and installation system and it also blocked efforts on my part to port the client tools from OpenLDAP 2.4: I just felt I was not up to the task.
That's my CV in a few sentences. If you can find a role for me to play towards 2.5, I'll help. The price is dealing with scratchy personality and some very fixed ideas that have taken root in my head.
On Thu, Jul 25, 2019 at 05:38:21AM +0200, Lucio De Re wrote:
On 7/24/19, Ondřej Kuzník ondra@mistotebe.net wrote:
We would love to welcome more people to participate in the project and make it more active and resilient. People of various skills and experience can make a difference, I am personally happy to assist anyone who wants to contribute with getting up to speed and start helping out, and for sure I'm not the only one. Also OpenLDAP is about more than just C programming and I'll try to outline the main areas where we want to focus our work in the short term here:
I'm a long-time user, but have never really got myself involved at the source level, although I have ported the client tools to Plan 9, way back in 2.3 times(I checked 2.3.38 - I still use them "to keep me honest").
I'll be happy to help, although OpenLDAP, like just about anything that is not seriously mainstream that I've done is really just a hobby.
I've also been a very early adopter of Go, which is now my developing language of choice. That does define my philosophy (Plan 9, Go - should be quite revealing, NetBSD is my Posix preference, by far) and I am not at all ashamed of my "periphery" preferences.
I have only a very few valuable resources I can contribute, but a long history of not quite taking anything for granted.
My efforts keeping Graphviz running under Plan 9 were defeated by the adoption of a practically incompatible configuration and installation system and it also blocked efforts on my part to port the client tools from OpenLDAP 2.4: I just felt I was not up to the task.
That's my CV in a few sentences. If you can find a role for me to play towards 2.5, I'll help. The price is dealing with scratchy personality and some very fixed ideas that have taken root in my head.
Hi Lucio, if you don't feel like delving into the codebase yet and don't want to extend the test suite either (also see the followup email on -devel that might be of interest to you), then any work on reviewing/improving project documentation might be useful?
Thanks,
Ondrej Kuzník ondra@mistotebe.net schrieb am 24.07.2019 um 20:01 in
Nachricht 20190724180157.ut3r62pdgiaemjdt@mistotebe.net:
Hi all, as 2.4 has finally stabilised and the ITS list is getting shorter not
longer
(thanks to Quanah's tireless efforts), the project can finally tackle some of the long-standing pain points. So this post aims to outline where we are/want to move to as well as to start a discussion and hopefully get you, the community, more involved on the road to 2.5 and beyond.
We would love to welcome more people to participate in the project and make
it more active and resilient. People of various skills and experience can make
a difference, I am personally happy to assist anyone who wants to contribute with getting up to speed and start helping out, and for sure I'm not the only one. Also OpenLDAP is about more than just C programming and I'll try to outline
the main areas where we want to focus our work in the short term here:
One of the pain points in the 2.4 release cycle was the level of testing done on the code before we have released. There are issues with the existing test suite that make testing hard and I will come to how this could be tackled in a later email. In the short term however, we could benefit from having the tests we
have run more often and on more diverse environments. If you have a chance to run
it regularly, in a loop and report issues picked up, that would be a definite help. If you could help extend the test suite to cover scenarios that are of interest to you and are not appropriately covered yet, even better.
Another issue frustrating both users and contributors to the project has been the existing jitterbugs bug tracker (a.k.a. ITS), which has by now outlived
its usefulness. Plans to move to a project-hosted Gitlab instance + Bugzilla (via Gitlab's built in Bugzilla integration) are being made and this should make
the issue tracker searchable again, help with triage as well as greatly improve
the visibility into our release process. Especially after the migration, this would be another opportunity for anyone with just a bit of spare time to help by triaging open issues so we can make timely releases of better quality.
Using Bugzilla can't be wrong it seems. Most issue trackers are just worse (from the perspective of users at least).
I'm sure everyone agrees our website could do with a redesign. We've
started
looking into this but it has been a slow process so far and if you can contribute here, that might speed things up. It doesn't need much, keeping it a collection of static html pages, just a slight reorganisation of the
content
that is more friendly to anyone visiting it for the first time plus a simplistic design along the lines of many other open source projects (openssl.org for example) would go a long way.
Personally I don't like sites that use too much script code, especially for download links. It would be great if the site still had minimal functionality when scripts are unavailable or disabled.
This leads to documentation, much of which is already hosted on the
website.
While I believe there is good work to be done on the admin guide, it is one
of the better parts of our documentation. This is where user feedback on its usefulness is more important, please read it, have people on your team read
it and show it people just getting started and report which parts are confusing, how they could be improved. We also intend to document our contributor guidelines in a more readable way.
The FAQ site however is on the opposite side of the spectrum and will be removed at some later point. There have been two suggestions how to replace it. We could use Gitlab internal wiki or a static webpage site based on Gitlab pages and
we want to transfer over articles that are still relevant.
I have no strong opinion on that, but what about this idea: Allow up/down votes for individual questions and answers (a bit like stackexchange sites). Then remove those entries with significant down votes, while keeping those with up votes. Next step could be to add references to official documentation to the answers (a good exercise to check whether the documentation is clear and sufficient): When eventually deciding to retire the FAQ, integrate the remaining FAQs not answerable from the rest of the documentation into some other document.
In general, moving to Gitlab should let us integrate CI much better, especially if there are people willing to integrate and manage external runners. As mentioned above, we could definitely do with more regular testing on non-Linux platforms, e.g. *BSD or Windows+MSYS2. Pull requests might then also be automatically tested.
Sounds good.
Let us know what the pain points have been with OpenLDAP when you were just starting, right now and if you have a suggestion how to make it easier to start using it. Or if you wanted to contribute, has anything discouraged you?
Maybe some type of "Read me first" document that could contain a "decision flow graph" dealing with a new installation or an upgrade.
There are things we might not be able to influence easily (LDAP itself can be complex), but a fresh look might help direct efforts in the right
direction.
Thanks ever so much for reading this far. This email is long enough already
so I will follow up with another one about my long term plans to overhaul the test infrastructure and other tools that might be worth introducing to help with setting up and managing OpenLDAP deployments.
What I don't like is the strong focus on one (LMDB) database backend, despite of all the stupid things Oracle does.
Regards, Ulrich
Regards,
-- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
On Thu, Jul 25, 2019 at 08:16:27AM +0200, Ulrich Windl wrote:
Ondrej Kuzník ondra@mistotebe.net schrieb am 24.07.2019 um 20:01 in Nachricht 20190724180157.ut3r62pdgiaemjdt@mistotebe.net:
Another issue frustrating both users and contributors to the project has been the existing jitterbugs bug tracker (a.k.a. ITS), which has by now outlived its usefulness. Plans to move to a project-hosted Gitlab instance + Bugzilla (via Gitlab's built in Bugzilla integration) are being made and this should make the issue tracker searchable again, help with triage as well as greatly improve the visibility into our release process. Especially after the migration, this would be another opportunity for anyone with just a bit of spare time to help by triaging open issues so we can make timely releases of better quality.
Using Bugzilla can't be wrong it seems. Most issue trackers are just worse (from the perspective of users at least).
It is popular and maintained by upstream.
I'm sure everyone agrees our website could do with a redesign. We've started looking into this but it has been a slow process so far and if you can contribute here, that might speed things up. It doesn't need much, keeping it a collection of static html pages, just a slight reorganisation of the content that is more friendly to anyone visiting it for the first time plus a simplistic design along the lines of many other open source projects (openssl.org for example) would go a long way.
Personally I don't like sites that use too much script code, especially for download links. It would be great if the site still had minimal functionality when scripts are unavailable or disabled.
I agree here that any redesign should be perfectly useable with JS disabled.
The FAQ site however is on the opposite side of the spectrum and will be removed at some later point. There have been two suggestions how to replace it. We could use Gitlab internal wiki or a static webpage site based on Gitlab pages and we want to transfer over articles that are still relevant.
I have no strong opinion on that, but what about this idea: Allow up/down votes for individual questions and answers (a bit like stackexchange sites). Then remove those entries with significant down votes, while keeping those with up votes.
I think the idea was to keep all those that are still salvageable, just copy them over to the wiki and retire the FAQ software altogether. I'm afraid we don't have anyone willing to add new functionality to something that is essentially dead already.
Next step could be to add references to official documentation to the answers (a good exercise to check whether the documentation is clear and sufficient): When eventually deciding to retire the FAQ, integrate the remaining FAQs not answerable from the rest of the documentation into some other document.
That could still happen after we've migrated to the wiki?
Let us know what the pain points have been with OpenLDAP when you were just starting, right now and if you have a suggestion how to make it easier to start using it. Or if you wanted to contribute, has anything discouraged you?
Maybe some type of "Read me first" document that could contain a "decision flow graph" dealing with a new installation or an upgrade.
That sounds good in principle. Would you be willing to drive this?
Thanks ever so much for reading this far. This email is long enough already so I will follow up with another one about my long term plans to overhaul the test infrastructure and other tools that might be worth introducing to help with setting up and managing OpenLDAP deployments.
What I don't like is the strong focus on one (LMDB) database backend, despite of all the stupid things Oracle does.
There are big issues with the two BerkeleyDB backends for many installations so it had to be abandoned. I'll let Howard or Quanah take this part of the discussion further should they choose to.
Unfortunately, no other backend is in shape to be useable as a main database in production.
Thanks,
Ondrej Kuzník ondra@mistotebe.net schrieb am 25.07.2019 um 11:12 in
Nachricht 20190725091220.o2ikgjeac5a626is@mistotebe.net:
On Thu, Jul 25, 2019 at 08:16:27AM +0200, Ulrich Windl wrote:
[...]
Maybe some type of "Read me first" document that could contain a "decision flow graph" dealing with a new installation or an upgrade.
That sounds good in principle. Would you be willing to drive this?
I could provide a graph (and maybe some text) once I know what the decisions to make are. I don't feel compentent enough to start such a thing from nothing.
[...]
Regards, Ulrich
On Thu, Jul 25, 2019 at 12:03:55PM +0200, Ulrich Windl wrote:
Ondrej Kuzník ondra@mistotebe.net schrieb am 25.07.2019 um 11:12 in Nachricht 20190725091220.o2ikgjeac5a626is@mistotebe.net:
On Thu, Jul 25, 2019 at 08:16:27AM +0200, Ulrich Windl wrote:
Maybe some type of "Read me first" document that could contain a "decision flow graph" dealing with a new installation or an upgrade.
That sounds good in principle. Would you be willing to drive this?
I could provide a graph (and maybe some text) once I know what the decisions to make are. I don't feel compentent enough to start such a thing from nothing.
You can start with a bunch of user stories or something similar and I'm sure we can help iterate and fill in the blanks as we go.
Thanks,
--On Thursday, July 25, 2019 12:12 PM +0200 Ondřej Kuzník ondra@mistotebe.net wrote:
What I don't like is the strong focus on one (LMDB) database backend, despite of all the stupid things Oracle does.
There are big issues with the two BerkeleyDB backends for many installations so it had to be abandoned. I'll let Howard or Quanah take this part of the discussion further should they choose to.
Unfortunately, no other backend is in shape to be useable as a main database in production.
BerkeleyDB 6 and later are not license compatible with OpenLDAP. Thus one of the "stupid" things Oracle did is ensure the removal of the back-bdb and back-hdb backends from OpenLDAP as well as BerkeleyDB from numerous other pieces of software. It has already been noted that back-bdb/hdb are deprecated and that the supported primary database backend going forward from that point was back-mdb.
More to the point, as this email is discussing OpenLDAP 2.5, there will be no back-bdb/hdb after OpenLDAP 2.4. They've already been removed from openldap-master. One thing there that would be helpful is ensuring that all references to them have been removed from the documentation in master.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Quanah Gibson-Mount quanah@symas.com schrieb am 25.07.2019 um 16:31 in
Nachricht <2537EDE10877E990D54B64FF@[192.168.1.39]>:
--On Thursday, July 25, 2019 12:12 PM +0200 Ondřej Kuzník ondra@mistotebe.net wrote:
What I don't like is the strong focus on one (LMDB) database backend, despite of all the stupid things Oracle does.
There are big issues with the two BerkeleyDB backends for many installations so it had to be abandoned. I'll let Howard or Quanah take this part of the discussion further should they choose to.
Unfortunately, no other backend is in shape to be useable as a main database in production.
BerkeleyDB 6 and later are not license compatible with OpenLDAP. Thus one of the "stupid" things Oracle did is ensure the removal of the back-bdb and
back-hdb backends from OpenLDAP as well as BerkeleyDB from numerous other pieces of software. It has already been noted that back-bdb/hdb are deprecated and that the supported primary database backend going forward from that point was back-mdb.
But if the license is the only problem, users still could use an older version ("last good") of BDB. To me I always had the impression that you want to push MDB, not because it's better, but because it's yours. Personally I think users should be able to decide which database they prefer. Ironically many users are using Oracle databases, because some software vendors don't leave customers a choice...
More to the point, as this email is discussing OpenLDAP 2.5, there will be no back-bdb/hdb after OpenLDAP 2.4. They've already been removed from openldap-master. One thing there that would be helpful is ensuring that all references to them have been removed from the documentation in master.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--On Monday, July 29, 2019 9:51 AM +0200 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
back-hdb backends from OpenLDAP as well as BerkeleyDB from numerous other pieces of software. It has already been noted that back-bdb/hdb are deprecated and that the supported primary database backend going forward from that point was back-mdb.
But if the license is the only problem, users still could use an older version ("last good") of BDB. To me I always had the impression that you want to push MDB, not because it's better, but because it's yours. Personally I think users should be able to decide which database they prefer. Ironically many users are using Oracle databases, because some software vendors don't leave customers a choice...
And that is what has been done for all of the OpenLDAP 2.4 series. Keep in mind that this license change is over 6 years old. Additionally, the OpenLDAP project has a very long history of updating what backends are supported to move with times and technology.
With OpenLDAP 2.0, the primary backend was back-ldbm. OpenLDAP 2.1 introduced the back-bdb backend, which was a significant step up from back-ldbm. I helped pioneer the usage of back-bdb in a large scale production environment when I worked for Stanford University back around 2002. OpenLDAP 2.2 introduced back-hdb, and again I helped pioneer its usage in a large scale production environment as part of my job at Stanford.
I also helped test the initial iterations of syncrepl in OpenLDAP 2.2 (which was definitely not ready to be a replacement for slurpd at that time), and similarly did that with the rewrite of syncrepl for OpenLDAP 2.3. Delta-syncrepl was specifically devised because of the issues I hit with syncrepl in OpenLDAP 2.3.
Back-bdb was already deprecated going into OpenLDAP 2.4, and the license changes by Oracle forced everyone's hand into looking for replacement solutions. While I as at Zimbra, I again spearheaded the use of back-lmdb in large scale production environments. I.e., this is simply a part of a the continuous history of the OpenLDAP project adapting its technologies to what is best available.
There is no good reason to keep support for back-bdb or back-hdb at this point, regardless of the license change. They simply do not offer the read or write performance that back-lmdb offers, and they require significant and extensive tuning to even be remotely usable in even a medium scale deployment of few 100k entries. However, the fact that the license did change over 6 years ago has only hastened the inevitable.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Quanah Gibson-Mount quanah@symas.com schrieb am 29.07.2019 um 17:02 in
Nachricht <4DD781BA4B249F2380158513@[192.168.1.39]>:
‑‑On Monday, July 29, 2019 9:51 AM +0200 Ulrich Windl <Ulrich.Windl@rz.uni‑regensburg.de> wrote:
[...]
There is no good reason to keep support for back‑bdb or back‑hdb at this point, regardless of the license change. They simply do not offer the read
or write performance that back‑lmdb offers, and they require significant and extensive tuning to even be remotely usable in even a medium scale deployment of few 100k entries. However, the fact that the license did change over 6 years ago has only hastened the inevitable.
Our LDAP server runs on a virtual machine together with an Apache web-server that generates a lot of graphics on the fly. The VM has about 700 MB RAM, the LDAP server has about 20000 entries, two databases and a dozen of indexes. The databases need 163MB on disk for the hdb database. The LDIF database dump has 153kB for config and 11MB for data, and the database is older than 6 years. So I think BDB/HDB are rather space-efficient.
I doubt that a busy LMDB will be happy which that little disk space after six years of changes. That's my major point against LMDB. I'm not saying that LMDB has no customers that really need it, but to be it seems a bit like overkill.
Apache eats about 150 MB virtual mem (5 MB resident), slapd 1.3GB virtual mem (77MB resident). I'm afraid LMDB will "eat up" much more RAM.
Don't get me wrong: We can make it big (CPUs, RAM, Disks, energy consumption ,cooling requirement), but isn't "making it small" more of an art? Today's software mostly isn't "using a lot of memory" but rather "wasting a lot of memory" IMHO.
Regards, Ulrich "What can we do to save the earth?"
--On Tuesday, July 30, 2019 12:20 PM +0200 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
Don't get me wrong: We can make it big (CPUs, RAM, Disks, energy consumption ,cooling requirement), but isn't "making it small" more of an art? Today's software mostly isn't "using a lot of memory" but rather "wasting a lot of memory" IMHO.
LMDB uses significantly *fewer* resources than back-bdb/hdb.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On 7/30/19 11:20 AM, Ulrich Windl wrote:
Don't get me wrong: We can make it big (CPUs, RAM, Disks, energy consumption ,cooling requirement), but isn't "making it small" more of an art? Today's software mostly isn't "using a lot of memory" but rather "wasting a lot of memory" IMHO.
lmdb's memory and disk footprint is small. My Æ-DIR development VMs are really small (~200 MB RAM) and there are various web components running on the providers.
I even tested this stuff with Raspberry PI model 1. And it did not consume too much resources. (Of course SD cards have really slow disk I/O.)
AFAICS there is only one case where back-mdb is significantly slower than back-hdb: ITS#8875. But this is actively worked on.
So stop spreading FUD about lmdb. If you provide real-world evidence that back-mdb consumes more resources than back-hdb then present seriously worked out test results.
Ciao, Michael.
Michael Ströder michael@stroeder.com schrieb am 30.07.2019 um 16:42 in
Nachricht 2205c354-382e-bcce-3c8f-f3d852752e2d@stroeder.com:
On 7/30/19 11:20 AM, Ulrich Windl wrote:
Don't get me wrong: We can make it big (CPUs, RAM, Disks, energy
consumption
,cooling requirement), but isn't "making it small" more of an art? Today's software mostly isn't "using a lot of memory" but rather "wasting a lot of memory" IMHO.
lmdb's memory and disk footprint is small. My Æ-DIR development VMs are really small (~200 MB RAM) and there are various web components running on the providers.
I even tested this stuff with Raspberry PI model 1. And it did not consume too much resources. (Of course SD cards have really slow disk I/O.)
AFAICS there is only one case where back-mdb is significantly slower than back-hdb: ITS#8875. But this is actively worked on.
So stop spreading FUD about lmdb. If you provide real-world evidence
Actually this just is the impression I got reading this list. I read a lot about running out of memory, having rebuild the databases as they grow out of bounds, having a database size three time the data size, lock-ups, and all the stuff. I'm not spreading FUD. I'm just worried from what I read here.
that back-mdb consumes more resources than back-hdb then present seriously worked out test results.
Ciao, Michael.
On 7/31/19 7:51 AM, Ulrich Windl wrote:
Michael Ströder michael@stroeder.com schrieb am 30.07.2019
So stop spreading FUD about lmdb.
Actually this just is the impression I got reading this list. I read a lot about running out of memory, having rebuild the databases as they grow out of bounds, having a database size three time the data size, lock-ups, and all the stuff.> I'm not spreading FUD. I'm just worried from what I read here.
You just have an "impression" and no real proofs. You don't even point to postings in the mailing list archive.
So what you're writing is exactly that: FUD.
For example "having a database size three time the data size" says nothing without knowing the indexing configuration.
And the "grow out of bounds" is just that people don't understand that they have to properly set back-mdb's maxsize parameter and monitor the count of used pages. Just like you choose a disk partion size and then you monitor whether your file systems gets filled up. (BTW: Howard implemented slapd-monitor support for slapd-mdb which was released with 2.4.48, see ITS#7770).
Ulrich, even if I still assume good faith on your side and that you want to push things to be improved your postings are quite disrespectful. Such a behaviour does not help to improve free software projects.
Ciao, Michael.
Michael Ströder michael@stroeder.com schrieb am 31.07.2019 um 08:27 in
Nachricht 657e3778-2cd6-2025-c780-150ecd608cfc@stroeder.com:
On 7/31/19 7:51 AM, Ulrich Windl wrote:
Michael Ströder michael@stroeder.com schrieb am 30.07.2019
So stop spreading FUD about lmdb.
Actually this just is the impression I got reading this list. I read a lot about running out of memory, having rebuild the databases as they grow out of bounds, having a database size three time the data size, lock-ups, and all the stuff.> I'm not spreading FUD. I'm just worried
from what I read here.
You just have an "impression" and no real proofs. You don't even point to postings in the mailing list archive.
So what you're writing is exactly that: FUD.
For example "having a database size three time the data size" says nothing without knowing the indexing configuration.
And the "grow out of bounds" is just that people don't understand that they have to properly set back-mdb's maxsize parameter and monitor the count of used pages. Just like you choose a disk partion size and then you monitor whether your file systems gets filled up. (BTW: Howard implemented slapd-monitor support for slapd-mdb which was released with 2.4.48, see ITS#7770).
Ulrich, even if I still assume good faith on your side and that you want to push things to be improved your postings are quite disrespectful. Such a behaviour does not help to improve free software projects.
Well critical questions should be allowed (unless you live in China, Russia, ...). And I never said "holy crap" or "bullshit"... ;-)
Ciao, Michael.
On 7/31/19 8:38 AM, Ulrich Windl wrote:
Michael Ströder michael@stroeder.com schrieb am 31.07.2019 um 08:27 in
Ulrich, even if I still assume good faith on your side and that you want to push things to be improved your postings are quite disrespectful. Such a behaviour does not help to improve free software projects.
Well critical questions should be allowed (unless you live in China, Russia, ...). And I never said "holy crap" or "bullshit"... ;-)
This answer was somewhat expected.
You should dig the mailing list archives and the issue tracker. You will see I'm well-known to criticize many things here.
But if you want to be taken serious your criticism must be based on hard facts and not just blurry impressions.
Ciao, Michael.
--On Wednesday, July 31, 2019 8:51 AM +0200 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
Actually this just is the impression I got reading this list. I read a lot about running out of memory, having rebuild the databases as they grow out of bounds, having a database size three time the data size, lock-ups, and all the stuff. I'm not spreading FUD. I'm just worried from what I read here.
You are spreading FUD because you literally have no idea what you're talking about. Get some experience with back-mdb vs back-hdb/bdb. back-mdb does fragment. So do back-bdb & back-hdb. Outside of some issues when back-mdb was brand new, I've not had the corruption issues with it that I continually had with back-bdb/hdb. Additionally there are a number of known bugs in BDB and back-bdb/hdb themselves (particularly around cache misses) that simply do not exist in back-mdb.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On 30/07/2019 15:42, Michael Ströder wrote:
On 7/30/19 11:20 AM, Ulrich Windl wrote:
Don't get me wrong: We can make it big (CPUs, RAM, Disks, energy consumption ,cooling requirement), but isn't "making it small" more of an art? Today's software mostly isn't "using a lot of memory" but rather "wasting a lot of memory" IMHO.
lmdb's memory and disk footprint is small. My Æ-DIR development VMs are really small (~200 MB RAM) and there are various web components running on the providers.
I even tested this stuff with Raspberry PI model 1. And it did not consume too much resources. (Of course SD cards have really slow disk I/O.)
AFAICS there is only one case where back-mdb is significantly slower than back-hdb: ITS#8875. But this is actively worked on.
*cough* I think you mean ITS#7657 ;-) It's good to see work being done on this issue and I can report that the performance is massively improved in the current 2.4.48 RC release compared to 2.4.47.
We actually managed to move away from using aliases due to this issue and another issue (this time on HDB) where the whole system ground to a halt when you went over 64K alias entries. (See my email to the list on 16th Nov 2015- I thought I'd submitted an ITS but I can't find it ao maybe I didn't)
So stop spreading FUD about lmdb. If you provide real-world evidence that back-mdb consumes more resources than back-hdb then present seriously worked out test results.
Ciao, Michael.
With the exception of the issue above I've found back-mdb to require less maintenance and be less prone to deadlocking under load and corruption than back-bdb/hdb. Having the database backend built-in and updated also means one less package dependency to worry about ;-)
RE: the community engagement time permitting I'd be happy to look over/ help out with the web documentation. One thing that might be useful is some form of "cookbook" with recipes for setting up some common OpenLDAP configs (e.g. single node, 2-way MMR, n-way MMR, single-master with multiple replicas etc).
Kind regards,
Mark
On Wed, Jul 31, 2019 at 09:23:26AM +0100, Mark Cairney wrote:
RE: the community engagement time permitting I'd be happy to look over/ help out with the web documentation. One thing that might be useful is some form of "cookbook" with recipes for setting up some common OpenLDAP configs (e.g. single node, 2-way MMR, n-way MMR, single-master with multiple replicas etc).
I've always found the this section of the admin guide a bit lacking, but once I understood things a bit better, the bugs have always been more urgent. If you can find the time, that would be much appreciated. Feel free to get in touch over email/IRC and we'll help shed light on anything, there are many interactions not adequately explained anywhere as yet.
Thanks,
Ulrich Windl wrote:
Quanah Gibson-Mount quanah@symas.com schrieb am 25.07.2019 um 16:31 in
Nachricht <2537EDE10877E990D54B64FF@[192.168.1.39]>:
--On Thursday, July 25, 2019 12:12 PM +0200 Ondřej Kuzník ondra@mistotebe.net wrote:
What I don't like is the strong focus on one (LMDB) database backend, despite of all the stupid things Oracle does.
There are big issues with the two BerkeleyDB backends for many installations so it had to be abandoned. I'll let Howard or Quanah take this part of the discussion further should they choose to.
Unfortunately, no other backend is in shape to be useable as a main database in production.
BerkeleyDB 6 and later are not license compatible with OpenLDAP. Thus one of the "stupid" things Oracle did is ensure the removal of the back-bdb and
back-hdb backends from OpenLDAP as well as BerkeleyDB from numerous other pieces of software. It has already been noted that back-bdb/hdb are deprecated and that the supported primary database backend going forward from that point was back-mdb.
But if the license is the only problem, users still could use an older version ("last good") of BDB. To me I always had the impression that you want to push MDB, not because it's better, but because it's yours.
LMDB is demonstrably better than BDB in every way.
On 7/29/19 8:51 AM, Ulrich Windl wrote:
But if the license is the only problem, users still could use an older version ("last good") of BDB. To me I always had the impression that you want to push MDB, not because it's better, but because it's yours.
back-mdb is better. Especially since it's much simpler. Did you ever try to fine-tune the three cache levels of back-hdb?
Personally I think users should be able to decide which database they prefer.
First of all users are interested in getting work done no matter which backend has to be used for that.
So developers should hunk out obsolete database backends if the time has come to save their most valuable resource: Time.
Wasting time on maintaining obsolete stuff is just plain wrong.
Ciao, Michael.
Ulrich Windl wrote:
Ondrej Kuzník ondra@mistotebe.net schrieb am 24.07.2019 um 20:01 in
so I will follow up with another one about my long term plans to overhaul the test infrastructure and other tools that might be worth introducing to help with setting up and managing OpenLDAP deployments.
What I don't like is the strong focus on one (LMDB) database backend, despite of all the stupid things Oracle does.
The Oracle license change on BDB 6.x+ makes it illegal to use BDB in OpenLDAP. There is nothing else to discuss here.
Le 24/07/2019 à 20:01, Ondřej Kuzník a écrit :
Let us know what the pain points have been with OpenLDAP when you were just starting, right now and if you have a suggestion how to make it easier to start using it. Or if you wanted to contribute, has anything discouraged you? There are things we might not be able to influence easily (LDAP itself can be complex), but a fresh look might help direct efforts in the right direction.
Hello Ondřej,
thanks a lot for this mail. I hope that I can help OpenLDAP project the best I can.
I can work on website or documentation, let me know.
On Thu, Jul 25, 2019 at 10:14:36AM +0200, Clément OUDOT wrote:
Le 24/07/2019 à 20:01, Ondřej Kuzník a écrit :
Let us know what the pain points have been with OpenLDAP when you were just starting, right now and if you have a suggestion how to make it easier to start using it. Or if you wanted to contribute, has anything discouraged you? There are things we might not be able to influence easily (LDAP itself can be complex), but a fresh look might help direct efforts in the right direction.
thanks a lot for this mail. I hope that I can help OpenLDAP project the best I can.
I can work on website or documentation, let me know.
Hi Clément, if you wanted to get started now, website would be the more important of the two. The main issue is that if someone's landed there for the first time, they expect to find something completely different (latest version download link, news, ...?) Don't know what's the best course of action, so will leave that up to you and others.
AFAIK the git repo here reflects exactly what is served? https://www.openldap.org/devel/gitweb.cgi?p=openldap-www.git
An evolution on the caterpillar might also be considered at some point.
If you wanted to review documentation, pick a task and we can help from there :)
Le 25/07/2019 à 10:43, Ondřej Kuzník a écrit :
On Thu, Jul 25, 2019 at 10:14:36AM +0200, Clément OUDOT wrote:
Le 24/07/2019 à 20:01, Ondřej Kuzník a écrit :
Let us know what the pain points have been with OpenLDAP when you were just starting, right now and if you have a suggestion how to make it easier to start using it. Or if you wanted to contribute, has anything discouraged you? There are things we might not be able to influence easily (LDAP itself can be complex), but a fresh look might help direct efforts in the right direction.
thanks a lot for this mail. I hope that I can help OpenLDAP project the best I can.
I can work on website or documentation, let me know.
Hi Clément, if you wanted to get started now, website would be the more important of the two. The main issue is that if someone's landed there for the first time, they expect to find something completely different (latest version download link, news, ...?) Don't know what's the best course of action, so will leave that up to you and others.
AFAIK the git repo here reflects exactly what is served? https://www.openldap.org/devel/gitweb.cgi?p=openldap-www.git
An evolution on the caterpillar might also be considered at some point.
If you wanted to review documentation, pick a task and we can help from there :)
Great, I'll do it as soon as possible, but will be after my vacations ;)
Clément.
* Ondřej Kuzník [24/07/2019 20:01] :
Another issue frustrating both users and contributors to the project has been the existing jitterbugs bug tracker (a.k.a. ITS), which has by now outlived its usefulness. Plans to move to a project-hosted Gitlab instance + Bugzilla (via Gitlab's built in Bugzilla integration) are being made and this should make the
If you need help maintaining Bugzilla or migrating the existing issues into it, please don't hesitate to ping me.
Emmanuel
On Jul 24, 2019, at 14:01, Ondřej Kuzník ondra@mistotebe.net wrote:
[…]
In general, moving to Gitlab should let us integrate CI much better, especially if there are people willing to integrate and manage external runners. As mentioned above, we could definitely do with more regular testing on non-Linux platforms, e.g. *BSD or Windows+MSYS2. Pull requests might then also be automatically tested.
FreeBSD has a team dedicated to building third-party packages (“Ports”):
https://www.freebsd.org/portmgr/index.html https://www.freshports.org/net/openldap24-server/
You may wish to contact them, and/or the OpenLDAP port maintainer, about ways to set up build environments and what they do already:
https://www.freebsd.org/doc/handbook/ports-poudriere.html
Let us know what the pain points have been with OpenLDAP when you were just starting, right now and if you have a suggestion how to make it easier to start using it. Or if you wanted to contribute, has anything discouraged you? There are things we might not be able to influence easily (LDAP itself can be complex), but a fresh look might help direct efforts in the right direction.
You mention binary packages on the website:
http://www.openldap.org/faq/data/cache/108.html
And yet when people come to this list, the response is often “that’s an old version, you need to upgrade”, especially for Red Hat.
While things like MariaDB/PostgreSQL packages are in various distros, those projects provide repos that people can use with yum/apt to get the latest versions. Providing ‘official’ first-party packages, at least for RHEL/CentOS and perhaps Ubuntu (LTS), would go a long way towards allowing people to have all the newest bug fixes.
Having predictable, time-based releases would also help admins and distributions keep up to date. Past releases:
OpenLDAP 2.4.48 (2019/07/24) OpenLDAP 2.4.47 (2018/12/19) -7 months OpenLDAP 2.4.46 (2018/03/22) -9 months OpenLDAP 2.4.45 (2017/06/01) -9 months OpenLDAP 2.4.44 (2016/02/05) -16 months OpenLDAP 2.4.43 (2015/11/30) -3 months OpenLDAP 2.4.42 (2015/08/14) -3 months OpenLDAP 2.4.41 (2015/06/21) -2 months
So 2015 was quite product, but most of 2016-2017... not so much.
I mentioned this last year:
https://www.openldap.org/lists/openldap-technical/201807/threads.html#00005
I have no idea what the the best schedule (annual, biannual, other) would be, but anything would be an improvement over sleep(rand()).
--On Tuesday, August 06, 2019 9:27 PM -0400 David Magda dmagda@ee.ryerson.ca wrote:
You mention binary packages on the website:
The FAQ explicitly states:
"Official releases are in source form only." I don't know how that could be any clearer.
While things like MariaDB/PostgreSQL packages are in various distros, those projects provide repos that people can use with yum/apt to get the latest versions. Providing 'official' first-party packages, at least for RHEL/CentOS and perhaps Ubuntu (LTS), would go a long way towards allowing people to have all the newest bug fixes.
Ryan Tandy already provides backports for Ubuntu: https://launchpad.net/~rtandy/+archive/ubuntu/openldap-backports
The LTB project already provides builds for RHEL7: https://ltb-project.org/documentation/openldap-rpm#yum_repository
Symas already provides a freedrop in replacements for RHEL7, with optional support: https://symas.com/linuxopenldap/
People who write the list are already provided the information on these options. What would the project having yet another build of the same things provide?
So 2015 was quite product, but most of 2016-2017... not so much.
2015 had a lot of serious bugs in its release, the releases were rushed, and the result of rushing was bad. I don't think 2015 is a "good" example of how things should be done.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On Aug 7, 2019, at 00:24, Quanah Gibson-Mount quanah@symas.com wrote:
--On Tuesday, August 06, 2019 9:27 PM -0400 David Magda dmagda@ee.ryerson.ca wrote:
You mention binary packages on the website:
The FAQ explicitly states:
"Official releases are in source form only." I don't know how that could be any clearer.
Yes, I’m sure all the people who I have seen come to this list running an older, distro-supplied RPM/Deb have read that, ignored it, and posted anyways thinking “surely they can’t be serious”. As an admin I know that all / most of the software in a distro is out-of-date, but there are not enough hours in the day to compile-from-source all the software that is used: that’s why distros were invented in the first place, to save everyone time.
People who write the list are already provided the information on these options. What would the project having yet another build of the same things provide?
Perhaps all of these people started providing these binaries because the project itself didn’t / doesn’t? Maybe all of those other efforts could be refocused to build binaries served from (say) repos.openldap.org. The infrastructure seems to already be present: perhaps it just needs to be centralized / concentrated?
So 2015 was quite product, but most of 2016-2017... not so much.
2015 had a lot of serious bugs in its release, the releases were rushed, and the result of rushing was bad. I don't think 2015 is a "good" example of how things should be done.
That is an argument for timed releases. The OpenBSD project is a good example: they release twice a year. If a feature cannot be made stable in time for one release, they either back it out or do not commit in the first place, and simply try to make it work for the following one. There is actually less pressure to force a feature (that may or may not be ready) in a particular release, because the next one will be along shortly. When releases are ad hoc, there is actually more pressure because people start thinking “if we don’t get it in this release, who knows when the next opportunity will be”.
On 8/7/19, David Magda dmagda@ee.ryerson.ca wrote:
That is an argument for timed releases. The OpenBSD project is a good example: they release twice a year. If a feature cannot be made stable in time for one release, they either back it out or do not commit in the first place, and simply try to make it work for the following one. There is actually less pressure to force a feature (that may or may not be ready) in a particular release, because the next one will be along shortly. When releases are ad hoc, there is actually more pressure because people start thinking “if we don’t get it in this release, who knows when the next opportunity will be”.
It is also an argument for external funding, because the team involved needs to be sponsored when release time comes. Who will then ensure the type of sponsorship that does not dry up at a bad moment?
Lucio.
--On Wednesday, August 7, 2019 8:08 AM -0400 David Magda dmagda@ee.ryerson.ca wrote:
People who write the list are already provided the information on these options. What would the project having yet another build of the same things provide?
Perhaps all of these people started providing these binaries because the project itself didn't / doesn't? Maybe all of those other efforts could be refocused to build binaries served from (say) repos.openldap.org. The infrastructure seems to already be present: perhaps it just needs to be centralized / concentrated?
The LTB project bundles some additional functionality of its own with its builds, and is specificaly designed to be separate from the system level installation. It also does things like link against the OpenLDAP recommended TLS libraries (OpenSSL).
For RHEL, RedHat has made it quite clear they have no interest in bundling OpenLDAP nor maintaining it (it does compete with their 389DS and RHDS products, after all). They also made the mistake of writing their own code to link against MozNSS for the majority of RHEL7 against the advice of the OpenLDAP project. Another issue with the RHEL builds is they default to using the deprecated back-hdb backend, etc.
Debian/Ubuntu continue to link to GnuTLS for theoretical licensing reasons with OpenSSL. However with the OpenSSL license change with OpenSSL 3.0 this hopefully will no longer be the case.
I.e., 'providing' a build of OpenLDAP has a number of complexities. If the OpenLDAP project were to do such a thing, should it only provides linked to OpenSSL? If so, what version of OpenSSL? Should it have SASL capabilities (linking to cyrus-sasl)? Should it provide SASL/GSSAPI? If so, which Kerberos library? Should those builds provide experimental backends like back-sql or only fully supported backends?
Quite frankly, the project developers are spread thin on time as it is now. Taking on the burden of then trying to support X random user's needs or complaints is not particularly enticing. With the source, they can build OpenLDAP exactly the way *they* need it to be built.
So 2015 was quite product, but most of 2016-2017... not so much.
2015 had a lot of serious bugs in its release, the releases were rushed, and the result of rushing was bad. I don't think 2015 is a "good" example of how things should be done.
That is an argument for timed releases.
I fail to see how that's the case. What I see is that we need to:
a) Ensure we have CI/CD
and
b) Better/expanded test cases & databases to validate against
and
c) more participation from the community in testing/validating new features and code fixes.
Just throwing out a new release every 6 months doesn't help with any of the above.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On 8/9/19 1:47 AM, Quanah Gibson-Mount wrote:
--On Wednesday, August 7, 2019 8:08 AM -0400 David Magda dmagda@ee.ryerson.ca wrote: I.e., 'providing' a build of OpenLDAP has a number of complexities.
Full ack.
It's really hard to decide what is needed in a package.
Linux distributions tend to enable all features to please everybody. But for highly secured systems it is mandatory to disable unneeded functionality. E.g. I'm maintaining the full-featured builds for openSUSE but personally I'm using stripped down builds without all deprecated backends.
Also Linux distros implement pseudo config management in there packages which trys to create a default config. Mostly this defeats serious deployments using a decent config management. I saw production systems break after a "yum update" or "apt-get upgrade" because of overzealous package post installation tasks.
2015 had a lot of serious bugs in its release, the releases were rushed, and the result of rushing was bad. I don't think 2015 is a "good" example of how things should be done.
That is an argument for timed releases.
I fail to see how that's the case.
Me too. Especially because timed releases can also lead to some kind of rush before the release date.
What I see is that we need to: a) Ensure we have CI/CD and b) Better/expanded test cases & databases to validate against and c) more participation from the community in testing/validating new features and code fixes.
Again, full ack here.
Ciao, Michael.
Michael Ströder michael@stroeder.com schrieb am 09.08.2019 um 08:00 in
Nachricht c682ab67-5216-0bc4-d4fa-5ca85e2e8372@stroeder.com:
On 8/9/19 1:47 AM, Quanah Gibson-Mount wrote:
--On Wednesday, August 7, 2019 8:08 AM -0400 David Magda dmagda@ee.ryerson.ca wrote: I.e., 'providing' a build of OpenLDAP has a number of complexities.
Full ack.
It's really hard to decide what is needed in a package.
Linux distributions tend to enable all features to please everybody. But for highly secured systems it is mandatory to disable unneeded functionality. E.g. I'm maintaining the full-featured builds for openSUSE but personally I'm using stripped down builds without all deprecated backends.
Also Linux distros implement pseudo config management in there packages which trys to create a default config. Mostly this defeats serious deployments using a decent config management. I saw production systems break after a "yum update" or "apt-get upgrade" because of overzealous package post installation tasks.
Yes, we also run an installation on SLES that the SLES configuration tool (yast) cannot handle any more...
2015 had a lot of serious bugs in its release, the releases were rushed, and the result of rushing was bad. I don't think 2015 is a "good" example of how things should be done.
That is an argument for timed releases.
I fail to see how that's the case.
Me too. Especially because timed releases can also lead to some kind of rush before the release date.
What I see is that we need to: a) Ensure we have CI/CD and b) Better/expanded test cases & databases to validate against and c) more participation from the community in testing/validating new features and code fixes.
Again, full ack here.
Ciao, Michael.
Quanah Gibson-Mount quanah@symas.com schrieb am 09.08.2019 um 01:47 in
Nachricht <1AB0E954D8914B6FF6B9655F@[192.168.1.144]>:
‑‑On Wednesday, August 7, 2019 8:08 AM ‑0400 David Magda dmagda@ee.ryerson.ca wrote:
People who write the list are already provided the information on these options. What would the project having yet another build of the same things provide?
Perhaps all of these people started providing these binaries because the project itself didn't / doesn't? Maybe all of those other efforts could be refocused to build binaries served from (say) repos.openldap.org. The infrastructure seems to already be present: perhaps it just needs to be centralized / concentrated?
The LTB project bundles some additional functionality of its own with its builds, and is specificaly designed to be separate from the system level installation. It also does things like link against the OpenLDAP recommended TLS libraries (OpenSSL).
For RHEL, RedHat has made it quite clear they have no interest in bundling OpenLDAP nor maintaining it (it does compete with their 389DS and RHDS products, after all). They also made the mistake of writing their own code
to link against MozNSS for the majority of RHEL7 against the advice of the OpenLDAP project. Another issue with the RHEL builds is they default to using the deprecated back‑hdb backend, etc.
Debian/Ubuntu continue to link to GnuTLS for theoretical licensing reasons with OpenSSL. However with the OpenSSL license change with OpenSSL 3.0 this hopefully will no longer be the case.
I.e., 'providing' a build of OpenLDAP has a number of complexities. If the
OpenLDAP project were to do such a thing, should it only provides linked to
OpenSSL? If so, what version of OpenSSL? Should it have SASL capabilities (linking to cyrus‑sasl)? Should it provide SASL/GSSAPI? If so, which Kerberos library? Should those builds provide experimental backends like back‑sql or only fully supported backends?
Quite frankly, the project developers are spread thin on time as it is now.
Taking on the burden of then trying to support X random user's needs or complaints is not particularly enticing. With the source, they can build OpenLDAP exactly the way *they* need it to be built.
So 2015 was quite product, but most of 2016‑2017... not so much.
2015 had a lot of serious bugs in its release, the releases were rushed, and the result of rushing was bad. I don't think 2015 is a "good" example of how things should be done.
That is an argument for timed releases.
I fail to see how that's the case. What I see is that we need to:
a) Ensure we have CI/CD
I wonder: Doesn't CI provide "builds" as a by-product? What configuration options are used for those builds? Couldn't that simpley produce an "OpenLDAP nightly" (similar to Mozilla's Firefox)?
and
b) Better/expanded test cases & databases to validate against
and
c) more participation from the community in testing/validating new features
and code fixes.
Just throwing out a new release every 6 months doesn't help with any of the
above.
‑‑Quanah
‑‑
Quanah Gibson‑Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--On Monday, August 12, 2019 9:03 AM +0200 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
a) Ensure we have CI/CD
I wonder: Doesn't CI provide "builds" as a by-product? What configuration options are used for those builds? Couldn't that simpley produce an "OpenLDAP nightly" (similar to Mozilla's Firefox)?
It results in compiled binaries, it does not result in a packaged product.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On 8/12/19 8:03 AM, Ulrich Windl wrote:
I wonder: Doesn't CI provide "builds" as a by-product? What configuration options are used for those builds? Couldn't that simpley produce an "OpenLDAP nightly" (similar to Mozilla's Firefox)?
Yes, it's possible.
But the question is whether the OpenLDAP project wants to take the burden supporting the binary builds. The current answer is no.
Ciao, Michael.
Its really easy to build your own, and there also lots of great distro’s that have a good build , I’m using the debian build , and it works just fine.
On Aug 12, 2019, at 9:31 AM, Michael Ströder michael@stroeder.com wrote:
On 8/12/19 8:03 AM, Ulrich Windl wrote:
I wonder: Doesn't CI provide "builds" as a by-product? What configuration options are used for those builds? Couldn't that simpley produce an "OpenLDAP nightly" (similar to Mozilla's Firefox)?
Yes, it's possible.
But the question is whether the OpenLDAP project wants to take the burden supporting the binary builds. The current answer is no.
Ciao, Michael.
Michael Ströder michael@stroeder.com schrieb am 12.08.2019 um 18:31 in
Nachricht 2d8bb110-94a0-509d-9616-d31b62ca8726@stroeder.com:
On 8/12/19 8:03 AM, Ulrich Windl wrote:
I wonder: Doesn't CI provide "builds" as a by-product? What configuration options are used for those builds? Couldn't that simpley produce an
"OpenLDAP
nightly" (similar to Mozilla's Firefox)?
Yes, it's possible.
But the question is whether the OpenLDAP project wants to take the burden supporting the binary builds. The current answer is no.
I did not have a "package solution" in mind, but a scenario like this: Some one is reporting problems with the current version. It could be advisable to exchange the binary with a recently built one (subject to experienced admins who run backups) to see if it makes a difference.
As for Mozilla's nightlys: The Linux versions at least are just tar archives that you can unpack and run from any directory. I didn't examine OpenLDAP whether it can (easily) be run from any sub-directory tree, however...
Ciao, Michael.
--On Tuesday, August 13, 2019 10:09 AM +0200 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
I did not have a "package solution" in mind, but a scenario like this: Some one is reporting problems with the current version. It could be advisable to exchange the binary with a recently built one (subject to experienced admins who run backups) to see if it makes a difference.
There's no way the OpenLDAP project could know if such a binary would be compatible with whatever build they're running.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
openldap-technical@openldap.org
-
Clément OUDOT -
David Magda -
Emmanuel Seyman -
Howard Chu -
Lucio De Re -
Mark Cairney -
Michael Ströder -
Neal Lawson -
Ondřej Kuzník -
Quanah Gibson-Mount -
Ulrich Windl