Mailing List Archive: DAViCal: General

Now: postgresql set-up Was: davical on mysql

Index | Next | Previous | View Threaded

simon.loewenthal at tele2

Sep 21, 2011, 5:22 AM

Post #1 of 11 (588 views)
Permalink

Now: postgresql set-up Was: davical on mysql

On 09/21/2011 11:19 AM, Simon Loewenthal/NL/Tele2 wrote:
> On 09/21/2011 10:21 AM, Simon Loewenthal/NL/Tele2 wrote:
>> On 09/21/2011 09:52 AM, Simon Loewenthal/NL/Tele2 wrote:
>>> On 09/21/2011 01:14 AM, Andrew McMillan wrote:
>>>> On Tue, 2011-09-20 at 16:41 +0200, Simon Loewenthal/NL/Tele2 wrote:
>>>>> OK, I shall relent on the mySQL requirement. We did not want to support
>>>>> another sql database :(
>>>>>
>>>>> I installed the debian package davical. The files are under
>>>>> /usr/share/davical.
>>>>> Symbolic links are disallowed in apache configurations. All content is
>>>>> placed in /web/.... (mounted noexec,nosetuid), and all cgi-bin is in
>>>>> another filesystem with exec allowed.
>>>> You don't need exec on the PHP code for DAViCal. It should all be
>>>> owner/group root, mode 644 so the simplest (and recommended) solution is
>>>> just to point the DocumentRoot at /usr/share/davical/htdocs. There is
>>>> no reason why anything should modify those files other than a version
>>>> upgrade. DAViCal does not write data to the filesystem.
>>>>
>>>>
>>>>> Can I simply copy the entire /usr/share/davical into /web/davical/ and
>>>>> run the scripts (e.g dba/create-database.sh) from there?
>>>> You could probably do that also (you'd also need to copy the AWL tree
>>>> similarly), and you probably also want to make sure that nothing in the
>>>> webserver has access to the non-web content of the tree, such as the
>>>> directories containing include files, scripts, etc, etc.
>>>>
>>>> So setting it up securely in that location will take some extra care,
>>>> but it sounds like you're probably paranoid enough to do an OK job.
>>>>
>>>> Cheers,
>>>> Andrew.
>>>>
>>> Hi Andrew,
>>>
>>> Then perhaps this:
>>>
>>> Move /usr/share/davical/htdocs to /web/static/davical/htdocs
>>> Leave the rest of davical where it is in /usr/share/davical
>>>
>>> Which gives
>>> # ls /usr/share/davical/
>>> dba htdocs inc locale
>>>
>>> # ls /www/roundcube/davical/
>>> htdocs
>>>
>>> * vhost
>>> Alias /images/ /web/static/davical/htdocs/images/
>>> <Directory /web/static/davical/davical/htdocs/>
>>> and the php settings etc.,
>>>
>>> I imagine that I would have to modify some of the davical scripts for
>>> this... Did I overlook something?
>>>
>>> Cheers, s
>> I think that this looks ok.
>>
>> # pwd
>> /usr/share/davical
>> # find -exec grep share \{\} \;
>> , '/usr/share/awl/inc' // Where it ends up on Debian
>> , '/usr/share/php/awl/inc' // Fedora's standard for PHP libraries
>> , '/usr/local/share/awl/inc'
>> # # php_value include_path /usr/share/awl/inc
>> , '/usr/share/awl/inc' // Where it ends up on Debian
>> , '/usr/share/php/awl/inc' // Fedora's standard for PHP libraries
>> , '/usr/local/share/awl/inc'
>> AWLDIR="/usr/share/awl"
>> AWLDIR="/usr/local/share/awl"
>> Thanks for trying DAViCal! Check in /usr/share/doc/davical/examples/ for
>> -- RAISE NOTICE 'Permissions to shared group % ', out_confers;
>> -- RAISE NOTICE 'Permissions to shared group';
>> -- RAISE NOTICE 'Permissions to shared group % ', out_confers;
>> -- RAISE NOTICE 'Permissions to shared group % ', out_confers;
>> -- RAISE NOTICE 'Permissions to shared group';
>> -- RAISE NOTICE 'Permissions to shared group % ', out_confers;
>> -- RAISE NOTICE 'Permissions to shared group';
>> # # php_value include_path /usr/share/awl/inc
>> , '/usr/share/awl/inc' // Where it ends up on Debian
>> , '/usr/share/php/awl/inc' // Fedora's standard for PHP libraries
>> , '/usr/local/share/awl/inc'
> or maybe not. The create-database.sh seems to have run well, but I
> suspect that it set something in the htdocs dir, which of course is in
> the wrong place as far as it is concerned, because hitting the htdocs on
> the web server serves a blank page.
>
>
> # su postgres -c ./dba/create-database.sh
>
> Supported locales updated.
> Updated view: dav_principal.sql applied.
> CalDAV functions updated.
> RRULE functions updated.
> Database permissions updated.
> NOTE
> ====
> * You will need to edit the PostgreSQL pg_hba.conf to allow the
> 'davical_dba' database user access to the 'davical' database.
>
> * You will need to edit the PostgreSQL pg_hba.conf to allow the
> 'davical_app' database user access to the 'davical' database.
>
> * The password for the 'admin' user has been set to 'nnnnnnnn'
>
> Thanks for trying DAViCal! Check in /usr/share/doc/davical/examples/ for
> some configuration examples. For help, visit #davical on irc.oftc.net.
>
> So, what I want to achieve, might want a little more tweaking:-
>
> htdocs only in the apache document root.
> The rest in /usr/share/
>
> The current apache vhost is:
> DirectoryIndex index.php index.html
> Alias /images/ /web/static/davical/htdocs/images/
> <Directory /web/static/davical/htdocs/>
> AllowOverride None
> Order allow,deny
> Allow from all
> </Directory>
> AcceptPathInfo On
> php_value include_path /usr/share/awl/inc
> php_value magic_quotes_gpc 0
> php_value register_globals 0
> php_value error_reporting "E_ALL & ~E_NOTICE"
> php_value default_charset "utf-8"
>
>
> ----

This was not going to work (don't know why not) so relented again and
used this in the vhost which gave me the setup page complaining that the
/etc/davical/config.php is missing. No problem, I'll create one! Not so
fast.... :-

The create-database.sh script was run yesterday. After completion I
copied and pasted the admin passwed. Now it s time to use it. I know
the password is correct as its in a file...

# psql -U admin -W
Password for user admin:
psql: FATAL: Ident authentication failed for user "admin"
# psql davical -c 'select username, password from usr;' -U admin
psql: FATAL: Ident authentication failed for user "admin"
# psql davical -c 'select username, password from usr;' -U admin -w
psql: FATAL: Ident authentication failed for user "admin"
# psql davical -c 'select username, password from usr;'
psql: FATAL: Ident authentication failed for user "root"

It won't accept the admin password.

Try again, but this time, contary to what the results of the
create-database.sh wrote I shall try this:
# psql davical -c 'select username, password from usr;' -W -U davical_app
Password for user davical_app: ****** <--- Use the admin password! Eh?
username | password
----------+------------
admin | **nnnnxxxx
(1 row)

i) The user admin does exist.
ii) The user admin has the same password as the user davical_app.
iii) The psql command does not accept the password listed for admin as
valid for the admin user.
Clearly, postgresql's way of doing things differs from my experience
with mysql.
iv) I wonder what those asterisk are for, that prefix the password entry.

Would someone tell me what is going on, and how I can log in as the
admin user?

Cheers, Simon.

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Davical-general mailing list
Davical-general [at] lists
https://lists.sourceforge.net/lists/listinfo/davical-general

simon.loewenthal at tele2

Sep 21, 2011, 5:44 AM

Post #2 of 11 (572 views)
Permalink

Re: Now: postgresql set-up Was: davical on mysql [In reply to]

On 09/21/2011 02:22 PM, Simon Loewenthal/NL/Tele2 wrote:
> On 09/21/2011 11:19 AM, Simon Loewenthal/NL/Tele2 wrote:
>> On 09/21/2011 10:21 AM, Simon Loewenthal/NL/Tele2 wrote:
>>> On 09/21/2011 09:52 AM, Simon Loewenthal/NL/Tele2 wrote:
>>>> On 09/21/2011 01:14 AM, Andrew McMillan wrote:
>>>>> On Tue, 2011-09-20 at 16:41 +0200, Simon Loewenthal/NL/Tele2 wrote:
>>>>>> OK, I shall relent on the mySQL requirement. We did not want to support
>>>>>> another sql database :(
>>>>>>
>>>>>> I installed the debian package davical. The files are under
>>>>>> /usr/share/davical.
>>>>>> Symbolic links are disallowed in apache configurations. All content is
>>>>>> placed in /web/.... (mounted noexec,nosetuid), and all cgi-bin is in
>>>>>> another filesystem with exec allowed.
>>>>> You don't need exec on the PHP code for DAViCal. It should all be
>>>>> owner/group root, mode 644 so the simplest (and recommended) solution is
>>>>> just to point the DocumentRoot at /usr/share/davical/htdocs. There is
>>>>> no reason why anything should modify those files other than a version
>>>>> upgrade. DAViCal does not write data to the filesystem.
>>>>>
>>>>>
>>>>>> Can I simply copy the entire /usr/share/davical into /web/davical/ and
>>>>>> run the scripts (e.g dba/create-database.sh) from there?
>>>>> You could probably do that also (you'd also need to copy the AWL tree
>>>>> similarly), and you probably also want to make sure that nothing in the
>>>>> webserver has access to the non-web content of the tree, such as the
>>>>> directories containing include files, scripts, etc, etc.
>>>>>
>>>>> So setting it up securely in that location will take some extra care,
>>>>> but it sounds like you're probably paranoid enough to do an OK job.
>>>>>
>>>>> Cheers,
>>>>> Andrew.
>>>>>
>>>> Hi Andrew,
>>>>
>>>> Then perhaps this:
>>>>
>>>> Move /usr/share/davical/htdocs to /web/static/davical/htdocs
>>>> Leave the rest of davical where it is in /usr/share/davical
>>>>
>>>> Which gives
>>>> # ls /usr/share/davical/
>>>> dba htdocs inc locale
>>>>
>>>> # ls /www/roundcube/davical/
>>>> htdocs
>>>>
>>>> * vhost
>>>> Alias /images/ /web/static/davical/htdocs/images/
>>>> <Directory /web/static/davical/davical/htdocs/>
>>>> and the php settings etc.,
>>>>
>>>> I imagine that I would have to modify some of the davical scripts for
>>>> this... Did I overlook something?
>>>>
>>>> Cheers, s
>>> I think that this looks ok.
>>>
>>> # pwd
>>> /usr/share/davical
>>> # find -exec grep share \{\} \;
>>> , '/usr/share/awl/inc' // Where it ends up on Debian
>>> , '/usr/share/php/awl/inc' // Fedora's standard for PHP libraries
>>> , '/usr/local/share/awl/inc'
>>> # # php_value include_path /usr/share/awl/inc
>>> , '/usr/share/awl/inc' // Where it ends up on Debian
>>> , '/usr/share/php/awl/inc' // Fedora's standard for PHP libraries
>>> , '/usr/local/share/awl/inc'
>>> AWLDIR="/usr/share/awl"
>>> AWLDIR="/usr/local/share/awl"
>>> Thanks for trying DAViCal! Check in /usr/share/doc/davical/examples/ for
>>> -- RAISE NOTICE 'Permissions to shared group % ', out_confers;
>>> -- RAISE NOTICE 'Permissions to shared group';
>>> -- RAISE NOTICE 'Permissions to shared group % ', out_confers;
>>> -- RAISE NOTICE 'Permissions to shared group % ', out_confers;
>>> -- RAISE NOTICE 'Permissions to shared group';
>>> -- RAISE NOTICE 'Permissions to shared group % ', out_confers;
>>> -- RAISE NOTICE 'Permissions to shared group';
>>> # # php_value include_path /usr/share/awl/inc
>>> , '/usr/share/awl/inc' // Where it ends up on Debian
>>> , '/usr/share/php/awl/inc' // Fedora's standard for PHP libraries
>>> , '/usr/local/share/awl/inc'
>> or maybe not. The create-database.sh seems to have run well, but I
>> suspect that it set something in the htdocs dir, which of course is in
>> the wrong place as far as it is concerned, because hitting the htdocs on
>> the web server serves a blank page.
>>
>>
>> # su postgres -c ./dba/create-database.sh
>>
>> Supported locales updated.
>> Updated view: dav_principal.sql applied.
>> CalDAV functions updated.
>> RRULE functions updated.
>> Database permissions updated.
>> NOTE
>> ====
>> * You will need to edit the PostgreSQL pg_hba.conf to allow the
>> 'davical_dba' database user access to the 'davical' database.
>>
>> * You will need to edit the PostgreSQL pg_hba.conf to allow the
>> 'davical_app' database user access to the 'davical' database.
>>
>> * The password for the 'admin' user has been set to 'nnnnnnnn'
>>
>> Thanks for trying DAViCal! Check in /usr/share/doc/davical/examples/ for
>> some configuration examples. For help, visit #davical on irc.oftc.net.
>>
>> So, what I want to achieve, might want a little more tweaking:-
>>
>> htdocs only in the apache document root.
>> The rest in /usr/share/
>>
>> The current apache vhost is:
>> DirectoryIndex index.php index.html
>> Alias /images/ /web/static/davical/htdocs/images/
>> <Directory /web/static/davical/htdocs/>
>> AllowOverride None
>> Order allow,deny
>> Allow from all
>> </Directory>
>> AcceptPathInfo On
>> php_value include_path /usr/share/awl/inc
>> php_value magic_quotes_gpc 0
>> php_value register_globals 0
>> php_value error_reporting "E_ALL & ~E_NOTICE"
>> php_value default_charset "utf-8"
>>
>>
>> ----
> This was not going to work (don't know why not) so relented again and
> used this in the vhost which gave me the setup page complaining that the
> /etc/davical/config.php is missing. No problem, I'll create one! Not so
> fast.... :-
>
> The create-database.sh script was run yesterday. After completion I
> copied and pasted the admin passwed. Now it s time to use it. I know
> the password is correct as its in a file...
>
> # psql -U admin -W
> Password for user admin:
> psql: FATAL: Ident authentication failed for user "admin"
> # psql davical -c 'select username, password from usr;' -U admin
> psql: FATAL: Ident authentication failed for user "admin"
> # psql davical -c 'select username, password from usr;' -U admin -w
> psql: FATAL: Ident authentication failed for user "admin"
> # psql davical -c 'select username, password from usr;'
> psql: FATAL: Ident authentication failed for user "root"
>
> It won't accept the admin password.
>
> Try again, but this time, contary to what the results of the
> create-database.sh wrote I shall try this:
> # psql davical -c 'select username, password from usr;' -W -U davical_app
> Password for user davical_app: ****** <--- Use the admin password! Eh?
> username | password
> ----------+------------
> admin | **nnnnxxxx
> (1 row)
>
> i) The user admin does exist.
> ii) The user admin has the same password as the user davical_app.
> iii) The psql command does not accept the password listed for admin as
> valid for the admin user.
> Clearly, postgresql's way of doing things differs from my experience
> with mysql.
> iv) I wonder what those asterisk are for, that prefix the password entry.
>
> Would someone tell me what is going on, and how I can log in as the
> admin user?
>
> Cheers, Simon.
>
>
>
Got it to work :D What does the mean? Is it important?
Suhosin "server.strip" disabled.

Dependencies

Dependency Status
Current DAViCal version Passed
DAViCal DB Schema version Passed
AWL Library version Passed
PHP PDO module available Passed
PDO PostgreSQL drivers Passed
PHP PostgreSQL available Passed
GNU gettext support Passed
PHP iconv support Passed
PHP DateTime class Passed
Suhosin "server.strip" disabled *Fail*
PHP Magic Quotes GPC off Passed
PHP Magic Quotes runtime off Passed

vvh at synergylaw

Sep 21, 2011, 6:23 AM

Post #3 of 11 (561 views)
Permalink

Re: Now: postgresql set-up Was: davical on mysql [In reply to]

2011/9/21 Simon Loewenthal/NL/Tele2 <simon.loewenthal [at] tele2>

>
> Got it to work :D What does the mean? Is it important?
> Suhosin "server.strip" disabled.
>

I don't know, but I have the same situation (also the 'Magic quotes Runtime'
is said to fail on my server), but it doesn't seem to harm my setup in
0.9.9.4?

Vincent

simon.loewenthal at tele2

Sep 21, 2011, 6:50 AM

Post #4 of 11 (572 views)
Permalink

Re: Now: postgresql set-up Was: davical on mysql [In reply to]

On 09/21/2011 02:44 PM, Simon Loewenthal/NL/Tele2 wrote:
> On 09/21/2011 02:22 PM, Simon Loewenthal/NL/Tele2 wrote:
>> On 09/21/2011 11:19 AM, Simon Loewenthal/NL/Tele2 wrote:
>>> On 09/21/2011 10:21 AM, Simon Loewenthal/NL/Tele2 wrote:
>>>> On 09/21/2011 09:52 AM, Simon Loewenthal/NL/Tele2 wrote:
>>>>> On 09/21/2011 01:14 AM, Andrew McMillan wrote:
>>>>>> On Tue, 2011-09-20 at 16:41 +0200, Simon Loewenthal/NL/Tele2 wrote:
>>>>>>> OK, I shall relent on the mySQL requirement. We did not want to support
>>>>>>> another sql database :(
>>>>>>>
>>>>>>> I installed the debian package davical. The files are under
>>>>>>> /usr/share/davical.
>>>>>>> Symbolic links are disallowed in apache configurations. All content is
>>>>>>> placed in /web/.... (mounted noexec,nosetuid), and all cgi-bin is in
>>>>>>> another filesystem with exec allowed.
>>>>>> You don't need exec on the PHP code for DAViCal. It should all be
>>>>>> owner/group root, mode 644 so the simplest (and recommended) solution is
>>>>>> just to point the DocumentRoot at /usr/share/davical/htdocs. There is
>>>>>> no reason why anything should modify those files other than a version
>>>>>> upgrade. DAViCal does not write data to the filesystem.
>>>>>>
>>>>>>
>>>>>>> Can I simply copy the entire /usr/share/davical into /web/davical/ and
>>>>>>> run the scripts (e.g dba/create-database.sh) from there?
>>>>>> You could probably do that also (you'd also need to copy the AWL tree
>>>>>> similarly), and you probably also want to make sure that nothing in the
>>>>>> webserver has access to the non-web content of the tree, such as the
>>>>>> directories containing include files, scripts, etc, etc.
>>>>>>
>>>>>> So setting it up securely in that location will take some extra care,
>>>>>> but it sounds like you're probably paranoid enough to do an OK job.
>>>>>>
>>>>>> Cheers,
>>>>>> Andrew.
>>>>>>
>>>>> Hi Andrew,
>>>>>
>>>>> Then perhaps this:
>>>>>
>>>>> Move /usr/share/davical/htdocs to /web/static/davical/htdocs
>>>>> Leave the rest of davical where it is in /usr/share/davical
>>>>>
>>>>> Which gives
>>>>> # ls /usr/share/davical/
>>>>> dba htdocs inc locale
>>>>>
>>>>> # ls /www/roundcube/davical/
>>>>> htdocs
>>>>>
>>>>> * vhost
>>>>> Alias /images/ /web/static/davical/htdocs/images/
>>>>> <Directory /web/static/davical/davical/htdocs/>
>>>>> and the php settings etc.,
>>>>>
>>>>> I imagine that I would have to modify some of the davical scripts for
>>>>> this... Did I overlook something?
>>>>>
>>>>> Cheers, s
>>>> I think that this looks ok.
>>>>
>>>> # pwd
>>>> /usr/share/davical
>>>> # find -exec grep share \{\} \;
>>>> , '/usr/share/awl/inc' // Where it ends up on Debian
>>>> , '/usr/share/php/awl/inc' // Fedora's standard for PHP libraries
>>>> , '/usr/local/share/awl/inc'
>>>> # # php_value include_path /usr/share/awl/inc
>>>> , '/usr/share/awl/inc' // Where it ends up on Debian
>>>> , '/usr/share/php/awl/inc' // Fedora's standard for PHP libraries
>>>> , '/usr/local/share/awl/inc'
>>>> AWLDIR="/usr/share/awl"
>>>> AWLDIR="/usr/local/share/awl"
>>>> Thanks for trying DAViCal! Check in /usr/share/doc/davical/examples/ for
>>>> -- RAISE NOTICE 'Permissions to shared group % ', out_confers;
>>>> -- RAISE NOTICE 'Permissions to shared group';
>>>> -- RAISE NOTICE 'Permissions to shared group % ', out_confers;
>>>> -- RAISE NOTICE 'Permissions to shared group % ', out_confers;
>>>> -- RAISE NOTICE 'Permissions to shared group';
>>>> -- RAISE NOTICE 'Permissions to shared group % ', out_confers;
>>>> -- RAISE NOTICE 'Permissions to shared group';
>>>> # # php_value include_path /usr/share/awl/inc
>>>> , '/usr/share/awl/inc' // Where it ends up on Debian
>>>> , '/usr/share/php/awl/inc' // Fedora's standard for PHP libraries
>>>> , '/usr/local/share/awl/inc'
>>> or maybe not. The create-database.sh seems to have run well, but I
>>> suspect that it set something in the htdocs dir, which of course is in
>>> the wrong place as far as it is concerned, because hitting the htdocs on
>>> the web server serves a blank page.
>>>
>>>
>>> # su postgres -c ./dba/create-database.sh
>>>
>>> Supported locales updated.
>>> Updated view: dav_principal.sql applied.
>>> CalDAV functions updated.
>>> RRULE functions updated.
>>> Database permissions updated.
>>> NOTE
>>> ====
>>> * You will need to edit the PostgreSQL pg_hba.conf to allow the
>>> 'davical_dba' database user access to the 'davical' database.
>>>
>>> * You will need to edit the PostgreSQL pg_hba.conf to allow the
>>> 'davical_app' database user access to the 'davical' database.
>>>
>>> * The password for the 'admin' user has been set to 'nnnnnnnn'
>>>
>>> Thanks for trying DAViCal! Check in /usr/share/doc/davical/examples/ for
>>> some configuration examples. For help, visit #davical on irc.oftc.net.
>>>
>>> So, what I want to achieve, might want a little more tweaking:-
>>>
>>> htdocs only in the apache document root.
>>> The rest in /usr/share/
>>>
>>> The current apache vhost is:
>>> DirectoryIndex index.php index.html
>>> Alias /images/ /web/static/davical/htdocs/images/
>>> <Directory /web/static/davical/htdocs/>
>>> AllowOverride None
>>> Order allow,deny
>>> Allow from all
>>> </Directory>
>>> AcceptPathInfo On
>>> php_value include_path /usr/share/awl/inc
>>> php_value magic_quotes_gpc 0
>>> php_value register_globals 0
>>> php_value error_reporting "E_ALL & ~E_NOTICE"
>>> php_value default_charset "utf-8"
>>>
>>>
>>> ----
>> This was not going to work (don't know why not) so relented again and
>> used this in the vhost which gave me the setup page complaining that the
>> /etc/davical/config.php is missing. No problem, I'll create one! Not so
>> fast.... :-
>>
>> The create-database.sh script was run yesterday. After completion I
>> copied and pasted the admin passwed. Now it s time to use it. I know
>> the password is correct as its in a file...
>>
>> # psql -U admin -W
>> Password for user admin:
>> psql: FATAL: Ident authentication failed for user "admin"
>> # psql davical -c 'select username, password from usr;' -U admin
>> psql: FATAL: Ident authentication failed for user "admin"
>> # psql davical -c 'select username, password from usr;' -U admin -w
>> psql: FATAL: Ident authentication failed for user "admin"
>> # psql davical -c 'select username, password from usr;'
>> psql: FATAL: Ident authentication failed for user "root"
>>
>> It won't accept the admin password.
>>
>> Try again, but this time, contary to what the results of the
>> create-database.sh wrote I shall try this:
>> # psql davical -c 'select username, password from usr;' -W -U davical_app
>> Password for user davical_app: ****** <--- Use the admin password! Eh?
>> username | password
>> ----------+------------
>> admin | **nnnnxxxx
>> (1 row)
>>
>> i) The user admin does exist.
>> ii) The user admin has the same password as the user davical_app.
>> iii) The psql command does not accept the password listed for admin as
>> valid for the admin user.
>> Clearly, postgresql's way of doing things differs from my experience
>> with mysql.
>> iv) I wonder what those asterisk are for, that prefix the password entry.
>>
>> Would someone tell me what is going on, and how I can log in as the
>> admin user?
>>
>> Cheers, Simon.
>>
>>
>>
> Got it to work :D What does the mean? Is it important?
> Suhosin "server.strip" disabled.
>
>
> Dependencies
>
> Dependency Status
> Current DAViCal version Passed
> DAViCal DB Schema version Passed
> AWL Library version Passed
> PHP PDO module available Passed
> PDO PostgreSQL drivers Passed
> PHP PostgreSQL available Passed
> GNU gettext support Passed
> PHP iconv support Passed
> PHP DateTime class Passed
> Suhosin "server.strip" disabled *Fail*
> PHP Magic Quotes GPC off Passed
> PHP Magic Quotes runtime off Passed
>
Cheers Vincent for the info about this.

