Equivalent of Apache's SetEnv Variable

Issue:
I’d like to configure Magento to run in multi-domain mode.
I’ve been successful doing this via Apache in the past.
It seems that Nginx should be equally capable, but I haven’t succeeded.

Server Specs:
Nginx (latest)
PHP 5.3.3
PHP-FPM enabled
Magento (latest)

What I Know:
Apache relies on the SetEnv variable in the virtual host definition or
a similar instruction in an .htaccess file to achieve this
functionality. The specifics are here:
Adobe Commerce Documentation.

What I Don’t Know:
Does Nginx have an equivalent to SetEnv?
Can Nginx be configured to imitate this configuration through rewrites
or some other method?

Larger Community to Benefit:
There are a number of people in the Nginx forum, Magento forum, etc.
asking about this. It would be stellar if someone could provide us
with a definitive answer - even if that answer is ‘it can’t be done’
or ‘proxy Nginx to Apache’. If anyone supplies an answer via the
mailing list, I will make sure that the answer is shared in the forums
and elsewhere for maximum benefit.

Thanks so much!

http://wiki.nginx.org/NginxHttpFcgiModule#fastcgi_param

On Thu, Jul 29, 2010 at 11:18:07AM -0500, Raina G. wrote:

What I Know:
Apache relies on the SetEnv variable in the virtual host definition or
a similar instruction in an .htaccess file to achieve this
functionality. The specifics are here:
Adobe Commerce Documentation.

What I Don’t Know:
Does Nginx have an equivalent to SetEnv?
Can Nginx be configured to imitate this configuration through rewrites
or some other method?

Probably, you need

 server {

     location / {
         fastcgi_pass   ...
         fastcgi_param  MAGE_RUN_CODE  base;
         fastcgi_param  MAGE_RUN_TYPE  website;
         ...
     }
 }


Igor S.
http://sysoev.ru/en/

I’ve tried several variations, but haven’t been able to get this
working. The virtual hosts are set up fine, and both domains will load
a home page, but Magento doesn’t seem to be picking up on the
MAGE_RUN_CODE or MAGE_RUN_TYPE variables being set. From the secondary
home page, all links (category/product pages) point to those pages on
the main domain. I’m confident everything within the Magento database
configuration is set up correctly.

Here’s what I’ve got:
Primary domain: http://dev.swimkitten.com/
Secondary domain: http://dev.swimkitten.co.uk/

/etc/nginx/nginx.conf - http://pastie.org/1073715
/etc/nginx/conf.d/dev.swimkitten.com.conf - http://pastie.org/1073720
/etc/nginx/conf.d/dev.swimkitten.co.uk.conf - http://pastie.org/1073722
/etc/fastcgi_params - http://pastie.org/1073725

Any further thoughts? I’ve tried putting the variables in:
location /
and
location ~ .php$

I haven’t yet tried making 2 separate fastcgi_params files and
pointing to the respective ones from within each domain.conf file.

Thanks for any further help with this!

Fabulous. Thank you. I will try it and report back asap.

A quick note your fastcgi_param should do it. Are you sure it’s in all
the locations it needs to be?

It should expose those as $_SERVER variables.

Ok. That’s really helpful information. Right now, both of these output
nothing:

<?php echo $_SERVER['MAGE_RUN_CODE']; ?> <?php echo $_SERVER['MAGE_RUN_TYPE']; ?>

That is what you meant, right? I’ll investigate further.

Ok, great. I just noticed that the Magento config listed on the Nginx
Wiki is way different than the one I’d grabbed from the Magento
forums. I’ll wade through those differences in a little while and see
if I can reconcile them intelligently.

I don’t have a solid understanding of this stuff - so allow yourself
to be inspired by anything I post at your own risk. :slight_smile: Trial and error
is my major MO.

Thanks for your insight, Michael.

yeah, var_dump($_SERVER) - should show you normal variables.

Do you see $_SERVER[‘HTTPS’]?

I think the key location you’re missing is putting it in here:

location ~ .php$ { ## Execute PHP scripts
expires off; ## Do not cache dynamic content
fastcgi_param HTTPS $fastcgi_https;
fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_script_name;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include fastcgi_params; ## See /etc/nginx/fastcgi_params

try adding these?

         fastcgi_param  MAGE_RUN_CODE  base;
         fastcgi_param  MAGE_RUN_TYPE  website;

}

FYI, I was not aware of an $fastcgi_https variable. If there is one,
that is awesome and I need to add that to my fastcgi_params - it
should be default as most apps seem to rely on $_SERVER[‘HTTPS’]

I am going to go look if it exists or not :slight_smile:

On Tue, Aug 3, 2010 at 4:45 PM, Raina G. [email protected]
wrote:

Ok, great. I just noticed that the Magento config listed on the Nginx
Wiki is way different than the one I’d grabbed from the Magento
forums. I’ll wade through those differences in a little while and see
if I can reconcile them intelligently.

btw where do you define this value?

fastcgi_param  HTTPS $fastcgi_https;

I don’t see any place in the nginx source code where $fastcgi_https is
a legitimate variable. are you defining it yourself somewhere else?

As I mentioned, I don’t really know what I’m doing.

This is where I got my initial configuration from, though, in the
Magento forums. Perhaps the user who posted there can shed some light?
http://www.magentocommerce.com/boards/viewthread/7931/#t211050

Hope that helps. Once I do get this sorted out in a way that is
satisfactory to me, I will post on the wikis. I’ll post the steps I’ve
taken to compile and install the latest versions of PHP, Nginx and
MySQL for Magento, too, as there were a few sticky bits involved. The
information floating around on Nginx+Magento isn’t exactly abundant.
I’m going to try and get things working with APC cache and/or Varnish,
too, before I consider this work done. Right now, PHP-FPM is being a
total memory hog, even on my virtual server that has no traffic and
just one default Magento installation. Not quite sure how to tackle
that yet, either. I personally do like Magento a lot, though
optimizing it for performance is a chore!

Thanks again for your time!

So far, so good. I’d tried this location previously, but hadn’t tested
with the variable dump, so didn’t think it was working. I removed it
from location /, and it is still working. location ~ .php$ alone
seems to be adequate, and each domain is respecting it’s unique
settings in the var dump.

I personally don’t use location / unless absolutely needed.

On Tue, Aug 3, 2010 at 4:45 PM, Raina G. [email protected]
wrote:

Ok, great. I just noticed that the Magento config listed on the Nginx
Wiki is way different than the one I’d grabbed from the Magento
forums. I’ll wade through those differences in a little while and see
if I can reconcile them intelligently.

I don’t have a solid understanding of this stuff - so allow yourself
to be inspired by anything I post at your own risk. :slight_smile: Trial and error
is my major MO.

Thanks for your insight, Michael.

I have to say that that config you were using seemed extremely
overkill. However, depending on how Magento is designed (and I haven’t
heard a lot of positive feedback about it) it could require a lot of
oddball configuration.

What I’ve realized over the couple years I’ve been using nginx is that
most people overengineer their configuration. I hardly ever need more
than a few lines of special sauce for anything I’ve ran in nginx. Of
course, I’m a minimalist.

On 04/08/2010 01:21, Michael S. wrote:

What I’ve realized over the couple years I’ve been using nginx is that
most people overengineer their configuration. I hardly ever need more
than a few lines of special sauce for anything I’ve ran in nginx. Of
course, I’m a minimalist.

However, all the default configs that I have seen for PHP setups on the
wiki, etc, seem insecure to my mind. They nearly all point all files
named xx.php to be processed by the your php interpreter. Coupled with
nearly all non trivial applications having some “upload” feature this
allows a gaping potential issue to upload arbitrary files named xx.php
and you are allowing arbitrary code to be uploaded…

I setup my machines to only point files in limited directories to be
processed by the php interpreter. Coupled with specific handling of any
upload/temp/template/public directories or anywhere else that might
accidently contain something it shouldn’t…

See, just checked the wiki. Surely this example allows you to
immediately upload a new file with a .php suffix and exploit the server?
http://wiki.nginx.org/NginxMediaWiki
Does Drupal allow uploads? If so then good luck…
Nginx, Fastcgi, PHP, rewrite config for Drupal | Drupal.org
Surely Dokuwiki allows uploads?
Dokuwiki | NGINX

Make your config secure! Don’t just trust the upload function parsing
and allowing only certain filename patterns!

Good luck

Ed W

On Wed, Aug 4, 2010 at 2:44 PM, Ed W [email protected] wrote:

However, all the default configs that I have seen for PHP setups on the
wiki, etc, seem insecure to my mind. Â They nearly all point all files
named xx.php to be processed by the your php interpreter. Â Coupled with
nearly all non trivial applications having some “upload” feature this allows
a gaping potential issue to upload arbitrary files named xx.php and you are
allowing arbitrary code to be uploaded…

Someone just posted this on my blog:

location ~ .php$ {

try_files $uri =404;

}

exploit http://site.ru/images/as5df3.jpeg/.php

might be an interesting approach, haven’t tried it yet. would this add
an additional stat call or two though for every PHP request, Igor?

Well magento is not known to be the best piece of software.

I may be working with magento and nginx soon but not sure. Was looking
forward to seeing how I could tame that beast.

Php-fpm itself isn’t a memory hog it’s a combination of the php
built-ins, modules, and configuration and then the code itself. I have
certain pools that average more ram per process than others - it is most
likely due to apc usage and/or just the underlying php code. My pool
averages less because I write pretty tight php code; another client runs
a vbulletin forum with lots of addons and his memory usage per php
process is much higher.

On Wed, 2010-08-04 at 22:44 +0100, Ed W wrote:

See, just checked the wiki. Surely this example allows you to
immediately upload a new file with a .php suffix and exploit the server?
http://wiki.nginx.org/NginxMediaWiki

Mediawiki doesn’t allow that. It filters by an allowed list of
extensions, and .php isn’t among them.

Of course, if you can also let Nginx provide another ounce of
prevention, then all the better. Unfortunately most PHP applications
expect to be able to run arbitrary PHP scripts from almost any directory
under the sun, so you can either account for each and every script
(hopefully they put included files in a separate directory) or simply
make sure that it’s not possible to upload files ending with .php.

Regards,
Cliff

On Wed, Aug 04, 2010 at 02:48:07PM -0700, Michael S. wrote:

location ~ .php$ {

try_files $uri =404;

}

exploit http://site.ru/images/as5df3.jpeg/.php

might be an interesting approach, haven’t tried it yet. would this add
an additional stat call or two though for every PHP request, Igor?

Yes, it adds a stat() syscall, however, it can be eliminated with
open_file_cache. Note also, that it works only if nginx and php are
on the same host.


Igor S.
http://sysoev.ru/en/

Yeah I expect nginx to only be aware of the filesystem it has access to.
So open_file_cache saves stat calls? How do you invalidate the cache if
a file is removed? Or if I put a new file that wasn’t there I want it to
instantly show up not 404 for a while? Apologies if you’ve covered this
already.