2024/11/04

Newest at the top

2024-11-04 19:25:52 +0100ash3en1ash3en
2024-11-04 19:24:33 +0100 <int-e> I have a hard time thinking of a legitimate reason for such requests. IDE integration might lead to long lists of packages... but they don't seem to connect and the varying suffix switching between different alternative preludes? Suspicious.
2024-11-04 19:24:12 +0100 <sclv> briandaed: oh lmao!!!
2024-11-04 19:23:34 +0100ash3en1(~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en
2024-11-04 19:23:28 +0100ash3en(~Thunderbi@146.70.124.222) (Ping timeout: 252 seconds)
2024-11-04 19:23:24 +0100 <briandaed> https://github.com/ndmitchell/hoogle/blob/master/src/Query.hs line#3 looks interesting
2024-11-04 19:21:32 +0100 <dolio> Is the amount of extra packages part of the problem?
2024-11-04 19:21:20 +0100Digit(~user@user/digit) Digit
2024-11-04 19:20:48 +0100hgolden_(~hgolden@146.70.173.37) (Ping timeout: 245 seconds)
2024-11-04 19:20:38 +0100Nachtgespenst(~user@user/siracusa) (Quit: Bye!)
2024-11-04 19:19:45 +0100Unicorn_Princess(~Unicorn_P@user/Unicorn-Princess/x-3540542) Unicorn_Princess
2024-11-04 19:19:07 +0100ash3en(~Thunderbi@146.70.124.222) ash3en
2024-11-04 19:18:25 +0100hgolden__(~hgolden@204.152.216.122) hgolden
2024-11-04 19:15:57 +0100 <sclv> i do suspect the best fix is making hoogle not work too hard when requests are goofy
2024-11-04 19:15:25 +0100 <sclv> specs not a secret, just don' recall off hand -- box is also shared with some other haskell infra. nothing beefy or special.
2024-11-04 19:13:58 +0100 <tomsmeding> given that log I would (hugely extrapolate and) think that adding more cores will not help
2024-11-04 19:13:35 +0100 <briandaed> and one more thing is hardware spec a secret? ram, core count, etc.?
2024-11-04 19:13:29 +0100 <tomsmeding> (as is everyone else, it seems)
2024-11-04 19:13:02 +0100 <tomsmeding> (I would but I'm swamped already...)
2024-11-04 19:12:32 +0100 <sclv> but yeah, anyone comfortable with nginx, systemd and willing to be comfortable with the hoogle codebase is encouraged to volunteer and you can get the auth to poke around on the system and take a look at it
2024-11-04 19:12:30 +0100 <briandaed> sclv any external monitoring, icinga/nagios? not sure what is hot now
2024-11-04 19:11:19 +0100 <sclv> as is it basically just passes through everything to the hoogle binary, which doesn't have very good logging.
2024-11-04 19:11:06 +0100 <tomsmeding> fair
2024-11-04 19:11:02 +0100gvg(~dcd@user/gvg) gvg
2024-11-04 19:11:00 +0100 <sclv> nope, we need to change the nginx setup to capture the log -- just been a low priority with everything else
2024-11-04 19:10:48 +0100chele(~chele@user/chele) (Remote host closed the connection)
2024-11-04 19:10:43 +0100 <tomsmeding> the packages in those requests really look quite random; the prefix is the same, and then the last 5 are completely arbitrary
2024-11-04 19:10:09 +0100 <tomsmeding> sclv: do you have IPs in the hoogle log?
2024-11-04 19:10:02 +0100gvg(~dcd@user/gvg) (Ping timeout: 255 seconds)
2024-11-04 19:08:17 +0100 <tomsmeding> that sample is indeed odd
2024-11-04 19:08:12 +0100 <briandaed> yeah, moved from hoogle to fw/ids/ips whatever
2024-11-04 19:07:44 +0100 <int-e> (which /may/ be easy to filter before they burden the CPU unduly but it's still work)
2024-11-04 19:07:20 +0100 <briandaed> https://discourse.haskell.org/t/hoogle-appears-to-be-down/10408/21
2024-11-04 19:07:07 +0100 <int-e> and everything that looks like it accepts parameters gets hammered with attempts to do SQL injection
2024-11-04 19:07:01 +0100 <tomsmeding> (link?)
2024-11-04 19:06:54 +0100 <briandaed> I also don't suspect spam or malicious activities, rather some misconfigured tool, but I saw only limited sample on discourse
2024-11-04 19:06:47 +0100ljdarj(~Thunderbi@user/ljdarj) (Ping timeout: 265 seconds)
2024-11-04 19:06:18 +0100 <tomsmeding> (and it's been up and linked to for more than a year now)
2024-11-04 19:06:10 +0100 <tomsmeding> the playground doesn't get spam like that
2024-11-04 19:06:05 +0100 <tomsmeding> and that happens enough times per second to bring the site to a crawl?
2024-11-04 19:05:50 +0100 <dolio> From what I heard, it doesn't sound like dos. It sounds like the internet is full of bots who will search for things like "password" on any web form hoping to get lucky.
2024-11-04 19:05:42 +0100 <tomsmeding> (though if it's really a DOS then it would be worth checking if it comes from a small number of IPs)
2024-11-04 19:05:40 +0100 <briandaed> in my narrow mind spam is sending some useless messages (sometimes malicious), while ddos wants service to be down
2024-11-04 19:04:35 +0100 <tomsmeding> is there a difference?
2024-11-04 19:04:26 +0100 <briandaed> not sure if we should classify it as a spam or rather (d)dos
2024-11-04 19:01:57 +0100 <tomsmeding> (if you know better: please let me know!)
2024-11-04 19:01:57 +0100morb(~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 248 seconds)
2024-11-04 19:01:19 +0100 <tomsmeding> (and, what's more, it's also counterproductive with things like CGNAT, or big schools having a small number of external IPs)
2024-11-04 19:00:26 +0100 <tomsmeding> IP rate limiting is pointless with IPv6
2024-11-04 19:00:03 +0100 <tomsmeding> ultimately spam protection is just really quite hard without relying on internet backbone providers like cloudflare