Re: [HEADSUP] Deprecation of the ftp support in pkg

On 1/22/22 01:35, Chris wrote:
> On 2022-01-22 00:09, Baptiste Daroussin wrote:
>> 22 janv. 2022 08:47:57 Chris <portmaster@bsdforge.com>:
>>
>>> On 2022-01-21 23:31, Baptiste Daroussin wrote:
>>>> 22 janv. 2022 08:25:47 Chris <portmaster@bsdforge.com>:
>>>> On 2022-01-20 06:25, Baptiste Daroussin wrote:
>>>>>> Hello everyone,
>>>>>> We plan to remove the support for fetching packages over ftp for 
>>>>>> the next
>>>>>> releases of pkg (probably 1.18)
>>>>> Must be a stupid question. But I'll ask anyway; Why the effort to 
>>>>> start removing transports?
>>>> Because maintaining ftp has a cost, number of line of code, user 
>>>> support etc.
>>>> if you have a strong reason to use ftp which
>>>>>> cannot be fixed by switching to any other supported protocols like 
>>>>>> ssh or http,
>>>>>> please do share.
>>>>> Local repos.
>>>>> ftp(1) is cheap. Other transports are (usually) more expensive.
>>>>>
>>> Thanks for taking the time to reply.
>>>
>>>> ssh which is supported is as cheap if not cheaper.
>>> Technically that's incorrect. But as I see you've also rejected 2 
>>> other requests. It's
>>> clear that this topic is not actually up for debate. So I'll say no 
>>> more on the subject.
>>>> Bapt
>>> -- Chris
>>
>> It is up for debate, I have been told we need something in base to 
>> which I replied
>> ssh is in base, so fill that requirement, you have said it is cheap no 
>> explaining
>> what you call cheap, I say ssh is cheap as well as in not more 
>> complicated to
>> configure, provide a path and here we are.
>>
>> You asked the reason for the removal I explained them, if ftp was free 
>> of cost I
>> won t care about keeping it.
>>
>> So up to now noone gave an detailed argument in favour of ftp, which 
>> ssh or other
>> transport cannot provide as well.
> Fair enough. Sorry if I misunderstood.
> I find it's less "housekeeping" to use ftp(1) setup through inetd(8) for 
> pkg repos, than
> via ssh. I have no keys to care for. I am able to setup enormous 
> intranets w/o any key exchange.
> ftp/inetd is in base. It seems "cheaper" both in resources as well as 
> setup / usage. This works
> equally well for internets with the addition of an allow list (IP 
> addresses). Where anything
> not in that list is dropped.

If you want to let it all hang out without encryption infrastructure
"inside" with base facilities only, another possibility is NFSv4 with,
uh, "sys" authentication.  I use this to follow a monthly stable
+ packages full rebuild and install/upgrade.  I *love* it.

Server:

$ grep nfs /etc/rc.conf
nfs_server_enable="YES"
nfs_server_flags="-u -t -n 5"
nfsv4_server_enable="YES"
nfsuserd_enable="YES"
nfsuserd_flags="-domain pinyon.lan"
nfscbd_enable="YES"
$ cat /etc/exports:
/     -maproot=root
V4: / -network 10.0.0.0/16

Client:
$ grep nfs /etc/rc.conf
nfs_client_enable="YES"

I use autofs and the following

$ cat /etc/auto_master
# Automounter master map, see auto_master(5) for details.
/- autofs/bruno-nfs
$ cat /etc/autofs/bruno-nfs
# See auto_master(5).
/mnt/bruno/packages  -intr,nfsv4,minorversion=1 bruno:/export/packages
/usr/src  -intr,nfsv4,minorversion=1 bruno:/usr/src
/usr/obj -intr,nfsv4,minorversion=1 bruno:/usr/obj
/usr/ports -intr,nfsv4,minorversion=1 bruno:/usr/ports

NFS is not without other, possibly deal-breaking aggravations.
I have found it impossible to maintain without absolute consistency
of UID/GID assignments across the intranet.  Yeah, no, I couldn't
get nfsuserd to fix that.  I also consider
SPOF kerberos or building an internal TLS cert infrastructure
to be absurd wastes of my unpaid finite time.  People
getting paid would surely do one or the other.

hth,
Russell

> 
> That's my take on it.
> Thank you for your thoughtful reply.
>>
>> Bapt
> -- Chris