Dnes a zítra probíhá vývojářská konference Google I/O 2025. Sledovat lze na YouTube a na síti 𝕏 (#GoogleIO).
V Bostonu probíhá konference Red Hat Summit 2025. Vybrané přednášky lze sledovat na YouTube. Dění lze sledovat na síti 𝕏 (#RHSummit).
Společnost Red Hat oficiálně oznámila vydání Red Hat Enterprise Linuxu 10. Vedle nových vlastností přináší také aktualizaci ovladačů a předběžné ukázky budoucích technologií. Podrobnosti v poznámkách k vydání.
Tuto sobotu 24. května se koná historicky první komunitní den projektu Home Assistant. Zváni jsou všichni příznivci, nadšenci a uživatelé tohoto projektu. Pro účast je potřebná registrace. Odkazy na akce v Praze a v Bratislavě.
Troy Hunt představil Have I Been Pwned 2.0, tj. nový vylepšený web služby, kde si uživatelé mohou zkontrolovat, zda se jejich hesla a osobní údaje neobjevily v únicích dat a případně se nechat na další úniky upozorňovat.
Microsoft představil open source textový editor Edit bežící v terminálu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
V Seattlu a také online probíhá konference Microsoft Build 2025. Microsoft představuje své novinky. Windows Subsystem for Linux je nově open source. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Z příspěvku Turris Sentinel – co přinesl rok 2024 na blogu CZ.NIC: "Za poslední rok (únor 2024 – únor 2025) jsme zachytili 8,3 miliardy incidentů a to z 232 zemí a z jejich závislých území. Tyto útoky přišly od 6,2 milionu útočníků (respektive unikátních adres). SMTP minipot je stále nejlákavější pastí, zhruba 79 % útoků bylo směřováno na tento minipot, 16 % útoků směřovalo na minipot Telnet, 3 % útoků směřovaly na minipot HTTP a 2 % na minipot FTP. Dále jsme zaznamenali 3,2 milionu unikátních hesel a 318 tisíc unikátních loginů, které útočníci zkoušeli."
Byla vydána (Mastodon, 𝕏) nová verze 3.0.4 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP (GNU Image Manipulation Program). Přehled novinek v oznámení o vydání a v souboru NEWS na GitLabu. Nový GIMP je již k dispozici také na Flathubu.
Byla vydána nová stabilní verze 7.4 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 136. Přehled novinek i s náhledy v příspěvku na blogu.
Upravená jádra Linuxu obou systémů byla obohacena o rozšířený plánovač přidělení CPU. Ten nyní musí obsluhovat jak jednotlivé procesy, tak i virtuální servery. Systémy pro plánovaní přidělení CPU používají technologii Token-bucket. Každému virtuálnímu serveru je přiděleno pouze tolik systémového času, než spotřebuje přidělené tokeny. Konfiguraci lze měnit i za běhu virtuálního prostředí.
Nastavení plánovače a přidělení CPU využijeme například ve chvíli, kdy server potřebuje při startu vyšší výkon než během svého běhu.
V Linux-VServeru nastavujeme počet tokenů (fill-rate
), které jsou doplněny do bucket za časový interval (fill-interval
). Dále můžeme nastavit počáteční, minimální a maximální množství tokenů.
Ke správné funkci plánovače musíme sestavit jádro Linux-VServeru s volbou CONFIG_VSERVER_HARDCPU=y
.
Linux-VServer rozlišuje mezi „tvrdým“ a „měkkým“ limitem plánovače. Virtuálnímu serveru s tvrdým limitem je po vyčerpání tokenů odebrán procesor. Pokud virtuální server vyčerpá svůj měkký limit a na procesor nečeká jiný virtuální server, je tomuto virtuálnímu serveru nastavena velmi nízká priorita, ale může mu být přidělen procesor. Tvrdý limit nastavíme vložením sched_hard
do souboru /etc/vservers/<id_of_vserver>/flags
. Pro měkký limit vložíme do stejného souboru sched_prio
. Metody nelze kombinovat.
Vlastní nastavení plánovače je uloženo v souboru /etc/vservers/<id_of_vserver>/schedule
. Tento soubor má šest řádků:
fill rate
– počet tokenů přidělených při jedné obrátcefill interval
– délka obrátky v tokenechprio bias
– hodnota, která je připočítána k ostatním hodnotámPo vyplnění může tento soubor vypadat například takto:
7 32 500 200 1000 0
Virtuálnímu serveru je přiděleno 7/32 procesoru, na počátku má k dispozici 500 tokenů, jejich minimální stav je 200 a maximální 1000. Poslední hodnotou je prio bias
. Je-li hodnota nenulová, přičte se k ostatním hodnotám. Pokud by v příkladu byla rovna 5, kontext by dostal 12/37 procesoru, měl by při startu k dispozici 505, minimálně 205 a maximálně 1005 tokenů.
Nastavení plánovače můžeme změnit i za běhu virtuálního serveru. Použijeme k tomu program vsched z balíku util-vserver
. Ten má následující syntaxi:
vsched [--xid <xid>] [--fill-rate <rate>] [--interval <interval>] [--tokens <tokens>] [--tokens-min <tokens>] [--tokens-max <tokens>] [--prio-bias <bias>] [--] [*]
Argumentem volby --xid
je kontextové číslo virtuálního stroje. To je možné zjistit pomocí utility vserver-stat
. Volby --fill-rate
, --interval
, --tokens
, --tokens-min
a --token-max
po řadě odpovídají pěti řádkům souboru /etc/vservers/<id_of_vserver>/schedule
. Program umožňuje nastavit přidělení procesoru i určité aplikaci virtuálního serveru. Tato aplikace je potom posledním argumentem vsched
.
Změnu nastavení plánování virtuálního serveru s kontextovým číslem 1000 provedeme následovně:
# vsched --xid 1000 --fill-rate 30 --interval 100 \ > --tokens 100 --tokens_min 30 --tokens_max 200
Nastavení plánování programu ls
ve virtuálním serveru s kontextovým číslem 1000 změníme například takto:
# vsched –-xid 1000 --fill-rate 30 --interval 100 \ > --tokens 100 --tokens_min 30 --tokens_max 200 -- /bin/ls
Změnu nastavení plánovače procesoru můžeme provést pomocí dvou přepínačů utility vzctl
.
Pro první možnost použijeme přepínač --cpulimit
. Hodnota parametru odpovídá procentu času, po který je procesor přiřazen virtuálnímu serveru a po jehož uplynutí je CPU virtuálnímu serveru odebrán. Odpovídá tedy tvrdému limitu. Chceme-li přidělit virtuálnímu serveru 1919
10 % času procesoru, zadáme příkaz následovně:
# /usr/sbin/vzctl set 1919 --cpulimit 10%
Přidělíme-li virtuálnímu serveru více procesorů (přepínač --cpus
utility vzctl
s argumentem rovnajícím se počtu přidělených CPU) odpovídá celkový čas CPU násobku počtu procesorů. Například se dvěma procesory má hodnotu 200 %.
Druhou variantu zvolíme přepínačem --cpuunits
. Ten určuje garantovanou hodnotu takzvaných CPU jednotek (tokenů), které budou přiděleny virtuálnímu serveru. Argumentem je kladné nenulové číslo předávané plánovači CPU. Vyšší hodnota zaručuje více času procesoru přiděleného virtuálnímu serveru. Po vyčerpání jednotek nemusí být procesor virtuálnímu serveru odebrán, pokud žádný jiný server na procesor nečeká. Maximální hodnota je 500000, minimální 8. V celém systému se čas procesoru přiděluje podle poměru těchto hodnot pro jednotlivé servery. Implicitní hodnota odpovídá 1000 tokenům. Nastavení potom může vypadat následovně:
# /usr/sbin/vzctl set 1919 --cpuunits 1000
Hodnotu přidělených CPU jednotek --cpuunits
můžeme nastavit i pro VE0, tedy samotný hostitelský systém. Přepínačem je --ve0cpuunits
a jako číslo VE uvedeme 0. Nastavení tohoto argumentu na příliš nízkou hodnotu v poměru k hodnotám jiných virtuálních serverů může způsobit nestabilitu celého operačního systému. Autoři doporučují hodnotu mezi 5 - 10 %. Ta se ukládá do souboru /etc/vz/vz.conf
(hodnota VE0CPUUNITS
) a o její nastavení se stará skript /etc/init.d/vz
.
Stejně jako u jiných nastavení pomocí utility vzctl
jsou nastavené hodnoty implicitně dočasné. Pro jejich trvalé uložení uvedeme přepínač --save
. Nastavení se ukládá do souboru /etc/sysconfig/vz-scripts/<VPS_ID>.conf
(hodnoty CPUUNITS
a CPULIMIT
).
Aktuální hodnoty CPU jednotek zjistíme utilitou vzcpucheck. Jejím výstupem je hodnota spotřebovaných jednotek všemi virtuálními servery a VE0 a maximální možný „výkon“ systému:
# vzcpucheck Current CPU utilization: 6667 Power of the node: 73072.5
/dev
Oba projekty nabízejí jiné položky přístupné implicitně v adresáři /dev
, stejně jako jiné přístupy k vytváření dalších speciálních souborů.
Po instalaci základní kostry systému obsahuje virtuální server následující položky:
full | log | null | ptmx | pts |
random | tty | urandom | zero | |
Vytvoření dalších souborů není z virtuálního serveru možné. V kontextech není povolena capability CAP_MKNOD
ani pro uživatele root, a samotný Linux-VServer nenabízí nástroj, který by byl obdobou mknod
. Speciální soubory lze vytvářet pouze z hostitelského systému.
Viditelnost speciálních souborů se mění podle konfigurace počítače. Obecně jsou vytvořené soubory a adresáře:
console | core | fd | full |
initctl | kmem | log | mem |
null | port | ptmx | pts |
ram | random | shm | tty |
urandom | zero |
OpenVZ umožňuje vytváření dalších speciálních souborů prostřednictvím svých utilit.
Zařízení v adresáři /dev
ve VPS zpřístupníme z hardwarového uzlu pomocí utility vzctl
:
# vzctl set VPS_ID --devnodes \ device:r|w|rw|none --save
Příkaz zpřístupní zařízení device
(ve tvaru například /dev/hda
) s přístupovými právy (r
– čtení, w
– zápis, rw
– čtení a zápis, none
– žádný přístup) s trvalým uložením změn v konfiguraci (parametr --save
).
Další možností je povolení capability CAP_MKNOD
ve VPS z hostitelského serveru:
# vzctl set VPS_ID --capability CAP_MKNOD:on --save
Poté je možné ve VPS vytvářet speciální soubory pomocí mknod
. Tato volba však může být možnou bezpečnostní slabinou.
V příštím díle se zaměříme na správu výpočetních zdrojů jako je paměť RAM, počet otevřených souborů atd.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
schedule
, ale adresář tohoto jména obsahuje soubory s parametry plánovače - fill-rate interval tokens tokens-max tokens-min.
Tak jsem to asi špatně pochopil a můj závěr je špatný. Co jsem si prostudoval dokumentaci, tak to vypadá tak, že OpenVZ prostě přiděluje každému VPS definovaný počet cpuunits. Po jejich vyčerpání přejde k dalšímu VPS a tak pořád dokola. Cpuunits tedy definují v jakém poměru se na dané VPS dostane čas na procesoru vzhledem k ostatním VPS. V mém případě tedy hostitel a 3 reálné VPS dostávají stejný díl času na procesoru, kdežto zkušebnímu VPS když se dostane na řadu bude přidělena pouze 8/1000 času (oproti ostatním). A když je "Power of the node: 186725", každé z VPS se dostane na řadu 186725/4008 krát za sekundu (cca 46Hz). Jinak řečeno (v mém případě): VE0 jede 5,35ms, pak se systém přepne na VPS1 a to jede 5,35ms, pak na VPS2 opět 5,35ms, pak na VPS3 zase 5,35ms a pak na zkušební VPS a to po dobu 0,04ms. A pak zase VE0 5,35ms .. .
Nevíte o nějakém nástroji, který by nějak souhrnně ukázal, jak je procesor využíván v rámci jednotlivých VPS ? Jde mi o odladění potřebných cpuunits pro jednotlivé VPS. V rámci kontextů je dostupná statistika v /proc/loadavg. Navíc se nějaké užitečné informace dají najít i v /proc/vz/vestat. Ale k tomu by se muselo něco bastlit, šlo mi o to, jestli jsem nepřehlédnul nějaký použitelný nástroj.