Wasm: Add support for directory access.

Due to the sandboxed nature of WebAssembly, by default WASM modules
don't have any access to the underlying filesystem.

There is however a capabilities based

Wasm: Add support for directory access.

Due to the sandboxed nature of WebAssembly, by default WASM modules
don't have any access to the underlying filesystem.

There is however a capabilities based mechanism[0] for allowing such
access.

This adds a config option to the 'wasm' application type;
'access.filesystem' which takes an array of directory paths that are
then made available to the WASM module. This access works recursively,
i.e everything under a specific path is allowed access to.

Example config might look like

"access" {
"filesystem": [
"/tmp",
"/var/tmp"
]
}

The actual mechanism used allows directories to be mapped differently in
the guest. But at the moment we don't support that and just map say /tmp
to /tmp. This can be revisited if it's something users clamour for.

Network sockets are another resource that may be controlled in this
manner, for example there is a wasi_config_preopen_socket() function,
however this requires the runtime to open the network socket then
effectively pass this through to the guest.

This is something that can be revisited in the future if users desire
it.

[0]:
<https://github.com/bytecodealliance/wasmtime/blob/main/docs/WASI-capabilities.md>

Reviewed-by: Alejandro Colomar <alx@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

show more ...

Wasm: Add core configuration data structure.

This is required to actually _build_ the Wasm language module.

The nxt_wasm_app_conf_t structure consists of the modules name, e.g
wasm, then the three

Wasm: Add core configuration data structure.

This is required to actually _build_ the Wasm language module.

The nxt_wasm_app_conf_t structure consists of the modules name, e.g
wasm, then the three required function handlers followed by the five
optional function handlers.

See the next commit for details of these function handlers.

We also need to include the u.wasm union entry that provides access to
the above structure.

The bulk of the configuration infrastructure will be added in a
subsequent commit.

Reviewed-by: Alejandro Colomar <alx@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

show more ...

Wasm: Register a new WebAssembly language module type.

This is the first patch in adding WebAssembly language module support.

This just adds a new NXT_APP_WASM type, required by subsequent commits.

Wasm: Register a new WebAssembly language module type.

This is the first patch in adding WebAssembly language module support.

This just adds a new NXT_APP_WASM type, required by subsequent commits.

Reviewed-by: Alejandro Colomar <alx@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

show more ...

Add per-application logging.

Currently when running in the foreground, unit application processes
will send stdout to the current TTY and stderr to the unit log file.

That behaviour won't change.

Add per-application logging.

Currently when running in the foreground, unit application processes
will send stdout to the current TTY and stderr to the unit log file.

That behaviour won't change.

When running as a daemon, unit application processes will send stdout to
/dev/null and stderr to the unit log file.

This commit allows to alter the latter case of unit running as a daemon,
by allowing applications to redirect stdout and/or stderr to specific
log files. This is done via two new application options, 'stdout' &
'stderr', e.g

"applications": {
"myapp": {
...
"stdout": "/path/to/log/unit/app/stdout.log",
"stderr": "/path/to/log/unit/app/stderr.log"
}
}

These log files are created by the application processes themselves and
thus the log directories need to be writable by the user (and or group)
of the application processes.

E.g

$ sudo mkdir -p /path/to/log/unit/app
$ sudo chown APP_USER /path/to/log/unit/app

These need to be setup before starting unit with the above config.

Currently these log files do not participate in log-file rotation
(SIGUSR1), that may change in a future commit. In the meantime these
logs can be rotated using the traditional copy/truncate method.

NOTE:

You may or may not see stuff printed to stdout as stdout was
traditionally used by CGI applications to communicate with the
webserver.

Closes: <https://github.com/nginx/unit/issues/197>
Closes: <https://github.com/nginx/unit/issues/846>
Reviewed-by: Alejandro Colomar <alx@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

show more ...

Removed dead code.

Signed-off-by: Alejandro Colomar <alx@nginx.com>

Removed dead code.

Signed-off-by: Alejandro Colomar <alx@nginx.com>

Sending shared port to application prototype.

Application process started with shared port (and queue) already configured.
But still waits for PORT_ACK message from router to start request processin

Sending shared port to application prototype.

Application process started with shared port (and queue) already configured.
But still waits for PORT_ACK message from router to start request processing
(so-called "ready state").

Waiting for router confirmation is necessary. Otherwise, the application may
produce response and send it to router before the router have the information
about the application process. This is a subject of further optimizations.

show more ...

Moving request limit control to libunit.

Introducting application graceful stop. For now only used when application
process reach request limit value.

This closes #585 issue on GitHub.

Ruby: process and thread lifecycle hooks.

This feature allows one to specify blocks of code that are called when certain
lifecycle events occur. A user configures a "hooks" property on the app
conf

Ruby: process and thread lifecycle hooks.

