Re: Deprecating base system ftpd?
I think this is an excellent start. My shopping list includes: - remove ftp(1) - remove ftpd(8) - remove telnet(1) - remove telnetd(8) - remove ftp:// and http:// from libfetch. This is 2021 and we should all use https://. - replace DNS lookups with DoH and/or DoT. Why let your ISP see your DNS traffic? I wonder how many people use YP/NIS (man 8 yp)? It's a nifty concept; I played around with it last century... I believe there is still an open PR in bugzilla I created (can't find it right now, used a diffent email address back then, although same username). Removing it from base (if it should be done at all) looks very complicated and therefore creating a port equally so. I know this topic (removing ftpd) is closed, so perhaps this should be a new one (removing YP/NIS)? ie. no development on yp has been done for over a decade. My view: remove neither -andyf ___ 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?
Cy Schubert writes: > In message om> > , Ed Maste writes: > > 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 think this is an excellent start. My shopping list includes: > > - remove ftp(1) > - remove ftpd(8) > - remove telnet(1) > - remove telnetd(8) > - remove ftp:// and http:// from libfetch. This is 2021 and we should all > use https://. > - replace DNS lookups with DoH and/or DoT. Why let your ISP see your DNS > traffic? > > > > > I'm happy to make a port for it if anyone needs it. Comments? > > I've started working on splitting ftp and ftpd into an external git repo. > The problem I've encountered is that though only ftp and ftpd are left the > resultant repo is still 1.2 GB. If my last attempt fails, there is a choice > between a 1.2 GB repo and burning ftp forever then the choice is clear: > burn it forever. The best I can do to separate libexec/ftpd out into its own repo is 596 MB (ZFS lz4 compressed). The worst was 1.5 GB. I suppose 596 MB will do. If we want to make it smaller then history will need to take a back seat. We can do a port with it now. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. ___ 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"
13.0-RELEASE MemStick does not install EFI Loader
Hi all together, I have downloaded the memstick (link below), dd it to a usb stick, added the `installerconfig` (see below) to `/etc/installerconfig` and tried to install FreeBSD 13.0-RELEASE automatically to a PC. After rebooting the system came not up, because the `efi` partition should be created by `bsdinstall` was empty and did not include the `bootx64.efi`. After mounting the `efi` partition, creating the directory and copied the `/boot/loader.efi` to `/efi/boot/bootx64.efi` the new installed system booted up. After `mount -u -rw /`, adding some `f_dprintf` to `/usr/libexec/bsdinstall/bootconfig` and a manual installation with `bsdinstall script /root/installerconfig | tee /root/installer.log` it generates this log: - https://gitlab.com/-/snippets/2105237 This log indicates me, that the `efi` partition is not mounted while the `bootconfig` script tries to copy the `loader` to it... see below the extract from the `installer.log`. MemStick: - https://download.freebsd.org/ftp/releases/amd64/amd64/ISO-IMAGES/13.0/FreeBSD-13.0-RELEASE-amd64-memstick.img installerconfig: ``` export nonInteractive="YES" export ZFSBOOT_DISKS=ada0 DISTRIBUTIONS="kernel.txz base.txz" #!/bin/sh # see `man bsdinstall` sysrc ifconfig_DEFAULT=DHCP sysrc sshd_enable=YES ``` installer.log: ``` DEBUG: Running installation step: bootconfig DEBUG: dialog.subr: DEBUG_SELF_INITIALIZE=[] DEBUG: UNAME_S=[FreeBSD] UNAME_P=[amd64] UNAME_R=[13.0-RELEASE] DEBUG: common.subr: Successfully loaded. DEBUG: uname -m => amd64 DEBUG: mount => /dev/ufs/FreeBSD_Install on / (ufs, local) devfs on /dev (devfs) tmpfs on /tmp (tmpfs, local) tmpfs on /var (tmpfs, local) zroot/ROOT/default on /mnt (zfs, local, noatime, nfsv4acls) zroot/tmp on /mnt/tmp (zfs, local, noatime, nosuid, nfsv4acls) zroot/usr/home on /mnt/usr/home (zfs, local, noatime, nfsv4acls) zroot/usr/ports on /mnt/usr/ports (zfs, local, noatime, nosuid, nfsv4acls) zroot/usr/src on /mnt/usr/src (zfs, local, noatime, nfsv4acls) zroot/var/audit on /mnt/var/audit (zfs, local, noatime, noexec, nosuid, nfsv4acls) zroot/var/crash on /mnt/var/crash (zfs, local, noatime, noexec, nosuid, nfsv4acls) zroot/var/log on /mnt/var/log (zfs, local, noatime, noexec, nosuid, nfsv4acls) zroot/var/mail on /mnt/var/mail (zfs, local, nfsv4acls) zroot/var/tmp on /mnt/var/tmp (zfs, local, noatime, nosuid, nfsv4acls) zroot on /mnt/zroot (zfs, local, noatime, nfsv4acls) DEBUG: Installing loader.efi onto ESP DEBUG: mkdir -p "/mnt/boot/efi//efi/freebsd" "/mnt/boot/efi//efi/boot" DEBUG: cp "/mnt/boot/loader.efi" "/mnt/boot/efi//efi/freebsd/loader.efi" DEBUG: Creating UEFI boot entry DEBUG: efibootmgr --create --activate --label "FreeBSD" --loader "/mnt/boot/efi//efi/freebsd/loader.efi" DEBUG: Finished configuring ESP ``` Regards from Lübeck, Nils Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff Registered office: Verl, Germany | Register court: Guetersloh HRA 7075 ___ 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: using interface groups in pf tables stopped working in 13.0-RELEASE
On 2021-04-14 11:04, Chris wrote:
On 2021-04-14 10:44, Peter Ankerstål wrote:
const { trusted:network mgmt:network dmz:network
guest:network edmz:network \
admin:network iot:network client:network }
If I reload the configuration I get the following:
# pfctl -f /etc/pf.conf
/etc/pf.conf:12: cannot create address buffer: Invalid argument
pfctl: Syntax error in config file: pf rules not loaded
Some changes in the pf source have been made over the last couple
of months. The error returned appears to be related. It appears
that your running into a table size/count and memory allocation
related error. The first change moved/changed memory allocation to
kernel space, requiring one to increase allocation via loader.conf(5).
It was recently moved back to userspace allowing one to make changes
to a running system via sysctl.conf(5) or the commandline.
IOW if your on the recent change you should be able to simply
increase your table count by executing something like:
# echo "set limit table-entries " | pfctl -m -f -
OTOH if your stuck with the change in kernelspace, increase
net.pf.request_maxcount=
by some amount in loader.conf(5). If you are on the newer userspace
change, you can issue the sysctl(8) command at your terminal for
net.pf.request_maxcount=
as well.
I dont think so. Everything works normally if I switch from group name to
interface name
in the config.
Sure. I only mentioned it because 1) the error you received looked almost
exactly
the same as the one I encountered after the (pf source) changes, 2) alot of
work
has been done recently (as I mentioned above). :-)
I'll defer to kp@ (Kristof Provost) for more insightful possibilities. As
he's done
most all the recent work. :-)
--Chris
CC'ing pf@ for better coverage of your problem.
It seems to me that pf for some reason changed how it interprets group
names
differently from
12.2-RELEASE-p4 and 13.0-RELEASE.
I dont really get how "anchor in from trusted:network” can resolve to
"anchor in inet6 all”
/Peter.
___
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: using interface groups in pf tables stopped working in 13.0-RELEASE
On 2021-04-14 10:44, Peter Ankerstål wrote:
const { trusted:network mgmt:network dmz:network
guest:network edmz:network \
admin:network iot:network client:network }
If I reload the configuration I get the following:
# pfctl -f /etc/pf.conf
/etc/pf.conf:12: cannot create address buffer: Invalid argument
pfctl: Syntax error in config file: pf rules not loaded
Some changes in the pf source have been made over the last couple
of months. The error returned appears to be related. It appears
that your running into a table size/count and memory allocation
related error. The first change moved/changed memory allocation to
kernel space, requiring one to increase allocation via loader.conf(5).
It was recently moved back to userspace allowing one to make changes
to a running system via sysctl.conf(5) or the commandline.
IOW if your on the recent change you should be able to simply
increase your table count by executing something like:
# echo "set limit table-entries " | pfctl -m -f -
OTOH if your stuck with the change in kernelspace, increase
net.pf.request_maxcount=
by some amount in loader.conf(5). If you are on the newer userspace
change, you can issue the sysctl(8) command at your terminal for
net.pf.request_maxcount=
as well.
I dont think so. Everything works normally if I switch from group name to
interface name
in the config.
Sure. I only mentioned it because 1) the error you received looked almost
exactly
the same as the one I encountered after the (pf source) changes, 2) alot of
work
has been done recently (as I mentioned above). :-)
I'll defer to kp@ (Kristof Provost) for more insightful possibilities. As
he's done
most all the recent work. :-)
--Chris
It seems to me that pf for some reason changed how it interprets group names
differently from
12.2-RELEASE-p4 and 13.0-RELEASE.
I dont really get how "anchor in from trusted:network” can resolve to
"anchor in inet6 all”
/Peter.
___
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: using interface groups in pf tables stopped working in 13.0-RELEASE
const { trusted:network mgmt:network dmz:network
>> guest:network edmz:network \
>>admin:network iot:network client:network }
>> If I reload the configuration I get the following:
>> # pfctl -f /etc/pf.conf
>> /etc/pf.conf:12: cannot create address buffer: Invalid argument
>> pfctl: Syntax error in config file: pf rules not loaded
> Some changes in the pf source have been made over the last couple
> of months. The error returned appears to be related. It appears
> that your running into a table size/count and memory allocation
> related error. The first change moved/changed memory allocation to
> kernel space, requiring one to increase allocation via loader.conf(5).
> It was recently moved back to userspace allowing one to make changes
> to a running system via sysctl.conf(5) or the commandline.
> IOW if your on the recent change you should be able to simply
> increase your table count by executing something like:
> # echo "set limit table-entries " | pfctl -m -f -
> OTOH if your stuck with the change in kernelspace, increase
> net.pf.request_maxcount=
> by some amount in loader.conf(5). If you are on the newer userspace
> change, you can issue the sysctl(8) command at your terminal for
> net.pf.request_maxcount=
> as well.
I dont think so. Everything works normally if I switch from group name to
interface name
in the config.
It seems to me that pf for some reason changed how it interprets group names
differently from
12.2-RELEASE-p4 and 13.0-RELEASE.
I dont really get how "anchor in from trusted:network” can resolve to "anchor
in inet6 all”
/Peter.
___
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: using interface groups in pf tables stopped working in 13.0-RELEASE
On 2021-04-14 07:16, Peter Ankerstål wrote:
In pf I use the interface group syntax alot to make the configuration more
readable. All interfaces are assigned to a group representing its use/vlan
name.
For example:
ifconfig_igb1_102="172.22.0.1/24 group iot description 'iot vlan' up"
ifconfig_igb1_102_ipv6="inet6 2001:470:de59:22::1/64"
ifconfig_igb1_300="172.26.0.1/24 group mgmt description 'mgmt vlan’ up"
ifconfig_igb1_300_ipv6="inet6 2001:470:de59:26::1/64”
in pf.conf I use these group names all over the place. But since I upgraded
to
13.0-RELEASE it no longer works to define a table using the :network syntax
and
interface groups:
tableconst { trusted:network mgmt:network dmz:network
guest:network edmz:network \
admin:network iot:network client:network }
If I reload the configuration I get the following:
# pfctl -f /etc/pf.conf
/etc/pf.conf:12: cannot create address buffer: Invalid argument
pfctl: Syntax error in config file: pf rules not loaded
Some changes in the pf source have been made over the last couple
of months. The error returned appears to be related. It appears
that your running into a table size/count and memory allocation
related error. The first change moved/changed memory allocation to
kernel space, requiring one to increase allocation via loader.conf(5).
It was recently moved back to userspace allowing one to make changes
to a running system via sysctl.conf(5) or the commandline.
IOW if your on the recent change you should be able to simply
increase your table count by executing something like:
# echo "set limit table-entries " | pfctl -m -f -
OTOH if your stuck with the change in kernelspace, increase
net.pf.request_maxcount=
by some amount in loader.conf(5). If you are on the newer userspace
change, you can issue the sysctl(8) command at your terminal for
net.pf.request_maxcount=
as well.
HTH
--Chris
I have tried to use just one network, double check the interface group
setting and
so on, but with no luck.
to use actual interface works just fine:
table{ igb1.300:network }
but using the group fails:
# ifconfig -g mgmt
igb1.300
table{ mgmt:network }
# pfctl -f /etc/pf.conf
/etc/pf.conf:12: cannot create address buffer: Invalid argument
pfctl: Syntax error in config file: pf rules not loaded
Any ideas?
Thanks!
/Peter.
___
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: stable/13, vm page counts do not add up
On 14/04/2021 16:32, Mark Johnston wrote:
On Wed, Apr 14, 2021 at 02:21:44PM +0300, Andriy Gapon wrote:
On 14/04/2021 00:18, Mark Johnston wrote:
fbt::vm_page_unwire:entry
/args[0]->oflags & 0x4/
{
@unwire[stack()] = count();
}
Unrelated report, dtrace complains about this probe on my stable/13 system:
failed to resolve translated type for args[0]
And I do not have any idea why...
There was a regression, see PR 253440. I think you have the fix
already, but perhaps not. Could you show output from
"dtrace -lv -n fbt::vm_page_unwire:entry"?
dtrace -lv -n fbt::vm_page_unwire:entry
ID PROVIDERMODULE FUNCTION NAME
54323fbtkernelvm_page_unwire entry
Probe Description Attributes
Identifier Names: Private
Data Semantics: Private
Dependency Class: Unknown
Argument Attributes
Identifier Names: Private
Data Semantics: Private
Dependency Class: ISA
Argument Types
args[0]: (unknown)
args[1]: (unknown)
It seems that I should have the fix, but somehow I still have the problem.
I've been doing NO_CLEAN builds for a long while, so maybe some stale file
didn't get re-created...
It looks that dt_lex.c under /usr/obj is rather dated.
... I've removed that file and rebuilt libdtrace and everything is okay now.
Thank you.
From ctfdump:
[27290] FUNC (vm_page_unwire) returns: 38 args: (1463, 3)
<1463> TYPEDEF vm_page_t refers to 778
<778> POINTER (anon) refers to 3575
<3575> STRUCT vm_page (104 bytes)
plinks type=3563 off=0
listq type=3558 off=128
object type=3564 off=256
pindex type=3565 off=320
phys_addr type=42 off=384
md type=3571 off=448
ref_count type=31 off=640
busy_lock type=31 off=672
a type=3573 off=704
order type=3 off=736
pool type=3 off=744
flags type=3 off=752
oflags type=3 off=760
psind type=2167 off=768
segind type=2167 off=776
valid type=3574 off=784
dirty type=3574 off=792
--
Andriy Gapon
--
Andriy Gapon
___
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: using interface groups in pf tables stopped working in 13.0-RELEASE
> On 14 Apr 2021, at 16:16, Peter Ankerstål wrote:
>
> In pf I use the interface group syntax alot to make the configuration more
> readable. All interfaces are assigned to a group representing its use/vlan
> name.
It seems that the rest of my ruleset is also affected by this, and interface
groups combined with :network no longer work.
For example I have this anchor:
anchor in from trusted:network {
}
which before resolved to
anchor in inet from 172.25.0.0/24 to any {
}
but now resolves to:
anchor in inet6 all {
}
/Peter.
___
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"
using interface groups in pf tables stopped working in 13.0-RELEASE
In pf I use the interface group syntax alot to make the configuration more
readable. All interfaces are assigned to a group representing its use/vlan
name.
For example:
ifconfig_igb1_102="172.22.0.1/24 group iot description 'iot vlan' up"
ifconfig_igb1_102_ipv6="inet6 2001:470:de59:22::1/64"
ifconfig_igb1_300="172.26.0.1/24 group mgmt description 'mgmt vlan’ up"
ifconfig_igb1_300_ipv6="inet6 2001:470:de59:26::1/64”
in pf.conf I use these group names all over the place. But since I upgraded to
13.0-RELEASE it no longer works to define a table using the :network syntax and
interface groups:
tableconst { trusted:network mgmt:network dmz:network
guest:network edmz:network \
admin:network iot:network client:network }
If I reload the configuration I get the following:
# pfctl -f /etc/pf.conf
/etc/pf.conf:12: cannot create address buffer: Invalid argument
pfctl: Syntax error in config file: pf rules not loaded
I have tried to use just one network, double check the interface group setting
and so on, but with no luck.
to use actual interface works just fine:
table{ igb1.300:network }
but using the group fails:
# ifconfig -g mgmt
igb1.300
table{ mgmt:network }
# pfctl -f /etc/pf.conf
/etc/pf.conf:12: cannot create address buffer: Invalid argument
pfctl: Syntax error in config file: pf rules not loaded
Any ideas?
Thanks!
/Peter.
___
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: stable/13, vm page counts do not add up
On Wed, Apr 14, 2021 at 02:21:44PM +0300, Andriy Gapon wrote:
> On 14/04/2021 00:18, Mark Johnston wrote:
> > fbt::vm_page_unwire:entry
> > /args[0]->oflags & 0x4/
> > {
> > @unwire[stack()] = count();
> > }
>
> Unrelated report, dtrace complains about this probe on my stable/13 system:
> failed to resolve translated type for args[0]
>
> And I do not have any idea why...
There was a regression, see PR 253440. I think you have the fix
already, but perhaps not. Could you show output from
"dtrace -lv -n fbt::vm_page_unwire:entry"?
>
> From ctfdump:
>[27290] FUNC (vm_page_unwire) returns: 38 args: (1463, 3)
>
><1463> TYPEDEF vm_page_t refers to 778
><778> POINTER (anon) refers to 3575
><3575> STRUCT vm_page (104 bytes)
> plinks type=3563 off=0
> listq type=3558 off=128
> object type=3564 off=256
> pindex type=3565 off=320
> phys_addr type=42 off=384
> md type=3571 off=448
> ref_count type=31 off=640
> busy_lock type=31 off=672
> a type=3573 off=704
> order type=3 off=736
> pool type=3 off=744
> flags type=3 off=752
> oflags type=3 off=760
> psind type=2167 off=768
> segind type=2167 off=776
> valid type=3574 off=784
> dirty type=3574 off=792
>
> --
> Andriy Gapon
___
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: stable/13, vm page counts do not add up
On 14/04/2021 00:18, Mark Johnston wrote:
fbt::vm_page_unwire:entry
/args[0]->oflags & 0x4/
{
@unwire[stack()] = count();
}
Unrelated report, dtrace complains about this probe on my stable/13 system:
failed to resolve translated type for args[0]
And I do not have any idea why...
From ctfdump:
[27290] FUNC (vm_page_unwire) returns: 38 args: (1463, 3)
<1463> TYPEDEF vm_page_t refers to 778
<778> POINTER (anon) refers to 3575
<3575> STRUCT vm_page (104 bytes)
plinks type=3563 off=0
listq type=3558 off=128
object type=3564 off=256
pindex type=3565 off=320
phys_addr type=42 off=384
md type=3571 off=448
ref_count type=31 off=640
busy_lock type=31 off=672
a type=3573 off=704
order type=3 off=736
pool type=3 off=744
flags type=3 off=752
oflags type=3 off=760
psind type=2167 off=768
segind type=2167 off=776
valid type=3574 off=784
dirty type=3574 off=792
--
Andriy Gapon
___
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"
