Available Firstboot clients

[dgdavid]

Context

Going through the example included in SLES (see #115).

According to the documentation [1], YaST Firstboot allows determining the workflow for the final personalization steps that involve end-user interaction in a customized preinstallation. To achieve it, it is possible to

• Configure various aspects of firstboot (such as release notes, scripts, and license actions) in /etc/sysconfig/firstboot
• Configure the installation workflow by enabling or disabling components or adding custom ones by properly creating/editing the Firstboot control file (/etc/YaST2/firstboot.xml)

Problem

However, it is only mentioned that those components must be placed in /usr/share/YaST/clients, but there is no reference about what are the requirements that must be accomplished to be able to run as a Firstboot client.

Is out there any list of valid Firsboot clients? Are all (/usr/share/YaST/)clients valid? Only those that are prefixed with firstboot_ or inst_?

Looks like the answer to all these questions is No.

Let's see some examples.

• Using the dns.rb client: it works!

   <module>
     <label>DNS</label>
     <enabled config:type="boolean">true</enabled>
     <name>dns</name>
   </module>

  

• Using the firewall.rb client: it crash

    <module>
      <label>Firewall</label>
      <enabled config:type="boolean">true</enabled>
      <name>firewall</name>
    </module>

  

• Using the firewall_proposal.rbclient: it complains & crash

    <module>
      <label>Firewall</label>
      <enabled config:type="boolean">true</enabled>
      <name>firewall_proposal</name>
    </module>

  Client complain	Client crash

• Using the inst_product_selector.rb client: it does not crash but it does not make sense at all (like inst_bootloader, inst_proposal, etc)

  <module>
    <label>Product selection</label>
    <enabled config:type="boolean">true</enabled>
    <name>inst_product_selector</name>
  </module>

  

• Using the inst_complex_welcome.rb client: it crash

• Using the inst_congratulate.rb client: it works

Suggested solutions / Ideas

• To provide a list of available Firstboot clients (problem: difficult to maintain up-to-date)

• To have a tool to validate the workflow/clients in the firstboot.xml control file (dream)

  I.e., something similar to the check-profile added to AutoYaST when modernizing it that could run a sandboxed firstboot with the given profile to check that everything works.

• To have a tool for asking if a client is a valid Firstboot client (dream)

  After giving an answer to the above question, what are the requirements that must be accomplished to be able to run as a Firstboot client?

• To ignore not valid Firstboot clients, instead of crashing (problem: they'll appear in the steps column anyway)

---

[1] Available documentation at the time of writing

• https://en.opensuse.org/YaST_Firstboot, quite outdated; there are references to .ycp files
• https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-deployment-firstboot.html
• https://github.com/yast/yast-installation/blob/master/doc/control-file.md
• https://github.com/yast/yast-firstboot/blob/master/doc/installer_and_firstboot.md, the @joseivanlopez's research done in Jun 2020.

[ancorgs]

I think I would just have dedicated Firstboot clients (either all living under /usr/share/YaST/clients/firstboot or all named firstboot_xyz.rb).

Being honest, there are very few clients that are really well thought and designed to be executed both in Firstboot and during installation/standalone without any change. They are either Firstboot-specific or they work by pure luck. So I would make all that more explicit really having dedicated Firstboot clients.

Even in cases in which is really expected that a client can be run both during installation and Firstboot without a single change, having it duplicated would still be reasonable. After all, a sane client should contain only two or three lines of code. Isn't it?

require "y2this_module/clients/whatever"
Y2ThisModule::Clients::Whatever.new.run

[joseivanlopez]

One idea came to my mind (dream). What about having a firstboot configuration UI? Now, the admin has to do some manual work to prepare a firstboot:

• Install first-boot package (well, this is difficult to avoid).
• Edit firstboot.xml to customize it.
• Activate firstboot by creating /var/lib/YaST2/reconfig_system file.

Even though these steps are documented, the customization of the default firstboot.xml is not that easy. As @dgdavid commented, which clients are available? What packages do I need to install in order to have some clients?

Maybe YaST might do it easier. Imagine that yast2-firstboot can be executed in a running system in order to configure a firstboot, and it would allow to:

• Select whether firstboot should be started on the next boot.
• Select the clients to execute (and their order).
• Discover new clients (and propose to install the required packages).
• Configure default values for each client.
• And maybe to configure the look&feel.

[jreidinger]

I think currently it is clients in example is adapted for firstboot and openqa really validate it as it is. So it goes thrue example and configure first boot as test.

[jreidinger]

@joseivanlopez problem with having runtime client is that usually that is not use case for first boot. Use case is having autoyast profile that deploy machine in lab env and then user of given machine do customization in place like root user account or network. So it is often about adapting autoyast profile to run firstboot during first boot.

[wfeldt]

Discover new clients (and propose to install the required packages).

That would assume that we know...

Judging from the few firstboot modules I've see in detail I would say there's not much reason to have separate firstboot and regular versions. The differences that exist could be handled with if Stage.firstboot - much like the dozen other Stage.foo and Mode.bar we have. There's already a number of clients that go that way and consist just of the identical two-line stub Ancor mentioned above, repeated under different client names.

Ivans idea would be a way, particularly as currently people naive enough to run yast firstboot are presented with the very helpful popup No workflow defined for this installation mode. - which basically makes a point on how elite you have to be before you are allowed to use yast in productive ways.

But we might do even simpler things, like:

• a client that's not suitable as firstboot client might just say so (with a popup)
• yast firstboot [--]help might show some info
• yast firstboot [--]list might list firstboot modules
• man yast firstboot might show some information
• while we're at it: man yast MODULE might have some content

Why are we making it so hard for admins used to Unix-like systems to find their way?