New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
nginx site-enabled vs conf.d/*.conf
Ever since I set up my first VPS to use nginx two years ago, I set it up the way everyone said to with two directories: sites-enabled and site-available with symlinks from available to enabled. This is usually cited as the "debian" way or style.
But by default, debian's nginx.conf includes conf.d/*.conf. It seems to me that the Debian way should be to simply put domain.conf into conf.d, and if you want to disable it just rename it to something like domain.inactive or domain.disable.
Am I missing something important? To me, this seems far simpler than dealing with two directories and symlinks.
Comments
Yes the site-enabled was very strange and I have enjoyed the conf.d/ approach a lot better
I prefer the sites-{enabled,available} thing, mainly because it is easier to just disable a site rather than deleting it/moving it somewhere temporarily.
I wrote a quick tutorial on how to do it: http://kamalnasser.net/nginx-apache-like-server-structure/
General settings (applied for all servers) should be in conf.d, servers and server-specific - in sites-{available, enabled}, so that somebody doesn't spend time on looking where the config for specific site is.
For example, I have conf.d/stuff.conf, where "client_max_body_size 50m;" option is set.
ls -all
vsls -all | grep .conf
i usually rename sites-{enabled,available} to {enable,avail}-sites for faster tab completion.
I like the ability to keep the config file around even if i dont want the site up.
conf.d/*.conf won't load site.name.disabled, but will load site.name.conf
I like conf.d/*.conf. Considering the nginx.org RPMs come with it by default, it's also slightly easier.
sites-enabled/sites-available is definitely the standard debian way. The same is used for apache2 in debian, and there's the a2ensite and a2dissite scripts to manage it. I presume that they've done it this way for nginx simply to keep things standardized, which makes sense. That's pretty much one of the core philosophies of Debian - do everything the same way if possible.
@NickM
If it were the standard Debian way, wouldn't Debian packages come configured that way?
@tweakstur
alias active="ls -al /etc/nginx/conf.d | grep .conf"
@breton
For example, I have conf.d/stuff.conf, where "client_max_body_size 50m;" option is set.
I can perhaps see that, but if it's going to apply to everyone, why not just put it in the main nginx.conf?
Install apache2 in debian. You'll find that any configuration file in /etc/apache2/sites-enabled gets used, by default.
Install nginx in debian. You'll find that any configuration file in /etc/nginx/sites-enabled gets used, by default.
So, I'm not sure what you're saying here...
@NickM
Right you are. I just tested vanilla squeeze and dotdeb, and both use sites- directories. I also tested nginx's repository, and it does not include them. I'm pretty sure I installed them directly from nginx before I knew about dotdeb, and hence thought that was debian's default. Learn something new every day. Previously I had compiled it, so it made sense that I would have to create the sites- directories.
This is just semantics, use whatever you yourself want. There's no reason to change the default, I personally like the Debian way a lot better too.
Because main nginx.conf may be overwritten after upgrade. The only place where a user should change (configure) something is "conf.d/" and "sites-{available,enabled}". Everything else may be suggested for overwriting during upgrade.
The new config is created as nginx.conf.rpmnew (when using the official nginx packages)
@dmmcintyre3
He did say suggested for overwriting.
@breton
Are you being literal, as in you would not even change the worker_processes or worker_connections? Or do you mean just minimize changes so that the differences are minimal on upgrade?
I dunno, I was talking about debian.
If I wanted to change it, I'd do it in either specific "server {}" section, or in "conf.d/connections_settings.conf" file, but not in "nginx.conf". Files in conf.d/ are not overwritten by the package manager.
Funny, "worker_processes" is in the "main" context of configuration file. Reading about it now.
Yep, it's in "main" context only. That sucks pretty much. I don't know then whether the package manager will overwrite the "nginx.conf" at all. If it bothered me, I'd file a bugreport against "nginx" debian package.
Well, it seems then that semantics is one good reason for such division.
+that.
In which case it will be nginx.conf.dpkg-dist, assuming you don't choose to overwrite it when prompted.