Mastodon 🐘

Kamalavelan<a href="https://mastodon.social/@douglasvb" class="u-url mention" rel="nofollow noopener" target="_blank">@douglasvb</a> I think the "new age" mix is to use <a href="https://mastodon.xyz/tags/Caddy" class="mention hashtag" rel="nofollow noopener" target="_blank">#Caddy</a> with <a href="https://mastodon.xyz/tags/FrankenPHP" class="mention hashtag" rel="nofollow noopener" target="_blank">#FrankenPHP</a>. I have tested it out but haven't migrated from my current setup of <a href="https://mastodon.xyz/tags/nginx" class="mention hashtag" rel="nofollow noopener" target="_blank">#nginx</a> & <a href="https://mastodon.xyz/tags/phpfpm" class="mention hashtag" rel="nofollow noopener" target="_blank">#phpfpm</a>

Gea-Suan Lin<a href="https://blog.gslin.org/archives/2025/09/05/12609/%e7%94%a8-caddy-%e5%9c%a8%e5%90%8c%e4%b8%80%e5%80%8b-port-%e5%90%8c%e6%99%82%e6%9c%8d%e5%8b%99%e7%b6%b2%e7%ab%99%e8%88%87-https-proxy/" rel="nofollow noopener" translate="no" target="_blank">https://blog.gslin.org/archives/2025/09/05/12609/%e7%94%a8-caddy-%e5%9c%a8%e5%90%8c%e4%b8%80%e5%80%8b-port-%e5%90%8c%e6%99%82%e6%9c%8d%e5%8b%99%e7%b6%b2%e7%ab%99%e8%88%87-https-proxy/</a>用 Caddy 在同一個 Port 同時服務網站與 HTTPS Proxy<a href="https://abpe.org/tags/address" class="mention hashtag" rel="nofollow noopener" target="_blank">#address</a> <a href="https://abpe.org/tags/caddy" class="mention hashtag" rel="nofollow noopener" target="_blank">#caddy</a> <a href="https://abpe.org/tags/http" class="mention hashtag" rel="nofollow noopener" target="_blank">#http</a> <a href="https://abpe.org/tags/https" class="mention hashtag" rel="nofollow noopener" target="_blank">#https</a> <a href="https://abpe.org/tags/ip" class="mention hashtag" rel="nofollow noopener" target="_blank">#ip</a> <a href="https://abpe.org/tags/nginx" class="mention hashtag" rel="nofollow noopener" target="_blank">#nginx</a> <a href="https://abpe.org/tags/port" class="mention hashtag" rel="nofollow noopener" target="_blank">#port</a> <a href="https://abpe.org/tags/proxy" class="mention hashtag" rel="nofollow noopener" target="_blank">#proxy</a> <a href="https://abpe.org/tags/server" class="mention hashtag" rel="nofollow noopener" target="_blank">#server</a> <a href="https://abpe.org/tags/squid" class="mention hashtag" rel="nofollow noopener" target="_blank">#squid</a> <a href="https://abpe.org/tags/tls" class="mention hashtag" rel="nofollow noopener" target="_blank">#tls</a> <a href="https://abpe.org/tags/web" class="mention hashtag" rel="nofollow noopener" target="_blank">#web</a>

GeeklandManual de Implementación de Keycloak en Alta Disponibilidad (HA) <a href="https://mastodon.social/tags/cluster" class="mention hashtag" rel="nofollow noopener" target="_blank">#cluster</a> <a href="https://mastodon.social/tags/keycloak" class="mention hashtag" rel="nofollow noopener" target="_blank">#keycloak</a> <a href="https://mastodon.social/tags/nginx" class="mention hashtag" rel="nofollow noopener" target="_blank">#nginx</a> <a href="https://mastodon.social/tags/postgresql" class="mention hashtag" rel="nofollow noopener" target="_blank">#postgresql</a> <a href="https://mastodon.social/tags/unix___" class="mention hashtag" rel="nofollow noopener" target="_blank">#unix___</a>*bsd___gnu_linux <a href="https://red-orbita.com/" rel="nofollow noopener" translate="no" target="_blank">https://red-orbita.com/</a>

Dusty<a href="https://aus.social/@kgoetz" class="u-url mention" rel="nofollow noopener" target="_blank">@kgoetz</a> I use <a href="https://autistics.life/tags/nginx" class="mention hashtag" rel="nofollow noopener" target="_blank">#nginx</a> in <a href="https://autistics.life/tags/Debian" class="mention hashtag" rel="nofollow noopener" target="_blank">#Debian</a> a lot. My fav web server. Just saying. <a href="https://autistics.life/tags/OpenSource" class="mention hashtag" rel="nofollow noopener" target="_blank">#OpenSource</a> <a href="https://autistics.life/tags/Linux" class="mention hashtag" rel="nofollow noopener" target="_blank">#Linux</a>

Jakke LehtonenError 502 ja sivustojen backup-näyttö<a href="https://www.eksis.one/palvelimet/error-502-ja-sivustojen-backup-naytto/" rel="nofollow noopener" translate="no" target="_blank">https://www.eksis.one/palvelimet/error-502-ja-sivustojen-backup-naytto/</a>Tuskin kukaan pitää tilanteesta, jossa selain esittää kliinisen kylmän error 500/502/503/504 virheen. Kävijät siksi, että eivät näe sisältöä. Ylläpito siksi, että 50x-sarjan virheet kertovat, että jokin serverillä on nurin, mutta ei anna pienintäkään viitettä syystä.Kertomattomuus johtuu siitä, että viallinen ei pysty kertomaan mihin sattuu, ja kuunteleva ei ymmärrä mistä on kyse.Omassa stackissa Nginx – Varnish – Apache2 (PHP, MariaDB, WordPress) virhekoodi saattaa antaa jotain suuntaa.<ul><li>500: Nginx tai virtuaalihostin konffi on rikki</li><li>502: Varnish on kaatunut</li><li>503: useimmiten Apache2 on kaatunut</li><li>504: Apachen takana oleva WordPress on sekaisin</li></ul>Mutta tuohonkin on olemassa poikkeuksia ja kaikki riippuu siitä miten ongelmakohta pystyy vastaamaan pyyntöihin ja miten kyselijä ilmoituksen tulkitsee.Varajärjestelmän varajärjestelmäOlen kehittänyt 50x-sarjan virheistä itselleni eräänlaisen pakkomielteen. Osaksi koska inhoan niitä syvästi ja osaksi siksi, että pääsääntöisesti minä olen syypäänä onnistunut kaatamaan tai rikkomaan jotain. Aika harvoin ohjelmat itsessään hajoavat, vaikka niitäkin tapauksia on ollut.Katkokset ovat siten suolaa haavoihin hierova muistutus kädettömän sysadminin ammattitaidottomuudesta. Tai en tiedä voidaanko tällaisen kotitarveylläpitäjän kohdalla puhua ammattitaidottomuudesta. Kyse on pelkästään kyvyttömyydestä. Ja huolimattomuudestakin aika usein.Ongelman toinen puoli on se, että en aina tiedä suoraan miten virheen korjaan. Tunteja voi kulua, ja koko sen ajan jokainen sivusto on saavuttamattomissa. Joten tarvitsin mahdollisuuksien mukaan joko informatiivisemmat virhesivut tai jonkun backup-järjestelmän, joka esittää sisällön.Palapeli palapelin selässäMinulla työnkuva on useimmiten mallia on ongelma, etsin ensimmäisen ratkaisun, ongelma laajenee, etsin uuden ratkaisun, en tiedä mihin päädyn ja miten.50x-virheiden kohdalla tuo tarkoittaa sitä, että ensin lähdin säätämään virhesivuja. Niiden muuttaminen on aika triviaalia, mutta lisäinformaation saaminen ei ollut. Joten tyydyin vain muuttamaan tekstiä ja kerjäämään ihmisiä kertomaan, että sivustot ovat alhaalla.En yleensä saanut mitään tietoa kaatumisista, koska kaupalliset monitorit ovat kalliita ja ilmaiset ratkaisut aina jollain tapaa ongelmallisia.Joten seuraavaksi aloin selvittämään miten pystyisin saamaan tiedon minulle sopivalla tavalla, kun jokin palvelu ei tee sitä mitä sen kuuluisi. Olin aiemmin oivaltanut, että sellaista outoutta kuin API voidaan käyttää keskustelujen avaamiseen <a href="https://foorumi.katiska.eu" rel="nofollow noopener" target="_blank">Discourse-foorumillani</a> — ja se osaa lähettää push-ilmoituksia minulle.Joten ensin pienen ja sitä seuranneen isomman riidan jälkeen sain rakennettua tavan, jossa <a href="https://www.eksis.one/palvelimet/kevyt-serverimonitori-varnishille-ja-apache2/" rel="nofollow noopener" target="_blank">Nginx kertoo Plesk-serverille 50x-virheestä</a>. Se taasen esittää kustomoidun virheilmoituksen ja avaa Discoursessa ketjun sille virheelle.Varnish tuuraa ApacheaSiinä samalla oli alkanut itää ajatus esittää backup-sisältöä. Miksi tyytyä virheilmoituksiin, jos voisikin esittää edes jotain sisältöä.Helpointa, ainakin sillä hetkellä, oli keskittyä 503/504-virheisiin. Tilanteisiin, joissa Varnish käy ja kukkuu, mutta Apache2 tai WordPress on kaatunut. Helpointa siksi, että minullahan oli jo sisältö valmiina, ainakin osaksi: Varnishin cachessa. Se sisältö ei muutoinkaan koskaan piittaa backendistä; se on cachen pointti ja merkitys. Cache hyödyttää korvikesisältönä vain, jos cache lämmitetään, eli kaikki kopioidaan sinne. Se tavataan tehdä wgetillä — joka kykenee luomaan kohtuullisesti toimivan staattisen version sivustoista.Joten kun alkuperäinen tavoite oli vain lämmittää cache, niin olin tullut luoneeksi siinä ohessa snapshot-sisältöä. Tein siitä <a href="https://www.eksis.one/palvelimet/snapshot-serveri-503-virheelle-ja-varnish/" rel="nofollow noopener" target="_blank">varajärjestelmän varajärjestelmän</a>.Apache2/WordPress kaatuu. Niin kauan kun kukaan ei tee POST-kutsua tai pyydä sellaista, jota ei voida cachettaa, niin kukaan ei tiedä ongelmista mitään. Kaikki tulee 1:1 kopioina Varnishista.Varnish saa tiedon backendin hengettömyydestä, kun pyydetään sisältöä, jota ei löydy cachesta. Se vaihtaa backendiä ja hakeekin Nginxin kautta snapshot-sisällön, jos se on kelvollista (GET/HEAD) , tai esittää tympeän virheilmon (POST, admin jne.). Kyllä, olisin voinut tuottaa Nginxin kautta dynaamisen sisällön, mutta en lähtenyt sille tielle. En halua sählätä liikaa tietokannan kanssa. Jos se hajoaa, vaikka kaksoiskäytön takia, niin olen liian syvissä vesissä täysin uimataidottomana. Pelkään tietokantoja.Kun snapshot-sisältöön siirrytään, niin siitä menee tieto Pleskille, joka kertoo Discourselle, joka kertoo minulle.Samaan aikaan kävijät eivät tiedä mitään ongelmista, cachen takia, tai saavat ehkä hieman rikkinäisen, mutta käytettävän sisällön. Eivät jotain error-ilmoitusta.Kuka tuuraa Varnishia?Minulla useimmiten kaatuu Varnish. Ei sen takia, että se olisi epävakaa, vaan koska säädän sitä aina kun on liikaa vapaa-aikaa. Minun säätöni tapaavat olla aika riskialttiita. Joten tarvitsin jonkin turvajärjestelmän Varnishin kaatumisen varalta.Minulla on Nginx ja minulla on valmis snapshot-sisältö. En siis tarvinnut muuta kuin tavan tunnistaa 502-virhe, eli Varnishin kaatuminen, ja sen myötä kääntääkin proxy-liikenne uuteen suuntaan: snapshot-serverille, joka oli Nginxin hoivissa.Tässäkin vain staattiset kyselyt kelpasivat, koska tavoitteeni ei ollut milloinkaan rakentaa täysin toimivaa korvaajaa. Halusin tarjota jotain sisältöä virheilmoituksen sijaan.Sain sen rakennettua. Mutta minulla oli melkoisia ongelmia saada kävijät pois emergency-reitiltä takaisin normaaliin siinä vaiheessa, kun Varnish palasi linjoille.Tiesin entisestään, että mm. Bing ei piittaa 410 virheistä, tai redirect 301/302 erosta, vaan koputtelee maailman tappiin saakka kaikkea löytämäänsä. Päinvastoin kuin mitä Google selittää, niin samaa tekee osaltaan googlebot ja varsinkin google-image. Mutta minulle oli yllätys kuinka vähän laillisetkin botit piittasivat 302 käännön väliaikaisuudesta sekä cache-headereista, jotka ohjasivat olemaan tallentamatta sisältöä.Ne indeksoivatki suunnilleen kaiken ja väliaikaisiksi leimattuja emergency-polkuja alkoi löytymään hakutuloksista. Tuo ei ollut haluttua.Snapshot versio 2Nginxin serveriblokit alkoivat lisäksi olla melkoista sekasotkua. Oli mappia ja oli if-lausetta. Kaikki hyvin pitkälle siksi, että kun kävijän saaminen emergency-reitille ja snapshot-serverille ei ollut kovinkaan vaikeaa, niin en saanut selaimia pois hätäreitiltä, kun paniikki oli ohi.Javascriptillä toki olisi onnistunut, mutta siitä en tiedä mitään. En minä ole koodari. Minä olen kopypeistaaja.Riitelin taas kerran Nginxin kanssa tämän asian puitteissa. Olin sammuttanut Varnishin simuloidakseni Varnishin kaatumista ja koska normaalisti Varnish käynnistyy hitaasti, niin hyödynsin sen panic-toimintaa simulaationa tilanteen normalisoitumisessa. Se kun käynnistyy silmänräpäyksessä.Minulla on panic-scripti tilanteita varten, jossa Varnish kaatuu, ja tiedän korjauksen vievän aikaa. Siinä master ohitetaan CLI:n avulla. Joten jos Varnishin ytimessä henki pihisee, niin saan sen käyntiin. Toki menetän cachen ja sellaisia asioita, mutta sivustoille pääsee Varnishin ollessa vain tyhmä putki.Jäin testeissäni ihmettelemään mitä olin juuri tehnyt. Olin käynnistänyt tmuxin, koska CLI täytyy olla koko ajan käynnissä, ja potkaissut Varnishin prosessin käyntiin. Mutta virallisestihan Varnish oli edelleen naamallaan, ja sehän on juurikin se tilanne, jonka hätätoimintoa yritin Nginxillä rakentaa.Olen tehnyt tuon ennenkin, monta kertaa. Kuten kun sekoilin kääntämisessä, ja rikoin Varnishin, niin pyöritin sitä tmuxin sisällä CLI:n kautta lähes viikon. Joten… miksi en tekisi samaa nyt, mutta ilman tmuxia ja automatisoituna, jolloin minun ei tarvitse riidellä niin paljon emergency-polun kanssa.Puolikkaan työpäivän ja useiden kokeilujen ja erehdysten jälkeen minulla on nyt järjestelmä, jossa Varnishin kaatuessa 10 sekunnin ajan esitetään virheilmoitus ja pyydetään kävijältä reload (tuo viive on Pleskin takia, luultavasti 5 sekuntiakin riittäisi varnistamaan, että API-pyyntö lähtee Discourseen).Seuraavaksi käynnistetään Varnish CLI-malliin mutta automaattisesti scriptillä. Taustalla käydään kyselemässä aika ajoin onko aito Varnish vihdoin järjissään ja kun se on käynnistynyt, niin vaihdetaan paniikki-Varnishista aitoon normaaliin Varnishiin.Eikä kukaan huomaa mitään — paitsi sen ensimmäisen 10 sekunnin ajan.Mutta… jos Varnish kaatuu oikeasti?Tuo järjestelmä ei ole todellakaan aukoton. Kaikkea muuta. Mutta noin 98 kertaa sadasta Varnishin kaatuminen on sellainen, että uusi instanssi saadaan käynnistettyä.Jos Varnish on täysin kuollut, niin sille ei ole varsinaista varajärjestelmää. Snapshot-serverin emergency ei onnistu minun taidoillani. Se hemmetin emergency-polku pysyy siellä, kiitos selainten. Ja koska moinen päätyy hakukoneisiin, niin en käytä sitä. Esitän mieluummin virheilmoitusta.Lisään emergencyn polkuun kahdesta syystä. Ensimmäinen on, että sillä estän wgetin muokkaaman (ja hieman rikkoman) sisällön saastuttamasta aitoa cachea. Toinen syy on, että silloin urista näkee, että ei olla normaalitilanteessa.Jos backend on saavuttamattomissa, niin Varnish ja Nginx käyttävät cacheamattoman sisällön kohdalla emergency-polkua. Mutta cachen lämmitys on noin 95 prosenttisen tehokas, joten se tulee käyttöön erittäin harvoin. Kun tulee, niin Varnish siivoaa emergemcy-osan pois vastauksesta tilanteen normalisoiduttua.Ihmiset näkevät emergencyn urlissa korjaantumisen jälkeenkin, paitsi jos klikkaavat jotain uutta linkkiä — merkintä lisätään Nginxissä, ei snapshotteihin — mutta botit näkevät polun oikein oikeilla headereilla. Eikä ihmisistä ole väliä, koska selaimethan eivät enää edes varsinaisesti näytä urlia.Mutta jos Varnish on totaalisen kuollut, niin laitan Nginxin juttelemaan suoraan Apachen kanssa. Se on vielä manuaalinen säätö, mutta tiedän miten sen saisi semiautomaattiseksi — ehkä teen sen muutoksen, kun taas on hieman liikaa vapaa-aikaa.Varajärjestelmä tämä kirjoitettaessaJos backend kaatuu, niin Varnish käyttää cachea tai ohjaa Nginxin kautta snapshot-sisältöön.Jos Varnish kaatuu, niin käynnistetään toisenlainen Varnish, joka keskustelee suoraan backendin kanssa.Jos Varnish kaatuu totaalisesti, niin pakotan manuaalisesti Nginxin juttelemaan Apachen kanssa.Jos Nginx kaatuu… tuota en ole vielä tehnyt, mutta minulla on alustava konsepti. Ehkä saisin Hitchin tai muun SSL/TSL-terminaattorin hoitamaan saapuvan liikenteen ja kääntäisin sen tyhmälle paniikki-Varnishille.Miten koostin nykyisen Varnish korvaa Varnishin?Alleviivaan jo mainittua: en ole koodari. Tämän olisi varmaan voinut tehdä helpomminkin, mutta minä en tätä kummallisempaan kyennyt.Nginx kääntää uudelle proxylle:Ennen server-blokkia (käytä omia porttejasi):❯ Näytä koodi<pre><code>[map $panic $varnish_upstream ](#) 0 127.0.0.1:8080; # normaali Varnish 1 127.0.0.1:8081; # panic-Varnish}</code></pre>Server-blokkiin:❯ Näytä koodi<pre><code>set $panic 0; if (-f /run/emergency_on) { set $panic 1; } location / { proxy_pass http://$varnish_upstream;...</code></pre>Varnishin kaatumisen ja nousun tunnistusVarnishin tilaa vahtii scripti <code>varnish-switchover.sh</code>:❯ Näytä koodi<pre><code>#!/usr/bin/env bashset -euo pipefail# stop doing several ones at the same timeexec 9>/run/varnish_switchover.lockflock -n 9 || exit 0HEALTH_URL="http://127.0.0.1:8080/"EMER_FLAG="/run/emergency_on"OK_CNT="/run/varnish_ok.count"BAD_CNT="/run/varnish_bad.count"BAD_SINCE="/run/varnish_bad_since.ts"MIN_BAD_SEC=10# Checking if actual Varnish is healthyif varnishadm -T 127.0.0.1:6082 -S /etc/varnish/secret -t 1 ping >/dev/null 2>&1; then healthy=1else healthy=0fiinc() { local f="$1"; local n=0; [[ -f "$f" ]] && n=$(cat "$f" 2>/dev/null || echo 0); echo $((n+1)) > "$f"; }reset() { : > "$1"; }if (( healthy )); then # reseting “bad since” [[ -f "$BAD_SINCE" ]] && rm -f "$BAD_SINCE" # keep small hysteresis: 2 OK in the row before dropping the flag inc "$OK_CNT"; reset "$BAD_CNT" if (( $(cat "$OK_CNT") >= 2 )); then [[ -f "$EMER_FLAG" ]] && rm -f "$EMER_FLAG" fielse # first BAD → mark startingtime (at this point Plesk get time to do its jobs, like post to Discourse) if [[ ! -f "$BAD_SINCE" ]]; then date +%s > "$BAD_SINCE" reset "$OK_CNT" fi inc "$BAD_CNT" bad_for=$(( $(date +%s) - $(cat "$BAD_SINCE" 2>/dev/null || echo 0) )) # raise the flag when BAD has been at least MIN_BAD_SEC if (( bad_for >= MIN_BAD_SEC )); then [[ -f "$EMER_FLAG" ]] || touch "$EMER_FLAG" fifi</code></pre>Se käyttää paria laskuria määrittelemään koska reagoidaan. Kun normaali Varnish ei vastaa kahteen kyselyyn peräkkäin, niin 10 sekunnin kuluttua asetetaan lippu <code>/run/emergency_on</code> . Sen löytyessä Nginx vaihtaa proxyksi paniikki-Varnishin.Scriptin kutsuu system-unit <code>varnish-healthcheck.service</code> :❯ Näytä koodi<pre><code>[Unit]Description=Varnish healthcheck and switchover[Service]Type=oneshotExecStart=/usr/local/sbin/varnish-switchover.sh</code></pre>Sitä taasen ajastaa 5 sekunnin välein <code>varnish-healthcheck.timer</code>:❯ Näytä koodi<pre><code>[Unit]Description=Run Varnish healthcheck every 30s[Timer]OnBootSec=10sOnUnitActiveSec=30sAccuracySec=1sUnit=varnish-healthcheck.service[Install]WantedBy=timers.target</code></pre>Aikaa voi toki muuttaa ja itse käytän hieman nopeasti reagoivaa.Paniikki-Varnish käynnistyy scriptillä <code>varnish-panic.sh</code> :❯ Näytä koodi<pre><code>#!/usr/bin/env bash# Automatic panic handlingset -euo pipefailexec 9>/run/varnish-panic.lockflock -n 9 || { echo "panic varnish already running"; exit 0; }# Original:# varnishd -I /etc/varnish/start.cli.emerg -P /var/run/varnish.pid \# -j unix,user=vcache -F -a :8080 -T localhost:6082 -f "" \# -S /etc/varnish/secret -s malloc,256M/usr/sbin/varnishd \ -n panic \ -a 127.0.0.1:8081 \ -T 127.0.0.1:6083 \ -S /etc/varnish/secret \ -s malloc,256M \ -j unix,user=vcache \ -F \ -f '' \ -I /etc/varnish/start.cli.emerg</code></pre>Koska molemmat Varnishit ovat koko ajan yhtä aikaa käynnissä, niin<ul><li>paniikki tarvitsee oman työhakemiston asetettuna -n lipulla</li><li>paniikki ei saa kuunnella samaa porttia Nginxin suuntaan kuin normaali</li><li>paniikki ei saa kuunnella backendiään samassa portissa kuin normaali</li><li>kommentoitu <code>Original</code> kohta toimii yksinään manuaalisena <code>panic.sh</code> ratkaisuna; kannattaa ajaa esim. tmuxissa</li></ul>Lisäksi paniikki tarvitsee oman käynnistystiedoston. Jos se käyttää samaa <code>default.vcl</code> tiedostoa tai vastaavaa, niin se kaatuu aivan samalla tavalla. Käyttämäni <code>start.cli.emerg</code> on:❯ Näytä koodi<pre><code>vcl.load hot /etc/varnish/emergency.vclvcl.use hot</code></pre>Ja tarvittava <code>emergency.vcl</code> on perusmallinen vcl, joka määrittelee backendit ja asettaa <code>return(pipe):</code>. Löydät sen täältä:<a href="https://github.com/eksiscloud/Varnish_7.x-multiple_sites/blob/main/emergency.vcl" rel="nofollow noopener" target="_blank">https://github.com/eksiscloud/Varnish7.x-multiplesites/blob/main/emergency.vcl </a>Paniikki-Varnishin käynnistysscriptin pitää hengissä system-unit <code>varnish-panic.service</code>:❯ Näytä koodi<pre><code>[Unit]Description=Varnish PANIC instance on :8081After=network-online.targetWants=network-online.target[Service]Type=simpleExecStart=/usr/local/bin/varnish-panic.shRestart=alwaysRestartSec=2sUser=rootGroup=root[Install]WantedBy=multi-user.target</code></pre>Omassa Ubuntussa systemd-yksiköt, service ja timer, löytyvät hakemistosta <code>/etc/systemd/system/</code> ja scriptit olen tottunut laittamaan hakemistoon <code>/usr/local/bin</code>.Servicet ja timerit vaativat sekä <code>systemctl daemon-reload</code> kuin myös <code>systemctl enable --now <nimi></code>. Scriptit muuttuvat ajettavaksi <code>chmod +x <nimi></code>.Kaikki Varnishiin liittyvät löytyvät reposta <a href="https://github.com/eksiscloud/Varnish_7.x-multiple_sites" rel="nofollow noopener" target="_blank">https://github.com/eksiscloud/Varnish_7.x-multiple_sites</a><a rel="nofollow noopener" class="hashtag u-tag u-category" href="https://www.eksis.one/tag/apache2/" target="_blank">#apache2</a> <a rel="nofollow noopener" class="hashtag u-tag u-category" href="https://www.eksis.one/tag/nginx/" target="_blank">#nginx</a> <a rel="nofollow noopener" class="hashtag u-tag u-category" href="https://www.eksis.one/tag/valvonta/" target="_blank">#valvonta</a> <a rel="nofollow noopener" class="hashtag u-tag u-category" href="https://www.eksis.one/tag/varnish/" target="_blank">#varnish</a>

Sleve McDichaelAny network engineers who can shed some light on if an nginx 403 error can come from a site refusing IPv4 connections? The site in question (readanybook.com) works when used from an IPv6 enabled network and that's the only difference I can see. <a href="https://mastodon.online/tags/nginx" class="mention hashtag" rel="nofollow noopener" target="_blank">#nginx</a> <a href="https://mastodon.online/tags/network" class="mention hashtag" rel="nofollow noopener" target="_blank">#network</a> <a href="https://mastodon.online/tags/NetworkEngineering" class="mention hashtag" rel="nofollow noopener" target="_blank">#NetworkEngineering</a> <a href="https://mastodon.online/tags/internet" class="mention hashtag" rel="nofollow noopener" target="_blank">#internet</a> <a href="https://mastodon.online/tags/IPv6" class="mention hashtag" rel="nofollow noopener" target="_blank">#IPv6</a>

jordanLOL Who tried to scan/blast me?<a href="https://git.jordanwages.com/wagesj45/wagenet-ip-ban-list" rel="nofollow noopener" translate="no" target="_blank">https://git.jordanwages.com/wagesj45/wagenet-ip-ban-list</a><a href="https://mastodon.jordanwages.com/tags/network" class="mention hashtag" rel="nofollow noopener" target="_blank">#network</a> <a href="https://mastodon.jordanwages.com/tags/security" class="mention hashtag" rel="nofollow noopener" target="_blank">#security</a> <a href="https://mastodon.jordanwages.com/tags/networksecurity" class="mention hashtag" rel="nofollow noopener" target="_blank">#networksecurity</a> <a href="https://mastodon.jordanwages.com/tags/banlist" class="mention hashtag" rel="nofollow noopener" target="_blank">#banlist</a> <a href="https://mastodon.jordanwages.com/tags/nginx" class="mention hashtag" rel="nofollow noopener" target="_blank">#nginx</a> <a href="https://mastodon.jordanwages.com/tags/fail2ban" class="mention hashtag" rel="nofollow noopener" target="_blank">#fail2ban</a>

mastodon.raddemo.hostHow to Setup a Reverse <a href="https://mastodon.raddemo.host/tags/Proxy" class="mention hashtag" rel="nofollow noopener" target="_blank">#Proxy</a> with HTTPS Using <a href="https://mastodon.raddemo.host/tags/Nginx" class="mention hashtag" rel="nofollow noopener" target="_blank">#Nginx</a> and <a href="https://mastodon.raddemo.host/tags/Certbot" class="mention hashtag" rel="nofollow noopener" target="_blank">#Certbot</a> (5 Minute Quick-Start Guide) This article outlines how to setup a reverse proxy with HTTPS using Nginx and Certbot. What is a Reverse Proxy? A reverse proxy is a server that sits between client devices and a backend server, forwarding client requests to the backend server and returning the server's response to the clients. Unlike a forward proxy, ... Continued 👉 <a href="https://blog.radwebhosting.com/how-to-setup-a-reverse-proxy-with-https-using-nginx-and-certbot-5-minute-quick-start-guide/?utm_source=ReviveOldPost&utm_medium=social&utm_campaign=ReviveOldPost" rel="nofollow noopener" target="_blank">https://blog.radwebhosting.com/how-to-setup-a-reverse-proxy-with-https-using-nginx-and-certbot-5-minute-quick-start-guide/?utm_source=ReviveOldPost&utm_medium=social&utm_campaign=ReviveOldPost</a> <a href="https://mastodon.raddemo.host/tags/proxyserver" class="mention hashtag" rel="nofollow noopener" target="_blank">#proxyserver</a> <a href="https://mastodon.raddemo.host/tags/reverseproxy" class="mention hashtag" rel="nofollow noopener" target="_blank">#reverseproxy</a> <a href="https://mastodon.raddemo.host/tags/letsencrypt" class="mention hashtag" rel="nofollow noopener" target="_blank">#letsencrypt</a>

Kathleen FitzpatrickA quick (and likely very dumb) question for folks who’ve worked with Nginx Proxy Manager: I’ve got it running in a Proxmox container, and am now setting up a VM to host several static websites. If I set a proxy host that points to some specific port on the VM, do I need to do something on the VM itself to map that port to the directory where the site lives? Or do I handle all of that in NPM? I tried including this under Advanced, without luck.location / { root /www/site1.net/; }I cannot tell whether its failure to work means that I need to add something to that configuration or that I need to do something on the VM to let it know what to do. (And if there is an introduction to Nginx Proxy Manager that will explain all of this to me, please do point me there. I haven’t been able to find documentation that doesn’t assume I already know what I’m doing.)<a href="https://hcommons.social/tags/homelab" class="mention hashtag" rel="nofollow noopener" target="_blank">#homelab</a> <a href="https://hcommons.social/tags/nginx" class="mention hashtag" rel="nofollow noopener" target="_blank">#nginx</a> <a href="https://hcommons.social/tags/proxmox" class="mention hashtag" rel="nofollow noopener" target="_blank">#proxmox</a>

Debacle<a href="https://gultsch.social/@daniel" class="u-url mention" rel="nofollow noopener" target="_blank">@daniel</a> What is the minimal system version supporting <a href="https://framapiaf.org/tags/TLS" class="mention hashtag" rel="nofollow noopener" target="_blank">#TLS</a> 1.3?I.e. would <a href="https://framapiaf.org/tags/Debian" class="mention hashtag" rel="nofollow noopener" target="_blank">#Debian</a> 11 (<a href="https://framapiaf.org/tags/buster" class="mention hashtag" rel="nofollow noopener" target="_blank">#buster</a> <a href="https://framapiaf.org/tags/oldoldstable" class="mention hashtag" rel="nofollow noopener" target="_blank">#oldoldstable</a>) suffice? It is under <a href="https://framapiaf.org/tags/LTS" class="mention hashtag" rel="nofollow noopener" target="_blank">#LTS</a> (long term support) until 2026-08-31 and probably still widespread.It has e.g. <a href="https://framapiaf.org/tags/ejabberd" class="mention hashtag" rel="nofollow noopener" target="_blank">#ejabberd</a> 21.01, <a href="https://framapiaf.org/tags/nginx" class="mention hashtag" rel="nofollow noopener" target="_blank">#nginx</a> 1.18.0, <a href="https://framapiaf.org/tags/prosody" class="mention hashtag" rel="nofollow noopener" target="_blank">#prosody</a> 0.11.9…

Aaron LongchampsGood news: no complicated etcd cluster needed. I figured out a way to get it to work with Technitium as my upstream server for *.k8s-dr.home. This replaces the excoredns pod I was running before, which handled such requests. I did have to setup a TSIG key and let external-dns do zone transfers, but that all works out anyways.I also re-learned that I should be deploying the nginx ingress controller that's for the cloud, because the bare metal one (I assume) thinks you have some external load balancer. It was actually picking up one of the k8s node's IP address instead of something from the load balancer pool. Changing back to the cloud version made it work with the MetalLB IP address pool, and that's working.With all of this homelab work lately, I should be able to get at least a couple of blog posts out of it. One about the new hardware for the lab, another for the new k8s setup and the fun of setting that up.Ansible really saved my sanity through this whole process. I was able to recreate the cluster on demand in only a few minutes, including cloning templates, configuring them, and bootstrapping a 5-node cluster.<a href="https://infosec.exchange/tags/homelab" class="mention hashtag" rel="nofollow noopener" target="_blank">#homelab</a> <a href="https://infosec.exchange/tags/kubernetes" class="mention hashtag" rel="nofollow noopener" target="_blank">#kubernetes</a> <a href="https://infosec.exchange/tags/troubleshooting" class="mention hashtag" rel="nofollow noopener" target="_blank">#troubleshooting</a> <a href="https://infosec.exchange/tags/nginx" class="mention hashtag" rel="nofollow noopener" target="_blank">#nginx</a> <a href="https://infosec.exchange/tags/learning" class="mention hashtag" rel="nofollow noopener" target="_blank">#learning</a> <a href="https://infosec.exchange/tags/networking" class="mention hashtag" rel="nofollow noopener" target="_blank">#networking</a> <a href="https://infosec.exchange/tags/ansible" class="mention hashtag" rel="nofollow noopener" target="_blank">#ansible</a> <a href="https://infosec.exchange/tags/proxmox" class="mention hashtag" rel="nofollow noopener" target="_blank">#proxmox</a> <a href="https://infosec.exchange/tags/automation" class="mention hashtag" rel="nofollow noopener" target="_blank">#automation</a> <a href="https://infosec.exchange/tags/infrastructure" class="mention hashtag" rel="nofollow noopener" target="_blank">#infrastructure</a>

Alanna 🏳️‍🌈🏳️‍⚧️I have just spent the last three hours getting enraged by a CSP problem. All I needed was this in the nginx config for a site I was working on today:fastcgi_param HTTPS 'on';<a href="https://mastodon.ie/tags/phphell" class="mention hashtag" rel="nofollow noopener" target="_blank">#phphell</a> <a href="https://mastodon.ie/tags/webdev" class="mention hashtag" rel="nofollow noopener" target="_blank">#webdev</a> <a href="https://mastodon.ie/tags/derp" class="mention hashtag" rel="nofollow noopener" target="_blank">#derp</a> <a href="https://mastodon.ie/tags/nginx" class="mention hashtag" rel="nofollow noopener" target="_blank">#nginx</a>

Gabriel Viso CarreraBueno, pues <a href="https://micromaquina.com" rel="nofollow noopener" translate="no" target="_blank">https://micromaquina.com</a> ya está en <a href="https://fedi.gvisoc.com/tags/hugo" class="mention hashtag" rel="nofollow noopener" target="_blank">#hugo</a>, en Cloudflare pages (de momento), y con ésto he terminado la migración. Desactivando <a href="https://fedi.gvisoc.com/tags/NGINX" class="mention hashtag" rel="nofollow noopener" target="_blank">#NGINX</a> en mi servidor y cerrando todos los puertos que quedaban abiertos en el router de casa.

N-gated Hacker News🚫 Forbidden: Enter the latest breakthrough in <a href="https://mastodon.social/tags/cosmic" class="mention hashtag" rel="nofollow noopener" target="_blank">#cosmic</a> <a href="https://mastodon.social/tags/research" class="mention hashtag" rel="nofollow noopener" target="_blank">#research</a>, where the only thing you'll discover is an impenetrable wall of 403 errors! The universe's <a href="https://mastodon.social/tags/secrets" class="mention hashtag" rel="nofollow noopener" target="_blank">#secrets</a> remain as elusive as ever, brought to you by the cutting-edge <a href="https://mastodon.social/tags/technology" class="mention hashtag" rel="nofollow noopener" target="_blank">#technology</a> of... <a href="https://mastodon.social/tags/nginx" class="mention hashtag" rel="nofollow noopener" target="_blank">#nginx</a>. 🌌🔒 <a href="https://drb.ie/articles/a-crack-in-the-cosmos/" rel="nofollow noopener" translate="no" target="_blank">https://drb.ie/articles/a-crack-in-the-cosmos/</a> <a href="https://mastodon.social/tags/Forbidden" class="mention hashtag" rel="nofollow noopener" target="_blank">#Forbidden</a> <a href="https://mastodon.social/tags/Errors" class="mention hashtag" rel="nofollow noopener" target="_blank">#Errors</a> <a href="https://mastodon.social/tags/Universe" class="mention hashtag" rel="nofollow noopener" target="_blank">#Universe</a> <a href="https://mastodon.social/tags/HackerNews" class="mention hashtag" rel="nofollow noopener" target="_blank">#HackerNews</a> <a href="https://mastodon.social/tags/ngated" class="mention hashtag" rel="nofollow noopener" target="_blank">#ngated</a>

psМені не дає спокою одне питання: якщо <a class="hashtag" href="https://wizard.casa/collections/tags/nginx" rel="nofollow noopener" target="_blank">#Nginx</a> вміє проксувати пакети<pre><code>stream { server { listen 443; proxy_pass [IP]:443; } } </code></pre>то виходить, що можна користуватись <a class="hashtag" href="https://wizard.casa/collections/tags/ssl" rel="nofollow noopener" target="_blank">#SSL</a> over <a class="hashtag" href="https://wizard.casa/collections/tags/yggdrasil" rel="nofollow noopener" target="_blank">#Yggdrasil</a>?!бо мене постійно параноїть користуватись чужими проксі, які пересилають через себе не захищену шкуру і можуть підробити destination / перехопити пароль реального логіну... чи тут браузер не пропустить? але ж свій браузер / хост вже можна "обманути"

JesseBotSemi-related: OWASP maintains a list of ModSecurity exceptions for nextcloud here:<a href="https://github.com/coreruleset/nextcloud-rule-exclusions-plugin" rel="nofollow noopener" target="_blank">https://github.com/coreruleset/nextcloud-rule-exclusions-plugin</a><a href="https://social.smallhack.org/tags/nextcloud" class="mention hashtag" rel="nofollow noopener" target="_blank">#nextcloud</a> <a href="https://social.smallhack.org/tags/nginx" class="mention hashtag" rel="nofollow noopener" target="_blank">#nginx</a> <a href="https://social.smallhack.org/tags/waf" class="mention hashtag" rel="nofollow noopener" target="_blank">#WAF</a> <a href="https://social.smallhack.org/tags/webapplicationfirewall" class="mention hashtag" rel="nofollow noopener" target="_blank">#webapplicationfirewall</a> <a href="https://social.smallhack.org/tags/modsecurity" class="mention hashtag" rel="nofollow noopener" target="_blank">#modSecurity</a>

JesseBotDoes anyone know of a public set of ModSecurity exceptions for the fediverse/ActivityPub I can take a look at? I'm setting it up for GoToSocial and Mastodon now and manually doing this is pain.Update, <a href="https://social.smallhack.org/@cloudymax" class="u-url mention" rel="nofollow noopener" target="_blank">@cloudymax</a> and I started a plugin here: <a href="https://github.com/small-hack/argocd-apps/blob/2b7995c6fae5ecbb3944c6c6f4b139d98b76e67f/ingress-nginx/modsecurity_plugins_configmap.yaml#L177" rel="nofollow noopener" target="_blank">https://github.com/small-hack/argocd-apps/blob/2b7995c6fae5ecbb3944c6c6f4b139d98b76e67f/ingress-nginx/modsecurity_plugins_configmap.yaml#L177</a>Still happy to collaborate on it, but also wanted to note there was a mention a year ago about making an ActivityPub plugin over at the OWASP CRS repo, so maybe we could donate to that if its ever created: <a href="https://github.com/coreruleset/coreruleset/issues/3497#issuecomment-1902181156" rel="nofollow noopener" target="_blank">https://github.com/coreruleset/coreruleset/issues/3497#issuecomment-1902181156</a><a href="https://social.smallhack.org/tags/waf" class="mention hashtag" rel="nofollow noopener" target="_blank">#WAF</a> <a href="https://social.smallhack.org/tags/modsecurity" class="mention hashtag" rel="nofollow noopener" target="_blank">#modsecurity</a> <a href="https://social.smallhack.org/tags/nginx" class="mention hashtag" rel="nofollow noopener" target="_blank">#nginx</a> <a href="https://social.smallhack.org/tags/apache" class="mention hashtag" rel="nofollow noopener" target="_blank">#apache</a> <a href="https://social.smallhack.org/tags/firewall" class="mention hashtag" rel="nofollow noopener" target="_blank">#firewall</a> <a href="https://social.smallhack.org/tags/webapplicationfirewall" class="mention hashtag" rel="nofollow noopener" target="_blank">#webApplicationFirewall</a> <a href="https://social.smallhack.org/tags/mastodon" class="mention hashtag" rel="nofollow noopener" target="_blank">#mastodon</a> <a href="https://social.smallhack.org/tags/gotosocial" class="mention hashtag" rel="nofollow noopener" target="_blank">#gotosocial</a> <a href="https://social.smallhack.org/tags/activitypub" class="mention hashtag" rel="nofollow noopener" target="_blank">#activitypub</a>

Debacle<a href="https://fedi.gvisoc.com/@gabriel" class="u-url mention" rel="nofollow noopener" target="_blank">@gabriel</a>I suggest to use port 443 for direct <a href="https://framapiaf.org/tags/TLS" class="mention hashtag" rel="nofollow noopener" target="_blank">#TLS</a> client connections instead of e.g. 5223. Unfortunately, some public wifis block everything but 443.<a href="https://framapiaf.org/tags/Nginx" class="mention hashtag" rel="nofollow noopener" target="_blank">#Nginx</a> can differentiate <a href="https://framapiaf.org/tags/XMPP" class="mention hashtag" rel="nofollow noopener" target="_blank">#XMPP</a>, HTTP, TURN etc. by means of <a href="https://framapiaf.org/tags/ALPN" class="mention hashtag" rel="nofollow noopener" target="_blank">#ALPN</a>.<a href="https://framapiaf.org/tags/Jabber" class="mention hashtag" rel="nofollow noopener" target="_blank">#Jabber</a> <a href="https://framapiaf.org/tags/Snikket" class="mention hashtag" rel="nofollow noopener" target="_blank">#Snikket</a>

Jan Wildeboer 😷:krulorange:What <a href="https://social.wildeboer.net/tags/OpenSource" class="mention hashtag" rel="nofollow noopener" target="_blank">#OpenSource</a> and <a href="https://social.wildeboer.net/tags/SelfHost" class="mention hashtag" rel="nofollow noopener" target="_blank">#SelfHost</a> can do. Had an idea, discussed it here. Seemed to rhyme with people. Booked two domains. Created a landing page with <a href="https://social.wildeboer.net/tags/Jekyll" class="mention hashtag" rel="nofollow noopener" target="_blank">#Jekyll</a> and CI/CD from a <a href="https://social.wildeboer.net/tags/git" class="mention hashtag" rel="nofollow noopener" target="_blank">#git</a> repo on my <a href="https://social.wildeboer.net/tags/Forgejo" class="mention hashtag" rel="nofollow noopener" target="_blank">#Forgejo</a> instance. Created logo with <a href="https://social.wildeboer.net/tags/Inkscape" class="mention hashtag" rel="nofollow noopener" target="_blank">#Inkscape</a>. Added <a href="https://social.wildeboer.net/tags/letsencrypt" class="mention hashtag" rel="nofollow noopener" target="_blank">#letsencrypt</a> certificate. Put it on my VPS (Virtual Private Server) running Red Hat Enterprise Linux, (<a href="https://social.wildeboer.net/tags/RHEL" class="mention hashtag" rel="nofollow noopener" target="_blank">#RHEL</a>) where it is now served with <a href="https://social.wildeboer.net/tags/Nginx" class="mention hashtag" rel="nofollow noopener" target="_blank">#Nginx</a>. Git repo mirrored to <a href="https://social.wildeboer.net/tags/Codeberg" class="mention hashtag" rel="nofollow noopener" target="_blank">#Codeberg</a> so all can join. In under 8h.<a href="https://devbnb.eu" rel="nofollow noopener" translate="no" target="_blank">https://devbnb.eu</a><a href="https://codeberg.org/jwildeboer/devbnb" rel="nofollow noopener" translate="no" target="_blank">https://codeberg.org/jwildeboer/devbnb</a>

George E. 🇺🇸♥🇺🇦🇵🇸🏳️‍🌈🏳️‍⚧️This is how we're <a href="https://bofh.social/tags/geoblocking" rel="nofollow noopener" target="_blank">#geoblocking</a> traffic from the UK, France, Mississippi, Texas, Wyoming, and others with <a href="https://bofh.social/tags/Cloudflare" rel="nofollow noopener" target="_blank">#Cloudflare</a>. This also assumes you have Cloudflare properly configured to send you the real-ip address of all ingress traffic and not just the IP address of Cloudflare's proxies: First, we have one <a href="https://bofh.social/tags/PageRule" rel="nofollow noopener" target="_blank">#PageRule</a> for each site. It's simple, it matches on every <a href="https://bofh.social/tags/URI" rel="nofollow noopener" target="_blank">#URI</a> and it has one setting: <code>IP Geolocation Header: On</code>. That tells Cloudflare to send the IP <a href="https://bofh.social/tags/Geolocation" rel="nofollow noopener" target="_blank">#Geolocation</a> headers with each request. Next, all of our sites are reverse-proxied behind <a href="https://bofh.social/tags/Nginx" rel="nofollow noopener" target="_blank">#Nginx</a>. So this is for <a href="https://bofh.social/tags/Nginx" rel="nofollow noopener" target="_blank">#Nginx</a>, not sure how you would implement this for <a href="https://bofh.social/tags/Caddy" rel="nofollow noopener" target="_blank">#Caddy</a> or <a href="https://bofh.social/tags/Apache" rel="nofollow noopener" target="_blank">#Apache</a>, but I'm sure you can: We created a map file in <code>/etc/nginx/conf.d/geo_map.conf</code> that contains the following: <pre><code># Build a single key of "COUNTRY:REGIONCODE" map "$http_cf_ipcountry:$http_cf_region_code" $blocked_geo { default 0; # Blocked countries (match regardless of region) ~^(GB|UK|IR|IL|RU|KP|FR|IT): 1; # US states (only when country is US) ~^US:(MS|WY|KY|MO|VA|UT|TX|TN|SD|OK|NC|NE|MT|LA|KS|IN|ID|GA|FL|AR|AZ)$ 1; }</code></pre> This map file is shared across all of our instances. Now, for the <a href="https://bofh.social/tags/nginx" rel="nofollow noopener" target="_blank">#nginx</a> <a href="https://bofh.social/tags/configuration" rel="nofollow noopener" target="_blank">#configuration</a> for our sites we have the following: <pre><code># For WebSocket map $http_upgrade $connection_upgrade { default upgrade; '' close; } proxy_cache_path /tmp/nginx_cache_app04 levels=1:2 keys_zone=cache4:16m max_size=6g inactive=720m use_temp_path=off; server { if ($host = foo.bar.baz) { return 301 https://$host$request_uri; } # managed by Certbot listen 80; listen [::]:80; server_name foo.bar.baz; ########### CLOUDFLARE GEOBLOCKING ########### if ($blocked_geo) { return 451; } # For SSL domain validation root /var/www/html; location /.well-known/acme-challenge/ { allow all; } location /.well-known/pki-validation/ { allow all; } location / { return 301 https://$server_name$request_uri; } access_log /var/log/nginx/foo-bar-baz-access.log; error_log /var/log/nginx/foo-bar-baz-error.log; } server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name foo.bar.baz; ########### CLOUDFLARE GEOBLOCKING ########### if ($blocked_geo) { return 451; } ssl_session_timeout 1d; ssl_session_cache shared:ssl_session_cache:10m; ssl_session_tickets off; # To use Let's Encrypt certificate ssl_certificate /etc/letsencrypt/live/foo-bar-baz/fullchain.pem; # managed by Certbot ssl_certificate_key /etc/letsencrypt/live/foo-bar-baz/privkey.pem; # managed by Certbot # SSL protocol settings ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers off; ssl_stapling on; ssl_stapling_verify on; # Change to your upload limit client_max_body_size 99m; # Gzip compression gzip on; gzip_proxied any; gzip_comp_level 6; gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript application/activity+json application/atom+xml; # Proxy to Node location / { proxy_pass http://10.0.0.17:3000; proxy_set_header Host $host; proxy_http_version 1.1; proxy_redirect off; # If it's behind another reverse proxy or CDN, remove the following. proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto https; # For WebSocket proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; # Cache settings proxy_cache cache4; proxy_cache_lock on; proxy_cache_use_stale updating; add_header X-Cache $upstream_cache_status; } access_log /var/log/nginx/foo-bar-baz-access.log; error_log /var/log/nginx/foo-bar-baz-error.log; } </code></pre> Then you basically add an <code>if</code> block toward the top of the <code>server</code> section in your site config to query the map file you created. If true, respond with an <code>HTTP/451</code> (access blocked for legal reasons) but you can just as easily specify any response code, and even redirect requests to another web page explaining why access has been blocked. Hopefully this helps other <a href="https://bofh.social/tags/fediadmins" rel="nofollow noopener" target="_blank">#fediadmins</a>.

Recent searches

Search options

Administered by:

Server stats:

#nginx