Too many ways to configure networking

Posted Sep 24, 2025 16:46 UTC (Wed) by pizza (subscriber, #46)
In reply to: Too many ways to configure networking by koverstreet
Parent article: An unstable Debian stable update

> That's all simulatable in VMs, exactly the same as I do for filesystem testing.

Then it's no longer "10-20 lines of bash code"

Too many ways to configure networking

Posted Sep 24, 2025 18:57 UTC (Wed) by koverstreet (✭ supporter ✭, #4296) [Link] (4 responses)

I already built it for you: https://evilpiepirate.org/git/ktest.git/

Too many ways to configure networking

Posted Sep 25, 2025 23:32 UTC (Thu) by smurf (subscriber, #17840) [Link] (3 responses)

This link throws a 404.

Too many ways to configure networking

Posted Sep 25, 2025 23:50 UTC (Thu) by koverstreet (✭ supporter ✭, #4296) [Link] (2 responses)

yeah I just had to flip off cgit, thanks to - you guessed it - too much AI crawler traffic

so until we get anubis going, there's a github mirror: https://github.com/koverstreet/ktest/

Too many ways to configure networking

Posted Sep 27, 2025 11:18 UTC (Sat) by smurf (subscriber, #17840) [Link] (1 responses)

I took that opportunity to look at my own cgit traffic. Yikes. Anubis downloaded and installed, nginx config adapted. Took ten minutes. "git clone" still works, no config modification required.

I do wonder how long it'll take these *censored* to notice that each request now results in an identical 12-kByte result (1.2 on the wire, it's compressed) … in the meantime I bet we're going to get a veritable ton of random search hits (and AI chat replies) for basically anything that smells like Anubis' challenge page.

What was that curse again … "may you live in interesting times".

NB my log shows a marked increase in the number of AI bot requests since yesterday, which is not at all surprising: Anubis replies a whole lot faster than cgit.

Too many ways to configure networking

Posted Sep 27, 2025 18:11 UTC (Sat) by koverstreet (✭ supporter ✭, #4296) [Link]

Yeah, it's gotten really bad. I used to be able to block them with a 10 line script that scraped the apache log, sorted IPs by number of accesses, and iptables blocked the ones that were over some silly number.

Now, they're all coming from different IPs - it's only a few accesses per IP - and the load was so bad the git fetches for the CI workers were unable to run. It ground my test infrastructure to a halt!

They're a bloody menace.

Although I'd also really like to know why git is so ridiculously memory hungry.