abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
včera 16:24 | Nová verze

Byla vydána Mageia 5.1. Jedná se o první opravné vydání verze 5, jež vyšla v červnu loňského roku (zprávička). Uživatelům verze 5 nepřináší opravné vydání nic nového, samozřejmě pokud pravidelně aktualizují. Vydání obsahuje všechny aktualizace za posledního téměř půldruhého roku. Mageia 5.1 obsahuje LibreOffice 4.4.7, Linux 4.4.32, KDE4 4.14.5 nebo GNOME 3.14.3.

Ladislav Hagara | Komentářů: 4
včera 13:42 | Pozvánky

V Praze probíhá konference Internet a Technologie 16.2, volné pokračování jarní konference sdružení CZ.NIC. Konferenci lze sledovat online na YouTube. K dispozici je také archiv předchozích konferencí.

Ladislav Hagara | Komentářů: 0
2.12. 22:44 | Komunita

Joinup informuje, že Mnichov používá open source groupware Kolab. V srpnu byl dokončen dvouletý přechod na toto řešení. V provozu je asi 60 000 poštovních schránek. Nejenom Kolabu se věnoval Georg Greve ve své přednášce Open Source: the future for the European institutions (SlideShare) na konferenci DIGITEC 2016, jež proběhla v úterý 29. listopadu v Bruselu. Videozáznam přednášek z hlavního sálu je ke zhlédnutí na Livestreamu.

Ladislav Hagara | Komentářů: 22
2.12. 15:30 | Zajímavý projekt

Společnost Jolla oznámila v příspěvku Case study: Sailfish Watch na svém blogu, že naportovala Sailfish OS na chytré hodinky. Využila a inspirovala se otevřeným operačním systémem pro chytré hodinky AsteroidOS. Použita je knihovna libhybris. Ukázka ovládání hodinek na YouTube.

Ladislav Hagara | Komentářů: 8
2.12. 14:15 | Nová verze

Byla vydána verze 7.1.0 skriptovacího jazyka PHP používaného zejména k vývoji dynamických webových stránek. Jedná se o první stabilní verzi nejnovější větvě 7.1. Přehled novinek v dokumentaci. Podrobnosti v ChangeLogu. K dispozici je také příručka pro přechod z PHP 7.0.x na PHP 7.1.x.

Ladislav Hagara | Komentářů: 3
2.12. 12:55 | Nová verze

Google Chrome 55 byl prohlášen za stabilní. Nejnovější stabilní verze 55.0.2883.75 tohoto webového prohlížeče přináší řadu oprav a vylepšení (YouTube). Opraveno bylo také 36 bezpečnostních chyb. Mariusz Mlynski si například vydělal 22 500 dolarů za 3 nahlášené chyby (Universal XSS in Blink).

Ladislav Hagara | Komentářů: 4
2.12. 11:55 | Pozvánky

Máte rádi svobodný software a hardware nebo se o nich chcete něco dozvědět? Přijďte na 135. sraz spolku OpenAlt, který se bude konat ve čtvrtek 8. prosince od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Sraz bude tentokrát tématický. Bude retro! K vidění budou přístroje jako Psion 5mx nebo Palm Z22. Ze svobodného hardwaru pak Openmoko nebo čtečka WikiReader. Přijďte se i vy pochlubit svými legendami, nebo alespoň na pivo. Moderní hardware má vstup samozřejmě také povolen.

xkucf03 | Komentářů: 1
2.12. 00:10 | Nová verze

Byla vydána verze 3.2 svobodného systému pro detekci a prevenci průniků a monitorování bezpečnosti počítačových sítí Suricata. Z novinek lze zmínit například podporu protokolů DNP3 a CIP/ENIP, vylepšenou podporu TLS a samozřejmě také aktualizovanou dokumentaci.

Ladislav Hagara | Komentářů: 0
1.12. 21:00 | Nová verze

Byla vydána beta verze Linux Mintu 18.1 s kódovým jménem Serena. Na blogu Linux Mintu jsou hned dvě oznámení. První o vydání Linux Mintu s prostředím MATE a druhé o vydání Linux Mintu s prostředím Cinnamon. Stejným způsobem jsou rozděleny také poznámky k vydání (MATE, Cinnamon) a přehled novinek s náhledy (MATE, Cinnamon). Linux Mint 18.1 bude podporován až do roku 2021.

Ladislav Hagara | Komentářů: 0
1.12. 16:42 | Nová verze

Byl vydán Devuan Jessie 1.0 Beta 2. Jedná se o druhou beta verzi forku Debianu bez systemd představeného v listopadu 2014 (zprávička). První beta verze byla vydána v dubnu letošního roku (zprávička). Jedna z posledních přednášek věnovaných Devuanu proběhla v listopadu na konferenci FSCONS 2016 (YouTube, pdf).

Ladislav Hagara | Komentářů: 2
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (7%)
 (5%)
 (3%)
Celkem 770 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

Dotaz: Kritický problém: masový útok zombie

