Any plans to "officially" support installation using Nginx?

Permalink 2 users found helpful
This page only mentions Apache and IIS:
http://www.concrete5.org/documentation/background/system_requiremen...

Do the core c5 developers plan test/document/recommend the use of Nginx?

cytringan
View Replies:
frz replied on at Permalink Reply
frz
Nah, apache seems great to us.

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
cytringan replied on at Permalink Reply
cytringan
"Nginx may not be as well-known as Apache and IIS, but it does not seem that will be the case for much longer. Its low resource, fast performance design is attracting adopters from Facebook to Dropbox."

http://www.cmswire.com/cms/web-cms/nginx-continues-its-rise-to-the-...
frz replied on at Permalink Reply
frz
Totally for competition and all, just looking at how we want to spend
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
sbajic replied on at Permalink Reply
sbajic
Which web servers are officially supported? Just Apache and IIS?

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?
frz replied on at Permalink Reply
frz
It's really not. You can likely run concrete5 on any webserver that
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!
sbajic replied on at Permalink Reply
sbajic
I can easily provide you a working configuration for nginx. The problem for me is that I am not a user of the CMS. I just provide it to others (if they want it) and that's all. So for me it is like a small black box. I have no clue how it is working internally. So getting it to work was ultra giga easy in nginx. But then I get complains that things don't work and deliver error 404. Just to name one:

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?
cytringan replied on at Permalink Reply
cytringan
I think we can help each other;

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?
sbajic replied on at Permalink Reply
sbajic
This here is for sure wrong!

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.
JohntheFish replied on at Permalink Reply
JohntheFish
I know nothing about nginx, but it looks like you may be making life too complicated for yourself.

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.
sbajic replied on at Permalink Reply
sbajic
You are funny. Do you think that I have not mirrored that trivial .htaccess functionality already? I have and it still does not work. I get those 404 and therefore I have to do the rewrites I have mentioned above.

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?
JohntheFish replied on at Permalink Reply
JohntheFish
CGI Variables (which in some cases get mapped to php variables by php)

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.
sbajic replied on at Permalink Reply
sbajic
Could you post one or two such links where people are mapping variables.

btw: I do those mappings too. Ningx has that mapping out of the box.
JohntheFish replied on at Permalink Reply
JohntheFish
All I did was enter nginx in the search box and click in and out of the first couple of pages of results:

http://www.concrete5.org/community/forums/-/view/?sort=relevance&am...
sbajic replied on at Permalink Reply
sbajic
Thanks for the link. I read all the messages and none of them is helpful to me. Most of them have issues with PATH_INFO and such but I don't have that issue. I am properly having that variable assigned even without using cgi.fix_pathinfo.

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.
cytringan replied on at Permalink Reply
cytringan
Seems like we found a different way to approach the problem. it seems to be working without a gazillion rewrite rules. I'll test it over the next days and report back!
sbajic replied on at Permalink Reply
sbajic
Who is "we"?
wcravens replied on at Permalink Reply
wcravens
This nginx config has worked for me so far... it's possible I've just not been bitten yet but I figured I'd get the suggestion out there:

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.
sbajic replied on at Permalink Reply
sbajic
Ohhh boy. That config is crying for trouble. Those if's look like you used the automatic tool on the web that transforms Apache's .htaccess into nginx rewrite rules. It is very bad. Bad, bad, bad. Read here why ->http://wiki.nginx.org/IfIsEvil

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;
}
ntisithoj replied on at Permalink Reply
ntisithoj
for the record, this .htaccess completely bvreaks the straing-out-of-the-box dev install


seehttp://www.concrete5.org/developers/bugs/5-6-1-2/pretty-urls-not-wo...
ggn06awu replied on at Permalink Reply
ggn06awu
I've just done some load testing on this subject, and found surprising results. Bare with me, as this was only exploratory! This testing was performed on EC2 with a small RDS (separate MySQL box in AWS) backing it.

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
sbajic replied on at Permalink Reply
sbajic
Your benchmark is just testing how well PHP is processed in Apache/nginx. This will not make nginx magically faster than Apache. For sure not with just 50 concurrent connections. Try the same thing with 1'000 concurrent connections and go up till over 10'000 concurrent connections and check the memory usage. You will see that Apache usually uses more memory than the nginx system. This is manly because Apache users often use the pre-fork MPM and together with mod_php you will end up in more memory used than in the typical nginx + php-fpm combo. Even if you use another MPM than pre-fork you will end in more memory (and indirectly more CPU power) used with mod_php.

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.
Remo replied on at Permalink Reply
Remo
I still have an ancient c5 version running on nginx without any problems. I stopped using it as it couldn't get much benefits from it and using a widely known webserver every employee of mine knows how to use seemed to be the better choice.

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;
}
sbajic replied on at Permalink Reply
sbajic
Hoi Remo,

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
Remo replied on at Permalink Reply
Remo
Hey Steve, I've read that post but I don't see why my configuration should be evil. The article you've linked that doesn't that you mustn't use if's, it also says that there are situations where it's actually safe to use!

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..
sbajic replied on at Permalink Reply
sbajic
Hi Remo. Where did you had that if? Enclosed in a location statement?
Remo replied on at Permalink Reply
Remo
No, server
sbajic replied on at Permalink Reply
sbajic
So you used FastCGI variables inside a server {} block without knowing if the request was a FastCGI request. Really?
Remo replied on at Permalink Reply
Remo
Yes. Can you please be a bit more elaborate instead of just telling everyone that their configuration is bad? That would be a bit more constructive..
cytringan replied on at Permalink Reply
cytringan
REMOVED!
sbajic replied on at Permalink Reply
sbajic
What?
sbajic replied on at Permalink Reply
sbajic
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...
Remo replied on at Permalink Reply
Remo
All right thanks, I see what you mean! I don't think that will ever happen on my site but if we wanted to have a "best practice" solution for nginx why should certainly consider this.

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.
sbajic replied on at Permalink Reply
sbajic
I don't take it personally. Why should I?

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.
wcravens replied on at Permalink Reply
wcravens
The extra info is really appreciated.

Seems like we could really use a community consensus wrapped up in an nginx howto.
gour replied on at Permalink Reply
gour
url.rewrite-if-not-file = (
  "^/(.*)$" => "/index.php/$1"
  )
}


is all what I need to have prettyURLs in lighty. :-)


Sincerely,
Gour
Remo replied on at Permalink Reply
Remo
I'm not saying C is a bad language, but C like any other language or tool can be a bad choice depending on what you're trying to achieve.. A configuration should imho be easy and safe.

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!
cytringan replied on at Permalink Reply
cytringan
Hi Remo,

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
sbajic replied on at Permalink Reply
sbajic
Hello 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.
Remo replied on at Permalink Reply
Remo
I agree, first we should find the proper setup for nginx. If we end up getting more configurations (in a different forum thread) we can assemble them in a guide. If we can also explain why APC does not necessarily work with concrete5 even though it's active, fine, but that's a different story..
dandv replied on at Permalink Reply
dandv
OK, so where is the guide on getting Concrete5 to work with nginx properly? Out of the box, with a standard nginx config (no rewrite rules), I get two requests to wrong paths that 404:
/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.
sbajic replied on at Permalink Reply
sbajic
Unfortunately I can not make it working without this rewrite:
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.
wcravens replied on at Permalink Reply
wcravens
Can you guys provide an example of when it breaks? E.g. what area of
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:
dandv replied on at Permalink Reply
dandv
Here's something that breaks:

/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.
dandv replied on at Permalink Reply
dandv
sbajic, I reported as a bug the fact that some of these paths are inconsistent, but Mnkras replies that this is not a bug -http://www.concrete5.org/developers/bugs/5-5-2-1/inconsistent-paths...
Mnkras replied on at Permalink Reply
Mnkras
This is correct, those are the correct paths, if you make a demo acct (using the instant setup link at the top of the page) you will see that this is correct. Do you have a nginx setup that I could possibly debug?

Mike
dandv replied on at Permalink Reply
dandv
I'm using nithin's config fromhttp://www.concrete5.org/community/forums/installation/deploying-co...

[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)
hajonolte replied on at Permalink Reply
hajonolte
this thread is a little bit old, but i was wasting over 1 hour to get the installation of concrete5 running on nginx. so this is what i 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.....
vipkilla replied on at Permalink Reply
Here is the How-to guide for concrete5 and nginx (with php5-fpm):
http://www.concrete5.org/documentation/how-tos/developers/nginx-wit...
rfs1970 replied on at Permalink Reply
I know it is an old post, but to help others setting concrete5 in Nginx+php-fpm, here is my settings:
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; }