Closed zicklag closed 5 years ago
Hi,
We need to think how it may work, I would think to go into a generic plugin system if it is possible. I need to investigate possibilities how it could be implemented.
I think I'm strongly for the LDAP support actually, possibly I will use it in the future too.
If you wanted to do a generic plugin system, one approach could be to provide:
settings/local.py
filepip
packages to installdist/conf.json
The problem with that is that it is rather inconvenient to set the massive, multiline environment variable would be necessary to extend the settings/local.py
file.
Another option would be to have a directory in the container that you could mount install scripts to. The container would just run every script in that directory at startup, which would allow you to do whatever you need to get that plugin intalled.
Both of those solutions involve installing the plugin when the container starts up, though, which means that you need an internet connection which could be a problem for some people.
If you baked the plugins into the image it would be a better user experience because you could set your plugin configuration in separate environment variables instead of having to pass it in as a large multiline environment variable or mount in a script. Also it would prevent you from having to have an internet connection to start the container, because it wouldn't have to run a pip install
every time the container starts.
Maybe we could build the LDAP plugin in, but still provide a way to install your own plugins if you want to do that.
I've almost got LDAP support as a built-in plugin finished. If you would rather not build it in and do a generic plugin interface that is fine, but I'm needing to get LDAP in as soon as possible so I started working on it and I can just use a fork until we figure out how we want to organize it.
I am having a problem, though. I'm getting an error message when connecting to the LDAP server:
{"error_message": "Error connecting to LDAP server: ('unable to open socket', [(LDAPSocketOpenError(\"('socket ssl wrapping error: [SSL: DH_KEY_TOO_SMALL] dh key too small (_ssl.c:852)',)\",), ('123.456.789.012', 123456))])"}
I can confirm that you get the same error when using curl
to hit the LDAP server in the container, but when I use curl
on my development machine, it comes back properly with an access denied ( which is expected because I didn't put the credentials in the curl
call ). This leads me to believe that there is some defficiency in the SSL library that is being used in the container. I tried running an apt upgrade
, but it still didn't fix the issue. Do you have any idea what might be the problem there?
The SSL problem is present in some base images of Debian, I think it should be possible to solve as I have seen it more times already.
There is a workaround for now: https://github.com/home-assistant/home-assistant/issues/19683
To do it better possibly we would need to upgrade the SSL library.
I'm still looking into it, but, while the workaround did change something, now it causes a Gunicorn worker timeout which results in a 502 Bad Gateway.
I don't think gunicorn is affected with this workaround. Gunicorn must be affected by incorrect confguration of the plugin or plugin itself.
On Sun, Aug 18, 2019 at 6:02 PM Zicklag notifications@github.com wrote:
I'm still looking into it, but, while the workaround did change something, now it causes a Gunicorn worker timeout which results in a 502 Bad Gateway.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/riotkit-org/docker-taiga/issues/3?email_source=notifications&email_token=AFOAJBVKMTXQGNVT3TWY623QFFXCZA5CNFSM4IMQHO32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4RC56Q#issuecomment-522333946, or mute the thread https://github.com/notifications/unsubscribe-auth/AFOAJBSJKITREBLT7TSQU4DQFFXCZANCNFSM4IMQHO3Q .
If there are not enough logs you can try ex. strace command to debug if it does connect or not. Or set up a dummy tcp or http server to see if taiga attempts to connect to ldap at least.
On Sun, Aug 18, 2019 at 6:29 PM Krzysztof Wesołowski < wesoly.krzysztofa@gmail.com> wrote:
I don't think gunicorn is affected with this workaround. Gunicorn must be affected by incorrect confguration of the plugin or plugin itself.
On Sun, Aug 18, 2019 at 6:02 PM Zicklag notifications@github.com wrote:
I'm still looking into it, but, while the workaround did change something, now it causes a Gunicorn worker timeout which results in a 502 Bad Gateway.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/riotkit-org/docker-taiga/issues/3?email_source=notifications&email_token=AFOAJBVKMTXQGNVT3TWY623QFFXCZA5CNFSM4IMQHO32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4RC56Q#issuecomment-522333946, or mute the thread https://github.com/notifications/unsubscribe-auth/AFOAJBSJKITREBLT7TSQU4DQFFXCZANCNFSM4IMQHO3Q .
Ah, I finallly found out that the LDAP integration wasn't the problem with the server hanging. Apparently anything that uses the Taiga API to modify/create user accounts will hang and cause the worker to timeout. I'm not sure why yet. I'll have to check whether or not that happened before I made the LDAP changes.
It would be nice then to fix the issue in our container, you can send a PR, when you will handle it :)
Ah! I finally figured it out after hours of debugging. It is the SMTP failing. When you try to edit a User's email, or when the LDAP plugin creates a new user that has been successfully authenticated, it tries to send an Email. If your Email config is wrong it will hang and the Gunicorn worker will time out, without any extra logging info. If you disable Email it lets you login without problems.
Its been over a year since I last setup Taiga, but I just remembered that I had had this same exact issue last time I set it up, and again, I spent hours debugging it because there were no logs to indicate the cause of the failure. I only figured it out this time after finding somebody else's issue, where they had a timeout because of SMTP failure.
Hopefully I will have an LDAP PR comming soon. :slightly_smiling_face:
Cool, thanks for the investigation. Maybe we should put this info in a FAQ section in the README then? :)
On Mon, Aug 19, 2019 at 2:29 AM Zicklag notifications@github.com wrote:
Ah! I finally figured it out after hours of debugging. It is the SMTP failing. When you try to edit a User's email, or when the LDAP plugin creates a new user that has been successfully authenticated, it tries to send an Email. If your Email config is wrong it will hang and the Gunicorn worker will time out, without any extra logging info. If you disable Email it lets you login without problems.
Its been over a year since I last setup Taiga, but I just remembered that I had had this same exact issue last time I set it up, and again, I spent hours debugging it because there were no logs to indicate the cause of the failure. I only figured it out this time after finding somebody else's issue, where they had a timeout because of SMTP failure.
Hopefully I will have an LDAP PR comming soon. 🙂
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/riotkit-org/docker-taiga/issues/3?email_source=notifications&email_token=AFOAJBURXD4G2G37SGBDQ2DQFHSNXA5CNFSM4IMQHO32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4RMOXY#issuecomment-522372959, or mute the thread https://github.com/notifications/unsubscribe-auth/AFOAJBQDQJLST5MATRGVEWTQFHSNXANCNFSM4IMQHO3Q .
Yeah, that's a good idea. It would be good to :+1: https://github.com/taigaio/taiga-back/issues/1081, too.
Sure :+1:
Closing as the PR was merged.
What do you think about building in LDAP support with using this Taiga plugin. It could be optional of course.
I need LDAP support for my Taiga instance so I would be glad to work it into this image if you don't mind. I'd rather put it into this image than run my own fork of it.