Announcement

Collapse
No announcement yet.

Fedora Workstation 39 Eyes Switch To Anaconda WebUI For Installations

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Fedora Workstation 39 Eyes Switch To Anaconda WebUI For Installations

    Phoronix: Fedora Workstation 39 Eyes Switch To Anaconda WebUI For Installations

    For the past year and a half Red Hat engineers have been developing a new web-based UI for their Anaconda OS installer and with the Fedora Workstation 39 release later this year they are looking at possibly switching to it by default...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I used to use VNC when (manually) installing on remote systems like Raspberry Pi or a server without a keyboard or monitor connected to it. I'm looking forward to just using my browser now instead of a VNC client.

    Comment


    • #3
      This is not a bad idea. It will make it easy to setup servers and integrate it into cockpit.

      Comment


      • #4
        Quick question to the uninformed. First, I do get how this would work and allow remote installations. But as someone that doesn't manage these kinds of things, how do you initially get the IP address that is assinged to the headless server you are going to install on, so you can point your web browser at that? I assume you could just log onto the router and see what IP address was assigned. But, are there other ways this is done as sort of "standard practice"? Just trying to learn something new.

        Does seem nice, great way to do a remote installs. Btw, I have accessed Cockpit before as well, and same concept. Leverage a lightweight web server as a means to create tools with web tech based UI, allowing for remote access, etc.

        Comment


        • #5
          Wow how exciting. I'm sure that a web interface for a crappy ancient installer will make everyone forget that RedHat and IBM are putting their RHEL sources behind a paywall.

          Reminds me of one of those old Maxwell Smart failed attempts at distraction. Not that anyone here would be old enough to know who Maxwell Smart was.

          Comment


          • #6
            Originally posted by ehansin View Post
            are there other ways this is done as sort of "standard practice"? Just trying to learn something new.
            MDNS would be one way the server could broadcast itself at a friendly URL that resolves to installer machine (or whichever responds first if there is multiple). Compatibility varies, usually it's a `.local` domain with only a single DNS label before that like `home.local` while Linux can be configured to be allow more like `installer.polarathene.local`, you need client support for that and I know Android wasn't compatible with three labels. IIRC your hostname (without `.local`) can be setup to direct to your machine without knowing the IP, pretty sure that was via MDNS too. Some users misuse `.local` for their own self-hosted DNS instead of MDNS which it is reserved for, there's also something with Microsoft product (Active Directory I think?) that commonly was configured to misuse `.local` that way too.

            I think I've seen a few "smart" IoT devices using mdns or UPnP to connect and configure via browser or app. Phillips HUE bulbs use an app that communicates over protocol like Zigbee while others use bluetooth or some others that I forget (this was when I had a role in 2016 working with many IoT devices and a smart hub product/service).

            Another option is for the machine itself to be an Access Point, and you connect to that where it manages regular DNS. I've seen this in routers with the ISP providing a mobile phone app sometimes instead of the user typing in the routers IP (sadly the browser address wouldn't allow admin access and insisted you setup via the phone app...).

            Comment


            • #7
              Originally posted by andyprough View Post
              Wow how exciting. I'm sure that a web interface for a crappy ancient installer will make everyone forget that RedHat and IBM are putting their RHEL sources behind a paywall.
              That's not relevant to Fedora though? And this WebUI has been in the works for quite a while.

              I have no interest in RHEL myself, and I'm aware of the relation to Fedora but doubt they'd being pulling off the same stunt there.

              Comment


              • #8
                i didnt think they'd use this till Fedora40 at least

                I am in favor of giving the web UI a shot, but I do think this is a pretty aggressive timeline given the amount of fairly large issues that remain to be resolved, especially exactly how the 'choose-your-own- partitioning' workflow is going to run (considering the stuff we discussed about constraints around partition size and boot partition requirements and disk label type requirements and so on). I think we need to be really ready, in advance, to pull the contingency lever for this one if it seems necessary. It should be fairly safe to do, since we'll still be testing the existing UI on other images, including the KDE live. Naming nitpicks: I'm pretty sure the existing non-custom partitioning flow is formally called "guided partitioning", so calling a new slightly-more-customizable-one "guided partitioning" and retroactively renaming the existing one "automatic partitioning" might be a bit confusing, at least to old-timers. Also, I still think of the existing UI as 'newUI', so I'm gonna keep calling this one 'webUI'.
                i tend to agree with what AdamW said above
                Last edited by Anvil; 26 June 2023, 09:52 PM.

                Comment


                • #9
                  Originally posted by polarathene View Post

                  MDNS would be one way the server could broadcast itself at a friendly URL that resolves to installer machine (or whichever responds first if there is multiple). Compatibility varies, usually it's a `.local` domain with only a single DNS label before that like `home.local` while Linux can be configured to be allow more like `installer.polarathene.local`, you need client support for that and I know Android wasn't compatible with three labels. IIRC your hostname (without `.local`) can be setup to direct to your machine without knowing the IP, pretty sure that was via MDNS too. Some users misuse `.local` for their own self-hosted DNS instead of MDNS which it is reserved for, there's also something with Microsoft product (Active Directory I think?) that commonly was configured to misuse `.local` that way too.

                  I think I've seen a few "smart" IoT devices using mdns or UPnP to connect and configure via browser or app. Phillips HUE bulbs use an app that communicates over protocol like Zigbee while others use bluetooth or some others that I forget (this was when I had a role in 2016 working with many IoT devices and a smart hub product/service).

                  Another option is for the machine itself to be an Access Point, and you connect to that where it manages regular DNS. I've seen this in routers with the ISP providing a mobile phone app sometimes instead of the user typing in the routers IP (sadly the browser address wouldn't allow admin access and insisted you setup via the phone app...).
                  Thank you for taking the time to fill me in on all of this! Makes a lot of sense, just never really dug in to learn the underlying mechanics. In the last year or so we got an iXsystems TrueNAS Mini at work for ZFS file storage. If you don't know the IP address, you just point your browser to "truenas.local" (the default - can be changed) while on the local subnet. Kind of forgot about this until after reading this, so cool to understand better. Thanks again.

                  Comment

                  Working...
                  X