820_copy_to_net.sh and PXE output fails with rsync protocol - DRLM issue 189¶

Labels: cleanup, fixed / solved / done

didacog opened issue at 2022-03-30 08:43:¶

Relax-and-Recover (ReaR) Issue Template¶

Fill in the following items before submitting a new issue
(quick response is not guaranteed with free support):

ReaR version ("/usr/sbin/rear -V"): 2.6
OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"): RHEL 8.5
ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"): DRLM managed
Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM guest or PowerVM LPAR): PowerVM LPAR
System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device): ppc64le
Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe): SAN
Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"):
Description of the issue (ideally so that others can reproduce it):

The initrd and kernel files of the PXE ouput are not being copied properly on OUTPUT_PREFIX using RSYNC

Workaround, if any:

put back the /usr/share/rear/output/PXE/default/820_copy_to_net.sh in place to do it properly

Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):

see: https://github.com/brainupdaters/drlm/issues/189

To paste verbatim text like command output or file content,
include it between a leading and a closing line of three backticks like

```
verbatim content
```

pcahyna commented at 2022-03-30 09:01:¶

ReaR version ("/usr/sbin/rear -V"): 2.6

The file is there in 2.6, so I suppose you are using the current development version, or the 2.6 version provided with RHEL 8.5 ?

The file was removed by me in 14a9a61d62b02a27f55495320f2d0e1090a72c30 - I will check why it is still needed. I suppose the relevant configuration file is https://github.com/brainupdaters/drlm/issues/189#issuecomment-1081634198 ?

didacog commented at 2022-03-30 09:09:¶

is still needed by PXE output with rsync proto, if not is not sending properly the PXE required files in OUTPUT PREFIX location.

pcahyna commented at 2022-03-30 09:33:¶

I checked the ReaR debug log. It reads

2022-03-28 08:26:39.624312668 Copying files '/var/lib/rear/output/<censored-host>.kernel /var/lib/rear/output/<censored-host>.initrd.cgz /var/lib/rear/output/<censored-host>.message /var/lib/rear/output/rear-<censored-host>' to rsync://<censored-host>@<censored-subnet>.123/<censored-host>_default/PXE/ location
++ cp -v /var/lib/rear/output/<censored-host>.kernel /var/lib/rear/output/<censored-host>.initrd.cgz /var/lib/rear/output/<censored-host>.message /var/lib/rear/output/rear-<censored-host> /tmp/rear.edPhWcoyMoFm3zO/tmp/rsync//
'/var/lib/rear/output/<censored-host>.kernel' -> '/tmp/rear.edPhWcoyMoFm3zO/tmp/rsync/<censored-host>.kernel'
'/var/lib/rear/output/<censored-host>.initrd.cgz' -> '/tmp/rear.edPhWcoyMoFm3zO/tmp/rsync/<censored-host>.initrd.cgz'
'/var/lib/rear/output/<censored-host>.message' -> '/tmp/rear.edPhWcoyMoFm3zO/tmp/rsync/<censored-host>.message'
'/var/lib/rear/output/rear-<censored-host>' -> '/tmp/rear.edPhWcoyMoFm3zO/tmp/rsync/rear-<censored-host>'
++ echo '
Relax-and-Recover 2.6 / 2020-06-17

Relax-and-Recover comes with ABSOLUTELY NO WARRANTY; for details see
the GNU General Public License at: http://www.gnu.org/licenses/gpl.html

Host <censored-host> using Backup RSYNC and Output PXE
Build date: Mon, 28 Mar 2022 08:25:42 +0200
'
+++ get_template RESULT_usage_PXE.txt
+++ [[ -e /etc/rear/templates/RESULT_usage_PXE.txt ]]
+++ echo /usr/share/rear/conf/templates/RESULT_usage_PXE.txt
++ cp -v /usr/share/rear/conf/templates/RESULT_usage_PXE.txt /tmp/rear.edPhWcoyMoFm3zO/tmp/rsync//README
'/usr/share/rear/conf/templates/RESULT_usage_PXE.txt' -> '/tmp/rear.edPhWcoyMoFm3zO/tmp/rsync//README'
++ cat /var/log/rear/rear-<censored-host>.log
++ case $RSYNC_PROTO in
++ Log 'rsync -a /tmp/rear.edPhWcoyMoFm3zO/tmp/rsync// --sparse --archive --hard-links --numeric-ids --stats --devices --acls --xattrs rsync://<censored-host>@<censored-subnet>.123:873/<censored-host>_default//'
++ echo '2022-03-28 08:26:39.669531306 rsync -a /tmp/rear.edPhWcoyMoFm3zO/tmp/rsync// --sparse --archive --hard-links --numeric-ids --stats --devices --acls --xattrs rsync://<censored-host>@<censored-subnet>.123:873/<censored-host>_default//'
2022-03-28 08:26:39.669531306 rsync -a /tmp/rear.edPhWcoyMoFm3zO/tmp/rsync// --sparse --archive --hard-links --numeric-ids --stats --devices --acls --xattrs rsync://<censored-host>@<censored-subnet>.123:873/<censored-host>_default//
++ rsync -a /tmp/rear.edPhWcoyMoFm3zO/tmp/rsync// --sparse --archive --hard-links --numeric-ids --stats --devices --acls --xattrs rsync://<censored-host>@<censored-subnet>.123:873/<censored-host>_default//
DRLM server 2.4.1

Number of files: 9 (reg: 7, dir: 2)
Number of created files: 7 (reg: 7)
Number of deleted files: 0
Number of regular files transferred: 7
Total file size: 137,041,987 bytes
Total transferred file size: 137,041,987 bytes
Literal data: 137,041,987 bytes
Matched data: 0 bytes
File list size: 0
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 137,076,084
Total bytes received: 165

sent 137,076,084 bytes  received 165 bytes  54,830,499.60 bytes/sec
total size is 137,041,987  speedup is 1.00

So the files <censored-host>.initrd.cgz and <censored-host>.kernel were copied to rsync://<censored-host>@<censored-subnet>.123:873/<censored-host>_default// (by output/RSYNC/default/900_copy_result_files.sh). Now I don't understand why they are missing.

gdha commented at 2022-03-30 09:57:¶

@pcahyna this was I got from the git history:

$ git log -- 820_copy_to_net.sh
commit 14a9a61d62b02a27f55495320f2d0e1090a72c30
Author: Pavel Cahyna <pcahyna@redhat.com>
Date:   Fri Jun 18 13:10:56 2021 +0200

    Revert "add script from Andreas Lemke to xfer to PXE server"

    This reverts commit d850c4094238a03c9b926b88d7e1582ecd28af52.

    The script probably made sense when it was submitted, but in the
    meantime generic handling of transfer of output files got implemented
    ( a8fdc44 ), which made it redundant when it was committed.

pcahyna commented at 2022-03-30 10:01:¶

@gdha indeed, and the file that is supposed to replace it has this:
https://github.com/rear/rear/blob/14a9a61d62b02a27f55495320f2d0e1090a72c30/usr/share/rear/output/default/950_copy_result_files.sh#L132
so the copying there gets skipped, because

# If BACKUP = RSYNC output/RSYNC/default/900_copy_result_files.sh took care of it:

and indeed, according to the log provided by the user, output/RSYNC/default/900_copy_result_files.sh took care of it. So I don't understand yet what's the problem....

pcahyna commented at 2022-03-30 10:19:¶

It seems that the underlying problem is that https://github.com/rear/rear/blob/14a9a61d62b02a27f55495320f2d0e1090a72c30/usr/share/rear/prep/RSYNC/default/100_check_rsync.sh sets the various RSYNC_ variables according to BACKUP_URL, but the results are used also in the output stage, so if OUTPUT_URL != BACKUP_URL (which is the case here), the output files get uploaded to BACKUP_URL instead of OUTPUT_URL.

That's quite a confusion and I think that my removal of that script is not the only place that exposes the problem. See also usr/share/rear/output/RSYNC/default/900_copy_result_files.sh, I think it has been also placing output files to BACKUP_URL.

pcahyna commented at 2022-03-30 10:33:¶

Sorry for causing you this problem. You may be the only one who sets BACKUP_URL different from OUTPUT_URL in the case of rsync and in your case the PXE script was circumventing the problem until I removed it.

pcahyna commented at 2022-03-30 10:35:¶

I believe that using global RSYNC_ variables is a bad idea. Any code that needs them should set local variables for this purpose and decide itself if it needs to set them according to BACKUP_URL or OUTPUT_URL.

didacog commented at 2022-03-30 12:29:¶

I agree, we must stick to BACKUP_URL / OUTPUT_URL vars to avoid strange behavior like this.

github-actions commented at 2022-06-01 03:52:¶

Stale issue message

didacog commented at 2022-06-01 09:08:¶

@pcahyna do you have any PR pending to solve this issue? how can we help to get rid of this issue before 2.7 release?

pcahyna commented at 2022-06-01 11:20:¶

@didacog not yet, but I am about to start working on this issue and have it resolved by 2.7, either by cleaning up the URL use with rsync or, if this proves too difficult, at least by restoring the old script temporarily.

didacog commented at 2022-06-01 11:24:¶

ok, perfect. let us know if something is needed from us.

pcahyna commented at 2022-06-01 15:49:¶

Reproducer for the underlying issue:

BACKUP=RSYNC
BACKUP_PROG_EXCLUDE+=( '/home/reartestuser/rsync' )
BACKUP_URL=rsync://reartestuser@localhost/home/reartestuser/rsync/backup/
OUTPUT_URL=rsync://reartestuser@localhost/home/reartestuser/rsync/output/

and

mkdir -p /home/reartestuser/rsync/backup/
mkdir -p /home/reartestuser/rsync/output/
chown reartestuser /home/reartestuser/rsync/backup/ /home/reartestuser/rsync/output/
rear mkbackup

After that, /home/reartestuser/rsync/backup/* contains both backup and rear-*.iso, while /home/reartestuser/rsync/output is empty.

jsmeix commented at 2022-06-09 08:41:¶

I marked this issue as 'blocker' for ReaR 2.7
because it seems to be a regression which
should be solved or avoided for ReaR 2.7.

pcahyna commented at 2022-06-20 09:00:¶

Hi @didacog

when working on a generic solution for the rsync URL oddities, I realized that there was an irregularity in how the URL was handled in the (now removed) usr/share/rear/output/PXE/default/820_copy_to_net.sh script. The script had

case "$scheme" in
...
    (rsync)
...
            rsync -a $v "$result_file" "$OUTPUT_URL"

What I am trying to do is to make the more generic script share/rear/output/RSYNC/default/900_copy_result_files.sh take care of it (it already uploads the files, but to $BACKUP_URL instead of $OUTPUT_URL). The problem is, the structure of the destination is different. share/rear/output/RSYNC/default/900_copy_result_files.sh creates a directory ${RSYNC_PREFIX} (defaults to hostname) under the specified URL and puts the output files there. In contrast, usr/share/rear/output/PXE/default/820_copy_to_net.sh script puts the files directly under $OUTPUT_URL. So, in ReaR 2.6, the files were under $OUTPUT_URL, after my fix, they will be under $OUTPUT_URL/$RSYNC_PREFIX, so, still a change in behavior. Is that acceptable for you?

This is only one of the many irregularities surrounding the use of rsync, and the regression that you encountered merely exposes it. The same irregularity has been always present in the most generic output script usr/share/rear/output/default/950_copy_result_files.sh:

case "$scheme" in
...
    (rsync)
        # If BACKUP = RSYNC output/RSYNC/default/900_copy_result_files.sh took care of it:
        test "$BACKUP" = "RSYNC" && return 0
...
        rsync -a $v "${RESULT_FILES[@]}" "${host}:${path}" || Error "Problem transferring result files to $OUTPUT_URL"

Yes, if BACKUP = RSYNC, output/RSYNC/default/900_copy_result_files.sh takes care of it, but differently: even if we suppose that $OUTPUT_URL == $BACKUP_URL , output/RSYNC/default/900_copy_result_files.sh puts the files under $RSYNC_PREFIX, while this file puts them directly under $OUTPUT_URL. I don't see why the structure of output directories should depend on the value of BACKUP, which is conceptually independent on the output code.
(The same difference is actually present in other output URLs: URL schemes that use a filesystem directly, like file:// and nfs://, put the files under $OUTPUT_PREFIX (which is distinct from $RSYNC_PREFIX, but fulfills the same function), while schemes using a transfer program (in practice, lftp) store output directly under $OUTPUT_URL, and for rsync we have both.)

The current code ( both usr/share/rear/output/default/950_copy_result_files.sh and usr/share/rear/output/PXE/default/820_copy_to_net.sh script ) has also the problem that it won't allow the use of rsync over ssh, because it passes the rsync:// URL directly to rsync, which is valid only if using a rsync daemon connection.

pcahyna commented at 2022-06-20 09:16:¶

Actually, I see that in the original issue, RSYNC_PREFIX=, so the difference should not affect the original bug reporter. I don't know whether that's always the case for DRLM, though (is the config file user-supplied or generated by DRLM?).

pcahyna commented at 2022-06-20 09:28:¶

Ignoring $RSYNC_PREFIX / $OUTPUT_PREFIX in the output structure should be in practice quite harmless, because the output files are distinguished by $RAMDISK_SUFFIX and, in the case of ISO image, $ISO_PREFIX (both embed the hostname by default), so there should be no collision, even if multiple machines upload their outputs to a single backup location. Still, one wonders why the difference.

didacog commented at 2022-06-20 09:59:¶

Hi @pcahyna

after my fix, they will be under $OUTPUT_URL/$RSYNC_PREFIX, so, still a change in behavior. Is that acceptable for you?
Yes, this is ok for us.

(is the config file user-supplied or generated by DRLM?).
The config is setup by the user on DRLM, then rear on run get the config by https from DRLM api, but are all rear configs adjusted to our supported rear backup methods. see: https://docs.drlm.org/en/latest/client_config_default.html

We simplified some config options to be easier for the user, but are translated to proper ReaR configs.

pcahyna commented at 2022-06-20 10:57:¶

@didacog I don't see RSYNC_PREFIX in that document. Does DRLM always set it to empty? Anyway, if you are ok with the change, the only question is whether the change is not too disruptive for users - @jsmeix what do you think? I feel that making the code and behavior more regular is worth it, but one will pay some price in terms of incompatibility in the case of simultaneous OUTPUT=PXE and OUTPUT_URL=rsync://....

jsmeix commented at 2022-06-20 11:13:¶

@pcahyna
personally I neither use PXE nor rsync
so I have no personal experience with it.

I think @gdha has more personal experience with it
so perhaps he can better answer questions about
incompatibility in the case of simultaneous
OUTPUT=PXE and OUTPUT_URL=rsync://...

In general we can change things in ReaR from version to version
in particular to improve things so in general I appreciate
making the code and behavior more regular when this
can be done without major regressions.

I consider it no major regression when users need to adapt
their settings in /etc/rear/local.conf to achieve basically
the same outcome as before.
For example see my changed behaviour and changed default
in ReaR 2.5 how the MODULES config variable works at
https://github.com/rear/rear/blob/master/doc/rear-release-notes.txt#L924
which caused "a minor backward incompatible change"
https://github.com/rear/rear/blob/master/doc/rear-release-notes.txt#L936

In contrast I would consider it a major regression if something
that has worked before would not at all work any longer.

didacog commented at 2022-06-20 14:02:¶

Hi @pcahyna

@didacog I don't see RSYNC_PREFIX in that document. Does DRLM always set it to empty? Anyway, if you are ok with the change, the only question is whether the change is not too disruptive for users - @jsmeix what do you think? I feel that making the code and behavior more regular is worth it, but one will pay some price in terms of incompatibility in the case of simultaneous OUTPUT=PXE and OUTPUT_URL=rsync://....

We see no problems on OUTPUT=PXE and OUTPUT_URL=rsync://... combo. we use it without any issue. see: https://github.com/brainupdaters/drlm/blob/b95ef8061f1cbd56d685b9e5c569db24e1044ea1/usr/share/drlm/www/drlm-api/client.go#L299

We know well that there are different variables for each type of setup so we simplified the config on DRLM side to avoid users to miss config stuff...

And yes, we set RSYNC_PREFIX to empty, so the backup and output files will be where the config setup needs.

Regards,
Didac

pcahyna commented at 2022-06-21 09:56:¶

Hi @didacog

sorry, I found yet another anomaly that will have an impact on OUTPUT=PXE if the issue is fixed the way I intend.

usr/share/rear/prep/RSYNC/default/100_check_rsync.sh has this explanation of BACKUP_URL:

#### OLD STYLE:
# BACKUP_URL=[USER@]HOST:PATH           # using ssh (no rsh)
#
# with rsync protocol PATH is a MODULE name defined in remote /etc/rsyncd.conf file
# BACKUP_URL=[USER@]HOST::PATH          # using rsync
# BACKUP_URL=rsync://[USER@]HOST[:PORT]/PATH    # using rsync (is not compatible with new style!!!)

#### NEW STYLE:
# BACKUP_URL=rsync://[USER@]HOST[:PORT]/PATH    # using ssh
# BACKUP_URL=rsync://[USER@]HOST[:PORT]::/PATH  # using rsync

So, rsync://[USER@]HOST[:PORT]/PATH form (that you are using for OUTPUT_URL) means to use rsync over ssh in the new style, but rsync daemon in the old style. It seems that everything interprets the URLs in the new style, except for usr/share/rear/output/PXE/default/820_copy_to_net.sh that passes $OUTPUT_URL directly to rsync, which interprets it in the old style.
My intent is to remove this irregularity, OUTPUT_URL will be always interpreted in the new style, but in your case it will lead to output file uploads going over ssh instead of using the rsync daemon, and thus possibly ending in a different place than you expect.

I realized that this irregularity may have been the very reason why you have introduced an OUTPUT_URL different from BACKUP_URL in the first place (you seem to want to use the rsync daemon for both, but the syntax is different in the two cases).

I am not sure how to fix it in a different way than to introduce this incompatibility, I believe this irregularity should not stay in ReaR forever.

Regards, Pavel

pcahyna commented at 2022-06-28 07:26:¶

@didacog can you please try a fixed build? Packages for RHEL 8 can be downloaded here: https://koji.fedoraproject.org/koji/taskinfo?taskID=88547667 , the source is here : https://github.com/pcahyna/rear/tree/rsync-output-backup-url

didacog commented at 2022-06-28 07:49:¶

@pcahyna sorry for not answering last week, we are preparing OpenExpo'22 conference in Madrid while working on the running projects, so we are pretty busy until the end of this week. We'll test it ASAP and update this issue.

pcahyna commented at 2022-06-28 08:03:¶

@didacog no problem! I know that it takes time and lots of work to test a change of one component in a complex environment. If you can't test the change now, please have a look at the description of intended behavior changes in https://github.com/rear/rear/issues/2781#issuecomment-1161527507 first (the code to test implements this change).

jsmeix commented at 2022-06-28 11:43:¶

Only FYI:
Because of
https://github.com/rear/rear/issues/2781#issuecomment-1168363028
I postponed the ReaR 2.7 release date to
beginning of July, see
https://github.com/rear/rear/issues/2751#issuecomment-1168557804

pcahyna commented at 2022-06-28 11:47:¶

@jsmeix thanks for taking it into consideration. Note though that I won't be available in the first two weeks of July. If all goes well, it would not be a problem (I have done extensive tests of the changes and now I need only to add comments to the code and I can submit a PR).

jsmeix commented at 2022-06-28 12:07:¶

@pcahyna
could you please create a regular pull request
(with the added comments in the code)
so I could "just merge" that when @didacog agrees
or if needed even fix something together with @didacog
(provided I understand what I do).

jsmeix commented at 2022-06-29 12:00:¶

@didacog
please test
https://github.com/rear/rear/pull/2831
as soon as you have time for it.
Many thanks in advance for your testing!

pcahyna commented at 2022-06-29 17:24:¶

@didacog since the proposed change will suffer from an ambiguity of interpretation of a rsync://[USER@]HOST[:PORT]/PATH-form in OUTPUT_URL (interpreted as using the rsync protocol in ReaR 2.6, but rsync over ssh after the change), I propose to use the alternate old-style form [USER@]HOST::PATH (without the rsync:// part and with double ::). This should be unambiguous: both old and new code should treat is as the rsync protocol.
I also don't intend to make the change in RHEL 8, which was the original concern: I will probably just restore the old file, because the change looks too disruptive.

didacog commented at 2022-07-04 14:43:¶

@pcahyna we are testing it and we are not able to set PXE output in a separated folder than backup data as we used to do previously. We are used to put backup data in backup subfolder and pxe files in PXE subfolder and is not working with the updated code.

this is the config we set:

OUTPUT=PXE
OUTPUT_PREFIX_PXE="debcli1/pxe/PXE"
OUTPUT_URL="rsync://debcli1@192.168.123.132/debcli1_pxe/PXE/"
BACKUP=RSYNC
RSYNC_PREFIX=
BACKUP_URL="rsync://debcli1@192.168.123.132::/debcli1_pxe"
BACKUP_RSYNC_OPTIONS+=( --devices --acls --xattrs )

Regards,
Didac

pcahyna commented at 2022-07-04 16:56:¶

@didacog thank you for testing. Per your config file above, the output pxe files should end up under /debcli1_pxe/PXE/ on the server. Is that not the case? Note that an URL of the form rsync://debcli1@192.168.123.132/debcli1_pxe/PXE/ is now interpreted as an rsync-over-ssh destination, so modules defined in the server's rsyncd.conf will have no effect. Could that be the problem?

pcahyna commented at 2022-07-04 16:58:¶

Oh and the latest code is at #2831

didacog commented at 2022-07-05 05:38:¶

@didacog thank you for testing. Per your config file above, the output pxe files should end up under /debcli1_pxe/PXE/ on the server. Is that not the case? Note that an URL of the form rsync://debcli1@192.168.123.132/debcli1_pxe/PXE/ is now interpreted as an rsync-over-ssh destination, so modules defined in the server's rsyncd.conf will have no effect. Could that be the problem?

Yes, it may be the problem, so should we use rsync://debcli1@192.168.123.132::/debcli1_pxe/PXE/ in the OUTPUT_URL?

didacog commented at 2022-07-05 07:29:¶

@pcahyna we tested all the possible options and no one creates the PXE sub-folder in the destination to put the output files there as used to do. Neither rsync_over_ssh or rsync_server, so please can you tell us what config is supposed to work the same as before with your changes in the config for SSH and rsync, please.

Regards,
Didac

pcahyna commented at 2022-07-05 14:16:¶

@didacog thank you for testing. Per your config file above, the output pxe files should end up under /debcli1_pxe/PXE/ on the server. Is that not the case? Note that an URL of the form rsync://debcli1@192.168.123.132/debcli1_pxe/PXE/ is now interpreted as an rsync-over-ssh destination, so modules defined in the server's rsyncd.conf will have no effect. Could that be the problem?

Yes, it may be the problem, so should we use rsync://debcli1@192.168.123.132::/debcli1_pxe/PXE/ in the OUTPUT_URL?

That should be it. Doesn't it work? Where do the files go then, or are they just lost?

pcahyna commented at 2022-07-05 16:00:¶

I think I know what's wrong... the code does not handle rsync server URLs with multiple path components or trailing slashes, like your /debcli1_pxe/PXE/. The original code before my change has this issue too for BACKUP_URL, but because you are using a one-component path for BACKUP_URL, you have not encountered it. I believe that if you used another level of directories at the server, say BACKUP_URL="rsync://debcli1@192.168.123.132::/debcli1_pxe/foo", you would have seen the problem.

didacog commented at 2022-07-06 08:59:¶

@pcahyna we may found the problem:

https://github.com/rear/rear/blob/bd484848eeed0c2a761f3244e4ab5e96396257af/usr/share/rear/output/RSYNC/default/200_make_prefix_dir.sh

here is creating $RSYNC_PREFIX and $RSYNC_PREFIX/backup, but there is nothing in rear code creating $RSYNC_PREFIX/output or $RSYNC_PREFIX/$OUTPUT_PREFIX or similar to set the dest folder of OUTPUT_URL if differs from BACKUP_URL. I think that just creating this:

mkdir -p $v -m0755 "${TMP_DIR}/rsync/${RSYNC_PREFIX}/$OUTPUT_PREFIX" >&2 || Error "Could not mkdir '${TMP_DIR}/rsync/${RSYNC_PREFIX}/$OUTPUT_PREFIX'"

in the proper place will solve the whole problem.

see this
https://github.com/rear/rear/blob/bd484848eeed0c2a761f3244e4ab5e96396257af/usr/share/rear/output/default/200_make_prefix_dir.sh
is doing it also for NETFS ... so i think sholud be done also for RSYNC and that's all

Regards,
Didac

pcahyna commented at 2022-07-07 09:11:¶

@didacog are you sure? OUTPUT_PREFIX has never been respected for rsync:// URLs. RSYNC_PREFIX is used instead (since both default to $HOSTNAME, you would get a duplicate entry in the path, like "${TMP_DIR}/rsync/$HOSTNAME/$HOSTNAME"). Have you tested your suggestion? By the way, do you have logs with -D of your unsuccessful attempts? It would be good to see how does rsync get actually invoked and where does it try to put the files.

didacog commented at 2022-07-07 12:47:¶

@pcahyna we found the root problem. is in the rsync_path and rsync_remote_base functions:

function rsync_path () {
    local url="$1"
    local host
    local path

    host=$(url_host "$url")
    path=$(url_path "$url")  <----- you are using this $path in the case (rsync), and it only works properly using $url or it removes part of the path with the else always!!!
    local tmp2="${host#*@}"

    case "$(rsync_proto "$url")" in

        (rsync)
            # path=/gdhaese1@witsbebelnx02::backup or path=/backup
            if grep -q '::' <<< $path ; then   <--- never gets this!!
                echo "${path##*::}"
            else
                # XXX what if path=/backup/sub/directory ? Should we remove
                # longest prefix?
                echo "${path##*/}"  <--- removes the path!!!
            fi
            ;;
        (ssh)
            echo "$path"
            ;;

    esac
}

