ah, sorry for missing that! Do you want me to send it again?
On 2024-04-17 07:22, Thomas Lamprecht wrote:
Am 16/04/2024 um 17:32 schrieb Aaron Lauterer:
patches until 31 got a [0,1]
Tested-by: Christoph Heiss
Reviewed-by: Christoph Heiss
why don't these patches include above trailers the
On Wed, 2024-04-17 at 08:45 +0200, Dominik Csapak wrote:
> similar to how it works for qemu, but add a confirmation dialog
> so one does not accidentally shutdown or reboot a node.
>
> Signed-off-by: Dominik Csapak
> ---
> changes from v1:
> * add an AlertDialog as confirmation before executing t
On 4/17/24 10:19, Folke Gleumes wrote:
On Wed, 2024-04-17 at 08:45 +0200, Dominik Csapak wrote:
similar to how it works for qemu, but add a confirmation dialog
so one does not accidentally shutdown or reboot a node.
Signed-off-by: Dominik Csapak
---
changes from v1:
* add an AlertDialog as con
similar to how it works for qemu, but add a confirmation dialog
so one does not accidentally shutdown or reboot a node.
Signed-off-by: Dominik Csapak
---
changes from v2:
* reordered and renamed yes/no on the confirmation dialog
* slightly adapted the confirmation text
lib/bloc/pve_node_overvie
only 2 changes for the URI necessary
Signed-off-by: Dominik Csapak
---
lib/widgets/pve_console_menu_widget.dart | 4 +-
pubspec.lock | 56 ++--
pubspec.yaml | 2 +-
3 files changed, 55 insertions(+), 7 deletions(-)
di
Changes since v4:
* Simplify cbind
* Fix selection of custom devid not being applied on creation in
onGetValues
Changes since v3:
* Pass confid in via cbind instead of manually setting it in the view
model
* Check me.isCreate instead of !me.confid for whether to find the next
free device slo
Clarify the naming of mount point utils to clearly indicate their
relation to LXC containers.
Signed-off-by: Filip Schauer
---
www/manager6/Utils.js| 12 ++--
www/manager6/lxc/MPEdit.js | 4 ++--
www/manager6/lxc/MultiMPEdit.js | 4 ++--
www/m
Signed-off-by: Filip Schauer
---
www/manager6/Makefile | 1 +
www/manager6/Utils.js | 11 +++
www/manager6/lxc/DeviceEdit.js | 176 +
www/manager6/lxc/Resources.js | 31 +-
4 files changed, 218 insertions(+), 1 deletion(-)
create mode 10
Am 17/04/2024 um 10:41 schrieb Dominik Csapak:
> only 2 changes for the URI necessary
>
as mentioned off-list I tried this already locally, so pushed
that similar change out instead replacing this:
https://git.proxmox.com/?p=flutter/pve_flutter_frontend.git;a=commit;h=b7ea60bc40fb542bbf13835369e7
Changed in patch v5. I also fixed a bug that ignored a custom devid when
creating a device passthrough.
https://lists.proxmox.com/pipermail/pve-devel/2024-April/063108.html
On 16/04/2024 15:57, Fiona Ebner wrote:
Am 16.04.24 um 14:10 schrieb Filip Schauer:
+
+cbind: {
+ confid: '{con
Am 17/04/2024 um 08:45 schrieb Dominik Csapak:
> similar to how it works for qemu, but add a confirmation dialog
> so one does not accidentally shutdown or reboot a node.
>
> Signed-off-by: Dominik Csapak
> ---
> changes from v1:
> * add an AlertDialog as confirmation before executing the action
move the confirm action to the right as mentioned in the material spec[0]
also rewords the buttons to 'cancel' and 'shutdown/reboot'
for that to work properly slightly rename the confirm message
0:
https://m3.material.io/components/dialogs/guidelines#befd7f4d-1029-4957-b1b5-da13fc0bbf3c
Signed-o
Am 16.04.24 um 17:02 schrieb Thomas Lamprecht:
> Am 16/04/2024 um 15:18 schrieb Dominik Csapak:
>> copies the OVF.pm and relevant ovf tests from qemu-server.
>> We need it here, and it uses PVE::Storage already, and since there is no
>> intermediary package/repository we could put it, it seems fitt
Am 17/04/2024 um 11:19 schrieb Fiona Ebner:
> Am 16.04.24 um 17:02 schrieb Thomas Lamprecht:
>> high-level nit: this, and most of the ESXi one, should go into another module
>> name space, e.g. PVE::GuestImport:: (or if that's to long, or we really are
>> sure
>> that other stuff can be imported (
both STDOUT and STDERR are written into `$info` which is then parsed for
IP and port of the target socket listening.
when the ports file can't be locked immediately `trying to acquire
lock...` is printed on STDERR and in turn written into `$info`.
trying to parse the IP then fails, resulting in a m
Am 17/04/2024 um 10:44 schrieb Filip Schauer:
> Changes since v4:
> * Simplify cbind
> * Fix selection of custom devid not being applied on creation in
> onGetValues
>
> Changes since v3:
> * Pass confid in via cbind instead of manually setting it in the view
> model
> * Check me.isCreate inst
That is already fixed by this commit to pve-container:
https://git.proxmox.com/?p=pve-container.git;a=commitdiff;h=556ddd393165d51653fe32c1f8fe8628d1802219
On 17/04/2024 11:54, Thomas Lamprecht wrote:
Also noticed something not related to the UI side: if I enter some bogus path,
like `/dev/enoen
Am 16.04.24 um 15:18 schrieb Dominik Csapak:
> in DirPlugin and not Plugin (because of cyclic dependency of
> Plugin -> OVF -> Storage -> Plugin otherwise)
>
> only ovf is currently supported (though ova will be shown in import
> listing), expects the files to not be in a subdir, and adjacent to t
Am 17/04/2024 um 11:48 schrieb Mira Limbeck:
> both STDOUT and STDERR are written into `$info` which is then parsed for
> IP and port of the target socket listening.
> when the ports file can't be locked immediately `trying to acquire
> lock...` is printed on STDERR and in turn written into `$info`
Am 16.04.24 um 15:18 schrieb Dominik Csapak:
> since we want to handle ova files (which are only ovf+vmdks bundled in a
> tar file) for import, add code that handles that.
>
> we introduce a valid volname for files contained in ovas like this:
>
> storage:import/archive.ova/disk-1.vmdk
>
> by b
Add support for compressing the body of responses with
`Content-Encoding: deflate` following [RFC9110]. Note that in this
context `deflate` is actually a "zlib" data format as defined in
[RFC1950].
To preserve the current behavior we prefer `Content-Encoding: gzip`
whenever `gzip` is listed as one
Am 16.04.24 um 15:18 schrieb Dominik Csapak:
> use the standards info about the ostypes to map to our own
> (see comment for link to the relevant part of the dmtf schema)
>
> every type that is not listed we map to 'other', so no need to have it
> in a list.
>
> Signed-off-by: Dominik Csapak
>
R
Am 16.04.24 um 15:18 schrieb Dominik Csapak:
> it seems there is no part of the ovf standard that handles which type of
> bios there is (at least i could not find it). Every ovf/ova i tested
> either has no info about it, or has it in a vmware specific property
> which we pare here.
s/pare/parse/
Am 16.04.24 um 15:18 schrieb Dominik Csapak:
> simply add all parsed disks to the boot order in the order we encounter
> them (similar to the esxi plugin).
>
> Signed-off-by: Dominik Csapak
> ---
> src/PVE/Storage/OVF.pm| 6 ++
> src/test/run_ovf_tests.pl | 3 +++
> 2 files changed, 9 in
--- Begin Message ---
Stable sorting in user.cfg config file allows tracking changes by
checking into git or when using automation like ansible.
Signed-off-by: Daniel Krambrock
---
changes since v2:
* code-style fix
src/PVE/AccessControl.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-
--- Begin Message ---
Stable sorting in cluster.fw config file allows tracking changes by
checking into git or when using automation like ansible.
Signed-off-by: Daniel Krambrock
---
changes since v2:
* code-style fix
src/PVE/Firewall.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
By matching the resulting json to be passed to the low level installer
against known good ones.
The environment info was gathered from one of our AMD Epyc Rome test
servers to have a realistic starting point.
Signed-off-by: Aaron Lauterer
---
proxmox-auto-installer/tests/parse-answer.rs | 106
By matching the resulting json to be passed to the low level installer
against known good ones.
The environment info was gathered from one of our AMD Epyc Rome test
servers to have a realistic starting point.
Signed-off-by: Aaron Lauterer
---
please use this one, I messed up the enconding settin
Am 16.04.24 um 15:19 schrieb Dominik Csapak:
> by iterating over the relevant parts and trying to parse out the
> 'ResourceSubType'. The content of that is not standardized, but I only
> ever found examples that are compatible with vmware, meaning it's
> either 'e1000', 'e1000e' or 'vmxnet3' (in va
so it can be deserialized from a string
Tested-by: Christoph Heiss
Reviewed-by: Christoph Heiss
Signed-off-by: Aaron Lauterer
---
proxmox-installer-common/src/utils.rs | 11 +++
1 file changed, 11 insertions(+)
diff --git a/proxmox-installer-common/src/utils.rs
b/proxmox-installer-co
necessary for the disk selection and network interfaces maps to have
tests with results that can be compared without much additional effort.
Tested-by: Christoph Heiss
Reviewed-by: Christoph Heiss
Signed-off-by: Aaron Lauterer
---
proxmox-installer-common/src/setup.rs | 8
proxmox-tui
as they will be used directly by the auto installer
Tested-by: Christoph Heiss
Reviewed-by: Christoph Heiss
Signed-off-by: Aaron Lauterer
---
proxmox-installer-common/src/setup.rs | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/proxmox-installer-common/src/setup.
Tested-by: Christoph Heiss
Reviewed-by: Christoph Heiss
Signed-off-by: Aaron Lauterer
---
unconfigured.sh | 8
1 file changed, 8 insertions(+)
diff --git a/unconfigured.sh b/unconfigured.sh
index 2b371f0..f02336a 100755
--- a/unconfigured.sh
+++ b/unconfigured.sh
@@ -5,6 +5,7 @@ trap
Fetches UDEV device properties prepended with 'E:' for NICs and disks.
The result is stored in its own JSON file.
This information is needed to filter for specific devices. Mainly for
the auto-installer for now.
Tested-by: Christoph Heiss
Reviewed-by: Christoph Heiss
Signed-off-by: Aaron Lauter
Tested-by: Christoph Heiss
Reviewed-by: Christoph Heiss
Signed-off-by: Aaron Lauterer
---
proxmox-installer-common/src/setup.rs | 10 ++
1 file changed, 10 insertions(+)
diff --git a/proxmox-installer-common/src/setup.rs
b/proxmox-installer-common/src/setup.rs
index 8432a2c..25d0e9e 1
Log to stdout and the file the binary needs to set up.
This is a first variant. By using the log crate macros we can change
that in the future without too much effort.
Tested-by: Christoph Heiss
Reviewed-by: Christoph Heiss
Signed-off-by: Aaron Lauterer
---
proxmox-auto-installer/Cargo.toml |
Tested-by: Christoph Heiss
Reviewed-by: Christoph Heiss
Signed-off-by: Aaron Lauterer
---
proxmox-auto-installer/Cargo.toml | 1 +
proxmox-auto-installer/src/utils.rs | 46 +++--
2 files changed, 18 insertions(+), 29 deletions(-)
diff --git a/proxmox-auto-installer/C
patches until 31 got a [0,1]
Tested-by: Christoph Heiss
Reviewed-by: Christoph Heiss
changes since v5:
some small style fixups and using cert_fingerprint or TLS instead of
ssl_fingerprint and SSL in patches 32-36.
changes since v4:
Patches 32-36 finalize how to prepare an ISO for automated i
as only the 'path' property is serialized -> deserialization is
problematic. The information would be present in the 'run-env-info-json',
but for now there is no need for it in any code that deserializes the
low-level config. Therefore we are currently skipping it on
deserialization
If we need it
and switch to accepting the full path to the answer file. This makes it
possible to use it in more situations than just the partition case.
Signed-off-by: Aaron Lauterer
---
.../src/fetch_plugins/partition.rs| 23 +--
.../src/fetch_plugins/utils/mod.rs| 13
It sends a http(s) POST request with the sysinfo as payload and expects
an answer file in return.
In order to handle non FQDN URLs (e.g. IP addresses) and self signed
certificates, it can optionally take an SHA256 fingerprint of the
certificate. This can of course also be used to pin a certificate
Signed-off-by: Aaron Lauterer
---
proxmox-fetch-answer/src/fetch_plugins/http.rs | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/proxmox-fetch-answer/src/fetch_plugins/http.rs
b/proxmox-fetch-answer/src/fetch_plugins/http.rs
index 4093131..cd3775f 100644
--- a/proxm
This patch switches the behavior to use the settings that can be
specified in the ISO.
This means, that it is possible to control how the answer file should be
fetched:
* auto - as usually, go through the options until one works (partition,
http)
* included - the answer file is included in the
This new subcommand makes it possible to prepare an ISO to use it for an
automated installation.
It is possible to control the behavior of the resulting automated ISO
with optional parameters.
If no target file is specified, the new ISO will be named with suffixes
to indicate it as automated and a
it is supposed to be run first and fetch an answer file.
The initial implementation searches for a partition/filesystem called
'proxmoxinst' or 'PROXMOXINST' with an 'answer.toml' file in the root
directory.
Once it has an answer file, it will call the 'proxmox-auto-installer'
and pipe in the con
It can parse an answer file to check against syntax errors, test match
filters against the current hardware and list properties of the current
hardware to match against.
Since this tool should be able to run outside of the installer
environment, it does not rely on the device information provided
This plugin will send a HTTP POST request with identifying sysinfo to
fetch an answer file. The provided sysinfo can be used to identify the
system and generate a matching answer file on demand.
The URL to send the request to, can be defined in two ways. Via a custom
DHCP option or a TXT record on
For the Enums that will be used to deserialize an answer file.
Tested-by: Christoph Heiss
Reviewed-by: Christoph Heiss
Signed-off-by: Aaron Lauterer
---
proxmox-installer-common/src/options.rs | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/proxmox-installer-c
It describes the data structure expected by the low-level-installer.
We do this so we can use it in more than the TUI installer, for example
the planned auto installer.
Make the members public so we can easily implement a custom From method
for each dependent crate.
Tested-by: Christoph Heiss
Re
Tested-by: Christoph Heiss
Reviewed-by: Christoph Heiss
Signed-off-by: Aaron Lauterer
---
proxmox-auto-installer/src/lib.rs | 1 +
proxmox-auto-installer/src/udevinfo.rs | 9 +
2 files changed, 10 insertions(+)
create mode 100644 proxmox-auto-installer/src/udevinfo.rs
diff --git
Tested-by: Christoph Heiss
Reviewed-by: Christoph Heiss
Signed-off-by: Aaron Lauterer
---
proxmox-auto-installer/Cargo.toml | 4
1 file changed, 4 insertions(+)
diff --git a/proxmox-auto-installer/Cargo.toml
b/proxmox-auto-installer/Cargo.toml
index 75cfb2c..67218dd 100644
--- a/proxmox-
Tested-by: Christoph Heiss
Reviewed-by: Christoph Heiss
Signed-off-by: Aaron Lauterer
---
Cargo.toml| 1 +
Makefile | 1 +
proxmox-auto-installer/Cargo.toml | 10 ++
proxmox-auto-installer/src/lib.rs | 0
4 files changed, 12 insertions
because we will need to access them directly in the future from a
separate binary
Tested-by: Christoph Heiss
Reviewed-by: Christoph Heiss
Signed-off-by: Aaron Lauterer
---
proxmox-auto-installer/src/utils.rs | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/proxmox-auto-i
Tested-by: Christoph Heiss
Reviewed-by: Christoph Heiss
Signed-off-by: Aaron Lauterer
---
debian/control | 10 ++
1 file changed, 10 insertions(+)
diff --git a/debian/control b/debian/control
index 3ca208b..1326400 100644
--- a/debian/control
+++ b/debian/control
@@ -8,10 +8,20 @@ Buil
This helps to know how the system was set up in steps after the
installation. For example in debug mode or when using post commands in
the automatic/unattended installation.
Tested-by: Christoph Heiss
Reviewed-by: Christoph Heiss
Signed-off-by: Aaron Lauterer
---
proxmox-low-level-installer |
Tested-by: Christoph Heiss
Reviewed-by: Christoph Heiss
Signed-off-by: Aaron Lauterer
---
proxmox-auto-installer/Cargo.toml| 1 +
proxmox-auto-installer/src/answer.rs | 248 +++
proxmox-auto-installer/src/lib.rs| 1 +
3 files changed, 250 insertions(+)
creat
These will be expected on the ISO itself and define the behavior of the
automated installation.
Signed-off-by: Aaron Lauterer
---
proxmox-auto-installer/src/utils.rs | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/proxmox-auto-installer/src/utils.rs
b/pr
It expects the contents of an answer file via stdin. It will then be
parsed and the JSON for the low level installer is generated.
It then calls the low level installer directly.
The output of the installaton progress is kept rather simple for now.
If configured in the answer file, commands will
Tested-by: Christoph Heiss
Reviewed-by: Christoph Heiss
Signed-off-by: Aaron Lauterer
---
proxmox-installer-common/Cargo.toml | 1 +
proxmox-installer-common/src/options.rs | 10 ++---
proxmox-installer-common/src/setup.rs | 30 ++---
3 files changed, 35 insertion
It will collect the information from the current system and show the
payload of identifiers that will be send.
To avoid confusion, the subcommands for the device info and filter
matching have been renamed.
Tested-by: Christoph Heiss
Reviewed-by: Christoph Heiss
Signed-off-by: Aaron Lauterer
--
They will be used as payload when POSTing a request for an answer file. The
idea is, that with this information, it should be possible to identify
the system and generate a matching answer file on the fly.
Many of these properties can also be found on the machine or packaging
of the machine and cou
contains several utility structs and functions.
For example: a simple pattern matcher that matches wildcards at the
beginning or end of the filter.
It currently uses a dedicated function (parse_answer) to generate the
InstallConfig struct instead of a From implementation. This is because
for now
a new v6 has been posted that includes the t-b and r-b tags as well as
some smaller style fixes in the most recent patches
https://lists.proxmox.com/pipermail/pve-devel/2024-April/063139.html
On 2024-04-16 17:32, Aaron Lauterer wrote:
patches until 31 got a [0,1]
Tested-by: Christoph Heiss
By matching the resulting json to be passed to the low level installer
against known good ones.
The environment info was gathered from one of our AMD Epyc Rome test
servers to have a realistic starting point.
Tested-by: Christoph Heiss
Reviewed-by: Christoph Heiss
Signed-off-by: Aaron Lauterer
On April 16, 2024 3:19 pm, Dominik Csapak wrote:
> but only for non esxi ones, since that does not allow
> uploading/downloading there
what about a remove button? :)
>
> Signed-off-by: Dominik Csapak
> ---
> www/manager6/storage/Browser.js| 7 ++-
> www/manager6/window/UploadToStor
This way, serde will throw errors if fields are not known.
This can help to reduce frustration if one might think to have set an
option, but for example a small type has happened.
Tested-by: Christoph Heiss
Reviewed-by: Christoph Heiss
Signed-off-by: Aaron Lauterer
---
proxmox-auto-installer/
Putting proxmox-fetch-answer into it's own crate, will keep the use of
OpenSSL localized to where we need it. Otherwise building other binaries
will always depend on OpenSSL as well, even without actually needing it.
Having a dedicated crate for the proxmox-autoinst-helper should make it
easier to
it is meant as a helper utility to prepare an installation for chroot
and clean up afterwards
It tries to determine the used FS from the previous installation, will
do what is necessary to mount/import the root FS to /target. It then
will set up all bind mounts.
Tested-by: Christoph Heiss
Review
On April 16, 2024 3:18 pm, Dominik Csapak wrote:
> in DirPlugin and not Plugin (because of cyclic dependency of
> Plugin -> OVF -> Storage -> Plugin otherwise)
>
> only ovf is currently supported (though ova will be shown in import
> listing), expects the files to not be in a subdir, and adjacent
On April 16, 2024 3:18 pm, Dominik Csapak wrote:
> since we want to handle ova files (which are only ovf+vmdks bundled in a
> tar file) for import, add code that handles that.
>
> we introduce a valid volname for files contained in ovas like this:
>
> storage:import/archive.ova/disk-1.vmdk
>
>
On 4/17/24 12:52, Fiona Ebner wrote:
Am 16.04.24 um 15:18 schrieb Dominik Csapak:
since we want to handle ova files (which are only ovf+vmdks bundled in a
tar file) for import, add code that handles that.
we introduce a valid volname for files contained in ovas like this:
storage:import/arch
On 4/17/24 14:45, Fabian Grünbichler wrote:
On April 16, 2024 3:18 pm, Dominik Csapak wrote:
since we want to handle ova files (which are only ovf+vmdks bundled in a
tar file) for import, add code that handles that.
we introduce a valid volname for files contained in ovas like this:
storage:
On April 16, 2024 3:18 pm, Dominik Csapak wrote:
> This series enables importing ova/ovf from directory based storages,
> inclusive upload/download via the webui (ova only).
>
> It also improves the ovf importer by parsing the ostype, nics, bootorder
> (and firmware from vmware exported files).
>
On 4/17/24 12:07, Fiona Ebner wrote:
Am 16.04.24 um 15:18 schrieb Dominik Csapak:
in DirPlugin and not Plugin (because of cyclic dependency of
Plugin -> OVF -> Storage -> Plugin otherwise)
only ovf is currently supported (though ova will be shown in import
listing), expects the files to not be
On 4/17/24 13:32, Fiona Ebner wrote:
Am 16.04.24 um 15:18 schrieb Dominik Csapak:
use the standards info about the ostypes to map to our own
(see comment for link to the relevant part of the dmtf schema)
every type that is not listed we map to 'other', so no need to have it
in a list.
Signed-o
On 4/17/24 13:54, Fiona Ebner wrote:
Am 16.04.24 um 15:18 schrieb Dominik Csapak:
simply add all parsed disks to the boot order in the order we encounter
them (similar to the esxi plugin).
Signed-off-by: Dominik Csapak
---
src/PVE/Storage/OVF.pm| 6 ++
src/test/run_ovf_tests.pl | 3
On 4/17/24 14:09, Fiona Ebner wrote:
Am 16.04.24 um 15:19 schrieb Dominik Csapak:
by iterating over the relevant parts and trying to parse out the
'ResourceSubType'. The content of that is not standardized, but I only
ever found examples that are compatible with vmware, meaning it's
either 'e100
On 4/17/24 15:11, Fabian Grünbichler wrote:
On April 16, 2024 3:18 pm, Dominik Csapak wrote:
This series enables importing ova/ovf from directory based storages,
inclusive upload/download via the webui (ova only).
It also improves the ovf importer by parsing the ostype, nics, bootorder
(and fir
On April 17, 2024 3:07 pm, Dominik Csapak wrote:
> On 4/17/24 12:52, Fiona Ebner wrote:
>> Am 16.04.24 um 15:18 schrieb Dominik Csapak:
>>> since we want to handle ova files (which are only ovf+vmdks bundled in a
>>> tar file) for import, add code that handles that.
>>>
>>> we introduce a valid vol
Am 17/04/2024 um 10:53 schrieb Dominik Csapak:
> move the confirm action to the right as mentioned in the material spec[0]
> also rewords the buttons to 'cancel' and 'shutdown/reboot'
> for that to work properly slightly rename the confirm message
>
> 0:
> https://m3.material.io/components/dialog
On April 17, 2024 3:10 pm, Dominik Csapak wrote:
> On 4/17/24 14:45, Fabian Grünbichler wrote:
>> On April 16, 2024 3:18 pm, Dominik Csapak wrote:
>>> +sub cleanup_extracted_image {
>>
>> same for this?
>>
>>> +my ($source) = @_;
>>> +
>>> +if ($source =~ m|^(/.+/\.tmp_[0-9]+_[0-9]+)/[^/]
Reviewed-by: Lukas Wagner
Reviewed-by: Max Carrara
Co-authored-by: Wolfgang Bumiller
Signed-off-by: Stefan Hanreich
---
.cargo/config| 5 +
.gitignore | 6 ++
Cargo.toml | 4
proxmox-ve-config/Cargo.toml | 19 ++
Adds types for log and (log-)rate-limiting firewall config options as
well as FromStr implementations for parsing them from the config.
Reviewed-by: Lukas Wagner
Reviewed-by: Max Carrara
Co-authored-by: Wolfgang Bumiller
Signed-off-by: Stefan Hanreich
---
proxmox-ve-config/Cargo.toml
Reviewed-by: Lukas Wagner
Reviewed-by: Max Carrara
Co-authored-by: Wolfgang Bumiller
Signed-off-by: Stefan Hanreich
---
proxmox-ve-config/src/firewall/types/group.rs | 36 +++
proxmox-ve-config/src/firewall/types/mod.rs | 2 ++
2 files changed, 38 insertions(+)
create mode
Adds types for all kinds of port-related values in the firewall config
as well as FromStr implementations for parsing them from the config.
Also adds a helper for parsing the named ports from `/etc/services`.
Reviewed-by: Lukas Wagner
Reviewed-by: Max Carrara
Co-authored-by: Wolfgang Bumiller
## Introduction
This RFC provides a drop-in replacement for the current pve-firewall package
that is based on Rust and nftables.
It consists of three crates:
* proxmox-ve-config
for parsing firewall and guest configuration files, as well as some helpers
to access host configuration (particular
Several objects, statements and expressions in nftables-json require
null values, for instance:
{ "flush": { "ruleset": null }}
For this purpose we define our own Null type, which we can then easily
use for defining types that accept Null as value.
Several keys accept as value either a singu
Currently the helpers for obtaining the host network configuration
panic on error, which could be avoided by the use of
OnceLock::get_or_init, but this method is currently only available in
nightly versions.
Generally, if there is a problem with obtaining the network config for
the node I would de
Reviewed-by: Lukas Wagner
Reviewed-by: Max Carrara
Co-authored-by: Wolfgang Bumiller
Signed-off-by: Stefan Hanreich
---
proxmox-ve-config/src/firewall/parse.rs | 52 ++
proxmox-ve-config/src/firewall/types/alias.rs | 160 ++
proxmox-ve-config/src/firewall/types/mod.r
Includes types for all kinds of IP values that can occur in the
firewall config. Additionally, FromStr implementations are available
for parsing from the config files.
Reviewed-by: Lukas Wagner
Reviewed-by: Max Carrara
Co-authored-by: Wolfgang Bumiller
Signed-off-by: Stefan Hanreich
---
proxm
Reviewed-by: Lukas Wagner
Reviewed-by: Max Carrara
Co-authored-by: Wolfgang Bumiller
Signed-off-by: Stefan Hanreich
---
proxmox-firewall/src/main.rs | 34 ++
1 file changed, 34 insertions(+)
diff --git a/proxmox-firewall/src/main.rs b/proxmox-firewall/src/main.
Adds an enum containing most of the statements defined in the
nftables-json schema [1].
[1]
https://manpages.debian.org/bookworm/libnftables1/libnftables-json.5.en.html#STATEMENTS
Reviewed-by: Lukas Wagner
Reviewed-by: Max Carrara
Co-authored-by: Wolfgang Bumiller
Signed-off-by: Stefan Hanrei
ToNftObjects is basically a conversion trait that converts firewall
config structs into nftables objects. It returns a list of commands
that create the respective nftables objects.
Reviewed-by: Lukas Wagner
Reviewed-by: Max Carrara
Co-authored-by: Wolfgang Bumiller
Signed-off-by: Stefan Hanreic
Add a thin wrapper around libnftables, which can be used to run
commands defined by the rust types.
Reviewed-by: Lukas Wagner
Reviewed-by: Max Carrara
Co-authored-by: Wolfgang Bumiller
Signed-off-by: Stefan Hanreich
---
proxmox-nftables/src/context.rs | 243
p
Signed-off-by: Stefan Hanreich
---
www/manager6/grid/FirewallOptions.js | 1 +
1 file changed, 1 insertion(+)
diff --git a/www/manager6/grid/FirewallOptions.js
b/www/manager6/grid/FirewallOptions.js
index 0ac9979c4..6aacb47be 100644
--- a/www/manager6/grid/FirewallOptions.js
+++ b/www/manager6/
Introduces new nftables configuration option that en/disables the new
nftables firewall.
pve-firewall reads this option and only generates iptables rules when
nftables is set to `0`. Conversely proxmox-firewall only generates
nftables rules when the option is set to `1`.
Signed-off-by: Stefan Han
We create the rules from the firewall config by utilizing the
ToNftRules and ToNftObjects traits to convert the firewall config
structs to nftables objects/chains/rules.
Reviewed-by: Lukas Wagner
Reviewed-by: Max Carrara
Co-authored-by: Wolfgang Bumiller
Signed-off-by: Stefan Hanreich
---
pro
This is the skeleton for the firewall that contains all the base
chains required for the firewall.
The file applies atomically, which means that it flushes all objects
and recreates them - except for the cluster/host/guest chain. This
means that it can be run at any point in time, since it only up
Reviewed-by: Lukas Wagner
Reviewed-by: Max Carrara
Co-authored-by: Wolfgang Bumiller
Signed-off-by: Stefan Hanreich
---
Cargo.toml | 1 +
proxmox-nftables/Cargo.toml | 16
proxmox-nftables/src/lib.rs | 0
3 files changed, 17 insertions(+)
create mode 100644
Reviewed-by: Lukas Wagner
Reviewed-by: Max Carrara
Co-authored-by: Wolfgang Bumiller
Signed-off-by: Stefan Hanreich
---
proxmox-ve-config/src/firewall/cluster.rs | 374 ++
proxmox-ve-config/src/firewall/mod.rs | 1 +
2 files changed, 375 insertions(+)
create mode 100
1 - 100 of 142 matches
Mail list logo
