Mailing List Archive

Update-davical-database permission issue
Hello!

Been trying to run the upgrade script but getting all the time
permission issue:

root@bigred:/usr/share/davical/dba#
/usr/share/davical/dba/update-davical-database
bash: /usr/share/davical/dba/update-davical-database: Permission denied

quite a while ago I ran an update but recall that it used to work prior
upgradingto Raspbian Buster; rights seems correct as well:

root@bigred:/usr/share/davical/dba# ls -l update*
-rw-r----- 1 root www-data 14474 Oct 31 21:21 update-davical-database

What I'm I missing here?

//Kim



_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general
Re: Update-davical-database permission issue [ In reply to ]
Hi Kim,

Looks like you need execute permissions on that script:

chmod ug+x update-davical-database

-Jim

On 31 Oct 2020, at 13:36, Kim Haverblad wrote:

> Hello!
>
> Been trying to run the upgrade script but getting all the time
> permission issue:
>
> root@bigred:/usr/share/davical/dba#
> /usr/share/davical/dba/update-davical-database
> bash: /usr/share/davical/dba/update-davical-database: Permission
> denied
>
> quite a while ago I ran an update but recall that it used to work
> prior upgradingto Raspbian Buster; rights seems correct as well:
>
> root@bigred:/usr/share/davical/dba# ls -l update*
> -rw-r----- 1 root www-data 14474 Oct 31 21:21 update-davical-database
>
> What I'm I missing here?
>
> //Kim
>
>
>
> _______________________________________________
> Davical-general mailing list
> Davical-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/davical-general


_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general
Re: Update-davical-database permission issue [ In reply to ]
Hello Jim,

Thanks for pointing out, hrm, yes missed that one even when it was
in-front of me and changing the permission let's me execute the script
which then prints the help info. So tried to included the db creds in
the update script which didn't make any difference and then created
.pgpass file in the /dba directory. Still won't upgrade the db. Verified
that the access rights in the db is set to the correct user, etc. Also,
everything seems to work fine. Seems that I'm still missing out on
something.

//Kim


On 2020-10-31 22:08, Jim Fenton wrote:
> Hi Kim,
>
> Looks like you need execute permissions on that script:
>
> chmod ug+x update-davical-database
>
> -Jim
>
> On 31 Oct 2020, at 13:36, Kim Haverblad wrote:
>
>> Hello!
>>
>> Been trying to run the upgrade script but getting all the time
>> permission issue:
>>
>> root@bigred:/usr/share/davical/dba#
>> /usr/share/davical/dba/update-davical-database
>> bash: /usr/share/davical/dba/update-davical-database: Permission denied
>>
>> quite a while ago I ran an update but recall that it used to work
>> prior upgradingto Raspbian Buster; rights seems correct as well:
>>
>> root@bigred:/usr/share/davical/dba# ls -l update*
>> -rw-r----- 1 root www-data 14474 Oct 31 21:21 update-davical-database
>>
>> What I'm I missing here?
>>
>> //Kim
>>
>>
>>
>> _______________________________________________
>> Davical-general mailing list
>> Davical-general@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/davical-general

--
Vänlig hälsning,
Kim Haverblad
M: 0760046232
--
GnuPG ID: 0x8B75 DF42 EE04 296E


_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general
Re: Update-davical-database permission issue [ In reply to ]
Kim,

I remember something like this when I last did a Debian upgrade, but
unfortunately don’t have anything in my notes. As I remember, Debian
sometimes installs a new version of postgresql in addition to the old
version, in order to be extra careful that it doesn’t mess up any of
your data.

You should be able to use pg_lsclusters to see if there is more than one
database cluster there, what version, what’s active, etc. If so, there
are some instructions online such as
https://wiki.postgresql.org/wiki/Using_pg_upgrade_on_Ubuntu/Debian on
how to make sure everything is running correctly on Buster.

Another good thing to do is to manually connect to PostgreSQL with the
sql command and credentials you should have, and see if you can at least
read from the database OK.

Hope this helps.

-Jim

On 31 Oct 2020, at 16:13, Kim Haverblad wrote:

> Hello Jim,
>
> Thanks for pointing out, hrm, yes missed that one even when it was
> in-front of me and changing the permission let's me execute the script
> which then prints the help info. So tried to included the db creds in
> the update script which didn't make any difference and then created
> .pgpass file in the /dba directory. Still won't upgrade the db.
> Verified that the access rights in the db is set to the correct user,
> etc. Also, everything seems to work fine. Seems that I'm still missing
> out on something.
>
> //Kim
>
>
> On 2020-10-31 22:08, Jim Fenton wrote:
>> Hi Kim,
>>
>> Looks like you need execute permissions on that script:
>>
>> chmod ug+x update-davical-database
>>
>> -Jim
>>
>> On 31 Oct 2020, at 13:36, Kim Haverblad wrote:
>>
>>> Hello!
>>>
>>> Been trying to run the upgrade script but getting all the time
>>> permission issue:
>>>
>>> root@bigred:/usr/share/davical/dba#
>>> /usr/share/davical/dba/update-davical-database
>>> bash: /usr/share/davical/dba/update-davical-database: Permission
>>> denied
>>>
>>> quite a while ago I ran an update but recall that it used to work
>>> prior upgradingto Raspbian Buster; rights seems correct as well:
>>>
>>> root@bigred:/usr/share/davical/dba# ls -l update*
>>> -rw-r----- 1 root www-data 14474 Oct 31 21:21
>>> update-davical-database
>>>
>>> What I'm I missing here?
>>>
>>> //Kim
>>>
>>>
>>>
>>> _______________________________________________
>>> Davical-general mailing list
>>> Davical-general@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/davical-general
>
> --
> Vänlig hälsning,
> Kim Haverblad
> M: 0760046232
> --
> GnuPG ID: 0x8B75 DF42 EE04 296E


_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general
Re: Update-davical-database permission issue [ In reply to ]
Hi list,

> As I remember, Debian
> sometimes installs a new version of postgresql in addition to the old
> version, in order to be extra careful that it doesn’t mess up any of
> your data.

Indeed, I have the following note to upgrade my PGSQL cluster from 8.4
to 9.1. It should ne applicable to newer versions as well, but remember
to keep backups, though. ;)


Delete default 9.1 cluster:
pg_dropcluster--stop 9.1 main

Upgrade current cluster:
pg_upgradecluster 8.4 main

Delete old cluster:
pg_dropcluster 8.4 main

Remove 8.4 engine:
apt-get autoremove --purge postgresql-8.4 postgresql-client-8.4


Regards,
Julien


Le 01/11/2020 à 01:47, Jim Fenton a écrit :
> Kim,
>
> I remember something like this when I last did a Debian upgrade, but
> unfortunately don’t have anything in my notes. As I remember, Debian
> sometimes installs a new version of postgresql in addition to the old
> version, in order to be extra careful that it doesn’t mess up any of
> your data.
>
> You should be able to use pg_lsclusters to see if there is more than one
> database cluster there, what version, what’s active, etc. If so, there
> are some instructions online such as
> https://wiki.postgresql.org/wiki/Using_pg_upgrade_on_Ubuntu/Debian on
> how to make sure everything is running correctly on Buster.
>
> Another good thing to do is to manually connect to PostgreSQL with the
> sql command and credentials you should have, and see if you can at least
> read from the database OK.
>
> Hope this helps.
>
> -Jim
>
> On 31 Oct 2020, at 16:13, Kim Haverblad wrote:
>
>> Hello Jim,
>>
>> Thanks for pointing out, hrm, yes missed that one even when it was
>> in-front of me and changing the permission let's me execute the script
>> which then prints the help info. So tried to included the db creds in
>> the update script which didn't make any difference and then created
>> .pgpass file in the /dba directory. Still won't upgrade the db.
>> Verified that the access rights in the db is set to the correct user,
>> etc. Also, everything seems to work fine. Seems that I'm still missing
>> out on something.
>>
>> //Kim
>>
>>
>> On 2020-10-31 22:08, Jim Fenton wrote:
>>> Hi Kim,
>>>
>>> Looks like you need execute permissions on that script:
>>>
>>> chmod ug+x update-davical-database
>>>
>>> -Jim
>>>
>>> On 31 Oct 2020, at 13:36, Kim Haverblad wrote:
>>>
>>>> Hello!
>>>>
>>>> Been trying to run the upgrade script but getting all the time
>>>> permission issue:
>>>>
>>>> root@bigred:/usr/share/davical/dba#
>>>> /usr/share/davical/dba/update-davical-database
>>>> bash: /usr/share/davical/dba/update-davical-database: Permission denied
>>>>
>>>> quite a while ago I ran an update but recall that it used to work
>>>> prior upgradingto Raspbian Buster; rights seems correct as well:
>>>>
>>>> root@bigred:/usr/share/davical/dba# ls -l update*
>>>> -rw-r----- 1 root www-data 14474 Oct 31 21:21 update-davical-database
>>>>
>>>> What I'm I missing here?
>>>>
>>>> //Kim
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Davical-general mailing list
>>>> Davical-general@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/davical-general
>>
>> --
>> Vänlig hälsning,
>> Kim Haverblad
>> M: 0760046232
>> --
>> GnuPG ID: 0x8B75 DF42 EE04 296E
>
>
> _______________________________________________
> Davical-general mailing list
> Davical-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/davical-general


_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general
Re: Update-davical-database permission issue [ In reply to ]
Thanks Jim and Julien! Never really been working postgresql so this
insight is absolutely helpful and checking with pg_lsclusters it shows
the below so it's the version 9.6 which is currently being used.

sudo pg_lsclusters
Ver Cluster Port Status Owner    Data directory               Log file
9.6 main    5432 online postgres /var/lib/postgresql/9.6/main
/var/log/postgresql/postgresql-9.6-main.log
11  main    5433 online postgres /var/lib/postgresql/11/main
/var/log/postgresql/postgresql-11-main.log

Just to make sure, no issues then to jump up to version 11?

//Kim

On 2020-11-01 08:57, Julien Métairie via Davical-general wrote:
> Hi list,
>
>> As I remember, Debian
>> sometimes installs a new version of postgresql in addition to the old
>> version, in order to be extra careful that it doesn’t mess up any of
>> your data.
>
> Indeed, I have the following note to upgrade my PGSQL cluster from 8.4
> to 9.1. It should ne applicable to newer versions as well, but
> remember to keep backups, though. ;)
>
>
> Delete default 9.1 cluster:
>     pg_dropcluster--stop 9.1 main
>
> Upgrade current cluster:
>     pg_upgradecluster 8.4 main
>
> Delete old cluster:
>     pg_dropcluster 8.4 main
>
> Remove 8.4 engine:
>     apt-get autoremove --purge postgresql-8.4 postgresql-client-8.4
>
>
> Regards,
> Julien
>
>
> Le 01/11/2020 à 01:47, Jim Fenton a écrit :
>> Kim,
>>
>> I remember something like this when I last did a Debian upgrade, but
>> unfortunately don’t have anything in my notes. As I remember, Debian
>> sometimes installs a new version of postgresql in addition to the old
>> version, in order to be extra careful that it doesn’t mess up any of
>> your data.
>>
>> You should be able to use pg_lsclusters to see if there is more than
>> one database cluster there, what version, what’s active, etc. If so,
>> there are some instructions online such as
>> https://wiki.postgresql.org/wiki/Using_pg_upgrade_on_Ubuntu/Debian on
>> how to make sure everything is running correctly on Buster.
>>
>> Another good thing to do is to manually connect to PostgreSQL with
>> the sql command and credentials you should have, and see if you can
>> at least read from the database OK.
>>
>> Hope this helps.
>>
>> -Jim
>>
>> On 31 Oct 2020, at 16:13, Kim Haverblad wrote:
>>
>>> Hello Jim,
>>>
>>> Thanks for pointing out, hrm, yes missed that one even when it was
>>> in-front of me and changing the permission let's me execute the
>>> script which then prints the help info. So tried to included the db
>>> creds in the update script which didn't make any difference and then
>>> created .pgpass file in the /dba directory. Still won't upgrade the
>>> db. Verified that the access rights in the db is set to the correct
>>> user, etc. Also, everything seems to work fine. Seems that I'm still
>>> missing out on something.
>>>
>>> //Kim
>>>
>>>
>>> On 2020-10-31 22:08, Jim Fenton wrote:
>>>> Hi Kim,
>>>>
>>>> Looks like you need execute permissions on that script:
>>>>
>>>> chmod ug+x update-davical-database
>>>>
>>>> -Jim
>>>>
>>>> On 31 Oct 2020, at 13:36, Kim Haverblad wrote:
>>>>
>>>>> Hello!
>>>>>
>>>>> Been trying to run the upgrade script but getting all the time
>>>>> permission issue:
>>>>>
>>>>> root@bigred:/usr/share/davical/dba#
>>>>> /usr/share/davical/dba/update-davical-database
>>>>> bash: /usr/share/davical/dba/update-davical-database: Permission
>>>>> denied
>>>>>
>>>>> quite a while ago I ran an update but recall that it used to work
>>>>> prior upgradingto Raspbian Buster; rights seems correct as well:
>>>>>
>>>>> root@bigred:/usr/share/davical/dba# ls -l update*
>>>>> -rw-r----- 1 root www-data 14474 Oct 31 21:21 update-davical-database
>>>>>
>>>>> What I'm I missing here?
>>>>>
>>>>> //Kim
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Davical-general mailing list
>>>>> Davical-general@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/davical-general
>>>
>>> --
>>> Vänlig hälsning,
>>> Kim Haverblad
>>> M: 0760046232
>>> --
>>> GnuPG ID: 0x8B75 DF42 EE04 296E
>>
>>
>> _______________________________________________
>> Davical-general mailing list
>> Davical-general@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/davical-general
>
>
> _______________________________________________
> Davical-general mailing list
> Davical-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/davical-general

--
Vänlig hälsning,
Kim Haverblad
M: 0760046232
--
GnuPG ID: 0x8B75 DF42 EE04 296E


_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general
Re: Update-davical-database permission issue [ In reply to ]
Well, Postgress upgrade worked out, I think, kinda. But, now Calidav
complaints about access and no sure whether Postgress access issue or
whether it's Calidav issue since DB and users

[Sun Nov 01 2020] [php7:notice] [pid 543] [client 192.168.0.120:65441]
Unable to connect to database: SQLSTATE[08006] [7] FATAL:  Peer
authentication failed for user "davical_app"
[Sun Nov 01 2020] [php7:error] [pid 543] [client 192.168.0.120:65441]
PHP Fatal error:  PDO connection error 'pgsql:dbname=davical port=5432
user=davical_app password=####': SQLSTATE[08006] [7] FATAL: Peer
authentication failed for user "davical_app" in
/usr/share/awl/inc/AwlDBDialect.php on line 103

So checking that we have the db:

                                   List of databases
   Name    |    Owner    | Encoding |   Collate   |    Ctype |   Access
privileges
-----------+-------------+----------+-------------+-------------+-----------------------
 davical   | davical_dba | UTF8     | en_US.UTF-8 | en_US.UTF-8 |

and then whether the user exists:

                                    List of roles
  Role name  | Attributes                         | Member of
-------------+------------------------------------------------------------+-----------
 davical_app
|                                                            | {}
 davical_dba
|                                                            | {}

So should is it seems that something didn't really go that well in the
migration process. What are the attributes expected for the two davical
users?

//Kim

On 2020-11-01 12:16, Kim Haverblad wrote:
> Thanks Jim and Julien! Never really been working postgresql so this
> insight is absolutely helpful and checking with pg_lsclusters it shows
> the below so it's the version 9.6 which is currently being used.
>
> sudo pg_lsclusters
> Ver Cluster Port Status Owner    Data directory               Log file
> 9.6 main    5432 online postgres /var/lib/postgresql/9.6/main
> /var/log/postgresql/postgresql-9.6-main.log
> 11  main    5433 online postgres /var/lib/postgresql/11/main
> /var/log/postgresql/postgresql-11-main.log
>
> Just to make sure, no issues then to jump up to version 11?
>
> //Kim
>
> On 2020-11-01 08:57, Julien Métairie via Davical-general wrote:
>> Hi list,
>>
>>> As I remember, Debian
>>> sometimes installs a new version of postgresql in addition to the old
>>> version, in order to be extra careful that it doesn’t mess up any of
>>> your data.
>>
>> Indeed, I have the following note to upgrade my PGSQL cluster from
>> 8.4 to 9.1. It should ne applicable to newer versions as well, but
>> remember to keep backups, though. ;)
>>
>>
>> Delete default 9.1 cluster:
>>     pg_dropcluster--stop 9.1 main
>>
>> Upgrade current cluster:
>>     pg_upgradecluster 8.4 main
>>
>> Delete old cluster:
>>     pg_dropcluster 8.4 main
>>
>> Remove 8.4 engine:
>>     apt-get autoremove --purge postgresql-8.4 postgresql-client-8.4
>>
>>
>> Regards,
>> Julien
>>
>>
>> Le 01/11/2020 à 01:47, Jim Fenton a écrit :
>>> Kim,
>>>
>>> I remember something like this when I last did a Debian upgrade, but
>>> unfortunately don’t have anything in my notes. As I remember, Debian
>>> sometimes installs a new version of postgresql in addition to the
>>> old version, in order to be extra careful that it doesn’t mess up
>>> any of your data.
>>>
>>> You should be able to use pg_lsclusters to see if there is more than
>>> one database cluster there, what version, what’s active, etc. If so,
>>> there are some instructions online such as
>>> https://wiki.postgresql.org/wiki/Using_pg_upgrade_on_Ubuntu/Debian
>>> on how to make sure everything is running correctly on Buster.
>>>
>>> Another good thing to do is to manually connect to PostgreSQL with
>>> the sql command and credentials you should have, and see if you can
>>> at least read from the database OK.
>>>
>>> Hope this helps.
>>>
>>> -Jim
>>>
>>> On 31 Oct 2020, at 16:13, Kim Haverblad wrote:
>>>
>>>> Hello Jim,
>>>>
>>>> Thanks for pointing out, hrm, yes missed that one even when it was
>>>> in-front of me and changing the permission let's me execute the
>>>> script which then prints the help info. So tried to included the db
>>>> creds in the update script which didn't make any difference and
>>>> then created .pgpass file in the /dba directory. Still won't
>>>> upgrade the db. Verified that the access rights in the db is set to
>>>> the correct user, etc. Also, everything seems to work fine. Seems
>>>> that I'm still missing out on something.
>>>>
>>>> //Kim
>>>>
>>>>
>>>> On 2020-10-31 22:08, Jim Fenton wrote:
>>>>> Hi Kim,
>>>>>
>>>>> Looks like you need execute permissions on that script:
>>>>>
>>>>> chmod ug+x update-davical-database
>>>>>
>>>>> -Jim
>>>>>
>>>>> On 31 Oct 2020, at 13:36, Kim Haverblad wrote:
>>>>>
>>>>>> Hello!
>>>>>>
>>>>>> Been trying to run the upgrade script but getting all the time
>>>>>> permission issue:
>>>>>>
>>>>>> root@bigred:/usr/share/davical/dba#
>>>>>> /usr/share/davical/dba/update-davical-database
>>>>>> bash: /usr/share/davical/dba/update-davical-database: Permission
>>>>>> denied
>>>>>>
>>>>>> quite a while ago I ran an update but recall that it used to work
>>>>>> prior upgradingto Raspbian Buster; rights seems correct as well:
>>>>>>
>>>>>> root@bigred:/usr/share/davical/dba# ls -l update*
>>>>>> -rw-r----- 1 root www-data 14474 Oct 31 21:21
>>>>>> update-davical-database
>>>>>>
>>>>>> What I'm I missing here?
>>>>>>
>>>>>> //Kim
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Davical-general mailing list
>>>>>> Davical-general@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/davical-general
>>>>
>>>> --
>>>> Vänlig hälsning,
>>>> Kim Haverblad
>>>> M: 0760046232
>>>> --
>>>> GnuPG ID: 0x8B75 DF42 EE04 296E
>>>
>>>
>>> _______________________________________________
>>> Davical-general mailing list
>>> Davical-general@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/davical-general
>>
>>
>> _______________________________________________
>> Davical-general mailing list
>> Davical-general@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/davical-general
>

--
Vänlig hälsning,
Kim Haverblad
M: 0760046232
--
GnuPG ID: 0x8B75 DF42 EE04 296E


_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general
Re: Update-davical-database permission issue [ In reply to ]
Right, found the error to what caused my little issue after the upgrade;
when checking the postresql logs it showed the following:

2020-11-01  CET [2945] davical_app@davical FATAL:  Peer authentication
failed for user "davical_app"
2020-11-01  CET [2945] davical_app@davical DETAIL:  Connection matched
pg_hba.conf line 90: "local   all             all

Checking pg_hba-conf line 90 it shows:

# "local" is for Unix domain socket connections only
local   all             all peer

so the issue was that connection was set to 'peer' and not 'md5' and
once this was changed to:

# "local" is for Unix domain socket connections only
local   all             all md5

everything was working again.

//Kim

On 2020-11-01 18:30, Kim Haverblad wrote:
> Well, Postgress upgrade worked out, I think, kinda. But, now Calidav
> complaints about access and no sure whether Postgress access issue or
> whether it's Calidav issue since DB and users
>
> [Sun Nov 01 2020] [php7:notice] [pid 543] [client 192.168.0.120:65441]
> Unable to connect to database: SQLSTATE[08006] [7] FATAL:  Peer
> authentication failed for user "davical_app"
> [Sun Nov 01 2020] [php7:error] [pid 543] [client 192.168.0.120:65441]
> PHP Fatal error:  PDO connection error 'pgsql:dbname=davical port=5432
> user=davical_app password=####': SQLSTATE[08006] [7] FATAL: Peer
> authentication failed for user "davical_app" in
> /usr/share/awl/inc/AwlDBDialect.php on line 103
>
> So checking that we have the db:
>
>                                    List of databases
>    Name    |    Owner    | Encoding |   Collate   |    Ctype | Access
> privileges
> -----------+-------------+----------+-------------+-------------+-----------------------
>
>  davical   | davical_dba | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
>
> and then whether the user exists:
>
>                                     List of roles
>   Role name  | Attributes                         | Member of
> -------------+------------------------------------------------------------+-----------
>
>  davical_app
> |                                                            | {}
>  davical_dba
> |                                                            | {}
>
> So should is it seems that something didn't really go that well in the
> migration process. What are the attributes expected for the two
> davical users?
>
> //Kim
>
> On 2020-11-01 12:16, Kim Haverblad wrote:
>> Thanks Jim and Julien! Never really been working postgresql so this
>> insight is absolutely helpful and checking with pg_lsclusters it
>> shows the below so it's the version 9.6 which is currently being used.
>>
>> sudo pg_lsclusters
>> Ver Cluster Port Status Owner    Data directory Log file
>> 9.6 main    5432 online postgres /var/lib/postgresql/9.6/main
>> /var/log/postgresql/postgresql-9.6-main.log
>> 11  main    5433 online postgres /var/lib/postgresql/11/main
>> /var/log/postgresql/postgresql-11-main.log
>>
>> Just to make sure, no issues then to jump up to version 11?
>>
>> //Kim
>>
>> On 2020-11-01 08:57, Julien Métairie via Davical-general wrote:
>>> Hi list,
>>>
>>>> As I remember, Debian
>>>> sometimes installs a new version of postgresql in addition to the old
>>>> version, in order to be extra careful that it doesn’t mess up any of
>>>> your data.
>>>
>>> Indeed, I have the following note to upgrade my PGSQL cluster from
>>> 8.4 to 9.1. It should ne applicable to newer versions as well, but
>>> remember to keep backups, though. ;)
>>>
>>>
>>> Delete default 9.1 cluster:
>>>     pg_dropcluster--stop 9.1 main
>>>
>>> Upgrade current cluster:
>>>     pg_upgradecluster 8.4 main
>>>
>>> Delete old cluster:
>>>     pg_dropcluster 8.4 main
>>>
>>> Remove 8.4 engine:
>>>     apt-get autoremove --purge postgresql-8.4 postgresql-client-8.4
>>>
>>>
>>> Regards,
>>> Julien
>>>
>>>
>>> Le 01/11/2020 à 01:47, Jim Fenton a écrit :
>>>> Kim,
>>>>
>>>> I remember something like this when I last did a Debian upgrade,
>>>> but unfortunately don’t have anything in my notes. As I remember,
>>>> Debian sometimes installs a new version of postgresql in addition
>>>> to the old version, in order to be extra careful that it doesn’t
>>>> mess up any of your data.
>>>>
>>>> You should be able to use pg_lsclusters to see if there is more
>>>> than one database cluster there, what version, what’s active, etc.
>>>> If so, there are some instructions online such as
>>>> https://wiki.postgresql.org/wiki/Using_pg_upgrade_on_Ubuntu/Debian
>>>> on how to make sure everything is running correctly on Buster.
>>>>
>>>> Another good thing to do is to manually connect to PostgreSQL with
>>>> the sql command and credentials you should have, and see if you can
>>>> at least read from the database OK.
>>>>
>>>> Hope this helps.
>>>>
>>>> -Jim
>>>>
>>>> On 31 Oct 2020, at 16:13, Kim Haverblad wrote:
>>>>
>>>>> Hello Jim,
>>>>>
>>>>> Thanks for pointing out, hrm, yes missed that one even when it was
>>>>> in-front of me and changing the permission let's me execute the
>>>>> script which then prints the help info. So tried to included the
>>>>> db creds in the update script which didn't make any difference and
>>>>> then created .pgpass file in the /dba directory. Still won't
>>>>> upgrade the db. Verified that the access rights in the db is set
>>>>> to the correct user, etc. Also, everything seems to work fine.
>>>>> Seems that I'm still missing out on something.
>>>>>
>>>>> //Kim
>>>>>
>>>>>
>>>>> On 2020-10-31 22:08, Jim Fenton wrote:
>>>>>> Hi Kim,
>>>>>>
>>>>>> Looks like you need execute permissions on that script:
>>>>>>
>>>>>> chmod ug+x update-davical-database
>>>>>>
>>>>>> -Jim
>>>>>>
>>>>>> On 31 Oct 2020, at 13:36, Kim Haverblad wrote:
>>>>>>
>>>>>>> Hello!
>>>>>>>
>>>>>>> Been trying to run the upgrade script but getting all the time
>>>>>>> permission issue:
>>>>>>>
>>>>>>> root@bigred:/usr/share/davical/dba#
>>>>>>> /usr/share/davical/dba/update-davical-database
>>>>>>> bash: /usr/share/davical/dba/update-davical-database: Permission
>>>>>>> denied
>>>>>>>
>>>>>>> quite a while ago I ran an update but recall that it used to
>>>>>>> work prior upgradingto Raspbian Buster; rights seems correct as
>>>>>>> well:
>>>>>>>
>>>>>>> root@bigred:/usr/share/davical/dba# ls -l update*
>>>>>>> -rw-r----- 1 root www-data 14474 Oct 31 21:21
>>>>>>> update-davical-database
>>>>>>>
>>>>>>> What I'm I missing here?
>>>>>>>
>>>>>>> //Kim
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Davical-general mailing list
>>>>>>> Davical-general@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/davical-general
>>>>>
>>>>> --
>>>>> Vänlig hälsning,
>>>>> Kim Haverblad
>>>>> M: 0760046232
>>>>> --
>>>>> GnuPG ID: 0x8B75 DF42 EE04 296E
>>>>
>>>>
>>>> _______________________________________________
>>>> Davical-general mailing list
>>>> Davical-general@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/davical-general
>>>
>>>
>>> _______________________________________________
>>> Davical-general mailing list
>>> Davical-general@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/davical-general
>>
>

--
Vänlig hälsning,
Kim Haverblad
M: 0760046232
--
GnuPG ID: 0x8B75 DF42 EE04 296E


_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general
Re: Update-davical-database permission issue [ In reply to ]
Well, still have issue with update-davical-database while I now can
execute it I get the splash text with parameters which is supported.
I've created .pgpass including administration.yml which didn't to the
trick. So still have the 'Database schema needs upgrading. Current:
1.3.2, Desired: 1.3.3' and don't know what else can be done to fix this.

Any suggestions?

//Kim

On 2020-11-01 20:07, Kim Haverblad wrote:
> Right, found the error to what caused my little issue after the
> upgrade; when checking the postresql logs it showed the following:
>
> 2020-11-01  CET [2945] davical_app@davical FATAL:  Peer authentication
> failed for user "davical_app"
> 2020-11-01  CET [2945] davical_app@davical DETAIL:  Connection matched
> pg_hba.conf line 90: "local   all             all
>
> Checking pg_hba-conf line 90 it shows:
>
> # "local" is for Unix domain socket connections only
> local   all             all peer
>
> so the issue was that connection was set to 'peer' and not 'md5' and
> once this was changed to:
>
> # "local" is for Unix domain socket connections only
> local   all             all md5
>
> everything was working again.
>
> //Kim
>
> On 2020-11-01 18:30, Kim Haverblad wrote:
>> Well, Postgress upgrade worked out, I think, kinda. But, now Calidav
>> complaints about access and no sure whether Postgress access issue or
>> whether it's Calidav issue since DB and users
>>
>> [Sun Nov 01 2020] [php7:notice] [pid 543] [client
>> 192.168.0.120:65441] Unable to connect to database: SQLSTATE[08006]
>> [7] FATAL:  Peer authentication failed for user "davical_app"
>> [Sun Nov 01 2020] [php7:error] [pid 543] [client 192.168.0.120:65441]
>> PHP Fatal error:  PDO connection error 'pgsql:dbname=davical
>> port=5432 user=davical_app password=####': SQLSTATE[08006] [7] FATAL:
>> Peer authentication failed for user "davical_app" in
>> /usr/share/awl/inc/AwlDBDialect.php on line 103
>>
>> So checking that we have the db:
>>
>>                                    List of databases
>>    Name    |    Owner    | Encoding |   Collate   |    Ctype | Access
>> privileges
>> -----------+-------------+----------+-------------+-------------+-----------------------
>>
>>  davical   | davical_dba | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
>>
>> and then whether the user exists:
>>
>>                                     List of roles
>>   Role name  | Attributes                         | Member of
>> -------------+------------------------------------------------------------+-----------
>>
>>  davical_app
>> |                                                            | {}
>>  davical_dba
>> |                                                            | {}
>>
>> So should is it seems that something didn't really go that well in
>> the migration process. What are the attributes expected for the two
>> davical users?
>>
>> //Kim
>>
>> On 2020-11-01 12:16, Kim Haverblad wrote:
>>> Thanks Jim and Julien! Never really been working postgresql so this
>>> insight is absolutely helpful and checking with pg_lsclusters it
>>> shows the below so it's the version 9.6 which is currently being used.
>>>
>>> sudo pg_lsclusters
>>> Ver Cluster Port Status Owner    Data directory Log file
>>> 9.6 main    5432 online postgres /var/lib/postgresql/9.6/main
>>> /var/log/postgresql/postgresql-9.6-main.log
>>> 11  main    5433 online postgres /var/lib/postgresql/11/main
>>> /var/log/postgresql/postgresql-11-main.log
>>>
>>> Just to make sure, no issues then to jump up to version 11?
>>>
>>> //Kim
>>>
>>> On 2020-11-01 08:57, Julien Métairie via Davical-general wrote:
>>>> Hi list,
>>>>
>>>>> As I remember, Debian
>>>>> sometimes installs a new version of postgresql in addition to the old
>>>>> version, in order to be extra careful that it doesn’t mess up any of
>>>>> your data.
>>>>
>>>> Indeed, I have the following note to upgrade my PGSQL cluster from
>>>> 8.4 to 9.1. It should ne applicable to newer versions as well, but
>>>> remember to keep backups, though. ;)
>>>>
>>>>
>>>> Delete default 9.1 cluster:
>>>>     pg_dropcluster--stop 9.1 main
>>>>
>>>> Upgrade current cluster:
>>>>     pg_upgradecluster 8.4 main
>>>>
>>>> Delete old cluster:
>>>>     pg_dropcluster 8.4 main
>>>>
>>>> Remove 8.4 engine:
>>>>     apt-get autoremove --purge postgresql-8.4 postgresql-client-8.4
>>>>
>>>>
>>>> Regards,
>>>> Julien
>>>>
>>>>
>>>> Le 01/11/2020 à 01:47, Jim Fenton a écrit :
>>>>> Kim,
>>>>>
>>>>> I remember something like this when I last did a Debian upgrade,
>>>>> but unfortunately don’t have anything in my notes. As I remember,
>>>>> Debian sometimes installs a new version of postgresql in addition
>>>>> to the old version, in order to be extra careful that it doesn’t
>>>>> mess up any of your data.
>>>>>
>>>>> You should be able to use pg_lsclusters to see if there is more
>>>>> than one database cluster there, what version, what’s active, etc.
>>>>> If so, there are some instructions online such as
>>>>> https://wiki.postgresql.org/wiki/Using_pg_upgrade_on_Ubuntu/Debian
>>>>> on how to make sure everything is running correctly on Buster.
>>>>>
>>>>> Another good thing to do is to manually connect to PostgreSQL with
>>>>> the sql command and credentials you should have, and see if you
>>>>> can at least read from the database OK.
>>>>>
>>>>> Hope this helps.
>>>>>
>>>>> -Jim
>>>>>
>>>>> On 31 Oct 2020, at 16:13, Kim Haverblad wrote:
>>>>>
>>>>>> Hello Jim,
>>>>>>
>>>>>> Thanks for pointing out, hrm, yes missed that one even when it
>>>>>> was in-front of me and changing the permission let's me execute
>>>>>> the script which then prints the help info. So tried to included
>>>>>> the db creds in the update script which didn't make any
>>>>>> difference and then created .pgpass file in the /dba directory.
>>>>>> Still won't upgrade the db. Verified that the access rights in
>>>>>> the db is set to the correct user, etc. Also, everything seems to
>>>>>> work fine. Seems that I'm still missing out on something.
>>>>>>
>>>>>> //Kim
>>>>>>
>>>>>>
>>>>>> On 2020-10-31 22:08, Jim Fenton wrote:
>>>>>>> Hi Kim,
>>>>>>>
>>>>>>> Looks like you need execute permissions on that script:
>>>>>>>
>>>>>>> chmod ug+x update-davical-database
>>>>>>>
>>>>>>> -Jim
>>>>>>>
>>>>>>> On 31 Oct 2020, at 13:36, Kim Haverblad wrote:
>>>>>>>
>>>>>>>> Hello!
>>>>>>>>
>>>>>>>> Been trying to run the upgrade script but getting all the time
>>>>>>>> permission issue:
>>>>>>>>
>>>>>>>> root@bigred:/usr/share/davical/dba#
>>>>>>>> /usr/share/davical/dba/update-davical-database
>>>>>>>> bash: /usr/share/davical/dba/update-davical-database:
>>>>>>>> Permission denied
>>>>>>>>
>>>>>>>> quite a while ago I ran an update but recall that it used to
>>>>>>>> work prior upgradingto Raspbian Buster; rights seems correct as
>>>>>>>> well:
>>>>>>>>
>>>>>>>> root@bigred:/usr/share/davical/dba# ls -l update*
>>>>>>>> -rw-r----- 1 root www-data 14474 Oct 31 21:21
>>>>>>>> update-davical-database
>>>>>>>>
>>>>>>>> What I'm I missing here?
>>>>>>>>
>>>>>>>> //Kim
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Davical-general mailing list
>>>>>>>> Davical-general@lists.sourceforge.net
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/davical-general
>>>>>>
>>>>>> --
>>>>>> Vänlig hälsning,
>>>>>> Kim Haverblad
>>>>>> M: 0760046232
>>>>>> --
>>>>>> GnuPG ID: 0x8B75 DF42 EE04 296E
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Davical-general mailing list
>>>>> Davical-general@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/davical-general
>>>>
>>>>
>>>> _______________________________________________
>>>> Davical-general mailing list
>>>> Davical-general@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/davical-general
>>>
>>
>

--
Vänlig hälsning,
Kim Haverblad
M: 0760046232
--
GnuPG ID: 0x8B75 DF42 EE04 296E


_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general
Re: Update-davical-database permission issue [ In reply to ]
The problem ‘Database schema needs updating’ is fixed by running
update-davical-database so getting that running is the problem to focus
on.

First, confirm that everything is running version 11 of postgresql. On
my system, ps -ax shows:

715 ? S 1:31 /usr/lib/postgresql/11/bin/postgres -D
/var/lib/postgresql/11/main -c
config_file=/etc/postgresql/11/main/postgresql.conf

The 11 is of course the version number.

In my /etc/postgresql/11/main/pg_hba.conf, my ‘local’ configuration
line is different:

local all all ident

But the documentation says ‘ident’ and ‘peer’ mean the same
thing for local connections.

I wish I could help you more with PostgreSQL authentication/permissions
configuration, but I don’t know it well myself and fortunately it’s
working for me.

You might try update-davical-database --debug which will show you the
password it’s using. In my case, the script is reading it from
/etc/davical/administration.yml.

Good luck!

-Jim

On 1 Nov 2020, at 11:38, Kim Haverblad wrote:

> Well, still have issue with update-davical-database while I now can
> execute it I get the splash text with parameters which is supported.
> I've created .pgpass including administration.yml which didn't to the
> trick. So still have the 'Database schema needs upgrading. Current:
> 1.3.2, Desired: 1.3.3' and don't know what else can be done to fix
> this.
>
> Any suggestions?
>
> //Kim
>
> On 2020-11-01 20:07, Kim Haverblad wrote:
>> Right, found the error to what caused my little issue after the
>> upgrade; when checking the postresql logs it showed the following:
>>
>> 2020-11-01  CET [2945] davical_app@davical FATAL:  Peer
>> authentication failed for user "davical_app"
>> 2020-11-01  CET [2945] davical_app@davical DETAIL:  Connection
>> matched pg_hba.conf line 90: "local   all            
>> all
>>
>> Checking pg_hba-conf line 90 it shows:
>>
>> # "local" is for Unix domain socket connections only
>> local   all             all peer
>>
>> so the issue was that connection was set to 'peer' and not 'md5' and
>> once this was changed to:
>>
>> # "local" is for Unix domain socket connections only
>> local   all             all md5
>>
>> everything was working again.
>>
>> //Kim
>>
>> On 2020-11-01 18:30, Kim Haverblad wrote:
>>> Well, Postgress upgrade worked out, I think, kinda. But, now Calidav
>>> complaints about access and no sure whether Postgress access issue
>>> or whether it's Calidav issue since DB and users
>>>
>>> [Sun Nov 01 2020] [php7:notice] [pid 543] [client
>>> 192.168.0.120:65441] Unable to connect to database: SQLSTATE[08006]
>>> [7] FATAL:  Peer authentication failed for user "davical_app"
>>> [Sun Nov 01 2020] [php7:error] [pid 543] [client
>>> 192.168.0.120:65441] PHP Fatal error:  PDO connection error
>>> 'pgsql:dbname=davical port=5432 user=davical_app password=####':
>>> SQLSTATE[08006] [7] FATAL: Peer authentication failed for user
>>> "davical_app" in /usr/share/awl/inc/AwlDBDialect.php on line 103
>>>
>>> So checking that we have the db:
>>>
>>>                                   
>>> List of databases
>>>    Name    |    Owner    | Encoding |   Collate  
>>> |    Ctype | Access privileges
>>> -----------+-------------+----------+-------------+-------------+-----------------------
>>>  davical   | davical_dba | UTF8     | en_US.UTF-8 |
>>> en_US.UTF-8 |
>>>
>>> and then whether the user exists:
>>>
>>>                                    
>>> List of roles
>>>   Role name  |
>>> Attributes                         | Member
>>> of
>>> -------------+------------------------------------------------------------+-----------
>>>  davical_app
>>> |                                                           
>>> | {}
>>>  davical_dba
>>> |                                                           
>>> | {}
>>>
>>> So should is it seems that something didn't really go that well in
>>> the migration process. What are the attributes expected for the two
>>> davical users?
>>>
>>> //Kim
>>>
>>> On 2020-11-01 12:16, Kim Haverblad wrote:
>>>> Thanks Jim and Julien! Never really been working postgresql so this
>>>> insight is absolutely helpful and checking with pg_lsclusters it
>>>> shows the below so it's the version 9.6 which is currently being
>>>> used.
>>>>
>>>> sudo pg_lsclusters
>>>> Ver Cluster Port Status Owner    Data directory Log file
>>>> 9.6 main    5432 online postgres /var/lib/postgresql/9.6/main
>>>> /var/log/postgresql/postgresql-9.6-main.log
>>>> 11  main    5433 online postgres /var/lib/postgresql/11/main
>>>> /var/log/postgresql/postgresql-11-main.log
>>>>
>>>> Just to make sure, no issues then to jump up to version 11?
>>>>
>>>> //Kim
>>>>
>>>> On 2020-11-01 08:57, Julien Métairie via Davical-general wrote:
>>>>> Hi list,
>>>>>
>>>>>> As I remember, Debian
>>>>>> sometimes installs a new version of postgresql in addition to the
>>>>>> old
>>>>>> version, in order to be extra careful that it doesn’t mess up
>>>>>> any of
>>>>>> your data.
>>>>>
>>>>> Indeed, I have the following note to upgrade my PGSQL cluster from
>>>>> 8.4 to 9.1. It should ne applicable to newer versions as well, but
>>>>> remember to keep backups, though. ;)
>>>>>
>>>>>
>>>>> Delete default 9.1 cluster:
>>>>>     pg_dropcluster--stop 9.1 main
>>>>>
>>>>> Upgrade current cluster:
>>>>>     pg_upgradecluster 8.4 main
>>>>>
>>>>> Delete old cluster:
>>>>>     pg_dropcluster 8.4 main
>>>>>
>>>>> Remove 8.4 engine:
>>>>>     apt-get autoremove --purge postgresql-8.4
>>>>> postgresql-client-8.4
>>>>>
>>>>>
>>>>> Regards,
>>>>> Julien
>>>>>
>>>>>
>>>>> Le 01/11/2020 à 01:47, Jim Fenton a écrit :
>>>>>> Kim,
>>>>>>
>>>>>> I remember something like this when I last did a Debian upgrade,
>>>>>> but unfortunately don’t have anything in my notes. As I
>>>>>> remember, Debian sometimes installs a new version of postgresql
>>>>>> in addition to the old version, in order to be extra careful that
>>>>>> it doesn’t mess up any of your data.
>>>>>>
>>>>>> You should be able to use pg_lsclusters to see if there is more
>>>>>> than one database cluster there, what version, what’s active,
>>>>>> etc. If so, there are some instructions online such as
>>>>>> https://wiki.postgresql.org/wiki/Using_pg_upgrade_on_Ubuntu/Debian
>>>>>> on how to make sure everything is running correctly on Buster.
>>>>>>
>>>>>> Another good thing to do is to manually connect to PostgreSQL
>>>>>> with the sql command and credentials you should have, and see if
>>>>>> you can at least read from the database OK.
>>>>>>
>>>>>> Hope this helps.
>>>>>>
>>>>>> -Jim
>>>>>>
>>>>>> On 31 Oct 2020, at 16:13, Kim Haverblad wrote:
>>>>>>
>>>>>>> Hello Jim,
>>>>>>>
>>>>>>> Thanks for pointing out, hrm, yes missed that one even when it
>>>>>>> was in-front of me and changing the permission let's me execute
>>>>>>> the script which then prints the help info. So tried to included
>>>>>>> the db creds in the update script which didn't make any
>>>>>>> difference and then created .pgpass file in the /dba directory.
>>>>>>> Still won't upgrade the db. Verified that the access rights in
>>>>>>> the db is set to the correct user, etc. Also, everything seems
>>>>>>> to work fine. Seems that I'm still missing out on something.
>>>>>>>
>>>>>>> //Kim
>>>>>>>
>>>>>>>
>>>>>>> On 2020-10-31 22:08, Jim Fenton wrote:
>>>>>>>> Hi Kim,
>>>>>>>>
>>>>>>>> Looks like you need execute permissions on that script:
>>>>>>>>
>>>>>>>> chmod ug+x update-davical-database
>>>>>>>>
>>>>>>>> -Jim
>>>>>>>>
>>>>>>>> On 31 Oct 2020, at 13:36, Kim Haverblad wrote:
>>>>>>>>
>>>>>>>>> Hello!
>>>>>>>>>
>>>>>>>>> Been trying to run the upgrade script but getting all the time
>>>>>>>>> permission issue:
>>>>>>>>>
>>>>>>>>> root@bigred:/usr/share/davical/dba#
>>>>>>>>> /usr/share/davical/dba/update-davical-database
>>>>>>>>> bash: /usr/share/davical/dba/update-davical-database:
>>>>>>>>> Permission denied
>>>>>>>>>
>>>>>>>>> quite a while ago I ran an update but recall that it used to
>>>>>>>>> work prior upgradingto Raspbian Buster; rights seems correct
>>>>>>>>> as well:
>>>>>>>>>
>>>>>>>>> root@bigred:/usr/share/davical/dba# ls -l update*
>>>>>>>>> -rw-r----- 1 root www-data 14474 Oct 31 21:21
>>>>>>>>> update-davical-database
>>>>>>>>>
>>>>>>>>> What I'm I missing here?
>>>>>>>>>
>>>>>>>>> //Kim
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Davical-general mailing list
>>>>>>>>> Davical-general@lists.sourceforge.net
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/davical-general
>>>>>>>
>>>>>>> --
>>>>>>> Vänlig hälsning,
>>>>>>> Kim Haverblad
>>>>>>> M: 0760046232
>>>>>>> --
>>>>>>> GnuPG ID: 0x8B75 DF42 EE04 296E
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Davical-general mailing list
>>>>>> Davical-general@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/davical-general
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Davical-general mailing list
>>>>> Davical-general@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/davical-general
>>>>
>>>
>>
>
> --
> Vänlig hälsning,
> Kim Haverblad
> M: 0760046232
> --
> GnuPG ID: 0x8B75 DF42 EE04 296E
>
>
> _______________________________________________
> Davical-general mailing list
> Davical-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/davical-general


