Knihovna FFmpeg byla vydána ve verzi 8.0 „Huffman“. Přibyla mj. podpora hardwarově akcelerovaného kódování s využitím API Vulcan, viz seznam změn.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) vydal Zprávu o stavu kybernetické bezpečnosti ČR za rok 2024 (pdf). V loňském roce NÚKIB evidoval dosud nejvíce kybernetických bezpečnostních incidentů s celkovým počtem 268. Oproti roku 2023 se však jedná pouze o drobný nárůst a závažnost dopadů evidovaných incidentů klesá již třetím rokem v řadě. V minulém roce NÚKIB evidoval pouze jeden velmi významný incident a významných incidentů bylo zaznamenáno 18, což oproti roku 2023 představuje pokles o více než polovinu.
Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie). Servo mimo jiné nově zvládne animované obrázky APNG a WebP.
Na chytré telefony a počítačové tablety v Rusku bude od začátku příštího měsíce povinné předinstalovávat státem podporovanou komunikační aplikaci MAX, která konkuruje aplikaci WhatsApp americké společnosti Meta Platforms. Oznámila to dnes ruská vláda. Ta by podle kritiků mohla aplikaci MAX používat ke sledování uživatelů. Ruská státní média obvinění ze špehování pomocí aplikace MAX popírají. Tvrdí, že MAX má méně oprávnění k přístupu k údajům o uživatelích než konkurenční aplikace WhatsApp a Telegram.
Společnost PINE64 stojící za telefony PinePhone nebo notebooky Pinebook publikovala na svém blogu srpnový souhrn novinek. Kvůli nedostatečnému zájmu byla ukončena výroba telefonů PinePhone Pro.
Po pěti měsících vývoje byla vydána nová verze 0.15.1 programovacího jazyka Zig (GitHub, Wikipedie). Verze 0.15.0 byla přeskočena. Přispělo 162 vývojářů. Přehled novinek v poznámkách k vydání.
Před sedmi lety společnost Valve představila fork projektu Wine s názvem Proton umožňující v Linuxu přímo ze Steamu hrát počítačové hry do té doby běžící pouze ve Windows. Aktuální přehled podporovaných her na stránkách ProtonDB
Společnost DuckDuckGo rozšířila svůj AI chat Duck.ai o GPT-5 mini (𝕏). Duck.ai umožňuje anonymní přístup bez vytváření účtů k několika modelům umělé inteligence. Aktuálně k GPT-4o mini, GPT-5 mini, Llama 4 Scout, Claude Haiku 3.5 a Mistral Small 3.
Marek Tóth v příspěvku DOM-based Extension Clickjacking: Data ve správcích hesel v ohrožení na svém blogu popsal novou clickjacking techniku s několika variantami útoků a otestoval ji proti 11 správcům hesel. Výsledkem bylo nalezení několika 0-day zranitelností, které mohly ovlivnit uložená data desítek milionů uživatelů. Jedno kliknutí kdekoliv na webové stránce kontrolované útočníkem umožňovalo ukrást uživatelská data ze
… více »Na dnešní akci Made by Google 2025 (YouTube) byly představeny telefony Pixel 10 s novým čipem Google Tensor G5 a novými AI funkcemi, hodinky Pixel Watch 4 a sluchátka Pixel Buds 2a.
Původně se měl tento blogpost jmenovat: "Proč spolu openvswitch a systemd neka..?", ale podařilo se mi to lousknout, tak bych tady chtěl popsat v čem spočíval problém, než to - jako obvykle - zapomenu.
U "staršího" clusteru Peanuts, na kterém jsem rozjížděl openvswitch zhruba před necelým rokem, jsem řešil konfiguraci sítě takto...
root@stroj:~# cat /etc/network/interfaces auto eth0 iface eth0 inet manual up ip link set $IFACE up down ip link set $IFACE down auto interni iface interni inet static pre-up service openvswitch-switch start address 10.0.0.214 netmask 255.255.255.0 broadcast 10.0.0.255
Vyžaduje to však aby již byl předem vytvořený bridge interni se "zapojeným" síťovým zařízením eth0:
root@stroj:~# ovs-vsctl show 458eb0ea-1825-40de-8e3b-028ea61c0faf Bridge interni Port interni Interface interni type: internal Port "eth0" Interface "eth0" ovs_version: "2.1.0"
U strojů clusteru Schrot jsem ale narazil na problém, že s touto konfigurací systém vůbec nenajížděl. Při startu končilo spouštění při konfiguraci sítě v nekonečné smyčce - viz snímek:
Nezbylo, než přidat do parametrů jádra při zavádění break
, najet do ramdisku, namountovat systémový disk a laborovat se souborem /etc/network/interfaces
.
Jak se metodou pokus/omyl ukázalo, příčinou problému byl následující řádek v souboru /etc/network/interfaces
:
... pre-up service openvswitch-switch start ...
Po jeho zakomentování systém normálně najel, ale bez nahozeného portu interni.
Vrtalo mi hlavou proč, až mě napadlo podívat se, zda-li je u systémů staršího clusteru Peanuts nainstalován systemd. Samo že nebyl. Odinstaloval jsem ho, a voilá! Začalo to fungovat.
Síťová konfigurace Schrotu je ale oproti staršímu clusteru Peanuts složitější v tom směru, že jeho stroje lezou ven pouze prostřednictvím jediného nodu. Aby je bylo možné spravovat přes Puppet, musí mít nastavenou maškarádu a povolený forwarding na vnější a vnitřní síťové rozhraní.
Vytvořil jsem tedy jednoduchý skript /etc/network/if-up.d/iptables
, který se stará o zavedení pravidel pro iptables a do souboru /etc/sysctl.conf
přidal následující dva řádky:
net.ipv4.conf.eth0.forwarding=1 net.ipv4.conf.interni.forwarding=1
Ale ouha! Při startu je akceptováno pouze nastavení pro eth0. Nikoliv pro port interni. Mohl bych sice forwarding povolit jedním parametrem pro všechna rozhraní najednou, to však nepovažuji řešení. Také jsem nebyl spokojen s odinstalováním systemd což nelze považovat za vyřešení problému. Když je s ním schopen koexistovat Pacemaker, tak to musí být řešitelné pro openvswitch.
Při hledání řešení pro NAT jsem narazil v ukázkové konfiguraci souboru /etc/network/interfaces
na parametr allow-ovs
. Nakouknul jsem tedy do souboru /usr/share/doc/openvswitch-switch/README.Debian.gz
, upravil podle něj příslušným způsobem konfiguraci, doinstaloval systemd a restartoval.
root@stroj:~# cat /etc/network/interfaces allow-ovs interni iface interni inet static address 10.0.0.214 netmask 255.255.255.0 broadcast 10.0.0.255 ovs_type OVSBrid ovs_ports eth0 allow-interni eth0 iface eth0 inet manual ovs_bridge interni ovs_type OVSPort
Jak už jsem poznamenal - při konfiguraci rozhraní virtuálního switche je klíčový parametr allow-ovs
, kterým se aktivuje síťové rozhraní bridge v ukázkovém příkladu s názvem interni. Kromě obvyklé síťové konfigurace, může obsahovat každá příslušná položka virtuálního switche parametr ovs_type
, jimž se implicitně říká, o jaký typ zařízení jde (zda bridge nebo port). A v případě, že se u bridge mají hned po startu nahodit i některé porty parametr ovs_ports
s jejich seznamem.
U konfigurace portu (síťového rozhraní) se parametrem allow-interni
implicitně řekne, do kterého bridge port patří a tím dojde při spuštění bridge i k jeho nahození.
Tiskni
Sdílej:
TimeoutSec=0
, tj. nekonečný timeout.
samba
, ntpd
a dnsmasq
. Postinst skript prostě udělá /etc/init.d/služba restart a služba si to vyloží jako že se má spustit, i když neběží a byla zakázána (přes update-rc.d služba remove
).
Výsledná konfigurace je vedlejší produkt hledání řešení jiného problému - povolení forwardingu pro virtuální interface.to mi připomíná tenhle čerstvě spravenej bug - při dostatečně novým jádru a userlandu by to tím pádem už mohlo fungovat všude i bez zvláštních obezliček.
Chtěl jsem tomu dát šanci, protože jinak proti systemd vcelku nic nemám. Jenže za současného stavu by to znamenalo jen další opruz navíc.Já tomu trochu času navíc věnuju, protože používám systemd na gentoo, kde taky ještě zdaleka není doma.
To ovšem sebou nese zase další zpoždění, neboť se snažím ze svých stávajících masterů postupně vydestilovat univerzálně použitelné moduly.Jo to dává smysl.
pre-up service openvswitch-switch startHádám, že tímto vzniknul deadlock. Jelikož systemd dodržuje závislosti služeb mezi sebou, tak spouštění služby z jiné služby je k tomu náchylné. Příkaz service čekal, až openvswitch-switch nastartuje. Ten ale místo startování čekal ve frontě, až doběhne jiná služba, na níž má pořadní závislost. Pokud je skutečně zapotřebí spouštět služby z jiných služeb, hodí se použít
systemctl
s parametrem --no-block
nebo --ignore-dependencies
.
Pokud je skutečně zapotřebí spouštět služby z jiných služeb, hodí se použít systemctl s parametrem --no-block nebo --ignore-dependencies.Za
--no-block
jsem dostal od Michala Sekletára vynadáno a měnil jsem to na --ignore-dependencies
. Na druhou stranu takové neblokující volání už nebude ani v nejmenším pre-up
, takže to nejde použít. Ale --ignore-dependencies
normálně blokuje, ne, takže to by mělo případně fungovat, že?
Nevím jestli je to bug nebo feature, ale doufám, že už to opravili.Hláška dne.
Virtuální infrastruktura.
Takhle kupříkladu vypadá konfigurace, jakou můj agent pro Pacemaker zpracovává když spouští virtuální disklessový stroj postel.felk.cvut.cz
primitive postel ocf:dce:kvm \ params workdir="/root" binfile=qemu-system-x86_64 \ ifup="/etc/openvswitch/ovs-ifup" \ ifdown="/etc/openvswitch/ovs-ifdown" \ cpu=kvm64 memory=4096 monitor="/tmp/7013.monitor" \ nic="00:0f:b0:46:23:89,virtio,tap,main,17 00:0f:b0:47:23:89,virtio,tap,main,5" \ serial="file:/var/log/postel.serial" logfile="/var/log/postel.log" \ pidfile="/var/run/kvm_postel.pid" \ errlogfile="/var/log/postel.err" \ meta target-role=Started is-managed=true \ op monitor interval=20 \ op start interval=0 timeout=30 \ op stop interval=0 timeout=30
Skript /etc/openvswitch/ovs-ifup
se stará o nahození virtuálního portu a skript /etc/openvswitch/ovs-ifdown
zase o jeho zrušení, když Pacemaker stroj vypne. Zařazení virtuálního portu do příslušného bridge a vlan se řeší zpracováním záznamů v parametru nic.