Laboratoře CZ.NIC vydaly novou verzi 4.16.0 aplikace Datovka, tj. svobodné multiplatformní desktopové aplikace pro přístup k datovým schránkám a k trvalému uchovávání datových zpráv v lokální databázi. Nově je pro překlad aplikace potřeba použít knihovnu libdatovka. Ta byla vydána ve verzi 0.1.0.
Brian Exelbierd, zástupce Red Hatu v představenstvu distribuce CentOS, poskytl rozhovor webu The Register. Ukončení vydávání CentOS jako sestavení RHEL vysvětluje tak, že Red Hat ho odmítl nadále sponzorovat. Dále hovoří o roli a omezeních nového bezplatného vydání RHEL.
Balíček s utilitou sudo byl vydán ve verzi 1.9.5p2. Řešena je bezpečnostní chyba CVE-2021-3156. Lokální uživatel může získat práva roota i když není uveden v souboru sudoers. Podrobnosti i s videoukázkou v příspěvku na blogu společnosti Qualys. Chyba byla do kódu sudo zanesena na konci července 2011 (commit 8255ed69). Týká se tedy verzí 1.8.2 až 1.8.31p2 a 1.9.0 až 1.9.5p1.
Společnost Backblaze zveřejnila statistiky spolehlivosti pevných disků používaných ve svých datových centrech za rok 2020. Ke konci roku vlastnila 165 530 pevných disků. V průběhu roku jich přibylo 39 792. Průměrná AFR (Annualized Failure Rate), tj. pravděpodobnost, že disk během roku selže, klesla na 0,93 %. V roce 2019 to bylo 1,89 %. V roce 2018 to bylo 1,25 %. V roce 2017 to bylo 1,77 %. V roce 2016 1,95 %.
Dle plánu byl vydán Mozilla Firefox 85.0. Přehled novinek v poznámkách k vydání, poznámkách k vydání pro firmy a na stránce věnované vývojářům. Přibyla ochrana před supercookies. Odstraněna byla podpora Flashe. Řešeny jsou také bezpečnostní chyby. Nejnovější Firefox je již k dispozici také na Flathubu.
Byla vydána nová verze 4.15 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl aktualizován na verzi 10.0.9. Thunderbird byl aktualizován na verzi 78.6.0. Linux byl aktualizován na verzi 5.9.15.
Projekt Mozilly MDN Web Docs dokumentující webové standardy včetně jejich podpory v jednotlivých prohlížečích byl loňským propouštěním citelně zasažen. Poté, co se obsah MDN přesunul na GitHub, čímž se z určitého pohledu více otevřel pro přispívání z řad webových vývojářů, vznikla nová organizace Open Web Docs. Na Open Collective už má přes 60 finančních přispěvatelů a největší mezi nimi jsou Google, Microsoft a Coil. Dále se do projektu zapojuje samozřejmě Mozilla, Samsung a W3C [Mozilla.cz].
Od verze 7.1 (vyjde na začátku února) bude mít LibreOffice přívlastek Community - přesný název tedy bude LibreOffice Community 7.1. Kromě názvu se nic nemění, nedochází k omezování funkcí apod. Přejmenování je výsledek dlouhých diskuzí nad novým marketingovým plánem a snahou odlišit komunitní a firemní verze LibreOffice. Vznikají také další nové pojmy: LibreOffice Technology - brand pro veškerý software založený na LibreOffice a LibreOffice Enterprise - pro partnery ekosystému a jejich enterprise verze LibreOffice.
Umělec a designer Rocky Bergen má na svých stránkách volně ke stažení papírové modely počítačů Amiga 500, Amstrad CPC 464, Apple II a dalších. Čtenáři AbcLinuxu na ně jistě dokážou dostat i Linux. :-)
OctoPi, linuxová distribuce pro Raspberry Pi s předinstalovaným webovým rozhraním pro ovládání 3D tiskáren OctoPrint, byla vydána ve verzi 0.18.0. Přehled novinek v oznámení na blogu a na GitHubu.
Dobrý den, řeším v práci problém s nedostatkem IP adres. Proto jsem přistoupil k nastavení dhcp serveru a rozdělení sítě do 2 podsítí (192.168.0.1/24 + 192.168.10.1/24) Podařilo se mi server přes direktivu POOL nastavit tak, že IP jsou přidělovány do příslušných podsítí, ale nastal problém. Druhá podsíť (192.168.10.1/24) nemá přístup do Internetu ani do sítě. Příkaz ping neprojde ani do brány.
Nastavení DPCP je podle tohoto vzoru:
class "mojepc" {
match hardware;
}
subclass "mojepc" 1:xx:xx:xx:xx:xx:xx; # host2
subclass "mojepc" 1:yy:yy:yy:xx:xx:xx; # host3
authoritative;
shared-network "moje-sit"
subnet 192.168.1.0 netmask 255.255.255.0 {
option-routers, option-domains atd.
pool {
allow-members of "mojepc";
boot-unknown clients false;
range 192.168.1.101 192.168.1.250;
host1 {
hardware ethernet xx:xx:xx:xx:xx:xx;
fixed-address 192.168.0.2;
}
takto vyjmenovaná další známá pc .......
}
subnet 192.168.10.0 netmask 255.255.255.0 {
option-routers, option-domains atd.
pool {
deny-members of "mojepc";
boot-unknown clients true;
range 192.168.10.2 192.168.10.255;
}
Myslím si, že problém je někde v routování - při výpisu příkazu route -n podsíť 192.168.10.1/24 v seznamu vůbec nefiguruje. Za jakoukoliv radu budu rád. Díky
Řešení dotazu:
řeším v práci problém s nedostatkem IP adres. Proto jsem přistoupil k nastavení dhcp serveru a rozdělení sítě do 2 podsítí (192.168.0.1/24 + 192.168.10.1/24)
Mohl byste tuhle úvahu nějak blíže osvětlit?
hardware ethernet xx:xx:xx:xx:xx:xx;
Paranoia není v zásadě špatná věc, ale měla by být podložená aspoň nějakou úvahou. Jaký smysl má podle vás tajit MAC adresy?
option-routers, option-domains atd.
Tady už začínám mít neodbytný pocit, že si z nás děláte legraci. Chcete po nás, abychom vám poradili, proč se ty stroje nikam nedostanou, a neobtěžujete se nám ani říct, co jim vlastně posíláte za routu/routy?
Myslím si, že problém je někde v routování - při výpisu příkazu route -n podsíť 192.168.10.1/24 v seznamu vůbec nefiguruje.
Pominu-li, že za pár měsíců to bude už 20 let, co je příkaz route
obsolete, zapomněl jste napsat, kde jste ho vlastně spouštěl. Na DHCP serveru? Na routeru? Na jedné z těch stanic?
1) Na mojí sítí je momentálně potřeba připojit více než 300 zařízení. Nevím jak jinak tuto situaci vyřešit než rozdělením jedné podsítě na několik podsítí a tím získat větší adresní prostor. Pokud máte jiné řešení rád si ho vyslechnu.
2) MAC adresa skrytá pod xx:xx:xx:xx:xx:xx je 00:27:0E:13:8C:56. Má znalost přesné MAC adresy nějaký zásadní vliv na vyřešení problému?
3) Ne legraci si opravdu nedělám, jak jsem již výše zmínil myslel jsem, že jsem situaci popsal správně. Co přesně bych měl ještě popsat ? DHCP server = router a zde jsem příkaz spouštěl. Výpis je zde:
Je to lepší popis situace ?Směrovací tabulka v jádru pro IP Adresát Brána Maska Přízn Metrik Odkaz Užt Rozhraní 10.0.0.0 * 255.255.255.0 U 0 0 0 eth1 192.168.0.0 * 255.255.255.0 U 0 0 0 eth0 default 10.0.0.138 0.0.0.0 UG 0 0 0 eth1
192.168.0.0 * 255.255.255.0 U 0 0 0 eth0Takze bude zrejme potreba pridat staticke routy:
ip route add 192.168.1.0/24 dev eth0 ip route add 192.168.10.0/24 dev eth0nebo upravit masku eth0 na /16. Dale tento host:
fixed-address 192.168.0.2;nespada do zadneho subnetu:
subnet 192.168.1.0 netmask 255.255.255.0 subnet 192.168.10.0 netmask 255.255.255.0tudiz staticka rezervace nebude moc fungovat.. Pokud mas na DHCP i firewall/maskaradu hodilo by se aktualizovat pravidla.
Statické routy vyzkouším.
U klienta jsem se pouze překlepl při psaní dotazu ve skutečnosti má IP 192.168.1.2.
Firewall i maskaradu jsem aktualizoval - bez výsledku.
Na mojí sítí je momentálně potřeba připojit více než 300 zařízení. Nevím jak jinak tuto situaci vyřešit než rozdělením jedné podsítě na několik podsítí a tím získat větší adresní prostor. Pokud máte jiné řešení rád si ho vyslechnu.
Co třeba použít jinou délku prefixu než 24? Pokud nemáte jiný důvod, proč tu síť chcete rozdělit, bylo by to nejjednodušší. Pokud ho máte, stejně bude většinou lepší nemít ty dva rozsahy na stejném segmentu, ale použít buď fyzicky oddělené sítě nebo aspoň VLAN.
MAC adresa skrytá pod xx:xx:xx:xx:xx:xx je 00:27:0E:13:8C:56. Má znalost přesné MAC adresy nějaký zásadní vliv na vyřešení problému?
V tomto konkrétním případě pravděpodobně ne. Ale obecně mne irituje, když někdo chce pomoci a místo skutečných konfiguračních souborů a logů přikládá nějaké náhodně upravené verze, takže nemůžu vědět, čemu můžu věřit a co je vymyšlené.
Ne legraci si opravdu nedělám, jak jsem již výše zmínil myslel jsem, že jsem situaci popsal správně.
Tak ještě jednou: vy máte problém, který podle všeho souvisí s routováním, ale zatajíte před námi tu skoro nejdůležitější informaci, tedy co těm stanicím vlastně posíláte jako default gateway. A to je přesně ten problém, o kterém mluvím výše: místo abyste přiložil skutečný konfigurační soubor, předložíte nám nějakou náhodně editovanou verzi.
Směrovací tabulka v jádru pro IP Adresát Brána Maska Přízn Metrik Odkaz Užt Rozhraní 10.0.0.0 * 255.255.255.0 U 0 0 0 eth1 192.168.0.0 * 255.255.255.0 U 0 0 0 eth0 default 10.0.0.138 0.0.0.0 UG 0 0 0 eth1
Tohle je docela určitě špatně. Ten stroj má sloužit jako router pro 192.168.10.0/24, ale sám nemá žádnou adresu z toho rozsahu. Takže jestli ty stanice routují přes 192.168.10.1, tak jim router ani neodpoví na ARP dotaz. (Jestli jim posíláte 192.168.1.1, tak pro změnu samy nebudou vědět, kde to hledat.)
Navíc je dost zvláštní, že proti takové konfiguraci neprotestuje už ten dhcpd.
1) Jinou délku vyzkouším. A důvod je opravdu pouze v počtu připojených zařízení. Vlan používám. Přikládám výpis ifconfig:
eth0 Link encap:Ethernet HWadr 00:18:fe:81:62:66 inet adr:192.168.0.1 Všesměr:192.168.0.255 Maska:255.255.255.0 AKTIVOVÁNO VŠESMĚROVÉ_VYSÍLÁNÍ BĚŽÍ MULTICAST MTU:1500 Metrika:1 RX packets:13807588 errors:0 dropped:27 overruns:0 frame:0 TX packets:14505674 errors:0 dropped:0 overruns:0 carrier:0 kolizí:0 délka odchozí fronty:1000 RX bytes:6635499497 (6.1 GiB) TX bytes:13232214934 (12.3 GiB) Přerušení:16 eth1 Link encap:Ethernet HWadr 00:17:08:56:9a:a5 inet adr:10.0.0.1 Všesměr:10.0.0.255 Maska:255.255.255.0 AKTIVOVÁNO VŠESMĚROVÉ_VYSÍLÁNÍ BĚŽÍ MULTICAST MTU:1500 Metrika:1 RX packets:5820831 errors:0 dropped:0 overruns:0 frame:0 TX packets:4628744 errors:0 dropped:0 overruns:0 carrier:0 kolizí:0 délka odchozí fronty:1000 RX bytes:6636799283 (6.1 GiB) TX bytes:2277173429 (2.1 GiB) Přerušení:17 eth0.2 Link encap:Ethernet HWadr 00:18:fe:81:62:66 inet adr:192.168.10.1 Všesměr:192.168.10.255 Maska:255.255.255.0 AKTIVOVÁNO VŠESMĚROVÉ_VYSÍLÁNÍ BĚŽÍ MULTICAST MTU:1500 Metrika:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:201 errors:0 dropped:0 overruns:0 carrier:0 kolizí:0 délka odchozí fronty:0 RX bytes:0 (0.0 B) TX bytes:9246 (9.0 KiB) lo Link encap:Místní smyčka inet adr:127.0.0.1 Maska:255.0.0.0 AKTIVOVÁNO SMYČKA BĚŽÍ MTU:16436 Metrika:1 RX packets:300748 errors:0 dropped:0 overruns:0 frame:0 TX packets:300748 errors:0 dropped:0 overruns:0 carrier:0 kolizí:0 délka odchozí fronty:0 RX bytes:28712439 (27.3 MiB) TX bytes:28712439 (27.3 MiB)
2) Díky za upozornění, příště dám pozor. Neměl jsem v úmyslu nikoho rozlobit.
A důvod je opravdu pouze v počtu připojených zařízení.
V tom případě bych doporučil prostě použít větší rozsah.
Vlan používám.
Pokud byste pro ty vnitřní rozsahy opravdu používal vlan (tomu ale ve vaší konfiguraci zatím nic nenasvědčovalo), bylo by potřeba na routeru nejen mít adresu z každého z těch rozsahů (která by se použila jako gateway), ale také by ta adresa musela být na odpovídajícím vlan interface. A navíc nakonfigurovaný příslušný port switche, aby vám posílal všechny vlany a nativně (tj. žádný stripping/tagging). Pak by ale také nebyla potřeba sekce shared-network
a to třídění hostů, protože rozsah by byl dán rozhraním, na které přijde dotaz.
Stejně jako teď, jen použijete větší rozsah. Takže místo 192.168.0.1/24 si na svém rozhraní nastavíte třeba 192.168.0.1/22 a odpovídajícím způsobem nakonfigurujete i dhcpd, např.
subnet 192.168.0.0 netmask 255.255.252.0 { # leave 192.168.0.0/24 for static addresses range 192.168.1.0 192.168.3.254; option routers 192.168.0.1; ... }
Paranoia není v zásadě špatná věc, ale měla by být podložená aspoň nějakou úvahou. Jaký smysl má podle vás tajit MAC adresy?
Pochopitelně, že má. Když mě třeba někdo hackne a dá si MAC adresu do Googlu, tak si bude moci přečíst, co jak řeším, jaký level znalostí mám, atd..
Anebo i když mě třeba nehackne, ale bude se o to snažit a dostane se mu do ruky má MAC adresa.
A naopak není žádný důvod dávat pravou MAC adresu, protože to ničemu nepomůže.
Tiskni
Sdílej: