I checked the content of allow.rpz file from archive I got from old machine: it is containing the correct whitelist.
The problem is NOT the archive. The archive contains everything.
The problem is the Restore process via WUI: none of the files from the archive were restored…
Late edit: does the add-on have a build in “restore”?
I mean: I can copy the rpz.ipf inside /var/ipfire/backup/addons/ and then use the RPZ add-on command to restore that?
The WUI is not doing its job!
I didn’t do the restore process, yet. Shortage of time
But looking inside the sources the WUI restore addon process should succeed.
I’l try it later this day.
There is no restore command. @jon uses the processes for IPFire addons.
There is no RPZ add-on restore command since we use the IPFire backup/restore system.
But we can do a command line restore. Can you do the following steps to help troubleshoot?
Please enter this and post results:
ls -al /var/ipfire/backup/addons/backup
Find the backup file from the restored box and copy it to the /var/ipfire/backup/addons/backup directory (just like you mentioned above). Did it copy OK?
Please enter this and post results:
ls -al /var/ipfire/backup/addons/backup
Run the IPFire restore and post results:
backupctrl restoreaddon rpz.ipf
Your RPZ files should be listed and installed.
PS - Sorry for asking the detail questions. Something odd is happening and it doesn’t make sense!
backupctrl restore rpz.ipf,
make a new backup,
save the new backup to rpz1.ipf on my desktop
compare rpz.ipf and rpz.ipf1
result: equal
addon restore in WUI ( rpz.ipf from my desktop )
make a new backup
save the new backup to rpz2.ipf on my desktop
compare rpz.ipf, rpz1.ipf, rpz2.ipf
result: equal
This means backupctrl and the WUI rpz.cgi do what they should. As @jon supposed there must be some oddity on your system.
Hi Jon,
I started the process from scratch on another box with core 189 where there is no rpz addon.
Status of the box: no trace of the rpz addon, or the rpz.ipf backup
ls -lth /var/ipfire/dns/r* ; ls -lth /etc/unbound/z*; ls -lth /etc/unbound/local.d/ ; ls -lth /var/ipfire/backup/addons/backup/
ls: cannot access '/var/ipfire/dns/r*': No such file or directory
ls: cannot access '/etc/unbound/z*': No such file or directory
total 0
total 0
I know this is not the latest version but I wanted to replicate my exact steps:
curl -k https://community.ipfire.org/uploads/short-url/q1sbCBTynBmAKDhoMThogHfV5Gk.zip -o /opt/pakfire/tmp/rpz-beta-0.1.10-10.ipfire.zip
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 15553 0 15553 0 0 62973 0 --:--:-- --:--:-- --:--:-- 63741
ls -lth /opt/pakfire/tmp/rpz-beta-0.1.10-10.ipfire.zip
-rw-r--r-- 1 root root 16K Dec 9 13:56 /opt/pakfire/tmp/rpz-beta-0.1.10-10.ipfire.zip
What is inside the file /opt/pakfire/tmp/rpz-beta-0.1.10-10.ipfire.zip
tar tvzf /opt/pakfire/tmp/rpz-beta-0.1.10-10.ipfire.zip
gzip: stdin has more than one entry--rest ignored
drwxr-xr-x root/root 0 2024-10-15 09:08 ./
-rw-r--r-- root/root 12728 2024-10-15 09:08 files.tar.xz
-rw-r--r-- root/root 427 2024-10-15 09:08 ROOTFILES
-rwxr--r-- root/root 2340 2024-10-15 09:08 update.sh
-rwxr--r-- root/root 2024 2024-10-15 09:08 uninstall.sh
-rwxr--r-- root/root 1945 2024-10-15 09:08 install.sh
tar: Child returned status 2
tar: Error is not recoverable: exiting now
tar -zxvf rpz-beta-0.1.10-10.ipfire.zip
gzip: stdin has more than one entry--rest ignored
./
files.tar.xz
ROOTFILES
update.sh
uninstall.sh
install.sh
tar: Child returned status 2
tar: Error is not recoverable: exiting now
ls -lth
total 48K
-rw-r--r-- 1 root root 16K Dec 9 13:56 rpz-beta-0.1.10-10.ipfire.zip
-rw-r--r-- 1 root root 13K Oct 15 09:08 files.tar.xz
-rw-r--r-- 1 root root 427 Oct 15 09:08 ROOTFILES
-rwxr--r-- 1 root root 1.9K Oct 15 09:08 install.sh
-rwxr--r-- 1 root root 2.0K Oct 15 09:08 uninstall.sh
-rwxr--r-- 1 root root 2.3K Oct 15 09:08 update.sh
Install RPZ 1.10:
NAME=rpz ./install.sh
Extracting files...
./
var/
var/ipfire/
var/ipfire/menu.d/
var/ipfire/menu.d/EX-rpz.menu
var/ipfire/dns/
var/ipfire/dns/rpz/
var/ipfire/dns/rpz/blocklist
var/ipfire/dns/rpz/allowlist
var/ipfire/backup/
var/ipfire/backup/addons/
var/ipfire/backup/addons/includes/
var/ipfire/backup/addons/includes/rpz
var/ipfire/addon-lang/
var/ipfire/addon-lang/rpz.en.pl
var/ipfire/addon-lang/rpz.de.pl
usr/
usr/sbin/
usr/sbin/rpz-sleep
usr/sbin/rpz-metrics
usr/sbin/rpz-make
usr/sbin/rpz-functions
usr/sbin/rpz-config
srv/
srv/web/
srv/web/ipfire/
srv/web/ipfire/cgi-bin/
srv/web/ipfire/cgi-bin/rpz.cgi
etc/
etc/unbound/
etc/unbound/zonefiles/
etc/unbound/zonefiles/allow.rpz
etc/unbound/local.d/
etc/unbound/local.d/00-rpz.conf
...Finished.
ownership of '/var/ipfire/dns/rpz/allowlist' retained as nobody:nobody
ownership of '/var/ipfire/dns/rpz/blocklist' retained as nobody:nobody
ownership of '/var/ipfire/dns/rpz' retained as nobody:nobody
ownership of '/etc/unbound/zonefiles/allow.rpz' retained as nobody:nobody
ownership of '/etc/unbound/zonefiles' retained as nobody:nobody
ownership of '/etc/unbound/local.d/00-rpz.conf' retained as nobody:nobody
changed ownership of '/etc/unbound/local.d' from root:root to nobody:nobody
Stopping Unbound DNS Proxy... [ OK ]
Starting Unbound DNS Proxy... [ OK ]
Status post install:
ls -lth /var/ipfire/dns/r* ; ls -lth /etc/unbound/z*; ls -lth /etc/unbound/local.d/ ; ls -lth /var/ipfire/backup/addons/backup/
total 0
-rw-r--r-- 1 nobody nobody 0 Oct 15 08:54 allowlist
-rw-r--r-- 1 nobody nobody 0 Oct 15 08:54 blocklist
total 0
-rw-r--r-- 1 nobody nobody 0 Oct 15 08:54 allow.rpz
total 4.0K
-rw-r--r-- 1 nobody nobody 301 Oct 15 08:54 00-rpz.conf
total 0
Using cgi-bin/backup.cgi to restore the below rpz.ipf file copied from “production” system that is also running 1.10 RPZ addon
Nothing changed on the system as result of using the above page to restore rpz.ipf
ls -lth /var/ipfire/dns/r* ; ls -lth /etc/unbound/z*; ls -lth /etc/unbound/local.d/ ; ls -lth /var/ipfire/backup/addons/backup/
total 0
-rw-r--r-- 1 nobody nobody 0 Oct 15 08:54 allowlist
-rw-r--r-- 1 nobody nobody 0 Oct 15 08:54 blocklist
total 0
-rw-r--r-- 1 nobody nobody 0 Oct 15 08:54 allow.rpz
total 4.0K
-rw-r--r-- 1 nobody nobody 301 Oct 15 08:54 00-rpz.conf
total 0
Then I used the process posted by @bbitsch: backupctrl restore rpz.ipf
To reproduce exactly my steps I would suggest to remove all rpz.ipf from the addon backup folder - my system was always “brand new” (never had RPZ) but your had the rpz.ipf on the addon backup folder.
This is the only difference I could spot between my process and your process…
That has been there for a very long time then. That existence test first went into backup.pl in Core Update 125, a bit over 6 years ago and no one has noticed that the restores for the addons don’t work, me included.
EDIT:
I took a vm that had no addons and then I installed bacula, which I use and I have backups for.
The first couple of times I tried to do the restore, nothing got changed so duplicating what has been mentioned here.
I then shut the vm down, then after a bit I thought what happens if I do a full restore so I restarted the vm, restored my IPFire which also provided all the addon backups listed in the backup WUI page and then I did a restore of the same bacula addon backup file via the WUI and this time the bacula config file was updated correctly.
So it is not as simple as it looked. Under some conditions the addon backups are restore correctly.
Can you tell me the date for the change you mention because the specific test you showed
I found in backup.pl in CU125 for the first time using a search by the midpoint after I tested back in CU120 and found that the line did not exist there.
Seaching a bit more, I think you are right. CU 130 contains the false line.
Your observations about restores are reproducible.
If the backup repo contains a file yet, this restored. Nobody has checked whether changes in the new file are transferred.
Okay, I have now shown that if I start with a system with no bacula and then I install it, it has a default bacula-fd.conf file.
Choosing a bacula.ipf file to restore from on the WUI page results in no update. Tried it several times and nothing was updated.
I then cleared the bacula.ipf file from the /tmp/ directory and then did a main backup restore first. That put a restore.ipf file into /tmp/ but the bacula-fd.conf file was still not correct.
I then selected the same bacula.ipf file for restore and now the bacula-fd.conf file was correctly restored.
So the sequence of things affects whether an addon restore works or not.
I didn’t check the restore action.
The error is in the restoreaddon action. See restore_addon_backup function in
/var/ipfire/backup/bin/backup.pl ( a bash file ).
).