No dobre, tak jeste teda nejdu spat, tak se trochu rozepisu a vysvetlim, o co jde: - kazdej kontejner je slozka na FS - coz znamena, ze abych mohl limitovat diskspace kontejneru, musel bych mit FS per kontejner, coz trochu drti nektery vyhody kontejneru (napr. agregace mista pri shared FS se proste neda udelat elegantneji) V OpenVZ to vyresili tak, ze mezi ext*fs/xfs a "simfs" (simulovany fs kontejneru) vlozili vzquotu, coz je neco jako tabulka mapovani muj inode -> node na FS + accounting infromace o velikosti. Diky tomu pak i funguje second-level quota (tzn. normalni linuxova user/group quota) - coz je neco, co budeme muset do ZFS doimplementovat. Nevyhoda vzquoty se pozna pri resetu systemu, kdyz nema cas si syncnout ten mapujici soubor na disk. Pak musi vzquota pri startu kazdyho kontejneru projit jeho soubory a znova je namapovat. To je prave to, co ti muze rozhazet cisla inodu. Bootovani serveru s vzquotou po resetu je pak tragedie a masina s 90 VPS muze naskakovat klidne 3-4 hodiny. Krom toho je vzquota nachylna na random rozbijeni se i pres tu kontrolu integrity, da se rozbit ze ukazuje min/vic zabranyho mista/inodes, akorat nevim, jak k tomu dochazi (co je trigger toho rozbiti), deje se to jenom zridkakdy. Also, ukazalo se ze mit vic kontejneru na EXT4 je totalni blbost, v ext4 je nejfatalnejsi problem journal. Stane se bottleneckem celyho toho FS a proste neda se nic. Obzvlast, kdyz nad tim FS bezi par databazi. Iowait leti nahoru, disky seekujou jak pomateny a propustnost filesystemu jde do kytek. Oproti tomu node se ZFS ma tech 90 VPS nastartovanych do tak 10ti minut jako absolutni maximum. A tech MySQL muze na serveru bezet, co zvlada CPU, protoze na synchronnni zapisy a fuckup unixovyho sveta jmenem sync() ma ZFS mechanismus jmenem Intent Log a moznost ho vysoupnout na dedikovany device. Oproti tomu ext4 ani s dedikovanym journalem na SSD nedela temer zadny rozdil. Pak uz disky tolik neseekujou, ale vykon porad nikde. Btw tahle "vlastnost" ext4ky donutila OpenVZ lidi implementovat ploop, takze pak delaji ext4 in a file per container. So much win! :)

Urcite budem dal pracovat na ZFS podpore, linuxovy filesystemy jsou jedna velka tragedie. Navic se diky tomu muzem zbavit ty tragedie vzquoty. /snajpa On 03/15/2014 10:55 PM, Pavel Snajdr wrote: _______________________________________________ Community-list mailing list Community-list(a)lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlMk0JMACgkQMBKdi9lkZ6qNPQD/fxDxVjrsR3lFonApxuZEOXhx Co0tXW/gidlA9v1oQcwA/2B8IDSJeW0T+2IMD+hVMa9o4cIMVmNZVT0PBa8N0GfE =SmMB -----END PGP SIGNATURE-----

Je nejaka cesta, jak tu vzquotu nepouzivat, resp. vypnout, aby to pri startu nepocitalo? Linux, ext4 :) Zfs neverim :)

Dne 15. 3. 2014 23:08, Pavel Snajdr napsal(a): No dobre, tak jeste teda nejdu spat, tak se trochu rozepisu a vysvetlim, o co jde: - kazdej kontejner je slozka na FS - coz znamena, ze abych mohl limitovat diskspace kontejneru, musel bych mit FS per kontejner, coz trochu drti nektery vyhody kontejneru (napr. agregace mista pri shared FS se proste neda udelat elegantneji) V OpenVZ to vyresili tak, ze mezi ext*fs/xfs a "simfs" (simulovany fs kontejneru) vlozili vzquotu, coz je neco jako tabulka mapovani muj inode -> node na FS + accounting infromace o velikosti. Diky tomu pak i funguje second-level quota (tzn. normalni linuxova user/group quota) - coz je neco, co budeme muset do ZFS doimplementovat. Nevyhoda vzquoty se pozna pri resetu systemu, kdyz nema cas si syncnout ten mapujici soubor na disk. Pak musi vzquota pri startu kazdyho kontejneru projit jeho soubory a znova je namapovat. To je prave to, co ti muze rozhazet cisla inodu. Bootovani serveru s vzquotou po resetu je pak tragedie a masina s 90 VPS muze naskakovat klidne 3-4 hodiny. Krom toho je vzquota nachylna na random rozbijeni se i pres tu kontrolu integrity, da se rozbit ze ukazuje min/vic zabranyho mista/inodes, akorat nevim, jak k tomu dochazi (co je trigger toho rozbiti), deje se to jenom zridkakdy. Also, ukazalo se ze mit vic kontejneru na EXT4 je totalni blbost, v ext4 je nejfatalnejsi problem journal. Stane se bottleneckem celyho toho FS a proste neda se nic. Obzvlast, kdyz nad tim FS bezi par databazi. Iowait leti nahoru, disky seekujou jak pomateny a propustnost filesystemu jde do kytek. Oproti tomu node se ZFS ma tech 90 VPS nastartovanych do tak 10ti minut jako absolutni maximum. A tech MySQL muze na serveru bezet, co zvlada CPU, protoze na synchronnni zapisy a fuckup unixovyho sveta jmenem sync() ma ZFS mechanismus jmenem Intent Log a moznost ho vysoupnout na dedikovany device. Oproti tomu ext4 ani s dedikovanym journalem na SSD nedela temer zadny rozdil. Pak uz disky tolik neseekujou, ale vykon porad nikde. Btw tahle "vlastnost" ext4ky donutila OpenVZ lidi implementovat ploop, takze pak delaji ext4 in a file per container. So much win! :) Urcite budem dal pracovat na ZFS podpore, linuxovy filesystemy jsou jedna velka tragedie. Navic se diky tomu muzem zbavit ty tragedie vzquoty. /snajpa On 03/15/2014 10:55 PM, Pavel Snajdr wrote: _______________________________________________ Community-list mailing list Community-list(a)lists.vpsfree.cz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlMk2HAACgkQMBKdi9lkZ6pQqgEAnHztZz4Qd8Hkc5bdIoUz4UK0 HVYOS7lYt+KoOf68MuoA/R1BTbI/lTczn7XTwdniTaqNZFZk3AwaCDcJTCCDN8ww =2M45 -----END PGP SIGNATURE-----

On 03/15/2014 10:52 PM, Ondrej Mikle wrote: A jeste jsem ti neodpovedel uplne, tvoji VPS jsem prave migroval nedavno z ext node na ZFS node, to zpusobilo tu zmenu inodu. Dal tedka jakakoliv obnova ze zalohy, dalsi migrace atd. bude menit cisla inodu.

Ale jakmile budeme ZFS only, povolime send/recv funkcionalitu a pak by mel ten filesystem VPS vypadat porad konzistentne v case, at je uz se na ten cilovej node dostal migraci nebo obnovenim ze zalohy.

Jop, a to neni jedina aplikace, kterou to afektuje, i trivialnejsi programy se ridi cislem inodu (tusim i treba git tak detekuje mv souboru).

On 03/16/2014 01:54 AM, Ondrej Mikle wrote: Z manu ZFS: --- checksum=on | off | fletcher2,| fletcher4 | sha256 Controls the checksum used to verify data integrity. The default value is on, which automatically selects an appropriate algorithm (currently, fletcher4, but this may change in future releases). The value off disables integrity checking on user data. Disabling checksums is NOT a recommended practice. Changing this property affects only newly-written data. --- Tzn. da se to nastavit per dataset (FS/ZVOL), default je fletcher4, kterej je paradne rychlej. Ale hodi se jenom na checksumy, protoze je hodne nachylnej na (a opravdu pravidelne generuje) kolize. Tzn. fletcher4 by se nedal pouzit v deduplikacnich tabulkach ZFS, ale ty jsou separatni, takze tam neni problem pouzivat jinej algoritmus, tam se prave pouziva ta sha256.

Ja se prave divim, ze vubec rkhunter pouzivas, ja mel za to, ze uz to dal nikdo nevyviji, vzdycky mi to prislo jako takovej polomrtvej projekt - nebo se mylim?

Ale at nad tim premejslim z jakyho chci uhlu, proste nevidim, jak se tomu vyhnout, krome prevence/osvety... Coz ale proste nefunguje, protoze tu svobodu mit svuj server maji i ti, co je to proste nezajima a jenom potrebujou, aby jim ten jejich eshop jel. S takovyma nadelame neco jenom tezko, protoze ti na to jdou stylem "install&forget", coz u systemu vystavenych do internetu nejde, no.

Automatizovat vyhledavani zastaralejch verzi baliku napric kontejnerama stejne nezachrani deravy wordpressy nachazejici se na tech nejnestandardnejsich mistech, prohledavat FS kazdyho kontejneru takhle se neda. Nevim, moc se s tim asi delat neda no.

On 03/16/2014 03:54 AM, Ondrej Mikle wrote: No, tak nejak. Asi s tim moc nenadelame. Jediny, co s tim post-mortem muzem delat, je vynutit si reinstall takovy VPS od clena, jinak mu ji nepustime. Toto realne delam ve vetsine pripadu, tzn. opravdu si chcete vsichni drzet ty VPS zabezpeceny, nechcete, abych po vas dupal, ze si to musite reinstallovat :) Drtiva vetsina lidi totiz nema na to dohledat vsechny dopady hacku dany VPS po celym jejim FS, takze je reinstall jedinou rozumnou moznosti. Ale jsou lidi, co by do nej dobrovolne nesli a radsi posilali spamy z VPS, tak proto to vynucuju (yes, i takovi jsou..). Nj jenze tohle zlo jedno z nejrozsirenejsich blogovadel/webovadel na svete, takze nas bude trapit jeste pekne dlouho :) Jinak jeste @ rkhunter: neznam moc alternativ no. Pak jsou akorat softy, ktery delaji neco trochu jinyho, v podstate ale taky IDS (intrusion detection). Kdysi se zvyknul pouzivat Tripwire, ale posledni release je 2011, takze jeste horsi, nez s rkhunterem. Ale behem hledani jsem narazil asi na jeden z mala aktivne vyvijenejch IDS pro linux aktualne: http://la-samhna.de/samhain/ (ono je toho vic, ale vsechno je nevyvijeny, napr AIDE, OSSEC...)

/snajpa _______________________________________________ Community-list mailing list Community-list(a)lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlMlnnkACgkQMBKdi9lkZ6pxhwD+Jtv52kZ9Vag1W5CKzgSj+1nR EtyNiInLkErsA/0HFswBAMZGgDxm8x0/d8ZUlEMvv8QAKODfhW9Xg4nPRgumm5eb =sgKV -----END PGP SIGNATURE-----