Byla vydána beta verze GNOME 48. Vyzkoušet lze instalační ISO GNOME OS. Vydání GNOME 48 je plánováno na březen.
Bochs (Wikipedie), tj. emulátor počítačů typu x86 a x86-64, byl vydán ve verzi 3.0.
Věříte své kalkulačce? Kolik je (10^100) + 1 − (10^100)? A kolik 1%−1%?
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
FlappyFavi, hra Flappy Bird v ikoně Favicon. Nefunguje na mobilech.
Byly vyhlášeny výsledky (YouTube) 28. ročníku D.I.C.E. (Design, Innovate, Communicate, Entertain) Awards: Hrou roku 2024 je Astro Bot.
Všem na AbcLinuxu vše nejlepší k Valentýnu aneb Dni lásky ke svobodnému softwaru (I love Free Software Day, Mastodon, 𝕏).
Vývojáři openSUSE Tumbleweed oznámili, že u nových instalací se ve výchozím stavu přechází z AppArmor na SELinux. Uživatelé, kteří chtějí zůstat na AppArmor si mohou AppArmor vybrat v instalátoru.
Hector "marcan" Martin skončil jako vedoucí projektu Asahi Linux aneb Linux na Apple Siliconu. Projekt ale pokračuje dál.
PostgreSQL byl vydán ve verzích 17.3, 16.7, 15.11, 14.16 a 13.19. Řešena je zranitelnost CVE-2025-1094 s CVSS 8.1 a více než 70 chyb.
Nize v blogu vidim hate na Supermicro, tak jsem si rikal, ze bych k tomu mohl
taky neco napsat
Kdyz vpsFree.cz zacinalo, nasim prvnim serverem byl tower s Core 2 Quad procesorem, Asus deskou, 8 GB DDR2 pameti a 4x 500 GB Samsung disky.
Abych nejak vyjadril svuj nazor na "skladacky" z consumer-grade dilu - vubec nemam nic proti, a ten, kdo uz z principu rika, ze je to blbost, by mel sklapnout a poradne se zamyslet.
Vyber jakekoliv komponenty (hardware, software, ...) vzdycky zavisi na use-case. Je potreba si dat proti sobe vsechny plusy a minusy a potom zvazit, jakou maji pro dane pouziti prioritu. Kdyz je mel vyjmenovat:
Pri staveni desktopoveho hardware existuje minimalne jedno "golden-rule", ktereho je dobre se drzet - nikdy nekupujte ty nejlevnejsi komponenty. Kdyz uz chcete setrit a stavet desktopy jako servery, jdete po - jak ja tomu rikam - "nejdrazsim minus jedna", tzn. seradte v eshopu consumer-grade hardware podle ceny sestupne, preskocte par prvnich a tam nekde pak vybirejte.
Spolehlivost takoveho reseni je z me zkusenosti vic nez slusna, z nejakych peti toweru, ktere jsme takhle ve vpsFree.cz postavili, pamatuju akorat jednu mrtvou desku, nejake mrtve disky (ale ty odchazeji vsude, to je proste spotrebni zbozi) a to je vsechno. Vsechny towery uz jsme vyradili z provozu, ale slouzi pekne dal jako desktopy, pripadne vyvojove stroje. Podotykam, ze vetsina z nich byla kupovana v prubehu 2009 a v DC byly tri roky v nonstop provozu. IMHO velice slusna bilance.
My jsme se ve vpsFree pohybovali cenove okolo 30ti tisic za kus, dneska by to bylo mozna o neco min, protoze od 2009 sly ceny hardwaru celkove o trochu dolu, rozdil je videt hodne napr. v cenach pameti.
Desktopovy hardware je podle mne idealni na zacinajici projekt - jestli si potrebujete validovat napad v praxi a staci vam slabsi hardware (128 GB RAM do desktopu nenacpete), myslim si, ze je to idealni low-cost cesta, kudy jit.
V druhe polovine roku 2010 bylo celkem jasne, ze situace s desktopy nebude udrzitelna uz moc dlouho - preci jenom pri nejakych 5ti desktopech uz bylo updatovani tech serveru s naslednym rebootem docela problemove. Chudaka technika jsem honil po Masteru aby mi prepojoval KVM mezi jednotlivymi nody, nadseni jsme z toho nebyli ani ja, ani ti technici.
Rekli jsme si tedy, ze se placneme pres kapsu a z polic prejdeme do racku. Vzhledem k tehdejsim rozpoctum vpsFree jsme nemohli vzit vic jak pul racku, proto jsme potrebovali reseni, kterym usetrime co nejvic mista - po chvili hledani padla volba na Supermicro 1U twin servery - tedy dva nody v 1U.
Ty masinky jsme vybrali proto, ze prostorove zabiraji pul U, ale vykonove slibovaly ekvivalent tech toweru - Xeon X3450 docela tim ekvivalentem pro nas use-case opravdu je.
Soucasne jsme k 3 takovym kompletum (= 6 nodu) koupili 3Uckovy storage (16 1T disku, jinak X3450 stejne jako twiny s 24GB DDR3 ECC RAM), ktery mel slouzit jako centralni storage box pro VPS data.
Po softwarove strance nam ale totalne vyhorel tenhle napad mit NAS box a k nemu 6 virtualizacnich nodu - o tom se rozepisu nekdy priste, ted si povidejme o hardware - takze nakonec jsme byli zpatky u lokalniho uloziste. A tady se ukazal problem s twin nody - 2 disky v RAID1 jsou sakra spatna volba. Po case jsme zacali davat do tech toweru, ktere byly stale jeste v provozu SSD disky nad kterymi jsme meli Facebook Flashcache (mimochodem skvely projekt), tedy SSD jako writeback cache nad disky, coz neuveritelne urychlilo napr. MySQL databaze - muzou si v klidu jet O_SYNC, coz jde na SSD a disky maji cas delat read operace.
No a tady je problem s twin nody - neni tam kam dat SSD . Tedy je,
je tam moznost dat low-profile PCI-express SSD, ale kdo kdy koukal na ceny, vi,
ze low-profile se delaji jenom "enterprise" SSD, ktera jsou vyslovene predrazena.
Nejdriv k Supermicro jako znacce - podle mne je to jedna z mala znacek serveroveho hardware, kterou vubec dava smysl kupovat ve vetsine pripadu, kdyz shanite hardware, co pujde nekam do serverovny. Kdyz se kouknu na ceny Supermicro a porovnam je s velkymi znackami jako IBM a dalsi - neni uplne daleko od pravdy, ze co koupim od IBM za cenu X, bych mel od Supermicro za X/2 (casto i vyhodneji). Jsou znacky, ktere muzou cenove konkurovat Supermicro s mensim rozdilem, ale vzdycky jsou drazsi a temer pokazde neni nejaka rozumna zaruka v cene.
Takze na co by nekdo kupoval drahy hardware, stejne se to vyrabi vsechno
kdesi v Asii, stejne je to ten samy hardware (oh, moment, IBM pouziva
sracka-sitovky od Broadcomu, takze vlastne plus pro Supermicro ).
A jen tak na okraj - kdo se ohani zarukou (NBD, 4h a podobne) - kde je sakra
problem koupit za tu samou cenu proste ten hardware dvakrat a v pripade problemu
jenom precvaknout disky?
Plus Supermicro ma spoustu zajimavych form-factoru, ktere jini vyrobci nedelaji - s 8nodovym Fat Twinem v 2U, kdo potrebuje blade centery?
Samozrejme je to o rozpoctu - kdyz mam rozpocet a nejsem omezeny penezi,
jak se rika - jeste nikdy nikoho nevyhodili za to, ze koupil IBM - ve
vetsi organizaci, kde jsou penize, se tezko bude nekdo zamyslet nad cenou
serveru. Na druhou stranu, ruzni cloud provideri stavi na techto tzv.
white-box znackach jako Supermicro, protoze presne tohle, o cem pisu,
zacinaji zjistovat taky.
Jelikoz se ukazalo, ze se toweru kvuli lepsimu IO nebudeme moct jeste zbavit, museli jsme nejak vyresit absenci remote managementu - tou dobou uz jsem byl naprosto zamilovany do Supermicro IPMI a uz jsem nechtel servery bez nej - myslim, ze to mi muze potvrdit kazdy, kdo prechazel z toweru na neco s remote managementem.
Supermicro nastesti delalo pro LGA1366 Intel Core i7 kompatibilni ATX desku - X8STi-F, ktera cenove vychazi jenom o neco malinko draz, nez ty Asus desky, co tam byly do ted. Tim se smazala z meho pohledu nejvetsi nevyhoda toweru.
Kdybyste to tak nekdo chteli resit dneska, Supermicro uz zadnou desku pro LGA2011 Core i7 nedela. Ono to z jejich pohledu ani nedava smysl - kdyz se kouknete na Intel Xeon E5 rady 1600, jsou cenove velmi podobne Core i7 procesorum - vsak jsou to v podstate ty same cipy, akorat s povolenym ECC na pametovem radici.
Kdyz uz jsem se tak rozepsal, radsi to ted ustrihnu a rozdelim do vice
dilu - mne by se teda tolik casu najednou jednomu textu nechtelo venovat.
Priste tedy o hardwaru, jaky kupujeme v soucasne dobe, o diskach a mem
pohledu na diskove pole, pripadne zaradim jeste neco, co vas zajima - ptejte
se v diskuzi
Tiskni
Sdílej:
V každém slušné housingu vás těmito prostory rádi provedou a je to pěkná podívaná (já rád tisíce ampér).No nevím, ale mám pocit že ve slušném hostingu to funguje přesně naopak... do restricted oblastí nepouštím lidi, kteří tam nemusí být. Je to jeden z požadavků bezpečnostní politiky každé rozumné normy pro zabezpečení datových center.
Jenže mě ujištění "máme to či ono", nestačí.Proto existujou normy, audity, auditoři a compliance. Samozřejmě tvrzení jsme Tier IV, je o ničem, ale prohlášení Uptime Institutu - byli jsme u návrhu toho datového centra, jeho stavby a pravidelně ho co půl roku kontrolujeme, že je opravdu ve shodě s normou Tier IV, je poměrně věrohodné. Mnohem věrohodnější, než vidět, že mají diesel, který vyzkoušeli naposledy před spuštěním produkčního provozu.
pravidelně ho co půl roku kontrolujeme, že je opravdu ve shodě s normou Tier IVJenom aby to nebylo "projdeme, jestli jsou v pořádku papíry o prováděných kontrolách"
od různých výrobců
Od těch všech dvou? Je to peklo, dřív jsem měl v políčku 6 disků od 4 výrobců, dnes jsou to dva a je vůbec problém najít nějaký slušný disk.
Imo je tema hardwaru, tak ako ho popisujete, dost old-school. V tejto dobe vobec nema vyznam sa zaoberat len cisto hardwarom ako takym. Nedavno sme testovali u nas kvoli novym projektom najnovsi rack a blade class x86 HW (t.j Cisco UCS, HP G8, a ibm bol tusim nejaky hs20). Z hladiska HW to boli vsetko takmer identicke stroje, zostavou aj vykonom.
Rozdiel robil jednoznacne management software + dalsie ficury.
IBM toho vela nedokazal, HP bolo na tom urcite lepsie (Onboard administrator+VIrtual Connect+flexfabric), ale imo cisco bolo urcite najinovativnejsie. Napr k nodam(blejdam) sa tam pristupovalo skor logicky ako fyzicky, a nody poskytovali len HW pre to co mu management da. Inymi slovami vytvorim si profil, kde chcem minimalne 4xCPU N x Virtualny Ethernet (rychlost portu sa meni online) N x Virtualne HBA (rychlost detto) min tolko RAM a hotovo. Potom profil pripradim k nejakej volnej node, alebo to necham na management samotny. K samotnym blejdam nesli ziadne kable cize prakticky cely konnekt do chasi bol N x elektrika, N x ethernet uplink, a N x SAN uplink. VLANy VSANy sa vsetko dialo na centralnom nexuse. No proste nadhera. ipmi je hodne za opicami oproti tomu co dokazu enterprise class vendori.
D.
Presne tak:)
ono v principe davam za pravdu ze desktop hardware je ok...pac co ho odlisuje od enterprise je to ze ventilatory fukaju ako besne a mozno (ozaj mozno) sa maticna testuje o trocha dlhsie....
D.
JJ, tuhle hračku myslím máme (možná ne přesně tento model), před nějakým časem to bylo jako část zálohovacího serveru (starý Fujitsu-Siemens P4, Centos, PCBackup) a rozhodně to přežilo použité disky. Teď je to odstavené, nahradilo se to malou krychličkou od HP, ale tehdy to účel plnilo celkem dobře.
Správně připomenuto, asi měl bych to zas oživit a použít.
Mimochodem, prima článek.
ZDAR!
- Je opravdu remote management dulezity, nebo to je jen dusledek nevhodneho OS? Osobne bych to resil podobne jako u routeru - mit read-only system na flash (staci CF v PATA redukci, i kdyz dnes uz nove mainboardy casto PATA nemaji) s optimalizovanymi startovacimi skripty (tedy nemit tam nic, co by se mohlo rozbit) a to pouzivat jako 'hypervizor', servery pak pobezi na beznem OS v chrootu/virtualu/... z jineho disku.Je to o pohodlí a jistotě. Stejně jako autor zápisku si nemůžu remote management vynachválit a kdyby to šlo, tak si ho dám na servery, o které se teď starám (desktopový hardware). Pokud má člověk snadný fyzický přístup, tak to nehraje roli. Ale jestliže jsou špatně přístupné - serverovna ve sklepě kam je potřeba si dohodnout vstup předem, nebo vzdálené přes půl města nebo i víc, tak se remote management sakra hodí. Když jsem potřeboval změnit ip adresu stroje na jinou za běhu (s přehazováním route a VLAN), případně s co nejkratším výpadkem, tak se přes remote management dá ledacos zachránit (např. když kvůli chybě v konfiguraci nestartovala síť). Nebo jsem nedávno šel přes půl města, abych ručně opravil ext3 oddíl protože systém nenastartoval a neměl jsem jistotu, že se nepokazilo ještě něco navíc (server z ničeho nic přestal reagovat na cokoliv kromě pingu a po restartu se nevzpamatoval).
Je opravdu remote management dulezity
Je.
nejake napajanie, ktore sa da na dialku spinat (na tvrdy reset stroja)
To bych také považoval za samozřejmost.
Co se tyce lidske chyby tak budiz (i kdyz vzhledem k striktnimu oddeleni 'hypervisora' a bezneho serverovskeho software se to riziko dost minimaluzuje a editovat grub tam uz nedava zas tak moc smysl).
Ano, ovšem ne všechny servery na sobě nesou (mohou nést) hypervizora. Na spoustě HW potřebujete mít OS.
Pokud uz nekdo ma v serverovne cely rack, tak proc radsi nemit terminal server, ktery umozni management serveru pres seriovou konzoli a vzdaleny reset/poweroff, nez mit v serverech potencialni bezpecnostni diru, jakou je IPMI?
Proč bezpečnostní díru? Na to IPMI se dostanete jedině z IPsec / OpenVPN sítě a k tomu zase potřebujete klíč. Úplně stejně na tom bude ten případný terminal server.
Ano, ovšem ne všechny servery na sobě nesou (mohou nést) hypervizora. Na spoustě HW potřebujete mít OS.Nejsem si jist, zda reagujes na mou puvodni otazku, ta neznela zda je dobre mit remote management na serveru z beznym OS, ale zda vhodnost remote managementu neni spis dusledek soucasnych 'nespolehlivych' OS, tedy pokud by byl system od zakladu postaven se spolehlivosti jako s jednim z primarnich cilu (vcetne napr. dusledne oddeleni 'hypervisora' a 'aplikacniho' software), pak by vyznam takoveho managementu byl podstatne mensi.
Proč bezpečnostní díru? Na to IPMI se dostanete jedině z IPsec / OpenVPN sítě a k tomu zase potřebujete klíč.Vychazim z dvou bodu (AFAIK): 1) IPMI sam o sobe neni vyznamne zabezpeceny, zabezpecit je tedy treba primarne management port. Takove reseni je vetsinou dost problematicke. Nerikam, ze to nejde udelat dobre, ale je tam spousta mist, ktere mohou selhat. Pokud mam rack, v nem vlastni nezavisly switch jen pro management pro management porty a k tomu vlastni vyhrazeny VPN server, pak OK, v typickych aplikacich (napr. kdyz ma jen jeden server) se tam asi clovek bude spolehat na daleko vic dalsich promennych. 2) Software bezici na BMC je proprietarni, je tedy otazka, jak moc se mu vubec da duverovat.
Co trochu konkretnejsi odpoved - v kterych pripadech pomuze…To je asi stejná otázka jako "co se rozbije příště". Pokud máš dopředu naplánované poruchy disků, nepotřebuješ disková pole. Pokud víš kdy bude problém se zdrojem, nepotřebuješ redundantní napájení. Et cetera… Pokud víš kdy budeš příště potřebovat židli a KVM, nepotřebuješ management karty. Příklad ze života: Kdysi na casablance zdechla klima a celý horní patro se nažhavilo jako pec. Ne tolik aby všechno rovnou popadalo, ale dost na to aby mašiny začaly náhodně zatuhávat. Právě tehdy jsme našeho šetřivého šéfa přesvědčili že pár tisícovek na mangement kartu je lepší investice než platit lidi za to že jedou stopadesát kilometrů, zmáčknou reset a jedou zpátky. Nebo než nedejbože čekat až se pan Hampl milostivě uvolí ten čudlík zmáčknout sám.
Pokud máš dopředu naplánované poruchy disků, nepotřebuješ disková pole. Pokud víš kdy bude problém se zdrojem, nepotřebuješ redundantní napájení. Et cetera… Pokud víš kdy budeš příště potřebovat židli a KVM, nepotřebuješ management karty.No, poruchy disky ci zdroju je problem z realneho sveta, kteremu se moc vyhnout neda, takze redundance jako reseni je rozumne. Oproti tomu 'je potreba zidli a KVM' je vicemene umely softwarovy problem, ktery v prevazne vetsine pripadu by sel snadno odstranit rozumnym navrhem software (resp. zajistit, aby v takovem pripade krome KVM konzole sla pouzit i sitova konzole). Remote management (specificky tedy spis remote KVM) je proste takovy rovnak na ohybak.
Ne tolik aby všechno rovnou popadalo, ale dost na to aby mašiny začaly náhodně zatuhávat. Právě tehdy jsme našeho šetřivého šéfa přesvědčili že pár tisícovek na mangement kartuA nestacilo by proste zapnout watchdog? Ten je dneska standardni soucasti superIO chipu, a pokud neveris internimu, lze poridit externi za par stovek.
Remote management (specificky tedy spis remote KVM) je proste takovy rovnak na ohybak.S tím souhlasím.
A nestacilo by proste zapnout watchdog? Ten je dneska standardni soucasti superIO chipu, a pokud neveris internimu, lze poridit externi za par stovek.Akorát za pár stovek pořídíš i to ipmi (pokud v tom serveru už není.) S výhodou, že že se můžeš podívat, jestli na obrazovce nezůstal nějaký výpis kernel panic
Je opravdu remote management dulezity…Případně se to dá řešit pomocí null modemu a propojení dvou serverů. Akorát ti nesmí odejít oba najednou a musíš si vystačit se sériovým portem (což se celkem dá: GRUB, GNU/Linux i některé BIOSy/Coreboot).
$ dd if=pack-d0975dc1d1667ecd904faaf20e75a8d4b5aed293.pack of=/dev/null 8985756019 bytes (9.0 GB) copied, 40.4833 s, 222 MB/s
$ dd if=pack-d0975dc1d1667ecd904faaf20e75a8d4b5aed293.pack of=/dev/null 8985756019 bytes (9.0 GB) copied, 1.5159 s, 5.9 GB/s32GB paměti se hodí, protože i když můžete mít SSD disk o rychlosti čtení (tohle je starej disk) i 500MB/s, tak z paměti je to pořád více než 10x rychlejší. Nejlepší použití paměti je jako IO cache.
Treba poustet virtualni masiny na tom ani nema smysl zkouset.Já jsem na něčem takovém, akorát se 3GB RAM, dělal školení, kde každý z účastníků měl k dispozici dva své vlastní virtuály.
Ad Supermicro hate:
jen bych rád podotknul, že servery jedeme prakticky jenom Supermicro, poměr cena výkon je opravdu fajn. Musím ale přiznat, že je jsem slyšel i názory lidí, kterým se Supermicra sypou. Z mého pozorování plyne, že dost potíží bylo se stroji typu Opteron do socketu F, tyhle starší stroje občas vytuhnou. Situace se taky hodně zlepšila od doby, kdy začalo Supermicro dělat AMD desky se síťovkama od Intelu, ty nVidie, co tam dávaly před tím, to byl mor, filcky, svrab a neštovice... všechny tyhle servery mají u nás píchnutou intelí síťovku do slotu.
Jinak FatTwin je miláček, jen mě u tak promyšlený mašiny zarazila tak podivně umístěná baterka + jumper...
monitoring / # cat /var/log/syslog | grep -i vacuu Feb 1 23:23:03 monitoring postgres[512]: [3-1] LOG: autovacuum launcher shutting down Feb 1 23:23:19 monitoring postgres[504]: [1-1] LOG: autovacuum launcher started Feb 2 02:28:53 monitoring postgres[504]: [2-1] LOG: autovacuum launcher shutting down Feb 2 02:31:10 monitoring postgres[512]: [1-1] LOG: autovacuum launcher started Feb 6 08:17:11 monitoring postgres[512]: [2-1] LOG: autovacuum launcher shutting down Feb 6 08:17:28 monitoring postgres[505]: [1-1] LOG: autovacuum launcher started Feb 6 08:17:42 monitoring postgres[505]: [2-1] LOG: autovacuum launcher shutting down Feb 6 08:17:54 monitoring postgres[497]: [1-1] LOG: autovacuum launcher started Feb 17 11:20:02 monitoring postgres[497]: [2-1] LOG: autovacuum launcher shutting down Feb 17 11:20:24 monitoring postgres[505]: [1-1] LOG: autovacuum launcher started Mar 5 08:20:53 monitoring postgres[505]: [2-1] LOG: autovacuum launcher shutting down Mar 5 08:23:33 monitoring postgres[512]: [1-1] LOG: autovacuum launcher started Mar 7 10:13:55 monitoring postgres[611]: [1-1] LOG: autovacuum launcher started Mar 9 09:00:01 monitoring postgres[611]: [2-1] LOG: autovacuum launcher shutting down Mar 9 09:02:10 monitoring postgres[513]: [1-1] LOG: autovacuum launcher started Mar 9 09:13:27 monitoring postgres[513]: [2-1] LOG: autovacuum launcher shutting down Mar 9 09:13:36 monitoring postgres[504]: [1-1] LOG: autovacuum launcher startedAle samozřejmě je otázka, nakolik je tohle srovnatelné s vaším použitím...