External Repository not restored from configuration restore

Steps to reproduce

  • create a server
  • add external repository (Mr Markuz)
  • install apps you need (packages, modules)
  • create config backup
  • create data backup
  • apply config backup to another freshly installed server
  • restore config backup
  • restore data backup

Effects:

  • empty application list (from previously installed modules and packages)
  • no modules installable from Software Center
  • impossible to perform updates
  • modules not restored
  • No user interface error is showed after the restore
  • Optional - Feeling quite dumb.

Workaround applied

  • From shell: check if everything is ok on updates via yum update
  • Error showed about GPG key for the repository
  • Manually reinstalled Mr Markuz Repository
  • Run again yum update (with new GPG key import)
  • Server updated
  • Manually reinstall modules and packages

Probably i missed something to do prior to restore? The server was freshly installed, no updates done before the restore. Same version from backup to freshly installed (7.8.2003)

3 Likes

I don’t think so. It seems there’s an error in the module, maybe the missing GPG key is not included in the backup, I’m going to check…
Thanks for pointing out.

EDIT:

The config restore uses eorepo to disable external repos so it seems only way is manually reinstalling external repos before config restore.
We could include the eorepo template that allows the external repos to the config backup but then eorepo makes no sense anymore as it secures Nethserver from probably broken external repos. @stephdl What do you think?

Sep 28 10:49:12 testserver eorepo[43484]: Repository mrmarkuz (mrmarkuz repo for Nethserver 7 - x86_64) has been disabled.
Sep 28 10:49:12 testserver eorepo[43484]: Repository stephdl (Stephdl (Stephane de Labrusse) repository for nethserver 7 - x86_64) has been disabled.

results in

Sep 28 10:56:17 testserver esmith::event[44610]: No package nethserver-mrmarkuz available.
Sep 28 10:56:20 testserver esmith::event[44610]: No package nethserver-stephdl available.
2 Likes

well that is a chicken and egg question

we push some templates inside our rpm to avoid that eorepo disables our external repository, so yes I assume when you reinstall the configuration backup to a newer server our repository could be disabled

Maybe we could trick and save the tempate fragment by the configuration backup

1 Like

:thinking: Time to change how the backup/restore works… again!

3 Likes

Trying to fix at the official level, thinking loudly

As a community developer I provide in my nethserver-stephdl rpm

/etc/yum.repos.d/stephdl.repo
/etc/pki/rpm-gpg/RPM-GPG-KEY-stephdl

these files are included inside the configuration backup

however eorepo will disable my repository so I push a template fragment to force my repository enabled, since it is a template, this file is not included in the configuration backup

/etc/e-smith/templates/etc/nethserver/eorepo.conf/45stephdl

My concern if I understand well is that I can provide the key and the configuration of my repository, the list of rpm won’t be reinstalled because my repository is disabled after the restoration to another server.

So I suppose the easier fix, maybe not the nicer could be to include in the configuration backup all the templates inside /etc/e-smith/templates/etc/nethserver/eorepo.conf/. Obviously we can exclude some official template fragments

At least this is what I do in my rpm, I include now /etc/e-smith/templates/etc/nethserver/eorepo.conf/45stephdl in the configuration backup

cc @dev_team

1 Like

… what? Custom templates are not backupped as part of configuration?

No, templates are not backuped because they are provided by the packages.
Custom templates are included in backup.

Ok, my bad, i barked up wrong…

…as alternative we can evaluate to include relevant files in the configuration backup:

For sure we need a deeper analysis to find a good approach to this issue :thinking:

It’s never a good idea to add some files owned by a package inside the backup because they will be overridden by an eventual update.

My suggestion for this kind of situations, is just to install the extra repo before restoring the backup.
If you installed extra repo, you already know it :slight_smile:

We can add a note inside the administrator manual.

1 Like

I agree to not fix it by now: that’s a restore pre-requisite, like configuring the IP gateway…

However we will have to consider this scenario, if a deeper work on the restore procedure starts in the future.

1 Like

And a note into the install procedure, both on docs than Cockpit.

I don’t get it :thinking:
Would you mind opening a PR? :wink:

You said…

And I can partially agree with you (some sysadmins forget the color of their toothbrush 15 seconds after washing their teeth. Yes, i am one of them) but you can’t take it as granted.

Your suggestion is IMHO sharable, but as also wrote by me, "add this note into docs.nethesis.org, administration manual and into Cockpit restore section, the built in, not the addon.

For what concerns

as stated before…


Therefore, is still a question:

I’m quite against adding a label inside Cockpit itself, since third party repositories are not part of the core. But I will open the PR for the doc. :wink:

A git patch is still good for me :stuck_out_tongue:

Anyway thanks

I see your point, but in any case partially are supported, and also documented into wiki. Thanks for allowing that but… if adding a thirdy party repository (also documented into wiki) make fully crash the yum mechanism, Backup of NethServer could be no more an option for me because it substantially failes to restore the server (with thirdy party repository)

It doesn’t make yum crash.

This is your free choice. :slight_smile:

But let me be blunt for a little: we involved 3 different developers, analysed the problem and searched for solutions. I’m even willing to modify the doc for your request … and you say it’s not enough. Why should I even spend more time on it? :man_shrugging:

PR open: https://github.com/NethServer/docs/pull/531

1 Like

IMVHO there’s should be a little bit of difference between talking and demanding.
Was never intended to expect the “fully satisfatory solution for the issue i encoundered”, just reporting what happened to me and (maybe) what could happen to another person who tried to restore from the configuration and data in case of disaster recovery.

I hope that was not misunderstood as “the project sucks because of the issue”, that’s not in my heart or in my thoughts; if anyway you or the developers felt bad about my answers, accept my apologies.

As free is the product, free are the experiences, the ideas, even the not always sharable goals between developers and adopters.

If you don’t feel right spending time on that… do what you please. :slight_smile:
Again, thanks for the PR :slight_smile:

4 Likes

every journey starts by a first step, mine was done when 7 years ago I asked what is a patch :smiley:

Do not hesitate to propose, to do, to ask, this is the power of the community.

This has two ways to fix the issue, the core and the developer side. I have already fixed the issue on my rpm, if you want to update the nethserver-stephdl, do a config backup and try to restore to another server please