If you’ve ever needed to install Fedora Linux on a headless server, a Raspberry Pi, or any machine without a monitor attached, you’ve probably reached for VNC or RDP. They work – but as the installer moves to a web-based interface, there’s a new opportunity to do something more native to that model. We’re building it, and we want your input before we go too far down a path that’s hard to reverse. Why This Is Happening The Anaconda installer’s Web UI first landed in Fedora Linux 42 Workstation and was extended to all Live spins in Fedora Linux 43.…
Read More
1 Like
I made also earlier a poc - feel free to digg and gather ideas from it.
Zoltan
1 Like
How do we find the source code please?
1 Like
There are links to github repos in the Fedora Magazine documents mentioned in this thread: https://github.com/bruno-fs.
Right, but my question was in reply to @zoltanh721 .
1 Like
This could be very useful, but more so if it can work with tablets. Before retiring, I found it hard to find space for a laptop when visiting user cubicles or break rooms. At home, an ipad (with termius and cockpit) is often more useful than a laptop for quick checks on desktop system status.
TY! I will definitely explore it!
I almost suggested in the article phones could be used to control the installation, but I never personally tried that. Cockpit (and patternfly the underlying patternfly widgets) are responsive. I personally think only the storage configuration might be tricky.
A tablet might work just fine, though!
1 Like
This specific PoC you can find in this PR: [do not merge] PoC for remote installation support by bruno-fs · Pull Request #1274 · rhinstaller/anaconda-webui · GitHub
oh, right! I’d love to see Zoltan’s source too.
But here’s a question we’re genuinely considering: should we ship a lightweight boot ISO without a local browser, with remote installation enabled by default?
Hmm, has Anaconda become so heavy that it requires two machines to run? One for web server, private dbus, web server to dbus bridge, python instances and the other one for web browser, javascript app?
It is an achievement to require 6 gb of memory for an installer which would probably work just fine in a terminal.
Maybe Anaconda should learn to fly and join the Hummingbird initiative?
Those 6 Gb come out of nowhere. The article does explain the reasons for remote installation quite well.
The ability to install the system over RDP and VNC existed for quite some time, and is used by many. Now WebUi allows us to significantly reduce the requirements for this use case, and have all the expected features (like copy-paste) work much easier than it is done with the remote desktop tools.
And of course the text mode, and kickstart installations for Anaconda, stay no matter the choices and features of the graphical UI.
You need to add much more context and details in your comment, if you’d like to turn this into a meaningful statement.
I installed Linux and FreeBSD to a RPi4 the past few days just writing the image to SD and booting it 
(oS TW and FreeBSD had SSH post-boot)
Vultr VPS with custom ISO installs I think had VNC in their web interface; not sure the specifics, but it seemingly just remote controlled the machine as if I was in front of it (didn’t matter the OS; it displayed GRUB boot, TTY, and installers the same as if bare-metal)
It’s no secret that Anaconda runs sluggish in Fedora WS with the recommended 4 gb .
Going minimal. The opposite of this process tree:
/usr/lib/systemd/systemd --switched-root --system --deserialize=46 rhgb
/usr/libexec/cockpit-ws -p 80 -a 127.0.0.1 --no-tls --local-session=-
/usr/bin/bash /usr/libexec/anaconda/cockpit-coproc-wrapper.sh 127.0.0.1
/usr/bin/python3 /usr/bin/cockpit-bridge
sh -ec echo SSH_AUTH_SOCK=$SSH_AUTH_SOCK; read a
/usr/bin/python3
/usr/lib/systemd/systemd --user
python3 -m pyanaconda.modules.boss
python3 -m pyanaconda.modules.services
python3 -m pyanaconda.modules.security
python3 -m pyanaconda.modules.runtime
python3 -m pyanaconda.modules.users
python3 -m pyanaconda.modules.payloads
python3 -m pyanaconda.modules.storage
python3 -m pyanaconda.modules.localization
python3 -m pyanaconda.modules.timezone
python3 -m pyanaconda.modules.network
/usr/bin/bash /usr/bin/liveinst
/usr/bin/bash /usr/bin/liveinst
/usr/bin/bash /usr/libexec/anaconda/webui-desktop -t live
/usr/lib64/firefox/firefox --new-instance --profile /run/user/1000/anaconda/firefox-profile http://127.0.0.1/cockpit/@localhost/anaconda-webui/index.html
...
/usr/bin/python3 /sbin/anaconda --liveinst --graphical
dbus-daemon --print-address --syslog --config-file=/usr/share/anaconda/dbus/anaconda-bus.conf
The only thing this list of processes shows is that Anaconda devs did a good job in the last years on making the backend more modular, and systemd does good job in visualizing it.
So yes, instead of one process called “anaconda” you see components which are involved in the installation process. These components are not new, the fact that you see them listed as modules is new.
The main resource requirements on the installation process do not come from Anaconda. they come from two places:
-
The package installation which Anaconda needs to trigger. Package manager needs quite a lot of resources especially when it deals with large list of packages for the initial installation and not just a couple of updates as in regular post-install workflows.
-
Graphical environment. WebUI or GTK UI - there is no big difference here, it is the need to show the UI locally on the system which bumps the resource requirements as we need to run a whole desktop to be able to show a UI at all. We try to reduce this dependency by using GNOME Kiosk instead of full GNOME Shell, but it is still quite a lot.
Remote installation solves that second part. Unlike RDP and VNC approach to remote installation, which adds couple of layers of complexity on top of the full local installation environment, installation over web removes the unnecessary layers, the need to deal with things like passing complex shortcuts to the remote desktop, copy-paste, keyboard layout switch.., and makes the whole process simple.
2 Likes
Of course if the installer is running from a live desktop session, then the graphical components are provided by the desktop.
But for the non-live use case, could a slimmer Everything ISO be made which supports only text-mode (and kickstart) installation, so doesn’t have to bundle the graphical components?
I think this is the question where we would need a community input.
I recently tried to map various installation configurations which we have in Fedora, and got something like this.
So we have several classes of iso images: Live, Atomic, boot.iso and DVD.iso, but all of them have text mode, kickstart mode and the graphical mode included.
We don’t want to make even more iso images, but replacing some of the existing images with a “slim” remote-only version might be good.
But then which one?
Everything iso is by definition, everything 
so I am not sure removing some feature from the Everything iso is aligned with its purpose.
But maybe we can do a remote-only Fedora Server?
Well - it’s meant to be able to install everything, by pulling it from the network 
A purely text-mode installer could provide all the same functionality.
Remote-only would be interesting. But the use case I was thinking of was just “boot your desktop/laptop into the installer USB, and do a custom Fedora installation pulling packages from the internet”. It would be nice to have a smaller ISO that can do all that in text mode, without all the machinery to provide a browser-based GUI.
1 Like
The Fedora WS live payload installs through rsync, not a package manager.
It’s the combination of GUI and web browser which causes the memory pressure. Remove one of them and there is enough memory left.
It doesn’t. Search Ask Fedora for wifi not working.
I was talking about boot.iso installations not Live.
For the Live image your target environment is the same as the installation environment. Trying to optimize the installation environment to use less resources doesn’t help here, because if you don’t have enough resources to run a DE and a browser on the target environment, there is no point installing it.
The boot.iso is used to install a custom system on a custom target, and here it becomes critical when installer uses more resources than the workload which it is supposed to install.
This does happen currently. I may want to run nothing but a static web page on my tiny home lab server, but I have to run entire desktop environment and dnf to get that homelab setup. And here remote web installation can help, because it removes that overhead. The dnf part still will be a problem in that case, but it can be improved with bootc.
You do need to put some effort in your arguments.
1 Like