Luci on nginx compile

both uwsgi and nginx runs as root

try start luci with uhttpd, login with it and then switch to nginx?

i'm inside but now i have a problem with the original luci (problem that i'm reporting...)

anyway i think i found how to take the data that we need

Syntax: uwsgi_pass_header field;
Default: —
Context: http, server, location
Permits passing otherwise disabled header fields from a uwsgi server to a client.

we need to find the header that luci pass with the cookie

yep can confirm
now we need to find what data to send to uwsgi and how

ok new update actually the uswcgi params are essential to make it work...

Cattura


to make it work we need #uwsgi_param CONTENT_LENGTH $content_length; enabled

but enabling it gives 503 error with this from nginx

upstream prematurely closed connection while reading response header from upstream

try nginx config
Should nginx close connection with FastCGI if client closed connection before got response?
default off

fastcgi_ignore_client_abort on;

Also could be helpful:

  1. Parameters in php.ini: upload_max_filesize and post_max_size
  2. Parameters in nginx config: fastcgi_connect_timeout and keepalive_timeout

http://www.right.com.cn/forum/thread-321157-1-1.html

The article mentioned the use of fcgiwrap to provide CGI support for nginx (Chinese page

Fgiwrap i can compile and install it but I couldn't manage to make it work...

Anyway fcgi and uwsgi are different things and we don't have PHP.ini ....

what would you say if i alert you that i fixed all the problems?

a little slow but i can confirm that luci is workign in nginx :slight_smile:

if someone wants more info ask

2 Likes

Hard work. Well done!
I need it :slight_smile:

think tomorrow i will push a pr to include uwsgi in package.... then it's just some configuration change...

anyway now the problem is that for some reason uwsgi takes 10000ms to process cgi script.... think this is wrong and something is bugged or wrong configuration....

because of this all xhr request needs to be more than 10 second or they will be cancelled.

Apart from that, all works like a normal uhttpd configuration...

this is uwsgi package....

https://github.com/openwrt/packages/pull/6083

you need to create some file and nginx needs to have uwsgi support

you need to create uwsgi.ini in /etc/

uwsgi.ini should contain

[uwsgi]
stric = True
plugins = cgi
uwsgi_modifier1 = 9
socket = 127.0.0.1:9090
cgi-mode = true
cgi = /www/cgi-bin/luci

nginx configuration should be something like...

location / {
            index  index.html;
			include /etc/nginx/uwsgi_params;
			uwsgi_modifier1 9;
			uwsgi_pass 127.0.0.1:9090;
        }
		
		location /luci-static {
			
		}

also in /etc/nginx you need this file... (uwsgi_params)

uwsgi_param QUERY_STRING $query_string;
uwsgi_param REQUEST_METHOD $request_method;
uwsgi_param CONTENT_TYPE $content_type;
uwsgi_param CONTENT_LENGTH $content_length if_not_empty;
uwsgi_param REQUEST_URI $request_uri;
uwsgi_param PATH_INFO $document_uri;
uwsgi_param SERVER_PROTOCOL $server_protocol;
uwsgi_param REMOTE_ADDR $remote_addr;
uwsgi_param REMOTE_PORT $remote_port;
uwsgi_param SERVER_ADDR $server_addr;
uwsgi_param SERVER_PORT $server_port;
uwsgi_param SERVER_NAME $server_name;

so now to actually start uwsgi you need to execute this

/usr/sbin/uwsgi --ini /etc/uwsgi.ini

hope someone helps me to solve the strange 10000ms problem with every request...

remember to stop uhttpd or nginx will stop working cause the port is already taken

(for now luci needs some modification as xhr request have 5 second of timeout.... and uwsgi needs at least 10 second to process request! that's why overview page seems broken)


also in my case also uhttpd is slow with load so could be just me... wait some test

i can confirm that there are some problem with my lua build as the stock script take 10 second so it's not a uswgi problem

1 Like

i found who was slowing down all luci (even with uhttpd...)

ludi-app-ddns is a little broken... bu removing that, luci with uwsgi is blazing fast!

here some log... notice the ms...

[pid: 16057|app: -1|req: -1/41] 192.168.2.101 () {38 vars in 754 bytes} [Wed May 23 02:39:45 2018] GET /admin/services/upnp/status?_=0.26370393746461684 => generated 134 bytes in 115 msecs (HTTP/1.1 200) 6 headers in 182 bytes (0 switches on core 0)
[pid: 16057|app: -1|req: -1/42] 192.168.2.101 () {38 vars in 754 bytes} [Wed May 23 02:39:45 2018] GET /admin/status/overview?hosts=1&_=0.92140143787879 => generated 749 bytes in 355 msecs (HTTP/1.1 200) 6 headers in 182 bytes (0 switches on core 0)
[pid: 16057|app: -1|req: -1/43] 192.168.2.101 () {38 vars in 762 bytes} [Wed May 23 02:39:50 2018] GET /admin/status/overview?status=1&_=0.24923868076424505 => generated 2984 bytes in 220 msecs (HTTP/1.1 200) 6 headers in 182 bytes (0 switches on core 0)
[pid: 16057|app: -1|req: -1/44] 192.168.2.101 () {38 vars in 752 bytes} [Wed May 23 02:39:50 2018] GET /admin/services/upnp/status?_=0.9786780920440452 => generated 134 bytes in 119 msecs (HTTP/1.1 200) 6 headers in 182 bytes (0 switches on core 0)
[pid: 16057|app: -1|req: -1/45] 192.168.2.101 () {38 vars in 760 bytes} [Wed May 23 02:39:55 2018] GET /admin/status/overview?status=1&_=0.1120892307449084 => generated 2943 bytes in 304 msecs (HTTP/1.1 200) 6 headers in 182 bytes (0 switches on core 0)
[pid: 16057|app: -1|req: -1/46] 192.168.2.101 () {38 vars in 750 bytes} [Wed May 23 02:39:55 2018] GET /admin/services/upnp/status?_=0.927344298301888 => generated 134 bytes in 119 msecs (HTTP/1.1 200) 6 headers in 182 bytes (0 switches on core 0)
[pid: 16057|app: -1|req: -1/47] 192.168.2.101 () {38 vars in 760 bytes} [Wed May 23 02:40:00 2018] GET /admin/status/overview?status=1&_=0.2956253749782798 => generated 2985 bytes in 277 msecs (HTTP/1.1 200) 6 headers in 182 bytes (0 switches on core 0)
[pid: 16057|app: -1|req: -1/48] 192.168.2.101 () {38 vars in 752 bytes} [Wed May 23 02:40:00 2018] GET /admin/services/upnp/status?_=0.6232856798224109 => generated 134 bytes in 137 msecs (HTTP/1.1 200) 6 headers in 182 bytes (0 switches on core 0)

by adding this

threads = 2
processes = 4

the page loads in an instant.

also we need this for now...

https://github.com/openwrt/luci/pull/1814


the luci fix got merged ! so we don't need it

1 Like

@Ansuel When you have some time, it would be awesome if you could add this to the LuCI wiki and add an inter-wiki link to the Nginx wiki (or vice versa)

We need first to accept uwsgi as package

i found what was causing the 10 s delay...

broken ddns package. Fixed with this commit.
https://github.com/openwrt/luci/pull/1816

How we can help with accepting uwsgi as package?

go to pr and request the merge ahahah

do the same thing to ddns pr as they cause delay if used... (luci + luci-app-ddns + uwsgi = unusable)

just tested http v2 with luci and it's even faster...