Arch Linux User Repository

As of 0.11.0 you need to add mysql_ca_cert: '' to /var/lib/baikal/config/baikal.yaml. (You can of course also actually specify a cert instead of an empty string.)

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 although support for older PHP versions is also dropped from time to time from Baikal's 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 phpXX-handler.conf;

cat /etc/nginx/php.conf 
location ~ ^(/baikal.+?\.php)(/.*)?$ {
  try_files $1 =404;
  include fastcgi.conf;
  fastcgi_pass phpXX-handler; # handler registered via phpXX-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/phpXX-handler.conf 
upstream phpXX-handler {
  server unix:/run/phpXX-fpm/php-fpm.sock;
}
cat /etc/nginx/php-handler.conf 
upstream php-handler {
  server unix:/run/php-fpm/php-fpm.sock;
}

(XX is of course supposed to be replaced by the actual PHP version.)

As of 0.11.0 you need to add mysql_ca_cert: '' to /var/lib/baikal/config/baikal.yaml. (You can of course also actually specify a cert instead of an empty string.)

@dimatematik done

Hello, Please update sha512sum of 'baikal.install' in PKGBUILD. The file was changed in recent commit but its hash was not

Hi, I can confirm Baikal 0.8.0 works with php-8.0.3. Tested on a RPi2 with Apache and php-fpm.

Netherless, I had issues following official documentation (https://sabre.io/baikal/install/), so I report here my solution in case it could be usefull for someone else. In the VirtualHost configuration:

• Put a slash at the end of the DocumentRoot path; eg DocumentRoot /var/www/baikal/html/
• AllowOverride directive must be set to All (at least, FileInfo and Limit are required).
• Option FollowSymlinks is required.

The latest version seems to work with php 7.4.14 from [extra]. I haven't tried php 8.0.1 from [testing] yet but release notes and users claim it would work. Nevertheless the pinned comment is still important to keep in mind because who knows what further PHP versions will break.

Is there are reason, that baikal installs the config into /var/lib/baikal/config instead of /etc/webapps/baikal?

For baikal 0.7.2, uncomment extension=iconv.so in php.ini.

I've updated to 0.7.0. It seems to work (not tested with PHP 7.4 though). Baikal now also expects a "config" directory. I've just put it under /var/lib/baikal/config. That is a little bit messy because it means it is within the "Specific" directory. However, this approach keeps it simple.

Also note my previous comment and that https://github.com/sabre-io/Baikal/issues/863 has not been closed yet.

I'm aware that 0.7.0 has been released. I will update the package as soon as I have the time to test the new release.

When I've pushed the new version, be sure to read the official release notes before updating.

Seems like there are even more issues with PHP 7.4: https://github.com/sabre-io/Baikal/issues/863

This issue isn't stopping synchronization in all cases so I haven't recognized it until now. Cherry-picking the change suggested in the issue didn't entirely fix the problem for me. I guess for now it is again a good idea to switch back to an older PHP version. The php72 package is still on my binary repo and I'm going to add php73, too. Like I said in a previous comment, it is very easy to use older PHP versions for some services and the current version for the test. I've added my NGINX config to the sticky comment at the top in case somebody finds it useful. For this package it is likely the less troublesome configuration.

Be sure to trigger the sync on all your devices after switching back to the previous PHP version. At least in my case all missing items got synced automatically again (no hacks like recreating items manually were required).