Added unit section to /status endpoint. Unit section is about web-server version, config last load time and config update generation
Response example below:
{"unit":{"version":"1.32.0","load_time":"2024-01-25T13:24:08.000Z","generation":0},"connections":{"accepted":0,"active":0,"idle":0,"closed":0},"requests":{"total":0},"applications":{"laravel":{"processes":{"running":1,"starting":0,"idle":1},"requests":{"active":0}}}}
Closes: nginx#928

According to the Node.js documenation this variable
should only include numbering scheme.

Thanks to @dbit-xia.

Closes: nginx#1085

This is in preparation for adding conditional access logging.
No functional changes.

This feature allows users to specify conditions to control if access log
should be recorded. The "if" option supports a string and JavaScript code.
If its value is empty, 0, false, null, or undefined, the logs will not be
recorded. And the '!' as a prefix inverses the condition.

Example 1: Only log requests that sent a session cookie.

    {
        "access_log": {
            "if": "$cookie_session",
            "path": "..."
        }
    }

Example 2: Do not log health check requests.

    {
        "access_log": {
            "if": "`${uri == '/health' ? false : true}`",
            "path": "..."
        }
    }

Example 3: Only log requests when the time is before 22:00.

    {
        "access_log": {
            "if": "`${new Date().getHours() < 22}`",
            "path": "..."
        }
    }

or

    {
        "access_log": {
            "if": "!`${new Date().getHours() >= 22}`",
            "path": "..."
        }
    }

Closes: nginx#594

Conditional access logging was introduced here:
nginx@4c91beb

This is a generic type to represent a uid_t/gid_t on Linux when user
namespaces are in use.

Technically this only needs to be an unsigned int, but we make it an
int64_t so we can make use of the existing NXT_CONF_MAP_INT64 type.

This will be used in subsequent commits.

Reviewed-by: Zhidao Hong <[email protected]>
Signed-off-by: Andrew Clayton <[email protected]>

Andrei reported an issue on arm64 where he was seeing the following
error message when running the tests

  2024/01/17 18:32:31.109 [error] 54904#54904 "gidmap" field has an entry with "size": 1, but for unprivileged unit it must be 1.

This error message is guarded by the following if statement

  if (nxt_slow_path(m.size > 1)

Turns out size was indeed > 1, in this case it was 289356276058554369,
m.size is defined as a nxt_int_t, which on arm64 is actually 8 bytes,
but was being printed as a signed int (4 bytes) and by chance/undefined
behaviour comes out as 1.

But why is size so big? In this case it should have just been 1 with a
config of

  'gidmap': [{'container': 0, 'host': os.getegid(), 'size': 1}],

This is due to nxt_int_t being 64bits on arm64 but using a conf type of
NXT_CONF_MAP_INT which means in nxt_conf_map_object() we would do (using
our m.size variable as an example)

  ptr = nxt_pointer_to(data, map[i].offset);
  ...
  ptr->i = num;

Where ptr is a union pointer and is now pointing at our m.size

Next we set m.size to the value of num (which is 1 in this case), via
ptr->i where i is a member of that union of type int.

So here we are setting a 64bit memory location (nxt_int_t on arm64)
through a 32bit (int) union alias, this means we are only setting the
lower half (4) of the bytes.

Whatever happens to be in the upper 4 bytes will remain, giving us our
exceptionally large value.

This is demonstrated by this program

  #include <stdio.h>
  #include <stdint.h>

  int main(void)
  {
          int64_t num = -1; /* All 1's in two's complement */
          union {
                  int32_t i32;
                  int64_t i64;
          } *ptr;

          ptr = (void *)&num;

          ptr->i32 = 1;
          printf("num : %lu / %ld\n", num, num);
          ptr->i64 = 1;
          printf("num : %ld\n", num);

          return 0;
  }
  $ make union-32-64-issue
  cc     union-32-64-issue.c   -o union-32-64-issue
  $ ./union-32-64-issue
  num : 18446744069414584321 / -4294967295
  num : 1

However that is not the only issue, because the members of
nxt_clone_map_entry_t were specified as nxt_int_t's on the likes of
x86_64 this would be a 32bit signed integer. However uid/gids on Linux
at least are defined as unsigned integers, so a nxt_int_t would not be
big enough to hold all potential values.

We could make the nxt_uint_t's but then we're back to the above union
aliasing problem.

We could just set the memory for these variables to 0 and that would
work, however that's really just papering over the problem.

The right thing is to use a large enough sized type to store these
things, hence the previously introduced nxt_cred_t. This is an int64_t
which is plenty large enough.

So we switch the nxt_clone_map_entry_t structure members over to
nxt_cred_t's and use NXT_CONF_MAP_INT64 as the conf type, which then
uses the right sized union member in nxt_conf_map_object() to set these
variables.

Reported-by: Andrei Zeliankou <[email protected]>
Reviewed-by: Zhidao Hong <[email protected]>
Signed-off-by: Andrew Clayton <[email protected]>

Use the NXT_CONF_VLDT_REQUIRED flag on the app_procmap members. These
three settings are required.

These are for the uidmap & gidmap settings in the config.

Suggested-by: Zhidao HONG <[email protected]>
Reviewed-by: Zhidao Hong <[email protected]>
Signed-off-by: Andrew Clayton <[email protected]>

With the previous commit which introduced the use of the
NXT_CONF_VLDT_REQUIRED flag, we no longer need to do this separate
validation, it's only purpose was to check if the three uidmap/gidmap
settings had been provided.

Reviewed-by: Zhidao Hong <[email protected]>
Signed-off-by: Andrew Clayton <[email protected]>

This function is like nxt_conf_get_string(), but creates a new copy,
so that it can be modified without corrupting the configuration string.

Reviewed-by: Andrew Clayton <[email protected]>
Cc: Zhidao Hong <[email protected]>
Signed-off-by: Alejandro Colomar <[email protected]>

Refactor.

Reviewed-by: Andrew Clayton <[email protected]>
Cc: Zhidao Hong <[email protected]>
Signed-off-by: Alejandro Colomar <[email protected]>

The commit that added support for Unix sockets accepts abstract sockets
using '@' in the config, but we stored it internally using '\0'.

We want to support abstract sockets transparently to the user, so that
if the user configures unitd with '@', if we receive a query about the
current configuration, the user should see the same exact thing that was
configured.  So, this commit avoids the transformation in the internal
state file, storing user input pristine, and we only transform the '@'
in temporary strings.

This commit fixes another bug, where we try to connect to abstract
sockets with a trailing '\0' in their name due to calling twice
nxt_sockaddr_parse() on the same string.  By calling that function only
once with each copy of the string, we have fixed that bug.

The following code was responsible for this bug, which the second time
it was called, considered these sockets as file-backed (not abstract)
Unix socket, and so appended a '\0' to the socket name.

    $ grepc -tfd nxt_sockaddr_unix_parse . | grep -A10 @
        if (path[0] == '@') {
            path[0] = '\0';
            socklen--;
    #if !(NXT_LINUX)
            nxt_thread_log_error(NXT_LOG_ERR,
                                 "abstract unix domain sockets are not supported");
            return NULL;
    #endif
        }

        sa = nxt_sockaddr_alloc(mp, socklen, addr->length);

This bug was found thanks to some experiment about using 'const' for
some strings.

And here's some history:

-  9041d27 ("nxt_sockaddr_parse() introducted.")

   This commit introduced support for abstract Unix sockets, but they
   only worked as "servers", and not as "listeners".  We corrupted the
   JSON config file, and stored a \u0000.  This also caused calling
   connect(2) with a bogus trailing null byte, which tried to connect to
   a different abstract socket.

-  d8e0768 ("Fixed support for abstract Unix sockets.")

   This commit (partially) fixed support for abstract Unix sockets, so
   they they worked also as listeners.  We still corrupted the JSON
   config file, and stored a \u0000.  This caused calling connect(2)
   (and now bind(2) too) with a bogus trailing null byte.

-  e2aec66 ("Storing abstract sockets with @ internally.")

   This commit fixed the problem by which we were corrupting the config
   file, but only for "listeners", not for "servers".  (It also fixes
   the issue about the terminating '\0'.)  We completely forgot about
   "servers", and other callers of the same function.

To reproduce the problem, I used the following config:

```json
{
	"listeners": {
		"*:80": {
			"pass": "routes/u"
		},
		"unix:@abstract": {
			"pass": "routes/a"
		}
	},

	"routes": {
		"u": [{
			"action": {
				"pass": "upstreams/u"
			}
		}],
		"a": [{
			"action": {
				"return": 302,
				"location": "/i/am/not/at/home/"
			}
		}]
	},

	"upstreams": {
		"u": {
			"servers": {
				"unix:@abstract": {}
			}
		}
	}
}
```

And then check the state file:

    $ sudo cat /opt/local/nginx/unit/master/var/lib/unit/conf.json \
    | jq . \
    | grep unix;
        "unix:@abstract": {
            "unix:\u0000abstract": {}

After this patch, the state file has a '@' as expected:

    $ sudo cat /opt/local/nginx/unit/unix/var/lib/unit/conf.json \
    | jq . \
    | grep unix;
        "unix:@abstract": {
            "unix:@abstract": {}

Regarding the trailing null byte, here are some tests:

    $ sudo strace -f -e 'bind,connect' /opt/local/nginx/unit/d8e0/sbin/unitd \
    |& grep abstract;
    [pid 22406] bind(10, {sa_family=AF_UNIX, sun_path=@"abstract\0"}, 12) = 0
    [pid 22410] connect(134, {sa_family=AF_UNIX, sun_path=@"abstract\0"}, 12) = 0
    ^C
    $ sudo killall unitd
    $ sudo strace -f -e 'bind,connect' /opt/local/nginx/unit/master/sbin/unitd \
    |& grep abstract;
    [pid 22449] bind(10, {sa_family=AF_UNIX, sun_path=@"abstract"}, 11) = 0
    [pid 22453] connect(134, {sa_family=AF_UNIX, sun_path=@"abstract\0"}, 12) = -1 ECONNREFUSED (Connection refused)
    ^C
    $ sudo killall unitd
    $ sudo strace -f -e 'bind,connect' /opt/local/nginx/unit/unix/sbin/unitd \
    |& grep abstract;
    [pid 22488] bind(10, {sa_family=AF_UNIX, sun_path=@"abstract"}, 11) = 0
    [pid 22492] connect(134, {sa_family=AF_UNIX, sun_path=@"abstract"}, 11) = 0
    ^C

Fixes: 9041d27 ("nxt_sockaddr_parse() introducted.")
Fixes: d8e0768 ("Fixed support for abstract Unix sockets.")
Fixes: e2aec66 ("Storing abstract sockets with @ internally.")
Link: <nginx#1108>
Reviewed-by: Andrew Clayton <[email protected]>
Cc: Liam Crilly <[email protected]>
Cc: Zhidao Hong <[email protected]>
Signed-off-by: Alejandro Colomar <[email protected]>

It's an integer, not a floating number.

Fixes: 68c6b67 ("Configuration: support for rational numbers.")
Closes: nginx#1115
Link: <nginx#1116>
Reviewed-by: Zhidao Hong <[email protected]>
Reviewed-by: Andrew Clayton <[email protected]>
Cc: Dan Callahan <[email protected]>
Cc: Valentin Bartenev <[email protected]>
Signed-off-by: Alejandro Colomar <[email protected]>

Added unit section to /status endpoint. Unit section is about web-server version, config last load time and config update generation
Response example below:
{"unit":{"version":"1.32.0","load_time":"2024-01-25T13:24:08.000Z","generation":0},"connections":{"accepted":0,"active":0,"idle":0,"closed":0},"requests":{"total":0},"applications":{"laravel":{"processes":{"running":1,"starting":0,"idle":1},"requests":{"active":0}}}}
Closes: nginx#928

…eature/unit_about_section