#varnish — Public Fediverse posts

Varnish, it's like MySQL, Gitea, ownCloud and OpenOffice?

Well we're all familiar with MariaDB, Forgejo, and LibreOffice, now one group that is likening the creation of those forks by the original development teams is also asking folks (for the sake of understanding) that #Vinyl-cache is the original, unbroken codebase that was once #Varnish, yet furthermore, is also akin to other software such as those others mentioned above both pre and post forking.

https://vinyl-cache.org/organization/on_vinyl_cache_and_varnish_cache.html#our-opinion

Obviously, this could be confusing. Which should you use? which is the original? which is better?

Honestly, this is a matter of philosophy, business, and other matters of choice; but not so much in substance - yet. These two code bases haven't had much time to diverge, but they are, and have been, for a bit now. Both are FOSS. Both (or at least one) claims to be the continuation of a two decades old code base. Here's what's important now, and how you might want to come to your own conclusions as to which one to choose moving forward.

#Sun_Microsystems manufactured some of the most admired and trusted enterprise server hardware platforms. They also created and maintained #Solaris (SunOS), and they scooped up the custodianship for what was once Star Office in the form of #OpenOffice. They also brought Monty's #MySQL into the fold, while VirtualBox was another free offering.

#Sun was acquired by the #Evil_EllisonCo, aka, #Oracle. Immediately, the company was dismantled. Servers rebranded, while the OpenOffice developer team mutinied under the tutelage of Ellison, and then departed forming "The Document Foundation (TDF) in the process - a fork, #LibreOffice resulted.

Monty Widenius, already soured on the state of MySQL's place at the table with Oracle created the fork, MariaDB (Slackware Linux was the first major Linux distro to include MariaDB as the default during installation of the OS).

MySQL had much use for Oracle but Not OpenOffice (aka OOo), and Ellison refused to give the name to the Document Foundation, so it languished in the Apache Incubator, where he had gifted it, for many years.

Another famous new name that is essentially the original team of creators and developers is #NextCloud, and yes, #ownCloud does still exist... somewhere, or so I'm told ;)

When the three people in charge of steering and the custodianship of Gitea Formed a couple of for profit companies and assigned all trade and service marks of the product to those companies, it caused a great stir within the FOSS community (because this was the de facto leading #FOSS version of a code forge especially appropriate to host FOSS projects). A new Fork, #Forgejo was birthed.

So in a nutshell, When the Varnish project bootstrapped a for profit corporation to operate under (even though at this time it's still FOSS), it likewise spawned a fork of itself, and like the others, the defecting developers created the name #Vinyl, and forked Varnish-cache so that it is Vinyl-cache that continues in the tradition of FOSS while it's expected that Varnish-cache will continue to diverge from the direction of the original code base and philosophy.

#tallship #reverse_proxy #software_forks #open_source

⛵

[arch-announce] Breaking changes for all users of `varnish`, which is renamed to `vinyl-cache`

https://lists.archlinux.org/archives/list/[email protected]/thread/4BSRLLGJ5552NASTYKCDZ3Q6DIMW2J4J/

#Linux #ArchLinux #Varnish #VinylCache #OpenSource

My very rough test shows that Rust hyper can achieve ~119k requests per second, but vinyl cache formerly known as Varnish with 1s cache on front of a same URL can reach 96k requests per second.

https://github.com/Ciantic/stress-test-vinyl-cache/tree/main

#Rust #VinylCache #Varnish

Hmmm,

My impression was that #Varnish Software would be based off on the #VinylCache upstream.

But now it seems like they have effectively created a new "varnish" repository where they intend to follow upstream, with their own patches *and* features vinyl doesn't want?

I already see changed not upstreamed, and they seem to be pushing for existing varnish packages to point to the "new" upstream?

Die TYPO3 Varnish Extension ist ab sofort mit TYPO3 14 kompatibel 🎉

Damit unterstützt die Version v8.0.0 der Extension neu TYPO3 v13 und v14. Die Extension findest du hier: https://extensions.typo3.org/extension/varnish

Auf unserem Managed Server ist Varnish bereits fixfertig vorkonfiguriert. Mehr Infos zum Managed Server: https://opsone.ch/de/managed-server

Und mehr zur Installation der Varnish Extension findest du in unserem Blogartikel zum Thema: https://opsone.ch/de/blog/typo-3-caching-mit-varnish-anleitung-und-tipps

#Varnish #TYPO3 #OpenSource #DevOps #SwissHosting

Die TYPO3 Varnish Extension ist ab sofort mit TYPO3 14 kompatibel 🎉

Damit unterstützt die Version v8.0.0 der Extension neu TYPO3 v13 und v14. Die Extension findest du hier: https://extensions.typo3.org/extension/varnish

Auf unserem Managed Server ist Varnish bereits fixfertig vorkonfiguriert. Mehr Infos zum Managed Server: https://opsone.ch/de/managed-server

Und mehr zur Installation der Varnish Extension findest du in unserem Blogartikel zum Thema: https://opsone.ch/de/blog/typo-3-caching-mit-varnish-anleitung-und-tipps

#Varnish #TYPO3 #OpenSource #DevOps #SwissHosting

Die TYPO3 Varnish Extension ist ab sofort mit TYPO3 14 kompatibel 🎉

Damit unterstützt die Version v8.0.0 der Extension neu TYPO3 v13 und v14. Die Extension findest du hier: https://extensions.typo3.org/extension/varnish

Auf unserem Managed Server ist Varnish bereits fixfertig vorkonfiguriert. Mehr Infos zum Managed Server: https://opsone.ch/de/managed-server

Und mehr zur Installation der Varnish Extension findest du in unserem Blogartikel zum Thema: https://opsone.ch/de/blog/typo-3-caching-mit-varnish-anleitung-und-tipps

#Varnish #TYPO3 #OpenSource #DevOps #SwissHosting

Die TYPO3 Varnish Extension ist ab sofort mit TYPO3 14 kompatibel 🎉

Damit unterstützt die Version v8.0.0 der Extension neu TYPO3 v13 und v14. Die Extension findest du hier: https://extensions.typo3.org/extension/varnish

Auf unserem Managed Server ist Varnish bereits fixfertig vorkonfiguriert. Mehr Infos zum Managed Server: https://opsone.ch/de/managed-server

Und mehr zur Installation der Varnish Extension findest du in unserem Blogartikel zum Thema: https://opsone.ch/de/blog/typo-3-caching-mit-varnish-anleitung-und-tipps

#Varnish #TYPO3 #OpenSource #DevOps #SwissHosting

Die TYPO3 Varnish Extension ist ab sofort mit TYPO3 14 kompatibel 🎉

Damit unterstützt die Version v8.0.0 der Extension neu TYPO3 v13 und v14. Die Extension findest du hier: https://extensions.typo3.org/extension/varnish

Auf unserem Managed Server ist Varnish bereits fixfertig vorkonfiguriert. Mehr Infos zum Managed Server: https://opsone.ch/de/managed-server

Und mehr zur Installation der Varnish Extension findest du in unserem Blogartikel zum Thema: https://opsone.ch/de/blog/typo-3-caching-mit-varnish-anleitung-und-tipps

#Varnish #TYPO3 #OpenSource #DevOps #SwissHosting

@jwildeboer And there is a new (but well known) player on the cdn-market: https://www.varnish-cdn.com/

#varnish #varnishcdn #norway

Typical sailor meetup: Share cake and expertise, in this case about varnish.

Yes that pack says 80 quid on it and that was back in 2016.

#CruisingLife #Varnish #Memories

Typical sailor meetup: Share cake and expertise, in this case about varnish.

Yes that pack says 80 quid on it and that was back in 2016.

#CruisingLife #Varnish #Memories

Typical sailor meetup: Share cake and expertise, in this case about varnish.

Yes that pack says 80 quid on it and that was back in 2016.

#CruisingLife #Varnish #Memories

Typical sailor meetup: Share cake and expertise, in this case about varnish.

Yes that pack says 80 quid on it and that was back in 2016.

#CruisingLife #Varnish #Memories

Typical sailor meetup: Share cake and expertise, in this case about varnish.

Yes that pack says 80 quid on it and that was back in 2016.

#CruisingLife #Varnish #Memories

Varnish and Virtue

https://literaryreview.co.uk/varnish-virtue

#HackerNews #Varnish #Virtue #Literature #Review #Ethics #Art

@AdamStuartSmith I had that problem with vanilla Mastodon for a bit when I first installed it. Any posts that got any sort of activity from anyone with a significant following would overwhelm my server for several minutes.

I solved that by setting up a #Varnish cache in front of my server. I don't use Mastodon anymore, but I still use the cache in front of my bespoke software (#Enigmatick). It works really well to take the load off of the core server for those fan-out posts. Varnish handles the load with aplomb.

Updated GitHub Action for VCL #linter is out! No big change, the v1 is fixed and working again! You can use it to lint your ACL and VCL files, e.g. for #Varnish or #Fastly https://github.com/ain/falco-github-action #Programming #EdgeComputing #OpenSource

Updated GitHub Action for VCL #linter is out! No big change, the v1 is fixed and working again! You can use it to lint your ACL and VCL files, e.g. for #Varnish or #Fastly https://github.com/ain/falco-github-action #Programming #EdgeComputing #OpenSource

Updated GitHub Action for VCL #linter is out! No big change, the v1 is fixed and working again! You can use it to lint your ACL and VCL files, e.g. for #Varnish or #Fastly https://github.com/ain/falco-github-action #Programming #EdgeComputing #OpenSource

I'm finally switching to #varnish for a caching. (or #vinyl as it is now)
What's the best way to do #https / #ssl?
I suppose I can just throw #apache in front of it, with HTTPS. But... is that the most effecient way?

Wooohooo! Native embeded Mermaid diagrams in @thecarpentries varnish for their workbench

https://github.com/carpentries/varnish/pull/125

#carpentries #mermaid #r #workbench #varnish

Medium and Message: Varnish and the mists of grime

https://fed.brid.gy/r/https://eclecticlight.co/2025/11/11/medium-and-message-varnish-and-the-mists-of-grime/

Medium and Message: Varnish and the mists of grime

https://web.brid.gy/r/https://eclecticlight.co/2025/11/11/medium-and-message-varnish-and-the-mists-of-grime/

Medium and Message: Varnish and the mists of grime

https://fed.brid.gy/r/https://eclecticlight.co/2025/11/11/medium-and-message-varnish-and-the-mists-of-grime/

Medium and Message: Varnish and the mists of grime

https://fed.brid.gy/r/https://eclecticlight.co/2025/11/11/medium-and-message-varnish-and-the-mists-of-grime/

Medium and Message: Varnish and the mists of grime

https://web.brid.gy/r/https://eclecticlight.co/2025/11/11/medium-and-message-varnish-and-the-mists-of-grime/

🚀 Wow, #Go can now access files 25 times faster with MMAP! But let's not get too excited—it's like putting a turbo on a tricycle. 🐢 Meanwhile, #Varnish is still doing its best to sound like a fancy condiment. 🥒
https://info.varnish-software.com/blog/how-memory-maps-mmap-deliver-25x-faster-file-access-in-go #MMAP #performance #technews #HackerNews #ngated

🚀 Wow, #Go can now access files 25 times faster with MMAP! But let's not get too excited—it's like putting a turbo on a tricycle. 🐢 Meanwhile, #Varnish is still doing its best to sound like a fancy condiment. 🥒
https://info.varnish-software.com/blog/how-memory-maps-mmap-deliver-25x-faster-file-access-in-go #MMAP #performance #technews #HackerNews #ngated

🚀 Wow, #Go can now access files 25 times faster with MMAP! But let's not get too excited—it's like putting a turbo on a tricycle. 🐢 Meanwhile, #Varnish is still doing its best to sound like a fancy condiment. 🥒
https://info.varnish-software.com/blog/how-memory-maps-mmap-deliver-25x-faster-file-access-in-go #MMAP #performance #technews #HackerNews #ngated

🚀 Wow, #Go can now access files 25 times faster with MMAP! But let's not get too excited—it's like putting a turbo on a tricycle. 🐢 Meanwhile, #Varnish is still doing its best to sound like a fancy condiment. 🥒
https://info.varnish-software.com/blog/how-memory-maps-mmap-deliver-25x-faster-file-access-in-go #MMAP #performance #technews #HackerNews #ngated

#varnish

The launch of Varnish Cache 8.0 has been eclipsed by heated debate over the project’s sudden rename to “Vinyl Cache.”
https://linuxiac.com/varnish-cache-8-0-arrives-in-the-middle-of-a-heated-rebranding-controversy/

#varnish #cache #foss #opensource

A #regression was discovered in the most recent release of #Varnish Enterprise (6.0.16r2).

As a result the package was pulled from the repositories.

https://www.geekersdigest.com/bug-in-varnish-enterprise-6-0-16r2-leads-to-removal-of-package/

Error 502 ja sivustojen backup-näyttö

https://www.eksis.one/palvelimet/error-502-ja-sivustojen-backup-naytto/

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.

• 500: Nginx tai virtuaalihostin konffi on rikki
• 502: Varnish on kaatunut
• 503: useimmiten Apache2 on kaatunut
• 504: Apachen takana oleva WordPress on sekaisin

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 Discourse-foorumillani — ja se osaa lähettää push-ilmoituksia minulle.

Joten ensin pienen ja sitä seuranneen isomman riidan jälkeen sain rakennettua tavan, jossa Nginx kertoo Plesk-serverille 50x-virheestä. Se taasen esittää kustomoidun virheilmoituksen ja avaa Discoursessa ketjun sille virheelle.

Varnish tuuraa Apachea

Siinä 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ä varajärjestelmän varajärjestelmän.

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 2

Nginxin 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ä kirjoitettaessa

Jos 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):

[map $panic $varnish_upstream ](#)    0 127.0.0.1:8080;  # normaali Varnish    1 127.0.0.1:8081;  # panic-Varnish}

Server-blokkiin:

set $panic 0;    if (-f /run/emergency_on) { set $panic 1; }    location / {        proxy_pass http://$varnish_upstream;...

Varnishin kaatumisen ja nousun tunnistus

Varnishin tilaa vahtii scripti varnish-switchover.sh:

#!/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

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 /run/emergency_on . Sen löytyessä Nginx vaihtaa proxyksi paniikki-Varnishin.

Scriptin kutsuu system-unit varnish-healthcheck.service :

[Unit]Description=Varnish healthcheck and switchover[Service]Type=oneshotExecStart=/usr/local/sbin/varnish-switchover.sh

Sitä taasen ajastaa 5 sekunnin välein varnish-healthcheck.timer:

[Unit]Description=Run Varnish healthcheck every 30s[Timer]OnBootSec=10sOnUnitActiveSec=30sAccuracySec=1sUnit=varnish-healthcheck.service[Install]WantedBy=timers.target

Aikaa voi toki muuttaa ja itse käytän hieman nopeasti reagoivaa.

Paniikki-Varnish käynnistyy scriptillä varnish-panic.sh :

#!/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

Koska molemmat Varnishit ovat koko ajan yhtä aikaa käynnissä, niin

• paniikki tarvitsee oman työhakemiston asetettuna -n lipulla
• paniikki ei saa kuunnella samaa porttia Nginxin suuntaan kuin normaali
• paniikki ei saa kuunnella backendiään samassa portissa kuin normaali
• kommentoitu Original kohta toimii yksinään manuaalisena panic.sh ratkaisuna; kannattaa ajaa esim. tmuxissa

Lisäksi paniikki tarvitsee oman käynnistystiedoston. Jos se käyttää samaa default.vcl tiedostoa tai vastaavaa, niin se kaatuu aivan samalla tavalla. Käyttämäni start.cli.emerg on:

vcl.load hot /etc/varnish/emergency.vclvcl.use hot

Ja tarvittava emergency.vcl on perusmallinen vcl, joka määrittelee backendit ja asettaa return(pipe):. Löydät sen täältä:https://github.com/eksiscloud/Varnish7.x-multiplesites/blob/main/emergency.vcl

Paniikki-Varnishin käynnistysscriptin pitää hengissä system-unit varnish-panic.service:

[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

Omassa Ubuntussa systemd-yksiköt, service ja timer, löytyvät hakemistosta /etc/systemd/system/ ja scriptit olen tottunut laittamaan hakemistoon /usr/local/bin.

Servicet ja timerit vaativat sekä systemctl daemon-reload kuin myös systemctl enable --now <nimi>. Scriptit muuttuvat ajettavaksi chmod +x <nimi>.

Kaikki Varnishiin liittyvät löytyvät reposta https://github.com/eksiscloud/Varnish_7.x-multiple_sites

#apache2 #nginx #valvonta #varnish

Error 502 ja sivustojen backup-näyttö

https://www.eksis.one/palvelimet/error-502-ja-sivustojen-backup-naytto/

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.

• 500: Nginx tai virtuaalihostin konffi on rikki
• 502: Varnish on kaatunut
• 503: useimmiten Apache2 on kaatunut
• 504: Apachen takana oleva WordPress on sekaisin

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 Discourse-foorumillani — ja se osaa lähettää push-ilmoituksia minulle.

Joten ensin pienen ja sitä seuranneen isomman riidan jälkeen sain rakennettua tavan, jossa Nginx kertoo Plesk-serverille 50x-virheestä. Se taasen esittää kustomoidun virheilmoituksen ja avaa Discoursessa ketjun sille virheelle.

Varnish tuuraa Apachea

Siinä 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ä varajärjestelmän varajärjestelmän.

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 2

Nginxin 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ä kirjoitettaessa

Jos 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):

[map $panic $varnish_upstream ](#)    0 127.0.0.1:8080;  # normaali Varnish    1 127.0.0.1:8081;  # panic-Varnish}

Server-blokkiin:

set $panic 0;    if (-f /run/emergency_on) { set $panic 1; }    location / {        proxy_pass http://$varnish_upstream;...

Varnishin kaatumisen ja nousun tunnistus

Varnishin tilaa vahtii scripti varnish-switchover.sh:

#!/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

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 /run/emergency_on . Sen löytyessä Nginx vaihtaa proxyksi paniikki-Varnishin.

Scriptin kutsuu system-unit varnish-healthcheck.service :

[Unit]Description=Varnish healthcheck and switchover[Service]Type=oneshotExecStart=/usr/local/sbin/varnish-switchover.sh

Sitä taasen ajastaa 5 sekunnin välein varnish-healthcheck.timer:

[Unit]Description=Run Varnish healthcheck every 30s[Timer]OnBootSec=10sOnUnitActiveSec=30sAccuracySec=1sUnit=varnish-healthcheck.service[Install]WantedBy=timers.target

Aikaa voi toki muuttaa ja itse käytän hieman nopeasti reagoivaa.

Paniikki-Varnish käynnistyy scriptillä varnish-panic.sh :

#!/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

Koska molemmat Varnishit ovat koko ajan yhtä aikaa käynnissä, niin

• paniikki tarvitsee oman työhakemiston asetettuna -n lipulla
• paniikki ei saa kuunnella samaa porttia Nginxin suuntaan kuin normaali
• paniikki ei saa kuunnella backendiään samassa portissa kuin normaali
• kommentoitu Original kohta toimii yksinään manuaalisena panic.sh ratkaisuna; kannattaa ajaa esim. tmuxissa

Lisäksi paniikki tarvitsee oman käynnistystiedoston. Jos se käyttää samaa default.vcl tiedostoa tai vastaavaa, niin se kaatuu aivan samalla tavalla. Käyttämäni start.cli.emerg on:

vcl.load hot /etc/varnish/emergency.vclvcl.use hot

Ja tarvittava emergency.vcl on perusmallinen vcl, joka määrittelee backendit ja asettaa return(pipe):. Löydät sen täältä:https://github.com/eksiscloud/Varnish7.x-multiplesites/blob/main/emergency.vcl

Paniikki-Varnishin käynnistysscriptin pitää hengissä system-unit varnish-panic.service:

[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

Omassa Ubuntussa systemd-yksiköt, service ja timer, löytyvät hakemistosta /etc/systemd/system/ ja scriptit olen tottunut laittamaan hakemistoon /usr/local/bin.

Servicet ja timerit vaativat sekä systemctl daemon-reload kuin myös systemctl enable --now <nimi>. Scriptit muuttuvat ajettavaksi chmod +x <nimi>.

Kaikki Varnishiin liittyvät löytyvät reposta https://github.com/eksiscloud/Varnish_7.x-multiple_sites

#apache2 #nginx #valvonta #varnish

Les gens qui sont chez #02switch hébergeur français qui ne me paye pas pour dire ça, peuvent avec #XtremCache #Varnish trouver une alternative efficace à #LiteSpeed qui est une usine à gaz très sensible. Ce système de cache au niveau du serveur permet pour résumer de servir la page comme si elle était un fichier statique HTML sans exécution de PHP, sans requête SQL, avec un temps de réponse beaucoup plus rapide. Ne fonctionnerait pas sur les pages dynamiques comme une boutique je pense. Les résultats sont probants. Combiné avec #Redis cela ne demande aucun réglage (mais n'exonère pas de proposer des pages légères). Et ne laisse aucun cookie !

Les gens qui sont chez #02switch hébergeur français qui ne me paye pas pour dire ça, peuvent avec #XtremCache #Varnish trouver une alternative efficace à #LiteSpeed qui est une usine à gaz très sensible. Ce système de cache au niveau du serveur permet pour résumer de servir la page comme si elle était un fichier statique HTML sans exécution de PHP, sans requête SQL, avec un temps de réponse beaucoup plus rapide. Ne fonctionnerait pas sur les pages dynamiques comme une boutique je pense. Les résultats sont probants. Combiné avec #Redis cela ne demande aucun réglage (mais n'exonère pas de proposer des pages légères). Et ne laisse aucun cookie !

Les gens qui sont chez #02switch hébergeur français qui ne me paye pas pour dire ça, peuvent avec #XtremCache #Varnish trouver une alternative efficace à #LiteSpeed qui est une usine à gaz très sensible. Ce système de cache au niveau du serveur permet pour résumer de servir la page comme si elle était un fichier statique HTML sans exécution de PHP, sans requête SQL, avec un temps de réponse beaucoup plus rapide. Ne fonctionnerait pas sur les pages dynamiques comme une boutique je pense. Les résultats sont probants. Combiné avec #Redis cela ne demande aucun réglage (mais n'exonère pas de proposer des pages légères). Et ne laisse aucun cookie !

Les gens qui sont chez #02switch hébergeur français qui ne me paye pas pour dire ça, peuvent avec #XtremCache #Varnish trouver une alternative efficace à #LiteSpeed qui est une usine à gaz très sensible. Ce système de cache au niveau du serveur permet pour résumer de servir la page comme si elle était un fichier statique HTML sans exécution de PHP, sans requête SQL, avec un temps de réponse beaucoup plus rapide. Ne fonctionnerait pas sur les pages dynamiques comme une boutique je pense. Les résultats sont probants. Combiné avec #Redis cela ne demande aucun réglage (mais n'exonère pas de proposer des pages légères). Et ne laisse aucun cookie !

Les gens qui sont chez #02switch hébergeur français qui ne me paye pas pour dire ça, peuvent avec #XtremCache #Varnish trouver une alternative efficace à #LiteSpeed qui est une usine à gaz très sensible. Ce système de cache au niveau du serveur permet pour résumer de servir la page comme si elle était un fichier statique HTML sans exécution de PHP, sans requête SQL, avec un temps de réponse beaucoup plus rapide. Ne fonctionnerait pas sur les pages dynamiques comme une boutique je pense. Les résultats sont probants. Combiné avec #Redis cela ne demande aucun réglage (mais n'exonère pas de proposer des pages légères). Et ne laisse aucun cookie !

Ah, the "MCP Security Suite" – because what could possibly go wrong when you slap a fresh coat of AI-driven #varnish on your server code and call it "mighty secure"? 🚀🔐 #GitHub really wants you to "validate and scan" because apparently, trust is for the naive 🤡.
https://github.com/NineSunsInc/mighty-security #MCPSecuritySuite #AI #TrustIssues #CyberSecurity #HackerNews #ngated

Oh no! You restarted your #Varnish Cache but the VCL file contained an error?

Congratz. You've just caused a downtime.

It's much better to verify the VCL prior to a config reload or Varnish restart. It can even be automated in a pipeline or similar.

Here's how.

https://www.claudiokuenzler.com/blog/1497/how-to-verify-varnish-vcl-configuration

@bert_hubert @joyofcoding

Deja-vu there....

When #Varnish-Cache were young, many years ago, we got a lot of reports of people reducing servers a factor of 3 to 10 because it was so much more efficient code.

[…] 2/2

📸 Adobe Indigo entfernt Reflexionen auf Glasscheiben aus Fotos

📈 Charts.css zeichnet Diagramme im Browser nur mit CSS

🗽 Ein Zitat zur Freiheit, welches mir seit einigen Tagen nicht mehr aus dem Kopf geht

🔊 In dieser Woche gehört: Naicet & Elias Goldmund, Lena Brysch, Tom Schön, MariaFila & Vladis Cue

#Wochenrückblick #Bikerouter #Varnish #Blutspende #RSS #BND #Bundesnachrichtendienst #Adobe #Indigo #ChartsCSS #Freiheit #Techno

https://www.marcusjaschen.de/blog/2025/2025-26/

Wochenrückblick, Ausgabe 98 (2025-26)

Themen:

🗺️ Bikerouter: jetzt mit Backend-Caching von Routenberechnungen

⚡ Varnish: mein To-Go-Tool für serverseitiges HTTP-Caching

🩸 Nie wieder Blutspende-Termine übersehen dank RSS

🕵️ Ich besitze jetzt ein T-Shirt vom BND

[…] 1/2

#Wochenrückblick #Bikerouter #Varnish #Blutspende #RSS #BND #Bundesnachrichtendienst #Adobe #Indigo #ChartsCSS #Freiheit #Techno

https://www.marcusjaschen.de/blog/2025/2025-26/

@elena ping @bsdphk #Varnish doing heavy lifting again!

🏕️ my adventures in #selfhosting - day 165 (VFX edition) 🎞️​

Good morning Fedi friends!

I've been quiet on here (it's a temporary pause, I promise) as I have been spending every second of free time - that doesn't include childcare - editing the fediverse promo video.

The video will premiere next week at a really exciting event, right after a presentation by an absolute legend. I'm experiencing low key anxiety / palpitations, rushing to get the film ready for that.

On the to do list: sound mix, fixing some VFX animations, adding a couple of slides to the end credits, color grading, doing subtitles, exporting the video and uploading it to my PeerTube. Gaaaaah!

On the self-hosting side, I have to admit it's incredibly empowering to know I can put it on my PeerTube. Super grateful to #YunoHost for that.

If you're curious, I've published some updates re: what I've been up to this month... including a video replay of my presentation for YunoHost at #JDLL: https://news.elenarossini.com/what-im-up-to-may-2025-edition/

As a geeky side note, I had to edit a link in the article... and it would not update on my site. Awww the wonders of #Varnish cache. It's really THAT powerful. So even though I don't have time to do proper self-hosting tasks these days, I still went into my VPS and used command lines to clear Varnish cache. It counts for something, right?

Wishing everyone a wonderful weekend!


#MySoCalledSudoLife

Spend a couple of days figuring out why Varnish kept increasing its RSS memory usage, eventually leading to OOMKills. It turns out Varnish on ARM is compiled against glibc, which is known for not returning memory very effectively.

This morning, I created a build for ARM with jemalloc and memory usage has been cut in half. Very solid stability and performance so far.

#Varnish #DevOps

@wikipedia #Varnish rulez!!! 😎