Re: [gentoo-user] Re: replacement for ftp?

[lee]

Kai Krakow <hurikhan77@×××××.com> writes:

> Am Sat, 29 Apr 2017 20:38:24 +0100
> schrieb lee <lee@××××××××.de>:
>
>> Kai Krakow <hurikhan77@×××××.com> writes:
>>
>> > Am Tue, 25 Apr 2017 15:29:18 +0100
>> > schrieb lee <lee@××××××××.de>:
>> >
>> >> since the usage of FTP seems to be declining, what is a replacement
>> >> which is at least as good as FTP?
>> >>
>> >> I'm aware that there's webdav, but that's very awkward to use and
>> >> missing features.
>> >
>> > If you want to sync files between two sites, try rsync. It is
>> > supported through ssh also. Plus, it's very fast also.
>>
>> Yes, I'm using it mostly for backups/copies.
>>
>> The problem is that ftp is ideal for the purpose, yet users find it
>> too difficult to use, and nobody uses it.  So there must be something
>> else as good or better which is easier to use and which ppl do use.
>
> Well, I don't see how FTP is declining, except that it is unencrypted.
> You can still use FTP with TLS handshaking, most sites should support
> it these days but almost none forces correct certificates because it is
> usually implemented wrong on the server side (by giving you
> ftp.yourdomain.tld as the hostname instead of ftp.hostingprovider.tld
> which the TLS cert has been issued for). That makes it rather pointless
> to use. In linux, lftp is one of the few FTP clients supporting TLS
> out-of-the-box by default, plus it forces correct certificates.

These certificates are a very stupid thing.  They are utterly
complicated, you have to self-sign them which produces warnings, and
they require to have the host name within them as if the host wasn't
known by several different names.

> But I found FTP being extra slow on small files, that's why I suggested
> to use rsync instead. That means, where you could use sftp (ssh+ftp),
> you can usually also use ssh+rsync which is faster.

That requires shell access.

What do you consider "small files"?  I haven't observed a slowdown like
that, but I haven't been looking for it, either.

> There's also the mirror command in lftp, which can be pretty fast, too,
> on incremental updates but still much slower than rsync.
>
>> I don't see how they would transfer files without ftp when ftp is the
>> ideal solution.
>
> You simply don't. FTP is still there and used. If you see something
> like "sftp" (ssh+ftp, not ftp+ssl which I would refer to as ftps), this
> is usually only ftp wrapped into ssh for security reasons. It just
> using ftp through a tunnel, but to the core it's the ftp protocol. In
> the end, it's not much different to scp, as ftp is really just only a
> special shell with some special commands to setup a file transfer
> channel that's not prone to interact with terminal escape sequences in
> whatever way those may be implemented, something that e.g. rzsz needs
> to work around.
>
> In the early BBS days, where you couldn't establish a second transfer
> channel like FTP does it using TCP, you had to send special escape
> sequences to put the terminal into file transfer mode, and then send
> the file. By that time, you used rzsz from the remote shell to initiate
> a file transfer. This is more the idea of how scp implements a file
> transfer behind the scenes.

IIRC, I used xmodem or something like that back then, and rzsz never
worked.

> FTP also added some nice features like site-to-site transfers where the
> data endpoints both are on remote sites, and your local site only is
> the control channel. This directly transfers data from one remote site
> to another without going through your local connection (which may be
> slow due to the dial-up nature of most customer internet connections).

Interesting, I didn't know that.  How do you do that?

> Also, FTP is able to stream multiple files in a single connection for
> transferring many small files, by using tar as the transport protocol,
> thus reducing the overhead of establishing a new connection per file.
> Apparently, I know only few clients that support that, and even fewer
> servers which that would with.
>
> FTP can be pretty powerful, as you see. It's just victim of its poor
> implementation in most FTP clients that makes you feel it's mostly
> declined. If wrapped into a more secure tunnel (TLS, ssh), FTP is still
> a very good choice for transferring files, tho not the most efficient.
> Depending on your use case, you get away much better using more
> efficient protocols like rsync.

So there isn't a better solution than ftp.  That's good to know because
I can say there isn't a better solution, and if ppl don't want to use
it, they can send emails or DVDs.


-- 
"Didn't work" is an error.