The mention of Barracuda reminds me that some of my drives also failed with ZFS years ago, but then I found out they were SMR, and posts saying ZFS doesn't handle those well.

i still have a few that are still alive in a pool lol

half of them died

Rest In Platters

ow

i redid my hdd mgmt after 3t seagates

:o

Why am I seeing a bunch of these in my apache access logs?: ::1 - - [15/Apr/2026:10:30:59 -0400] "OPTIONS * HTTP/1.0" 200 -

i think that's apache talking to itself,

CrtxReavr: do you run any reverse proxies in front of it, monitoring tools, etc? check the logs when it started, how often they appear and whether they are at regular intervals, etc

ananke, I do not.

I did find this, though I'm unsure of its relevance:

that's possible, you might want to check with #httpd

ananke: Those are internal dummy connections

thumbs: ahh, thanks

Pretty annoying, but it's been there for a while.

CrtxReavr, That ::1 is the IPv6 loopback so the call is definitely coming from inside the house. Other than apache monitoring its children do you have Munin or Prometheus or anything else that would be running status checks?

I don't see that in my apache logs so I wonder if it is also dependent upon which worker module is used.

My understanding is that it's seen when sites ask for your robots.txt

er - when clients ask for your robots.txt

got distracted by other things. . . I'll dig more into it later.

The robots.txt file is just a text file. That's not going to log an OPTIONS line. And also this was logged as coming from ::1 the loopback device which is on your own system.

Yep. That is something local, for sure. Likely some kind of monitoring software.

Right. Something like "apachectl status" which uses /server-status and/or /server-info but different because this one is looking at OPTIONS. I /have seen that/ past tense in my apache logs but not currently seeing it. I believe it is not anything bad. It's just some forgotten bit of monitoring.

And when I say I /have seen it/ past tense I found a system of mine no longer running apache but long ago it did and the logs have not been cleaned up from there (I should do that) and it logged it as "OPTIONS * HTTP/1.0" 200 126 "-" "Apache/2.2.22 (Debian) (internal dummy connection)"

That was from 2015 so quite some time ago.

rwp: Yep. Totally normal for Apache to do that.

IIRC, there is a way to disable that. Not sure I would even worry about it.

There something on FreeBSD that will accurately tell me the install date?

ls -l /bin/ls but i guess its not reliable

Those are probabaly accurate: bpa.st/BWQLQ

o0x1eef, I'm sure ls has been replaced many, many times.

it is installed with installworld

so its timestamp matches that build

afaik

Yeah, but that's not what I asked.

well, for me, 'install date' is the last installworld.

youre a weirdo

Tell me something that everyone doesn't already know.

i have a better idea. ill ignore you.

hmm should have rtfm before upgrading to 15.0 while using bridges :D

What is someone hoping to find if they run this against your web server?: "GET /.env HTTP/1.1"

credentials, etc, information

Anyone have a less-generic idea?

less generic, it cant contain anything any other environment file contains

it _shouldnt_ but people do this, and hence leak information

they're looking for service configuration info they can use to gain a beachhead or further leverage an existing beachhead. so they are looking for secrets, architecture details, configuration details, anything they can analyze to determine how to get deeper into your system.

same reason they scan for .git/config in your documentroot

anything they might want from a config.php

or config.ini

or what iRobbery said

a bit more loosely but also kinda more specifically: they are also hoping to find out that your site and web server are misconfigured to allow access to the file, which might give them other ideas about things it isn't configured to hide

unsure what changed in 15 with regards of bridge and my particular setup that breaks ipfw/nat, simple public interface that gets ip via dhcp from isp. This iterface is added to bridge0 (for jails to use also with public addresses). And i have a bridge_internal for jails with only internal ip ranges which the host does nat for. Works fine in 14.x but no more in 15

iRobbery: If you open a bug for that, please share it so more of us can follow it.

i dont know if i have a bug or just dont understand what has changed :)

hmm. my 15 jails don't seem to be having trouble but i'm not managing the bridge directly, i'm using bastille.

do you also do any NAT for jails with internal addresses?

i'm not sure i understand the question but let me tell you waht i do have: i have forwarding/nat inbound from some ports into some jails. but nothing between jails, and never more than one layer of translation

i'm also using nat to allow outbound connections from services in the jails, such as ZNC

And how many bridges do you have?

looks like my deployments have one called bastille0

although the host is also running wg, not sure if that is relevant

the wg is not intended to be involved in the jail stuff.

but the services in the jails are accessible from the other side of wg as well as from eth0 (internet)

hmmm well i know something has changed and i see the deprecated message about bridge members with ip addresses assigned

iRobbery: that's only if you have the member_ifaddrs=0 set, which is not the default

do you have bridge and vlan interfaces on the same physical interface? the behaviour of that changed in 15.0

bridge members?

oh, nvm. i see.

iRobbery, multiple times I've been bit by failing to read UPDATING.

I've never learned my lesson. . . when something breaks, then I look at UPDATING.

yes i'm in that penalty booth now :)

What'd they do to bridges?

a.o. people.freebsd.org/~ivy/bridge_vlan_filtering.txt

and reads for many situations to be improvement

but my simple straight forward use of bridges/NAT/ipfw breaks...

iRobbery: none of this is enabled by default if you don't explicitly configure it

there should be no difference in bridge behaviour between 14 and 15 unless you set member_ifaddrs=1, or you're using vlan and bridge on the same physical interface

s/=1/=0

hmm but if i copy my rc.conf/ipfw/jail setup 1:1 on a 14.4 fresh install it works fine, doing exact same on 15.0 and it doesnt

I've only ever used bridges on FreeBSD once. . . I built a portable, in-line sniffer appliance.

i have a bridge0 with the public interface as member, i use it for jails with public addresses too. And i have an internal bridge2 which i use for internal addresses on jails and i do IPFW/NAT on the host for jails that only have internal 10/8 ips

imho quite classic setup

can you use tcpdump to find where expected packets are not arriving or going missing?

I built a bridge that included two NICs. . . which would be put in-line on LACP connections for NAS devices.

The network devs could debug their LACP code/behavior with it by sniffing the bridge interface with tcpdump or wireshark.

Worked great.

I've done a lot of weird, one-off FreeBSD implementations.

its too late for debugging. time for a midnight snack and sleep. Will try another fresh look tomorrow, and else this machine going back to 14.x, has to go into production next week.

also something i notice getting insane counter increases on an ipfw rule, but tcpdump doesnt show any traffic coming close to it

anyway, snack -> Zzz bbl

hi. if making buildkernel crashes, running it again is -DNOCLEAN the default or does it automatically clean

f451: crashes as in clang SIGSEGVs? or the kernel panics?

ivy: clang - exit code 139

that doesn't look like a crash... is there an error before that?

yeah a stack dump

okay, please report that since it's a bug. but regarding clean, buildkernel has no knowledge about what to do in various failure states, if you run it again, it will do the same thing again. so either clean manually or ensure WITH_CLEAN=yes is set (i can't remember what the default is on various branches)

this is building -current kernel on 15-stable. I don't want it cleaned as it's slow

context: rpi2b (so, armv7)

then set WITH_CLEAN=no, although i think this is the default in main now

er, WITHOUT_CLEAN=yes, rather

looks like it's carried on where it left off, guessing

thanks for clarifying

ivy: the bug, should it go to bin or to arm ?

bin

unless you know for sure it's ARM-specific

btw, you might consider cross-compiling from a faster host...

dunno if it was arm-specific, it failed at linux_radix.o

for the cross-compiling id need all the docs and a gallon of coffee

any ideas how much ram filemon needs?

i would expect basically none as it doesn't store any data, maybe a couple of kB for buffers

ill use that next time too

the src obj and ccache are all nfs mounted

ya basically none, it writes to files

ok filemon it is, thanks

*sigh* I appear to have misread or misremembered freebsd.org/security/#sup. I thought 13.5 went EOL in December, not in 2 weeks.

i just deleted all my 13 VMs, very happy :D

i have to upgrade a couple of very important ones

actually three of em

ugh

two of em are in datacentres, one overseas

there'll be another -pXY before the end of the month? another patch?

only secteam knows that

ok ty