Welcome! Log In Create A New Profile

Advanced

Mechanism to avoid restarting nginx upon every change

Posted by Ajay Garg 
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
francis@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
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 <[email protected]<mailto:[email protected]>> on behalf of Ajay Garg <[email protected]<mailto:[email protected]>>
Reply-To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
Date: Sunday, 9 April 2017 at 15.55
To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
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 [email protected]<mailto:[email protected]>, 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:2001https://127.0.0.1:2000;
}

if ($remote_user = "user2") {
proxy_pass https://127.0.0.1:2002https://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
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 <[email protected]> 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 <[email protected]> on behalf of Ajay Garg <
> [email protected]>
> Reply-To: "[email protected]" <[email protected]>
> Date: Sunday, 9 April 2017 at 15.55
> To: "[email protected]" <[email protected]>
> 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
> francis@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
B.R. via nginx
Re: Mechanism to avoid restarting nginx upon every change
April 10, 2017 09:40AM
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 <[email protected]> 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 <[email protected]> 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 <[email protected]> on behalf of Ajay Garg <
>> [email protected]>
>> Reply-To: "[email protected]" <[email protected]>
>> Date: Sunday, 9 April 2017 at 15.55
>> To: "[email protected]" <[email protected]>
>> 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
>> francis@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
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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> on behalf of Ajay Garg <
> [email protected]>
> Reply-To: "[email protected]" <[email protected]>
> Date: Sunday, 9 April 2017 at 15.55
> To: "[email protected]" <[email protected]>
> 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
> francis@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
B.R. via nginx
Re: Mechanism to avoid restarting nginx upon every change
April 11, 2017 01:20PM
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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> on behalf of Ajay Garg <
>> [email protected]>
>> Reply-To: "[email protected]" <[email protected]>
>> Date: Sunday, 9 April 2017 at 15.55
>> To: "[email protected]" <[email protected]>
>> 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
>> francis@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
On Mon, Apr 10, 2017 at 1:04 PM, B.R. via nginx <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> on behalf of Ajay Garg <
>>> [email protected]>
>>> Reply-To: "[email protected]" <[email protected]>
>>> Date: Sunday, 9 April 2017 at 15.55
>>> To: "[email protected]" <[email protected]>
>>> 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
>>> francis@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
Sorry, only registered users may post in this forum.

Click here to login