That bug is from v3.2.5 but IPFire is currently running with v3.2.4 which was installed in April 2022. No update was done of the rsync package itself but a patch was added to fix a CVE with rsync. I can’t tell if that might have introduced a difference.
Searching on the
error message I found many reports about differences in rync version between machines causing this error message over several years and many version numbers.
Has there been an rsync version update on the other machine. One thing that can be done is to tell rsync on the other machine to use the protocol from version 3.2.4. man rsync should help with that.
I will do a patch to submit an updated version but that will likely not make it into CU171 as that was planned to be closed by end of today and the Testing release issued by the end of this week but it should get into CU172
I built rsync version 3.2.6 and found it to be working with core 170, haven’t looked that far into it other then that.
[root@ipsio tmp]# rsync --version
rsync version 3.2.6 protocol version 31
Copyright (C) 1996-2022 by Andrew Tridgell, Wayne Davison, and others.
Web site: https://rsync.samba.org/
Capabilities:
64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
socketpairs, symlinks, symtimes, hardlinks, hardlink-specials,
hardlink-symlinks, IPv6, atimes, batchfiles, inplace, append, ACLs,
xattrs, optional secluded-args, iconv, prealloc, stop-at, no crtimes
Optimizations:
SIMD-roll, no asm-roll, openssl-crypto, no asm-MD5
Checksum list:
md5 md4 none
Compress list:
zstd lz4 zlibx zlib none
rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and you
are welcome to redistribute it under certain conditions. See the GNU
General Public
Licence for details.
I have found a bug report in rsync about the CVE-2022-29154 patch giving the error message that you found. CVE-2022-29154 was a high severity issue and so was applied but no there was no feedback, positive or negative, on rsync from the CU170 Testing Release.
rsync fixed the bug in their git repository but that fix was flagged and fixed five days after the CVE patch was merged into the IPFire next tree.
Wait for the updated version to be included and released. I am currently doing the build of 3.2.6 and will submit the patch later today. I will flag up that this is an important fix to deal with a non-working rsync in CU170. Hopefully my arguments will result in it getting squeezed into CU171 at the last minute but I can’t guarantee that in which case it will be in CU172
It has been agreed that my patch with rsync-3.2.6 will be merged into CU171 which should end up going to Testing at the end of this week (no guarantees though).
It would be good if it would be possible for you to upgrade to the Testing release of CU171 to confirm that it resolves the problem for you. Based on all the info in the rsync git repo I expect it too but it would be good to confirm it.
If you have changed from stable to testing but not then run the update you can still change back to stable. Once you have run the update the easiest way to go back is to take a backup and do a fresh install.
Luckily I asked again. It kind of reminds me of before. I don’t want to do that! =))
I will build it myself.
PS:
If I reinstall and then restore the backup, will ALL settings including firewall rules be restored?
I would give it a try just to try it.
I still have a full backup.
Yes, they will. There is also a file /var/ipfire/backup/include.user that you can add additional directories or files to that will then be backed up. So if you have created scripts, or results files etc then you can add them to that file to be backed up in the IPFire backup files. The entries in include.user should have the leading / removed.
The .ipf backup file is just an archive file so you can open it up and read what is in it using a GUI or command line tool. Then you can see all the files that have been saved and can look at their contents.
My backup .ipf files have been very small since July 17th, 2022, and I cannot open them either.
What GUI or command line tool can I use to read the .ipf backup files?
I can’t read(open) you
The additional files must be included in the “/var/ipfire/backup/include.user” like this?
My sizes are all correct but I have just noticed when opening some of mine up that the content does not look right. My user defined content is missing from the file but also not all the standard data is showing up in it.
Incidentally if you use xarchiver on a 1.5GB file then it will take some time before you see the gui screen and some time before it is fully opened. My files are around 500MB and they were taking around 20 to 30 secs.
I am going to have look further at this issue with the backups. Obviously haven’t looked at them for a while. Will try a command line test.
EDIT:
Panic over. The backup files are okay but xarchiver is having problems properly opening them. This includes ones that have opened properly in the past so obviously a bug has occurred in xarchiver.
On the command line use tar tvzpf 2022-10-01-21_00.ipf replacing the IPFire backup file name I have written with the one you want to look at. This is basically the command that IPFire would use (minus the exclude files) but with a t in place of an x so that you only get shown what the contents are without them actually being extracted.
If you want to look at the .ipf archive file with a Linux GUI then lxqt-archiver will correctly show it if you change the extension from .ipf to .tar
lxqt refuses to try and open the file if it has .ipf but changing it to .tar works fine and the content is as it should be. Then after viewing the contents you would need to change the ext back to .ipf
deepin-compressor is a Linux archive manager gui that I have found that works properly with the IPFire backup files while still leaving the extension as .ipf