Mailing List Archive

On Thu, 2010-06-24 at 11:42 +1000, jesse at cake wrote:
> Hi Folks
>
> Running some security updates yesterday afternoon I hadn't looked
> close enough to realise that I was also updating our installation of
> DAViCal and today we appear to be unable to access our calendar system
> via Lightning (the interface however still functions).
>
> Our current version is 0.9.6.1 (unknown previous version) and when
> running the recommended:
>
> /usr/share/davical/dba/update-davical-database --dbuser=davical_dba
>
> I get in response:
>
> The database is currently at revision 1.2.3.
> Applying patch 1.2.4.sql ... failed!
> psql:/usr/share/davical/dba/patches/1.2.4.sql:10: ERROR: column
> "completed" of relation "calendar_item" already exists
> psql:/usr/share/davical/dba/patches/1.2.4.sql:12: ERROR: current
> transaction is aborted, commands ignored until end of transaction
> block
> there is no transaction in progress
> ==> No further patches will be attempted!
> No patches were applied.
> Supported locales updated.
> CalDAV functions updated.
> RRULE functions updated.
> WARNING: no privileges were granted for "dav_id_seq"
> Database permissions updated.
>
> Does anyone have any info as to what will help to rectify this?

Hi Jesse,

Given that is the *only* change in that database patch, it seems your DB
must be at version 1.2.4 already.


http://repo.or.cz/w/davical.git/blob/HEAD:/dba/patches/1.2.4.sql

So you could manually tell the database that it is actually version
1.2.4, by the following (in psql):

DELETE FROM awl_db_revision;
SELECT new_db_revision(1,2,4, 'Avril' );


I'm afraid that version was released a long time ago now... The current
version of DAViCal is 0.9.9, and I expect to release 0.9.9.1 Real Soon
Now.

It's great that it's been 'Just Working' for you though :-)

Cheers,
Andrew.

--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Beware the one behind you.
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20100624/65b02420/attachment.pgp>
-------------- next part --------------

On 24/06/10 12:54, Andrew McMillan wrote:
>
>> I get in response:
>>
>> The database is currently at revision 1.2.3.
>> Applying patch 1.2.4.sql ... failed!
>> psql:/usr/share/davical/dba/patches/1.2.4.sql:10: ERROR: column
>> "completed" of relation "calendar_item" already exists
>> psql:/usr/share/davical/dba/patches/1.2.4.sql:12: ERROR: current
>> transaction is aborted, commands ignored until end of transaction
>> block
>> there is no transaction in progress
>> ==> No further patches will be attempted!
>> No patches were applied.
>> Supported locales updated.
>> CalDAV functions updated.
>> RRULE functions updated.
>> WARNING: no privileges were granted for "dav_id_seq"
>> Database permissions updated.
>>
>> Does anyone have any info as to what will help to rectify this?
>>
> Hi Jesse,
>
> Given that is the *only* change in that database patch, it seems your DB
> must be at version 1.2.4 already.
>
>
> http://repo.or.cz/w/davical.git/blob/HEAD:/dba/patches/1.2.4.sql
>
> So you could manually tell the database that it is actually version
> 1.2.4, by the following (in psql):
>
> DELETE FROM awl_db_revision;
> SELECT new_db_revision(1,2,4, 'Avril' );
>
I'm sorry Andrew I'm not versed in interacting with Postgresql at all so
are you able to give me a step by step at all here? I attempted this as
root and of course I'm told database "root" does not exist - trying as
user postgres only asks for a password which I don't recall setting...

>
> I'm afraid that version was released a long time ago now... The current
> version of DAViCal is 0.9.9, and I expect to release 0.9.9.1 Real Soon
> Now.
>
Ah yes I see what I've done here - this installation was quite some time
ago so in my /etc/apt/sources.list I was using:
deb http://debian.mcmillan.net.nz/debian unstable awm

I've now rectified and upgraded to the latest but still the same error
so your assumption about it already being upgraded to the next level
database must be correct and I'll need to do the above..
> It's great that it's been 'Just Working' for you though :-)
>
>
I use DAViCal on several sites combined with LDAP for authentication and
enjoy it - now that Roundcube has an addon for caldav calendars I really
don't see any other choice than this great software.
> Cheers,
> Andrew.
>
Jesse

> Hi Jesse,
>
> Given that is the *only* change in that database patch, it seems your DB
> must be at version 1.2.4 already.
>
>
> http://repo.or.cz/w/davical.git/blob/HEAD:/dba/patches/1.2.4.sql
>
> So you could manually tell the database that it is actually version
> 1.2.4, by the following (in psql):
>
> DELETE FROM awl_db_revision;
> SELECT new_db_revision(1,2,4, 'Avril' );
>
> Cheers,
> Andrew.
>
>
OK sorry figured it out and successfully ran those commands and then
attempted the upgrade again. Here is what I got:

otto:/usr/share/davical/dba# ./update-davical-database
The database is version 8.3 currently at revision 1.2.4.
Applying patch 1.2.5.sql ... succeeded.
Applying patch 1.2.6.sql ... succeeded.
Applying patch 1.2.7.sql ... succeeded.
Applying patch 1.2.8.sql ... succeeded.
Successfully applied 4 patches.
Supported locales updated.
Updated view: dav_principal.sql applied.
CalDAV functions updated.
RRULE functions updated.
WARNING: no privileges were granted for "dav_id_seq"
Database permissions updated.

Which seemed positive but I still have no luck with access to my server
from lightning. In the Apache2 logs I have this scattered throughout:

