[Rear-users] Broken ISO_URL/OUTPUT_URL

Schlomo Schapiro schlomo at schapiro.org
Wed Aug 31 15:50:47 CEST 2011


did we not want to have OUTPUT_URL as the place where things should go?

We could use http:// vs. dav:// to distinguish between simple POST vs.

I have to say that IMHO having OUTPUT_URL=http://... is not really
self-explanatory because it does not tell how the files should go there
(PUT,POST,Form Upload,...).

FYI, you could also use SMTP to centralise the result ISOs, RESULT_EMAIL
was designed for that.


On 31.08.2011 15:20, Dag Wieers wrote:
> Hi,
> One of my setups at a customer was using:
>      ISO_URL=http://blade03:18080/rear/
> With the purpose of pushing the ISO images using lftp to the requested 
> ISO_URL. This is a simple way of centralizing the Rear ISO images to a 
> single location (be it a virtualization host, a PXE boot server or a 
> mounted USB disks for ofsite storage).
> So far so good. This worked fine using svn 620, but apparently is broken 
> now on svn704, because somehow Rear prefers to mount my HTTP url.
>      Relax and Recover 0.0.0 / 2011-06-27 09:07:15 +0200
>      Creating disk layout
>      Creating root FS layout
>      Copy files and directories
>      Copy program files & libraries
>      Copying kernel modules
>      Checking udev
>      Create initramfs
>      ERROR: Mount command 'mount -v -t http -o rw,noatime blade03:18080:/rear/ /tmp/rear.jXGDzdEDNDI3136/outputfs' failed.
>      Aborting due to an error, check /tmp/rear-linmgt01.log for details
>      Finished in 59 seconds
>      Terminated
> I am not very fond of the implicit nature of doing mounts. That was why we 
> opted to have ISO_URL instead of NETFS_URL. But that is now broken.
> I guess we need to rethink the various workflows and make it much more 
> simple so that someone's changes do not inadvertently break someone else's 
> working setup (because it is clear what something is for, rather than 
> being too smart).
> Now considering that with FUSE davfs one could actually mount an HTTP url, 
> we may need some other logic to explicitly tell what action is desired. 
> Not sure if that means we want to have:
> or rather move this logic so some other place, but the 
> output/default/10_mount_output_path.sh and 
> output/default/98_umount_output_dir.sh seems ill-fated as output does not 
> necessarily means I want to mount something (eg. file:///, http:///, 
> rsync:///).
> Cfr. output/ISO/Linux-i386/90_transfer_image.sh
> So, what is the prefered solution here so I can convert the current code 
> to something that works again :-)
> Kind regards,

More information about the rear-users mailing list