On Wed Apr 3, 2024 at 11:10 AM CEST, Friedrich Weber wrote:
> Currently, `Proxmox.window.Edit` initializes `extraRequestParams` to
> an object that, if not overwritten, is shared between all instances of
> subclasses. This bears the danger of modifying the shared object in a
> subclass instead of o
On 04/04/2024 10:22, Stefan Sterz wrote:
> On Wed Apr 3, 2024 at 11:10 AM CEST, Friedrich Weber wrote:
>> Currently, `Proxmox.window.Edit` initializes `extraRequestParams` to
>> an object that, if not overwritten, is shared between all instances of
>> subclasses. This bears the danger of modifying
-- >8 snip 8< --
> >
> > i did a quick an dirty test and using a constructor like this seems to
> > rule out this class of bug completelly:
> >
> > ```js
> > constructor: function(conf) {
> > let me = this;
> > me.extraRequestParams = {};
> > me.initConfig(conf);
> >
Stefan Lendl writes:
> This patch series allows configuring a VLAN network interfaces in the PBS GUI
>
... I sent the cover letter only to me and not to pve-devel ...
will send the entire series again.
___
pve-devel mailing list
pve-devel@lists.proxm
subject should be more in the style of:
ui: qemu: add clipboard selector to options
Am 21/11/2023 um 13:39 schrieb Markus Frank:
> For SPICE and VNC, a different message is displayed.
>
possibly reference the backend work here,
> Save config in DisplayEdit so that the clipboard setting persist
On 04/04/2024 11:23, Stefan Sterz wrote:
> -- >8 snip 8< --
>>>
>>> i did a quick an dirty test and using a constructor like this seems to
>>> rule out this class of bug completelly:
>>>
>>> ```js
>>> constructor: function(conf) {
>>> let me = this;
>>> me.extraRequestParams = {
On Thu Apr 4, 2024 at 12:10 PM CEST, Friedrich Weber wrote:
> On 04/04/2024 11:23, Stefan Sterz wrote:
> > -- >8 snip 8< --
> >>>
> >>> i did a quick an dirty test and using a constructor like this seems to
> >>> rule out this class of bug completelly:
> >>>
> >>> ```js
> >>> constructor: funct
Am 04/04/2024 um 12:10 schrieb Friedrich Weber:
> Maybe we could do:
>
> ```js
> extraRequestParams: {},
>
> constructor: function(conf) {
> let me = this;
> me.extraRequestParams = Ext.clone(me.extraRequestParams);
> me.initConfig(conf);
> me.callParent();
>
On Thu Apr 4, 2024 at 12:54 PM CEST, Stefan Sterz wrote:
> On Thu Apr 4, 2024 at 12:10 PM CEST, Friedrich Weber wrote:
> > On 04/04/2024 11:23, Stefan Sterz wrote:
> > > -- >8 snip 8< --
> > >>>
> > >>> i did a quick an dirty test and using a constructor like this seems to
> > >>> rule out this cla
On 04/04/2024 12:59, Thomas Lamprecht wrote:
> Am 04/04/2024 um 12:10 schrieb Friedrich Weber:
>> Maybe we could do:
>>
>> ```js
>> extraRequestParams: {},
>>
>> constructor: function(conf) {
>> let me = this;
>> me.extraRequestParams = Ext.clone(me.extraRequestParams);
>>
Am 03/04/2024 um 13:46 schrieb Stoiko Ivanov:
> copying files within a cifs-share currently result in the following
> trace:
> ```
> [ 495.388739] BUG: unable to handle page fault for address: fffe
> [ 495.388744] #PF: supervisor read access in kernel mode
> [ 495.388746] #PF: error_
Am 03/04/2024 um 12:45 schrieb Christoph Heiss:
> This adds an empty line between the feature list and the "more
> information" paragraph, which looks a lot better.
>
> The exact same is already present in the HTML template for both other
> products, probably a simple oversight.
>
> Signed-off-by
I've tested this on my machine. It works if the MTU is explicitly set in
the zone configuration. If the MTU is set on the bridge to something
else than 1500 and the zone configuration has 'auto', then the MTU of
all other interfaces and bridges is still set to 1500.
Shouldn't we try to get the MTU
Tested building this with sbuild - completed successfully (including tests).
I've also checked out the changes and tested them by creating a new EVPN
zone and setting a local frr config. Everything still seems to be
working as before.
Consider this:
Tested-By: Stefan Hanreich
On 4/2/24 13:07,
as they will be used directly by the auto installer
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.rs
b/proxmox-installer-common/src/setup.rs
index 03beb77.
For the Enums that will be used to deserialize an answer file.
Signed-off-by: Aaron Lauterer
---
proxmox-installer-common/src/options.rs | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/proxmox-installer-common/src/options.rs
b/proxmox-installer-common/src/optio
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.
Signed-off-by: Aaron Lauterer
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.
Signed-off-by: Aaron Lauterer
---
Proxmox/Makefile| 1 +
Proxmox/Sys/U
because we will need to access them directly in the future from a
separate binary
Signed-off-by: Aaron Lauterer
---
proxmox-auto-installer/src/utils.rs | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/proxmox-auto-installer/src/utils.rs
b/proxmox-auto-installer/src/utils.
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 100644
--- a/proxmox-installer-common/src/setup.rs
+++ b/pr
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.
Signed-off-by: Aaron Lauterer
---
proxmox-auto-installer/Cargo.toml | 2 ++
proxmox-auto-installer/src/lib.rs | 1 +
proxmox-
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/Cargo.toml
b/proxmox-auto-installer/Cargo.toml
index b1d3e
This patch series adds the possibility to do an automated / unattended
installation of Proxmox VE.
The overall idea is that we will have a dedicated ISO for the unattended
installation. It should be configured in such a way that it will start
the installation without any user interaction. Therefor
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.
Signed-off-by: Aaron Lauterer
---
.../src/bin/proxmox-autoinst-helper.rs| 54
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
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 insertions(+), 6 deletions(-)
diff --git a/proxmox-installer-commo
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
so it can be deserialized from a string
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-common/src/utils.rs
index 36b1d53..f6521eb 100644
--- a/prox
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(+)
create mode 100644 proxmox-auto-installer/Cargo.toml
necessary for the disk selection and network interfaces maps to have
tests with results that can be compared without much additional effort.
Signed-off-by: Aaron Lauterer
---
proxmox-installer-common/src/setup.rs | 8
proxmox-tui-installer/src/options.rs | 4 ++--
proxmox-tui-installer
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-auto-installer/Cargo.toml
+++ b/proxmox-auto-installer/Car
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 a/proxmox-auto-installer/src/lib.rs
b/proxmox-auto-instal
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 "err_reboot" ERR
# NOTE: we nowadays get exec'd by the in
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.
Signed-off-by: Aaron Lauterer
---
proxmox-low-level-installer | 1 +
1 file changed, 1 insertion(+)
diff --git a/proxmox-
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(+)
create mode 100644 proxmox-auto-installer/src/answer.rs
diff -
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 @@ Build-Depends: cargo:native,
libgtk3-perl,
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
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
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
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
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
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.
Signed-off-by: Aaron Lauterer
---
Am 02/04/2024 um 13:07 schrieb Stefan Lendl:
> Extract and mock functions that otherwise access system files which is not
> possible in a clean sbuild environment.
> Namely /etc/network/interfaces as well as /etc/frr/frr.config.local
> Added .gitignore for sbuild artifacts
>
> Changes v2 -> v3:
>
Am 03/04/2024 um 10:08 schrieb Lukas Wagner:
> Versions of Gotify < 2.2.0 only supported the 'X-Gotify-Key' header
> for passing the API token. This comment sets this header in addition
> to the regular 'Authorization' header in order to be compatible with
> older Gotify servers.
>
> Signed-off-by
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 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
Am 30/01/2024 um 18:10 schrieb Friedrich Weber:
Maybe start of with "Add a helper to abort all tasks from a specific
(type, user, vmid) tuple. It will be used ...
> This helper is used to abort any active qmshutdown/vzshutdown tasks
> before attempting to stop a VM/CT (if requested).
>
> Signed-o
Am 30/01/2024 um 18:10 schrieb Friedrich Weber:
> Previously, container start/stop/shutdown/suspend would try to acquire
> the config lock in the API handler prior to forking a worker. If the
> lock was currently held elsewhere, this would block the API handler
> and thus the pvedaemon worker threa
48 matches
Mail list logo
