Installation Experiences
From DAViCal Wiki
Contents |
Install on Scientific Linux 4.1
(SL =~ RHEL/CENTOS)
System includes:
- postgresql-server-7.4.17-1.RHEL4.1
- httpd-2.0.59-1.el4s1.8.el4.centos
- php-4.3.9-3.22.9
Note: Apache prior to 2.0.56 does not properly support OPTIONS, so we used a CENTOS package rather than the current SL one
Add
- rscds-0.9.2-2.noarch.rpm
- libawl-php-0.22-2.noarch.rpm
Add virtual host to httpd.conf as per installation page. Reload httpd.
create database
# service postgresql start # su postgres -c /usr/share/davical/dba/create-database.sh
edit /var/lib/pgsql/data/pg_hba.conf; make sure to not have trailing blank line! Use database name davical
$c->pg_connect[] = 'dbname=davical port=5432 user=davical_app';
reload postgres: {{{service postgresql reload}}}
- Now admin PHP page works; can add users. Can look at database, e.g.
# su postgres $ psql davical -c 'select username, password from usr;' $ pg_dumpall|less
Install on Gentoo
I had to change
createuser --no-createdb --no-createrole "${1}"
to
createuser --no-createdb --no-adduser "${1}"
on line 41 of createdb
Install on Kubuntu with Postgres 8.3
There were major problems with Postgres permissions, but YEA!
- Anyway, this is from the start to actually being able to login.
- DISCALIMER - as always E&OE, and I have yet to actually try using - this is just the install.
- I use kate under root (Run -> kedsu kate) so the configuration files are automatically saved as root-root
# /etc/apt/sources.list # SERVER - Install LDAP AddressBook # sudo apt-key advanced --keyserver subkeys.pgp.net --recv-keys CCA377BD77494424B0DB674F8C90347F8F068012 deb http://debian.mcmillan.net.nz/debian unstable awm
sudo apt-key advanced --keyserver subkeys.pgp.net --recv-keys CCA377BD77494424B0DB674F8C90347F8F068012 sudo aptitude update sudo aptitude install -y davical # DAViCal CalDAV Server
You can change the include path for PHP by editing /etc/php5/apache2/php.ini and adding in /usr/share/awl/inc or you can crudely symlink them all into the DAViCal include directory like this:
cd /usr/share/davical/inc ln -s /usr/share/awl/inc/* .
Postgres 8.3
# /etc/postgresql/8.3/main/pg_hba.conf local davical davical_app trust
- This is where the major problems occurred - I did delete the database/users and did it again with these commands.
- That line *MUST* be at the top of the pg_hba.conf file.
sudo -i # Become User root su postgres # Become User postgres createuser --no-createdb --no-createrole --no-superuser davical_app createuser --no-createdb --no-createrole --no-superuser davical_dba psql -U postgres -c "GRANT davical_dba TO postgres" createdb --encoding UTF8 --template template0 --owner davical_dba davical /usr/share/rscds/dba/create-database.sh exit # From User postgres sudo /etc/init.d/postgresql-8.3 restart
- If you continue to have permission problems, check /var/log/postgresql/postgresql-8.3-main.log
- If you are getting EST FATAL: Ident authentication failed for user "www-data", then you haven't specified the correct user in your /etc/davical/*.conf file's $c->pg_connect[] assignment statement.
- If you are getting EST FATAL: Ident authentication failed for user "davical_app", then need to modify your ph_hba.conf file. Make sure the davical_app trust line appears at the *BEGINNING* of the file.
- Note: When a client connects to the database, hosts/rules listed are processed in order until one matches and the client is allowed or denied. So, when editing the pg_hba.conf file, put the trust lines (shown here) before the other rules. Webmin's Postgres module will display the problem visually and easily allow you to reorder the rules.
- You should be able to test connectivity from an account that doesn't have a role with: $ psl davical davical_app
Apache2
- I think the postgres standard is shifting towards the /etc/apache2/conf.d directory
# /etc/apache2/conf.d/davical # DAViCal Alias /cal/ /usr/share/davical/htdocs/
/etc/init.d/apache2 restart
DAViCal
sudo mkdir -p -v /etc/davical
# /etc/davical/<domain>-conf.php <?php // /etc/davical/<domain>-conf.php // $c->domain_name = "calendar.example.net"; // $c->sysabbr = 'davical'; $c->admin_email = 'admin@example.net'; $c->system_name = "DAViCal CalDAV Store"; // $c->collections_always_exist = true; // $c->enable_row_linking = true; // $c->default_locale = en_NZ.UTF-8; $c->pg_connect[] = 'dbname=davical port=5432 user=general'; ?>
- Yes, I connected from localhost and (my LAN) server1
# WARNING: the "-quotes are required ln -s "/etc/davical/<domain>-conf.php" localhost-conf.php ln -s "/etc/davical/<domain>-conf.php" /etc/davical/server1-conf.php
http://localhost/cal/ # and Good Luck
Change the password? admin-user?
su postgres psql -d davical -c "UPDATE usr SET password = '**abcdef' WHERE user_no=1;" psql -d davical -c "UPDATE usr SET username = 'admin1' WHERE user_no=1;" exit # From User postgres
Trailing newline in config
Never have a trailing newline in your config, better don't close the <?php bracket at all. This innocent-looking newline is copied to the xml data stream with Sunbird complaining about "xml declaration not at start of external entity".
Mistreated like this, Sunbird will happily add new entries to the calendar, but fail to reload them. I've seen numerous reports all over the net that might actually be caused by this.
Install on a Hosted Server
These notes describe how to install davical on a hosted server, that is, a server which does not provide root access and possibly, shell access. This typically prevents using virtual hosting which is the standard method of operation of davical. Likewise writing to /etc/davical isn't usually possible and the installation scripts may not be able to run. Additional issues can include that the name of the postgresql database and users may be enforced to be a particular format, when the server is hosting multiple sites.
There are two steps to the installation, setting up the PostgreSQL database and installing the PHP files.
Setting up the PostgreSQL database
Usually the standard davical installation script dba/create-database.sh creates and populates the required PostgreSQL databases. However, the server may not provide full access to all the PostgreSQL administration tools, or allow scripts to be run.
On some hosted servers, PostgreSQL database and user naming must meet a certain format, for example, no underscores are allowed in the username after the unix username, so username_davical and username_davicalapp respectively are required. You will need to edit the dba/create-database.sh script or run the commands in the script individually. Often the PostgreSQL databases may need to be created using a web admin application (e.g phpPgAdmin), not using the shell script. The new names of the database and database user will need to be changed in the config.php file (described below).
Installing the PHP files
On systems such as cPanel controlled servers, it is possible to define a subdomain. For example, calendar.example.com can be defined to refer to a directory path differing from www.example.com. Assuming the server has a directory structure similar to:
- /home/example/ # Where the hosted site user account resides (referred to as "~" below).
- ~/public_html # Where the web pages reside.
It is recommended to create the following directories
- ~/calendar/htdocs/
- ~/calendar/inc/
- ~/calendar/dba/
- ~/calendar/config
Upload all the files from the htdocs, inc and dba directories in the davical distribution into ~/calendar/htdocs, ~/calendar/inc and ~/calendar/dba directories on the server respectively. Upload all the files from the inc directory of the awl distribution that matches davical to ~/calendar/inc also.
You need to copy example.com-conf.php and edit the file to match your previously defined database location and users for the$c->pg_connect[]variable, then upload the file as ~/calendar/config/config.php.
Define the subdomain calendar.example.com using the appropriate web application supplied by your hosting company. Define calendar.example.com to access files in ~/calendar/htdocs.
You will need to be super user to create the plsql procedural language. In my case, I had to beg my sysadmin to set the procedural language on my database.
You will need Perl in order to run the configuration scripts. The scripts require the Perl libraries DBD::Pg and DBD::YAML. Most systems should have these, but on the cPanel server I was working with, it doesn't come installed (for security), requiring begging the sysadmin to install it for you. However, other than the initial configuration, Perl isn't required for normal running of the system. However the update script update-davical-database requires Perl in order to run.
