Problems and Solutions: Difference between revisions

From Davical
Jump to navigationJump to search
No edit summary
(8 intermediate revisions by 2 users not shown)
Line 17: Line 17:
* Note: on OpenBSD 4.8 the DBI module may need to be installed along with YAML and DBD::Pg.
* Note: on OpenBSD 4.8 the DBI module may need to be installed along with YAML and DBD::Pg.


==Admin Interface==
=== Unix Socket Directory ===
 
The PostgreSQL default for the unix_socket_directory variable is ''/tmp''. DAViCal expects the Debian path of ''/var/run/postgresql''. Other distributions and bugs in Debian/Ubuntu can lead you to get the wrong path.  Change the ''unix_socket_directory'' variable in ''/etc/postgresql/8.4/main/postgresql.conf''.
 
The error message that would be triggered by this would look something like:
  DBI connect('dbname=davical','davical_dba',...) failed: could not connect to server: '''No such file or directory'''
        Is the server running locally and accepting
        connections on '''Unix domain socket''' "'''/var/run/postgresql/'''.s.PGSQL.5432"? at /usr/share/davical/dba/update-davical-database line 244
  Can't connect to database davical at /usr/share/davical/dba/update-davical-database line 244
 
You will see this error if the user you are trying to run the <pre>dba/create_database.sh</pre> script as cannot access the database in order to create database users for the application and create the 'davical' database.
 
=== No Database Rights ===
 
There are several variations on resolving the issue:
* Database on Local Server (you need to grant access to it)
* Database on Remote Server (you need to tell the script where it is)
 
==== Database on Local Server ====
If the database for DAViCal is on the local server then you will need to edit the pg_hba.conf file to give appropriate permissions to the database administration user (usually 'davical_dba') as well as giving permissions to the application user (usually 'davical_app').
 
Note that this only gives permissions for those users to connect to the database.  DAViCal will restrict the rights of those database users to the specific minimum access needed for them to do their jobs.  The davical_dba user does not need rights to create databases or users, but it does need to own all the tables.
 
The ''dba/create_database.sh'' script will need to be run by a user who '''does''' have the right to create users and databases, however.  Normally this is the 'postgres' user.
 
==== Database on Remote Server or non-default port ====
 
If the database is on a remote server then (as well as having to grant permissions, as above) you will need to set a few environment variables (PGPORT, PGHOST, PGCLUSTER) in order that the correct database server is used. Also check out the User Contributions for a modified version of the ''create_database.sh'' script.


===I have to log in to every page===
===I have to log in to every page===


This indicates that your browser is not getting or accepting the session cookie for some reason.  The cause can be several things:  
This indicates that your browser is not getting or accepting the session cookie for some reason.  The cause can be several things:
# There could be an error message coming from PHP before it sends the "Cookie" header back.  Look at the source of the page, or in the webserver error log for clues. Take care not to add any new line characters after ?> in the config file in /etc/davical/*-conf.php!
# There could be an error message coming from PHP before it sends the "Cookie" header back.  Look at the source of the page, or in the webserver error log for clues. Take care not to add any new line characters after ?> in the config file in /etc/davical/*-conf.php! If you have extra characters after the ?> at the end of your DAViCal configuration file you need to remove them. While you're at it, remove the ?> as well so it doesn't happen again! The problem is that this causes the output to the browser to be started before DAViCal has sent it's session cookie. So the browser never receives the session cookie, and never actually manages to log in for more than the single page.
# Your browser might be rejecting the cookie.  Check in the privacy settings for your browser that it allows the cookie.
# Your browser might be rejecting the cookie.  Check in the privacy settings for your browser that it allows the cookie.


===I get a blank page===


===I get a blank page===
Unfortunately several different reasons can trigger that behaviour.
 
# <u>The most likely cause for this to happen is a typo in one of your PHP configuration pages</u>, like a missing semicolon or an unclosed hyphen.
# If you didn't install DAViCal via a package manager check if you meet all the given [[DAViCal_Dependencies|dependencies]].
# Check if you indeed created a configuration file for DAViCal (''/etc/davical/config.php''), also check your symbolic links in that directory if any.
# Make sure your configuration is pointing to the right database and you're using the right database name and user.


Maybe your PHP installation is configured to interpret scripts only in a directory for web contents (i.e. ''/var/www'') - what is totally good - and you have forgotten this or never knew about it.
Finally, your PHP installation might be configured to only interpret scripts in a directory specifically dedicated to web contents (i.e. ''/var/www'') - which is good, btw.


To solve this problem, you must allow PHP to interpret scripts from ''davical'' and ''awl''. To do so, just add the following line to a ''.htaccess'' file in ''/usr/share/davical/htdocs'' or to your VirtualHost configuration:
To solve this problem, you must allow PHP to interpret scripts from ''davical'' and ''awl''. To do so, just add the following line to a ''.htaccess'' file in ''/usr/share/davical/htdocs'' or to your VirtualHost configuration:
Line 35: Line 68:
</pre>
</pre>


'''''Note:''''' Some sites mistakenly state that 'open_basedir "1"' is sufficient.  It is not, and is frequently the '''cause''' of this problem!
'''''Note:''''' Some sites mistakenly state that ''open_basedir "1"'' is sufficient.  It is not, and is frequently the '''cause''' of this problem!


==Authentication==
==Authentication==
Line 42: Line 75:


