Re: [HEADSUP] Deprecation of the ftp support in pkg
Date: Mon, 24 Jan 2022 08:59:41 UTC
On Mon, Jan 24, 2022 at 12:12:20AM -0800, Chris wrote: > On 2022-01-23 10:19, Patrick M. Hausen wrote: > > Hi all, > > > > I did not really have an opinion on this, since we never used FTP, > > but I was a bit surprised by the suggestion to use SSH instead. > > > > It never occurred to us that anything but HTTP(S) was possible. > > We simply run Nginx in a jail serving the packages that Poudriere > > produces for us. Setup time/effort: 5 minutes. > > > > Now after this comment: > > > > > Am 22.01.2022 um 09:35 schrieb Chris <portmaster@bsdforge.com>: > > > I find it's less "housekeeping" to use ftp(1) setup through inetd(8) > > > for pkg repos, than > > > via ssh. > > > > I understand the appeal of FTP. > > Maybe this discussion is focusing on the wrong topic. Perhaps > > we should consider including a light weight way to serve HTTP(S) > > in base? Like Lighttpd, which as far as I know comes with a BSD > > 3-clause equivalent license. > > > > But then the general tendency has been to remove network services > > from base rather than introduce them. Like e.g. BIND. > > > > So I really have no idea what the general opinion is, just wanted > > to throw in that IMHO HTTPS is the best protocol to the task and > > if some way to serve that could be included in base, I for one would > > appreciate that. > > > > OTOH Chris, what's keeping you from installing a web server just > > serving static files? > Different environments/ different requirements. But habit as much as > anything else. > Ftp is trivial, has always been available. So I never even need to think > about it. > I perform mass installs/upgrades in large networks. There is no overhead > using ftp > either through a one-start | inetd. The clients are all started/used at will. > It seems to me that removing features also removes value. IMHO the gain from > the > removal of transports as trivial as ftp(1) bring little to the table for all > concerned. But that's just me. :-) > based on the discussion I am adding right now, a new protocol: tcp:// which uses the protocol we made on top of ssh way simple than ftp and capsicumized on the server side), but without the requirement for a ssh connection. This will enable people with performance concern but still willing to have data encrypted to use spiped or socat for example as a transport. And for other a simple inetd will work. on inetd.conf pkg stream tcp nowait nobody /usr/local/sbin/pkg -- -o SSH_RESTRICT_DIR=/mypackages ssh and define in /etc/services "pkg" to the port you want pkg to be serving its files to. for the repo on the pkg side: tcp://url:port/mypackages What do you think? For me as a maintainer it is very few lines of code to add, the protocol itself being already written, way easier to suppoer and it provides an interesting feature by the ability to serve via spiped or inetd. Best regards, Bapt