A hashed password can be created e.g. using the `mkpasswd(1)`.
This then will allow the auto-installer to pass along a
already-hashed password from the user, instead of simple plaintext.
Signed-off-by: Christoph Heiss
---
Changes v1 -> v2:
* no changes
Proxmox/Install.pm| 25 +
This allows user to specify the root password in a hashed format,
generated using e.g. mkpasswd(1), instead of plaintext.
Signed-off-by: Christoph Heiss
---
Changes v1 -> v2:
* move root password setting validation into own function
* explicitly check for case for both are unset
proxmox-aut
It's only used internally there anyway, so make it slightly less
confusing.
Signed-off-by: Christoph Heiss
---
Changes v1 -> v2:
* no changes
proxmox-installer-common/src/options.rs | 15 ---
proxmox-tui-installer/src/main.rs | 4 ++--
proxmox-tui-installer/src/options.rs
Signed-off-by: Christoph Heiss
---
Changes v1 -> v2:
* previously split up into two separate patches between auto- and tui-
installer, now merged together for consistency
proxmox-auto-installer/src/utils.rs | 9 +++--
.../tests/resources/parse_answer/disk_match.json
So we never accidentally show/log the password somewhere. Need to drop
it from `InstallerOptions` in turn too, but it's never used currently
anyway.
Signed-off-by: Christoph Heiss
---
Changes v1 -> v2:
* no changes
proxmox-tui-installer/src/options.rs | 4 ++--
1 file changed, 2 insertions(+)
This series adds a new answer option `global.root_password_hashed`
for the auto-installer, enabling administrators to specify the root
password of the new installation in a hashed format - as generated by
e.g. mkpasswd(1) - instead of plain-text.
Administrators/users might want to avoid passing al
Signed-off-by: Christoph Heiss
---
Changes v1 -> v2:
* no changes
.../parse_answer/hashed_root_password.json| 20 +++
.../parse_answer/hashed_root_password.toml| 14 +
2 files changed, 34 insertions(+)
create mode 100644
proxmox-auto-installer/tests/resour
Am 10/07/2024 um 15:27 schrieb Christoph Heiss:
> This implements a mechanism for post-installation "notifications" via a
> POST request [0] when using the auto-installer.
>
> It's implemented as a separate, small utility to facilitate separation
> of concerns and make the information gathering ea
Thanks for the feedback!
Since this will be externally consumed API surface, changing it
afterwards will be a pain anyway - so comments on the JSON schema are
really appreciated too.
On Mon, Jul 15, 2024 at 12:42:41PM GMT, Thomas Lamprecht wrote:
> Am 10/07/2024 um 15:27 schrieb Christoph Heiss:
Thanks for the review!
On Fri, Jul 12, 2024 at 11:36:56AM GMT, Aaron Lauterer wrote:
> only one small nit inline
>
> On 2024-07-11 13:57, Christoph Heiss wrote:
> > [..]
> > +sub zfs_ask_existing_zpool_rename {
> > +my ($pool_name) = @_;
> > +
> > +# At this point, no pools should be imp
Thanks again!
On Fri, Jul 12, 2024 at 11:42:58AM GMT, Aaron Lauterer wrote:
> tested this series more thoroughly and checked with an existing root pool
> all 3 install options:
>
> * TUI
> * GUI
> * auto
>
> Worked well in 3 cases to rename.
>
> One oddity seems to be if we cancel the rename in th
--- Begin Message ---
Hi, to everyone, i'm interested in native S3 support on proxmox, is anyone
working on it ( to avoid double work )?
Second question, my idea is to reuse existing pbs code but upload chunks
and index to s3, sounds good? The thing puzzling me is that a lot of code
will end up dup
> Tiziano Bacocco via pve-devel hat am 16.07.2024
> 00:20 CEST geschrieben:
> Hi, to everyone, i'm interested in native S3 support on proxmox, is anyone
> working on it ( to avoid double work )?
None of us is, but there is an external developer that is trying to implement
something like this.
13 matches
Mail list logo
