Overview
Request 1167691 revoked
Set RuntimeDirectory to offer a location for Unix sockets at /run/nginx
- Created by crameleon
- In state revoked
- 5 package maintainers
Loading...
openSUSE Build Service is sponsored by
Set RuntimeDirectory to offer a location for Unix sockets at /run/nginx
Hi Georg!
1 This directive is best placed at the very beginning of the Service section, not at the end. Without vertical indentation at the beginning and end.
2 Where and how is the variable %N defined? Can it be empty? How will the service behave if it is empty, will use /run?
3 I'm also not quite sure why you'd want to change it at all? If you want to run different nginx instances with different config, socket, pidfile and runtime directory parameters, wouldn't it be better to create a nginx@.service file and use the %i variable?
Hi!
1) There does not seem to be any sorting of directives in this file (no grouping into logical segments or alphabetical ordering), hence I appended it to the end. Is there a sorting scheme you implement which I missed?
2) The variables are defined in the systemd source code (https://github.com/systemd/systemd/blob/d05487ef95e6da5e204cd23a7b121314745aba39/src/core/unit-printf.c#L160) and explained in https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html -
%Nexpands to the unit name with the suffix stripped. It is always defined in any systemd unit.3) Currently no directory in /run is created. To allow users to use Unix socket listeners in a FHS compliant location, the service should provide the directory. I am not currently interested in running multiple NGINX instances, but rather in potentially multiple Unix socket listeners (using
serverblocks in the NGINX configuration).1 Sorting is functional. The pidfile is specified at the beginning. But any lines using variables must be at the beginning.
2 Thanks, only knew the variable %i will familiarize myself with them.
3 I understand correctly, you add this variable line not to change the variable to change this parameter, but to ensure that the directory /run/nginx is created?
If so, it's a very bad idea to use a variable that will probably create /run/web when creating an alias for a service like web.
This is done via the /usr/lib/tmpfiles.d/nginx.conf file with the contents
d /run/nginx 0755 nginx nginx -
I'll add it later.
I read about RuntimeDirectory more carefully, indeed, this parameter is responsible for creating a temporary directory. But for some reason I have not seen this directive in other openSUSE projects, but always saw that tmpfiles.d is used for this. I don't know why, but I will do the same with tmpfiles.d as is common in openSUSE. https://build.opensuse.org/request/show/1167866
The systemd documentation clearly states that RuntimeDirectory should be used, unless additional features which tmpfiles provide are needed. Such additional features are in openSUSE are usually due to setting a different user/group. This is not needed for nginx, because nginx creates Unix sockets before dropping privileges.
See https://www.freedesktop.org/software/systemd/man/latest/tmpfiles.d.html#Description:
Another issue with tmpfiles is that the directory is left behind when the unit is stopped.
Thank you for the detailed explanation with links and citations!
I will add the RuntimeDirectory=nginx directive to the beginning of the Service section instead of tmpfiles.d, substituting your entry in changes.
https://build.opensuse.org/request/show/1167915
Thanks for the implementation! This helps me keep my nginx socket listeners in a good location. :)
You're welcome!
And how do you use sockets in nginx? The only thing I can think of is reverse-proxy from one nginx instance to another, but then 2 nginx instances have to be running on the same host, or reverse-proxy from one virtual host to another?
My nginx is always available to the client on port 443 or reverse-proxy on port 80.
We use it for the local Prometheus exporter to connect to a
stub_statusserver.Oh, for monitoring, I see.
Have you had any need to access redis from nginx?
I had a need to do this, to read the user's session key from the cookie, then access redis, it processes the php sessions to get the user id from the session for that key if there is one, then compare it to the id from the URL and decide whether to give the user that image or return a 403.
I have built the modules http-redis https://build.opensuse.org/package/show/home:13ilya/nginx-module-http-redis и redis2 https://build.opensuse.org/package/show/home:13ilya/nginx-module-redis2, but unfortunately they turned out to be useless for this task. http-redis is used only for caching and can only receive data by key and send it to stdout in its entirety, and redis2 can only save, because when receiving any data, it sends this data together with debugging information, similar to when working with redis-cli, to stdout and it is impossible to save it to a variable and process it for further decision making.
I understand that the only way to do this is through OpenResty or lua module. OpenResty, for some reason, does not build any distribution, despite the GPL-compatible license, and it is suggested to connect third-party repositories, in which even nginx is put its own. I don't really like this option, but even so there is no repository for OpenSUSE Tumbleweed, only for openSUSE Leap.
I tried to build a lua module myself https://build.opensuse.org/package/show/home:13ilya/nginx-module-lua. and got bogged down by the fact that it needs luajit with FFI support.
checking for Lua language 5.1 ... found
checking for LuaJIT has FFI ... not found
./configure: error: unsupported LuaJIT build; ngx_http_lua_module requires LuaJIT with FFI enabled.
The upstime says that FFI support is enabled by default, https://luajit.org/ext_ffi_tutorial.html and I didn't find any way to disable it in downstream. https://build.opensuse.org/package/show/devel:languages:lua/luajit
That's where I'm stuck for now. :-(
Maybe you have experience with OpenResty build or how to solve similar problem of nginx to redis?
I haven't, but I looked into OpenResty in the past for the Lua support. The problem with the modules is that they need to always be built against the same version of nginx. If we could get the Lua module into the distribution that would make it easier. I'm not sure what the benefit of packaging/using OpenResty directly would be, from what I gather it is only a nginx bundled together with the Lua module.
https://build.opensuse.org/package/show/home:13ilya/nginx-module-lua I have already managed to build ngnx-module-lua and it works. If I can convince the lua maintainer to accept the luajit2 package, a fork of OpenResty's luajit, openSUSE Tumbleweed will be the only distribution that provides a working ngnx-module-lua out of the box. https://build.opensuse.org/request/show/1170499
@13ilya, @MargueriteSu, @ammler, @elvigia, @fschnizlein: review reminder