Why is sites-enabled and sites-available deprecated?

In complete nginx cookbook it says

"The /etc/nginx/conf.d/ directory contains the default HTTP server configuration file. Files in this directory ending in .conf are included in the top-level http block from within the /etc/ nginx/nginx.conf file. It’s best practice to utilize include state‐ ments and organize your configuration in this way to keep your configuration files concise. In some package repositories, this folder is named sites-enabled, and configuration files are linked from a folder named site-available; this convention is deprecated."

But why is that convention deprecated? I always felt it was easier to maintain multiple sites by just removing/adding the symlink between sites-available and sites-enabled, thus giving me control over which sites to serve without deleting configurations which I might again need in future.

If I use the new structure where all configs for all sites come from same conf.d folder, I'll have to rename file to not have conf extension or remove that conf file completely in order to temporary keep site unavailable.

Is there any new and better pattern/convention that I'm missing?

6 thoughts on “Why is sites-enabled and sites-available deprecated?”

  1. TIL

    I don’t like `*` includes, but it seems reasonable that adding/removing (commenting out) a line in `nginx.conf` would be more reasonable than symlinking.

    Reply
  2. No idea.

    I still use this pattern on every platform where I use either nginx or apache. It’s much easier wrt config management to drop in whatever file you need to the include directory than it is to programmatically/selectively edit the main config. Whoever thinks this is a bad idea doesn’t understand systems management.

    I *still* plan to use this pattern until they completely remove the capability from the code. Even then, I might patch it back in.

    Reply
  3. The package will behave differently depending from where it was pulled. Either approach works and can be used no matter what package you are using. You’ll just need to customize the configuration.

    The sites-enabled was set up to mimic the way apache behaved (as mentioned by u/BattlePope in the comments using the a2ensite cli command). The NGINX packages moved away from this concept many years ago, but the debian/ubuntu packages have kept it around.

    That being said, the sites-enabled setup makes less sense when you are dealing with systems that are managed via automation rather than people logging in and configuring the system manually. One approach is somewhat hybrid, leveraging the conf.d director but including set to conf.d/\*.conf to avoid loading files that are in that dir but are not config files.

    Reply
  4. The Debian-specific convention caused unnecessary confusion. Consider:

    * It is more convenient to rename a file in conf.d/ (change the extension to something other than “.conf”) than to manage symbolic links across directories (by default, all files in sites-enabled are processed, regardless of extension).
    * Novice administrators might put a configuration file in sites-available, instead of a symbolic link. Hilarity ensues later, when the file is deleted in an attempt to “disable” the site.
    * Or the file is copied to sites-enabled, instead of symbolically linked, leading to more hilarity as the file versions grow out of sync.
    * Trying to shoehorn the nginx configs into an apache mindset blurs the lines between the two engines in an inconsistent and non-portable way. Nginx administrators from other architectures have an unnecessary learning curve to assist Debian users.
    * The symbolic link mechanism is so clunky that a concerned netizen saw fit to write popular scripts to perform the task. See [https://github.com/perusio/nginx\_ensite](https://github.com/perusio/nginx_ensite) .
    * conf.d is significantly shorter to type than sites-available / sites-enabled (and you need to type both, frequently) even with tab completion.

    A pox on the house of whomever thought this was a good idea to release at the distribution level.

    Reply

Leave a Comment