17.11.2008 14:26 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
Kritický problém: masový útok zombie
Přečteno: 1201×

Prosím o radu s následujícím (kritickým) problémem. Předem se omlouvám za dlouhý zápis.

Po určité době běhu systému se na mém stroji objeví velký počet zombie pocházejících z mailového serveru Courier-MTA. Nelze je zabít. Obvyklá fráze, že stačí zabít jejich rodiče, zde selhává, neboť jejich rodičem už je init. Tento problém už pozorovalo víc lidí.

Potíž je v tom, že server po jakési události, o které prakticky nic nevím, ještě klidně i dvanáct hodin zdánlivě běží dál, než se objeví první příznaky. Prvním příznakem je (pochopitelně) nefunkčnost mailového serveru. Ale celých těch dvanáct hodin už prakticky nefunguje souborový systém ani zápis na disky. (!!!)

Přibliže deset hodin před prvním selháním se úplně přestane logovat a celých uplynulých dvanáct hodin logů, které zatím ještě lze přečíst, se nachází pouze v cache. Po (nezbytném) násilném restartu chybí samozřejmě nejen logy, ale obecně všechny změny provedené na souborovém systému.

Systém se nakonec dostane do stavu, kdy nefunguje Magic SysRq a příkaz sync zůstane navždy viset. Pokus o spuštění prakticky jakéhokoliv dalšího procesu opět časem skončí zatuhnutím procesu v podobě zombie, včetně reboot nebo vi. (Tedy není žádná možnost, jak server ohleduplně restartovat.)

V dmesg není absolutně žádná zpráva o problémech. Jen poslední dochovaná hláška kernelu je podezřelá. (Clocksource tsc unstable (delta = 4686980179 ns)) Celý tento problém jsem viděl už dvakrát. O záhadné události samotné se nedochová žádný záznam. Poslední záznam z uložených logů pochází ze včerejška cca z 02:00 a mail server vypověděl službu až dnes kolem poledne.

Jistě se mě někdo zeptá: Zapsal jsi tohle do kernelové bugzilly? Ne, nezapsal. Ten kernel je tainted. Server slouží (mimo jiné) jako WiFi AP a používá chipset Atheros. Je všeobecně známo, že MadWiFi SUCKS. A to až tak, že přibližně jednou týdně způsobí jen tak pro zábavu kernel panic. Jenže v tomto případě kernel panic nenastal... Takže se nabízí několik možností:

  • MadWiFi kropí paměť tak usilovně, že spousta vláken nakonec uvízne v kernel mode na nějakém zámku, ať už se to týká sítě nebo souborového systému. Problém se neodhalí včas, nenastane kernel panic a průšvih je na světě.

  • V kernelu je bug. S minulými verzemi se tohle nikdy nestalo. Nicméně nemám šanci to prověřit, protože bez toho odporného binárního modulu by server neposkytoval WiFi. Nemůžu WiFi prostě na měsíc odpojit a čekat, zda se ta chyba stane i bez MadWiFi...

  • Selhává hardware. Jeden z disků něco nemohl zapsat, nastala chyba při komunikaci s řadičem a podobně. Ale proč o tom nic nebylo v dmesg ani na konzoli? Nebyla tam ani jediná řádka, kterou by vypsal ext3, ovladač SCSI řadiče nebo podobný chytrák...

  • Jde o důsledek vzdáleného útoku. (O čemž pochybuji, protože mám ten stroj přece jen solidně zabezpečený a navíc nespravuje choulostivá data, která by mohla posloužit k ukradení závratné sumy peněz...)

Tak to je celé. Tohle je zlý sen každého administrátora. I když jde jen o domácí server, člověka to připraví o klidný spánek. Čím to může být? Máte někdo podobnou zkušenost?

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ

Odpovědi

17.11.2008 15:10 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Kritický problém: masový útok zombie
Tohle je typický projev případu, kdy chybové e-maily se mají doručit na adresu, kterou má obsluhovat váš server, ale neumí to. Tj. dorazí první mail, který vygeneruje chybovou zprávu. Tu se váš počítač pokusí doručit, a to sám sobě – jenže adresát neexistuje, což vygeneruje další chybovou zprávu. Tu se počítač opět pokusí doručit – a tak dále. Zpestřit je to možné ještě tím, že se v chybové odpovědi cituje celý původní e-mail, to ta chybová zpráva pak ještě navíc neustále narůstá.

Řešením (pokud je to tento případ) je nakonfigurovat mailserver tak, aby uměl doručit chybové zprávy (a odpovědi na ně), které sám vygeneruje. Tedy buď jako odesílatele a adresáta chybových zpráv použít nějaký existující účet, nebo k nastavenému odesílateli a příjemci chybových zpráv odpovídající účet (a případně i DNS záznam) vytvořit.
17.11.2008 15:36 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Kritický problém: masový útok zombie
Tohle je typický projev případu, kdy chybové e-maily se mají doručit na adresu, kterou má obsluhovat váš server, ale neumí to.

