Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In with OpenID
Advertise on LowEndTalk.com

In this Discussion

nginx site-enabled vs conf.d/*.conf

nginx site-enabled vs conf.d/*.conf

patrokovpatrokov Member
edited October 2012 in Help

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.

Tagged:

Comments

  • Yes the site-enabled was very strange and I have enjoyed the conf.d/ approach a lot better

    PrismaVPS - Kansas City and Romania OpenVZ VPS Hosting. Plans start at $4/mo
  • 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/

    Thanked by 1Chief
  • bretonbreton Member
    edited October 2012

    @patrokov said: 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.

    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.

    Thanked by 2Chief tux
  • ls -all vs ls -all | grep .conf

  • flyfly Member

    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.

  • @fly said: 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

    FreeVPS.us - The oldest post to host VPS provider
  • I like conf.d/*.conf. Considering the nginx.org RPMs come with it by default, it's also slightly easier.

    "We are in a prison drama. This is like The Shawshank Redemption, only with more tunneling through shit and no fucking redemption."
  • 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.

  • patrokovpatrokov Member
    edited October 2012

    @NickM

    sites-enabled/sites-available is definitely the standard debian way

    If it were the standard Debian way, wouldn't Debian packages come configured that way?

    @tweakstur

    ls -all vs ls -all | grep .conf

    alias active="ls -al /etc/nginx/conf.d | grep .conf"

    @breton

    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.

    I can perhaps see that, but if it's going to apply to everyone, why not just put it in the main nginx.conf?

  • @patrokov said: If it were the standard Debian way, wouldn't Debian packages come configured that way?

    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...

    Thanked by 1patrokov
  • @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.

  • WintereiseWintereise Member
    edited October 2012

    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.

    -- BOFH

  • @patrokov said:

    I can perhaps see that, but if it's going to apply to everyone, why not just put it in the main nginx.conf?

    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.

    Thanked by 1patrokov
  • dmmcintyre3dmmcintyre3 Member
    edited October 2012

    @breton said: Because main nginx.conf may be overwritten after upgrade.

    The new config is created as nginx.conf.rpmnew (when using the official nginx packages)

    FreeVPS.us - The oldest post to host VPS provider
  • @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?

  • bretonbreton Member
    edited October 2012

    @dmmcintyre3 said:

    The new config is created as nginx.conf.rpmnew (when using the official nginx packages)

    I dunno, I was talking about debian.

    @patrokov said: Are you being literal, as in you would not even change the worker_processes or worker_connections?

    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.

  • bretonbreton Member
    edited October 2012

    Funny, "worker_processes" is in the "main" context of configuration file. Reading about it now.

  • bretonbreton Member
    edited October 2012

    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.

    @patrokov said: Or do you mean just minimize changes so that the differences are minimal on upgrade?

    +that.

  • sleddogsleddog Member
    edited October 2012

    @breton said: @dmmcintyre3 said:

    The new config is created as nginx.conf.rpmnew (when using the official nginx packages)

    I dunno, I was talking about debian.

    In which case it will be nginx.conf.dpkg-dist, assuming you don't choose to overwrite it when prompted.

Sign In or Register to comment.