[Thu Jun 24 17:39:26 2010] [error] [client 192.168.20.1] davical: LOG:
DAVResource: Query: QF: SELECT collection.*,
path_privs(:session_principal::int8,
collection.dav_name,:scan_depth::int), p.principal_id, p.type_id AS
principal_type_id, p.displayname AS principal_displayname,
p.default_privileges AS principal_default_privileges, t
[Thu Jun 24 17:39:26 2010] [error] [client 192.168.20.1] davical: LOG:
DAVResource: Query: QF: ime_zone.tz_spec FROM collection LEFT JOIN
principal p USING (user_no) LEFT JOIN time_zone ON
(collection.timezone=time_zone.tz_id) WHERE collection.dav_name =
:raw_path ORDER BY LENGTH(collection.dav_name) DESC LIMIT 1
[Thu Jun 24 17:39:26 2010] [error] [client 192.168.20.1] davical: LOG:
DAVResource: Query: QF: ":raw_path" => "/"
[Thu Jun 24 17:39:26 2010] [error] [client 192.168.20.1] davical: LOG:
always: Query: Error: QF in '/usr/share/davical/htdocs/always.php' on
line 219
[Thu Jun 24 17:39:26 2010] [error] [client 192.168.20.1] davical: LOG:
DAVResource: Query: QF: ":session_principal" => ""
[Thu Jun 24 17:39:26 2010] [error] [client 192.168.20.1] davical: LOG:
always: Query: QF: SQL error "42501" - ERROR: permission denied for
relation principal"
[Thu Jun 24 17:39:26 2010] [error] [client 192.168.20.1] davical: LOG:
DAVResource: Query: QF: ":scan_depth" => "2"
[Thu Jun 24 17:39:26 2010] [error] [client 192.168.20.1] davical: LOG:
always: Query: Error: QF in '/usr/share/davical/htdocs/always.php' on
line 219
[Thu Jun 24 17:39:26 2010] [error] [client 192.168.20.1] davical: LOG:
always: Query: QF: SELECT *, to_char(updated at time zone 'GMT','Dy, DD
Mon IYYY HH24:MI:SS "GMT"') AS modified, principal.*, 0::BIT(24) AS
privileges FROM usr LEFT JOIN principal USING(user_no) WHERE
lower(username) = lower(:param)
[Thu Jun 24 17:39:26 2010] [error] [client 192.168.20.1] davical: LOG:
always: Query: QF: ":param" => "accashared"
[Thu Jun 24 17:39:26 2010] [error] [client 192.168.20.1] davical: LOG:
DAVResource: Query: QF: SQL error "42501" - ERROR: permission denied for
relation principal"
[Thu Jun 24 17:39:26 2010] [error] [client 192.168.20.1] davical: LOG:
DAVResource: Query: QF: SELECT collection.*,
path_privs(:session_principal::int8,
collection.dav_name,:scan_depth::int), p.principal_id, p.type_id AS
principal_type_id, p.displayname AS principal_displayname,
p.default_privileges AS principal_default_privileges, t
[Thu Jun 24 17:39:26 2010] [error] [client 192.168.20.1] davical: LOG:
DAVResource: Query: QF: ime_zone.tz_spec FROM collection LEFT JOIN
principal p USING (user_no) LEFT JOIN time_zone ON
(collection.timezone=time_zone.tz_id) WHERE collection.dav_name =
:raw_path ORDER BY LENGTH(collection.dav_name) DESC LIMIT 1
[Thu Jun 24 17:39:26 2010] [error] [client 192.168.20.1] davical: LOG:
DAVResource: Query: QF: ":raw_path" => "/"
[Thu Jun 24 17:39:26 2010] [error] [client 192.168.20.1] davical: LOG:
DAVResource: Query: QF: ":session_principal" => ""
[Thu Jun 24 17:39:26 2010] [error] [client 192.168.20.1] davical: LOG:
DAVResource: Query: QF: ":scan_depth" => "2"

And I can no longer login as admin!

Is this a problem perhaps with my config file not being compatible
anymore? I'm authorising against an LDAP database - perhaps my admin
user can no longer authenticate as they're not in the LDAP database?

Jesse

> OK sorry figured it out and successfully ran those commands and then
> attempted the upgrade again. Here is what I got:
>
> otto:/usr/share/davical/dba# ./update-davical-database
> The database is version 8.3 currently at revision 1.2.4.
> Applying patch 1.2.5.sql ... succeeded.
> Applying patch 1.2.6.sql ... succeeded.
> Applying patch 1.2.7.sql ... succeeded.
> Applying patch 1.2.8.sql ... succeeded.
> Successfully applied 4 patches.
> Supported locales updated.
> Updated view: dav_principal.sql applied.
> CalDAV functions updated.
> RRULE functions updated.
> WARNING: no privileges were granted for "dav_id_seq"
> Database permissions updated.
>
> Which seemed positive but I still have no luck with access to my server
> from lightning. In the Apache2 logs I have this scattered throughout:
>
> [Thu Jun 24 17:39:26 2010] [error] [client 192.168.20.1] davical: LOG:
> DAVResource: Query: QF: SELECT collection.*,
> path_privs(:session_principal::int8,
> collection.dav_name,:scan_depth::int), p.principal_id, p.type_id AS
> principal_type_id, p.displayname AS principal_displayname,
> p.default_privileges AS principal_default_privileges, t
> [Thu Jun 24 17:39:26 2010] [error] [client 192.168.20.1] davical: LOG:
> DAVResource: Query: QF: ime_zone.tz_spec FROM collection LEFT JOIN
> principal p USING (user_no) LEFT JOIN time_zone ON
> (collection.timezone=time_zone.tz_id) WHERE collection.dav_name =
> :raw_path ORDER BY LENGTH(collection.dav_name) DESC LIMIT 1
> [Thu Jun 24 17:39:26 2010] [error] [client 192.168.20.1] davical: LOG:
> DAVResource: Query: QF: ":raw_path" => "/"
> [Thu Jun 24 17:39:26 2010] [error] [client 192.168.20.1] davical: LOG:
> always: Query: Error: QF in '/usr/share/davical/htdocs/always.php' on
> line 219
> [Thu Jun 24 17:39:26 2010] [error] [client 192.168.20.1] davical: LOG:
> DAVResource: Query: QF: ":session_principal" => ""
> [Thu Jun 24 17:39:26 2010] [error] [client 192.168.20.1] davical: LOG:
> always: Query: QF: SQL error "42501" - ERROR: permission denied for
> relation principal"
> [Thu Jun 24 17:39:26 2010] [error] [client 192.168.20.1] davical: LOG:
> DAVResource: Query: QF: ":scan_depth" => "2"
> [Thu Jun 24 17:39:26 2010] [error] [client 192.168.20.1] davical: LOG:
> always: Query: Error: QF in '/usr/share/davical/htdocs/always.php' on
> line 219
> [Thu Jun 24 17:39:26 2010] [error] [client 192.168.20.1] davical: LOG:
> always: Query: QF: SELECT *, to_char(updated at time zone 'GMT','Dy, DD
> Mon IYYY HH24:MI:SS "GMT"') AS modified, principal.*, 0::BIT(24) AS
> privileges FROM usr LEFT JOIN principal USING(user_no) WHERE
> lower(username) = lower(:param)
> [Thu Jun 24 17:39:26 2010] [error] [client 192.168.20.1] davical: LOG:
> always: Query: QF: ":param" => "accashared"
> [Thu Jun 24 17:39:26 2010] [error] [client 192.168.20.1] davical: LOG:
> DAVResource: Query: QF: SQL error "42501" - ERROR: permission denied for
> relation principal"
> [Thu Jun 24 17:39:26 2010] [error] [client 192.168.20.1] davical: LOG:
> DAVResource: Query: QF: SELECT collection.*,
> path_privs(:session_principal::int8,
> collection.dav_name,:scan_depth::int), p.principal_id, p.type_id AS
> principal_type_id, p.displayname AS principal_displayname,
> p.default_privileges AS principal_default_privileges, t
> [Thu Jun 24 17:39:26 2010] [error] [client 192.168.20.1] davical: LOG:
> DAVResource: Query: QF: ime_zone.tz_spec FROM collection LEFT JOIN
> principal p USING (user_no) LEFT JOIN time_zone ON
> (collection.timezone=time_zone.tz_id) WHERE collection.dav_name =
> :raw_path ORDER BY LENGTH(collection.dav_name) DESC LIMIT 1
> [Thu Jun 24 17:39:26 2010] [error] [client 192.168.20.1] davical: LOG:
> DAVResource: Query: QF: ":raw_path" => "/"
> [Thu Jun 24 17:39:26 2010] [error] [client 192.168.20.1] davical: LOG:
> DAVResource: Query: QF: ":session_principal" => ""
> [Thu Jun 24 17:39:26 2010] [error] [client 192.168.20.1] davical: LOG:
> DAVResource: Query: QF: ":scan_depth" => "2"
>
> And I can no longer login as admin!
>
> Is this a problem perhaps with my config file not being compatible
> anymore? I'm authorising against an LDAP database - perhaps my admin
> user can no longer authenticate as they're not in the LDAP database?
>
> Jesse
>
>
Ok more troubleshooting here - it's turning into a step by step it seems
- It seemed I had some oddities in my postgres setup which was denying
access to these tables etc. Very strange it wouldn't show itself until
now though...

I'm now able to login as admin and see the users as expected and
relationships still exist. What I don't see though is any events in my
Lightning. I've checked the error console and have found the following:

===============================================
Warning: There has been an error reading data for calendar: Cake
Shared. However, this error is believed to be minor, so the program
will attempt to continue. Error code: 0x80004005. Description: CalDAV:
Failed to parse getCalendarData REPORT for calendar Cake Shared

Warning: There has been an error reading data for calendar: Cake
Shared. However, this error is believed to be minor, so the program
will attempt to continue. Error code: READ_FAILED. Description:
===============================================


This "Cake Shared" calendar was a user created as a resource to use for
other users. I have also tried getting access to my personal calendar
resource (my username) and even though I don't get the error that the
Cake Shared resource does I'm not able to see any events or post any new
events.

If I type the full address of these resources into a browser and
authenticate as myself I'm presented with an ICS file it seems full of
events in the body so it appears it's all still there but I'm just not
able to use the resource...

There isn't anything appearing in the apache2 error log either

Any hints? Is there a debugging switch anywhere to see more?

Jesse

On Thu, 2010-06-24 at 17:42 +1000, jesse at cake wrote:
> > Hi Jesse,
> >
> > Given that is the *only* change in that database patch, it seems your DB
> > must be at version 1.2.4 already.
> >
> >
> > http://repo.or.cz/w/davical.git/blob/HEAD:/dba/patches/1.2.4.sql
> >
> > So you could manually tell the database that it is actually version
> > 1.2.4, by the following (in psql):
> >
> > DELETE FROM awl_db_revision;
> > SELECT new_db_revision(1,2,4, 'Avril' );
> >
> > Cheers,
> > Andrew.
> >
> >
> OK sorry figured it out and successfully ran those commands and then
> attempted the upgrade again. Here is what I got:
>
> otto:/usr/share/davical/dba# ./update-davical-database
> The database is version 8.3 currently at revision 1.2.4.
> Applying patch 1.2.5.sql ... succeeded.
> Applying patch 1.2.6.sql ... succeeded.
> Applying patch 1.2.7.sql ... succeeded.
> Applying patch 1.2.8.sql ... succeeded.
> Successfully applied 4 patches.
> Supported locales updated.
> Updated view: dav_principal.sql applied.
> CalDAV functions updated.
> RRULE functions updated.
> WARNING: no privileges were granted for "dav_id_seq"
> Database permissions updated.

Good...


> Which seemed positive but I still have no luck with access to my server
> from lightning. In the Apache2 logs I have this scattered throughout:
> ...
> [Thu Jun 24 17:39:26 2010] [error] [client 192.168.20.1] davical: LOG:
> DAVResource: Query: QF: SQL error "42501" - ERROR: permission denied for
> relation principal"
...


> And I can no longer login as admin!
>
> Is this a problem perhaps with my config file not being compatible
> anymore? I'm authorising against an LDAP database - perhaps my admin
> user can no longer authenticate as they're not in the LDAP database?

I think most likely this is a problem along the lines of what is
described here:

http://wiki.davical.org/w/Issues/Wrong_table_owner

If you were running a very old DAViCal version it's possible that the DB
user 'general' was being used, rather than 'davical_app' for connecting
to the database.

Regards,
Andrew McMillan.
--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Flexibility is overrated. Constraints are liberating.
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20100624/f428e475/attachment.pgp>
-------------- next part --------------

>> OK sorry figured it out and successfully ran those commands and then
>> attempted the upgrade again. Here is what I got:
>>
>> otto:/usr/share/davical/dba# ./update-davical-database
>> The database is version 8.3 currently at revision 1.2.4.
>> Applying patch 1.2.5.sql ... succeeded.
>> Applying patch 1.2.6.sql ... succeeded.
>> Applying patch 1.2.7.sql ... succeeded.
>> Applying patch 1.2.8.sql ... succeeded.
>> Successfully applied 4 patches.
>> Supported locales updated.
>> Updated view: dav_principal.sql applied.
>> CalDAV functions updated.
>> RRULE functions updated.
>> WARNING: no privileges were granted for "dav_id_seq"
>> Database permissions updated.
>>
> Good...
>
>
>
> I think most likely this is a problem along the lines of what is
> described here:
>
> http://wiki.davical.org/w/Issues/Wrong_table_owner
>
> If you were running a very old DAViCal version it's possible that the DB
> user 'general' was being used, rather than 'davical_app' for connecting
> to the database.
>
> Regards,
>
> Andrew McMillan.
>

Hi Andrew

I followed through with the link you included above and was able to
verify that all the tables were owned by davical_dba other than:

public | dav_id_seq | sequence | postgres

Is this a problem? It appears to be owned by the postgres admin.

Also my installation was using the 'general' user but this hasn't shown
up in the table structure. I ran the upgrade script again as recommended
there also but there was no change in ownership for "dav_id_seq" in
postgresql.

My client is still as before.

Any other suggestions?

Jesse

On Thu, 2010-06-24 at 19:49 +1000, jesse at cake wrote:
>
> Hi Andrew
>
> I followed through with the link you included above and was able to
> verify that all the tables were owned by davical_dba other than:
>
> public | dav_id_seq | sequence | postgres
>
> Is this a problem? It appears to be owned by the postgres admin.

Probably it isn't a problem.


> Also my installation was using the 'general' user but this hasn't shown

The rationale behind having the table owner not being the user accessing
the tables from the web application is a security one. The
update-davical-database script sets up a minimum set of privileges
against the tables for the application user. By default this is a user
called 'davical_app', and if that's the user being granted the
permissions in your case then that's the user that you should change to
in your connection string. You will probably also need to
s/general/davical_app/ in your PostgreSQL 'pg_hba.conf' file, which
controls the users allowed to connect to the databases.


> up in the table structure. I ran the upgrade script again as recommended
> there also but there was no change in ownership for "dav_id_seq" in
> postgresql.

It should really be owned by davical_dba, but it's not going to affect
anything so long as the davical_app user can read it and increment it.

Cheers,
Andrew.

--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
You may get an opportunity for advancement today. Watch it!
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20100624/f43cb64d/attachment.pgp>
-------------- next part --------------

On 24/06/10 20:09, Andrew McMillan wrote:
>
>> Also my installation was using the 'general' user but this hasn't shown
>>
> The rationale behind having the table owner not being the user accessing
> the tables from the web application is a security one. The
> update-davical-database script sets up a minimum set of privileges
> against the tables for the application user. By default this is a user
> called 'davical_app', and if that's the user being granted the
> permissions in your case then that's the user that you should change to
> in your connection string. You will probably also need to
> s/general/davical_app/ in your PostgreSQL 'pg_hba.conf' file, which
> controls the users allowed to connect to the databases.
>
>
>
Great no problem - updated these things so they're in order now -
davical interface now using davical_app user to access database and
pg_hba.conf now trusts access to the davical table by users davical_app
and davical_dba.
>> up in the table structure. I ran the upgrade script again as recommended
>> there also but there was no change in ownership for "dav_id_seq" in
>> postgresql.
>>
> It should really be owned by davical_dba, but it's not going to affect
> anything so long as the davical_app user can read it and increment it.
>
> Cheers,
> Andrew.
>
Unfortunately I'm still unable to connect the client to the DAViCal
server - nothing changed on the client end - it's been the same since
before the problems began.

I'm also still able to download an .ics.part file from the server by
entering the calendar details into Firefox so it appears the
collections/resources are there - I just can't seem to get to them using
Lightning now for some reason. Error report below again:

==================================
Warning: There has been an error reading data for calendar: Cake
Shared. However, this error is believed to be minor, so the program
will attempt to continue. Error code: 0x80004005. Description: CalDAV:
Failed to parse getCalendarData REPORT for calendar Cake Shared

Warning: There has been an error reading data for calendar: Cake
Shared. However, this error is believed to be minor, so the program
will attempt to continue. Error code: READ_FAILED. Description:
==================================

Jesse

On Thu, 2010-06-24 at 20:19 +1000, jesse at cake wrote:

> Unfortunately I'm still unable to connect the client to the DAViCal
> server - nothing changed on the client end - it's been the same since
> before the problems began.
>
> I'm also still able to download an .ics.part file from the server by
> entering the calendar details into Firefox so it appears the
> collections/resources are there - I just can't seem to get to them using
> Lightning now for some reason. Error report below again:
>
> ==================================
> Warning: There has been an error reading data for calendar: Cake
> Shared. However, this error is believed to be minor, so the program
> will attempt to continue. Error code: 0x80004005. Description: CalDAV:
> Failed to parse getCalendarData REPORT for calendar Cake Shared
>
> Warning: There has been an error reading data for calendar: Cake
> Shared. However, this error is believed to be minor, so the program
> will attempt to continue. Error code: READ_FAILED. Description:
> ==================================

Well, it seems that you must be close now :-)

From the message it sounds like perhaps you now have an error in your
configuration file. Perhaps you have a php closing tag like ?> in there
with some whitespace after it?

Have you tried removing the calendar from Lightning and adding it back?

If possible you could enable debugging in Lightning (there's some
details in the wiki) or sniff the communication with something like
Wireshark, looking for any uninitialised variable warnings, and things
like that.

Is it possible that when you originally set things up you copied the AWL
include files into the DAViCal include directory? This is something I
have heard of people doing, and it will break stuff very effectively!

Also, make sure you have all debugging off, and that you have PHP set to
not display NOTICEs:

error_reporting = E_ALL & ~E_NOTICE

in your php.ini.

Cheers,
Andrew.
--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Necessity is the mother of documentation
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20100624/c23837e3/attachment.pgp>
-------------- next part --------------

On 24/06/10 21:00, Andrew McMillan wrote:
> On Thu, 2010-06-24 at 20:19 +1000, jesse at cake wrote:
>
>
>> Unfortunately I'm still unable to connect the client to the DAViCal
>> server - nothing changed on the client end - it's been the same since
>> before the problems began.
>>
>>
> Well, it seems that you must be close now :-)
>
> From the message it sounds like perhaps you now have an error in your
> configuration file. Perhaps you have a php closing tag like ?> in there
> with some whitespace after it?
>

