abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
dnes 06:00 | Zajímavý software

OMG! Ubuntu! představuje emulátor terminálu Hyper (GitHub) postavený na webových technologiích (HTML, CSS a JavaScript). V diskusi k článku je zmíněn podobný emulátor terminálu Black Screen. Hyper i Black Screen používají framework Electron, stejně jako editor Atom nebo vývojové prostředí Visual Studio Code.

Ladislav Hagara | Komentářů: 3
dnes 06:00 | Zajímavý článek

I letos vychází řada ajťáckých adventních kalendářů. QEMU Advent Calendar 2016 přináší každý den nový obraz disku pro QEMU. Programátoři se mohou potrápit při řešení úloh z kalendáře Advent of Code 2016. Kalendáře Perl Advent Calendar 2016 a Perl 6 Advent Calendar přinášejí každý den zajímavé informace o programovacím jazyce Perl. Stranou nezůstává ani programovací jazyk Go.

Ladislav Hagara | Komentářů: 4
3.12. 16:24 | Nová verze

Byla vydána Mageia 5.1. Jedná se o první opravné vydání verze 5, jež vyšla v červnu loňského roku (zprávička). Uživatelům verze 5 nepřináší opravné vydání nic nového, samozřejmě pokud pravidelně aktualizují. Vydání obsahuje všechny aktualizace za posledního téměř půldruhého roku. Mageia 5.1 obsahuje LibreOffice 4.4.7, Linux 4.4.32, KDE4 4.14.5 nebo GNOME 3.14.3.

Ladislav Hagara | Komentářů: 9
3.12. 13:42 | Pozvánky

V Praze probíhá konference Internet a Technologie 16.2, volné pokračování jarní konference sdružení CZ.NIC. Konferenci lze sledovat online na YouTube. K dispozici je také archiv předchozích konferencí.

Ladislav Hagara | Komentářů: 0
2.12. 22:44 | Komunita

Joinup informuje, že Mnichov používá open source groupware Kolab. V srpnu byl dokončen dvouletý přechod na toto řešení. V provozu je asi 60 000 poštovních schránek. Nejenom Kolabu se věnoval Georg Greve ve své přednášce Open Source: the future for the European institutions (SlideShare) na konferenci DIGITEC 2016, jež proběhla v úterý 29. listopadu v Bruselu. Videozáznam přednášek z hlavního sálu je ke zhlédnutí na Livestreamu.

Ladislav Hagara | Komentářů: 24
2.12. 15:30 | Zajímavý projekt

Společnost Jolla oznámila v příspěvku Case study: Sailfish Watch na svém blogu, že naportovala Sailfish OS na chytré hodinky. Využila a inspirovala se otevřeným operačním systémem pro chytré hodinky AsteroidOS. Použita je knihovna libhybris. Ukázka ovládání hodinek na YouTube.

Ladislav Hagara | Komentářů: 8
2.12. 14:15 | Nová verze

Byla vydána verze 7.1.0 skriptovacího jazyka PHP používaného zejména k vývoji dynamických webových stránek. Jedná se o první stabilní verzi nejnovější větvě 7.1. Přehled novinek v dokumentaci. Podrobnosti v ChangeLogu. K dispozici je také příručka pro přechod z PHP 7.0.x na PHP 7.1.x.

Ladislav Hagara | Komentářů: 4
2.12. 12:55 | Nová verze

Google Chrome 55 byl prohlášen za stabilní. Nejnovější stabilní verze 55.0.2883.75 tohoto webového prohlížeče přináší řadu oprav a vylepšení (YouTube). Opraveno bylo také 36 bezpečnostních chyb. Mariusz Mlynski si například vydělal 22 500 dolarů za 3 nahlášené chyby (Universal XSS in Blink).

Ladislav Hagara | Komentářů: 4
2.12. 11:55 | Pozvánky

Máte rádi svobodný software a hardware nebo se o nich chcete něco dozvědět? Přijďte na 135. sraz spolku OpenAlt, který se bude konat ve čtvrtek 8. prosince od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Sraz bude tentokrát tématický. Bude retro! K vidění budou přístroje jako Psion 5mx nebo Palm Z22. Ze svobodného hardwaru pak Openmoko nebo čtečka WikiReader. Přijďte se i vy pochlubit svými legendami, nebo alespoň na pivo. Moderní hardware má vstup samozřejmě také povolen.

xkucf03 | Komentářů: 1
2.12. 00:10 | Nová verze

Byla vydána verze 3.2 svobodného systému pro detekci a prevenci průniků a monitorování bezpečnosti počítačových sítí Suricata. Z novinek lze zmínit například podporu protokolů DNP3 a CIP/ENIP, vylepšenou podporu TLS a samozřejmě také aktualizovanou dokumentaci.

Ladislav Hagara | Komentářů: 0
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (7%)
 (5%)
 (3%)
Celkem 771 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

Dotaz: Fedora 17, systemd a SysV init skripty

21.8.2012 02:09 Radek Hladik | skóre: 20
Fedora 17, systemd a SysV init skripty
Přečteno: 643×
Zdravím,

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. Tedy aby patřičný "checkpoint" (nebo jak se to nazývá) počkal, až se spustí. Jako vhodný se mi zdá sysinit.target.wants, ale jestli to správně chápu, tak do toho adresáře v /etc/systemd/... můžu linkovat jen unity. Pokud by to nešlo, tak to se skřípěním zůbů přepíšu na unit file, ale radší se nejdřív zeptám :-)

P.S. Dájí se nějak ty [Ok] při startu přehodit doprava, jako to bylo ve F16?

P.P.S. Opravdu bych nechtěl (opět) rozpoutat nějaký flamewar, takže poprosím pouze technické odpovědi :)

Řešení dotazu:


Odpovědi

pavlix avatar 21.8.2012 07:56 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
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 :).
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
21.8.2012 14:14 Radek Hladik | skóre: 20
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
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...
pavlix avatar 21.8.2012 23:50 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
O checkpointech přesně nevím, to bude vědět michich jestli tam něco takového je. Jen šlo o to, že wants/requires určuje závislosti typu služba X potřebuje službu Y, přičem nedefinuje, zda ji potřebuje před svým startem nebo po něm.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
22.8.2012 01:06 Radek Hladik | skóre: 20
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
Pardon, trochu jsem to popletl. Nejmenuje se to checkpoint, ale je to target, ale takový ten, kterým se projde při bootu, ale není ještě finální - sysinit,sockets,network,atd... Měl jsem v těch pojmech trochu zmatek, myslel jsem, že target je jen ten jeden cílový (třeba multiuser).

Ale každopádně myšlenka je stejná a je to na tom bootu i vidět. Nemá smysl, aby třeba mysql mělo závislost na třeba remount-root-fs, takže se udělá nějaký bod (sysinit, network), který shrne určitou část bootu a mysql se pak už odkazuje na něj. Při bootu je vidět, že se na takovém místě boot zastaví, dodělají se služby, které musí a pak to pokračuje.
pavlix avatar 22.8.2012 10:34 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
Jo, máš pravdu. Akorát je potřeba si pamatovat, že pořadí a závislosti jsou ortogonální a bude to fungovat.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
Řešení 1× (Radek Hladik (tazatel))
michich avatar 21.8.2012 12:02 michich | skóre: 50 | blog: ohrivane_parky
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
Se SysV skriptem se před sysinit.target nedostaneš.

Ten unit file by vypadal nějak takto - /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.target
Pozice 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ří.
21.8.2012 14:26 Radek Hladik | skóre: 20
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
Díky, zkusím.

Jestli tomu dobře rozumím, tak pokud init skript nemá unit file, tak se spouští až někdy ke konci hromadně, zatímco, když má unit file, tak se spustí, kdy chci? Takže to, že používám službu network místo NetworkManageru, znamená, že se mi síť spouští až skoro nakonec (jestli jsem se nepřehlíd, tak unit file nemá)? :-)