This feature allows one to specify blocks of code that are called when certain
lifecycle events occur. A user configures a "hooks" property on the app
configuration that points to a script. This script will be evaluated on boot
and should contain blocks of code that will be called on specific events.

An example of configuration:

{
"type": "ruby",
"processes": 2,
"threads": 2,
"user": "vagrant",
"group": "vagrant",
"script": "config.ru",
"hooks": "hooks.rb",
"working_directory": "/home/vagrant/unit/rbhooks",
"environment": {
"GEM_HOME": "/home/vagrant/.ruby"
}
}

An example of a valid "hooks.rb" file follows:

File.write("./hooks.#{Process.pid}", "hooks evaluated")

on_worker_boot do
File.write("./worker_boot.#{Process.pid}", "worker booted")
end

on_thread_boot do
File.write("./thread_boot.#{Process.pid}.#{Thread.current.object_id}",
"thread booted")
end

on_thread_shutdown do
File.write("./thread_shutdown.#{Process.pid}.#{Thread.current.object_id}",
"thread shutdown")
end

on_worker_shutdown do
File.write("./worker_shutdown.#{Process.pid}", "worker shutdown")
end

This closes issue #535 on GitHub.

show more ...

Python: support for multiple targets.

Python: multiple values in the "path" option.

Python: supporting ASGI legacy protocol.

Introducing manual protocol selection for 'universal' apps and frameworks.

Perl: request processing in multiple threads.

This closes #486 issue on GitHub.

Ruby: request processing in multiple threads.

This closes #482 issue on GitHub.

Java: request processing in multiple threads.

This closes #458 issue on GitHub.

Python: request processing in multiple threads.

This closes #459 issue on GitHub.

Python: app module callable name configuration.

Now it is possible to specify the name of the application callable using
optional parameter 'callable'. Default value is 'application'.

This closes

Python: app module callable name configuration.

Now it is possible to specify the name of the application callable using
optional parameter 'callable'. Default value is 'application'.

This closes #290 issue on GitHub.

show more ...

Added "rootfs" feature.

Refactor of process management.

The process abstraction has changed to:

setup(task, process)
start(task, process_data)
prefork(task, process, mp)

The prefork() occurs in the main process rig

Refactor of process management.

The process abstraction has changed to:

setup(task, process)
start(task, process_data)
prefork(task, process, mp)

The prefork() occurs in the main process right before fork.

The file src/nxt_main_process.c is completely free of process
specific logic.

The creation of a process now supports a PROCESS_CREATED state. The
The setup() function of each process can set its state to either
created or ready. If created, a MSG_PROCESS_CREATED is sent to main
process, where external setup can be done (required for rootfs under
container).

The core processes (discovery, controller and router) doesn't need
external setup, then they all proceeds to their start() function
straight away.

In the case of applications, the load of the module happens at the
process setup() time and The module's init() function has changed
to be the start() of the process.

The module API has changed to:

setup(task, process, conf)
start(task, data)

As a direct benefit of the PROCESS_CREATED message, the clone(2) of
processes using pid namespaces now doesn't need to create a pipe
to make the child block until parent setup uid/gid mappings nor it
needs to receive the child pid.

show more ...

PHP: implemented "targets" option.

This allows to specify multiple subsequent targets inside PHP applications.
For example:

{
"listeners": {
"*:80": {
"pass": "route

PHP: implemented "targets" option.

This allows to specify multiple subsequent targets inside PHP applications.
For example:

{
"listeners": {
"*:80": {
"pass": "routes"
}
},

"routes": [
{
"match": {
"uri": "/info"
},

"action": {
"pass": "applications/my_app/phpinfo"
}
},
{
"match": {
"uri": "/hello"
},

"action": {
"pass": "applications/my_app/hello"
}
},
{
"action": {
"pass": "applications/my_app/rest"
}
}
],

"applications": {
"my_app": {
"type": "php",
"targets": {
"phpinfo": {
"script": "phpinfo.php",
"root": "/www/data/admin",
},

"hello": {
"script": "hello.php",
"root": "/www/data/test",
},

"rest": {
"root": "/www/data/example.com",
"index": "index.php"
},
}
}
}
}

show more ...

Adding "limits/shm" configuration validation and parsing.

Initial applications isolation support using Linux namespaces.

Removed unnecessary abstraction layer.

Introducing Java Servlet Container beta.

Fixed processing of SERVER_NAME after 77aad2c142a0.

Previously, the nxt_router_prepare_msg() function expected server host among
other headers unmodified. It's not true anymore since normalization

Fixed processing of SERVER_NAME after 77aad2c142a0.

Previously, the nxt_router_prepare_msg() function expected server host among
other headers unmodified. It's not true anymore since normalization of the
Host header has been introduced in 77aad2c142a0.

The nxt_unit_split_host() function was removed. It didn't work correctly with
IPv6 literals. Anyway, after 77aad2c142a0 the port splitting is done in router
while Host header processing.

show more ...