The installation documentation is somewhat correct for 0.9.6.1. Actually, including the wiki, I count no less than four guides for handling installation of DAViCal. None of them are completely right. Scary, no?
Here’s a verified working procedure for installing DAViCal on Debian GNU/Linux Etch as of this writing. As indicated at the link above, you’ll need to add a new source for apt. (Feel free to use sudo if it suites you.)
# echo "deb http://debian.mcmillan.net.nz/debian unstable awm" >> /etc/apt/sources.list # apt-key advanced --keyserver subkeys.pgp.net \ --recv-keys CCA377BD77494424B0DB674F8C90347F8F068012 # apt-get update # apt-get install davical
The above should pull down PostgreSQL, PHP, and the necessary Perl DBI dependencies. If you’ve never used PostgreSQL before, now isn’t really the time to learn. Fortunately, the setup script for DAViCal, with a small change, will do all the work for you.
As a quick overview, PostgreSQL has a concept of database roles. Each role can have different privileges. There are two roles involved with DAViCal: davical_dba and davical_app. Both are created by the script create-database.sh. In some DAViCal documentation, you may see instructions to create database users manually. Don’t do this. You don’t need to. Also, there is no longer any such thing as the general user. It’s from an earlier version of libawl-php, which DAViCal depends on.
First let’s correct create-database.sh (the Perl is only needed for <= 0.9.6.1):
# perl -i -pe ‘s/template0/template1/g’ /usr/share/davical/dba/create-database.sh # su – postgres -c /usr/share/davical/dba/create-database.sh No directory, logging in with HOME=/ Supported locales updated. 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 ‘[replaced with per install random passwd]‘” Thanks for trying DAViCal! Check in /usr/share/doc/davical/examples/ for some configuration examples. For help, visit #davical on irc.oftc.net.
Additionally, I needed to change the owner of one of the sequences. I don't know why.
# su - postgres -c "psql -c 'alter table dav_id_seq owner to davical_dba;'"
If for some reason that fails, you'd want to run the following to drop any incompletely populated database and any unnecessary roles:
# su - postgres -c 'psql' postgres=# drop database davical; postgres=# drop role davical_app; postgres=# drop role davical_dba; postgres=# \q #
Assuming nothing fails, you'll be given an admin password for you DAViCal install's web interface. This is uniquely for your install. Copy it somewhere. Don't lose it, or you'll have to recover it somehow. Not losing it myself, I didn't investigate how you'd accomplish that short of starting over again.
Once create-database.sh has had its way with your PostgreSQL install, you need to allow the roles specified in the post install text access to the davical database. There are many ways to handle that, including some in the various instances of the installation documentation. I did the following simply to be different:
# cat /etc/postgresql/8.3/main/pg_hba.conf ... # Database administrative login by UNIX sockets local all postgres ident sameuser local davical davical_app ident davical-app local davical davical_dba ident davical-dba ...
Then I configured mappings for those in pg_ident.conf:
# cat /etc/postgresql/8.3/main/pg_ident.conf ... davical-dba www-data davical_dba davical-app www-data davical_app
Instead, you could simply replace ident in the first file with trust and skip changing the second file altogether. But, I rather enjoy the way ilustrated above. You must restart PostgreSQL for changes to pg_*.conf to take effect.
After all this, if you noticed I am using PostgreSQL 8.3, which is not available in Etch, kudos to you. I am using the version from backports.org for Etch, mostly for access to CREATE OR REPLACE TRIGGER.
Next it's time to configure the beast.
# gunzip \ /usr/share/doc/davical/examples/davical-conf.php/example-config.php.gz -c > \ /etc/davical/davical.host.domain.com-conf.php
You may wish to change a few things, but it's unnecessary to get started.
Finally an Apache configuration is necessary. The ones specified in the installation guides are fine. Everyone has a different flavour, but I stick my configurations in /etc/apache2/sites-available and run
a2ensite to enable.
# Virtual Host def for Debian packaged DAViCal <VirtualHost *:80> DocumentRoot /usr/share/davical/htdocs ServerName davical.example.net Alias /images/ /usr/share/davical/htdocs/images/ 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" </VirtualHost>
At this point, you ought to restart Apache with
apache2ctl graceful and access your new DAViCal URL. You'll be asked to login. The login is admin and the randomly generated password was provided to you earlier during install. You did write it down, yes?
Once inside, the interface is fairly self explanatory. (Maybe not, but it isn't too difficult to figure out.)
If you're trying to get Chandler working with DAViCal, again, the directions aren't entirely correct. First you need to create a new account under File -> Accounts. Using the WebDAV Sharing account type, enter your DAViCal information. The last part of the path is the collection, which can be whatever. As far as I can tell, you need an account for each collection. (Don't be fooled by the account type; Chandler will actually use CalDav if it is supported and running
wireshark confirms it.)
If you want to push entries to DAViCal from Chandler, right click on a collection in the left pane and select Publish... You should find your newly created account listed. Select it and hit Publish. It ought to work. Afterwards, you can choose to Unpublish... if you so choose. Going back to the DAViCal web interface, you can confirm calendar entries are been propgated successfully.
Being new to Chandler, I don't know what actually works, other than publishing. We'll see. (Now if only Python + GTK didn't suck so much to use...)
It appears Chandler picked a new collection name while I slept. The default Work now appears three times. That can't be good.