reboot ENTER .... Jajj, nem itt!

Címkék

Mikor történt veled utoljára, hogy a rossz gépen adtad ki a reboot/poweroff parancsot?

Választások

Hozzászólások

Tavaly: 2 hónapja dolgoztam a cégnél, sima Linux frissítést bíztak rám. Egy KVM hostot és azon futó 2 VM-et kellett frissítenem de amúgy további 20 VM és docker container futott a gépen, taxis társaság cuccai diszpécser szoftverekkel, nyomkövetéssel, egyebekkel - hétvége estéről lévén szó intenzív használatban egy megyeszékhelyen. Lelkemre kötötték, hogy a hostot csak hajnal 02:00 után rebootoljam a többi szolgáltatás miatt, a 2 VM mehet bármikor 20:00 után. 20:15-kor persze hogy az egyik VM helyett a hoston adtam ki a rebootot, bő fél óra volt amíg helyre állt minden. Mai napig nem tudom, hogy egyáltalán mi a bánatnak léptem be a hostra. 

Nem voltak boldogok, jó lecke volt. Utólag már csak röhögünk rajta (még mindig ott dolgozok :D )

Még csak nem is a hétvége, mint élesítésre akartam kihegyezni: hanem ha tudják, hogy a hétvége éjszaka a csúcsidei felhasználás („hétvége estéről lévén szó intenzív használatban egy megyeszékhelyen”), akkor miért hétvége estére van ütemezve ez? Hiszen éjszakázni meg hétvégézni senki nem szeret :)

Vagy ha mindig egyenletes terhelés van (kétlem), akkor gond nélkül mehetne kedd délelőtt -> hiszen ugyanazt jelenti, mint a hétvége este.

Azért raktam idézőjelbe, mert üzleti oldalról ez a maszlag jön általában. Hosszú, de akár középtávon sem fenntartható az az állapot ha hívni kell valakit. Már nem a 90-es évek van, lehet magas rendelkezésre állású rendszereket építeni, de van cég amelyik nem ébredt fel.

Jópárszor megtörtént, egy ideje apt install molly-guard paranccsal kezdek SSH után új rendszeren.

Van valami hasonló redhat rendszerekre is?

Illetve csak interaktív SSH session-re működik?

Mellesleg nem tartom csodaszernek, mert ugye a jó rendszergazda mindig lusta, akkor meg reflexből fel fogja váltani egy "reboot $(hostname)"... De valami talán jó.

"Sose a gép a hülye."

Ennek sincs értelme. Beírod "foo" helyett hogy "foobarbaz" egy idő után reflexből, és ugyanúgy újraindul minden gép.

Pl. annak lenne értelme, hogy reboot-ra kiír egy üzenetet, hogy biztos újraindítod az xy gépet? Ha igen, írd be, hogy xy(randomszám).

"Sose a gép a hülye."

Igen. A hostnévre kell rákérdezni, akkor többet ér, esetleg valami fetch-típusú kimenet is lehet előtte. Bár a hostnevet bele lehet tenni a PS1 promptba is, hogy látszódjon melyik gépen ügyködik az ember.

The world runs on Excel spreadsheets. (Dylan Beattie)

Ja, biztosan jó, de a neve tipikus FOSS projekthez híven egy szar. Valahogy elnevezésben sose voltak jók ezek, a legidiótább neveket tudják kitalálni nekik. Épp most néztek egy videót a Zellij terminál-multiplexerről, valami arab név, azt jellenti, hogy mozaik. Vagy Czkawka egy másik agyrém.

The world runs on Excel spreadsheets. (Dylan Beattie)

Ezt nem tudtam, nekem hülyeségnek hangzott. Mondom, védelmére legyen mondva, hogy ez általános. Biztosan fel tudnánk más projektnél is hozni a védelmükre valamit, hogy valami 70 éves mainframe vagy valami nem sok ember által beszélt nyelvből van, amit ismer 2 ember, csak az a baj, hogy a szoftverneveket a userek többi 99,9999999%-nak meg kéne tudni jegyezni, és nekik, ahogy nekem is, nem fog összeállni semmi a Molly név hallatán, maximum egy női név.

The world runs on Excel spreadsheets. (Dylan Beattie)

Mellesleg nem tartom csodaszernek, mert ugye a jó rendszergazda mindig lusta, akkor meg reflexből fel fogja váltani egy "reboot $(hostname)"... De valami talán jó.

Aki erre rászokik, az nem lusta, hanem direkt hülye. Egyébként imho interaktívan kérdez, szóval inkább vmi reboot <$(hostname) talán.

Illetve csak interaktív SSH session-re működik?

Alap esetben igen.

De egyébként csak scripteket futtat, szóval ha neked a random számosra keményedik, csak oda kell tenni.

Friss sztori egy cégnél: El kellett magyaráznom, hogy miért vegyük fel és telepítsük fel a szerverekre a molly-guardot. Ijesztő volt látni, hogy nem mindenki értette a létjogosultságát.

Windows szerverek: Ha rajtam múlik, akkor kb. 10. dolgom, hogy kiveszem a menüből való leállítás / újraindítás lehetőségét. Irtó veszélyes tud lenni. Pláne, ha a gép 100+ km-rel arrébb van szombat este.

Mikor kezdtem, én is raktam mindenféle PC-t szervernek...

Aztán egyrészt a hardverek elkezdtem baromi szarok és megbízhatatlanok lenni (újonnan is), a fullos mgmt meg nagyon sokszor jó, úgyhogy már egy ideje csak rendes szervert (akár használtat) veszünk.

"Sose a gép a hülye."

El kellett magyaráznom, hogy miért vegyük fel és telepítsük fel a szerverekre a molly-guardot. Ijesztő volt látni, hogy nem mindenki értette a létjogosultságát.

>20 éve van közöm valamilyen formában linux üzemeltetéshez, de őszintén szólva nem ismertem eddig a molly-guard-ot. Sosem volt szükségem ilyen toolra, és nem is látom létjogosultságát, annak ellenére, hogy vannak komoly dolgok is a kezem alatt. Én abban hiszek, hogy ha egyszer rossz helyen adtál ki parancsot, akkor utána 6x meg fogod nézni, hogy mit indítasz újra.

Halványan rémlik csak, hogy a pályafutásom elején mintha történt volna velem is hasonló, hogy rossz gépet indítottam újra. A konkrét eset nem maradt meg, az még eléggé "játszós" környezet és időszak volt. Arra viszont bőven elég volt, hogy megtanuljak odafigyelni komolyabb parancsok kiadása előtt.

Én is valahogy így vagyok vele. Egy alkalomra emlékszem, az konkrétan az utolsó munkanapon történt, már pakoltam össze, amikor kértek egy újraindítást egy gépre. "Ezt még megcsinálom" felkiáltással újra is indítottam a jumphostot. Oké, akkor épp csak nevetés lett belőle, de lehetett volna komoly is. Szóval többet ésszel, mint ész nélkül.

 

Most beugrott még egy eset, az már évtizedek előtt volt. Windows szerveren a kvm - mittomén - 3x capslock parancsa helyett sikerült a sleep gombot megcsapkodni. Baj ebből se lett, de nem vagyok rá büszke.

Én is 20+ éve linuxozom - pontosan 1997. óta.

Viszont ha van 1000+ géped (fizikai vagy vm mindegy), vannak kollégáid (L1-L3), van sok projekted, amik párhuzamosan is futnak, akkor célszerű valahogy minimalizálni a hibázás lehetőségét.

Egy újraindítás "csak" egy újraindítás. Jobb esetben elindul minden rendesen, lesz belőle egy 5-10-15 perces kiesés rendszertől függően. Na de amikor mondjuk SQL-ben adja ki valaki az UPDATE, DELETE utasításokat WHERE feltétel nélkül...

Ekkora méretnél restartot nem a jumphost-jumphost-jának-rdpje katasztrófaláncolaton keresztül ssh-n kellene kiadni. Hanem valami menedzsment-rendszerben. Ami megvédi a rendszert az admintól. Urambocsá CAB dzseditanács által jóváhagyottan, ahol be köll mutatni a szkriptet amit lefuttatsz, h. ne kézzel ad-hoc parancsok mentén menjen a dolog visszaellenőrizhetetlenül.

Aztán a tűzoltó vár az égő ház előtt, amíg végigmegy az engedélyezési láncon, hogy beléphet e vagy használhat e vizet. 

Ha valakit azért veszel fel, mert megbízol abban, hogy felelősséggel nyúl a melóhoz, akkor ne legyen már lánccal összekötve a bokája. Ha beugró külsős csinálja, akkor meg legyen aki értőn szemmel veri és dönt hogy le lehet e ütni az entert.

Mondom ezt úgy, hogy vallom a zéró trust és a szükséges és elégséges jogosultságok elvét. 

Nem menedzselek annyi gépet, hogy ez velem megtörténjen. Velem inkább régen volt olyan, hogy játék közben a billentyűzeten véletlen benyomtam a Power Off gombot, és csak csodálkoztam, hogy miért állt le a gép, talán elromlott, kifingott a táp, aztán jöttem rá, hogy mást nyomkodtam, mint kéne.

Egyébként meg a gyakorlati jelentőségét sem látom, mert alapból a shutdown/reboot nem azonnali, vár vele a rendszer egy kicsit, ha nem NOW/now/+0 opcióval adod ki kifejezetten, pont azért, ha meggondolnád magad, akkor még le tudd lőni a folyamatát, és nem indul újra, nem áll le.

The world runs on Excel spreadsheets. (Dylan Beattie)

Szerintem az emberek egyszer vesznek ilyen billentyűzetet. Azonnal hajítom ki, ha olyat találok amin power/sleep/standby gombok vannak. Opcionálisan fogok egy csavarhúzót, és kitöröm a faszba.

Ennél agyatlanabb faszságot nem láttam még, főleg hogy ha a nyilak és a fölötte lévő hatos környékén van. Legalább olyan, mintha direkt ki akarnának cseszni veled. Mintha a kocsi kormányára a hangerő mellé, vagy a váltókarra tennének csak úgy poénból egy Engine Stop gombot, és ahogy megnyomod instant megáll a motor, akár az autópályán 140-nél. Agyfasz.

"Sose a gép a hülye."

Ja, én se vettem többet. Ahogy mondod, ott volt a nyílbillentyűk fölött a Home, PgUp, stb. rész alatt, és bár a játékot WASD-vel nyomtam már akkor is, de másodlagosan ki kellet nyúlni a nyilak meg a numerikus rész környékére (chat, sound effect, stb. miatt), és véletlen beletenyereltem. Végül is nem volt akkora trauma, de face palm volt rendesen. Gondolom a dizájnerek nem gondolkodtak rajta, ott volt hely az extra billentyűknek. Ez azért 17 éve volt, akkor még jobban le voltak maradva a billentyűzetek, ráadásul ez valami noname, ócska, PS/2-es, gumidómos modell volt, valami Chickony vagy mi a törp, ami akkor megfelelt, de ez az egy idegesítő volt rajta. Hála istennek gyorsan tönkre is ment, így nem szívtam vele sokat.

The world runs on Excel spreadsheets. (Dylan Beattie)

ilyen és ehhez hasonló malőrök elkerülése végett a putty (multi putty manager) background környezetenként más-más színű (TEST, UAT, PROD, home, stb). jó pár éve csináltam bakikat, de ez bevált.

For Whites Only meeting room!

Igen, ilyenbe én is beleszaladtam. Nálam annyi a különbség, hogy magában a putty-ban a szöveg színe (Default Foreground) változott pl. éles környezeten pirosra, hogy jelezze a fontosságát. :) (AZ UAT zöld, a PET meg kék, hogy jelezze, itt nem gáz annyira, ha véletlenül rosszul adnék ki egy parancsot. ;) )

nem emlekszem hogy ilyen volt.

viszont egy pvh guest reboot kb. 5s. eszre sem veszik :)

neked aztan fura humorod van...

Az elmúlt 20 évben párszor előfordult, de legutóbb pár éve volt, hogy 100VM-es hostot sikerült rebootolni.
Akkor csak alig használtam, de ezt követően kötelezően mindenhova felteszi az Ansible a molly-guard-od, a hoston szintén + aliasolva a reboot, shutdown parancs.

Szerkesztve: 2024. 06. 10., h – 04:51

Van ennél rosszabb is:

root@server# cd /torlendo/adatokat/tartalmazo/folder
root@server# rm -r /*

huhhbazmeg, lemaradt a pont a per jel előtt!

(nem én követtem el, bár saját gépen volt már hasonló balesetem)

A legszebb talan nalam volt meg valamikor 2000 kornyeken:

rm -rf /torlendo/adatokat/tartalmazo / folder

Utana raadasul akkor valamiert ki akartam menni kavezni.

Azóta kitabolom az utvonalat, nem rekurziv torlesnel pedig unlink.

Error: nmcli terminated by signal Félbeszakítás (2)

+option: majdnem megtörtént ;)

ENTER előtti utolsó utáni pillanatban kérdés magamnak: biztos ezt akarom újraindítani? ...baszki nem is ezt kellene rebootolni

