I do not know anything about third-party modules. I'll let experts on the lua one answering that one. The baseline is: you should not need to. --- *B. R.*
On Mon, Apr 10, 2017 at 11:31 PM, Alex Samad <a...@samad.com.au> wrote: > But long live sessions are closed and I've had lua session information > persist with a reload. Needed a restart > > A > On Sun, 9 Apr 2017 at 21:35, B.R. via nginx <nginx@nginx.org> wrote: > >> You could have got your answer yourself by Reading The... Fine? Manual: >> https://nginx.org/en/docs/control.html >> >> There are tons of interesting pieces of informations there, by the nature >> of said docs... >> I suggest you take a look at everything: https://nginx.org/en/docs/ >> --- >> *B. R.* >> >> On Sun, Apr 9, 2017 at 4:25 PM, Ajay Garg <ajaygargn...@gmail.com> wrote: >> >> Thanks a ton Lucas. >> >> Just checked reloading, and the previous proxy-session was intact !! >> Thanks a ton again. >> >> And sorry I missed your name in the credits, you too had helped a greate >> deal yesterday, and today too !! >> Thanks a ton again !!! >> >> >> Thanks and Regards, >> Ajay >> >> On Sun, Apr 9, 2017 at 7:29 PM, Lucas Rolff <lu...@lucasrolff.com> wrote: >> >> Hi Ajay, >> >> If you generate the configuration, and issue a nginx reload – it won't >> cause any downtime. The master process will reread the configuration, start >> new workers, and gracefully shut down the old ones. >> There's absolutely no downtime involved in this process. >> >> >> From: nginx <nginx-boun...@nginx.org> on behalf of Ajay Garg < >> ajaygargn...@gmail.com> >> Reply-To: "nginx@nginx.org" <nginx@nginx.org> >> Date: Sunday, 9 April 2017 at 15.55 >> To: "nginx@nginx.org" <nginx@nginx.org> >> Subject: Mechanism to avoid restarting nginx upon every change >> >> Hi All. >> >> We are wanting to implement a solution, wherein the user gets proxied to >> the appropriate local-url, depending upon the credentials. >> Following architecture works like a charm (thanks a ton to >> fran...@daoine.org, without whom I would not have been able to reach >> here) :: >> >> #################################################### >> server { >> listen 2000 ssl; >> >> ssl_certificate /etc/nginx/ssl/nginx.crt; >> ssl_certificate_key /etc/nginx/ssl/nginx.key; >> >> location / { >> auth_basic 'Restricted'; >> auth_basic_user_file >> /etc/nginx/ssl/.htpasswd; >> >> if ($remote_user = "user1") { >> proxy_pass >> https://127.0.0.1:2001 <https://127.0.0.1:2000>; >> } >> >> if ($remote_user = "user2") { >> proxy_pass >> https://127.0.0.1:2002 <https://127.0.0.1:2000>; >> } >> >> # and so on .... >> >> } >> } >> #################################################### >> >> >> Things are good, except that adding any new user information requires >> reloading/restarting the nginx server, causing (however small) downtime. >> >> Can this be avoided? >> Can the above be implemented using some sort of database, so that the >> nginx itself does not have to be down, and the "remote_user <=> proxy_pass" >> mapping can be retrieved from a database instead? >> >> Will be grateful for pointers. >> >> >> Thanks and Regards, >> Ajay >> >> >> _______________________________________________ >> nginx mailing list >> nginx@nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx >> >> >> >> >> -- >> Regards, >> Ajay >> >> _______________________________________________ >> nginx mailing list >> nginx@nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx >> >> >> _______________________________________________ >> nginx mailing list >> nginx@nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx > >
_______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
