Hogyan tartotok frissen több eszközt?

Miniszámítógépek, SBC-k

Best practice érdekelne.

A saját Linuxos laptopomon (most épp Debian stable, néha Debian testing) időnként kézzel aptitude-ot indítok és telepítem a frissítéseket. A KDE-nek van egy frissítés figyelő cucca, szóval néha szól, hogy van x frissíthető csomag, vagy van y biztonsági frissítés. Ilyenkor indítom az aptitude-ot és frissítek. De ha nem szól, akkor is időnként ránézek, hogy van-e újdonság.

Sok évvel ezelőtt, amikor még Linuxos szervereket is karbantartottam, hasonló volt a megközelítés: Debian stable, és időnként ránéztem, hogy van-e frissítés. Ha a saját laptopomon láttam, hogy biztonsági frissítés van, akkor a szervereken is végignéztem azonnal, de egyébként ugye Stable-hez nem jön túl gyakran frissítés, és nem okozott gondot az, ha mondjuk egy csomagból egy újabb verzió nem a kiadás után 2-3 hanem mondjuk 8-10 nappal került fel.

Volt olyan gép, ahol telepítettem az unattended upgrade vagy valami hasonló nevű csomagot, és rábíztam, hogy rendszeresen nézze meg, van-e frissítés, és ha van security, akkor azt ő maga tegye is fel.

Biztos ezt is lehetne sokkal profibban csinálni, központilag vezérelve, automatikus figyeléssel riasztással akármi, de nem ez a része érdekel a dolognak.

Mostanában a linuxos laptop mellett van néhány raspbian-t vagy armbian-t futtató kis céleszközöm, amikre nem szoktam belépni interaktív shellbe gyakran. Ha belépek nagy ritkán, akkor persze szoktam frissíteni, de ez pl. zavar, hogy ritkán történik.

A másik gond, hogy ezeken az eszközökön vannak olyan programok, amik nem a Debian részei, és így a szokásos frissítési eljárásomból kimaradnak.

Pl. BananaPi-ből épített NAS-on van egy docker, és a dockerben egy Plex. Az aptitude boldogan frissíti a docker keretrendszert (nagy ritkán, amikor valami miatt épp belépek), de maga a Plex image nem frissül, ha épp nem jut eszembe, hogy a NAS admin weboldaláról indulva több lépésen keresztül oda nem jutok, hogy megnézzem, van-e frissítés, és ha van, akkor ott a weboldalról fel is tegyem azt.

Szóval az érdekelne, hogy ti a hasonló dolgokat hogyan csináljátok. Kézzel? Scripttel? Valami felügyelő programmal?

Nem néztem utána, de bizonyára a Plex docker image-et lehetne az admin weboldal helyett simán docker parancsokkal is frissíteni, és ezekből bizonyára lehetne könnyen shell scriptet készíteni és azt meg betenni a crontabba.

De ez a jó irány? Vagy van jobb? Vagy nem kell ez se?

  • 1027 megtekintés

( KoGa v | 2021. 04. 02., p – 05:14 )

Lefagyasztom, és mikróban felmelegítem, ha épp frissen szeretném...

( Raynes v | 2021. 04. 02., p – 06:32 )

Nem kell ezt központi felügyelő programmal bonyolítani, az csak akkor lenne célravezető, ha nagyon sok gépet kéne menedzselned, mondjuk céges szinten. Így érdemesebb a szög egyszerű megoldások felé tendálni, pl. az, amit írsz, hogy írsz rá egy shell scriptet, és azt automatizálod, pl. írsz hozzá egy pár soros systemd service-t, ami x időnként lefuttatja a scriptet. Még cron sem kell, a legtöbb systemd-s disztrón nincs is default, külön kell telepíteni, konfigurálni. De ha azt ismered, cronban is csinálhatod, nagyon azzal sem lehet mellényúlni. A lényeg, hogy túlbonyolítani nem kell, meg minden sz@rt feltelepíteni a gépre, csak azért, hogy professzionálisabb legyen. Legtöbbször a legegyszerűbb megoldások a leghatékonyabbak, ugyanis egy megoldás minél bonyolult, annál nagyobb a kódbázisa, annál inkább eltörik frissítéskor, disztróupgrade-kor, annál inkább több sechole/támadhatósági pont lesz benne, annál jobban növeli a rendszer hardverigényét.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Nálam, otthon: időnként indítok dist-upgrade-t a gépen (openSUSE Tumbleweed, ott a sima upgrade nem elég, mindig a dist-upgrade-t javasolják)

