Společnost Pebble představila (YouTube) prsten s tlačítkem a mikrofonem Pebble Index 01 pro rychlé nahrávání hlasových poznámek. Prsten lze předobjednat za 75 dolarů.
Společnost JetBrains v listopadu 2021 představila nové IDE s názvem Fleet. Tento týden oznámila jeho konec. Od 22. prosince 2025 již nebude možné Fleet stáhnout.
Byl vydán Mozilla Firefox 146.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 146 bude brzy k dispozici také na Flathubu a Snapcraftu.
Před rokem převzala Digitální a informační agentura (DIA) vlastnictví a provoz jednotné státní domény gov.cz. Nyní spustila samoobslužný portál, který umožňuje orgánům veřejné moci snadno registrovat nové domény státní správy pod doménu gov.cz nebo spravovat ty stávající. Proces nové registrace, který dříve trval 30 dní, se nyní zkrátil na několik minut.
IBM kupuje za 11 miliard USD (229,1 miliardy Kč) firmu Confluent zabývající se datovou infrastrukturou. Posílí tak svoji nabídku cloudových služeb a využije růstu poptávky po těchto službách, který je poháněný umělou inteligencí.
Nejvyšší správní soud (NSS) podruhé zrušil pokutu za únik zákaznických údajů z e-shopu Mall.cz. Incidentem se musí znovu zabývat Úřad pro ochranu osobních údajů (ÚOOÚ). Samotný únik ještě neznamená, že správce dat porušil svou povinnost zajistit jejich bezpečnost, plyne z rozsudku dočasně zpřístupněného na úřední desce. Úřad musí vždy posoudit, zda byla přijatá opatření přiměřená povaze rizik, stavu techniky a nákladům.
Organizace Free Software Foundation Europe (FSFE) zrušila svůj účet na 𝕏 (Twitter) s odůvodněním: "To, co mělo být původně místem pro dialog a výměnu informací, se proměnilo v centralizovanou arénu nepřátelství, dezinformací a ziskem motivovaného řízení, což je daleko od ideálů svobody, za nimiž stojíme". FSFE je aktivní na Mastodonu.
Paramount nabízí za celý Warner Bros. Discovery 30 USD na akcii, tj. celkově o 18 miliard USD více než nabízí Netflix. V hotovosti.
Nájemný botnet Aisuru prolomil další "rekord". DDoS útok na Cloudflare dosáhl 29,7 Tbps. Aisuru je tvořený až čtyřmi miliony kompromitovaných zařízení.
Iced, tj. multiplatformní GUI knihovna pro Rust, byla vydána ve verzi 0.14.0.
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
/devOba 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.