GNOME Bugzilla – Bug 618978
ldap contacts birthdays do not show up on the calendar
Last modified: 2010-06-07 08:15:56 UTC
This is sort of an issue that happens 90% percent of the time and sometimes it works. After wasting hours with evo and my openldap server logs, I was able to establish a link between the problem and the ldap server logs, well at least I hope so. After starting to use evolution, my ldap server logs started to contain error messages saying "get_filter: unknown filter type=48". After increasing the log level of my ldap servers, I found out that evo sends an ill-formed filter to the ldap server, which is according to the ldap logs is the following: "(?=undefined)" So, I believe that the solution to my problem lies somewhere in evo code which sends the above filter to the ldap server.
Thanks for a bug report. What is your exact version of evolution/evolution-data-server, please? From Evolution you can Help->About, to see it.
evolution: 2.30.1.2 e-d-s: 2.30.1
Created attachment 161576 [details] eds debug patch for evolution-data-server; I hope you can compile evolution-data-server, as this is a debug patch for you, to give it a try. It doesn't do much, it only disables most of ldap debug prints and adds there some valueable for this issue. You might see lines like ** e_book_backend_ldap_search: invoking LDAP search with '(cn=*)' on e-addressbook-factory console. It adds one testing facility, when there is set the environment variable LDAP_OBJCLS (to any value), then for browsing the addressbook is not used the above (cn=*) filter, but (objectclass=*), which is used on couple other places, thus should be supported by the server. Note that when you run evolution in the Contacts view, then selecting this address book should show you the contacts, where I guess it will not for you, due to the error on the server. You should have e-addressbook-factory located either in /usr/libexec or /usr/lib, depends on your distribution (or if you use other prefix when compiling evolution-data-server, then there in libexec or lib directory). There cannot run two e-addressbook-factory -ies at the same time, when you'll try to do that the later will abort. One possible test, out of evolution, I think of, is to try ldapsearch with the query of (cn=*) on your server, whether it'll show anything or not.
(In reply to comment #3) > Created an attachment (id=161576) [details] > eds debug patch > > for evolution-data-server; > > I hope you can compile evolution-data-server, as this is a debug patch for you, > to give it a try. It doesn't do much, it only disables most of ldap debug > prints and adds there some valueable for this issue. You might see lines like > ** e_book_backend_ldap_search: invoking LDAP search with '(cn=*)' > on e-addressbook-factory console. It adds one testing facility, when there is > set the environment variable LDAP_OBJCLS (to any value), then for browsing the > addressbook is not used the above (cn=*) filter, but (objectclass=*), which is > used on couple other places, thus should be supported by the server. > > Note that when you run evolution in the Contacts view, then selecting this > address book should show you the contacts, where I guess it will not for you, > due to the error on the server. > > You should have e-addressbook-factory located either in /usr/libexec or > /usr/lib, depends on your distribution (or if you use other prefix when > compiling evolution-data-server, then there in libexec or lib directory). > There cannot run two e-addressbook-factory -ies at the same time, when you'll > try to do that the later will abort. > > One possible test, out of evolution, I think of, is to try ldapsearch with the > query of (cn=*) on your server, whether it'll show anything or not. Hi, After reading your message, I am not so sure that I've made myself absolutely clear. I have no problems with this ldap addressbook. It works ok for searching or browsing contacts. I can also see the bdays of contacts and change them etc. in the properties window of that contact. The only thing that is not working properly/consistently is the displaying of bdays in the calendar.
Sorry, I will have to object to my own post above! I restarted evolution after disabling "show bdays from this adressbook" setting. Here is the log info from the ldap server. As you can see, the same error exists still, where it says "unknown filter type=48" and then it closes the connection and then evo reconnects... May 25 11:23:41 gollum slapd[6246]: conn=225 fd=13 ACCEPT from IP=78.165.108.42:56470 (IP=0.0.0.0:636) May 25 11:23:41 gollum slapd[6246]: conn=225 fd=13 TLS established tls_ssf=128 ssf=128 May 25 11:23:42 gollum slapd[6246]: conn=225 op=0 BIND dn="" method=128 May 25 11:23:42 gollum slapd[6246]: conn=225 op=0 RESULT tag=97 err=0 text= May 25 11:23:42 gollum slapd[6246]: conn=225 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" May 25 11:23:42 gollum slapd[6246]: conn=225 op=1 SRCH attr=supportedControl supportedExtension supportedFeatures supportedSASLMechanisms supportedLDAPVersion subschemaSubentry schemaNamingContext May 25 11:23:42 gollum slapd[6246]: conn=225 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= May 25 11:23:42 gollum slapd[6246]: conn=225 op=2 SRCH base="cn=Subschema" scope=0 deref=0 filter="(objectClass=subschema)" May 25 11:23:42 gollum slapd[6246]: conn=225 op=2 SRCH attr=objectClasses May 25 11:23:43 gollum slapd[6246]: conn=225 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= May 25 11:23:43 gollum slapd[6246]: get_filter: unknown filter type=48 May 25 11:23:43 gollum slapd[6246]: conn=225 op=3 DISCONNECT tag=120 err=2 text=decoding attrs error May 25 11:23:43 gollum slapd[6246]: conn=225 fd=13 closed (operations error) May 25 11:23:44 gollum slapd[6246]: conn=226 fd=13 ACCEPT from IP=78.165.108.42:56471 (IP=0.0.0.0:636) May 25 11:23:44 gollum slapd[6246]: conn=226 fd=13 TLS established tls_ssf=128 ssf=128 May 25 11:23:44 gollum slapd[6246]: conn=226 op=0 BIND dn="" method=128 May 25 11:23:44 gollum slapd[6246]: conn=226 op=0 RESULT tag=97 err=0 text= May 25 11:23:44 gollum slapd[6246]: conn=226 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" May 25 11:23:44 gollum slapd[6246]: conn=226 op=1 SRCH attr=supportedControl supportedExtension supportedFeatures supportedSASLMechanisms supportedLDAPVersion subschemaSubentry schemaNamingContext May 25 11:23:44 gollum slapd[6246]: conn=226 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
(In reply to comment #3) > Created an attachment (id=161576) [details] > eds debug patch > > for evolution-data-server; > I'll try this patch asap and report back here.
Hey, I've got some news. My ldap addressbook was unning over a secure connection on port 636. So, I gave it a try with a standard connection from port 389 with no security. The result is that all of the problems went away. Everything seems to be working consistently. So, I am pretty much lost about this. Where is the problem? Why does my openldap server complains about filters onşy when connected over a secure connection? Any hints would be really appreciated!
Thanks for the update and investigation. I'm afraid it's a question for openldap folks, not evolution folks, unfortunately. I'm closing this bug, but feel free to reopen/ask when you'll know more from them.
Milan, I have solved my problems mentioned in this bug but I have one last question, which I think is a feature request, but I wanted to ask in the first place. When clock applet queries the addressbook for bdays and it fails due to a problem, for example the internet connection, it seems like it does not retry ever again. Is this actually the case?
(In reply to comment #9) > When clock applet queries the addressbook for bdays and it fails due to a > problem, for example the internet connection, it seems like it does not retry > ever again. Is this actually the case? Honestly, I do not know. The clock applet in the Gnome panel wrote other developers, not evolution developers. They are "only" using evolution-data-server to get to data they are looking for, relaying on functionality of evolution-data-server. Thus if any request, then it should come to gnome panel first, and they may redirect it to evolution-data-server when they realize the way they are using it doesn't work on evolution-data-server side.