10.0.0.1/cgi-bin/luci
You mean I should access 10.0.0.1/ instead?
yes 
also test it with another browser
You need to be more specific. This sound more like nginx stuff than LuCI, so it should be in the nginx makefile. One more package to be defined in the nginx makefile.
One way is to have the package in packages repo, and then have the luci-nginx-* meta-packages to depend on that new config package. You might even chain them so, that luci-nginx LuCI collection selects the nginx luci config package that selects the actual nginx package.
(So, the alternative config might even be a variant of the main nginx. Might be that the main variant install nginx config A, but the luci version installs config B)
rc.d is created automatically for all installed packages that have init script.
You can't overwrite files that have been installed by other packages.
One way to overcome that is to have an uci-defaults script that runs once after the installation. You can there modify the specific file using shell commands (sed, uci config etc.)
There are various ways to achieve what you seek, but I have no idea what you exactly want 
My hunch is that you should aim to all that inside the nginx main Makefile, and then just have luci-nginx to depend on the correct variant of nginx
1 Like
Thx a lot for the suggestions
This got merged so now to run luci on nginx you only need to change nginx configuration. (waiting for the last commit to merge)
to install luci on nginx you need
luci-nginx and uwsgi-cgi-luci-support
I tried your package nginx-mod-luci-ssl with uwsgi-cgi-luci-support enabled. I can't access the luci web server. nginx does not start per command line because ngx_http_ssl_module is missing. nginx -V does show me that this option was not enabled at compile time.
Did a make clean but did not resolve. niginx.conf is getting altered correctly in /etc/nginx/ and the old config is backupped as _old.
can you try to remove ssl entities from nginx config? just to test if plain http works
I switched my nginx.conf from luci_nginx_ssl.conf to my luci_nginx.conf and the web interface is usable at port 80.
then the problem as you say it's just the ssl config flag disbaled by default...
@hnyman is it possible to enable it by default? think build a variant of the entire nginx package with that flag enabled is too much...
Enabled "Enable SSL module" (NGINX_SSL) in menuconfig nginx->Configuration and now it's working with ssl.
Thank you. 
you might try to get some input from heil, who is the maintainer for the nginx package.
Can someone tell how luci on nginx is better (actual experience, not theory) and how much more resources (RAM and flash) this will use?
I'm curious.
1 Like
ummm someone should do real test actually...
the experience can't be worse....
I have not done real tests but for me uhttpd uses 10mb less RAM directly after boot and the CPU is like half utilizated compared to the nginx build when viewing Realtime graphs .
These are the sizes for my firmware.
12103853 Jun 17 23:51 ../lede_config/openwrt-ramips-mt7621-mir3g-squashfs-sysupgrade-nginx-ssl.tar
11581613 Jun 18 00:57 ../lede_config/openwrt-ramips-mt7621-mir3g-squashfs-sysupgrade-uhttpd-ssl.tar
2 Likes
well i don't think the use of nginx is finalised to better use the luci interface..
probably it is intended to be used if you need it for something else (a proper web server? reverse proxy? something like that?) and avoid having 2 different httpserver..
btw, so is it working? can anyone list what is it needed to have luci on nginx working? should i remove luci with uhttpd before?
Thanks 
1 Like
you should remove luci and uhttpd and install the appropriate package.. that's all... currently nginx ssl is borken... will fix it later...
The main way in which nginx would be better than uhttpd would be that it's an asynchronous web browser, whereas uhttpd is synchronous... that being said, my guess is LuCI would likely need to be configured differently in order to take advantage of asynchronousity
For me I notice a better response from nginx to uhttpd
Anyway you are right
As Luci is written in lua we should be able to run it with the lua module directly but this needs a rewrite of the code as for now everything is coded to work with cgi response...
Also we should rework the code to supporto async request
For now use nginx instead of uhttpd improve speed because we can use a 2 core and have 4 process of the Luci app so Luci is able to process 4 request at once...
Also by watching the code, lot's of thing are outdated code with some inefficient structure (like concatenate lots of string or use external command to take data)
So we have 2 bottleneck uhttpd and Luci itself that needs some love to speed up (an example was the ddns app that adds 10s to process all the request before my commit) I'm just doing my best to improve it as I'm learning more and more of lua code
2 Likes
Thanks for your efforts! I tried your luci-supprt package and it works like a charm!
One more question, now everytime I reflash the firmware, it resets nginx.conf to default. I'm running another service which binds to port 443, so either of them will fail to start if the default nginx configuration file is loaded. How can I prevent this?