Partkeepr 0.78 fresh installation: test on app/logs/ignore.json dependent to non-existing parameters.php

[trial-n-error]

Hi,

during a fresh installation test on app/logs/ignore.json fails as it is routed to app.php which complains about non-existing parameters.php.

The file parameters.php is created at a later step of the installation routine.

Environment:

• php-5.6.11
• nginx-1.8.0
• postgresql-9.4.4
• https://downloads.partkeepr.org/partkeepr-0.78.tbz2

Workaround: $ cp partkeepr/app/config/parameters.php.dist partkeepr/app/config/parameters.php

[Drachenkaetzchen]

Good find. In theory, the installer should accept any response except for the actual contents of the ignore.json file, so for some reason this is not working, probably related to nginx.

As I'm not much familar with nginx, can you give me the relevant nginx configuration so I can reproduce the issue more easily?

[trial-n-error]

Hi Felicitus,

I'm a new user of PartKeepr. It took me some time to install it, due to the specific environment I use (nginx+postgres). I append my nginx configuration. I tried to stick to the wiki description. But I figured out it is important what user will include in fastcgi_params, therefore I append this file as well (e.g. I ran into issues with PATH_INFO before).

Nginx Config

    server {
        listen 80;
        listen [::]:80; 
        server_name  parts.domain.tld;

        access_log  /srv/http/parts.domain.tld/logs/access.log;
        error_log   /srv/http/parts.domain.tld/logs/error.log;

        client_max_body_size 100M;

        dav_methods off;

        root   /srv/http/parts.domain.tld/partkeepr/web/;

        # Use app.php as index
        index app.php;

        location /setup {
                index index.html;
        }

        location / {
            # try to serve file directly, fallback to app.php
            try_files $uri /app.php$is_args$args;
        }

        # This is required for the setup to detect if this KB article has been implemented
        rewrite ^/setup\/webserver-test$ /setup/tests/webservercheck.json;

        location ~ ^/(app_dev|config|setup)\.php(/|$) {
            # fastcgi_pass unix:/var/run/php5-fpm.sock;
            fastcgi_pass 127.0.0.1:9000;
            fastcgi_split_path_info ^(.+\.php)(/.*)$;
            include fastcgi_params.partkeepr;
            # When you are using symlinks to link the document root to the
            # current version of your application, you should pass the real
            # application path instead of the path to the symlink to PHP
            # FPM.
            # Otherwise, PHP's OPcache may not properly detect changes to
            # your PHP files (see https://github.com/zendtech/ZendOptimizerPlus/issues/126
            # for more information).
            fastcgi_param  SCRIPT_FILENAME  $realpath_root$fastcgi_script_name;
            fastcgi_param DOCUMENT_ROOT $realpath_root;
        }
        # PROD
        location ~ ^/app\.php(/|$) {
            # fastcgi_pass unix:/var/run/php5-fpm.sock;
            fastcgi_pass 127.0.0.1:9000;
            fastcgi_split_path_info ^(.+\.php)(/.*)$;
            include fastcgi_params.partkeepr;
            # When you are using symlinks to link the document root to the
            # current version of your application, you should pass the real
            # application path instead of the path to the symlink to PHP
            # FPM.
            # Otherwise, PHP's OPcache may not properly detect changes to
            # your PHP files (see https://github.com/zendtech/ZendOptimizerPlus/issues/126
            # for more information).
            fastcgi_param  SCRIPT_FILENAME  $realpath_root$fastcgi_script_name;
            fastcgi_param DOCUMENT_ROOT $realpath_root;
            # Prevents URIs that include the front controller. This will 404:
            # http://domain.tld/app.php/some-path
            # Remove the internal directive to allow URIs like this
            internal;
        }

        location ~ [^/]\.php(/|$) {
                fastcgi_split_path_info ^(.+?\.php)(/.*)$;
                if (!-f $document_root$fastcgi_script_name) {
                        return 404;
                }

                fastcgi_pass 127.0.0.1:9000;
                fastcgi_index index.php;
                include fastcgi_params.partkeepr;
        }
    }

fastcgi_params.partkeepr;

fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;

fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
fastcgi_param  PATH_INFO          $fastcgi_path_info;
fastcgi_param  PATH_TRANSLATED    $document_root$fastcgi_path_info;
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;

fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx/$nginx_version;

fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;

fastcgi_param  HTTPS              $https;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param  REDIRECT_STATUS    200;

Best regards, Mario

[Drachenkaetzchen]

I'm not sure on how to proceed from here. Is there anything I should fix in the wiki documentation?

[trial-n-error]

Hi,

the server configuration of nginx is fine. I just added it for reference.

the original error or problem I had was the one described in the first post:

" during a fresh installation test on app/logs/ignore.json fails as it is routed to app.php which complains about non-existing parameters.php. The file parameters.php is created at a later step of the installation routine. "

So I think it is nothing for the wiki. In the past I did not investigated what is the origin for the problem was, but could just get it working by creating a default parameters.php. This was an easy workaround for me. If this occurs not on apache I might try it again in the future and do more research on the real issue for you. I can inform you about the problem I found.

Best regards, Mario