Munkahelyen: van egy központi Icinga szerver (egyelőre lusta voltam updatelni, úgyhogy a régi Nagios-fork icinga, nem az új Icinga2), az always on gépekre NRPE-vel belép és a megfelelő check_yum/check_apt/check_anyámtyúkja-t hívogatja, az appliance cuccoknál netről vadászott / saját scriptekkel az API-n keresztül kérdezi le, hogy van-e frissítés, a nem always on gépek pedig úgy vannak beállítva, hogy NRDP-n keresztül jelentsenek időnként, hogy van-e frissítés.

Ha nem akarsz NRPE-t (tényleg plusz aktív daemon, certtel/komplett PKI-vel cseszekedés stb.), a script + NRDP-n jelentés egy teljesen jó megoldás lehet és kb. egy curl kell csak hozzá; windowsokra meg pl. NSClient++ (pl. a szervereken a profile.d-be be van téve egy NRDP hívás, hogy lője át CRITICAL-ra a monitorozóban az utolsó belépést ha valaki shellt indít, amit kézzel submitolva ütök vissza OK-ra indoklással, hogy miért léptem/léptünk be).

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

( xsak v | 2021. 04. 02., p – 11:04 )

Linuxok (Ubuntu) frissítésére az unattended-upgrades csomagot használom, az felteszi a security update-eket. Ezen túl időnként kézzel megy teljes update. Van, ahol használok aptycron-t, hogy küldjön email-t az elérhető új frissítésekről.

Docker image-ek frissítésére a containrrr/watchtower-t állítottam be. Be lehet állítani, hogy frissítsen vagy csak szóljon...

( msandor v | 2021. 04. 02., p – 11:32 )

Én különválasztottam a prod és nonprod szervereket. A nonprod szerverekre yum-cronnal automatikusan feltelepítem a frissítéseket. A prod szerverek szintén a yum-cron segítségével csak jelzik (e-mail), ha van frissítés. Majd a teszthez képest pár nappal később felteszem a prod gépekre is egy egyszerű ansible-playbook segítségével.

zeller szvsz. arra gondolt, hogy megkapod a figyelmeztetést mondjuk hétfőn, hogy van frissítés (teszten ugye már fenn van), aztán csütörtökön a prod-on kiadsz egy frissítést, ami az _akkori_ legfrissebbet teszi fel... tehát ha a hétfői frissítés rossz volt és mondjuk szerdán is frissült a csomag, csütörtökön a szerdait és nem a napokig tesztelt csomagot fogod feltenni.

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Amikor mindezt 100+ gépen kell végigtolni, akkor nagyon nem buli, hogy tegnap is frissítés, ma is, meg holnap is - é ski tudja, holnapután lesz-e valami... Bónuszként prod környezetben esélyed sincs naponta-kétnaponta-hetente többször frissítés miatt szolgáltatásokat le/fel rángatni, ha úgy adódik.

Bónuszként prod környezetben esélyed sincs naponta-kétnaponta-hetente többször frissítés miatt szolgáltatásokat le/fel rángatni, ha úgy adódik.

a patchek 99 %-a nem okoz semmilyen szolgáltatás kiesést, a többit meg tudom számolni egy kezemen, azzal meg már lehet tervezni

Ha nem lett volna egyértelmű, én a saját tapasztalataimról beszélek a saját környezetemről, nem kell rögtön nekem esni, ha nem egyezik a saját tapasztalatoddal és környezeteddel. A kiindulás az volt, hogy ezzel a "bulival" jóval rövidebb ideig vagyok kiszolgáltatva, mint más rendszerek a havi patchekkel.

