Cu 163, 164, 165_RC : backup restore : DynDns entry missing

[manfred_knick]

After restore, previous Dynamic DNS entry was lost.

[bonnietwin (Adolf Belka)]

Hi Manfred

Let’s look first if the data is in the backup file.

The backup .ipf file is just a tar file so you can open it on the command line or via an archiver gui and look at the contents of the file.

The ddns info is backed up in /var/ipfire/ddns/ and there should be three files
config
ddns.conf
settings
These should have all the details of the ddns providers that you had setup.

Edit:
You can akso check in the same directory path on your ipfire mschine to see what ended up in that directory after the restore.

[manfred_knick]

The backup is empty, ddns.conf missing:

/…/2022/2022-03-11_09-19__cu-163/var/ipfire/ddns

-rw-r–r-- 1 manfred manfred 0 9. Feb 2018 config
-rw-r–r-- 1 manfred manfred 0 9. Feb 2018 settings

DynDns re-added manually;
From a later restore:

/…/IPFire/2022/2022-03-23_17-39__cu-163/var/ipfire/ddns

-rw-r–r-- 1 manfred manfred 49 22. Mär 16:35 config
-rw-r–r-- 1 manfred manfred 101 22. Mär 16:35 ddns.conf
-rw-r–r-- 1 manfred manfred 0 9. Feb 2018 settings

Running box (ssh), upgraded to cu165_TESTING:

/var/ipfire/ddns
-rw-r–r-- 1 nobody nobody 49 Mar 22 16:35 config
-rw-r–r-- 1 nobody nobody 101 Mar 22 16:35 ddns.conf
-rw-r–r-- 1 root root 3.5K Feb 7 15:17 ddns.conf.sample
-rw-r–r-- 1 nobody nobody 0 Feb 7 12:47 ipcache
-rw-r–r-- 1 nobody nobody 0 Feb 9 2018 settings

Fresh Backup:
/…/IPFire/2022/2022-03-24_10-54__cu-165-Testing/ :

/var/ipfire/: NO sub-folder ./ddns/ exists <—!

####################################################

Don’t know yet if it could be related (implausible, rather):
concerning spdns.org / spdyn.de , there is a sepciality:

Originally, this service was free and worked the ‘classical’ configuration:
. 3 parameters:
. . . Hostname:
. . . Username:
. . . Password:
which is being kept on for regular registered customers originating form ‘ancient’ times ;-(
Nowadays, this has been ‘improved’:

a)
Seit dem 01.07.2020 ist die Erstellung von neuen Accounts nur noch für Securepoint-Reseller möglich. Die Funktion von bestehenden Accounts ist nicht eingeschränkt.

b)
ACME Challenge Token

. 2 parameters:
. . . Hostname:
. . . Token:

which is reflected by IPFire’s " Dynamic DNS" setup page.

If I enter my {hostname}, neglect my {username} and fill in my {password} into “Token:” ,
that gets being accepted ‘somehow’,
and I can issue an “Instant Update” with no ERROR being thrown,
but the spdyn Dashboard still displays the latest update to be outdated 04.02.2018 15:21:15 :
which indicates it did not work as expected.

Kind regards
Manfred

P.S.:
Manually updating my account via Dashboard works.
Will have an eye on these effects during expected IPFire update → cu165_Stable.

[bonnietwin (Adolf Belka)]

So I just checked through the backup/include file for IPFire.

It has includes for:-

• /var/ipfire//.conf
• /var/ipfire/*/settings
• /var/ipfire/*/config

So that should capture all the required files.
Not sure why the ddns.conf file would have not been backed up.

What happens if you do a backup now. Are all three files present in the backup. ie is the missing ddns.conf a systematic issue on your system or was it a one-off.

[manfred_knick]

The latest referene was “right now” - c.f. the date/time :

Fresh Backup:
/…/IPFire/2022/2022-03-24_10-54__cu-165-Testing/ :

Re-done again:
…/2022-03-24_12-17__cu-165-Testing/var/ipfire : NO ./ddns/ subdirectory contained.

according to " System → Home", the version installed is:
. . . IPFire 2.27 (x86_64) - Core Update 165 Development Build: master/38f5bc99

Via ssh:

ll /var/ipfire//.conf | grep ddns
-rw-r–r-- 1 nobody nobody 101 Mar 24 11:14 /var/ipfire/ddns/ddns.conf

ll /var/ipfire/*/config | grep ddns
-rw-r–r-- 1 nobody nobody 49 Mar 22 16:35 /var/ipfire/ddns/config

ll /var/ipfire/*/settings | grep ddns
-rw-r–r-- 1 nobody nobody 0 Feb 9 2018 /var/ipfire/ddns/settings

[bonnietwin (Adolf Belka)]

I have just done a backup on my CU164 running system and I found that a whole bunch of directories were not backed up.
I was missing

• captive
• connscheduler
• ddns
• dhcp
• dhcpc
• dma

However this can’t be directly related to the change to CU 164 as I carried that out on 14th March and I have a backup, that I run weekly from a script, which is dated 19th March and that has all the directories backed up.
Also the backup run by the CU164 change on the 14th also has all the directories.
Ones I am running today either from the WUI or using my script all have the above directories missing.
Actually I must check the whole list to see fi there are any others missing that would have been there in the past.
Don’t understand what is happening at the moment.

[manfred_knick]

I have posted other problems which - in light of your findings - might be related; e.g.

cu-163-164-165-rc-backupctrl-broken/7467
cu-163-backup-restore-addon-hostapd-devices-can-not-connect-waiting-for-ip-address/7476
cu-163-backup-restore-sensors-broken/7468

During near future, I will definitely take a leaf out of my own book
and not miss out exploiting CloneZilla:

cu-163-backup-restore-sensors-broken/7468/3

Good luck, kind regards!
Manfred

[bonnietwin (Adolf Belka)]

Additionally the following are also missing

• accounting addon
• dnsforward
• extrahd
• isdn
• logging
• mac
• main
• modem
• optionsfw
• pakfire
• qos
• remote
• sensors
• wakeonlan
• wio addon
• wireless

So there are a huge number missing from my backup.

Can you check your backup and see if the ones I have listed are also missing in your ipfire directory. This would show if the directories not being backed up are consistent for the two of us. Makes the fault easier to diagnose.

I may raise a bug for this but will first check out some of what you highlighted. My script was using backup.pl directly not backupctrl and the issue with backupctrl was a problem with the paths. I will have a look at that. Although what I don’t understand is why the backups were okay up to 19th March which is after I had updated to CU164

[manfred_knick]

Please, c.f. PM:
. . . ls -h -AlgR 2022-03-24_12-17__cu-165-Testing
. . . 2022-03-24_12-17__cu-165-Testing.txt.gz

Hth!

Feel free to request for more

[bonnietwin (Adolf Belka)]

I think you were right about the backupctrl issue being related.

I think it was caused by a change issued in CU164 which changed the backup include and exclude files to have their entries as relative paths and not absolute paths. I think that may have then caused the backupctrl issue.

Either way, changing the include file paths back to absolute (ie prepending a / at the start of every line) has made my backup now include all the required directories.

I will have a look at testing out the path change that @Michael implemented to fix the backupctrl issue to confirm if that also fixes this problem - ie they are driven by the same root cause. However I will over to my vm testbed for that because I will have to copy in the modified backupctrl file from the git repository and the path change was made to one of the c files for backupctrl.

Anyway a simple temp fix for your running system is to add a / at the start of each line in
/var/ipfire/backup/include

[bonnietwin (Adolf Belka)]

The fix for the backupctrl issue is in next which means it will be seen in CU166

[manfred_knick]

I fear there are more $PATH-related issues - e.g.:

Adding aliases into .bashrc like

cat .bashrc
…
[[ -f ~/.bash_aliases ]] && . ~/.bash_aliases

yields the following failure at ssh-login:

. . . Last login: Thu Mar 24 13:25:43 2022 from 10.31.101.51
-bash: /root/.bash_aliases: Permission denied

Directly afterwards, commanding
. . . source ~/.bash_aliases
works instantaneously …

[manfred_knick]

CONFIRMATION: Re-do :

…/2022-03-24_13-37__cu-165-Testing____slash $ ll var/ipfire/ddns/

-rw-r–r-- 1 manfred manfred 49 22. Mär 16:35 config
-rw-r–r-- 1 manfred manfred 101 24. Mär 11:14 ddns.conf
-rw-r–r-- 1 manfred manfred 0 9. Feb 2018 settings

[bonnietwin (Adolf Belka)]

So I just ran CU166 (next) which has the backupctrl path fix and the fix looks to work in that the previous issue did not occur but there was another failure but that is due to an uninitialised variable in something that is still being worked on.

However, key thing is that with the backupctrl path fix in place the missing directories in the backup were still missing so it looks like this is a different bug so I will raise it in the IPFire Bugzilla.

[bbitsch (Bernhard Bitsch)]

If backupctrl call backup.pl ( a bash script ) the problem is the missing expansion of entries like ‘var/ipfire//.conf’.

[bonnietwin (Adolf Belka)]

Except that I had the same problem if I ran backup.pl directly from the command line. The directories were still missing.

[bonnietwin (Adolf Belka)]

bug raised https://bugzilla.ipfire.org/show_bug.cgi?id=12817

[rejjysail (Rejjy_S)]

@Adolf , I had submitted bug 12816 earlier which I think may be related.

[bonnietwin (Adolf Belka)]

Hi Rejjy,
Yes I only saw it after I had submitted mine.

Reading through it i think it is the same.

[jon]

This one may be related…
https://bugzilla.ipfire.org/show_bug.cgi?id=12811

Cu 163, 164, 165 RC: backupctrl broken

Using the “Backup Console”, running “backupctrl restore” fails with backup.pl: . . . 145: convert-to-location . . . 148: firewallctrl . . . 151: convert-ovpn . . . 163: convert-dns-settings “not found” - although existing. Temporarily replacing the calls with full path of the files circumvented this pothole, leading to further errors as follow-ups. [ wiki.ipfire.org - Using the Backup Console ]