Utoljára a koliban a routert, igaz, azt nem egyszer :D

Természetesen soha, ha azt a múltkori esetet nem vesszük figyelembe. Meg azt a másikat.

Legjobb a távoli gépeken kiadni ezt, főleg, hogy windowson mindig vándorol a logout gömb

hup.hu##article[data-comment-user-id="16401"]

hup.hu##article[data-comment-user-id="4199"]

Bár már nem szerverekkel dolgozom, csak hálózati eszközökkel, de ezt hiszem, egy uplink trunk shutdown a nem megfelelő eszközön ide sorolható. Igaz, ha nem pont múlt héten sikerült volna, akkor a "sok éve" lett volna a megfelelő válasz.

"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Nekem ehhez legközelebb eső hibám, hogy hamarabb indítottam újra a szervert mint szerettem volna.
Elkezdtem írni a Rendszer üzenet szövegét egy textboxba. Nyomta egy enter sor törés céljával, erre kiküldte a reboot parancsot.
Mivel volt rajta egy 5 perces várakoztatás, hogy mindenki kitudjon lépni, így annyi történt hogy küldtem csak a rendszerüzenetet a hiányzó szöveg résszel.

Nem, de lehetne.

Kolléga 10+ éve megkapta a jegyet, title: reboot xy gép. Ő szépen meg is bootolta. Aztán jött a nagy eszkaláció, hogy este 20-kor kellett volna. Még neki állt feljebb majdnem, csak miután elolvasta az egész jegyet, akkor derült ki, hogy tényleg benne van, hogy reboot este 20-kor :D (TLDR néha káros)

Egyszer sikerült 3 napnyi munkát generálnom a first levelnek, részben önhibámon kívül. Lezároltam hibásan kb 300 usert. A script jól működött, és azokat zárolta akiket "kellet". Csak nem néztem meg a listát amit küldtek.
Utána derült, ki hogy kolléga rossz listát küldött, mert nem azok az emberek voltak vágólapon akiket gondolt + kb 6x annyi. Én meg ellenőrzés nélkül "kigyomláltam" őket.

Nem, de lehetne.

Régebben a reboot és shutdown kapott egy spec wrapper scriptet, ami jelszót kért. (Nem annyira a saját hülyeségem miatt, hanem a többi power user miatt.) A molly-guard óta nincs erre szükségem.

"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Szerkesztve: 2024. 06. 11., k – 09:19

Megtörtént esetek:

  • Ctrl-r  eseten a legutolso systemctl utasitas futott le, ami nem az volt, amire szamitottam :)
  • Up -> Enter
  • lxc container kapott 3 halt -ot, mire leallt, csak en ezt nem vettem eszre (mert miert is a monitort neznem), igy a kovetkezot maga a host kapta

Error: nmcli terminated by signal Félbeszakítás (2)

Vagy 20 eve nem volt ilyenem, aztan mult heten egy esti upgrade-nel a tavoli szerver helyett a notebookom indult ujra... Mondjuk meg ez a jobbik eset. ;)

Szerkesztve: 2024. 06. 11., k – 17:50

Egyeb: `shutdown` es `reboot` nem, viszont `iptables -P INPUT DROP` illetve `ifconfing eth0 down` volt mar, utana ment a telefon hosting cegnek, hogy reboot pls :)

Ilysmi rázós esetek előtt berakok egy crontabot +15...30 perccel későbbi lefutásra. Mondjuk reboot vagy egy tűzfalat kinullázó script.

Olyan már többször volt a múltban, hogy a rázós teszt mutatvány jól sikerült, haladtam tovább a melóval, majd 15 perc múlva elment az ssh....jah, reboot. Nabazz, nem vettem ki :)
 

jaja, juniper. Igazából az edgerouter (vagyis hát az alatta levő vyatta vagy vyos, vagy hogy hívják épp), hogy is mondjam, szóval erősen inspirálódott a junosból.

Illetve hát eleve, hogy van tranzakció, nem kezd el élni azonnal, amit begépeltél, azért az nagy királyság.

Évek óta nem turkálok kézzel szervereken, arra való az adott configuration management tool, a "kézzel SSH" antipattern, pláne nem is kivitelezhető, ha van mondjuk több száz node, no way, hogy egyesével kezeljem kézzel... ha megvan ehhez a mindset, akkor hamarabb is megvan egy új szerver, mint kézzel parancsolgatni...

Ezt szoktam ajánlani rövid olvasmánynak: https://www.copado.com/resources/blog/pets-vs-cattle-more-than-an-analo…

Látszik, hogy nem úgy üzemeltetek, ahogy te. Amiket szoktam üzemeltetni, azt nem is lehet másképp. :)

Már 15 éve is ciki volt az, hogy be kell lépni a gépekre valami csinálni, 15 év alatt pedig messze lehet jutni, ha van rá akarat, mindset és skill. A Puppet jövőre lesz 20 éves, az Ansible 12 éves, a Chef 15 éves, a Terraform 10 éves tool, miről beszélünk? A legrégebbi Puppet projektem 12 éves. Milyen zöldmezőről beszélünk? Nem tudok racionális indokot felhozni arra, hogy ezek ne legyenek használva, hogy éveken át ne merülne fel, hogy be kellene vezetni futó rendszerekre. Maximum azt tudom elfogadni, hogy nulla hozzáértés és nulla affinitás van erre az üzemeltetésen...

Ahogy én? Honnan gondolod, hogy tudod, hogy én hogyan üzemeltetek? :)

Amit kér a megrendelő, azt kap. Leírhatom én a véleményem, eszmecserét is folytathatok vele. Rossz esetben ott is szoktam hagyni a megrendelőt.

Maximum azt tudom elfogadni, hogy nulla hozzáértés és nulla affinitás van erre az üzemeltetésen...

Ez egy elég erős selection bias (más szóval butaság) részedről.

Ki mondta, hogy olyan távol állnánk egymástól? :)

Beszélsz te is faszságokat, Franko is. Néha egyikőtökkel értek egyet, néha másikotokkal, néha egyikőtökkel sem, néha mindkettőtökkel. Persze tudom, hogy ebbe belejátszik nálatok a provokálási faktor is (=pörgetni kell a HUP-ot).

Te mikor beszélsz faszságokat? :)

Persze tudom, hogy ebbe belejátszik nálatok a provokálási faktor is (=pörgetni kell a HUP-ot).

Na, akkor szervezek neked egy találkozót a kiadóval is, ahol megérdeklődheted, hogy mennyi ilyen elvárás van felém: pörgetni kell a HUP-ot :D (előre leírom: 0)

