GNOME slaví 25 let. Přesně před pětadvaceti lety odeslal Miguel de Icaza do diskusního listu GTK+ email, který je považován za zahájení projektu GNOME, jehož cílem bylo vyvinout prostředí podobné CDE a KDE, ale založené výhradně na svobodném softwaru.
Kamera Intel MIPI IPU6 v noteboocích Lenovo ThinkPad X1 Carbon nebo Dell XPS 13 9315/9320 potřebuje na Linuxu proprietární firmware. Navíc aktuálně běží pouze na opatchovaném Linuxu 5.15. Nejenom Greg Kroah-Hartman z těchto důvodů koupi těchto notebooků nedoporučuje. Zajímavé je, že Dell XPS 9315 získal certifikaci pro Ubuntu.
Nejnovější glibc rozbíjí Easy Anti-Cheat. Řada her tak přestala fungovat. V glibc 2.36 byla odstraněna podpora DT_HASH, jež je právě v Easy Anti-Cheat od Epic Games používána. Nejnovější glibc se již dostala například do Arch Linuxu. Tam je problém řešen balíčkem glibc 2.36-2 s vrácenou podporou DT_HASH.
V knihovně pro kompresi dat zlib (Wikipedie) byla objevena bezpečnostní chyba CVE-2022-37434 s vážností CVSS 9.8. Opravená upstream verze zatím nevyšla. Chyba se samozřejmě týká i softwarů s bundlovanou zlib, viz například vydání rsync 3.2.5.
JuiceFS dospěl do verze 1.0. Jedná se o distribuovaný souborový systém kompatibilní s POSIX, HDFS a S3. Architektura JuiceFS sestává ze 3 částí: JuiceFS Client, Data Storage (S3, Azure Blob, OpenStack Swift, Ceph, MinIO, …) a Metadata Engine (Redis, TiKV, MySQL/MariaDB, PostgreSQL, SQLite, …). Zdrojové kódy JuiceFS jsou k dispozici na GitHubu pod licencí Apache 2.0.
Včera skončila bezpečnostní konference Black Hat USA 2022 (Twitter) a začala bezpečnostní konference DEF CON 30 (Twitter). V rámci Black Hat byly vyhlášeny výsledky letošní Pwnie Awards (Twitter). Pwnie Awards oceňují to nejlepší, ale i to nejhorší z IT bezpečnosti (bezpečnostní Oscar a Malina v jednom).
Vývojáři PostgreSQL oznámili vydání verzí 14.5, 13.8, 12.12, 11.17, 10.22 a 15 Beta 3. Opraveno je více než 40 chyb a také zranitelnost CVE-2022-2625. Upstream podpora verze 10 končí 10. listopadu letošního roku.
This article describes problems in configuration of traffic shaping in unusual circumstances. These circumstances are not as unusual as may by seem on first view. It's about real life situations.
This article expects basic knowledge about traffic shaping in GNU/Linux and packet path in Linux kernel.
Common usage of shaping in small network is traffic limiting on internet gateway. Company is connected to internet using DSL provider, WIFI or something similar, which doesn't have guaranteed quality. Configuring traffic shaping and QoS in this environment is hard. It may by impossible to guarantee anything.
The first problem is link quality. Internet service provider doesn't guarentee bandwidth, latency, nothing. Traffic shaping is typicaly based on slowing down packets. It handles TCP flow control. TCP sends packets as fast as client is able to send responses. Slowing down packets causes less inbound traffic, which is our mission. It's usual that there are many data streams which competes against. Each stream has its own data speed control and it is trying to take as much bandwidth as it is avaliable. Traffic shaping is applied at internet service provider's router, all data streams are same priority, when link capacity is filled up, all packets are delayed. It may be OK at home, but if you want to use IP telephony which quality will be realy bad, user will call for some solution.
Basic solution is to configure linux router, set traffic shaper, for example HTB and limit internet line. ISP limits our line to 1Mb/s so we configure shaper to 1Mb/s. (We follow only download part in this example.) One rule for basic internet traffic with limit to 512Mb/s and second one with limit to 512Mb/s for VoIP. There is too much unused conectivity for VoIP but there is reserve for more VoIP calls. But you want to use all your connectivity. It's possible with HTB, create one root rule with limit to 1Mb/s, one child rule with rate 128Mb/s and ceil 1Mb/s, next one child rule with rate 256Mb/s and ceil 512Mb/s. This configuration will work quite well - internet trafic will use first child rule, VoIP second one. If there is no VoIP traffic, internet traffic will use all available bandwidth. VoIP has guaranteed 256Mb/s which should be enought but if more VoIP traffic requirements occurs, it will be available with highier priority than common internet traffic. This is quite good solution, but there are some problems. When clients uses all available connectivity, VoIP quality suddenly drop. It will be close to quality without shaping. Where is problem? ISP does traffic shaping too and limitation of inbound traffic is firstly applied at ISP side and then by our router so ability to eliminate latency and priorize VoIP is minimal. Standard solution is to limit maximal bandwidth to 80 % or less of total bandwidth. It's usually the only one realizable sollution because it is realizable without ISP cooperation. It is nearly impossible to take some unusual configuration of ISP's traffic shaper.
Problem with shaping cascades is that there is no way to pass through traffic at not last shaper, it's solvable by underflow ISP's limitation, but it's not 100% solution in networks with aggregation of multiple clients, with speed unstable lines and so on.
If you are internet service provider, provides connectivity to your clients using multiple network cards and would share your unused connectivity between network cards, you hit limitation of linux shaping principles. Linux shaping usually uses output buffer of network card so it isn't possible to share bandwidth between more network cards. You can reserve bandwidth for each network card but you cannot share unused bandwidth between them.
There is solution which can help – IMQ. It creates special network interface used only for shaping. IMQ is not part of vanilla Linux kernel, it isn't included in distribution kernels, it's distributed only as patches. Installation requires patching kernel and iptables. IMQ is controlled using kernel module parameters – number of IMQ devices and iptables – packet routing. Typical solution uses two IMQ devices, one for upload and one for download. It is able to use iptables configuration to separate inbound and outbound traffic, separate networks, join and share network connectivity via many network cards.
Many ISPs provides Half-duplex lines or your users are connected using half-duplex technology, for example IEEE802.11 wifi. Maximum line capacity is usually known but its limit is for upload and download together. Basic Linux kernel limits at outbound interface output buffer so limiting together is not possible. Solution is to use IMQ as described in chapter Multiple network cards.
You can configure one IMQ devices for all traffic and route there all traffic – inbound and outbound. Using iptables and tc you can configure root rule with total line capacity and child nodes for upload and download. It's possible to provide limits such as 2Mb/s download and 512kb/s upload for many clients and use as much bandwidth as is currently available.
If you are administrator of small company network your network is probably connected to internet using router with nat and you want configure this router to equalize clients so you configure linux shaping using tc. Simple solution is routing packets to shapper using tc filter's u32 filter. It will work well without nat, but not with it. Problem is packet path in Linux kernel – shaping is applied after iptables changes source address so all upload traffic is count as only one address. It's usually solved by marking packets by iptables before address modification.
Second solution is using IMQ – it allows compile time configuration of hook in packet path which is able to shape traffic before nat.