_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general
Re: Update-davical-database permission issue [ In reply to ]
Long story short, just can't get the upgrade script to work and posted
another email about that issue. So upgraded the db by executing the sql
commands directly against the database so now it's been updated.

Next issue to solve is that I can create entries but I can't invite any
other to the calendar entry; meaning when I add another users who has
access and exist in the same DAVical server and click save; well nothing
is saved or kept. Same entry without any invite it's being saved without
any problem. Editing the saved entry and add an invite, the edit of
adding a invite isn't saved. Checking my user profile it clearly
indicates that users can "Scheduling: Deliver an Invitation".

Suggestion what to look for would be appreciated.

//Kim

On 2020-11-01 20:38, Kim Haverblad wrote:
> Well, still have issue with update-davical-database while I now can
> execute it I get the splash text with parameters which is supported.
> I've created .pgpass including administration.yml which didn't to the
> trick. So still have the 'Database schema needs upgrading. Current:
> 1.3.2, Desired: 1.3.3' and don't know what else can be done to fix this.
>
> Any suggestions?
>
> //Kim
>
> On 2020-11-01 20:07, Kim Haverblad wrote:
>> Right, found the error to what caused my little issue after the
>> upgrade; when checking the postresql logs it showed the following:
>>
>> 2020-11-01  CET [2945] davical_app@davical FATAL:  Peer
>> authentication failed for user "davical_app"
>> 2020-11-01  CET [2945] davical_app@davical DETAIL:  Connection
>> matched pg_hba.conf line 90: "local   all             all
>>
>> Checking pg_hba-conf line 90 it shows:
>>
>> # "local" is for Unix domain socket connections only
>> local   all             all peer
>>
>> so the issue was that connection was set to 'peer' and not 'md5' and
>> once this was changed to:
>>
>> # "local" is for Unix domain socket connections only
>> local   all             all md5
>>
>> everything was working again.
>>
>> //Kim
>>
>> On 2020-11-01 18:30, Kim Haverblad wrote:
>>> Well, Postgress upgrade worked out, I think, kinda. But, now Calidav
>>> complaints about access and no sure whether Postgress access issue
>>> or whether it's Calidav issue since DB and users
>>>
>>> [Sun Nov 01 2020] [php7:notice] [pid 543] [client
>>> 192.168.0.120:65441] Unable to connect to database: SQLSTATE[08006]
>>> [7] FATAL:  Peer authentication failed for user "davical_app"
>>> [Sun Nov 01 2020] [php7:error] [pid 543] [client
>>> 192.168.0.120:65441] PHP Fatal error:  PDO connection error
>>> 'pgsql:dbname=davical port=5432 user=davical_app password=####':
>>> SQLSTATE[08006] [7] FATAL: Peer authentication failed for user
>>> "davical_app" in /usr/share/awl/inc/AwlDBDialect.php on line 103
>>>
>>> So checking that we have the db:
>>>
>>>                                    List of databases
>>>    Name    |    Owner    | Encoding |   Collate   |    Ctype |
>>> Access privileges
>>> -----------+-------------+----------+-------------+-------------+-----------------------
>>>
>>>  davical   | davical_dba | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
>>>
>>> and then whether the user exists:
>>>
>>>                                     List of roles
>>>   Role name  | Attributes                         | Member of
>>> -------------+------------------------------------------------------------+-----------
>>>
>>>  davical_app
>>> |                                                            | {}
>>>  davical_dba
>>> |                                                            | {}
>>>
>>> So should is it seems that something didn't really go that well in
>>> the migration process. What are the attributes expected for the two
>>> davical users?
>>>
>>> //Kim
>>>
>>> On 2020-11-01 12:16, Kim Haverblad wrote:
>>>> Thanks Jim and Julien! Never really been working postgresql so this
>>>> insight is absolutely helpful and checking with pg_lsclusters it
>>>> shows the below so it's the version 9.6 which is currently being used.
>>>>
>>>> sudo pg_lsclusters
>>>> Ver Cluster Port Status Owner    Data directory Log file
>>>> 9.6 main    5432 online postgres /var/lib/postgresql/9.6/main
>>>> /var/log/postgresql/postgresql-9.6-main.log
>>>> 11  main    5433 online postgres /var/lib/postgresql/11/main
>>>> /var/log/postgresql/postgresql-11-main.log
>>>>
>>>> Just to make sure, no issues then to jump up to version 11?
>>>>
>>>> //Kim
>>>>
>>>> On 2020-11-01 08:57, Julien Métairie via Davical-general wrote:
>>>>> Hi list,
>>>>>
>>>>>> As I remember, Debian
>>>>>> sometimes installs a new version of postgresql in addition to the
>>>>>> old
>>>>>> version, in order to be extra careful that it doesn’t mess up any of
>>>>>> your data.
>>>>>
>>>>> Indeed, I have the following note to upgrade my PGSQL cluster from
>>>>> 8.4 to 9.1. It should ne applicable to newer versions as well, but
>>>>> remember to keep backups, though. ;)
>>>>>
>>>>>
>>>>> Delete default 9.1 cluster:
>>>>>     pg_dropcluster--stop 9.1 main
>>>>>
>>>>> Upgrade current cluster:
>>>>>     pg_upgradecluster 8.4 main
>>>>>
>>>>> Delete old cluster:
>>>>>     pg_dropcluster 8.4 main
>>>>>
>>>>> Remove 8.4 engine:
>>>>>     apt-get autoremove --purge postgresql-8.4 postgresql-client-8.4
>>>>>
>>>>>
>>>>> Regards,
>>>>> Julien
>>>>>
>>>>>
>>>>> Le 01/11/2020 à 01:47, Jim Fenton a écrit :
>>>>>> Kim,
>>>>>>
>>>>>> I remember something like this when I last did a Debian upgrade,
>>>>>> but unfortunately don’t have anything in my notes. As I remember,
>>>>>> Debian sometimes installs a new version of postgresql in addition
>>>>>> to the old version, in order to be extra careful that it doesn’t
>>>>>> mess up any of your data.
>>>>>>
>>>>>> You should be able to use pg_lsclusters to see if there is more
>>>>>> than one database cluster there, what version, what’s active,
>>>>>> etc. If so, there are some instructions online such as
>>>>>> https://wiki.postgresql.org/wiki/Using_pg_upgrade_on_Ubuntu/Debian
>>>>>> on how to make sure everything is running correctly on Buster.
>>>>>>
>>>>>> Another good thing to do is to manually connect to PostgreSQL
>>>>>> with the sql command and credentials you should have, and see if
>>>>>> you can at least read from the database OK.
>>>>>>
>>>>>> Hope this helps.
>>>>>>
>>>>>> -Jim
>>>>>>
>>>>>> On 31 Oct 2020, at 16:13, Kim Haverblad wrote:
>>>>>>
>>>>>>> Hello Jim,
>>>>>>>
>>>>>>> Thanks for pointing out, hrm, yes missed that one even when it
>>>>>>> was in-front of me and changing the permission let's me execute
>>>>>>> the script which then prints the help info. So tried to included
>>>>>>> the db creds in the update script which didn't make any
>>>>>>> difference and then created .pgpass file in the /dba directory.
>>>>>>> Still won't upgrade the db. Verified that the access rights in
>>>>>>> the db is set to the correct user, etc. Also, everything seems
>>>>>>> to work fine. Seems that I'm still missing out on something.
>>>>>>>
>>>>>>> //Kim
>>>>>>>
>>>>>>>
>>>>>>> On 2020-10-31 22:08, Jim Fenton wrote:
>>>>>>>> Hi Kim,
>>>>>>>>
>>>>>>>> Looks like you need execute permissions on that script:
>>>>>>>>
>>>>>>>> chmod ug+x update-davical-database
>>>>>>>>
>>>>>>>> -Jim
>>>>>>>>
>>>>>>>> On 31 Oct 2020, at 13:36, Kim Haverblad wrote:
>>>>>>>>
>>>>>>>>> Hello!
>>>>>>>>>
>>>>>>>>> Been trying to run the upgrade script but getting all the time
>>>>>>>>> permission issue:
>>>>>>>>>
>>>>>>>>> root@bigred:/usr/share/davical/dba#
>>>>>>>>> /usr/share/davical/dba/update-davical-database
>>>>>>>>> bash: /usr/share/davical/dba/update-davical-database:
>>>>>>>>> Permission denied
>>>>>>>>>
>>>>>>>>> quite a while ago I ran an update but recall that it used to
>>>>>>>>> work prior upgradingto Raspbian Buster; rights seems correct
>>>>>>>>> as well:
>>>>>>>>>
>>>>>>>>> root@bigred:/usr/share/davical/dba# ls -l update*
>>>>>>>>> -rw-r----- 1 root www-data 14474 Oct 31 21:21
>>>>>>>>> update-davical-database
>>>>>>>>>
>>>>>>>>> What I'm I missing here?
>>>>>>>>>
>>>>>>>>> //Kim
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Davical-general mailing list
>>>>>>>>> Davical-general@lists.sourceforge.net
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/davical-general
>>>>>>>
>>>>>>> --
>>>>>>> Vänlig hälsning,
>>>>>>> Kim Haverblad
>>>>>>> M: 0760046232
>>>>>>> --
>>>>>>> GnuPG ID: 0x8B75 DF42 EE04 296E
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Davical-general mailing list
>>>>>> Davical-general@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/davical-general
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Davical-general mailing list
>>>>> Davical-general@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/davical-general
>>>>
>>>
>>
>

