Re: Migracja serwisów SysV - systemd
On Sun, Feb 05, 2012 at 00:39:19 +0100, Paweł Gołaszewski wrote:
Dla przykładu - dowolne wywołanie rpm wygląda tak:
# rpm -e bluez-systemd-4.98-2.i686
^Cbłąd: stat /proc/sys/fs/binfmt_misc nie powiodło się: Przerwane wywołanie
systemowe
#
Ja nawet nie mam tego w /proc.
Gorzej, że nie działa systemctl - wywala się po timeout jak poniżej:
[...]
stat64(/proc/1/root, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64(/, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
writev(2, [{Failed to get D-Bus connection: ..., 63}, {\n, 1}], 2Failed
to get D-Bus connection: Failed to authenticate in time.) = 64
exit_group(1) = ?
[...]
Demon chodzi:
122 4415 1 0 00:21 ?00:00:00 /usr/bin/dbus-daemon --system
--address=systemd: --nofork --systemd-activation
A ja nawet jak ubiję specjalnie, to:
[root@fs ~]# pgrep -l dbus
[root@fs ~]# systemctl | wc -l
162
ale używam 37-0.4 jeszcze.
Startowanie w obecności systemd, ale zwykłego init-a zawisa na startowaniu
acpid. Wisi po prostu.
No a sprawdziłeś, czy jest to acpid-specific i po jego pominięciu reszta
działa, czy w ogóle coś w tym momencie klęka?
--
Tomasz Pala go...@pld-linux.org
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Sun, 5 Feb 2012, Tomasz Pala wrote:
Dla przykładu - dowolne wywołanie rpm wygląda tak:
# rpm -e bluez-systemd-4.98-2.i686
^Cbłąd: stat /proc/sys/fs/binfmt_misc nie powiodło się: Przerwane wywołanie
systemowe
#
Ja nawet nie mam tego w /proc.
To akurat dziwne - findmnt powinien ci pokazać, że masz coś takiego,
szczególnie, że:
# ls /lib/systemd/system/proc-sys-fs-binfmt_misc.*
/lib/systemd/system/proc-sys-fs-binfmt_misc.automount
/lib/systemd/system/proc-sys-fs-binfmt_misc.mount
Gorzej, że nie działa systemctl - wywala się po timeout jak poniżej:
[...]
stat64(/proc/1/root, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64(/, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
writev(2, [{Failed to get D-Bus connection: ..., 63}, {\n, 1}], 2Failed
to get D-Bus connection: Failed to authenticate in time.) = 64
exit_group(1) = ?
[...]
Demon chodzi:
122 4415 1 0 00:21 ?00:00:00 /usr/bin/dbus-daemon
--system --address=systemd: --nofork --systemd-activation
A ja nawet jak ubiję specjalnie, to:
[root@fs ~]# pgrep -l dbus
[root@fs ~]# systemctl | wc -l
162
ale używam 37-0.4 jeszcze.
AFAIK to bez dbus systemd wogóle może nie działać...
Startowanie w obecności systemd, ale zwykłego init-a zawisa na
startowaniu acpid. Wisi po prostu.
No a sprawdziłeś, czy jest to acpid-specific i po jego pominięciu reszta
działa, czy w ogóle coś w tym momencie klęka?
Nie, za późno było.
--
pozdr. Paweł Gołaszewski jid:bluesatjabberdotgdadotpl
--
If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby
Pro-Logic Surround Sound with Bass Boost and all the music is free.___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Sun, Feb 05, 2012 at 12:09:47 +0100, Paweł Gołaszewski wrote: Dla przykładu - dowolne wywołanie rpm wygląda tak: # rpm -e bluez-systemd-4.98-2.i686 ^Cbłąd: stat /proc/sys/fs/binfmt_misc nie powiodło się: Przerwane wywołanie systemowe # Ja nawet nie mam tego w /proc. To akurat dziwne - findmnt powinien ci pokazać, że masz coś takiego, Ale ja to w kernelu mam wyłączone, systemd nie wymaga tego. [root@fs ~]# systemctl | wc -l 162 ale używam 37-0.4 jeszcze. AFAIK to bez dbus systemd wogóle może nie działać... Działa działa. A systemctl musi. Tutaj masz jakiś problem z tym, że widzi włączonego, ale nie może się zgadać. Więc jeszcze w ramach testów możesz spróbować wywalić dbusa (chmod -x) i zobaczyć, co się stanie. -- Tomasz Pala go...@pld-linux.org ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Friday 20 of January 2012, Tomasz Pala wrote: On Fri, Jan 20, 2012 at 13:24:07 +0100, Bartlomiej Zimon wrote: No dobra ale jest jeszcze jeden temat - dodalem kdm.service (paczka kde4-kdm-systemd) ale aktualizacja powoduje restart kdm a tego nie chcemy jak ten temat rozwiazac? nowe/uaktualnione makro w macros.build? Hmm? Co tam kdm, sprawdzał ktoś jak się zachowa ssh? kdm zachowuje się źle w przypadku upgrade z paczki nie-systemd do paczki obsługującej systemd. Jeśli mam kdma odpalonego, upgraduje do paczki obsługującej systemd to bodaj init.d/ stary stopuje kdma. W każdym razie kończy się z zastopowanym kdmem. -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Sun, 5 Feb 2012, Tomasz Pala wrote: Dla przykładu - dowolne wywołanie rpm wygląda tak: # rpm -e bluez-systemd-4.98-2.i686 ^Cbłąd: stat /proc/sys/fs/binfmt_misc nie powiodło się: Przerwane wywołanie systemowe # Ja nawet nie mam tego w /proc. Coś tutaj namierzyłem - miałem zainstalowany binfmt-detector, który tu bruździł. Na razie powinno być raczej conflicts na tą paczkę, szczególnie, że to jest załatwiane w systemd. Startowanie w obecności systemd, ale zwykłego init-a zawisa na startowaniu acpid. Wisi po prostu. No a sprawdziłeś, czy jest to acpid-specific i po jego pominięciu reszta działa, czy w ogóle coś w tym momencie klęka? Sprawdziłem - acpid jest tutaj winny, bo po jego pominięciu zaczyna działać. P.S.: cronie w test ma błąd w triggerze - jest no-realod, zamiast no-reload. W macrach rpm-a jest poprawione już, ale chyba wartoby przebudować. -- pozdr. Paweł Gołaszewski jid:bluesatjabberdotgdadotpl -- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free.___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Sun, 5 Feb 2012, Arkadiusz Miśkiewicz wrote: No dobra ale jest jeszcze jeden temat - dodalem kdm.service (paczka kde4-kdm-systemd) ale aktualizacja powoduje restart kdm a tego nie chcemy jak ten temat rozwiazac? nowe/uaktualnione makro w macros.build? Hmm? Co tam kdm, sprawdzał ktoś jak się zachowa ssh? kdm zachowuje się źle w przypadku upgrade z paczki nie-systemd do paczki obsługującej systemd. Jeśli mam kdma odpalonego, upgraduje do paczki obsługującej systemd to bodaj init.d/ stary stopuje kdma. W każdym razie kończy się z zastopowanym kdmem. Natomiast gdm nie jest w stanie wystartować jeżeli jest zainstalowany systemd, ale jest uruchomiony ze zwykłym init-em. Magiczne rozwiązanie: rpm -e systemd -- pozdr. Paweł Gołaszewski jid:bluesatjabberdotgdadotpl -- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free.___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Sun, Feb 05, 2012 at 22:40:24 +0100, Paweł Gołaszewski wrote: Natomiast gdm nie jest w stanie wystartować jeżeli jest zainstalowany systemd, ale jest uruchomiony ze zwykłym init-em. Magiczne rozwiązanie: rpm -e systemd SOA#1 Strzelam, że wystarczy rm /var/lock/subsys/gdm. -- Tomasz Pala go...@pld-linux.org ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Thu, Jan 26, 2012 at 19:35:53 +0100, Pawel Golaszewski wrote: No niestety, ale nie widzę nadal - system będzie działał dokładnie tak samo. Miałeś może na myśli, że będzie się w innej kolejności coś uruchamiało? Nie. Będzie albo nie będzie się uruchamiało zależnie od tego w jakiej kolejności zainstalujesz (przed lub po systemd). Paweł, jeszcze raz przeczytaj jak działa systemd - jeśli nie zrobisz systemctl enable, to usługa _uruchomi_ się tak jak dotychczas - skryptem SysV. Żeby go zablokować trzeba ALBO włączyć natywny unit, ALBO zamaskować skrypt SysV ręcznie. Ostateczny wynik będzie taki sam - usługa działa, uruchomi się tylko w inny (nierównoległy) sposób, starym (przetestowanym!) skryptem. systemd uruchamia DOMYŚLNIE wszystkie usługi SysV z runleveli 2-4(5), o ile nie są wprost wyłączone. W momencie tego podziału reszta pakietu zastępowała całego inita. Później dopiero wydzieliłem 'compat' (tj. /bin/init oraz towarzyszące symlinki) i teraz jedyne uzasadnienie units to właśnie R/S w demonach. Nie lepiej teraz wrzucić wszystkie unity do samego systemd? A tą paczkę przemianować na utils (albo jakieś commons) i wrzucać tam wszystko co jest potrzebne innym aplikacjom, czyli na przykład właśnie ten ctl. To byłoby najprostsze rozwiązanie... ctl oraz unity muszą być razem - ich rozdział nie ma najmniejszego sensu. Sam sobie zaprzeczasz. Powyżej twierdziłeś coś innego. Przecież ctl _JEST_ w units. Odnoszę wrażenie, że rozmawiasz o systemd, a nawet nie próbowałeś tego zainstalować, sprawdzić jak działa czy chociażby zajrzeć do speca... Nie wiem z czym teraz mylisz, co niby twierdziłem - 'compat' to jest podpakiet init, zastępujący faktycznie inita legacy. A units zawiera ctl oraz unity. A główny zawiera samego demona, jego binarki i inny core systemd. To jest zdecydowanie niedopuszczalne! Nie wyobrażam sobie sytuacji, w której system uruchamia mi usługę, która może być nieskonfigurowana i wystawiać maszynę na ataki ze świata. To jest zdecydowanie niedopuszczalne! Nie wyobrażam sobie sytuacji, w której system nie uruchamia mi usługi, którą zainstalowałem w podstawowej konfiguracji. Co ty na to? man systemd Po prostu musisz skupić się na faktach, jak ten init działa, a nie swoich, błędnych niestety, domysłach. Najlepiej jest to robić instalując go i sprawdzając warianty, bo bez tego to tracimy kupę maili na ustalanie, czego nie wiesz o systemd... -- Tomasz Pala go...@pld-linux.org ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Thu, Jan 26, 2012 at 19:38:22 +0100, Pawel Golaszewski wrote: No to już pisałem - AUTOMIGRATE2SYSTEMD załatwia wszystkie moje obawy. Ja sobie przestawię na 'no' i będę ręcznie włączał, wy z defaulta będziecie mieli domyślnie włączone. Ale ja nie mówię o żadnym dziwnym migrate, ale ogólnej funkcji, która będzie blokowała automatyczne aktywowanie usługi if [ $AUTO_ACTIVATE_SERVICE != no ]; then to co jest teraz robione w kwestii aktywowania serwisu fi Do makra i wszyscy będą szczęśliwi. No to już przed momentem ustaliliśmy, że nie o to chodzi - nikt (jak dotąd) nie podważał sensu automatycznej aktywacji serwisu w czasie instalacji, a JEDYNIE jego migrację na systemd, bo dużo rzeczy może mieć administrator zmienionych lokalnie, a nasza logika migracji powinna zamknąć się w góra paru linijkach (sprawdzenie chkconfig). -- Tomasz Pala go...@pld-linux.org ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Fri, 27 Jan 2012, Tomasz Pala wrote: On Thu, Jan 26, 2012 at 19:35:53 +0100, Pawel Golaszewski wrote: No niestety, ale nie widzę nadal - system będzie działał dokładnie tak samo. Miałeś może na myśli, że będzie się w innej kolejności coś uruchamiało? Nie. Będzie albo nie będzie się uruchamiało zależnie od tego w jakiej kolejności zainstalujesz (przed lub po systemd). Paweł, jeszcze raz przeczytaj jak działa systemd - jeśli nie zrobisz systemctl enable, to usługa _uruchomi_ się tak jak dotychczas - skryptem SysV. Żeby go zablokować trzeba ALBO włączyć natywny unit, ALBO zamaskować skrypt SysV ręcznie. Ostateczny wynik będzie taki sam - usługa działa, uruchomi się tylko w inny (nierównoległy) sposób, starym (przetestowanym!) skryptem. systemd uruchamia DOMYŚLNIE wszystkie usługi SysV z runleveli 2-4(5), o ile nie są wprost wyłączone. Oj, żebyś się srodze nie zdziwił, jak Ci systemd odpali serwisy SysV starym przetestowanym skryptem. Np. niby skąd ma wiedzieć, że sshd potrzebuje sieci? Bijesz pianę próbując osiągnąć niemożliwe, funkcjonalność pozwalająca mu uruchamiać serwisy SysV to tylko prosta kompatybilność dla usług third-party i jakiegoś komercyjnego oprogramowania które się zmienia w tempie przyrostu lodowca. Nie służy do tego żeby sobie selektywnie przełączać usługi. Albo masz SysV albo systemd, po prostu. -- Jan Rękorajski| ALL SUSPECTS ARE GUILTY. PERIOD! bagginsatmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Fri, Jan 27, 2012 at 11:58:19 +0100, Jan Rękorajski wrote: Oj, żebyś się srodze nie zdziwił, jak Ci systemd odpali serwisy SysV starym przetestowanym skryptem. Np. niby skąd ma wiedzieć, że sshd potrzebuje sieci? SysV uruchamiane są na samym końcu, wtedy sieć już masz uruchomioną. A to jest nasz JEDYNY warunek zapisany w SysV. Uruchamiane są także w oryginalnej kolejności. Bijesz pianę próbując osiągnąć niemożliwe, funkcjonalność pozwalająca mu uruchamiać serwisy SysV to tylko prosta kompatybilność dla usług third-party i jakiegoś komercyjnego oprogramowania które się zmienia w tempie przyrostu lodowca. Wręcz przeciwnie - PEŁNE wsparcie dla SysV jest zapisane jako jedno z założeń systemd, bo takie właśnie wymagania stawiane są w komercyjnych dystrybucjach. Bez obsługi _standardu_ LSB to właśnie systemd byłby na etapie lodowca (patrz upstart). Zresztą, no offence, ale zwyczajnie pieprzysz bzdury - jaka 'prosta' kompatybilność? Zajrzałeś chociaż w ten kod? Tam jest pełne PARSOWANIE NAGŁÓWKÓW skryptów SysV _oraz_ interpretacja LSB. W porównaniu do tego, to nasz rc.sysinit implementuje _prostą_ kompatybilność SysV! Zatem zaryzykuję tutaj kolejne stwierdzenie, że jeśli jakikolwiek SysV nie ruszy pod systemd, to winny będzie ...właśnie nasz skrypt SysV, łamiący standard (choć nie podejrzewam, bo systemd wygląda na robust). Nie służy do tego żeby sobie selektywnie przełączać usługi. Albo masz SysV albo systemd, po prostu. Autor twierdzi inaczej, z nim podyskutuj. Najlepiej przedstawiając konkretnie - co nie działa, zakwestionuj że jest to drop-in replacement. -- Tomasz Pala go...@pld-linux.org ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Wed, 25 Jan 2012, Tomasz Pala wrote: 0. olewamy sprawę, jak ktoś zmieni inita, to ten mu uruchomi usługi SysV; będzie musiał sobie ręcznie włączyć co chce mieć pod systemd. No nie - to nie jest fajne, system staje się niedeterministyczny, zależny MOCNO od kolejności instalacji. A czym się różni uruchomienie przez SysV od uruchomienia przez unit? Niczym istotnym - funkcjonalność pozostaje. Przeczytaj jeszcze raz: w zależności od kolejności instalowania dostaniesz zupełnie inaczej działający system. W jaki niby sposób? Konkretnie - bo nie widzę takiej możliwości. no jak nie widzisz? W zależności czy zainstalujesz usługę przed systemd czy po systemd dostaniesz inaczej działający system. To niedeterministyczne - nieakceptowalne. Nie dam sobie teraz nic uciąć, ale enable/disable z tego co pamiętam (bo CHYBA kiedyś sprawdzałem) nie wymaga dbusa ani nic - przecież ta funkcja powinna działać nawet z poziomu emergency.target. Jaki sens ma wogóle wydzielenie units do osobnego pakietu? W momencie tego podziału reszta pakietu zastępowała całego inita. Później dopiero wydzieliłem 'compat' (tj. /bin/init oraz towarzyszące symlinki) i teraz jedyne uzasadnienie units to właśnie R/S w demonach. Nie lepiej teraz wrzucić wszystkie unity do samego systemd? A tą paczkę przemianować na utils (albo jakieś commons) i wrzucać tam wszystko co jest potrzebne innym aplikacjom, czyli na przykład właśnie ten ctl. To byłoby najprostsze rozwiązanie... 2. Magia przy instalacji systemd-units, która włączy wcześniej zainstalowane paczki. 3. Odłożenie komend z makr do wykonania później. Jak już wspomniałem - oba te warianty są wadliwe, gdyż mogą aktywować usługi wyłączone chkconfigiem. Jeżeli nie masz jakiejś procedury przejścia konfiguracji chkconfiga to ten temat nie istnieje (proszę, nie mów o ręcznym grzebaniu, to można zrobić na 1-2 maszynach). No właśnie - wariant 2 i 3 możemy sobie od razu odpuścić, bo zawiodą i tak. Robota głupiego - szczególnie zważywszy na charakter PLD. Nie o tym mówiłem. Nie mówimy o działaniu instalacji paczek, ale o przeniesieniu _istniejącej_ konfiguracji _różniącej_ się od standardowych ustawień z paczki. Bo nigdy nie będzie. 100% automatyczne przejście nie jest chyba możliwe, fedory i inne też chyba tego nie obsługują... Oni mają prościej - od powiedzmy FC15 jest systemd (jest punkt migracji), no i oni nie są tak elastyczni dla indywidualnych konfiguracji, jak stara się być PLD. no właśnie. -- pozdr. Paweł Gołaszewski jid:bluesatjabberdotgdadotpl -- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free.___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Wed, 25 Jan 2012, Jan Rękorajski wrote: Czyli zostały dwie opcje: W zasadzie trzy: 0. olewamy sprawę, jak ktoś zmieni inita, to ten mu uruchomi usługi SysV; będzie musiał sobie ręcznie włączyć co chce mieć pod systemd. Mi się to rozwiązanie podoba najbardziej. Świadoma migracja przez administratora i świadome aktywowanie usług pod systemd. To jest bardzo kiepski pomysł. Bo jak kiedyś SysVinit wyleci to dostaniesz system w którym nic się nie uruchamia, albo będziesz musiał poprawiać milion pakietów, żeby włączały usługi systemd. Najlepszym rozwiązaniem jest R:systemd-units i (warunkowe) włączanie usług systemd w post, Najprostszym - na pewno. Prościej jest wyłączyć pojedyncze, niechciane usługi niż włączać wszystko. Amen. -- pozdr. Paweł Gołaszewski jid:bluesatjabberdotgdadotpl -- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free.___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Wed, 25 Jan 2012, Tomasz Pala wrote: Prościej jest wyłączyć pojedyncze, niechciane usługi niż włączać wszystko. Nie - ponieważ włączenie systemd robi się JEDEN raz, a wyłączać będę musiał przy KAŻDEJ aktualizacji. Zmierzasz do tego, żeby usługa była wyłączona przy instalacji domyślnie? Wystarczy do tego dorobić switch w makrach, a ustawienie w /etc/sysconfig/rpm -- pozdr. Paweł Gołaszewski jid:bluesatjabberdotgdadotpl -- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free.___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Thu, Jan 26, 2012 at 11:46:55AM +0100, Pawel Golaszewski wrote: Nie lepiej teraz wrzucić wszystkie unity do samego systemd? A tą paczkę przemianować na utils (albo jakieś commons) i wrzucać tam wszystko co jest potrzebne innym aplikacjom, czyli na przykład właśnie ten ctl. To byłoby najprostsze rozwiązanie... Tyle, że te „unity” to też AFAIK katalogi do których systemctl robi te symlinki. Nie mówimy o działaniu instalacji paczek, ale o przeniesieniu _istniejącej_ konfiguracji _różniącej_ się od standardowych ustawień z paczki. systemd to nie SysVinit. IMHO jak się zmienia aplikację, na zupełnie inną, to się ją od nowa konfiguruje. Kiedyś w PLD ktoś sobie wymyślił, że wszystko ma się przenosić (stąd rc-inetd, /etc/mail dla zupełnie różnych serwerów itp. potworki), ale to nie ma sensu. Gdy zamieniam Apache na lighttpd, to piszę konfigi od nowa. Tak samo z initem/skryptami startowymi. W większości przypadków jednak używa się w tym miejscu konfiguracji standardowej lub lokalne zmiany są minimalne (włączenie, czy wyłączenie pojedynczych usług). Każdy admin może sobie to sam załatwić. I będzie to rozwiązanie na pewno pewniejsze niż jakikolwiek automat. Zresztą, przy takiej zmianie inita dużo gorsze rzeczy mogą pójść nie tak, niż to że któraś usługa się odpaliła albo nie. Pozdrowienia, Jacek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: network scripts (Bylo Re: Migracja serwisów SysV - systemd)
On Wed, Jan 25, 2012 at 13:40:43 +0100, Bartlomiej Zimon wrote: dobrze rozumiem ?: network-post.service - /etc/init.d/network start_postinit - static rarp,arp Tak to planowałem. Przy okazji - jako że są to relatywnie rzadko używane funkcje, każdy może to sobie lokalnie wyłączyć. -- Tomasz Pala go...@pld-linux.org ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Thu, Jan 26, 2012 at 11:46:55 +0100, Pawel Golaszewski wrote: W jaki niby sposób? Konkretnie - bo nie widzę takiej możliwości. no jak nie widzisz? W zależności czy zainstalujesz usługę przed systemd czy po systemd dostaniesz inaczej działający system. No niestety, ale nie widzę nadal - system będzie działał dokładnie tak samo. Miałeś może na myśli, że będzie się w innej kolejności coś uruchamiało? To nie jest ŻADEN problem - naczelną zasadą równoległego uruchamiania jest to, że kolejność ostateczna jest niedeterministyczna (np. jakieś oczekiwanie na jedną usługę spowolni inne, zależne od niej, nie spowalniając niezależnych). Bardzo dobrze to zresztą widać przy uruchamianiu systemd z confirm_spawn=1: nie dość, że wynik jest zupełnie inny niż normalne uruchamianie (i fakt, czasem ciężko się debuguje), to jeszcze uruchamiane usługi 'w tle' zaśmiecają konsolę. Biegną także timeouty usług (30 sekund), więc trzeba się streszczać, inaczej część w ogóle nie wstanie. To niedeterministyczne - nieakceptowalne. To w takim razie musisz pozostać przy liniowym SysV (albo nawet napisać sobie BSD!) :) Bo sam fakt, JAK będzie uruchamiana usługa, jest jak najbardziej deterministyczny - wszystko doinstalowane PO systemd-units będzie uruchamiane przez systemd. W momencie tego podziału reszta pakietu zastępowała całego inita. Później dopiero wydzieliłem 'compat' (tj. /bin/init oraz towarzyszące symlinki) i teraz jedyne uzasadnienie units to właśnie R/S w demonach. Nie lepiej teraz wrzucić wszystkie unity do samego systemd? A tą paczkę przemianować na utils (albo jakieś commons) i wrzucać tam wszystko co jest potrzebne innym aplikacjom, czyli na przykład właśnie ten ctl. To byłoby najprostsze rozwiązanie... ctl oraz unity muszą być razem - ich rozdział nie ma najmniejszego sensu. No właśnie - wariant 2 i 3 możemy sobie od razu odpuścić, bo zawiodą i tak. Robota głupiego - szczególnie zważywszy na charakter PLD. Nie o tym mówiłem. Nie mówimy o działaniu instalacji paczek, ale o przeniesieniu _istniejącej_ konfiguracji _różniącej_ się od standardowych ustawień z paczki. To jest zdecydowanie niedopuszczalne! Nie wyobrażam sobie sytuacji, w której system uruchamia mi usługę, która może być nieskonfigurowana i wystawiać maszynę na ataki ze świata. -- Tomasz Pala go...@pld-linux.org ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Thu, Jan 26, 2012 at 13:58:02 +0100, Jacek Konieczny wrote: Nie lepiej teraz wrzucić wszystkie unity do samego systemd? A tą paczkę przemianować na utils (albo jakieś commons) i wrzucać tam wszystko co jest potrzebne innym aplikacjom, czyli na przykład właśnie ten ctl. To byłoby najprostsze rozwiązanie... Tyle, że te ???unity??? to też AFAIK katalogi do których systemctl robi te symlinki. systemctl nie zmienia nic w /lib (to jest tylko i wyłącznie dla oryginalnych plików, administrator też nie powinien tam grzebać, choć w pewnych przypadkach jest to jedyna możliwość) - wszystkie symlinki lecą do /etc na podstawie danych przeczytanych z /lib. systemd to nie SysVinit. IMHO jak się zmienia aplikację, na zupełnie inną, to się ją od nowa konfiguruje. Kiedyś w PLD ktoś sobie wymyślił, że wszystko ma się przenosić (stąd rc-inetd, /etc/mail dla zupełnie różnych serwerów itp. potworki), ale to nie ma sensu. Gdy zamieniam Apache na lighttpd, to piszę konfigi od nowa. Tak samo z initem/skryptami startowymi. Dokładnie. Te /etc/httpd czy mail to PITA, szczególnie jak się robi coś także na inne dystrybucje. Pożytku nie ma żadnego. Zresztą, przy takiej zmianie inita dużo gorsze rzeczy mogą pójść nie tak, niż to że któraś usługa się odpaliła albo nie. No nie wiem - jakby mi się nagle bgpd z quaggi uruchomiło zamiast birda, to miałbym poważniejszy problem, niż watchdog restartujący maszynę. -- Tomasz Pala go...@pld-linux.org ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Thu, Jan 26, 2012 at 11:51:10 +0100, Pawel Golaszewski wrote: Prościej jest wyłączyć pojedyncze, niechciane usługi niż włączać wszystko. Nie - ponieważ włączenie systemd robi się JEDEN raz, a wyłączać będę musiał przy KAŻDEJ aktualizacji. Zmierzasz do tego, żeby usługa była wyłączona przy instalacji domyślnie? Wystarczy do tego dorobić switch w makrach, a ustawienie w /etc/sysconfig/rpm No to już pisałem - AUTOMIGRATE2SYSTEMD załatwia wszystkie moje obawy. Ja sobie przestawię na 'no' i będę ręcznie włączał, wy z defaulta będziecie mieli domyślnie włączone. -- Tomasz Pala go...@pld-linux.org ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Thu, 26 Jan 2012, Tomasz Pala wrote: Prościej jest wyłączyć pojedyncze, niechciane usługi niż włączać wszystko. Nie - ponieważ włączenie systemd robi się JEDEN raz, a wyłączać będę musiał przy KAŻDEJ aktualizacji. Zmierzasz do tego, żeby usługa była wyłączona przy instalacji domyślnie? Wystarczy do tego dorobić switch w makrach, a ustawienie w /etc/sysconfig/rpm No to już pisałem - AUTOMIGRATE2SYSTEMD załatwia wszystkie moje obawy. Ja sobie przestawię na 'no' i będę ręcznie włączał, wy z defaulta będziecie mieli domyślnie włączone. Ale ja nie mówię o żadnym dziwnym migrate, ale ogólnej funkcji, która będzie blokowała automatyczne aktywowanie usługi if [ $AUTO_ACTIVATE_SERVICE != no ]; then to co jest teraz robione w kwestii aktywowania serwisu fi Do makra i wszyscy będą szczęśliwi. -- pozdr. Paweł Gołaszewski jid:bluesatjabberdotgdadotpl -- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free.___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Thu, 26 Jan 2012, Bartosz Świątek wrote: W dniu 26 stycznia 2012 19:38 użytkownik Pawel Golaszewski bl...@pld-linux.org napisał: On Thu, 26 Jan 2012, Tomasz Pala wrote: Prościej jest wyłączyć pojedyncze, niechciane usługi niż włączać wszystko. Nie - ponieważ włączenie systemd robi się JEDEN raz, a wyłączać będę musiał przy KAŻDEJ aktualizacji. Zmierzasz do tego, żeby usługa była wyłączona przy instalacji domyślnie? Wystarczy do tego dorobić switch w makrach, a ustawienie w /etc/sysconfig/rpm No to już pisałem - AUTOMIGRATE2SYSTEMD załatwia wszystkie moje obawy. Ja sobie przestawię na 'no' i będę ręcznie włączał, wy z defaulta będziecie mieli domyślnie włączone. Ale ja nie mówię o żadnym dziwnym migrate, ale ogólnej funkcji, która będzie blokowała automatyczne aktywowanie usługi if [ $AUTO_ACTIVATE_SERVICE != no ]; then to co jest teraz robione w kwestii aktywowania serwisu fi Do makra i wszyscy będą szczęśliwi. Problematyka godna PLD. Ciekawe czy w innych, dużo większych i bardziej popularnych dystrybucjach, które używają systemd, też takie wyszukiwanie problemów było. Pewnie nie, ale jeszcze nie słyszałem o takim któremu udało się zrobić upgrade fedory, tak żeby system działał tak samo po jak przed ;) -- Jan Rękorajski| ALL SUSPECTS ARE GUILTY. PERIOD! bagginsatmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
W dniu 26 stycznia 2012 20:28 użytkownik Jan Rękorajski bagg...@pld-linux.org napisał: On Thu, 26 Jan 2012, Bartosz Świątek wrote: W dniu 26 stycznia 2012 19:38 użytkownik Pawel Golaszewski bl...@pld-linux.org napisał: On Thu, 26 Jan 2012, Tomasz Pala wrote: Prościej jest wyłączyć pojedyncze, niechciane usługi niż włączać wszystko. Nie - ponieważ włączenie systemd robi się JEDEN raz, a wyłączać będę musiał przy KAŻDEJ aktualizacji. Zmierzasz do tego, żeby usługa była wyłączona przy instalacji domyślnie? Wystarczy do tego dorobić switch w makrach, a ustawienie w /etc/sysconfig/rpm No to już pisałem - AUTOMIGRATE2SYSTEMD załatwia wszystkie moje obawy. Ja sobie przestawię na 'no' i będę ręcznie włączał, wy z defaulta będziecie mieli domyślnie włączone. Ale ja nie mówię o żadnym dziwnym migrate, ale ogólnej funkcji, która będzie blokowała automatyczne aktywowanie usługi if [ $AUTO_ACTIVATE_SERVICE != no ]; then to co jest teraz robione w kwestii aktywowania serwisu fi Do makra i wszyscy będą szczęśliwi. Problematyka godna PLD. Ciekawe czy w innych, dużo większych i bardziej popularnych dystrybucjach, które używają systemd, też takie wyszukiwanie problemów było. Pewnie nie, ale jeszcze nie słyszałem o takim któremu udało się zrobić upgrade fedory, tak żeby system działał tak samo po jak przed ;) Istnieje cieniutka granica między sytuacją kiedy rozdmuchiwanie problematyki wdrożenia czegoś jest konstruktywne i dąży do poprawienia błędów w nowym rozwiązaniu, a sytuacją kiedy juz po prostu tylko hamuje rozwój i wdrożenie nowej technologii. Powolutku jesteście już w fazie hamującej. -- I'm living proof if you do one thing right in your career, you can coast for a long time. A LONG time. -Guy Kawasaki ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
W dniu 2012-01-26 20:28, Jan Rękorajski pisze: Pewnie nie, ale jeszcze nie słyszałem o takim któremu udało się zrobić upgrade fedory, tak żeby system działał tak samo po jak przed Hm, głupia sprawa. Ja robiłem. Działa. :) -- Paweł @duddits Długosz .::http://dlugosz.eu::. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Thu, 26 Jan 2012, Bartosz Świątek wrote: W dniu 26 stycznia 2012 20:28 użytkownik Jan Rękorajski bagg...@pld-linux.org napisał: On Thu, 26 Jan 2012, Bartosz Świątek wrote: W dniu 26 stycznia 2012 19:38 użytkownik Pawel Golaszewski bl...@pld-linux.org napisał: On Thu, 26 Jan 2012, Tomasz Pala wrote: Prościej jest wyłączyć pojedyncze, niechciane usługi niż włączać wszystko. Nie - ponieważ włączenie systemd robi się JEDEN raz, a wyłączać będę musiał przy KAŻDEJ aktualizacji. Zmierzasz do tego, żeby usługa była wyłączona przy instalacji domyślnie? Wystarczy do tego dorobić switch w makrach, a ustawienie w /etc/sysconfig/rpm No to już pisałem - AUTOMIGRATE2SYSTEMD załatwia wszystkie moje obawy. Ja sobie przestawię na 'no' i będę ręcznie włączał, wy z defaulta będziecie mieli domyślnie włączone. Ale ja nie mówię o żadnym dziwnym migrate, ale ogólnej funkcji, która będzie blokowała automatyczne aktywowanie usługi if [ $AUTO_ACTIVATE_SERVICE != no ]; then to co jest teraz robione w kwestii aktywowania serwisu fi Do makra i wszyscy będą szczęśliwi. Problematyka godna PLD. Ciekawe czy w innych, dużo większych i bardziej popularnych dystrybucjach, które używają systemd, też takie wyszukiwanie problemów było. Pewnie nie, ale jeszcze nie słyszałem o takim któremu udało się zrobić upgrade fedory, tak żeby system działał tak samo po jak przed ;) Istnieje cieniutka granica między sytuacją kiedy rozdmuchiwanie problematyki wdrożenia czegoś jest konstruktywne i dąży do poprawienia błędów w nowym rozwiązaniu, a sytuacją kiedy juz po prostu tylko hamuje rozwój i wdrożenie nowej technologii. Powolutku jesteście już w fazie hamującej. To akurat sam widzę :) Dlatego spokojnie robię eksperymentalne wdrożenie i kolejne jego efekty wrzucam do CVS zamiast tu bić pianę. Jak już będę miał w miare pełny obraz to wrzucę tu podsumowanie ; -- Jan Rękorajski| ALL SUSPECTS ARE GUILTY. PERIOD! bagginsatmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Wed, Jan 25, 2012 at 08:24:28 +0100, Pawel Golaszewski wrote: 0. olewamy sprawę, jak ktoś zmieni inita, to ten mu uruchomi usługi SysV; będzie musiał sobie ręcznie włączyć co chce mieć pod systemd. No nie - to nie jest fajne, system staje się niedeterministyczny, zależny MOCNO od kolejności instalacji. A czym się różni uruchomienie przez SysV od uruchomienia przez unit? Niczym istotnym - funkcjonalność pozostaje. Przeczytaj jeszcze raz: w zależności od kolejności instalowania dostaniesz zupełnie inaczej działający system. W jaki niby sposób? Konkretnie - bo nie widzę takiej możliwości. Nie dam sobie teraz nic uciąć, ale enable/disable z tego co pamiętam (bo CHYBA kiedyś sprawdzałem) nie wymaga dbusa ani nic - przecież ta funkcja powinna działać nawet z poziomu emergency.target. Jaki sens ma wogóle wydzielenie units do osobnego pakietu? W momencie tego podziału reszta pakietu zastępowała całego inita. Później dopiero wydzieliłem 'compat' (tj. /bin/init oraz towarzyszące symlinki) i teraz jedyne uzasadnienie units to właśnie R/S w demonach. 2. Magia przy instalacji systemd-units, która włączy wcześniej zainstalowane paczki. 3. Odłożenie komend z makr do wykonania później. Jak już wspomniałem - oba te warianty są wadliwe, gdyż mogą aktywować usługi wyłączone chkconfigiem. Jeżeli nie masz jakiejś procedury przejścia konfiguracji chkconfiga to ten temat nie istnieje (proszę, nie mów o ręcznym grzebaniu, to można zrobić na 1-2 maszynach). No właśnie - wariant 2 i 3 możemy sobie od razu odpuścić, bo zawiodą i tak. Robota głupiego - szczególnie zważywszy na charakter PLD. Bo nigdy nie będzie. 100% automatyczne przejście nie jest chyba możliwe, fedory i inne też chyba tego nie obsługują... Oni mają prościej - od powiedzmy FC15 jest systemd (jest punkt migracji), no i oni nie są tak elastyczni dla indywidualnych konfiguracji, jak stara się być PLD. -- Tomasz Pala go...@pld-linux.org ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Wed, Jan 25, 2012 at 08:40:34 +0100, Jan Rękorajski wrote: To jest bardzo kiepski pomysł. Bo jak kiedyś SysVinit wyleci to dostaniesz system w którym nic się nie uruchamia, albo będziesz musiał poprawiać milion pakietów, żeby włączały usługi systemd. A czemu SysV miałoby wylecieć? Mówisz o perspektywie 10 lat (LSB i konieczność utrzymania 3rd party software!). Przy zastosowaniach PLD i jego popularności śmiem twierdzić, że nikogo _zainteresowanego_ problem nie dotknie. Nie uprawiajmy sztuki dla sztuki. Najlepszym rozwiązaniem jest R:systemd-units i (warunkowe) włączanie usług systemd w post, np coś w stylu: if init = /sbin/init chkconfig --list service | grep -qs on %systemd_post service else %systemd_post service fi Szczególnie, jak np. nowopowstały unit dla ssh nie podniesie tejże usługi i będzie trzeba zrobić sobie wycieczkę. Albo wyjdzie jakiś babol przy restarcie. Albo tysiąc innych rzeczy - SysV mamy przetestowane w maksymalnym możliwym stopniu we wszystkich wariantach, tu nie chodzi o to, co jest 'prościej', lecz bezpieczniej. Mam wymieniać potencjalne problemy? Demony monitorujące usługi (np. monit) odwołujące się wprost do SysV - jak ktoś sobie napisał, to musi przerobić (a skoro napisał, to pewnie były problemy). Albo wyłączyć w monicie i włączyć supervision w systemd. To samo w logrotate. Dalej - ja mam przykładowo uruchomione lokalnie 2 kopie apacha (worker dla statycznych treści i prefork za reverse proxy do PHP). Dodając takie %posty zmusisz mnie do aktualizowania wszystkiego z --noscripts. Prościej jest wyłączyć pojedyncze, niechciane usługi niż włączać wszystko. Nie - ponieważ włączenie systemd robi się JEDEN raz, a wyłączać będę musiał przy KAŻDEJ aktualizacji. -- Tomasz Pala go...@pld-linux.org ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
Dnia 25 stycznia 2012 8:31 Arkadiusz Miśkiewicz ar...@maven.pl napisał(a): On Tuesday 24 of January 2012, Tomasz Pala wrote: On Tue, Jan 24, 2012 at 15:23:46 +0100, Jacek Konieczny wrote: Czyli zostały dwie opcje: W zasadzie trzy: 0. olewamy sprawę, jak ktoś zmieni inita, to ten mu uruchomi usługi SysV; będzie musiał sobie ręcznie włączyć co chce mieć pod systemd. Mi się to rozwiązanie podoba najbardziej. Świadoma migracja przez administratora i świadome aktywowanie usług pod systemd. +1 Aktualnie systemd po zainstalowaniu podnosi minimum systemowe + co uda mu sie z kompatybilnosci SYSV + siec (onboot) Ktos kto migruje sobie na systemd powinien teraz sprawdzic ktore uslugi np. sie nie podniosly/nie dzialaja itp. Ewentualnie doinstalowac paczke -systemd uslugi ktora nie wstala i ja zrestartowac, podniosla sie albo nie. systemd-journal pomaga w tym i innych problemach. Docelowo mozna wrzucic to pozniej do paczki glownej z Obsoletes. Zasadniczo jestem z systemd na desktopie zadowolony, nie odpowiada mi jeszcze ze NetworkManager do polaczen automatycznych dodaje ONBOOT=yes przez co rc-scripts/systemd probuje wszystkie po kolei podniesc. imho powinien do tego uzyc jakis inny znacznik - zobacze czy da sie do tego jakas latke zrobic. Do filesystem trzeba dodac /etc/hostname, a w samym rc-scripts dodac drukowanie hosta do /etc/hostname albo zaczac korzystac z tego w rc-scripts co chyba jest lepsze. Aktualnie problemem jest zasadniczo u nas to ze nie ma feedbacku co sie nie podnosi co poprawic. Dyskusja ta powinna byc o dzialaniu i problemach. Pozniej wypracujmy sobie model gdzie ostatecznie co ma sie znalezc. Pozdrawiam Bartlomiej Zimon ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
Dnia 20 stycznia 2012 13:26 Tomasz Pala go...@polanet.pl napisał(a): On Fri, Jan 20, 2012 at 13:24:07 +0100, Bartlomiej Zimon wrote: No dobra ale jest jeszcze jeden temat - dodalem kdm.service (paczka kde4-kdm-systemd) ale aktualizacja powoduje restart kdm a tego nie chcemy jak ten temat rozwiazac? nowe/uaktualnione makro w macros.build? Hmm? Co tam kdm, sprawdzał ktoś jak się zachowa ssh? dla potomnosci: export NORESTART=1 powoduje ze nie restartuja sie uslugi - fajne tylko czemu nie ta zmienna: # grep RESTART /etc/sysconfig/rpm #RPM_SKIP_AUTO_RESTART=yes Pozdrawiam Bartlomiej Zimon ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
Dnia 25 stycznia 2012 9:43 Pawel Sikora pl...@agmk.net napisał(a): On Wednesday 25 of January 2012 09:37:23 Bartlomiej Zimon wrote: Aktualnie problemem jest zasadniczo u nas to ze nie ma feedbacku co sie nie podnosi co poprawic. tu zamiescilem linka do przykladu dzialajacego na rc-scripts, a nie dzialajcego na systemd: http://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2012-January/154578.html da sie to jakos na carme przetestowac? ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
network scripts (Bylo Re: Migracja serwisów SysV - systemd)
Dnia 25 stycznia 2012 9:37 Bartlomiej Zimon uz...@o2.pl napisał(a): Zasadniczo jestem z systemd na desktopie zadowolony, nie odpowiada mi jeszcze ze NetworkManager do polaczen automatycznych dodaje ONBOOT=yes przez co rc-scripts/systemd probuje wszystkie po kolei podniesc. imho powinien do tego uzyc jakis inny znacznik - zobacze czy da sie do tego jakas latke zrobic. Czy brak wpisu ONBOOT w pliku np. /etc/sysconfig/interfaces/ifcfg-eth0 podniesie usluge podczas uruchamiania czy nie, oraz jak to powinno byc poprawnie? Pozdrawiam Bartlomiej Zimon ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: network scripts (Bylo Re: Migracja serwisów SysV - systemd)
Dnia 25 stycznia 2012 10:00 Bartlomiej Zimon uz...@o2.pl napisał(a): Dnia 25 stycznia 2012 9:37 Bartlomiej Zimon uz...@o2.pl napisał(a): Zasadniczo jestem z systemd na desktopie zadowolony, nie odpowiada mi jeszcze ze NetworkManager do polaczen automatycznych dodaje ONBOOT=yes przez co rc-scripts/systemd probuje wszystkie po kolei podniesc. imho powinien do tego uzyc jakis inny znacznik - zobacze czy da sie do tego jakas latke zrobic. Czy brak wpisu ONBOOT w pliku np. /etc/sysconfig/interfaces/ifcfg-eth0 podniesie usluge podczas uruchamiania czy nie, oraz jak to powinno byc poprawnie? ok network scripts olewa takie polaczenie za to trzeba dopisac w network scripts ze jesli istnieje zapis USERS to tez powinny go olac bo to konfiguracja uzytkownika ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: network scripts (Bylo Re: Migracja serwisów SysV - systemd)
On Wed, 25 Jan 2012, Bartlomiej Zimon wrote: Dnia 25 stycznia 2012 10:00 Bartlomiej Zimon uz...@o2.pl napisał(a): Dnia 25 stycznia 2012 9:37 Bartlomiej Zimon uz...@o2.pl napisał(a): Zasadniczo jestem z systemd na desktopie zadowolony, nie odpowiada mi jeszcze ze NetworkManager do polaczen automatycznych dodaje ONBOOT=yes przez co rc-scripts/systemd probuje wszystkie po kolei podniesc. imho powinien do tego uzyc jakis inny znacznik - zobacze czy da sie do tego jakas latke zrobic. Czy brak wpisu ONBOOT w pliku np. /etc/sysconfig/interfaces/ifcfg-eth0 podniesie usluge podczas uruchamiania czy nie, oraz jak to powinno byc poprawnie? ok network scripts olewa takie polaczenie za to trzeba dopisac w network scripts ze jesli istnieje zapis USERS to tez powinny go olac bo to konfiguracja uzytkownika A może NMCONTROLLED? Tak jak to jest w wiodących dystrybucjach? -- Jan Rękorajski| ALL SUSPECTS ARE GUILTY. PERIOD! bagginsatmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Wed, 25 Jan 2012, Tomasz Pala wrote: On Wed, Jan 25, 2012 at 08:40:34 +0100, Jan Rękorajski wrote: To jest bardzo kiepski pomysł. Bo jak kiedyś SysVinit wyleci to dostaniesz system w którym nic się nie uruchamia, albo będziesz musiał poprawiać milion pakietów, żeby włączały usługi systemd. A czemu SysV miałoby wylecieć? Mówisz o perspektywie 10 lat (LSB i konieczność utrzymania 3rd party software!). Przy zastosowaniach PLD i jego popularności śmiem twierdzić, że nikogo _zainteresowanego_ problem nie dotknie. Nie uprawiajmy sztuki dla sztuki. A jak będę chciał zainstalować nowy system to będę musiał dzielnie dłubać i każdą usługę włączać ręcznie? Nie dziękuję, w takiej sytuacji to można sobie wogóle darować. Najlepszym rozwiązaniem jest R:systemd-units i (warunkowe) włączanie usług systemd w post, np coś w stylu: if init = /sbin/init chkconfig --list service | grep -qs on %systemd_post service else %systemd_post service fi Szczególnie, jak np. nowopowstały unit dla ssh nie podniesie tejże usługi i będzie trzeba zrobić sobie wycieczkę. Albo wyjdzie jakiś babol przy restarcie. Albo tysiąc innych rzeczy - SysV mamy przetestowane w maksymalnym możliwym stopniu we wszystkich wariantach, tu nie chodzi o Nowy unit też można wytestować. A jak się zmienia init zdalnie, nie mająć jakiegoś LOM, to jest kompletna jazda bez trzymanki. Nowe systemy też instalujesz zdalnie? to, co jest 'prościej', lecz bezpieczniej. Mam wymieniać potencjalne problemy? Demony monitorujące usługi (np. monit) odwołujące się wprost do SysV - jak ktoś sobie napisał, to musi przerobić (a skoro napisał, to pewnie były problemy). Albo wyłączyć w monicie i włączyć supervision w systemd. To samo w logrotate. Dalej - ja mam przykładowo uruchomione lokalnie 2 kopie apacha (worker dla statycznych treści i prefork za reverse proxy do PHP). Dodając takie %posty zmusisz mnie do aktualizowania wszystkiego z --noscripts. Prościej jest wyłączyć pojedyncze, niechciane usługi niż włączać wszystko. Nie - ponieważ włączenie systemd robi się JEDEN raz, a wyłączać będę musiał przy KAŻDEJ aktualizacji. Przeczytałeś tek kawałek shella który podrzuciłem? Chodzi o to żeby usługę systemd: - włączyć o ile jest włączona usługa SysV - jeżeli nie ma usługi SysV to włączyć (tak jak teraz dla usług SysV) - przy upgrade usługi systemd nie zmieniać stanu A dla sshd to można dać z defaultu Restart=on-abort. O. -- Jan Rękorajski| ALL SUSPECTS ARE GUILTY. PERIOD! bagginsatmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: network scripts (Bylo Re: Migracja serwisów SysV - systemd)
Dnia 25 stycznia 2012 10:25 Jan Rękorajski bagg...@pld-linux.org napisał(a): On Wed, 25 Jan 2012, Bartlomiej Zimon wrote: Dnia 25 stycznia 2012 10:00 Bartlomiej Zimon uz...@o2.pl napisał(a): Dnia 25 stycznia 2012 9:37 Bartlomiej Zimon uz...@o2.pl napisał(a): Zasadniczo jestem z systemd na desktopie zadowolony, nie odpowiada mi jeszcze ze NetworkManager do polaczen automatycznych dodaje ONBOOT=yes przez co rc-scripts/systemd probuje wszystkie po kolei podniesc. imho powinien do tego uzyc jakis inny znacznik - zobacze czy da sie do tego jakas latke zrobic. Czy brak wpisu ONBOOT w pliku np. /etc/sysconfig/interfaces/ifcfg-eth0 podniesie usluge podczas uruchamiania czy nie, oraz jak to powinno byc poprawnie? ok network scripts olewa takie polaczenie za to trzeba dopisac w network scripts ze jesli istnieje zapis USERS to tez powinny go olac bo to konfiguracja uzytkownika A może NMCONTROLLED? Tak jak to jest w wiodących dystrybucjach? samo to ze UUID jest ustawione oznacza ze to NM go dodal jesli jest USERS to znaczy ze nie jest to polaczenie systemowe ktorymi wlasnie zajmuje sie rc-scripts. ok rel 4 rc-scripts powinien zalatwic sprawe ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: network scripts (Bylo Re: Migracja serwisów SysV - systemd)
On Wed, 25 Jan 2012, Bartlomiej Zimon wrote: Dnia 25 stycznia 2012 10:25 Jan Rękorajski bagg...@pld-linux.org napisał(a): On Wed, 25 Jan 2012, Bartlomiej Zimon wrote: Dnia 25 stycznia 2012 10:00 Bartlomiej Zimon uz...@o2.pl napisał(a): Dnia 25 stycznia 2012 9:37 Bartlomiej Zimon uz...@o2.pl napisał(a): Zasadniczo jestem z systemd na desktopie zadowolony, nie odpowiada mi jeszcze ze NetworkManager do polaczen automatycznych dodaje ONBOOT=yes przez co rc-scripts/systemd probuje wszystkie po kolei podniesc. imho powinien do tego uzyc jakis inny znacznik - zobacze czy da sie do tego jakas latke zrobic. Czy brak wpisu ONBOOT w pliku np. /etc/sysconfig/interfaces/ifcfg-eth0 podniesie usluge podczas uruchamiania czy nie, oraz jak to powinno byc poprawnie? ok network scripts olewa takie polaczenie za to trzeba dopisac w network scripts ze jesli istnieje zapis USERS to tez powinny go olac bo to konfiguracja uzytkownika A może NMCONTROLLED? Tak jak to jest w wiodących dystrybucjach? samo to ze UUID jest ustawione oznacza ze to NM go dodal jesli jest USERS to znaczy ze nie jest to polaczenie systemowe ktorymi wlasnie zajmuje sie rc-scripts. ok rel 4 rc-scripts powinien zalatwic sprawe To jeszcze post w systemd zmień. -- Jan Rękorajski| ALL SUSPECTS ARE GUILTY. PERIOD! bagginsatmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Wed, Jan 25, 2012 at 10:39:33 +0100, Jan Rękorajski wrote: A jak będę chciał zainstalować nowy system to będę musiał dzielnie dłubać i każdą usługę włączać ręcznie? Nie dziękuję, w takiej sytuacji to można sobie wogóle darować. To sobie najpierw zainstalujesz systemd-units i wszystko się samo aktywuje. Nowy unit też można wytestować. A jak się zmienia init zdalnie, nie mająć jakiegoś LOM, to jest kompletna jazda bez trzymanki. Nie, czemu? Już wspominałem, że jest to teraz rozdzielone i można spokojnie testować z init=/sbin/systemd, wystarczy mieć zdalny reseter (choćby na telefonie, IPMI nawet bez SOL, zarządzalna listwa zasilająca itp.). Nowe systemy też instalujesz zdalnie? Tak, lokalnie nie instalowałem systemu od hoho. Przeczytałeś tek kawałek shella który podrzuciłem? Chodzi o to żeby usługę systemd: - włączyć o ile jest włączona usługa SysV - jeżeli nie ma usługi SysV to włączyć (tak jak teraz dla usług SysV) - przy upgrade usługi systemd nie zmieniać stanu To ja tylko poproszę o obsługę czegoś w stylu AUTOMIGRATE2SYSTEMD=no w /etc/sysconfig/rpm do tego shella i jak dla mnie może być. Czyli wariant 1 z R: systemd-units, a przejście do wariantu 0 konfigurowalne explicite. -- Tomasz Pala go...@pld-linux.org ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: network scripts (Bylo Re: Migracja serwisów SysV - systemd)
Dnia 25 stycznia 2012 11:00 Jan Rękorajski bagg...@pld-linux.org napisał(a): On Wed, 25 Jan 2012, Bartlomiej Zimon wrote: Dnia 25 stycznia 2012 10:25 Jan Rękorajski bagg...@pld-linux.org napisał(a): On Wed, 25 Jan 2012, Bartlomiej Zimon wrote: Dnia 25 stycznia 2012 10:00 Bartlomiej Zimon uz...@o2.pl napisał(a): Dnia 25 stycznia 2012 9:37 Bartlomiej Zimon uz...@o2.pl napisał(a): Zasadniczo jestem z systemd na desktopie zadowolony, nie odpowiada mi jeszcze ze NetworkManager do polaczen automatycznych dodaje ONBOOT=yes przez co rc-scripts/systemd probuje wszystkie po kolei podniesc. imho powinien do tego uzyc jakis inny znacznik - zobacze czy da sie do tego jakas latke zrobic. Czy brak wpisu ONBOOT w pliku np. /etc/sysconfig/interfaces/ifcfg-eth0 podniesie usluge podczas uruchamiania czy nie, oraz jak to powinno byc poprawnie? ok network scripts olewa takie polaczenie za to trzeba dopisac w network scripts ze jesli istnieje zapis USERS to tez powinny go olac bo to konfiguracja uzytkownika A może NMCONTROLLED? Tak jak to jest w wiodących dystrybucjach? samo to ze UUID jest ustawione oznacza ze to NM go dodal jesli jest USERS to znaczy ze nie jest to polaczenie systemowe ktorymi wlasnie zajmuje sie rc-scripts. ok rel 4 rc-scripts powinien zalatwic sprawe To jeszcze post w systemd zmień. Dlaczego? Tam powinno byc ok ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: network scripts (Bylo Re: Migracja serwisów SysV - systemd)
On Wed, 25 Jan 2012, Bartlomiej Zimon wrote: Dnia 25 stycznia 2012 11:00 Jan Rękorajski bagg...@pld-linux.org napisał(a): On Wed, 25 Jan 2012, Bartlomiej Zimon wrote: Dnia 25 stycznia 2012 10:25 Jan Rękorajski bagg...@pld-linux.org napisał(a): On Wed, 25 Jan 2012, Bartlomiej Zimon wrote: Dnia 25 stycznia 2012 10:00 Bartlomiej Zimon uz...@o2.pl napisał(a): Dnia 25 stycznia 2012 9:37 Bartlomiej Zimon uz...@o2.pl napisał(a): Zasadniczo jestem z systemd na desktopie zadowolony, nie odpowiada mi jeszcze ze NetworkManager do polaczen automatycznych dodaje ONBOOT=yes przez co rc-scripts/systemd probuje wszystkie po kolei podniesc. imho powinien do tego uzyc jakis inny znacznik - zobacze czy da sie do tego jakas latke zrobic. Czy brak wpisu ONBOOT w pliku np. /etc/sysconfig/interfaces/ifcfg-eth0 podniesie usluge podczas uruchamiania czy nie, oraz jak to powinno byc poprawnie? ok network scripts olewa takie polaczenie za to trzeba dopisac w network scripts ze jesli istnieje zapis USERS to tez powinny go olac bo to konfiguracja uzytkownika A może NMCONTROLLED? Tak jak to jest w wiodących dystrybucjach? samo to ze UUID jest ustawione oznacza ze to NM go dodal jesli jest USERS to znaczy ze nie jest to polaczenie systemowe ktorymi wlasnie zajmuje sie rc-scripts. ok rel 4 rc-scripts powinien zalatwic sprawe To jeszcze post w systemd zmień. Dlaczego? Tam powinno byc ok Znaczy się samo sprawdzenie czy jest zmienna DEVICE= powinno wystarczyć? Patrzyłeś co w tym post wogóle jest? -- Jan Rękorajski| ALL SUSPECTS ARE GUILTY. PERIOD! bagginsatmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: network scripts (Bylo Re: Migracja serwisów SysV - systemd)
Dnia 25 stycznia 2012 11:26 Jan Rękorajski bagg...@pld-linux.org napisał(a): On Wed, 25 Jan 2012, Bartlomiej Zimon wrote: Dnia 25 stycznia 2012 11:00 Jan Rękorajski bagg...@pld-linux.org napisał(a): On Wed, 25 Jan 2012, Bartlomiej Zimon wrote: Dnia 25 stycznia 2012 10:25 Jan Rękorajski bagg...@pld-linux.org napisał(a): On Wed, 25 Jan 2012, Bartlomiej Zimon wrote: Dnia 25 stycznia 2012 10:00 Bartlomiej Zimon uz...@o2.pl napisał(a): Dnia 25 stycznia 2012 9:37 Bartlomiej Zimon uz...@o2.pl napisał(a): Zasadniczo jestem z systemd na desktopie zadowolony, nie odpowiada mi jeszcze ze NetworkManager do polaczen automatycznych dodaje ONBOOT=yes przez co rc-scripts/systemd probuje wszystkie po kolei podniesc. imho powinien do tego uzyc jakis inny znacznik - zobacze czy da sie do tego jakas latke zrobic. Czy brak wpisu ONBOOT w pliku np. /etc/sysconfig/interfaces/ifcfg-eth0 podniesie usluge podczas uruchamiania czy nie, oraz jak to powinno byc poprawnie? ok network scripts olewa takie polaczenie za to trzeba dopisac w network scripts ze jesli istnieje zapis USERS to tez powinny go olac bo to konfiguracja uzytkownika A może NMCONTROLLED? Tak jak to jest w wiodących dystrybucjach? samo to ze UUID jest ustawione oznacza ze to NM go dodal jesli jest USERS to znaczy ze nie jest to polaczenie systemowe ktorymi wlasnie zajmuje sie rc-scripts. ok rel 4 rc-scripts powinien zalatwic sprawe To jeszcze post w systemd zmień. Dlaczego? Tam powinno byc ok Znaczy się samo sprawdzenie czy jest zmienna DEVICE= powinno wystarczyć? Patrzyłeś co w tym post wogóle jest? dobrze rozumiem ?: network-post.service - /etc/init.d/network start_postinit - static rarp,arp ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
Dnia 25 stycznia 2012 11:08 Pawel Sikora pl...@agmk.net napisał(a): On Wednesday 25 of January 2012 09:48:16 Bartlomiej Zimon wrote: Dnia 25 stycznia 2012 9:43 Pawel Sikora pl...@agmk.net napisał(a): On Wednesday 25 of January 2012 09:37:23 Bartlomiej Zimon wrote: Aktualnie problemem jest zasadniczo u nas to ze nie ma feedbacku co sie nie podnosi co poprawic. tu zamiescilem linka do przykladu dzialajacego na rc-scripts, a nie dzialajcego na systemd: http://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2012-January/154578.html da sie to jakos na carme przetestowac? jak odpalisz qemu z opcja -curses to powinno sie dac. pytanie czy chesz sie tak bawic? nie lepiej odpalic to lokalnie? brak miejsca lokalnie ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: network scripts (Bylo Re: Migracja serwisów SysV - systemd)
On Wed, 25 Jan 2012, Bartlomiej Zimon wrote: Dnia 25 stycznia 2012 11:26 Jan Rękorajski bagg...@pld-linux.org napisał(a): On Wed, 25 Jan 2012, Bartlomiej Zimon wrote: Dnia 25 stycznia 2012 11:00 Jan Rękorajski bagg...@pld-linux.org napisał(a): On Wed, 25 Jan 2012, Bartlomiej Zimon wrote: Dnia 25 stycznia 2012 10:25 Jan Rękorajski bagg...@pld-linux.org napisał(a): On Wed, 25 Jan 2012, Bartlomiej Zimon wrote: Dnia 25 stycznia 2012 10:00 Bartlomiej Zimon uz...@o2.pl napisał(a): Dnia 25 stycznia 2012 9:37 Bartlomiej Zimon uz...@o2.pl napisał(a): Zasadniczo jestem z systemd na desktopie zadowolony, nie odpowiada mi jeszcze ze NetworkManager do polaczen automatycznych dodaje ONBOOT=yes przez co rc-scripts/systemd probuje wszystkie po kolei podniesc. imho powinien do tego uzyc jakis inny znacznik - zobacze czy da sie do tego jakas latke zrobic. Czy brak wpisu ONBOOT w pliku np. /etc/sysconfig/interfaces/ifcfg-eth0 podniesie usluge podczas uruchamiania czy nie, oraz jak to powinno byc poprawnie? ok network scripts olewa takie polaczenie za to trzeba dopisac w network scripts ze jesli istnieje zapis USERS to tez powinny go olac bo to konfiguracja uzytkownika A może NMCONTROLLED? Tak jak to jest w wiodących dystrybucjach? samo to ze UUID jest ustawione oznacza ze to NM go dodal jesli jest USERS to znaczy ze nie jest to polaczenie systemowe ktorymi wlasnie zajmuje sie rc-scripts. ok rel 4 rc-scripts powinien zalatwic sprawe To jeszcze post w systemd zmień. Dlaczego? Tam powinno byc ok Znaczy się samo sprawdzenie czy jest zmienna DEVICE= powinno wystarczyć? Patrzyłeś co w tym post wogóle jest? dobrze rozumiem ?: network-post.service - /etc/init.d/network start_postinit - static rarp,arp Tak. -- Jan Rękorajski| ALL SUSPECTS ARE GUILTY. PERIOD! bagginsatmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
Dnia 25 stycznia 2012 13:41 Bartlomiej Zimon uz...@o2.pl napisał(a): Dnia 25 stycznia 2012 11:08 Pawel Sikora pl...@agmk.net napisał(a): On Wednesday 25 of January 2012 09:48:16 Bartlomiej Zimon wrote: Dnia 25 stycznia 2012 9:43 Pawel Sikora pl...@agmk.net napisał(a): On Wednesday 25 of January 2012 09:37:23 Bartlomiej Zimon wrote: Aktualnie problemem jest zasadniczo u nas to ze nie ma feedbacku co sie nie podnosi co poprawic. tu zamiescilem linka do przykladu dzialajacego na rc-scripts, a nie dzialajcego na systemd: http://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2012-January/154578.html da sie to jakos na carme przetestowac? jak odpalisz qemu z opcja -curses to powinno sie dac. pytanie czy chesz sie tak bawic? nie lepiej odpalic to lokalnie? brak miejsca lokalnie ok zobaczymy cos nie cos oproznilem moze sie zmieszcze :P ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: network scripts (Bylo Re: Migracja serwisów SysV - systemd)
Dnia 25 stycznia 2012 13:51 Jan Rękorajski bagg...@pld-linux.org napisał(a): On Wed, 25 Jan 2012, Bartlomiej Zimon wrote: dobrze rozumiem ?: network-post.service - /etc/init.d/network start_postinit - static rarp,arp Tak. Wydaje mi sie ze nie powinno byc z tym problemu. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Wed, 25 Jan 2012, Bartlomiej Zimon wrote: No dobra ale jest jeszcze jeden temat - dodalem kdm.service (paczka kde4-kdm-systemd) ale aktualizacja powoduje restart kdm a tego nie chcemy jak ten temat rozwiazac? nowe/uaktualnione makro w macros.build? Hmm? Co tam kdm, sprawdzał ktoś jak się zachowa ssh? Restart sshd normalnie nie powodował żadnych problemów, sesje zostawały. dla potomnosci: export NORESTART=1 powoduje ze nie restartuja sie uslugi - fajne tylko czemu nie ta zmienna: # grep RESTART /etc/sysconfig/rpm #RPM_SKIP_AUTO_RESTART=yes Bo to jest włączenie/wyłączenie globalne, a tutaj trzebaby dla jednej usługi -- pozdr. Paweł Gołaszewski jid:bluesatjabberdotgdadotpl -- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free.___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
Dnia 25 stycznia 2012 13:54 Bartlomiej Zimon uz...@o2.pl napisał(a): Dnia 25 stycznia 2012 13:41 Bartlomiej Zimon uz...@o2.pl napisał(a): Dnia 25 stycznia 2012 11:08 Pawel Sikora pl...@agmk.net napisał(a): On Wednesday 25 of January 2012 09:48:16 Bartlomiej Zimon wrote: Dnia 25 stycznia 2012 9:43 Pawel Sikora pl...@agmk.net napisał(a): On Wednesday 25 of January 2012 09:37:23 Bartlomiej Zimon wrote: Aktualnie problemem jest zasadniczo u nas to ze nie ma feedbacku co sie nie podnosi co poprawic. tu zamiescilem linka do przykladu dzialajacego na rc-scripts, a nie dzialajcego na systemd: http://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2012-January/154578.html da sie to jakos na carme przetestowac? jak odpalisz qemu z opcja -curses to powinno sie dac. pytanie czy chesz sie tak bawic? nie lepiej odpalic to lokalnie? brak miejsca lokalnie ok zobaczymy cos nie cos oproznilem moze sie zmieszcze :P ok w jakis sposob wrzucic jakis plik na taki system w qemu? ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Wednesday 25 of January 2012 15:27:11 Bartlomiej Zimon wrote: Dnia 25 stycznia 2012 13:54 Bartlomiej Zimon uz...@o2.pl napisał(a): Dnia 25 stycznia 2012 13:41 Bartlomiej Zimon uz...@o2.pl napisał(a): Dnia 25 stycznia 2012 11:08 Pawel Sikora pl...@agmk.net napisał(a): On Wednesday 25 of January 2012 09:48:16 Bartlomiej Zimon wrote: Dnia 25 stycznia 2012 9:43 Pawel Sikora pl...@agmk.net napisał(a): On Wednesday 25 of January 2012 09:37:23 Bartlomiej Zimon wrote: Aktualnie problemem jest zasadniczo u nas to ze nie ma feedbacku co sie nie podnosi co poprawic. tu zamiescilem linka do przykladu dzialajacego na rc-scripts, a nie dzialajcego na systemd: http://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2012-January/154578.html da sie to jakos na carme przetestowac? jak odpalisz qemu z opcja -curses to powinno sie dac. pytanie czy chesz sie tak bawic? nie lepiej odpalic to lokalnie? brak miejsca lokalnie ok zobaczymy cos nie cos oproznilem moze sie zmieszcze :P ok w jakis sposob wrzucic jakis plik na taki system w qemu? scp? ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
W dniu 20 stycznia 2012 13:26 użytkownik Tomasz Pala go...@polanet.pl napisał: On Fri, Jan 20, 2012 at 13:24:07 +0100, Bartlomiej Zimon wrote: No dobra ale jest jeszcze jeden temat - dodalem kdm.service (paczka kde4-kdm-systemd) ale aktualizacja powoduje restart kdm a tego nie chcemy jak ten temat rozwiazac? nowe/uaktualnione makro w macros.build? Hmm? Co tam kdm, sprawdzał ktoś jak się zachowa ssh? A ja mam takie pytanie. Dlaczego skrypty systemdowe, są paczkowane w podpaczki -systemd? Jakie to ma zalety? Jesli dobrze rozumiem, to zawiera to tylko pliczki init dla systemd, które ważą ~nic. Robiona jest podpaczka, żeby RPM miał jeszcze więcej roboty grzebiąc po swojej bazie. Jako admin, trzeba np. przy migracji, pamiętać żeby sobie zainstalować te podpaczki do każdej usługi jaką się ma żeby w ogóle wystartowała, albo inaczej nie wystartuje lub wystartuje w trybie kompatybilności z sysV, tak? Moja propozycja to wrzucać to do normalniej paczki głównej tak samo jak skrypty sysV, bo przecież to niczemu nie przeszkadza, a i sprawa migracji jest załatwiona, bo trzeba tylko systemd zainstalować i nie trzeba pamiętać o tych podpaczkach. RPM też jest szczęśliwy, że nie musi bzdurami się zajmować. -- I'm living proof if you do one thing right in your career, you can coast for a long time. A LONG time. -Guy Kawasaki ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Tue, Jan 24, 2012 at 12:26:04PM +0100, Bartosz Świątek wrote: A ja mam takie pytanie. Dlaczego skrypty systemdowe, są paczkowane w podpaczki -systemd? Jakie to ma zalety? Też mnie to zastanawia. W przypadku Upstart to miało jakiś sens, gdy mało kto tego używał i instalowanie/nie-instalowanie paczki było wyborem między użyciem skryptu albo joba Upstart. Poza tym, rc-scripts działało obok Upstarta, a systemd praktycznie zastępuje rc-scripts. Mało sensu ma używanie skryptów w init.d/ gdy chodzi systemd. które ważą ~nic. Robiona jest podpaczka, żeby RPM miał jeszcze więcej roboty grzebiąc po swojej bazie. Robotą RPMa bym się nie przejmował. Co innego robota developerów i potem adminów… też dodatkowa gdy każda usługa musi mieć dodatkową paczkę dla systemd. Moja propozycja to wrzucać to do normalniej paczki głównej tak samo jak skrypty sysV +1 Pozdrowienia, Jacek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
2012/1/24 Jacek Konieczny jaj...@jajcus.net: które ważą ~nic. Robiona jest podpaczka, żeby RPM miał jeszcze więcej roboty grzebiąc po swojej bazie. Robotą RPMa bym się nie przejmował. Niektórym przeszkadza, że RPM przez rozdęcie bazy paczek działa tak ślamazarnie jak działa. wolf ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Tue, Jan 24, 2012 at 12:26:04PM +0100, Bartosz Świątek wrote:
A ja mam takie pytanie.
Dlaczego skrypty systemdowe, są paczkowane w podpaczki -systemd?
Jakie to ma zalety?
Już usłyszałem wyjaśnienie: %post w paczkach -systemd wymaga teraz
zainstalowanego systemd, jakby to było w głównej paczce, ten kod nie
wykonałby się, jeśli systemd będzie zainstalowany później.
Szybka analiza wykazała, że ze standardowych systemdowych %post i %preun
ten problem dotyczy tylko 'systemctl enable', reszta ma sens tylko w
systemie w którym systemd już działa jako init.
'systemctl enable' robi tylko symlinki, można by go zreimplementować,
ale to wymagałoby zrobienia parsera dla unitów systemd. Prościej chyba
jednak wydzielić minimum wymagane dla 'systemctl' i wymagać tego przez
pakiety z unitami dla systemd.
Teraz systemctl jest w systemd-units i wymaga systemd-libs. Można więc
wymagać systemd-units w paczkach używających %systemd_post
i %systemd_preun, albo próbować wydzielić systemctl do czegoś jeszcze
mniejszego (chyba nie ma sensu).
# rpm -q --queryformat '%{name} %{size}\n' systemd-units systemd-libs
systemd-units 308307
systemd-libs 47948
# ls -l /bin/systemctl
-rwxr-xr-x 1 root root 186472 Dec 6 21:17 /bin/systemctl
Pozdrowienia,
Jacek
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
W dniu 24 stycznia 2012 13:11 użytkownik Jacek Konieczny jaj...@jajcus.net napisał: On Tue, Jan 24, 2012 at 12:26:04PM +0100, Bartosz Świątek wrote: A ja mam takie pytanie. Dlaczego skrypty systemdowe, są paczkowane w podpaczki -systemd? Jakie to ma zalety? Już usłyszałem wyjaśnienie: %post w paczkach -systemd wymaga teraz zainstalowanego systemd, jakby to było w głównej paczce, ten kod nie wykonałby się, jeśli systemd będzie zainstalowany później. Czy to jest jakas baza systemdowa? Ze systemd wie ze zarejestrowaly sie u niego takie a siakie uslugi? Czy da sie ta baze manipulowac? Bo wyobrazam sobie pare lepszych rozwiazan. 1) Instalowac wszystko jak leci, jesli nie ma zainstalowanego systemd to sie najwyzej %post i %preun nie wykonaja (gracefully). Instalacja systemd wykrywalaby sobie sama w %post juz zainstalowane uslugi i je rejestrowala u siebie 2) Instalowac wszystko jak leci majac zainstalowany wlasnie jakis pakiet tworzacy ta baze, czy te symlinki potrzebne systemdowi. A instalacja systemd juz nic nie robi i widzi ze uslugi sa juz zarejestrowane u niego. 3) Jeszcze jakas inteligentniejsza metoda ktora akurat teraz nie zostala podana. -- I'm living proof if you do one thing right in your career, you can coast for a long time. A LONG time. -Guy Kawasaki ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Tue, Jan 24, 2012 at 01:26:41PM +0100, Bartosz Świątek wrote: Czy to jest jakas baza systemdowa? Tak jakby. Ze systemd wie ze zarejestrowaly sie u niego takie a siakie uslugi? To raczej unity, które odpowiadają plikom w init.d/ I symlinki, odpowiadające tym w rc*.d/. 'systemctl enable' odpowiada 'chkconfig --add'. Czy da sie ta baze manipulowac? Da się, normalnie za pomocą ln -s i rm, ale żeby to robić mądrze, to trzeba pliki /lib/systemd/system/*.service parsować. 1) Instalowac wszystko jak leci, jesli nie ma zainstalowanego systemd to sie najwyzej %post i %preun nie wykonaja (gracefully). Instalacja systemd wykrywalaby sobie sama w %post juz zainstalowane uslugi i je rejestrowala u siebie Też o tym myślałem. Tylko co ma systemd rozumieć jako 'juz zainstalowane uslugi'? Wszystko w /lib/systemd/system/? Czy tylko to co przyszło z RPMów? Albo tylko z rpmów z %systemd_post? Jak to rozróżnić? 2) Instalowac wszystko jak leci majac zainstalowany wlasnie jakis pakiet tworzacy ta baze, czy te symlinki potrzebne systemdowi. A instalacja systemd juz nic nie robi i widzi ze uslugi sa juz zarejestrowane u niego. To właśnie załatwiałoby systemd-units (zawierające obecnie i systemctl), ale musiałby być wymagane przez pakiety (tak jak teraz chkconfig). 3) Jeszcze jakas inteligentniejsza metoda ktora akurat teraz nie zostala podana. systemd-units to ponad 300kB, pewnie można byłoby znacznie krócej 'systemctl enable' i 'systemctl disable' zreimplementować w jakimś awku… ale nie jestem przekonany do tego rozwiązania. Pozdrowienia, Jacek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
W dniu 24 stycznia 2012 13:42 użytkownik Jacek Konieczny jaj...@jajcus.net napisał: On Tue, Jan 24, 2012 at 01:26:41PM +0100, Bartosz Świątek wrote: Czy to jest jakas baza systemdowa? Tak jakby. Ze systemd wie ze zarejestrowaly sie u niego takie a siakie uslugi? To raczej unity, które odpowiadają plikom w init.d/ I symlinki, odpowiadające tym w rc*.d/. 'systemctl enable' odpowiada 'chkconfig --add'. Czy da sie ta baze manipulowac? Da się, normalnie za pomocą ln -s i rm, ale żeby to robić mądrze, to trzeba pliki /lib/systemd/system/*.service parsować. 1) Instalowac wszystko jak leci, jesli nie ma zainstalowanego systemd to sie najwyzej %post i %preun nie wykonaja (gracefully). Instalacja systemd wykrywalaby sobie sama w %post juz zainstalowane uslugi i je rejestrowala u siebie Też o tym myślałem. Tylko co ma systemd rozumieć jako 'juz zainstalowane uslugi'? Wszystko w /lib/systemd/system/? Czy tylko to co przyszło z RPMów? Albo tylko z rpmów z %systemd_post? Jak to rozróżnić? Ja mysle ze to co przyszlo z rpmem, czyli te pliczki .service, tak? W %post po prostu szukac tych plikow i rejestrowac uslugi. 2) Instalowac wszystko jak leci majac zainstalowany wlasnie jakis pakiet tworzacy ta baze, czy te symlinki potrzebne systemdowi. A instalacja systemd juz nic nie robi i widzi ze uslugi sa juz zarejestrowane u niego. To właśnie załatwiałoby systemd-units (zawierające obecnie i systemctl), ale musiałby być wymagane przez pakiety (tak jak teraz chkconfig). Mogloby byc tez wymagane przez makra. Wtedy tych pakietow tykac nie trzeba. Powiedzmy makro %systemd_post wymaga jakiegos tam pakietu systemd-*. Jesli decydowac sie na ten wariant. 3) Jeszcze jakas inteligentniejsza metoda ktora akurat teraz nie zostala podana. systemd-units to ponad 300kB, pewnie można byłoby znacznie krócej 'systemctl enable' i 'systemctl disable' zreimplementować w jakimś awku… ale nie jestem przekonany do tego rozwiązania. -- I'm living proof if you do one thing right in your career, you can coast for a long time. A LONG time. -Guy Kawasaki ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
2012/1/24 Jacek Konieczny jaj...@jajcus.net: Teraz systemctl jest w systemd-units i wymaga systemd-libs. Można więc wymagać systemd-units w paczkach używających %systemd_post i %systemd_preun, albo próbować wydzielić systemctl do czegoś jeszcze mniejszego (chyba nie ma sensu). Z perspektywy czasu widzę, że można to właśnie tak zrobić, czyli zintegrować -systemd i wymagać systemd-units ze względu na %systemd_*. Oczywiście nie obędzie się teraz bez problemów przy zniknięciu -systemd (wyrejestrowanie i rejestrowanie unita w losowej kolejności). Ktoś chętny do zrobienia odpowiednich %trigger? -- Artur Frysiak ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Tue, 24 Jan 2012, Artur Frysiak wrote: 2012/1/24 Jacek Konieczny jaj...@jajcus.net: Teraz systemctl jest w systemd-units i wymaga systemd-libs. Można więc wymagać systemd-units w paczkach używających %systemd_post i %systemd_preun, albo próbować wydzielić systemctl do czegoś jeszcze mniejszego (chyba nie ma sensu). Z perspektywy czasu widzę, że można to właśnie tak zrobić, czyli zintegrować -systemd i wymagać systemd-units ze względu na %systemd_*. Oczywiście nie obędzie się teraz bez problemów przy zniknięciu -systemd (wyrejestrowanie i rejestrowanie unita w losowej kolejności). Ktoś chętny do zrobienia odpowiednich %trigger? %triggerpostun -- pakiet-systemd pierwsza wesja pakietu bez wydzielonego systemd %systemd_post Wystarczy? -- Jan Rękorajski| ALL SUSPECTS ARE GUILTY. PERIOD! bagginsatmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Tue, Jan 24, 2012 at 01:54:18PM +0100, Artur Frysiak wrote: Z perspektywy czasu widzę, że można to właśnie tak zrobić, czyli zintegrować -systemd i wymagać systemd-units ze względu na %systemd_*. Jeśli o mnie chodzi, to 'good enough'. Oczywiście nie obędzie się teraz bez problemów przy zniknięciu -systemd (wyrejestrowanie i rejestrowanie unita w losowej kolejności). Ktoś chętny do zrobienia odpowiednich %trigger? Ja bym przyjął, że dotychczasowe instalacje *-systemd były eksperymentalne i jak ktoś tego używał to sobie ręcznie zrobi co trzeba. Pozdrowienia, Jacek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Tue, 24 Jan 2012, Bartosz Świątek wrote: 1) Instalowac wszystko jak leci, jesli nie ma zainstalowanego systemd to sie najwyzej %post i %preun nie wykonaja (gracefully). Instalacja systemd wykrywalaby sobie sama w %post juz zainstalowane uslugi i je rejestrowala u siebie Też o tym myślałem. Tylko co ma systemd rozumieć jako 'juz zainstalowane uslugi'? Wszystko w /lib/systemd/system/? Czy tylko to co przyszło z RPMów? Albo tylko z rpmów z %systemd_post? Jak to rozróżnić? Ja mysle ze to co przyszlo z rpmem, czyli te pliczki .service, tak? W %post po prostu szukac tych plikow i rejestrowac uslugi. A nie lepiej to co miałoby sie wykonać we wszystkich postach w przypadku nieobecności wrappera z systemd wrzucić do jakiegoś katalogu (powiedzmy: /var/spool/systemd/dupa/nazwa_posta/) i potem w momencie instalacji systemd wykonać je hurtem? Przecież to jest lista poleceń shell-owych. To by załatwiło wszystkie problemy i było robione na poziomie makr rpm-a, bez parsowania plików i bez wszystkich problemów z tym związanych. -- pozdr. Paweł Gołaszewski jid:bluesatjabberdotgdadotpl -- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free.___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Tue, Jan 24, 2012 at 14:47:05 +0100, Pawel Golaszewski wrote: 'systemctl enable' robi tylko symlinki, można by go zreimplementować, ale to wymagałoby zrobienia parsera dla unitów systemd. Byłbym ostrożny, bo to może się zmienić w przyszłości i będzie ponowne wymyślanie koła. Tak szybko tylko - zgadzam się z Pawłem. Nie róbmy reimplementacji binarki, albo w dowolny sposób odłożymy JEJ wykonanie na przyszłość, albo trzeba wymagać JEJ obecności. -- Tomasz Pala go...@pld-linux.org ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Tue, Jan 24, 2012 at 02:55:16PM +0100, Pawel Golaszewski wrote: A nie lepiej to co miałoby sie wykonać we wszystkich postach w przypadku nieobecności wrappera z systemd wrzucić do jakiegoś katalogu (powiedzmy: /var/spool/systemd/dupa/nazwa_posta/) i potem w momencie instalacji systemd wykonać je hurtem? Przecież to jest lista poleceń shell-owych. Kolejny katalog z plikami do pilnowania. Będą instalacje i deinstalacje, które trzeba obsłużyć, przy obecności systemd (a właściwie systemd-units) i bez niego. Zmieni się koncepcja i co z plikami co tam już leżą? To by załatwiło wszystkie problemy i było robione na poziomie makr rpm-a, Bardziej skomplikowane makra też mnie nie pociągają… bez parsowania plików i bez wszystkich problemów z tym związanych. Parsowanie to głupi pomysł, tu zgoda. Pozdrowienia, Jacek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Tue, Jan 24, 2012 at 03:00:28PM +0100, Tomasz Pala wrote: On Tue, Jan 24, 2012 at 14:47:05 +0100, Pawel Golaszewski wrote: 'systemctl enable' robi tylko symlinki, można by go zreimplementować, ale to wymagałoby zrobienia parsera dla unitów systemd. Byłbym ostrożny, bo to może się zmienić w przyszłości i będzie ponowne wymyślanie koła. Tak szybko tylko - zgadzam się z Pawłem. Nie róbmy reimplementacji binarki, albo w dowolny sposób odłożymy JEJ wykonanie na przyszłość, albo trzeba wymagać JEJ obecności. Zaznaczę tylko, że wymieniłem opcję reimplementacji nie znaczy, że uważałem ją za dobry pomysł. ;) Czyli zostały dwie opcje: 1. Requires(post,preun): systemd-units 2. Magia przy instalacji systemd-units, która włączy wcześniej zainstalowane paczki. Może wystarczy 'systemctl enable /lib/systemd/system/*.service'? To na które się decydujemy? Pozdrowienia, Jacek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Tue, Jan 24, 2012 at 15:23:46 +0100, Jacek Konieczny wrote: Czyli zostały dwie opcje: W zasadzie trzy: 0. olewamy sprawę, jak ktoś zmieni inita, to ten mu uruchomi usługi SysV; będzie musiał sobie ręcznie włączyć co chce mieć pod systemd. 1. Requires(post,preun): systemd-units To jest najczystsze rozwiązanie - 300 KB dzisiaj nie stanowi problemu na większości maszyn. Wersja pośrednia pomiędzy 0 a 1 to po prostu S: systemd-units. 2. Magia przy instalacji systemd-units, która włączy wcześniej zainstalowane paczki. Może wystarczy 'systemctl enable /lib/systemd/system/*.service'? Pod * złapie się dużo rzeczy, które są uruchamiane jedynie zależnościami i nie powinno się ich włączać bezpośrednio. Mogą też być usługi, które po zainstalowaniu ktoś wyłączył chkconfigiem! Zatem jeśli już jakakolwiek automatyka, to tylko włączająca to co pokazuje chkconfig dla domyślnego runlevelu. Ale ja nie widzę takiej potrzeby - nawet bardziej bezpieczne jest rozwiązanie, w którym administrator świadomie przełącza każdą usługę z SysV na unit z osobna, a domyślnie nic mu się nie przełącza, tj. ma zwykły drop-in replacement (z jednym jedynym zastrzeżeniem: systemd uruchamia SysV z _wszystkich_ runleveli 2-4 i dodatkowo 5 dla graficznego defaulta). -- Tomasz Pala go...@pld-linux.org ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Tue, 24 Jan 2012, Jacek Konieczny wrote: A nie lepiej to co miałoby sie wykonać we wszystkich postach w przypadku nieobecności wrappera z systemd wrzucić do jakiegoś katalogu (powiedzmy: /var/spool/systemd/dupa/nazwa_posta/) i potem w momencie instalacji systemd wykonać je hurtem? Przecież to jest lista poleceń shell-owych. Kolejny katalog z plikami do pilnowania. A co w nim pilnować? Będą instalacje i deinstalacje, które trzeba obsłużyć, przy obecności systemd (a właściwie systemd-units) i bez niego. Nie ma systemd: - przy instalacji dodajesz pliczek - przy deinstalacji go usuwasz Przy instalacji systemd lecisz po kolei z wykonaniem i usuwasz wszystko. Jak jest systemd to nic nie potrzebujesz, katalog ma być pusty, a wszystko ma sie wykonać. Tak naprawdę to jest stosunkowo proste, zwykłe składowanie co powinno się było wykonać we wszelkich postach. Nawet do wykonania przez administratora ręcznie... (cat * | sh) Jakby to dobrze pomyśleć to tak naprawdę to mógłby być ogólny mechanizm... Zmieni się koncepcja i co z plikami co tam już leżą? Wystarczy znacznik wersji (np. wersja makr rpm) dać na początku pliku. Czy się go użyje czy nie - mało istotne, będzie jakiś wyznacznik z kiedy jest taki zestaw komend. To by załatwiło wszystkie problemy i było robione na poziomie makr rpm-a, Bardziej skomplikowane makra też mnie nie pociągają… ...a kogo pociągają...? -- pozdr. Paweł Gołaszewski jid:bluesatjabberdotgdadotpl -- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free.___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Tue, 24 Jan 2012, Tomasz Pala wrote: 0. olewamy sprawę, jak ktoś zmieni inita, to ten mu uruchomi usługi SysV; będzie musiał sobie ręcznie włączyć co chce mieć pod systemd. No nie - to nie jest fajne, system staje się niedeterministyczny, zależny MOCNO od kolejności instalacji. 1. Requires(post,preun): systemd-units. To jest najczystsze rozwiązanie - 300 KB dzisiaj nie stanowi problemu na większości maszyn. A nie będzie problemów i sypania błędami dotyczących komunikacji z dbusem? Sprawdziliście jak to się zachowa przy jego całkowitym braku? 2. Magia przy instalacji systemd-units, która włączy wcześniej zainstalowane paczki. 3. Odłożenie komend z makr do wykonania później. Może wystarczy 'systemctl enable /lib/systemd/system/*.service'? No nie, to nie jest dobre. -- pozdr. Paweł Gołaszewski jid:bluesatjabberdotgdadotpl -- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free.___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Tue, Jan 24, 2012 at 19:46:48 +0100, Pawel Golaszewski wrote: 0. olewamy sprawę, jak ktoś zmieni inita, to ten mu uruchomi usługi SysV; będzie musiał sobie ręcznie włączyć co chce mieć pod systemd. No nie - to nie jest fajne, system staje się niedeterministyczny, zależny MOCNO od kolejności instalacji. A czym się różni uruchomienie przez SysV od uruchomienia przez unit? Niczym istotnym - funkcjonalność pozostaje. A zależność jest trywialna do opisania: systemd uruchamia natywnie usługi zainstalowane po nim. Można nawet stwierdzić, że to feature a nie bug: zamiana init na systemd nie zmienia automatycznie konfiguracji startu systemu, więc jest operacją niskiego ryzyka. Administrator może później zatrzymać usługę SysV, uruchomić z ręki unit i jeśli stwierdzi, że działa - to go włączyć. 1. Requires(post,preun): systemd-units. To jest najczystsze rozwiązanie - 300 KB dzisiaj nie stanowi problemu na większości maszyn. A nie będzie problemów i sypania błędami dotyczących komunikacji z dbusem? Sprawdziliście jak to się zachowa przy jego całkowitym braku? Nie dam sobie teraz nic uciąć, ale enable/disable z tego co pamiętam (bo CHYBA kiedyś sprawdzałem) nie wymaga dbusa ani nic - przecież ta funkcja powinna działać nawet z poziomu emergency.target. 2. Magia przy instalacji systemd-units, która włączy wcześniej zainstalowane paczki. 3. Odłożenie komend z makr do wykonania później. Jak już wspomniałem - oba te warianty są wadliwe, gdyż mogą aktywować usługi wyłączone chkconfigiem. W wariancie zerowym nie dzieje się nic nieprzewidywalnego, wariant pierwszy dodaje jedynie pewne zużycie dysku. Dlatego moje zdanie to po prostu S: systemd-units; bez rzeźbienia. A żaden z wariantów i tak nie obsługuje sytuacji, w której ktoś ma lokalnie zmienioną kolejność SysV. -- Tomasz Pala go...@pld-linux.org ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Tue, Jan 24, 2012 at 07:59:41PM +0100, Tomasz Pala wrote: On Tue, Jan 24, 2012 at 19:46:48 +0100, Pawel Golaszewski wrote: [...] 1. Requires(post,preun): systemd-units. To jest najczystsze rozwiązanie - 300 KB dzisiaj nie stanowi problemu na większości maszyn. A nie będzie problemów i sypania błędami dotyczących komunikacji z dbusem? Sprawdziliście jak to się zachowa przy jego całkowitym braku? Nie dam sobie teraz nic uciąć, ale enable/disable z tego co pamiętam (bo CHYBA kiedyś sprawdzałem) nie wymaga dbusa ani nic - przecież ta funkcja powinna działać nawet z poziomu emergency.target. A jak się w przyszłości zmieni i bez dbusa czy udeva przestanie działać? systemd w założeniach wymaga obu, więc autor może uznać, że na ich istnieniu może polegać. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Tue, Jan 24, 2012 at 21:16:01 +0100, Jakub Bogusz wrote: Nie dam sobie teraz nic uciąć, ale enable/disable z tego co pamiętam (bo CHYBA kiedyś sprawdzałem) nie wymaga dbusa ani nic - przecież ta funkcja powinna działać nawet z poziomu emergency.target. A jak się w przyszłości zmieni i bez dbusa czy udeva przestanie działać? systemd w założeniach wymaga obu, więc autor może uznać, że na ich istnieniu może polegać. Linkowanie? Wtedy sam poprę wyrzucenie całego systemd do śmietnika. Ale nie widzę realnego zagrożenia, aby systemCTL mógł odmówić współpracy z init=/bin/sh. -- Tomasz Pala go...@pld-linux.org ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Tue, 24 Jan 2012, Tomasz Pala wrote: 0. olewamy sprawę, jak ktoś zmieni inita, to ten mu uruchomi usługi SysV; będzie musiał sobie ręcznie włączyć co chce mieć pod systemd. No nie - to nie jest fajne, system staje się niedeterministyczny, zależny MOCNO od kolejności instalacji. A czym się różni uruchomienie przez SysV od uruchomienia przez unit? Niczym istotnym - funkcjonalność pozostaje. Przeczytaj jeszcze raz: w zależności od kolejności instalowania dostaniesz zupełnie inaczej działający system. W przypadku naszego obecnego systemu (SysV) nie ma zupełnie takiego zagrożenia, mając listę pakietów otrzymuję taki sam podstawowy system. Taka sytuacja jest IMO kompletnie niedopuszczalna i do tej pory nie miała u nas miejsca. 1. Requires(post,preun): systemd-units. To jest najczystsze rozwiązanie - 300 KB dzisiaj nie stanowi problemu na większości maszyn. A nie będzie problemów i sypania błędami dotyczących komunikacji z dbusem? Sprawdziliście jak to się zachowa przy jego całkowitym braku? Nie dam sobie teraz nic uciąć, ale enable/disable z tego co pamiętam (bo CHYBA kiedyś sprawdzałem) nie wymaga dbusa ani nic - przecież ta funkcja powinna działać nawet z poziomu emergency.target. Jaki sens ma wogóle wydzielenie units do osobnego pakietu? 2. Magia przy instalacji systemd-units, która włączy wcześniej zainstalowane paczki. 3. Odłożenie komend z makr do wykonania później. Jak już wspomniałem - oba te warianty są wadliwe, gdyż mogą aktywować usługi wyłączone chkconfigiem. Jeżeli nie masz jakiejś procedury przejścia konfiguracji chkconfiga to ten temat nie istnieje (proszę, nie mów o ręcznym grzebaniu, to można zrobić na 1-2 maszynach). Równie dobrze można by było odwrócić temat: jak masz coś pozmieniane to przy przejściu na systemd sobie tak samo zrobisz. A żaden z wariantów i tak nie obsługuje sytuacji, w której ktoś ma lokalnie zmienioną kolejność SysV. Bo nigdy nie będzie. 100% automatyczne przejście nie jest chyba możliwe, fedory i inne też chyba tego nie obsługują... -- pozdr. Paweł Gołaszewski jid:bluesatjabberdotgdadotpl -- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free.___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Tuesday 24 of January 2012, Tomasz Pala wrote: On Tue, Jan 24, 2012 at 15:23:46 +0100, Jacek Konieczny wrote: Czyli zostały dwie opcje: W zasadzie trzy: 0. olewamy sprawę, jak ktoś zmieni inita, to ten mu uruchomi usługi SysV; będzie musiał sobie ręcznie włączyć co chce mieć pod systemd. Mi się to rozwiązanie podoba najbardziej. Świadoma migracja przez administratora i świadome aktywowanie usług pod systemd. -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Wed, 25 Jan 2012, Arkadiusz Miśkiewicz wrote: On Tuesday 24 of January 2012, Tomasz Pala wrote: On Tue, Jan 24, 2012 at 15:23:46 +0100, Jacek Konieczny wrote: Czyli zostały dwie opcje: W zasadzie trzy: 0. olewamy sprawę, jak ktoś zmieni inita, to ten mu uruchomi usługi SysV; będzie musiał sobie ręcznie włączyć co chce mieć pod systemd. Mi się to rozwiązanie podoba najbardziej. Świadoma migracja przez administratora i świadome aktywowanie usług pod systemd. To jest bardzo kiepski pomysł. Bo jak kiedyś SysVinit wyleci to dostaniesz system w którym nic się nie uruchamia, albo będziesz musiał poprawiać milion pakietów, żeby włączały usługi systemd. Najlepszym rozwiązaniem jest R:systemd-units i (warunkowe) włączanie usług systemd w post, np coś w stylu: if init = /sbin/init chkconfig --list service | grep -qs on %systemd_post service else %systemd_post service fi Prościej jest wyłączyć pojedyncze, niechciane usługi niż włączać wszystko. -- Jan Rękorajski| ALL SUSPECTS ARE GUILTY. PERIOD! bagginsatmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Fri, Jan 20, 2012 at 13:24:07 +0100, Bartlomiej Zimon wrote: No dobra ale jest jeszcze jeden temat - dodalem kdm.service (paczka kde4-kdm-systemd) ale aktualizacja powoduje restart kdm a tego nie chcemy jak ten temat rozwiazac? nowe/uaktualnione makro w macros.build? Hmm? Co tam kdm, sprawdzał ktoś jak się zachowa ssh? -- Tomasz Pala go...@pld-linux.org ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Migracja serwisów SysV - systemd
Pytanie do speców od systemd - czy jest jakaś metoda, a jeśli tak to jaka, na mało bolesną konwersję serwisów z SysV do systemd? Na przykład nfs serwer, w wersji SysV ma (w dużym uproszczeniu) jeden skrypt startowy zwany nfsd starujący kilka rzeczy, a pod systemd te kilka rzeczy ma, każde z nich, swoje własne serwisy. Czy da się teraz spowodować automagicznie, żeby systemd nie próbował odpalać i wersji SysV i swoich natywnych serwisów? -- Jan Rękorajski| ALL SUSPECTS ARE GUILTY. PERIOD! bagginsatmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
2012/1/19 Jan Rękorajski bagg...@pld-linux.org: Pytanie do speców od systemd - czy jest jakaś metoda, a jeśli tak to jaka, na mało bolesną konwersję serwisów z SysV do systemd? Na przykład nfs serwer, w wersji SysV ma (w dużym uproszczeniu) jeden skrypt startowy zwany nfsd starujący kilka rzeczy, a pod systemd te kilka rzeczy ma, każde z nich, swoje własne serwisy. Czy da się teraz spowodować automagicznie, żeby systemd nie próbował odpalać i wersji SysV i swoich natywnych serwisów? Jeśli jakiś z serwisów systemd będzie się nazywał tak jak ten SysV to go przykryje i będzie uruchomiony tylko ten z systemd. Możesz też zrobić symlink ln -s jakis-service-systemd.service /lib/systemd/system/nazwa-serwisu-SysV.service Inne rozwiązanie to zamaskowanie serwisu SysV ln -s /dev/null /lib/systemd/system/nazwa-serwisu-SysV.service -- Artur Frysiak ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Thu, Jan 19, 2012 at 12:39:28 +0100, Jan Rękorajski wrote: Na przykład nfs serwer, w wersji SysV ma (w dużym uproszczeniu) jeden skrypt startowy zwany nfsd starujący kilka rzeczy, a pod systemd te kilka rzeczy ma, każde z nich, swoje własne serwisy. Czy da się teraz spowodować automagicznie, żeby systemd nie próbował odpalać i wersji SysV i swoich natywnych serwisów? http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/systemd/systemd.spec?r1=1.75r2=1.76 W ten sposób maskujesz (/dev/null = wyłączasz bezwzględnie, nawet z ręki nie uruchomisz) unit o danej nazwie. Taka blokada lokalnie (a nie na poziomie dystrybucji) powinna znajdować się w /etc/systemd/coś. Albo jeden z tych NFS-owych unitów systemd musi nazywać się tak samo, jak w SysV - zamaskuje sobą; to rozwiązanie jest logiczniejsze, chyba że już autorzy nfsd wymyślili inne nazwy dla swoich subservice'ów (tak jak console i random jest już w samym systemd, ale inaczej nazwane - jeszcze muszę spróbować maskowania odpowiednimi unitami). -- Tomasz Pala go...@pld-linux.org ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
