Am 31.01.2026 um 05:09 schrieb Christian Schulte:
> Am 30.01.2026 um 06:50 schrieb Janne Johansson:
>>>
>>> How's that AI's fault when your software was always inefficient at scale?
>
> Should we all buy an AI data center just to be able to catch up with
> massive compute hammering on some private web server hosting a bunch of
> subversion repositories and trac instances, just because they do not
> obey any conventions?
>
>> While this is not strictly aimed at you or this particular reply, but
>> for anyone in this thread that has a solution to suggest, PLEASE set
>> up something where you present tons of links that cause load, doesn't
>> matter if it is cvsweb, github/igtlanb/gitea clone, gotweb or
>> something else, and show the before-and-after your suggestion is
>> applied.
>
> That's a very time consuming task if you are dealing with a website
> served by apache2 on a linux box serving subversion repositories over
> HTTP (mod_dav), trac instances using mod_python, applying content
> negotiation (mod_negotiation) and also using some nifty php scripts
> containing things like:
>
> <?php header("Location: http://www.somewhere.else/subdir/wiki";); exit();?>
>
> For what it's worth. By preparing an OpenBSD box to migrate to, I think
> the following pf.conf should do the trick. Science also is about trial
> and error. Let's see. Don't know yet. Still questioning what damn
> asshole is programming some kind of bot that aggressively and for what
> reasons.
For what it's worth. Running -current, the following configuration does
a great job here.
$(hostname)# cat /etc/pf.conf
# $OpenBSD: pf.conf,v 1.55 2017/12/03 20:40:04 sthen Exp $
#
# See pf.conf(5) and /etc/examples/pf.conf
set skip on lo
set block-policy return
set timeout tcp.opening 3
block return # block stateless traffic
pass # establish keep-state
# By default, do not permit remote connections to X11
block return in on ! lo0 proto tcp to port 6000:6010
# Port build user does not need network
block return out log proto {tcp udp} user _pbuild
# Localhost
source limiter "default" id 1 entries 1000 limit 5 rate 1/10
pass in on egress inet source limiter "default" (block) synproxy state
# rules for spamd(8)
table <spamd-white> persist
table <nospamd> persist file "/etc/mail/nospamd"
pass in on egress inet proto tcp from any to any port smtp\
divert-to 127.0.0.1 port spamd
pass in on egress proto tcp from <nospamd> to any port smtp
pass in log on egress proto tcp from <spamd-white> to any port smtp
pass out log on egress proto tcp to any port smtp
$(hostname)# cat /etc/httpd.conf
# $OpenBSD: httpd.conf,v 1.22 2020/11/04 10:34:18 denis Exp $
server "$(hostname)" {
listen on * port 80
connection max requests 1
location "/.well-known/acme-challenge/*" {
root "/acme"
request strip 2
}
location * {
block return 302 "https://$HTTP_HOST$REQUEST_URI";
}
}
server "$(hostname)" {
listen on * tls port 443
connection max requests 1
gzip-static
tls {
certificate "/etc/ssl/0x02.schulte.it.fullchain.pem"
key "/etc/ssl/private/0x02.schulte.it.key"
}
location "/pub/*" {
directory auto index
}
}
That "connection max requests 1" in httpd.conf is crucial here to stop
an endpoint from hammering the http service once a connection has been
established and to make httpd send Connection: close for each request.
Power users may still get hit by that "limit 5" in pf.conf. Glad there
are no power users around there, so no complaints thus far.
Regards,
--
Christian
