Ondsel, tj. vylepšený FreeCAD, po dvou letech skončil. Cílem Ondselu bylo vylepšit UX/UI FreeCADu a nabízet jej komerčně. Od začátku věděli, že konkurovat komerčním CADům bude těžké. Bylo to ale těžší, než si mysleli. Proprietární CADy se vyučují na školách a jsou hluboce zakořeněny v průmyslu. Většina vylepšení od Ondselu se dostane do FreeCADu.
Desktopové prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklé sloučením projektů Razor-qt a LXDE bylo vydáno ve verzi 2.1.0. Přehled novinek v poznámkách k vydání.
Aplikace LocalSend, tj. multiplatformní open source alternativa k AirDropu, tj. bezpečné sdílení souborů a zpráv s okolními zařízeními přes lokální síť, bez potřeby připojení k internetu, byla vydána ve verzi 1.16, aktuálně 1.16.1. Instalovat lze také z Flathubu a Snapcraftu.
Nejnovější publikace v knižní edici správce české národní domény nese název ESP32 prakticky a jejím autorem je Martin Malý. Kniha je průvodcem ve světě výkonných a velmi bohatě vybavených mikrokontrolérů společnosti Espressif. V knize se naučíte, jak využít tento čip pro různé projekty, od základního nastavení a programování ESP32 v Arduino IDE, přes připojení k Wi-Fi a Bluetooth, až po pokročilé techniky, jako je realtime operační systém FreeRTOS, příjem signálu z družic nebo programování v ESP-IDF.
Byl představen nový oficiální 7palcový Raspberry Pi Touch Display 2. Rozlišení 720 × 1280 pixelů. Cena 60 dolarů.
Na čem aktuálně pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za říjen (YouTube).
Byla vydána verze 0.4.0 v Rustu napsaného frameworku Pingora pro vytváření rychlých, spolehlivých a programovatelných síťových systémů. Z novinek lze vypíchnout počáteční podporu Rustls, tj. implementaci TLS v Rustu. Společnost Cloudflare uvolnila framework Pingora letos v únoru pod licencí Apache 2.0.
Byla vydána první pre-release verze desktopového prostředí Xfce (Wikipedie). Vydání ostré verze je plánováno na 15. prosince. Současně byla vyhlášena soutěž o výchozí wallpaper pro Xfce 4.20. Uzávěrka přihlášek je 15. listopadu.
Přímý přenos z konference OpenAlt 2024, jež probíhá tento víkend v prostorách FIT VUT v Brně. Na programu je spousta zajímavých přednášek. Pokud jste v Brně, stavte se. Vstup zdarma.
V Coloradu unikla hesla k volebním počítačům. Více než 2 měsíce byla tabulka se stovkami hesel do BIOSu volně na webových stránkách. Dle úřadu je potřeba ještě druhé heslo, takže se o žádnou bezprostřední bezpečnostní hrozbu pro volby nejedná [Ars Technica].
Řešení dotazu:
chtěl bych se zeptat, zda je možné v systemd ve Fedoře 17 zařadit SysV init skript jako wants. V principu mi jde o to, že mám vlastní firewallovací init skript a chtěl bych ho zařadit před start služeb.Chybyčka. Ani wants ani requires v systemd neslouží k ovlivnění pořadí startu služeb, ale k vyjádření toho, která služba kterou chce/potřebuje. To, co hledáš je after/before, popřípadě kombinace obojího (tedy určení závislosti i pořadí).
P.S. Dájí se nějak ty [Ok] při startu přehodit doprava, jako to bylo ve F16?Netuším. Mně funguje grafický start, takže tyhle věci vidím jenom když chci a pak zas neřeším estetiku.
P.P.S. Opravdu bych nechtěl (opět) rozpoutat nějaký flamewar, takže poprosím pouze technické odpovědi :)To je zbytečné. Flamewar buď přijde nebo nepřijde, tazatel ho může pouze vyprovokovat, ne mu zabránit :).
Chybyčka. Ani wants ani requires v systemd neslouží k ovlivnění pořadí startu služeb, ale k vyjádření toho, která služba kterou chce/potřebuje. To, co hledáš je after/before, popřípadě kombinace obojího (tedy určení závislosti i pořadí).Tomu rozumím, ale měl jsem pocit, že jsou tam určitá místa, jakýsi checkpointy, kde se počká na všecko, co do té doby mělo být, ale možná se mýlim. Jako aby každá služba nemusela mít jako závislost mount, storage-init, atd...
/etc/systemd/system/mujfw.service
:
[Unit] Description=firewall skript, co se spouští hodně brzo DefaultDependencies=no After=local-fs.target Before=sysinit.target # Conflicts= a Before=shutdown.target u tohoto unitu asi nejsou nutné [Service] Type=oneshot RemainAfterExit=yes ExecStart=/etc/rc.d/init.d/mujfw start ExecStop=/etc/rc.d/init.d/mujfw stop [Install] WantedBy=sysinit.targetPozice těch vypisovaných "[ OK ]" značek je zakódovaná natvrdo. Doleva jsem to přesunul schválně, protože na širokých monitorech už nešlo pouhýma očima poznat, ke kterému řádku která značka patří.
Jinak nevim co myslis rozdilem init scriptu a unit - unit je jen obecny popis pro konfiguraci, ktera muze poustet co chce, treba init script, jako to napsal michich.To vím, ale tady jsem četl, že systemd volá init skripty, pokud nenajde unit file stejného jména. Z toho a z toho, co psal michich, jsem usoudil, že když pro init skript udělám unit file, který se bude stejně jmenovat (a bude volat ten init skript), tak ho de facto vyřadím z "defaultního zpracování všech plebejských init skriptů" a budu si ho moct řídit kompletně pomocí systemd.
DefaultDependencies=no
, se spouštějí až po basic.target. Tady jsou nejdůležitější targety při bootu:
http://0pointer.de/public/systemd-man/bootup.html
Pořadní závislosti unitu si můžeš vypsat systemctl show -p Before -p After foo.service
Přidávat volbu pro pozici výpisu OK se mi moc nechce.
Tak mně napadá, jak je v systemd vyřešeno to, že služba může mít různé závislosti podle toho, jaká je na serveru konfigurace?Jako že by byla různá struktura závislostí pro různé profily? To si nemyslím.
V takovou chvíli je ovšem tedy potřeba, aby NM shodil síť až úplně na konci nebo jí klidně i nechal, to nikoho nezabije.Ukončení NM obecně neshazuje síť. Dřív to tak nebylo, a některé chybi i vlastnosti (kvůli problémům kernelu) shození sítě způsobují. Ale oficiální plán je ten, že ukončení NM nechá síť viset tak jak je pro případ, že se jedná o upgrade a NM se bude zase spouštět a konfiguraci si bude přebírat. Momentálně to funguje jen pro IPv4 a i tam jsem opravoval před 0.9.6 nějakou chybu (kód pro IPv6 jsem odstraňoval úplně, protože nefungoval, jen dělal problémy).
A to, že při shutdown zavolá iscsi stop mezi jedněmi z prvních, je už naprostá katastrofa, protože to je poslední, co udělá, pokud má na iSCSI root...Já bych to asi hlásil do bugzilly. Do redhatí, abych nemusel moc řešit jestli je to problém systemd nebo unity té služby, oni už si to nějak přehodí.
úplně krásně by stačil skriptík, co 3x zavolá ip něco něco...To je kolikrát nejlepší.
protože Fedora pořád nedokáže správně poznat, že síť nemá shazovat...To by mě docela zajímalo, za jakých okolností Fedora shazuje síť bez žádosti uživatele.
Do toho si opravdu nemám chuť pustit poměrně nepredikovatelný NMChápu :).
ani jsem tam nenašel žádný soubor, který by obsahoval "online"
$ find /lib/systemd/ | grep online /lib/systemd/system/NetworkManager-wait-online.service /lib/systemd/system/remote-fs-pre.target.wants/NetworkManager-wait-online.service
Na druhou stranu, pokud to opravdu jen napíše warning, že nm-online pláče po nm, tak se nic neděje...Na ten warning se akorát bude nejspíš čekat půlminutový timeout.
protože Fedora pořád nedokáže správně poznat, že síť nemá shazovat...To by mě docela zajímalo, za jakých okolností Fedora shazuje síť bez žádosti uživatele.
Ono to spolu souvisí. Pokud je root na iSCSI nebo něčem, co potřebuje síť, tak by shození sítě nemělo k tomu potřebné věci shodit. Postupně s tím bojuju už od cca Fedory 8, psal jsem to do bugzily (ikdyž už nemůžu ty bugy najít), ale nějak tak od cca fedory 12-13 s tím nebyl problém. Problém je v tom, že cca ve fedoře 7 mělo mkinitrd sice detekci, zda root nepotřebuje iSCSI, ale nebylo to rekurzivní. Takže pokud boot byl přímo na iSCSI, tak ok, ale pokud byl na raidu, kde bylo iSCSI, tak už ne. Ale to šlo jen dělání ramdisku, takže člověk holt musel po každém upgradu kernelu přegenerovat ramdisk s parametry, aby se zahrnulo iSCSI. Už zhruba někdy od té 7-8 to dělalo to, že ve cvhíli, kdy se rozjelo iscsi, tak to vyplo shození síťovek při network stop. A ta detekce se dala obejít přidáním _netdev nebo _rnetdev do fstabu. Pak přišel dracut, který v tom nadělal vcelku pořádek a pokud se přegeneruje ramdisk, aby měl iSCSI a síť, tak je to všecko otázka parametrů kernelu a pak jen je potřeba, aby tu síť nikdo neshodil. Původní rc sckript netowkr to už měl docela vymakané, ale teď je jak iscsi tak network spouštěnej jen přes "kompatibiltu s InitV", takže se spouští jako poslední, resp. první. Nevím, jestli to hlásit do bugzily, zda je network ještě pořád podporovaný nebo ne, stejně tak nevím, zda pro iscsi neexistuje nějaká novější varianta... To bylo celé, co jsem měl na mysli, tedy to, že fedora neshazuje síť bez přání uživatele, ale při shutdownu to shazuje v jiném pořadí, než jak by bylo podle aktuální konfigurace potřeba.A to, že při shutdown zavolá iscsi stop mezi jedněmi z prvních, je už naprostá katastrofa, protože to je poslední, co udělá, pokud má na iSCSI root...Já bych to asi hlásil do bugzilly. Do redhatí, abych nemusel moc řešit jestli je to problém systemd nebo unity té služby, oni už si to nějak přehodí.
No myslím to tak, že by se struktura závislostí měnila podle nějakých parametrů. Řekněme, že nastavím, aby se server autentizoval proti winbindu, pak je například rozumné (ikdyž ne nutné) mít závislost: sshd potřebuje winbind. Prostě a jednoduše to, že se závislostí mění podle aktuálního nastevení nečeho jiného na serveru. Ten remote root je taky dobrý příklad. Prostě pokud mám root připojený přes síť, tak najednou síť potřebuju shazovat mezi posledními. To že to ve skutečnosti síť neshodí je jen taková obezlička, sice funkční, ale ne moc čistá, třeba řekněme, že budu mít root nejen přes síť, ale přes IPSec. Pak mi nestačí, že síť zustane nahozená, kdyby nezůstal nahozený IKE. Což je další přiklad toho, že se IKE může shazovat jako jeden z prvních nebo naopak skooro až na konci, podle potřeby... Jako admin si to můžu nastavit, ale přijde mi, že to je věc, kterou by se systemd snaží řešit, tak mně zajímá, jak a jestli....Tak mně napadá, jak je v systemd vyřešeno to, že služba může mít různé závislosti podle toho, jaká je na serveru konfigurace?Jako že by byla různá struktura závislostí pro různé profily? To si nemyslím.
$ find /lib/systemd/ | grep onlineProto jsem psal, že jsem to nenašel v /etc/systemd, tedy že to není ani moje lokální unit, ani v nějakém wants nebo jako přímá závislost. Čímž pádem nemám přímočarý prostředek, jak to vypnout... Ale ani to pul minuty netimeoutuje, jen to napíše, dependency failed a jede dál....
Jako admin si to můžu nastavit, ale přijde mi, že to je věc, kterou by se systemd snaží řešit, tak mně zajímá, jak a jestli...
Obávám se, že takové magie nebude žádný init schopný. Když už správce nastaví ipsecovou politiku pro iSCSI, tak náležitě upraví závislosti mezi službami.
V případě systemd lze v /etc/systemd/system vytvořit stejnojmenný jednotkový soubor, do něj napsat direktivu pro vložení obsahu původní jednotky z /usr/lib/systemd/system a přidat specifikaci kýžené závislosti.
To bylo celé, co jsem měl na mysli, tedy to, že fedora neshazuje síť bez přání uživatele, ale při shutdownu to shazuje v jiném pořadí, než jak by bylo podle aktuální konfigurace potřeba.Jo, já to všechno celkem chápu. Jen by mě zajímaly přesné okolnosti které vedou k tomu, že Fedora shodí síť a taky jestli to má nebo nemá souvislost s NetworkManagerem. Mám pocit, že by měl být tenhle problém vcelku jednoduše řešitelný.
Řekněme, že nastavím, aby se server autentizoval proti winbindu, pak je například rozumné (ikdyž ne nutné) mít závislost: sshd potřebuje winbind.Ty závislosti se někdy značně přeceňují.
Prostě pokud mám root připojený přes síť, tak najednou síť potřebuju shazovat mezi posledními.To je takové dost nekonkrétní.
Pak mi nestačí, že síť zustane nahozená, kdyby nezůstal nahozený IKE.Čistě teoreticky může IKE použít stejný trik. Může se shodit aniž by došlo k okamžitému shození IPsec.
ale přijde mi, že to je věc, kterou by se systemd snaží řešit, tak mně zajímá, jak a jestli....Jak jsem psal výše, nemám pocit, že by se snažil toto řešit. Jediné, o co se snaží je se tomu vyhnout a přesunout část zodpovědnosti za závislosti na aplikace.
Čímž pádem nemám přímočarý prostředek, jak to vypnout...Můžeme se přít o tom, jestli je to dobře nebo špatně. Ale je to zdokumentované, alespoň :).
Ale ani to pul minuty netimeoutuje, jen to napíše, dependency failed a jede dál....Tak ono to vlastně bude timeoutovat jen pokud bude NM spuštěný ale nebude se mu dařit získat spojení.
Ty závislosti se někdy značně přeceňují.No jestli to správně chápu, tak je to jediná možnost, jak nastavit, že nějaká unit potřebuju nějakou jinou unit...
Nevím, co je na tom nekonkrétní, ale budž, zkusím trochu vyelaborovat. Ve chvíli, kdy soubory potřebné pro běh systemd a dalších služeb jsou na partition, která je připojená přes NFS, SMB,... nebo na disku, který je připojený přes iSCSI nebo obsahuje (LVM, Device Mapper, mdraid, dmraid) disk, který je připojený přes iSCSI, tak je potřeba neshazovat síťovku, přes kterou se takto komunikuje, dokud nejsou tyto partitions odmountovány. Protože je to poměrně složitý oříšek, tak se používaly zjednodušení typu neshazuje se žádná síť, aby se nemuselo řešit, kterou síťovku můžu a kterou ne, admin do fstabu připíše "hint", že ten filesystém je _netdev nebo _rnetdev...Prostě pokud mám root připojený přes síť, tak najednou síť potřebuju shazovat mezi posledními.To je takové dost nekonkrétní.
Čistě teoreticky může IKE použít stejný trik. Může se shodit aniž by došlo k okamžitému shození IPsec.To jo, ale tenhle přístup je principielně špatný. Pokud byl démon potřeba za provozu, měl by být potřeba celou dobu, co se ta věc používá. Není dobré spoléhat na to, že ten shutdown bude trvat krátce, to vnáši nějaké implicitní omezení, které nemusí být pravda...
Jak jsem psal výše, nemám pocit, že by se snažil toto řešit. Jediné, o co se snaží je se tomu vyhnout a přesunout část zodpovědnosti za závislosti na aplikace.No ale to je docela divné ne? Ta aplikace nemá přece řešit komplexitu těch závislostí, přece nebudeš do NM programovat detekci, zda root potřebuje síť, zda jí potřebuje /usr (tedy detekovat, jestli je nebo není /usr na jiné partition) (to se samozřejmě dá po lenartovsku odbýt, že to je crazy věc)? Když ideální řešení by právě bylo mít na tuto poměrně složitou detekci vlastní unit file, který by sloužil ostantím jako zdroj informace a oni (klidně na úorvni aplikace) by se podle něj zařídili....
Můžeme se přít o tom, jestli je to dobře nebo špatně. Ale je to zdokumentované, alespoň :).Já se (kupodivu) nepřu, v tomhle případě je mi to poměrně šumák, ale zarazilo mně, že se spustí něco, na co nemám v /etc/systemd nějakou jasnou vazbu. Ale asi má systemd nějakou volbu, která vypíše, co všechno se při startu bude volat (jako bylo ls /etc/rc.5....)
No jestli to správně chápu, tak je to jediná možnost, jak nastavit, že nějaká unit potřebuju nějakou jinou unit...Ano. A přesně to je značně přeceňováno, zvláště pokud se jedná o závislosti, které mají vliv na pořadí spouštění. V jazyce systemd tedy before/after.
tak je potřeba neshazovat síťovku, přes kterou se takto komunikujeMně přijde ideální neshazovat síťovku vůbec. A zřejmě je to cesta, kterou se budeme opravdu ubírat. Původně jsem s tím nesouhlasil, ale kluci mě přesvědčili, že to dává smysl. Akorát zatím tento postup aplikujeme myslím pouze na Ethernet.
Není dobré spoléhat na to, že ten shutdown bude trvat krátce, to vnáši nějaké implicitní omezení, které nemusí být pravda...Kdybych cítil naději, že se celá věc vyřeší ideálním způsobem, tak s tebou možná budu souhlasit.
No ale to je docela divné ne?Podle mě není. Aplikace ty závislosti stejně vidí/řeší. Navíc jedině aplikace zná své skutečné závislosti, pokud jsou odvozené od konfigurace.
přece nebudeš do NM programovat detekci, zda root potřebuje síť, zda jí potřebuje /usrTo rozhodně nebudu. Závislosti se vždy řeší na straně, která závisí, ne na straně, na které se závisí. V NetworkManageru máme všechny běhové závislosti řešené opravdu za běhu. Navíc NetworkManager samozřejmě používá /etc, takže pokud by se měl NetworkManager používat k získání kořenového adresáře, tak jsou závislosti mezi ním a kořenem stejné jako závislosti mezi initem a kořenem. Řešit to lze jedině tak, že bude NetworkManager (ořezaný na minimum odstraněním všech nepotřebných modulů) stejně jako init zabalený do initrd. Při ukončení může NetworkManager nechat nakonfigurovanou síť (na Ethernetu to částečně funguje) a po mountování se spustí nový init, který spustí nový NetworkManager, který si síťovou konfiguraci převezme. Samozřejmě z toho vyplyne řada problémů a omezení, ale v tuhle chvíli to nejde rozumně řešit jinak.
Když ideální řešení by právě bylo mít na tuto poměrně složitou detekci vlastní unit file, který by sloužil ostantím jako zdroj informace a oni (klidně na úorvni aplikace) by se podle něj zařídili....Takhle to na Linuxu nefunguje. Alespoň ne v tuto chvíli.
Já se (kupodivu) nepřu, v tomhle případě je mi to poměrně šumák, ale zarazilo mně, že se spustí něco, na co nemám v /etc/systemd nějakou jasnou vazbu.
ale zarazilo mně, že se spustí něco, na co nemám v /etc/systemd nějakou jasnou vazbu.Přitom si stačilo přečíst manuál. Odložení distribučních konfiguráků do /usr/lib umožňuje zcela obejít problém s updatem konfiguračních souborů, kdy není bez zásahu uživatele zcela rozhodnutelné, zda chce uživatel konfigurační soubory přepsat či nikoli. V /etc se pak nacházejí jen uživatelské úpravy. Má to svoje výhody především v případě konfiguračních adresářů, jejichž konfigurace se může často měnit balíčkovacím systémem a konflikty s uživatelskou konfigurací jsou rozlezlé přes hromadu souborů. V případě problémů pak administrátor jenom smaže celý uživatelský override a udělá si případně lokální úpravy znovu.
Ano. A přesně to je značně přeceňováno, zvláště pokud se jedná o závislosti, které mají vliv na pořadí spouštění. V jazyce systemd tedy before/after.Tomu nerozumím, co je značně přeceňováno. To že nějaká služba potřebuje jinou?
No jasně, tak budou muset lidi od iscsid dodělávat do svých věcí toto, kam to vcelku logicky patří. Ale NM jim pak stejně bude muset nabídnout nějakou možnost, jak se nechat řídit tak, aby šlo udělat to, co oni potřebují. A proto mi připadá init proces ideální mezinástroj, který v tom může napomoci...přece nebudeš do NM programovat detekci, zda root potřebuje síť, zda jí potřebuje /usr?To rozhodně nebudu. Závislosti se vždy řeší na straně, která závisí, ne na straně, na které se závisí.
Přitom si stačilo přečíst manuál.Přitom si stačilo přečíst mé příspěvky. Já princip oddělení lokálních a systémových souborů chápu. Ale šlo mi o to, že se míchají věci z /usr s věcmi z /etc takovým způsobem, že není jednoduché zjistit, co všechno se tedy použije... Dokonce jsem si ze začátku myslel, že v /etc budu mít přesně to, co se lokálně má použít a věci z /usr se budou používat jen jako nástroje pro to, ale to jsem brzy zjistil, že to tak není. Každopádně jsem tohle shrnul v příspěvku níže, protože jsem se toho chvíli snažil zbavit.
To je zajímavý přístup, podmiňovat (ne)souhlas s koncepční myšlenkou nějakým subjektivním pocitem z něčeho souvisejícího. Ale proč jsem o tom psal bylo, že například libvirt-guest si v klidu při shutdownu začal ukládat snapshoty běžících strojů. Nic divného a nevidím důvod, proč by to bylo špatně, ale celý shutdown pak trval třeba 10 minut....Není dobré spoléhat na to, že ten shutdown bude trvat krátce, to vnáši nějaké implicitní omezení, které nemusí být pravda...Kdybych cítil naději, že se celá věc vyřeší ideálním způsobem, tak s tebou možná budu souhlasit.
Tomu nerozumím, co je značně přeceňováno. To že nějaká služba potřebuje jinou?Ano. A především to, že je potřeba to pořád nějak komplikovaně řešit.
Ale NM jim pak stejně bude muset nabídnout nějakou možnost, jak se nechat řídit tak, aby šlo udělat to, co oni potřebují.NM jim může maximálně tak nabídnout garanci, že nezasáhne té části konfigurace sítě, kterou používají. A to není až tak složité, pro začátek stačí požadavky popsat v bugzille.
A proto mi připadá init proces ideální mezinástroj, který v tom může napomoci...Nemyslím si, že existuje vůbec nějaký způsob, jak v tomto může init pomoci, tedy pokud init sám nebude síťovým démonem. Není to ani v nejmenším jeho věc.
Ale šlo mi o to, že se míchají věci z /usr s věcmi z /etc takovým způsobem, že není jednoduché zjistit, co všechno se tedy použije...Podle mě je to velice jednoduché. Uživatelské konfigurační soubory (v /etc) mají přednost před stejnojmennými distribučními konfiguračními soubory (v /usr/lib). To je všechno.
To je zajímavý přístup, podmiňovat (ne)souhlas s koncepční myšlenkou nějakým subjektivním pocitem z něčeho souvisejícího.A ještě navíc možná :). Suchá teorie a praxe se prostě občas liší. Ale když nad tím tak přemýšlím, tak v podstatě to, co bys chtěl, už systemd umí. Ty bys totiž chtěl několik grafů závislostí. Vtip je v tom, že se všechny klidně vejdou do jednoho.
Ale proč jsem o tom psal bylo, že například libvirt-guest si v klidu při shutdownu začal ukládat snapshoty běžících strojů.Jo, taky mě nějaké náročnější akce napadly. Takže jsi mě přesvědčil, u těch síťových věcí, které je potřeba udržovat. Takže jo. Bylo by fajn mít vyřešené závislisti mezí sítí a síťovým filesystémem. Takže odpojit síťový root, než se ukončí třeba ten strongswan. To asi nepůjde. Možná je samotný root po síti špatný nápad a měl by být radši v RAM. Takže jediné, co mě napadá, je oddělit klíčové komponenty a aplikace. Tedy odložit ukončení síťových démonů až po ukončení toho virtualizačního software. Ony ty virtuály síť stejně nejspíš potřebují :). A tohle systemd podle mě zvládne.
Jo, taky mě nějaké náročnější akce napadly. Takže jsi mě přesvědčil, u těch síťových věcí, které je potřeba udržovat. Takže jo. Bylo by fajn mít vyřešené závislisti mezí sítí a síťovým filesystémem. Takže odpojit síťový root, než se ukončí třeba ten strongswan. To asi nepůjde. Možná je samotný root po síti špatný nápad a měl by být radši v RAM.Já zase můžu vyjmenovat spoustu důvodů, proč je síťový root dobrý nápad. Dva příklady za všecky. Máme servery, které bootuji z flashky, ze které si stáhnou kernel a initrd, vše ostatní je na iSCSI. Takovou flashku můžu naprosto triviálně vrazit do jiného HW a jedu dál. Ideální právě pro virtuální hostitele. Dřív byl problém s rozdílným HW, ale to velice elegatně vyřešil dracut. Druhým příkladem jsou různé servery, které mají klidně i lokální raid a na iSCSI mají další member. A nějaké drobné nenáročné servery mají třeba jen jeden lokální a jeden síťový. A v nejhorším je možné ten server dočasně (ale rychle) pustit z toho iSCSI, takže třeba pod virtualizací. Tady by se dalo namítnout, že když se odpojí síť, tak to pojede z toho lokálního, ale to se doufám shodneme, že je špatné řešení
Takže jediné, co mě napadá, je oddělit klíčové komponenty a aplikace. Tedy odložit ukončení síťových démonů až po ukončení toho virtualizačního software. Ony ty virtuály síť stejně nejspíš potřebují :).Ty virtuály tu síť už potřebovat nemusí, navíc na ní nemusí být závislé... Přiznám se, že nevím, jestli je ten init skript nejdřív všechny pauznul a pak po jednom snapshotoval, nebo to dělal postupně. Já to tak i tak nepovažuju za moc ideální řešení, takže pokud se vypíná hostitel, vypnu i všechny stroje, stejně se většinou jedná o síťové servery, tam nějaký snapshot nemá moc smysl :)
A tohle systemd podle mě zvládne.Zvládne, ale to co jsem psal bylo, že původní init to zvládal bez nutnosti to explicitně konfigurovat, protože to udělal už tvůrce toho init skriptu. A protože jsem slíbil, že nebudu flamovat, tak se zdržím poznámek o LP a jeho přístupu P.S. Teď mi to vše funguje k plné spokojenosti, ale objektivně to bylo složitější u té Fedory17 než u té Fedory13 - a to i když nepočítám čas a námahu vynaloženou na studium nové věci...
Já zase můžu vyjmenovat spoustu důvodů, proč je síťový root dobrý nápad.Zde nejsme ve sporu.
Ty virtuály tu síť už potřebovat nemusí, navíc na ní nemusí být závislé...V tom rovněž nejsme ve sporu. Pouštět virtuály až po nastavení sítě a ukončovat je ještě předním podle mě ničemu nevadí. A netýká se to jen nastavení sítě, ale celé řady klíčových systémových démonů.
Já to tak i tak nepovažuju za moc ideální řešení, takže pokud se vypíná hostitel, vypnu i všechny stroje, stejně se většinou jedná o síťové servery, tam nějaký snapshot nemá moc smysl :Já jsem to používal, protože to bylo rychlejší.
Zvládne, ale to co jsem psal bylo, že původní init to zvládal bez nutnosti to explicitně konfigurovat, protože to udělal už tvůrce toho init skriptu.Stejně jako to může udělat tvůrce .service souboru.
A protože jsem slíbil, že nebudu flamovat, tak se zdržím poznámek o LP a jeho přístupuAle o tom si klidně zaflejmovat můžeme. V říjnu se s ním nejspíš podruhé potkám osobně :).
P.S. Teď mi to vše funguje k plné spokojenosti, ale objektivně to bylo složitější u té Fedory17 než u té Fedory13 - a to i když nepočítám čas a námahu vynaloženou na studium nové věci...Problém je v tom, že systemd pořádně nikdo neumí. Ani tvůrci software, ani maintaineři balíků. Viz ten problém s automatickým startováním NetworkManageru po
service NetworkManager stop
. Vůbec to nebyla chyba systemd,
ale dokud nám nepomohl michich, tak jsme byli úplně v háji. Pak to podle toho
samozřejmě ve Fedoře vypadá.
Podle mě je správná cesta hlásit bugy na konkrétní projekty a snažit se docílit toho, aby byla funkční konfigurace už v distribuci, jako tomu bylo u sysvinit.
V tom rovněž nejsme ve sporu. Pouštět virtuály až po nastavení sítě a ukončovat je ještě předním podle mě ničemu nevadí. A netýká se to jen nastavení sítě, ale celé řady klíčových systémových démonů.Rejp: Tohle mi připadá trochu v rozpouru s tím, že se ty závislosti přeceňují...
Stejně jako to může udělat tvůrce .service souboru.Jak jsme se shodli výše, pouze za cenu všelijaké černé magie nebo jiných nepěkných hacků.
Ale o tom si klidně zaflejmovat můžeme. V říjnu se s ním nejspíš podruhé potkám osobně :).Já jsem ho osobně viděl na přednášce kdysi na Fosdemu, už jsem tu o tom i někde psal, pročetl jsem hodně článků na jeho blogu a musím říct, že kdybych nebyl nucen, tak si o tak arogatního člověka ani neopřu kolo...
Problém je v tom, že systemd pořádně nikdo neumí.Problém je v tom, že systemd pořádně nikdo neumí, ale přesto už je ve fedoře tři verze jako defaultní init. Druhej problém je, že kdyby to tak nebylo, tak by systemd neměl ani zdaleka tolik nedobrovolných testerů, protože kdyby si lidi mohli svobodně vybrat.... Jestli s ním budeš mluvit, tak se ho zeptej, jak se mu podařilo systemd protlačit do fedory v tom stavu v jakém byl... Můj osobní tip je, že něco věděl na celou Fedora Steering Comittee
Rejp: Tohle mi připadá trochu v rozpouru s tím, že se ty závislosti přeceňují...Rejp: Mně :).
Jak jsme se shodli výše, pouze za cenu všelijaké černé magie nebo jiných nepěkných hacků.Ne. Může to udělat pomocí systému závislostí, který systemd nabízí a pomocí sdružení více služeb pod target.
Já jsem ho osobně viděl na přednášce kdysi na Fosdemu, už jsem tu o tom i někde psal, pročetl jsem hodně článků na jeho blogu a musím říct, že kdybych nebyl nucen, tak si o tak arogatního člověka ani neopřu kolo...Uvidíme, co si na nás vymyslí.
Druhej problém je, že kdyby to tak nebylo, tak by systemd neměl ani zdaleka tolik nedobrovolných testerů, protože kdyby si lidi mohli svobodně vybrat....Oni si lidi můžou svobodně vybrat. Tedy aktivní lidi :). Lze používat distribuci, která vyhovuje a v ní nástroje, které vyhovují.
Jestli s ním budeš mluvit, tak se ho zeptej, jak se mu podařilo systemd protlačit do fedory v tom stavu v jakém byl...Myslím, že budu mít lepší věci na práci.
Můj osobní tip je, že něco věděl na celou Fedora Steering ComitteeJá jsem zase slyšel, že FSC schvalovala prakticky všechno, co jim přišlo na stůl, zvlášť od dlouhodobých aktivních přispěvatelů. Chtěl jsem dodat ještě něco, ale vynechám to z důvodu svého současného zaměstnání.
Rejp: Mně :).Syntaktický detail
Oni si lidi můžou svobodně vybrat. Tedy aktivní lidi :). Lze používat distribuci, která vyhovuje a v ní nástroje, které vyhovují.To je klasický argument, který by byl pravda jen v případě, že by existovaly distribuce, které by pokrývaly všechny možnosti. V praxi je to tak, že se mi většina ostatních věcí na Fedoře líbí, ale kdyby někdo udělal Fedoru se SysV initem, tak bych to zvažoval
Chtěl jsem dodat ještě něco, ale vynechám to z důvodu svého současného zaměstnání.Velice rozumné, viz ten chudák od Asusu v Alze
Syntaktický detailNene, ztratilo se mi tam něco, mělo to být „mně ne“.
To je klasický argument, který by byl pravda jen v případě, že by existovaly distribuce, které by pokrývaly všechny možnosti.Existují distribuce, které dávají uživateli hodně na výběr. Ale každá sranda něco stojí. Nicméně si myslím, že zrovna Fedora má mnohem větší problémy než systemd a to stejné se podle mě týká i dalších distribucí.
kdyby někdo udělal Fedoru se SysV initem, tak bych to zvažovalPackaging guidelines ponechávají možnost zabalit sysvinit skripty do podbalíku se suffixem -sysvinit. Pokud by měl někdo dostatečný zájem, tak by se to teoreticky dalo. Jediný problém vidím v tom, že Fedora je typicky distribuce, která se snaží o relativně jednotný setup, kdy se maintaineři soustředí převážně na funkci toho jednoho setupu. Fedora není Gentoo, které už v handbooku vybízelo vždy k výběru z několika záměnných produktů (například různé crony a syslogy). Gentoo má už hodně let spolehlivý init systém, který je založený na skriptech a přitom má spoustu vlastností, které Fedora získala až se systemd.
Velice rozumné, viz ten chudák od Asusu v AlzeJo to byla hodně velká tragédie. Já jsem ale v trochu jiné pozici, už jen tím, že jsem do té firmy nastoupil, přestože jsem žádnou práci nesháněl. Navíc každou energii, kterou bych vložil nadáváním na kolegy, můžu místo toho vložit do zlepšování některého open source produktu z oblasti sítí. Tím, že finance zdaleka nebyly hlavní motivací, by bylo divné, kdybych teď věnoval víc energie nadávání, než všemu tomu, kvůli čemu jsem do té firmy šel.
Existují distribuce, které dávají uživateli hodně na výběr. Ale každá sranda něco stojí. Nicméně si myslím, že zrovna Fedora má mnohem větší problémy než systemd a to stejné se podle mě týká i dalších distribucí. Packaging guidelines ponechávají možnost zabalit sysvinit skripty do podbalíku se suffixem -sysvinit. Pokud by měl někdo dostatečný zájem, tak by se to teoreticky dalo. Jediný problém vidím v tom, že Fedora je typicky distribuce, která se snaží o relativně jednotný setup, kdy se maintaineři soustředí převážně na funkci toho jednoho setupu. Fedora není Gentoo, které už v handbooku vybízelo vždy k výběru z několika záměnných produktů (například různé crony a syslogy).To, že se Fedora snaží o jednotný setup je právě její největší síla. Věci jsou vyladěný dohromady a fungují. Všechny distribuce jako gentoo, kde si člověk může udělat kombinaci jakou chce, trpí právě tím, že každej pes jiná ves. Nikdo si pro to netroufne něco podporovat a špatně se to spravuje. Už proto je myšlenka dvou initů ve Fedoře nereálná.
Gentoo má už hodně let spolehlivý init systém, který je založený na skriptech a přitom má spoustu vlastností, které Fedora získala až se systemd.Chápu, že pro desktop to může být jiné, ale na serveru mi opravdu vyhovovalo to, jak to dělal SysV se všemi těmi skripty. Služby se ovládaly přímočaře přes service a v "setup" existovalo textové klikáto, co spouštět. Z tohohle hlediska mi systemd přinesl opravdu jen starosti a čekám, kdy poprvé využiju nějakou jeho novou fičuru. Myslim opravdu využiju a ne, že mi server nabootuje o 5 vteřin rychlejc po tom, co to hodinu ladim
Nicméně si myslím, že zrovna Fedora má mnohem větší problémy než systemdUpřímně řečeno, kromě systemd nemám s Fedorou na serveru žádný problém.
Navíc každou energii, kterou bych vložil nadáváním na kolegy, můžu místo toho vložit do zlepšování některého open source produktu z oblasti sítí.Já si myslím, že dokud je to "nadávání" v konstruktivní rovině, tak minimálně přináší jiný pohled na věc. A když je to v rozumné míře, tak to naopak prospívá.
$ find /lib/systemd/ | grep online /lib/systemd/system/NetworkManager-wait-online.service /lib/systemd/system/remote-fs-pre.target.wants/NetworkManager-wait-online.serviceMimochodem, jaký je správný postup, jak se toho zbavit? Já jsem smazal link /lib/systemd/system/remote-fs-pre.target.wants/NetworkManager-wait-online.service a místo něj nalinkoval mojí network tedy /etc/systemd/system/network.service. To sice funguje, ale nevím, jestli to při upgradu nevezme za své... Druhé, co jsem zkusil, je udělat si v /etc/systemd celý ten adresář remote-fs-pre.target.wants a dát do něj tu mojí network.service. Ten systémový se ovšem vezme v potaz, takže se při startu také spustí. Takže jsem si udělal lokální /etc/systemd/system/NetworkManager-wait-online.service , který volá /bin/true a je to... Předpokládám, že jsem přehlédl nějakou jednoduchou alternativu, protože ani jeden tento postup není ideální...
Tiskni Sdílej: