Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu optimalizovaná pro jednodeskové počítače na platformě ARM a RISC-V, ke stažení ale také pro Intel a AMD, byl vydán ve verzi 24.5.1 Havier. Přehled novinek v Changelogu.
Společnost xAI založena Elonem Muskem a stojící za AI LLM modelem Grok získala investici 6 miliard dolarů.
Finálový zápas mistrovství světa v ledním hokeji přinesl nový rekord NIX.CZ (𝕏): "Dosavadní absolutní maximum našeho propojovacího uzlu bylo překonáno v čase 21:10, kdy jsme při přenosu dat dosáhli 3,14 Tbps. Je třeba také doplnit, že po deváté hodině večerní byly na maximu i ostatní datové přenosy nesouvisející s hokejovým šampionátem".
Přihlaste svou přednášku na další ročník konference LinuxDays, který proběhne 12. a 13. října na FIT ČVUT v pražských Dejvicích. CfP poběží do konce prázdnin, pak proběhne veřejné hlasování a výběr přednášek.
Na crowdsourcingové platformě Crowd Supply byla spuštěna kampaň na podporu open source biometrického monitoru ve tvaru hodinek HealthyPi Move. Cena je 249 dolarů a plánovaný termín dodání listopad letošního roku.
Firma Murena představila /e/OS verze 2.0. Jde o alternativní sestavení Androidu bez aplikací Google. Mezi novinkami je podrobnější nastavení ochrany soukromí před sledováním aplikacemi. Murena prodává několik smartphonů s předinstalovaným /e/OS (Fairphone, repasovaný Google Pixel 5).
Do 30. května lze v rámci akce Warhammer Skulls 2024 získat na Steamu zdarma hru Warhammer 40,000: Gladius - Relics of War.
HelenOS (Wikipedie), tj. svobodný operační systém českého původu založený na architektuře mikrojádra, byl vydán ve verzi 0.14.1. Přehled novinek v poznámkách k vydání. Vypíchnou lze nabídku Start. Videopředstavení na YouTube.
BreadboardOS je firmware pro Raspberry Pi Pico (RP2040) umožňující s tímto MCU komunikovat pomocí řádkového rozhraní (CLI). Využívá FreeRTOS a Microshell.
Jako správně líný sysadmin jsem si dřív šetřil čas a místo instalace nových serverů jsem je kopíroval.
Prostě jsem přes USB redukci připojil disk z dalšího serveru, který byl na řadě, k čerstvě nainstalovanému, nahodil shell z initrd, spáchal partition tabulku, filesystémy, swap a tarem na něj poslal OS. Pak jsem vzal tu kopii, upravil /etc/fstab, /etc/hosts a /etc/network/interfaces, vrazil disk do správného chasis, nabootoval a frčel.
Bylo nebylo a vyšel nový stable Debian.
Takže přišlo klasické kombo - úprava sources listu, apt update, apt upgrade, apt full-upgrade, apt autoremove, reboot, aptitude remove '~o', apt clean.
Upgrade prvního serveru byl naprosto v pohodě, ale po rebootu druhého začala brutálně zlobit síť.
V čem byl problém?
V generování MAC adres pro bondy a bridge. Kdesi NEWS a Changelogu jsou schované lahůdky jako
bridge-utils (1.7-1) unstable; urgency=medium Linux kernel has changed bridge MAC address selection. In older Linux kernels the MAC of the bridge was the lower mac of the devices attached to it, this is no longer the case now at Bullseye. The kernel now makes up a completely new MAC address.kde makes up znamená vygenerování podle názvu interfacu a obsahu /etc/machine-id.
Takže jestli jste někdy zkopírovali server s Debianem Buster a starším, používáte bondy nebo bridge a máte originál i kopii na stejné síti, vřele doporučuji před upgradem pustit ještě:
rm -f /etc/machine-id /var/lib/dbus/machine-id
dbus-uuidgen --ensure=/etc/machine-id
sudo dbus-uuidgen --ensure
Tiskni Sdílej:
Linux kernel has changed bridge MAC address selection.
Nevím o tom, že by jádro v tomto ohledu něco změnilo. Spíš půjde o systemd / udev, tam se na nějakou zpětnou kompatibilitu nehraje.
dpkg -s lxc ... Depends: ... bridge-utilsI když to někoho zajímalo a chtěl to odinstalovat, jsou programy, co bez toho nedokážou žít. Ostatně Debian ještě pár let zpátky bez toho ifconfig nedokázal nakonfigurovat síť.
hlavněže to jako dobře dopadlo :O :D :D ;D
enp97s0f1Takú dlhú zbernicu by som rád videl. Čo to je za hardware?
S dostatečně novým jádrem (upstream od verze 5.5) lze rozhraní přiřadit "alternative names" (altnames), která lze použít místo standardního jména. Novější verze udev pak umějí nechat původní jméno od jádra a přidat "predictable" jako altname:
lion:~ # ip -d link show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether a0:36:9f:0a:81:b0 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 9216 addrgenmode eui64 numtxqueues 8 numrxqueues 8 gso_max_size 65536 gso_max_segs 65535 parentbus pci parentdev 0000:04:00.0 altname enp4s0f0 lion:~ # ip -d link show dev enp4s0f0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether a0:36:9f:0a:81:b0 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 9216 addrgenmode eui64 numtxqueues 8 numrxqueues 8 gso_max_size 65536 gso_max_segs 65535 parentbus pci parentdev 0000:04:00.0 altname enp4s0f0
(Příklad z openSUSE Leap 15.3.) Pořád to ale bohužel vypadá, že udev použije jen jedno jmenné schéma, ne rozdíl od blokových zařízení, kde ke stejnému zařízení existuje víc /dev/disk/by-*/
symlinků a lze tak použít kterýkoli (a zároveň původní jméno od jádra).
S dostatečně novým jádrem (upstream od verze 5.5) lze rozhraní přiřadit "alternative names" (altnames)Takového s.aní jen kvůli tomu, že jednoho blbečka včas nevyhodili ze dveří...
Pak jsem vzal tu kopii, upravil /etc/fstab, /etc/hosts a /etc/network/interfaces, vrazil disk do správného chasis, nabootoval a frčel.Doufám, že sshd host klíče jsi vypustil pouze zde kvůli stručnosti. A jinak díky za informaci. Já ještě přidám, že poslední dobou nějak moc často začalo být potřeba
apt-get --allow-releaseinfo-change update
. Nepochopil jsem co to dělá, resp. proč to jako je potřeba když všude používám kódová jména a ne "stable".
Ono je těch věcí tolik, že je skoro lepší udělat čistou instalaci.
Kdysi jsem tu psal: Kontrolní seznam pro nový server
Vzhledem k tomu, že málokteré stroje mám stejné a často experimentuji s různými distribucemi nebo verzemi nebo zkouším jinou konfiguraci (tabulka disků, RAID, šifrování, LVM, souborové systémy atd.), tak většinou dělám klasickou instalaci. Zase tolik času to nezabere.
S příchodem kontejnerů se přišlo na to, že mít předpis (skript)Tohle je na delší povídání. Mám několik ansible playbooku ve svém repu, používám je, ulehčí to čas (a hlavně nudnou opakovanou práci), ale já se obecně snažím mít servery co nejjednodušší, že jejich čistá ruční instalace zase tolik nezabere. Aktuálně spolupracuju s lidmi, kteří to vidí lehce jinak a ti zase nastavují naprosto všechno. (A proto chtějí ke všemu skripty.)
Nebo rolling update v podobě testingu a čistit to v průběhu.Nebo upgrade mezi stable a čistit to při přechodu. Nebo teda "čistit", protože třeba se "síť v networkd místo interfaces" nechť se každý laskavě odebere tam, kam mu slunce nesvítí - mít spuštěnou službu na statickou záležitost jako nastavení sítě na serveru je ptákovina.
Ta vase staticka zalezitost ale pak neumi fungovat treba v rezimu (ne)dostupnosti site.To jsem nějak nepochopil. Při statické konfiguraci přiřadím rozhraní adresy a nastavím routy a je jedno jestli je link a tak. Jediné co mě napadá že by se mělo dělat je, pokud síťovka může failnout a zase se objevit (u PCIečkových se to asi nestane, ale u USB si to představit dokážu), tak se musí znovu nakonfigurovat.
V offiko repu vůbec nic není (na rozdíl od Debu), na všechno je nutno přidávat vlastní repo
Žádná jiná liga a dá se to rozbít úplně stejně.
Řekl bych, že když si přidáváš repositáře spravované různými týmy, tak je to riziko rozbití naopak větší – závislosti mezi balíčky, kolize, překřížení verzí… Alespoň tedy u klasických distribucí typu .deb/.rpm.
Debian/Ubuntu by se tímhle způsobem dal rozbít taky, ale tam má člověk to štěstí, že najde prakticky vše v distribučních repositářích. A když už instaluješ něco bokem, tak to je jedna dvě důležité aplikace, které si ohlídáš (ne spousty menších programů a knihoven, které chybí v .rpm distribucích).