On Mon, Apr 10, 2017 at 1:04 PM, 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/ > Thanks B.R., I surely will !! > --- > *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 > -- Regards, Ajay
_______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx