07:42:09 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. 07:42:56 i still have a few that are still alive in a pool lol 07:43:06 half of them died 07:50:00 Rest In Platters 07:58:06 ow 07:58:59 i redid my hdd mgmt after 3t seagates 08:18:29 :o 14:37:34 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 - 14:39:42 i think that's apache talking to itself, 14:43:14 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 14:44:09 ananke, I do not. 14:44:20 I did find this, though I'm unsure of its relevance: 14:44:31 https://webmasters.stackexchange.com/questions/12305/apache-logs-1-options-http-1-0-200 14:45:01 that's possible, you might want to check with #httpd 15:42:20 ananke: Those are internal dummy connections 15:53:12 thumbs: ahh, thanks 16:06:11 Pretty annoying, but it's been there for a while. 17:06:22 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? 17:06:38 I don't see that in my apache logs so I wonder if it is also dependent upon which worker module is used. 17:07:05 My understanding is that it's seen when sites ask for your robots.txt 17:07:22 er - when clients ask for your robots.txt 17:08:55 got distracted by other things. . . I'll dig more into it later. 17:19:51 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. 17:51:40 Yep. That is something local, for sure. Likely some kind of monitoring software. 17:54:44 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. 17:56:26 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)" 17:57:03 That was from 2015 so quite some time ago. 18:19:46 rwp: Yep. Totally normal for Apache to do that. 18:20:13 IIRC, there is a way to disable that. Not sure I would even worry about it. 18:31:53 There something on FreeBSD that will accurately tell me the install date? 18:36:51 ls -l /bin/ls but i guess its not reliable 18:37:00 Those are probabaly accurate: https://bpa.st/BWQLQ 18:37:20 o0x1eef, I'm sure ls has been replaced many, many times. 18:37:33 it is installed with installworld 18:37:43 so its timestamp matches that build 18:37:44 afaik 18:37:59 Yeah, but that's not what I asked. 18:38:33 well, for me, 'install date' is the last installworld. 18:39:20 * CrtxReavr pats o0x1eef's head. 18:39:39 youre a weirdo 18:43:57 Tell me something that everyone doesn't already know. 18:45:21 i have a better idea. ill ignore you. 18:52:46 * CrtxReavr waves goodbye. 19:27:31 hmm should have rtfm before upgrading to 15.0 while using bridges :D 19:29:12 What is someone hoping to find if they run this against your web server?: "GET /.env HTTP/1.1" 19:29:59 credentials, etc, information 19:30:43 Anyone have a less-generic idea? 19:33:04 https://dev.to/talaamm/what-is-a-env-file-and-why-should-you-use-it-599o 19:33:28 less generic, it cant contain anything any other environment file contains 19:33:39 it _shouldnt_ but people do this, and hence leak information 19:34:10 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. 19:34:12 same reason they scan for .git/config in your documentroot 19:34:41 anything they might want from a config.php 19:34:50 or config.ini 19:34:56 or what iRobbery said 19:38:32 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 19:46:02 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 19:46:43 iRobbery: If you open a bug for that, please share it so more of us can follow it. 19:47:36 i dont know if i have a bug or just dont understand what has changed :) 19:47:47 hmm. my 15 jails don't seem to be having trouble but i'm not managing the bridge directly, i'm using bastille. 19:48:08 do you also do any NAT for jails with internal addresses? 19:49:08 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 19:50:29 i'm also using nat to allow outbound connections from services in the jails, such as ZNC 19:52:42 And how many bridges do you have? 19:54:24 looks like my deployments have one called bastille0 19:54:54 although the host is also running wg, not sure if that is relevant 19:55:07 the wg is not intended to be involved in the jail stuff. 19:55:51 but the services in the jails are accessible from the other side of wg as well as from eth0 (internet) 20:04:47 hmmm well i know something has changed and i see the deprecated message about bridge members with ip addresses assigned 20:05:03 iRobbery: that's only if you have the member_ifaddrs=0 set, which is not the default 20:05:27 do you have bridge and vlan interfaces on the same physical interface? the behaviour of that changed in 15.0 20:07:53 bridge members? 20:08:49 oh, nvm. i see. 20:10:42 iRobbery, multiple times I've been bit by failing to read UPDATING. 20:11:08 I've never learned my lesson. . . when something breaks, then I look at UPDATING. 20:12:28 yes i'm in that penalty booth now :) 20:12:46 What'd they do to bridges? 20:18:50 a.o. https://people.freebsd.org/~ivy/bridge_vlan_filtering.txt 20:19:12 and reads for many situations to be improvement 20:19:29 but my simple straight forward use of bridges/NAT/ipfw breaks... 20:19:50 iRobbery: none of this is enabled by default if you don't explicitly configure it 20:20:17 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 20:20:25 s/=1/=0 20:22:08 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 20:23:43 I've only ever used bridges on FreeBSD once. . . I built a portable, in-line sniffer appliance. 20:24:04 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 20:24:23 imho quite classic setup 20:25:09 can you use tcpdump to find where expected packets are not arriving or going missing? 20:25:36 I built a bridge that included two NICs. . . which would be put in-line on LACP connections for NAS devices. 20:26:35 The network devs could debug their LACP code/behavior with it by sniffing the bridge interface with tcpdump or wireshark. 20:26:43 Worked great. 20:27:08 I've done a lot of weird, one-off FreeBSD implementations. 20:52:13 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. 20:52:56 also something i notice getting insane counter increases on an ipfw rule, but tcpdump doesnt show any traffic coming close to it 20:54:45 anyway, snack -> Zzz bbl 22:45:15 hi. if making buildkernel crashes, running it again is -DNOCLEAN the default or does it automatically clean 22:45:39 f451: crashes as in clang SIGSEGVs? or the kernel panics? 22:46:22 ivy: clang - exit code 139 22:47:02 that doesn't look like a crash... is there an error before that? 22:47:52 yeah a stack dump 22:48:55 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) 22:49:51 this is building -current kernel on 15-stable. I don't want it cleaned as it's slow 22:50:30 context: rpi2b (so, armv7) 22:51:11 then set WITH_CLEAN=no, although i think this is the default in main now 22:51:29 er, WITHOUT_CLEAN=yes, rather 22:51:41 looks like it's carried on where it left off, guessing 22:51:49 thanks for clarifying 22:53:35 ivy: the bug, should it go to bin or to arm ? 22:53:53 bin 22:54:00 unless you know for sure it's ARM-specific 22:54:22 btw, you might consider cross-compiling from a faster host... 22:55:05 dunno if it was arm-specific, it failed at linux_radix.o 22:56:53 for the cross-compiling id need all the docs and a gallon of coffee 22:58:05 any ideas how much ram filemon needs? 22:58:47 i would expect basically none as it doesn't store any data, maybe a couple of kB for buffers 22:59:02 ill use that next time too 22:59:23 the src obj and ccache are all nfs mounted 22:59:24 ya basically none, it writes to files 22:59:43 ok filemon it is, thanks 23:01:04 *sigh* I appear to have misread or misremembered https://www.freebsd.org/security/#sup. I thought 13.5 went EOL in December, not in 2 weeks. 23:01:47 i just deleted all my 13 VMs, very happy :D 23:03:32 i have to upgrade a couple of very important ones 23:04:07 actually three of em 23:04:12 ugh 23:05:08 two of em are in datacentres, one overseas 23:06:20 there'll be another -pXY before the end of the month? another patch? 23:07:10 only secteam knows that 23:09:00 ok ty