Moving Recordings between two Humax Machines
- Thread starter escat
- Start date
prpr
Well-Known Member
Yes, but it's quite slow. CPU-bound rather than I/O-bound.
Standard FTP is faster, but not quite as simple.
Thanks for the prompt reply.
I realised that it would be slow, but I couldn't even get it to work. The problem seemed to be that the sftp command didn't seem to accept the private key in the .ssh/authorized_keys directory.
Is that using betaftpd (which I haven't used before), or some other FTP client-server?
Black Hole
May contain traces of nut
betaftpd is the CF alternative to the standard built-in FTP server, yes. To use it the (flaky and restricted) standard service must be turned off:
Menu >> Settings >> System >> Internet Setting >> FTP Server = OFF
...that's a different matter. To use the FTP server on each machine, you're going to be using a third device as an FTP client and pull down the recording from one then pushing it up to the other. I'm not aware of there being an FTP client within the CF.
What's needed is File Exchange Protocol (FXP), where a third machine could command a transfer between two other machines, but I'm not aware of that being available.
I know little of dropbear-ssh and greenend-sftp, but with encryption involved it's sure to be slow (unless thay can be used for straight FTP). The way I would do it is by network file sharing, either NFS (nfs-utils) or SMB (samba + cifs). With one machine's storage mounted into the file system of the other, the options for copying files from place to place become almost endless.
If this is a one-off, honestly it's quicker to use sneakernet (walking it across with a USB drive) than faff around trying to set up (reliable) electronic transfer. If this is required more regularly, perhaps you could explain what you are trying to achieve – there is often more than one way of skinning a cat. If all you want to do is play the recording from one machine using another (on the same network), we've got that covered.
I presume you are aware of the recordings being encrypted, and therefore unplayable on another machine, without intervention.
Last edited:
prpr
Well-Known Member
There certainly is. I asked, and af123 obliged.
Code:
humax ~ # opkg list|grep ftp
betaftpd - 0.0.8pre17-5 - BetaFTPD is a single-threaded FTP daemon, making it very fast
greenend-sftp - 1.0 - SFTP Server plugin.
tnftp - 20151004-3 - tnftp is a port of the NetBSD FTP client to other systems.Don't have time or energy to try this now, but I just use scp or rsync rather than S(FTP) most of the time.
Yes, betaftpd on one side, and tnftp (ftp) on the other.
Black Hole
May contain traces of nut
Presumably with a network file share mount?
Ooooh... just found tnftp in WebIF >> Package Management >> Available (with advanced packages enabled).
MymsMan
Ad detector
Recordings would need to be decrypted to be playable on the second humax machine.
If they are not already decrypted you could use
If they are not already decrypted you could use
wget or curl on the target machine to copy and decrypt the recordings at the same time. However you would need to know the DLNA URL for each file which would probably require writing a script if you have a largish number of recordings to process.Thanks to you both for very helpful answers.
OK, full disclosure: I have to confess that my question was at least as much one of intellectual curiosity (aka play) as it was of dire necessity. I have installed dropbear-ssh and greenend-sftp as part of improving my external security. The limited information that I could find out about these packages led me to believe that one could perform client-server transfers either way between two Humax machines. So I tried it. So far I've failed to get them to agree on the location of the required keys. Hence the question.
It would be convenient to move recordings in this way, but - as has been pointed out - the encryption overhead would outweigh any real benefit. (Though it might provide a convenient way of moving the much smaller files of my own code from one machine to another). But it seems from the above that the combination of betaftpd and tnftp might fill this role nicely? Could they both be installed on both machines, and do the transfer either way? (Another piece of intellectual curiosity!) Presumably, they would also permit the moving of files outside the "My Video" structure?
OK, full disclosure: I have to confess that my question was at least as much one of intellectual curiosity (aka play) as it was of dire necessity. I have installed dropbear-ssh and greenend-sftp as part of improving my external security. The limited information that I could find out about these packages led me to believe that one could perform client-server transfers either way between two Humax machines. So I tried it. So far I've failed to get them to agree on the location of the required keys. Hence the question.
It would be convenient to move recordings in this way, but - as has been pointed out - the encryption overhead would outweigh any real benefit. (Though it might provide a convenient way of moving the much smaller files of my own code from one machine to another). But it seems from the above that the combination of betaftpd and tnftp might fill this role nicely? Could they both be installed on both machines, and do the transfer either way? (Another piece of intellectual curiosity!) Presumably, they would also permit the moving of files outside the "My Video" structure?
Black Hole
May contain traces of nut
I don't see why not - there will be no confusion, because one makes FTP requests and the other services them. The particular server won't be confused because they are at separate IP addresses. Obviously you would need to operate tnftp on the command line, so it's not exactly user-friendly, whereas at least the same level of convenience can be achieved (on the command line) with a mounted external file system and the cp command.
There are many ways to do that. It's only the built-in Humax facilities (including the FTP server) which are restricted to My Video / My Music / My Photo and recognised media file types. You can do anything you like form the Telnet / Webshell command line using the Linux commands cp (copy), mv (move), ls (list directory), mkdir (create directory) etc.
WebIF >> Browse Media Files can be used as a GUI for file management (media files only), or what I do is access my Humii as NAS mounts from my PC's file manager - and then it's drag'n'drop (just inhibited by my slow and flaky home network)!
Why? Do you interact with your units via the external Internet?
Last edited:
Sorry, I've only just seen this. The recordings are already decrypted. I have now managed to move files using wget from one machine to another, but using the inbuilt ftp server protocols, rather than DLNA. I was interested in finding out if there was a less fiddly way than that.
Well, I'm afraid that takes us back to 'intellectual curiosity' - sorry. I wanted to use remote scheduling, which started me thinking more about security... and one thing led to another.
I'd still like to know whether the SSH/SFTP difficulty with key locations that I am encountering is something fundamental, or just down to my ignorance. Any insight would be appreciated. But otherwise, I've been given enough helpful insights to sate my curiosity on file movements in general. Many thanks to you all.
Black Hole
May contain traces of nut
Just to assure other readers: the RS service does not actively poll our HDR-FOXes, the rs package running on the HDR-FOX accesses RS periodically to upload status and check for instructions to download. This means all activity is initiated from the LAN side of the router and does not require any open ports for accesses initiated from the wild-west WAN side, and the router rejects incoming speculative probes.
I can't help you there, hopefully somebody with the right experience will come along and add to the collective wisdom.
Absolutely - yes. Sorry that I could have been read otherwise. It was realising that rs had been implemented in such a way as to avoid any security concerns, that caused me to think much more deeply about my whole set-up.
The .ssh/authorized_keys file should contain public keys.
prpr
Well-Known Member
No. You just copy a file from source to destination (usually one is a local path and the other is in the form "a.b.c.d:/path", depending on the direction of travel). Of course you need to set up the keys and stuff first if you want an easy life thereafter.
FWIW, I can't get the greenend client to do anything useful at all, and there seems to be s*d all documentation. The server seems OK (using a real Linux client).
Black Hole
May contain traces of nut
OK, I didn't realise rsync (or whatever) had to be running at both ends.
prpr
Well-Known Member
Only necessary to have an SSH daemon at one end (dropbear in our case).
If you don't want the overhead of ssh encryption then is is possible to run an {i}rsync[/i} daemon at one end of the connection. The possible disadvantage is that it allows copying of files without any authentication.
Edit: A basic authentication is now supported.
Edit: A basic authentication is now supported.
Last edited:
Oops! You're absolutely right, of course. Sorry about the slip - I'm still new to this game.
I think that's the problem that I ran into. I think it might be expressed as: "How can the private key generated by dropbear in the client Humax be accessed so that the SFTP extension can use it in its SSH connection to the Humax server?" Is that right?
If so, I wonder whether the latest release of dropbear might have a fix? The Humax package is built from release 2018.76-1. According to this website, the latest release, 2022.82, contains the following commentary:
and the following code:
I'm not expert enough to judge, whether this will fix the above problem, but it seems to be in the right area. If it is the problem, do we have any access to the pre-compiled version of the Humax dropbear-ssh package, or any other way of getting an updated version?