--
Vänlig hälsning,
Kim Haverblad
M: 0760046232
--
GnuPG ID: 0x8B75 DF42 EE04 296E


_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general
Re: Unable to deliver invitation [ In reply to ]
Hi Kim,

On Mon, 2020-11-23 at 21:44 +0100, Kim Haverblad via Davical-general
wrote:
> Next issue to solve is that I can create entries but I can't invite
> any
> other to the calendar entry; meaning when I add another users who
> has
> access and exist in the same DAVical server and click save; well
> nothing
> is saved or kept. Same entry without any invite it's being saved
> without
> any problem. Editing the saved entry and add an invite, the edit of
> adding a invite isn't saved. Checking my user profile it clearly
> indicates that users can "Scheduling: Deliver an Invitation".

Is there anything appearing in your webservers error log?

--
Andrew Ruthven, Wellington, New Zealand
andrew@etc.gen.nz |
Catalyst Cloud: | This space intentionally left blank
https://catalystcloud.nz |



_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general
Re: Unable to deliver invitation [ In reply to ]
Hi Andrew,

Yes, the error log does show quite a bit to look into; here goes:

[Tue Nov 24 20:18:53.521206 2020] [php7:notice] [pid 26001] [client
192.168.0.120:50518] davical: LOG: POST: Query: Error: QF in
'/usr/share/davical/inc/caldav-POST.php' on line 89
[Tue Nov 24 20:18:53.521344 2020] [php7:notice] [pid 26001] [client
192.168.0.120:50518] davical: LOG: POST: Query: QF: SQL error "0A000" -
ERROR: set-returning functions are not allowed in CASE LINE 4: ...
expanded.g_id FROM (SELECT CASE WHEN $2 > 0 THEN expand_mem... ^ HINT: You
[Tue Nov 24 20:18:53.521381 2020] [php7:notice] [pid 26001] [client
192.168.0.120:50518] davical: LOG: POST: Query: QF: RY: SELECT group_id
FROM group_member WHERE member_id = $1 UNION SELECT expanded.g_id FROM
(SELECT CASE WHEN $2 > 0 THEN expand_memberships( group_id, $2 - 1) EN
[Tue Nov 24 20:18:53.521443 2020] [php7:notice] [pid 26001] [client
192.168.0.120:50518] davical: LOG: POST: Query: QF: id IS NOT NULL;
CONTEXT: SQL function "expand_memberships" during startup SQL statement
"SELECT bit_or(subquery.privileges) FROM ( SELECT privileges FROM grants
[Tue Nov 24 20:18:53.521475 2020] [php7:notice] [pid 26001] [client
192.168.0.120:50518] davical: LOG: POST: Query: QF: cessor OR
to_principal IN (SELECT expand_memberships(in_accessor,in_depth))) UNION
SELECT bit_or(sq2.privileges) FROM ( SELECT 32::BIT(24) AS privileges
FROM exp
[Tue Nov 24 20:18:53.521507 2020] [php7:notice] [pid 26001] [client
192.168.0.120:50518] davical: LOG: POST: Query: QF: ON SELECT
default_privileges AS privileges FROM principal WHERE principal_id =
in_grantor ) AS sq2 ) AS subquery" PL/pgSQL function
pprivs(bigint,bigint,integer)
[Tue Nov 24 20:18:53.521563 2020] [php7:notice] [pid 26001] [client
192.168.0.120:50518] davical: LOG: POST: Query: Error: QF in
'/usr/share/davical/inc/caldav-POST.php' on line 89
[Tue Nov 24 20:18:53.521592 2020] [php7:notice] [pid 26001] [client
192.168.0.120:50518] davical: LOG: POST: Query: QF: SELECT
pprivs(:session_principal::int8,principal_id,:scan_depth::int) AS p,
username FROM usr JOIN principal USING(user_no) WHERE lower(usr.email) =
lower(:email
[Tue Nov 24 20:18:53.521627 2020] [php7:notice] [pid 26001] [client
192.168.0.120:50518] davical: LOG: POST: Query: QF: ":session_principal"
[Tue Nov 24 20:18:53.521656 2020] [php7:notice] [pid 26001] [client
192.168.0.120:50518] davical: LOG: POST: Query: QF: ":scan_depth" => "2"
[Tue Nov 24 20:18:53.521683 2020] [php7:notice] [pid 26001] [client
192.168.0.120:50518] davical: LOG: POST: Query: QF: ":email" =>
"test@tjansson.se"
[Tue Nov 24 20:18:53.521767 2020] [php7:notice] [pid 26001] [client
192.168.0.120:50518] davical: LOG: :Response status 501 for POST
/caldav.php/khav/.out/
[Tue Nov 24 20:18:53.521799 2020] [php7:notice] [pid 26001] [client
192.168.0.120:50518] davical: LOG: :***************** Response Header
****************
[Tue Nov 24 20:18:53.521826 2020] [php7:notice] [pid 26001] [client
192.168.0.120:50518] davical: LOG: headers:-->Server: 1.1
[Tue Nov 24 20:18:53.521851 2020] [php7:notice] [pid 26001] [client
192.168.0.120:50518] davical: LOG: headers:-->DAV: 1, 2, 3,
access-control, calendar-access, calendar-schedule
[Tue Nov 24 20:18:53.521876 2020] [php7:notice] [pid 26001] [client
192.168.0.120:50518] davical: LOG: headers:-->DAV: extended-mkcol, bind,
addressbook, calendar-auto-schedule, calendar-proxy
[Tue Nov 24 20:18:53.521902 2020] [php7:notice] [pid 26001] [client
192.168.0.120:50518] davical: LOG: headers:-->X-DAViCal-Version:
DAViCal/1.1.8; DB/1.3.3
[Tue Nov 24 20:18:53.521926 2020] [php7:notice] [pid 26001] [client
192.168.0.120:50518] davical: LOG: headers:-->Content-type: text/plain;
charset="utf-8"
[Tue Nov 24 20:18:53.521952 2020] [php7:notice] [pid 26001] [client
192.168.0.120:50518] davical: LOG: :******************** Response
********************
[Tue Nov 24 20:18:53.522023 2020] [php7:notice] [pid 26001] [client
192.168.0.120:50518] davical: LOG: response:-->Database error
[Tue Nov 24 20:19:02.086371 2020] [php7:notice] [pid 15864] [client
192.168.0.120:50520] davical: LOG: Principal: Query: Error: QF in
'/usr/share/davical/inc/Principal.php' on line 224
[Tue Nov 24 20:19:02.086474 2020] [php7:notice] [pid 15864] [client
192.168.0.120:50520] davical: LOG: Principal: Query: QF: SQL error
"0A000" - ERROR: set-returning functions are not allowed in CASE LINE 4:
... expanded.g_id FROM (SELECT CASE WHEN $2 > 0 THEN expand_mem... ^ HINT
[Tue Nov 24 20:19:02.086510 2020] [php7:notice] [pid 15864] [client
192.168.0.120:50520] davical: LOG: Principal: Query: QF: RY: SELECT
group_id FROM group_member WHERE member_id = $1 UNION SELECT
expanded.g_id FROM (SELECT CASE WHEN $2 > 0 THEN expand_memberships(
group_id, $2 -
[Tue Nov 24 20:19:02.086570 2020] [php7:notice] [pid 15864] [client
192.168.0.120:50520] davical: LOG: Principal: Query: QF: id IS NOT NULL;
CONTEXT: SQL function "expand_memberships" during startup SQL statement
"SELECT bit_or(subquery.privileges) FROM ( SELECT privileges FROM gr
[Tue Nov 24 20:19:02.086602 2020] [php7:notice] [pid 15864] [client
192.168.0.120:50520] davical: LOG: Principal: Query: QF: cessor OR
to_principal IN (SELECT expand_memberships(in_accessor,in_depth))) UNION
SELECT bit_or(sq2.privileges) FROM ( SELECT 32::BIT(24) AS privileges FRO
[Tue Nov 24 20:19:02.086634 2020] [php7:notice] [pid 15864] [client
192.168.0.120:50520] davical: LOG: Principal: Query: QF: ON SELECT
default_privileges AS privileges FROM principal WHERE principal_id =
in_grantor ) AS sq2 ) AS subquery" PL/pgSQL function
pprivs(bigint,bigint,int
[Tue Nov 24 20:19:02.086684 2020] [php7:notice] [pid 15864] [client
192.168.0.120:50520] davical: LOG: Principal: Query: Error: QF in
'/usr/share/davical/inc/Principal.php' on line 224
[Tue Nov 24 20:19:02.086712 2020] [php7:notice] [pid 15864] [client
192.168.0.120:50520] davical: LOG: Principal: Query: QF: SELECT *,
pprivs(:session_principal::int8,principal_id,:scan_depth::int) AS
privileges FROM dav_principal WHERE lower(email)=lower(:param)
[Tue Nov 24 20:19:02.086747 2020] [php7:notice] [pid 15864] [client
192.168.0.120:50520] davical: LOG: Principal: Query: QF:    
":session_principal" => "1001"
[Tue Nov 24 20:19:02.086775 2020] [php7:notice] [pid 15864] [client
192.168.0.120:50520] davical: LOG: Principal: Query: QF:    
":scan_depth" => "2"
[Tue Nov 24 20:19:02.086802 2020] [php7:notice] [pid 15864] [client
192.168.0.120:50520] davical: LOG: Principal: Query: QF:     ":param" =>
"test@tjansson.se"
[Tue Nov 24 20:19:02.089351 2020] [php7:notice] [pid 15864] [client
192.168.0.120:50520] davical: LOG: PUT: Query: Error: QF in
'/usr/share/davical/inc/caldav-PUT-functions.php' on line 1631
[Tue Nov 24 20:19:02.089416 2020] [php7:notice] [pid 15864] [client
192.168.0.120:50520] davical: LOG: PUT: Query: QF: SQL error "25P02" -
ERROR: current transaction is aborted, commands ignored until end of
transaction block"
[Tue Nov 24 20:19:02.089482 2020] [php7:notice] [pid 15864] [client
192.168.0.120:50520] davical: LOG: PUT: Query: Error: QF in
'/usr/share/davical/inc/caldav-PUT-functions.php' on line 1631
[Tue Nov 24 20:19:02.089512 2020] [php7:notice] [pid 15864] [client
192.168.0.120:50520] davical: LOG: PUT: Query: QF: INSERT INTO
caldav_data ( dav_id, user_no, dav_name, dav_etag, caldav_data,
caldav_type, logged_user, created, modified, collection_id, weak_etag )
VALUES( :dav_i
[Tue Nov 24 20:19:02.089543 2020] [php7:notice] [pid 15864] [client
192.168.0.120:50520] davical: LOG: PUT: Query: QF: d, :modified,
:collection_id, :weak_etag )
[Tue Nov 24 20:19:02.089573 2020] [php7:notice] [pid 15864] [client
192.168.0.120:50520] davical: LOG: PUT: Query: QF: ":etag" =>
"992f8e8d510a05c1f9ac93c7ad51c61c"
[Tue Nov 24 20:19:02.089601 2020] [php7:notice] [pid 15864] [client
192.168.0.120:50520] davical: LOG: PUT: Query: QF: ":dav_data" =>
"BEGIN:VCALENDAR\r\nPRODID:-//Mozilla.org/NONSGML Mozilla Calendar
V1.1//EN\r\nVERSION:2.0\r\nBEGIN:VTIMEZONE\r\nTZID:Europe/Stockholm\r\nBEGIN
[Tue Nov 24 20:19:02.089681 2020] [php7:notice] [pid 15864] [client
192.168.0.120:50520] davical: LOG: PUT: Query: QF: ":caldav_type" =>
"VEVENT"
[Tue Nov 24 20:19:02.089708 2020] [php7:notice] [pid 15864] [client
192.168.0.120:50520] davical: LOG: PUT: Query: QF: ":session_user" => "1001"
[Tue Nov 24 20:19:02.089735 2020] [php7:notice] [pid 15864] [client
192.168.0.120:50520] davical: LOG: PUT: Query: QF: ":weak_etag" => ""
[Tue Nov 24 20:19:02.089761 2020] [php7:notice] [pid 15864] [client
192.168.0.120:50520] davical: LOG: PUT: Query: QF: ":dav_id" => "1415"
[Tue Nov 24 20:19:02.089787 2020] [php7:notice] [pid 15864] [client
192.168.0.120:50520] davical: LOG: PUT: Query: QF: ":modified" =>
"20201124T191901Z"
[Tue Nov 24 20:19:02.089813 2020] [php7:notice] [pid 15864] [client
192.168.0.120:50520] davical: LOG: PUT: Query: QF: ":collection_id" =>
"1002"
[Tue Nov 24 20:19:02.089839 2020] [php7:notice] [pid 15864] [client
192.168.0.120:50520] davical: LOG: PUT: Query: QF: ":user_no" => "1001"
[Tue Nov 24 20:19:02.089865 2020] [php7:notice] [pid 15864] [client
192.168.0.120:50520] davical: LOG: PUT: Query: QF: ":dav_name" =>
"/khav/calendar/2b41b780-16a3-42bd-b8cf-742606b1a901.ics"
[Tue Nov 24 20:19:02.089892 2020] [php7:notice] [pid 15864] [client
192.168.0.120:50520] davical: LOG: PUT: Query: QF: ":created" =>
"20201124T191828Z"
[Tue Nov 24 20:19:02.089939 2020] [php7:notice] [pid 15864] [client
192.168.0.120:50520] davical: FATAL: :Insert into calendar_item failed...
[Tue Nov 24 20:19:02.089957 2020] [php7:notice] [pid 15864] [client
192.168.0.120:50520] ================= Stack Trace ===================
[Tue Nov 24 20:19:02.090005 2020] [php7:notice] [pid 15864] [client
192.168.0.120:50520]  ===> /usr/share/davical/htdocs/caldav.php[123]
calls include()
[Tue Nov 24 20:19:02.090026 2020] [php7:notice] [pid 15864] [client
192.168.0.120:50520]  ===>
/usr/share/davical/inc/caldav-PUT-vcalendar.php[85] calls write_resource()

Hope this provides some input enought on how to fix this.

//Kim

On 2020-11-24 11:26, Andrew Ruthven wrote:
> Hi Kim,
>
> On Mon, 2020-11-23 at 21:44 +0100, Kim Haverblad via Davical-general
> wrote:
>> Next issue to solve is that I can create entries but I can't invite
>> any
>> other to the calendar entry; meaning when I add another users who
>> has
>> access and exist in the same DAVical server and click save; well
>> nothing
>> is saved or kept. Same entry without any invite it's being saved
>> without
>> any problem. Editing the saved entry and add an invite, the edit of
>> adding a invite isn't saved. Checking my user profile it clearly
>> indicates that users can "Scheduling: Deliver an Invitation".
> Is there anything appearing in your webservers error log?
>

--
Vänlig hälsning,
Kim Haverblad
M: 0760046232
--
GnuPG ID: 0x8B75 DF42 EE04 296E


_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general
Re: Unable to deliver invitation [ In reply to ]
I think this is due to a change made in PostgreSQL 10. See
https://github.com/postgres/postgres/commit/0436f6bde8848b7135f19dd7f8548b8c2ae89a34

-Jim

On 24 Nov 2020, at 11:29, Kim Haverblad via Davical-general wrote:

> Hi Andrew,
>
> Yes, the error log does show quite a bit to look into; here goes:
>
> [Tue Nov 24 20:18:53.521206 2020] [php7:notice] [pid 26001] [client
> 192.168.0.120:50518] davical: LOG: POST: Query: Error: QF in
> '/usr/share/davical/inc/caldav-POST.php' on line 89
> [Tue Nov 24 20:18:53.521344 2020] [php7:notice] [pid 26001] [client
> 192.168.0.120:50518] davical: LOG: POST: Query: QF: SQL error "0A000"
> - ERROR: set-returning functions are not allowed in CASE LINE 4: ...
> expanded.g_id FROM (SELECT CASE WHEN $2 > 0 THEN expand_mem... ^ HINT:
> You
> [Tue Nov 24 20:18:53.521381 2020] [php7:notice] [pid 26001] [client
> 192.168.0.120:50518] davical: LOG: POST: Query: QF: RY: SELECT
> group_id FROM group_member WHERE member_id = $1 UNION SELECT
> expanded.g_id FROM (SELECT CASE WHEN $2 > 0 THEN expand_memberships(
> group_id, $2 - 1) EN
> [Tue Nov 24 20:18:53.521443 2020] [php7:notice] [pid 26001] [client
> 192.168.0.120:50518] davical: LOG: POST: Query: QF: id IS NOT NULL;
> CONTEXT: SQL function "expand_memberships" during startup SQL
> statement "SELECT bit_or(subquery.privileges) FROM ( SELECT privileges
> FROM grants
> [Tue Nov 24 20:18:53.521475 2020] [php7:notice] [pid 26001] [client
> 192.168.0.120:50518] davical: LOG: POST: Query: QF: cessor OR
> to_principal IN (SELECT expand_memberships(in_accessor,in_depth)))
> UNION SELECT bit_or(sq2.privileges) FROM ( SELECT 32::BIT(24) AS
> privileges FROM exp
> [Tue Nov 24 20:18:53.521507 2020] [php7:notice] [pid 26001] [client
> 192.168.0.120:50518] davical: LOG: POST: Query: QF: ON SELECT
> default_privileges AS privileges FROM principal WHERE principal_id =
> in_grantor ) AS sq2 ) AS subquery" PL/pgSQL function
> pprivs(bigint,bigint,integer)
> [Tue Nov 24 20:18:53.521563 2020] [php7:notice] [pid 26001] [client
> 192.168.0.120:50518] davical: LOG: POST: Query: Error: QF in
> '/usr/share/davical/inc/caldav-POST.php' on line 89
> [Tue Nov 24 20:18:53.521592 2020] [php7:notice] [pid 26001] [client
> 192.168.0.120:50518] davical: LOG: POST: Query: QF: SELECT
> pprivs(:session_principal::int8,principal_id,:scan_depth::int) AS p,
> username FROM usr JOIN principal USING(user_no) WHERE lower(usr.email)
> = lower(:email
> [Tue Nov 24 20:18:53.521627 2020] [php7:notice] [pid 26001] [client
> 192.168.0.120:50518] davical: LOG: POST: Query: QF:
> ":session_principal" => "1001"
> [Tue Nov 24 20:18:53.521656 2020] [php7:notice] [pid 26001] [client
> 192.168.0.120:50518] davical: LOG: POST: Query: QF: ":scan_depth" =>
> "2"
> [Tue Nov 24 20:18:53.521683 2020] [php7:notice] [pid 26001] [client
> 192.168.0.120:50518] davical: LOG: POST: Query: QF: ":email" =>
> "test@tjansson.se"
> [Tue Nov 24 20:18:53.521767 2020] [php7:notice] [pid 26001] [client
> 192.168.0.120:50518] davical: LOG: :Response status 501 for POST
> /caldav.php/khav/.out/
> [Tue Nov 24 20:18:53.521799 2020] [php7:notice] [pid 26001] [client
> 192.168.0.120:50518] davical: LOG: :***************** Response Header
> ****************
> [Tue Nov 24 20:18:53.521826 2020] [php7:notice] [pid 26001] [client
> 192.168.0.120:50518] davical: LOG: headers:-->Server: 1.1
> [Tue Nov 24 20:18:53.521851 2020] [php7:notice] [pid 26001] [client
> 192.168.0.120:50518] davical: LOG: headers:-->DAV: 1, 2, 3,
> access-control, calendar-access, calendar-schedule
> [Tue Nov 24 20:18:53.521876 2020] [php7:notice] [pid 26001] [client
> 192.168.0.120:50518] davical: LOG: headers:-->DAV: extended-mkcol,
> bind, addressbook, calendar-auto-schedule, calendar-proxy
> [Tue Nov 24 20:18:53.521902 2020] [php7:notice] [pid 26001] [client
> 192.168.0.120:50518] davical: LOG: headers:-->X-DAViCal-Version:
> DAViCal/1.1.8; DB/1.3.3
> [Tue Nov 24 20:18:53.521926 2020] [php7:notice] [pid 26001] [client
> 192.168.0.120:50518] davical: LOG: headers:-->Content-type:
> text/plain; charset="utf-8"
> [Tue Nov 24 20:18:53.521952 2020] [php7:notice] [pid 26001] [client
> 192.168.0.120:50518] davical: LOG: :******************** Response
> ********************
> [Tue Nov 24 20:18:53.522023 2020] [php7:notice] [pid 26001] [client
> 192.168.0.120:50518] davical: LOG: response:-->Database error
> [Tue Nov 24 20:19:02.086371 2020] [php7:notice] [pid 15864] [client
> 192.168.0.120:50520] davical: LOG: Principal: Query: Error: QF in
> '/usr/share/davical/inc/Principal.php' on line 224
> [Tue Nov 24 20:19:02.086474 2020] [php7:notice] [pid 15864] [client
> 192.168.0.120:50520] davical: LOG: Principal: Query: QF: SQL error
> "0A000" - ERROR: set-returning functions are not allowed in CASE LINE
> 4: ... expanded.g_id FROM (SELECT CASE WHEN $2 > 0 THEN expand_mem...
> ^ HINT
> [Tue Nov 24 20:19:02.086510 2020] [php7:notice] [pid 15864] [client
> 192.168.0.120:50520] davical: LOG: Principal: Query: QF: RY: SELECT
> group_id FROM group_member WHERE member_id = $1 UNION SELECT
> expanded.g_id FROM (SELECT CASE WHEN $2 > 0 THEN expand_memberships(
> group_id, $2 -
> [Tue Nov 24 20:19:02.086570 2020] [php7:notice] [pid 15864] [client
> 192.168.0.120:50520] davical: LOG: Principal: Query: QF: id IS NOT
> NULL; CONTEXT: SQL function "expand_memberships" during startup SQL
> statement "SELECT bit_or(subquery.privileges) FROM ( SELECT privileges
> FROM gr
> [Tue Nov 24 20:19:02.086602 2020] [php7:notice] [pid 15864] [client
> 192.168.0.120:50520] davical: LOG: Principal: Query: QF: cessor OR
> to_principal IN (SELECT expand_memberships(in_accessor,in_depth)))
> UNION SELECT bit_or(sq2.privileges) FROM ( SELECT 32::BIT(24) AS
> privileges FRO
> [Tue Nov 24 20:19:02.086634 2020] [php7:notice] [pid 15864] [client
> 192.168.0.120:50520] davical: LOG: Principal: Query: QF: ON SELECT
> default_privileges AS privileges FROM principal WHERE principal_id =
> in_grantor ) AS sq2 ) AS subquery" PL/pgSQL function
> pprivs(bigint,bigint,int
> [Tue Nov 24 20:19:02.086684 2020] [php7:notice] [pid 15864] [client
> 192.168.0.120:50520] davical: LOG: Principal: Query: Error: QF in
> '/usr/share/davical/inc/Principal.php' on line 224
> [Tue Nov 24 20:19:02.086712 2020] [php7:notice] [pid 15864] [client
> 192.168.0.120:50520] davical: LOG: Principal: Query: QF: SELECT *,
> pprivs(:session_principal::int8,principal_id,:scan_depth::int) AS
> privileges FROM dav_principal WHERE lower(email)=lower(:param)
> [Tue Nov 24 20:19:02.086747 2020] [php7:notice] [pid 15864] [client
> 192.168.0.120:50520] davical: LOG: Principal: Query: QF:    
> ":session_principal" => "1001"
> [Tue Nov 24 20:19:02.086775 2020] [php7:notice] [pid 15864] [client
> 192.168.0.120:50520] davical: LOG: Principal: Query: QF:    
> ":scan_depth" => "2"
> [Tue Nov 24 20:19:02.086802 2020] [php7:notice] [pid 15864] [client
> 192.168.0.120:50520] davical: LOG: Principal: Query: QF:    
> ":param" => "test@tjansson.se"
> [Tue Nov 24 20:19:02.089351 2020] [php7:notice] [pid 15864] [client
> 192.168.0.120:50520] davical: LOG: PUT: Query: Error: QF in
> '/usr/share/davical/inc/caldav-PUT-functions.php' on line 1631
> [Tue Nov 24 20:19:02.089416 2020] [php7:notice] [pid 15864] [client
> 192.168.0.120:50520] davical: LOG: PUT: Query: QF: SQL error "25P02" -
> ERROR: current transaction is aborted, commands ignored until end of
> transaction block"
> [Tue Nov 24 20:19:02.089482 2020] [php7:notice] [pid 15864] [client
> 192.168.0.120:50520] davical: LOG: PUT: Query: Error: QF in
> '/usr/share/davical/inc/caldav-PUT-functions.php' on line 1631
> [Tue Nov 24 20:19:02.089512 2020] [php7:notice] [pid 15864] [client
> 192.168.0.120:50520] davical: LOG: PUT: Query: QF: INSERT INTO
> caldav_data ( dav_id, user_no, dav_name, dav_etag, caldav_data,
> caldav_type, logged_user, created, modified, collection_id, weak_etag
> ) VALUES( :dav_i
> [Tue Nov 24 20:19:02.089543 2020] [php7:notice] [pid 15864] [client
> 192.168.0.120:50520] davical: LOG: PUT: Query: QF: d, :modified,
> :collection_id, :weak_etag )
> [Tue Nov 24 20:19:02.089573 2020] [php7:notice] [pid 15864] [client
> 192.168.0.120:50520] davical: LOG: PUT: Query: QF: ":etag" =>
> "992f8e8d510a05c1f9ac93c7ad51c61c"
> [Tue Nov 24 20:19:02.089601 2020] [php7:notice] [pid 15864] [client
> 192.168.0.120:50520] davical: LOG: PUT: Query: QF: ":dav_data" =>
> "BEGIN:VCALENDAR\r\nPRODID:-//Mozilla.org/NONSGML Mozilla Calendar
> V1.1//EN\r\nVERSION:2.0\r\nBEGIN:VTIMEZONE\r\nTZID:Europe/Stockholm\r\nBEGIN
> [Tue Nov 24 20:19:02.089681 2020] [php7:notice] [pid 15864] [client
> 192.168.0.120:50520] davical: LOG: PUT: Query: QF: ":caldav_type" =>
> "VEVENT"
> [Tue Nov 24 20:19:02.089708 2020] [php7:notice] [pid 15864] [client
> 192.168.0.120:50520] davical: LOG: PUT: Query: QF: ":session_user" =>
> "1001"
> [Tue Nov 24 20:19:02.089735 2020] [php7:notice] [pid 15864] [client
> 192.168.0.120:50520] davical: LOG: PUT: Query: QF: ":weak_etag" => ""
> [Tue Nov 24 20:19:02.089761 2020] [php7:notice] [pid 15864] [client
> 192.168.0.120:50520] davical: LOG: PUT: Query: QF: ":dav_id" => "1415"
> [Tue Nov 24 20:19:02.089787 2020] [php7:notice] [pid 15864] [client
> 192.168.0.120:50520] davical: LOG: PUT: Query: QF: ":modified" =>
> "20201124T191901Z"
> [Tue Nov 24 20:19:02.089813 2020] [php7:notice] [pid 15864] [client
> 192.168.0.120:50520] davical: LOG: PUT: Query: QF: ":collection_id" =>
> "1002"
> [Tue Nov 24 20:19:02.089839 2020] [php7:notice] [pid 15864] [client
> 192.168.0.120:50520] davical: LOG: PUT: Query: QF: ":user_no" =>
> "1001"
> [Tue Nov 24 20:19:02.089865 2020] [php7:notice] [pid 15864] [client
> 192.168.0.120:50520] davical: LOG: PUT: Query: QF: ":dav_name" =>
> "/khav/calendar/2b41b780-16a3-42bd-b8cf-742606b1a901.ics"
> [Tue Nov 24 20:19:02.089892 2020] [php7:notice] [pid 15864] [client
> 192.168.0.120:50520] davical: LOG: PUT: Query: QF: ":created" =>
> "20201124T191828Z"
> [Tue Nov 24 20:19:02.089939 2020] [php7:notice] [pid 15864] [client
> 192.168.0.120:50520] davical: FATAL: :Insert into calendar_item
> failed...
> [Tue Nov 24 20:19:02.089957 2020] [php7:notice] [pid 15864] [client
> 192.168.0.120:50520] ================= Stack Trace ===================
> [Tue Nov 24 20:19:02.090005 2020] [php7:notice] [pid 15864] [client
> 192.168.0.120:50520]  ===> /usr/share/davical/htdocs/caldav.php[123]
> calls include()
> [Tue Nov 24 20:19:02.090026 2020] [php7:notice] [pid 15864] [client
> 192.168.0.120:50520]  ===>
> /usr/share/davical/inc/caldav-PUT-vcalendar.php[85] calls
> write_resource()
>
> Hope this provides some input enought on how to fix this.
>
> //Kim
>
> On 2020-11-24 11:26, Andrew Ruthven wrote:
>> Hi Kim,
>>
>> On Mon, 2020-11-23 at 21:44 +0100, Kim Haverblad via Davical-general
>> wrote:
>>> Next issue to solve is that I can create entries but I can't invite
>>> any
>>> other to the calendar entry; meaning when I add another users who
>>> has
>>> access and exist in the same DAVical server and click save; well
>>> nothing
>>> is saved or kept. Same entry without any invite it's being saved
>>> without
>>> any problem. Editing the saved entry and add an invite, the edit of
>>> adding a invite isn't saved. Checking my user profile it clearly
>>> indicates that users can "Scheduling: Deliver an Invitation".
>> Is there anything appearing in your webservers error log?
>>
>
> --
> Vänlig hälsning,
> Kim Haverblad
> M: 0760046232
> --
> GnuPG ID: 0x8B75 DF42 EE04 296E
>
>
> _______________________________________________
> Davical-general mailing list
> Davical-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/davical-general


_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general