Společnost Murena představila (YouTube) novou verzi 4.0 mobilního operačního systému /e/OS (Wikipedie) založeného na Androidu a LineageOS bez aplikací a služeb od Googlu.
V Arch User Repository (AUR) bylo kompromitováno přes 400 opomíjených balíčků (jejich seznam). Útočník do nich začlenil škodlivý npm balíček atomic-lockfile, který krade citlivá data uživatelů. Publikována byla předběžná analýza spouštěného malwaru deps.
Homebrew, správce balíčků nejen pro macOS, byl vydán ve verzi 6.0.0 (seznam změn). Hlavními novinkami jsou bezpečnostní mechanismus tap trust kvůli důvěryhodnosti závislostí, vylepšení sandboxingu na Linuxu, interní JSON API nebo zlepšení výkonu.
Byla nalezena a 9. června opravena kritická zranitelnost ve FreeBSD v Kernel TLS (KTLS). Pojmenována byla Bumsrakete (FreeBSD-SA-26:26.ktls, CVE-2026-45257). Lokální neprivilegovaný uživatel může přepisovat soubory, ke kterým má právo pouze pro čtení. Přepsáním setuid binárky a jejím spuštěním může získat roota. Na všech verzích od verze 13.0 vydané v dubnu 2021.
Vývojáři open source operačního systému ReactOS (Wikipedie), jehož cílem je kompletní binární kompatibilita s aplikacemi a ovladači pro Windows, se na síti 𝕏 pochlubili, že ReactOS zvládne počítačovou hru Half-Life.
Byla vydána nová verze 4.8 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Využíván je Free Pascal Compiler (FPC) 3.2.2.
Apple container dospěl do verze 1.0.0. Jedná se o open source nástroj pro spouštění linuxových kontejnerů na macOS postavený nad containerization. Napsaný je v programovacím jazyce Swift a optimalizovaný pro Apple silicon.
Bylo vydáno Eclipse IDE 2026-06 aneb Eclipse 4.40. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
Asterinas (GitHub) je v Rustu napsané jádro operačního systému poskytující s jádrem Linux kompatibilní ABI. Vydána byla verze 0.18.0. První distribucí postavenou nad jádrem Asterinas je Asterinas NixOS. Nejedná se o oficiální projekt NixOS a nemá nic společného s NixOS Foundation.
Podrobně byla rozebrána kritická zranitelnost v nf_tables (CVE-2026-23111). Další lokální eskalace práv na Linuxu. V upstreamu byla zranitelnost již v únoru opravena. Ve zdrojovém kódu stačilo odstranit 1 vykřičník.
Proč chcete zrovna specifický turorial pro Ubuntu? Raději si přečtěte něco o tom, co to vlastně VLAN je a jak to funguje, pak se podívejte do dostatečně nové dokumentace k příkazu ip (nebo starší k vconfig), jak se to konfiguruje, a máte vystaráno.
Ve výsledku to bude mnohem užitečnější - nebo jste si snad stoprocentně jistý, že nikdy s jinou distribucí do kontaktu nepřijdete? Z konfigurace specifické pro Ubuntu vás může nanejvýš zajímat to, jestli lze použít jeho startovací skripty a konfigurační soubory nebo jestli si budete muset napsat vlastní skript.
VLAN je to samé jako druhá síťovka. Provoz se routuje tam, kam ho pošlou routovací pravidla (ip route). VLAN samozřejmě můžete i bridgovat, ale pokud bridgujete mezi VLANy na stejném rozhraní, tak je dost zbytečné vůbec ty VLANy vytvářet.
To záleží, jak jsou ty virtuály emulované, třeba s OpenVZ máte smůlu, ale v KVM můžete provozovat cokoliv včetně VLANů. Ale na tohle úplně stačí tomu jednomu virtuálu emulovat dvě síťovky a pak to na hostiteli akorát vhodně pospojovat.
Pokud si správně pamatuju, tak takovéto standardní pořadí by mělo být, že se naspodu udělá bonding (pokud je potřeba), nad ním se vytvoří vlany, aby se člověk připojil ke správným virtuálním sítím, a nad nimi se vytváří bridge, do kterého se pak zapojí virtuální síťovky.
Ano, to je nejobvyklejší konfigurace, ale už jsem viděl i různé jiné, třeba to, že se bonding skládal až uvnitř guesta (dokonce i když šlo o Xen, kde tím člověk přijde o MII monitor). Takže asi opravdu bude lepší, když tazatel napíše, čeho chce vlastně docílit.
Když jsem to tady řešil na fóru, tak se kolegové chytali za hlavu, že se to tak vůbec nedělá a že si mám udělat nějaký VLAN pro všechny VM, povolit IP FORWARDING a L3 strukturu a do něj nějak zapojit ty VM. Celkem jsem to nepochopil, ale chtěl bych se poučit a mít to správně, ať se třeba někdy někdo nezděsí, kdyby se v tom musel hrabat po mě.
Takže to je to, čeho bych chtěl dosáhnout. A kdyby to navíc fungovalo, tak by to bylo super. Moje řešení je sice asi prasácké, ale na všechny VM se dostanu tak, jak potřebuju, i z venku, jen mám brouka v hlavě, že to není podle nějaké koncepce.
VM1 s IP 10.0.10.11 je na routeru vystrčený do DMZMluvíš na mě skoro čínsky. Teda přesněji řečeno jazykem čínských krabiček, kde se pojem DMZ používá dost podivně. Správný krok by byl požádat poskytovatele o IP adresy. Když už musíš nutně NATovat jednu veřejnou IP (nastavovat port forward), tak to dělej stroji, který má tu veřejnou IP. V tomhle setupu nevidím pro VLAN žádné použití.
Takže to je to, čeho bych chtěl dosáhnout. A kdyby to navíc fungovalo, tak by to bylo super. Moje řešení je sice asi prasácké, ale na všechny VM se dostanu tak, jak potřebuju, i z venku, jen mám brouka v hlavě, že to není podle nějaké koncepce.O tom, jak to máš udělané, bych si netroufl říct, že to funguje. Serveru bez IP adresy neříkám z venku dostupný server.
DMZ je demilitarized zone
Což o to, tu zkratku znám a nepochybuji, že ji zná i pavlix…
a na toto interní IP router směruje veškerý provoz z venčí, nemá-li jiné pravidlo ve vlastním NAT.
…ale tohle zcela určitě neznamená. Nešlo by se té "krabičky od O2" zbavit a dát místo ní něco, co se dá nakonfigurovat příčetně?
Tiskni
Sdílej: