You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(10) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(8) |
Feb
(10) |
Mar
(4) |
Apr
(9) |
May
(21) |
Jun
(11) |
Jul
(2) |
Aug
(5) |
Sep
(9) |
Oct
(4) |
Nov
(25) |
Dec
(17) |
| 2008 |
Jan
(16) |
Feb
(23) |
Mar
(13) |
Apr
(41) |
May
(32) |
Jun
(18) |
Jul
(23) |
Aug
(12) |
Sep
(2) |
Oct
(29) |
Nov
(20) |
Dec
(21) |
| 2009 |
Jan
(22) |
Feb
(5) |
Mar
(23) |
Apr
(5) |
May
(13) |
Jun
(54) |
Jul
(52) |
Aug
(32) |
Sep
(14) |
Oct
(92) |
Nov
(73) |
Dec
(29) |
| 2010 |
Jan
(84) |
Feb
(65) |
Mar
(89) |
Apr
(82) |
May
(59) |
Jun
(123) |
Jul
(64) |
Aug
(66) |
Sep
(100) |
Oct
(100) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(55) |
Feb
(92) |
Mar
(96) |
Apr
(47) |
May
(49) |
Jun
(32) |
Jul
(51) |
Aug
(22) |
Sep
(142) |
Oct
(111) |
Nov
(69) |
Dec
(57) |
| 2012 |
Jan
(125) |
Feb
(50) |
Mar
(39) |
Apr
(84) |
May
(80) |
Jun
(37) |
Jul
(124) |
Aug
(28) |
Sep
(52) |
Oct
(81) |
Nov
(38) |
Dec
(33) |
| 2013 |
Jan
(36) |
Feb
(49) |
Mar
(47) |
Apr
(88) |
May
(21) |
Jun
(15) |
Jul
(27) |
Aug
(22) |
Sep
(70) |
Oct
(39) |
Nov
(57) |
Dec
(30) |
| 2014 |
Jan
(59) |
Feb
(57) |
Mar
(71) |
Apr
(59) |
May
(12) |
Jun
(29) |
Jul
(13) |
Aug
(24) |
Sep
(26) |
Oct
(25) |
Nov
(18) |
Dec
(38) |
| 2015 |
Jan
(33) |
Feb
(3) |
Mar
(15) |
Apr
(17) |
May
(7) |
Jun
(12) |
Jul
(29) |
Aug
(52) |
Sep
(36) |
Oct
(12) |
Nov
(61) |
Dec
(22) |
| 2016 |
Jan
(47) |
Feb
(9) |
Mar
(13) |
Apr
(41) |
May
(21) |
Jun
(13) |
Jul
(8) |
Aug
(5) |
Sep
(16) |
Oct
(11) |
Nov
(2) |
Dec
(11) |
| 2017 |
Jan
(9) |
Feb
(12) |
Mar
(3) |
Apr
(15) |
May
(12) |
Jun
(2) |
Jul
(5) |
Aug
(4) |
Sep
(11) |
Oct
(9) |
Nov
|
Dec
(6) |
| 2018 |
Jan
(10) |
Feb
(7) |
Mar
(2) |
Apr
|
May
(16) |
Jun
(2) |
Jul
|
Aug
(3) |
Sep
(2) |
Oct
(7) |
Nov
(6) |
Dec
(13) |
| 2019 |
Jan
(4) |
Feb
|
Mar
(11) |
Apr
|
May
(3) |
Jun
(5) |
Jul
(8) |
Aug
(4) |
Sep
(5) |
Oct
(2) |
Nov
|
Dec
(15) |
| 2020 |
Jan
|
Feb
(7) |
Mar
|
Apr
(2) |
May
(6) |
Jun
|
Jul
(2) |
Aug
(9) |
Sep
(1) |
Oct
(19) |
Nov
(30) |
Dec
(2) |
| 2021 |
Jan
(9) |
Feb
(10) |
Mar
(2) |
Apr
|
May
(3) |
Jun
|
Jul
(1) |
Aug
(4) |
Sep
(19) |
Oct
(1) |
Nov
(4) |
Dec
|
| 2022 |
Jan
(8) |
Feb
|
Mar
(1) |
Apr
(2) |
May
|
Jun
(3) |
Jul
(4) |
Aug
|
Sep
(2) |
Oct
(27) |
Nov
|
Dec
(3) |
| 2023 |
Jan
(5) |
Feb
(2) |
Mar
|
Apr
(8) |
May
(7) |
Jun
(21) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(3) |
Dec
(1) |
| 2024 |
Jan
(2) |
Feb
(14) |
Mar
(3) |
Apr
(8) |
May
(6) |
Jun
|
Jul
(2) |
Aug
|
Sep
(2) |
Oct
|
Nov
(1) |
Dec
(3) |
| 2025 |
Jan
(4) |
Feb
(7) |
Mar
(2) |
Apr
|
May
(12) |
Jun
|
Jul
|
Aug
(4) |
Sep
(1) |
Oct
(1) |
Nov
(2) |
Dec
|
| 2026 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Giuseppe S. <giu...@sg...> - 2026-02-16 10:01:38
|
Hello, I just moved Davical from one old machine to a new hardware and updated from debian 12 (davical version 1.1.12-2) to debian 13 (davical version 1.1.12- 2.1). Davical is behind nginx and uses postgresql locally, as before. The database has been copied to the new machine, as well. Old postgresql was version 15, new version is 17. Nginx web site configuration was copied as is. PHP changed from 8.2 to 8.4. The administration web interface works, all users are authenticated. But... when synchronizing calendars from clients, we get this error message in nginx log (i replaced user and host names): 2026/02/16 09:50:22 [error] 18395#18395: *2373 FastCGI sent in stderr: " PHP message: davical: LOG: :Response status 403 for REPORT /caldav.php/$myuser/calendar/; PHP message: davical: LOG: :***************** Response Header ****************; PHP message: davical: LOG: headers:-->Server: 1.1; PHP message: davical: LOG: headers:-->DAV: 1, 2, 3, access-control, calendar-access, calendar-schedule; PHP message: davical: LOG: headers:-->DAV: extended-mkcol, bind, addressbook, calendar-auto-schedule, calendar-proxy; PHP message: davical: LOG: headers:-->X-DAViCal-Version: DAViCal/1.1.12; DB/1.3.5; PHP message: davical: LOG: headers:-->Content-type: text/plain; charset="utf-8"; PHP message: davical: LOG: :******************** Response ********************; PHP message: davical: LOG: response:-->The calendar-query report must be run against a calendar or a scheduling collection" while reading response header from upstream, client: 79.X.Y.Z, server: cal.$mydomain, request: "REPORT /caldav.php/$myuser/calendar/ HTTP/2.0", upstream: "fastcgi://unix:/run/php/php8.4-fpm.sock:", host: "cal.$mydomain" Do you have idea of what could be the problem or how to identify it? Thank you very much, Giuseppe |
|
From: <sou...@pa...> - 2025-11-02 22:00:54
|
On 11/2/25 08:02, Julien Métairie via Davical-general - davical-general at lists.sourceforge.net wrote: > Hello, > > I upgraded from Debian 12 to Debian 13 (Trixie). AWL and Davical > versions do not change across migration (respectively 0.64 and 1.1.12), > but Postgres cluster was upgraded from 15 to 17 as part of the process. > > Before migration, I had an external binding for official holidays. > > However this external binding disappeared during the process. My DAV > client now gets a 404 response when trying to get it. > It appears that the "dav_binding" table is now empty. I found the > following in /var/log/apt/term.log: > > pg_restore: erreur : COPY échoué pour la table « dav_binding » : ERREUR: > la relation « collection » n'existe pas > [...] > REQUÊTE : SELECT TRUE FROM collection WHERE dav_name = in_path > CONTEXTE : fonction PL/pgSQL public.real_path_exists(text), ligne 16 à > instruction SQL > COPY dav_binding, ligne 1 : « 43806 43805 \N 1001 > /ruliane/ /ruliane/joursferies/ Jours fériés > https://etalab.github.io/jours-fe... » > pg_restore: attention : erreurs ignorées lors de la restauration : 1 > > > I'm not sure why the automatic Postgres upgrade process didn't manage to > fully restore the content of DAViCal database. Is somebody aware of this > issue ? > > Regards > Julien Hello Julien, I've found that upgrading from Debian 12 to 13 using just aptitude, results in problems. So I have created a minimal KVM image and a KDE image and use these as 'cardinal' images and am flanging each of my VMs into these as I have time. In Davical I have all US holidays using this method. With a major upgrade it's usually best to just reinstall, with as much time as that takes. Carl |
|
From: Julien M. <rul...@ru...> - 2025-11-02 16:19:07
|
Hello, I upgraded from Debian 12 to Debian 13 (Trixie). AWL and Davical versions do not change across migration (respectively 0.64 and 1.1.12), but Postgres cluster was upgraded from 15 to 17 as part of the process. Before migration, I had an external binding for official holidays. However this external binding disappeared during the process. My DAV client now gets a 404 response when trying to get it. It appears that the "dav_binding" table is now empty. I found the following in /var/log/apt/term.log: pg_restore: erreur : COPY échoué pour la table « dav_binding » : ERREUR: la relation « collection » n'existe pas [...] REQUÊTE : SELECT TRUE FROM collection WHERE dav_name = in_path CONTEXTE : fonction PL/pgSQL public.real_path_exists(text), ligne 16 à instruction SQL COPY dav_binding, ligne 1 : « 43806 43805 \N 1001 /ruliane/ /ruliane/joursferies/ Jours fériés https://etalab.github.io/jours-fe... » pg_restore: attention : erreurs ignorées lors de la restauration : 1 I'm not sure why the automatic Postgres upgrade process didn't manage to fully restore the content of DAViCal database. Is somebody aware of this issue ? Regards Julien |
|
From: C. A. <nox...@al...> - 2025-10-17 15:27:41
|
Hi, One of my externally bound calendars has recently stopped updating. The following error message is written to log file multiple times a day: FATAL: :Cannot begin a transaction while a transaction is already active. ================= Stack Trace =================== ===> /usr/share/davical/htdocs/caldav.php[110] calls include() ===> /usr/share/davical/inc/caldav-PROPFIND.php[274] calls get_collection_contents() ===> /usr/share/davical/inc/caldav-PROPFIND.php[151] calls update_external() ===> /usr/share/davical/inc/external-fetch.php[126] calls fetch_external() ===> /usr/share/davical/inc/external-fetch.php[94] calls import_collection() ===> /usr/share/davical/inc/caldav-PUT-functions.php[789] calls import_calendar_collection() ===> /usr/share/davical/inc/caldav-PUT-functions.php[1066] calls AwlQuery->Begin() ===> /usr/share/awl/inc/AwlQuery.php[478] calls AwlDatabase->Begin() I confirmed that the remote calendar is accessible and has new events by navigating to the remote calendar manually using a web browser. I have a second externally bound calendar and there have been no issues observed with respect to that one. I enabled the debug logging options 'external', 'report', 'propfind', 'get', and 'querystring'. The following is written immediately prior the above error message(leading timestamps, etc. removed from each line for clarity/brevity): DBG: external:checking if external resource needs update LOG: DAVResource: Query: DBGQ: SELECT bind_id, external_url as url from dav_binding LEFT JOIN collection ON (collection.collection_id=bound_source_id) WHERE dav_binding.dav_name = :dav_name AND ( collection.modified + interval :interval < NOW() OR collection.modified is LOG: DAVResource: Query: DBGQ: NULL ) LOG: DAVResource: Query: DBGQ: ":dav_name" => "/<user_name>/<calendar_name>/" LOG: DAVResource: Query: DBGQ: ":interval" => "60 minutes" LOG: DAVResource: Query: DBGQ: Took: 0.001851 to find 1 rows. DBG: external:external resource needs updating, this might take a minute : https://<domain_name>/sites/202408/ahmh_equipe_15/index.php?page=calics&id=0 LOG: DAVResource: Query: DBGQ: SELECT collection.*, collection.dav_name AS path, dav_binding.external_url AS external_url FROM dav_binding LEFT JOIN collection ON (collection.collection_id=bound_source_id) WHERE bind_id = :bind_id AND ( collection.modified + interval :interval < NOW() OR collection.modified is NULL ) ORDER BY modified DESC LIMIT 1 LOG: DAVResource: Query: DBGQ: ":bind_id" => "13437" LOG: DAVResource: Query: DBGQ: ":interval" => "60 minutes" LOG: DAVResource: Query: DBGQ: Took: 0.002770 to find 1 rows. DBG: external:checking external resource for remote changes https://<domain_name>/sites/202408/ahmh_equipe_15/index.php?page=calics&id=0 DBG: external:external resource changed, re importing-1 LOG: DAVResource: Query: DBGQ: UPDATE collection SET modified=NOW(), dav_etag=:etag WHERE collection_id = :cid LOG: DAVResource: Query: DBGQ: ":cid" => "13436" LOG: DAVResource: Query: DBGQ: ":etag" => "0eb6b09e2fa9a7e5c403d2cea38f2cb7" LOG: DAVResource: Query: DBGQ: Took: 0.004660 to find 1 rows. LOG: PUT: Query: DBGQ: SELECT * FROM collection WHERE dav_name = :dav_name LOG: PUT: Query: DBGQ: ":dav_name" => "/.external/52035882f54fd16909f5ef7596369894" LOG: PUT: Query: DBGQ: Took: 0.000904 to find 1 rows. LOG: PUT: Query: DBGQ: SELECT dav_name, caldav_data FROM caldav_data WHERE collection_id=:collection_id LOG: PUT: Query: DBGQ: ":collection_id" => "13436" LOG: PUT: Query: DBGQ: Took: 0.001940 to find 6 rows. LOG: PUT: Query: DBGQ: SELECT new_sync_token(0,13436) LOG: PUT: Query: DBGQ: Took: 0.003539 to find 1 rows. FATAL: :Cannot begin a transaction while a transaction is already active. ... Does anyone have any insight into the likely cause(s) of the problem and suggestions of how to remedy the situation? Thanks. Until next time, Colin. |
|
From: Harald N. <hoc...@gm...> - 2025-09-03 00:04:51
|
Solved - it was exactly the problem described here: https://gitlab.com/davical-project/davical/-/issues/171 specifically the command sudo -u postgres psql davical -f /usr/share/davical/dba/caldav_functions.sql br, Harald Am 31.08.25 um 15:13 schrieb Harald Nikolisin: > Hello, > > I migrated an old davical installation (davical 1.1.7 / postgresql 9.2 > / php 5.6 / apache 2.2) > to a new server environment which uses (davical 1.1.7 / postgresql 11 > / php 7.4 / apache 2.4) > > Actually it runs out of the box, but only with the private calendars. > Currently there are 4 users in that setup - each of them has their own > calendar, but there is also a "group principal" where every of the 4 > user is member of. Principals grants were set to have read/write > access from every user. > > In the old system everything worked. Every user had r/w access to the > group calendar. Even the free/busy system worked (at least with > clients which supported it, like Thunderbird calendar) > > In the new system neither the group calendar, nor the free/busy access > of the other calenders is working. > > What I did is to copy the database to an experimental server, also > with postgresql 11 / php 7.4 and apache 2.4. > Here I updated davial - first to 1.1.9-3 (database schema update to > 1.3.3) and then to the lastest version 1.1.12 (database schema upgrade > to 1.3.5). > > Unfortunately without success - does anybody has an idea? > My davical config file contains only 3 entries (c->domainname, > c->admin-email, c->pg_connect). > > best regards, > Harald > > |
|
From: Harald N. <hoc...@gm...> - 2025-08-31 13:13:25
|
Hello, I migrated an old davical installation (davical 1.1.7 / postgresql 9.2 / php 5.6 / apache 2.2) to a new server environment which uses (davical 1.1.7 / postgresql 11 / php 7.4 / apache 2.4) Actually it runs out of the box, but only with the private calendars. Currently there are 4 users in that setup - each of them has their own calendar, but there is also a "group principal" where every of the 4 user is member of. Principals grants were set to have read/write access from every user. In the old system everything worked. Every user had r/w access to the group calendar. Even the free/busy system worked (at least with clients which supported it, like Thunderbird calendar) In the new system neither the group calendar, nor the free/busy access of the other calenders is working. What I did is to copy the database to an experimental server, also with postgresql 11 / php 7.4 and apache 2.4. Here I updated davial - first to 1.1.9-3 (database schema update to 1.3.3) and then to the lastest version 1.1.12 (database schema upgrade to 1.3.5). Unfortunately without success - does anybody has an idea? My davical config file contains only 3 entries (c->domainname, c->admin-email, c->pg_connect). best regards, Harald |
|
From: Julien M. <rul...@ru...> - 2025-08-24 19:32:53
|
Hi Jim, I would have no difficulty with registering, but I didn't try to. And I think it should be mandatory to register before requesting or providing with some help. Spam may be a problem, though I've never be witness of spam on any of the IRC channels I am connected to. Regards, Julien -------- Message d'origine -------- De : Jim Fenton <fe...@bl...> Envoyé : vendredi 22 août 2025 à 8:29 PM UTC+2 Pour : Julien Métairie <rul...@ru...> Copie à : dav...@li... Sujet : RE: [Davical-general] Unable to send messages on #davical channel (mode +M) Hi Julien, Apologies, it has been a while since I’ve been on the IRC channel. As I remember, the main reason for the +M mode was to discourage spam on the channel, and that is an ongoing problem. Is there a difficulty with registering yourself so that you can use the channel? -Jim On 19 Aug 2025, at 6:58, Julien Métairie via Davical-general wrote: >> Hello, >> >> The #davical IRC channel on OFTC has +M mode, which mean that only registered people can send message. As an unregistered user, any message I send is replied by the following: >> #davical Cannot send to channel (You are not registered and verified. '/msg NickServ help' to learn how to register and verify) >> >> >> I think admins should consider removing +M mode, since this channel is supposed to receive questions from any user. >> >> Regards, >> Julien >> >> >> _______________________________________________ >> Davical-general mailing list >> Dav...@li... >> https://lists.sourceforge.net/lists/listinfo/davical-general |
|
From: Jim F. <fe...@bl...> - 2025-08-22 18:58:36
|
Hi Julien, Apologies, it has been a while since I’ve been on the IRC channel. As I remember, the main reason for the +M mode was to discourage spam on the channel, and that is an ongoing problem. Is there a difficulty with registering yourself so that you can use the channel? -Jim On 19 Aug 2025, at 6:58, Julien Métairie via Davical-general wrote: > Hello, > > The #davical IRC channel on OFTC has +M mode, which mean that only registered people can send message. As an unregistered user, any message I send is replied by the following: > #davical Cannot send to channel (You are not registered and verified. '/msg NickServ help' to learn how to register and verify) > > > I think admins should consider removing +M mode, since this channel is supposed to receive questions from any user. > > Regards, > Julien > > > _______________________________________________ > Davical-general mailing list > Dav...@li... > https://lists.sourceforge.net/lists/listinfo/davical-general |
|
From: <rul...@ru...> - 2025-08-19 14:16:10
|
Hello, The #davical IRC channel on OFTC has +M mode, which mean that only registered people can send message. As an unregistered user, any message I send is replied by the following: #davical Cannot send to channel (You are not registered and verified. '/msg NickServ help' to learn how to register and verify) I think admins should consider removing +M mode, since this channel is supposed to receive questions from any user. Regards, Julien |
|
From: <sou...@pa...> - 2025-05-11 20:29:24
|
Thank you. Yours is quite complex -- the php sections are the determining factor in my case. Hopefully I'll have time at some point to decrypt your blocks. On Saturday, May 10th, 2025 at 23:13, Pierre Couderc via Davical-general - davical-general at lists.sourceforge.net <dav...@pa...> wrote: > > > > > > On 5/9/25 22:52, Julien Métairie via Davical-general wrote: > > > Hi, > > > > The wiki[1] is discouraging from using nginx to serve DAViCal. > > However, if you can share your nginx configuration, maybe someone on > > the list will be able to give you some hint. > > > > [1] https://wiki.davical.org/index.php?title=Nginx_Config > > Mmm; I did not imagine Apache being still used... > > Here is my config, which works since more that10 years but which > separates admin from user : there were good reasons then... I am no > more able to comment it and explain it and it gives some wanings in nginx... > > Admin (controlled by toldev authentification) : > > > server { > server_name davical.couderc.eu davical.secours.couderc.eu; > ssl_certificate /etc/acme/fullchain/davical.couderc.eu.pem; > ssl_certificate_key /etc/acme/key/davical.couderc.eu.pem; > root /usr/share/davical/htdocs; > index index.html index.htm index.php index.pl; > # begin : https section > listen 443 ssl http2 ; > listen [::]:443 ssl http2; > # les parametres généraux de ssl sont inclus dans : > include /etc/nginx/pc_https.conf ; > > # end : https section > keepalive_timeout 0; > client_max_body_size 8M; # has to be same size as in > php.ini, else worthless! > > > location /images/ { > } > ssl_client_certificate /root/CA/ca.crt; > ssl_verify_client optional; > > location / { > auth_basic_user_file /etc/nginx/toldev.password; > if ($ssl_client_verify = SUCCESS) { > set $auth_basic off; > } > if ($ssl_client_verify != SUCCESS) { > set $auth_basic "toldev"; > } > auth_basic $auth_basic; > > try_files $uri $uri/ =404; > } > > location ~ ^(.+\.php)(.)$ { > include fastcgi_params; > fastcgi_param SCRIPT_FILENAME > $document_root$fastcgi_script_name; > include /etc/nginx/fastcgi_pass_php_socket; > fastcgi_split_path_info ^(.+\.php)(.)$; > fastcgi_param PATH_INFO $fastcgi_path_info; > fastcgi_param PATH_TRANSLATED > $document_root$fastcgi_path_info; > fastcgi_read_timeout 180; > fastcgi_buffer_size 128k; > fastcgi_buffers 4 256k; > } > > location ~ .php$ { > try_files $uri =404; > include fastcgi_params; > include /etc/nginx/fastcgi_pass_php_socket; > fastcgi_index index.php; > fastcgi_split_path_info ^(.+\.php)(.)$; > fastcgi_param SCRIPT_FILENAME > $document_root$fastcgi_script_name; > fastcgi_param PATH_INFO $fastcgi_path_info; > fastcgi_param PATH_TRANSLATED > $document_root$fastcgi_path_info; > } > > > location =caldavzap/ { > > > try_files /infcloud/index.html =404; > auth_basic off; > add_header Cache-Control "max-age=0, must-revalidate, no-cache, > no-transform, private"; > > } > location /carddavmate/ { > > auth_basic off; > add_header Cache-Control "max-age=0, must-revalidate, no-cache, > no-transform, private"; > } > > } > > User : > > server { > server_name agenda.couderc.eu; > root /usr/share/davical/htdocs; > index index.html index.htm index.php index.pl; > # begin : https section > listen 443 ssl http2 ; > listen [::]:443 ssl http2; > # les parametres généraux de ssl sont inclus dans : > include /etc/nginx/pc_https.conf ; > ssl_certificate /etc/acme/fullchain/agenda.couderc.eu.pem; > ssl_certificate_key /etc/acme/key/agenda.couderc.eu.pem; > > # end : https section > # > keepalive_timeout 0; > client_max_body_size 12M; # has to be same size as in > php.ini, else worthless! > > > location /images/ { > } > > location / { > return 301 https://agenda.couderc.eu/caldavzap/; > try_files $uri $uri/ =404; > } > location /admin.php { > return 301 https://agenda.couderc.eu/caldavzap/; > try_files $uri $uri/ =404; > } > > location ~ ^(.+\.php)(.)$ { > include fastcgi_params; > fastcgi_param SCRIPT_FILENAME > $document_root$fastcgi_script_name; > include /etc/nginx/fastcgi_pass_php_socket; > fastcgi_split_path_info ^(.+\.php)(.)$; > fastcgi_param PATH_INFO $fastcgi_path_info; > fastcgi_param PATH_TRANSLATED > $document_root$fastcgi_path_info; > fastcgi_read_timeout 180; > fastcgi_buffer_size 128k; > fastcgi_buffers 4 256k; > } > > location ~ .php$ { > try_files $uri =404; > include fastcgi_params; > include /etc/nginx/fastcgi_pass_php_socket; > fastcgi_index index.php; > fastcgi_split_path_info ^(.+\.php)(.)$; > fastcgi_param SCRIPT_FILENAME > $document_root$fastcgi_script_name; > fastcgi_param PATH_INFO $fastcgi_path_info; > fastcgi_param PATH_TRANSLATED > $document_root$fastcgi_path_info; > } > > > location /caldavzap/ { > > > add_header Cache-Control "max-age=0, must-revalidate, no-cache, > no-transform, private"; > try_files $uri $uri/ =404; > } > location /carddavmate/ { > > add_header Cache-Control "max-age=0, must-revalidate, no-cache, > no-transform, private"; > } > > } > > > > > _______________________________________________ > Davical-general mailing list > Dav...@li... > https://lists.sourceforge.net/lists/listinfo/davical-general |
|
From: Pierre C. <pi...@co...> - 2025-05-11 06:08:25
|
On 5/9/25 22:52, Julien Métairie via Davical-general wrote: > Hi, > > The wiki[1] is discouraging from using nginx to serve DAViCal. > However, if you can share your nginx configuration, maybe someone on > the list will be able to give you some hint. > > [1] https://wiki.davical.org/index.php?title=Nginx_Config > > Mmm; I did not imagine Apache being still used... Here is my config, which works since more that10 years but which separates admin from user : there were good reasons then... I am no more able to comment it and explain it and it gives some wanings in nginx... Admin (controlled by toldev authentification) : server { server_name davical.couderc.eu davical.secours.couderc.eu; ssl_certificate /etc/acme/fullchain/davical.couderc.eu.pem; ssl_certificate_key /etc/acme/key/davical.couderc.eu.pem; root /usr/share/davical/htdocs; index index.html index.htm index.php index.pl; # begin : https section listen 443 ssl http2 ; listen [::]:443 ssl http2; # les parametres généraux de ssl sont inclus dans : include /etc/nginx/pc_https.conf ; # end : https section keepalive_timeout 0; client_max_body_size 8M; # has to be same size as in php.ini, else worthless! location /images/ { } ssl_client_certificate /root/CA/ca.crt; ssl_verify_client optional; location / { auth_basic_user_file /etc/nginx/toldev.password; if ($ssl_client_verify = SUCCESS) { set $auth_basic off; } if ($ssl_client_verify != SUCCESS) { set $auth_basic "toldev"; } auth_basic $auth_basic; try_files $uri $uri/ =404; } location ~ ^(.+\.php)(.*)$ { include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include /etc/nginx/fastcgi_pass_php_socket; fastcgi_split_path_info ^(.+\.php)(.*)$; fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info; fastcgi_read_timeout 180; fastcgi_buffer_size 128k; fastcgi_buffers 4 256k; } location ~ .php$ { try_files $uri =404; include fastcgi_params; include /etc/nginx/fastcgi_pass_php_socket; fastcgi_index index.php; fastcgi_split_path_info ^(.+\.php)(.*)$; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info; } location =caldavzap/ { try_files /infcloud/index.html =404; auth_basic off; add_header Cache-Control "max-age=0, must-revalidate, no-cache, no-transform, private"; } location /carddavmate/ { auth_basic off; add_header Cache-Control "max-age=0, must-revalidate, no-cache, no-transform, private"; } } User : server { server_name agenda.couderc.eu; root /usr/share/davical/htdocs; index index.html index.htm index.php index.pl; # begin : https section listen 443 ssl http2 ; listen [::]:443 ssl http2; # les parametres généraux de ssl sont inclus dans : include /etc/nginx/pc_https.conf ; ssl_certificate /etc/acme/fullchain/agenda.couderc.eu.pem; ssl_certificate_key /etc/acme/key/agenda.couderc.eu.pem; # end : https section # keepalive_timeout 0; client_max_body_size 12M; # has to be same size as in php.ini, else worthless! location /images/ { } location / { return 301 https://agenda.couderc.eu/caldavzap/; try_files $uri $uri/ =404; } location /admin.php { return 301 https://agenda.couderc.eu/caldavzap/; try_files $uri $uri/ =404; } location ~ ^(.+\.php)(.*)$ { include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include /etc/nginx/fastcgi_pass_php_socket; fastcgi_split_path_info ^(.+\.php)(.*)$; fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info; fastcgi_read_timeout 180; fastcgi_buffer_size 128k; fastcgi_buffers 4 256k; } location ~ .php$ { try_files $uri =404; include fastcgi_params; include /etc/nginx/fastcgi_pass_php_socket; fastcgi_index index.php; fastcgi_split_path_info ^(.+\.php)(.*)$; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info; } location /caldavzap/ { add_header Cache-Control "max-age=0, must-revalidate, no-cache, no-transform, private"; try_files $uri $uri/ =404; } location /carddavmate/ { add_header Cache-Control "max-age=0, must-revalidate, no-cache, no-transform, private"; } } |
|
From: Bennett P. <be...@pi...> - 2025-05-10 08:27:28
|
On Friday, May 9, 2025 11:16:17 PM Central European Summer Time colony.three--- via Davical-general wrote: > Further, I have two addressbooks, home and work. When I delete an entry in > work... it also disappears in home. > > This is intolerable. These are supposed to be two -different- addressbooks > in davical. I have a business to run and I can not function with such > foolish problems. When I set up davical ~8 years ago, I couldn't make it work with nginx, so I just used apache, which worked out of the box with the davical debian package. Nginx still does all my TLS termination, but it proxies davical through apache. If you have a business to run, it may be worth doing something like that, at least to get up and running. Then you can configure nginx on a seperate domain (or path) in your own time, and eventually bypass apache. Cheers, Bennett |
|
From: <col...@pm...> - 2025-05-09 21:16:30
|
Further, I have two addressbooks, home and work. When I delete an entry in work... it also disappears in home. This is intolerable. These are supposed to be two -different- addressbooks in davical. I have a business to run and I can not function with such foolish problems. On Friday, May 9th, 2025 at 14:07, col...@pm... <col...@pm...> wrote: > > > On Friday, May 9th, 2025 at 13:56, Julien Métairie via Davical-general dav...@li... wrote: > > > Hi, > > > > The wiki[1] is discouraging from using nginx to serve DAViCal. However, > > if you can share your nginx configuration, maybe someone on the list > > will be able to give you some hint. > > > > [1] https://wiki.davical.org/index.php?title=Nginx_Config > > > > Regards > > Julien > > > It's not worth using Apache for this one function. And Apache is a mess. > > Changing the php section of the nginx config helped some. I am at least able to pull up cal and contacts in davx5. And they now show in Android calendar and contacts. > > But still auth is refused for TBird in the davical server. And thus I have no idea whether my cal and contacts are making it into the database on the davical server. > > server { > listen 127.0.0.1:8008; > server_name calendar.darkmatter.org; > > access_log /var/log/nginx/davical.access_log; > error_log /var/log/nginx/davical.error_log warn; > > root /usr/share/davical/htdocs; > index index.php index.html; > > keepalive_timeout 0; > client_max_body_size 8M; # has to be same size as in php.ini, else worthless! Except no such setting there. > > location /images/ { > } > > location ~ ^(.+\.php)(.)$ { > include fastcgi_params; > fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; > fastcgi_pass unix:/run/php/php8.2-fpm.sock; > > fastcgi_split_path_info ^(.+\.php)(.)$; > fastcgi_param PATH_INFO $fastcgi_path_info; > fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info; > > fastcgi_read_timeout 180; > fastcgi_buffers 4 256k; > fastcgi_buffer_size 128k; > } > > location ~ \.php { > include /etc/nginx/fastcgi_params; > fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; > fastcgi_pass unix:/run/php/php8.2-fpm.sock; > fastcgi_index index.php; > } |
|
From: <col...@pm...> - 2025-05-09 21:07:22
|
On Friday, May 9th, 2025 at 13:56, Julien Métairie via Davical-general <dav...@li...> wrote: > > Hi, > > The wiki[1] is discouraging from using nginx to serve DAViCal. However, > if you can share your nginx configuration, maybe someone on the list > will be able to give you some hint. > > [1] https://wiki.davical.org/index.php?title=Nginx_Config > > Regards > Julien It's not worth using Apache for this one function. And Apache is a mess. Changing the php section of the nginx config helped some. I am at least able to pull up cal and contacts in davx5. And they now show in Android calendar and contacts. But still auth is refused for TBird in the davical server. And thus I have no idea whether my cal and contacts are making it into the database on the davical server. server { listen 127.0.0.1:8008; server_name calendar.darkmatter.org; access_log /var/log/nginx/davical.access_log; error_log /var/log/nginx/davical.error_log warn; root /usr/share/davical/htdocs; index index.php index.html; keepalive_timeout 0; client_max_body_size 8M; # has to be same size as in php.ini, else worthless! Except no such setting there. location /images/ { } location ~ ^(.+\.php)(.*)$ { include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass unix:/run/php/php8.2-fpm.sock; fastcgi_split_path_info ^(.+\.php)(.*)$; fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info; fastcgi_read_timeout 180; fastcgi_buffers 4 256k; fastcgi_buffer_size 128k; } location ~ \.php { include /etc/nginx/fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass unix:/run/php/php8.2-fpm.sock; fastcgi_index index.php; } |
|
From: Julien M. <rul...@ru...> - 2025-05-09 20:52:59
|
Hi, The wiki[1] is discouraging from using nginx to serve DAViCal. However, if you can share your nginx configuration, maybe someone on the list will be able to give you some hint. [1] https://wiki.davical.org/index.php?title=Nginx_Config Regards Julien Le 09/05/2025 à 20:11, colony.three--- via Davical-general a écrit : > Wow, Davical is starting to look snakebit. I've spent days trying to make it work like it did for many years, but have failed. > > I actually set up Thunderbird on the Davical server and tried to create a new Davical addressbook. Gave UN and link, then UN:PW and it could not connect. Even on the local server! > > nginx error log shows: > 2025/05/09 10:59:35 [error] 969#969: *27 FastCGI sent in stderr: "PHP message: davical: ***: ERROR:authentication failure for user 'bill' from host [127.0.0.1]" while reading response header from upstream, client: 127.0.0.1, server: calendar.darkmatter.org, request: "PROPFIND /caldav.php/bill/contacts-phone/ HTTP/1.1", upstream: "fastcgi://unix:/run/php/php8.2-fpm.sock:", host: "127.0.0.1:8008" > 2025/05/09 10:59:35 [error] 968#968: *31 FastCGI sent in stderr: "PHP message: davical: ***: ERROR:authentication failure for user 'bill' from host [127.0.0.1]" while reading response header from upstream, client: 127.0.0.1, server: calendar.darkmatter.org, request: "PROPFIND /caldav.php/bill/contacts-phone/ HTTP/1.1", upstream: "fastcgi://unix:/run/php/php8.2-fpm.sock:", host: "127.0.0.1:8008" > > Oh? Auth failure... with the same UN:PW I can log in with in a browser? > > It must have rabies. > > No wonder I can't succeed with Davical. > > > > > On Thursday, May 8th, 2025 at 13:13, col...@pm... <col...@pm...> wrote: > >> >> >> FWIW here's the debug log. >> >> >> >> >> On Thursday, May 8th, 2025 at 12:51, col...@pm... col...@pm... wrote: >> >>> On Wednesday, May 7th, 2025 at 11:06, Julien Métairie via Davical-general dav...@li... wrote: >>> >>>> Hello Bill, >>>> >>>> Can you try to shorten the URL ? >>>> => http://10.2.3.1:2001/caldav.php/bill/ >>>> >>>> On my setup, Davx5 automatically discovers resources and their URL. >>>> >>>> Regards >>>> Julien >>> >>> Thanks, but exactly the same behavior. I've had this problem for at least 8 months. >>> >>> Davx5 log is attached. It's failing to connect from some unknown IP to the correct one in a different CIDR. Zero firewall errors. >>> >>> The nginx logs also give a clue but I don't understand it because I am def giving the correct UN:PW. I can log in to the webpage using these principal creds. >>> >>> The socket exists and has www-data rights. >>> >>> 2025/05/08 11:36:20 [error] 950#950: *661 FastCGI sent in stderr: "PHP message: davical: ***: ERROR:authentication failure for user 'bill' from host [127.0.0.1]" while reading response header from upstream, client: 127.0.0.1, server: calendar.darkmatter.org, request: "PROPFIND /caldav.php/bill/contacts-phone/ HTTP/1.1", upstream: "fastcgi://unix:/run/php/php8.2-fpm.sock:", host: "127.0.0.1:8008" >>> 2025/05/08 11:46:20 [error] 950#950: *665 FastCGI sent in stderr: "PHP message: davical: ***: ERROR:authentication failure for user 'bill' from host [127.0.0.1]" while reading response header from upstream, client: 127.0.0.1, server: calendar.darkmatter.org, request: "PROPFIND /caldav.php/bill/contacts-phone/ HTTP/1.1", upstream: "fastcgi://unix:/run/php/php8.2-fpm.sock:", host: "127.0.0.1:8008" >>> 2025/05/08 11:46:20 [error] 950#950: *669 FastCGI sent in stderr: "PHP message: davical: ***: ERROR:authentication failure for user 'bill' from host [127.0.0.1]" while reading response header from upstream, client: 127.0.0.1, server: calendar.darkmatter.org, request: "PROPFIND /caldav.php/bill/contacts-phone/ HTTP/1.1", upstream: "fastcgi://unix:/run/php/php8.2-fpm.sock:", host: "127.0.0.1:8008" >>> 2025/05/08 11:56:20 [error] 946#946: *673 FastCGI sent in stderr: "PHP message: davical: ***: ERROR:authentication failure for user 'bill' from host [127.0.0.1]" while reading response header from upstream, client: 127.0.0.1, server: calendar.darkmatter.org, request: "PROPFIND /caldav.php/bill/contacts-phone/ HTTP/1.1", upstream: "fastcgi://unix:/run/php/php8.2-fpm.sock:", host: "127.0.0.1:8008" >>> 2025/05/08 11:56:20 [error] 946#946: *677 FastCGI sent in stderr: "PHP message: davical: ***: ERROR:authentication failure for user 'bill' from host [127.0.0.1]" while reading response header from upstream, client: 127.0.0.1, server: calendar.darkmatter.org, request: "PROPFIND /caldav.php/bill/contacts-phone/ HTTP/1.1", upstream: "fastcgi://unix:/run/php/php8.2-fpm.sock:", host: "127.0.0.1:8008" > > > _______________________________________________ > Davical-general mailing list > Dav...@li... > https://lists.sourceforge.net/lists/listinfo/davical-general |
|
From: <col...@pm...> - 2025-05-09 18:11:25
|
Wow, Davical is starting to look snakebit. I've spent days trying to make it work like it did for many years, but have failed. I actually set up Thunderbird on the Davical server and tried to create a new Davical addressbook. Gave UN and link, then UN:PW and it could not connect. Even on the local server! nginx error log shows: 2025/05/09 10:59:35 [error] 969#969: *27 FastCGI sent in stderr: "PHP message: davical: ***: ERROR:authentication failure for user 'bill' from host [127.0.0.1]" while reading response header from upstream, client: 127.0.0.1, server: calendar.darkmatter.org, request: "PROPFIND /caldav.php/bill/contacts-phone/ HTTP/1.1", upstream: "fastcgi://unix:/run/php/php8.2-fpm.sock:", host: "127.0.0.1:8008" 2025/05/09 10:59:35 [error] 968#968: *31 FastCGI sent in stderr: "PHP message: davical: ***: ERROR:authentication failure for user 'bill' from host [127.0.0.1]" while reading response header from upstream, client: 127.0.0.1, server: calendar.darkmatter.org, request: "PROPFIND /caldav.php/bill/contacts-phone/ HTTP/1.1", upstream: "fastcgi://unix:/run/php/php8.2-fpm.sock:", host: "127.0.0.1:8008" Oh? Auth failure... with the same UN:PW I can log in with in a browser? It must have rabies. No wonder I can't succeed with Davical. On Thursday, May 8th, 2025 at 13:13, col...@pm... <col...@pm...> wrote: > > > FWIW here's the debug log. > > > > > On Thursday, May 8th, 2025 at 12:51, col...@pm... col...@pm... wrote: > > > On Wednesday, May 7th, 2025 at 11:06, Julien Métairie via Davical-general dav...@li... wrote: > > > > > Hello Bill, > > > > > > Can you try to shorten the URL ? > > > => http://10.2.3.1:2001/caldav.php/bill/ > > > > > > On my setup, Davx5 automatically discovers resources and their URL. > > > > > > Regards > > > Julien > > > > Thanks, but exactly the same behavior. I've had this problem for at least 8 months. > > > > Davx5 log is attached. It's failing to connect from some unknown IP to the correct one in a different CIDR. Zero firewall errors. > > > > The nginx logs also give a clue but I don't understand it because I am def giving the correct UN:PW. I can log in to the webpage using these principal creds. > > > > The socket exists and has www-data rights. > > > > 2025/05/08 11:36:20 [error] 950#950: *661 FastCGI sent in stderr: "PHP message: davical: ***: ERROR:authentication failure for user 'bill' from host [127.0.0.1]" while reading response header from upstream, client: 127.0.0.1, server: calendar.darkmatter.org, request: "PROPFIND /caldav.php/bill/contacts-phone/ HTTP/1.1", upstream: "fastcgi://unix:/run/php/php8.2-fpm.sock:", host: "127.0.0.1:8008" > > 2025/05/08 11:46:20 [error] 950#950: *665 FastCGI sent in stderr: "PHP message: davical: ***: ERROR:authentication failure for user 'bill' from host [127.0.0.1]" while reading response header from upstream, client: 127.0.0.1, server: calendar.darkmatter.org, request: "PROPFIND /caldav.php/bill/contacts-phone/ HTTP/1.1", upstream: "fastcgi://unix:/run/php/php8.2-fpm.sock:", host: "127.0.0.1:8008" > > 2025/05/08 11:46:20 [error] 950#950: *669 FastCGI sent in stderr: "PHP message: davical: ***: ERROR:authentication failure for user 'bill' from host [127.0.0.1]" while reading response header from upstream, client: 127.0.0.1, server: calendar.darkmatter.org, request: "PROPFIND /caldav.php/bill/contacts-phone/ HTTP/1.1", upstream: "fastcgi://unix:/run/php/php8.2-fpm.sock:", host: "127.0.0.1:8008" > > 2025/05/08 11:56:20 [error] 946#946: *673 FastCGI sent in stderr: "PHP message: davical: ***: ERROR:authentication failure for user 'bill' from host [127.0.0.1]" while reading response header from upstream, client: 127.0.0.1, server: calendar.darkmatter.org, request: "PROPFIND /caldav.php/bill/contacts-phone/ HTTP/1.1", upstream: "fastcgi://unix:/run/php/php8.2-fpm.sock:", host: "127.0.0.1:8008" > > 2025/05/08 11:56:20 [error] 946#946: *677 FastCGI sent in stderr: "PHP message: davical: ***: ERROR:authentication failure for user 'bill' from host [127.0.0.1]" while reading response header from upstream, client: 127.0.0.1, server: calendar.darkmatter.org, request: "PROPFIND /caldav.php/bill/contacts-phone/ HTTP/1.1", upstream: "fastcgi://unix:/run/php/php8.2-fpm.sock:", host: "127.0.0.1:8008" |
|
From: <sou...@pa...> - 2025-05-09 00:28:36
|
On Thursday, May 8th, 2025 at 14:28, Julien Métairie via Davical-general - davical-general at lists.sourceforge.net <dav...@pa...> wrote: > Your network configuration seems very odd to me. > > AFAIK, the IP address you're connecting to (192.0.0.2) is not supposed > to be used in a real environment. > This is also the same IP address as your primary DNS resolver. > > Can you try from another device, and from another network ? > > Julien Yup, you've caught me. But this is going to get a little technical. I have a LAN. One KVM VM member of that LAN is my WireGuard server. It has an interface called inWG (10.2.3.1), which my remote phone connects to over The Internets. (10.2.3.20) All of this works transparently. Now, the WG server VM sets up a reverse SSH tunnel to the DaviCAL server (10.2.1.10) via its LAN interface (10.2.1.1). So the Davical server appears on the WG server at 10.2.3.1:8008, and is readily visible to the phone. I set the phone's DavX5 to go to 10.2.3.1:8008 and the WG server pulls it out of its bellybutton from the DaviCAL server. This system has worked for over a decade with other servers. ('Reverse SSH server') The (designated) server's port appears on another VM as if it's local. So on my phone I set it to 10.2.3.1:8008 which connects it to the WG server, which passes that along to the Davical server, which handles the requests. This exact system served me well for a decade. I have no idea where 192.0.0.1 comes in. It bears no relation to anything in my systems AFAICT. |
|
From: Julien M. <rul...@ru...> - 2025-05-08 21:23:32
|
Your network configuration seems very odd to me. AFAIK, the IP address you're connecting to (192.0.0.2) is not supposed to be used in a real environment. This is also the same IP address as your primary DNS resolver. Can you try from another device, and from another network ? Julien Le 08/05/2025 à 22:13, colony.three--- via Davical-general a écrit : > FWIW here's the debug log. > > > > |
|
From: <col...@pm...> - 2025-05-08 20:13:44
|
FWIW here's the debug log. On Thursday, May 8th, 2025 at 12:51, col...@pm... <col...@pm...> wrote: > > > On Wednesday, May 7th, 2025 at 11:06, Julien Métairie via Davical-general dav...@li... wrote: > > > Hello Bill, > > > > Can you try to shorten the URL ? > > => http://10.2.3.1:2001/caldav.php/bill/ > > > > On my setup, Davx5 automatically discovers resources and their URL. > > > > Regards > > Julien > > > Thanks, but exactly the same behavior. I've had this problem for at least 8 months. > > Davx5 log is attached. It's failing to connect from some unknown IP to the correct one in a different CIDR. Zero firewall errors. > > The nginx logs also give a clue but I don't understand it because I am def giving the correct UN:PW. I can log in to the webpage using these principal creds. > > The socket exists and has www-data rights. > > > 2025/05/08 11:36:20 [error] 950#950: *661 FastCGI sent in stderr: "PHP message: davical: ***: ERROR:authentication failure for user 'bill' from host [127.0.0.1]" while reading response header from upstream, client: 127.0.0.1, server: calendar.darkmatter.org, request: "PROPFIND /caldav.php/bill/contacts-phone/ HTTP/1.1", upstream: "fastcgi://unix:/run/php/php8.2-fpm.sock:", host: "127.0.0.1:8008" > 2025/05/08 11:46:20 [error] 950#950: *665 FastCGI sent in stderr: "PHP message: davical: ***: ERROR:authentication failure for user 'bill' from host [127.0.0.1]" while reading response header from upstream, client: 127.0.0.1, server: calendar.darkmatter.org, request: "PROPFIND /caldav.php/bill/contacts-phone/ HTTP/1.1", upstream: "fastcgi://unix:/run/php/php8.2-fpm.sock:", host: "127.0.0.1:8008" > 2025/05/08 11:46:20 [error] 950#950: *669 FastCGI sent in stderr: "PHP message: davical: ***: ERROR:authentication failure for user 'bill' from host [127.0.0.1]" while reading response header from upstream, client: 127.0.0.1, server: calendar.darkmatter.org, request: "PROPFIND /caldav.php/bill/contacts-phone/ HTTP/1.1", upstream: "fastcgi://unix:/run/php/php8.2-fpm.sock:", host: "127.0.0.1:8008" > 2025/05/08 11:56:20 [error] 946#946: *673 FastCGI sent in stderr: "PHP message: davical: ***: ERROR:authentication failure for user 'bill' from host [127.0.0.1]" while reading response header from upstream, client: 127.0.0.1, server: calendar.darkmatter.org, request: "PROPFIND /caldav.php/bill/contacts-phone/ HTTP/1.1", upstream: "fastcgi://unix:/run/php/php8.2-fpm.sock:", host: "127.0.0.1:8008" > 2025/05/08 11:56:20 [error] 946#946: *677 FastCGI sent in stderr: "PHP message: davical: ***: ERROR:authentication failure for user 'bill' from host [127.0.0.1]" while reading response header from upstream, client: 127.0.0.1, server: calendar.darkmatter.org, request: "PROPFIND /caldav.php/bill/contacts-phone/ HTTP/1.1", upstream: "fastcgi://unix:/run/php/php8.2-fpm.sock:", host: "127.0.0.1:8008" |
|
From: Julien M. <rul...@ru...> - 2025-05-07 18:02:50
|
Hello Bill, Can you try to shorten the URL ? => http://10.2.3.1:2001/caldav.php/bill/ On my setup, Davx5 automatically discovers resources and their URL. Regards Julien Le 07/05/2025 à 02:09, colony.three--- via Davical-general a écrit : > I seem to have my Davical server set up properly, and on my Android 14 > phone I run the current Davx5. > > In Davx5 I hit the + to create a new account, choose "Log in with URL > and user name"|Continue > > I fill in http://10.2.3.1:2001/caldav.php/bill/calendar-work > <http://10.2.3.1:2001/caldav.php/bill/calendar-work> and the correct > username and password for the DaviCal server and hit Login. > > It goes to the Account name page so I know it found the server and my > creds are right. For account name I fill in calendar-work, and check > "Groups are separate vcards", then Finish. > > Now, here's the part where it's supposed to take me to two tabs, CalDAV > and CardDAV, and it does... but it's supposed to let me make choices > under these tabs but they are all blank. Under both tabs. > > I thought maybe it's read or write permissions in the server, but as my > user I check these in both Principal Grants and Access Tickets, > Create... but, the checkboxes go blank again. I reload and still > blank. I check them again and Create, still blank. > > I don't understand what's wrong. > > Bill > > > --------------------------------------------------------------------- > PS - I've had a very difficult time getting the server running because > the Davical instructions encourage you to use the source with a git > clone. I tried using this and failed for hours until I realized this > must have to be compiled even though it's php. Not a word about this in > the instructions. Probably turned alot of ppl off. > > I found that Debian has a pretty new version (1.12) so I installed that > and with all the other rather technical tweaks was able to finally get > Davical running. This is not for shoe salesmen. > > Also I run nginx, and had to use other resources to try and flange that > into the picture. setup.php is all green now, thankfully. I think I > lost 2 years off my life. But this is part of the price I pay for > hating G**gle. > > > > > _______________________________________________ > Davical-general mailing list > Dav...@li... > https://lists.sourceforge.net/lists/listinfo/davical-general |
|
From: <col...@pm...> - 2025-05-07 00:10:20
|
I seem to have my Davical server set up properly, and on my Android 14 phone I run the current Davx5. In Davx5 I hit the + to create a new account, choose "Log in with URL and user name"|Continue I fill in http://10.2.3.1:2001/caldav.php/bill/calendar-work and the correct username and password for the DaviCal server and hit Login. It goes to the Account name page so I know it found the server and my creds are right. For account name I fill in calendar-work, and check "Groups are separate vcards", then Finish. Now, here's the part where it's supposed to take me to two tabs, CalDAV and CardDAV, and it does... but it's supposed to let me make choices under these tabs but they are all blank. Under both tabs. I thought maybe it's read or write permissions in the server, but as my user I check these in both Principal Grants and Access Tickets, Create... but, the checkboxes go blank again. I reload and still blank. I check them again and Create, still blank. I don't understand what's wrong. Bill --------------------------------------------------------------------- PS - I've had a very difficult time getting the server running because the Davical instructions encourage you to use the source with a git clone. I tried using this and failed for hours until I realized this must have to be compiled even though it's php. Not a word about this in the instructions. Probably turned alot of ppl off. I found that Debian has a pretty new version (1.12) so I installed that and with all the other rather technical tweaks was able to finally get Davical running. This is not for shoe salesmen. Also I run nginx, and had to use other resources to try and flange that into the picture. setup.php is all green now, thankfully. I think I lost 2 years off my life. But this is part of the price I pay for hating G**gle. |
|
From: <col...@pm...> - 2025-03-15 18:58:06
|
I am discarding Davical in favor of OpenContacts because Davical just doesn't work anymore, and nobody knows whats wrong. I can not live like this. OpenContacts saves call logs as well. Now looking for an OpenCalendar. On Thursday, February 27th, 2025 at 11:58, colony.three--- via Davical-general <dav...@li...> wrote: > > > On Thursday, February 27th, 2025 at 09:25, Florian Schlichting fs...@de... wrote: > > > I haven't looked at your config or logs, but with DavX5 I use > > https://server.name/caldav.php/myuser/ as the URL. > > > Tried that many times. It used to work before I rebuilt my Davical server. It logs in fine, but on the tabbed page for CalDAV and CardDAV, it is blank under the tabs. I have no way to choose whether it's a calendar or contact. > > I imported my two addressbooks into Thunderbird and they were empty. So I imported to each of them and it worked. But creating these accounts in Davx5 resulted in the same blank tabs. > > Nothing in the error log, but in the access log: > > 127.0.0.1 - carl [27/Feb/2025:09:52:15 -0800] "PROPFIND /caldav.php/carl/ HTTP/1.1" 207 751 "-" "DAVx5/4.4.7-ose (dav4jvm; okhttp/4.12.0) Android/15" > 127.0.0.1 - carl [27/Feb/2025:09:52:15 -0800] "OPTIONS /caldav.php/carl/caldav.php/carl/ HTTP/1.1" 404 37 "-" "DAVx5/4.4.7-ose (dav4jvm; okhttp/4.12.0) Android/15" > 127.0.0.1 - carl [27/Feb/2025:09:52:15 -0800] "PROPFIND /.well-known/carddav HTTP/1.1" 405 157 "-" "DAVx5/4.4.7-ose (dav4jvm; okhttp/4.12.0) Android/15" > 127.0.0.1 - carl [27/Feb/2025:09:52:15 -0800] "PROPFIND /caldav.php/carl/ HTTP/1.1" 207 1533 "-" "DA > > > _______________________________________________ > Davical-general mailing list > Dav...@li... > https://lists.sourceforge.net/lists/listinfo/davical-general |
|
From: Florian S. <fs...@de...> - 2025-03-05 08:19:48
|
On Thu, Feb 27, 2025 at 07:58:10PM +0000, colony.three--- via Davical-general wrote: > Nothing in the error log, but in the access log: > > 127.0.0.1 - carl [27/Feb/2025:09:52:15 -0800] "PROPFIND /caldav.php/carl/ HTTP/1.1" 207 751 "-" "DAVx5/4.4.7-ose (dav4jvm; okhttp/4.12.0) Android/15" > 127.0.0.1 - carl [27/Feb/2025:09:52:15 -0800] "OPTIONS /caldav.php/carl/caldav.php/carl/ HTTP/1.1" 404 37 "-" "DAVx5/4.4.7-ose (dav4jvm; okhttp/4.12.0) Android/15" it should never have "caldav.php" in there twice. Your DavX5 logs show that this is something returned e.g. for the first propfind for /caldav.php/carl/contacts/ So DAViCal is confused about where it is located relative to the request URI. I've never used it with nginx and php-fpm, but looking at https://wiki.davical.org/index.php/Nginx_Config I wonder if you have tried setting PATH_INFO? That feels like it could make a difference... |
|
From: <col...@pm...> - 2025-02-28 15:44:57
|
Well I can't function like this. I guess I fall in to the hateful, surveilling arms of G**gle. On Thursday, February 27th, 2025 at 11:58, col...@pm... <col...@pm...> wrote: > > > On Thursday, February 27th, 2025 at 09:25, Florian Schlichting fs...@de... wrote: > > > I haven't looked at your config or logs, but with DavX5 I use > > https://server.name/caldav.php/myuser/ as the URL. > > > Tried that many times. It used to work before I rebuilt my Davical server. It logs in fine, but on the tabbed page for CalDAV and CardDAV, it is blank under the tabs. I have no way to choose whether it's a calendar or contact. > > I imported my two addressbooks into Thunderbird and they were empty. So I imported to each of them and it worked. But creating these accounts in Davx5 resulted in the same blank tabs. > > Nothing in the error log, but in the access log: > > 127.0.0.1 - carl [27/Feb/2025:09:52:15 -0800] "PROPFIND /caldav.php/carl/ HTTP/1.1" 207 751 "-" "DAVx5/4.4.7-ose (dav4jvm; okhttp/4.12.0) Android/15" > 127.0.0.1 - carl [27/Feb/2025:09:52:15 -0800] "OPTIONS /caldav.php/carl/caldav.php/carl/ HTTP/1.1" 404 37 "-" "DAVx5/4.4.7-ose (dav4jvm; okhttp/4.12.0) Android/15" > 127.0.0.1 - carl [27/Feb/2025:09:52:15 -0800] "PROPFIND /.well-known/carddav HTTP/1.1" 405 157 "-" "DAVx5/4.4.7-ose (dav4jvm; okhttp/4.12.0) Android/15" > 127.0.0.1 - carl [27/Feb/2025:09:52:15 -0800] "PROPFIND /caldav.php/carl/ HTTP/1.1" 207 1533 "-" "DA |
|
From: <col...@pm...> - 2025-02-27 19:58:26
|
On Thursday, February 27th, 2025 at 09:25, Florian Schlichting <fs...@de...> wrote: > I haven't looked at your config or logs, but with DavX5 I use > https://server.name/caldav.php/myuser/ as the URL. Tried that many times. It used to work before I rebuilt my Davical server. It logs in fine, but on the tabbed page for CalDAV and CardDAV, it is blank under the tabs. I have no way to choose whether it's a calendar or contact. I imported my two addressbooks into Thunderbird and they were empty. So I imported to each of them and it worked. But creating these accounts in Davx5 resulted in the same blank tabs. Nothing in the error log, but in the access log: 127.0.0.1 - carl [27/Feb/2025:09:52:15 -0800] "PROPFIND /caldav.php/carl/ HTTP/1.1" 207 751 "-" "DAVx5/4.4.7-ose (dav4jvm; okhttp/4.12.0) Android/15" 127.0.0.1 - carl [27/Feb/2025:09:52:15 -0800] "OPTIONS /caldav.php/carl/caldav.php/carl/ HTTP/1.1" 404 37 "-" "DAVx5/4.4.7-ose (dav4jvm; okhttp/4.12.0) Android/15" 127.0.0.1 - carl [27/Feb/2025:09:52:15 -0800] "PROPFIND /.well-known/carddav HTTP/1.1" 405 157 "-" "DAVx5/4.4.7-ose (dav4jvm; okhttp/4.12.0) Android/15" 127.0.0.1 - carl [27/Feb/2025:09:52:15 -0800] "PROPFIND /caldav.php/carl/ HTTP/1.1" 207 1533 "-" "DA |