Tornevall Networks

"Web01" is currently running on a CPX31 cloud server.

From time to time I experience something that tells me that 8 GB internal memory is a bit too small, when running database AND web server on the same server like we do.

A plan is to upgrade to a "cost optimized" server, which gives us 16 GB.

The catch? We need to shut the server down.

It might be a good idea though, since the server has been up without reboot for 1150 days...

For uptime-nerds:

21:00:26 up 1150 days, 7:05

The site has occasionally stopped responding even though the server itself was still running.

The main issue appears to have been that PHP-FPM was configured to run only five PHP processes at the same time. This does not mean that only five visitors could use the site. Each process handles a PHP request, finishes it, and then immediately becomes available for the next request.

Most visitors only occupy a PHP process for a fraction of a second while the page is being generated. Static files such as images, CSS and JavaScript are normally served separately by Apache.

Problems occur when several PHP requests become slow or get stuck. If all available PHP processes are occupied, new page requests must wait in a queue, making the site appear to have frozen.

The following changes have now been made:

• The maximum number of simultaneous PHP processes has been increased from five to eight.

• More PHP processes are kept ready to handle temporary traffic increases.

• PHP processes are recycled after 200 requests to reduce the risk of memory usage building up over time.

• Requests taking longer than five seconds are now recorded in a slow log.

• PHP requests that remain stuck for more than two minutes are automatically terminated.

• The same configuration has been applied to PHP 8.3, 8.4 and 8.5.

• A maintenance script has been created that checks these settings and only updates the configuration when something is missing or incorrect.

These changes should reduce the risk of the site becoming unresponsive during temporary load increases or when individual requests take too long.

If the problem happens again, the new logs should also make it easier to identify the exact page, plugin or function causing the delay. And eventually render that we move elsewhere, one more time.

Det här började egentligen inte med ett särskilt svårt tekniskt problem. Någonting hade plötsligt förändrats i systemet, forumet började returnera 500-fel och Apache vägrade acceptera ett direktiv som tidigare hade legat där utan att ställa till med något.

Jag visste redan att PHP kördes via PHP-FPM. Jag visste redan hur servern var installerad. Det jag inte visste var vad som hade förändrats och varför felet dök upp just nu.

Det borde ha varit utgångspunkten.

I stället började ChatGPT förklara för mig att servern körde PHP-FPM.

Tack. Det var ungefär lika användbart som att informera en bilförare om att bilen har hjul.

Sedan föreslogs en ny konfigurationsrad. Den gjorde att Apache inte längre kunde starta över huvud taget.

När jag påpekade det kom nästa råd:

a2enmod mod_env

Problemet var bara att servern kör en egen konfiguration. I den här storyn försöker chatgpt få er att tro att servern kör en egenkompilerad Apache under /usr/local/apache2. Även under själva uppbyggnaden av historien försöker alltså systemet LJUGA FÖR ER!

Debians a2enmod hade alltså ingenting med den aktiva webbservern att göra. Lika lite som att det skulle vara egenkompilerad.

Resultatet blev:

ERROR: Module mod_env does not exist!

Vid det laget började tonen bli en aning mindre pedagogisk.

"Ja det var ju smart...", skrev jag till den ovanligt imbecilla botjäveln - och kallade den samtidigt imbecill. ChatGPT bad om ursäkt och presenterade en ny förklaring. Sedan skulle jag skriva ett inlägg om upplevelsen. Jag bad om min frustration som ton, men fortfarande professionellt formulerat. Det gick inte det heller.

Texten började då förklara att:

"Miljön visade sig köra PHP via PHP-FPM och proxy_fcgi, inte via mod_php."

Och där brast det.

"JAG VET ATT JAG KÖR FPM! MEN VAD SOM FÖRÄNDRATS FÖR ATT DETTA SKULLE SLUTA FUNKA VET JAG FAN INTE."

Det intressanta med ChatGPT är att den ofta kan återge varje teknisk detalj korrekt och ändå missa exakt det man försöker säga.

Jag frågade inte hur PHP kördes.

Jag frågade vad som hade förändrats.

Jag ville inte ha en teknisk genomgång av PHP-FPM.

Jag ville beskriva frustrationen över att någonting plötsligt slutade fungera och en botjävel som inget begriper.

När jag bad om någonting komiskt som även en pensionär kunde förstå fick jag en teknisk redogörelse. När jag bad om en roman fick jag faktiskt en roman. När jag sedan förklarade att jag inte ville ha en roman, utan en text om hur ChatGPT kan driva en till vansinne, behövde jag återigen förklara vad texten skulle handla om.

Till sist sitter man och svär åt en språkmodell eftersom den för femte gången förklarar den enda sak man uttryckligen har sagt att man redan vet.

Vansinnet börjar när man försöker få ett system byggt för att förstå språk att förstå en enkel mening, och systemet i stället fortsätter svara på en fråga som aldrig ställdes.

​

Och vid den här punkten har allt i den här tråden slutat handla om den driftstörning jag från början satt med. Så jag satte mig ned för att skriva det själv.

​

​

Av en ren slump upptäcktes att något hade förändrats någonstans i systemet. Forumet började returnera 500-fel eftersom webservern plötsligt inte längre kände igen direktiven den fått.

Det är nu löst!

Detta är en bakgrundshistoria om hur vår sajt spelar roll i spam-sammanhang.

Hur vi framledes kan bredda oss i kampen mot troll-verksamheter på internet jobbar vi på och det finns ett övervägande kring om vi kan utnyttja tekniken som presenteras här på samma sätt.

Runt 2005-2006 startade Tornevall Networks en utveckling av något som skulle få en ganska ovanlig roll på nätet. Jag hade arbetat med dokusåpor via webben sedan ungefär 2003, efter att ha fått förtroendet av en innebandyspelare (!) som hade ont om tid att hantera alla chatter och forum han var delaktig i. Han spelade på elitnivå och ville satsa mer på det, förståeligt nog.

Meter Film, som då var en av de stora aktörerna bakom svenska dokusåpor, hade anlitat ett mindre bolag som skötte webb, streaming, forum, chatter och i princip allt som hörde till webbnärvaron. De hade i sin tur hittat leverantörer för de öppna chatter som var igång dygnet runt och som vem som helst kunde delta i. Tornevall Networks tog tidigt över hela den delen ihop med ett annat nätverk som hanterade en del av chatterna, och runt 2004 började vi administrera forumen på heltid.

På pappret kunde det se ut som en ganska enkel uppgift. Forum och chatter skulle hållas igång, användare skulle kunna skriva, och tekniken skulle fungera. Men precis som i dag följde det alltid med troll, spam, som skyddade sig med öppna proxies och personer som bara var där för att förstöra för andra. Det gjorde att vi behövde bygga ett system som var tillräckligt stabilt för att skydda forum och chatter utan att stoppa vanliga användare.

Det visade sig efter någon månad in i Big Brother vara betydligt svårare än det lät. Databasen överbelastades av alla spårningskontroller, så vi fick rensa den och börja om. Där och då började systemet byggas om för att kunna hantera extremt hög belastning.

Det systemet lärde oss också något viktigt: webbspam fungerar inte på samma sätt som e-postspam. Ett vanligt e-postfilter tittar ofta på avsändare, innehåll, länkar, rubriker och mönster i själva meddelandet. Ett forum behöver däremot kunna fatta snabba beslut redan innan skadan är skedd, samtidigt som det har en viss beständighet där samma användare återkommer gång på gång i högre takt. Ska den här besökaren få registrera sig? Ska inlägget släppas igenom? Är IP-adressen känd sedan tidigare? Kommer trafiken från en öppen proxy? En chatt ställer liknande krav på snabba beslut, men där är interaktionerna ofta mer flyktiga och sker i realtid.

Det blev grunden till ett antispamsystem för forum, snarare än e-post, som fortfarande fungerar och som fortfarande används. Under den tiden fick vi också kontakt med StopForumSpam, som arbetade mot samma typ av forum- och registreringsspam som vi gjorde. Deras lösning byggde främst på centrala databaser och API-baserade uppslag, medan vi fokuserade på "DNSBL"-teknik för snabbare kontroller direkt via DNS.

Vi har pratat en del om "DNSBL" i olika sammanhang, men få känner nog till vad det faktiskt betyder eller vilken roll vi har haft där. En DNSBL är alltså en spärrlista som kan frågas via DNS, alltså samma grundteknik som används när ett domännamn översätts till en IP-adress - exempelvis, din dator får reda på vart den ska ta vägen när du skriver in aftonbladet.se i din läsare.

I stället för att slå i en vanlig databas gör systemet ett snabbt DNS-uppslag. Svaret är enkelt: är IP-adressen listad eller inte, och ibland även varför. Det handlar alltså inte om att identifiera en person, utan om att känna igen nätadresser som tidigare har använts för spam, abuse, öppna proxies eller annan oönskad trafik.

Tornevall Networks har drivit den här typen av DNSBL-baserad antispam sedan 2006. Under åren har tjänsten utvecklats från den klassiska DNSBL-lösningen på dnsbl.tornevall.org, med fokus på IP-adresser kopplade till öppna proxies, spam och annat webbmissbruk, till att även omfatta bedrägeri-relaterade attacker via fraudbl.org. Medan DNSBL främst riktar in sig på spamrelaterad trafik fokuserar FraudBL på bedrägerier och missbruk där phishing, falska avsändare, bedrägliga webbplatser eller ekonomisk skada kan vara en del av problemet.

I dag finns Tornevall Networks DNSBL inte bara som en intern lösning som florerat i några månader på Big Brothers forum. Den förekommer i externa blacklist-index, kan kontrolleras via publika uppslagstjänster och används även genom integrationer, bland annat för WordPress, där den kan skydda kommentarer, registreringar och andra formulär från kända missbrukskällor.

Hur många frågor som faktiskt ställs till våra system i dag är svårt att säga exakt - vi vet däremot att våra offentliga webbsidor supportar mängder av besökare på internet dagligen. Att det är möjligt beror bland annat på att vi inte längre pratar om en ensam server i Sverige, utan om flera noder och externa servrar som hanterar uppslag från olika delar av världen, beroende på var de befinner sig. Det viktiga är dock inte den exakta siffran, utan att systemet fortfarande gör det det byggdes för: att snabbt stoppa trafik som annars hade nått forum, kommentarsfält, registreringar och andra öppna ytor.

Det började med dokusåpachatter och forum som behövde skyddas från troll och spam.

Det blev ett antispamsystem som fortfarande lever.

Därifrån och framåt finns det nu flera möjligheter att driva projektet vidare och bredda oss.

​

Forum => Forum.

Forum => Socials (?).

Order on our Website below

URLS are removed due to spam.

/Admin

Order on our Website below

URLS are removed due to spam.

/Admin

Order on our Website below

URLS are removed due to spam.

/Admin

Order on our Website below