Fórumok
Sziasztok!
Jelenleg nem vagyok otthon és az Internet kapcsolatom is csak eléggé körülményes.
A problémám:
Van egy Asterisk config, ami egyik része mc-vel szerkesztés után 0 byte-os lett.
Az oka, hogy a merevlemez partíciója megtelt.
Az Asterisk jelenleg fut.
Van lehetőség az extensions config kiolvasására a futó kliensből - esetleg a 0-byteos file-lal kezdhető valami?
Cirka tíz nap múlva tudok foglalkozni vele - remélhetőleg addig nem lesz nagyobb baja...
Előre is köszönöm az esetleges válaszokat.
Szerk.:
dialplan save segítségével egész szépen és korrekt formátumban kiadta magából a konfigot (ahogy benne is volt kb.), így minden lényeges dolog megtalálható benne.
Hozzászólások
core show dialplan
ill. a pontos syntax verzió függő, de nagyjából ez kell neked. kis konverzió után akár az eredeti config filet is összehozhatod belőle.
Köszönöm, dialplan show-val ki lehet íratni a hiányzó részeket.
sub
Köszönöm még egyszer.
dialplan save segítségével gyakorlatilag kiadta magából az eredeti config file-t.
Mondjuk az extensions.conf-ot felülcsapja - erre érdemes lehet figyelni (nálam pl. több fileból áll) -, de kommenteket leszámítva szinte minden az eredeti formátumban előkerült.
Végülis a lényeg megvolt mentésben is, csak néhány dolgot kellett volna újraírni - de ez sokkal több segítség hozzá, mint amire számítottam...
A naccerű mingyákummanter/mingyáeditor... Örülj neki, hogy nem F6-tal mozgattál át a megtelt partícióra csilió darab pótolhatatlan fájlt, mert tudomásom szerint ilyen esetben azok is go to devnull.
Igen, elég nagyszerűen csinálja a dolgokat. :S
Nekem most jobb dolgom is lenne egyébként - nem szándékoztam net mellett ülni...
Na most értem én, hogy meg lehet szebben is csinálni egy programot, ugyanakkor nem gondolom normális üzemi körülménynek azt, hogy megtelik a filerendszer, amin dolgozunk.
Örülj neki, hogy nem F6-tal mozgattál át a megtelt partícióra csilió darab pótolhatatlan fájlt, mert tudomásom szerint ilyen esetben azok is go to devnull.
Legalább lesz sok szabad hely. :D Igaz, nem a célon, hanem a forráson, ahol eddig is volt. (Nem, nem mondtam komolyan. ;) )
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
En pedig azt gondolom, hogy egy olyan szoftver, ami file managgernek hirdeti magat, igenis legyen mar oly kedves aranyos elengedni egy ellenorzest, hogy valoban van-e ennyi helyunk.
--
De, normális üzemi körülmény. Egy multiuser/miltitask környezetben bármikor telemehet a fájlrendszer, bármikor elfogyhatnak az osztott erőforrások - ezekre illendő dolog felkészülni.
Ezzel vitatkoznék. Üzemi, de nem normális.
1. Multiuser környezetben kvótázni, ha megvan a veszélye, hogy egy user lenullázza a szabad helyeket.
2. Ahogy írod, erre illik felkészülni, tehát ha fogyóban a hely és riaszt a felügyelő szoftver, akkor sürgősen tenni kell valamit, megelőzendő a fájlrendszer betelését.
Hm? ;)
Hint: UID=0 esetén nullázni lehet a szabad helyet, ha van kvóta, ha nincs - hiába használ a kvótájából szinte semmit a mancika123 user, ha épp telerotty az adott fájlrendszer, akkor neki a 123 bájtos nagyonfontos.txt állománya megy az emcéedit jóvoltából a levesbe.
A monitoring az egy dolog, de egyrészt az alkalmazáson az nem segít, ráadásul az fs telef0sása is változó sebességgel történik. Scenario: A qwer alkalmazás meggajdul, és ontja magából a logokat, jól bele az egy / fájlrendszerbe. Közben mancika123 user az mcedittel szerkeszti a nagyonfontos.txt fájlt. A monitoring néhány percenként (m) néz rá a szabad helyre. A gépen be van jelentkezve 456 fő interaktív user. t=0 fs telemegy. Átlagosan t+m/t időpontban a monitoring észreveszi, hogy tele van az fs. A meggajdult app m/2 idő alatt képes a warning szinttől 100%-ra elfogyasztani a helyet - láttunk már ilyet.
Admin kap sms meg e-mail, hogy tele az fs, illetve hogy n+1 másik alkalmazás a helyhiány miatt leállt. Az admin mit fog csinálni? Először helyet, aztán a megállt szolgáltatásokat teszi rendbe - nem pedig a 456 bejelentkezett usert fogja végigtelefonálni, hogy "na most ne lépj ki az emcéeditből, mert szó nélkül nem foga elmenteni azt, amit szerkesztettél".
Itt az alkalmazásnak kell megnéznie, hogy a fájl mentése sikerült-e vagy sem (más néven menteni, ha az sikerült, akkor unlink és rename), és ha nem, akkor feltenni a kérdést, hogy "nem sikerült a mentés, mi legyen?"
Ha a root képes telenyomni egy fájlrendszert, ott valami nagyon el van cseszve.
Logokat normális helyen nem rakunk olyan helyre, amit Mancika is írhat. Amit nem tudok biztosan: a syslogd különböző változatai mit művelnek, ha nincs helyük a logok számára.
Egyébként emlékeim szerint a vi nem lép ki, ha hiba történik a mentés közben, bár ez lehet, hogy megint verzió (vim, gvim stb.) függő. Mást meg nem szoktam használni.
De mindegy, mélyebben nem másznék bele. Nekem a tizenöt év alatt, amit üzemeltetéssel töltöttem, tán egyszer volt olyan gondom, hogy elvesztettem valamit egy diszk betelése miatt. És akkor még nem volt monitoring rendszer.
Az uid=0 bizony bármelyik rw-re csatolt fájlrendszert képes csurig telenyomni. Az, hogy "mit szokás", meg mi a valóság, az te is tudod, hogy nagyjából köszönőviszonyban sincs nagyon sok esetben. A vi-család az jól meg van csinálva. Az emcéedit meg nem.
Képes alatt nem azt értem, hogy lehetősége van rá (ez általában természetes), hanem azt, hogy ha a szolgáltatások rootként futnak, akkor ritka kivételtől eltekintve, ott valami gáz van a gazdával.
Ami meg nem root nevében fut, azt lehet normálisan kvótázni.
És én nem arról beszéltem, hogy mi a valóság a legtöbb helyen, hanem arról, hogy mi lenne a megoldás, hogy illene normálisan működtetni az ilyen környezeteket.
ui: félre ne érts, még csak azt sem mondom, hogy ami a kezeim közt volt rendszer, az mindenben megfelelt volna a mostani elképzeléseimnek! De a lehetőség megvan, hogy minimálisra csökkentsük az ilyen események kockázatát.
"ha a szolgáltatások rootként futnak, akkor ritka kivételtől eltekintve, ott valami gáz van a gazdával"
Tevedsz, nagyon sok olyan szolgaltatas van, aminek rootkent _kell_ futnia.
"Ami meg nem root nevében fut, azt lehet normálisan kvótázni."
Kvotazni, igen. Csak az a problema, hogy a legtobb szoftver meg arra sincs felkeszitve, hogy elfogy alatta a fajlrendszer, nemhogy arra, hogy elfogy alatta a kvota. Nem tudom peldaul egy nginx vagy egy munin mennyire orulne, ha betelne alatta egy hardkvota. Kb. magabazuhanna. Szoval nem, nem lehet a szolgaltatasokat normalisan kvotazni, hacsak nem akarsz onszantadbol teljes erobol nekiszaladni egy szivhato dolognak.
--
nginx lesz szíves syslog-ba logolni és ettől kezdve mi baja lehet a kvótákkal? (PHP-t amennyire tudom, külön futtatja)
Milyen szolgáltatás az, aminek feltétlenül root-ként kell futnia? Mondjuk annak a capability c. témának azóta sem jártam utána, de a legtöbb, amiről tudok, csak azért igényel root jogot, mert 1024 alatti portra akar ülni (meg azért, mert valaki lusta volt átkonfigurálni), azt meg meg lehetne oldani ezekkel a bigyókkal, amennyire emlékszem.
És még ezek is olyanok, hogy azért elég szépen el lehet őket szeparálni a rendszer többi részétől, hogy tényleg csak maguk alól egyék a tárhelyet.
Munin az valami monitoring cucc, nem? Ha nem riaszt időben és önmaga alól felzabálja a helyet... (szóval ez megint csak üzemeltetési gondnak tűnik)
Nginx lesz szives leszakadni a syslogrol.
Rootkent futo szolgaltatasok
- minden monitoring service (munin, snmpd, chek_mk agent, etc)
- Cluster/HA eseteben az osszes management cucc, ugyanis az IP machinaciokat meg egyebeket csak rootkent lehet elvegezni. Nem, a sudo nem megoldas.
- Samba (meg is neznem egyebkent, hogy egy sambat hogy konfiguralsz at alternativ portra)
- DHCP szerver ( -||- )
De ezek csak peldak amik 30 fokban igy eszembe jutottak. Van sok, trust me.
Az elszeparalasra: overkill. Csak azert, hogy nehogy megegyek a tarhelyet, overkill mondjuk chrootba tenni az ilyesmit (ha onerobol nem tud ilyet).
A Munin monitoring cucc, de nem a notifikalos fajtabol, hanem a grafikonozosbol. Szepen legrafikonozza neked, hogy hogyan fogyott el a tarhely.
Legyszives, tenyleg olvass mar utana dolgoknak, mielott nekiallsz ervelni. Folyamatosan azt erzem ki a mondataidbol, hogy nincs igazan komoly uzemeltetesi tapasztalatod. Engedd meg, hogy nekunk tobbieknek legyen.
--
Na itt fejezzük be szerintem, mert nagyon nem egyformán látjuk ezeket a dolgokat és lusta vagyok tételesen felsorolni, mennyire nincs igazad a legtöbb dologban.
A nagyképűsködés előtt meg szvsz te is nézz utána, miről pofázok, mert ez így... (még1x: említettem valami capability c. dolgot, amit _elméletileg_ userek számára is ki lehet osztani - monitoringból én csak BMC Patrolt használtam, emlékeim szerint saját user alatt futott az agent is, meg a központi szerver is - VMS-en biztosan, de szerintem HPUX-on, AIX-en is)
Csak egyetlen konkrét példa:
DHCP - dnsmasq root-ként indul, majd eldobálja az összes root jogot és privilegizálatlan userként működik tovább, HA megfelelően van konfigurálva.
És ez csak egy példa, amiért jobb lett volna, ha visszaveszel az arcméretedből.
Mindegy, úgy gondolom, a sz@rul megírt mentés/kilépés részt nem lehet védeni. Ha nem sikerül az adatokat mentenie egy szövegszerkesztő alkalmazásnak, akkor legyen oly kedves, és NE lépjen addig ki, amíg a felhasználót az adatvesztésről nem tájékoztatta. És ugyanez az app legyen oly okos, hogy fájl mozgatása esetén a forrásra az unlink()-et csak akkor hívja meg, ha a cél írása hiba nélkül befejeződött.
Egyébiránt elég arra gondoloni, hogy nfs-en/smb megosztáson van az a terület, ahova írni akar az alkalmazás, és az átmegy r/o állapotba. Nem kell, hogy beteljen, csak épp az írhatósága szűnjön meg, máris ott a szép adatvesztés, ha nincs vizsgálva, hogy a kiírni kívánt adatok mentése sikeresen megtörtént-e.
Védi a nyavalya... Viszont ha átmegy RO-ba a terület, akkor max. a módosításaid veszhetnek el, nem fog törlődni az eredeti fájlod.
Elvileg... Viszont ha úgy van megírva az app, hogy kiüríti az eredeti fájlt, majd utána próbálja meg beleírni az aktuális adatokat... Itt úgy néz ki, ilyesmi történhetett - de anélkül, hogy látnám az mcedit forráskódjának érintett részét, anélkül kár ezen polemizálni, a lényeg, hogy adatvesztés lehet - és ez szerintem az app hibája.
Ez humoros...
Nekem nem sikerült lenulláznom a fájlt.
Létrehoztam egy 100KB-os loop device-t, rajta ext2 fájlrendszerrel.
Odaraktam egy x.x fájlt, benne valami szeméttel.
Megnyitottam mcedit-tel, egy másik ablakból feltöltöttem a diszket 100%-ra, majd kiléptem az mceditből mentéssel és gond nélkül mentette. Megmaradtak a változások is.
upd: gondolom, akkor lett volna 0 a mentett fájl hossza, ha folyamatosan töltődik a diszk és amint felszabadul egy blokk, az azonnal felülíródik a másik processz által.
Előrebocsátom, hogy - mivel Dos Navigatoron lettem gépfüggő - kedvelem az mc-t (bár az mceditet kerülöm). Ettől függetlenül mondom, hogy a fájlokkal hanyagul bánik extrém de nem lehetetlen körülmények között... még a sajátjaival is. Betelt lemezen kilépéskor ahelyett, hogy hagyná úgy a ~/.mc/history fájlt, ahogy találta, simán leradírozza, ami nem csak esztétikai kérdés, ha az ember korábban összeszerkesztett pár pofás parancsot vagy összeszedett egy kézreálló listát a quickCD múltjában, amely elemeket Meta-H-val hoz vissza.
Oke, akkor most vesd ossze a dnsmasq meg az ISC DHCPD feature-listajat, majd gyere vissza, es mondd el, melyik alkalmas inkabb enterprise hasznalatra.
Az a szoftver, ami az otthoni routerkeben elzotyog, nem feltetlen alkalmas egy komolyabb halozat uzemeltetesere.
A monitoring kapcsan pedig epp az a problema, hogy nem ismersz tobb monitoring rendszert, van egy darab, es az alapjan osztod az eszt. Peldaul ott a monit, ami szinten monitoring eszkoz, annyi kitetellel, hogy kepes proaktivan beavatkozni, ha problemat eszlel, szervizt indit ujra, swapot kapcsolgat, mountolast indit. Ez massziv root jogok nelkul elkepzelhetetlen.
De tenyleg kar vitatkoznunk. A capabilities sem mindenhato, van amire vagy nincs capability, vagy maga az alkalmazas nem kompatibilis a capability rendszerrel, keptelen azt hasznalni.
--
http://www.friedhoff.org/posixfilecaps.html#POSIX%20Capabilities%20-%20…
Nézz itt körül!
Többek közt DHCP, Samba példák vannak benne.
Hol mondtam en azt, hogy a DHCPD vagy a Samba nem tud capabilitiest? Azt mondom, hogy _sok program nem tudja_. Ebbol sem implicite sem explicite nem kovetkezik az, hogy a Samba beletartozna ebbe a korbe.
Nezd, elhiszem, hogy igyekszel utanaolvasni a dolgoknak, de en eleg sok rendszert lattam, es volt jonehany diszk-elfogyasos esetem. Altalaban tervezesnel mindig ez a legutolso szempont, amire _barki_ figyel, mert - ahogy irtad is - a monitoring ugyis szol. Ha meg esetleg nem szol, vagy szol, de hiaba, mert nem szerzik be idoben a tarhelyboviteshez szukseges hardvert, akkor meg ott tartunk, hogy elfogyott a hely. Es igen, tudom, elbaszott egy ceg az, ahol nem szerzik be idoben a kritikus gepekbe a diszket - de van ilyen. Es ez a topic meg mindig arrol szol, hogy hogyan kell helyesen kezelni ezt az esetet, es nem arrol, hogy hogyan tervezzunk olyan rendszert, ahol ennek minimalis az eselye.
--
Kapásból hoztad ellenpéldaként a DHCP-t. Mikor mondtam, hogy ott a dnsmasq, akkor jöttél, hogy ISC. Most megmutatom, hogy az ISC-DHCP is képes nem-root userként futni, most jössz az újabb hülyeségeiddel.
Bocs, itt kiszálltam, mert amint látom, nálad a kötekedésben merül ki az üzemeltetés lényege...
Oke.
Eloszor is: koszi, hogy szoltal, hogy az ISC DHCP is tud nem-root userkent futni. Bevallom oszinten, ezt eddig nem tudtam. Ez a capabilities nekem is kisse feher folt.
Amire viszont en reagaltam, az elsosorban az, hogy azt erzem ki a szavaidbol, hogy a kvotazas mindenhato, es mindent rendeljunk ennek ala. Hogy tisztan lass: en egyetertek azzal a torekvessel, hogy lehetoleg minel kevesebb cucc fusson root jogkorokkel, viszont en ebben elsosorban az alapertelmezesek hive vagyok. Vagyis, ha egy szerviz alapertelmezesben nem-root user neveben fut (peldaul MySQL, Nginx, stb), akkor az nagyon jo dolog, de ha nekem ezert kulon kuzdenem kell, akkor haromszor is meggondolom, hogy ez mennyire eri meg, es merlegelem annak a lehetoseget is, hogy - tekintve, hogy nem ez az alapertelmezett futtatasi modja az adott szoftvernek - mivel az en use-case-m nem olyan jol tesztelt, megeri-e a jovoben elofordulo random szopasokkal foglalkozni cserebe azert, hogy "biztonsagosabb' legyen a rendszer.
Sajnos en a legtobb esetben alultervezett kornyezetbol jovok, ahol sok gepre van keves rendszergazda, igy nagyon sokszor inkabb az egyszerubb uzemeltethetoseg iranyaba szoktam menni, vagyis hogy lehetoseg szerint minel problemamentesebb kornyezetet epitsek, mert tudom, hogy nincs mindig eroforras az egyedi felepites miatt fellepo problemakkal foglalkozni. Ha az ISC DHCP default rootkent fut, akkor fusson rootkent, mert ez az alapertelmezett indulasi modja, tehat ezt a modot sokan, sokfelekeppen halalra teszteltek.
Szoval, visszaterve a kerdesre: en jo dolognak tartom az ISC DHCP POSIX Capabilities kepessegeit (huhh, szoismetles), ugyanakkor ameddig ez nem a default uzemmodja, addig en nem biztos, hogy energiat akarok fektetni abba, hogy az altalam kezelt DHCP szerverek igy uzemeljenek.
Ami a kvotazas teren felmerult bennem: tenyleg jo dolog a kvotazas - de elsosorban ott, ahol felhasznalokat kell kvotazni. Rendszerszolgaltatast nem biztos, hogy szeretnek/jo otlet kvotazni, mert a legtobb szolgaltatas egyaltalan nincs arra felkeszitve, hogy betelik alatta a diszk/kvota.
Tarts idiotanak, de en azt mondom, hogy abba, ami jol mukodik, ketszer meg kell gondolni, mielott belenyulunk. Mert persze, mas az, hogy VirtualBoxban mivel jatszadozok el, es megint mas az, hogy egy eles, produktiv kornyezetben mit lepek meg. Ott, ahol igenykent felmerul, hogy a DHCP szerver legyen minel biztonsagosabb, ott persze, erdemes merlegelni a capabilities alapu korlatozast, de ott, ahol a DHCP szerver egy fizikailag agyonvedett switch labain oszt csak cimet, _szerintem_ felesleges ebbe az iranyba elmenni.
--
Ket kulonallo dologrol beszelunk.
Te arrol beszelsz, hogy a szabad hely elfogyasat monitorozni kell. Hatalmas +1, de ez onmagaban adminisztrativ problema, es semmit nem tesz hozza a vitatott kerdeshez.
Egy editornak igenis ellenoriznie kell, hogy kepes-e menteni, ugyanis egy mar elindult mentes kozben nem tortenhet adatvesztes. Es ez nem csak a tarhely betelesre vonatkozik, hanem arra is, ha pl. menet kozben readonlyva valik a FS, vagy eppen kompletten eltunik. Es ismetlem: ez teljesen fuggetlen attol, hogy a gep monitorozva van-e vagy sem.
--
De néhány (sok) nem teszi.
Egyébként elbeszélünk egymás mellett, de mindegy. :)
Én épp azt próbálom magyarázni, hogy az ilyen események esélyét szinte jelentéktelenre lehet redukálni megfelelő tervezéssel.
Miért kell, hogy köze legyen a Mari néni dokumentumának egy web szerver által írt, potenciálisan megtelő diszkterülethez?
Ha meg a Mari néni elhasználta a kvótáját és nem tud menteni, az valahol az ő sara, de erre is lehet időben figyelmeztetni.
A magamfajta, "kösz, majd utánanézek" hozzáállású alakok meg... hát így jártál, legközelebb odafigyelsz kategória.
Egyebekben meg az mceditor, ha jól emlékszem, pont egy rossz példa volt, mert az mentés előtt készít backupot, tehát ha le is nulláz egy fájlt, az előző verzió még ott van valahol (de lehet, hogy keverem valamivel)
Irrelevans, hogy az eselyt milyen jelentektelenre lehet vagy nem lehet redukalni. A kerdes az, hogy elofordulhat-e egyaltalan, hogy egy editor adatot veszit. Nem, nem fordulhat elo (ha elofordul, szar az editor). Ha mentes+kilepest kernek, akkor nem szabad kilepnie addig, amig a user meg nem erositi, hogy vallalja az adatvesztes kockazatat.
Egyet erts meg: a figyelmeztetes egy dolog, az adatvesztes meg egy masik. Peldaul, ha teged a zebran elut egy auto, es eltorik a labad, toloszekbe kerulsz, akkor nem fogsz felallni a szekbol attol, hogy marpedig neked lett volna elsobbseged. Mert az onnantol kezdve irrelevans, ertelmetlen rola beszelni is.
--