Package Details: baikal 0.7.1-1

Git Clone URL: https://aur.archlinux.org/baikal.git (read-only, click to copy)
Package Base: baikal
Description: Lightweight CalDAV+CardDAV server
Upstream URL: http://sabre.io/baikal/
Licenses: GPL
Submitter: The-Compiler
Maintainer: Martchus
Last Packager: Martchus
Votes: 20
Popularity: 0.49
First Submitted: 2014-01-07 12:12
Last Updated: 2020-06-13 23:18

Pinned Comments

Martchus commented on 2020-01-31 13:47

When updating your PHP, have a look whether Baikal still works and checkout the comments here for possible issues. Any hints/patches from your side are welcome of course, too. PHP is known to break things and it broke Baikal in the past. At the bottom of this comment you also find NGINX configuration snippets to use an older PHP version. Using an older PHP version is likely the best for being on the safe side.


All my packages are managed at GitHub where you can also contribute directly: https://github.com/Martchus/PKGBUILDs
There's also a binary repository, also including older PHP versions: https://wiki.archlinux.org/index.php/Unofficial_user_repositories#ownstuff


head -n 20 /etc/nginx/nginx.conf 
[...]
http {
    include php-handler.conf;
    include php72-handler.conf;
cat /etc/nginx/php.conf 
location ~ ^(/baikal.+?\.php)(/.*)?$ {
  try_files $1 =404;
  include fastcgi.conf;
  fastcgi_pass php72-handler; # handler registered via php72-handler.conf included in nginx.conf
  fastcgi_index index.php;
  fastcgi_param SCRIPT_FILENAME $document_root$1;
  fastcgi_param PATH_INFO $2;
  fastcgi_param HTTPS on;
}
location ~ ^(.+?\.php)(/.*)?$ {
  try_files $1 =404;
  include fastcgi.conf;
  fastcgi_pass php-handler; # handler registered via php-handler.conf included in nginx.conf
  fastcgi_index index.php;
  fastcgi_param SCRIPT_FILENAME $document_root$1;
  fastcgi_param PATH_INFO $2;
  fastcgi_param HTTPS on;
}
cat /etc/nginx/php72-handler.conf 
upstream php72-handler {
  server unix:/run/php72-fpm/php-fpm.sock;
}
cat /etc/nginx/php-handler.conf 
upstream php-handler {
  server unix:/run/php-fpm/php-fpm.sock;
}

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 Next › Last »

BunBum commented on 2014-09-05 06:47

After I made these steps:

# mv /usr/share/webapps/baikal/Specific{,.bak}
<upgrade the package>
# mv /usr/share/webapps/baikal/Specific.bak/db/db.sqlite /var/lib/baikal/db
# rm -r /usr/share/webapps/baikal/Specific.bak


I get following error in my browser:

Baïkal Install Tool is locked.
To unlock it, create (or re-create if it exists already) an empty file named ENABLE_INSTALL (uppercase, no file extension) in the Specific/ folder of Baïkal.


In /var/lib/baikal/ however the file ENABLE_INSTALL exist and is empty.

The-Compiler commented on 2014-09-02 09:17

I finally fixed this and I'm now installing everything to the proper locations. I disagree with the wiki page on the example configs though, and I'm placing them in /usr/share/doc/baikal.

Manual intervention is required for upgrading:

# mv /usr/share/webapps/baikal/Specific{,.bak}
<upgrade the package>
# mv /usr/share/webapps/baikal/Specific.bak/db/db.sqlite /var/lib/baikal/db
# rm -r /usr/share/webapps/baikal/Specific.bak

The-Compiler commented on 2014-08-21 06:53

Sorry for messing this up, and thanks for the contribution. I didn't notice because I use it with MySQL.

I currently don't have time to fix this properly this week, but I'll take care of it next Monday.

Yamakaky commented on 2014-08-20 11:15

/!\ Test

Here is an updated version of the PKGBUILD. May someone test it ? May someone tell me if /var/lib/baikal/ENABLE_INSTALL is deleted after the update ?

http://0bin.net/paste/JLGXj5NYP8sfKPjw#oqiZruSyDqe16DuW5vUQj3bWfJ5OvNhXpDE9u66jOOD

Yamakaky commented on 2014-08-20 09:47

Yes, it was predictable. If the data location isn't configurable, you can also symlink /usr/share/webapps/baikal/Specific/db to /var/lib/baikal/db, and create this directory. And Specific/virtualhosts/* should go to /etc/webapps/baikal/ (like said in the wiki), with maybe a symlink in /usr. The example config files need to be modified, they point to /var/www.

What ? The package contains the database file ? It's a mistake, you must remove it in `package()`.

BunBum commented on 2014-08-20 09:33

"Since baikal doesn't seem to need writable files anyways" => After the update I get the following error in my Browser: "DB file is not writable. Please give write permissions on file '/usr/share/webapps/baikal/Specific/db/db.sqlite'"

Also after every update my data will be overriden. If I didn't made a backup before the update all my contacts would now be lost...

Yamakaky commented on 2014-08-19 17:03

You're welcome!

So where does it store it's data ? Is it configurable ?

The-Compiler commented on 2014-08-19 14:52

Hmm, you are right, didn't think of that.

Since baikal doesn't seem to need writable files anyways, I removed the chown. For my other packages I'll symlink these paths into /var like suggested on https://wiki.archlinux.org/index.php/Web_Application_Package_Guidelines

Thanks!

Yamakaky commented on 2014-08-19 12:17

#1 Well, it seems like an axiom to me. /usr is read-only except for updates, so apps don't have to modify it, so root:root. Data should go in /var.

#2 OK

The-Compiler commented on 2014-08-19 04:17

Yamakaky: Regarding #1: Care to elaborate why? Stuff will most likely break. Even some official arch packages do this.

Regarding #2: This can safely be ignored. SabreDAV comes bundled with Baikal, but that Python-script isn't used anywhere.