Ubuntu/Karmic

These instructions are for DAViCal ver. 0.9.8, which is a major rewrite of DAViCal. (This new version is not available in the Ubuntu Jaunty/Karmic/Lucid repositories.) It is complex and more powerful, but somewhat more difficult to understand than the older version.

The instructions for ver. 0.9.7 (from the Ubuntu Jaunty/Karmic/Lucid repositories) are here.

= DAViCal Calendar Server = DAViCal is a CalDAV, postgreSQL, Apache and php-based shared Calendar server that works with Mozilla Thunderbird/Lightning/Sunbird, Evolution, and other calendar clients. sudo apt-get install davical
 * If you wish to use the the older version (0.9.7) from the Ubuntu repositories:


 * Install the newest version (> 0.9.8) from the DAViCal repositories:

sudo apt-key advanced --keyserver pgp.net.nz --recv-keys F6E0FA5CF0307507BB23A512EAFCFEBF8FEB8EBF echo " deb http://debian.mcmillan.net.nz/debian lenny awm " | sudo tee /etc/apt/sources.list.d/davical.list sudo apt-get update sudo apt-get install davical


 * Note: Port 11371 must be open in the firewall to allow the keyserver.

The following detailed instructions are duplicated and updated on the DAViCal website.

Introduction
DaviCal has been included in the Ubuntu repositories as a .deb package.

The instructions below are for a new user with a new Ubuntu Server installation. (Obviously, if you are already using the Ubuntu Server, you will probably have done many of the steps already.)

Preliminary Requirements
It is easiest to install the components at the time of the Ubuntu Server installation.

Select the PostgreSQL database task and the LAMP (Linux, Apache2, MySQL5, PHP) tasks at the time of the server install.

At a minimum, you will need PostgreSQL (see below), Apache2 (see below), and PHP. You can install PHP separately (i.e. not part of the integrated LAMP stack), if you wish, following these Ubuntu instructions.

Set up the PostgreSQL database
sudo apt-get install postgresql
 * See these Ubuntu instructions. Use the Hardy Installation instructions (for PostgreSQL 8.3) as well as the Basic Server Setup instructions for Gutsy/Hardy. In short, install (if you already haven't):

Basic Server Setup: sudo -u postgres psql postgres

Set a password for the postgres superuser: \password postgres


 * (You may need to quit using \q when you are done).


 * (Note: You could also generate a random password and use it here. Just be sure to record it in an accessible location.)

Create the first database: sudo -u postgres createdb mydb

Install the DaviCal package from repositories
sudo apt-get install davical

Set up DaviCal PostgreSQL users
sudo su su postgres -c "createuser davical_app" exit
 * Create the DaviCal users (first becoming the the system root superuser, using sudo su, then becoming the database superuser, postgres):

You will get asked about superusers, roles and databases, but just say "No" to all questions. This functional ID needs only minimum rights. Repeat the process to create one more user, "davical_dba":

sudo su su postgres -c "createuser davical_dba" exit

Note: In the (older) main DAViCAL site installation page, the user created at this step is "general." This account name is for older versions. You do not need to create a user named "general" any longer.

sudo nano /etc/postgresql/8.4/main/pg_hba.conf
 * Edit the configuration file pg_hba.conf:


 * Add the following 4 lines near (or at) the top;

local all all trust local davical davical_dba trust local davical davical_app trust host davical davical_app 127.0.0.1/32 trust

(The last line is for accessing the database over TCP/IP, assuming the database and the apache2 server are on the same computer. See here under "Connecting to the Database" for more details.)

sudo /etc/init.d/postgresql-8.4 restart
 * Restart the postgreSQL server:

Setup the DaviCal database
sudo su su postgres -c /usr/share/davical/dba/create-database.sh exit
 * Run the database creation/installation script:

Write down the admin password when it is displayed. You will need it later.

sudo nano /etc/postgresql/8.4/main/pg_hba.conf
 * Once the creation script has run correctly, again edit the pg_hba.conf file:
 * and remove the line

local all all trust

(This step is not strictly necessary for the installation, but do you really want anybody with a local account to have free access to all the databases?)

sudo /etc/init.d/postgresql-8.4 restart
 * Restart the database daemon:

Test that your database creation was successful
sudo su su postgres psql davical davical=# \z davical=# \q exit exit

You should see a table with a list of access permissions to "davical_dba". (Typing "\q" exits pqsl.)

Set up Apache2
Install the Apache2 webserver, if you have not done so already. See the Ubuntu documentation for help. sudo apt-get install apache2

In your router settings (assuming you have one), set your port forwarding so that your port 80 (http) and 443 (https) is forwarded to your server. Make sure your server firewall (if you have one) allows incoming ports 80 and 443.

I set up a dynamicDNS URL name at DynDNS.org called mydavicalsite.dyndns.org, which gets forwarded to my router's IP address by DynDNS.org. (My router happens to keep the DynDNS settings updated.) I want this to be forwarded to the server on my LAN.

I therefore created a virtual host setup in the Apache2 schema by copying the default virtualhost settings file to a new virtualhost settings file for mydavicalsite: sudo cp /etc/apache2/sites-available/default /etc/apache2/sites-available/mydavicalsite

I edited the virtualhost config file: sudo nano /etc/apache2/sites-available/mydavicalsite

so that these lines were used (instead of the original ones): #  DocumentRoot /usr/share/davical/htdocs DirectoryIndex index.php index.html ServerName mydavicalsite.dyndns.org ServerAlias calendar.mydavicalsite.dyndns.org Alias /images/ /usr/share/davical/htdocs/images/  AllowOverride None Order allow,deny Allow from all  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" 
 * 1) Virtual Host def for Debian package DAViCal

To then make the virtualhost file active, I made a symbolic link from the virtualhost configuration file in the apache2 "sites-available" folder to the apache2 "sites-enabled" folder: sudo ln -s /etc/apache2/sites-available/mydavicalsite /etc/apache2/sites-enabled/mydavicalsite

Then restart apache2: sudo /etc/init.d/apache2 restart

Create your configuration file
Edit your own configuration file in /etc/davical. (Use your own domain name instead of the one in the example, of course.): sudo nano /etc/davical/mydavicalsite.dyndns.org-conf.php

You can merely include the following lines: admin_email = 'admin@example.net'; $c->system_name = "DAViCal CalDAV Server"; $c->pg_connect[] = 'dbname=davical port=5432 user=davical_app';

Start up DaviCal
From your browser, go to http://mydavicalsite.dyndns.org
 * or

http://mydavicalsite.dyndns.org/cal

Use admin as your initial login, and the password assigned to you at installation (you did write it down, didn't you?)

(See here if you forgot your password. In brief:

>sudo su >su postgres >psql davical -c 'select username, password from usr;'

Only the initial "admin" password is stored in plain text. All subsequent users have their password stored in an encrypted state. If you change the admin password through the web interface it will also be encrypted from that point forward.)

sudo ln -s /etc/davical/mydavicalsite.dyndns.org-conf.php /etc/davical/localhost-conf.php sudo ln -s /usr/share/davical/htdocs /var/www/davical
 * Optionally copy a configuration file for testing on the localhost server (this did not work correctly for me, though):
 * Then you can also log through localhost using your browser:

http://localhost/davical

Create TestUser
I created a testuser (that was not an administrator) using the admin login (above), and gave it a password davtest. I created a calendar, using the default location /testuser/home


 * (Note: You could also generate a random password and use it here. Just be sure to record it in an accessible location.)

I then installed both Sunbird sudo apt-get install sunbird

and Thunderbird with Lightning: sudo apt-get install thunderbird lightning-extension

Making sure that my firewall wasn't blocking any ports (while testing), or at least allowed 80 and 443 through, I created a new network calendar in both Sunbird and Thunderbird.
 * Sunbird -> File -> New Calendar... -> On the Network -> CalDAV ->
 * Location: http://mydavicalsite.dyndns.org/caldav.php/testuser/home ->
 * Name: testuser


 * Thunderbird -> Calendar -> Calendar -> New Calendar... -> On the Network -> CalDAV ->
 * Location: http://mydavicalsite.dyndns.org/caldav.php/testuser/home
 * Name: testuser

I then entered a calendar entry in Sunbird. I then reloaded the remote calendar:
 * Sunbird -> File -> Reload Remote Calendars

and when I did the same in Thunderbird Calendar
 * Thunderbird -> Calendar -> Reload button

then the two calendars were synchronized and both showed the same events.

Voila! Shared calendars.

Administer users
If I made an error in a user setup (from the DaviCAL web interface as the admin user), to correct it I had to make the user inactive and then activate him/her again, at which time I could change the settings.

I had to make a user Public if I wanted to view his/her calendar. The "relationships" are discussed on other pages.

User roles
In DAViCal 0.9.8 onwards, users are referred to as 'Principals'. A "user" is really a type of account. There are three types of "Principal" in DAViCal. Not all of them represent individual users.


 * Person: This is an individual user. Every individual user who wants to have an individual calendar must have a Person account.


 * Group: This type of account is meant as a placeholder for mediating access. It acts as a user in some ways, but it is not intended to be an individual user's account. Privileges will usually be granted to a group, in order that the group can grant privileges on to many individuals.


 * Resource: This is an account for a shared calendar, such as for booking a meeting room, or an office vehicle. Various resources will usually grant privileges to a Group (or directly to a Person) must have a "relationship" with the resource to administer the group calendar associated with it.

Additionally, a user may be set as an 'Administrator'. These users administer the DAViCal database by logging into the administration web interface. It is the only type of user that can create new users and change their status (e.g. "active" vs. "inactive"). Users who are set to 'inactive' can no longer log into DAViCal.

Grants and Permissions Example

 * More information is at the DAViCal website.

I have a sensitive PowWow group calendar which I want to share with different users.

Using the web administration interface and the initial "admin" account (see above), I first create a new Person (account) named BigChief. He does not have his own calendar.

There are seven new "Public" users (each with their own calendar by default) that I then create through the web interface (using either my original admin or new 'BigChief' admin account). The seven Public users are Chief1, Chief 2, Indian1, Indian2, Squaw1, Squaw2, and Janitor.

Again through the administration web interface, I then set up a new 'Group' account, with a username of "Braves". In this account I grant ALL privileges to each of the members (Indian1 and Indian2) which confers full rights to each member (Indian1 and Indian2) in the Group to do whatever the Group Braves can do.

I then set up a second Group user account with a username of "Squaws." Again I create a grant of ALL privileges to each user (i.e. Squaw1 & Squaw2).

Once more through the administration web interface, I set up a new 'Resource' account, which will contains the actual group calendar. I name this user "PowWowCalendar" (which is what I want to call the group calendar).

For PowWowCalendar, I want BigChief to administer it, so I create a grant, giving ALL privileges to BigChief. I want Chief1 and Chief2 to read and change the PowWowCalendar directly. I therefore add another grant to each individually, giving them write, read and free/busy privileges. Since these Chiefs can also send/respond to meeting invitations on behalf of the group in general I also give the chiefs schedule privileges, although DAViCal will not support that feature until 0.9.9 is released.

I then want all the Indians in the Braves group to also be able to read and change this group calendar resource, so I create two more grants, to the 'Braves' and 'Squaws' groups, conferring write, read and free/busy privileges also.

Lastly, I don't want the Janitor to see the actual details of the calendar, but I do want him to know when the meetings are happening. And in fact I don't mind if anyone else in the organisation can see when the meetings are, so I set the Default Privileges to 'Free/Busy'.

Now I have to set up the clients.

Each real user (Chief1, Chief 2, Indian1, Indian2, Squaw1, Squaw2, and Janitor) will set their own user/password combination in their own calendar client. Then each will create a new CalDAV calendar "on the network" (see above for Sunbird/Thunderbird/Lightning instructions) with the location
 * http://mydavicalsite.dyndns.org/caldav.php/PowWowCalendar/home

Each user should then be able to see the resource calendar with the privileges assigned above.

Clients
Multiple Email/Calendar/PIM clients work with DAViCal. See this list, although almost all CALDAV-compatible clients will work.

Mozilla Sunbird / Thunderbird with Lightning
Mozilla Sunbird is a standalone calendar application, while Lightning is a plugin for the email program Thunderbird which is made to work almost identically to Sunbird (but from within Thunderbird, of course).

Idiosyncracies of Sunbird and Thunderbird Lightning
There are two ways to use Sunbird (or the Lightning Extension for Thunderbird): without a saved user name / password combination, or with one. The first is to leave the user name / password unsaved. This will require that you enter the user name / password each time you log in (which can be tiresome, eventually). If using a computer with many users, this is desirable. When prompted to enter the user name and password, merely do not tick the box prompting whether to save the user name /password.

The second method involves saving the user name / password when prompted. However, Sunbird only likes one saved user name. If there are more than one, it will not know which user name to use when logging in to the server. Therefore, do not attempt to save more than one user name / password.

When a user has subscribed to many calendars, that user can view one or many calendars (for which the user has privileges) at the same time by individually checking or unchecking the boxe next to each calendar name.

However, changes made from the calendar screen itself will only apply to the calendar which is highlighted (in the calendar list), whether or not that calendar's box is actually checked.

To view the calendar (and the changes), however, the calendar must also be checked. It is therefore possible to add/change events to a highlighted calendar but not be able to see the changes (if you have that calendar's name highlighted but not checked).

This point can't be stressed enough -- changes to the calendar are applied to whichever calendar is highlighted, but to see the changes, the calendar must also be checked.

Kontact
Kontact is the personal information manager for KDE (used in Kubuntu). There are some instructions on the DAViCal website, but despite the warnings there, the calendar functions of the current version of Kontact work very nicely with DAViCal. In brief:


 * Add a new calendar:
 * Kontact ->  Calendar -> Add... -> Calendar in remote file
 * (in French: "Calendrier dans un fichier distant")
 * Use the same URL for "Download from" and "Upload to"
 * Example: http://calendar.example.com/caldav.php/user/home


 * The calendar must exist in order to use it, of course, or Kontact will send an error (such as "file http://calendar.example.com/caldav.php/user/home does not exist"). You must create the calendar using the DAViCal web-based administration interface.


 * These instructions apply to both Kontact and Korganizer.

Evolution
See the DAViCal website for some details. I haven't used Evolution with DAViCal, so if you have, please add your experience here.