Otevřená certifikační autorita Let’s Encrypt v příspěvku na svém blogu představila své nové databázové servery. Hardware: 2U rack server Dell EMC PowerEdge R7525, CPU 2x AMD EPYC 7542, Memory 2TB 3200MT/s, Storage 24x 6.4TB Intel P4610 NVMe SSD. Software: OpenZFS a MariaDB s InnoDB.
Článek systemd pro vývojáře: lokální vývojové servery v systemd na MojeFedora.cz doporučuje vývojářům používání systemd k ovládání svých projektů pomocí "systemctl --user".
Vyšla nová verze souborového manažera Midnight Commander 4.8.26. Mezi hlavní novinky patří zachování obsahu příkazové řádky při přepínání panelů pomocí Ctrl+O, stíny okolo dialogových oken jako v Norton Commanderu a dalších (vytvořeno autorem zprávičky), podpora jakkoli dlouhých názvů souborů a spousta dalších drobnějších věcí.
Projekty Elasticsearch a Kibana změní s verzí 7.11 licenci. Už se nebude jednat o open source software. Důvodem změny licence byl spor se společností AWS (Amazon Web Services). AWS na změnu licence odpovídá vlastním forkem. Vycházet bude z verze 7.10 a zůstane pod open source licencí Apache.
Lidé ze společnosti Corellium se včera na Twitteru pochlubili screenshotem Ubuntu na Apple Siliconu aneb zprovoznili Ubuntu na počítači Apple s novým ARM procesorem M1. CTO jej už používá k vývoji ve svém herním křesle s 49 palcovým monitorem. Dnes byly na blogu Corellium publikovány detaily a pro případné zájemce i návod a obraz ke stažení. Upravili obraz Ubuntu pro Raspberry Pi.
Rodina počítačů Raspberry Pi se rozšířila o jednočipový počítač Raspberry Pi Pico v ceně 4 dolary s vlastním procesorem RP2040. Představení na YouTube.
Společnost Red Hat na svém blogu oznámila, že Red Hat Enterprise Linux (RHEL) bude možné provozovat zdarma na 16 serverech.
Pod společným názvem DNSpooq byly zveřejněny informace o 7 bezpečnostních chybách v DNS caching a DHCP serveru dnsmasq. Jedná se o cache poisoning (CVE-2020-25686, CVE-2020-25684, CVE-2020-25685) a buffer overflow (CVE-2020-25687, CVE-2020-25683, CVE-2020-25682, CVE-2020-25681). Jejich kombinací lze dosáhnout závažnosti CVSS 9.8. Chyby jsou opraveny v dnsmasq 2.83.
Byla vydána nová stabilní verze 19.07.6 (Changelog) linuxové distribuce primárně určené pro routery a vestavěné systémy OpenWrt (Wikipedie). Řešena je také řada bezpečnostních chyb. Především v dnsmasq (DNSpooq).
Google Chrome 88 byl prohlášen za stabilní (YouTube). Nejnovější stabilní verze 88.0.4324.96 přináší řadu oprav a vylepšení. Vylepšeny byly také nástroje pro vývojáře (YouTube). Opraveno bylo 36 bezpečnostních chyb. Nálezci nejvážnější z nich (CVE-2021-21117) bylo vyplaceno 30 000 dolarů.
Zdá se, že už vůbec ničemu nerozumim... Mám následující problém:
V jednom počítači mám 2 síťové karty, eth0 a eth1. Obě dvě jsou funkční, alespoň samostatně. Když nastavim eht0 ip na 192.168.1.2 a eth1 na 192.168.1.3 (maska 255.255.255.0) tak funguje ale jenom eth0 a to na obou ip adresách, tzn 192.168.1.2 i 192.168.1.3!!!
Obě síťovky jsou dle výpisu ifconfig "UP" a maj každá svou IP adresu. Ta "nefunkční" po pokusu o připojení přes toto rozhraní vykazuje pár (asi 10-20) přijatých packetů, odeslané žádné. V žádném logu žádná chybová hláška, kde může bejt chyba?
To že funguje jenom jedna a na obou adresách je empiricky ověřeno. Taky si to naprosto nedovedu vysvětlit...
Dvě síťovky ve stejný síti ve stejnym PC jsou proto, že zatim žádná jiná síť neexistuje. V dohledný době by tenhle počítač měl sloužit jako router do internetu, proto ty dvě síťovky, ale zatim mi slouží jenom jako server na vývoj php aplikací.
Nicméně to, že to neni standartní situace, by ještě nemělo znamenat, že to nebude fungovat, ne? Jde mi prostě jenom o to, abych sem se mohl k tomuhle "serveru" připojit přes obě dvě síťovky
Směrování nemám zprovozněno žádný, to je pravda. Funguje mi ale zároveň například ppp a eth0, takže na to, abych měl dvě na sobě nezávyslé rozhraní(tzn. nepotřebuju se z vnitřní síťe dostat ven skrz ppp) směrování přece nepotřebuju, ne?
Hlavně je to principiálně blbě.
192.168.1.2/255.255.255.0 a 192.168.1.3/255.255.255.0 je obojí ze stejného IP subnetu a dost dobře nejde to mít na dvou různých eth zařízeních a čekat jakékoliv smysluplné chování.
Řešení problému: použít adresy z různých subnetů 
Podrobnější popis řešení: není k dispozici, pokud nevíme, co se od toho čeká
Ano, tohle mě taky napadlo, že by mohl bejt problém s tím, že je to obojí stejná síť, na druhou stranu jsem si řekl, že neznám důvod, proč by to takhle nemohlo fungovat. Můžete mi tedy někdo prosím podrobně vysvětlit, proč to nejde?
Takže musíme nastavit routování aby veděl na kterou sítovku to má poslat, což je zbytečné nastavovat stačí jak použijeme správné masky a správné rozdělení do sítí a nemusíme se o nic vice potom starat.
Díky. Tohle zní logicky. Jenom bych předpokládal, že si automaticky vybere tu, ve který je zrovna zastrčenej kabel
Vybere si tu, která najela jako první. Zkuste ty síťovky obě shodit a pak nahodit v pořadí eth1 a eth0. Pak bude komunikovat jen přes eth1.
Když vypnete rp_filter, v zásadě vytvoříte simplexní hub
Nejde to proto, protože když najede eht0, jádro si vytvoří v routovací tabulce záznam typu:
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.2
Vytvori se (interni) routovaci zaznam pro celou sit 192.168.1.0/24, ktery se uz NEZMENI pri najizdeni eth1. Cili jadro bude vsechno pro tuto sit routovat vzdy jen pres eth0. Prichozi provoz z eth1 vam zahodi rp_filter a i kdybyste jej vypnul, odpoved stejne odejde na eth0.
Díky všem za vysvětlení, proč to takhle nejde
Až bude druhá síť, tak to nastavim, do tý doby prostě jednu síťovku "vypnu".
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz