Andrew Clayton 2e3e1c7e7b Socket: Remove Unix domain listen sockets upon reconfigure.
Currently when using Unix domain sockets for requests, if unit is
reconfigured then it will fail if it tries to bind(2) again to a Unix
domain socket with something like

  2023/02/25 19:15:50 [alert] 35274#35274 bind(\"unix:/tmp/unit.sock\") failed (98: Address already in use)

When closing such a socket we really need to unlink(2) it. However that
presents a problem in that when running as root, while the main process
runs as root and creates the socket, it's the router process, that runs
as an unprivileged user, e.g nobody, that closes the socket and would
thus remove it, but couldn't due to not having permission, even if the
socket is mode 0666, you need write permissions on the containing
directory to remove a file.

There are several options to solve this, all with varying degrees of
complexity and utility.

  1) Give the user who the router process runs as write permission to
     the directory containing the listen sockets. These can then be
     unlink(2)'d from the router process.

     Simple and would work, but perhaps not the most elegant.

  2) Using capabilities(7). The router process could temporarily attain
     the CAP_DAC_OVERRIDE capability, unlink(7) the socket, then
     relinquish the capability until required again.

     These are Linux specific (other systems may have similar mechanisms
     which would be extra work to support). There is also a, albeit
     small, window where the router process is running with elevated
     privileges.

  3) Have the main process do the unlink(2), it is after all the process
     that created the socket.

     This is what this commit implements.

We create a new port IPC message type of NXT_PORT_MSG_SOCKET_UNLINK,
that is used by the router process to notify the main process about a
Unix domain socket to unlink(2).

Upon doing a reconfigure the router process will call
nxt_router_listen_socket_release() which will close the socket, we
extend this function in the case of non-abstract Unix domain sockets, so
that it will send a message to the main process containing a copy of the
nxt_sockaddr_t structure that will contain the filename of the socket.

In the main process the handler that we have defined,
nxt_main_port_socket_unlink_handler(), for this message type will run
and allow us to look for the socket in question in the listen_sockets
array and remove it and unlink(2) the socket.

This then allows the reconfigure to work if it tries to bind(2) again to
a socket that previously existed.

Link: <https://github.com/nginx/unit/issues/669>
Link: <https://github.com/nginx/unit/pull/735>
Reviewed-by: Alejandro Colomar <alx@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2023-03-17 04:28:23 +00:00
2023-03-01 18:25:52 +00:00
2022-01-10 16:07:31 +03:00
2023-03-01 18:25:52 +00:00
2022-05-03 12:41:36 +02:00
2020-09-18 19:37:56 +01:00
2023-03-01 18:25:52 +00:00
2022-10-03 14:16:44 +01:00
2023-02-28 16:16:27 +00:00
2023-01-31 23:47:53 +01:00
2017-09-06 18:26:37 +03:00
2022-02-15 18:21:10 +03:00
2022-11-24 15:06:54 +00:00
2022-12-16 12:42:53 +00:00

NGINX Unit

Universal Web App Server

NGINX Unit Logo

NGINX Unit is a lightweight and versatile open-source server that has three core capabilities:

  • acts as an HTTP reverse proxy,
  • serves static media assets,
  • runs application code in seven languages.

Unit compresses several layers of the modern application stack into a potent, coherent solution with a focus on performance, low latency, and scalability. It is intended as a universal building block for any web architecture regardless of its complexity, from enterprise-scale deployments to your pet's homepage.

Its native RESTful JSON API enables dynamic updates with zero interruptions and flexible configuration, while its out-of-the-box productivity reliably scales to production-grade workloads. We achieve that with a complex, asynchronous, multithreading architecture comprising multiple processes to ensure security and robustness while getting the most out of today's computing platforms.

Quick Installation

macOS

$ brew install nginx/unit/unit

For details and available language packages, see the docs.

Docker

$ docker pull docker.io/nginx/unit

For a description of image tags, see the docs.

Amazon Linux, Fedora, RedHat

$ wget https://raw.githubusercontent.com/nginx/unit/master/tools/setup-unit && chmod +x setup-unit
# ./setup-unit repo-config && yum install unit
# ./setup-unit welcome

For details and available language packages, see the docs.

Debian, Ubuntu

$ wget https://raw.githubusercontent.com/nginx/unit/master/tools/setup-unit && chmod +x setup-unit
# ./setup-unit repo-config && apt install unit
# ./setup-unit welcome

For details and available language packages, see the docs.

Running a Hello World App

Suppose you saved a PHP script as /www/helloworld/index.php:

<?php echo "Hello, PHP on Unit!"; ?>

To run it on Unit with the unit-php module installed, first set up an application object. Let's store our first config snippet in a file called config.json:

{
    "helloworld": {
        "type": "php",
        "root": "/www/helloworld/"
    }
}

Saving it as a file isn't necessary, but can come in handy with larger objects.

Now, PUT it into the /config/applications section of Unit's control API, usually available by default via a Unix domain socket:

# curl -X PUT --data-binary @config.json --unix-socket  \
       /path/to/control.unit.sock http://localhost/config/applications

{
	"success": "Reconfiguration done."
}

Next, reference the app from a listener object in the /config/listeners section of the API. This time, we pass the config snippet straight from the command line:

# curl -X PUT -d '{"127.0.0.1:8000": {"pass": "applications/helloworld"}}'  \
       --unix-socket /path/to/control.unit.sock http://localhost/config/listeners
{
    "success": "Reconfiguration done."
}

Now Unit accepts requests at the specified IP and port, passing them to the application process. Your app works!

$ curl 127.0.0.1:8080

      Hello, PHP on Unit!

Finally, query the entire /config section of the control API:

# curl --unix-socket /path/to/control.unit.sock http://localhost/config/

Unit's output should contain both snippets, neatly organized:

{
    "listeners": {
        "127.0.0.1:8080": {
            "pass": "applications/helloworld"
        }
    },

    "applications": {
        "helloworld": {
            "type": "php",
            "root": "/www/helloworld/"
        }
    }
}

For full details of configuration management, see the docs.

Community

  • The go-to place to start asking questions and share your thoughts is our Slack channel.

  • Our GitHub issues page offers space for a more technical discussion at your own pace.

  • The project map on GitHub sheds some light on our current work and plans for the future.

  • Our official website may provide answers not easily found otherwise.

  • Get involved with the project by contributing! See the contributing guide for details.

  • To reach the team directly, subscribe to the mailing list.

  • For security issues, email us, mentioning NGINX Unit in the subject and following the CVSS v3.1 spec.

Description
No description provided
Readme 12 MiB
Languages
Shell 63.7%
HTML 36.3%