So this function should be using :

 (rsync)
            # path=/gdhaese1@witsbebelnx02::backup or path=/backup
            if grep -q '::' <<< $url ; then   
                echo "${url##*::}"
            else
                # XXX what if path=/backup/sub/directory ? Should we remove
                # longest prefix?
                echo "${url##*/}"  
            fi
            ;;

or simply ans maybe better:

(rsync)
          echo $path

as url_path is getting the proper path with :: or without.

the rsync_remote_base in line 140:

            echo "rsync://${user}@${host}:${port}/"

must be:

            echo "rsync://${user}@${host}:${port}"

and with these changes everything is working properly!

kind regards,
Didac

pcahyna commented at 2022-07-07 13:25:¶

Thank you @didacog, we have narrowed it to the same piece of code - after I wrote https://github.com/rear/rear/issues/2781#issuecomment-1175226505 , I saw that the problem should lie there. But note that because the routines have to handle multiple URL formats, it will take some time to test the changes - I am a bit afraid that the proposed changes might break other stuff.

By the way, when you say "with these changes everything is working properly!", what is the config file that it is working properly with? In particular, what do you set OUTPUT_URL to?

didacog commented at 2022-07-07 13:49:¶

@pcahyna here is an example:

OUTPUT_URL="rsync://debcli1@192.168.123.132::/debcli1_pxe/PXE"

and the result files properly in place:

pcahyna commented at 2022-07-08 18:17:¶

Thanks @didacog for the information, I updated the PR with a commit that should fix it, please retest.

didacog commented at 2022-07-11 10:35:¶

@pcahyna, retested and now is working well.
Thanks!

pcahyna commented at 2022-07-12 08:53:¶

@didacog thanks for the test! If you are using rsync://debcli1@192.168.123.132::/debcli1_pxe/PXE/ for OUTPUT_URL, I suggest to try the form debcli1@192.168.123.132::/debcli1_pxe/PXE/ both with the old (before the removal of /usr/share/rear/output/PXE/default/820_copy_to_net.sh) and the proposed code. That is, if you are interested in a format that is equally supported both by the old and the new code without needing a configuration file change.

jsmeix commented at 2022-07-12 10:58:¶

@didacog @pcahyna
for ReaR 2.7 the old and the new style rsync URLs will be supported.

BUT:
Because I get more and more annoyed by the complications of the
old style rsync URLs (horrible subtle working fragile code
that nobody can maintain with reasonable effort over a long time)
cf. https://github.com/rear/rear/pull/2831#discussion_r918762882
I may lose my patience and "simply remove" support for the
old style rsync URLs in ReaR 2.8 or in a later version.
Whether or not this happens mainly depends on how many
further issues will appear with ReaR and rsync.
If things work sufficiently OK (except minor issues)
I won't touch the rsync code.
But when a generic cleanup is the only reasonable way out
in practice I would mercilessly clean it up
to make it simple and straightforward.

jsmeix commented at 2022-07-12 12:00:¶

With https://github.com/rear/rear/pull/2831 merged
this issue is fixed.

pcahyna commented at 2022-07-12 13:48:¶

I may lose my patience and "simply remove" support for the
old style rsync URLs in ReaR 2.8 or in a later version.

I understand, but in addition to compatibility, the value of old-style URLs it that they should allow remote paths not starting with / (there is a difference between user@host:path and user@host:/path, because the former is rooted at user's $HOME and there is no way to get this with a new-style URL, AFAICT).

jsmeix commented at 2022-07-12 14:27:¶

I think that because user is a static known value
its home directory is also a static known value
so I assume one can specify a full path URL like

user@host:/full/path/to/user/home/directory/subdir

instead of user@host:subdir?
Or is there something why the full path URL cannot work?
(I am not a rsync user so I don't know rsync special stuff.)

pcahyna commented at 2022-07-12 14:33:¶

This should work, yes. I felt it was an artificial gap, as rsync itself allows relative paths. But since nobody has AFAIK complained about it, probably users can live without it and expand to a full path if needed.
Another argument for keeping the old syntax for some time is if it is the only way to have the same URL format that works with PXE both in ReaR 2.6 and ReaR 2.7.

pcahyna commented at 2022-07-12 14:35:¶

(the last argument is not valid if it is a ReaR version that intentionally stops being compatible with many other configuration options. I would call it 3.0 in that case, though.)

jsmeix commented at 2022-07-12 14:37:¶

If there is real value in the old style rsync URLs
we keep them of course because

(1)  It Has To Work.

https://datatracker.ietf.org/doc/html/rfc1925

pcahyna commented at 2022-07-12 14:41:¶

I am not sure myself, because I am merely testing the rsync stuff, and only since quite recently. I will try to ask others if the time for the decision comes.

[Export of Github issue for rear/rear.]

#2781 Issue closed: Missing /usr/share/rear/output/PXE/default/820_copy_to_net.sh and PXE output fails with rsync protocol - DRLM issue 189¶

didacog opened issue at 2022-03-30 08:43:¶

Relax-and-Recover (ReaR) Issue Template¶

pcahyna commented at 2022-03-30 09:01:¶

didacog commented at 2022-03-30 09:09:¶

pcahyna commented at 2022-03-30 09:33:¶

gdha commented at 2022-03-30 09:57:¶

pcahyna commented at 2022-03-30 10:01:¶

pcahyna commented at 2022-03-30 10:19:¶

pcahyna commented at 2022-03-30 10:33:¶

pcahyna commented at 2022-03-30 10:35:¶

didacog commented at 2022-03-30 12:29:¶

github-actions commented at 2022-06-01 03:52:¶

didacog commented at 2022-06-01 09:08:¶

pcahyna commented at 2022-06-01 11:20:¶

didacog commented at 2022-06-01 11:24:¶

pcahyna commented at 2022-06-01 15:49:¶

jsmeix commented at 2022-06-09 08:41:¶

pcahyna commented at 2022-06-20 09:00:¶

pcahyna commented at 2022-06-20 09:16:¶

pcahyna commented at 2022-06-20 09:28:¶

didacog commented at 2022-06-20 09:59:¶

pcahyna commented at 2022-06-20 10:57:¶

jsmeix commented at 2022-06-20 11:13:¶

didacog commented at 2022-06-20 14:02:¶

pcahyna commented at 2022-06-21 09:56:¶

pcahyna commented at 2022-06-28 07:26:¶

didacog commented at 2022-06-28 07:49:¶

pcahyna commented at 2022-06-28 08:03:¶

jsmeix commented at 2022-06-28 11:43:¶

pcahyna commented at 2022-06-28 11:47:¶

jsmeix commented at 2022-06-28 12:07:¶

jsmeix commented at 2022-06-29 12:00:¶

pcahyna commented at 2022-06-29 17:24:¶

didacog commented at 2022-07-04 14:43:¶

pcahyna commented at 2022-07-04 16:56:¶

pcahyna commented at 2022-07-04 16:58:¶

didacog commented at 2022-07-05 05:38:¶

didacog commented at 2022-07-05 07:29:¶

pcahyna commented at 2022-07-05 14:16:¶

pcahyna commented at 2022-07-05 16:00:¶

didacog commented at 2022-07-06 08:59:¶

pcahyna commented at 2022-07-07 09:11:¶

didacog commented at 2022-07-07 12:47:¶

pcahyna commented at 2022-07-07 13:25:¶

didacog commented at 2022-07-07 13:49:¶

pcahyna commented at 2022-07-08 18:17:¶

didacog commented at 2022-07-11 10:35:¶

pcahyna commented at 2022-07-12 08:53:¶

jsmeix commented at 2022-07-12 10:58:¶

jsmeix commented at 2022-07-12 12:00:¶

pcahyna commented at 2022-07-12 13:48:¶

jsmeix commented at 2022-07-12 14:27:¶

pcahyna commented at 2022-07-12 14:33:¶

pcahyna commented at 2022-07-12 14:35:¶

jsmeix commented at 2022-07-12 14:37:¶

pcahyna commented at 2022-07-12 14:41:¶

#2781 Issue `closed`: Missing /usr/share/rear/output/PXE/default/820_copy_to_net.sh and PXE output fails with rsync protocol - DRLM issue 189¶