Any plans to "officially" support installation using Nginx?
Permalink 2 users found helpfulhttp://www.concrete5.org/documentation/background/system_requiremen...
Do the core c5 developers plan test/document/recommend the use of Nginx?
http://www.cmswire.com/cms/web-cms/nginx-continues-its-rise-to-the-...
the rather limited time in our day. If we wanted to spend any more of
it being server experts, you'd see us work harder to support IIS as
there's a lot of money tied up in wimblows.
Today concrete5 works on IIS, but we don't have the expertise in house
to recommend people use it in a production environment. If we're
talking business decisions, that'd be wise for us to explore.
But like I said, go for it! More platforms concrete5 works well on, the better!
best wishes
Franz Maruna
CEO - concrete5.org
http://about.me/frz
Why is the web server so important for Concrete5? After all it is an web application running on top of PHP. Right? Why is it so important what web server it runs on?
supports PHP and MySQL. You might have some issues getting Pretty URLs
to work, or other details - but there's really nothing major that
should get in your way.
I believe what is being asked is will we provide support, testing and
documentation for how to best configure it for these platforms. Will
we go through the process of making sure any new versions of concrete5
work well on platform X. That's where things get tricky for us,
there's only so much time in the day and money in the bank. That being
said, it's open source - let's make it work on whatever, together!
URI: /index.php/tools/required/i18n_js/......
In reality that should go to /concrete/tools/i18n_js/......
So there I am. I am again needing to write rules for that:
location ~ ^/index\.php/tools/required/(.+) { try_files /concrete/tools/$1 $uri; }
Okay. That works until the user using the CMS tells me that you can overwrite everything in Concrete5 by creating your own file system structure without the /concrete/ directory. Okay. Then again I am changing configuration:
location ~ ^/index\.php/tools/required/(.+) { try_files /tools/$1 /concrete/tools/$1 $uri; }
This again works until the user using the CMS is telling me that you can install things in Concrete5 by using some kind of package manager and the things are then on the file system in /packages/....
And again I need to change configuration. And this is then the moment where I ask my self: WTF is going on? Where is that special behaviour mentioned? Why do I have to write so much rewrite/try_file rules for something so simple like a CMS? Why is this CMS so special and needs so much rules on the server?
All I would like to have is a central place where I can easily and quickly read about the 'special' behaviour of Concrete5. Does something like that exist?
1) Amend the 'System Requirements' page to say that you primarily develop/test/approve on Apache, but the system should work on any webserver supporting php. Its known to work on IIS, Nginx and others. See the below document.
2) Lets make a document (assuming it does not exist) that describes the rewrites required to make c5 work with or without pretty urls if not using Apache. This document can then be used by any systems administrator to setup c5 on any webserver (in theory).
For example the themes folder could be located in:
/themes
/packages/[theme_name?]/themes
/concrete/themes
or tools could be located in:
/tools
/packages/[tool_name?]/tools
/concrete/tools
That all sounds logical, but then I see requests to:
/index.php/tools/required/i18n_js.php
/index.php/tools/required/page_controls_menu_js.php
Arh! Where did that '/required/' come from?
Currently I'm working my way through these rewrite rules one-by-one.
Does such a document already exist?
For example the themes folder could be located in:
/themes
/packages/[theme_name?]/themes
/concrete/themes
As far as I can tell the theme paths are (for example lets call the theme 'omega'):
/themes/omega/...
/packages/theme_omega/themes/omega/...
/concrete/themes/omega/...
Or to use your naming convention:
/themes/[theme name]/...
/packages/theme_[theme name]/themes/[theme name]/...
/concrete/themes/[theme name]/...
IMHO this is totally frustrating to find out the inner working of Concrete5 by waiting and babysitting it all the time and watching the error log for those stupid 404 issues and fix them. I hate that. My time is valuable too. I have no time to sit all day and try to magically find out what is going on.
C5 sorts out all file overrides internally, so you don't need to have any rewrite or searching rules for it. By including such rules, I suspect you will be breaking the prioritisation that C5 sets and hence causing a cascade of errors that you are now rushing to fix.
The .htaccess in Apache is usually trivial, for example:
# -- concrete5 urls start -- <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME}/index.html !-f RewriteCond %{REQUEST_FILENAME}/index.php !-f RewriteRule . index.php [L] </IfModule> # -- concrete5 urls end --
After that, C5 scans through a few server variables to get the request info, and again does everything else internally.
What do you mean with 'scans through a few server variables'? What variables are they and how do they influence C5? Is there any documentation about that? Maybe providing C5 with the proper 'server variables' would be easier than writing those rewrite/try_file rules?
Are you writing about CGI variables and/or PHP variables?
A quick search for nginx in the C5 forums reveals plenty who have done it who have posted details of their configurations. I couldn't find any trying to replicate C5 overrides in the nginx configuration like you are. Many appear to be mapping a handful of CGI variable names from nginx variables.
btw: I do those mappings too. Ningx has that mapping out of the box.
http://www.concrete5.org/community/forums/-/view/?sort=relevance&am...
Anyway... I think I can work around the problem described above by changing how PHP is called. Unfortunately I can not test it right now since I am out of office. Will however test after work and let you know if my idea worked or not.
location / {
if (!-f $request_filename){
set $rule_0 a;
}
if (!-f $request_filename/index.html){
set $rule_0 b$rule_0;
}
if (!-f $request_filename/index.php){
set $rule_0 c$rule_0;
}
if ($rule_0 = "cba"){
rewrite /. /index.php last;
}
index index.html index.htm index.php;
}
Along with a pretty standard php.conf setup with php-fpm.
You should use other techniques available to nginx that are way better then using if's.
Something like this here (not full config but you get the picture):
location / { try_files $uri $uri/ /index.php$request_uri /index.php; } location ~ \.php { fastcgi_split_path_info ^(.+\.php(?:[3-5])?)(/.+)$; include /etc/nginx/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_pass unix:/path/to/unix/socket; try_files $fastcgi_script_name =404; }
Or if you want then use named locations:
location / { try_files $uri $uri/ /index.php$request_uri /index.php; } location ~ ^(?<script_name>.+\.php(?:[3-5])?)(?<path_info>/.*)?$ { include /etc/nginx/fastcgi_params; fastcgi_param PATH_INFO $path_info; fastcgi_param PATH_TRANSLATED $document_root$path_info; fastcgi_param SCRIPT_NAME $script_name; fastcgi_param SCRIPT_FILENAME $document_root$script_name; fastcgi_pass unix:/path/to/unix/socket; try_files $script_name =404; }
seehttp://www.concrete5.org/developers/bugs/5-6-1-2/pretty-urls-not-wo...
To generate the load, I threw a hugely powerful (and ruddy expensive) Windows Server instance running JMeter at a L(A/N)MP box,
The box I ran had Apache 2.4 + APC, then I replaced this with Nginx + APC (+ PHP FastCGI Process Manager) and found that there was little difference (falling, eventually to Apache's favour!). Rough stats:
- 50 Concurrent Users -
Apache: 33% CPU Usage, Avg Response 5.1s
NGinx: 31.2% CPU Usage, Avg Response 5.4s
Honestly, these aren't the results I expected or wanted to see, but Apache really cleaned up their act in their 2.4 release. I am also reading that Nginx has been accepted as slower in this scenario anyway. It comes into its own when you want to deliver static assets at lightening speeds. I wonder if Nginx can be used here? Does anyone know if there's a way to separate assets into their own subdomain (assets.website.com) for example?
Kindest Regards,
Mark
To say it in other words: nginx usually uses +/- less resources than Apache to deliver the same result.
This does not say anything about speed. Apache 2.4 has made huge improvements regarding speed. But most users using something other than Apache usually do that because of other reasons than speed. If Apache would be so snail slow, it would never get that widely accepted as it is today.
And on top of that: You can easily use PHP over FCGI/CGI in Apache too and reduce the memory footprint of Apache. But one Apache instance will most likely use more resources than something so lean as nginx. So the more instances you run the more likely you will benefit from using nginx. Or if you run a system with very limited resources then using nginx, Cherokee, Lighttpd, etc will more likely be a better solution than using Apache.
But anyways, I didn't need much magic. The following config is basically everything that I needed:
if (!-f $document_root$fastcgi_script_name) { rewrite (.*) /index.php/$1 break; }
read my comment why that 'if' is not good and how to make it better ->http://www.concrete5.org/community/forums/chat/any-plans-to-officia...
Gruess us Züri
// Steve
You can't see it in my one line snippet but since it's the last statement I need, it basically works like "rewrite ... last" which is listed under "The only 100% safe things".
I see the point why we should avoid if's in general but I don't see why my configuration should be evil. I can also tell you that this server runs for several years without any interruption and has served more than just a few thousands page views..
if (!-f $document_root$fastcgi_script_name) { rewrite (.*) /index.php/$1 break; }
In nginx internally the $fastcgi_script_name is set to the URI ->http://wiki.nginx.org/HttpFastcgiModule#.24fastcgi_script_name...
And later that variable gets split into $fastcgi_script_name and $fastcgi_path_info. Now if you would make a request to /index.php/my/path/whatever then the above code will in most cases look for a file named $document_root/index.php/my/path/whatever.
Better approach would be to enclose this into a location block that only handles php[3-5]? files and the do either the path splitting or work from the beginning with a regexp location and set proper PATH_INFO and SCRIPT_NAME CGI variables.
try_files is as well way more efficient than using if statements.
More info here ->http://nginx.org/en/docs/http/ngx_http_core_module.html#try_files...
I guess I'll leave it up to you to come up with the perfect nginx configuration for concrete5 as you definitely know more about nginx than I do.
Don't take it personally, but this is kind of bad advertising for nginx. I understand why they still support all kind of if's but if you have to read/know that much to properly configure nginx I'm glad I'm stuck with apache.
Regarding nginx: The problem is that to many people out there have no clue about web servers and such and then they go on and hear that this ultra fancy giga super dupper lean web server called nginx is the next cool thing and if you want to be cool and 31337 then you have to install that beast. It is going to fly so fast that Apache and IIS and all the others have no chance to catch up. Ever!
So they install it on their server and go on and read some where on the net how to configure it. They blindly copy configuration snippets from all over the web without really knowing what they do. And then they start up their web server and do a bunch of requests and it seams to work. That is all what counts for them. They never ever are going to touch it again. They don't care if they are open for attacks or anything other. They don't care as long as they don't get officially owned by some hacker group or they don't get their php code changed to server malicious code. When that happens then they are the first to cry out loud about how bad nginx is, how bad php is, yadda, yadda, yadda.
You can not blame nginx for this. nginx is just a tool. It has some things in it that prevents you from shooting into your own foot but it is not the job of nginx to 100% be foolproof. It is pretty much like saying that C is a bad language because you can dereference a null pointer or you could do stupid things with pointers.
Seems like we could really use a community consensus wrapped up in an nginx howto.
url.rewrite-if-not-file = ( "^/(.*)$" => "/index.php/$1" ) }
is all what I need to have prettyURLs in lighty. :-)
Sincerely,
Gour
But anyways, back to the actual topic: I strongly agree with wcravens, we should have a bunch of best practice howtos for nginx, lighty, cherokee and whatever there is one might work with.
I could do some testing or even write an article about it, but I'd need some help from the community as I don't work with anything but Apache these days!
As Apache seems to be the most common web server used with Concrete5 then I suggest starting a guide for Apache first then we can use that a template for documenting the other web servers.
I think the document should be more like a "guide" of best practices rather that saying pumping your MinSpareServers 500 is what you must do to achieve ultimate performance.
With all the options and circumstances to take into account do you think its possible to create such a guide?
ie do you want to discuss the various caching options, or do you just talk about APC?
Do you want to get into php_mod vs. fast_cgi method or just stick with php_mod?
Do you want to talk about tweaking MySQL? or how to look at the ampunt of RAM or CPU being used?
How do you measure if your server needs adjusting in some way?
Maybe a best practices guide is too broad a subject to cover within a few pages?
Paul
this thread started about how to make Concrete5 work under nginx and now you start to talk about ultimate performance (*), tweaking MySQL, using PHP accelerators, etc....
(*) IMHO there is no such thing as 'ultimate performance'. If you run a page that gets all the time on the front page of Slashdot, Reddit, etc then for sure you have other requirements (and viewpoint about performance) than a SME running your company page on Concrete5.
/index.php/tools/css/themes/greek_yogurt/main.css /index.php/tools/css/themes/greek_yogurt/typography.css
The other CSS requests are correct and return 200 OK:
/concrete/themes/greek_yogurt/css/text.css /concrete/themes/greek_yogurt/css/reset.css
As sbajic else pointed out (http://www.concrete5.org/community/forums/chat/any-plans-to-officially-support-installation-using-nginx/#358325), C5 should make uniform path requests.
BTW, is there a Concrete5 wiki? I can submit a howto, but I can't improve someone else's howto.
location ~ ^/index\.php/tools/css/themes/([^/]+)/(.*) { try_files /packages/theme_$1/themes/$1/$2 /concrete/themes/$1/$2 $uri; }
Everything else so far works without rewrites.
the site is being accessed when it breaks?
I've been trialing C5 with nginx for about a month... and given all the
experimentation that has been going on I'd be surprised if we didn't
touch all areas of the site. But in saying that we've not ran into any
problems such as this.
Thanks,
Wes
On 7/30/2012 6:20 AM, concrete5 Community wrote:
/index.php/tools/required/page_controls_menu_js?cID=1&cvID=&btask=&ts=1343692685
I issue a 301 redirect to /concrete/tools/page_controls_menu_js.php?cID=1&cvID=&btask=&ts=1343692685
Problem is, that PHP file just echoes "Access Denied".
This causes the admin bar to not display any buttons.
Mike
[NB: bug in the forum, the space character that I typed in the editor between "from" and "http" above, is eaten up when the message is rendered]
It works without requiring any rewrite rules, but the two CSS files that I reported, return a 404:
/index.php/tools/css/themes/greek_yogurt/main.css 404 (Not Found) /index.php/tools/css/themes/greek_yogurt/typography.css 404 (Not Found)
the nginx-directive:
location / {
try_files $uri $uri/ /index.php$request_uri /index.php;
}
location ~ \.php($|/) {
try_files $uri =404;
fastcgi_pass unix:/var/run/php5-fpm.sock;
include /etc/nginx/fastcgi_params;
fastcgi_index index.php;
set $script $uri;
set $path_info "";
if ($uri ~ "^(.+\.php)(/.+)") {
set $script $1;
set $path_info $2;
}
fastcgi_param URI $uri;
fastcgi_param PATH_INFO $path_info;
fastcgi_param SCRIPT_NAME $script;
fastcgi_param SCRIPT_FILENAME $document_root$script;
}
after that i restarted nginx (don´t know whether this is really necessary) with /etc/init.d/nginx restart
and what was MUCH important: my firefox (after having cleared cache) STILL told me that the PATH_INFO is not correct. so i opened a new browser with the setup and everything was OK. hope this helps someone to set up concrete5 with nginx in no time.....
http://www.concrete5.org/documentation/how-tos/developers/nginx-wit...
server { listen 80; server_name domain.com; root /home/domain.com/public_html/; index index.html index.htm index.php; access_log /var/log/nginx/domain_com-access; error_log /var/log/nginx/domain_com-error; autoindex on; rewrite_log on; log_not_found off; real_ip_header $http_x_forwarded_for; if (!-f $document_root$fastcgi_script_name) { rewrite (.*) /index.php/$1 break; } location ~ /\. { deny all; access_log off; log_not_found off; }
For me the issues were related with "Access denied" on dashboard and several editing blocks that were not working anymore (development has been carried on a Apache 2.4 with PHP 5.6, using mod-apache)
Focus was creating a working "location /"
try_files $uri $uri/ /index.php?q=$uri&$args;
server { listen 80; server_name www.example.com; root /var/www/example.com/www; index index.php index.html index.htm default.html default.htm; add_header Access-Control-Allow-Origin *; #add_header X-Frame-Options "ALLOWALL"; location = /favicon.ico { log_not_found off; access_log off; } location = /robots.txt { allow all; log_not_found off; access_log off;
I'm sure you can make concrete5 work on nginx, I don't see any reason
to "officially" bother with it however. ;)
best wishes
Franz Maruna
CEO - concrete5.org
http://about.me/frz