Mailing List Archive

Hi - I believe I may have introduced some db inconsistencies into my cPanel
hosted DAViCal server when I upgraded to 0.9.9. Because my hosts don't have
all the perl dependencies, I can't run update-davical-database so I have to
hand-crank the steps using the Postgres UI. This leads to the possibility of
me introducing errors.


Issue 1
======
In the admin UI, I am attempting to delete a principal I created prior to
upgrade. I am getting a diagnostic back "There was an error writing to the
database" after I confirmed the delete. Any chance you could give me an idea
where to start looking in the code?


Issue 2
======
I am using the interactive Perl command line utility dave locally. I can
connect to my hosted DAViCal server ok, do stuff like create collection, ls,
get. However, if I try to 'put' or 'delete' I get a 403 Forbidden. I should
note that I have a local DAViCal server with the same principals and
collections and on that I can 'put' and 'delete'. Again, any ideas where the
best place to start looking is?

Many thanks

On Thu, 2010-07-15 at 12:18 +0100, Nigel wrote:
> Hi - I believe I may have introduced some db inconsistencies into my cPanel
> hosted DAViCal server when I upgraded to 0.9.9. Because my hosts don't have
> all the perl dependencies, I can't run update-davical-database so I have to
> hand-crank the steps using the Postgres UI. This leads to the possibility of
> me introducing errors.

Hi Nigel,

Yeah, I can believe it. I want to reimplement a bunch of this stuff in
PHP, partly for this reason, but that work only creaks along very slowly
due to other, more fun, priorities like adding CardDAV support... :-)

In the meantime perhaps a better approach would be to dump the database,
reload it on another machine where you do have more access, do the
upgrade, dump that, and then restore that on the server.

Possibly there are other problems with that approach, however due to
data volume or rate of change.


> Issue 1
> ======
> In the admin UI, I am attempting to delete a principal I created prior to
> upgrade. I am getting a diagnostic back "There was an error writing to the
> database" after I confirmed the delete. Any chance you could give me an idea
> where to start looking in the code?

Very likely the database permissions are wrong. The database update
script tries to apply a minimum level of permissions to the database for
the DB user which the application connects as.

In your case I would set the web application to connect to the database
as the DB owner - normally 'davical_dba', but in your situation it could
be anything, I guess.


> Issue 2
> ======
> I am using the interactive Perl command line utility dave locally. I can
> connect to my hosted DAViCal server ok, do stuff like create collection, ls,
> get. However, if I try to 'put' or 'delete' I get a 403 Forbidden. I should
> note that I have a local DAViCal server with the same principals and
> collections and on that I can 'put' and 'delete'. Again, any ideas where the
> best place to start looking is?

DAViCal uses the hostname it is being accessed as to work out the name
of the configuration file. Possibly there is no symlink there for the
name (or IP) you're using locally, in this case. You can also
use /etc/davical/config.php as the name of the configuration file, since
DAViCal will always fall back to using this name if it didn't find a
hostname-based config file.

Cheers,
Andrew.
--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
You possess a mind not merely twisted, but actually sprained.
------------------------------------------------------------------------

-------------- 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/20100715/4c8ba5c7/attachment.pgp>
-------------- next part --------------

Hi Andrew,

Am 16.07.10 05:29, schrieb Andrew McMillan:

> Yeah, I can believe it. I want to reimplement a bunch of this stuff in
> PHP, partly for this reason, but that work only creaks along very slowly
> due to other, more fun, priorities like adding CardDAV support... :-)

BTW. Did you made any progress in getting CardDAV going? I am still
stuck with not being able to store addressbook entries and seeing them
after readding the account in iAddressbook? The same applies for the iOS
version of iAddressbook. There I am also able to add the account, but I
can't see the different clients syncing their entries.

And unfortunately my knowledge of all these DAV protocols is too low and
debugging DAViCal to complicated to help you :(

regards,
jens
--
Jens Langner, Dresden/Germany
http://www.jens-langner.de/

On 16 Jul 2010, at 2:15 AM, Jens Langner wrote:

> BTW. Did you made any progress in getting CardDAV going? I am still
> stuck with not being able to store addressbook entries and seeing them
> after readding the account in iAddressbook? The same applies for the iOS
> version of iAddressbook. There I am also able to add the account, but I
> can't see the different clients syncing their entries.
>
> And unfortunately my knowledge of all these DAV protocols is too low and
> debugging DAViCal to complicated to help you :(

I'm curious as to how you were able to configure your Apple address book and iPhone address book to see your server. When I try, I get a server error, and the box to enter the path to the address book is not available.

Dan

On Fri, 2010-07-16 at 11:15 +0200, Jens Langner wrote:
> Hi Andrew,
>
> Am 16.07.10 05:29, schrieb Andrew McMillan:
>
> > Yeah, I can believe it. I want to reimplement a bunch of this stuff in
> > PHP, partly for this reason, but that work only creaks along very slowly
> > due to other, more fun, priorities like adding CardDAV support... :-)
>
> BTW. Did you made any progress in getting CardDAV going? I am still
> stuck with not being able to store addressbook entries and seeing them
> after readding the account in iAddressbook? The same applies for the iOS
> version of iAddressbook. There I am also able to add the account, but I
> can't see the different clients syncing their entries.

I'll try to continue my work after next week, but at the moment I am on
holiday with the family and it is really difficult to combine these
efforts :-)

Probably I won't fully be able to continue until I get home in the
middle of August.

Cheers,
Andrew.

--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
You will be awarded some great honor.
------------------------------------------------------------------------

-------------- 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/20100716/727a6a18/attachment.pgp>
-------------- next part --------------

On Friday 16 Jul 2010 04:29:03 Andrew McMillan wrote:
> On Thu, 2010-07-15 at 12:18 +0100, Nigel wrote:
> > Hi - I believe I may have introduced some db inconsistencies into my
> > cPanel hosted DAViCal server when I upgraded to 0.9.9. Because my hosts
> > don't have all the perl dependencies, I can't run update-davical-database
> > so I have to hand-crank the steps using the Postgres UI. This leads to
> > the possibility of me introducing errors.
>
> Hi Nigel,
>
> Yeah, I can believe it. I want to reimplement a bunch of this stuff in
> PHP, partly for this reason, but that work only creaks along very slowly
> due to other, more fun, priorities like adding CardDAV support... :-)
>
> In the meantime perhaps a better approach would be to dump the database,
> reload it on another machine where you do have more access, do the
> upgrade, dump that, and then restore that on the server.
>
> Possibly there are other problems with that approach, however due to
> data volume or rate of change.
>
> > Issue 1
> > ======
> > In the admin UI, I am attempting to delete a principal I created prior to
> > upgrade. I am getting a diagnostic back "There was an error writing to
> > the database" after I confirmed the delete. Any chance you could give me
> > an idea where to start looking in the code?
>
> Very likely the database permissions are wrong. The database update
> script tries to apply a minimum level of permissions to the database for
> the DB user which the application connects as.
>
> In your case I would set the web application to connect to the database
> as the DB owner - normally 'davical_dba', but in your situation it could
> be anything, I guess.
>

I took the easy way out since my server isn't live yet and dropped the db and
reinstalled.


> > Issue 2
> > ======
> > I am using the interactive Perl command line utility dave locally. I can
> > connect to my hosted DAViCal server ok, do stuff like create collection,
> > ls, get. However, if I try to 'put' or 'delete' I get a 403 Forbidden. I
> > should note that I have a local DAViCal server with the same principals
> > and collections and on that I can 'put' and 'delete'. Again, any ideas
> > where the best place to start looking is?
>
> DAViCal uses the hostname it is being accessed as to work out the name
> of the configuration file. Possibly there is no symlink there for the
> name (or IP) you're using locally, in this case. You can also
> use /etc/davical/config.php as the name of the configuration file, since
> DAViCal will always fall back to using this name if it didn't find a
> hostname-based config file.
>
> Cheers,
> Andrew.


After a couple of days head-scratching I got to the bottom of this. It is
apparently normal practice on hosts for them to outlaw the http PUT and DELETE
methods. Thankfully my host allows an override with .htaccess so this needs
adding:
<Limit PUT DELETE>
Order Allow,Deny
Allow from All
</Limit>
obviously I could nail-down the Allow a little bit more for greater security.

It may be worthwhile this being mentioned in the documentation somewhere to
prevent someone else losing a couple of days of their life! I have updated my
Badzilla how-to-host-DAViCal blog also to accommodate this change at
http://tinyurl.com/34bp6xh

Cheers
Nigel


>

--

Friends of Badzilla
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20100718/bacd8250/attachment.htm>
-------------- next part --------------

On Sun, 2010-07-18 at 19:19 +0100, Nigel wrote:
>
> After a couple of days head-scratching I got to the bottom of this. It
> is apparently normal practice on hosts for them to outlaw the http PUT
> and DELETE methods. Thankfully my host allows an override
> with .htaccess so this needs adding:
>
> <Limit PUT DELETE>
>
> Order Allow,Deny
>
> Allow from All
>
> </Limit>
>
> obviously I could nail-down the Allow a little bit more for greater
> security.
>
> It may be worthwhile this being mentioned in the documentation
> somewhere to prevent someone else losing a couple of days of their
> life! I have updated my Badzilla how-to-host-DAViCal blog also to
> accommodate this change at
>
> http://tinyurl.com/34bp6xh

Yeah, very interesting. I've not come across PUT/DELETE being limited
before now, but some of the more unusual CalDAV methods like MKCALENDAR,
MKCOL, REPORT I have seen blocked by proxies in particular, in the past.

Cheers,
Andrew.

--
------------------------------------------------------------------------
http://andrew.mcmillan.net.nz/ Porirua, New Zealand
Twitter: _karora Phone: +64(272)DEBIAN
Give him an evasive answer.
------------------------------------------------------------------------

-------------- 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/20100718/3d915c1c/attachment.pgp>
-------------- next part --------------