Restoring With Old/Outdated Apps?
-
afaik a config restore will fetch the newest version of the packages. the settings will be used in the new version.
-
There is only ever one set of files on the package server so if a newer version has been released that's what will be downloaded.
Steve
-
Ok guys, thanks for the clarification.
I'll keep doing my nightly backups then.
If I may be so bold to ask? Is their a reason why we cannot include the previous version(s) of package on the package server for a roll back?
Cheers
-
I don't believe there is a particular reason other than it has never been felt necessary. Most updates to the packages are to remove bugs or increase functionality. If a sufficiently large change is made the package is often split into a -dev version and later merged back if it proves successful. One of the devs could probably answer that better.
There are separate repos for different FreeBSD based versions. If you roll back from 2.2 to 2.1.5 you will automatically get the older packages from the 8 repo.Steve
-
If I may be so bold to ask? Is their a reason why we cannot include the previous version(s) of package on the package server for a roll back?
Cheers
There is only one version of the PHP code that is used as part of most packages. Many packages are a combination of an underlying binary that runs as a daemon and then PHP code that provides GUI configuration pages. Snort and Suricata are examples of this. The binary bits are contained within a PBI package, but the PHP GUI bits are stored as simple text files on the packages repository server. There is no "versioning" of these as the file names are always the same and they are stored in the same directory. So while it is technically possible to rollback to an older PBI package for the binary bits, the PHP GUI code bits are always "current" (meaning designed to support the latest version). So even if you rollback to an older binary package, your PHP GUI would potentially not be matched up to that binary and would probably produce configuration files the older binary could choke on.
A shorter answer is simply that the packages repository system is not set up to handle multiple versions of both the binary bits and the PHP GUI code bits
for packages. The packages repository always points to the "current version" of any package.Bill
-
Is their a reason why we cannot include the previous version(s) of package on the package server for a roll back?
A better question might be, "Why aren't you taking a snapshot before you make any changes to it in the first place?". I run 2.1.5 in production in a vSphere environment. I take daily backups of the VM and regular config backups. But besides all that, if I'm going to make a major change that could affect the stability of the system then I will take a snapshot first. Better to have to delete an unwanted snap than to have to do a full restore while the CEO is asking why he can't get his email.
-
So it seems that it's more complicated to me (the layman) the file/storage/package structure is maybe not as straightforward as the layman may think ;)
I do take a nightly backup of my VM so can role back relatively easily. I guess I was also thinking at the back of my mind how to people running a physical box manage?
-
For physical servers, your options are more limited. If you are concerned that a package update might cause damage then your only real option would be to image the system disk beforehand, which is obviously undesirable as it takes the firewall out of service until the backup is complete. If you make a config XML backup, then a restore will pull down the current packages and not the ones you had previously installed. That may actually fix the problem if it was a weird upgrade glitch that caused it in the first place.
-
If you're running the full install on physical hardware you can use the full-backup option. That backs up packages as well.
https://doc.pfsense.org/index.php/Full_BackupSteve
-
If you run a local copy of the packages repo, you can sync it to any version/commit you want.
If someday pfSense packages files get fetched by a commit id or tag just like we can do on freebsd ports, it will be easy to roll back.
