Red Hat / Fedora Anaconda Installer Shifting To A Web Based UI

[tildearrow]

i'll repeat: to be able to use native installer for your otherwise case, do you insist on bloating fedora with two installers or on forbidding remote install?

Again, what "two installers"? Two installers are not needed, just one that can do both tasks (local and remote installation).
And no, I am not talking about the web-based one. I am referring to a native installer.

[pal666]

Otherwise I'd rather have the native non-web-based installer only.

i'll repeat: to be able to use native installer for your otherwise case, do you insist on bloating fedora with two installers or on forbidding remote install?

[tildearrow]

so for otherwise case you want to bloat it with two installers?

Otherwise I'd rather have the native non-web-based installer only.

[pal666]

So, modernizing means adding bloat...

A web-based installer may be very nice for easier remote installations, but otherwise......

so for otherwise case you want to bloat it with two installers?

[zparihar]

It should not directly affect Kickstart, but there could be various positive side effects:

• nice modern remote UI makes a stronger case for having a small headless installation image as one of the official deliverables
• it should be easier and nicer to monitor and or/debug remote Kickstart installs via the Web UI

Also in some of the feedback threads for this announcements I have seen a cool suggestion to enable copy pasting kickstart via remote Web UI, possibly removing the need to have a reachable HTTP server to host in in some cases. At the same time one could presumably edit the Kickstart, making rapid tuning possible.

Cockpit also has nice components for log display and even a cool in-browser terminal emulator. If that could be reused in some way in the anaconda Web UI, it would be possible to debug remote Kickstart installs via logs and console access without needing a separate SSH or serial connection.

While this would be theoretically possible even now via VNC, the copy paste support in VNC is wacky at best and the UI currently starts far too late to load Kickstart.

This is Excellent! Many companies and products are reliant upon Kickstart. Glad to see this getting enhanced!

[MartinK]

How will this effect Kickstart?

It should not directly affect Kickstart, but there could be various positive side effects:

• nice modern remote UI makes a stronger case for having a small headless installation image as one of the official deliverables
• it should be easier and nicer to monitor and or/debug remote Kickstart installs via the Web UI

Also in some of the feedback threads for this announcements I have seen a cool suggestion to enable copy pasting kickstart via remote Web UI, possibly removing the need to have a reachable HTTP server to host in in some cases. At the same time one could presumably edit the Kickstart, making rapid tuning possible.

Cockpit also has nice components for log display and even a cool in-browser terminal emulator. If that could be reused in some way in the anaconda Web UI, it would be possible to debug remote Kickstart installs via logs and console access without needing a separate SSH or serial connection.

While this would be theoretically possible even now via VNC, the copy paste support in VNC is wacky at best and the UI currently starts far too late to load Kickstart.

[zparihar]

How will this effect Kickstart?

[Terrablit]

No, Electron will definitely not be used in any form or manner for the new Anaconda Web UI. :-)

The backend written in Python that does all the actual installer work will remain in place as will the existing text interface as well as automated installation support via kickstart. The Web UI will be developed in parallel with the existing GTK3/Python GUI and is not expected to become the default until it is sufficiently feature complete.

As much as possible of the Web UI will be built using existing & well proven Cockpit based tooling and the robust and widely used PatternFly web widget library. The Web UI will communicate with the Anaconda Python backend via DBus, as the current GTK3 GUI and the text interface already do. The various configuration screen you might find when you install cockpit on your machine basically do the same (they talk to various services, say Metwork Manager or Udisks - running on your machine via DBus, so the cockpit tech is a really good fit for this usecase.

when running locally (like the GTK3 GUI does at the moment) the cockpit-desktop tool will be used:

https://cockpit-project.org/guide/la...kpit-desktop.1

This is again already well used and working well so far + as its just a Python/GTK/Webkit combo, it does not really add any extra dependencies to the installation image as all of these things are already there (Python for Anaconda, GTK for the existing GTK UI, Webkit for the Yelp help viewer).

While its still quite early, performance of the Web UI does not seem to be really different from the existing GUI when running locally.

For remote access though, the Web UI has the potential to improve things quite a bit!

Current GUI remote access uses VNC, which is inefficient (sends bitmaps), does local rendering (putting more starin on the machine doing the installation), requires GUI libs locally installed (no headless images if you want remote GUI), insecure (limited password length, no encryption) and needs specific client software (VNC viewer).

In comparison a remote Web UI only really transfers a few bits here and there, could likely run of a first generation RPI as it does no local rendering, from a small image (no need to have X/Wayland, GTK, VNC server, etc. on the image) via encrypted connection (HTTPS) and effectively stateless GUI that (at least in theory) could be spawned in any installation phase. Say when your automated install somewhere on the net gets stuck or you want to provision the Fedora image you just put on an SD card for your new SBC via the Fedora ARM installer, without involving any serial consoles or temporary HDMI monitors.

That's kind of what I expected. Thanks for actually explaining things. It's pretty typical for people to think that a web gui = electron, but the entire point of cockpit is that it's a web server for configuring one or more systems with existing interfaces. Everyone forgets that HTTP has a lot of different API approaches on top (e.g. REST) that can make for very responsive remote GUIs with minimal network traffic. There's more in the world than pages stuffed with 100MB of javascript.

Theoretically this could be used for manual remote installs as well as scripted remote installs. Booting several installers via PXE, having them connect to a central cockpit instance and pushing a configuration could make for a fairly positive experience. Especially for people who don't already have experience with an existing configuration management tool like chef, puppet or ansible. And this could also be a way to bootstrap the system and then push ansible scripts.

It'd be really nice if PXE boot server work was also done to simplify managing it from cockpit, since the configuration of a PXE boot server can be a bit arcane. Wouldn't be surprised if it does, as it's definitely an enterprise time sink.

[Mez']

...while your fingers rejoice from the usefulness... but seriously: If looks is so important for you - do you run an installer often enough that you really care? Would somebody be as stupid as not to try a distro (or whatever) just because the installer which is normally used once is not pretty enough?

Firstly, it's not about me. It's about appealing to users, hence ease of use and access. It's off-putting to see this when you have 2020's GUI almost everywhere else.
In the Linux world, we need to get out of that mentality of the 80's where it's normal for some to see and use some obscure screens, because "that's how we've always done it"...
Secondly, sure it's not for the few times a decade you're going to use an installer. But the visual front somehow reflects the mentality behind. Every choice a distro make will have the same mindset behind the scenes, and therefore an outdated and geeky visual will show that this distro is not made for ease of use but for geeks. So, yeah, it's somehow representative and I might avoid a distro with that mindset, hence not install it due to its installer, yes. Even if it's only an one-off thing. Yes.

[Anvil]

That's not entirely true.

most of it is, one doesnt need the Dandrif Vivaldi puts out. im more than happy to download & use a Plain Chromium browser, if i want more i'll just play around in chromium://flags