godot blogja

Egy jó kis összefoglaló a Cumulus-tól:

https://docs.cumulusnetworks.com/cumulus-linux-42/Network-Solutions/Dat…

Adja magát a kérdés,hogy melyiket érdemes választani, ha a klasszikus "Traditional Spanning Tree" megoldásról kellene elmozdulni, és tegyük fel, hogy olyan switcheink vannak, amik tudnak VXLAN,EVPN-t és MLAG-ot is.

L2-MLAG felé hajlok, mert az egyszerű.

Azonban az okosok azt mondják, hogy valamelyik Layer 3 megoldás a tuti. A hypervisoron nem lehet BGP-t futtatni. De VM-ben pl elképzelhető (Layer-3 Routing on the VM szkenárió).

Vagy mindjárt az űrfegyver bonyolultságú EVPN+VXLAN-t válasszuk.

Nem kell extrém skálázhatónak lennie az egésznek tehát néhány tucat hypervisor 1000 körüli vm szám mondjuk.

Az AT&T kiadta a DANOS nevű Network Operating System forráskódját.

https://access.redhat.com/security/vulnerabilities/mds?sc_cid=701f20000…;
https://blog.ubuntu.com/2019/05/14/ubuntu-updates-to-mitigate-new-micro…

https://www.intel.com/content/www/us/en/security-center/advisory/intel-…
https://www.intel.com/content/dam/www/public/us/en/documents/corporate-…
https://software.intel.com/security-software-guidance/insights/deep-div…

Sok disztribúció a következő verzióban már nftables-t fog használni iptables helyett.
Az átállásnak több módja van. Debian Buster-ben az iptables-nft fog az iptables-re mutatni (alternatives), ami azt jelenti, hogy amikor az iptables parancsokat kiadod, akkor valójában azok nft ruleokká konvertálódnak.
Lásd: https://wiki.nftables.org/wiki-nftables/index.php/Moving_from_iptables_…

Mindaddig nincs is baj ezzel,amíg csak olyan matchereket használsz amik léteznek iptables-ben és nftables-ben is. Azonban például az iptables-ben létező ipsec policy matchnek a Debian Buster által szállított 4.19-es kernelben nincs 100%-os megfelelője.

Megjött a megrendelt eszköz.

Az első meglepetés, hogy nem működik 12V-os adapterrel. Minimum 16V kell neki. A specifikáció gyakorlatilag nem említi, hogy a DC jack-en milyen feszültséget vár az eszköz.

Az OpenBSD csomagszűrője bináris logformátumot (tcpdump link-type PFLOG ) használ, de legtöbbször szükség van a logüzenetek syslog formátumban történő tárolására és/vagy továbbküldésére (valós időben akár) egy központi logszervernek/logfeldolgozónak.

Az alábbiakban egy lehetséges megoldást prezentálok, nem mellesleg kipróbálom a 3.0-ás syslog-ng parser és rewrite opcióit is.

Az OpenBSD-ben jelenleg csomagban/ports fában 2.1-es syslog-ng van, úgyhogy a 3.0-át kézzel fordítottam. A hogyanra most nem térek ki.

Egy pf log üzenet pl. így néz ki:

Úgy látszik, hogy a GPLv3 licensz nem zavarja a fejlesztőket.

http://leaf.dragonflybsd.org/mailarchive/commits/2009-08/msg00015.html