Argentinec, který byl náhodně zachycen Google Street View kamerou, jak se zcela nahý prochází po svém dvorku, vysoudil od internetového giganta odškodné. Soud uznal, že jeho soukromí bylo opravdu porušeno – Google mu má vyplatit v přepočtu asi 12 500 dolarů.
Eben Upton, CEO Raspberry Pi Holdings, informuje o RP2350 A4, RP2354 a nové hackerské výzvě. Nový mikrokontrolér RP2350 A4 řeší chyby, i bezpečnostní, předchozího RP2350 A2. RP2354 je varianta RP2350 s 2 MB paměti. Vyhlášena byla nová hackerská výzva. Vyhrát lze 20 000 dolarů.
Představen byl notebook TUXEDO InfinityBook Pro 15 Gen10 s procesorem AMD Ryzen AI 300, integrovanou grafikou AMD Radeon 800M, 15,3 palcovým displejem s rozlišením 2560x1600 pixelů. V konfiguraci si lze vybrat až 128 GB RAM. Koupit jej lze s nainstalovaným TUXEDO OS nebo Ubuntu 24.04 LTS.
Po půl roce od vydání verze 2.41 byla vydána nová verze 2.42 knihovny glibc (GNU C Library). Přehled novinek v poznámkách k vydání a v souboru NEWS. Vypíchnout lze například podporu SFrame. Opraveny jsou zranitelnosti CVE-2025-0395, CVE-2025-5702, CVE-2025-5745 a CVE-2025-8058.
Byla vydána nová verze 9.15 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání.
Společnost CORSAIR podporuje svůj systém iCUE LINK pouze ve Windows a macOS. Jak jej ovládat v Linuxu? OpenLinkHub (GitHub) je open source linuxové rozhraní k iCUE LINK. Z webového rozhraní na adrese http://localhost:27003 lze ovládat RGB osvětlení, rychlost ventilátorů, nastavovat klávesnice, myši, headsety…
Ve funkci koordinátora k bitcoinové kauze skončil bývalý ústavní soudce David Uhlíř. Informaci, kterou zveřejnil Deník N, potvrdila Radiožurnálu ministryně spravedlnosti Eva Decriox (ODS). Uvedla, že odchod byl po vzájemné dohodě. „Jeho mise je ukončená, auditní procesy se už povedlo nastavit,“ řekla. Teď má podle ministryně další kroky podniknout policie a státní zastupitelství. Koordinátorem jmenovala ministryně Uhlíře 19. června.
Byla vydána nová verze 25.07.26 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Nejnovější Shotcut je již vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Po 9 týdnech vývoje od vydání Linuxu 6.15 oznámil Linus Torvalds vydání Linuxu 6.16. Přehled novinek a vylepšení na LWN.net: první a druhá polovina začleňovacího okna a Linux Kernel Newbies.
Americký výrobce čipů Intel propustí 15 procent zaměstnanců (en), do konce roku by jich v podniku mělo pracovat zhruba 75.000. Firma se potýká s výrobními problémy a opouští také miliardový plán na výstavbu továrny v Německu a Polsku.
nosplash nomodeset
a odebrat parametr quiet
(proč to tam proboha všichni dávají?!)Stroj, který po jednom přerušeném bootu zůstane navždy viset v GRUBu, fakt potěší. Jak tohle mohl někdo udělat jako default?Ah, díky. Tohle mě pálilo docela dlouho.
/etc
používáš přes etckeeper? Pokud ne tak doporučuji.
Zatím ne Verzovat jsem to začal ručně, ještě než jsem o nějakém etckeeperu věděl, a pak nebyla až taková motivace na něj přejít. Prostě dám
hg commit -m "co jsem změnil"
a hotovo Ten cron je tam pro jistotu, kdyby se v tom šťoural někdo jiný, kdo na to není zvyklý, tak se to aspoň zaverzuje jednou denně automaticky.
Když nad tím tak přemýšlím, tak jsem tu historii zatím nikdy nepotřeboval… Ale hodně užitečné je znát, co se změnilo od poslední verze – když zjistíš, že služby s novou konfigurací nenabíhají, tak to nemusíš ve stresu přepisovat zpátky a dáš prostě jen hg revert
nebo přes diff snadno zjistíš, které řádky je potřeba opravit.
Možná ho zkusím. Dokáže se ujmout /etc
, ve kterém už .hg
je a začít ho používat?
Jak je to vychová? Může jim etckeeper nějak zabránit v editaci konfiguráků a neverzované správě systému?
Když už někdo ty změny zapomene zdokumentovat (udělat hg commit
), tak mi přijde lepší, když se to zaverzuje aspoň automaticky jednou denně a víme, kdy se to zhruba změnilo (a podle logů možná i kdo to změnil), než mít nashromážděných spoustu nesouvisejících změn třeba za měsíc, kdy si konečně někdo vzpomene, že by se mělo verzovat.
Dokud se nazakomituje, tak nejde přes aptitude atd. instalovat/updatovat/zrušit žádný balíček. Zároveň je zajištěné, že se nesmíchají změny způsobené automatickou instalací do jednoho commitu s lokální změnou. Pokud je pak někde uložený
aptitude search '?installed?not(?automatic)' \
| sed -n -e 's/^i[ \t]\+\([^ \t]*\)[ \t].*$/\1/p' >packages
a ideálně je git automaticky pushovaný na záložní server, tak restaurace systému odpovídá
aptitude install `cat packages`
a projití nebo přímo naaplikování změn, které nebyly automatické. Problém jsou nastavení provedené přes dialogy během automatické instalace/zamíchají se s masivními změnami a pohyby souborů v etc. Proto sám vždy odklepávám default a teprve po dokončení instalace končící automatickým commitem znova vyvolám dpkg-reconfigure na dané balíčky a změnu pak pěkně vidím samotnou a s odpovídajícím popisem ji commituji.
Jako vše, i tento postup má své mouchy, na hodně podobných serverů bych i já asi přešel na puppet tak, jak to dělá náš správce serverů. Ale pokud se jedná o počítač který využívá (včetně doinstalace SW) více soudných a znalých lidí (dříve i rootfs pro laborky) a správu udělá ten, který změnu potřebuje, tak je etckeeper ideální. Spravovali jsme takto v podstatě ve třech systém pro laboratoře roky a chodilo to dobře. Vše bylo dokumentované a i při přechodu správce IT na puppet z commitů většinu relativně komplikovaných konfigurací dostal - distribuovaný rootfs s úpravami práv, autentizací proti různým serverům po škole, skripty pro speciální režim při bootu stroje ve virtuálu jako externě dostupná brána pro studenty atd. V etc. virtuálního serveru pak doprava NFS za NATy jednotlivých učeben, licenční servery. Vlastní hostitel všeho pak měl také určité množství úprav, ale o ten se staral již téměř výhradně správce (Aleš Kapica). Každý z těch, co úpravy podle aktuálních potřeb řešili pak měl ve svém profile nastavené GIT_AUTHOR_NAME a GIT_AUTHOR_EMAIL a názvy těchto proměnných byly v sudo env_keep. Takže po přihlášení na server a sudo nebo i chrootu do distribuovaného rootfs za sebou každý nechával v commitech době čitelnou stopu. Jasně, že když by chtěl, tak mohl podvádět a vydávat se za někoho jiného, ale opravdu nejsme malé děti, aby jsme si přidělávali práci, té skutečně tvořivé máme už teď tolik, že by nám stačila do důchodu.
Ale zpět k tomu tlaku na pořádek, když něco potřebuji nainstalovat a správce balíčků tvrdohlavě trvá na tom, že se nejdříve musí změny nacommitovat, jinak pracovat nebude, tak je to dobrá motivace. A i kdyby se vše mezi dvěma automatickými updaty od správce balíčků vložilo i jen do jednoho commitu, který se však od automatických pozná, tak je to pokrok. Zároveň tam zbude jméno, takže lze osobě vyčinit za to, že necommitovala po logických celcích. A vzhledem k tomu, že při vývoji SW v desítkách, možná stovce a více gitů, co používáme, musíme nějakou kulturu dodržovat, jinak by se nám projekty zcela rozpadly a nikdo by o naši práci nestál, tak ta trocha slušného chování při správě serverů není problém. A jasně, když není věc urgentní, tak jí dělá správce nebo se dohodne, kdo třeba pro hlubší znalosti o daném problému, věc otestuje, zkusí podle svých časových možností vyřešit, a pak změny zakomituje a časem informuje ostatní. I když teď už je to pravdu na těch veřejnějších službách spíš věc správce, protože se nám alespoň z pohledu potřeb výuky podařilo dojít k řešení, které koncepčně roky drží a lze adaptovat i na zvěrstava a omezení, která nám připraví různé specifické požadavky -- distribuce bootu do laborky pro jiné předměty zcela izolované od veřejné sítě atd.
Nebo tu mám nějaký chybný předpoklad?Myslím, že máš chybný předpoklad, že server musí nabootovat bez lidské interakce. V nejjednodušším případě je šifrované vše kromě jádra a initramdisku. V initramdisku je ssh server, na který se ty nebo automat připojí a zadá klíč. Zloděj, který server ukradl, data nedostane. Pokud ale dokáže se serverem nepozorovaně manipulovat a pak ho zase spustit, aby si toho nikdo nevšiml, může do initramdisku například vložit backdoor, který mu zadaný klíč pošle. Nebo si může z initramdisku zkopírovat klíče a udělat Mrkva-in-the-middle.
Jen na některých serverech nebo virtuálech… Je to prakticky neřešitelný problém. Význam to má hlavně pro případ běžné krádeže, reklamace disku nebo méně schopného útočníka.
Mám například jednoho KVM hostitele a trvale (uvnitř) zasunutou flashku a hostitel + jedna virtuálníá mašina nastartuje automaticky ze šifrovaného oddílů (klíč je na té flashce). Další VMs a data jsou na jiném úložišti, které musí být odemknuto (buď vzdáleně, nebo prostým zasunutým jiné flashky).
Význam šifrování, i když je klíč součástí stroje, to má jen pro reklamaci či další putování daného disku/ů.
K tomu prvnímu, bych doplnil, udev pravidla na MAC a zakázání NM (a jeho případné vypnutí), něco jako:
NM_CONTROLLED=no BOOTPROTO=none PEERDNS=no USERCTL=no
K tomu sedmému: nastavení barev PS1
.
K tomu jedenáctému: /tmp
do paměti a doplnění relatime
A doplnil bych:
rhgb
;))V podstatě +- stejné, až na:
firewall zakazující všechno, kromě explicitně uvedených služeb
Osobně mám za cíl nemuset mít firewall žádný, tedy mít nainstalované pouze služby, které musí být dostupné (jejich porty by se ve fw stejně povolily) a zbytek, pokud je nutný, mít nastavený třeba přes unix socket apod. Potom není fw potřeba, povoloval by vlastně stejně vše, co na daném portu poslouchá. Myslím si, že při dobře nastavených a zabezpečených službách není fw potřeba.
instalace základních nástrojů (mc, htop, emacs, java, pv, socat… podle využití serveru)
Od tohoto jsem upustil. Každý server má jiné využití a jinou sadu "základních nástrojů", je tedy zbytečné je tam instalovat dopředu. Jak bude potřeba, on si je admin stejně během pár sekund nainstaluje. Tzn. každý z těch serverů po čase dokonverguje k nějaké vlastní sadě nainstalovaných nástrojů.
…které musí být dostupné (jejich porty by se ve fw stejně povolily)Některé(většinu) služby instaluji, ale porty neotvírám - je třeba si ssh-tunelovat ANEBO jsou porty na fw povolené jen odněkud či někam.
Od tohoto jsem upustil.Nechtělo se mi to komentovat, ale taky tak, začnu s naprostým minimem a u každého nově instalovaného balíku se krátce zamyslím „opravdu je to třeba!?“.
To je pravda, nesmí se to přehánět, ale třeba ten mc
a htop
jsem zvyklý mít všude. Stejně tak pv
se dříve či později hodí. Naopak tu Javu nemám všude (taky tam píšu podle využití serveru). Editor je otázka osobních preferencí…
Některé(většinu) služby instaluji, ale porty neotvírám - je třeba si ssh-tunelovatProč je nenecháš poslouchat jen na loopbacku?
To můžu taky, (jako dvojitá ochrana). Ale jinak mi přijde flexibilnější to řídit na fw „odkud na co“.
A taky se cítím klidnější, bo pokud jsem danou službu blbě nastavil neprojde to přes fw.Každý server má jiné využití a jinou sadu "základních nástrojů", je tedy zbytečné je tam instalovat dopředu.Záleží na tom, o jakých nástrojích tu mluvíme. Třeba instalovat tcpdump, abys zjistil, proč ti nejde síť, když ti nejde síť...
Problém nastáva, keď má na serveri viac ľudí konto. Síce nič na porte nižšom ako 1024 nespustia, pokiaľ neuhádnu heslo na root-a, ale na ostatných portoch môžu spúšťať čo len chcú, pokiaľ to neobmedzíš pomocou FW.V podstatě +- stejné, až na:
firewall zakazující všechno, kromě explicitně uvedených služebOsobně mám za cíl nemuset mít firewall žádný, tedy mít nainstalované pouze služby, které musí být dostupné (jejich porty by se ve fw stejně povolily) a zbytek, pokud je nutný, mít nastavený třeba přes unix socket apod. Potom není fw potřeba, povoloval by vlastně stejně vše, co na daném portu poslouchá. Myslím si, že při dobře nastavených a zabezpečených službách není fw potřeba.
/etc/apt/apt.conf.d/20recommends
APT { Install-Recommends "false"; };
Tiskni
Sdílej: