Blokować ai boty na nginx czy nie blokować… Oto jest pytanie
#nginx #ai #bots

Topic: #nginx transformation of script arguments

This post is for #Linux and #webdev readers. The details discussed below aren't at all obvious, so I thought that I'd share them.

Note: "angie" is a fork of "nginx". It's recommended because, unlike "nginx", it offers Let's Encrypt provisioning for free. For the purposes of this post, though, the two programs are essentially identical.

Suppose that you're using #nginx or #angie to run a website that accepts script arguments of the form "sandwich?type=thing" and you'd like to edit the "thing" at the "nginx" ".conf" level. This is possible using "nginx" ".conf" code that looks roughly like this:

location ~ ^/sandwich {
    if ($arg_type ~ "peanut-butter") {
        set $arg_type jelly;
        return 301 https://your.site/sandwich?type=$arg_type;
    }
    # Finish default processing here
}

"nginx" and "angie" support the feature that variables named "$arg_..." are the values of script parameters named by the "..." part. In the current example, "$arg_type" is the value specified by "type=...".

The "~" lines are regex checks. The rules for regexes need to be kept in mind for those lines.

The preceding "location" block will stop further processing of "/sandwich" links whether or not the conditional is satisfied. So, the "# Finish default" part needs to finish whatever you were going to do with "/sandwich" links if you hadn't added the "location" block.

For example, if the "nginx" ".conf" file does a "proxy_pass" later as part of default processing, you might need to duplicate the "proxy_pass" here.

The use case, for me, was that my "nginx" setup needed to transform some links related to Pleroma remote follows or the links wouldn't work with my copy of Pleroma. In the end, the "location" block listed below worked for my purposes:

location ~ ^/ostatus_subscribe {
    if ($arg_acct ~
"https\%3A\%2F\%2F(?<rhost>.+?)\%2F\%40(?<ruser>[A-Za-z0-9]+)") {
    set $arg_acct https://$rhost/users/$ruser;
return 301 https://dansu.org/ostatus_subscribe?acct=$arg_acct;
    }
    proxy_pass http://phoenix_dansu;
}

The preceding "nginx" ".conf" code transforms links of the form:

https://dansu.org/ostatus_subscribe
?acct=https%3A%2F%2Fmastodon.social%2F%40UnicornRiot

to:

https://dansu.org/ostatus_subscribe
?acct=https://mastodon.social/users/UnicornRiot

The "proxy_pass" used here is needed because that is part of the default processing for my Pleroma "nginx" setup.

Illustration: A wizard transforms a sandwich into Fediverse follows.

Thinking about firing up a #VPS to run my own software (wiki, #gotosocial, ???). I want something cheap and lightweight, so I'll probably just manage the server myself. It's been like 10 years since I've done this. Before, I've just run Ubuntu Server, which worked well at the time. I think I used #supervisord to manage services, IIRC, with #nginx as the public gateway w/ manual routing configs. Not sure what is best for this type of hosting now. I want to avoid docker images for efficiency sake.

@jsbilsbrough I use #nginx, outside of a container because #IPv6.

How To Limit Rate of Connections (Requests) in NGINX
https://www.tecmint.com/nginx-rate-limiting/

#nginx #http_429 #rate_limiting

kubuntu 24.04.2LTS + nginx + apache2 + php 8.3 + all timeout settings correct = still a '502 bad gateway' error #kubuntu #apache2 #php #nginx

https://askubuntu.com/q/1551000/612

Set up a script to ping me when my fail2ban blocks a malicious IP (and grabs the location) trying to connect to my #nginx reverse proxy. I swear at some point I'll block every IPv4 out there.

I'm thinking of developing a new course or workshop in the fall.. would any of these interest you?

#webdev #svelte #html #css #javascript #nginx #lua #freelancer

Seit einigen Tagen werden Medien meiner Mastodon-Instanz metalhead.club global verteilt über ein eigenes CDN ausgeliefert. :goose_hacker:

Das verringert die Latenzen für Benutzer aus nicht-EU Ländern und sorgt für weniger Frust bei den Ladezeiten.

Was ein CDN ist, welche Implementierungsmethoden es gibt und wie ich mein kleines CDN umgesetzt habe, erfahrt ihr in meinem neuen Blogpost:

"Ein eigenes kleines CDN für meine Mastodon-Instanz metalhead.club" - https://thomas-leister.de/mastodon-media-storage-cdn/

#metalheadclub #cdn #media #mastodon #instance #mastoadmin #hosting #selfhosting #nginx #scaleway #dns #geoip #geodns #hetzner

CDN ja podcast-linkit

https://www.eksis.one/palvelimet/cdn-ja-podcast-linkit/

Käytin aiemmin sivustolla katiska.eu Amazonin AWS:n CDN:ää. Sivuston cdn-osoite viittasi CloudFrontiin, joka oli kytketty hakemaan tiedostot S3-bucketista. Normikauraa siis.

Alussa sinne meni aivan kaikki staattiset tiedostot. JS, css, kuvat, audio jne. Sitten tuli hassu olo, että joka sivulatauksessa haettavat JavaScriptit ja tyylimuotoilut itseasiassa aiheuttivat latenssia, hidastelua, kun ne haettiin CDN:stä. Mutta suurin hidaste oli cacheaminen, koska minulla oli silloin Varnish käytössä. Joten ne palasivat takaisin kotiin. Kuvat ja audiot jäivät AWS:n hoiviin.

Sitten oivalsin yhden asian. Minä en tee CDN:llä yhtään mitään. En varsinkaan tilanteessa, jossa edge-CDN ei palvele mitään eikä ketään.

Globaali vastaan paikallinen

Olin tehnyt asioita kuin superisot sivustot. Mutta minä ja sivustoni emme ole muuta kuin ikkiriikkisiä. Olin syyllistynyt perussyntiini, tekemiseen tekemisen vuoksi.

CDN sellaisenaan tarjoaa yhden asian, sen edgen. Edge-CDN tarkoittaa sitä, että se on maailmanlaajuinen tai muuten iso verkosto servereitä, jotka tarjoavat cachestaan sivun tiedostot lähempää kävijää.

Kun otin Amazonin myymän systeemin käyttöön, niin sivustojeni sisältö — oikeammin niihin liittyvä oheismateriaali, kuten juurikin ulkonäköä säätelevät CSS:t, laitteissa toiminnallisuutta tarjoavat JS:t, kuvat jne. — tarjottiin lähempää pyytäjää kuin missä aito serveri sijaitsee.

Maailma on suuri ja vaikka internet, valokuitu ja satelliitit kattavat pallon hyvin ja ovat nopeita, niin silti viivettä on.

Edge tarkoittaa sitä, että kävijän pyyntö sivujen tiedostoista menee jonnekin muualle kuin alkuperäiselle palvelimelle. Eräällä tavalla annetaan ymmärtää, että varsinainen datakeskus on keskiössä ja sen ympärille rakennetaan verkosto tai ympyrä, ja kävijää palvellaankin sen reunoilta, lähempää aitoa kävijää.

Koska minulla oli silloin sivustot Saksassa, niin AWS ja CloudFront pystyivät tarjoamaan eräällä tavalla paikallisesti, tai ainakin lähempää, eri mantereilla sivustojeni tiedostot.

Ongelma on siinä, että minulla ei ole kävijöitä noissa maissa. Niistä tulevat (haitalliset) botit sen sijaan saivat tiedostot hieman nopeammin. Minun kävijäni ovat suomalaisia ja muutamaa ulkosuomalaista lukuunottamatta… Suomessa — ja siellä/täällä ei ole edge-serveriä.

Siihen aikaan lähin oli Saksassa. Kotiserverinikin oli Saksassa. Sitten Amazon hieman laajensi ja Tukholmaan tuli datakeskus. Joten logiikka sitten yritti päätellä, että annetaanko suomalaisille tiedostot Saksasta, jossa kaikki siis alunperinkin oli, vai Ruotisista.

Ei mitään merkitystä millekään muulle paitsi sille, että maksoin joka kuukausi tuosta ilosta. Paitsi että se toi iloa vain Amazonin liikevaihdolle.

Toiminnan järkeistäminen

Minä en saanut CloudFrontin kanssa minkäänlaista nopeusetua, koska se ei lyhentänyt tiedonsiirron matkaa. Se itseasiassa pidensi. Toki voidaan olettaa, että Amazonin serverit ovat yhteyksiltään nopeampia kuin käyttämäni palvelin, mutta kyse oli teoreettisesta edusta. Ei näkyvästä.

Toinen ongelma oli se, jonka ratkaisin Varnishilla. Eivät kuvat ja sivujen pikkutiedostot, vaikka niitä paljon määrällisesti onkin, ole se pullonkaula. Käyttämäni WordPress on.

Sivujen rakentaminen PHP:n ja tietokannan yhteistyöllä vei enemmän aikaa kuin sisällön siirtäminen kävijälle. Edes siinä vaiheessa kun aloin tarjoamaan Varnishin avulla cachetettua sisältöä, suoraan tarjoiltavat oheistiedostot — joita on yleensä turha viedä välimuistiin — eivät tuoneet lataukseen nopeutta CDN:ää käytettäessä.

Joten purin CloudFrontin ja lakkasin tuolta osin rahoittamasta Jeff Bezoksen elämää.

CDN (oikeammin sen tarjoama järjestelmä, mutta oion mutkia) tarjoaa yhden asian, jota tavallinen serverisivusto ei tarjoa. Se on isojen mediatiedostojen striimaus.

Striimaus tarkoittaa sitä, että esimerkiksi videon tai audion sisältöä aletaan toistamaan heti. Ei odoteta, että koko megatiedosto on ladattu puhelimeen tai tietokoneelle. Tuttua esimerkiksi Netflixistä tai Spotifystä — toki niiden tekniikka on hieman erilainen, mutta periaate on sama.

Minulla on audiotiedostoja, podcasteja. Niiden toistossa olisi mukavaa, jos ne alkaisivat jutella nyt, ei vasta minuutin kuluttua. Mutta minulla on kaksi järjestelmää, joka hoitavat tuon: podcastit tarjoava plugin sekä Varnish.

Sitten on sekin, että niitä kuunnellaan paljon podcastejä tarjoavien palveluiden kautta, kuten Spotifystä, Applesta jne. En pidä tuosta tilanteesta, koska silloin ihmiset maksavat noille kuunnellessaan minun sisältöäni. Minä en saa muuta iloa kuin maksaa serverimaksuja. Tuolle tilanteelle ei voi mitään, joten sen kanssa on vain elettävä.

Joten en saanut striimauksenkaan etua Amazonin palveluista

Tiedostokokojen tuska

Kun purin CDN:n oheistiedostojen suhteen, niin tilan käytössä omalla serverillä ei muuttunut mikään. Ne on pakko olla paikallisesti ja siirretään maailmalle kävijöiden takia.

Kuvat ovat siinä rajoilla. Niitä tuppaa kertymään ja ne vievät tilaa ilman, että niitä käytetään pyydetyn sivun rakentamiseen. Ne ovat osa sen sivun sisältöä. Mutta päätin, että tilan kulutus kuvien takia ei ollut merkityksellistä.

Audiot olivat hieman toinen juttu. Eivät nekään videoiden kokoluokkaa ole, mutta yksi podcast-jakso syö levytilaa 30 – 50 kuvan verran. Joten tein kompromissin. Jätin audiot CDN:n haltuun. En voittaakseni nopeudessa, vaan säästääkseni oman serverin tilaa. Sen laajentaminen maksaa aina.

Aloin kuitenkin lopulta lähestyä hetkeä, että oma serveri olisi päivitettävä suurempaan. Samalla lompakko sanoi, että minulla menee nyt rahaa liikaa joka suuntaan.

Sama ongelma kuin kotitalouksilla striimauspalveluiden kanssa. Ei se yksi tai kaksi kympin kuussa maksava palvelu normaalitaloudessa maailmaa kaada. Mutta kun niitä kympin palveluita on kymmenen, ja suurinta osaa ei edes käytä, niin se satanen kuussa ja 1200 euroa vuodessa alkaa sattumaan.

Minulla meni liikaa rahaa Amazonille. Serverin laajennus maksaisi lisää. Aloin ynnäilemään noita ja havaitsin, että kun otan audiot pois Amazonilta, sekä muutaman muun backup-tyyppisen tiedostosäilön, niin itseasiassa serverin kallistuminen ei nostaisi kulujani. Toki ne pitäisi siirtää jonnekin muualla, mutta silti kokonaiskulut olisivat samat kuin ennen serverin päivitystä.

Elämässä on valintoja

Tässä oli taustalla muutakin, nimittäin nykyisen maailmanpolitiikan tila. Minä en halua enää rahoittaa amerikkalaisia megakorporaatioita yhtään sen enempää kuin on pakko.

Olen luopunut vahvasti Facebookista ja siirtynyt federoituun ja algoritmivapaaseen someen, joka ei rahoita Mark Zuckerbergin vakoilua, sisällön varastamista ja vittuilua. Joten olen Mastodonissa. Samaten lopetin Instagramin ja siirryin Pixelfediin.

Sivustoni olivat ennen DigitalOceanilla. Sitten päätin, että en halua rahoittaa venäläisomisteisen amerikkalaisen suuryhtiön, joka vuotaa servereiden tiedot mm. tiedustelupalvelulle, yhtään enempää. Joten vaihdoin saksalaiselle Hetznerille.

Ehkä täytyy olla hieman rehellisempi. Päätöstä helpotti DigitalOceanin melkoisen isot hinnankorotukset.

Jeff Bezos on yrittäjänä täysi hirviö. Amazonin yritys- ja henkilöpolitiikka on sellaista, jota täällä ei edes ymmärretä. Mutta Amazonin AWS:n palvelujen korvaaminen on vaikeaa. Korvaan kuitenkin sen minkä pystyn. Ja CDN-tyyppinen tiedostojen välitys on sellainen.

S3 tiedostosäilö Suomessa

Sivustojani hostaava Hetzner pitää niitä datakeskuksessa lähellä Helsinkiä. Porvoossako se aidosti sijaitsee? Joten sivustoni muuttivat takaisin Suomeen, ja siihen paloikin sitten CDN:n hyöty lopullisesti.

Hetzner tarjoaa aidon CDN:n lisäksi myös S3-tyyppisen pilvipalvelun. Inhoan pilvi-nimitystä, koska eivät tiedostot missään pilven reunalla ohuessa ilmassa leiju. Ne ovat ihan tismalleen samassa datakeskuksessa syömässä sähköä ja tuottamassa lämpöä.

S3 on tapa, jolla Amazon rakensi tiedostosäilöt. Muut adoptoivat/kopioivat tekniikan, ja siitä tule de facto standardi. Se kuitenkin tarkoittaa sitä, että ne toimivat samalla tavalla ja niitä pystyy komentoriviltä käyttämään samalla tavalla.

Niiden ero on enemmän UX-tyyppinen. AWS:n S3 antaa suoraan aidot linkit tiedostoihin. Hetznerin S3 antaa polun tiedostoon. Sitten täytyy erikseen kopioida endpoint. Sitten täytyy lisätä endpointin alkuun bucketin nimi. Ja lopuksi liimata nuo yhteen. Vähintäänkin ärsyttävää ja epämukavaa. Ehkä he kehittävät tuota jossain vaiheessa.

Joten otin Hetznerin S3:n käyttöön. Koska ne käyttävät samaa kieltä ja rakennetta, niin yksinkertaisella bash-scriptillä tiedostojen siirto AWS:stä Hetzneriin on kohtuullisen vaivatonta asw cli avulla.

Nyt podcastini tulevat Hetznerin tiedostosäilöstä AWS:n S3 sijaan.

Rumat domainit

Podcastin aito url näkyy aniharvoin kenellekään. Mutta silti url malliin https://podcastit.hel1.your-objectstorage.com/kaffepaussi/podcast-149.mp3 saa amalgaamit kirkumaan tuskasta ja silmät vuotamaan verta. Se täytyy muuttaa joksikin inhimillisemmäksi.

Aidon CDN:n käyttö tekisi sen, koska silloin käytetään omaa domainia. Mutta kun en halua maksaa CDN:stä, koska se ei tuo mitään etua.

Tuohon on olemassa kiertotie. Tehdään Nginxillä proxy ja kierrätetään sitä kautta pyynnöt Hetznerin S3:een. Se mahdollistaa myös suunnitelmien muuttumisen tulevaisuudessa. Jos yhtä äkkiä päätänkin käyttää jonkun muun myymää S3-säilöä, niin muutan vain Nginxin proxyn kohdetta.

Mikä parasta, niin tuo ei maksa mitään. Toki S3:n verran, mutta senhän joutuu kuitenkin maksamaan aivan riippumatta minkä näköinen url on.

Hetzner S3 domainin muuttaminen

Tämä onnistunee Apachellakin, mutta en tiedä miten siellä nämä tehdään. Minä käytän reverse proxyna Nginxiä.

Kaikessa seuraavassa minä toimin aina rootin ominaisuudessa. Olen serverini ainoa käyttäjä ja jos SSH murretaan, niin silloin murtuu rootinkin tili, eikä sudon käyttö pelasta miltään. Mutta kun kuitenkin olet normaalina käyttäjänä liikkeellä, niin muista sudo oikeisiin paikkoihin.

Ensiksi täytyy lisätä DNS-tietoihin haluttu domain. Minä käytän podcast.katiska.eu. Voisi se olla myös cdn, mutta olen kyllästynyt siihen, eikä tuo ole määritelmällisesti eikä toiminnallisesti content delivery network, sisällönjakoverkko.

Nginxille tarvitaan host. Muista, että esimerkki on live, joten muokkaa se kohdalleen. Ja ei, vaikka yrittäisit käyttää tuota päästäksesi buckettiini, niin se ei nyt vaan toimi niin (ystävällinen vinkki, koska joku yritti sitä).

server {    listen 443 ssl;    http2 on;    server_name podcast.katiska.eu;    # Let’s Encryptin sertit    ssl_certificate /etc/nginx/dummy-certs/dummy.crt;    ssl_certificate_key /etc/nginx/dummy-certs/dummy.key;    ssl_protocols TLSv1.2 TLSv1.3;    ssl_prefer_server_ciphers on;    ssl_ciphers HIGH:!aNULL:!MD5;    # CORS-headereita jos audiosoitin tarvitsee niitä    add_header Access-Control-Allow-Origin *;    add_header Access-Control-Allow-Methods "GET, HEAD" always;    # Proxy S3-tiedostoille Hetzneriltä    location /kaffepaussi/ {        proxy_pass https://podcastit.hel1.your-objectstorage.com/kaffepaussi/;        proxy_set_header Host podcastit.hel1.your-objectstorage.com;        # Poistetaan mahdollinen Varnish cache-bypass-otsikko        proxy_set_header X-Bypass-Cache "";        # Sallitaan puskurointi        proxy_buffering on;        proxy_request_buffering off;        # Estetään gzip (S3 palauttaa jo valmiiksi sopivasti)        proxy_set_header Accept-Encoding "";        # Poistetaan virheellinen SSL-verifikaatio, jos ongelmia        proxy_ssl_verify off;    }}server {    listen 80;    server_name podcast.katiska.eu;    # Pakotetaan HTTPS    return 301 https://$host$request_uri;}

• Jos et tiedä miten dummy SSL-sertikaatti tehdään, niin googleta. Se on siellä vain siksi, että saan lennosta conffin kuntoon ennen Let’s Encryptiä. Voit toki tehdä saman perinteistä tietä laittamalla ensin vain serveriblokin 80, hakemalla SSL:n ja sitten muokkaamalla 443 kuntoon.

Tarvitaan SSL-sertifikaatti.

certbot --nginx -d podcast.katiska.eu

Ja perään tietysti:

nginx -t && systemctl reload nginx

Se oli siinä. Nyt urlit ovat paljon kauniimpia.

Entä ne WordPressin linkit?

Yleensä jotain tällaista tehdään siinä vaiheessa, kun on jo jotain käytössä (tämähän toki toimii muullekin kuin vain podcast-audiolle). Joten pelkästään se, että on kopioinut tiedostot S3:een, ei riitä. WordPressin sisällössä täytyy linkit myös muuttaa.

Käsin moinen homma on kurjaa ja SQL:n suora tökkiminen on riskialtista. Käytä WP CLI:tä, kuten jokaisem WordPress-adminin kuuluisi tehdä.

Ihan ensimmäiseksi turvaa selustasi ja tee tietokannasta varmuuskopio.

wp --allow-root db export tietokanta.sql

• kyllä, edelleenkin olen root; tuo kannattaa laittaa aliakseksi malliin wp='wp --allow-root'

Sitten tehdään haku ja korvaus, search & replace. Ja tässäkin, muokkaa itsellesi sopivaksi.

wp --allow-root search-replace \  'https://podcastit.hel1.your-objectstorage.com/kaffepaussi/' \  'https://podcast.katiska.eu/kaffepaussi/' \  --skip-columns=guid --precise --all-tables

Tuo ei tosin toimi minulla, koska podcasteissä käyttämäni Seriously Simple Podcast ei tallenna audion polkua itse artikkeliin vaan metatietoihin kentällä audio_file. Joten joudun menemään hieman toista reittiä.

Ensin kannattaa kokeilla, että saa jollain aidolla artikkeli-ID:llä sen urlin mitä on muuttamassa.

wp post meta get 158851 audio_file

Tuo antoi vastaukseksi

https://podcastit.hel1.your-objectstorage.com/kaffepaussi/podcast-149.mp3

Sitten tehdään vähän luuppikierroksia. Tämä toimii komentoriviltä, mutta on hieman tarkka sisennyksistä, kauttaviivoista ja sellaisista. Joten se voi laittaa scriptiksikin.

Huomio. Jos käyttää wp --allow-root aliasta, niin se toimii komentorivillä ensimmäisessä. Mutta jos on scripti, niin se täytyy lisätä sinne. Samaten jos on on pipe, niin alias toimii vain ensimmäisessä, muihin --allow-root täytyy lisätä.

#!/bin/bashecho "id,old_url,new_url" > podcast-url-replacements.csvpost_ids=$(wp --allow-root post list --post_type=post --post_status=publish --format=ids)for id in $post_ids; do  current_url=$(wp --allow-root post meta get "$id" audio_file 2>/dev/null)  if [[ "$current_url" == https://podcastit.hel1.your-objectstorage.com/kaffepaussi/* ]]; then    new_url="${current_url/podcastit.hel1.your-objectstorage.com/podcast.katiska.eu}"    echo "🔁 $id: $current_url → $new_url"    wp --allow-root post meta update "$id" audio_file "$new_url" >/dev/null    echo "$id,$current_url,$new_url" >> podcast-url-replacements.csv  fidone

Sitten kannattaa tarkistaa, että urlit ovat tosiaan muuttunneet.

#cdn #hetzner #nginx #podcast #wordpress

For people with large WebSocket workloads using the ingress-nginx controller.

I recently hit this issue:

https://github.com/kubernetes/ingress-nginx/issues/2461

This drops all current WebSocket connections when ever the controller reloads the config. This can be triggered by adding/removing a new Ingress object (which this project does regularly due to customer load).

We ended up moving the WebSocket ingress to a separate LoadBalancer/Ingress class.

#kubernetes #nginx #websockets

Dockerising Flutter Web app with dockerised Flutter build:
https://www.glukhov.org/post/2025/06/dockerising-flutter-web-app/
#Docker #flutter #webapp #build #nginx

I just launched a new phpBB forum. The rollout was super smooth despite my doing it via git deployment. I feel like I’ve reached a comfortable level with my Nginx configuration skill.

The hardest part was setting up Postfix with Domain Keys and Sender Policy Framework correctly.

#phpBB #Nginx

@kaixin @feld or just setup #nginx to serve the #html #poudriere creates: live observation in the browser.

All the "scrolling crap" ends up in individual logfiles, very helpful to debug occassional issues.

第867回　「後で読む」サービスのWallabagをUbuntuでセルフホストする
https://gihyo.jp/admin/serial/01/ubuntu-recipe/0867?utm_source=feed

#gihyo #技術評論社 #gihyo_jp #業界動向 #OS #アプリケーション #ネットワーク技術 #お役立ち情報 #Ubuntu #DNS #Wallabag #PHP #nginx #Pocket

I've said this before, but I can't say it enough: OpenResty (nginx+lua) is painfully underappreciated. It's fantastic, and the only platform I trust for very high volume, high performance, mission critical web application servers.

#openresty #nginx #webdev

Forbidden art, you say? 🎨🚫 More like forbidden access. Clearly, Richard Foreman’s work is so avant-garde, even the internet can't handle it. Must be that cutting-edge #nginx performance art. 🙄💻
https://yalereview.org/article/jennifer-krasinski-richard-foreman #forbiddenart #avantgarde #performanceart #internetculture #creativity #HackerNews #ngated