Re: Vinum deprecation for FreeBSD 14 - are there any remaining Vinum users?

[Eugene Grosbein]

07.04.2021 12:49, Scott Bennett via freebsd-stable wrote:

>  At least w.r.t. gvinum's raid5, I can attest that the kernel panics
> are real.  Before settling on ZFS raidz2 for my largest storage pool, I
> experimented with gstripe(8), gmirror(8), graid3(8), and graid5(8) (from
> sysutils/graid5).  All worked reasonably well, except for one operation,
> namely, "stop".  Most/all such devices cannot actually be stopped because
> a stopped device does not *stay* stopped.  As soon as the GEOM device
> node is destroyed, all disks are retasted, their labels, if any, are
> recognized, and their corresponding device nodes are recreated and placed
> back on line. :-(  All of this happens too quickly for even a series of
> commands entered on one line to be able to unload the kernel module for
> the device node type in question, so there is no practical way to stop
> such a device once it has been started.

In fact, you can disable re-tasting with sysctl kern.geom.notaste=1,
stop an GEOM, clear its lables and re-enable tasting setting 
kern.geom.notaste=0 back.

>  A special note is needed here regarding gcache(8) and graid3(8).  The
> documentation of gcache parameters for sector size for physical devices
> and gcache logical devices is very unclear, such that a user must have the
> device nodes and space on them available to create test cases and do so,
> whereas a properly documented gcache(8) would obviate the need to set up
> such experiments.  There is similar lack of clarity in various size
> specifications for blocks, sectors, records, etc. in many of the man pages
> for native GEOM commands.

I found gcache(8) very nice at first, it really boosts UFS performance provided
you have extra RAM to dedicate to its cache. gcache can be stacked with gmirror 
etc.
but I found it guilty to some obscure UFS-related panics. It seems there were 
races or something.
No data loss, though as it is intended to be transparent for writing.

I was forced to stop using gcache for sake of stability and it's a shame.
For example, dump(8) speed-up due to gcache was 2x at least with big cache
comparing to dump -C32 without gcache.

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Vinum deprecation for FreeBSD 14 - are there any remaining Vinum users?

[Scott Bennett via freebsd-stable]

Ed,
 On Thu, 25 Mar 2021 13:25:44 -0400 Ed Maste  wrote:

>Vinum is a Logical Volume Manager that was introduced in FreeBSD 3.0,
>and for FreeBSD 5 was ported to geom(4) as gvinum. gvinum has had no
>specific development at least as far back as 2010 and it is not clear
>how well it works today. There are open PRs with reports of panics
>upon removing disks, etc. And, it also imposes an ongoing cost as it

 First off, the "port" to geom(4) was incomplete in that gvinum is
somehow not restricted to the geom(4) device nodes presented to it, but
instead always grabs the entire physical device and node to do its own
label processing.
 Second, gvinum is completely incompatible with GPT partitioning
because, regardless of the device nodes given it to use, it always writes
and reads its own label to and from the ends of the physical drives.
That means it overwrites the GPT secondary partition table with its own
labels, which soon causes error/warning messages from the kernel about
a damaged/missing secondary partition table and recommending a recovery
of that damaged/missing partition table.  Doing the recovery then will
overwrite gvinum's labels, which is likely to cause a kernel panic or
worse.
 My memory on gvinum's compatibility with glabel(8) labels is fuzzy
at the present remove, but I seem to recall having encountered problems
there, too.  This is not unique, unfortunately, to gvinum(8).  For
example, using glabel(8) to label swap partitions, as well as
bsdlabel(8)ed partitions, can lead to many unexpected problems.  Such
inconsistencies should be researched and fixed.
 GPT labels allow a partition type of "freebsd-vinum".  I did not try
to play with that one, but I suspect that it would not work correctly
because gvinum is somehow not limited to the GEOM device node for a
partition.  However, if you decide to keep gvinum(8) for some reason,
then this matter should be checked out in detail and its inconsistencies
fixed..
 At least w.r.t. gvinum's raid5, I can attest that the kernel panics
are real.  Before settling on ZFS raidz2 for my largest storage pool, I
experimented with gstripe(8), gmirror(8), graid3(8), and graid5(8) (from
sysutils/graid5).  All worked reasonably well, except for one operation,
namely, "stop".  Most/all such devices cannot actually be stopped because
a stopped device does not *stay* stopped.  As soon as the GEOM device
node is destroyed, all disks are retasted, their labels, if any, are
recognized, and their corresponding device nodes are recreated and placed
back on line. :-(  All of this happens too quickly for even a series of
commands entered on one line to be able to unload the kernel module for
the device node type in question, so there is no practical way to stop
such a device once it has been started.  Because gvinum's raid5 was
always unbearably slow and also subject to kernel panics, I soon excluded
it from further consideration.  GEOM is one of the brightest gems of
modern FreeBSD design.  GEOM's native functions should not be corrupted
or ignored as a result of a botched attempt to "modernize" an old
monstrosity like gvinum, which was originally written for a system that
lacked GEOM and has not fit well into a modern system that *has* GEOM,
not to mention GPT partitioning.
  All of these specific, native GEOM second-level devices otherwise
work pretty much as advertised.  graid5(8), however, was recently marked
as deprecated, which is a real shame.  I would vote for finishing its man
page, which is very incomplete, and for adding a subcommand to do some
sort of scrub procedure like many hardware RAID5 controllers do.  There
are perfectly valid reasons to use these devices in some situations
instead of ZFS, e.g., better performance for temporary/disposable data,
especially for situations involving millions of very short files like
ccache(1) directory trees, portmaster(8)'s $WRKDIRPREFIX, and likely
others.  gvinum(8) appears to have been broken in several ways since
FreeBSD 5.0, is unmaintained as you wrote, and should be deprecated and
eliminated for the reasons given above.  The simple GEOM devices provide
much the same flexibility that gvinum was intended to provide without
the need to learn gvinum's peculiar configuration method.  Once one
understands how GEOM devices work and can be stacked, they are generally
very simple to use in contrast to gvinum, which remains broken in
multiple ways.

>must be updated when other work is done (such as the recent MAXPHYS
>work). I suspect that by now all users have migrated to either
>graid(8) or ZFS.

 graid(8) is not always a good option.  If you read its man page,
you will see that RAID5 is usually only supported as read-only devices,
where it is supported at all.  This can be helpful for recovering data
from a proprietary RAID device, but is not generally useful for actively
used and updated data.  IOW, it can be helpful in a potentially large
number of situations for some users, especially for

Re: Deprecating base system ftpd?

[Pete Wright]

On 4/6/21 5:32 PM, Kevin P. Neal wrote:

On Tue, Apr 06, 2021 at 09:19:27AM +0100, Gerald de la Pascua wrote:

"Can I ask, for those who do enable it, why isn’t “sftp” acceptable (or
“scp”)?  Both provide a similar function, securely, which also works with a

I just tried to sftp to ftp.freebsd.org. Connection refused.

I can ftp (or ncftp) to ftp.freebsd.org and download whatever.

What's the current, secure way to download FreeBSD releases?


https?
https://download.freebsd.org/
https://download.freebsd.org/ftp/releases/ISO-IMAGES/13.0/
etc.


-p

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Portsnap no updates since 3/31/2021 ?

[Ed Maste]

On Tue, 6 Apr 2021 at 06:49, Robert Blayzor via freebsd-stable
 wrote:
>
> I have several servers running 11.4 and 12.2 that do nightly portsnap
> updates and the last time they've seen anything new is 3/31/2021, since
> then, nothing.
>
> This seems highly unusual since seems like there was always SOMETHING
> updated daily now nothing.

I am working on converting the portsnap build infrastructure to use
git rather than subversion. I do not yet have an ETA.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Deprecating base system ftpd?

[Chris]

On 2021-04-04 12:10, Ian Lepore wrote:

On Sat, 2021-04-03 at 16:39 -0400, Ed Maste wrote:

I propose deprecating the ftpd currently included in the base system
before FreeBSD 14, and opened review D26447
(https://reviews.freebsd.org/D26447) to add a notice to the man page.
I had originally planned to try to do this before 13.0, but it
dropped
off my list. FTP is not nearly as relevant now as it once was, and it
had a security vulnerability that secteam had to address.

I'm happy to make a port for it if anyone needs it. Comments?



I would find the removal of ftpd to be very inconvenient unless there
was a port/pkg to install it from.

If there is a port, it would only be useful if I could set PREFIX=/usr
when building/installing it, so that its behavior when installed as a
port/pkg would be identical to how it was when it was part of base (in
terms of where its config files are located).

I like the sound of that. Except that I'd like to do it one better and
suggest something along the lines of PORTS_MODULES in make.conf(5).
Maybe
PORTS_DAEMONS= ftpd sshd rpcbind nfsd ypbind inetd etc...

That might make it a tenable for situation for everyone. ;-)

--Chris


-- Ian

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Deprecating base system ftpd?

[Chris]

On 2021-04-03 13:45, Warner Losh wrote:

On Sat, Apr 3, 2021 at 2:40 PM Ed Maste  wrote:


I propose deprecating the ftpd currently included in the base system
before FreeBSD 14, and opened review D26447
(https://reviews.freebsd.org/D26447) to add a notice to the man page.
I had originally planned to try to do this before 13.0, but it dropped
off my list. FTP is not nearly as relevant now as it once was, and it
had a security vulnerability that secteam had to address.

I *strongly* object. MacOS also did this. Which made me discover that I
could simply copy my already built FreeBSD version over to all my MacOS
laptops and now enjoy an even better version than had previously existed.
This fact has made my use and need for FreeBSD' ftp even more important.
It has also made FreeBSD more popular with the Mac folks.
I depend upon ftp(1) && ftpd(8). I have on FreeBSD, for as many years as
FreeBSD has existed. I find the ssh and related ports are probed and
hammered on constantly. Whereas the ftp ports are quite rare by comparison.
So keeping sshd(8) and friends ports closed removes overhead. I have no
difficulty managing ftpd(8) via inet(8) && hosts.allow(5). Ftp && ftpd
are both trivial programs and should not be considered for removal.
If the reason for their suggested removal is "development overhead".
Please allow me to maintain both. I will happily assume full
responsibility for them.

Thank you for listening. :-)

--Chris


I'm happy to make a port for it if anyone needs it. Comments?



I already use one of the ports ftpd's for my needs, so this is fine by me.
I'm agnostic about whether we need a port for what was in base, but suspect
that's likely the path of least resistance.

Warner
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Portsnap no updates since 3/31/2021 ?

[Charles Sprickman via freebsd-stable]

> On Apr 6, 2021, at 7:10 AM, Gary Palmer  wrote:
> 
> On Tue, Apr 06, 2021 at 06:49:17AM -0400, Robert Blayzor via freebsd-stable 
> wrote:
>> I have several servers running 11.4 and 12.2 that do nightly portsnap
>> updates and the last time they've seen anything new is 3/31/2021, since
>> then, nothing.
>> 
>> This seems highly unusual since seems like there was always SOMETHING
>> updated daily now nothing.
> 
> git transition
> 
> https://wiki.freebsd.org/git 

Is portsnap still going to be supported?

I was noticing my local ports tree (which autoupdates every night with 
portsnap) was looking pretty dated, so I started googling and found talk on the 
forums that portsnap was going away (this was late 2020) and folks were 
suggesting svnlite and fetching updates via svn. Based on that, I just nuked my 
ports tree and grabbed it again via git, which seems to have worked.

What’s odd is that looking at that wiki entry, this port should have been up to 
date if I was using portsnap:

https://www.freshports.org/multimedia/plexmediaserver-plexpass/ 


But portsnap kept insisting that I was up to date even though I was seeing 
version 1.21.3.4015…

Anyhow, if anyone can confirm portsnap status, I’d love to know what the 
official line is and whether I should expect to see it around for awhile.

Is the git transition impacting freebsd-update at all? etcupdate?

Thanks,

Charles

> 
> Regular service should resume soon
> 
> Regards,
> 
> Gary
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Deprecating base system ftpd?

[Eugene Grosbein]

06.04.2021 15:37, aventa...@fastmail.fm wrote:

> Deprecating base system ftpd does seem to be a good idea, especially for 
> FreeBSD users wanting to use their computer
> as a workstation/desktop instead of as a server. I think the argument 
> becomes, "who is our target audience?"
> If the target audience is both server and desktop users, then minimizing the 
> base system makes a lot of sense.

Stock ftpd is single file /usr/libexec/ftpd sized 112KBytes uncompressed (71KB 
compressed with ZFS lz4 online compression)
and this is less than MAXPHYS=128K in current FreeBSD releases.
Minimizing the base system makes it another kind of Linux instead of solid 
operating system we love.


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Deprecating base system ftpd?

[Roderick]

On Tue, 6 Apr 2021, aventa...@fastmail.fm wrote:


Deprecating base system ftpd does seem to be a good idea,
especially for FreeBSD users wanting to use their computer as a
workstation/desktop instead of as a server. I think the argument becomes, 
"who is our target audience?" If the target audience is both server and
desktop users, then minimizing the base system makes a lot of sense. FreeBSD 
is not just for servers anymore.


I will never, never understand this kind of argumantation.

A desktop user, and desktop users like a lot of bloat with
few functionality, want to deprecate a meager program with a
clear functionality only because he do not need it.

R.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Deprecating base system ftpd?

[Kyle Evans]

On Tue, Apr 6, 2021 at 5:21 AM Andrea Brancatelli via freebsd-stable <
freebsd-stable@freebsd.org> wrote:

> On 2021-04-05 02:05, Daniel Morante via freebsd-stable wrote:
>
> > My vote is for no.
> >
> > Reasoning is simple... at what point does it stop?  By continuously
> moving stuff from base to ports, FreeBSD slowly becomes just a Kernel. 😉
>
> I strongly agree with this consideration.
>
>
Picking a random e-mail in this thread-

emaste already declared the effort abandoned because it was clear that
there's a strong objection... we don't need to continue litigating this? At
some point, a continuous flow of disagreement like this after the fact
becomes demotivating in general as it feels more like a dogpile than a
constructive effort on the original topic.

Thanks,

Kyle Evans
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Deprecating base system ftpd?

[aventador]

Deprecating base system ftpd does seem to be a good idea, especially for 
FreeBSD users wanting to use their computer as a workstation/desktop instead of 
as a server. I think the argument becomes, "who is our target audience?" If the 
target audience is both server and desktop users, then minimizing the base 
system makes a lot of sense. FreeBSD is not just for servers anymore. 

Best Regards,
Vic Thacker

On Tue, Apr 6, 2021, at 17:21, Gerald de la Pascua wrote:
> +1 again from me too, keep it,
> 
> It seems a pointless change of something that it seems a reasonable number
> of people are still using,  even if there are better tools now,
> 
> G
> 
> 
> On Mon, Apr 5, 2021 at 8:16 PM Ted Hatfield  wrote:
> 
> > On Mon, 5 Apr 2021, Patrick M. Hausen wrote:
> > > Hi all,
> > >
> > >> Am 03.04.2021 um 22:39 schrieb Ed Maste :
> > >> I'm happy to make a port for it if anyone needs it. Comments?
> > >
> > > A bit late to the party, but my take is: please just don't.
> > >
> > > I absolutely freaked out when Apple removed the telnet and ftp clients
> > > from Mac OS and I needed to reinstall them via MacPorts.
> > >
> > > People who manage any larger collection of networking gear *depend*
> > > on these outdated but simple services. Client and server side alike.
> > >
> > > TFTP is not going away, neither is FTP. I'm dead serious. Remote media
> > > via Supermicro IPMI in 2021? SMB1. Firmware updates for my UPS? FTP.
> > > Scanner/printer/fax all-in-one thingy? Uploads received fax transmissions
> > > via FTP. PBX? Uploads usage reports via FTP. This stuff is here to stay.
> > > In local networks, of course.
> > >
> > > But still even on "the Internet", FTP is the most used method for
> > customers
> > > of static website hosting. You cannot teach these people what an SSH key
> > is.
> > > Just my experience, but backed by a load of customer interactions over
> > more
> > > than 20 years ...
> > >
> > > Kind regards,
> > > Patrick
> > > --
> > >
> >
> >
> > Hear! Hear!
> >
> > Although I don't have any statistics to back this up this
> > has been my experience as well.
> >
> > Sincerely,
> >
> > Ted Hatfield
> >
> > ___
> > freebsd-stable@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
> >
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Portsnap no updates since 3/31/2021 ?

[Gary Palmer]

On Tue, Apr 06, 2021 at 06:49:17AM -0400, Robert Blayzor via freebsd-stable 
wrote:
> I have several servers running 11.4 and 12.2 that do nightly portsnap
> updates and the last time they've seen anything new is 3/31/2021, since
> then, nothing.
> 
> This seems highly unusual since seems like there was always SOMETHING
> updated daily now nothing.

git transition

https://wiki.freebsd.org/git

Regular service should resume soon

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Portsnap no updates since 3/31/2021 ?

[Robert Blayzor via freebsd-stable]

I have several servers running 11.4 and 12.2 that do nightly portsnap 
updates and the last time they've seen anything new is 3/31/2021, since 
then, nothing.


This seems highly unusual since seems like there was always SOMETHING 
updated daily now nothing.


--
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Deprecating base system ftpd?

[Stefan Bethke]

Am 06.04.2021 um 12:08 schrieb Helge Oldach :
> 
> Stefan Bethke wrote on Tue, 06 Apr 2021 11:29:34 +0200 (CEST):
>> Strato did disable FTP access over a year ago,
> 
> Actually it was effective October 20, 2020.

You are correct; I was remembering the announcement, not the switch off.

> and instructed customers on how to use SSH-based access instead,
> 
> They have a completely different incentive (avoiding cleartext passwords
> over the Internet, and reportedly they had a number of cases where
> customers where affected by password snooping) than a local admin person
> on a local network not exposed to the public.
> 
>> so it's definitely possible, and people are moving towards more secure
>> protocols, even when (non-technical) end users are affected.
> 
> No doubt about that. Any information about the ticket volume triggered
> by this deprecation?

I have no insight into Strato's operations, but from having to support a bunch 
of non-technical people who are customers, I'd say it was relatively painless, 
because Strato provided good instructions, and the (non-techincal) customers 
were using GUI clients already anyway where they only needed to switch from FTP 
to SFTP.

Stefan

--
Stefan BethkeFon +49 151 14070811



signature.asc
Description: Message signed with OpenPGP

Re: Deprecating base system ftpd?

[Miroslav Lachman]

On 06/04/2021 11:29, Stefan Bethke wrote:

Am 05.04.2021 um 21:01 schrieb Patrick M. Hausen :


But still even on "the Internet", FTP is the most used method for customers
of static website hosting. You cannot teach these people what an SSH key is.
Just my experience, but backed by a load of customer interactions over more
than 20 years ...


Strato did disable FTP access over a year ago, and instructed customers on how 
to use SSH-based access instead, so it's definitely possible, and people are 
moving towards more secure protocols, even when (non-technical) end users are 
affected.


Working for small / average web hosting company - we disabled plaintext 
FTP over 15 years ago. All customers are able to use FTP client 
supporting FTPeS (FTP with explicit TLS). So it definitely is possible 
if there is a will or enough pressure on customers.
On the other hand it does not matter to me if ftpd will be shipped in 
FreeBSD base for next 10 years. It is just a matter of maintaining it / 
man power for each release, testing etc.


Miroslav Lachman
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Deprecating base system ftpd?

[Eugene Grosbein]

05.04.2021 19:57, Alan Somers write:

> I wouldn't say that anything is "very good" when it has no test suite 
> whatsoever.

Many years of employment of ftpd in different environments (sometimes under 
heavy load) means something, too.
Maybe even more than synthetic tests.

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Deprecating base system ftpd?

[Andrea Brancatelli via freebsd-stable]

On 2021-04-05 02:05, Daniel Morante via freebsd-stable wrote:

> My vote is for no.
> 
> Reasoning is simple... at what point does it stop?  By continuously moving 
> stuff from base to ports, FreeBSD slowly becomes just a Kernel. 😉

I strongly agree with this consideration.  

---

Andrea Brancatelli
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Deprecating base system ftpd?

[Eugene Grosbein]

06.04.2021 1:27, Roger Leigh wrote:

>>> I propose deprecating the ftpd currently included in the base system
>>> before FreeBSD 14, and opened review D26447
>>> (https://reviews.freebsd.org/D26447) to add a notice to the man page.
>>> I had originally planned to try to do this before 13.0, but it dropped
>>> off my list. FTP is not nearly as relevant now as it once was, and it
>>> had a security vulnerability that secteam had to address.
>>>
>>> I'm happy to make a port for it if anyone needs it. Comments?
>>
>> I'm strongly against remove of stock ftpd. FTP is fastest protocol for both 
>> testing
>> and daily file transfer for trusted isolated segments, and even for WAN 
>> wrapped in IPSec.
>>
>> Our stock ftpd has very short backlog of security issues comparing with 
>> other FTP server implementations,
>> mostly linked with libc or other libraries and not with ftpd code itself.
>>
>> Please don't fix what ain't broken. Please.
> 
> How would you draw the line between something that must be part of the base 
> system vs. something
> that would be better off as part of the ports tree?  What bar should ftpd 
> have to meet to warrant remaining in base vs moving to ports?

POLA at least.

> Personally, I’ve never enabled it nor had any desire to.  FTP is, at this 
> point in time, thoroughly obsolescent,

Because someone told us so? 

> and I cannot imagine that it is something that most people enable, if they 
> are even aware of its existence.
> Why can’t it simply be installed from the ports for the occasional user who 
> still requires it?

This is one of services that should be available even if distfiles/packages are 
not reachable.
You know, sshd used to be in ports too.

> Can I ask, for those who do enable it, why isn’t “sftp” acceptable (or “scp”)?

sftp is not compatible with FTP clients and FTP is faster, basically it is 
plain TCP socket for data transfer.

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Deprecating base system ftpd?

[Stefan Bethke]

Am 05.04.2021 um 21:01 schrieb Patrick M. Hausen :
> 
> But still even on "the Internet", FTP is the most used method for customers
> of static website hosting. You cannot teach these people what an SSH key is.
> Just my experience, but backed by a load of customer interactions over more
> than 20 years ...

Strato did disable FTP access over a year ago, and instructed customers on how 
to use SSH-based access instead, so it's definitely possible, and people are 
moving towards more secure protocols, even when (non-technical) end users are 
affected.


Srefan

--
Stefan BethkeFon +49 151 14070811



signature.asc
Description: Message signed with OpenPGP

Re: Deprecating base system ftpd?

[Gerald de la Pascua]

+1 again from me too, keep it,

It seems a pointless change of something that it seems a reasonable number
of people are still using,  even if there are better tools now,

G


On Mon, Apr 5, 2021 at 8:16 PM Ted Hatfield  wrote:

> On Mon, 5 Apr 2021, Patrick M. Hausen wrote:
> > Hi all,
> >
> >> Am 03.04.2021 um 22:39 schrieb Ed Maste :
> >> I'm happy to make a port for it if anyone needs it. Comments?
> >
> > A bit late to the party, but my take is: please just don't.
> >
> > I absolutely freaked out when Apple removed the telnet and ftp clients
> > from Mac OS and I needed to reinstall them via MacPorts.
> >
> > People who manage any larger collection of networking gear *depend*
> > on these outdated but simple services. Client and server side alike.
> >
> > TFTP is not going away, neither is FTP. I'm dead serious. Remote media
> > via Supermicro IPMI in 2021? SMB1. Firmware updates for my UPS? FTP.
> > Scanner/printer/fax all-in-one thingy? Uploads received fax transmissions
> > via FTP. PBX? Uploads usage reports via FTP. This stuff is here to stay.
> > In local networks, of course.
> >
> > But still even on "the Internet", FTP is the most used method for
> customers
> > of static website hosting. You cannot teach these people what an SSH key
> is.
> > Just my experience, but backed by a load of customer interactions over
> more
> > than 20 years ...
> >
> > Kind regards,
> > Patrick
> > --
> >
>
>
> Hear! Hear!
>
> Although I don't have any statistics to back this up this
> has been my experience as well.
>
> Sincerely,
>
> Ted Hatfield
>
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Deprecating base system ftpd?

[Gerald de la Pascua]

"Can I ask, for those who do enable it, why isn’t “sftp” acceptable (or
“scp”)?  Both provide a similar function, securely, which also works with a
basic installation without any ports.  SSHFXP, the protocol underlying sftp
is better specified, less ambiguous and more fault tolerant and safe than
the FTP protocol ever was.  The client is better than most ftp clients, and
the server (/usr/libexec/sftp-server) is started on demand on a
per-connection basis.  What makes FTP more desirable than a service over
SSH which is (from a technical and usability point of view) a better"r FTP
than FTP ever was?"

Because we have a lot of legacy clients, in the field that use ftp to
transfer non sensitive data,
it's simple,  and I don't see the need to revisit this because it's an old
fashioned non encrypted protocol,
you may disagree that's fine,  but for many purposes it does the job.
Sure there may be better tools,  but I see no reason to re issue lots of
client apps that are built on this and are working fine needlessly,

G


On Mon, Apr 5, 2021 at 7:28 PM Roger Leigh  wrote:

> On 3 Apr 2021, at 22:21, Eugene Grosbein  wrote:
> >
> > 04.04.2021 3:39, Ed Maste wrote:
> >
> >> I propose deprecating the ftpd currently included in the base system
> >> before FreeBSD 14, and opened review D26447
> >> (https://reviews.freebsd.org/D26447) to add a notice to the man page.
> >> I had originally planned to try to do this before 13.0, but it dropped
> >> off my list. FTP is not nearly as relevant now as it once was, and it
> >> had a security vulnerability that secteam had to address.
> >>
> >> I'm happy to make a port for it if anyone needs it. Comments?
> >
> > I'm strongly against remove of stock ftpd. FTP is fastest protocol for
> both testing
> > and daily file transfer for trusted isolated segments, and even for WAN
> wrapped in IPSec.
> >
> > Our stock ftpd has very short backlog of security issues comparing with
> other FTP server implementations,
> > mostly linked with libc or other libraries and not with ftpd code itself.
> >
> > Please don't fix what ain't broken. Please.
>
> How would you draw the line between something that must be part of the
> base system vs. something that would be better off as part of the ports
> tree?  What bar should ftpd have to meet to warrant remaining in base vs
> moving to ports?
>
> Personally, I’ve never enabled it nor had any desire to.  FTP is, at this
> point in time, thoroughly obsolescent, and I cannot imagine that it is
> something that most people enable, if they are even aware of its
> existence.  Why can’t it simply be installed from the ports for the
> occasional user who still requires it?  Why should the base system contain
> obsolete stuff that few people will use?  Surely the ports tree serves this
> need better?
>
> Can I ask, for those who do enable it, why isn’t “sftp” acceptable (or
> “scp”)?  Both provide a similar function, securely, which also works with a
> basic installation without any ports.  SSHFXP, the protocol underlying sftp
> is better specified, less ambiguous and more fault tolerant and safe than
> the FTP protocol ever was.  The client is better than most ftp clients, and
> the server (/usr/libexec/sftp-server) is started on demand on a
> per-connection basis.  What makes FTP more desirable than a service over
> SSH which is (from a technical and usability point of view) a better FTP
> than FTP ever was?
>
> Kind regards,
> Roger
>
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Deprecating base system ftpd?

[Gerald de la Pascua]

Speaking for myself,  like some others here,  I would find the removal of
ftp inconvenient, and if it is removed,
please could we have it in an easy to install and configure port.

We have a number of apps that transfer data,  and legacy issues mean that
it's hard to transfer to another protocol.
It's not sensitive data so the security concerns aren't an issue to us.

thanks,

Gerald,


On Sat, Apr 3, 2021 at 9:40 PM Ed Maste  wrote:

> I propose deprecating the ftpd currently included in the base system
> before FreeBSD 14, and opened review D26447
> (https://reviews.freebsd.org/D26447) to add a notice to the man page.
> I had originally planned to try to do this before 13.0, but it dropped
> off my list. FTP is not nearly as relevant now as it once was, and it
> had a security vulnerability that secteam had to address.
>
> I'm happy to make a port for it if anyone needs it. Comments?
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Deprecating base system ftpd?

[Andrea Venturoli]

On 4/5/21 8:27 PM, Roger Leigh wrote:


Can I ask, for those who do enable it, why isn’t “sftp” acceptable (or “scp”)?


Because it's an *incompatible* replacement.

While I never enabled ftpd, I was once asked to.
I refused and enabled sftp instead: the problem was that for 99% of the 
customers on the other side of the wire, this wasn't the same thing.

It was hard to make them change their habits, their clients, etc...

That said, I vote for moving ftpd to ports.

Just my 2c.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"