kruska blogja

Mindig tanul az ember valamit.

Most például azt, hogy a CASE működik COUNT-on belül, és ORDER BY feltételben is.

Itt az ideje az első nem szakmai blogbejegyzésemnek.

Mindig is idegesített a címben jelzett mondat mögött lévő elvárás: miért kell állandóan hajszolni a növekedést? 

Nem vagyok fejlesztő, sihederkorom óta nem igazán programozok (csak scripteket üzemeltetéshez), de most egy hobbiprojektemhez próbálnék egy API felületet varázsolni. Az adatbázis részével nem lesz valószínűleg gond, de a fölötte lévő ügyekhez kellene pár dolgot tanulnom.

A napokban futottam bele egy nagyon jó leírásba (lehet, hogy pont itt a HUP-on), de most égen-földön nem találom. A lényege az volt, hogy akkor jó egy API, ha nem egyszerűen adatbázisfelületet ad CRUD alapfunkciókkal (data-driven API design approach) - mert így az üzleti logika nagy részét a kliensben kell megvalósítani; hanem folyamatokat, funkciókat képez le szerveroldalon.

Ez az írás hasonló tartalmú, de biztosan nem ugyanaz - mert az a gRPC-t is említette (nem mintha annyira el akarnám bonyolítani az ügyet):

https://hackernoon.com/process-driven-rest-api-design-75ca88917582

Ha esetleg valaki ráismer, megköszönöm, ha bedobja ide. Ha közben találok még valamit, én is felteszem.

Mérnökinfós nagyfiammal próbálom megszerettetni a shell script programozást. 

Én magam sem vagyok nagymestere a műfajnak, de néhány érdekességet összeszedtünk ebben a scriptben, ami egy újoncnak még izgalmas lehet.

Van egy szerveralkalmazás, ami csak .htpasswd basic authentikációt tud - bár TLS-t támogat, a kliensek azonosítására szolgáló mTLS-t nem. Én pedig mindenképp azt szeretnék, mert elkapott a gépszíj, hogy ahol lehet, privát/publikus kulcsos azonosítást használjak; a secret sose hagyja el azt a gépet, ahol generáltuk.

Adja magát, hogy tegyünk elé egy reverse proxy-t, ami megoldja az azonosítást is, az alkalmazást pedig zárjuk be tűzfallal, hogy csak a reverse proxy felől érkező kéréseket fogadja.

Először nginx-et akartam, mert azt már valamennyire ismerem, aztán felmerült egy olyan igény, hogy a csatlakozó kliensektől függően ágazzunk el különböző IP-n/porton figyelő szerveralkalmazások felé. Gyakorlásképpen összedobtam egy Móricka-kódot Golang-ban, szerintem nem bonyolultabb, mint ugyanennek az nginx konfigja.

Van egy kis anomália VPN NAT ügyben, aminek a mélyére kellene néznem, ezt az irományt ajánlották.

Háát, nem is tudom hirtelen, hogy megvilágosodtam, vagy elbizonytalanodtam..
Mindenesetre elég részletes olvasmány; látszik, hogy nem abból a célból írodott, hogy boruljunk le a nagy szaktekintély előtt, hanem hogy megértsük a mágiát. 

https://tailscale.com/blog/how-nat-traversal-works/

Mini.WebVM: Your own Linux box from Dockerfile, virtualized in the browser via WebAssembly

Egy rádióamatőr pikoballon eltűnt, ami már 124 napja a levegőben volt, és már 7x megkerülte a Földet. Akkor szakadt meg vele a kapcsolat, amikor a vadászgépek kilőtték az "azonosítatlan repülő tárgyat".

Gondoltam összeszedek pár izgalmasabb dolgot az LTO szalagokról / driveokról, hátha valaki mostanában szemez ilyen backup megoldással.

Nagyobb lélegzetű VM módosításkor (OS / alkalmazás update, bonyolultabb install) az ember természetesen készít egy VM snapshotot, amiből kényelmes és gyors visszaállni szükség esetén. Néha viszont igény lehet arra is, hogy ezeket a snapshotokat elmentsük / elarchiváljuk hosszabb ideig, tovább, mint ameddig a Hyper-V snapshotok általában megmaradnak.

A klasszikus módszer szerint átkergethetjük az adatfolyamot egy (vagy több) pv-n, és akár párhuzamosan nézhetjük a progressbarokat.

Viszont lehet olyan eset, amikor nem szeretnénk pipe-okat használni (pl. bufferelési vagy blokkméret beállítások miatt), ilyenkor egyszerűen küldhetünk a tar processznek egy SIGUSR1 szignált, akár rendszeresen, mondjuk percenként, crontab-ban időzítve:

* * * * * root pkill -SIGUSR1 tar

A tar-t pedig megkérjük arra, hogy legyen kedves ezeket a SIGUSR1-eket menet közben elkapni, és rá mindig olyan módon reagálni, hogy kiírja a pillanatnyi statisztikáit. 

lxc03:/mnt/ctdev02/sapdata # tar cf /dev/nst0 DISKD0051 --totals=USR1
Total bytes written: 14206033920 (14GiB, 354MiB/s)
Total bytes written: 39681720320 (37GiB, 376MiB/s)
Total bytes written: 65241937920 (61GiB, 394MiB/s)
Total bytes written: 87778324480 (82GiB, 384MiB/s)
Total bytes written: 115248916480 (108GiB, 396MiB/s)

Ha nem adjuk meg a --totals=USR1 kapcsolót, és mégis megkapja a SIGUSR1-et, akkor megáll 138-as returnkóddal, egyébként csak kiírja az adott pillanatban, és a végén rc0-val áll meg (vagy amivel amúgy állt volna meg).

Eddig mindig tar-ral írtam szalagra, az alapbeállításokkal. Ezzel nem is volt semmi baj, de szembejött néhány doksi, hogy lehetne ezt optimálisabban is, például a blokkméret növelésével.

TL;DR: Paraméterezéssel két-háromszorosára lehetett gyorsítani a tar/dd LTO írási/olvasási sebességét az alapértelmezetthez képest

Egy LTO-5 eszközt használva ezt kapom:

Adott egy host /64 IPv6 alhálózattal, amiben szeretnék IPv6-only LXC konténereket indítani, ugyanabból az alhálózatból kiosztva a címeket. Megörökíteném a későbbiekre a számomra legegyszerűbbnek tűnő megoldást. Egy Hetzner VPS-en kísérletezgetés közben szedegettem össze a lentieket, ott egyszerűen reprodukálható a folyamat.

Egy hónapja lecseréltem a 12-es Macbookomat egy M1-es Pro-ra, és eltökéltem, hogy nem fogok Rosettát telepíteni, fusson minden natívan.

Ami eddig pipa, és üzemszerűen használom:

Mai felfedezés: egy folyamat többpontos mérése.

dd if=/dev/xvdj | pv -s 5G -cN dd | gzip | pv -cN gzip > /var/www/virtual/xvdj_var-log.img.gz

       dd: 1.67GB 0:00:39 [48.1MB/s] [===============>                                        ] 33% ETA 0:01:17
     gzip:  105MB 0:00:39 [ 883kB/s] [                                    <=>                 ]