GNOME Bugzilla – Bug 424459
ekiga.net has weird search behaviour
Last modified: 2020-06-06 16:31:17 UTC
As Luc found out, doing something like : ldapsearch -h ldap.ekiga.net -x -b "dc=ekiga,dc=net" '(cn=foo)' will do a proper search, while : ldapsearch -h ldap.ekiga.net -x -b "dc=ekiga,dc=net" '(givenName=foo)' just returns 100 results, as if there was no search. This is where my new LDAP code gets bitten. I now have a workaround, but still.
The ldap server seems to have been modified so a search on (cn=foo) is really a search on ((cn=*foo*)|(givenname=*foo*)) But the search on (givenname=foo) seems to be broken. And doesn't do anything. btw: the email is plain readeable
Yes there is a broken PERL back-end derivated from Paul's work. I don't have the time to maintain it, so, except if anyone steps up, it will be marked as WONTFIX.
About the email : we've had a report once, which we closed because people knowingly register and publish, but now I wonder if it's serious :-/
I thought the perl backend was for ILS !?
It is still being used to read in the SQL databases of SER. The problem is that the native SQL backend of OpenLDAP was really crappy, and the server was overloaded all the time. So I had to find a hack !
You said "was" ; did it get better ?
else is it possible to have the source of the perl code ? to try to fix the bug ?
Luc, perl code is written, never read. ;-)
I can take a look at it for you. I just did an ldapsearch at ldap.ekiga.net just now, it is definitely wacked...
Ekiga.net is not real LDAP. It is a complete hack. The problem is that the mysql openldap backend does not support the high load on the server, so we had to write a hack involving a perl back-end and that hack is really bad. The ideal would be to use the mysql openldap backend.
Would postgresql do better?
In general definitely (far) better. But I don't think this particular problem stands and falls with the DB system. J.
It is an OpenLDAP backend problem. But I think it has been rewritten since our last try.
(In reply to comment #13) > It is an OpenLDAP backend problem. But I think it has been rewritten since our > last try. > It's received a variety of updates, sure. We'd have to profile it to see if it's actually improved enough for this purpose. I should point out that OpenLDAP 2.4.12 (due to be released in the next couple days) has a new back-ndb backend that talks natively to MySQL's NDB storage engine (no SQL translation layer involved). The tables that it uses can be accessed simultaneously from both SQL and LDAP with no performance penalty on either side. But you'll need to make sure that new entries are only created from the LDAP side. (Should be no problem to make your account registration web page use LDAP, right?)
It would be a huge change :-/
Yes, but if on the one hand we have ekiga.net with a strange-LDAP and on the other hand a vast number of really-LDAP servers, what should our LDAP::Book code do? Isn't fixing ekiga.net the path of least resistance *and* higher sanity?
If someone does it, why not. But I would not change the webpages to use LDAP. I would keep MySQL as it is what all of our SIP servers use. The best is to have a real LDAP frontend with SQL as backend. Not the opposite.
What do you mean the opposite? The back-ndb solution is a real LDAP frontend and a real SQL backend. (Actually, a lower level backend, but SQL will still work with it transparently.) The SIP servers can continue to operate as they have; why does it matter to them what the web page uses?
Why can't we use mysql to modify the table ? If the SIP Server modifies some of the tables, does that mean those modifications can not be seen using the LDAP server ndb back-end ?
You can perform most modifications from either LDAP or SQL. But the LDAP side also uses some auxiliary tables that your SQL apps will know nothing about. When inserting new records into the database, both the main table and the auxiliary table must be updated. But if you're just modifying existing records, there's no restriction.
What is the status of this bug?
Any news about this bug?
k, I'm closing this bug for good. If you have any problems, please open a new bug and let's hope that it won't go mad ;)
Hi, We will rework ekiga.net. This will extend wht users can do with their account. I really need to know how to integrate the LDAP stuff in. Damien, please comment how to have all this properly integrated because a of now I've no idea how the LDAP stuff work with ekiga.net. Best regards, Yannick
Ekiga is not under active development anymore: https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/273 Ekiga saw its last release 7 years ago. The last code commits were 4 years ago. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (and transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active Ekiga development again in the future.