Singularity je rootkit ve formě jaderného modulu (Linux Kernel Module), s otevřeným zdrojovým kódem dostupným pod licencí MIT. Tento rootkit je určený pro moderní linuxová jádra 6.x a poskytuje své 'komplexní skryté funkce' prostřednictvím hookingu systémových volání pomocí ftrace. Pro nadšence je k dispozici podrobnější popis rootkitu na blogu autora, případně v článku na LWN.net. Projekt je zamýšlen jako pomůcka pro bezpečnostní experty a výzkumníky, takže instalujte pouze na vlastní nebezpečí a raději pouze do vlastních strojů 😉.
Iconify je seznam a galerie kolekcí vektorových open-source ikon, ke stažení je přes 275000 ikon z více jak dvou set sad. Tento rovněž open-source projekt dává vývojářům k dispozici i API pro snadnou integraci svobodných ikon do jejich projektů.
Dle plánu certifikační autorita Let's Encrypt nově vydává také certifikáty s šestidenní platností (160 hodin) s možností vystavit je na IP adresu.
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 14.0 (Mastodon). Forgejo je fork Gitei.
Just the Browser je projekt, 'který vám pomůže v internetovém prohlížeči deaktivovat funkce umělé inteligence, telemetrii, sponzorovaný obsah, integraci produktů a další nepříjemnosti' (repozitář na GitHubu). Využívá k tomu skrytá nastavení ve webových prohlížečích, určená původně pro firmy a organizace ('enterprise policies'). Pod linuxem je skriptem pro automatickou úpravu nastavení prozatím podporován pouze prohlížeč Firefox.
Svobodný multiplatformní herní engine Bevy napsaný v Rustu byl vydán ve verzi 0.18. Díky 174 přispěvatelům.
Miliardy korun na digitalizaci služeb státu nestačily. Stát do ní v letech 2020 až 2024 vložil víc než 50 miliard korun, ale původní cíl se nepodařilo splnit. Od loňského února měly být služby státu plně digitalizované a občané měli mít právo komunikovat se státem digitálně. Do tohoto data se povedlo plně digitalizovat 18 procent agendových služeb státu. Dnes to uvedl Nejvyšší kontrolní úřad (NKÚ) v souhrnné zprávě o stavu digitalizace v Česku. Zpráva vychází z výsledků víc než 50 kontrol, které NKÚ v posledních pěti letech v tomto oboru uskutečnil.
Nadace Wikimedia, která je provozovatelem internetové encyklopedie Wikipedia, oznámila u příležitosti 25. výročí vzniku encyklopedie nové licenční dohody s firmami vyvíjejícími umělou inteligenci (AI). Mezi partnery encyklopedie tak nově patří Microsoft, Amazon a Meta Platforms, ale také start-up Perplexity a francouzská společnost Mistral AI. Wikimedia má podobnou dohodu od roku 2022 také se společností Google ze skupiny
… více »D7VK byl vydán ve verzi 1.2. Jedná se o fork DXVK implementující překlad volání Direct3D 5, 6 a 7 na Vulkan. DXVK zvládá Direct3D 8, 9, 10 a 11.
Byla vydána verze 12.0.0 knihovny libvirt (Wikipedie) zastřešující různé virtualizační technologie a vytvářející jednotné rozhraní pro správu virtuálních strojů. Současně byl ve verzi 12.0.0 vydán související modul pro Python libvirt-python. Přehled novinek v poznámkách k vydání.
Komunity jsou vlastně jakési značky, kterými si můžete označit prefixy a dle těchto značek následně řídit směrovací politiku (pomocí route-map s příslušným match). Pomocí komunit lze například označit prefixy z Evropy, USA apod. Protože je tento atribut tranzitivní, můžete komunity přejímat od svých peerů.
Nastavení komunity se provádí pomocí route-map:
route-map SETCOMM permit 20 set community 61111:1001
Příklad community listu a route-mapy pro řízení routovací politiky:
ip community-list standard BACKUP permit 61111:1001 route-map BACKUP permit 10 match community BACKUP set local-preference 50
Pokud hodláte být tranzitním providerem, můžete v závislosti na topologii vaší sítě potřebovat BGP routery v jednotlivých lokalitách. Zákazník, který tedy bude chtít tranzit přes váš AS, naváže peer z BGP routerem přímo v dané lokalitě. Tento váš router pak bude mít navázané peery s dalšími vašimi BGP routery. Je nutné mít peer každý s každým (full mesh), aby byl routing konzistentní. Pokud ale máte BGP routerů více, je vhodné ze dvou (redundance) routerů udělat tzv. route-reflektory. Princip je takový, že všechny BGP routery navážou peery pouze s route-reflektory, čímž se sníží počet vzájemných peerů a složitost konfigurace a správy. Je dobré nastavit shodné bgp cluster-id na obou reflektorech. V rozsáhlejších topologiích může být výhodné provozovat i více než dva reflektory, jednotlivé skupiny se pak rozlišují právě pomocí cluster-id. Konfigurace peeru na route-reflektoru může vypadat nějak takto:
neighbor 178.32.11.2 route-reflector-client
Konfigurace klienta route-reflektoru není nijak odlišná od klasického peeru. BGP session mezi samotnými route-reflektory se konfiguruje stejně jako při full-mesh IBGP.
Další možnou metodou pro zjednodušení routingu, pokud nechceme full-mesh ve velmi složitých topologiích, jsou konfederace, což je zjednodušeně řečeno rozdělení AS na menší celky (skupiny BGP routerů), které se snáze spravují. Uvnitř konfederací se typicky využívají privátní čísla AS (64512-65535).
Pokud povaha služeb, které poskytuje váš AS do internetu (serverhosting, webhosting atd.), vyžaduje připojení na páteř, a disponujete-li dostatečným množstvím prostředků, připojte svůj AS do českého internetu přes NIX v některém z uzlů. Asi nejznámějším je Sitel. Samotné členství v NIXu tolik nestojí, jsou tu ale další náklady na housing vaší technologie, pronájem optických vláken, náklady na zřizování kabeláže atd. Dobře si spočítejte, zda to potřebujete a vyplatí se vám to. Více informací naleznete na http://www.nix.cz/.
Pokud potřebujete řešit zahraniční konektivitu a „mixovaná“ vám nevyhovuje, je třeba návázat přímý peer s některým z poskytovatelů tranzitní konektivity (Global Crossing, Verizon, Level3, Telia, Interoute, Tiscali, Cogent, Lambdanet, Deutsche Telekom atd.). Při domlouvání podmínek pro zahraniční konektivitu nejspíše narazíte na pojem 95 % percentile, který zjednodušeně znamená, že si domluvíte například 200 Mbit, za který zaplatíte nějakou měsíční taxu a pokud přesáhnete krátkodobě (méně než 5 %) měsíčně přes tento limit, je to v toleranci. Pokud ovšem přesáhnete, zaplatíte navíc za každý přenesený megabajt přes limit. Většinou se s providerem zahraniční konektivity domluvíte na prvním měsíci jako ochranné lhůtě, kdy zjistíte, kolik přesně vám do zahraničí poteče a jaký je výhled, a dohodnete si konkrétnější podmínky.
Protože IPv4 adresy docházejí, je dobré být připraven na IPv6 a možná ještě lépe poskytovat svým uživatelům nativní IPv6 konektivitu. Požádejte tedy prostřednictvím LIR o IPv6 adresy pro váš autonomní systém a navažte peering se svými poskytovateli. Prefix pro IPv6 adresy, který dostanete od RIPE, je /32, koncovým uživatelům pak můžete přidělovat typicky /48. Opět od obou poskytovatelů získáte IPv6 pro vzájemné propojení. Vzor žádosti o IPv6 adresy může vypadat nějak takto:
% IPv6 First Allocation Request Form % RIPE NCC members can use this form to request their first IPv6 Allocation. % Please see ripe-413 for instructions on how to complete this form. #[GENERAL INFORMATION]# % % Please add your RegID. request-type: ipv6-first-alloc form-version: 1.1 x-ncc-regid: cz.provider #[REQUESTER TEMPLATE]# % % Please add your contact details. name: Frantisek Novak phone: +420 xxx xxx xxx fax-no: +420 xxx xxx xxx e-mail: adresa@vasedomena.cz nic-hdl: FN8468-RIPE #[REQUIRED INFORMATION]# % % Do you accept the IPv6 Address Allocation and Assignment % Policy? (Yes/No) confirmation: Yes % If you have any online information about your future % IPv6 services, please add the URL below. website: http://www.vasedomena.cz #[OVERVIEW OF ORGANISATION TEMPLATE]# % % Please add a short description of your organisation. org-description: A nonprofit community network for promoting Internet technologies and computer literacy in general. % If your organisation has IPv6 allocations from any of the Regional % Internet Registries (RIR), please list the ranges below. other-allocation: % Will the whole organisation use the requested allocation? If % another part of the organisation will request separate IPv6 % address space from any RIR, please inform us below. (Whole/Part) for-whole-or-part-of-the-organisation: Whole #[IPv6 ALLOCATION USAGE PLAN]# % % When will you use this address space? % % Subnet Within Within Within % size (/nn) 3 months 1 year 2 years Purpose subnet: /48 x – – Main POPs, hosted servers and services subnet: /44 – x – Existing infrastructure and workstations #[DATABASE TEMPLATE(S)]# % % Please complete all of the fields below. % % You can find more information on how to complete these fields % in the supporting notes (ripe-413). inet6num: netname: descr: MY Network s.r.o. country: CZ org: ORG-SK1344-RIPE admin-c: FN8468-RIPE tech-c: FN8468-RIPE tech-c: JA6461-RIPE status: ALLOCATED-BY-RIR mnt-by: RIPE-NCC-HM-MNT mnt-lower: MY-CZ-MNT mnt-routes: MY-CZ-MNT notify: notify@vasedomena.cz changed: hostmaster@ripe.net source: RIPE #[INSERT SUPPLEMENTAL COMMENTS]# % % Please add more information if you have specific addressing needs. Our community network consists of a small number of border POPs, the internal network is, however, very structured as it contains over 100 sites organized into 8 high-level topology groups. Each of the sites supports both wired and wireless clients on several network segments. Those sites span over 8 cities and several dozens villages in about 15km perimeter, providing network (and Internet) access to mainly home users and small/individual businesses. Currently we are running this network using private IPv4 (10.0.0.0/8) and using NAT for those workstations which need to be accessed from the Internet. We would like to offer central services to dual IPv4/IPv6 shortly (~2 months), and have a already plan in place to migrate the network backbone to dual IPv4/IPv6 as well. Individual users will be offered to use IPv6 immediately after the migration (estimate: 6 months), however the speed of migration will vary based on the users' technology. We assume that a majority of the users (approx 3800 to this date) will migrate within the next 3 years, mostly when legacy IPv6-unfriendly consumer devices are replaced by newer appliances. On IPv6, we want to retain autoconfiguration ability for user consumer appliances and offer some degree of structuring user network, which is now (on IPv4) limited. The requested subnet size allows us to set up addressing scheme as follows: 4 bits = topology group 6 bits = site 4 bits = network subnet ID at site 6 bits = reserved for user subnetting 64 bits = EUI-64 ---------------- 84 bits => /44 prefix requested If the requested network size (based on the above requirements description) does not fit the 'effective usage' policy, we are seeking your advice on sizing the network properly. Best regards, Frantisek Novak #[END of REQUEST]#
Základní konfigurace IPv6 peeringu může vypadat nějak takto:
neighbor 2001:490:0:1::1 remote-as 61111 no neighbor 2001:490:0:1::1 activate address-family ipv6 neighbor 2001:490:0:1::1 activate neighbor 2001:490:0:1::1 send-community both neighbor 2001:490:0:1::1 soft-reconfiguration inbound
Pro IPv6 se využívá multiprotokolového rozšíření BGP protokolu – toto se nevyužívá jen pro IPv6. Většina výše popsaných vlastností zůstává i pro IPv6 nezměněná, odlišnosti jsou jen minimální. Rozdílně se konfigurují jen IPv6 prefix-listy, které jsou ve tvaru:
ipv6 prefix-list GLOBALS permit 2000::/3
a jeho aplikace v route-map:
route-map BACKUP permit 10
match ipv6 address prefix-list GLOBALS
Při tvorbě vlastních route-map, prefixlistů atd. nikdy nezapomínejte na to, že implicitním posledním pravidlem je „deny all“, které se uplatní v případě, že se jiné pravidlo neaplikuje.
Jak již bylo výše naznačeno, nově se v prostředí internetu začínají objevovat 32bitová čísla autonomních systémů, které RIPE přiděluje, pokud explicitně nepožádáte o číslo původně 16bitové. Práce s 32bit AS je u routovacího daemonu Quagga totožná jako s původními 16bitovými čísly, aktuální verze daemonu tuto funkcionalitu již podporují. Při propojování s peery, které 32bitová čísla AS nepodporují, se používá vyhrazené AS23456. Samotné 32bitové cesty AS se pak přenášejí ve speciálním tranzitivním atributu AS4_PATH.
Daniel Suchý, NIX.CZ, z. s. p. o.
Aleš Lednej, RIO Media, a. s.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Tak tento díl je teda hrozně odfláknutý. Myslel jsem, že se bude více do podrobna věnovat NIXu, jak to funguje, jak se zřizují peery, co to obnáší. Informace (návody) pro více peerů, rozdělení zátěže :(.