Hmm I'm running through it - there doesn't appear to be anything in
there - in fact nothing had changed until I went looking so it there had
been I would assume the previous installation would have also been broken?

> Have you tried removing the calendar from Lightning and adding it back?
>
>
Yep - still nothing - same behaviour
> If possible you could enable debugging in Lightning (there's some
> details in the wiki) or sniff the communication with something like
> Wireshark, looking for any uninitialised variable warnings, and things
> like that.
>
Yep just enabled debugging in Lightning and here is something
interesting (there are miles of logs to run through!):

==========================
CalDAV: recv:
<multistatus>
<response>
<href>/caldav.php/jesse/home/</href>
<propstat>
<prop>
<getcontenttype>httpd/unix-directory</getcontenttype>
<resourcetype>
<collection></collection>
<C:calendar></C:calendar>
</resourcetype>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
<propstat>
<prop>
<getetag></getetag>
</prop>
<status>HTTP/1.1 404 Not Found</status>
</propstat>
</response>
</multistatus>
============================

But further below this I also see a bunch of what looks like ical syntax
with the contents of heaps of the items that are in the calendar
resources. And then there is this:

============================
CalDAV: Status 207 fetching calendar-data for calendar Cake Shared
CalDAV: Failed to parse getCalendarData REPORT for calendar Cake Shared
============================
and:
============================
CalDAV: Status 207 checking ctag for calendar ACCA Shared
CalDAV: ctag matches, no need to fetch data for calendar ACCA Shared
============================
CalDAV: Status 207 fetching calendar-data for calendar Cake Shared
CalDAV: Failed to parse getCalendarData REPORT for calendar Cake Shared
============================