On another set-up note:

1)
I created a normal user called simon [at] test Works and I can log in.
However, it states that it is an administrator, and cannot access
calendars, which is odd as its not an admin:-
Principle type = Person
Active = yes (ticked)
Administrator = No (unticked)

What is it missing to make it a normal user with a calendar?

2)
I am trying to configure a Android phone to connect with it. It seems
that the Samsung SGS9100 has the ability to sync directtly with it, but
adding a "Server account" - Sync Server.

The settings are:
Address: https://mydomain/ical/ (if I try and add the
caldev.php/simon [at] test, it fails the authentication)
LoginID: simon [at] test
Password: nnnnnn
Additional settings are:
Sync Catagory --
Contacts DBname:
Calendar DBname:
Memo DBname:
I don't know what to add into the Calendar DBname. Is there one
specific (or generic) the users?

However, I expect that the option in the handset is not really for iCal
but for some samsung poorly undocumented synchronization service... ;)

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Davical-general mailing list
Davical-general [at] lists
https://lists.sourceforge.net/lists/listinfo/davical-general

vvh at synergylaw

Sep 21, 2011, 7:56 AM

Post #5 of 11 (558 views)
Permalink

Re: Now: postgresql set-up Was: davical on mysql [In reply to]

2011/9/21 Simon Loewenthal/NL/Tele2 <simon.loewenthal [at] tele2>
>
> 2)
> I am trying to configure a Android phone to connect with it. It seems
> that the Samsung SGS9100 has the ability to sync directtly with it, but
> adding a "Server account" - Sync Server.
>

Android doesn't speak calDAV directly, you need an app like acal (available
in the market for € 1.49).

Vincent

simon.loewenthal at tele2

Sep 21, 2011, 8:06 AM

Post #6 of 11 (561 views)
Permalink

Re: Now: postgresql set-up Was: davical on mysql [In reply to]

On 09/21/2011 04:56 PM, Vincent Van Houtte wrote:
> 2011/9/21 Simon Loewenthal/NL/Tele2 <simon.loewenthal [at] tele2
> <mailto:simon.loewenthal [at] tele2>>
>
> 2)
> I am trying to configure a Android phone to connect with it. It seems
> that the Samsung SGS9100 has the ability to sync directtly with
> it, but
> adding a "Server account" - Sync Server.
>
>
> Android doesn't speak calDAV directly, you need an app like acal
> (available in the market for € 1.49).
>
> Vincent
Thanks Vincent. 1.49 is not a hefty price to pay. I'll look at acal for
the time being.

I know that Android does not speak calDAV directly, but Samsung included
this strange looking calandar sync account on this particular phone
only. (Its not on google asop that I have seen, at least not on the
Nexus S). All I have got from Samsung is that its for syncing
calendars, but their 'tech support' do not know how.

Rsgs, Simon.

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Davical-general mailing list
Davical-general [at] lists
https://lists.sourceforge.net/lists/listinfo/davical-general

andrew at morphoss

Sep 21, 2011, 1:25 PM

Post #7 of 11 (571 views)
Permalink

Re: Now: postgresql set-up Was: davical on mysql [In reply to]

On Wed, 2011-09-21 at 14:22 +0200, Simon Loewenthal/NL/Tele2 wrote:
> >
> > So, what I want to achieve, might want a little more tweaking:-
> >
> > htdocs only in the apache document root.
> > The rest in /usr/share/
> >
> > The current apache vhost is:
> > DirectoryIndex index.php index.html
> > Alias /images/ /web/static/davical/htdocs/images/
> > <Directory /web/static/davical/htdocs/>
> > AllowOverride None
> > Order allow,deny
> > Allow from all
> > </Directory>
> > AcceptPathInfo On
> > php_value include_path /usr/share/awl/inc
> > php_value magic_quotes_gpc 0
> > php_value register_globals 0
> > php_value error_reporting "E_ALL & ~E_NOTICE"
> > php_value default_charset "utf-8"
> >
> >
> > ----
>
> This was not going to work (don't know why not) so relented again and
> used this in the vhost which gave me the setup page complaining that the
> /etc/davical/config.php is missing. No problem, I'll create one! Not so
> fast.... :-

You might need to add /usr/share/davical/inc into that include path if
you're going to separate the .../htdocs from .../inc

> The create-database.sh script was run yesterday. After completion I
> copied and pasted the admin passwed. Now it s time to use it. I know
> the password is correct as its in a file...
>
> # psql -U admin -W
> Password for user admin:
> psql: FATAL: Ident authentication failed for user "admin"
> # psql davical -c 'select username, password from usr;' -U admin
> psql: FATAL: Ident authentication failed for user "admin"
> # psql davical -c 'select username, password from usr;' -U admin -w
> psql: FATAL: Ident authentication failed for user "admin"
> # psql davical -c 'select username, password from usr;'
> psql: FATAL: Ident authentication failed for user "root"
>
> It won't accept the admin password.

The admin password is the password which an 'admin' user in DAViCal uses
to log onto the DAViCal UI. It is not a *database* password.

> Try again, but this time, contary to what the results of the
> create-database.sh wrote I shall try this:
> # psql davical -c 'select username, password from usr;' -W -U davical_app
> Password for user davical_app: ****** <--- Use the admin password! Eh?
> username | password
> ----------+------------
> admin | **nnnnxxxx
> (1 row)
>
> i) The user admin does exist.

They exist within DAViCal's userbase.

> ii) The user admin has the same password as the user davical_app.

They are different classes of things. The database user used for
owning/modifying the database is 'davical_dba', which is a normal
database user (i.e. not a superuser) which happens to own the database
so has full rights. This database user does not get assigned a password
by default, with access locked down to the local system. If you need
more security than that then you definitely need to read up on
pg_hba.conf syntax and restrict access by that user, and probably assign
a password to it also.

> iii) The psql command does not accept the password listed for admin as
> valid for the admin user.
> Clearly, postgresql's way of doing things differs from my experience
> with mysql.

Yes, there are differences there as well. The postgresql 'superuser' is
usually 'postgres' and is usually restricted to access (with no
password) only from the local unix account of the same name.

The pg_hba.conf file controls access and has some trust mechanisms such
as 'unix account must match' or 'must be a member of XXX unix group'
which can be quite nice for limiting access.

> iv) I wonder what those asterisk are for, that prefix the password entry.

The asterisks are used by DAViCal to indicate that this password is
unencrypted. There are a variety of other prefixes that DAViCal uses
for identifying other password hashing schemes.

When you create a password within DAViCal it will be a SHA1 salted hash,
compatible with passwords for OpenLDAP, but it's useful for the random
password created for admin to be available as plain text because
commonly gets forgotten. I didn't want to have DAViCal install with a
default password with an admonition to "don't forget to change the admin
password" at the end, because people don't.

> Would someone tell me what is going on, and how I can log in as the
> admin user?

Hope this clarifies it all :-)

There is information about most of this on the wiki.

> I know that Android does not speak calDAV directly, but Samsung
> included this strange looking calandar sync account on this particular
> phone only. (Its not on google asop that I have seen, at least not on
> the Nexus S). All I have got from Samsung is that its for syncing
> calendars, but their 'tech support' do not know how.

I'm not aware of the sync account on the Samsung SGS9100 but if it's
talking about a Calendar DBname I would expect that will be something
local to the device. If it fails authentication against a remote CalDAV
server it's possible that the login ID of 'simon [at] test' might not
have the '@' handled properly, since it needs to be URL escaped in the
URL, but not escaped in the basic auth headers. It's a common coding
error - I remember fixing it in DAViCal back in 2007 or so, and seeing
it on many occasions in other software since.

As well as aCal (which I wrote) there are several CalDAV and CardDAV
sync applications which will synchronize the server with the internal
Android calendar (or addressbook, for CardDAV of course :-). aCal does
not do this - it is a complete standalone calendar which understands
CalDAV

Cheers,
Andrew.

--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Nothing in life is to be feared. It is only to be understood.
------------------------------------------------------------------------

Attachments:

signature.asc (0.82 KB)

simon.loewenthal at tele2

Sep 22, 2011, 2:09 AM

Post #8 of 11 (586 views)
Permalink

Re: Now: postgresql set-up Was: davical on mysql [In reply to]

On 09/21/2011 10:25 PM, Andrew McMillan wrote:
> On Wed, 2011-09-21 at 14:22 +0200, Simon Loewenthal/NL/Tele2 wrote:
>>> So, what I want to achieve, might want a little more tweaking:-
>>>
>>> htdocs only in the apache document root.
>>> The rest in /usr/share/
>>>
>>> The current apache vhost is:
>>> DirectoryIndex index.php index.html
>>> Alias /images/ /web/static/davical/htdocs/images/
>>> <Directory /web/static/davical/htdocs/>
>>> AllowOverride None
>>> Order allow,deny
>>> Allow from all
>>> </Directory>
>>> AcceptPathInfo On
>>> php_value include_path /usr/share/awl/inc
>>> php_value magic_quotes_gpc 0
>>> php_value register_globals 0
>>> php_value error_reporting "E_ALL & ~E_NOTICE"
>>> php_value default_charset "utf-8"
>>>
>>>
>>> ----
>> This was not going to work (don't know why not) so relented again and
>> used this in the vhost which gave me the setup page complaining that the
>> /etc/davical/config.php is missing. No problem, I'll create one! Not so
>> fast.... :-
> You might need to add /usr/share/davical/inc into that include path if
> you're going to separate the .../htdocs from .../inc
>
>
>> The create-database.sh script was run yesterday. After completion I
>> copied and pasted the admin passwed. Now it s time to use it. I know
>> the password is correct as its in a file...
>>
>> # psql -U admin -W
>> Password for user admin:
>> psql: FATAL: Ident authentication failed for user "admin"
>> # psql davical -c 'select username, password from usr;' -U admin
>> psql: FATAL: Ident authentication failed for user "admin"
>> # psql davical -c 'select username, password from usr;' -U admin -w
>> psql: FATAL: Ident authentication failed for user "admin"
>> # psql davical -c 'select username, password from usr;'
>> psql: FATAL: Ident authentication failed for user "root"
>>
>> It won't accept the admin password.
> The admin password is the password which an 'admin' user in DAViCal uses
> to log onto the DAViCal UI. It is not a *database* password.
>
>
>> Try again, but this time, contary to what the results of the
>> create-database.sh wrote I shall try this:
>> # psql davical -c 'select username, password from usr;' -W -U davical_app
>> Password for user davical_app: ****** <--- Use the admin password! Eh?
>> username | password
>> ----------+------------
>> admin | **nnnnxxxx
>> (1 row)
>>
>> i) The user admin does exist.
> They exist within DAViCal's userbase.
>
>
>> ii) The user admin has the same password as the user davical_app.
> They are different classes of things. The database user used for
> owning/modifying the database is 'davical_dba', which is a normal
> database user (i.e. not a superuser) which happens to own the database
> so has full rights. This database user does not get assigned a password
> by default, with access locked down to the local system. If you need
> more security than that then you definitely need to read up on
> pg_hba.conf syntax and restrict access by that user, and probably assign
> a password to it also.
>
>
>> iii) The psql command does not accept the password listed for admin as
>> valid for the admin user.
>> Clearly, postgresql's way of doing things differs from my experience
>> with mysql.
> Yes, there are differences there as well. The postgresql 'superuser' is
> usually 'postgres' and is usually restricted to access (with no
> password) only from the local unix account of the same name.
>
> The pg_hba.conf file controls access and has some trust mechanisms such
> as 'unix account must match' or 'must be a member of XXX unix group'
> which can be quite nice for limiting access.
>
>
>> iv) I wonder what those asterisk are for, that prefix the password entry.
> The asterisks are used by DAViCal to indicate that this password is
> unencrypted. There are a variety of other prefixes that DAViCal uses
> for identifying other password hashing schemes.
>
> When you create a password within DAViCal it will be a SHA1 salted hash,
> compatible with passwords for OpenLDAP, but it's useful for the random
> password created for admin to be available as plain text because
> commonly gets forgotten. I didn't want to have DAViCal install with a
> default password with an admonition to "don't forget to change the admin
> password" at the end, because people don't.
>
>
>> Would someone tell me what is going on, and how I can log in as the
>> admin user?
> Hope this clarifies it all :-)
>
> There is information about most of this on the wiki.
>
>
>> I know that Android does not speak calDAV directly, but Samsung
>> included this strange looking calandar sync account on this particular
>> phone only. (Its not on google asop that I have seen, at least not on
>> the Nexus S). All I have got from Samsung is that its for syncing
>> calendars, but their 'tech support' do not know how.
> I'm not aware of the sync account on the Samsung SGS9100 but if it's
> talking about a Calendar DBname I would expect that will be something
> local to the device. If it fails authentication against a remote CalDAV
> server it's possible that the login ID of 'simon [at] test' might not
> have the '@' handled properly, since it needs to be URL escaped in the
> URL, but not escaped in the basic auth headers. It's a common coding
> error - I remember fixing it in DAViCal back in 2007 or so, and seeing
> it on many occasions in other software since.
>
> As well as aCal (which I wrote) there are several CalDAV and CardDAV
> sync applications which will synchronize the server with the internal
> Android calendar (or addressbook, for CardDAV of course :-). aCal does
> not do this - it is a complete standalone calendar which understands
> CalDAV
>
> Cheers,
> Andrew.
>
Hi Andrew,

Many thanks for the detailed explanations. Its all clear now.

I set-up a calendar with Lightening. Seems to have authenticated well.
Attempted to add a new event into the calendar and got back an error
from Lightening:
An error occurred when writing to the calendar test [at] test
Error code: MODIFICATION_FAILED

Not a lot else. I imagine that the user missed some permissions when I
created it. Does any one know what the permission should be. (I have
added read/write to everything for the user account

Privileges granted to All Users:
Read Write Metadata Write Data Override a Lock Read Access Controls Read
Current User's Access Create Events/Collections Delete
Events/Collections Write Access Controls Read Free/Busy Information
Scheduling: Deliver an Invitation Scheduling: Deliver a Reply
Scheduling: Query free/busy Scheduling: Send an Invitation Scheduling:
Send a Reply Scheduling: Send free/busy

Regards, Simon

andrew at morphoss

Sep 22, 2011, 5:34 PM

Post #9 of 11 (549 views)
Permalink

Re: Now: postgresql set-up Was: davical on mysql [In reply to]

On Thu, 2011-09-22 at 11:09 +0200, Simon Loewenthal/NL/Tele2 wrote:
> Hi Andrew,
>
> Many thanks for the detailed explanations. Its all clear now.
>
> I set-up a calendar with Lightening. Seems to have authenticated
> well. Attempted to add a new event into the calendar and got back an
> error from Lightening:
> An error occurred when writing to the calendar test [at] test
> Error code: MODIFICATION_FAILED
>
> Not a lot else. I imagine that the user missed some permissions when
> I created it. Does any one know what the permission should be. (I
> have added read/write to everything for the user account

Privileges granted to all users are not the privileges granted to the
owner, who always has full access to their own stuff.

Is this a user accessing their own stuff? Is it a calendar that has
been added as a CalDAV calendar, or is it possibly one that is being
accessed as a WebDAV calendar? Since DAViCal supports legacy access
over WebDAV it can be easy (particularly in Lightning) to configure the
access this way by mistake. When accessed in this manner DAViCal
defaults to being read-only.

If this is a user accessing another's calendar then you need to check
the permissions that the other user grants to this user. The buttons
above the detailed permissions set are intended to provide 'quick' ways
of setting the things that people typically want to provide, so the
'Read/Write' button should toggle all the appropriate settings on (or
off) for read/write access.

Cheers,
Andrew.

--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
My opinions may have changed, but not the fact that I am right.
------------------------------------------------------------------------

Attachments:

signature.asc (0.82 KB)

simon.loewenthal at tele2

Sep 23, 2011, 5:32 AM

Post #10 of 11 (581 views)
Permalink

Re: Now: postgresql set-up Was: davical on mysql [In reply to]

On 09/23/2011 02:34 AM, Andrew McMillan wrote:
> On Thu, 2011-09-22 at 11:09 +0200, Simon Loewenthal/NL/Tele2 wrote:
>> Hi Andrew,
>>
>> Many thanks for the detailed explanations. Its all clear now.
>>
>> I set-up a calendar with Lightening. Seems to have authenticated
>> well. Attempted to add a new event into the calendar and got back an
>> error from Lightening:
>> An error occurred when writing to the calendar test [at] test
>> Error code: MODIFICATION_FAILED
>>
>> Not a lot else. I imagine that the user missed some permissions when
>> I created it. Does any one know what the permission should be. (I
>> have added read/write to everything for the user account
> Privileges granted to all users are not the privileges granted to the
> owner, who always has full access to their own stuff.
>
> Is this a user accessing their own stuff? Is it a calendar that has
> been added as a CalDAV calendar, or is it possibly one that is being
> accessed as a WebDAV calendar? Since DAViCal supports legacy access
> over WebDAV it can be easy (particularly in Lightning) to configure the
> access this way by mistake. When accessed in this manner DAViCal
> defaults to being read-only.
>
> If this is a user accessing another's calendar then you need to check
> the permissions that the other user grants to this user. The buttons
> above the detailed permissions set are intended to provide 'quick' ways
> of setting the things that people typically want to provide, so the
> 'Read/Write' button should toggle all the appropriate settings on (or
> off) for read/write access.
>
> Cheers,
> Andrew.
>
Seems that its logging these errors. I suppose that I did not set up the
calendar correctly when I created the user.

[Fri Sep 23 14:26:53 2011] [error] [client 8.1.2.3] DAViCal: LOG: :***************** Response Header ****************
[Fri Sep 23 14:26:53 2011] [error] [client 8.1.2.3] DAViCal: LOG: headers:-->X-Powered-By: PHP/5.3.8-1~dotdeb.2
[Fri Sep 23 14:26:53 2011] [error] [client 8.1.2.3] DAViCal: LOG: headers:-->Server: 0.9
[Fri Sep 23 14:26:53 2011] [error] [client 8.1.2.3] DAViCal: LOG: headers:-->DAV: 1, 2, 3, access-control, calendar-access, calendar-schedule
[Fri Sep 23 14:26:53 2011] [error] [client 8.1.2.3] DAViCal: LOG: headers:-->DAV: extended-mkcol, calendar-proxy, bind, addressbook, calendar-auto-schedule
[Fri Sep 23 14:26:53 2011] [error] [client 8.1.2.3] DAViCal: LOG: headers:-->X-DAViCal-Version: DAViCal/0.9.9; DB/1.2.10
[Fri Sep 23 14:26:53 2011] [error] [client 8.1.2.3] DAViCal: LOG: headers:-->Content-type: text/xml; charset="utf-8"
[Fri Sep 23 14:26:53 2011] [error] [client 8.1.2.3] DAViCal: LOG: :******************** Response ********************
[Fri Sep 23 14:26:53 2011] [error] [client 8.1.2.3] DAViCal: LOG: response:--><?xml version="1.0" encoding="utf-8" ?>
[Fri Sep 23 14:26:53 2011] [error] [client 8.1.2.3] DAViCal: LOG: response:--><error xmlns="DAV:">
[Fri Sep 23 14:26:53 2011] [error] [client 8.1.2.3] DAViCal: LOG: response:--> <must-exist/>That resource is not present on this server.
[Fri Sep 23 14:26:53 2011] [error] [client 8.1.2.3] DAViCal: LOG: response:--></error>
[Fri Sep 23 14:27:07 2011] [error] [client 8.1.2.3] DAViCal: LOG: :***************** Response Header ****************
[Fri Sep 23 14:27:07 2011] [error] [client 8.1.2.3] DAViCal: LOG: headers:-->X-Powered-By: PHP/5.3.8-1~dotdeb.2
[Fri Sep 23 14:27:07 2011] [error] [client 8.1.2.3] DAViCal: LOG: headers:-->Server: 0.9
[Fri Sep 23 14:27:07 2011] [error] [client 8.1.2.3] DAViCal: LOG: headers:-->DAV: 1, 2, 3, access-control, calendar-access, calendar-schedule
[Fri Sep 23 14:27:07 2011] [error] [client 8.1.2.3] DAViCal: LOG: headers:-->DAV: extended-mkcol, calendar-proxy, bind, addressbook, calendar-auto-schedule
[Fri Sep 23 14:27:07 2011] [error] [client 8.1.2.3] DAViCal: LOG: headers:-->X-DAViCal-Version: DAViCal/0.9.9; DB/1.2.10
[Fri Sep 23 14:27:07 2011] [error] [client 8.1.2.3] DAViCal: LOG: headers:-->Content-type: text/xml; charset="utf-8"
[Fri Sep 23 14:27:07 2011] [error] [client 8.1.2.3] DAViCal: LOG: :******************** Response ********************
[Fri Sep 23 14:27:07 2011] [error] [client 8.1.2.3] DAViCal: LOG: response:--><?xml version="1.0" encoding="utf-8" ?>
[Fri Sep 23 14:27:07 2011] [error] [client 8.1.2.3] DAViCal: LOG: response:--><error xmlns="DAV:">
[Fri Sep 23 14:27:07 2011] [error] [client 8.1.2.3] DAViCal: LOG: response:--> <must-exist/>That resource is not present on this server.
[Fri Sep 23 14:27:07 2011] [error] [client 8.1.2.3] DAViCal: LOG: response:--></error>
[Fri Sep 23 14:27:11 2011] [error] [client 8.1.2.3] DAViCal: LOG: :***************** Response Header ****************
[Fri Sep 23 14:27:11 2011] [error] [client 8.1.2.3] DAViCal: LOG: headers:-->X-Powered-By: PHP/5.3.8-1~dotdeb.2
[Fri Sep 23 14:27:11 2011] [error] [client 8.1.2.3] DAViCal: LOG: headers:-->Server: 0.9
[Fri Sep 23 14:27:11 2011] [error] [client 8.1.2.3] DAViCal: LOG: headers:-->DAV: 1, 2, 3, access-control, calendar-access, calendar-schedule
[Fri Sep 23 14:27:11 2011] [error] [client 8.1.2.3] DAViCal: LOG: headers:-->DAV: extended-mkcol, calendar-proxy, bind, addressbook, calendar-auto-schedule
[Fri Sep 23 14:27:11 2011] [error] [client 8.1.2.3] DAViCal: LOG: headers:-->X-DAViCal-Version: DAViCal/0.9.9; DB/1.2.10
[Fri Sep 23 14:27:11 2011] [error] [client 8.1.2.3] DAViCal: LOG: headers:-->Content-type: text/xml; charset="utf-8"
[Fri Sep 23 14:27:11 2011] [error] [client 8.1.2.3] DAViCal: LOG: :******************** Response ********************
[Fri Sep 23 14:27:11 2011] [error] [client 8.1.2.3] DAViCal: LOG: response:--><?xml version="1.0" encoding="utf-8" ?>
[Fri Sep 23 14:27:11 2011] [error] [client 8.1.2.3] DAViCal: LOG: response:--><error xmlns="DAV:">
[Fri Sep 23 14:27:11 2011] [error] [client 8.1.2.3] DAViCal: LOG: response:--> <must-exist/>That resource is not present on this server.
[Fri Sep 23 14:27:11 2011] [error] [client 8.1.2.3] DAViCal: LOG: response:--></error>
[Fri Sep 23 14:27:49 2011] [error] [client 8.1.2.3] DAViCal: LOG: :***************** Response Header ****************
[Fri Sep 23 14:27:49 2011] [error] [client 8.1.2.3] DAViCal: LOG: headers:-->X-Powered-By: PHP/5.3.8-1~dotdeb.2
[Fri Sep 23 14:27:49 2011] [error] [client 8.1.2.3] DAViCal: LOG: headers:-->Server: 0.9
[Fri Sep 23 14:27:49 2011] [error] [client 8.1.2.3] DAViCal: LOG: headers:-->DAV: 1, 2, 3, access-control, calendar-access, calendar-schedule
[Fri Sep 23 14:27:49 2011] [error] [client 8.1.2.3] DAViCal: LOG: headers:-->DAV: extended-mkcol, calendar-proxy, bind, addressbook, calendar-auto-schedule
[Fri Sep 23 14:27:49 2011] [error] [client 8.1.2.3] DAViCal: LOG: headers:-->X-DAViCal-Version: DAViCal/0.9.9; DB/1.2.10
[Fri Sep 23 14:27:49 2011] [error] [client 82.173.139.52] DAViCal: LOG: headers:-->Content-type: text/plain; charset="utf-8"
[Fri Sep 23 14:27:49 2011] [error] [client 8.1.2.3] DAViCal: LOG: :******************** Response ********************
[Fri Sep 23 14:27:49 2011] [error] [client 8.1.2.3] DAViCal: LOG: response:-->

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
_______________________________________________
Davical-general mailing list
Davical-general [at] lists
https://lists.sourceforge.net/lists/listinfo/davical-general

andrew at morphoss

Sep 23, 2011, 4:35 PM

Post #11 of 11 (555 views)
Permalink

Re: Now: postgresql set-up Was: davical on mysql [In reply to]

On Fri, 2011-09-23 at 14:32 +0200, Simon Loewenthal/NL/Tele2 wrote:
> >
> Seems that its logging these errors. I suppose that I did not set up the
> calendar correctly when I created the user.
>
> response:--> <must-exist/>That resource is not present on this server.

Some URL you are using somewhere is incorrect. The client is attempting
to access a non-existent resource.

Log into the admin UI, review the principal and check the name of the
resource you are trying to access. Much documentation will refer
to /caldav.php/username/home/ as a calendar URL, but the default has
changed and on a new setup this will be /caldav.php/username/calendar/
and this could be your problem.

Cheers,
Andrew.
--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
I have not seen high-discipline processes succeed in commercial
settings. - Alistair Cockburn

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

Attachments:

signature.asc (0.82 KB)

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads