A new (and easy) way to access yast settings

[wfeldt]

Jira links for reference

• epic jsc#SLE-16263
• dev jsc#PM-1895

Note to non-SUSE readers: links in this document are only for reference, they don't contain information not mentioned in the text below.

Collected use cases

Here's an overview of the use cases that have been brought up:

• hidpi setting (bsc#1173451)
• (brief) summary of current network settings (bsc#1168487)
• control registration (SCC) settings, like access to update repos
  (bsc#1168490) - and keep these settings for target system
• proxy/authentication settings (bsc#1168495, jsc#PM-2272), also an option to copy these settings to target systen
• view self-update/driver update state
• present extra features (e.g. security roles (jsc#PM-1245))
• 'allow vendor change' state for repository

What is possibly doable

This is just a collection of ideas. It doesn't imply all of them have to be implemented.

1. A link on the first installer page or a separate first page to edit global settings

That could offer control over all kinds of settings that are not directly exposed currently. Like

• repository URL
• autoupgrade
• update vs. normal install
• selfupdate state
• driver update state
• network config
• proxy

Or for things that can't always be autodetected correctly or where the user simply prefers something else

• hidpi

Generally everything from a hypothetical yast.conf (see later).
Changing might involve a restart.
Some things might be read-only (e.g. a network overview).

2. A link on each page to hide additional settings

Much like a 'more' button, or think of the 3 dots on Android.
Maybe not on each page but (say) on the client's main page.

That could offer context related settings that are not always needed. Like

• whether or not to use updates (on the registration page)
• extra security roles (on the roles page?)

If changing a setting in a later stage requires a yast restart, things might get tricky or simply annoy the user too much.

3. A way to store (and keep) settings

It would be a good opportunity to introduce a yast config file to read and store settings. E.g. [/usr]/etc/yast.conf + [/usr]/etc/yast.d.

• it's a central place, settings can easily be copied
• linuxrc could use it instead of install.inf
• it could make weird things like touch /var/lib/YaST2/reconfig_system redundant in the long run
• you could store convenience settings; e.g. turn off the partitioner's 'continue despite this warning' dialog
• it's very helpful to be able to override settings for debugging, e.g. architecture
• it could consolidate the various ways to influence yast
• it can be documented with a man-page (and people know where to look for it)

The config file format should be human-readable (like YAML, not XML).

Maybe: allow environment variables to override config entries in a systematic, predictable way - e.g. based on the keys in the YAML file. For example given a hypothetical yast.conf fragment with

---
arch: s390x
debug: false

install:
  hidpi: false
  repourl: http://example.com/foo
  textmode: true
  update: false

Allow YAST_ARCH=aarch64 YAST_INSTALL_HIDPI=true to change arch and hidpi settings.

[ancorgs]

About (3), it's indeed hard to believe we have not such central place to store configuration yet.

[lslezak]

The question is if some settings would make sense also later (in a running system) or should we consider these settings only for installation.

BTW we have some configuration files, like /etc/sysconfig/yast2 or /etc/YaST2/ProductFeatures.

[wfeldt]

The question is if some settings would make sense also later (in a running system) or should we consider these settings only for installation.

The config file at least would also be for later.

BTW we have some configuration files, like /etc/sysconfig/yast2 or /etc/YaST2/ProductFeatures.

Sure, and also firstboot has its config files. It's just not a single place and it's not really the place people would expect. So why not consolidate into a single place like other programs have? We even have the infrastructure in place to deal with this kind of config files.

[kobliha]

Config could be also used for exporting the system AY profile later. E.g, we would know if we should export all or the minimal profile. What to do with system users, etc.

[shundhammer]

More use cases:

• Switching to the "vision impaired" palette
• Collecting y2logs
• Enabling / disabling y2debug for logging

Those operations are currently accessible with key combinations that most users don't know. We might want to make that more easily discoverable.