In short, yum history rollback is not a good way to do do anything other
than very small package changes. i.e. downgrading from version 1.4.27 to
1.4.26 of some package or completely removing package you just installed
for testing along with all dependencies.
Longer explanation:
Yum history rollback just finds out which packages are to be installed
(and in which versions) and which are to be removed. After that it
simply downloads needed pakage files and runs appropriate install/remove
actions. It's in no way similar to any "restore snapshot" operation. In
case of files contained in the packages, the situation is easy - the
"new" package installs new packages, then the files belonging to the
"old" package but not belonging to "new" one are removed. Simple.
It gets more tricky with package scripts. RPM runs like this:
1. Runs pre-install script
2. Installs files
3. Runs post-install script
4. Runs pre-uninstall script
5. Removes files
6. Runs post-uninstall script
Steps 1-3 are run if there's any package installation or update
(upgrade/downgrade) and steps 4-6 are run if there's any package removal
(uninstall/upgrade/downgrade).
Bear with me, it's getting more magical :-)
The scripts executed during the operations are run almost completely
without any additional environment or context. The only parameter is "a
number representing the number of instances of the package currently
installed on the system, /after/ the current package has been installed
or erased" (http://ftp.rpm.org/max-rpm/s1-rpm-inside-scripts.html). This
means that install scripts might be run with an argument of 1 (initial
install) or 2 (upgrade/downgrade) since after the install stage the
number of package instances on the system will be equal to those numbers
and the uninstall scripts might be run with an argument of 0 (complete
removal) or 1 (upgrade/downgrade) since that's how many instances of
package will be left after the uninstall phase. There is probably an
option for
You can see how it's used by querying a package with rpm -q --scripts. A
good example here is an openssh-server package which runs some actions
only on complete removal.
Unfortunately, the rpm scripts have no more context about the package
versions (and don't have any reasonable way for querying the state of
the rpm database in the middle of a transaction) so there is no way of
knowing whether the update operation is an upgrade or downgrade. And we
need also to remember than usually "big upgrades" invoke some "external"
changes, like database schema upgrades, which are not easily
rollbackable (as we said before - rpm rollback doesn't work on
system-level snapshot). Therefore it's usually either assumed that
update operation is indeed an upgrade one, not a downgrade. And it's a
good practice to check prerequisites before executing needed "upgrade
scripts" (like check database schema version beforehand as to not apply
an upgrade script twice). Sometimes packagers just create a package with
new files and tell you to upgrade the dependencies (like database
schema) on your own.
So, long story short - no, there is no simple way to perform a yum
history rollback and have a usable system if the upgrade had been "deep".
Therefore if you upgrade Bareos installation upgrade I'd do a full
configuration backup and database dump to have a working state to which
you can roll back.
Hope this wasn't too complicated :-)
On 28.04.2020 14:37, Goncalo Sousa wrote:
yum history rollback [id] doesn't do the job?
terça-feira, 28 de Abril de 2020 às 13:12:40 UTC+1, Oleg Volkov escreveu:
No, I am talking about rollback, reverting back to previous version.
Upgrading of production server suggest that you have any roll back
plan.
Anyway it is your choice, not mine.
--
You received this message because you are subscribed to the Google
Groups "bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/bareos-users/34303ce5-505a-4f9c-b531-f9262b169689%40googlegroups.com
<https://groups.google.com/d/msgid/bareos-users/34303ce5-505a-4f9c-b531-f9262b169689%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/bareos-users/c1946b4a-a625-7a82-0b8b-8f5d9ae89c1b%40gmail.com.