Legközelebbre ezt a találkozót az idei SysadminDay-re le is foglalom neked, remélem nem lesz probléma ott megjelenned (ha nekem nem az győriként :D)

Abból is hasznos lehetne ez, hogy utána a HUP-on te lennél a hivatkozási alapom, amivel a HUP-pal és velem kapcsolatban 20+ éve fennálló faszságokat tudnék cáfolni :D :D :D

Deal?

trey @ gépház

Ez sok mindentől függ. Főként helyzettől, helyszíntől, szituációtól.

De, amit te itt látsz, az nincs 40%-a annak, amit a közvetlen haverjaim látnak. Hogy ez jó vagy rossz, azt döntsd el magad ... nekem meggyőződésem, hogy nem csak én vagyok az itteniek közül ilyen, csak én őszintébb vagyok az itt az átlagnál :D

(kevesebb alakoskodás, modorosság, színi alakítás)

trey @ gépház

Egyrészt alakoskodás és alakoskodás között is nagy különbség van. Az internet nem felejt. Továbbá 1-1 mondatrész kiragadva sértő, bántó lehet. Én ezért fogalmazok diplomatikusabban itt, mint mondjuk szóban.

Mondjuk az én nickem nehezebb is beazonosítani. Jól tudok "radar alatt repülni".

Az internet nem felejt.

Remélem is, mert tettem ide a netre olyat, ami 25 év kemény munkába került.

Én ezért fogalmazok diplomatikusabban itt, mint mondjuk szóban.

Továbbá 1-1 mondatrész kiragadva sértő, bántó lehet.

Leszarom, mert ez nem templom, hanem egy fórum. Aki nem tudja az mit jelent az internetes anoním fórum, az egy idióta. A ilyen fórum nem szalon, nem templom, hanem kávéház/kocsma. Aki ez alapján ítél, az egy balfasz.

Tehát, emiatt teljesen felesleges egy nem létező figurát hozni, a kocsmában sem alakoskodok a haverjaimmal. 🤷‍♂️

trey @ gépház

Ahogy én? Honnan gondolod, hogy tudod, hogy én hogyan üzemeltetek? :)

Ezek szerint te nem használsz ilyen eszközöket... mert lehet ezeket legacy szar rendszereknél is használni, nem kell zöldmezős projekt hozzá.

Amit kér a megrendelő, azt kap. Leírhatom én a véleményem, eszmecserét is folytathatok vele. Rossz esetben ott is szoktam hagyni a megrendelőt.

A megrendelő ilyen szinten előírja, hogy márpedig CMDB/CMT tilos, kézzel kell turkálni? Vagy hogy kell ezt elképzelni?

Ez egy elég erős selection bias (más szóval butaság) részedről.

Mint ahogy az is, hogy nem üzemeltetek és az is, hogy ha mégis valahogy és valamit, akkor az zöldmezős... satöbbi.

Ezek szerint te nem használsz ilyen eszközöket... mert lehet ezeket legacy szar rendszereknél is használni, nem kell zöldmezős projekt hozzá.

Sherlock.... Használok ilyen eszközöket is. Tudod, nem minden feladatra használok kalapácsot.
A másik, hogy hiába használnám / használom ezeket az eszközöket, ha nem minden kollégában / ügyfélben (nem csak IT-ról beszélek!) nincs meg a kompetencia hozzá?

A megrendelő ilyen szinten előírja, hogy márpedig CMDB/CMT tilos, kézzel kell turkálni? Vagy hogy kell ezt elképzelni?

A megrendelő azt se tudja sokszor, hogy mi az a CMDB/CMT. Már az ITIL-nél, change mgmt-nél is leragadnak. Amit kifizet a megrendelő, amihez van kompetenciája, azt kapja tőlem. Ráadásul én igyekszem nem "kiselefánt a porcelánboltban" elven viszonyulni az ügyfelekhez. Elmondom az előnyöket, hátrányokat, győzködöm őket a szerintem jó megoldásról egy ideig. Aztán rájuk hagyom.

Mint ahogy az is, hogy nem üzemeltetek és az is, hogy ha mégis valahogy és valamit, akkor az zöldmezős... satöbbi.

Mégis úgy írsz, mintha nem üzemeltetnél. Nem ugyanúgy kell üzemeltetni Kis Pista Bt-t a maga 5 desktop számítógépével és 1 MS365 előfizetésével, mint a GigaNagyBankot a maga 5000 onprem szerverével + clouddal. Tudod, igényekhez a kabátot.

Egy mondatban: megfelelő IT érettség kell az IT technológiákhoz.

Sherlock.... Használok ilyen eszközöket is. Tudod, nem minden feladatra használok kalapácsot.

Mire nem használod és miért nem?

A másik, hogy hiába használnám / használom ezeket az eszközöket, ha nem minden kollégában / ügyfélben (nem csak IT-ról beszélek!) nincs meg a kompetencia hozzá?

Idézném magam szó szerint: Maximum azt tudom elfogadni, hogy nulla hozzáértés és nulla affinitás van erre az üzemeltetésen...

A megrendelő azt se tudja sokszor, hogy mi az a CMDB/CMT. Már az ITIL-nél, change mgmt-nél is leragadnak. Amit kifizet a megrendelő, amihez van kompetenciája, azt kapja tőlem. Ráadásul én igyekszem nem "kiselefánt a porcelánboltban" elven viszonyulni az ügyfelekhez. Elmondom az előnyöket, hátrányokat, győzködöm őket a szerintem jó megoldásról egy ideig. Aztán rájuk hagyom.

Akkor nem is te üzemeltetsz, hanem a megrendelő. Mit üzemeltetsz akkor?

Mégis úgy írsz, mintha nem üzemeltetnél. Nem ugyanúgy kell üzemeltetni Kis Pista Bt-t a maga 5 desktop számítógépével és 1 MS365 előfizetésével, mint a GigaNagyBankot a maga 5000 onprem szerverével + clouddal. Tudod, igényekhez a kabátot.

Mindkettőhöz pont ugyanannyira használható CMT/CMDB eszköz, ez független attól, hogy mekkora a cég, kisebb cégnél ráadásul könnyebb is bevezetni, hamarabb jön az előnye is.

Egy mondatban: megfelelő IT érettség kell az IT technológiákhoz.

Az bizony kell. Meg folyamatos fejlődés.

Mindkettőhöz pont ugyanannyira használható CMT/CMDB eszköz, ez független attól, hogy mekkora a cég, kisebb cégnél ráadásul könnyebb is bevezetni, hamarabb jön az előnye is.

