LDAP not starting after 8.0.3 upgrade
-
We have a Cloudron instance that we have been using for a good while as an LDAP provider. Since this latest upgrade, the LDAP service will not start and/or bind on the host. We have the Directory Server enabled under the User Directory page. The Server URL matches the host and is correct(ldaps and 636). There is a bind password set and we have IPs listed in the restrect access section. This configuration has not changed from before the upgrade, and the LDAP service was being used externally before that just fine.
I did note that, it looks like the the 636 port is being redirected internally(the Cloudron firewall config) on the host to port 3004 . However, that port is not exposed on the host at all. We cannot see any process or service binding that port. We have attempted to disable and re-enable the Director Server from the UI there, along with trying to change the bind password and adding/removing IPs from the list. None seem to impact this.
We do have other Cloudron hosts, and I have enabled it on one of them to test, and I do see that the 'node' process for Box looks to be what is binding the port 3004 on there. I do not see that getting bound on this host though.
Any ideas on how to resolve this? Anything we can try? Any known issues like this after the upgrade? Is there any further information I can provide at all? We do not see anything there in the logs when saving the Directory Server config in the UI. We really need this working, as there are multiple external services that use that for client services.
-
We have a Cloudron instance that we have been using for a good while as an LDAP provider. Since this latest upgrade, the LDAP service will not start and/or bind on the host. We have the Directory Server enabled under the User Directory page. The Server URL matches the host and is correct(ldaps and 636). There is a bind password set and we have IPs listed in the restrect access section. This configuration has not changed from before the upgrade, and the LDAP service was being used externally before that just fine.
I did note that, it looks like the the 636 port is being redirected internally(the Cloudron firewall config) on the host to port 3004 . However, that port is not exposed on the host at all. We cannot see any process or service binding that port. We have attempted to disable and re-enable the Director Server from the UI there, along with trying to change the bind password and adding/removing IPs from the list. None seem to impact this.
We do have other Cloudron hosts, and I have enabled it on one of them to test, and I do see that the 'node' process for Box looks to be what is binding the port 3004 on there. I do not see that getting bound on this host though.
Any ideas on how to resolve this? Anything we can try? Any known issues like this after the upgrade? Is there any further information I can provide at all? We do not see anything there in the logs when saving the Directory Server config in the UI. We really need this working, as there are multiple external services that use that for client services.
@ramiroro If you do
systemctl restart box, you will something like this in box.log2024-08-20T19:07:19.792Z box:directoryserver starting server on port 3004- lsof will show the listen
# lsof -n -i :3004 | grep LISTEN node 78452 yellowtent 26u IPv6 517617 0t0 TCP *:3004 (LISTEN)- check the rediect from 636 to 3004
# iptables -t nat -L | grep 3004 REDIRECT tcp -- anywhere anywhere tcp dpt:ldaps redir ports 3004- test with
telnet my.domain.com 636. Note that if you are behind Cloudflare this won't work.
-
J joseph referenced this topic on
-
G girish has marked this topic as solved on