V dokumentově orientované databázi MongoDB byla nalezena a v upstreamu již opravena kritická bezpečností chyba CVE-2025-14847 aneb MongoBleed.
Při úklidu na Utažské univerzitě se ve skladovacích prostorách náhodou podařilo nalézt magnetickou pásku s kopií Unixu V4. Páska byla zaslána do počítačového muzea, kde se z pásky úspěšně podařilo extrahovat data a Unix spustit. Je to patrně jediný známý dochovaný exemplář tohoto 52 let starého Unixu, prvního vůbec programovaného v jazyce C.
FFmpeg nechal kvůli porušení autorských práv odstranit z GitHubu jeden z repozitářů patřících čínské technologické firmě Rockchip. Důvodem bylo porušení LGPL ze strany Rockchipu. Rockchip byl FFmpegem na porušování LGPL upozorněn již téměř před dvěma roky.
K dispozici je nový CLI nástroj witr sloužící k analýze běžících procesů. Název je zkratkou slov why-is-this-running, 'proč tohle běží'. Klade si za cíl v 'jediném, lidsky čitelném, výstupu vysvětlit odkud daný spuštěný proces pochází, jak byl spuštěn a jaký řetězec systémů je zodpovědný za to, že tento proces právě teď běží'. Witr je napsán v jazyce Go.
Yazi je správce souborů běžící v terminálu. Napsán je v programovacím jazyce Rust. Podporuje asynchronní I/O operace. Vydán byl v nové verzi 25.12.29. Instalovat jej lze také ze Snapcraftu.
Od soboty do úterý probíhá v Hamburku konference 39C3 (Chaos Communication Congress) věnovaná také počítačové bezpečnosti nebo hardwaru. Program (jiná verze) slibuje řadu zajímavých přednášek. Streamy a záznamy budou k dispozici na media.ccc.de.
Byl představen nový Xserver Phoenix, kompletně od nuly vyvíjený v programovacím jazyce Zig. Projekt Phoenix si klade za cíl být moderní alternativou k X.Org serveru.
XLibre Xserver byl 21. prosince vydán ve verzi 25.1.0, 'winter solstice release'. Od založení tohoto forku X.Org serveru se jedná o vůbec první novou minor verzi (inkrementovalo se to druhé číslo v číselném kódu verze).
Wayback byl vydán ve verzi 0.3. Wayback je "tak akorát Waylandu, aby fungoval Xwayland". Jedná se o kompatibilní vrstvu umožňující běh plnohodnotných X11 desktopových prostředí s využitím komponent z Waylandu. Cílem je nakonec nahradit klasický server X.Org, a tím snížit zátěž údržby aplikací X11.
Byla vydána verze 4.0.0 programovacího jazyka Ruby (Wikipedie). S Ruby Box a ZJIT. Ruby lze vyzkoušet na webové stránce TryRuby. U příležitosti 30. narozenin, první veřejná verze Ruby 0.95 byla oznámena 21. prosince 1995, proběhl redesign webových stránek.
. S tou bezpecnosti (a ted ji nechci podcenovat) by me absence "nekolika firewallu" na databazovem serveru zas az tolik nevadila, protoze od toho jsou firewally na jinych serverech. Tento je ciste databazovy.
)
sem tam patchujete.. rychlo sa na to zvyka a je to koplexny OS ...- (nie jadro + GNU) (Linuxaci nehnevajte sa na mna..)
Behom jedneho dna si pekne na novy OS zvyknete a budete spokojny.. uvidite.
Povedzme, ze chlapik by si uplne zablokoval akekolvek lokalne prihlasovanie a mal pristup len cez ssh (pri niektorych housingoch je to nutnost), a root by bol premenovany inak (napr. matejko UID 0).A co třeba zakázat přihlášení roota přes ssh, než takovéhle kejkle?
Klišé typu "SuSE (Red Hat, Mandrake) se hodí jen na desktop, na server se nehodí" bytostně nesnáším. Je to totiž naprostý nesmysl. Proč třeba Oracle certifikuje své produkty pro Red Hat a SuSE? Že by byly určeny desktopovým uživatelům? Asi ne. Jistě, SLES se na server určitě hodí více než SuSE x.y Professional a RHEL více než Fedora Core. Jenže důvody, proč tomu tak je, by spolehlivě vyřadily ze hry všechny ostatní alternativy, o kterých tu padla zmínka.
A ještě drobnost: váš příklad s přejmenovaným rootem mi připadá poněkud přitažený za vlasy. Můžete mi sdělit jediný praktický důvod, k čemu by to mělo být dobré? Napadá mne leda "zabezpečování" podle hesla security by obscurity. Chápal bych důvody pro zavedení druhého uživatelského účtu s UID 0, ale tam zase nevidím, v čem by měl být problém. A když už o tom přemýšlím, nenapadá mne ani důvod, proč blokovat lokální přihlášení - natož důvod, proč by to snad měla být nutnost.
su nevidím žádnou velkou výhru. Spíš bych chápal zákaz autentizace heslem (autentizace pouze klíčem) nebo restrikci IP adres klientů.
aspon dufam.. ak nie, tak ma opravte..
Ak bez problemov pouzivate suse na serveroch, tak urcite nie s ich jadrami.. ak ano, tak uzrcite nie na raid1+0 s xfs .. pretoze to sa size da vytvorit aj spravit mkfs, ale pri mount toho raidu s xfs kernel spadne..... je to vyriesene az v 2.6.8 - a to je az v suse 9.2
pokial to date na iny mountpoin ( /usr ) tak to v pohode zozerie..
.. potom mi to potvrdili aj po telefone, ked som volal na support.. (nejaka babenka to tam ma nastarosti)
ad 'security by obscurity' - zmena uzivatela root je jednou zo zakladnych veci, ktore treba urobit v ramci lokalneho aj sietoveho zabezpecenia..
2. Úžasné, vy víte lépe než já, na co mne instalační program upozornil. Netvrdil jsem, že to byla verze 9.1. Ale i z jiných náznaků jsem vyrozuměl, že implementace XFS ještě není úplně stoprocentní a v netypických situacích (jako je třeba právě kombinace se SW RAIDem) mohou nastat problémy.
4. To je docela zvláštní názor. Zajímavé je, že jsem se s ním zatím setkal jen u těch, kteří toho jinak o bezpečnosti moc nevěděli. Naopak ti, kteří byli odborně na výši, se na podobné techniky "zabezpečení" dívali s úsměvem nebo opovržením.
Jinak ta verze Apache toho sama o sobě moc neříká, většina linuxových distribucí updaty provádí v naprosté většině formou backportu oprav (ne upgradem na novou verzi s novými featurami a novými chybami), takže pokud v době release SuSE 9.1 (duben 2004) byla aktuální verze Apache 2.0.49 (což je poměrně pravděpodobné), je tam dodnes a bude tam velmi pravděpodobně už pořád. To ale neznamená, že jsou v ní chyby, které byly opraveny v novějších verzích.
Pokud byste udělal analytický benchmark čistě na výkon procesoru (tj. výpočetně náročný algoritmus pracující na malém kousku paměti), nebude mít při algoritmu, nepoužívajícím 64-bitová data, AMD64 nijak zřetelně navrch. Pokud ale bude algoritmus používat často 64-bitová data, bude rozdíl značný. Jako modelový příklad bych uvedl recenzi na http://www.anandtech.com/linux/showdoc.aspx?i=2213&p=8, zejména dva extrémní případy: v John-the-Ripper MD5 je 64-bitová verze dokonce o něco pomalejší (asi nedoladěná optimalizace), ale u OpenSSL RSA-1024 je výkon 64-bitové verze více než dvojnásobný.
uz neviem co pysem.. je 3:18 rano a o 7:00 vstavam, takze majte sa krasne a so sorry za tie security-obscur.. no sak viete.. .. taz zatial papa.. dobru nocku..
Ale vůbec ne. To, že vám taková konfigurace připadá sexy, vůbec neznamená, že je opravdu nejlepší (nebo dokonce nejoptimálnější). Především tu pracujete s jedním velmi dlouhým souborem (nebo několika málo soubory), takže na filesystému zase až tak nezáleží. Pokud tedy nepotřebujete připadat si jako velký borec, který má slavný XFS (a ReiserFS nebo ext3 jsou pod jeho úroveň), není prakticky žádný důvod, proč si s ním komplikovat život. Tím nechcí říct, že jinde XFS nebude přínosem, ale tady nevidím žádný důvod, proč ho nějak preferovat.
A s RAIDem je to také otázka. Viděl jsem mnoho pojednání na téma použití RAID 1 (mirror) vs. databáze a jediný obecný závěr, který bych si dovolil prohlásit za obecně platný, je ten, že názory se různí. V některých případech totiž při provozování databáze nad RAID 1 docházelo i k dost znatelnému zpomalení. Konkrétně v případě Firebirda je alternativou použití shadow files a také není obecně příliš jasné, která z variant je efektivnější - spíš je to třeba posoudit případ od případu.
Vzhledem k vašim relativně krátkým zkušenostem bych vám doporučoval neprezentovat vlastní názory formou jednoznačně dané pravdy. Zvláště v případě, že nejsou podloženy faktickými argumenty, ale pouze pocity.
XFS vykazuje ve (všech co jsem viděl) benchmarcích lepší výsledky než ostatní FS právě při operacích s velkými soubory a ty rozdíly bývají často markantní, takže bych tento faktor určitě nepodceňoval.
Tiskni
Sdílej: