I seem to have missed when the conversation and conversion from /etc/zypp/zypp.conf.
When did this occur and where is this discussion article located at?
There is no longer use of /etc/zypp/zypp.conf to configure zypper behavior then correct? How does this work with older Tumbleweed installations then? It is migrated with a Tumbleweed upgrade?
I did a ls -als /etc/zypp/ and found /etc/zypp/zypp.conf.README
> cat /etc/zypp/zypp.conf.README
The traditional /etc/zypp/zypp.conf configuration data will no longer be read
solely from this single file, but merged according to the rules defined by the
UAPI.6 Configuration Files Specification from:
system configuration: /etc/zypp/zypp.conf[.d/*.conf]
vendor configuration: /usr/etc/zypp/zypp.conf[.d/*.conf]
After this update an unmodified /etc/zypp/zypp.conf will have been be removed
and the system will continue to use the distributed vendor defaults.
A modified /etc/zypp/zypp.conf will stay in place, so the modified settings
still apply. You may nevertheless want to consider to store your changed settings
in a drop-in file in /etc/zypp/zypp.conf.d/*.conf and afterwards remove your
/etc/zypp/zypp.conf.
See the FILES section in ZYPP.CONF(5) to learn more about the two methods of
overriding the vendor provided configuration.
Clear story, my /etc/zypp/zypp.conf is still there so I have changes. Will try to move these changes into other files and maybe study man zypper.conf.
It had to have happened before late January, as I made a mistake in the process then that didn’t surface until this month, and resulted in this thread here just days ago.
I think it’s man zypp.conf because the above man zypper.conf results in error on the machine here.
Another question I have is that I am trying to increase the maximum concurrent connections by adding the following to [main] in /etc/zypp/zypper.conf
download.max_concurrent_connections (8) on line 68, it fails.
:~> sudo zypper dup AugeasException: /etc/zypp/zypper.conf parse_failed: at 68:0: Get did not match entire input *** Augeas exception: No config files read, sticking with defaults. Loading repository data... Reading installed packages... Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. Computing distribution upgrade... Nothing to do.
I would like to know why this fails.
I think we need to see your .conf file.
Ok, please see under [main] that I have since changed the entry to download.max_concurrent_connections key = 8
the zypper.conf file is currently as follows:
## Configuration file for Zypper.
##
## location: /etc/zypp/zypper.conf (system-wide)
## or: $HOME/.zypper.conf (user-specific)
##
## You can edit this file by hand (try to keep the structure) or by using
## 'zypper conf' command (TODO). If you need user-specific configuration
## and you do not have ~/.zypper.conf yet, use /etc/zypp/zypper.conf
## as template (copy it to ~/.zypper.conf) and adjust to your liking.
##
## The options known also to libzypp will be overridden by zypper.conf, if set.
##
## Boolean values are:
## 0 1 yes no on off true false
## Color values:
## Color values are case insensitive and may be prefixed with
## either Bold, Light or Bright to turn on the terminals
## bold/increased intensity attribute:
## Grey Red Green Blue Brown Cyan Purple/Magenta Black
## White (== LightGrey)
## Yellow (== LightBrown)
## Default (== terminals default color)
## Bold, Light, Bright (== LightDefault, terminals default bold color)
[main]
## Show repository alias instead of name.
##
## Alias is an alternative unique name of repository. Some users prefer
## to define short, handy aliases for their repositories and use them
## when specifying repositories instead of number, name, or URI.
## These users might want to set this option to 'true'.
##
## Other users prefer to keep the aliases and names set by installation,
## registration, YaST, or other software managers, or .repo files (most
## software managers even hide the alias from user's view).
## These users might want to see the descriptive names, thus leave this
## option set to 'false'.
##
## Setting this option to 'true' will tell zypper to show repository
## alias instead of the long name wherever it needs to tell the name of
## the repository.
##
## Valid values: true, false
## Default value: false
##
# showAlias = false
## Columns to show in repository list printed by repos (lr) command by default.
##
## The # (number) and Enabled column is shown always. The following columns
## can be configured:
##
## a - alias - the shorthand for name and unique identifier
## n - name - full name of the repository
## r - autorefresh?
## k - keep-packages?
## u - URL
## p - priority
##
## Valid values: any combination of the above letters; capital letter marks
## column by which the table will be sorted (if multiple
## are used the sorting is undefined).
## Default value: Anr
##
# repoListColumns = Anr
download.max_concurrent_connections key = 8
[solver]
## Commands in which to force resolution.
##
## Comma-separated list of commands in which the resolution should be forced
## when solving package dependencies. This means the solver
## will automatically opt to remove problematic packages instead
## of asking the user how to resolve the dependency problem.
##
## This is particularly useful in the 'remove' command, since one
## typically wants to remove the requested package and all the packages
## which depend on it, without being asked. But one may find it convenient
## to force the resolution also in the 'install' command, or perhaps even
## others.
##
## This setting can be overridden ad-hoc by the --force-resolution and
## --no-force-resolution command line options.
##
## Valid values: remove, install, update, patch, verify
## Default value: remove
# forceResolutionCommands = remove
[commit]
## Automatically say 'yes' at third party license confirmation prompts.
##
## Happy-go-lucky automated deployments.
##
## Valid values: boolean
## Default value: no
##
# autoAgreeWithLicenses = no
## Post commit check for processes/services using old/deleted files
##
## Like 'zypper ps', the post commit check for processes/services using
## old/deleted files calls 'lsof'. On some systems 'lsof' seems to perform
## very slow, and the check takes up to several minutes. Due to this it's
## possible to disable the automatic check after each commit. Explicit calls
## to 'zypper ps' are not affected by this option.
##
## Valid values: boolean
## Default value: yes
##
# psCheckAccessDeleted = yes
[search]
## Whether an available zypper-search-packages-plugin should be called at the
## end of each search command.
##
## Valid values: boolean values incl. 'always' or 'never', everything else is
## mapped to 'ask' (the default).
## Default value: ask
##
# runSearchPackages = ask
[color]
## Whether to use colors
##
## `autodetect` checks whether the terminal can handle colors
## and whether the NO_COLOR environment variable is not set.
## (For details about NO_COLOR, see https://no-color.org/)
##
## Valid values: always, never, or autodetect
## Default value: autodetect
##
# useColors = autodetect
## Color for displaying results of operations.
## This includes installation summary, tables, and result messages.
##
## Valid values: color
## Default value: default
##
# result = default
## Color for displaying status and progress messages.
##
## Valid values: color
## Default value: default
##
# msgStatus = default
## Color for displaying error messages.
##
## Valid values: color
## Default value: red
##
# msgError = red
## Color for displaying warnings.
##
## Valid values: color
## Default value: purple
##
# msgWarning = purple
## Color for highlighting additions or positive actions.
##
## Valid values: color
## Default value: green
##
# positive = green
## Color for highlighting modifications or changes.
##
## Valid values: color
## Default value: brown
##
# change = brown
## Color for highlighting removals or negative information.
##
## Valid values: color
## Default value: red
##
# negative = red
## Color for highlighting information.
##
## Valid values: color
## Default value: cyan
##
# highlight = cyan
## Color for dimming less relevant information.
##
## Valid values: color
## Default value: brown
##
# lowlight = brown
## Color for prompts.
##
## Valid values: color
## Default value: bold
##
# prompt = bold
## Color for prompt options.
##
## Valid values: color
## Default value: undefined, follows prompt
##
# promptOption =
## Do highlighting of package lists for easier reading?
##
## Within the packagelists displayed as transactions summary
## highlight the first letter of every package name (all),
## or only of the first package in each letter group (first).
##
## Valid values: all/first/no
## Default value: all
##
# pkglistHighlight = all
## Color to use for package list highlighting (see pkglistHighlight)
##
## 'default' or 'bold' will use the current lists headline color. Any
## other value will set a fix color used for all package lists.
##
## Valid values: color
## Default value: undefined, follows lists headline
##
# pkglistHighlightAttribute =
[obs]
## openSUSE Build Service repository base URL.
## This is used to construct real URL from obs://project/platform URI
##
# baseUrl = https://download.opensuse.org/repositories/
## openSUSE Build Service repository target platform.
## This will be used if none is given in the obs://obsrepo/platform URI
## when adding new repository with 'addrepo' command.
##
## NOTE: The 'platform' is actually a directory on the OBS server.
## We can only guess, how the directory containing the repository that fits
## your distribution is named. If you are following 'openSUSE_Factory' or
## 'openSUSE_Tumbleweed' you may need to set this as your platform.
## In case of doubt you need to look up the right URL in a browser.
##
# platform = openSUSE_$releasever
[subcommand]
## Whether to look for subcommands in $PATH
##
## If a subcommand is not found in the zypper_execdir, the wrapper
## will look in the rest of your $PATH for it. Thus, it's possible
## to write local zypper extensions that don't live in system space.
## See section SUBCOMMANDS in the zypper manpage.
##
## Valid values: boolean
## Default value: yes
##
# seachSubcommandInPath = yes
There are no complaints when a zypper dup is issued now, but is the modification syntax correct? Can this be checked or verified somehow?
Where is “key” coming from? The syntax should look like this:
##
## Maximum number of concurrent connections to use per transfer
##
## Valid values: Integer
## Default value: 5
##
## This setting is only used if more than one is possible
## Setting it to a reasonable number avoids flooding servers
##
download.max_concurrent_connections = 20
As I was reviewing the zypp.conf manpage I see:
A key-value assignment is a single line that has the name of the key, an equals sign, and a setting for the value, like
key = vlaue
That is a manpage typo above vlaue.
and
SECTIONS
The following sections are known, and can contain the given key assignments. Libzypp’s builtin default value for a key is given in parenthesis, like
key (value)
For some keys there is no fix builtin default value, but the best value is chosen according to the concrete task to be performed. While it is possible to prescribe a fix value, it’s
often the best decision not to define this key at all. This is indicated by showing <UNSET> as default value like
key (<UNSET>)
Many of the defaults set here can be overridden via zypper command line options. This is especially true for the resolver related defaults. See the zypper(8) man page for more
details.
So in this case download.max_concurrent_connections is the key and the value is 8 or 20 or whatever?
yes, correct.
in /etc/zypp/zypp.conf, not /etc/zypp/zypper.conf…
If you wrote it like that, of course it fails. It should be
download.max_concurrent_connections = 8and it shoud be in zypp.conf or, better in zypp.conf.d/10-max-concurrent.conf in a [main] section
Are you suggesting that each additional key that is added have it’s own .conf file which is named in a format such as 10-example-example.conf ?
These additional keys that may be added are then added to /etc/zypp/zypper.conf defaults and called on when zypper dup is issued?
From my clipboard:
system configuration: /etc/zypp/zypp.conf[.d/*.conf]
vendor configuration: /usr/etc/zypp/zypp.conf[.d/*.conf]
While it isn’t strictly necessary, it’s good practice to have a separate .conf in the .d directory for each change (each change might involve multiple keys). Modular config files in the conf.d directory are loaded after the base config file in alphanumeric order, overwriting any base configuration in the process.
You could just create one .conf called something like 10-myconfig.conf and use it for any and all changes, but having a different file for each change can be easier to manage.
The preceding number isn’t strictly necessary, either, but it gives you control over the order in which multiple config files are loaded.
.d directories were introduced to allow packages and admins to change configurations without altering (or worse, overwriting) the vendor-provided configuration.