nginx-ui

nginx-ui copied to clipboard

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

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.

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.

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

I think so.