Xaymar

Thank you Rich, that was indeed what was causing it.

Reinstalling PHP7 only made it respond slightly faster, no change on what it does though. Does sharing work with permalinks enabled? Could that be why it’s getting messed up?

Not that I am aware of, no. Pagespeed is disabled and fastcgi is pretty much the secure nginx setup from the nginx wiki.

fastcgi.conf

# FastCGI Settings {
        include                                         "fastcgi_params";

        fastcgi_param   PATH_INFO                       $fastcgi_path_info;
        fastcgi_param   PATH_TRANSLATED                 $document_root$fastcgi_path_info;
        fastcgi_param   SCRIPT_NAME                     $fastcgi_script_name;
        fastcgi_param   SCRIPT_FILENAME                 $document_root$fastcgi_script_name;
        fastcgi_param   SERVER_NAME                     $server_name;

        fastcgi_intercept_errors        on;
# }

# Default to no_cache if caching is enabled.
set $fastcgi_cache                              1;

fastcgi_php7.conf

location ~ [^/]\.php(/|$) {
        # Split the path information correctly.
        fastcgi_split_path_info         ^((?U).+\.php7)(/?.+)$;
        try_files                       $uri =404;

        fastcgi_pass                    unix:$server_root/php7.socket;
        fastcgi_index                   index.php;
}

fastcgi_php5.conf

location ~ [^/]\.php5(/|$) {
        # Split the path information correctly.
        fastcgi_split_path_info         ^((?U).+\.php)(/?.+)$;
        try_files                       $uri =404;

        fastcgi_pass                    unix:$document_root/../php5.socket;
        fastcgi_index                   index.php;
}

fastcgi_params

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_NAME        $fastcgi_script_name;
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  REQUEST_SCHEME     $scheme;
fastcgi_param  HTTPS              $https if_not_empty;

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;

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

It is worth noting that this behavior wasn’t always like this, it worked fine on 4.2.2 (which is what the website started with) and seems to have broken with the later WordPress versions. Is there any way I can enable debug logging for jetpack so a better way of figuring out what is going wrong can be found?

I’m going to try reinstall php5 and php7 in case these are the ones causing issues.

I did that now, it seems to not have an effect (only increased page load time). It looks like whatever should intercept the page load isn’t doing that

“Don’t cache pages with GET parameters. (?x=y at the end of a url)” is checked and even disabling WP Super Cache doesn’t seem to change this behavior. This is the output in nginx log if it matters:

[06/Oct/2016:16:12:10 +0200] ~^(?<subdomain>[\x5Cw\x5C.]+)\[email protected]:443 <1149985+1>: Protocol="HTTP/1.1", Response="200", ResponseLength="17189 byte", Request="GET /tag/rc HTTP/1.1", RequestLength="423 byte", RequestHost="www.xaymar.com", RequestFile="/home/www-xaymar-com/public/www/index.php", RemoteAddr="66.249.76.112:57595", UserAgent="Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +https://www.google.com/bot.html)", GZipRatio="3.80", RequestURI="/tag/rc", URI="/www/index.php", FastCGIScriptName="/www/index.php"
[06/Oct/2016:16:12:17 +0200] ~^(?<subdomain>[\x5Cw\x5C.]+)\x5C.xaymar.com$@2001:4ba0:ffff:125::1:0:443 <1149981+2>: Protocol="HTTP/1.1", Response="200", ResponseLength="20082 byte", Request="GET /2016/10/06/version-1-3-3-0-of-the-encoder-plugin-has-been-released?share=tumblr&nb=1 HTTP/1.1", RequestLength="1378 byte", RequestHost="www.xaymar.com", RequestFile="/home/www-xaymar-com/public/www/index.php", RemoteAddr="2a02:8109:7c0:1024:1137:5956:aa5e:2e29:10297", UserAgent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36", GZipRatio="3.70", RequestURI="/2016/10/06/version-1-3-3-0-of-the-encoder-plugin-has-been-released?share=tumblr&nb=1", URI="/www/index.php", FastCGIScriptName="/www/index.php"

• This reply was modified 8 years, 1 month ago by Xaymar.

Fixed it by supplying a fake path to the php handler whenever a wordpress file was used. Strange to design it this way.

I have set it to 32mb, usually is enough for many plugins that use the “get->work->drop->next” routine (especially in databases). Only had one plugin so far that complained about that was Jetpack.
I have about 120 pages (~100 hidden/created & maintained by plugins) and posts on the site. If loaded all at the same time, that would go over the memory limit, but otherwise it should be fine.

The following functions are blacklisted (more may be statically disabled by php extensions that I cant modify):
pcntl_alarm,pcntl_fork, pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsigna
led,pcntl_wexitstatus, pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_dispatch,pcntl_get_last_error, pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec, pcntl_getpriority,pcntl_setpriority

Most other settings are at the default, with the memory limit and upload filesize being adjusted to larger files and requests. I also have the following extensions installed: curl, enchant, exactimage, gd, geoip, gmp, gnupg, imagick, imap, intl, json, ldap, mcrypt, memcache, memcached(auto installed when installing memcache), mongo, mysqlnd, oauth, pecl-http, pgsql, propro, pspell, raphf, readline, recode, redis, sasl, sqlite, ssh2, stomp, tidy, twig, xcache, xmlrpc, xsl

The only thing that differs between the non-sandboxed and the sandboxed one is that the non-sandboxed one doesnt have a blacklist for commands.

Yeah, the domain is currently outside of the chroot, that’s why it works. It stops, or stopped as you will soon learn, after moving it back into it. I ‘fixed’ it by removing all blacklisted php commands and then moving it back to the chroot, though I’m not sure why that works. At least it’s working now, even though it’s insecure.

(I don’t use EasyEngine, I have a custom built setup that is designed to serve content as fast as possible from multiple other servers and itself. Using a panel would just make things more difficult for me.)

Unfortunately I can’t edit the review so people will have to look at the comments: Plugin works, but for some reason occasionally requires the blacklist to be removed from php.

…the error log for fastcgi says that there was no response from the upstream host(PHP).

How did I misread that?

You did not misread that, however in my configuration setup, that means that the php-file being executed terminated early, either by the script or the fpm-handler for taking too long (second one would trigger a php.slow.log entry, which doesn’t happen – i.e. for some reason your php script or template manages to terminate the entire process, which is not logged).

I’ve moved the php controller out of the chroot and it works there, but I can’t keep it there for long – too insecure.

Also, the requested links:
https://project-kube.de/sitemap.xml
https://www.project-kube.de/sitemap.xml
https://project-kube.de/www/sitemap.xml
https://project-kube.de/?feed=sitemap
https://www.project-kube.de/?feed=sitemap
https://project-kube.de/www/?feed=sitemap

Edit: As soon as I put it back into the chroot, it just stops working again. PHP, nginx, MySql are all up to date from sources.

You’re assuming that the upstream php host is configured wrong – that would mean that I’d get an error message instead of an empty page. (Also, not writing or using a unix-socket/pipe-stream sitemap.xml is really an odd idea, but yours to make so meh)

Also, even Google Webmaster Tools was unable to read the sitemap, so yeah. Not working, in the slightest. I can send you the cleaned (removal of identifying data) error logs if you so desire, but they are mostly 0 bytes big.

I also tried the ?feed=sitemap thing, and it just returns an empty page and the error log for fastcgi says that there was no response from the upstream host(PHP). Not the greatest thing to happen, I’m probably better off writing my own plugin for this.