Reboot a rossz terminálban.

Már sokadszorra. Szerencsére a saját gépem indítottam újra távoli helyett, és nem fordítva. Mindenesetre azt hiszem ideje új megoldást találnom. Le fogom szoktatni magam, hogy init 6-ot írjak, inkább összefirkantok egy scriptet minden általam kezelt rendszerhez, ami újraindítja a gépet, de csak akkor ha a kötelező argumentumként megadott hostnév az, amin épp fut. Kis failsafe hülyeség ellen.

( E-Medve v | 2016. 09. 02., p – 16:58 )

A molly-guard csomag épp ilyesmire szolgál. Ha SSH-n vagy benn egy távoli gépen, akkor megkérdezi a hostnevet, ha kiadtad a shutdown/reboot/halt/poweroff parancsok egyikét. (Tehát az init 6 ellen nem véd.)


#!/bin/sh

# alt-reboot
HOSTNAME=$(hostname)

echo -n "Enter hostname: "
read answer
if [ "${HOSTNAME}" != "${answer}" ]; then
  echo "Error: Invalid hostname entered."
  exit 1
fi
exec reboot

Aliasold be, hogy ez fusson le a reboot parancsra, es mar kesz is.
--
Blog | @hron84
Üzemeltető macik

( bucko | 2016. 09. 02., p – 19:58 )

A Window title beállítása sokat szokott segíteni.

Nagyon helyes, en minden szerveren kotelezove tennem a heti, legfeljebb havi egyszeri restartot. Eleg sok kernel frissites meg minden mas hulyeseg jon ki, es ha csak labon frissited a rendszert, az nem biztos, hogy mindent meg is old. Arrol nem beszelve, hogy a tervezett restart meg mindig jobb, mintha egy aramszunet utan nem bootolna a gep, mert mondjuk szar kernel van a defaultban.
--
Blog | @hron84
Üzemeltető macik

Átgondoltam már elég régen. Biztosíthatlak full hülyék. ;)
Az ilyen utasításoknak az a lényege, hogy a témához abszolút semmit sem értők hoznak szabályokat. Ez nagyon jó, mert látszólag dolgoztak, lehet dokumentálni. Az előírt tevékenységet is lehet dokumentálni.

Ez a periodikus boot nagyon értelmes dolog.
Kaptam már parancsot AIX mentésére: CD-re tar.gz formátumban, hogy egységes legyen! Ez volt a "vállati szabvány"! :)) Ha belegondolsz, az AIX saját backup formátummal (mksysb) rendelkezik, amely CD-re, DVD-re, szalagra, hálózatra :) kiírható és a kopasz gépre (ha elfüstölt, akkor másik ugyanolyan vagy eltérő hardverre) installálható. Bedugod a backupot és fölmegy. Mellékesen a tar.gz pl. az acl-eket sem tárolja, szóval semmire nem használható.

Tehát ez a példa tervezett mentés volt, és full hülyék írták elő. Hidd el, ennél a nem pici, országos cégnél 20év fejlesztés/üzemeltetés/üzemeltetés támogatás keretében jó néhány hasonló okosság előfordult!

Összegezve: a full hülyék írnak elő olyan dolgokat, hogy full hülyék is tudjanak üzemeltetni. A rendszerek elég jók ahhoz, hogy még ezt is túléljék, tehát a megoldás jobbára működik. ;)

En nem tudok abban a kerdesben nyilatkozni, hogy akik a periodikus bootot eloirtak, azok full hulyek voltak-e vagy sem, mert nem ismertem az illetoket, am a mondas attol meg igaz: a vastyuk is talal szeget. Vagy micsoda micsodat.

Szoval, en lattam mar olyan gepeket, amik egy aramszunet utan (igen, szunetmentesnel is van ilyen, a vegtelensegig semmi nem tart) nem bootoltak ujra, mert nem volt rendesen megcsinalva a boot, es ilyen 3-400 nap uptime utan mar mindenki elfelejtette, hogy erre is gondot kellene forditani. Meg a know-how -t is, hogy hogyan is bootol a gep.

Olyat is lattam mar, hogy valaki figyelmetlensegbol letorolte a glibc nehany fajljat. A gep ettol meg labon marad, de rendesen bootolni mar sosem fog.
--
Blog | @hron84
Üzemeltető macik

Számomra ezek a dolgok elképzelhetetlenek, bár láttam már karón varjút. ;)
A szakemberek, a hozzáállás és a linux is igen felhígult mára. :(
Mi viszont sokkal keményebben üzemeltettünk. Mindent meg kellett tenni annak érdekében, hogy
1) A kocsmából el ne késs.
2) A balta esik valamelyk gépre, akkor se kelljen abbahagyni a piálást.
Ebből következően a baleset nem szerepelt a szótárunkban. ;)

A szünetmentesnél meg nem az áramszünet a probléma, hanem a háromnyolcvan! Éjjel fél háromkor, tápok robbannak, csajok sikoltoznak. :))

Egy produktív server - de egy fejlesztőire is igaz - újraindítása a legkevésbé a rendszergazdát érinti. Felelős üzemeltető nem akkor indítja újra a gépet, amikor úri kedve úgy diktálja, hanem igyekszik két TMK között működőképes állapotban tartani, majd a TMK során véglegesíti a változásokat és egy reboottal ellenőrzi, hogy minden rendben be lett-e állítva. Az egy jó hely, ahol van heti TMK, szerintem a havi elegendő, de a legtöbb általam ismert helyen a TMK egy sátántól való dolog és teljesen elképzelhetetlen, hogy egy servert újraindítsanak. Az ilyen felelőtlen üzemeltetésnek érdekes napjai vannak, amikor valami bedől.

Ave, Saabi.

Jajjj! Nem vagyok tisztában ezekkel a modern katonai rendfokozatokkal. ;)
Számomra a rendszergazda az, aki a rendszer módosíthatja, pl. upgrade, patch és szoftver installálás, konfiguráció kialakítás, hardver módosítás.
Az összes többi az az alkalmazást üzemelteti. Max valamilyen módon monitorozhatja a rendszer erőforrásait, esetleg szól a rendszegazdának, de nem nyúlhat hozzá.
Napjainkban, amikor jönnek a havi, heti stb. frissítések, akkor is érdemes
- csak azokat az elemeket felrakni, amire szükséged van - melós
- elolvasni miről szólnak a frissítések, és csak akkor felrakni, ha szükséged van rá - ez is melós
- a működő rendszert befagyasztani
Viszont kevesebbet kell próbálkozni. ;)
Egy szakképzetlenebb (mily szép magyar szó:) üzemeltető rossz esetben a próbálkozás után csak megállapítani tudja, hogy nem bootolt. Ez kinek jó?
TMK - ez tetszik! Eddig csak TMK lakatosról hallottam. ;)
AIX alatt is van preventive maintenance, ami részben azt célozza, hogy az új eszközök/driverek benn legyenek az adatbázisban. Ha eldurran egy nagyon régi diszked, máris rakhatod be helyette az újat és ismeri a rendszer. Ugyanez linuxon néha kézműves tevékenységnek felel meg. ;)
Bocsi, az áixezésért, azon dolgoztam/üzemeltettem sokat. De azért a mióta használsz linuxban én vagyok az egyik 25 éves. Ráadásul van jelenleg is egy elég feszített üzemű linuxos rendszerem, ahol a rendszergazdi vagy nem érti, vagy a haját tépi, vagy üvöltöz', ha megszabom az üzemeltetési szabályokat. Pedig csak a rendszer megbízható működése érdekében teszem. Semmi ilyet nem akarok mondani, hogy "régebbi iskola". Inkább a mindenféle policy helyett a feledatot tartom szem előtt.

Elobb-utobb fel kell rakni a postpone-olt frissiteseket is, nem veletlenul jonnek azok ki. Raadasul te sem fogod tudni fejben tartani ketezer-nemtudomhanyszaz csomag osszes tetves fuggoseget.