Ez csak részben igaz. Ha nincs hozzáadott értéke, ami forintosítható az 5 desktop gépes cégnél, akkor felesleges bevezetni. Nem kell mindenhová csillagromboló.

Az bizony kell. Meg folyamatos fejlődés.

Akkor meg? Ha az nincs meg a megrendelőknél, ügyfeleknél, kollégáknál, akkor hogyan akarsz modern megoldásokat bevezetni, alkalmazni?

Tudod, sok cég le van maradva 10-20-30 évvel.

Milyen hibára gondolsz, például? Cattle séma van: ha egyet köhög, terminálódik és a CMT újrahúzza nulláról, nem gyógyítgatjuk. Teszt szerver van, de azon se kell turkálni, azt is a CMT/CMDB hozza létre, ugyanúgy és kezeli ugyanúgy, ahogy a fejlesztői szervereket és környezeteket is, satöbbi. Ha próbálsz különböző megoldásokat, azt is a CMT/CMDB állítja be, erre a célra felhúzott környezeten. Ez működik akár egy géppel is és felskálázható több ezer gépre, amit másképp nem is lehet értelmesen kezelni. Szóval nem értem a kérdést... ha használnál évek óta bármilyen CMT/CMDB eszközt, akkor szerintem se se értenéd, hogy mi volt a kérdésed. :)

Sok példa lenne, sok féle környezetből, kiragadok most egyet:

Levelezés, spamassassin, új filter írása, ahol cél, hogy ha a from name részben adott kulcsszó van (tipikusan cégneved vagy admin), ÉS nem a te smtp szerveredről jött, akkor jelölje spamnek. Van viszont néhány legitim külső partner, pl. google calendar, ahol szerepel a cégneved kulcsszava a feladó nevében, őt ne jelölje spamnek.

Ezt össze kell reszelni, nem triviális a feladat, sosem csináltad még. A teszteléshez kell teszt leveleket fogadni, hogy addig reszeld, míg úgy viselkedik, ahogy kell.

Ezt ugye sima SPF nem fogja meg, mert a spammer nem a @domain.hu -t írja át, hanem a CÉGNÉV <spammer@domainje.hu> formában jön. Levelező kliensek pedig jellemzően elfedik a mail címet, ha van név. Mancika pedig jól beszívja a phishing mailt.
Nevezhetjük kicsit durván fejlesztésnek, tesztelésnek. Akkor is kell egy szerver, ami be van drótozva egy nagyobb rendszerbe, tud levelet küldeni, fogadni és tudsz tesztelni rakja SSH-n, logon nézni, configot modosítani, restart, újra próba, logot nézni.

Ezt hogy oldod meg?

Levelezés, spamassassin, új filter írása, ahol cél, hogy ha a from name részben adott kulcsszó van (tipikusan cégneved vagy admin), ÉS nem a te smtp szerveredről jött, akkor jelölje spamnek. Van viszont néhány legitim külső partner, pl. google calendar, ahol szerepel a cégneved kulcsszava a feladó nevében, őt ne jelölje spamnek. Ezt össze kell reszelni, nem triviális a feladat, sosem csináltad még. A teszteléshez kell teszt leveleket fogadni, hogy addig reszeld, míg úgy viselkedik, ahogy kell. [...] Nevezhetjük kicsit durván fejlesztésnek, tesztelésnek. Akkor is kell egy szerver, ami be van drótozva egy nagyobb rendszerbe, tud levelet küldeni, fogadni és tudsz tesztelni rakja SSH-n, logon nézni, configot modosítani, restart, újra próba, logot nézni.

Továbbra se értem, hogy ennek az egésznek mi köze ahhoz, hogy kell-e SSH-n belépve turkálni a gépen vagy sem. CMDB/CMT eszközben át kell írni a konfigurációt és a CMDB/CMT eszköz a megfelelő gépre kiteszi a változást. Azt kell feltételezzem, hogy nem használtál még CMDB/CMT eszközt...

Ezt hogy oldod meg?

Például a Puppet spamassassin modulja írja ki a célgépre, deklaratív konfiguráció alapján,amit módosítok és a Puppet, ha kell újraindítja a szolgáltatást, ha nem kell, akkor nem. A fő különbség alapvetően ezen eszközöknél a kézi melóhoz képest, hogy nem procedurálisan írod le, hogy mit kell csinálni a gépen, hanem deklaratív módon leírod az állapotot, amit el szeretnél érni és a CMDB/CMT eszköz az, amelyik ezt "lefordítja" procedurális és környezetfüggő lépésekre. Ha nem tudosz jó deklaratív módot, akkor van mindig fallback procedurális módra, ott meg szimplán csak azt írod le, amit csinálnál a gépen, de ez nagyon ritka esetben szükséges.

Mutatok példát, Spamassassin ilyen módon már nincs, mert pod-ban fut, ami más műfaj, de például egy Postfix konfiguráció módosítás úgy néz ki, hogy az adott gépen vagy adott csoportban vagy valamilyen flag alapján megjelölt gépeken módosítok egy bejegyzést, például a Mailman sorba beleteszek egy plusz szóközt a demó kedvéért és a változás kimegy az adott gépekre így:
 

Info: Using environment 'production'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Retrieving locales
Info: Loading facts
Info: Applying configuration version '1718269808'
Notice: /Stage[main]/Postfix::Files/File[/etc/postfix/master.cf]/content:
--- /etc/postfix/master.cf      2024-06-06 05:17:59.088711560 +0000
+++ /tmp/puppet-file20240613-771182-9le03l      2024-06-13 09:10:34.070983177 +0000
@@ -80,2 +80,2 @@
-mailman  unix  -  n  n  -  -  pipe  flags=FR user=mailman argv=/usr/lib/mailman/bin/postfix-to-mailman.py ${nexthop} ${user}
+mailman  unix  -  n  n  -  -  pipe  flags=FR user=mailman  argv=/usr/lib/mailman/bin/postfix-to-mailman.py ${nexthop} ${user}
Info: Computing checksum on file /etc/postfix/master.cf
Info: /Stage[main]/Postfix::Files/File[/etc/postfix/master.cf]: Filebucketed /etc/postfix/master.cf to puppet with sum 1132e6d3c84e374f1e6fc771d60f1bbd
Notice: /Stage[main]/Postfix::Files/File[/etc/postfix/master.cf]/content: content changed '{md5}1132e6d3c84e374f1e6fc771d60f1bbd' to '{md5}5d7f28c8e2cb9ab721b285ba4a57bfa3'
Info: Class[Postfix::Files]: Scheduling refresh of Class[Postfix::Service]
Info: Class[Postfix::Service]: Scheduling refresh of Exec[restart postfix after packages install]
Info: Class[Postfix::Service]: Scheduling refresh of Service[postfix]
Info: Class[Postfix::Service]: Scheduling refresh of Exec[newaliases]
Notice: /Stage[main]/Postfix::Service/Exec[restart postfix after packages install]: Triggered 'refresh' from 1 event
Notice: /Stage[main]/Postfix::Service/Service[postfix]: Triggered 'refresh' from 1 event
Notice: /Stage[main]/Postfix::Service/Exec[newaliases]: Triggered 'refresh' from 1 event
Notice: Applied catalog in 41.30 seconds

Az egésznek annyi az előnye, hogy nem csak a módosítást teszi ki így, hanem a gépet akár nulláról újrahúzza, illetve ezt végrehajtja akár ezer gépen is, ha kell. Ha nincs Postfix, telepít, ha nincs ilyen sor, létrehozza, ha van, akkor módosítja, satöbbi. Nem megyek be a gépre terminállal.

Szóval továbbra se értem, hogy mi a problémád és azt miért nem lehet megoldani CMDB/CMT eszközzel.

Ansible-t használok, igaz még gyerekcipőben a lehetőségekhez képest.

A szitut még mindig ott nem értem, hogy míg az Ansible és a többi központi config management tool a kész megoldást teszi ki, amit jó esetben teszt szerveren előtte kiraktam és lepróbáltam. Na de odáig el kell jutni. Azt a configot össze kell rakni és vannak olyan feladatok, amit először tökölsz ki életedben, nem készen veszed le a polcról és rakod ki.
Egy scriptet is előbb megírsz, saját gépen letesztelsz legalább dummy I/O adatokkal, hogy hozza-e az elvárt működést. Aztán teszt szerveren életszagúbb adatokkal átpörgeted. Ha ok, akkor meg ki éles szerverre. Na de a fejlesztést, a kitökölést egy komplex problémánál muszáj nagyobb környezetben kipróbálni, pl. a fenti mail szerver. Nem az a kérdés, hogy hogy rakod a végleges configot vagy annak egy sorának módosítását. Hanem hogyan jutsz el oda, hogy az az 1 sor tényleg megoldást ad a te problémádra? Kisujjban ez nincs mindig meg, ha új a probléma. Eddig a pontig milyen környezetben, milyen hozzáféréssel jutsz el?

Itt a példád:

mailman unix - n n - - pipe flags=FR user=mailman argv=/usr/lib/mailman/bin/postfix-to-mailman.py ${nexthop} ${user}

A különböző flagekkel akarsz játszani, kell egy új feature. Hol hozod össze azt a végleges sort, amit majd kitelepítesz?

Gyanítom nem próbálkozásonként módosítod a mgmt toolt, hogy deploy config....á nem jó, módosít, újra deploy, még mindig nem jó. Mert ez így hatalmas overhead.

Na de odáig el kell jutni. Azt a configot össze kell rakni és vannak olyan feladatok, amit először tökölsz ki életedben, nem készen veszed le a polcról és rakod ki.

És ezt miért a célgépen akarod kézzel tökörészni?

Aztán teszt szerveren életszagúbb adatokkal átpörgeted. Ha ok, akkor meg ki éles szerverre. Na de a fejlesztést, a kitökölést egy komplex problémánál muszáj nagyobb környezetben kipróbálni, pl. a fenti mail szerver. Nem az a kérdés, hogy hogy rakod a végleges configot vagy annak egy sorának módosítását.

Pedig az is kérdés. És az is, hogy fejben még nem álltál át deklaratív leírásra, hanem procedurálisan próbálod megfogni.

A különböző flagekkel akarsz játszani, kell egy új feature. Hol hozod össze azt a végleges sort, amit majd kitelepítesz?

Alapvetően a Puppet modul rakja össze, nem én, én csak belenyúltam a template-be, hogy legyen változás, amit tudok demózni.

Gyanítom nem próbálkozásonként módosítod a mgmt toolt, hogy deploy config....á nem jó, módosít, újra deploy, még mindig nem jó. Mert ez így hatalmas overhead.

De. Mi az overhead? Push kimegy a megfelelő szerverre, azonnal. Ami hatalmas előny: nyoma van, hogy mit csináltál és mikor csináltad, vissza tudsz állni egy korábbi működő állapotra, létre tudsz hozni egy játszós-szervert, minimális melóval, mert csak megmondod a CMDB/CMT eszköznek, hogy legyen még egy szerver virtualizálva, ilyen-és-ilyen class, role, whatever és ott lesz, anélkül, hogy munkád lenne vele. Aztán azon megoldod, amit meg akarsz oldani, és ha megvan, akkor megy a szokásos merge-flow, akár squash commit mellett a végleges konfigurációba. Nem nagyon lehet másképp, ha nem akarsz a nyakadba venni egy valag üzemeltetési kockázatot.

Én nem tudok olyanról, aki vissza szeretne térni az old school kézi módosításokra, ha már egyszer átállt erre a működésmódra... sokan a fejüket verték a falba, hogy évekig szoptak feleslgesen, mert nem tudták, hogy ez milyen a gyakorlatban. Nyilván meg kell tanulni, ki kell alakulnia a készségeknek, de onnan triviális lesz.

És ezt miért a célgépen akarod kézzel tökörészni?

Van, hogy tucatszor vagy akár 100x mentem el a configot és restartolom a szolgáltatást és nézem az eredményt. Főleg, ha nem triviális, nem sokak által használt elborult ötlet pattan ki a fejemből  és a google-n is sok töredékből kell összelegozni a megoldást.
Ha nem egy szerveren lennék SSH-val, ahol mentek, restart, szolgáltatás tesztelés c. móka menne, hanem egy deploy rendszeren keresztül, akkor annyiszor kéne ugyanúgy (deploy) configot menteni és kirakni valamelyik játszós szerverre. Ezt érzem overheadnek.
Értem, hogy nyoma van..éles szerveren legyen is, oké azzal meggyőzhető vagyok, hogy éleset ne buzeráljunk közvetlen, ha nem muszáj.
De ahol az érdemi munka folyik, a fejlesztés, reszelés, szívás, azt miért kell minduntalan deployon keresztül, naplózva, mind a 100 próbálkozásomat? Azok csak skiccek, nem a kész terv rajz.
Nálunk a web fejlesztők munkájának életútja: laptopon a dev környezet, kitököli a kódját, ha már nem szintakt hibás és látszólag működőképes, akkor deploy a dev környezetbe, ahol nagyobb körítés van, aztán teszt környezet ahol még nagyobb környezet van, teszt kapcsolatok, teszt adatok, streamek, szinte pontos mása az élesnek. Ha itt is oké, akkor megy éles környezetbe.
De a php/java/dotnet stb kódját nem blokkonként tolja devre és nézi, hogy na mi újság? Előbb laptopon összerakja valami studio szoftverrel.
 

