Sometimes, I need to make some changes to Centos like installing and testing some utilities or trying a complex tutorial to install an advanced program for which the outcome is unknown.
How can I revert back to the state before doing changes.
A practical case: I want to install PHP7 besides PHP5.6, there are many tutorials, I want to test each one and if I fail, I want at least to revert back to the previous state.
For production use, the best approach is to have a testing environment where you can test any changes before applying them into production. Having this as a VM of course helps with snapshots and rollbacks.
Another approach is the use of modern file systems like ZFS that also allow to do snapshots or even LVM.
This is best done with in a virtual machine such as VMware or VirtualBox, rather than on physical hardware. Take a snapshot of your virtual machine prior to making any changes, then it's a trivial matter of reverting to your snapshot should you need to revert to your previous state.
Say you install some package:
yum install php
And say that package php installs a bunch of dependencies.
Dependencies Resolved
===============================================================================================================================
Package Arch Version Repository Size
===============================================================================================================================
Installing:
php x86_64 5.3.3-49.el6 base 1.1 M
Installing for dependencies:
php-bcmath x86_64 5.3.3-49.el6 base 40 k
php-cli x86_64 5.3.3-49.el6 base 2.2 M
php-common x86_64 5.3.3-49.el6 base 530 k
php-dba x86_64 5.3.3-49.el6 base 46 k
php-devel x86_64 5.3.3-49.el6 base 513 k
php-embedded x86_64 5.3.3-49.el6 base 1.1 M
php-enchant x86_64 5.3.3-49.el6 base 34 k
php-gd x86_64 5.3.3-49.el6 base 111 k
php-imap x86_64 5.3.3-49.el6 base 55 k
php-intl x86_64 5.3.3-49.el6 base 76 k
php-ldap x86_64 5.3.3-49.el6 base 43 k
php-mbstring x86_64 5.3.3-49.el6 base 460 k
php-mysql x86_64 5.3.3-49.el6 base 86 k
php-odbc x86_64 5.3.3-49.el6 base 56 k
php-pdo x86_64 5.3.3-49.el6 base 80 k
php-pgsql x86_64 5.3.3-49.el6 base 75 k
php-process x86_64 5.3.3-49.el6 base 44 k
php-pspell x86_64 5.3.3-49.el6 base 33 k
php-recode x86_64 5.3.3-49.el6 base 30 k
php-snmp x86_64 5.3.3-49.el6 base 36 k
php-soap x86_64 5.3.3-49.el6 base 145 k
php-tidy x86_64 5.3.3-49.el6 base 41 k
php-xml x86_64 5.3.3-49.el6 base 108 k
php-xmlrpc x86_64 5.3.3-49.el6 base 58 k
php-zts x86_64 5.3.3-49.el6 base 1.2 M
If you were to simply try to remove package php, via yum remove php, yum will do just that, and leave the most/all of the dependencies on the system since you didn't ask it to remove them as well.
Dependencies Resolved
===============================================================================================================================================================================================================
Package Arch Version Repository Size
===============================================================================================================================================================================================================
Removing:
php x86_64 5.3.3-49.el6 @base 3.5 M
Removing for dependencies:
php-devel x86_64 5.3.3-49.el6 @base 3.0 M
php-pecl-apc-devel x86_64 3.1.9-2.el6 @base 3.3 k
Transaction Summary
===============================================================================================================================================================================================================
Remove 3 Package(s)
Rather, you can use yum to undo a transaction entirely, by invoking yum history command.
]# yum history
Loaded plugins: fastestmirror, security
ID | Login user | Date and time | Action(s) | Altered
-------------------------------------------------------------------------------
41 | <user> | 2018-06-08 10:45 | Install | 26
And now undo history ID 41, in this case:
yum history undo 41
Note, that in some cases, yum won't be able to remove certain packages, if newer updates depend on them, or they are core system packages, etc... but generally, this will "undo" that transaction.
Also note, on Fedora (and soon on CentOS) systems, dnf package manager has the same commands, so dnf history will still work.
Last note, this won't undo any config file changes you've made in /etc (it will remove newly installed config files if a package put them there, however). Anything you do to the system will persist, anything the package manager did, will be reverted. If you need a full-system revert capability, then it's best to use a VM and snapshots as others have mentioned.
