On 1/22/22 01:35, Chris wrote:
On 2022-01-22 00:09, Baptiste Daroussin wrote:
22 janv. 2022 08:47:57 Chris <portmas...@bsdforge.com>:
On 2022-01-21 23:31, Baptiste Daroussin wrote:
22 janv. 2022 08:25:47 Chris <portmas...@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