It seems the username for HTTP-auth needs to be lowercase, even though the username in the admin interface contains uppercase letters. See also [http://sourceforge.net/tracker/index.php?func=detail&aid=1709192&group_id=179845&atid=890785 this bug report].
It seems the username for HTTP-auth needs to be lowercase, even though the username in the admin interface contains uppercase letters. See also [http://sourceforge.net/tracker/index.php?func=detail&aid=1709192&group_id=179845&atid=890785 this bug report].
If you experience problems authenticating to caldav.php and you have mod_fastcgi or mod_fcgi, please see https://stackoverflow.com/questions/17018586/apache-2-4-php-fpm-and-authorization-headers how to pass on the necessary headers.


==DB Errors During Upgrade==
==DB Errors During Upgrade==

Revision as of 17:14, 29 November 2017

Template:Languages Template:TOCright

Installation

Database-script fails because of missing libraries (No Perl YAML)

During the installation process DAViCal runs the database upgrade script in order to apply the correct permissions for the application and dba users to the database tables and sequences. The most common reason that this program might not work is that you don't have the YAML library for Perl installed.

For Debian and related distributions you should install the libyaml-perl and libdbd-pg-perl packages - they should arealdy be there if you installed the .deb because it is a dependency.

For RedHat and related distributions there should be a simple way to find an RPM of the package.

Otherwise you should visit CPAN and install the YAML libraries manually.

  • Note: this error can also occur on Fedora systems even though YAML and DBD::Pg are installed. Type "yum install -y perl-YAML perl-DBD-Pg" (as root) to install them if they're not already present.
  • Note: on OpenBSD 4.8 the DBI module may need to be installed along with YAML and DBD::Pg.

Unix Socket Directory

The PostgreSQL default for the unix_socket_directory variable is /tmp. DAViCal expects the Debian path of /var/run/postgresql. Other distributions and bugs in Debian/Ubuntu can lead you to get the wrong path. Change the unix_socket_directory variable in /etc/postgresql/8.4/main/postgresql.conf.

The error message that would be triggered by this would look something like:

 DBI connect('dbname=davical','davical_dba',...) failed: could not connect to server: No such file or directory 
       Is the server running locally and accepting 
       connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"? at /usr/share/davical/dba/update-davical-database line 244 
 Can't connect to database davical at /usr/share/davical/dba/update-davical-database line 244

You will see this error if the user you are trying to run the

dba/create_database.sh

script as cannot access the database in order to create database users for the application and create the 'davical' database.

No Database Rights

There are several variations on resolving the issue:

  • Database on Local Server (you need to grant access to it)
  • Database on Remote Server (you need to tell the script where it is)

Database on Local Server

If the database for DAViCal is on the local server then you will need to edit the pg_hba.conf file to give appropriate permissions to the database administration user (usually 'davical_dba') as well as giving permissions to the application user (usually 'davical_app').

Note that this only gives permissions for those users to connect to the database. DAViCal will restrict the rights of those database users to the specific minimum access needed for them to do their jobs. The davical_dba user does not need rights to create databases or users, but it does need to own all the tables.

The dba/create_database.sh script will need to be run by a user who does have the right to create users and databases, however. Normally this is the 'postgres' user.

Database on Remote Server or non-default port

If the database is on a remote server then (as well as having to grant permissions, as above) you will need to set a few environment variables (PGPORT, PGHOST, PGCLUSTER) in order that the correct database server is used. Also check out the User Contributions for a modified version of the create_database.sh script.

I have to log in to every page

This indicates that your browser is not getting or accepting the session cookie for some reason. The cause can be several things:

  1. There could be an error message coming from PHP before it sends the "Cookie" header back. Look at the source of the page, or in the webserver error log for clues. Take care not to add any new line characters after ?> in the config file in /etc/davical/*-conf.php! If you have extra characters after the ?> at the end of your DAViCal configuration file you need to remove them. While you're at it, remove the ?> as well so it doesn't happen again! The problem is that this causes the output to the browser to be started before DAViCal has sent it's session cookie. So the browser never receives the session cookie, and never actually manages to log in for more than the single page.
  2. Your browser might be rejecting the cookie. Check in the privacy settings for your browser that it allows the cookie.

I get a blank page

Unfortunately several different reasons can trigger that behaviour.

  1. The most likely cause for this to happen is a typo in one of your PHP configuration pages, like a missing semicolon or an unclosed hyphen.
  2. If you didn't install DAViCal via a package manager check if you meet all the given dependencies.
  3. Check if you indeed created a configuration file for DAViCal (/etc/davical/config.php), also check your symbolic links in that directory if any.
  4. Make sure your configuration is pointing to the right database and you're using the right database name and user.

Finally, your PHP installation might be configured to only interpret scripts in a directory specifically dedicated to web contents (i.e. /var/www) - which is good, btw.

To solve this problem, you must allow PHP to interpret scripts from davical and awl. To do so, just add the following line to a .htaccess file in /usr/share/davical/htdocs or to your VirtualHost configuration:

php_admin_value open_basedir /usr/share/davical:/usr/share/awl/inc:/etc/davical

Note: Some sites mistakenly state that open_basedir "1" is sufficient. It is not, and is frequently the cause of this problem!

Authentication

HTTP authentications fails on me

It seems the username for HTTP-auth needs to be lowercase, even though the username in the admin interface contains uppercase letters. See also this bug report.

If you experience problems authenticating to caldav.php and you have mod_fastcgi or mod_fcgi, please see https://stackoverflow.com/questions/17018586/apache-2-4-php-fpm-and-authorization-headers how to pass on the necessary headers.

DB Errors During Upgrade

Permission Denied errors during Upgrade

Check that you're not facing this Issues/Wrong table owner.

Upgrading from Debian Lenny to Squeeze

If you get blank pages from the server and HTTP 500 errors in the access log but nothing in the error.log after an upgrade from Debian Lenny to Squeeze, check the php_value entries in the virtual host, as the format seems to have changed. The new entries have to look like:

php_value include_path /usr/share/awl/inc
php_flag magic_quotes_gpc off
php_flag register_globals off
php_value error_reporting "E_ALL & ~E_NOTICE"
php_value default_charset "utf-8"