szerintem nem arrol van szo hogy buli vagy nem buli, hanem hogy mi okozhat nagyobb problemat ezaltal kiesest, az, ha a foltozatlan rendszert feltorik es helyre kell allitani, vagy az, ha a hibas folt miatt ujra kell telepiteni a program elozo verziojat.

mindenkinek vannak szempontjai, mindenki (vagy mindenki fonoke) el tudja donteni hogy nala melyik szempontok milyen sullyal szamitanak bele a dontesbe.

el tudom kepzelni hogy nalad a foltozatlan rendszerbol adodo arcvesztes kisebb mint a hibas frissitesbol adodo

neked aztan fura humorod van...

Nem azt mondtam, hogy a külső réteg ad 100%-hoz közeli védelmet, hanem azt, hogy az, illetve azok a rétegek olyanok, hogy egy hotfixet, egy javítást, egy alkalmazásszintű szűrést úgy lehet rajtuk implementálni/telepíteni, hogy a tényleges core szolgáltatás rendelkezésre állására nincs kihatással. Ez utóbbinak a patchelése meg jellemzően x időnként, tervezette, az SLA-t nem sértve kell, hogy történjen - természetesen kockázatelemzés mellett, azaz ha olyan a sérülékenység, hogy a köré húzott rétegek védelme nem elég, akkor akár soron kívüli szogáltatáskieséssel is. De alapból nem a belső réteget fogom minden esetben pecselni, hanem azt, ami annak a védelmét látja el.

"Bónuszként prod környezetben esélyed sincs naponta-kétnaponta-hetente többször frissítés miatt szolgáltatásokat le/fel rángatni, ha úgy adódik."

mivel nem tudhatom mirol van szo ezert csak altalanossagban tudom azt mondani hogy ilyen esetben esetleg lehetne 2 peldanyban futtatni a szolgaltatast es amig az elsodlegeset frissited addig csak a masodlagoson fut a szolgaltatas, hogy ne legyen kieses. ez azert is jo lehetne, hogy eloszor a masodlagoson frissitel, megnezed hogy minden megfeleloen mukodik-e es az elsodlegeset csak akkor frissited ha ugy van.

neked aztan fura humorod van...

"egyre több alkalmazást migrálok konténerbe" - és gondolom, a konténerekbe csomagolt komponenseket is rendszeresen frissíted... Mert oká, hogy az OS-ben lévő motyó frissül alatta, de ha a konténerben ócska, lukas csomagok vannak, akkor adtál a sza...nak egy marha nagy taslit...

( Elbandi v | 2021. 04. 02., p – 11:33 )

desktopon a software upgrade szol hogy van frissites, bokok hogy tegye. servereken unattended upgrade, de csak ubuntu hivatalos repo csomagokra, kulos repokra nem (ppa, percona, nodejs, stb). zabbixban van riaszto, igy szol ha ilyen kulsos csomag frissites van, utana kis kesessel kezzel. ha docker-compose futtat valamit ott a configban van "prerunnal" image upgrade, vagy cronbol upgrade. sajat gepen ahol csak a "gyorsan kell valami X kornyezet", kezi docker frissites:

alias docker-upgrade="docker images|cut -f1 -d' '|sort -u|grep -v elbandi|xargs --no-run-if-empty -n1 docker pull"
alias docker-remove="docker images -q --filter 'dangling=true'|xargs --no-run-if-empty docker rmi"
alias docker-clean="docker ps -a | egrep \"Exited|Dead\" | awk '{print \$1}'|xargs --no-run-if-empty docker rm"

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

"unattended upgrade, de csak ubuntu hivatalos repo csomagokra" - Milyen príma is, amikor a jdk-t megfrissíti, és az appszerver maga alá rosál emiatt - sajnos saját tapasztalat, hogy WildFly be tud maga alá fordulni ilyenkor... (Vagy a csillagok állása volt olyan, hogy pont akkor döglött meg a vadlégy, amikor a jdk-t automatice megfrissítette a bubuntu...)

