No support of default sites-available/sites-enabled logic

[Soul6in6Gun]

Title says it all - tool searches default and common conf.d dir for webhost config but ignores typical debian\ubuntu's config dir of sites-available with symlinks in sites-enabled. I bet this is simple thing to add (probably this should be customizable for many other cases).

[kennyparsons]

Adding to this: I dont use the sites-available/sites-enabled logic, but rather simple folders of the different .conf files. The folders are almost like categories: php sites, static web servers, proxy sites, etc. So it seems there needs to be some logic built in.

As a proposed solution: nginx itself already has this logic when it builds the configuration. The output of nginx -T will show every site enabled to be served up with the path to the configuration file. Here's a snippet of mine:

# configuration file /etc/nginx/conf.d/php/files.techup.dev.conf:
    server {
        listen                  80;
        #items omitted
        location ~ \.php$ {
            fastcgi_pass        unix:/run/php/php7.3-fpm.sock;
            include             fastcgi_params;
            fastcgi_param       SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_param       SCRIPT_NAME $fastcgi_script_name;
        }
    }

As you can see here, by parsing the output of nginx -T, we can very easily get the absolute path of every config file used. The great part is that it would be user agnostic. @Soul6in6Gun and I have different methods to organize our .conf files, but parsing the nginx compiled configuration would work for both of us, without modification.

[Soul6in6Gun]

Yeah, this thing could be parsed from configs itself. Although even simple manual option "check this path for webhost config" is enough for many cases imo - this covers up our requests.

[schenkd]

Hello @Soul6in6Gun and @kennyparsons, these are a very good points!

I hear two things from this discussion:

Point 1: is the way available and enabled sites are managed is different. In your example it uses the well-known separation of two different directories which is also known from the Apache web server. This is because I currently only support the nginx type structure. I could implement both logics and have them controlled by an environment variable/or other parameter.

Point 2: is the use of subdirectories for the organization of pages etc. This is another problem I can solve by adjusting the way such files are looked at. Should both be feasible and will be worked out by me in the next release.

Have I understood your requirements correctly?

Best David

[kennyparsons]

I think so.