Altalaban en ugy frissitek, hogy ami nem erinti a rendszerkritikus reszeket, azok mehetnek fel instant. Dpkg, APT, atop, kulonbozo monitorozo toolok, ezek rendszeresen frissulnek. Az osszes tobbi tervezett maintenance kereteben (vagyis amikor megallhat a kiszolgalas). Illetve a security frissiteseket probalom mindig, kivetel nelkul mindig felrakni, mert azok altalaban fontosak. Inkabb alljon meg egy fel percre is a szolgaltatas, minthogy egy ismert lukon ne legyen folt.
--
Blog | @hron84
Üzemeltető macik

TMK a.m. Tervszerű Megelőző Karbantartás. Nem csak a traktoroknak van ilyenre szükségük. Amúgy én se ma kezdtem az üzemeltetést, ifjú koromban meg tisztességesen le lettem tolva, amikor az egy HP9000 K220-as serverem várható meghibásodást jelzett az egyik root disken, mire én bejelentettem a hibát és leállítottam a gépet, mivel ezekben még nem volt hot-swappable a system disk. Úgy lebaszott a főnököm, hogy egy életre megtanultam, amíg nem dől össze magától, addig csak akkor állítunk le servert, ha a felhasználók - nyilván nem mind egytől egyig - hozzájárulnak. Vagy legalább értesítsem őket.
Azóta persze mindenféle megoldások születtek HP-UX alatt is arra, hogy on-line telepíthess mindeféle patch-et, drivert, miegyebet és egy tervezett reboot során majd aktiválódnak. Ám ezt a rebootot sem érdemes hónapokig halogatni.

Ave, Saabi.

A TMK = preventive maintenance. ;)
Ezt a hibát meg nem követted volna el, ha többet olvasol. A diszkről is, meg az üzemeltetésről is. Bár személy szerint a há-pukszot nem tartom nagyra, de gondolom ez őket nem nagyon zavarja. ;)

Az ész nélküli frissítgetés az inkább egy vindózos mánia. Jól belőtt rendszernél igen ritkán van rá szükség. A véleményemet azért az is befolyásolja, hogy soha nem üzemeltettem sok random useres szervert ami kifelé nyitott. Inkább a soha nem állunk meg és adott időre be tudjuk fejezni a feladatot volt az irányelv.

Én arra lennék kíváncsi, hogy pl. a Google vagy az Amazon, esetleg a Dropbox milyen gyakran rebootolgat node-okat? Mert péládul egy-egy ilyen leállással/újraindulással a redundanciát is tudod tesztelni. Mert szép dolog a folyamatos frissítés (akár kernel esetén is), de ha egy reboot után nem indul el, akkor cseszheted.

Lásd még a témában a Chaos-Monkey-t

Sztem azert ott se szeretnek rebootolgatni, mert egy cloud node eseteben ez nem egy instant dolog. Eleve el kell migralni rola az osszes ott futo customert, legyen az VPS vagy mas cucc, ki kell loginolnia a clusterbol, leall, reboot, migra vissza, hogy az egyensuly ne boruljon. Egy fullra erre optimalizalt rendszerben is negyed ora siman meglehet egy ilyen ciklus, es egyszerre csak korlatozott mennyisegu node indulhat ujra, hiszen az osszkapacitas nem csokkenhet az aktualisan kihasznalt kapacitas ala lenyegesen.
--
Blog | @hron84
Üzemeltető macik

Én a múltkor azon lepődtem meg, hogy egy 3 node-os MongoDB esetén hogy zajlik az update.

Valószínűleg sok múlik azon, hogy VPS-t kap a kedves ügyfél vagy valami szolgáltatást. Ott ugyanis könnyen elképzelhető, hogy akár földrészenként megvan 1-2 példányban az adata. Akkor pedig max. annyit vesz észre egy-egy leállásból, hogy nem 10-30 ms a késleltetés (EU-EU), hanem 150-300 ms (EU-US).

( uzsolt v | 2016. 09. 02., p – 20:15 )

Vagy egyszerűen: alias init 'echo Tavoli gep '. Persze ekkor az lesz a baj, hogy a /sbin/init-re szoksz rá :)