aki appservert futtat az tudja hogy kenyes a javara, kenyes erre-arra, azt szepen blacklistre rakja. az userek nagy %-nak, boven jo. a bash meg az openssl frissulhet :)

raadasul mintha lenne policy arra, hogy sec updateben nem frissulhet config valtozhat meg parameter neve, stb. igy _elmeletben_ nem is szabadna semminek eltornie.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( ggallo | 2021. 04. 02., p – 21:41 )

Én a helyedben, ha már egynél több eszközöd van, akkor Ansible-lel csinálnám mindezt. Egyszer összedobsz egy inventory-t, ahhoz újra csak akkor kell nyúlni, ha új gépet csapsz hozzá. Aztán egy playbook, ami csomagokat frissít (esetleg valami szűrőfeltétel alapján, hogy ne minden frissüljön, csak ami nem csinálhat nagy bajt neked) nem nagy dolog. A Docker konténert ugyan úgy tudod Ansible-n keresztül frissíteni, majd újraindítani a frisset.

Aztán ezt fokozhatod azzal, hogy a saját gépedről cron-ban futtatod valami gyakorisággal, és akkor tényleg nem kell onnantól hozzá nyúlni sem, nem lehet elfelejteni. Amikor meg lefut, küld neked egy levelet (hogy ne kelljen log állományokat keresgélned a gépeden) arról, hogy melyik gépen mit végzett.

Ha nagyon biztosra mennél, akkor napi szinten futhat egy olyan verzió, ami csak biztonsági frissítéseket tesz fel, aztán heti-havi gyakorisággal meg az a verzió, ami a hétköznapi csomagokat frissíti és Docker konténereket.

( locsemege v | 2021. 04. 03., szo – 00:02 )

Én egy rakás Fedorát terelgetek. Ezek desktop gépek. Jellemzően félévente személyesen vagy ssh-n upgrade-elek a következő release-re, a köztes időben pedig rábízom a dnf-automatic-install.timer nevű systemd triggerelő berendezésre, ami indítja a dnf-automatic-install.service-t, az meg letölt, frissít. De néha ssh-n keresztül kézzel is, de az nem szükségszerűség, inkább csak pótcselekvés. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( x-daemon | 2021. 04. 03., szo – 11:43 )

libek frissitesekor nem art a szervizeket ujrainditani ami hasznalja, en erre a needrestart-ot hasznalom

persze jo a windowsos modszer is a reboot

neked aztan fura humorod van...

"jo a windowsos modszer is a reboot" - ha 2-3 havi rendszerességgel van frissítés, akkor esélyes, hogy kernelből is jön új, úgyhogy a reboot nem kerülhető meg. (Tudom, ksplice meg krenelcare meg hasonlók - de ha az "apróbetűst" is elolvassuk, illetve a saját tapasztalatokat is megnézzük, bizony ezek csak átmeneti megoldást nyújtanak, és az új kernellel való reboot az a biztosabb.

Oké, de nagyobb infrastruktúra esetén nem napi szinten frissíted a gépeket - jó ha adott gépre néhány hetente sort tudsz keríteni teszteléssel, újraindításokkal mindennel együtt, hiszen akár fejlesztők, akár tesztelők, akér éles userek kiszolgálása a cél, és egy szolgáltatás, vagy épp egy komplett gép újraindítása az általában több körös egyeztetés után történhet meg...

( Friczy v | 2021. 04. 03., szo – 18:50 )

Debian esetén nagyon régóta a cron-apt a megoldásom erre. Naponta meghívja az apt-t megnézi, hogy van-e frissítés, beállítás kérdése, hogy telepíti is, vagy csak letölti, esetleg azt sem. Nekem úgy van beállítva, hogy töltse le, és küldjön emailt, így nem kell várni a letöltésre, ha frissíteni kell.