A nešla by pozice těch Ok nastavovat v konfiguraci, je to drobnost, ale přeci jen jsem za těch snad už 20 verzí Fedory a Redhatu zvyklý :-)
21.8.2012 15:52 covex
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
Ach ta vecna konfigurovatelnost. Presne z toho duvodu je konfigurace systemd takovy binec. Puvodni myslenka hezka, ale reseni startu chronyd vs. ntp vyzaduje vymyslet dalsi parametr. Me se to vlevo libi vic.:)

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.
21.8.2012 16:27 Radek Hladik | skóre: 20
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
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.
michich avatar 21.8.2012 20:36 michich | skóre: 50 | blog: ohrivane_parky
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
SysV skripty a nativní unity, které se tomu nebrání přes 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.
22.8.2012 00:23 Radek Hladik | skóre: 20
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
Díky, už to pěkně chodí, služby se spouštějí, kdy mají. Teď už jen zjistit, proč si stežuje, že "Dependency failed for Network Manager Wait Online", když má vypnutý NetworkManager. Ale k tomu se asi ještě dočtu :-)

S tím OK to není potřeba nějak hrotit, drze jsem si udělal patch (v příloze), který revertne tvůj patch na přesun doleva :-) (oproti systemd-44-17.fc17.srpm)
pavlix avatar 22.8.2012 10:39 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
To znamená, že to má nějaká služba jako závislost. Čistě mezi náma, nm-online je ošklivý hack, protože správně by měla služba umět reagovat na změny síťové konfigurace (tedy pokud to není primitivní služba na wildcard adrese, což většinou stačí).

Některé služby nejsou schopné se přizpůsobit aktuální situaci ani přes netlink, ani přes NM, takže při startu čekají na nm-online (tedy myslím až 30 sekund timeout, pokud nenajede síť) a ještě do /etc/NetworkManager/dispatcher.d přidávají hook, který je restartuje. Pokud NM vůbec neplánuješ používat, není problém závislost na nm-online úplně odstranit.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
22.8.2012 13:29 Radek Hladik | skóre: 20
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
Je to server, v tomhle případě dokonce "jednoslužbový". Na desktopu s NM problém nemám, ale na serveru preferuju jednoduchost staré dobré network. Navíc síť nahazuje už dracut (dokonce jako bridge), takže tady potřebuju jenom přiházet další adresy a nastavit routy, úplně krásně by stačil skriptík, co 3x zavolá ip něco něco.... Navíc to nesmí tu síť ani na chvíli shodit, dokonce mám hned na začátku stop části v tom network initscriptu exit, protože Fedora pořád nedokáže správně poznat, že síť nemá shazovat... Do toho si opravdu nemám chuť pustit poměrně nepredikovatelný NM :-)

Takže jsem udělal systemctl disable NetworkManager.service a on se opravdu nespustí. Ale je tam nem nm-online, který ovšem nenám nikde v /etc/systemd nalinkovaný a ani jsem tam nenašel žádný soubor, který by obsahoval "online". Na druhou stranu, pokud to opravdu jen napíše warning, že nm-online pláče po nm, tak se nic neděje...
22.8.2012 13:50 Radek Hladik | skóre: 20
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
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? Konkrétně například to, co jsem nastínil výše. Řekněme, že nechám NM jakožto moderní věc, která se mi má starat o síť. Dejme tomu, že boot nějak projde a já chci stroj vypnout. Dejme tomu, že Fedoří skripty správně vyhodnotí _rnetdev u / ve fstab nebo že si všimnou, že root je na md raidu, kde jedinné aktivní membery jsou iSCSI. 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. Samozřejmě můžu závislositi ručně změnit, ale to není moc ideální. Například starý network skript v části stop udělá nějakou detekci a pokud to vyhodnotí, jako že nemá shazovat síť, tak neshazuje (jen v mém případě trochu hapruje ta detekce).

Jestli jsem dobře koukal, tak systemd vůbec iSCSI neřeší, na všecko volá původní init skripty iscsid a iscsi, což je řešení alespoň částečně funkční, ale rozhodně bych si představoval, že takovouto věc bude systemd nějak řešit. Už jen to, že se takovýto iscsi initscipt spustí po většině služeb, není moc ideálni :-) 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... :-)
pavlix avatar 23.8.2012 02:01 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
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í.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
pavlix avatar 23.8.2012 01:55 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
ú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ý NM :-)
Chá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.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
23.8.2012 16:25 Radek Hladik | skóre: 20
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
Odpovědi na obojí do jednoho příspěvku:
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.
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í.
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.
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.
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....
$ find /lib/systemd/ | grep online
Proto 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....
23.8.2012 20:07 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
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.

23.8.2012 21:00 Radek Hladik | skóre: 20
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
Tak určitě záleží na míře. Například klasický init (nebo možná spíš už runinit, upstart nebo co, ale to není podstatné) ve Fedoře okolo verze 11-13 poměrně elegatně výše nastíněný problém s (ne)shazováním sítě a iSCSI zvládal. Nebylo to kdovíjak elegatní, správce od iscsid musel šahat do skriptu od sítě, do mkinitrd a buhví kam všude jinam, ale fungovalo to. Ten IPSec jsem myslel spíš jako extrémní příklad... Ruční úprava mi problém nedělá, ale zajímalo mně, jestli má systemd vůbec nějaký mechanismus, jak může unit file dynamicky řešit svoje závislosti...
23.8.2012 21:21 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
Obávám se, že to je základní vlastnost systemd – jednotkové soubory nejsou skripty.
23.8.2012 21:32 Radek Hladik | skóre: 20
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
To ale ještě neznamená, že nemůžou mít nějakou schopnost komplikovanější parametrizace. A navíc to, že to nejsou skripty je tak trochu marketing, protože pořád ještě hodně věcí dělají přes volání skriptů nebo se tomu vyhýbají. Například to s tím postgresql initdb (jak jsem psal tady). To je typická práce pro nějaký skript...

Stejně jako to, že by unit file mohl zavolat skript nebo třeba nějaký svůj modul, který by zjistil, zda je používané iSCSI, a pak by správce iscsid do unit filu networku přidal něco jako: dependency=(isiscsi.sh)?iscsi:nic...
pavlix avatar 24.8.2012 02:00 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
Já jsem docela rád, že tam takováhle černá magie není.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
24.8.2012 12:18 Radek Hladik | skóre: 20
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
No někdo to považuje za černou magii, někdo za běžnou věc :-). Když si vezmu, že celý systemd se snaží de facto o přechod od imperativniho paradigma k deklarativnímu...
pavlix avatar 25.8.2012 19:59 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
Což o to, pro mě je černá magie běžná věc :). Provozuju ji hlavně na sítích, ale pokud něco vytvářím, snažím se chovat tak, abych k jejímu použití nenutil druhé.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
25.8.2012 20:28 Radek Hladik | skóre: 20
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
Kdo říká nutil, pokud tam ta možnost je, tak je na uživateli (ve smyslu systemd spíš tvůrci unit než koncovém uživateli), zda jí použije. Pokud tam není, tak jí nepoužije a pak to musí řešit různými ošklivými hacky....
pavlix avatar 24.8.2012 01:53 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
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í.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
24.8.2012 12:37 Radek Hladik | skóre: 20
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
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...
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í.
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...
Č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....)
pavlix avatar 25.8.2012 20:40 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
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 komunikuje
Mně 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 /usr
To 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.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
25.8.2012 20:55 Radek Hladik | skóre: 20
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
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?
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í.
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ř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.
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.
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....
pavlix avatar 25.8.2012 22:03 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
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.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
25.8.2012 22:22 Radek Hladik | skóre: 20
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
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...
pavlix avatar 25.8.2012 22:45 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
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řístupu :-)
Ale 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.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
25.8.2012 22:59 Radek Hladik | skóre: 20
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
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 :-)
pavlix avatar 25.8.2012 23:15 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
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 Comittee :-)
Já 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í.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
25.8.2012 23:40 Radek Hladik | skóre: 20
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
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 :-)
pavlix avatar 26.8.2012 02:11 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
Syntaktický detail :-)
Nene, 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žoval :-)
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).

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 Alze :-)
Jo 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.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
26.8.2012 02:52 Radek Hladik | skóre: 20
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
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ž systemd
Upří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á.
25.8.2012 14:16 Radek Hladik | skóre: 20
Rozbalit Rozbalit vše Re: Fedora 17, systemd a SysV init skripty
$ find /lib/systemd/ | grep online /lib/systemd/system/NetworkManager-wait-online.service /lib/systemd/system/remote-fs-pre.target.wants/NetworkManager-wait-online.service
Mimochodem, 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í...

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.