From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id 07A931FF09B for ; Mon, 12 Oct 2026 18:54:17 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 1B228213C8; Mon, 12 Oct 2026 18:54:14 +0200 (CEST) Message-ID: Date: Mon, 12 Oct 2026 18:54:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [RFC] installer web console for headless installs (native text mode + browser front) To: feng liu , pve-devel@lists.proxmox.com References: Content-Language: en-US From: Thomas Lamprecht In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1791824048865 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.580 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: MKGDAXSPKRDZ7F5EIMTF5RQICGEM5UYX X-Message-ID-Hash: MKGDAXSPKRDZ7F5EIMTF5RQICGEM5UYX X-MailFrom: t.lamprecht@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Hello, Thx for sending an RFC upfront over just "dumping" some patches here. See my answer below. Am 12.10.26 um 17:58 schrieb feng liu: > headless installs currently mean a serial TUI or a pre-authored answer.toml. For one-off boxes both loops feel heavy: no keyboard or monitor on the machine, and writing TOML before touching hardware. > > Proposal: one new installer boot entry - "Install Proxmox VE (web console)" - that boots the native text-mode installer exactly as the serial entry does, and additionally serves the installer's own question flow over plain HTTP on the LAN. Implementation-wise this is a third Proxmox::UI:: backend ("Web") beside the existing Gtk3 and StdIO ones: same questions, same validations, same progress stream, same auto-installer path downstream. One flow, three faces - no parallel wizard to maintain. > > Access is gated by a one-time pairing code printed at boot: a session code on the console/serial, plus an optional machine code drawn by the bootloader from the SMBIOS UUID, so a machine with no screen or serial cable attached can still be paired from a phone. The target machine keeps showing the native text-mode screens throughout. > > Full proposal text (motivation, code mapping to Proxmox::UI::Base / unconfigured.sh, honest security notes, open questions): > > https://github.com/yeungtuzi/pve-installer/tree/web-console-proposal/web-console > > Concept mockups attached - boot menu, pairing page, setup form, progress page and the target machine's native text screen. They are concept art in the corporate palette, not UI code. > > If there is interest I will follow up with an RFC patch series (small HTTP daemon in the initrd + Proxmox::UI::Web). In the meantime I would value the list's opinion - in particular whether the maintained surface of a web front is worth it versus extending the existing auto-install answer tooling. Note that you can already use PDM for configuring installation answer files via a web UI and then serving these to any Proxmox installation. This which uses the HTTP-answer-file-source mode to server a answer file. It's also planned to make this interactively, as the system information the installer sends to the answer-file source endpoint is complete for a fully installer, there isn't really anything else required and allows to keep the installer lean and avoids additional attack surface there. We thought about doing so in the past, but held it off due to it not unlocking a fundamental new method. If we probably would still effectively use this approach (get system info for rendering the installer wizard/UI and let it send a answer file back) over another Proxmox::UI:: impl, as it would require less dependencies. The PDM/answer-file approach also has trust and auth solved already, as one needs to prepare the ISO, so ISO can validate answer-source endpoint and vice versa, which a pure web based interface would need to solve again. Also note that this can be a stand-alone tool, and you could already leverage this and create your own independent tooling/wizard in the front that doesn't runs on the installer then if the PDM use case doesn't fit your needs, just needs to prepare the ISO once to point it at your endpoint. Might be still simpler to reused PDM. If we re-evaluate the directly web UI inside the installer (could also be just to replace Gtk some day), we would in any case (re-)use the rust/yew based proxmox web UI components from PDM's installer integration - where applicable over some other web UI framework. best regards, Thomas