-
Notifications
You must be signed in to change notification settings - Fork 44
New Installer: System Config File
Here you can find (not yet) all pieces of information that are needed by the installer to be able to install a system, all apply to:
- Manual Installation
- Automatic / semi-automatic installation (via external config file)
- System Manifest (via external config file)
- Entry missing
- If optional, use default / proposed value
- If mandatory, ask user
- Entry present
- If marked as "do not touch", current system configuration will be kept intact
- Otherwise use the given value
- root password
- Disk activation (mandatory always for S/390 and if no disk is present on other architectures)
- Whether user accepts EULA and/or package licenses
- registration information (depends on product, if product has reg_URL defined)
- local user (depending on product control, mandatory for openSUSE)
- Roles (can also add software, maybe extend workflow, require and extend FirstBoot, etc.)
- Partitioning, by default, use values from product control file
- Additional repositories to use (e.g. PTF repository)
- Software to install or image to deploy, by default use all available products, except migration and special products
- Fingerprint trust-stuff (trusted keys, fingerprints, ...)
- Add-ons - repositories with products to install
- Locale information (time zone/language/keyboard), by default try to use GeoIP
- Hostname
- NTP
- Network settings (default: all DHCP)
- Firewall config, defaults depend on product control file and also the selected installation method (VNC, SSH, ...)
- Runlevel, by default, product control file (or 5 if not defined)
- Bootloader, by default, use values from product control file
- Services to start (e.g., ssh, apache2, ...)
The Installer will not support all possible configurations, if something is not listed above (Mandatory or Optional) then it's not supported.
AutoYaST XML profile format could be reused as the new installer config file. The advantage would be that the AutoYaST profiles created for SLE11 could be used also as SLE12 installation config files. Users could simply reuse the already existing profiles.
Here is an incomplete example of AutoYaST profile.
It seems that almost all needed config options are already supported by SLE11 AutoYaST. Of course, the new features are missing (like roles or image deployment support). So the AutoYaST XML profile could be easily reused for the new installer config file.
AutoYaST also supports custom scripts which can be executed in specific installation points. For backward compatibility we need to support that also in the new installer.
The custom scripts supported by AutoYaST:
- Preinstallation scripts
- Postinstallation scripts
- Chroot scripts
- Init scripts
- Postpartitioning scripts
All these scripts needs to be executed in the first installation stage the same way as in the old installer. That simply means just to reuse the existing functionality.
New sections will be needed for the new features, but as long as they do not conflict with existing sections there is no problem.
The only problem is to use the same XML schema as defined by AutoYaST, especially for data type attributes or lists. See AutoYaST RNC files for details.
The datatypes should not cause any problems to other tools, the autoyast example
can be loaded in Ruby by simple Hash.from_xml call and the content is loaded
correctly.
If the same XML structure cannot be reused then it should be possible to convert an existing AutoYaST profile by a special tool or via provided XSLT transformation.
The new installer will only have one stage and the first stage will be limited to only the really needed options. That means the old SLE11 AutoYaST file cannot be fully supported.
To support also the additional configurations (like LDAP client, Kerberos client...) the respective modules could be installed into the target system and for AutoYaST case there would be additional second stage installation part which would configure the extra settings not supported by the installer.
(Including the additional modules in the first stage could be also a possible solution, but this would need additional space in the inst-sys image and the needed RAM size would likely exceed the minimal required limit. So merging complete AutoYaST into the new installer is probably not possible because of memory requirements.)