OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.
Byla vydána nová verze 6.2 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.14.
Byla vydána nová verze 30.0.0 frameworku pro vývoj multiplatformních desktopových aplikací pomocí JavaScriptu, HTML a CSS Electron (Wikipedie, GitHub). Chromium bylo aktualizováno na verzi 124.0.6367.49, V8 na verzi 12.4 a Node.js na verzi 20.11.1. Electron byl původně vyvíjen pro editor Atom pod názvem Atom Shell. Dnes je na Electronu postavena celá řada dalších aplikací.
Byla vydána nová verze 9.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 220 vývojářů. Provedeno bylo více než 2 700 commitů. Přehled úprav a nových vlastností v seznamu změn.
Ano, uznávám, pomalu, ale jistě to na mém blogu vyhnívá... hlavně kvůli nedostatku času a nápadů, co si budeme povídat :-/ No a jelikož se většina mých zápisků v poslední době čím dál tím více odchylovala od zaměření ABC Linuxu, rozhodl jsem se založit tématicky volný blog Letters from Earth, na který jsem zároveň přesunul zápisky odsud za poslední půlrok.
FuxBlog budiž tedy nadále ryze technickým blogem se zaměřením na IT. Snad na něj budu mít čas...
Varování! Následující zápisek nemá v úmyslu vyvolávat flamewar, hanět, či chválit jmenované distribuce. Jde pouze o střízlivý popis radostí a strastí změny distribuce.
Jako první bych asi měl popsat důvod částečné změny distribuce - je jím nenápadný program pro modelování metodou konečných prvků, Agros2D. Problémem tohoto programu je, že je postaven nad knihovnou Hermes2D, což je knihovna, která nemá balíček pro žádnou RPM distribuci a při pokusech o kompilaci jsem po několika dnech selhal. Vzhledem k tomu, že Agros2D budu nucen používat čím dál tím více a jeho spouštění pod WINE se mi příliš nezamlouvalo, nezbývalo než přejít k distribuci, která balíček Hermes2D má a lze do ní nainstalovat i balíček s Agros2D - Debianu.
Samozřejmě od začátku jsem nejel naostro. Celá cesta marnými pokusy k Debianu Wheezy, na který jsem momentálně odkázán, byla následující:
Instalace Debianu mě trochu zklamala. To, že grafická instalace nefunguje, lze u Wheezyho očekávat - přeci jen jde o "Testing" verzi, takže jisté chyby jsou autorům vyhrazeny. Nicméně rozdíly mezi možnostmi instalace z GUI oproti TUI jsou tak malé, že je prakticky jedno, kterou cestu zvolíte. To, co mne zklamalo, byly vlastní možnosti instalace. Instalátor se vás zeptá hned na začátku na lokalizaci počítače, používanou klávesnici a podobně, provede se rozdělení disků (oproti openSUSE velmi jednoduše provedené a možná vhodnější pro začátečníky) a ve chvíli, kdy by si uživatel měl zvolit možnosti instalace nabídne pouhých osm voleb, ve které si k základní instalaci je možné přidat různé serverové nástroje. Konkrétní volba balíků, stejně tak jako repozitářů, zůstává kompletně skryta a vše je třeba doinstalovat až z běžícího systému.
Poměrně zvláštní je i systém výběru pracovního prostředí - tento výběr je k dispozici při bootování z instalačního CD - na výběr máte mezi GNOME (defaultní), KDE, LXDE a XFCE. Tyto volby jsou skryty pod pokročilými možnostmi a podle výběru při startu instalace se vybírají samotné balíčky k instalaci. V mém případě jsem okamžitě volil instalaci S KDE, neboť při marném pokusu číslo 3 jsem zjistil, že GNOME je již ve verzi 3 s GNOME Shell a po delším kontaktu s ním jsem zjistil, že na toto bych si opravdu nezvykl.
Co může susákům při instalaci chybět jsou prakticky veškeré expertní volby, které při instalaci openSUSE nabízí - nelze si vybrat pořadí zvukových zařízení, nelze si vybrat, zda chcete zakázat PulseAudio, nelze si při instalaci nastavit NTP démona atd. V instalaci při výběru disků pak zcela schází možnost práce s reiserfs, takže mé dvě reiserovské partišny jsem do /etc/fstab musel přidat až později ručně. Z pohledu susáka jde tedy o instalaci oholenou na kost.
Po instalaci přichází seznámení se systémem. Po pravdě ihned po instalaci jsem ani příliš neřešil, zda má Debian grafický instalátor balíků a v zájmu urychlení práce jsem do systému vše nasoukal z konzole za pomoci apt-get.
Zjištění první - Debian má ve výchozím stavu povolen jen repozitář main - tedy repozitář, ve kterém je obsažen pouze ryzí open source software neodporující "náboženskému přesvědčení" autorů Debianu. K povolení dalších repozitářů (contrib a non-free) naštěstí postačuje pouze připsat tyto zdroje do souboru /etc/apt/sources.list, v mém případě tedy jde o změnu řádky
deb http://ftp.zcu.cz/mirrors/debian/ wheezy mainna
deb http://ftp.zcu.cz/mirrors/debian/ wheezy main non-free contrib
Zjistění druhé - ačkoliv Debian má repozitář non-free, chybí v něm (některé) multimediální programy. Od tohoto je tu náhražkový repozitář Debian Multimedia, do /etc/apt/sources.list tedy přibývá i řádek
deb ftp://ftp.debian-multimedia.org wheezy main non-free
Zjištění třetí - apt je poznamenán náboženstvím Debianu. Jinak si nedovedu vysvětlit, proč při instalaci nějakého balíku hlásí "balíček XXX se nebude instalovat. Pro pokračování zadejte apt-get -f install." Po zadání
apt-get -f installse provede stejná operace, o kterou jsem se snažil předtím, jen s tím rozdílem, že se nainstalují i "non-free" programy.
Celkové porovnání práce s aptem oproti susímu zypperu je asi takové, že je jedno, co použijete, jen stačí si na to zvyknout. Buďto napíšete
zypper in krusadernebo napíšete
apt-get install krusaderJediné, co bych považoval za plus
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
zypperu je fakt, že si před instalací sám obnoví repozitáře (samozřejmě ne pokaždé, jen "jednou za rozumný čas"), zatímco aptu musíte říci, aby tak učinil (apt-get update).
V porovnání s openSUSE si nelze než chrochtat nad výběrem balíků - to, co bylo v řadě případů nutné na SUSE kompilovat, má Debian ve svých repozitářích. Ale platí to i naopak - Debianu schází některé balíčky, které v openSUSE jsou, například řada témat pro KDE, Qt a kwin, některé hry a podobně.
Porovnám-li Debian s jinými distribucemi, které jsem zkoušel, pak musím ocenit jednotnost jeho repozitářů a balíčků - zde je na tom snad ještě lépe než openSUSE. Nenastává zde problém typu Fedory (a RedHatu a CentOS a jejich derivátů), kdy stejný balíček je v několika repozitářích, má nastaven pokaždé jiné závislosti, různé balíčky se mezi sebou vylučují a nastává chaos.
Samotný běh systému mě překvapil. Ačkoliv bych tomu nikdy nevěřil, KDE 4.7.4 se na Debianu svojí rychlostí vyrovnají KDE 4.8.1 na openSUSE. Start systému je také rychlejší, což lze ale připsat řade služeb, kterými je openSUSE "dovybavena" proti vůli uživatele. Po chvíli na novém systému jsem si pro pohodlí opatřil grafický package manager Smart, známý i z openSUSE, či Ubuntu, což považuji za nejrozumnější alternativu package managementu z Yastu.
Provoz systému a nastavení zatím také není nijak problematické - po instalaci fglrx z non-free a lehké konfiguraci funguje bez problémů big desktop, tiskárna po konfiguraci v CUPS též a překvapivě i scanner, a to bez jakékoliv konfigurace. :-O Osobně mi ale zatím stále schází něco podobného YaSTu - kompletní ovládací centrum pro celý systém. God bless YaST!
Výsledkem je ale to, o co mi šlo - získat plnohodnotnou náhradu openSUSE s tím, že pod ní budu moci nativně provozovat Agros2D (použil jsem ovšem Ubuntí balíček 
).
Z pohledu člověka zvyklého na openSUSE je přechod na Debian překvapivě snadný. Na rychlé rozeběhnutí systému není třeba znát prakticky nic navíc oproti openSUSE, systém balíčků má dobrou konzistenci a výsledkem je stejně vždycky takový desktop, jakým si jej uživatel udělá. Bonusem je "větší" výběr balíčků - realita je ale závislá na konkrétní aplikaci.
Právě se mi podařilo zreprodukovat bug s apt-get -f install. Příkladem je instalace balíku qt3-assistant. Výstup aptu vypadá následovně:
root@pushkin:/home/data/Debian Wheezy# apt-get install qt3-assistant Čtu seznamy balíků… Hotovo Vytvářím strom závislostí Čtu stavové informace… Hotovo Pro opravení následujících můžete spustit „apt-get -f install“: Následující balíky mají nesplněné závislosti: qt3-assistant : Závisí na: qt3-doc ale nebude se instalovat E: Nesplněné závislosti. Zkuste spustit „apt-get -f install“ bez balíků (nebo navrhněte řešení).
Takže jsem provedl apt-get -f install. Vše se nakonec samozřejmě nainstalovalo:
root@pushkin:/home/data/Debian Wheezy# apt-get -f install Čtu seznamy balíků… Hotovo Vytvářím strom závislostí Čtu stavové informace… Hotovo Opravuji závislosti… Hotovo Následující extra balíky budou instalovány: qt3-assistant qt3-doc Navrhované balíky: libqt3-headers Následující NOVÉ balíky budou nainstalovány: qt3-assistant qt3-doc 0 aktualizováno, 2 nově instalováno, 0 k odstranění a 71 neaktualizováno. 1 instalováno nebo odstraněno pouze částečně. Potřebuji stáhnout 5 836 kB archivů. Po této operaci bude na disku použito dalších 27,2 MB. Chcete pokračovat [Y/n]? Y Mám:1 http://ftp.zcu.cz/mirrors/debian/ wheezy/main qt3-doc all 3:3.3.8b-11 [5 578 kB] Mám:2 http://ftp.zcu.cz/mirrors/debian/ wheezy/main qt3-assistant amd64 3:3.3.8b-11 [257 kB] Staženo 5 836 kB za 0s (37,2 MB/s) Selecting previously unselected package qt3-doc. (Čtu databázi … nyní je nainstalováno 186010 souborů a adresářů.) Rozbaluji qt3-doc (z …/qt3-doc_3%3a3.3.8b-11_all.deb) … Selecting previously unselected package qt3-assistant. Rozbaluji qt3-assistant (z …/qt3-assistant_3%3a3.3.8b-11_amd64.deb) … Zpracování spouštěčů pro balík man-db … Zpracování spouštěčů pro balík menu … Nastavuji balík qt3-doc (3:3.3.8b-11) … Nastavuji balík qt3-assistant (3:3.3.8b-11) … update-alternatives: používám /usr/bin/assistant-qt3 pro poskytnutí /usr/bin/assistant (assistant), automatický režim. Nastavuji balík qcad-doc (2.0.5.0-1-2.1) … Zpracování spouštěčů pro balík menu …
Tušíte někdo, proč to?
Tiskni
Sdílej:
Ale fungují bez něj jiní, tak si snad také zvyknu. Jinak RPM z DEBka jde udělat alienem, ale to jsem nezkoušel, z podobných pokusů jsem vyléčen od chvíle, co jsem se pokoušel některé Fedoři RPMko naroubovat do openSUSE - díky závislostem jsem stahoval a hledal asi hodinu balíčky a pak jsem zjistil, že to prostě nepůjde díky odlišné verzi některé knihovny :-/
Díky, zkusím
27.3.2012 18:46
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
27.3.2012 22:42
Dreit | skóre: 15
| blog: Dreit a jeho dračí postřehy
| Královehradecký kraj
Koukám že nejsem sám 
29.3.2012 07:56
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
29.3.2012 16:01
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
Note Although the aptitude command comes with rich features such as its enhanced package resolver, this complexity has caused (or may still causes) some regressions such as Bug #411123, Bug #514930, and Bug #570377. In case of doubt, please use the apt-get and apt-cache commands over the aptitude command.Ja osobne som to našiel niekde v poznámkach v Debiane, pred asi štyrmi rokmi. Neviem či to nebolo priamo dopísané v helpe k Aptitude :)
29.3.2012 18:03
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
29.3.2012 18:10
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
29.3.2012 09:55
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
Tak mi najdi něco jiného, co má schopnosti svaté krávy.Kalousek?
Mě třeba ta minimalističnost instalace vyhovuje. Prostě rychle nainstalovat základ z cd, rozjet síť, openssh a zbytek se dá dodělat později z pohodlí domova.
Rozdělovač disku je taky imho v pohodě. Lze s ním provádět LVM na dm-raidem, a větší vymoženost co by byla potřeba mě nenapadá.
27.3.2012 15:37
Dreit | skóre: 15
| blog: Dreit a jeho dračí postřehy
| Královehradecký kraj
Když vybereš "expertní instalaci" (v pokročilých volbách), tak ti nabídne jestli chceš rovnou přidat contrib a non-free
27.3.2012 22:45
Dreit | skóre: 15
| blog: Dreit a jeho dračí postřehy
| Královehradecký kraj
Já taky, i když potom si to dloooooooouhym seznamem "nezbytných" balíků zase rychle zase*u
1) Copak je tam špatně, že je třeba používat volbu -f?
27.3.2012 21:07
28.3.2012 08:29
27.3.2012 15:54
28.3.2012 09:00
28.3.2012 10:39
29.3.2012 16:11
27.3.2012 14:37
27.3.2012 15:52
27.3.2012 14:42
27.3.2012 16:38
27.3.2012 17:36
apt-get install XXX, na což mi apt odpověděl, že balíček XXX vyžaduje balíky YYY a ZZZ, které se nebudou instalovat. Pro vyřešení problému zadejte apt-get -f install. No a když jsem to zadal, tak se dané balíky stejně nainstalovaly V danou chvíli mi přišlo, že jde o to, že daný balík závisí na knihovnách z non-free, ale vzhledem k tomu, že se mi to nedaří zopakovat, tak netuším :-/
Jinak kdybys měl zájem na vývoji spolupracovat, nějaký balič do RPM by se určitě šiknul. Každopádně díky za nabídku!
28.3.2012 07:12
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
/etc/network/interfaces (dohromady) v openSUSE v /etc/sysconfig/network/ (souborech pro každý interface zvlášť) a v CentOS v /etc/sysconfig/network-scripts (zvlášť). Proč to mám znovu hledat, kde ta která konfigurace je zrovna v této distribuci.
/etc/NetworkManager/system-connections/ je (nebo by mělo být) všude stejné ...
Jednak Network Manager používám tak maximálně na notebooku, ale ne na serverech a ani ne na stacionárních pracovních stanicích, které mají fixní interface.Tak pokud žádáš sjednocení, tak bys měl doufat, že časem budeš pohodlně používat NM všude :).
Za druhé tohle byl jen jeden příklad, který mne napadl, protože jsem se s ním potkal v minulém měsíci. Těch příkladů v rozdílném umístění konfigurace je mnohem více.Jen bych tě rád upozornil, že tohle záleží na tvůrcích distribucí. Každá z distribucí může přijít s nějakou inovací, změnou. Každá jiná distribuce může danou změnu přijmout či odmítnout. Některé věci budou v konkrétních distribucích odlišné už z principu (třeba Gentoo nebude mít stejnou konfiguraci systému pro správu instalovaného software jako Fedora). U těch, které můžou být společné, se naráží na problémy jak v kvalitě inovací, tak v úsudku těch, kdo je mají přijmout „jinde“. Třeba NetworkManager byl do několika distribucí přijat ve stavu, kdy byl vyloženě desktop-only. Až se začnou rozšiřovat IPv6-only sítě, bude zase všechno jinak :). Já zase nevím, co bys ve světě distribucí čekal? Kdyby byly všechny stejné, tak se z nich dá udělat jedna a měnit jenom logo :D.
Tak pokud žádáš sjednocení, tak bys měl doufat, že časem budeš pohodlně používat NM všude :).Taková představa o budoucnosti mi přijde naprosto děsivá :) Pochybnější kus softwaru než NM aby jeden pohledal... Po pravdě řečeno, nejlepší způsob konfigurace sítě je stejně jednoduchý skript, který párkrát zavolá
ip a spol. Je to perfektně přehledné a pokud potřebuji cokoliv méně obvyklého (třeba policy-based routing), mohu to do toho skriptu triviálně připsat.
Taková představa o budoucnosti mi přijde naprosto děsivá :)To tě naprosto chápu :).
Pochybnější kus softwaru než NM aby jeden pohledal...Asi bych se měl rovnou přiznat, že se účastním výběrovky právě na vývoj NetworkManageru. A nezávisle na tom už mám v merku i nějaké ty návrhové chyby.
Po pravdě řečeno, nejlepší způsob konfigurace sítě je stejně jednoduchý skript, který párkrát zavolá ip a spol.Máš naprostou pravdu. Dělám to tak, kdykoli distribuční nástroj nezvládá. A jediný nástroj, u kterého se mi to nestává, jsou interfaces v Debianu, kde se dají příkazy vepisovat přímo do konfigurace. Jako kernelář a síťař podle mě ani nemůžeš mít NetworkManager rád, protože to dělá příliš mnoho věcí samo. Ale rád bych se tě zeptal na návrh řešení následujícího zadání: Chci uzpůsobit (jakoukoli) distribuci instalovanou na notebook či jiné mobilní zařízení tak, aby šel drátově či bezdrátově připojit do libovolné sítě s nějakou automatickou konfigurací. Ty sítě můžou mít automatickou konfiguraci řešenou různě. Testovací schémata jsou následující (všechny z praxe): 1) IPv4 adresy, gateway a IPv4 DNS z DHCP 2) IPv4 adresy, gateway a IPv4 DNS z DHCP, IPv6 adresy a gateway z RA 3) IPv6 adresy, gateway a IPv6 DNS z RA 4) IPv6 adresy a gateway z RA, IPv6 DNS z DHCPv6 5) IPv6 adresy a IPv6 DNS z DHCPv6, IPv6 gateway z RA Komlikovanější schémata zatím nechme stranou, ale přidejme ještě jeden požadavek, a to aby ten systém uměl sdělit uživateli a aplikacím, jestli je připojení k síti a plně zkonfigurovaný nebo ne. Samotný dhclient momentálně zvládá pouze 1 a 2 (s tím, že IPv6 pro 2 zajišťuje trochu netypicky jádro). NetworkManager momentálně z DNS konfiguruje jenom RDNSS, ale DNSSL půjde celkem jednoduše přidat. Pak má NM ještě problémy s timeouty u RDNSS, ale to je částečně i kvůli blbě napsanému RFC, když nepočítám regresi v poslední verzi ve F17, kde už to nefunguje vůbec. Já osobně zatím vidím nejjednodušší řešení v opravě NetworkManageru nebo v napsání software, který bude mít podobnou architekturu jako NM a tudíž se ti nebude líbit. Obchází se tím i komplikace, kdy v linuxovém jaderném světě se DNS de facto nepovažuje za součást síťové konfigurace, zatímco uživatel je obvykle bez DNS dost v háji. Nad tím se blbě staví tenká architektura, kde se o každou síťovou věc stará jiný démon a celé to zastřešuje pouze kernel.
A jediný nástroj, u kterého se mi to nestává, jsou interfaces v Debianu, kde se dají příkazy vepisovat přímo do konfigurace.Ty jsou z těch lepších, ale selžou například v okamžiku, kdy chci na ethernetu používat více VLANů přes 802.1q.
Přijde mi, že nejzásadnější návrhová chyba Network Manageru je ta, že je to nástroj o několik řádů komplikovanější, než problém, který se snaží řešit. Zdrojáky verze 0.8.1 mají přes 65000 řádků, ačkoliv celý program v podstatě nic složitého nedělá.Nemůžu posoudit, zatím jsem se díval pouze do zdrojových kódů částí okolo IPv6 a ty byly celkem přehledné a dělaly víceméně co bylo potřeba. Takže mě čeká nějaké ošklivé překvapení, že?
Ještě donedávna se ani nebyl schopen vyrovnat s prostým faktem, že jeden počítač může používat více uživatelů, a myslím, že dodnes se pořádně neumí vyrovnat s případem, kdy je jeden počítač připojen k síti dvěma rozhraními (typicky WiFi + ethernet).O tom se teďka docela hodně mluví.
Souhlasím s Tebou, že nějaký daemonek na automatickou konfiguraci sítě se hodí, ale měl by být především navržen tak, aby byl velmi jednoduchý, uměl fungovat i na holém systému bez všelijakých DBUSůTak zrovna D-bus mi připadá jako celkem rozumný požadavek. Ale jak říkám, chápu tvé výtky.
Ty jsou z těch lepších, ale selžou například v okamžiku, kdy chci na ethernetu používat více VLANů přes 802.1q.Tak na to mi naopak debianí interfaces vyhovovaly perfektně.
Takže mě čeká nějaké ošklivé překvapení, že?Tipl bych si, že ještě nejedno :) Ale držím palce.
Tak na to mi naopak debianí interfaces vyhovovaly perfektně.No jo, ale to mně nutí ke konkrétnímu způsobu pojmenování interfaců – daleko přehlednější mi přijde pojmenovávat VLANky podle toho, k čemu se používají, namísto čísel. Navíc je to použitelné jen tehdy, když se o VLANky stará driver 8021q. Jakmile je spravuje přímo síťová karta (což je běžné u různých integrovaných ethetnetových switchů), už to popsat nejde.
Tipl bych si, že ještě nejedno :) Ale držím palce.Děkuju ti.
No jo, ale to mně nutí ke konkrétnímu způsobu pojmenování interfaců – daleko přehlednější mi přijde pojmenovávat VLANky podle toho, k čemu se používají, namísto čísel.A zkoušel jsi to? :).
Navíc je to použitelné jen tehdy, když se o VLANky stará driver 8021q. Jakmile je spravuje přímo síťová karta (což je běžné u různých integrovaných ethetnetových switchů), už to popsat nejde.Popravdě s tímhle mají problémy i v konfiguraci OpenWRT, které je na routery specializované. Switche se zpravidla konfigurují trochu jinak než VLANy na klasických kartách. Jestli to je zavedeno do debian interfaces, to nevím, ale pokud na tom někomu záleží, jistě není problém to doplnit stejně jako jsou doplněné VLANy na eth rozhraních.
A zkoušel jsi to? :).Nezkoušel, ale nevím, kde by v případě jména, které neobsahuje číslo VLANky, ten konfigurátor číslo VLANky našel. (Možná na to nějaký atribut existuje, ale jak se jmenuje? Dokumentace je velmi skoupá, manuálová stránka možnost konfigurovat VLANky vůbec nezmiňuje.) Mimochodem, jde debianími interfaces popsat rozhraní s více IP adresami?
Popravdě s tímhle mají problémy i v konfiguraci OpenWRT, které je na routery specializované. Switche se zpravidla konfigurují trochu jinak než VLANy na klasických kartách. Jestli to je zavedeno do debian interfaces, to nevím, ale pokud na tom někomu záleží, jistě není problém to doplnit stejně jako jsou doplněné VLANy na eth rozhraních.Ale jistě, doplnit jde ledacos. Ale dává smysl, aby každou pro každou z desítek featur síťového subsystému musel existovat zvláštní hack v konfigurátoru interfaců? Já na svých strojích konverguji k tomu, že konfigurace sítě je shellový skript, který si na ty operace, které nejsou úplně triviální, volá předdefinované funkce.
Nezkoušel, ale nevím, kde by v případě jména, které neobsahuje číslo VLANky, ten konfigurátor číslo VLANky našel.Těch direktiv na VLANy je víc než jen vlan_raw_device.
Mimochodem, jde debianími interfaces popsat rozhraní s více IP adresami?Jde. Pomocí aliasů. A není to jediný nedostatek interfaces, například mi vadí, že se délka prefixu IPv4 musí zadávat po staru maskou, že délka prefixu nejde prostě připsat k adrese CIDR notací. Našlo by se toho víc. Ale při troše snahy to použít jde.
Ale jistě, doplnit jde ledacos. Ale dává smysl, aby každou pro každou z desítek featur síťového subsystému musel existovat zvláštní hack v konfigurátoru interfaců?Tak, pokud nechceš používat všude přímo příkazy, což samozřejmě v interfaces můžeš, v tom ti nikdo nebrání, ale poskytuje to určité nepohodlí v tom, že musíš psát i zrušení té stejné konfigurace. Prostě typické důsledky rozdílu mezi deklarativním a imperativním konfiguračním jazykem.
Já na svých strojích konverguji k tomu, že konfigurace sítě je shellový skript, který si na ty operace, které nejsou úplně triviální, volá předdefinované funkce.Chápu. Ale budeš jeden z mála :). Já to naposledy takhle dělal před mnoha lety v nějakém SUSE, kde nešlo do konfigurace pořádně napsat bridge.
Těch direktiv na VLANy je víc než jen vlan_raw_device.Kde je najdu? Manpage mlčí.
Jde. Pomocí aliasů.Argh, já nechci obskurní virtuální interfacy určené pro kompatibilitu s preglaciální érou. Já chci jeden interface s několika adresami :) To je vůbec druhá věc, která mi na debianím
ifupu vadí: ještě stále používá naprosto obsoletní kernelové rozhraní, takže většina nových kernelových featur buďto není k dispozici, nebo se musí popisovat obskurně.
Tak, pokud nechceš používat všude přímo příkazy, což samozřejmě v interfaces můžeš, v tom ti nikdo nebrání, ale poskytuje to určité nepohodlí v tom, že musíš psát i zrušení té stejné konfigurace. Prostě typické důsledky rozdílu mezi deklarativním a imperativním konfiguračním jazykem.Lze nicméně nalézt kompromis mezi deklarativností a imperativností: Jednou (imperativně) popíši, jak se zakládá a maže VLAN, a pak to vícekrát (deklarativně) použiji u jednotlivých rozhraní. Přesně tohle od systému na konfiguraci sítě čekám: vlastnosti rozhraní by neměly být zadrátované do programu, každou z nich bych si měl mít možnost nadefinovat.
Kde je najdu? Manpage mlčí.Chyba je samozřejmě na mé straně, špatně jsem si to pamatoval, nejspíš kvůli záměně s bridgováním. Ale, díky tobě jsem si všiml, že se vlany dají nastavovat přes ip. Dosud jsem měl za to, že se nastavují pouze přes vconfig, a ten zřejmě neumí vše to, co ip.
Argh, já nechci obskurní virtuální interfacy určené pro kompatibilitu s preglaciální érou. Já chci jeden interface s několika adresami :)Můžeš následně příkazem ip ověřit, co ve skutečnosti vzniklo :).
To je vůbec druhá věc, která mi na debianím ifupu vadí: ještě stále používá naprosto obsoletní kernelové rozhraní, takže většina nových kernelových featur buďto není k dispozici, nebo se musí popisovat obskurně.Jo. Debianí konfigurace je sto let za opicema. Prostě není s čím tak úplně srovnávat.
Lze nicméně nalézt kompromis mezi deklarativností a imperativností: Jednou (imperativně) popíši, jak se zakládá a maže VLAN, a pak to vícekrát (deklarativně) použiji u jednotlivých rozhraní.Dá se, ale z globálního pohledu je lepší mít ten popis deklarativního jazyka ustálený a oddělený. Spousta lidí dává mnohem lepší výsledky, když už je to pro ně trochu foolproof.
Přesně tohle od systému na konfiguraci sítě čekám: vlastnosti rozhraní by neměly být zadrátované do programu, každou z nich bych si měl mít možnost nadefinovat.Ta tvá představa mi pořád není úplně jasná.
Ta tvá představa mi pořád není úplně jasná.Představuji si to asi takhle: konfigurační program zná nějakou základní množinu vlastností síťových rozhraní, které umí sám nastavovat, a pak umožňuje definovat vlastnosti nové spolu s pravidly na jejich nastavování. Tedy kupříkladu kdybych chtěl rozhraním přidělovat IPX adresy, nadefinuji nový atribut ipx-address a k němu dva příkazy: jeden, který se má vykonat při nahazování interfacu, druhý při shazování. A pak už budu k jednotlivým rozhraním jen připisovat nový atribut a vše bude fungovat.
Dá se, ale z globálního pohledu je lepší mít ten popis deklarativního jazyka ustálený a oddělený.To je dobrý důvod k tomu, aby jazyk nabízel bohatou standardní knihovnu vlastností, nikoliv aby nešlo nové dodefinovat.
Tedy kupříkladu kdybych chtěl rozhraním přidělovat IPX adresy, nadefinuji nový atribut ipx-address a k němu dva příkazy: jeden, který se má vykonat při nahazování interfacu, druhý při shazování. A pak už budu k jednotlivým rozhraním jen připisovat nový atribut a vše bude fungovat.Jo, to zní docela rozumně. Jako příjemný bonus. Ale mě teďka daleko víc zajímá zpracování automatické konfigurace Wifi, IPv4 a IPv6, což je věc, která mi jako celek nefunguje správně nikde. Ani s NetworkManagerem, ani s jiným démonem.
To je dobrý důvod k tomu, aby jazyk nabízel bohatou standardní knihovnu vlastností, nikoliv aby nešlo nové dodefinovat.To jo. Omezení množiny vlastností může mít jiné výhody, které ale člověk hned nedocení, když se na systém dívá z pohledu, kdy programátor, administrátor i uživatel jsou jedna osoba.
To jo. Omezení množiny vlastností může mít jiné výhody,Jaké vlastně?
Jaké vlastně?Omezená množina nastavení umožňuje postavit dobré klikátko, webovou administraci a třeba i CLI jehož model odpovídá těm předchozím. To vše s mnohem menším prostorem pro chyby. Podle mě nic, co by zrovna tobě vyhovovalo :). V podstatě se jedná o abstrakci, která ti třeba umožňuje sjednotit pohled na několik různých věcí. Zkus si třeba představit, že by každý druhý člověk měl na základě ústně předaných informací o IP adrese, bráně apod sestavit skript, který zajistí konfiguraci systému pro danou síť. Tak to nefunguje. Za to když omezíš celou konfiguraci na pár políček, ve kterých se nastaví dané hodnoty, tak je to ok. Můžeš namítnout, že v backendu není potřeba nic omezovat a že klikátko zobrazí jen podmnožinu konfigurace. Pak se ale dostaneš do situace, kdy změna expertním nástrojem bude často nedetekovatelné pohledem do toho GUI nástroje. Tudíž přestanou fungovat všechny standardní návody kromě těch, které začínají vyresetováním celé konfigurace (či reinstalací).
Tak to nefunguje. Za to když omezíš celou konfiguraci na pár políček, ve kterých se nastaví dané hodnoty, tak je to ok.To, že je to OK, je pouze iluze. Dnešní svět sítí zkrátka je složitý a dříve či později potkáš situaci, kterou nástrojem se třemi nastavitelnými parametry vyřešit nejde. Myslím si, že je zásadní chyba chtít v takovém případě po uživatelích, aby nástroj zahodili a síť si najednou začali konfigurovat úplně jinak. Daleko lepší je, když jim spřátelený počítačový kouzelník poradí, aby na nějaké místo připsali magické zaříkávadlo. Zbytku konfigurace pak stále budou rozumět a když se přestěhují do jiné sítě, zaříkávadlo budou zase umět vypnout. Obecně: přijde mi velmi důležité, aby se nástroje chovaly spojitě. Tedy aby se pomocí nich daly jednoduché problémy vyřešit jednoduše a ty složité o něco složitěji. Nikoliv aby v triviálním případě šlo nástroj používat triviálně a v jakémkoliv jiném to nešlo vůbec. Skálopevné přesvědčení programátorů o tom, že vědí, co přesně uživatelé budou potřebovat, je příznakem naprosté naivity. Skutečnost je taková, že ani programátoři, ani uživatelé nevědí, co je čeká zítra. Takže dobrý program musí počítat s nečekaným a být dost flexibilní na to, aby se ono nečekané dalo zvládnout, byť třeba ne pohodlně. Ušít nástroj na míru největšímu ignorantovi z okolí a nestarat se o pokročilejší uživatele, je zkrátka cesta do pekel. Smutné je, že Gnome se po této cestě vydal.
Můžeš namítnout, že v backendu není potřeba nic omezovat a že klikátko zobrazí jen podmnožinu konfigurace.To samozřejmě namítnu, protože stačí nad návrhem klikátka trochu přemýšlet a vybavit ho textovým polem, ve kterém se taková nastavení objeví. I uživatel, který jim nebude rozumět, bude vědět, že tam jsou, a bude je moci smazat.
Dnešní svět sítí zkrátka je složitý a dříve či později potkáš situaci, kterou nástrojem se třemi nastavitelnými parametry vyřešit nejde. Myslím si, že je zásadní chyba chtít v takovém případě po uživatelích, aby nástroj zahodili a síť si najednou začali konfigurovat úplně jinak.V tomhle se neshodnem. Pokud nelze udělat nástroj, který plně vyhovuje jak běžnému síťování, tak tomu advanced (a v tomhle případě se tím myslí hodně advanced, protože do té základní konfigurace lze schovat docela hodně věcí, které kdekdo považuje za nadstandard), tak může být vhodnější použít nástroje dva. Byť by ten druhý byl právě shell skript s voláním příkazu ip.
Daleko lepší je, když jim spřátelený počítačový kouzelník poradí, aby na nějaké místo připsali magické zaříkávadlo. Zbytku konfigurace pak stále budou rozumět a když se přestěhují do jiné sítě, zaříkávadlo budou zase umět vypnout.Vycházíš z toho, že se nemalé procento lidí setká ze situací, která nejde vyřešit základními nástroji. Já s tímhle předpokladem nesouhlasím a dokonce si myslím, že NetworkManager (nebo kterýkoli nástroj, který by ho měl nahradit), dokáže (z hlediska koncepce) pokrýt potřeby začátečníků, pokročilých i lidí jako jsme my. To vše za předpokladu, že se jedná o stroj, který chceme připojit k síti nebo více sítím, tedy koncový bod, ne router. Jestliže NM dokáže poskytnout do určité míry routerovou konfiguraci, je to podle mě trochu omyl, spíš úlitba pro případ, kdy chce začátečník zřídit Wifi AP apod. Na skutečný router v tuhle chvíli NM není vhodný a neumím si zatím představit, že by někdy byl. I když to co mají v OpenWRT je svým způsobem trochu podobné a funguje to jakž takž ke spokojenosti.
Obecně: přijde mi velmi důležité, aby se nástroje chovaly spojitě. Tedy aby se pomocí nich daly jednoduché problémy vyřešit jednoduše a ty složité o něco složitěji. Nikoliv aby v triviálním případě šlo nástroj používat triviálně a v jakémkoliv jiném to nešlo vůbec.Obecně je to dobrý nápad, pro tento konkrétní případ ale nevidím uspokojivé řešení.
Skutečnost je taková, že ani programátoři, ani uživatelé nevědí, co je čeká zítra. Takže dobrý program musí počítat s nečekaným a být dost flexibilní na to, aby se ono nečekané dalo zvládnout, byť třeba ne pohodlně.Svět počítačových sítí je docela dost pasivní a to, co se v něm vytváří nového se zdaleka nemusí druhý den začít používat. Mnohem důležitější mi přijde, aby nástroj typu NM nepřekážel tomu, když si chci s nějakým rozhraním naložit po svém, což lze. Ono stačí se podívat na IPv6, jakou za sebou má historii :).
Ušít nástroj na míru největšímu ignorantovi z okolí a nestarat se o pokročilejší uživatele, je zkrátka cesta do pekel. Smutné je, že Gnome se po této cestě vydal.No počkej, to bych si mohl vzít jako spokojený uživatel Gnome a skoro spokojený uživatel NetworkManageru osobně. Jenže já jsem k tomu přišel trochu z jiné strany než ty. Já jsem vzal nějakou verzi Fedory a začal jsem ji úmyslně používat „tak jak je“, tedy včetně výběru základních programů jako Evolution, a včetně výběru výchozího prostředí, tedy Gnome 3, a postupně jsem se téměř smířil s tím NetworkManagerem.
To samozřejmě namítnu, protože stačí nad návrhem klikátka trochu přemýšlet a vybavit ho textovým polem, ve kterém se taková nastavení objeví. I uživatel, který jim nebude rozumět, bude vědět, že tam jsou, a bude je moci smazat.Jo, to je pravda, stačí vytvořit nějaký about:config jako ve Firefoxu apod. V podstatě jediný důvod, proč tomu tak u NM není je to, že se hřeší na textovou konfigurační databázi, kde každé rozhrané má textovou konfiguraci ve formě název-hodnota. Alespoň tedy pokud se používá rhplugin, s vestavěnou konfigurací jsem NM ještě nepoužíval. Takže ano, v tuhle chvíli se dají konfigurovat i hodnoty, které v GUI nejsou, a je možné rozbít konfiguraci tak, aby to uživatel přes GUI dohromady nedal.
Pokud nelze udělat nástroj, který plně vyhovuje jak běžnému síťování, tak tomu advanced (a v tomhle případě se tím myslí hodně advanced, protože do té základní konfigurace lze schovat docela hodně věcí, které kdekdo považuje za nadstandard), tak může být vhodnější použít nástroje dva.Ale zajisté. Jenže důkaz toho, že to nejde, zatím nikdo nepřednesl a naopak mám důvodné podezření, že to jde a že to není zase tak těžké.
Vycházíš z toho, že se nemalé procento lidí setká ze situací, která nejde vyřešit základními nástroji.Vycházím a realita mi to potvrzuje – vzhledem k tomu, že takoví lidé často přicházejí pro radu ke mně, vím, že jich není málo. (Typické příklady: WiFi síť, která vyžaduje méně obvyklý mód autentikace. Nebo ethernet s autentikací přes 802.1x.)
Jestliže NM dokáže poskytnout do určité míry routerovou konfiguraci, je to podle mě trochu omyl,Po routerové konfiguraci nevolám. Ale například zmiňovaná možnost připojit se na jednom rozhraní do více VLANek rozhodně není omezena jen na routery.
No počkej, to bych si mohl vzít jako spokojený uživatel Gnome a skoro spokojený uživatel NetworkManageru osobně.I když ušijí software na míru idiotům, rozhodně to neznamená, že nemůže náhodou vyhovovat i někomu jinému
[...] a postupně jsem se téměř smířil s tím NetworkManagerem.To je vskutku rozdíl mezi námi. Já se s věcmi jen tak nesmiřuji, většinou si rozmyslím, čeho přesně chci dosáhnout, a teprve pak hledám nástroje, které mi to umožní. Přeci nebudu celý život používat jenom křížový šroubovák a smiřovat se s tím, že ne všechny šrouby mají křížovou hlavu.
Obecně je to dobrý nápad, pro tento konkrétní případ ale nevidím uspokojivé řešení.Ve svém minulém příspěvku jsem takové řešení navrhl. V čem není uspokojivé?
Ale zajisté. Jenže důkaz toho, že to nejde, zatím nikdo nepřednesl a naopak mám důvodné podezření, že to jde a že to není zase tak těžké.Já nemám víc než osobní zkušenost ohledně toho, co mi v jakém případě vyhovuje.
Vycházím a realita mi to potvrzuje – vzhledem k tomu, že takoví lidé často přicházejí pro radu ke mně, vím, že jich není málo. (Typické příklady: WiFi síť, která vyžaduje méně obvyklý mód autentikace. Nebo ethernet s autentikací přes 802.1x.)Tady bych rozlišoval věci, na které daný nástroj není vhodný koncepčně, a věci, které prostě jen (zatím) neumí.
Po routerové konfiguraci nevolám. Ale například zmiňovaná možnost připojit se na jednom rozhraní do více VLANek rozhodně není omezena jen na routery.Tak tohle bych rozhodně neřadil do kategorie těch, co od začátku koncepčně nevyhovují.
I když ušijí software na míru idiotům, rozhodně to neznamená, že nemůže náhodou vyhovovat i někomu jinémuA já myslel, že to „na míru idiotům“ by mělo jít vyvodit z toho, že „nikdo jiný než idiot to nebude chtít používat“? Pokud bys vzal za vděk předpokladem, že nejsem idiot, tak bych v tomto případě byl protipříkladem :).
To je vskutku rozdíl mezi námi. Já se s věcmi jen tak nesmiřuji, většinou si rozmyslím, čeho přesně chci dosáhnout, a teprve pak hledám nástroje, které mi to umožní.Tímhle způsobem pracuju na většině svých domácích miniprojektů. V první fázi napíšu skript, který provede přesnou akci. V druhé fázi zavedu určitou genericitu, aby byl skript parametrizovatelný. Ve třetí fázi si k tomu udělám interface, který mi vyhovuje. A po celou dobu to můžu používat, ale to ještě neznamená, že ten výsledek či spíše mezivýsledek každému druhému doporučím :).
Přeci nebudu celý život používat jenom křížový šroubovák a smiřovat se s tím, že ne všechny šrouby mají křížovou hlavu.Tak s křížovou hlavou jsem celkem smířený už dlouho, i když občas na speciální účel pokoukávám po hvězdách.
Ve svém minulém příspěvku jsem takové řešení navrhl. V čem není uspokojivé?Podle mě, když do NM přidáme záložku advanced, kde bude k dispozici editovatelný seznam atributů rozhraní, tak to na tvé nespokojenosti nic nezmění.
Tady bych rozlišoval věci, na které daný nástroj není vhodný koncepčně, a věci, které prostě jen (zatím) neumí.Jenže věci, které zatím neumí, vždycky nějaké budou a jádro se vyvíjí daleko rychleji než uživatelské nástroje, takže pokud nástroj nabízí pevnou množinu vlastností bez možnosti rozšíření, není vhodný koncepčně.
Podle mě, když do NM přidáme záložku advanced, kde bude k dispozici editovatelný seznam atributů rozhraní, tak to na tvé nespokojenosti nic nezmění.Pokud tím půjde dostatečně ovlivnit všechno, co NM dělá, tak to mou nespokojenost značně zmenší. Zbytek té nespokojenosti pramení zejména z toho, že NM je obluda, což nepřímo způsobuje, že jeho činnost je velmi těžko debugovatelná. Od programu, který se snaží dělat cokoliv automaticky, bych čekal, že bude umět produkovat velmi detailní log, ze kterého půjde poznat, co se děje. A že i obyčejný uživatel bude mít možnost si tento log vyžádat, aby ho svému čaroději poslal.
Jenže věci, které zatím neumí, vždycky nějaké budou a jádro se vyvíjí daleko rychleji než uživatelské nástroje, takže pokud nástroj nabízí pevnou množinu vlastností bez možnosti rozšíření, není vhodný koncepčně.Otázka ale přece není, jestli nabízí nebo nenabízí rozšíření vlastností, otázka je pouze jak se to rozšíření realizuje.
Pokud tím půjde dostatečně ovlivnit všechno, co NM dělá, tak to mou nespokojenost značně zmenší.Možná tě od května budu otravovat konkrétnějšími otázkami na tvoji představu :).
Zbytek té nespokojenosti pramení zejména z toho, že NM je obluda, což nepřímo způsobuje, že jeho činnost je velmi těžko debugovatelná.Odobludování je strašná práce :).
Od programu, který se snaží dělat cokoliv automaticky, bych čekal, že bude umět produkovat velmi detailní log, ze kterého půjde poznat, co se děje.Já si už nějakou dobu nechávám do /tmp posílat detailní log a řekl bych, že je dost výmluvný.
Otázka ale přece není, jestli nabízí nebo nenabízí rozšíření vlastností, otázka je pouze jak se to rozšíření realizuje.Nutnost rozšíření doprogramovat v Céčku mi moc přijatelná nepřijde
Možná tě od května budu otravovat konkrétnějšími otázkami na tvoji představu :).Rád je uslyším.
Odobludování je strašná práce :).No jo, tak proč tam ty obludy strkali?
Já si už nějakou dobu nechávám do /tmp posílat detailní log a řekl bych, že je dost výmluvný.Teď nemám po ruce žádný stroj s NM, ale jestli mi ukázku logu pošleš, rád si počtu a spravím si názor. Mimochodem, jak si jako obyčejný uživatel takový log pořídím?
Nutnost rozšíření doprogramovat v Céčku mi moc přijatelná nepřijdeJá na to nemám až tak vyhraněný názor.
Rád je uslyším.V to doufám :).
No jo, tak proč tam ty obludy strkali?To naštěstí nebude otázka na mě :). Alespoň zatím.
Teď nemám po ruce žádný stroj s NM, ale jestli mi ukázku logu pošleš, rád si počtu a spravím si názor.https://bugzilla.redhat.com/show_bug.cgi?id=753482 Doporučuju číst od konce.
Mimochodem, jak si jako obyčejný uživatel takový log pořídím?Tak, že administrátor ty logy vůbec zapne. Ale problém je, že jsou docela dost živé, takže třeba já si je radši posílám do /tmp na tmpfs, než na disk. Vyžaduje to trochu víc konfigurace. Pokud máš nějakou radu na tohle, taky si ji rád vyslechnu. Zatím mi syslog celkem vyhovuje. Jistě by to šlo mírně poladit.
Já na to nemám až tak vyhraněný názor.Já v tom vidím jeden obrovský rozdíl: připsat řádek do konfigurace umím poradit po telefonu nebo mailem, připsat 100 řádků Céčka a přeložit už ne
https://bugzilla.redhat.com/show_bug.cgi?id=753482To jsou logy pro někoho, kdo se vyzná ve zdrojácích NM. Rozhodně nic, podle čeho by správce systému mohl pohodlně zjistit, v čem je problém. Hlášky typu "Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled..." toho mnoho neříkají. Kdyby radši zalogoval, co s tím rozhraním přesně dělá.
Tak, že administrátor ty logy vůbec zapne.No právě... Od pohodlného GUI čekám, že když nastane chyba, bude mi samo umět zobrazit detailní informace o tom, co se pokazilo, abych věděl, jestli správným řešením je oeditovat heslo, vytáhnout a zatáhnout kabel, sesílat hromy a blesky na správce místní sítě nebo odinstalovat NM