| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
It can fail with reporting following alert:
[alert] 137462#137462 mount("none", "/tmp/unit-test-636e0uh8/proc", "proc", 2097162, "") (16: Device or resource busy)
|
|
This now includes support for the 'wasm-wasi-component' module.
This targets the upcoming 1.32.0 release which is required by
wasm-wasi-component. However of course the 1.32.0 tag doesn't exist yet,
so there will be a small window where this image won't build.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
Thus
$ make build-wasm
will build _both_ the 'wasm' & 'wasm-wasi-component' modules.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
The minimum version required to build wasmtime 17 which is required by
wasm-wasi-component is 1.73.0
But no point not using the latest version.
This also now needs the libclang-dev package installed, we install this
via MODULE_PREBUILD_wasm.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
Et voila...
$ ./configure wasm-wasi-component
configuring wasm-wasi-component module
Looking for rust compiler ... found.
Looking for cargo ... found.
+ wasm-wasi-component module: wasm_wasi_component.unit.so
$ make install
test -d /opt/unit/sbin || install -d /opt/unit/sbin
install -p build/sbin/unitd /opt/unit/sbin/
test -d /opt/unit/state || install -d /opt/unit/state
test -d /opt/unit || install -d /opt/unit
test -d /opt/unit || install -d /opt/unit
test -d /opt/unit/share/man/man8 || install -d /opt/unit/sh
man/man8
install -p -m644 build/share/man/man8/unitd.8 /opt/unit/share/ma
n8/
make build/src/nxt_unit.o
make[1]: Entering directory '/home/andrew/src/unit'
make[1]: 'build/src/nxt_unit.o' is up to date.
make[1]: Leaving directory '/home/andrew/src/unit'
cargo build --release --manifest-path src/wasm-wasi-component/Cargo.toml
Finished release [optimized] target(s) in 0.55s
install -d /opt/unit/modules
install -p src/wasm-wasi-component/target/release/libwasm_wasi_component.so \
/opt/unit/modules/wasm_wasi_component.unit.so
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
The indentation uses spaces and not TABs.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This exposes the various WebAssembly Component Model language module
specific options.
The application type is "wasm-wasi-component".
There is a "component" option that is required, this specifies the full
path to the WebAssembly component to be run. This component should be in
binary format, i.e a .wasm file.
There is also currently one optional option
"access"
Due to the sandboxed nature of WebAssembly, by default Wasm
modules/components 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-wasi-component' application type
(same as for 'wasm');
'access.filesystem' which takes an array of
directory paths that are then made available to the wasm
module/component. This access works recursively, i.e everything under a
specific path is allowed access to.
Example config might look like
"applications": {
"my-wasm-component": {
"type": "wasm-wasi-component",
"component": "/path/to/component.wasm",
"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.
[0]: <https://github.com/bytecodealliance/wasmtime/blob/main/docs/WASI-capabilities.md>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
It seems we do want to track this thing. This is just the latest version
that cargo had generated for me.
Cc: Dan Callahan <d.callahan@f5.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
With the initial port to wasmtime 17 we could no longer use the
'reactor' adaptor but had to switch to the more restrictive 'proxy'
adaptor.
This meant amongst other things (probably) we could no longer access the
filesystem.
Thanks to Joel Dice for pointing out the fix.
With this we can go back to using the 'reactor' adaptor again and things
are back to working as before.
It's worth noting that you can use either the 'proxy' or 'reactor'
adaptor depending on your requirements.
Cc: Joel Dice <joel.dice@fermyon.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This brings WASI 0.2.0 support.
Link: <https://github.com/bytecodealliance/wasmtime/releases/tag/v17.0.0>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
When Unit receives a request, if the body of that request is greater
than a certain amount (16KiB by default) then it is written to a
temporary file.
When a language module goes to read the request body in such situations
it will end up using read(2).
The wasm-wasi-component language module was failing to properly read
request bodies of around 2GiB or more.
This is because (on Linux at least) read(2) (and other related system
calls) will only read (or write) at most 0x7ffff000 (2,147,479,552)
bytes, this is the case for both 32 and 64-bit systems.
Regardless, it's probably not a good idea doing IO in such large chunks
anyway.
This patch changes the wasm-wasi-component language module to read the
request buffer in 32MiB chunks (this matches the original 'wasm'
language module).
We are still limited to a 4GiB address space and can only upload files a
little under 4GiB.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
Run from the repository root like
$ rustfmt --edition 2021 src/wasm-wasi-component/src/lib.rs
Also manually fix up some overly long comments.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This is used by the rustfmt program to format Rust code according to the
rules contained in this file.
Currently we just set the line width limit to 80 characters to match our
C code.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This is the work of Alex Crichton.
This is written in Rust. The problem is that there is currently no
support on the C side of things for the component model, which is the
point of this module.
It talks to Unit via automatically generated bindings.
I've (Andrew) just made some minor tweaks to src/lib.rs, build.rs &
Cargo.toml to adjust some paths, adjust where we get the language module
config from and the module name and where it's located in the source
tree,
I also removed and disabled the tracking of the Cargo.lock file, this is
constantly changing and not tracking it seems right for 'libraries' and
dropped the README's...
Other than that I have tried to leave his work intact, subsequent
commits will make some larger changes, but I didn't want to intermix
them with Alex's work.
One such commit will update the module to use wasmtime 17 which brings
WASI 0.2.0 support.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This is required to actually _build_ the 'wasm-wasi-componet' language
module.
The nxt_wasm_wc_app_conf_t structure consists of the component name, e.g
my_component.wasm, this is required. It also consists of an object to
store the directories that are allowed access to by the component, this
is optional.
The bulk of the configuration infrastructure will be added in a
subsequent commit.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This is the first commit in adding WebAssembly Component Model language
module support.
This just adds a new NXT_APP_WASM_WC type, required by subsequent
commits.
The WC stands for WASI_COMPONENT
This new module will have a type of 'wasm-wasi-component'.
Link: <https://github.com/nginx/unit/issues/1098>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This commit adds GitHub Actions configuration, running tests on
pull-requests and master push changes.
This change is meant to be a first-pass at our evolving CI processes.
- Tests run in parallel per language for speed and isolation
- Test matrix is composed by a string list of languages and versions
- `setup-${language}` actions are preferred over base (and changing)
versions from `ubuntu-latest` operating system
A few caveats with the current setup:
- Only tests on Ubuntu (no FreeBSD or Alpine)
- Unpriviledged tests only
- No core dumps available on failure
|
|
@filiphanes requested support for bytearray
and memoryview in the request body here:
<https://github.com/nginx/unit/issues/648>
This patch implements bytearray body support only.
Memoryview body still need to be implemented.
|
|
|
|
This allows the editor(1) to enable syntax highlighting. See
suffixes(7).
Cc: Liam Crilly <liam@nginx.com>
Reviewed-by: Andrew Clayton <a.clayton@nginx.com>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
|
|
Reviewed-by: Andrew Clayton <a.clayton@nginx.com>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
|
|
When editing the configuration in-place, it's easy to make a mistake.
If the configuration is wrong, it will be passed to the control socket,
which will reject it, keeping the old configuration. Those manual edits
would be lost, which can make it very uncomfortable to edit in-place.
By printing the name of the temporary file, we allow the user to recover
the changes.
Cc: Liam Crilly <liam@nginx.com>
Reviewed-by: Andrew Clayton <a.clayton@nginx.com>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
|
|
Suggested-by: Liam Crilly <liam@nginx.com>
Reviewed-by: Andrew Clayton <a.clayton@nginx.com>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
|
|
Centralize handling of the ssh(1) tunnel in the ctl command.
This is possible now that we do the cleanup with trap(1).
Reviewed-by: Andrew Clayton <a.clayton@nginx.com>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
|
|
This allows listening to command exit statuses. Before this change, we
had to ignore the exit status of curl(1) (and a few other commands),
since otherwise the script would go kaboom and not cleanup the ssh(1)
tunnels.
Fixes: 543d478e1236 ("Tools: setup-unit: ctl: added "edit" subcommand.")
Fixes: 3778877eb3be ("Tools: Added subcommands to setup-unit.")
Reviewed-by: Andrew Clayton <a.clayton@nginx.com>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
|
|
|
|
- Go: Drop 1.20, Add 1.22
- Node: Drop 18, Add 21
- PHP: Add 8.3
- Ruby: Add 3.3
Perl and Python are still up-to-date with upstream releases
Regenerating the Dockerfiles also picks up the logging change from
183a1e9d634ae2fb129ce98f1ca8a16cbfdeac99
|
|
Add more entries for Andrei and Konstantin and an entry for Dan.
Reviewed-by: Dan Callahan <d.callahan@f5.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
Saves on the order of 10 MBs of transfer for each build.
We call `rm -rf /usr/src/unit` later in this step, so the full repo has
never appeared in our published images anyway.
|
|
In that particular issue the compiled nuxt files end up importing the
http module as node:http rather than http only. This bypasses unit's
custom loader implementation which only check for the http or unit-http
modules, and their websocket counterparts.
This changeset adds replace sources for both the node:http and
node:websocket import signatures.
Closes: https://github.com/nginx/unit/issues/1013
Reviewed-by: Andrew Clayton <a.clayton@nginx.com>
|
|
As suggested by @lcrilly
|
|
|
|
This allows to use /dev/stdout as application logs if users choose to do
so.
Closes: https://github.com/nginx/unit/issues/982
|
|
This commit introduces the 'vars' JavaScript object to NJS,
enabling direct access to native variables such as $uri and $arg_foo.
The syntax is `${vars.var_name}` or `${'vars[var_name]'}`.
For example:
{
"action": {
"share": "`/www/html${vars.uri}`"
}
}
|
|
|
|
This commit is for subsequent commits that will support njs variable
accessing. In this commit, nxt_var_get() is introduced to extend
the variable handling capabilities. Concurrently, nxt_var_ref_get()
has been refactored to use in both configuration and request phases.
|
|
This commit enhances nxt_var_cache_value() to enable variable access
using string names, complementing the existing reference index method.
The modification ensures future compatibility with njs variable access.
|
|
|
|
|
|
This is a simple temporary fix (doesn't address the underlying problem)
for an issue reported by a user on GitHub whereby downloading of files
from a PHP application would cause the router process to crash.
This is actually a generic problem that will affect anything sending
data via nxt_unit_response_write().
This is just a simple fix for the 1.32 release, after which the full
correct fix will be worked out.
Link: <https://github.com/nginx/unit/issues/1125>
Reported-by: rustedsword <https://github.com/rustedsword>
Co-developed-by: rustedsword <https://github.com/rustedsword>
Tested-by: rustedsword <https://github.com/rustedsword>
Tested-by: Andrew Clayton <a.clayton@nginx.com>
Reviewed-by: Zhidao Hong <z.hong@f5.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
A user on GitHub reported an issue when trying to build/install the
nodejs language module.
Doing a
$ ./configure nodejs --node=/usr/bin/node --npm=/usr/bin/npm --node-gyp=/usr/bin/node-gyp
$ make install
was throwing the following error
mv build/src//usr/bin/node/unit-http-g/unit-http-1.31.1.tgz build//usr/bin/node-unit-http-g.tar.gz
mv: cannot move 'build/src//usr/bin/node/unit-http-g/unit-http-1.31.1.tgz' to 'build//usr/bin/node-unit-http-g.tar.gz': No such file or directory
make: *** [build/Makefile:2061: build//usr/bin/node-unit-http-g.tar.gz] Error 1
The fact that we're using the path given by --node= to then use as
directory locations seems erroneous.
But rather than risk breaking existing expectations the simple fix is to
just use build/src in the destination path above to match that of the
source.
These paths were added in some previous commits, and the missing 'src/'
component looks like an oversight.
After this commit both the following work
$ ./configure nodejs --node-gyp=/usr/lib/node_modules/bin/node-gyp-bin/node-gyp --local=/opt/unit/node
$ ./configure nodejs --node=/usr/bin/node --node-gyp=/usr/lib/node_modules/npm/bin/node-gyp-bin/node-gyp --local=/opt/unit/node
Reported-by: ruspaul013 <https://github.com/ruspaul013>
Tested-by: ruspaul013 <https://github.com/ruspaul013>
Fixes: 0ee8de554 ("Fixed Makefile target for NodeJS.")
Fixes: c84948386 ("Node.js: fixing module global installation.")
Reviewed-by: Timo Stark <t.stark@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
Forgotten in
<https://github.com/nginx/unit/commit/c3af21e970ca3c822004cfda7c5b56ec07d99da9>
|
|
Functionally identical, but marginally more idiomatic.
Refines: fbeb2065b180e2376088387ee150d3975dc08cd5
|
|
Now that unitd has multiple --control* startup options, locating the
address of the control socket requires additional precision.
Signed-off-by: Liam Crilly <liam.crilly@nginx.com>
Acked-by: Andrew Clayton <a.clayton@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
Several users in GitHub have asked for the ability to set the
permissions of the unitd UNIX Domain control socket.
This can of course be done externally, but can be done much cleaner by
Unit itself.
This commit adds three new options
--control-mode Set the mode of the socket, e.g 644
--control-user Set the user/owner of the socket, e.g unit
--control-group Set the group of the socket, e.g unit
Of course these only have an affect when using a UNIX Domain Socket for
the control socket.
Requested-by: michaelkosir <https://github.com/michaelkosir>
Requested-by: chopanovv <https://github.com/chopanovv>
Link: <https://github.com/nginx/unit/issues/254>
Link: <https://github.com/nginx/unit/issues/980>
Closes: https://github.com/nginx/unit/issues/840
Tested-by: Liam Crilly <liam.crilly@nginx.com>
Reviewed-by: Zhidao Hong <z.hong@f5.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This wraps chown(2) but takes the user/owner and group as strings.
It's a little long winded as it uses the thread safe versions of
getpwnam()/getgrname() which require a little more work.
This function will be used by the following commit that allows to set
the permissions of the Unix domain control socket.
We need to cast uid & gid to long in the call to nxt_thread_log_alert()
to appease clang-ast as it's adamant that uid/gid are unsigned ints, but
chown(2) takes -1 for these values to indicate don't change this item,
and it'd be nice to show them in the error message.
Note that getpwnam()/getgrname() don't define "not found" as an error as
per their man page
The formulation given above under "RETURN VALUE" is from POSIX.1-2001.
It does not call "not found" an error, and hence does not specify what
value errno might have in this situation. But that makes it impossible
to recognize errors. One might argue that according to POSIX errno
should be left unchanged if an entry is not found. Experiments on var‐
ious UNIX-like systems show that lots of different values occur in this
situation: 0, ENOENT, EBADF, ESRCH, EWOULDBLOCK, EPERM, and probably
others.
Thus if we log an error from these functions we can end up with the
slightly humorous error message
2024/02/12 15:15:12 [alert] 99404#99404 getpwnam_r("noddy", ...) failed (0: Success) (User not found) while creating listening socket on unix:/opt/unit/control.unit.sock
Reviewed-by: Zhidao Hong <z.hong@f5.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
|
|
|