Ne, tohle nebude ten případ. Myslím, že nastavení bounces mám v pořádku. Courier-MTA i v defaultním nastavení takovéhle cyklení zvládá korektně, pokud vím. Kromě toho, v takovém případě by těch procesů bylo závratně mnoho. Nic takového se ovšem nestalo. Nedošla paměť a zatuhlých procesů kolem mail serveru bylo cca patnáct. Všechny ve stavu defunct s rodičem init.

Taky se nabízí otázka, proč se to v deseti měsících před instalací slavného chipsetu Atheros nikdy nestalo, zatímco od instalace té karty ten průser vidím podruhé.

Jak by to dopadlo, kdyby se opravdu jednalo o případ, který popisujete? Podle mě by to znamenalo velké vytížení CPU, spuštění obrovské haldy procesů a zaplnění swapu. No a mohlo by to skončit zabitím jednoho z nich kvůli nedostatku paměti, čímž by se rekurze na chvíli přerušila. (Asi jen do doby, než se nižší patro rekurze pokusí znovu o odeslání.) Jenže na mém serveru bylo vytížení CPU nulové, procesy se vůbec nemnožily a prakticky každý nově spuštěný proces (kromě těch velmi triviálních, které nic nedělají se sítí a s diskem) skončil také ve stavu nesmrtelné zombie.

Myslíte, že by se i přesto mohlo jednat o vámi popisovaný problém? Nechce se mi věřit, že by obyčejný mail server mohl takhle odvařit celý systém a způsobit, že se 12 hodin nic neloguje ani neukládá cache souborového systému...

Existuje možnost, jak bych mohl popsanou mailovou apokalypsu sám vyvolat? Stačilo by poslat nějaký vadný mail na lokální adresu? (Takové věci dělávám denně (ne já osobně, ale Cron ano) a žádná hrůza se nekoná...)

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
17.11.2008 15:41 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Kritický problém: masový útok zombie

Chybové zprávy nemají mít vyplněného odesílatele, a pak se samozřejmě chybová zpráva na chybovou zprávu ani nevytvoří.

18.11.2008 07:54 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Kritický problém: masový útok zombie
Napsal jsem to špatně, nešlo o odpověď na nedoručitelný e-mail, ale o upozornění správce na chybu (v Postfixu notify_classes a spol.).
17.11.2008 16:26 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Kritický problém: masový útok zombie

Mimochodem, existuje spousta podivných důvodů, proč init nesežere zombie, které zdědí. Například na stránce, na kterou jsem už jednou odkazoval, se lze dočíst:

We’ve recently found that having software flow on the system console after getting an XOFF can cause the system console’s buffer to fill up, giving init task constipation, and therefore all tasks that were created by init task will become zombies when they exit. Further, it appears that system console (in this case on a serial port /dev/ttyS0) has software flow is enabled by default, and is re-enabled periodically (each time character is output?).

To by vysvětlovalo, proč nefungoval shutdown ani reboot. Nicméně otázka je, zda by zablokování procesu init opravdu způsobilo takovou katastrofu, jakou jsem viděl já. Je naprosto jasné, že by pak každý démon zatuhl v režimu zombie. Každý mi ale tvrdí, že zombie je proces, který už uvolnil všechny prostředky. Je možné, že by tyto zombie, které init nestačí konzumovat, zablokovaly celý systém?

Připusťme, že by zombie (čistě hypoteticky) nadále držely nějaké prostředky, zejména pokud jde o síť. Pak by mail server samozřejmě dřív nebo později přestal přijímat spojení, protože by nikdo neuvolnil ta stará. Počet zpráv čekajících na zápis do logu taky není neomezený a když někdo poničí zamykání sítě, asi by se mohlo stát, že syslog-ng už nic nepřijímá a tím zablokuje prakticky všechny další démony, i takové, kterých se to zdánlivě vůbec netýká.

Rozdíl oproti popisované situaci je v tom, že nepoužívám žádnou sériovou konzoli. Takže co by mohlo zablokovat init? Pokud se to stane, jak na to přijdu? A jak je možné, že SSH normálně funguje? Pracuje přece taky se sítí.

Může tohle být způsobeno pokropením paměti, které nešťastnou náhodou nevyvolá panic a zanechá systém v poškozeném stavu? Hrůza pomyslet!

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
Bluebear avatar 17.11.2008 16:51 Bluebear | skóre: 30 | blog: Bluebearův samožerblog | Praha
Rozbalit Rozbalit vše Re: Kritický problém: masový útok zombie
Je možné, že by tyto zombie, které init nestačí konzumovat, zablokovaly celý systém?

Za nešťastných okolností asi ano. Přinejmenším zaplácnutím všech volných PIDů.
To mi připomíná, jak jsem si pořídil květináč, že v něm budu mít květinu. Opravdu tam byla, ale potom být přestala...
17.11.2008 16:57 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Kritický problém: masový útok zombie

Těch zombie bylo cca 15. PIDů je sice jenom 65534 (protože 0 nemá nikdo, 1 má init a 32-bitové PIDy nemám zapnuté), ale to je přece jen pořád ještě dost. Server má jenom 1,5 GB paměti a podle mě by vůbec neustál tolik zombie, aby zaplnily všechny PIDy.

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
Bluebear avatar 17.11.2008 16:53 Bluebear | skóre: 30 | blog: Bluebearův samožerblog | Praha
Rozbalit Rozbalit vše Re: Kritický problém: masový útok zombie
Nájezd zombií tohoto typu jsem kdysi viděl na jednom z našich serverů - ukázalo se, že se tímto způsobem s námi loučil disk. :-(

Doporučuji neprodleně vše zazálohovat (ale to už jsi určitě udělal).
To mi připomíná, jak jsem si pořídil květináč, že v něm budu mít květinu. Opravdu tam byla, ale potom být přestala...
17.11.2008 17:08 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Kritický problém: masový útok zombie

No, kéž by... To jsem sice udělal minulý týden, ale od té doby je DVD vypalovačka v opravě.

Bylo to loučení aspoň nějak vidět ve SMARTu? Zrovna předevčírem mi někdo tvrdil, že SMART je k ničemu a nedokáže předpovědět nic.

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
AraxoN avatar 17.11.2008 19:08 AraxoN | skóre: 45 | blog: slon_v_porcelane | Košice
Rozbalit Rozbalit vše Re: Kritický problém: masový útok zombie

Tiež by som to videl na disk. Niekde na disku je kritické miesto, ktorého čítaním (či zápisom) sa celé I/O na daný fyzický disk zablokuje a od tej chvíle sa už nezapíše ani čiarka. Systém potom ešte chvíľku funguje, lebo väčšinu potrebných vecí vie naťahať z diskovej cache, ale ako sa postupne buffre plnia požiadavkami na zápis, ktoré nikto nevybavuje, tak sa cache uvoľňuje a nakoniec sa už nedá spustiť ani len "ls", lebo aj ten sa z cache vyhodil v prospech narastajúcej I/O fronty. Čím väčšia pamäť, tým väčší problém, lebo tým dlhšie trvá, kým sa to definitívne sekne a tým viac sa stratí neuložených údajov.

Prešiel by som disk dd-čkom, či sa ho podarí celý prečítať, a ak nepodarí, tak potom už len pripojiť monitor a pokochať sa nejakou obskurnou chybovou hláškou, ktorá tam asi bude svietiť.

A k tomu SMART-u - podľa wikipedie dokáže predikovať zlyhanie disku asi v 30% všetkých prípadov. Iste, bolo by fajn, ak by to bolo viac. Je to ale dôvod na úplne zavrhnutie SMART-u?

A fine is a tax for doing wrong. A tax is a fine for doing well.
17.11.2008 19:30 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Kritický problém: masový útok zombie

SMART long selftest nehlásí žádné chyby. (Nevím, jak přesně si mám tento výsledek vykládat, ale je to tak.)

S diskem je potíž v tom, že tam jsou dva SCSI disky a na nich LVM striping. Selhání jednoho samozřejmě pošle všechno do kytek.

Selhání disku a růst cache jsem zažil už cca třikrát, ale vždy to bylo zaprvé na IDE, zadruhé na obyčejném desktopu a zatřetí bez LVM. Pokaždé to bylo provázeno extrémně bouřlivými výpisy v logu. Byly tam zápisy od ext3, že vypršel timeout. Spousta I/O errorů. Zprávy o tom, že řadič XYZ selhal nebo mu přetekla cache a podobně.

Ale tady nevidím nic. Ani v dmesg, ani nikde jinde. Kontroluju to pravidelně. Za celý rok provozu jsem nikde takovou hlášku neviděl. Je třeba možné, že LVM2 tyhle hlášky nějak filtruje? To se mi vůbec nezdá, protože když z disku prostě něco nejde přečíst, musí tam být nějaký timeout a hláška, že se to nepodařilo.

Mám snad zkusit zapnout v LVM2 nějaké debuggovací hlášky? Dají se takové hlášky zapnout za provozu? Kdybych věděl, že disk selhává, hned bych šel na eBay koupit jiný. Takhle vím prd. Předpokládám, že pomocí dd můžu jeden z těch dvou disků celý zkopírovat (bude-li navlas stejný a půjde-li originál ještě přečíst) a LVM oddíly se tím zachrání.

Právě teď jsem přenesl pár GB dat přes 1 Mbit/s, abych měl všechno zazálohované. Ach jo, toto je opravdu k vzteku.

Opravdu může LVM i ovladač od řadiče v případě chyby jenom čekat a neříct vůbec nic?

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
17.11.2008 19:57 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Kritický problém: masový útok zombie

Co tam máte za jádro? Některá 2.6.27.y revize opravovovala chybu v device-mapperu.

Řekl bych, že device mapper umí propagovat chyby (dokonce pro to existuje simulátor chybujícího blokového zařízení), navíc ta chyba by se stala na fyzickém blokovém zařízení a tak byste dostal hlášení od ATA rozhraní.

17.11.2008 21:30 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Kritický problém: masový útok zombie

2.6.27.6 Nicméně tentýž problém jsem viděl před týdnem s 2.6.27.4. Aktualizoval jsem kernel právě proto, že jsem měl podezření na takovou chybu, nicméně kýžené zlepšení to nepřineslo, jak je vidět.

Dostal bych hlášení od SCSI, nikoliv od ATA. Právě v tom může být problém. Průšvihů s ATA rozhraním jsem viděl hodně a vždycky se přesně hlásily. Třeba vypršel timeout na DMA a podobně. Nicméně netuším, jak je to u SCSI a jestli třeba nemusím někde explicitně zapnout nějaký debugging.

Nechce se mi ani trochu věřit, že by celý systém čekal dvanáct hodin na SCSI disk a neřekl nic.

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
18.11.2008 00:00 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Kritický problém: masový útok zombie

Já mám SCSI CD mechaniku a ta když čte poškrábaný disk, tak u toho jádro docela nadává. Je pravda, že chybová SCSI hlášení jsou docela kryptická, ale aspoň se dá poznat, že se něco děje.

17.11.2008 19:40 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Kritický problém: masový útok zombie

Ještě dotaz k tomu dd: Můžu tím příkazem číst disk, na kterém jsou zrovna namountované filesystémy?

Otázka je, co se stane, když jeden ze dvou disků v rámci LVM volume group začnu takto intenzivně číst. Nerad bych, aby mi to sestřelilo filesystémy, třeba kvůli nějakému timeoutu a podobně...

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
17.11.2008 21:41 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Kritický problém: masový útok zombie

Odpovím si sám. Dodal jsem si odvahy tuplákem výtečného ležáku a zkusil jsem to.

Celý příkaz se prostě provedl bez chybové hlášky. Hláška není ani v dmesg, ani jinde v logu. Zombie zatím nevidím. Rychost byla nějakých 50 MB/s, bez větších výkyvů. Každých 5 vteřin jsem posílal SIGUSR1, abych viděl statistiky.

Z toho (asi) vyplývá, že oba disky lze přečíst. O možnosti zápisu tento pokus samozřejmě neříká vůbec nic.

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
Bluebear avatar 17.11.2008 16:55 Bluebear | skóre: 30 | blog: Bluebearův samožerblog | Praha
Rozbalit Rozbalit vše Re: Kritický problém: masový útok zombie
Clocksource tsc unstable (delta = 4686980179 ns)

Myslím, že v tom to nebude; IMO to jen znamená, že TSC nedrží přesně čas; to by neměl být zvláštní problém.
To mi připomíná, jak jsem si pořídil květináč, že v něm budu mít květinu. Opravdu tam byla, ale potom být přestala...
17.11.2008 17:03 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Kritický problém: masový útok zombie

Taky si říkám. Na notebooku, který mění dynamicky frekvenci, mám tuhle hlášku pořád a žádný problém to není. Jen jsem to tam napsal pro úplnost, protože to byla poslední hláška kernelu, která se objevila v dmesg před tím nekonzistentním stavem, kdy většina démonů ještě sloužila svému účelu, ale nic se nelogovalo ani nepsalo na disk.

Můj notebook teď mívá mnohem delší uptime než můj server. To je poněkud k pláči. Vzpomínám na časy, kdy jsem jenom po každých sto dnech uptime aktualizoval software a vyměnil kernel a stabilita byla samozřejmost. Ještě před pár měsíci tohle byla realita.

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
17.11.2008 21:01 linuxik | skóre: 32 | Milovice
Rozbalit Rozbalit vše Re: Kritický problém: masový útok zombie
Ahoj,

skoro urcite to bude HW problem. Chyba disku, spatny kabel (i to se stava) nebo problem v komunikaci mezi scsi radicem a modulem v jadre. Zkus se podivat jestli neexistuje novy bios pro scsi radic. Uz jsem takhle parkrat narazil a vetsinou se to projevuje presne tak jak popisujes. V logu nic nenajdes, protoze kdyz nastane problem tak uz to neni kam zapsat ;-).

ps. Mit wifi na serveru je docela uchylarna, zvlast kdyz vis ze jsou s nim problemy, ale disky ve stripu pod LVM a bez zalohavani to je na zastreleni.
17.11.2008 21:20 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Kritický problém: masový útok zombie

No, s kabelem nic nenadělám. Je tam backplane a dva hotswap bay. Mohl bych zkusit oba disky vytáhnout a zastrčit zpátky, ale pouhý špatný kontakt to asi nebude. To by určitě odletělo rychleji.

BIOS pro SCSI řadič se flashuje společně s „hlavním“ BIOSem, protože je to on-board řadič. Je to IBM xSeries 335. Je tam nejovější BIOS od IBM a novější už asi vydaný nebude.

Oba disky mají nejnovější firmware, ten jsem samozřejmě aktualizoval.

Jasně, že v logu nic nenajdu. Ale proč to nevidím ani v dmesg? Tento výpis určitě nečte log z disku. Čte prostě nějaký buffer, který tam kernel má a který občas flushne do kernel.log. Takže bych v dmesg čekal vřískot, kdyby nějak fatálně selhal disk. U všech disků, které jsem viděl selhat, tam vřískot byl. A jaký! Vůbec nevadilo, že to není kam zapsat...

I když, co vůbec kernel udělá, když ten buffer nemá jak zapsat do logu? Zahazuje starší zprávy, nebo se to celé zablokuje? Možná, že u těch selhání, která jsem viděl, nebyl zápis zcela zablokovaný. Těžko říct.

Jestli je DVD vypalovačka dostatečné zálohování, pak to na zastřelení snad nebude, ne? Jenže shodou okolností se vypalovačka minulý týden porouchala a musel jsem ji poslat na reklamaci. A co čert nechtěl, je to zrovna v době, kdy nepříjemně často vidím takovéhle průšvihy. Murphyho zákony fungují krásně.

U domácího serveru, který je spíš „na hraní“, se problém striping versus mirroring rozhoduje velmi snadno. A to tak, že pouhých 36 GB mi nestačí... S tím WiFi je to nepříjemné. Od Atherosu jsem čekal kdovíco, protože ho všichni vychvalují. Teď už vím, že to byla hloupost, a mám jasno v tom, že MadWiFi sucks. Kdyby existoval chipset, pro který je open-source driver a zároveň podpora pro hostapd, Atheros by okamžitě letěl z okna. Jenže takový chipset už není. Prism/Intersil už se nikde nesežene a tím nabídka končí.

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
17.11.2008 21:49 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Kritický problém: masový útok zombie
I když, co vůbec kernel udělá, když ten buffer nemá jak zapsat do logu?

V jádře je kruhový buffer. Takže nevybrané zprávy se budou od konce přepisovat. Vybírání má na starost uživatelský prostor (obvykle syslog démon).

Suma sumárum jádru je (ne)vybírání systémového logu ukradené.

17.11.2008 23:19 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Kritický problém: masový útok zombie

Tak potom vůbec nechápu, proč ten buffer ukazoval pořád totéž, od úplně první bootovací hlášky až po zprávu TSC unstable, která v době prvního selhání byla dvanáct hodin stará.

Kdykoliv jsem zažil selhání disku, v dmesg nebylo nic jiného než šílené kvantum DMA timeoutů, I/O errorů a kdovíčeho ještě. Tady nebylo nic.

Možná jsem měl zkusit něco, co zaručeně vyvolá zápis do dmesg. Třeba příkaz sysctl, který používá jakési deprecated vlastnosti. Pak bych viděl, jestli je ten buffer pro dmesg přístupný, nebo zda je úplně se vším konec.

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
17.11.2008 23:57 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Kritický problém: masový útok zombie

Špatně jsem to napsal.

Ten kruhový buffer se nevyprazdňuje. Proto příkaz dmesg vždy vypíše několik posledních hlášek (prostě vypíše obsah bufferu). Ačkoliv pomocí dmesg -c lze buffer vyprázdnit.

Syslog čte nové hlášky z /proc/kmsg. Jak tam to je s bufferováním, nevím.

Možná jsem měl zkusit něco, co zaručeně vyvolá zápis do dmesg.

SysRq s nenaváznou klávesou vypisuje nápovědu. A mimo jiné se tam logují všechny SysRq požadavky včetně jejich výstupů (např. SysRq : Emergency Sync).

17.11.2008 21:02 dfsfsfs
Rozbalit Rozbalit vše Re: Kritický problém: masový útok zombie
Myslím, že je to komunikací s diskem.

Obvykle se to pozná tak, že se pečlivě prohlidnou atributy processů přes ps a pokud je v nepřerušitelným I/O waitu je to obvykle právě důsledek toho, že nelze komunikovat s diskem.
17.11.2008 21:26 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Kritický problém: masový útok zombie

To je docela dobře možné. Nicméně mezi zombie jsou prakticky výhradně procesy, které komunikují po síti. Čtení z disků fungovalo normálně. Zápis zdánlivě také, ale žádné změny se už nezachovaly.

Čekal bych, že při selhání zápisu se okamžitě napíše hláška do dmesg a že tam ta hláška samozřejmě bude i poté, kdy už se nedá nic nikam psát. Já jsem tam ovšem žádnou chybovou hlášku neviděl.

Taky je možné, že tam ten šílený MadWifi (jak příhodný název) něco pokropí a poničí zamykací struktury kolem sítě tak, že to zablokuje úplně všechno. Koneckonců, i logování je víceméně síťová záležitost. Sice je to UNIXový socket, ale přece...

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
Bluebear avatar 22.11.2008 02:13 Bluebear | skóre: 30 | blog: Bluebearův samožerblog | Praha
Rozbalit Rozbalit vše Re: Kritický problém: masový útok zombie
Pokusil jsem se predstavit si, jak bych se snazil neco takoveho resit, a dospel jsem k tomuto - prosim posud sam, jestli neco z toho je v tvem pripade aplikovatelne:

1) pustit na masine test pameti (samozrejme bez OS a beze vseho, jen memcheck) a nechat ho bezet pres noc

2) zkompilovat vlastni kernel se zapnutymi testy a debugovacimi hlaskami a sledovat, zda a kde to hnije

3) (akt cireho zoufalstvi) preinstalovat cely system docista docista

4) kdyz selze vsechno ostatni, tak holt zkusit vymenit casti hardwaru, kde mi srdce rika, ze by mohl byt problem (ale bohuzel je to financne narocne a hrozi efekt "proklete bedny" - nakonec vymenis uplne vsechno vcetne casu a bude to furt delat to same)
To mi připomíná, jak jsem si pořídil květináč, že v něm budu mít květinu. Opravdu tam byla, ale potom být přestala...
22.11.2008 15:16 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Kritický problém: masový útok zombie

Podezřelé je, že teď už mám pět dní uptime a nic zlého to (zatím) nedělá. Takže buď ta chyba nastává v různých intervalech s velkým rozptylem, nebo to má celé jiný důvod. Kromě bodu 3, který nikdy změnu k lepšímu nepřináší, jsem pomýšlel víceméně na všechny ostatní možnosti. Kernel tam mám vlastní, ale žádné extra debuggovací hlášky zapnuté nemám. Předpokládám, že kdyby šlo o chybu disku, muselo by se to hlásit přinejmenším v dmesg. Proto možnost chyby disku v podstatě vylučuji, zejména poté, co se mi podařilo oba disky na běžícím systému přečíst pomocí dd, a to bez jakýchkoliv chybových hlášení nebo jiných následků.

Celkem vzato, zbývají jen dvě možnosti. První možost je, že driver Atheros postupně kropí paměť a je jenom otázkou času, kdy pokropí něco důležitého. V lepším případě vyvolá kernel panic, v horším připadě provede něco, co se nedá detekovat, a vyvolá podivný deadlock v celém síťovém stacku.

Otázka dne: K čemu je mi memtest, když mám moduly typu ECC REG SYNC? Nevypisuje náhodou kernel selhání ECC taktéž do dmesg? Vsadil bych se, že ano. Nicméně žádnou hlášku o selhání ECC jsem tam neviděl.

Ať už je to jakkoliv, není to žádný med. Člověk kvůli tomu nemá klidné spaní. Server je ode mě vzdušnou čarou 255 km. I několikrát denně tam nasísám, jestli se loguje, jestli se nezasekne příkaz sync, jestli tam už zase nejsou mrtvá vlákna... Prostě už to není ten starý dobrý server, který jsem zapnul a nechal 100 dní běžet. :-( A prože DVD vypalovačka je pořád ještě v reklamaci, každý den přenáším inkrementální zálohy až sem na svůj notebook. Bééé, fňuk.

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
17.11.2008 21:58 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše SysRq
Systém se nakonec dostane do stavu, kdy nefunguje Magic SysRq

Konkrétně nefungoval který požadavek? Ani SysRq-B? Pak bych opravdu viděl chybu v rozbitých jaderných strukturách (ať už softwarově nebo hardwarově).

Pokud reboot funguje, ještě by šlo přes předpřipravený kexec rebootovat do záchranného systému, dumpnout rozbité jádro a zapitvat si.

17.11.2008 23:15 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: SysRq

Zkoušel jsem samozřejmě postupně celý busier pozpátku, jak se to má dělat. Bohužel u e jsem skončil definitivně a pak už nefungovalo ani b. Nemám tušení, jestli by b fungovalo, kdybych ho použil jako první.

Jedno vím jistě: Až ten problém uvidím příště, nebudu zkoušet vůbec nic, dokonce ani u, a skončím rovnou u b... Stejně už se nedá nic zachránit. Procesy stejně zůstanou jako zombie a nemůžou už nic zapisovat. Co je horší, samotný příkaz sync zůstával viset nekonečně. Bez jakékoliv chybové hlášky...

Pitvání jsem zažil jenom na Solarisu, v kurzu, který trval jen pět dní a zabýval se jen platformou AMD64 a debuggerem mdb. Nevím, jestli bych si s Linuxem poradil a něco smysluplného našel.

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
17.11.2008 22:02 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Kritický problém: masový útok zombie
S minulými verzemi se tohle nikdy nestalo.

Jsou lidi, co mají na 2.6.27 problémy s hostap. A to je přitom v Linusově stromu. Takže bych se nedivil, kdyby madwifi mělo problémy taky. (Z tohoto důvodu na svém serveru mám stále 2.6.26.)

17.11.2008 23:07 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Kritický problém: masový útok zombie

No, záleží na tom, o jaké problémy se jedná. Samozřejmě se ví, že stanice s Windows se neustále odpojují a znovu asociují bez zjevné příčiny. Ale to je v podstatě pouze detail.

Pokud jde o potíže v kernelu, za ty hostapd nemůže. Za ty může binární HAL, jeden (trunk) horší než druhý (branches/madwifi-hal-testing). Nebo se paměť nekropí přímo v tom HALu, ale někde v open-source části toho ovladače? Těžko říct. Ten ovladač se už roky nějak bastlí a nikam to nevede.

S kernelem 2.6.26 byla u mě situace extrémně špatná a vždy po několika desítkách minut provozu se úplně zastavil IPv6. Nechápu, proč IPv6 nefungoval a IPv4 ano. WiFi s tím přece nemá nic společného, je to jiná vrstva... No nicméně bylo to tak. Upgrade na 2.6.27 tyto problémy ukončil, ale přinesl jiné, jak je vidět.

A mimochodem, i dnes je v MadWiFi jeden zaručený kernel panic: Stačí dvakrát po sobě změnit frekvenci přes iwconfig v době, kdy běží hostapd. Pak už to udělá jenom hoplá...

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
17.11.2008 23:28 artec | skóre: 24
Rozbalit Rozbalit vše Re: Kritický problém: masový útok zombie
Pak už to udělá jenom hoplá...
OpenSource no :).

Nejnovejsi nemusi byt vzdy nejlepsi (nejstabilnejsi). U madwifi "stabilni" verze neexistuje a uz asi ani existovat nebude. U hostapd je to celkem v pohode. Co takhle vyzkouset misto supernovinek 2.6.26-28 kernel 2.6.22-24? Jestli neni opravdu problem v hw, tak bych asi zacal laborovat timto smerem.
17.11.2008 23:39 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Kritický problém: masový útok zombie

Mluvím o ovladači hostap pro Intersil Prism karty. Nikoliv o hostapd démonovi pro WPA2/Radius atentizaci.

Můj problém je, že kdykoliv se jádro pokusí odeslat rámec, tak v logu přibude hláška „invalid skb->cb magic“. Ale to je jiná kapitola.

10.12.2008 23:01 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Jak to celé nakonec dopadlo

Vzhledem k tomu, že všechno už vypadá normálně, rád bych tuto ošklivou kapitolu uzavřel a poděkoval všem diskutujícím za cenné postřehy.

[andrej@charon ~]$ uptime
 22:42:47 up 14 days,  8:30,  1 user,  load average: 0.00, 0.00, 0.00

Pokud někoho zajímá, v čem byl problém, je to vcelku jednoduché. Stačilo dát modul pro WiFi kartu na blacklist a byl rázem klid. WiFi teď zajišťuje oddělený access point a můj server funguje „pouze“ jako RADIUS. Access point je v režimu bridge. Tím pádem mám všechno, co jsem chtěl. Zaprvé, WPA2-EAP-TLS. Zadruhé, IPv6 v celé LAN. Zatřetí, stabilitu.

Až vám někdy někdo řekne „ono to má sice binární ovladač, ale funguje to dobře“, vyhoďte ho oknem ven a ten hardware mu hoďte na hlavu! Cokoliv jiného uděláte, povede to jen k potížím, které za to nestojí.

Upřímně řečeno, ještě dnes mívám špatné sny o serveru plném zombie. :-D Dokud nedosáhnu těch standardních 100 dní uptime, pořád budu mít tak trochu nejistotu.

Neodpustím si na závěr jednu zajímavost. Chtěl jsem odchytit nějaký kernel panic, který způsoboval ten Atheros, abych to mohl pořádně nahlásit. Jal jsem se tedy instalovat netconsole. Těsně před instalací netconsole nastal panic dvakrát po sobě během půl hodiny. Jakmile jsem ovšem netconsole zprovoznil, nedělo se nic... Po dvanácti hodinách běhu server totálně zatuhl. Panic to nebyl, protože ten by vyvolal restart. Nedochovala se o tom ani jedna zpráva v logu. Tedy jsem natvrdo restartoval server (!) a čekal dál... Po dalším dni se stalo totéž. Zatuhnutí, žádný panic, žádná zpráva v netconsole. (!!!) No nepřipomíná vám to Heisenbergovy relace neurčitosti? :-D Každopádně tohle byla poslední kapka. To binární svinstvo šlo ihned pryč, pro jistotu jsem důkladně zkontroloval všechny souborové systémy, přebootoval a hotovo. Od té doby server běží normálně.

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
11.12.2008 07:30 JB
Rozbalit Rozbalit vše Re: Jak to celé nakonec dopadlo

Snad jen pro doplneni pro ostatni. Podobne problemy jsem pozoroval s modulem

rt61pci a kartou '05:09.0 Network controller: RaLink RT2561/RT61 rev B 802.11g" v jadrech Fedory 9 a nize.

V techto distrech je resenim pouzivat legacy modul rt61, ktery vychazi z proprietary kodu.

 

Z toho vypada, ze FS moduly jadra (popripade samotny navrh FS jadra) maji problem se spatne se chovajicim se wireless subsystemem.

Hmm a protoze o tom vim prd, tak to dal rozebirat nebudu.

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.