Nekem linux üzemelteti oldalon a laptopomon nincs bind, mysql, postfix, dovecot, stb, mert ezeknek rögtön nagyobb környezettel kell együtt működnie, a teszthez is. Ezért ez a lépés kiesik.

Van, hogy tucatszor vagy akár 100x mentem el a configot és restartolom a szolgáltatást és nézem az eredményt. Főleg, ha nem triviális, nem sokak által használt elborult ötlet pattan ki a fejemből  és a google-n is sok töredékből kell összelegozni a megoldást.

Ez azért nagyon olyan szagú, hogy jobb, ha nem így csinálod, mert nem véletlen, hogy milliók fejéből nem pattant még ki és nincs rá kitaposott út...

Nekem linux üzemelteti oldalon a laptopomon nincs bind, mysql, postfix, dovecot, stb, mert ezeknek rögtön nagyobb környezettel kell együtt működnie, a teszthez is. Ezért ez a lépés kiesik.

És mi tart vissza attól, hogy konténerben teszteld magadnál és aztán konténerben is fusson? Nem kell feltalálnod a meleg vizet vagy a kereket újra, erre vannak kidolgozott módszertanok, amelyek már legalább 10-15 évesek.

Oké, értem, bár kicsit idegen a szitu, ez tény :)
Te helyi gépen/laptpon kontérenben szoktak kitesztelni azt, amit utána a deploy rendszerrel kiraksz dev/teszt/éles környezetbe?
Ott a configokat azért konzollal betyárkodod, ugye?

És ha adott megbízód adott szerverét kell módosítani valami okból, akkor előkeresed az adott konténert a laptopodon, beröffented és ott rakod előbb össze? Söt mi több, ha indokolt, indítod hozzá a teljes dev szerver "parkot", ha külső kapcsolatai vannak? 
Próbálom minél jobban elképzelni, mert egyelőre nagyon macásnak tűnik :)

Ott a configokat azért konzollal betyárkodod, ugye?

én néha belekezdek kézzel konfig-betyárkodni, de a vége mindig az, hogy elfelejtem, mi is a változtatás, amit kézzel összekókányoltam. azért az alábbi kettőnek nem jelentősen bonyolultabb az átfutási-ideje:

  • option1
    • átírom az infrastrukcture as code repoban
    • lefuttatom lokalból a helmfile syncet / ansible playbookot / bármit
  • option2
    • átírom kézzel
    • restart, ha kell
    • jegyzetelek, hogy mi mindent kell majd nem elfelejteni átvezetni

Te helyi gépen/laptpon kontérenben szoktak kitesztelni azt, amit utána a deploy rendszerrel kiraksz dev/teszt/éles környezetbe?

Nem feltétlen helyben és nem így, de igen. Szinte kizárólag az Infrastructure-as-Code az eleje, try-and-error jellegű módosítás nem annyira jellemző, inkább elolvasom rendesen a doksit és felépítem fejben, amit el szeretnék érni, mint vakon próbáljam.

Próbálom minél jobban elképzelni, mert egyelőre nagyon macásnak tűnik :)

Mint írtam, amíg nem jössz bele, nem alakulnak ki készségek és nem állsz át fejben arra, hogy mikor-honnan-hova megy a konfiguráció, addig lehet macerásabb. Utána nem fogod érteni, hogy mi a 'faszé nem csináltad így évekkel ezelőtt már...

A deploy toolt kézzel "txt-ben" szerkeszted, mint láthatunk a neten megannyi pl. Ansible playbook példát vagy van valami kattingatós varázs felület, ami segít a kezed alá dolgozni és nem azzal meg el az idő (Ansible-nél maradva), hogy a behúzás a helyén legyen, különben elszáll az értelmező?
 

Na ez egy kiváló példa, hogy miért bugosak, memory leakesek manapság a programok.

Meglepő módon pont a konténerek és a felhős árazás óta javult jelentősen a kódminőség, mert ha a cég SaaS (is) szolgáltat, akkor minden ilyen leak neki fáj, nem az ügyfélnek, merthogy nem az ügyfélnél fut. Például a Gitlab nagyságrendeket javult, amióta van felhős Gitlab, mert a kódbázis ugyanaz, nem csinálnak egy "nálunk fut, fasza" és egy "ügyfélnél fut, leszarom" kódbázist.

Akkor maradjunk egy konkrét üzemeltetési issue-nál (friss példa):

Adott X cég. Egy ideje tapasztalják az admin felhasználók, hogy nem tudnak belépni bizonyos szerverekre bizonyos időnként. Nem lehet sémát húzni a hibára. Hónapok óta él a hiba, de nem lehet egyértelmű időponthoz kötni. ITIL, CHG mgmt., dokumentáció nincs. Túl nagy a fluktuáció ezen admin felhasználók között, így megkérdezni se lehet a régi kollégákat. A te CMT / CMDB megoldásod önmagában hogyan oldaná meg ezt a problémát?

ITIL, CHG mgmt., dokumentáció nincs.

Legyen, aztán lehet folytatni az legacy szarok pucolását. Mint írtam, a Puppet jövőre lesz 20 éves, az Ansible 12 éves, a Chef 15 éves, a Terraform 10 éves tool, miről beszélünk? 10-15 éves lemaradásról. Igen, szakmai igénytelenség, ha ma futó rendszeren nincs használva semmilyen CMDB/CMT eszköz. Mondtam én, hogy nincs ilyen? Nem mondtam, itt hozzátok az élő példákat, hogy velünk élő történelem az ilyen szakmailag igénytelen rendszer. Lásd ismét szó szerint idézve magam: "Maximum azt tudom elfogadni, hogy nulla hozzáértés és nulla affinitás van erre az üzemeltetésen..."

Nem lehet üzemeltetőként azt mondani magadra, hogy naprakész tudásod van, kurrens technológiákkal és nincs lemaradásod, meg azt, hogy nem használsz CMDB/CMT eszközöket és nem célod átállni CMDB/CMT alapú működésre.

A te CMT / CMDB megoldásod önmagában hogyan oldaná meg ezt a problémát?

Úgy, hogy minden változás nyomon van követve, mert a CMDB/CMT végzi el. Vissza lehet követni, hogy mióta van hiba.

Megjegyzem, hogy ez a projekt zöldmezős. Igen, legacy módon építették fel a rendszert. Igen, ezt átfaragni + átpréselni a vezetőségen hónapok munkája lenne (szegények nem igazán értenek a modern IT-hoz) - közben szorít a határidő is.

Úgy, hogy minden változás nyomon van követve, mert a CMDB/CMT végzi el. Vissza lehet követni, hogy mióta van hiba.

Amíg az "buli", hogy az emberek titkolják a munkájukat, mit csináltak aznap, megy a legacy tákolgatás, addig nem lesz CMDB/CMT. Még a végén kiesnének a csontvázak a szekrényből. Megjegyzem: CMDB/CMT nélkül is elég sok csontvázat, aknát találtam.

Nekem hiba esetén mindig az alábbi kérdéseim szoktak lenni:
- Mióta él a hiba?
- Ki / hol észlelte először?
- Milyen change-k történtek a hiba észlelése +-1 hónapos intervallumban?
- Mit okoz a hiba ténylegesen?

Szóval a te CMDB/CMT megoldásod az általam említett hibán nem segít, mert nincs információforrás. Ilyenkor jön a senior (például én), aki végigtúrja a rendszert és megkeresni a hiba okát, majd el is hárítja azt. Igen, ha kell, akkor belépve az összes szerverre, végigtúrva az összes naplófájlt stb. Már ha van egyáltalán naplózás....

Megjegyzem, hogy ez a projekt zöldmezős. Igen, legacy módon építették fel a rendszert. Igen, ezt átfaragni + átpréselni a vezetőségen hónapok munkája lenne (szegények nem igazán értenek a modern IT-hoz) - közben szorít a határidő is.

Idézném magam szó szerint: Maximum azt tudom elfogadni, hogy nulla hozzáértés és nulla affinitás van erre az üzemeltetésen...

Mit mondjak egy olyan üzemeltetésről, ahol az utóbbi 10 évben nem volt arra se igény, se érdeklődés, hogy egy CMDB/CMT eszközt elkezdjenek bevezetni? Ők lennének a szakma csúcsa, ahogy többen is előadják itt, büszkén, hogy bizony a CMDB/CMT az faszság?

Szóval a te CMDB/CMT megoldásod az általam említett hibán nem segít, mert nincs információforrás.

Hogyne segítene, ha lenne, nem lenne ilyen jellegű hiba. 10-15 év volt bevezetni. 10-15 év rengeteg idő az IT területén.

Konkrétan ez a cég 1,5 éves. Nem 10, nem 15, hanem 1,5. Nem régen kerültem velük csak kapcsolatba.

A CMDB/CMT jó dolog, ebben egyetértünk. Én is hiányolni szoktam - a cégek 90%-nál kupleráj van ezen a téren. Is.

A véleménykülönbség köztünk: Amiről te beszélsz, azt is fel kell valakinek építeni és majd üzemeltetni is. Szerinted ezt a lépcsőt pikk-pakk el lehet érni. Szerintem nem, vannak előfeltételei. Kb. mint egy Mashlov piramis az IT infrában.

Továbbra se értem, hogy akkor miről beszélünk.

Ezek a CMDB/CMT eszközök 10-15-20 évesek, használatuk kvázi kötelező, ahol nem használják ott nem azért nem használják, mert nem zöldmezős a projekt, hanem azért, mert nincs meg rá a szakmai igényességük, pedig jelentős mennyiségű munkát spórolnak meg és akár ingyen van szinte mindegyik. A Puppet 15 éve már közel stabilnak mondható, 15 éve be lehet vezetni zöldmezős projektnél, akár, de ami 15 éves projekt létezik még ma, az már gyakorlatilag legacy szar.

Ahogy írtam már, maximum azt tudom elfogadni, hogy nulla hozzáértés és nulla affinitás van erre az üzemeltetésen, de akkor meg ne legyen már büszke magára az illető...

FYI: nem, nem bővebb, sőt, valószínűleg a szavazók többsége közelébe nem került még olyan rendszereknek, amelyeket én rakok össze és/vagy üzemeltetek. A melóm jelentős része az, hogy megtanítsam az üzemeltetőknek, hogyan lehet a sok munkát igénylő legacy fosból egy kevés munkával automatikusan üzemeltethető rendszert faragni. Ahja, vannak cégek, de még mennyi, ahol a helyi nagyhangú jön azokkal az "érvekkel", amelyekkel itt a helyi nagyhangúak jönnek, mint te is, aztán kiderül, hogy meg lehet csinálni, amit szerintük nem lehet. Mondjuk ennek időnként az a premisszája, hogy a helyi nagyhangút kirúgják, vagy az a következménye, hogy a helyi nagyhangú felmond, mert kiderült, hogy a király meztelen...

Ha itt valaki nagyhangú, az te vagy.

Nem érted az egész lényegét. Nem csak arról van szó, hogy reboot, nem csak linuxon, és nem csak SSH-n. Igen, a központi management nagyon jó, kényelmes, gyors..... Akkor is ha le kell gyalázni valamit. Mert egy rossz "mozdulat", egy benézett script, command, kiküldöd több száz vagy ezer gépre... Az sokkal jobban fáj, mint egy rossz helyen kiadott reboot.

"Sose a gép a hülye."

Sikeres cégek mégse azt az utat választják, ahol a szerencsétlen rendszergazda egyesével végigiterál a gépeken... ahhoz túl drága az emberi erőforrás, versenyhátrányt okoz, ha könnyen és egyszerűen automatizálható feladatokat emberre bízunk.

Szerkesztve: 2024. 06. 13., cs – 13:11

Aki a reboottol fél, az nem nyomott  meg init 0-at, init 6 helyett egy nem menedzselt eszközön, ami cserében magasan van és mástól kapja az áramot.

Ugyanez tűzfalszabalyokkal való önkizárásnál mégszebb.

Örök kedvencem, mikor az ügyfél tàvolról kernelt frissített a gépen, csak épp elfelejtette a hàlókàrtya moduljàt beforgatni a kernelbe. Tette december közepén egy olyan gépen, ami egy oszlop tetején figyelt....

"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Pff... Egyszer, egyetlen egyszer volt olyan szerverem, amihez így fordítani kellett a modult.... És minden frissítés és minden reboot után össze volt szorulva a kloákám, hogy akkor feljön-e a hálózat restart után.

Utána ha volt ilyen (1-2x előfordult, centos 6 idején volt egy talán broadcom kártyákkal), inkább raktam a gépbe 1500-ért a sarki boltból egy realtek 8169-et, mert az tuti mindig megy. Később CentOS 7-től már nem volt sose ilyen gond soha.

"Sose a gép a hülye."