Baikal: Blank browser page version 0.5.3 to 0.6.x

[whowantsmybigdata]

Baikal version: 0.6.x

• [x] I have searched open and closed issues for duplicates, issues #860, #824 seems similar but doesn't fix my problem
• [x] I have installed the release zip, not the source code zip
• [x] I have moved the whole, untouched Specific folder to the new installation

Problem:
First: thanks for the great work! Am using baikal for years with my rasperry pi and till now everything worked flawlessly!!
Now I wanted to upgrade from version 0.5.3 to 0.6.1 and all I get is a blank webpage when trying to open the admin-panel-login.

• Tried with 0.6.0
• double-checked all permissions

• edited my nginx-config to the exact thing you put on https://sabre.io/baikal/install/ plus ssl setting which worked perfectly with version 0.5.4 and all the prior ones
  

  my nginx config:

  
  

  server {
  listen 1234 ssl http2;
  server_name 192.168.0.6;

  ssl_certificate {hidden, but path and permissions are 100% correct};
  ssl_certificate_key {hidden, but path and permissions are 100% correct};
  ssl_session_timeout 1d;
  ssl_session_cache shared:SSL:5m;
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-SEED-SHA:DHE-RSA-CAMELLIA128-SHA:HIGH:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS';
  ssl_prefer_server_ciphers on;
  ssl_dhparam {hidden, but path and permissions are 100% correct};
  add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
  server_tokens off;

  root {install path 100% correct};
  index index.php;

  rewrite ^/.well-known/caldav /dav.php redirect;
  rewrite ^/.well-known/carddav /dav.php redirect;

  charset utf-8;

  location ~/(\.ht|Core|Specific) {
          deny all;
          return 404;
  }
  
  include /etc/nginx/conf.d/restrictions.conf;
  

  location ~ ^(.+.php)(.)$ {
  try_files $fastcgi_script_name =404;
  fastcgi_split_path_info ^(.+.php)(.)$;
  fastcgi_pass unix:/var/run/php5-fpm.sock;
  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
  fastcgi_param PATH_INFO $fastcgi_path_info;
  include /etc/nginx/fastcgi_params;
  }
  }

• tried without the include...nginx...restrictions

• tried without ssl
• have (and had before) PHP 7.0.33-0+deb9u6 (cli) (built: Oct 24 2019 18:50:20) ( NTS )
• made up a second fresh instance from scratch with the exact nginx config mentioned on https://sabre.io/baikal/install/
• tried different browsers and devices

All with the same result. No failure in the browser, nothing in the logs, no timeout - just a blank page.
Appreciate your help!

[ByteHamster]

Between 0.5.3 and 0.6.1, there have been close to zero changes to the admin interface. The biggest thing we did was to upgrade sabre/dav but this does not influence how the admin interface is displayed. Are you sure you used the right zip file? The source code file does not include dependencies. The release file comes bundled with dependencies.

[whowantsmybigdata]

thanks for your quick reply! Yes, I'm absolutely sure.
I used wget https://github.com/sabre-io/Baikal/releases/download/0.6.1/baikal-0.6.1.zip

[ByteHamster]

Pretty strange that there are no logs. Maybe you need some nginix configuration. I am not experienced with nginix, so I can't really help you there. A quick Google search lead to catch_workers_output = 1 and display_errors = On. Maybe you can give those a try.

[whowantsmybigdata]

yeah, so there were logs of course but none regarding baikal.
Now I figured out how to handle the logs in nginx:
in nginx.conf error_logs /var/log/ngninx error.log {error or warn or info or notice};)
could have done that before, sorry.

And furtunately I now got a result:
2020/02/17 11:00:31 [error] 22553#22553: *1 FastCGI sent in stderr: "PHP message: PHP Warning: Unsupported declare 'strict_types' in /home/baikal/baikal/vendor/sabre/uri/lib/functions.php on line 3
PHP message: PHP Parse error: syntax error, unexpected ':', expecting '{' in /home/baikal/baikal/vendor/sabre/uri/lib/functions.php on line 28" while reading response header from upstream, client: 192.168.0.35, server: 192.168.0.6, request: "GET /baikal/html/admin/

the lines in /baikal/vendor/sabre/uri/lib/functions.php creating that error:
line 3: declare(strict_types=1);
line 28: function resolve(string $basePath, string $newPath): string

[phil-davis]

https://www.php.net/manual/en/functions.arguments.php#functions.arguments.type-declaration.types
That : string is a return type declaration, only valid since PHP 7.0

What version of PHP are you running? 5.6?

[whowantsmybigdata]

as mentioned:

> php -v
PHP 7.0.33-0+deb9u6 (cli) (built: Oct 24 2019 18:50:20) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
    with Zend OPcache v7.0.33-0+deb9u6, Copyright (c) 1999-2017, by Zend Technologies

[ByteHamster]

Try to place a file with the content <?php phpinfo(); ?> on your server and open the website. Looks like something is wrong with the php setup. What version does this show?

[whowantsmybigdata]

Try to place a file with the content <?php phpinfo(); ?> on your server and open the website. Looks like something is wrong with the php setup. What version does this show?

where should I place it?

[ByteHamster]

I guess just creating a new file baikal/html/test.php should work. Then open the test.php file in your browser (something like http://192.168.x.x/baikal/html/test.php)

[whowantsmybigdata]

I guess just creating a new file baikal/html/test.php should work. Then open the test.php file in your browser (something like http://192.168.x.x/baikal/html/test.php)

Oh man, you're right - it shows PHP Version 5.6.36-0+deb8u1!

[whowantsmybigdata]

ok, I removed php5 completely and reinstalled php7.
I had to change this line in your installation manual regarding the nginx-config:
fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;
to
fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
is there somehow a way now to prevent php this line from pointing to a wrong directory after upgrading php-fqm to e.g. 7.1 besides editing it manually?

Anyway: now the testpage is showing the correct php7 version and baikal-admin-page is reachable and upgrade worked flawlessly!
thanks a lot!

[nathanzachary]

The only thing that you could do is to create a symlink to the current version, but that still may require manual intervention. What OS? I personally use Gentoo, and we have the eselect tool to switch between installed versions of PHP (for CLI, PHP-FPM, Apache, et cetera).

[whowantsmybigdata]

The only thing that you could do is to create a symlink to the current version, but that still may require manual intervention. What OS? I personally use Gentoo, and we have the eselect tool to switch between installed versions of PHP (for CLI, PHP-FPM, Apache, et cetera).

Thanks but I just switched completely to PHP7, wanted to do that anyway and actually it wasn't that much of an issue...

The only thing which is still "troubling" me is my question from last post:

is there somehow a way now to prevent php this line from pointing to a wrong directory after upgrading php-fqm to e.g. 7.1 besides editing it manually?

[nathanzachary]

That's why I asked what OS you are using. Each Linux distribution handles the installation of PHP and FPM differently, so it would ultimately depend on the distro. The name of the socket (and even the directory under /var/run/) can differ.

[whowantsmybigdata]

That's why I asked what OS you are using. Each Linux distribution handles the installation of PHP and FPM differently, so it would ultimately depend on the distro. The name of the socket (and even the directory under /var/run/) can differ.

Sorry got you wrong, I use Debian 9

[nathanzachary]

Ah, I don't personally use Debian, but it seems like it is using systemd as the init system. As such, you would have to edit the systemd unit file for php-fpm. Looking at the one that ships with Debian 9, though:

[Unit]
Description=The PHP 7.0 FastCGI Process Manager
Documentation=man:php-fpm7.0(8)
After=network.target

[Service]
Type=notify
PIDFile=/run/php/php7.0-fpm.pid
ExecStart=/usr/sbin/php-fpm7.0 --nodaemonize --fpm-config /etc/php/7.0/fpm/php-fpm.conf
ExecReload=/bin/kill -USR2 $MAINPID

[Install]
WantedBy=multi-user.target

I don't see a specific call for the socket file (only the PID). It could be that you would have to recompile PHP-FPM from source and pass an option during the ./configure stage. I don't see any other option besides --enable-sockets, so it may be that the path is hardcoded somewhere. Ultimately, I don't think that it is worth the hassle to change it, and it likely just changed with the major revisions in PHP 7.x.

[ByteHamster]

Looks like the original issue with Baikal is resolved. You are free to talk about how to set the default php version on Debian (maybe it helps someone else, too) but I will already go ahead and close this issue.

[whowantsmybigdata]

@nathanzachary
Appreciate your help a lot but as you already summarized thats too much of a hassle for my opinion.
Hopefully you're right and it just changed once witch v6-v7, would be strange if not regarding how many people use Debian and php7.
I was just wondering with the addition of ".0" in the path. If it would be /var/run/php/php7-fpm.sock I would get it but as the socket-file is called php7.0-fpm.sock it would be confusing if it would stay that way during any minor updates so e.g. 7.0 to 7.1, wouldn't it?