Hi I have recently installed lldap in
Hi, I have recently installed lldap in docker. Everything went smooth EXCEPT smtp config. I am running an open SMTP relay server in a separate docker container. No TLS/SSL or password. How can I just relay from lldap to my server? I set port 25 and server but it seems to still default to TLS? How can I force lldap to NOT use TLS or any other security to relay via my postfix smtp server? Thx Stefan
23 Replies
TLS is required for sending email. It's a requirement from the email library I'm using, and one that I consider reasonable, so I'm not going to implement non-encrypted traffic.
Ok thanks. Makes sense in the end. Any specific requirements to get Google mail to work? I have no luck when using the same as with my internal open relay.
Hmm, no, it should work the same.
Are you on stable or latest?
I think there were some issues with certificates on stable that got fixed on latest
Hi, sorry for the delay. Yes, I am running latest. I am using same Google account as with my postfix server but receive error message when trying password reset.
"Could not initiate password reset[500 Internal Server Error]: Internal server error:
Could not send email: permanent error (535): 5.7.8 Username and Password not accepted. Learn more at"Do you have MFA? If so, you'll need an app password
Yes, I do have MFA. I am using the same app password from a secret.
Courier
[Solution] smtplib Username and Password Not Accepted
This is a common SMTPLIB error -- get the solution for smtplib Username and Password Not Accepted.
ensure that you've enabled "Less Secure Sign In Technology"
Did that work for you?
Have not been able to check yet, but if I recall correctly this setting is superseded by MFA and app password. Need to double-check
In that case, it might be hard to use directly with Gmail
Hi, been looking into this again. First, yes the option to run less secure is obsolete. But, app password should work. Here comes the embarrassing part, I was trying to reuse my existing docker secret without making sure lldap supported that for all variables. So good news is that smtp with Gmail directly works.
Bad news, after pulling latest today secrets for jwt and user seems to be broken. This worked previously but I now receive permission error. Temporary setting values as regular variables it works again.
Hmm. I think the difference is that previously it was the root user reading the files, but now it's the lldap user
Makes sense as the "secrets" directory are locked down to root to protect them
Is this change by design? Or will this be fixed? I figure many have secrets directory locked down with root. Any suggestions otherwise to fix this?
The change is by design: it's better to have your secrets limited to the app user rather than require the app to run as root
Ok. In reality, how do You suggest to set the permission? Should I move the secrets out of a common secrets folder then to be able to set to other than root?
I would create a group with the lldap user in it, change the group ownership of the secrets to that group, and make them group readable
Or just chown them to the lldap user, since root anyway has all the rights
Not sure how to do that, I don't have a lldap user on my system, I guess that only exists in the docker container?
It's the user with id 10001
If you don't have such a user in your system, you can create it with that ID
Note that the lldap group also has the ID 10001
Or you can run it with a different UID by passing it to docker by env variables
(variables UID and GID)
Hmm, I will try this out. Not sure which approach is the simplest in regards to the current setup. Curious about one thing, most other containers I have are using PUID and PGID variables, whats the difference with UID and GID used by lldap?
Ah, it's the same role
I'm not sure whether docker treats these variables differently, but the entry point needs to run as root. It'll delegate to the given UID/GID though
Just want to report back on this. So I had an override since earlier for a common "docker" user also for lldap. What I missed was that the exact file permission in the OS is controlling the secret accessibility. Even if I saw the secret loaded in the container the actual file containing the secret only had read for root, not for the "container" user set by UID/GID. which was used by lldap starting up. This now works after adding the UID user to the secret file in the OS. Thanks again for quick responses.
Glad I could help!
Learned a bit more how secrets are handled when not running in swarm mode as well 🙂