What does it mean when I see both "nginx.conf" and "nginx.conf.default" configuration files? I also see "fastcgi.conf" and "fastcgi.conf.default" and "fastcgi.params" and "fastcgi.params.default" etc, in the same folder.
Does ".conf.default" get applied and then the ".conf" gets applied on top of it?
Nginx will strictly load the configuration from the .conf files unless you haven't specified otherwise (like using an include rule and include a file with other extension that .conf).
.conf.default files are not applied on top of the .conf files. In fact they are not applied at all.
As far as I know this behaviour appears on debian when you do update nginx (but I might be wrong).
Related
I use Nginx with many domains. Some of these domains have custom configurations. I'm including these files inside the server blocks in the Nginx configurations.
For example:
server {
... some configurations things here...
include /var/somewhere/custom.conf;
etc.. etc..
}
The configuration files of Nginx are inside: /etc/nginx
To try and keep everything in one place and not have my custom configuration files all over the place I would like to place my custom configuration files inside /etc/nginx/some_directory
Can I create a sub directory inside /etc/nginx without it causing any issues with Nginx itself? I want to create /etc/nginx/some_directory/ and place my many custom configuration files inside it and include them.
I'm specifically asking this question because I don't want to break something on my production server.
If nginx doesn't know about a directory, it'll not touch it. You can verify that by greping against such pattern in nginx's codebase.
However, messing with a foreign folder structure might cause problems with permissions and ownership of the files, therefore either just use a pre-defined folders nginx prepared for you (/etc/nginx/sites-enabled and /etc/nginx/sites-available) which you can use with symlinks such as nginx itself does
# ls /etc/nginx/sites-enabled
default -> /etc/nginx/sites-available/default
# ls /etc/nginx/sites-available
default
otherwise you're getting into a situation what C/C++ programmers call an undefined behavior and there's no guarantee that what works now will work in the future / nginx doesn't change as well as the distro maintainers might mess with the folder structure and permissions for the packages in distro package manager.
Example:
Nginx might verify the full /etc/nginx tree's permissions and owners - if your folders/files don't match it might cause a warning or crash even. If it's installed by a package manager, it might cause issues when removing the package itself e.g. if the package manager attempts to remove only a known list of folders + afterwards the parent i.e. /etc/nginx by rmdir or similar. Situations you don't really want to get into and debug when you can use allowed folders or symlinks or your own folders that are not bound to an application or behavior except the one you define.
It seems my server setup does not support headers in .htaccess
When I try to add this below code in .htaccess file, My site breaks.
<filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|svg|js|css|swf)$">
Header set Cache-Control "max-age=84600, public"
</filesMatch>
So my question is how do I install mod_headers in the GCP where my apache server is.
For the httpd.conf file: following is the tutorial
https://www.onepagezen.com/add-expires-headers-wordpress-bitnami/
But my server uses apache2.conf file instead of the httpd.conf
Can't find the solution, any inputs?
Man, I've had the same issue.
First off, next time you setup a wordpress via GCP, try out KUSANAGI OS, incredibly fast.
You need to make sure you put the FilesMatch config in the right spot.
httpd/apache2 and the way they load conf seems to be rather complex, so I can't provide a specific reason as why it doesn't work when you place it.
BUT!
according to: https://serverfault.com/questions/648262/filesmatch-configuration-to-restrict-file-extensions-served
you might have a chance by trying to place it in v_host.conf, as per:
The FilesMatch directive is applied against the "directory" hit prior to the mod-dir
DirectoryIndex directive assignment to "index.htm." As a result, a "null" condition
must pass the test in order for the request to be handled. With that, this set up
(all the same except for this change to the V_HOST.conf file) works:...
I have a custom nginx.conf file that I start nginx with using the cli, for example nginx -c /my/path/nginx.conf.
I have found that if I take the include /my/path/mime.types from the custom nginx.conf file, that the server still starts up fine, and webpages seem to load normally with no apparent errors.
I have been researching nginx directive priority, but I cannot see any reason that the default mime.types might be getting included. Is it safe to remove the custom mime.types include?
(I should clarify that there is nothing special about the contents of /my/path/mime.types. For the purposes of this question, consider it to be effectively the same as the contents of the default file.)
Actually i did some tests and concluded that if you comment out the mime.types line in the /etc/nginx/nginx.conf file
# include /etc/nginx/mime.types
And restart nginx
sudo service nginx restart
And you clear the browser cache before accessing again your page, you will notice that nginx will not take advantage of mime.types configuration (of course), and will NOT render correctly the media type of your content.
The following example, shows how styles.css is rendered (Content-Type: application/octet-stream) instead of text/css
To sum up, yes mime.types is required for nginx to render the right media type of content.
There are two config files around, /etc/nginx/conf.d/default.conf
and /etc/nginx/nginx.conf, but which one is enabled?
I am running CentOS6.4 and nginx/1.0.15.
Technically, nginx.conf is all that matters, if you define every thing inside there it would still work, but to keep things organized, they use include, somewhere at the end of nginx.conf you'll see include /etc/nginx/conf.d/* and in some distros you'll also find include /etc/nginx/sites-enabled/* this is a convention to keep things organized, you create your server blocks in that conf.d or sites-enabled folder and it would be included here as if it's written in the nginx.conf file.
Of course you can add your own include lines there normally and create your own new conf folder that would be auto included.
TIP: These files are included in alphabetical order, you need to keep that in mind if you don't specify any server as default_server, because first one would be the default.
the general configuration of nginx is in /etc/nginx/nginx.conf. /etc/nginx/conf.d/default.conf is used to configure the default virtual host. For this you can also use sites-available and sites-enabled.
You can find more details at a blog entry from digital ocean How To Configure The Nginx Web Server On a Virtual Private Server
for save time.
if you just have 1 site to host, nginx.conf is ok. but,
if you have 2~n sites, for more clear config, you should use conf.d fold.
I have a folder, and for all php files in that folder (or even better, in that folder or any folders within it) I'd like to make some changes to the php settings. Can I just place a php.ini file in that folder with those settings I'd like to change?
If so, any reason why this wouldn't be working for me? It's my own server.
Thanks!
edit: I'd like to be able to use a local php.ini file, as I've been able to do with several webhosts. Is this a possibility?
It looks like you're wanting to use per-directory php.ini files which are available as of PHP 5.3. If it's your own server, I'd like to think you're happy to keep up with the latest stable releases (currently 5.3.2). Back to ini files, to quote that manual page:
Since PHP 5.3.0, PHP includes support for .htaccess-style INI files on a per-directory basis. These files are processed only by the CGI/FastCGI SAPI. This functionality obsoletes the PECL htscanner extension. If you are using Apache, use .htaccess files for the same effect.
In addition to the main php.ini file, PHP scans for INI files in each directory, starting with the directory of the requested PHP file, and working its way up to the current document root (as set in $_SERVER['DOCUMENT_ROOT']). Only INI settings with the modes PHP_INI_PERDIR and PHP_INI_USER will be recognized in .user.ini-style INI files.
You'll have to use a .htaccess file for that. There a section in the PHP manual about that:
http://php.net/manual/en/configuration.changes.php
For more general information on htaccess files you can read:
http://en.wikipedia.org/wiki/Htaccess
or
http://httpd.apache.org/docs/2.0/howto/htaccess.html
The .htaccess files are typically the best way to go for an Apache server. However, to answer your original question, yes you can set a php.ini file in every directory if you want. However, in order for it to work, PHP must be set to run as PHP-CGI. My guess is that you are running PHP as an Apache module.
See this link for reference on where PHP looks for php.ini and when it looks for it: http://www.php.net/manual/en/configuration.file.php
You could also use ini_set(), if you wanted to do it in code.
instead of modifying php.ini file for each folder you would be required to modify a .htaccess file. Keep the file in the folders with whatever setting you like. You cant do this with a php.ini file since changes in php.ini are considered server wide