Re: [RFR] fex package
I've just noticed that your post to mentors:
http://lists.debian.org/debian-mentors/2008/11/msg00056.html
had some useful extra context.
Giuseppe Iuculano wrote:
> It uses inetd, and (debian) default installation takes over port 8080. User can
> change it editing /etc/services
Running out of inetd is sufficiently unusual that it might well be
worth hinting at in the package description, so that users don't
expect a freshly-installed F*EX server to be visibly "running".
(Wait, editing /etc/services? /etc/services says 8080 is
"webcache"; does fex mess around with that? Oh well, I'm wandering
miles out of debian-l10n-english's jurisdiction.)
>> Why not just mail the file? Or up/download it via FTP? These
>> methods may have disadvantages, but none of them intrinsically limit
>> the file size, so I don't understand why F*EX is advertised so
>> heavily on this basis.
>
> Email isn't conceived for file transfer.
> Do you think that sending an email with
> a 100MB file size attachment is a good idea?
If the only machine I control is a home PC connected to the Internet
by a dialup modem, it's quite possible that the _best_ solution is
to compress the file with rzip, chop it up and send the bits via a
series of e-mails.
> FTP should make its job, but I must
> create/delete account for every file, or create an anonymous FTP account.
No, I just set up anonymous FTP and make it read-only. Even easier,
"apt-get install apache2" and chuck the file in the webroot. That's
assuming I've got root access on a well-networked server, of course.
> Vincent Bernat wrote:
>
>> This kind of service is really useful for users that keep sending large
>> piece of data through mail servers and then complain that this does not
>> work. They need an easy service allowing to send large files without
>> learning something new (like a FTP client), which is almost as fast as
>> attaching a document to an email and provides the same privacy options
>> than an unencrypted email (so, uploading to a shared FTP is not an
>> option, unless you excessively tune the FTP server). Otherwise, they
>> will just keep sending files via mail.
Yes, so F*EX has advantages in terms of organising a particular
*workflow* that makes life easier for admins with many (perhaps
widely dispersed) non-technical users. That's its selling point, so
it needs to be clear from the description.
>> I see no explanation in /usr/share/doc/fex/SSL - only a shell
>> fragment with undeclared dependencies on openssl and xinetd (as
>> opposed to openbsd-inetd, which _is_ in the package dependencies).
>
> Right, upstream recommends xinetd and that doc uses it
It's not documentation, it's a script that won't work. SSL is
possible, but it'll take some effort to set up.
>> Data transferred unencrypted by default, authentication via
>> passwords sent in e-mails... this software was first released in
>> March, yet it's doing a passable impression of a nineties relic.
>
> Come on, I installed this service about a month ago, and feedbacks from my users
> are extremely positive. Why? Because it's easy and provides the same privacy
> options than an unencrypted email.
But isn't e-mail our benchmark _wrong_ solution? And in fact it
seems to me that files sent via F*EX are slightly less secure than
ones sent via gmail against some privacy dangers - for instance, the
danger that the _admin_ might not be trustworthy.
>> Presumably it has some big advantage that makes up for all this, but
>> I can't work out quite what its selling point is, given that it's
>> taken for granted that I have root access on a web-accessible host.
>
> Do you give root access to your user/customer ?
I don't need to. They tell me what file they're talking about, and
I put it on the webserver. F*EX is for situations where that
workflow isn't adequate.
After all this moaning the least I should do is suggest an
alternative first paragraph:
Description: web service for transferring very large files
F*EX (Frams's Fast File EXchange) is a service that can be used to
allow users anywhere on the Internet to exchange very large files
quickly and conveniently.
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Reply to: