I just recently had to try to run Flow on a Strato webhost – which was a pretty bumpy experience as you might expect. While they have SSH, their command-line PHP is not the CLI fpm, but the FCGI fpm…
At this point, it occurred to me at my back of my mind, that at some point we were thinking of moving the sub-CLI-request to a sub-web-request. I have talked about it with @bwaidelich, @christianm and @kdambekalns recently, and I believe with @christopher a while ago.
This would solve the following issues:
PHP version for “CLI” and “Web” are always the same
The ./flow CLI tool would not run into permission issues as everything is executed as the web user.
We would not depend on a PHP-CLI SAPI anymore.
It has the following drawbacks (that I currently know of)
when running “./flow”, we need to know the public web URL - so we can forward the CLI request to there. This needs manual configuration. As soon as the application is e.g. running behind an authenticating reverse-proxy or htaccess, this would fail.
potential security holes (I tried carefully to not add any, but you never know…)
I hacked together some rough, working, prototype, which you find over at https://review.typo3.org/#/c/40873/. I’m really curious at your opinions about the general idea, whether we should support this, etc.
Currently, I feel that I’d support it as an additional way of running Flow commands, targeted to entry-level users. But that leaves the question on based on which condition we should use one-way or the other; so whether the user needs to choose which way is the correct one for him…
In general, I absolutely welcome this idea, but we should be really careful with the implementation. Thanks for starting this!
Some thoughts:
It might not be necessary to route all CLI calls via web as the CLI still has advantages (interactive shell etc) over what can be done through web. Our task is not to switch from CLI to web but to solve the root causes for people’s problems. That’s tightly connected of course but I think it’s important to be aware of the actual problems before deciding on a implementation.
I think that CLI currently cause the following problems:
some system simply don’t have a PHP CLI installed or it’s almost impossible to use it correctly
in some cases the PHP version or php.ini of CLI is different than the web configuration
command line user and web server usually run as different users; if either one creates files or directories, the other user does not have write access to it (by default at least, unless you run processes with umask 002)
even if PHP CLI is installed, some users might not have shell access to the server
some users are uncomfortable with using command line tools
On the other hand, there are a lot of users who benefit from Neos / Flow providing a command line interface because it nicely integrates into their toolchain (being able to pipe data etc). A web solution might also have problems where a firewall blocks outgoing traffic (very often the case in “proper” server setups).
Currently I think that we need both options. The “flow” command should become a bash script which commits a few basic checks and then decides how to proceed. If there is no CLI PHP at all (reachable via env for example) it could pipe the request via web. If there is PHP, a Flow PHP script could run further tests, like comparing php versions, certain php.ini values and then decide how to continue. All that could also (optionally) be determined by an environment variable (FLOW_CLI_MODE or the like).
There are nice web-based terminals which we could include into Neos (into a separate, sandboxed script which also works if Neos is unstable). For example Wetty: https://github.com/krishnasrinivas/wetty
But we need to think more about issues like firewall etc.
Let’s collect a few more thoughts and solutions - what do you think?
please don’t forget about INIs max_execution_time on the “Web”(FPM, mod_php, [F]CGI, etc.), which disallows long running scripts and thus MQ, Websockets and many other great possible things with current CLI-Implementation atall.
I get very frustrated when the famous host-providers provide the environment so badly.
I can understand if they will save up their computing capacity by disalowing long-run processes on cheap hosting offer but if they do that on managed hosts i get…
Also it would be very nice if Neos is usable on cheap or badly configured env. but in no case damage current CLI-Functionality please!
I’m personally fine with the way it is, but it’s a red carpet issue mostly.
Yesterday had a fun experiment: install Neos on a friend’s netbook pc with 1GB of RAM and Linux. The funny thing it worked, but I just looked at initial installation process with the eyes of a novice user, and yeah, it isn’t trivial. Can’t even think about what experience I’d have if that laptop was running Windows…
Don’t be afraid, that won’t happen (as far as I’m involved). The discussion is mostly about the use case of supporting more environments that don’t have access to PHP CLI. There were plans of routing the CLI requests to a web request for consistent permission handling, but I don’t see that completely replacing the current CLI implementation, because we still need that for longer running tasks.
Does someone work on this issue? It would be a huge step forward for Neos, if it would support more shared hosters like Strato. So please do not forget on this issue.