And these things loop due to the calendars trying to auto-refresh.

So it appears that it is working a point but there is something small
failing which is causing it to ditch the calendar all together.


> Is it possible that when you originally set things up you copied the AWL
> include files into the DAViCal include directory? This is something I
> have heard of people doing, and it will break stuff very effectively!
>
I've always followed strict Debian packaging and hate doing hacky things
like that as upgrades always break so it won't be this.
> Also, make sure you have all debugging off, and that you have PHP set to
> not display NOTICEs:
>
> error_reporting = E_ALL& ~E_NOTICE
>
> in your php.ini.
>

Yep this all checks out (Debian standard?).
> Cheers,
> Andrew.
>
Thanks for the assistance Andrew - happened to happen at a time when I'm
desperately clinging to my calendar! For reference also we've been using
Thunderbird 3 since installation of Ubuntu 10.04 LTS on our workstations
on the day of launch with Lightning 1.0b since day one and all of us
have the same issues.

Thanks

Jesse

> Thanks for the assistance Andrew - happened to happen at a time when I'm
> desperately clinging to my calendar! For reference also we've been using
> Thunderbird 3 since installation of Ubuntu 10.04 LTS on our workstations
> on the day of launch with Lightning 1.0b since day one and all of us
> have the same issues.
>
> Thanks
>
> Jesse
>
>
> ---------------------------------------------------------------
>

HOLD THE PRESS!

Ack... on top of everything else I had also whilst troubleshooting
turned on gnome's proxy settings so I probably had already resolved the
issues I was facing earlier on, but then compounded my problems by
switching on global proxying - as the proxy lives on the target server
I'm sure it was blocking things... grrr

Apologies list for the stupidity - at least I ended up cleaning up our
aging installation!

Jesse

Realising you've solved this now by fixing the proxying issue, but for
the record...

On Thu, 2010-06-24 at 21:35 +1000, jesse at cake wrote:

> >
> Yep just enabled debugging in Lightning and here is something
> interesting (there are miles of logs to run through!):
>
> ==========================
> CalDAV: recv:
> <multistatus>
> <response>
> <href>/caldav.php/jesse/home/</href>
> <propstat>
> <prop>
> <getcontenttype>httpd/unix-directory</getcontenttype>
> <resourcetype>
> <collection></collection>
> <C:calendar></C:calendar>
> </resourcetype>
> </prop>
> <status>HTTP/1.1 200 OK</status>
> </propstat>
> <propstat>
> <prop>
> <getetag></getetag>
> </prop>
> <status>HTTP/1.1 404 Not Found</status>
> </propstat>
> </response>
> </multistatus>
> ============================

This is normal. The 404 that you see is because the 'getetag' property
is not defined on collections.


> But further below this I also see a bunch of what looks like ical syntax
> with the contents of heaps of the items that are in the calendar
> resources. And then there is this:
>
> ============================
> CalDAV: Status 207 fetching calendar-data for calendar Cake Shared
> CalDAV: Failed to parse getCalendarData REPORT for calendar Cake Shared
> ============================

Right, so the problem was here. It seems likely that your proxy was not
forwarding the REPORT request or response correctly. The HTTP REPORT
method is a wee bit unusual and some proxies don't deal with it well, or
simply default to not forwarding it.



> > Is it possible that when you originally set things up you copied the AWL
> > include files into the DAViCal include directory? This is something I
> > have heard of people doing, and it will break stuff very effectively!
> >
> I've always followed strict Debian packaging and hate doing hacky things
> like that as upgrades always break so it won't be this.

Yay! :-)


> > Also, make sure you have all debugging off, and that you have PHP set to
> > not display NOTICEs:
> >
> > error_reporting = E_ALL& ~E_NOTICE
> >
> > in your php.ini.
> >
>
> Yep this all checks out (Debian standard?).

Indeed.


> Thanks for the assistance Andrew - happened to happen at a time when I'm
> desperately clinging to my calendar! For reference also we've been using
> Thunderbird 3 since installation of Ubuntu 10.04 LTS on our workstations
> on the day of launch with Lightning 1.0b since day one and all of us
> have the same issues.

Ouch. Oh well, working now.

Cheers,
Andrew.

--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Q: What is orange and goes "click, click?"
A: A ball point carrot.

------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20100625/f4df4195/attachment.pgp>
-------------- next part --------------