On Fri, Oct 19, 2018 at 11:27:09PM +0200, Stefan Müller wrote:

Hi there,

> thank you for the update

You're welcome.

> 1. documentation
> I've read up and down the documentation and other sources. I could
> not find anything saying that if you run the nginx binary, you run a
> new instance of nginx, independent of any other.

In my experience, pretty much every time I run a command, it starts a
new instance of the command that I just ran. That's what I expect
to happen.

The few exceptions are the ones that should be documented as exceptional.

So the documentation as-is reads fine to me, and I am not in a position
to suggest alternate words that might be clearer for others.

> 2. command line
> Slowly I being understanding reading Starting, Stopping, and
> Restarting NGINX

> e.g. I have a master and two user nginx instances relaoding each of
> them would be:
> master: nginx -s reload
> user1:  nginx -s reload "pid /var/run/nginx_user1.pid"
> user2:  nginx -s reload "pid /var/run/nginx_user2.pid"
> or by its PIDs listed by ps aux -P | grep nginx
> master: nginx -s reload
> user1:  nginx -s reload PID_NoOfUser1Instance
> user2:  nginx -s reload PID_NoOfUser1Instance

My reading of that documentation does not lead me to the same conclusion
that you apparently came to. That's ok; it should be straightforward
enough for you to test.

Run "nginx -c conf1", "nginx -c conf2", and "nginx". Check "ps" or read
log files, so that you can see which instances are running.

Then run "nginx -s stop" with whatever other arguments look right, and
see what the response is, and what nginx instances are running afterwards.

I suspect that the system is much simpler than you might think it is.

If you want to stop the nginx that you started with "nginx -c conf1",
you can run "nginx -c conf1 -s stop".

> Making sure that I understood correctly nginx -g "pid
> /var/run/nginx.pid; worker_processes `sysctl -n hw.ncpu`;" means to
> replace the number of workers by the count of CPUs in nginx master
> process with the process id given in /var/run/nginx.pid, doesn't it?

I'm afraid I really don't know how to answer that, without just saying
"no" and repeating my previous mail.

What happened when you tried to run that command?

> 4.  all in all there two layers of isolation

> After all, I just want to have a clear picture of what is at risk
> when some part of the entire server environment is compromised and
> how can I minimize the risk by isolation of all involved parts.

That is a good thing to aim for.

Only you can do your risk assessment. You have access to exactly what
nginx does -- it's in the directory "src". If that's not something you
want to read, then you will have to accept someone else's summary of it,
and put your trust in them.

If I were to write "the entire system is now, and will forever remain,
totally unbreakable, no matter what configuration you use", would that
change your opinion of it? Why should you accept random words in a
stranger's email? (The quoted statement is almost certainly incorrect,
by the way.)

Some people and some companies seem willing to run the software. Maybe
they did their own risk assessments and decided it was ok, or it was ok
so long as they avoid some specific parts; or maybe they just assumed
that it was good enough because other people were using it.

I'm happy to use nginx for my purposes.

One nginx which can read all relevant static files, plus one fastcgi
server for each php application that I don't want to fully assess,
is enough for me.

> I reckon the information gathered so far put me in a quite good
> position, doesn't it?

I hope so.

f
--
Francis Daly francis@daoine.org
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx