Docker Mailserver
dovecot: auth: Error ldap_search failed: Operations error #3785
-
|
Hi, Have anyone got any similar error? Or do you have any idea how to debug such errors? I have been trying for many hours to figure out what is wrong, but with no luck. The weird thing is that I am using a setup that used to be working (most likely). This issue happens as soon as I try to login using a mail client to the mail server. Here is the full log of one of the setups I tried, here I enabled the debug to see the env vars: I have no clue what I can do more to debug or solve this. Could anyone help please? |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 15 replies
-
|
May I ask you, @polarathene, to take a look when you have some time? As you suggested, I disabled the quota, but the messages did not change. If it is needed, I can provide access to DMS and LDAP server. |
Beta Was this translation helpful? Give feedback.
-
|
Oh and the new VPS, does that work fine with k8s if both run on that? If so might just be something related to your DMS volumes, you could try running without some mounted like |
Beta Was this translation helpful? Give feedback.
-
|
No the volumes are correct. Though, it should work without any persistence. The summary of tests. Just for me to keep everything documented. You may comment of course if anything comes to your mind :D
This means:
Samba does not accept turning encryption off. Could this mean, that there is a problem when DMS trying to access my Samba LDAP in the cluster because of some encryption issue, but it is only between this specific DMS with this specific Samba? Can this "version" error be the reason? but why only in the cases I mentioned above. Really annoying.. |
Beta Was this translation helpful? Give feedback.
-
|
Could this mean, that there is a problem when DMS trying to access my Samba LDAP in the cluster because of some encryption issue, but it is only between this specific DMS with this specific Samba? You could try enabling TLS with the OpenLDAP setup to better compare that and see if it reproduces the same behaviour with Samba. Do verify that the issue is specific to DMS though. If you install Were your comparisons both against DMS v13 or newer? Do note that configuration changes happened regarding LDAP for v13, notably the LDAP host URI now expects you to be more explicit. 3 ENV would fallback to I'd still advise keeping k8s out of the picture for now, to ensure that's not introducing any additional complications. Along with any other infrastructure not necessary. Focus on a minimal reproduction.
These are different hosts? Does the same apply if using Docker Compose instead of k8s? This should be possible to verify with the reproduction I provided: # On one host (_ldap will need port 389 published to be reached publicly_):
$ docker compose up ldap
# On another host:
$ docker compose up dmsDNS also becomes relevant for that external connectivity, but you could configure both to use the same DNS service you host yourself, no need to manage actual public domains and DNS records. If you'd like an example, let me know. It would be good to reproduce with Docker Compose, then I have something I can actually work with :) |
Beta Was this translation helpful? Give feedback.
-
|
Checking it without K8s would not really be very helpful, because as we saw, it works out of the box when running any of the components outside k8s. Very strange.. I changed the search base from Though, using the same filter with the same base in Though what I don't understand is why it works from the external DMS, but not with that in the cluster My users are located normally in Users, but could be though somewhere else. I do not understand what kind of duplication it finds :/ |
Beta Was this translation helpful? Give feedback.
-
With the OpenLDAP container enable the debug ENV and perform the reproduction for the working and not working setups and you should get some insights into how the queries and responses differ. Likewise with It's probably related to DNS? I am not familiar with k8s, so I don't know how that differs from same host vs separate hosts, but if you can identify what differences those introduce it'd probably make it clearer.
If you'd like to try building DMS from my LDAP Config Templates PR, you might have an easier time tweaking configuration. Then again the lacking docs to make that easier probably makes that a no-go right now 😓 Here are the new template files that will replace the current approach. There is a base with defaults, followed by an override template of the full settings supported by the Dovecot, Postfix and SASLAuthd configs:
This shows some implicit defaults that DMS sets, they're possibly messing with your queries? 🤷♂️ For Postfix, here is the LDAP config docs which explain each setting. You can see that we set a
That wasn't clear to me based on these two statements:
I guess the cluster is running on a separate system? On the same VPS was k8s used? If you cannot reproduce failure outside of k8s, then it's clearly a k8s issue not a DMS one and you'll need to figure that out as I don't have experience with k8s. I can only assume it's related to the DNS cluster/routing logic, or the ingress controller which AFAIK operates like a reverse proxy inbetween services and that's known to cause some problems (see the If anything it could be related to the |
Beta Was this translation helpful? Give feedback.
-
|
Shouldn't this be the problem? Though I don't know what are the "two" results. I have a very fresh LDAP server. So I am not sure what is going on here. Does any one see something I am missing? |
Beta Was this translation helpful? Give feedback.
-
From the logs it looks like it returned these two: You can follow my troubleshooting steps I shared in the other response with I don't know the command right now, but there is one you could use from Alternatively with the Bitnami LDAP container you'll also get plenty of insights on the LDAP side through it's logs (you may need to enable the debug env if it's not showing the queries received). With those insights, you'd know what the multiple results returned are for a query. Clearly the query was expected to return only one result, which presumably is the DN for an account queried? I did mention there was a gotcha regarding There are additional ways to test the login with credentials is valid, IIRC they're Anyway... given the log output you've shared. Looks like you're trying to authenticate as If you login with just the username, and the expectation of that is without the DMS hostname appended, I think Postfix would append this by default to the query. Thus fails to match. If the query would have been successful with your own mail domain appended ( Fixing the supervisor config for saslauthd with The plan was to fix those months ago with a breaking release that would go with the LDAP refactor I've done. Writing up the docs and other events has just severely delayed that being addressed 😓 |
Beta Was this translation helpful? Give feedback.
-
|
Wow, this discussion became a good source for debugging. I finally got it working. After the analysis mentioned above that both components, LDAP server and Mail server, work when used with external systems but not with each other, this made me think again about the connection between them. The relationship that connects them is LDAP, DNS and TLS. I checked TLS and seemed to be working properly. LDAP filters were also OK, after testing them with ldapsearch. That leaves DNS of the cluster, particularly CoreDNS. The biggest confusion came from the log messages of Dovecot actually, as they always were inconsistent and misleading. In K8s, I configured the CoreDNS to forward all requests that are specific to my intra domain to Samba's DC DNS server. Removing this configuration from CoreDNS made my mail server works again. I am still investigating why this caused my DMS / Samba relationship to fail, because my simple configuration seems to be correct, and everything other than DMS works with it. NOTE: because of the cache TTLS (30 seconds in this case), after removing the entry from CoreDNS configmap we have to wait about 30 seconds before the changes take effect and DMS starts working again. I still though do not exactly understand the behavior, that changing the search base solved the issue and how it is directly related to the DNS. Many thanks to @polarathene for his support! |
Beta Was this translation helpful? Give feedback.
Wow, this discussion became a good source for debugging.
I finally got it working.
After the analysis mentioned above that both components, LDAP server and Mail server, work when used with external systems but not with each other, this made me think again about the connection between them. The relationship that connects them is LDAP, DNS and TLS. I checked TLS and seemed to be working properly. LDAP filters were also OK, after testing them with ldapsearch. That leaves DNS of the cluster, particularly CoreDNS.
The biggest confusion came from the log messages of Dovecot actually, as they always were inconsistent and misleading.
In K8s, I configured the CoreDNS to forward all requests that a…