Make cli version of PHP used by Updater configurable #25973
Comments
@VicDeo THX |
|
@timreeves Could you please adjust your nginx configuration according to owncloud-archive/documentation#2551 and recheck? |
|
The nginx config doesn't need to be updated here. The linked issue would cause the updater app to shown but with missing styles / graphics. Its more about this:
where the shared hoster is limited some methods or similar needed for the updater app. |
|
I agree with @RealRancor , the "Not allowed" is the real clue. I already know the thread about updater CSS/JS, and added my own comment to the original thread Resync nginx config. My Nginx config is good, the updater screen is shown with all resources. It just does'nt run. Neither am I at a shared hoster - it's an own VPS at HostEurope, managed with Plesk. And both Plesk and all system packages are fully up to date. I'm using HTTP/2, so tried a fallback to HTTP/1.1, but the problem remained unchanged. So I come back to my original thought: Which version of PHP is the Updater using? Can that be configured anywhere, if not officially then in some arcane manner? |
|
I think that question is not relevant for your "not allowed" issue. Furthermore this looks more like a configuration issue (blocked HTTP verbs or other restrictions) which are better discussed at https://central.owncloud.org |
|
I have now checked this on OC 9.1.0 AND on an Ubuntu 14.04 LTS server (VPS), there using a self-compiled PHP 7.0.5 / 7.0.10 and not the Plesk one. Always the same - Not allowed. So it seems like a bug to me - or something in my environment which I have (mis)configured the same on both maschines (e.g. Nginx-Config). |
One of the requests going to your server is very likely coming back with an "405 Method not allowed" or similar. |
|
Thanks for the instructions! My FF-Console says:
This is my Nginx-Config, which passes PHP to a self-compiled PHP 7.0.10 via PHP-FPM. Sorry about so much comment - I'm 62 and my memory was never the best and aint getting better, I simply need the comments: Put this file in the Plesk webspace root, NOT the document root of ownCloud. Why?1) that way it's update-safe; and (2) ownCloud code-signing would complain.Plesk: Websites & Domains | {Your OC Domain} | Apache & nginx Settings:All defaults, ALL checkboxes off, Additional nginx directives:include "/var/www/vhosts/{plesk-webspace}/nginx-for-own-phpfpm-owncloud9.conf";set $sockname ##YOUR-POOL##; Plesk Web Server settings:PHP support: Plesk-PHP 7.0.X as FPM application server by nginxSmart static files processing = NeinServe static files directly by nginx = NeinAfter each modification: service nginx restartNginx Server Error log: /var/log/nginx/error.logNginx Domain Error log: /var/www/vhosts/system/{domain}/logs/error_logFPM-Log: /var/log/php5-fpm.log bzw. /var/log/plesk-php70-fpm/error.loghttp://wiki.nginx.org/Pitfallshttp://www.php.net/manual/de/regexp.introduction.phpThe following directives are included at the end of each Server-Block, i.e. in "server { ... }" context.This config is a merge of my previous effort and this:"OCNX": https://doc.owncloud.org/server/9.1/admin_manual/installation/nginx_owncloud_9x.htmlPlesk's "location /" sends the resource request to Apache via Ports 7080/7081Plesk's "location /" is the ONLY prefix string location in the Plesk config,which means it's always the winning prefix location, and gets noted as such.- UNLESS we add any longer prefix string locations...Implying that if we want to use Nginx for everything, then we must add"location" statements matching ALL resource types we expect, with "try_files" or "rewrite".Security via e.g. "try_files" is NOT an issue at "location /", that's then Apache's job.Force SSL (if you use http, then comment out)if ($server_port = 80) { rewrite ^ https://$server_name$request_uri? permanent; } Adds the specified charset to the “Content-Type” response header field.Context: http, server, location, if in locationcharset utf-8; Add security related headersBefore enabling Strict-Transport-Security headers please read into this topic firstadd_header Strict-Transport-Security "max-age=15768000; preload;"; set max upload sizeNginx says client_max_body_size already set - I only see it in plesk.conf.d/webmail.conffastcgi_buffers 64 4K; location = / { index index.php; } error_log /var/log/nginx/error.log debug;location = /robots.txt { allow all; log_not_found off; access_log off; } Then comes regex processing, *** which terminates on the first match ***, and thecorresponding location configuration is used. If no match with a regular expressionis found, then the configuration of the prefix location remembered earlier is used.SO the order in which regex locations appear is IMPORTANT!(?: ... ) non-capturing, siehe https://de.wikipedia.org/wiki/Regul%C3%A4rer_AusdruckownCloud ab 8 nutzt PATH-INFO to .js and .php, e.g. /index.php/core/js/oc.js,/index.php/core/ajax/share.php, /index.php/apps/files/ajax/list.php, /index.php/avatar/TimReeves/128See: https://doc.owncloud.org/server/9.1/admin_manual/installation/nginx_owncloud_9x.htmllocation = /.well-known/carddav { return 301 $scheme://$host/remote.php/dav; } OCNX has a "location /" - which we cannot, as Plesk has already used it, to pass thru to ApacheThe OCNX version - location / { rewrite ^ /index.php$uri; } - means:rewrite the URI, appending it (as PATH_INFO) to /index.php; andit ONLY happens as a final fallback, being a prefix string.It must be replaced by a regex - at the END, after all other location directives have had their chance.The Apache .htaccess provided by OC also does: RewriteRule ^remote/(.*) remote.php [QSA,L]But not needed, see here: owncloud-archive/documentation#2014These catch the worst flagrant attempts to call disallowed locations from the weblocation ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)/ { deny all; return 404; } This is careful: It matches all the EXPECTED ".php" calls and passes them to PHP-FPMThere is NO pendant in the Apache .htaccesslocation ~ ^/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|ocs-provider/.+|core/templates/40[34]|apc|info|ocp).php(?:$|/) { See http://wiki.nginx.org/HttpFastcgiModule\#fastcgi_split_path_infoDirective populates $fastcgi_script_name + $fastcgi_path_infoBUT there's a problem: http://trac.nginx.org/nginx/ticket/321fastcgi_split_path_info ^((?U).+.php)(/?.+)$; Requested PHP Scripts MUST exist exactly as namedtry_files $fastcgi_script_name =404; try_files has emptied $fastcgi_path_infofastcgi_param PATH_INFO $path_info; You can add any application-special headers to $_SERVER herefastcgi_param PATH "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"; Following include sets SCRIPT_FILENAME to $document_root$fastcgi_script_nameMeaning that $fastcgi_script_name MUST be correct now!include /etc/nginx/fastcgi.conf; Avoid sending the security headers twicefastcgi_param modHeadersAvailable true; This and the above are both ownCloud-specificfastcgi_param front_controller_active true; http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html\#fastcgi_intercept_errorsfastcgi_intercept_errors on; http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html\#fastcgi_request_bufferingfastcgi_request_buffering off; This is the one branch we DO want to logaccess_log off;} Beginning "updater" or "ocs-provider" and ending with nothing more, or continuing with "/" (and potentially more behind it)In fact, clicking on "Open updater" requests "/updater/", which matches this location, which is why we need the "index" -the index addition goes into a new parsing round and then matches the location above, for ".php" files.The HTML source file returned actually contains:<script src="/updater//pub/js/vendor/jquery.min.js?v=..."></script><script src="/updater//pub/js/main.js?v=..."></script>which do NOT match the ".php" location above, thus are handled here~ = regex case-sensitivelocation ~ ^/(?:updater|ocs-provider)(?:$|/) { try_files: If none of the files were found, an internal redirect to the uri specified in the last parameter is made.} Adding the cache control header for js and css filesMake sure it is BELOW the PHP block~* = regex case-insensitivelocation ~* .(?:css|js)$ { Add headers to serve security related headers (It is intended to duplicate the ones above). Nginx allows several add_header directives.These directives are inherited from the previous level if and only if there are no add_header directives defined on the current level.add_header Strict-Transport-Security "max-age=15768000; preload;"; location ~* .(?:svg|gif|png|html|ttf|woff|ico|jpg|jpeg)$ { location ~ ^/core/doc/[^\/]+/$ { location = /fpmstatus { fastcgi_pass "unix:/usr/local/$sockname.sock"; include /etc/nginx/fastcgi.conf; } Nothing should arrive here EXCEPT the things needing redirecting to be handled by index.phplocation ~ ^/.+ { Finally, switch gzipping onSeems fixed since OC8.1 - #15227, #9005Background: https://github.com/owncloud/client/wiki/Etags-and-file-idsClient + Server: owncloud/client#3946gzip on; |
|
@timreeves your config doesn't work for me at all unless I change to But this is not the case IMO. Can you grep nginx access.log and error.log for requests to User agent for these requests will be |
|
Many thanks @VicDeo for taking the trouble to install my nginx config! I can't see why removing the ".|" from the start of the deny location should make a difference - it matches a period as the first char of the URI and is there on purpose, to prevent access e.g. to .htaccess and .user.ini - and it works fine for me. And the rewrite to add index.php means we get prettier URLs than with the Apache .htaccess. In the meantime I'm going nuts, having noticed that although the GUI works without complaints (except for the Updater problem), the file sync via Webdav coming from Mirall (Windows) causes error messages like this in the OC log:
However, these log messages seem to be "false positives" - the file uploads arrive on the OC server. I have noted this here. I have tried OC 9.1.0 with
Always the same result:
Can't see anything in the nginx error log that looks relevant to the Updater problem (there are some entries, but more to do with all my switching environments while testing). grep occ access_ssl_log So that shows it is happening and formally succeeding - the error is noted in the JSON returned, so the problem seems to be in the PHP code, not in the client-server communication. Any help much appreciated - I really don't want to fall back to 9.0.4, inasmuch as a number of my data files have changed since then and the backup DB is outdated. Thanks! |
|
@timreeves I might be wrong but a dot matches ANY character and |
|
@VicDeo sorry we were, in a way, both right: My original nginx config has a backslash in front of the period in question, which was deleted in the display of my comment by the markdown processing. I have now edited my comment above with the nginx config, and doubled up the backslashes in FIVE places - should work better now :) |
|
Now the good news: I found something relevant to the Updater problem in the PHP 5.6 error log (maybe the log protocol settings differ in the various PHP versions I have used):
Really hope this helps to find the problem! |
|
@timreeves I guess mention of |
|
@timreeves I suspect that the following validation is failing: Please add logging below this line https://github.com/owncloud/core/blob/stable9/core/controller/occcontroller.php#L126 as follows |
|
@VicDeo thx for your patient support! Yes, I am calling the Updater from the web GUI, in my case then via nginx/php-fpm. The nature of the work to be done, and the error message involved, caused me to assume that the GUI component would be making CLI calls in the background to actually do the job - sorry if I confused things. I added the log warning you requested above, but nothing appears from it in the OC log. But now I did find this in my php-fpm error log:
Looks like it's in the Updater itself, in this function in src/Utils/OccRunner.php
Personally I have'nt a clue what that code does - but I rather assume you do - hope this helps! Tim |
yes. It expects a valid json as a response when requesting |
|
@timreeves change it to |
|
Your suspicion was correct: Raw output: Web executor is not allowed to run from a different host Also, I added your code from further above now ABOVE the line throwing the exception and get this in my OC log: {"reqId":"LanE7kdpDc8MVQJmFTPX","remoteAddr":"176.28.16.171","app":"core","message":"occ controller requested from location "176.28.16.171"","level":2,"time":"2016-09-05T17:12:08+00:00","method":"POST","url":"/index.php/occ/config:list HA: 176.28.16.171 is the external IP of my Server - is there some way you (or the core author involved) can find that out and allow it through also? But beware: I have FIVE IP's on that server, assigned via Plesk to different domains, so I can use reverse DNS on them for optimal SEO. On that server, luckily ownCloud is on the basic IP of the server, but other users may have it on a secondary IP - I think basically we need either the IP of the Domain in use, failing that any IP assigned to the server. |
|
And here is my $_SERVER as comes through nginx - php-fpm, in case it helps: $_SERVER: |
|
@DeepDiver1975 looks like we need to allow occ controller execution for requests originating from |
|
@timreeves thanks for these details, but I think you'd better cut them a bit (or even completely) |
|
@timreeves for now it should be enough to replace |
|
I have tried the suggestion - which looks reasonable to me - on my test server, which is Ubuntu 12.04 LTS with OS-PHP 5.3.10 (but the GUI is using Plesk PHP 7.0.9). I don't dare doing it on my production server, because the Updater is only offered if I select "daily" - probably not a good idea for production. What I get is this: OC-Log: {"reqId":"UxScOx90RfW4JS6r/So7","remoteAddr":"","app":"index","message":"Exception: FPM-Log: [05-Sep-2016 21:59:33] WARNING: [pool owncloud.] child 26145 said into stderr: "[error] " Can that be caused by the outdated Ubuntu? I would try it on my production server IF you can tell me how to ensure that the Updater does not actually run when the tests are passed... |
|
@timreeves my fault. one closing square bracket is missing: |
|
Heartfelt Thanks @VicDeo - SUCCESS, the corrected patch works, tested on Ubuntu 12.04 and 14.04. |
|
Don't know if this would be better as a new topic, but: I noticed that when I call the Updater and it runs through the initialisation - with success at the GUI - and before I click on "Start", then these entries appear in the OC log: {"reqId":"...","remoteAddr":"176.28.16.171","app":"PHP","message":"Undefined index: argv at /var/www/vhosts/{domain}/3rdparty/symfony/console/Input/ArgvInput.php#55","level":3,"time":"2016-09-06T07:30:42+00:00","method":"POST","url":"/index.php/occ/config:list","user":"--"} {"reqId":"...","remoteAddr":"176.28.16.171","app":"PHP","message":"array_shift() expects parameter 1 to be array, null given at /var/www/vhosts/{domain}/3rdparty/symfony/console/Input/ArgvInput.php#59","level":3,"time":"2016-09-06T07:30:42+00:00","method":"POST","url":"/index.php/occ/config:list","user":"--"} {"reqId":"...","remoteAddr":"176.28.16.171","app":"PHP","message":"Invalid argument supplied for foreach() at /var/www/vhosts/{domain}/3rdparty/symfony/console/Input/ArgvInput.php#262","level":3,"time":"2016-09-06T07:30:42+00:00","method":"POST","url":"/index.php/occ/config:list","user":"--"} {"reqId":"...","remoteAddr":"176.28.16.171","app":"PHP","message":"Undefined index: argv at /var/www/vhosts/{domain}/3rdparty/symfony/console/Input/ArgvInput.php#55","level":3,"time":"2016-09-06T07:30:43+00:00","method":"POST","url":"/index.php/occ/status","user":"--"} {"reqId":"...","remoteAddr":"176.28.16.171","app":"PHP","message":"array_shift() expects parameter 1 to be array, null given at /var/www/vhosts/{domain}/3rdparty/symfony/console/Input/ArgvInput.php#59","level":3,"time":"2016-09-06T07:30:43+00:00","method":"POST","url":"/index.php/occ/status","user":"--"} {"reqId":"...","remoteAddr":"176.28.16.171","app":"PHP","message":"Invalid argument supplied for foreach() at /var/www/vhosts/{domain}/3rdparty/symfony/console/Input/ArgvInput.php#262","level":3,"time":"2016-09-06T07:30:43+00:00","method":"POST","url":"/index.php/occ/status","user":"--"} |
|
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Steps to reproduce
Expected behaviour
The Updater should work, and use the PHP 7.0.9, which is available on the host
Actual behaviour
The Updater says: [UnexpectedValueException]
Could not parse a response for config:list. Please check if the current shell user can run occ command. Raw output: Not allowed
So it looks to me as if the Updater is using the standard OS-PHP, which no doubt cannot understand the PHP of OC.
My wish/suggestion is: To be able to add a config statement re the version of PHP to use for executing external PHP commands. No doubt you know that here in Germany many Hosters like HostEurope, Strato, Hetzner etc. offer Plesk, so it would be great to have this option. Otherwise, I have to tell my clients that they need a new server - something they don't want to hear )-:
UPDATE: Turns out, on later trials with Ubuntu 14.04, that PHP 5.3 was NOT the problem.
Server configuration
Ubuntu 12.04 OR 14.04 LTS
Web server:
Nginx (from Plesk - 1.11.1)
Database:
MySQL
PHP version:
OS = 5.3.10 / 5.5.9, Plesk = 7.0.9 (at /opt/plesk/php/7.0/bin/php)
ownCloud version:
9.0.4 OR 9.1.0
Updated from an older ownCloud or fresh install:
Updated
Where did you install ownCloud from:
From Source-Zip, via CLI
Signing status (ownCloud 9.0 and above):
No errors have been found.
List of activated apps:
Enabled:
Disabled:
The content of config/config.php:
{
"system": {
"instanceid": "oc452bf87cea",
"passwordsalt": "_REMOVED SENSITIVE VALUE",
"trusted_domains": [
"owncloud.biblische-reisen.de"
],
"datadirectory": "/var/www/vhosts/biblische-reisen.de/oc-data",
"dbtype": "mysql",
"version": "9.0.4.1",
"dbname": "owncloudbde",
"dbhost": "localhost",
"dbtableprefix": "oc",
"dbuser": "_REMOVED SENSITIVE VALUE",
"dbpassword": "_REMOVED SENSITIVE VALUE",
"installed": true,
"loglevel": 4,
"forcessl": true,
"theme": "",
"maintenance": false,
"mail_from_address": "owncloud",
"mail_domain": "biblische-reisen.de",
"mail_smtpmode": "php",
"mail_smtpname": "_REMOVED SENSITIVE VALUE",
"mail_smtppassword": "_REMOVED SENSITIVE VALUE",
"default_language": "en",
"secret": "_REMOVED SENSITIVE VALUE",
"log_rotate_size": 10485760,
"check_for_working_wellknown_setup": false,
"check_for_working_htaccess": false,
"memcache.local": "\OC\Memcache\APCu",
"filelocking.enabled": "true",
"memcache.locking": "\OC\Memcache\Redis",
"redis": {
"host": "/var/run/redis/redis.sock",
"port": 0,
"timeout": 0,
"dbindex": 1
},
"trashbin_retention_obligation": "auto",
"updater.secret": "_REMOVED SENSITIVE VALUE"
}
}
Are you using external storage
No
Are you using encryption:
No
Are you using an external user-backend, if yes which one:
No
Client configuration
Browser:
Firefox
Operating system:
Windows 10
Logs
Web server error log
The text was updated successfully, but these errors were encountered: