Ubuntu/Lucid

These instructions are for DAViCal ver. 0.9.8, which is a major rewrite of DAViCal. (The original 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.

PostgreSQL 8.4
I had no problem with PostgreSQL 8.4 on a new Lucid installation. In Lucid, PostgreSQL 8.4 is the default and is installed: sudo apt-get install postgresql

Install PostgreSQL 8.3 in Lucid
Some users seem to have a problem when upgrading from PostgreSQL 8.3 to PostgreSQL 8.4 (as when upgrading from Karmic to Luicd, for example). It is possible to install PostgreSQL 8.3 in Lucid. See this Ubuntu forum thread and this Ubuntu forum thread.


 * In short, temporarily add the repositories for Karmic by adding to the repository list:

deb http://archive.ubuntu.com/ubuntu/ karmic main restricted universe deb-src http://archive.ubuntu.com/ubuntu/ karmic main restricted universe

and install (if you already haven't): sudo apt-get install postgresql-8.3

(Once the program has been installed, you can then remove the Karmic repositories, if you choose). Obviously, if you do this, replace postgresql-8.4 in the instructions below with postgresql-8.3.

Set up PostgreSQL database

 * Refer to these Ubuntu instructions. Use the Hardy Installation instructions (for PostgreSQL 8.3) as well as the Basic Server Setup instructions for Gutsy/Hardy.

sudo -u postgres psql postgres
 * Basic Server Setup:

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
 * Install the older version 0.97 from the Ubuntu repositories:


 * or


 * 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.

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.

Upgrading from earlier versions

 * See these upgrade notes.

Attempts to upgrade DAViCal database from PostgreSQL 8.3 to PostgreSQL 8.4 (not working)
During an upgrade from Karmic to Lucid, PostgreSQL is upgraded from 8.3 to 8.4. When this happens, a DAViCal configuration initially set up with PostgreSQL 8.3 often won't run. The simplest solution is to reinstall PostgreSQL 8.3.

My method for doing this (different from the solutions above) is to


 * Backup the p/var/lib/postgresql/8.3/ folder (to be used later):

zip -9 -r ~/postgresql-8.3.zip /var/lib/postgresql/8.3


 * Erase the old main cluster (to be restored later):

sudo rm -rf /var/lib/postgresql/8.3


 * Remove old configuration files:

ls /var/lib/dpkg/info | grep "postgresql-8.3" rm /var/lib/dpkg/info/postgresql-8.3.* rm -rf /etc/postgresql


 * Reinstall PostgreSQL 8.3:

sudo apt-get install postgresql-8.3 postgresql-client-8.3 postgresql-client-common postgresql-client


 * Stop PostgreSQL 8.4 and start PostgreSQL 8.3

sudo /etc/init.d/postgresql-8.3 stop sudo /etc/init.d/postgresql-8.3 start


 * Recreate the "main"cluster

pg_createcluster 8.3 main --start Creating new cluster (configuration: /etc/postgresql/8.3/main, data: /var/lib/postgresql/8.3/main)... Moving configuration file /var/lib/postgresql/8.3/main/postgresql.conf to /etc/postgresql/8.3/main...  Moving configuration file /var/lib/postgresql/8.3/main/pg_hba.conf to /etc/postgresql/8.3/main...  Moving configuration file /var/lib/postgresql/8.3/main/pg_ident.conf to /etc/postgresql/8.3/main...  Configuring postgresql.conf to use port 5432...


 * Reinject the trust for davical, put "trust" to "all" and to "postgress" also

sudo nano /etc/postgresql/8.3/main/pg_hba.conf

and edit:

--- # TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD local davical davical_dba trust local davical davical_app trust /etc/init.d/postgresql-8.3 restart


 * As postgres user recreate a DAViCal databse :

su postgres /usr/share/davical/dba/create-database.sh /usr/share/davical/dba/update-davical-database exit


 * In /etc/postgresql/8.3/main/postgresql.conf the port is 5432 so edit the \*.conf, so verify that the port is 5432 in the conf file of the 8.3 server:

sudo nano /etc/postgresql/8.3/main/postgresql.conf

5432, ok sudo nano /etc/davical/calendar.foo.bar-conf.php ---  $c->pg_connect[] = 'dbname=davical port=5432 user=davical_app'; ---


 * Restore backed-up files:

exit # to normal user, since we're in root.

When normal user again, the backup file is here. unzip postgresql-8.3.zip -d ~/backup/

sudo rm ~/backup/postgresql-8.3/var/lib/postgresql/8.3/main/\*.key sudo rm ~/backup/postgresql-8.3/var/lib/postgresql/8.3/main/\*.crt

in /etc/postgresql/8.3/main/postgresql.conf it say that the data are in /var/lib/postgresql/8.3/ Before copy files in /var/lib we need to change permissions

chown -R root: /var/lib/postgresql/8.3 cp -r ~/backup/postgresql-8.3/var/lib/postgresql/8.3/main /var/lib/postgresql/8.3/ chown -R postgres: /var/lib/postgresql/8.3 /etc/init.d/postgresql-8.3 restart /usr/share/davical/dba/update-davical-database --dbuser=davical_dba /etc/init.d/postgresql-8.3 restart

And the 8.3 is running again, I hope, for me it works!

I've tried to upgrade those to 8.4 but it fails with errors.

pg_dropcluster 8.4 main Error: specified cluster does not exist pg_upgradecluster 8.3 main Creating new cluster (configuration: /etc/postgresql/8.4/main, data: /var/lib/postgresql/8.4/main)... Moving configuration file /var/lib/postgresql/8.4/main/postgresql.conf to /etc/postgresql/8.4/main...  Moving configuration file /var/lib/postgresql/8.4/main/pg_hba.conf to /etc/postgresql/8.4/main...  Moving configuration file /var/lib/postgresql/8.4/main/pg_ident.conf to /etc/postgresql/8.4/main...  Configuring postgresql.conf to use port 5433...  Disabling connections to the old cluster during upgrade...  Disabling connections to the new cluster during upgrade...  Roles, databases, schemas, ACLs...  Fixing hardcoded library paths for stored procedures...  Upgrading database davical... pg_restore: [programme d'archivage (db)] Erreur pendant le traitement de la TOC (« PROCESSING TOC ») : pg_restore: [programme d'archivage (db)] Erreur à partir de l'entrée TOC 2079 ; 0 16513 TABLE DATA caldav_data davical_dba pg_restore: [programme d'archivage (db)] COPY failed: ERREUR: une instruction insert ou update sur la table « caldav_data » viole la contrainte de clé étrangère « caldav_data_collection_id_fkey » DÉTAIL : La clé (collection_id)=(11) n'est pas présente dans la table « collection ». pg_restore: [programme d'archivage (db)] Erreur à partir de l'entrée TOC 2081 ; 0 16548 TABLE DATA calendar_item davical_dba pg_restore: [programme d'archivage (db)] COPY failed: ERREUR: une instruction insert ou update sur la table «   calendar_item » viole la contrainte de clé étrangère « caldav_exists » DÉTAIL : La clé (user_no,dav_name)=(1002,/foo/home/c1861408-bc88-11de-ae93-000a95aadd7e.ics) n'est pas présente dans la table « caldav_data ». pg_restore: [programme d'archivage (db)] Erreur à partir de l'entrée TOC 2078 ; 0 16495 TABLE DATA collection davical_dba pg_restore: [programme d'archivage (db)] COPY failed: ERREUR: une instruction insert ou update sur la table « collection » viole la contrainte de clé étrangère « collection_user_no_fkey » DÉTAIL : La clé (user_no)=(1004) n'est pas présente dans la table « usr ». pg_restore: [programme d'archivage (db)] Erreur à partir de l'entrée TOC 2090 ; 0 25062 TABLE DATA grants davical_dba pg_restore: [programme d'archivage (db)] COPY failed: ERREUR: une instruction insert ou update sur la table « grants » viole la contrainte de clé  étrangère « grants_by_principal_fkey » DÉTAIL : La clé (by_principal)=(933) n'est pas présente dans la table « principal ». pg_restore: [programme d'archivage (db)] Erreur à partir de l'entrée TOC 2089 ; 0 25043 TABLE DATA principal davical_dba pg_restore: [programme d'archivage (db)] COPY failed: ERREUR: une instruction insert ou update sur la table « principal » viole la contrainte de clé étrangère « principal_type_id_fkey » DÉTAIL : La clé (type_id)=(1) n'est pas présente dans la table « principal_type ». pg_restore: [programme d'archivage (db)] Erreur à partir de l'entrée TOC 2085 ; 0 16621 TABLE DATA property davical_dba pg_restore: [programme d'archivage (db)] COPY failed: ERREUR: une instruction insert ou update sur la table « property » viole la contrainte de clé étrangère « property_changed_by_fkey » DÉTAIL : La clé (changed_by)=(1003) n'est pas présente dans la table « usr ». pg_restore: [programme d'archivage (db)] Erreur à partir de l'entrée TOC 2083 ; 0 16591 TABLE DATA relationship davical_dba pg_restore: [programme d'archivage (db)] COPY failed: ERREUR: une instruction insert ou update sur la table « relationship » viole la contrainte de clé étrangère « relationship_from_user_fkey » DÉTAIL : La clé (from_user)=(1002) n'est pas présente dans la table « usr ». pg_restore: [programme d'archivage (db)] Erreur à partir de l'entrée TOC 2074 ; 0 16440 TABLE DATA role_member davical_dba pg_restore: [programme d'archivage (db)] COPY failed: ERREUR: une instruction insert ou update sur la table « role_member » viole la contrainte de clé étrangère « role_member_role_no_fkey » DÉTAIL : La clé (role_no)=(1) n'est pas présente dans la table « roles ». pg_restore: [programme d'archivage (db)] Erreur à partir de l'entrée TOC 2075 ; 0 16455 TABLE DATA session davical_dba pg_restore: [programme d'archivage (db)] COPY failed: ERREUR: une instruction insert ou update sur la table « session » viole la contrainte de clé étrangère « session_user_no_fkey » DÉTAIL : La clé (user_no)=(1) n'est pas présente dans la table « usr ». pg_restore: [programme d'archivage (db)] Erreur à partir de l'entrée TOC 2091 ; 0 25084 TABLE DATA sync_tokens davical_dba pg_restore: [programme d'archivage (db)] COPY failed: ERREUR: une instruction insert ou update sur la table «   sync_tokens » viole la contrainte de clé étrangère « sync_tokens_collection_id_fkey » DÉTAIL : La clé (collection_id)=(1) n'est pas présente dans la table « collection ». pg_restore: [programme d'archivage (db)] Erreur à partir de l'entrée TOC 2076 ; 0 16472 TABLE DATA tmp_password davical_dba pg_restore: [programme d'archivage (db)] COPY failed: ERREUR: une instruction insert ou update sur la table «  tmp_password » viole la contrainte de clé étrangère « tmp_password_user_no_fkey » DÉTAIL : La clé (user_no)=(1001) n'est pas présente dans la table « usr ». ATTENTION : erreurs ignorées lors de la restauration : 11 Analyzing database davical... Fixing hardcoded library paths for stored procedures...  Upgrading database postgres...  Analyzing database postgres...  Fixing hardcoded library paths for stored procedures...  Upgrading database template1...  Analyzing database template1...  Re-enabling connections to the old cluster...  Re-enabling connections to the new cluster...  Copying old configuration files...  Copying old start.conf...  Copying old pg_ctl.conf...  Stopping target cluster...  Stopping old cluster...  Disabling automatic startup of old cluster...  Configuring old cluster to use a different port (5433)...  Starting target cluster on the original port...  Success. Please check that the upgraded cluster works. If it does, you can remove the old cluster with pg_dropcluster 8.3 main

Also tried to dump and restore, no chance, so for now I use the 8.3.

But I've see that the permissions in the users profile are not good in the http interface. Perhaps it was the reason that the 8.4 upgrade is not working. The permissions looks like that following table:

Restore 8.3 database in 8.4 (working)
After multiple tries, I found a simple way to update from 8.3 to 8.4. As it seems the "pg_upgradecluster 8.3 main" default command line is not working well.


 * It's required to have the two PostgreSQL versions both installed in order to do it.


 * In a fresh install, with the 8.4 started, create the "main" cluster.

/etc/init.d/postgresql-8.4 stop /etc/init.d/postgresql-8.3 stop /etc/init.d/postgresql-8.3 start pg_dropcluster 8.4 main pg_createcluster 8.4 main --start


 * Stop the 8.3 server, start the 8.4, pg_dump, and restore with psql

/etc/init.d/postgresql-8.4 stop /etc/init.d/postgresql-8.3 stop /etc/init.d/postgresql-8.3 start sudo -u postgres /usr/lib/postgresql/8.3/bin/pg_dump davical > /tmp/davical-8.3.pgdump /etc/init.d/postgresql-8.3 stop /etc/init.d/postgresql-8.4 stop /etc/init.d/postgresql-8.4 start sudo -u postgres /usr/lib/postgresql/8.4/bin/psql -c "CREATE DATABASE davical" sudo -u postgres /usr/lib/postgresql/8.4/bin/psql -d davical -f /tmp/davical-8.3.pgdump /usr/share/davical/dba/update-davical-database The database is version 8.4 currently at revision 1.2.8. No patches were applied. Supported locales updated. Updated view: dav_principal.sql applied. CalDAV functions updated. RRULE functions updated. ATTENTION: aucun droit n'a été accordé pour « dav_id_seq » Database permissions updated. /etc/init.d/postgresql-8.4 restart

I think we need to check the permissions in the http interface. And I don't known what the `WARNING: no right has been granted for "dav_id_seq"` means and if it affects DAViCAL usage!

A look in the database, and a psql command on it to check the permissions in the "dav_id_seq" give me that:

psql -d davical -U davical_dba psql (8.4.4) Saisissez « help » pour l'aide. davical=> \z dav_id_seq Droits d'accès Schéma |   Nom     |   Type   |      Droits d'accès      | Droits d'accès à la colonne ++--+--+- public | dav_id_seq | séquence | postgres=rwU/postgres    | : davical_app=rw/postgres : davical_dba=rwU/postgres (1 ligne)