HowTo update Nethserver correctly via CLI?


(fpausp) #1

NethServer Version: 7.5

I did a fresh Installation of NS 7.5 and configured the Software updates origin to lock:

The next step was to update the server via GUI (Software center).
grafik
Everything went well…

Later on I used the command:
yum clean all && rm -rf /var/cache/yum && yum update
to update the Server via CLI and got this:

I would like the same result on CLI, why is there a difference ?

How does the GUI do it (what command) ?


Latest Updates (20Dec2018) causes YumRPMCheckError
(Marc) #2

Admin manual warns about this:

When yum is run from the command line and the software origin is “locked”, EPEL and other repositories which are generically compatible with “7” are enabled

That’s why you got additional updates from CLI.

Developer manual gives some explanation.

When NS Release Lock is enabled, CentOS repos are available but they point to a fixed CentOS release (/etc/yum.repos.d/NsReleaseLock.repo). Repos that don’t support lock to minor release (epel, centos-sclo-rh, centos-sclo-sclo…) are disabled when using Software Center.

Configuration of enabled repositories is stored inside:

  • /etc/nethserver/pkginfo.conf: repos with groups listed on Software Center (modules)
  • /etc/nethserver/eorepo.conf: repos enabled by software-repos-save event

Note: when a subscription is enabled, NSReleaseLock will be disabled.

Software Center does not use yum command, it makes use of pkginfo and pkgaction commands, and they relay on yum’s API (python). When Release Lock is enabled, Software Center gets updates using pkgaction --strict-update.

# /usr/libexec/nethserver/pkgaction -h
Usage: /usr/libexec/nethserver/pkgaction {<command> {PACKAGE|@GROUP}}...
    command: [--install|--update|--strict-update|--remove]

Those helper programs are placed under /usr/libexec directory tree and, according to the FHS, are not meant to be used directly by users:

/usr/libexec includes internal binaries that are not intended to be executed directly by users or shell scripts.

Long time ago I recall having used pkgaction, but only for testing purposes while troubleshooting some software center related stuff. I don’t recall its usage having any adverse effect, but NethServer developers can shed some light on it.

While those commands are meant for very specific tasks, yum has more options and is more flexible. man yum and man yum.conf probe this.

One way to restrict from which repositories your server gets updates when using yum from CLI, is to make use of --enablerepo= and --disablerepo= options.

Haven’t looked much into it but to get same updates as Software Center it could suffice with:

yum --disablerepo=\* --enablerepo=ce-\*,nethserver-{base,updates},nethforge update

or (as lock is enabled some repos are disabled; if additional repos were added adjust command accordingly, or take action on repository settings referenced in the manual):

yum --disablerepo=epel,centos-sclo\* update

But updates for packages from EPEL et al. that are already installed shall be checked from time to time.


Upgrade failing due to 'Resolving RPM Dependencies - metacache caching issue'
(fpausp) #3

Thank you Marc, for this excellent explanation, that sounds like the only safe way for me at the moment is to use the GUI… I will take the time and learn more abt yum, repos, etc…


(Marc) #4

If no extra repositories were added, the last command should work the same.


(Giacomo Sanchietti) #5

Honestly I could explain it better!

Thank you @dnutan!


(fpausp) #6

I still have the update-problems if I configured the Software-Center to locked:

Can you confirm this ?


Ultimate ns7 software updates origin policy
(Marc) #7

Yes, same error when updating packages from software center.
A clue from the log file:

[YumRPMCheckError] [u'ERROR with transaction check vs depsolve:', 'jq is needed by nethserver-subscription-3.3.0-1.ns7.noarch']

jq package is from EPEL repository, which is disabled by “locked” mode.


Yum: Failed to check for updates
(fpausp) #8

So if I install jq once, the problem is solved for the future ?


(Marc) #9

For this package I’d say yes, at least for the foreseeable future, but…
It will depend on other package dependencies. If a package needs and updated version of a dependency from a locked repo, the error could happen again.


(fpausp) #10

Thank you for your answer, I ask myself if the locked-feature is technically mature…


Software center configuration: locked-feature: flaky to say the least and be polite
(Giacomo Sanchietti) #11

I’m not sure neither, currently to make it work really well you need a full mirror of all repositories (EPEL, centos, sclo, etc…). This requires a lot of work and a good infrastructure, this is why we create the subscription plan: at least we are trying to cover the basic expanses for the infra :wink:

I still hope we can make it better in the future!


(fpausp) #12

Thank you Giacomo, nethserver and its community is great !


(Marc) #13

If it’s of use, CentOS Vault holds sclo/rh repo data of pasts versions.