[SOGo] BTS activities for Monday, June 26 2023
Title: BTS activities for Monday, June 26 2023 BTS Activities Home page: https://bugs.sogo.nu Project: SOGo For the period covering: Monday, June 26 2023 idlast updatestatus (resolution)categorysummary 5798 2023-06-26 14:24:13 updated (open) Packaging (RedHat) kernel: sogod[1907582]: segfault libgnustep-base.so.1.24.9 5794 2023-06-26 14:53:01 assigned (open) Web Mail Webmail calendar showing some events in 1970
Re: [SOGo] two mailservers cannot talk to each other
Both systems are SOGo groupware server installed on sorry my typing error its yunohost as app in separate domains Yes, ping works. Von: Marco Moock Gesendet: Montag, 26. Juni 2023 22:20 An: Betreff: Re: [SOGo] two mailservers cannot talk to each other Am 26.06.2023 um 19:44:33 Uhr schrieb "S1000RR": > i have set up two mail servers A and B für different domains A B > both can send and receive any mailserver in the web. > but not each other. > > MX A internal IP-A over NAT to external IP-A to external MX = Okay > MX B internal IP-B over NAT to external IP-B to external MX = Okay > > MX A to MX B fails > MB A to MX A fails How is that related to SOGo? Can you ping them? -- Gruß Marco Moock URZ Uni Heidelberg
Re: [SOGo] two mailservers cannot talk to each other
Both systems are SOGo groupware server installed on yogohost as app in separate domains Yes, ping works. Von: Marco Moock Gesendet: Montag, 26. Juni 2023 22:20 An: Betreff: Re: [SOGo] two mailservers cannot talk to each other Am 26.06.2023 um 19:44:33 Uhr schrieb "S1000RR": > i have set up two mail servers A and B für different domains A B > both can send and receive any mailserver in the web. > but not each other. > > MX A internal IP-A over NAT to external IP-A to external MX = Okay > MX B internal IP-B over NAT to external IP-B to external MX = Okay > > MX A to MX B fails > MB A to MX A fails How is that related to SOGo? Can you ping them? -- Gruß Marco Moock URZ Uni Heidelberg
Re: [SOGo] two mailservers cannot talk to each other
Am 26.06.2023 um 19:44:33 Uhr schrieb "S1000RR": > i have set up two mail servers A and B für different domains A B > both can send and receive any mailserver in the web. > but not each other. > > MX A internal IP-A over NAT to external IP-A to external MX = Okay > MX B internal IP-B over NAT to external IP-B to external MX = Okay > > MX A to MX B fails > MB A to MX A fails How is that related to SOGo? Can you ping them? -- Gruß Marco Moock URZ Uni Heidelberg
Re: [SOGo] SAML login not working / Keycloak 21.1.1 / Debian bookworm
Hi, next Update. After using the URL https://www.scottbrady91.com/tools/saml-parser to inspect my SAML response I'm pretty sure everything is fine. This site is able to display SAML Response without any garbage. Now I'm getting a little step further (after manually doing this query: ALTER TABLE sogo_sessions_folder MODIFY c_value VARCHAR(4096);) --- Jun 26 18:45:21 sogod [2521]: |SOGo| starting method 'POST' on uri '/SOGo/saml2-signon-post' 2023-06-26 18:45:21.404 sogod[2521:2521] SQL: BEGIN; 2023-06-26 18:45:21.404 sogod[2521:2521] query has no results. 2023-06-26 18:45:21.404 sogod[2521:2521] SQL: SELECT t1.c_creationdate, t1.c_id, t1.c_lastseen, t1.c_value FROM sogo_sessions_folder t1 WHERE t1.c_id='+dm+GN1YY2Cu2LHI'; 2023-06-26 18:45:21.405 sogod[2521:2521] query has results, entering fetch-mode. 2023-06-26 18:45:21.405 sogod[2521:2521] SQL: ROLLBACK; 2023-06-26 18:45:21.405 sogod[2521:2521] query has no results. 2023-06-26 18:45:21.405 sogod[2521:2521] SQL: BEGIN; 2023-06-26 18:45:21.405 sogod[2521:2521] query has no results. 2023-06-26 18:45:21.405 sogod[2521:2521] SQL: INSERT INTO sogo_sessions_folder (c_lastseen, c_creationdate, c_value, c_id) VALUES (1687805121, 1687805121, 'iYz+xz02bTv8zdjSHNQUAGs6O/I49dCc4MhKKn0Nymqik2Dm+37+PGdVgU3d1q4izrES89wLe7h85jXF0PQhjE6wL494/RvTUin2e2gJvebZtJQ317RyX1x7KieUrbAqn9MGadEFI6+HsK6zwylpafHJ/163+u5Ii2C/mG2I0DXdFoddXQcl8YxeaOFscWNl2TdsSc/VJO897mRKoZuZZdu7U0xWTKdqK5y2vW40Oe6kJx9WUVp7GWX9rsbVeKtlTHJPHNQ2+GiyoeaOHTe676v7ufytiMOPQ1NmFqJ6vLgcfRgXyJd0P7WgUHWW+1KlbfTkveHRdsVzRhVXrhWp85rMYDV8tEZuVl2WXXuaZPSbg2BnX5QjQKgyrcauqAWktn4/uJmTRyA/fLI8oMf7WmbTmr5Gr+foXfP9Eq4lkCLWgPcitOKSs0dmyY++4nwuikMISapGekvdP1LX+elFve3vt34AXZ0/RPiAkWH+Kxh9Jr3ClBLQERjbJPgj9s/hefozT9iKoJhEaWL7EhJy2eOanwAKraA53cMI2TkXcVPbYcHkyg8N/qmhG+apwVe82a2frdFAEOT8tGsNUOfW3jIOaWEhUKSw4MnoC0qszwwZt5KYG7cSiIRCcypUeSMs1k78EBEuaI5G3A9ZviGwwP413YuV7lPH46xUDD3wJKTRWO0B2gHUZBuSRFc22HFXdYGljLuYl90PhlpR97cYBxNvhboTjT6jAZ3sPNF0QsPnvfNSNUWUvMY/e0Gp+0y5rUxQQ3WeDthFYFJxTS92rkknEiD47JsQuEEEIaFcn0ld1VszVP2ONr/biSEAMNm1VdCKshviN/21x1PP4D2YV21ntV1eHF9TgggpOIU4gqbV9FnYGtKUV86DKyHQlN7c0AvTxh4K2qL/qeUKhE4Epm3qLyEMwyPHn/JMAjmZ6WWWRdNaRmBcYGL4zL9Vqj7yrFvP/JyZtsBgDnbYR/3BuAF2TwAuOBSAYCDof +ZGcWPVXC+mnpv4Kd3xBLgolTbA H6cQe1wdVAa4hjmNZN/KFUUeuGI0v1tiNgy4Z+gnf6RZ+lf6ojr3Pw6uBI6OK/xUKnB4NdxPjJ408GxbXwbFk6ghUUGXPJ1rvGWV8+3MY9DS0g+QSnhX8ckSKZPT57tsZ0tJfTn0N8ycSaC5VmaLyN0oJZdFTIWNhqZ8debIl0WxszSZhHaS6Gb9GkvbDFMAmvLcDjYQp4AURQ22RhXb1r/YlHhdsr2EwvAafvUk+X8dHLETVXqTah4PXnu3z+eRSsR+LML4NojQ1w31hiMjQxFBZyiNB6gU0EMpHXTQ0BjzS4IocyFhamr4pL332+Q6fZll5tb/An+jnmXdU6Kp3dyrj0dI2loVS4zp4Qrfz/AJjJMUROKfTFlINQRRuEToBAMl6kVyKXTSvMlfB1Fa1Cf7esHSzegbgyPCKOHxlBqkssxXVQs78fQbczj8MDFNBTOe82+7eFrTqxY3xN1MDUcRI7awnXEQwYEOJEsR9F2X6JbY6Ee6n5DjCpRA1bgo6SuUPpB5M8Zgxff0GTaf3TyYigWqw8rdE+TLl6sGC+hAGGj9Iq0D8FAToj/dXVpC7aez5Umo8DzGxxS3Y9vMcRdvf8G4tEGP1V0KWgLMMY+cc5T1xv/jF1C9/e+Sh5dvx34beIGtBBWRS4vqjPdfLwn2vgSAwEtVvKBayzAz2WHRZJ9kK83PfSuvMeHUyqadbZUYewc7ryKkcIwcBvDXgzM6IkyZmZ58arkD6UEQLuFtDtYYrNB1WNSrxxiKrkSvaPhTFntYhH8nhDkQoVhzsQFMhYyo4XtpOSq3SsLc9s77A8YCm1M5jxgTOgyklwDBaatny0QDCeLpN9vpPQ5f00n8VfKwf2WVZ32okBk1kPnFZX3wiAfYeddSNDml/BzwoSVAiDvQkqnsmoZTWSh0mfWFOydcgMjQMD98E/F/28xykxvGoy3GPsrzvTytl9q4FR0fc0sxrNIRHtzfQqea4OiTJK1TAsHIzBirYu aXbnkcpFuyit7pgY46JwPK4abL 98E/F/28xykxvGoy3GPsrzvTytl9q4FR0fc0sxrNIRHtzfQqea4OiTJK1TAsHIzBirYuaXbnkcpFuyit7pgY46JwPK4abL 9/FPpQzff1tZeAx/MOmMmoH9QB4SU8OnqwlqRU7nqmR96W8TPjcfH+WIn8hW1do1VbEsXHVv4UvNLKlO0D3tY+/pWjSixNdov1mA1I4sWx6RreZFe7qWV/FWJT189aMz2LtGhy/azD2jVQFpHtUNTPS7STf1t6LhNVWsDhCDwWq1Ie9u/8PtFd2Tx9GLbjK3jXS9M9SCBC1nSCjP+v8aqRyjVPpntTYYnXQ8QLLbTrUmGF4No7ZRcovuzXiot+3X+1MUl+HPQPREgxF99Q9WkRdtYJHyMaHUZEkd62k+W57FUASiaCGwBz2hEimfBaSAj7yd4XAGYWJ2ZqGsBC0ne9+EfsdEdSDMt3YyGYuOusTPklJqHDxjS2n8XEDZneD3ISxDaZWT/Ps2/0kl4RtptzdGKOLv5oU05bi5twFIl1YG19ie62wsMuUN40ZZlrYXpCbl66h+TL35W1eYrYnMgLqsdR9QwWGgjeOX4Do9w4WM7GsFIKb6edCfnxFNb0oUj6HOsKfJLgbOlAHdJOJnjrIsLTwqz0TKKGjItH2qFK7DW9hNyY7uqSxe/B8m7sXIS6zznJqog5iy/Isc7PKNH7lEwqZqmHPOvwA1MRG8tImFlsM8mabPUP1QE9qiRwOv5DQuLm3950Ov8WwKmsMNFdBzOIyEcP9kmGlqPDfk5qO/rEyzJBN75xMjN+Ojh7egyZ6uWJZmDMhnqiFBKpnUsXAMStcZNyqHYhA55BVoMQmEx3c7QNL9kREOfLBKyzSEfvScyodvieGeblibPRBLKLqCz0xsrTUYTpb3iLM+lCfd5nGnLpjrOi2uptD7jHkrd5HGkcKBr33pi+G318MkhGBGCoHX8neC2EQGs0mSlmQ+S1JLvpbi2NoKQvuLnRDucQ6zZXdphTD9SJLKgbyEoHsSsFJdBQvZDIss3bj7eoiVY7NvAMcLRfDyr0Pzc1U=', '+dm+GN1YY2Cu2LHI'); 2023-06-26 18:45:21.405 sogod[2521:2521] query has no results. 2023-06-26 18:45:21.405 sogod[2521:2521] SQL: COMMIT; 2023-06-26 18:45:21.406 sogod[2521:2521] query has no results. Jun 26 18:45:21 sogod [2521]: |SOGo| constructed root-url: /SOGo/ Jun 26 18:45:21 sogod [2521]: |SOGo| setting root-url in context: /SOGo/ Jun 26 18:45:21 sogod [2521]: |SOGo| ROOT baseURL(no container, name=(null)): own: /SOGo/ (process:2521): Lasso-CRITICAL **: 20:45:21.407: 2023-06-26 20:45:21 (profile.c/:913) Trying to unref a non GObject pointer file=profile.c:913
[SOGo] two mailservers cannot talk to each other
Hi, i have set up two mail servers A and B für different domains A B both can send and receive any mailserver in the web. but not each other. MX A internal IP-A over NAT to external IP-A to external MX = Okay MX B internal IP-B over NAT to external IP-B to external MX = Okay MX A to MX B fails MB A to MX A fails thanks in advance
Re: [SOGo] SAML login not working / Keycloak 21.1.1 / Debian bookworm
Hi, after looking at the sourcecode, which is just: if (loginAttribue && (strcmp (attribute->Name, [loginAttribue UTF8String]) == 0)) I tried to debug the request flow. With the help of the apache dumpio module I was able to capture the whole traffic. II tried to decode the capture but it seems that the data is brocken. It starts like this: xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Destination="https://sogo.linum.biz/SOGo/saml2-signon-post; ID="ID_f2451abf-1693-4509-a54f-af20461c28d5" InResponseTo="_02F15ED37EA154C6F8927F722B48897D" IssueInstant="2023-06-26T15:46:30.664Z" Version="2.0"> looks like garbage. So somewhere in between the proxy setup something goes wrong.
Re: [SOGo] SAML login not working / Keycloak 21.1.1 / Debian bookworm
Hi, In your logs you have a segfault. You need to provide a backtrace according to https://www.sogo.nu/support/faq/how-do-i-debug-sogo.html Here it is: --- 2023-06-26 07:39:05.169 sogod[816:816] SQL: SELECT c_defaults FROM sogo_user_profile WHERE c_uid = 'anonymous'; 2023-06-26 07:39:05.171 sogod[816:816] query has results, entering fetch-mode. Jun 26 07:39:05 sogod [816]: |SOGo| request took 0.468025 seconds to execute Jun 26 07:39:05 sogod [816]: 79.140.187.148, 172.27.11.107 "GET /SOGo HTTP/1.1" 302 0/0 0.471 - - 4M - 11 Jun 26 07:39:10 sogod [816]: |SOGo| starting method 'POST' on uri '/SOGo/saml2-signon-post' Program received signal SIGSEGV, Segmentation fault. 0x76ac7744 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt #0 0x76ac7744 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x77f400c1 in -[SOGoSAML2Session _updateDataFromLogin] (self=0x55705c40, _cmd=0x77fc0cc0 <_OBJC_SELECTOR_TABLE+640>) at ./SoObjects/SOGo/SOGoSAML2Session.m:272 #2 0x77f40f2c in -[SOGoSAML2Session processAuthnResponse:] (self=0x55705c40, _cmd=0x725e99b0 <_OBJC_SELECTOR_TABLE+720>, authnResponse=0x55e26970) at ./SoObjects/SOGo/SOGoSAML2Session.m:466 #3 0x725deb3b in -[SOGoSAML2Actions saml2SignOnPOSTAction] (self=0x55e07820, _cmd=0x558769c0) at ./UI/MainUI/SOGoSAML2Actions.m:175 #4 0x7794cd31 in -[WODirectAction performActionNamed:] (self=0x55e07820, _cmd=0x77b28ca0 <_OBJC_SELECTOR_TABLE+928>, _actionName=0x55dc9590) at ./sope-appserver/NGObjWeb/WODirectAction.m:97 #5 0x779ea252 in -[SoActionInvocation callOnObject:withPositionalParametersWhenNotNil:inContext:] (self=0x55752f70, _cmd=0x77b28cd0 <_OBJC_SELECTOR_TABLE+976>, _client=0x55998c80, _positionalArgs=0x0, _ctx=0x5578e790) at ./sope-appserver/NGObjWeb/SoObjects/SoActionInvocation.m:300 #6 0x779ea39b in -[SoActionInvocation callOnObject:inContext:] (self=0x55752f70, _cmd=0x77b229a0 <_OBJC_SELECTOR_TABLE+672>, _client=0x55998c80, _ctx=0x5578e790) at ./sope-appserver/NGObjWeb/SoObjects/SoActionInvocation.m:318 #7 0x779e4031 in -[SoObjectMethodDispatcher dispatchInContext:] (self=0x55de1e60, _cmd=0x77b24e40 <_OBJC_SELECTOR_TABLE+1536>, _ctx=0x5578e790) at ./sope-appserver/NGObjWeb/SoObjects/SoObjectMethodDispatcher.m:192 #8 0x779e685c in -[SoObjectRequestHandler handleRequest:inContext:session:application:] (self=0x55a978b0, _cmd=0x77aaec10 <_OBJC_SELECTOR_TABLE+848>, _rq=0x555e9f30, _ctx=0x5578e790, _sn=0x0, app=0x55998c80) at ./sope-appserver/NGObjWeb/SoObjects/SoObjectRequestHandler.m:584 #9 0x779605cd in -[WORequestHandler handleRequest:] (self=0x55a978b0, _cmd=0x77a77190 <_OBJC_SELECTOR_TABLE+1616>, _request=0x555e9f30) at ./sope-appserver/NGObjWeb/WORequestHandler.m:240 #10 0x7791aa2b in -[WOCoreApplication dispatchRequest:usingHandler:] (self=0x55998c80, _cmd=0x77a771e0 <_OBJC_SELECTOR_TABLE+1696>, _request=0x555e9f30, handler=0x55a978b0) at ./sope-appserver/NGObjWeb/WOCoreApplication.m:712 #11 0x7791ad96 in -[WOCoreApplication dispatchRequest:] (self=0x55998c80, _cmd=0x55567520 <_OBJC_SELECTOR_TABLE+1664>, _request=0x555e9f30) at ./sope-appserver/NGObjWeb/WOCoreApplication.m:752 #12 0xd9b5 in -[SOGo dispatchRequest:] (self=0x55998c80, _cmd=0x77b14d00 <_OBJC_SELECTOR_TABLE+1760>, _request=0x555e9f30) at ./Main/SOGo.m:584 #13 0x779d2c28 in -[WOHttpTransaction _run] (self=0x558f2470, _cmd=0x77b14d30 <_OBJC_SELECTOR_TABLE+1808>) at ./sope-appserver/NGObjWeb/WOHttpAdaptor/WOHttpTransaction.m:566 #14 0x779d2fee in -[WOHttpTransaction run] (self=0x558f2470, _cmd=0x77b11250 <_OBJC_SELECTOR_TABLE+1168>) at ./sope-appserver/NGObjWeb/WOHttpAdaptor/WOHttpTransaction.m:619 #15 0x779ce5e6 in -[WOHttpAdaptor runConnection:] (self=0x558f1fd0, _cmd=0x77b112f0 <_OBJC_SELECTOR_TABLE+1328>, _socket=0x55a7df70) at ./sope-appserver/NGObjWeb/WOHttpAdaptor/WOHttpAdaptor.m:373 #16 0x779ce83d in -[WOHttpAdaptor _handleAcceptedConnection:] (self=0x558f1fd0, _cmd=0x77b11300 <_OBJC_SELECTOR_TABLE+1344>, _connection=0x55a7df70) at ./sope-appserver/NGObjWeb/WOHttpAdaptor/WOHttpAdaptor.m:407 #17 0x779cecb6 in -[WOHttpAdaptor _handleConnection:] (self=0x558f1fd0, _cmd=0x77b113a0 <_OBJC_SELECTOR_TABLE+1504>, connection=0x55a7df70) at ./sope-appserver/NGObjWeb/WOHttpAdaptor/WOHttpAdaptor.m:466 #18 0x779cf1c7 in -[WOHttpAdaptor acceptConnection:] (self=0x558f1fd0, _cmd=0x77b11210 <_OBJC_SELECTOR_TABLE+1104>, _notification=0x5574f650) at ./sope-appserver/NGObjWeb/WOHttpAdaptor/WOHttpAdaptor.m:527 --Type for more, q to quit, c to
Re: [SOGo] SAML login not working / Keycloak 21.1.1 / Debian bookworm
In your logs you have a segfault. You need to provide a backtrace according to
https://www.sogo.nu/support/faq/how-do-i-debug-sogo.html
Sebastien
Le Samedi, Juin 24, 2023 13:38 CEST, "Claas Hilbrecht"
(claas-pool.s...@linum.com) a écrit:
Hi,
I try to get a SAML login working and failed. I read a lot in this
list and think I'm pretty close towards a working setup. I managed to
get redirected to the IDP login screen and while I get redirected back
to SOGo I get this error message:
---
Proxy Error
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request
Reason: Error reading from remote server
---
The sogo.log to this request is:
---
Jun 24 11:16:38 sogod [2131]: |SOGo| starting method 'GET' on uri '/SOGo'
Jun 24 11:16:38 sogod [2131]: <0x0x5572c15faaa0[SOGoCache]> Cache
cleanup interval set every 3600.00 seconds
Jun 24 11:16:38 sogod [2131]: <0x0x5572c15faaa0[SOGoCache]> Using
host(s) '127.0.0.1' as server(s)
Jun 24 11:16:38 sogod [2131]: [WARN]
<0x0x7fc5bc4d8a80[WOxElemBuilder]> could not locate builders:
WOxExtElemBuilder,WOxExtElemBuilder
Jun 24 11:16:38 sogod [2131]: [ERROR]
<0x0x5572c19e0770[SOGoUserManager]> No authentication sources defined
- nobody will be able to login. Check your defaults.
2023-06-24 11:16:38.057 sogod[2131:2131]
SQL:
SELECT c_defaults FROM sogo_user_profile WHERE c_uid = 'anonymous';
2023-06-24 11:16:38.058 sogod[2131:2131]
query
has results, entering fetch-mode.
Jun 24 11:16:38 sogod [2131]: |SOGo| request took 0.152470 seconds to execute
Jun 24 11:16:38 sogod [2131]: 79.140.187.148, 172.27.11.107 "GET /SOGo
HTTP/1.1" 302 0/0 0.155 - - 6M - 12
Jun 24 11:16:44 sogod [2131]: |SOGo| starting method 'POST' on uri
'/SOGo/saml2-signon-post'
Jun 24 11:16:44 sogod [2128]: <0x0x5572c1604cf0[WOWatchDogChild]>
child 2131 exited
Jun 24 11:16:44 sogod [2128]: <0x0x5572c1604cf0[WOWatchDogChild]>
(terminated due to signal 11)
Jun 24 11:16:44 sogod [2128]: <0x0x5572c1543c80[WOWatchDog]> child
spawned with pid 2135
2023-06-24 11:16:44.602 sogod[2135:2135] MySQL4 connection established
0x0x5572c168a150
2023-06-24 11:16:44.602 sogod[2135:2135] -- -[MySQL4Channel
openChannel]: opens channel count[0]
2023-06-24 11:16:44.602 sogod[2135:2135] MySQL4 channel
0x0x5572c155ae80 opened (connection=0x0x5572c168a150,sogo)
2023-06-24 11:16:44.602 sogod[2135:2135]
SQL:
SELECT 1 FROM sogo_user_profile WHERE 1 = 2;
2023-06-24 11:16:44.603 sogod[2135:2135]
query
has results, entering fetch-mode.
2023-06-24 11:16:44.603 sogod[2135:2135]
SQL:
SELECT 1 FROM sogo_folder_info WHERE 1 = 2;
2023-06-24 11:16:44.603 sogod[2135:2135]
query
has results, entering fetch-mode.
2023-06-24 11:16:44.605 sogod[2135:2135]
SQL:
SELECT 1 FROM sogo_sessions_folder WHERE 1 = 2;
2023-06-24 11:16:44.605 sogod[2135:2135]
query
has results, entering fetch-mode.
Jun 24 11:16:44 sogod [2135]: <0x0x5572c176b150[WOHttpAdaptor]>
notified the watchdog that we are ready
---
I think the WOWatchDogChild kills for whatever reason the login
process... Previously I got a this error:
---
sogo.log.1:2023-06-22 19:10:31.616 sogod[4831:4831] EXCEPTION:
NAME:NSInvalidArgumentException
REASON:Tried to add nil value for key 'login' to dictionary INFO:{}
---
But after adding a login key (as a AttributeStatement Mapper/User
Property) to the SAML answer the above error message is thrown.
I try to get the SAML login working with Debian bookworm and Keykoack 21.1.1.
---
dpkg -l | grep -e 'sogo\|sope'
ii libsope1 5.8.0-1
amd64 SKYRiX Object Publishing Environment (shared libraries)
ii sogo 5.8.0-1
amd64 Scalable groupware server
ii sogo-activesync 5.8.0-1
amd64 Scalable groupware server - ActiveSync module
ii sogo-common 5.8.0-1 all
Scalable groupware server - common files
---
My sogo.conf looks like this:
---
{
SOGoDebugRequests = YES;
SoDebugBaseURL = YES;
SOGoEASDebugEnabled = YES;
ImapDebugEnabled = YES;
LDAPDebugEnabled = YES;
MySQL4DebugEnabled = YES;
PGDebugEnabled = YES;
SOGoUIxDebugEnabled = YES;
WODontZipResponse = YES;
/* Authentication */
SOGoPasswordChangeEnabled = NO;
/* Web Interface */
SOGoPageTitle = SOGo;
//SOGoVacationEnabled = YES;
//SOGoForwardEnabled = YES;
//SOGoSieveScriptsEnabled = YES;
//SOGoMailAuxiliaryUserAccountsEnabled = YES;
//SOGoTrustProxyAuthentication = NO;
//SOGoXSRFValidationEnabled = YES;
MySQL4Encoding = "utf8mb4";
SOGoProfileURL =
"mysql://user:password@127.0.0.1:3306/sogo/sogo_user_profile";
OCSFolderInfoURL =
"mysql://user:password@127.0.0.1:3306/sogo/sogo_folder_info";
OCSSessionsFolderURL =
"mysql://user:password@127.0.0.1:3306/sogo/sogo_sessions_folder";
OCSEMailAlarmsFolderURL =
"mysql://user:password@127.0.0.1:3306/sogo/sogo_alarms_folder";
SOGoLanguage = English;
SOGoAppointmentSendEMailNotifications = YES;
SOGoMailingMechanism = smtp;
SOGoSMTPServer = 127.0.0.1;
SOGoTimeZone = UTC;
SOGoSentFolderName = Sent;
SOGoTrashFolderName = Trash;
SOGoDraftsFolderName = Drafts;
SOGoIMAPServer =
Re: [SOGo] Timeout to fetch web calendars configurable?
Hello Frank, If you are using Apache in front, maybe you can try to increase timeout as explained here : https://serverfault.com/questions/948312/apache-reverse-proxy-timeout-in-60-seconds Sebastien Le Vendredi, Juin 23, 2023 09:42 CEST, "Frank Richter" (frank.rich...@hrz.tu-chemnitz.de) a écrit: Hello, when users subscribe to web calendars (CalDAV) we see timeouts, when the CalDAV server answers too slow: Jun 23 09:27:11 sogod [2125260]: <0x5574f1f944d0[SOGoWebAppointmentFolder]:206DCC-64954980-19-3E98F2C0> Load web calendar https://….tu-chemnitz.de/users/…/calendar/ (401) Jun 23 09:27:39 sogod [2125260]: [ERROR] <0x5574f190c590[SOGoWebAppointmentFolder]:206DCC-64954980-19-3E98F2C0> CURL error while accessing https://….tu-chemnitz.de/users/…/calendar/ (28): Operation timed out after 2 milliseconds with 229376 bytes received Is this timeout value configurable in SOGo? Thanks, Frank -- Frank Richter Chemnitz University of Technology, Germany
