#108 Issue `closed`: Relax-and-Recover asks password when using cifs to a public share¶

Labels: bug

dagwieers opened issue at 2012-06-10 21:34:¶

When using the following configuration:

OUTPUT=ISO
OUTPUT_URL=cifs://nas02/rear/

Rear asks for a password, while it should not ask for one (or at least it should try first without).

schlomo commented at 2012-06-10 21:42:¶

For NETFS_URL we supported additional options and had an example that would
use credentials= for this purpose... Maybe we should clone this for
OUTPUT_URL as well?

dagwieers commented at 2012-06-10 21:46:¶

Ok, I am confused. I would like to put the ISO image onto a CIFS share. I assumed the above configuration would in fact do that. However when looking in output/ISO/Linux-i386/90_transfer_image.sh the statement # The ISO has already been transferred by NETFS. assumes that I am using NETFS (?).

So I wondered, should I have used OUTPUT=NETFS instead ? But that leads to:

[root@moria rear]# rear -v -D mkrescue
Relax and Recover 1.13.0 / $Date$
Using log file: /var/log/rear/rear-moria.log
ERROR: You must specify either BACKUP_URL or BACKUP_MOUNTCMD and BACKUP_UMOUNTCMD !
Aborting due to an error, check /var/log/rear/rear-moria.log for details
Finished in 1 seconds

Which in itself is very strange too, since I ran rear mkrescue so it shouldn't bother me about any BACKUP configuration. (BACKUP= is in fact empty)

If I then change it to add unwanted BACKUP variables:

OUTPUT=NETFS
OUTPUT_URL=cifs://nas02/rear/
BACKUP=NETFS
BACKUP_URL=cifs://nas02/rear/

This happens:

[root@moria rear]# rear -v -D mkrescue
Relax and Recover 1.13.0 / $Date$
Using log file: /var/log/rear/rear-moria.log
Creating disk layout
Creating root FS layout
Copy files and directories
Copy binaries and libraries
Copying kernel modules
Checking udev
Create initramfs
Password: 
Copying resulting files to cifs location
ERROR: Could not copy usage file to cifs location
Aborting due to an error, check /var/log/rear/rear-moria.log for details
Finished in 50 seconds
Terminated

So it doesn't work as expected, and I don't even know whether I am doing it correctly either...

schlomo commented at 2012-06-10 21:51:¶

I think the OUTPUT_URL stuff is not complete and that we need to enable it
to use more code from NETFS_URL e.g. to support mount options.

dagwieers commented at 2012-06-10 21:56:¶

So the following configuration did what I wanted:

OUTPUT=ISO
OUTPUT_URL=cifs://nas02/rear/
BACKUP=NETFS
BACKUP_URL=cifs://nas02/rear/

Although I was only interested in having the rescue environment on the CIFS share using rear mkrscue. What is weird is that the BACKUP=NETFS part seems to have taken care of copying my OUTPUT file to the OUTPUT_URL ?

So conclusion:

Using cifs:// makes Rear ask for a password (even on public shares)
Using cifs:// in OUTPUT_URL requires a BACKUP=NETFS to work !?!
Command rear mkrescue requires a BACKUP_URL (anything really) even if an OUTPUT_URL is defined

I am convinced now that we need to reassess how this is supposed to work.

dagwieers commented at 2012-06-10 22:06:¶

Another weirdness is that if I do not specify an OUTPUT_URL in the above example, my rear output on screen says:

Excluding component fs:/var

I don't seen a connection there...

dagwieers commented at 2012-06-10 22:34:¶

@schlomo You are right, the documentation does not mention CIFS or NFS support for OUTPUT_URL. Although it happens to work if you push the right knobs...

kpieth commented at 2012-06-11 09:22:¶

What do you think of:
If OUTPUT_URL is set, then "./output/ISO/Linux-i386/90_transfer_image.sh" should do the work. If not, then the chosen BACKUP workflow cares about transferring the image.

dagwieers commented at 2012-06-11 15:28:¶

I moved the discussion wrt. the current OUTPUT_URL and BACKUP_URL mess to issue #37. So that this issue only relates to the CIFS password issue.

gdha commented at 2012-06-15 14:31:¶

When we have defined a BACKUP=NETFS method and we also defined a BACKUP_URL=cifs://cifs-server-name/share/path then a setting like BACKUP_OPTIONS="cred=/etc/rear/.cifs" will make sure that no credential will be asked.

I guess we only need to check the BACKUP_URL and BACKUP_OPTIONS and making it not dependent of a BACKUP method. This way we can easily use the same code for the OUTPUT_URL.

The bottom line is I'm in favor of using a credential definition (file).

dagwieers commented at 2012-06-15 18:42:¶

I guess the expectation for a public share is that you don't need credentials, and thus not need a credential definition file.

schlomo commented at 2012-06-16 21:13:¶

Isn't putting your backups on a public share setup for failure? I actually don't understand what is bad about the credentials file...

dagwieers commented at 2012-06-16 23:16:¶

@schlomo That is not the point, this obviously was part of me testing the CIFS code internally (triggering more than one issue). But it does make sense to put the recovery images on a "public" share. (Or at least a share that has certain ACLs set to not require a password)

BTW There is nothing bad about a credentials file per se, except maybe if you have no need for credentials ? What do you put in the credentials file for a public share ? Do we leave it empty ? Do we add empty values ? Do we add something that's not used ? It does not seem very obvious and need to be fixed or documented...

Also, it's not because I open a ticket that it should get the highest priority or that it requires someone to fix it in their own time. Issues are listed so someone who does think it is valuable to fix, can look into it. Or as a reference to others with a similar problem to chime in. Or so we do not forget about it.

gdha commented at 2012-06-25 09:29:¶

With the default ,guest option my cred= option is broken:

2012-06-25 12:17:21 ERROR: Mount command 'mount -v -o cred=/home/gdha/projects/rear/rear-1.13.0/etc/rear/.cifs.phist,guest //hpx189.ncsbe.eu.jnj.com/phist /tmp/rear.d5jqHyre7SMb0CL/outputfs' failed.

To be honest for security reason I would not add guest option to cifs. Is it possible to revert this change?

dagwieers commented at 2012-06-25 10:00:¶

Sure, please revert.

gdha commented at 2012-06-25 10:47:¶

it works with guest also. I leave it this way...

pasarn commented at 2012-09-07 10:05:¶

Hello,

I can not mount the cifs target. The command from gdha:

With the default ,guest option my cred= option is broken:

2012-06-25 12:17:21 ERROR: Mount command 'mount -v -o cred=/home/gdha/projects/rear/rear-1.13.0/etc/rear/.cifs.phist,guest //hpx189.ncsbe.eu.jnj.com/phist /tmp/rear.d5jqHyre7SMb0CL/outputfs' failed.
To be honest for security reason I would not add guest option to cifs. Is it possible to revert this change?

When i remove the guest parameter from global_functions.sh it works.

[Export of Github issue for rear/rear.]

#108 Issue closed: Relax-and-Recover asks password when using cifs to a public share¶