Skip to content

New Installer: SLE12 Installer Workflow

Jump to bottom Edit New page
Ladislav Slezák edited this page Oct 16, 2013 · 1 revision

SLE12 Installation Workflow (§1)

(This is only about Installation. Update workflow still needs to be defined, see the update section.)

The current installer is limited and we have many tools doing the same but using different technology.

The main reasons for this change are:

  1. Installer should not be installed in the target system (to require as small space as possible)
    • Use standard languages/libraries/tools which are in minimal system (JeOS, "minimal system" pattern) if possible
    • It is not possible to install part of the installer, use it for writing the configuration and remove it after the work is done. This cannot be done because of disk space issues (zypper and bootloader are fine, they are needed anyway, YaST must not be required in the target system).
  2. Installation workflow is too complex, although it presents good defaults for most users. Many users just press Next, Next,...
    • Minimal, basic installations for all
    • Extra features only for those who want it (and not need automatic configurations)
  3. Currently, registration happens after installation. We should first register, see the list of available products (add-ons) and select them for installation.

There will be just one stage installation. All configuration needs to be done before reboot. After reboot, the machine should be fully functional in a way, that the admin can login locally or remotely, start the control center (YaST or what ever else) and configure the remaining missing pieces like user administration, printer, ...

The control center can be something completely different to the installer (example: YaST2 ncurses/qt for installation, WebYaST/SUSE Manager for configuration/administration/maintenance).

Note: We could have a hidden 2nd stage for something needed to be configured after reboot. It is acceptable as long as it is non-interactive and does not add many large dependencies. Ideally it should be just a simple script. But this should be used as the very last option.

Installation Process Consists of 5 Major Steps (§2)

Every single step should be self-contained and "communicate" with the next step via a configuration file. Goal is to be able to exchange the tool for a single step by another one (example: use the same installation wizard workflow for studio and SLES, but Studio is web based, SLES installation workflow not. Or to use the current YaST2 code until we have something else ready).

Note: There are several options for the file format. XML, JSON, YAML, ... we need to check which format fits the task the best. Take file handling (manually, only machine-readable, ...), data format and other variables into consideration. Think also of support in various tools and programming languages.

One possible option is also to reuse the current AutoYaST XML profile.

The Major Installation Steps

  1. Boot new machine
  2. Installation Wizard (optional workflow step)
  3. Deployment
  4. Apply Config
  5. Firstboot (optional)

Any of these steps can be replaced by completely different implementation (even 3rd party tool which is not present on the installation medium - it can be added via, e.g., DUD). Replacing any step might require repeated initialization (e.g. HW detection). That's acceptable and using standard full installation (running in a single process) should not be affected by this.

There are no real use cases for replacing any step yet, but we want to offer flexibility. Users can use a different GUI for creating configuration, edit the file by hand, or it can be created by other projects like Studio or System Manifest. We do not want to limit users to just one single tool.

Needs to be Usable on (§2.1)

  • local console (§2.1.1)

  • serial console (this is necessary since for security reasons not every machine is allowed to be connected to a network, but you don't want to go into the server room every time, too. SUSE itself has such machines because of CC certification). (§2.1.2)

  • remote (network, too slow for X11) (§2.1.3)

  • Remote graphical client usable also in Windows (currently VNC, could be something web based instead) (§2.1.4)

  • with 512MB of RAM (§2.1.5)

    Swap space is not a hard requirement for kernel, it is just recommended. System should work properly even without any swap space if there is enough RAM. There is a [swap knowledgebase article] (https://www.suse.com/support/kb/doc.php?id=7010157) regarding this problem.

Note: 512MB RAM can be a problem, without second stage we need complete installer in RAM. That will very likely be a problem for web based installation, but web based installation is optional. (Maybe we could, e.g., use VNC installation via flash client, like in Studio test drive or noVNC http://kanaka.github.com/noVNC/noVNC/vnc.html)

Tested openSUSE-12.3 DVD and NET installation (x86_64, using Qt GUI), the memory usage in the installation proposal was about 130MB in both cases. But a swap will be required, the installation later failed (OOM killer killed y2base) when there was no swap.

  • Compatible with DUDs/Add-Ons during whole product lifetime (§2.1.6).

    An add-on developed for GM should be possible to install also in SP1, SP2... The installer cannot be changed in SP1 to not support GM add-ons. Do not break compatibility (like add-on metadata) during product lifetime. It is not about package update problems caused by changed dependencies, this we cannot predict.

Other Requirements (§2.2)

  • Installer does not need any code inside of the installed system to configure it, everything is running out of the inst-sys. (§2.2.1)

    Using the base functionality of the system is possible, e.g. chroot && mkinitrd. The base functionality is everything that is always installed (i.e. Minimal system pattern). It is possible to install additional tools but only those really necessary and as small as possible.

    (Note: The snapper library cannot be used from inst-sys and needs a small modification, maybe there are more cases like this.)

  • No data/files from the inst-sys are copied to the installed system, especially no network configuration or passwd/group files. (§2.2.2)

    All config changes have to be applied to the installed config files. Creating config files in inst-sys (during installation, based on entered data) and copying these is possible. Just do not copy those present in the initial inst-sys.

    Libzypp cache can be copied, but only for present and enabled repositories by default. In most cases, the cache will be created anyway at some time (e.g. when installing updates), so it won’t be an issue. It should be also possible to optionally not copy the cache to save some space if needed (make it configurable).

    SSH installation needs to copy the SSH keys always. We actually already offer a way (configurable in control.xml) to select the files that should be copied to the target system. See Installation in General, especially chapters 1.1.3.5. Installation helpers and 1.1.3.6. Importing Files from Previous Installation.

  • Adding Add-Ons later in running system should look like installing Add-Ons during installation. Means same behavior/options including Roles, Patterns, RPMs, ... (§2.2.3)

    If Add-on module is installed in the target system it should work and have the same features as the Add-on module in the installer. This means that the Add-on module can be optionally installed into the target system (probably with some parts of the installer).

  • SCC should either send only this Add-Ons customer has paid for and is able to install, or all existing Add-Ons, with tag for every Add-On if installable or not. (§2.2.4)

Summary: Registration will be part of the configuration workflow, it will send all add-ons available for installation (not only updates as the current NCC).

Open Question: Should be Applying Updates part of the workflow? Can we even do that in first stage?

  • DUD process (§2.2.5)

  • Autoinstallation should work with the same config files and use the same workflow, but needs to be adapted by autoinstall experts. If the config is not compatible with SLE11, we need a converter. (§2.2.6)

    The new installer will support also semi-auto installation - it will ask for missing mandatory information (see later).

Note: Conversion is not possible for all cases. E.g. autoyast config can contain scripts that convert the config. The converter probably cannot support all cases, manual adaptation might be needed in some cases.

  • It's always possible to read the release-notes, the original ones until we have downloaded the new ones, only the new ones afterwards. Should be a button next to the help button, if available. (§2.2.7)

    Download the latest release notes as soon as possible (during the Wizard). They can be read also during Deployment. The release notes should be downloaded them from the SUSE web site, not from an update channel, these are the latest by definition.

  • We need an user management option, which is at least able to create local user accounts (especially needed for openSUSE). (§2.2.8)

  • "Self Patching/Updating" The installer should be able to update itself before installing a product. DUD: be able to replace everything, be able to add everything (§2.2.9)

  • Optional: Install server, which provides installation sources and the config files for a special machine. This can depend on hardware specifics, like MAC address, BIOS, etc, but also depending on number of harddisks, disk space, RAM, CPU, ... (§2.2.10)

Open Problems (§2.3)

  • Communication with SCC, how to make sure we tell customer which add-ons he can use, and how to tell SCC, which customer really did install, so that we can increase the use count and check if free licenses are available.
  • Firewall already during installation or only in installed system? If during installation, which ports do we need to open? => According to Marcus Meissner, security team is fine without firewall since there shouldn't be any open ports besides the one explicit start for remote installation.
  • Firewall/ssh:
    • Product default is defined by the product manager and is stored in the product control.xml. (This is the same as the current solution.)
    • how to change the default: during installation or only in "control center"? For ssh: needs to be open during installation to allow remote administration.
  • How far do we need to support SLE10 or SLE11 YaST modules on SLE12?
  • Proxy configuration (where, when)

No Longer Supported During Installation (§2.4)

  • Full blown user management including LDAP, NIS, AD, ... (if we get something of this for free, fine, but we will not make investments into this).
  • CA management
  • LDAP setup
  • CIM setup (maybe pattern/role based?)
  • "Remote Administration" -> this hack shouldn't be necessary anymore, "control center" should provide this functionality by default.
  • Test Internet (hack because we are not able to start the whole network during second stage and guess the right interface, not needed at lest on SLE anymore, openSUSE?)
  • user authentication (NIS, LDAP, AD). Needs to be configured in control center afterwards. No big change as of today, where it is in the second stage, excepts the admin can start the right module from the beginning does not need to click through a lot of pages.
  • Extra release notes screen
  • Extra hardware config screen is removed, while X11 and sound should be (still) autoconfigured if possible (and needed), printer can be configured in control center later if available.

Summary: X11 is no longer configured by YaST, sound configuration should not be needed and could be removed from the installer. (Optionally the sound can be configured from installed system.) The interactive configuration proposals should be removed, but we can still write some configs (via auto-config).

  1. Boot New Machine (§3) ========================

Boot Workflow

                              />  DVD -> isolinux (or similar) \
BIOS/libvirt -> (secure boot) ->  USB /                        -> Boot kernel/initrd/linuxrc -> Fetch config
                              \>  PXE -> PXE Boot Menu        /

Boot Media

  • DVD
  • USB
  • PXE
  • libvirt

DUD and PLDP needs to be supported.

Boot Menu

Choose from:

  • Boot Harddisk
  • Product Installation
  • Product Update (optional)
  • Rescue System
  • ...

Choose from should be configurable if delivered with a product/appliance (§3.2). The menu is present on the installation media, there is no requirement for a new technology here, the current solution is sufficient.

Other Requirements

  • It would be nice to have an Universal Mini-ISO, it may not match the installed product. The kernel of the Mini-ISO must fit to the inst-sys, but does not need to fit to the product. We have that already today (inst-sys has default kernel, while installed system has an optimized kernel). (§3.1)

  • The configuration file should be XML and contain: (§3.3)

    Note: Not only XML but also JSON might be an option. JSON can be sometimes better understandable comparing to XML which is mostly machine-readable only. Also YAML is an option but does not seem to be good enough especially because of escaping and whitespace issues. This is worth some research (and summary) though. (See http://yaml.org/spec/1.2/spec.html#id2759572 for comparison YAML with JSON and XML.)

    One possible option is also to reuse the current AutoYaST XML profile

    • ssh/vnc/web/...
    • network configuration
    • product source
    • autoinstall
    • autoupdate
    • installation
    • update

    See configuration file details

  • linuxrc gets the inst-sys and looks, if there is a config available for this machine. (§3.4)

    • no translations
    • shouldn't be visible if possible at all
    • optionally be able to communicate with install-server to get correct config. install server can be found via local config file, SLP, DNS, command line, ... (installation server is optional so network discovery is not always needed ).
  1. Installation Wizard (optional step) (§4) ===========================================

  • Installation wizard

    • Uses given config (nothing is displayed if not needed, like Autoyast today). But if a mandatory data is missing there will be a dialog for it displayed.
    • Or creates a new config interactively

    See configuration file details

  • Installation workflow inside the installation wizard is configurable like today with xml config file.

There are more possibilities how to ask for missing values:

  • Ask only for the missing values
  • Ask for all values, prefill the configured values

(Note: Pay attention to the dependencies between steps.)

The installer can stop the installation after finishing the configuration wizard and just save the configuration file for later use. It can be used as a GUI for creating the config for later automatic installation.

(Note: It would be nice to support running the installation wizard separately, without knowledge of the target hardware, but it is not required.)

Roles

A role is a software collection (usually a pattern) with additional configuration module. It defines what needs to be installed and what is needed for configuration. Roles can add a new workflow dialogs and add packages to FirstBoot. Not precisely defined yet.

The roles are defined by products and add-ons (so the product managers are responsible for them).

Task for Installer group is to define the role description format. For updating roles define dependencies (like for patterns) and versions. Update then means that the selected role is already installed in the system.

Hierarchy of Products, Roles, Patterns and RPMs

  • Products can contain Roles, Patterns, RPMs
  • Products can modify installation workflow
  • Roles can require Patterns and RPMs
  • Patterns can require RPMs

Note: Better do not handle products in Roles, concentrate on patterns/packages dependencies. Technically, we usually need to require specific package/pattern versions anyway.

Workflow:

  1. Step

    • Try to start DHCP on all network interfaces as soon as possible. (Don't try to find out which is the correct one, DHCP on all interfaces should configure routing/gateways correctly). If DHCP configuration fails, user can configure network from UI (and use static setup if needed).

      Editing the host name is usually needed by SLES users, but it could be hidden by default. (Discuss with UX people.)

      (Note: The network solution is not decided yet, so wireless setup support is still not clear.)

      (Note: The proxy configuration is still unclear, it can be needed in almost all installation steps (DUD, SCC, installation repositories))

    • Language (prefill with GeoIP value)

    • Keyboard (prefill with GeoIP value) (first language or keyboard?)

    • EULA

  2. Step (as of today)
  • Media Check (triggered by flag in iso image)
  1. Step
  • Download current release notes.
  • From now on, we should have a button "release notes" next to "help", which shows the current release notes. If no new one was downloaded or no network available, use the original ones
  • Root Password
  • Hostname (prefilled from DHCP)
  • Time zone/clock (preselect from location detected via local IP, GeoIP?)
  • NTP (preselect from location detection via local IP)
  • Button "Configure Network"

Question: What about displaying the button earlier? The steps before require assigned IP, what if there is only WLAN device which is not configured yet? Network should be probably configured sooner... [Added to open questions]

  • Network => Depends on "Network Virtual Team" Required interfaces:
    • Network Interfaces (eth, biosdevname, bridging, vlan, ...)
    • UMTS
    • WLAN
    • VPN Optional/not decided/unlikely:
    • DSL (open for discussion)
    • ISDN (do we still need that? We have customers, see current L3s).
    • modem (maybe preload, else not needed)

    Note: Modem should be removed, even POS doesn't use it (checked with POS team).

  1. Step (only if network is available or if we can verify reg.codes without network)
  • Registration (like today in second stage/adjusted for SCC, ...)
  1. Step
  • Roles (extended via templates gotten from media, during registration via SCC or by registration of Add-Ons online or by media). Examples:
    • SLES: physical, virtualized, ...
    • SLED: GNOME, KDE, ...
    • openSUSE: KDE, GNOME, ...
  • Add-Ons: Available Add-Ons gotten during registration will be shown for usage, additional add-ons can be registered via media or network installation source.

Add-Ons can provide additional Roles. This Roles will be shown here, if customer can install the add-on. If such a Role will be selected, Add-On will automatically be selected, too. 6. Step

  • Disk Activation (optional, mandatory only if no disk present or S/390) (Note: Disk activation might be also needed in the deployment step in autoinstallation.)
  • Storage/Partitioning
  • Software ("patterns", single package selection)
  • Runlevel (if runlevel 5, autoconfigure X11)
  • kdump (optional)
  • bootloader
  1. Step Deployment, show package installation progress, release-notes, optional slide show. release notes must be viewable even if no slide show is installed.
  2. Finish screen
  • Apply config
  • Create autoinstall profile
  • The final installation proposal should display only items that were not configured before (e.g. because of good proposal for certain component, that usually do not need to be edited). This means: bootloader, software selection, runlevel

In case of auto installation, when there is no information missing, proposal should be skipped. (This is the default behavior of current autoYaST as well.)

  1. Deployment (step 7 above) (§5) =================================
  • Use the configuration file to deploy, check if all mandatory values are there, abort the installation if something is missing
  • Setup and partition storage (hard disk, mulitpath, FCOE, SAN, ...)
  • Do the deployment, one of these:

    • Deploy an image (for example Studio or Kiwi appliance). The goal is to provide a simple way for deploying pre-built images.

      And even for appliances it still makes sense to configure some parts of the system (e.g. the root password) and replace the original configuration. If something must not be changed by the installer it must be set to "do not touch" in the configuration file.

      The set of supported image formats is not specified, we should support at least RAW disk image (including S390 formats). The other formats (VMDK, ISO...) depend on complexity and the tools needed for deploying.

      Studio should be also able to create the installer config file for the built appliance, it should simply tell the installer which parts are already configured and can be skipped.

    • Create filesystem, optionally untar pre-installed images, install RPMs. The images here are tar.xz images with pre-installed RPMs as are currently used in openSUSE.

      For SLE the image functionality will be probably not needed as admins install quite different sets of packages and the images also take some space on the medium. We would likely need to add a new DVD medium which is not acceptable. (The images could be available only online. The base system will be always installed and having an image for that might make sense. Of course the image would have to be up-to-date with new packages available in online update, with new installer it will be possible to install GM or Updated version.)

  1. Apply Config (step 8 above) (§6) ===================================

Write the configuration to the installed system:

  • Write bootloader/config
  • Write network config to image
  • Create user
  • ...

(Note: It seems that applying a config standalone is not needed. Preloads will probably use FirstBoot configuration.)

Reboot

This can be done by hard boot or kexec, but the default should be defined by the product (kexec is not reliable, more over it cannot be used in SecureBoot).

  1. Firstboot (optional) (§7) ============================
  • Let user config things like language, keyboard, ... (like yast2-firstboot)

Priorities (§8)

  • Adapt current YaST installer to new workflow

  • Implement a new system management solution for the running system. The SLE12 Installer virtual team preferred a console based tool with a web based front-end. Unfortunately, this is out of scope due to vast complexity.

  • Use system management technology from the running system for the installer. That means use the solution which is present in the running system, if there is a new solution for System Management, we should try to use it for the installer as well (like a new Web based solution). So far, there is nothing like that defined.

Various things (§9)

  • Do we want SLE to install the latest and greatest or just GA

    • By default: No, but let admin decide (flag in config file, optional front-end if config file allows this)

  • OES initial config does heavy stuff during the 2nd stage.

    • They would need to move to a 1st boot or create their own 2nd stage. (SUSE Manager appliance uses firstboot for configuration.)

Note: These steps are usually added to second stage because Add-ons add their software during first stage, then and we can use the config software after new modules and SCR (and ...) are integrated and YaST restarted. Thus we need to make sure installation can be extended in basically any point of time.

  • What was selected in the interactive installation can be applied after first boot?
    • No, would add modules to minimal system. What about like the Live installer, that uninstall the Live installer?
    • Needs more disk space in the beginning, problem for virtualization. Ask stuff and apply before reboot is valid.

Update

The requirements for update are not yet ready.

There are many questions:

  • SLE11 -> SLE12 update?
  • AutoYaST update?
  • Online migration? Customers like online migration, but it is problematic (e.g. glibc update problems) and practically not possible. Wagon currently solves online migration on service pack level only.
Add a custom footer
Add a custom sidebar
Clone this wiki locally