mirror of
https://github.com/modoboa/modoboa.git
synced 2026-04-26 17:36:01 +03:00
[GH-ISSUE #2571] Calendar issues #1642
Labels
No labels
bug
bug
dependencies
design
documentation
duplicate
enhancement
enhancement
enhancement
feedback-needed
help-needed
help-needed
installer
invalid
looking-for-sponsors
modoboa-contacts
new-ui
new-ui
pr
pull-request
pyconfr
python
question
security
stale
webmail
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/modoboa-modoboa#1642
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @gsloop on GitHub (Jul 21, 2022).
Original GitHub issue: https://github.com/modoboa/modoboa/issues/2571
Impacted versions
Steps to reproduce
Regular script install using defaults.
Create a new domain, and a simple user in that domain.
Login as that "simple user" into the UI.
Via the UI, nav to the Calendar.
(I think it's "normal" for there to be no default calendar, but perhaps not. But that is the state a simple user sees when first logging in and viewing "Calendars"
Since there's no default calendar, you have to create a "+New Calendar"
Creating a new Calendar appears to work ok. You can name it and set its color.
However if you try to add an entry to the calendar, you can enter the entry details and then click "Save" and nothing occurs.
No UI response, no entry is created.
Nginx sees this;
"POST /api/v1/user-calendars/1/events/ HTTP/1.1" 500 870 "https://server-fqdn-or-ip/calendars/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Firefox/102.0"
So, it looks like UWSGI / Nginx are responding with a 500 return code, but nothing occurs.
This also appears to occur if you attempt to "edit" the calendar itself, to change its name or color.
When you attempt to save the change, the UI does nothing.
Tested initially under Ubuntu 22.04, then wondering if it were some other strange bug that only occurs in 22.04, installed a test setup under 20.04 and the behavior is the same.
@tonioo commented on GitHub (Jul 22, 2022):
@gsloop Can you set the DEBUG variable to True inside settings.py, reload uwsgi and check your browser console to catch the response of the request which comes back with a 500 code ?
@gsloop commented on GitHub (Jul 22, 2022):
I should have noted in the OP - I did turn on debug, but get no debug output to the UI.
Is there somewhere else I should look for debug output?
(The only relevant lines I see are the ones I've already posted, in the logs for nginx and uwsgi.)
@gsloop commented on GitHub (Jul 24, 2022):
If it would be really helpful, I could provide you access to a VPS with an install you could tinker with. (If you have a VM, though, that's probably better, snapshots etc.)
I'd just like to make it as straight-forward to figure out as possible, since I'm pretty lost in where to start to resolve this problem.
@gsloop commented on GitHub (Jul 25, 2022):
Some additional details and a possible solution in one case:
On Ubuntu 22.04, an issue with supervisord/policyd causes supervisor not to start. A very tentative fix (see: https://github.com/modoboa/modoboa/issues/2561) appears to resolve this. (As noted in the comments, I'm not at all sure the "fix" is a good idea. But I did test it and it appears to work. Confirmation from Tonio or someone very familiar with the code would be a very good next step.) After the fix, supervisord starts, and the calendar issues vanish - on 22.04 ONLY!
On 20.04 the supervisord problem doesn't exist, but the same kinds of nginx 500 responses occur. (Same symptoms, perhaps different causes.) I don't know if it matters, but the test Ubuntu 20.04 setup I did is on a VM, and I'm accessing the Web UI via an IP address, not a FQDN. (I mod the nginix available sites and uwsgi configuration so it allows this.) It would be super helpful if someone knowledgeable could weigh in on whether this could cause the same symptoms.
@gsloop commented on GitHub (Jul 27, 2022):
This probably needs to get split into two issues.
One for Ubuntu 22.04 and the other for 20.04.
I did a bunch of testing on Ubuntu 20.04.4 and I can't get calendaring to work in ANY situation.
The general problem is this: Install u 20.04 and update to the latest updates etc. Pull modoboa from github and do a totally stock install for mail.mydomain.com. Login as admin and set password. Create a domain. Create a "simple user". Login as the simple user on the Web UI, and go to calendars. Attempt to create a calendar. You can put in the text description/name and color, but when you click to save it, nothing happens.
I get 500 responses in the logs from uwsgi and nginx, but setting [debug = true] in doesn't result in any debug output in the web UI. Checks of all the other logs (sysog/supervisord/nginx/uwsgi/etc) don't show anything that looks interesting (other than the 500 http responses.)
The 500 responses are like this:
[26/Jul/2022:18:56:25 -0700] "POST /api/v1/user-calendars/ HTTP/1.1" 500 870 "https://mail.mydomain.com/calendars/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.134 Safari/537.36"
Changing browsers doesn't help. It's the same with Safari, Firefox, Brave and Chrome.
I still have these VM's with some snapshots - so I can go back and test some things, if someone can come up with some suggestions.
My biggest question is: Has anyone gotten calendars to work on Ubuntu 20.04?
@Spitfireap commented on GitHub (Aug 4, 2022):
Hey, so I managed to find time to test it, I do have the same issue if I run it with a self-signed certificate.
Here is the error
Are you using let's encrypt or not ?
@Spitfireap commented on GitHub (Aug 4, 2022):
see modoboa/modoboa-radicale#90 :)
@gsloop commented on GitHub (Aug 9, 2022):
*** UBUNTU 22.04 ONLY ***
Update.
I finally had time to go re-produce a clean install environment and test the proposed fix by @Spitfireap.
It works. (And I haven't seen any undue side-effects. But that's with very little additional testing - so it's not like I'm promising there aren't any!)
Since this is Nginx/django talking to the Radicale server on the same host, SSL wrapping the connection probably isn't needed.
This won't apply if you've issued SSL certs on a trusted CA, for example, using LetsEncrypt. It will only come up with self-signed certificates.
Until a patch gets merged into the base setup, this should "fix" it on Ubuntu 22.04 ONLY
[All other distros and versions are untested. You should verify all details before proceeding, and use at your own risk.]
cp /srv/modoboa/env/lib/python3.10/site-packages/modoboa_radicale/backends/caldav_.py /srv/modoboa/env/lib/python3.10/site-packages/modoboa_radicale/backends/caldav_.py.bak
sed -i 's/username=username, password=password)/username=username, password=password, ssl_verify_cert=False)/' /srv/modoboa/env/lib/python3.10/site-packages/modoboa_radicale/backends/caldav_.py
@Spitfireap commented on GitHub (Aug 10, 2022):
I have tested it on Ubuntu (20.04) and Debian, but this is not distro dependent, it rather depends on how you generate your self-signed cert.
Installer method should not be used for prod environment as it is not a full chain certificate ! so you could say that the fix on this side is not really necessary.
On the other hand, if you install through the installer, or even follow closely the tutorial on the documentation, your system's hostname will be set to
mail.example.com. This means that a dig will answer127.0.1.1, meaning it is safe to not verify the cert in any condition (if it's server calling itself - present case -).Even if we take into account special install where people mess with some stuff (like dns), your machine hostname MUST (in a RFC meaning) have its hostname set to the right hostname, so I'm in favor for simply applying this patch globally.
@gsloop commented on GitHub (Aug 10, 2022):
@Spitfireap
I agree the principle of the fix applies to any distro. However the exact fix I gave above relies on a specific python version etc - and I've only tested on Ubuntu 22.04. (All the controlled/careful testing I've done is on 22.04)
@gsloop commented on GitHub (Aug 18, 2022):
I've done a bunch of additional testing, and while I don't know exactly what's going on, I still have a case where, EVEN AFTER APPLYING THE "ssl_verify_cert=False" mod above, I still can't EDIT a calendar name.
I can create an initial calendar, but can't edit the name/color after creating it.
I quite sure there's some "interesting" interaction with DNS.
For example.
In a production setup that I'm getting ready for - I can do the modoboa setup using mail.a.com.
But I intend the server to handle mail.b.com (once we go live)
I have real DNS records for mail.a.com but not the mail.b.com (mail.b.com conflicts with the current server).
So, if I run the modoboa setup for mail.a.com (and use the https://mail.a.com URL) it works. (I can create and then rename calendars.)
However, if I modify nginx and django to allow me to use mail.b.com or the IP address of the server and use those URL's, it fails.
So, somewhere in the code there's some references that depend on live DNS lookups, I think..
@stale[bot] commented on GitHub (Oct 18, 2022):
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
@stale[bot] commented on GitHub (Dec 27, 2022):
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.