Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Strony: 1
Mam kilka pakietów, np. firefox, które po aktualizacji systemu mają pewne problemy z działaniem. W przypadku tego firefox'a konieczne jest utworzenie kilku dodatkowych twardych dowiązań (na potrzeby osobnych profili w AppArmor). Ręczne utworzenie takich dowiązań załatwia sprawę jedynie do momentu aktualizacji pakietu firefox, no bo te pliki z katalogu są zastępowane nowymi i te dowiązania zwyczajnie przestają działać i trzeba je stworzyć na nowo. Czy da radę to jakoś zautomatyzować np. by podczas aktualizacji systemu, apt/aptitude będąc świadom, że aktualizowany jest firefox wykonał przy tym kilka dodatkowych akcji albo też zainicjował skrypt po zakończeniu aktualizacji tego pakietu?
Offline
Zasadniczo od tego są skrypty postinst w pakiecie ;-)
Możesz to obejść wykorzystując opcje w apt.conf:
DPkg::Post-Invoke {"/root/skrypt";};
W skrypcie zrobisz sobie co tylko chcesz..
Offline
No właśnie z tym skryptem to też nie jest tak miło do końca, bo on jest wywoływany po zakończeniu prac apt i pytanie jest jak ustalić czy firefox był aktualizowany czy nie, bo takie usuwanie dowiązań i tworzenie nowych za każdym razem gdy jest update, to jest trochę bez sensu. xD
Offline
Może analiza logów aptitude?
Offline
Można zapisać w pliku wynik np. md5sum pliku wykonywalnego firefoxa i jesli byłby inny to skrypt aktualizowałby linki i tworzył nowy z md5
@gnejusz pompejusz
Z tą analizą logów bardzo dobry pomysł, przecież logi tworzy i apt i dpkg...
Ostatnio edytowany przez andreq (2018-03-28 16:43:51)
Offline
[quote=andreq]Zasadniczo od tego są skrypty postinst w pakiecie ;-)
Możesz to obejść wykorzystując opcje w apt.conf:
DPkg::Post-Invoke {"/root/skrypt";};
W skrypcie zrobisz sobie co tylko chcesz..[/quote]
Nie ma przypadkiem opcji, żeby DPkg do skryptu /root/skrypt przekazywał w zmiennej nazwę instalowanej paczki?
Coś na kształt tego:
https://forums.gentoo.org/viewtopic-t-950062-start-0.html
@Morfilk
Jak będziesz takie kombinacje alpejskie wymyślał, to ani się obejrzysz, a to się na Gen2 skończy. xD
Tu masz przykład ciekawszej zabawy:
https://forums.gentoo.org/viewtopic-p-6584471.html#6584471
Jeszcze sporo przed tobą.
konieczne jest utworzenie kilku dodatkowych twardych dowiązań (na potrzeby osobnych profili w AppArmor)[/quote]
Dziwne rzeczy piszesz.
Instalator zazwyczaj kolejne wersje pakuje w te same katalogi, w których były poprzednie.
Nie lepiej pokombinować z profilem AA?Ostatnio edytowany przez Jacekalex (2018-03-28 16:52:54)
W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem para bellum ;) | Pozdrawiam :)
Offline
Może i sobie instalator pliki ładuje do tego samego katalogu ale jak masz twarde dowiązanie do pliku i ten plik zostanie usunięty (a to się przecie dzieje przy aktualizacji), to dowiązanie odnosi się do starego pliku (do i-node), w przeciwieństwie gdy sobie stworzyłbyś dowiązanie symboliczne, które odwoła cię do pliku w sytuacji gdy taki istnieje. Więc w efekcie masz nowego firefox'a z nowym plikiem /usr/lib/firefox/firefox a obok niego siedzi sobie stara wersja sprzed aktualizacji i chyba nie muszę ci mówić, że próba odpalenia fiefox'a przez takie twarde dowiązanie nie powiedzie się. xD
AppArmor jest w stanie tworzyć profile tylko w oparciu o dowiązania twarde i mogę stworzyć sobie 10 takich dowiązań i mieć 10 różnych profili firefox'a (w zależności który twardy link się aktywuje) i każdy profil może mieć inne prawa dostępu do plików i te profile mogą być od siebie odseparowane. Na symbolicznych dowiązaniach AppArmor nie operuje, tzn. ostatecznie zostanie i tak odpalony ten program (po nazwie pliku), na który wskazuje link. To taka różnica jest w mechanice działania. Dlatego próba zmiany czegokolwiek w profilu AppArmor'a nic nie da. xD
Nie ma przypadkiem opcji, żeby DPkg do skryptu /root/skrypt przekazywał w zmiennej nazwę instalowanej paczki?[/quote]
Raczej jest tylko pytanie jak ją wyciągnąć. xDOstatnio edytowany przez morfik (2018-03-28 17:53:22)
Offline
U mnie FF kompilowany zawsze siedzi w:
/usr/lib64/firefox/firefox
a binarka firefox-bin jako:
/opt/firefox/firefox
więc nie za bardzo ogarniam ten problem z dowiązaniami.
Jak wytargać zmienne do których skrypt ma dostęp?
Sprawdź, czy u Ciebie taki myk zadziała:
env >/tmp/env.txt
cat /tmp/env.txt
Z resztą proces /root/skrypt może swoje zmienne obejrzeć w pliczku:
/proc/self/environ
a argumenty ma w:
/proc/self/cmdline
Także nie jesteś taki strasznie bezradny w sprawdzaniu zmiennych.
Co najmniej jedną zmienną możesz wytargać od razu:
https://unix.stackexchange.com/questions/172492/dpkg-env-variable-dpkg-hook-action-is-not-set-in-hook-script
W
man dkpg
masz opisanych kilka innych.
Ostatnio edytowany przez Jacekalex (2018-03-28 19:05:39)
Offline
więc nie za bardzo ogarniam ten problem z dowiązaniami.[/quote]
No bo ja mam kilka profili firefox'a i każdy z nich by mieć osobny profil i co za tym idzie inne reguły w AppArmor musi używać innego pliku wykonywalnego, a najprościej jest to zrobić przez stworzenie twardych dowiązań. xD Po aktualizacji firefox'a działa mi tylko jeden profil, ten który się odwołuje do pliku /usr/lib/firefox/firefox , pozostałe zaś przestają działać bo są oparte o hard linki, które nie odwołują się do tego i-node, do którego odwołuje się nowy plik /usr/lib/firefox/firefox , który został umieszczony na dysku po aktualizacji pakietu. Dlatego wymagana jest aktualizacja tych hard linków i trzeba je usunąć i stworzyć na nowo, a do tego mi jest właśnie potrzebny jakiś automat, który to zrobi, gdy ten pakiet firefox'a będzie aktualizowany. No prościej to już nie uda mi się tego wytłumaczyć. xD
A w zmiennych to nic ciekawego nie ma co by było w stanie zidentyfikować, że firefox był aktualizowany.
Offline
A w zmiennych to nic ciekawego nie ma co by było w stanie zidentyfikować, że firefox był aktualizowany.[/quote]
No to witamy w Gen2, albo pisz łatkę na dpkg, żeby w zmiennej nazwę pakietu przekazywał.
Względnie jakaś lista mailingowa dpkg, weź ich tam pomolestuj troszkę, żeby podciągnęli dpkg do poziomu portage w temacie zmiennych.
Apt i DPKG potrafią pożądaną nazwę do loga zapisać, czyli gdzieś w brzuchu ją trzymają, tylko na razie nie chcą się tą wiadomością podzielić z twoim skryptem.
To bardzo nieładnie z ich strony, więc możesz zgłaszać uzasadnione skargi i zażalenia. xD
W tym celu trzeba się zapisać na listę:
debian-dpkg@lists.debian.org
Sznurek:
https://lists.debian.org/debian-dpkg/Ostatnio edytowany przez Jacekalex (2018-03-28 19:59:27)
W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem para bellum ;) | Pozdrawiam :)
Offline
Ja zagadałem na debian-users i tam mi powiedzieli, że to co ja chce zrobić to się nie da via dpkg/apt ale można zaprogramować trigger (man deb-triggers) i stworzyć malutką paczuszkę, która ten trigger wgra do systemu i będzie patrzeć na pewne pliki i jak one będą ulegać zmianie (aktualizacja pakietu), to ten trigger będzie aktywowany i wykonywał pewne akcje. Przynajmniej tak to ma działać w teorii. xD
Się pobawię tym trochę i zobaczę co z tego wyjdzie ale jak się uda to mi więcej w sumie nic nie będzie potrzebne.
Offline
Łatka dla dpkg, żeby przy każdej paczce deb wypluwał do do {pre|post}-invoke nazwę paczki deb którą aktualnie molestuje, to byłyby ze dwie linijki w kodzie (i tak program tą nazwę przetwarza przecież), więc na dpkg-dev mogą to załatwić w 3 minuty.
Oczywiście potem to musi przejść skomplikowaną drogę pakietu w Debianie, ale przynajmniej za 3 lata miałbyś problem z głowy. xD
Chyba żebyś w skrypcie wyciągał PID dpkg (parent-pid), potem parsował np
/proc/$DPKG_PID/cmdline
żeby wyciągnąć , co potrzeba.
Tak można zrobić obejście na te trzy latka, zanim latka uzgodniona w dpkg-dev trafi pod strzechy.
Po prostu "nie da się dpkg" to nie wina niewykonalności, tylko tego, ze dpkg nie przekazuje jednej zmiennej do skryptu.
Informuje przez zmienną, co aktualnie robi, ale nie informuje z jaką paczką to robi.
EDIT:
Chyba znalazła się brakująca zmienna:
Normalnie ustawiane przez dpkg w zmiennej środowiskowej
DPKG_MAINTSCRIPT_PACKAGE skryptu opiekuna pakietu, wskazując
nazwę pakietu, do którego należy skrypt (jest to wartość używana
domyślnie).[/quote]
http://manpages.ubuntu.com/manpages/trusty/pl/man1/dpkg-trigger.1.htmlOstatnio edytowany przez Jacekalex (2018-03-28 21:25:38)
W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem para bellum ;) | Pozdrawiam :)
Offline
W sumie to ten przypadek z linkami to się udało załatwić bardzo prosto. Wystarczyło policzyć ile linków ma plik firefox'a po aktualizacji:
# ls -l /usr/lib/firefox/firefox | cut -d ' ' -f 2 1
Czyli jest jeden link a powinno być ich tyle ile jest twardych dowiązań. Znając oczekiwaną ilość linków można w Post-Invoke dodać skrypt, w którym zaraz na początku można dać warunek sprawdzający ile tych linków faktycznie ten plik ma i jeśli firefox będzie aktualizowany, to ta liczba znów spadnie do 1 i będzie wiadomo wtedy, że trzeba te linki utworzyć na nowo i to właśnie robi pozostała część skryptu.
Tak czy inaczej te triggery to też sobie obadam bo one są i tak chyba bardziej uniwersalne, choć póki co mi nie działa ten co zrobiłem. xD
Offline
No i trigger też ogarnięty już:
# apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
firefox
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/41.6 MB of archives.
After this operation, 3,072 B disk space will be freed.
Do you want to continue? [Y/n]
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
(Reading database ... 248269 files and directories currently installed.)
Preparing to unpack .../firefox_59.0.2-1_amd64.deb ...
Unpacking firefox (59.0.2-1) over (59.0.1-1) ...
Processing triggers for mime-support (3.60) ...
Processing triggers for desktop-file-utils (0.23-2) ...
Setting up firefox (59.0.2-1) ...
Processing triggers for man-db (2.8.2-1) ...
Processing triggers for hicolor-icon-theme (0.17-2) ...
Processing triggers for [b]firefox-trigger[/b] (1.0) ...[/quote]
I test:# stat firefox
File: firefox
Size: 195608 Blocks: 384 IO Block: 4096 regular file
Device: fe05h/65029d Inode: 101 [b]Links: 3[/b]
Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2018-03-28 23:07:45.000000000 +0200
Modify: 2018-03-27 01:29:16.000000000 +0200
Change: 2018-03-28 23:07:56.031129691 +0200
Birth: -[/quote]
W sumie te triggery nawet nie są takie skomplikowane. xDOffline
To pochwal się treścią/konfiguracją tego triggera, skoro to takie proste, to opisać pewnie też prosto. xD
Chociaż najbardziej, to się przyda do zabawy z IMA/EVM.
https://wiki.gentoo.org/wiki/Extended_Verification_Module
Ostatnio edytowany przez Jacekalex (2018-03-29 01:37:07)
Offline
No to trzeba stworzyć taką paczkę:
https://app.box.com/s/up6rswi80a0ox05gmky73sswad7wlbtp
To są pliki źródłowe, gdzie w zasadzie jest tylko katalog debian/ a w nim jest kilka plików wygenerowanych przez dh_make --native no i dwa pliki w zasadzie dodane i reszta dostosowana pod kątem realiów. Te dwa dodatkowe pliki to firefox-trigger.postinst oraz firefox-trigger.triggers . W firefox-trigger.triggers się definiuje pliki/katalogi, które mają być objęte przez dodawany trigger. Ja tam dałem jedynie plik /usr/lib/firefox/firefox , bo to jego zmiana mnie najbardziej interesuje. Jeśli teraz będzie instalowana/aktualizowana jakaś paczka, która ma w swoich plikach coś co pasuje do tej ścieżki, a ma póki co jedynie firefox, to za każdym razem gdy ta paczka będzie instalowana, to zostaną wywołane akcje określone przez trigger, a te z kolei są dodane do firefox-trigger.postinst . W zasadzie to ten plik się niczym nie różni od szkieletu, za wyjątkiem dodania warunku triggered i kilku poleceń. I to cała filozofia triggerów. xD
Ostatnio edytowany przez morfik (2018-03-29 01:58:45)
Offline
Rzeczywiście proste to.
To jak, tworzysz katalog debian, w nim dwa pliczki, i potem
dh-make debian/
a potem wczytujesz poleceniem w stylu:
dpkg-triggers paczuszka
Poza tym ciekawe, czy można mu podać globalnie wszystkie paczki do obróbki, nie tylko jedna, ale np ścieżki:
/usr/{bin,sbin}/ /{bin,sbin}/ /opt/ /etc/ /lib{,32,64}/ /usr/lib{,32,64}/
Ostatnio edytowany przez Jacekalex (2018-03-29 02:41:07)
Offline
Strony: 1
Time (s) | Query |
---|---|
0.00013 | SET CHARSET latin2 |
0.00005 | SET NAMES latin2 |
0.00094 | SELECT u.*, g.*, o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='18.119.159.196' WHERE u.id=1 |
0.00186 | REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '18.119.159.196', 1732694493) |
0.00063 | SELECT * FROM punbb_online WHERE logged<1732694193 |
0.00061 | SELECT topic_id FROM punbb_posts WHERE id=318724 |
0.00112 | SELECT id FROM punbb_posts WHERE topic_id=30382 ORDER BY posted |
0.00062 | SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=30382 AND t.moved_to IS NULL |
0.00005 | SELECT search_for, replace_with FROM punbb_censoring |
0.00098 | SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=30382 ORDER BY p.id LIMIT 0,25 |
0.00079 | UPDATE punbb_topics SET num_views=num_views+1 WHERE id=30382 |
Total query time: 0.00778 s |