I work on windows 10 use built-in bash for ubantu
I installed openresty, and start it's nginx with command "nginx -p openresty-test".
My nginx.conf content is:
worker_processes 2;
error_log logs/error.log;
events {
worker_connections 1024;
}
http {
server {
listen 6699;
location / {
default_type text/html;
content_by_lua_block {
ngx.say("HelloWorld")
}
}
}
}
problem:
I try curl "http://localhost:6699 -i", It's blocked without any message and didn't return.
I use web browser to visit localhost:6699, It's blocked too.
I run "ps -ef | grep nginx" show:
27 1 0 2433 ? 00:00:00 nginx: master process ng
29 2 0 2433 ? 00:00:00 grep --color=auto nginx
As we see there is only a master process, no any work process, I doubt that cause my problem,
how should I do?
Related
My goal is to see the newest log messages on web page.
I know I could use tail -f <file> to trace the latest 10 line log messages on terminal.
But today, I want to config nginx, so that I could see the same result on web.
For example, when I access to http://192.168.1.200/nginx (My Nginx Host)
I could see the files under /var/log/nginx
Index of /nginx/
-------------------------------------------------
../
access.log 08-Aug-2019 16:43 20651
error.log 08-Aug-2019 16:43 17810
And when I access to http://192.168.1.200/nginx/access.log
I could see the same result as tail -f /var/log/nginx/access.log in terminal (and it is dynamic).
/etc/nginx/conf.d/log.conf
server {
listen 80;
root /var/log/nginx;
location /nginx {
root /var/log/;
default_type text/plain;
autoindex on;
}
}
This is my config, but there are 2 points that doesn't meet my requirements:
I want to access to log page by accessing /log/access.log not by /nginx/access.log
When I access to /log/access.log, this page is static.
This is very puzzling:
I'm on RHEL 7.5, trying to run Nginx 1.14.0 under Supervisor 3.3.4. The ultimate aim is to serve a Django site.
My "/etc/init.d/supervisord" looks like this:
#!/bin/sh
...
# Source init functions
. /etc/rc.d/init.d/functions
prog="supervisord"
prog_bin="/bin/supervisord -c /etc/supervisord.conf"
PIDFILE="/var/run/$prog.pid"
start()
{
echo -n $"Starting $prog: "
daemon $prog_bin --pidfile $PIDFILE
sleep 1
[ -f $PIDFILE ] && success $"$prog startup" || failure $"$prog startup"
echo
}
... # "stop", "restart" functions, etc.
"/etc/supervisord.conf" looks like this:
[unix_http_server]
file=/var/run//supervisor.sock
[supervisord]
logfile=/var/log/supervisor/supervisord.log
pidfile=/var/run/supervisord.pid
childlogdir=/var/log/supervisor
[rpcinterface:supervisor]
supervisor.rpcinterface_factory =
supervisor.rpcinterface:make_main_rpcinterface
[supervisorctl]
serverurl=unix:///var/run//supervisor.sock
[include]
files = /etc/supervisor/conf.d/*.conf
"/etc/supervisor/conf.d/" has just one file in it: nginx.conf:
[program:nginx]
user=root
command=/usr/sbin/nginx -c /path/to/site/etc/nginx.conf
autostart=true
autorestart=true
startretries=3
redirect_stderr=True
Invoking the above command directly with sudo /usr/sbin/nginx -c /path/to/site/etc/nginx.conf & is successful. It starts right up and I can see the nginx processes with ps -ef
But if I start supervisor d like this:
$ sudo /etc/init.d/supervisord restart
It fails to launch Nginx:
$ sudo cat /var/log/supervisor/nginx-stdout---supervisor-tqI97D.log
nginx: [emerg] open() "/path/to/site/etc/nginx.conf" failed (13: Permission denied)
Permissions to read that file are good all the way down. Of course, the path is not actually called "/path/to/site/etc/nginx.conf", but there's an "x" for all users on every directory and a "r" for all users on the conf file itself:
$ namei -om /path/to/site/etc/nginx.conf
f: /path/to/site/etc/nginx.conf
dr-xr-xr-x root root /
drwxr-xr-x root root path
drwxr-xr-x root root to
drwxrwxr-x user1 group1 site
drwxrwxr-x user1 group1 etc
-rw-r--r-- root group1 nginx.conf
How can there be an error on an "open()" operation for this file? I've tried changing the "user" to root in "/etc/supervisor/conf.d/nginx.conf" and/or in "/etc/supervisord.conf" but the result is always the same.
Could the fact that this is SELinux make a difference? It's currently activated.
$ getenforce
Enforcing
If it helps, the nginx.conf file that can't be opened looks like this:
user nginx;
daemon off;
error_log /path/to/site/var/log/nginx-error.log warn;
pid /path/to/site/var/run/nginx.pid;
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /path/to/site/var/log/nginx-access.log main;
sendfile on;
#tcp_nopush on;
keepalive_timeout 65;
#gzip on;
upstream app_server {
server unix:/path/to/site/var/run/my-django.socket fail_timeout=0;
}
server {
listen 8000;
server_name xxx.xxx.xxx.xxx;
charset utf-8;
location /media {
alias /path/to/site/htdocs/media;
}
location /static {
alias /path/to/site/htdocs/static;
}
location / {
uwsgi_pass app_server;
include /path/to/site/etc/uwsgi_params;
}
}
}
Does anyone have any ideas?
I suggest you check with SELinux to really grasp the whole concept before doing anything to a production machine.
The httpd_t context permits NGINX to listen on common web server ports, to access configuration files in /etc/nginx, and to access content in the standard docroot location (/usr/share/nginx). It does not permit many other operations, such as proxying to upstream locations or communicating with other processes through sockets.
Once you are a king at SELinux (hah) check out NGINX's - Modifying SELinux Settings
Let us know, good luck!
On SELinux enabled systems process and files have security labels. SELinux policy contains the allowed access patterns between these labels. Access is denied if there is not a rule allowing the access.
The security labels on your nginx files seem to be incorrect: the AVC error message tells that access was denied for a process in httpd_t domain trying to access a file with default_t label. To allow access, you need to assign suitable security contexts to your nginx files. Possible contexts are documented in httpd_selinux man page. For configuration files, an approriate context would be httpd_config_t and for user content perhaps httpd_user_content_t.
You can manually apply a new security context to a file using chcon tool. After you have decided the security contexts to use, you should save them in file context database using semanage. Otherwise automatic relabeling will label the files incorrectly.
I've written a more detailed answer on the topic on related Unix & Linux Stack exchange question Configure SELinux to allow daemons to use files in non-default locations.
I am current using ASP.NET Core 2.0 behind nginx through HTTP requests in Ubuntu 16.
And I'd like to switch to Unix domain socket.
In my Program.cs I have:
var host = default(IWebHost);
var builder = new WebHostBuilder()
.UseKestrel(opt =>
{
if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux) && settings.Config.ListenUnixSocket)
{
opt.ListenUnixSocket("/tmp/api.sock");
}
})
.Configure(app =>
{
app.Map("/health", b => b.Run(async context =>
{
context.Response.StatusCode = (int)HttpStatusCode.OK;
await context.Response.WriteAsync("Ok");
}));
});
if(RuntimeInformation.IsOSPlatform(OSPlatform.Windows) || !settings.Config.ListenUnixSocket)
{
host = builder.UseUrls("http://0.0.0.0:5501").Build();
}
else
{
host = builder.Build();
}
host.Run();
And, at Nginx:
location /health {
#proxy_pass http://127.0.0.1:5501;
proxy_pass http://unix:/tmp/api.sock:/;
}
Running it using the default TCP socket works, but switching to Unix domain sockets, I got a 502 error.
Do I need any specific module at nginx? What I am doing wrong?
Aspnetcore will create api.socket when its running but Nginx must have permission to write.
So, if you don't know what user nginx uses, execute:
ps aux | grep nginx
You'll get something this in the terminal:
root 5005 0.0 0.2 125116 1460 ? Ss 20:12 0:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
www-data 5006 0.0 0.6 125440 3260 ? S 20:12 0:00 nginx: worker process
root 5173 0.0 0.1 14516 920 pts/0 S+ 20:17 0:00 grep --color=auto nginx
Then you set the permission:
sudo chown www-data:www-data /tmp/api.sock
And, that's it!
#Apolineo correctly identified that the Unix socket's permissions need to be opened up to allow other users to connect to the socket.
However, a better solution than manually setting the permissions is to do it programmatically from Main immediately after the socket is created.
Example solution in this answer.
I am running a rails app on nginx and sending an image to my rails api via my ios app.
The IOS app keeps receiving this response from nginx:
{ status code: 413, headers {
Connection = close;
"Content-Length" = 207;
"Content-Type" = "text/html";
Date = "Sun, 17 Jul 2016 23:16:07 GMT";
Server = "nginx/1.4.6 (Ubuntu)";
}
So I did sudo vi /etc/nginx/nginx.conf and added a large client_max_body_size.
Now my nginx.conf reads:
user www-data;
worker_processes 4;
pid /run/nginx.pid;
events {
worker_connections 768;
}
http {
#fastcgi_read_timeout 300;
client_max_body_size 1000000M;
...
I ran sudo service nginx reload and got [ OK ]
But, my ios still gets the same response.
If I use a tiny image the IOS app gets a 200 response.
Question
Why does nginx give the 413 error when the client_max_body_size is so big?
try to put
client_max_body_size 1000M;
In the server {} block where the sites nginx config is stored. Usually /etc/nginx/sites-available/mysite
As mentioned, set the max size to whatever you need it to be.
I'm serving some demos in isolation like:
/demo1/-- nginx.conf
|- index.html
|- ...
#run
/demo1$ sudo nginx -c `pwd`/nginx.conf
and
/demo2/-- nginx.conf
|- index.html
|- ...
#run
/demo2$ sudo nginx -c `pwd`/nginx.conf
now I have the following nginx processes:
$ ps aux | grep nginx
root 3434 0.0 0.0 85904 1340 ? Ss 12:02 0:00 nginx: master process nginx -c /demo1/nginx.conf
nobody 3435 0.0 0.0 86316 2272 ? S 12:02 0:00 nginx: worker process
root 5096 0.0 0.0 85904 1344 ? Ss 11:21 0:00 nginx: master process nginx -c /demo2/nginx.conf
nobody 5097 0.0 0.0 86316 2272 ? S 11:21 0:00 nginx: worker process
I believe (tell me if I'm wrong) that if I reload the configuration this way:
$ sudo nginx -s reload
It will only deliver the message to the last master process that was spun.
How do I reload the configuration on a specific master process?
After reading the manpage I believe it has some to do with the -g option but I'm not sure how. Should I specify a static PID or something?
Here is my nginx.conf for reference
user nobody;
worker_processes 1;
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
server {
listen 8000;
location / {
root /demoX;
index index.html index.htm;
}
}
}
You can use a signal to certain PID:
kill -QUIT 3434
Reload option is a reference to QUIT signal which reloads the config and spawn new worker.