dodawanie i usuwanie grup w pakietach

[Tomasz Kłoczko]

On Thu, 8 May 2003, Tomasz Kłoczko wrote:
[..]
> ŁTFGO (?) :|
   ^ s/T/D/ .. oczywiśćie ;>

> Idę coś zjeść i biorę sobie na deser wydruk powyższego bo coś mi tu nie pasuje :>
> Czyżbym coś jeszcze przeoczył ? :>

Ano przeoczyłem .. brakowało w tftp.spec -n tftpd przy triggerach przez co 
lądowały one nie w tftpd tylko w tftp 8>

Teraz jest już pełna symeria zachowań ale nadal jakoś działa to nie tak 
jak by intuicja nakazywała/chchała :) .. choć jest w tym pewna 
konsekwencja i logika:

Egzample:

---

# rpm -U tftpd-0.17-21.i686.rpm 
*** post tftpd.
Generating /etc/rlinetd.conf for rlinetd...........................[ ZROBIONE ]
Reload rlinetd service configuration...............................[ ZROBIONE ]
*** triggerin in utftpd for tftpd
*** triggerin in tftpd for utftpd
*** triggerun in utftpd for tftpd
*** triggerun in tftpd for utftpd
*** postun utftpd.
Zatrzymywanie uslugi rlinetd.......................................[ ZROBIONE ]
Generating /etc/rlinetd.conf for rlinetd...........................[ ZROBIONE ]
Uruchamianie uslugi rlinetd........................................[ ZROBIONE ]
Removing user tftp.
*** triggerpostun in tftpd for utftpd
Adding user tftp UID=15.
Zatrzymywanie uslugi rlinetd.......................................[ ZROBIONE ]
Generating /etc/rlinetd.conf for rlinetd...........................[ ZROBIONE ]
Uruchamianie uslugi rlinetd........................................[ ZROBIONE ]

--- i w drugą stronę ..

# rpm -U utftpd-0.2.4-13.i686.rpm -v
Preparing packages for installation...
utftpd-0.2.4-13
*** post utftpd.
Zatrzymywanie uslugi rlinetd.......................................[ ZROBIONE ]
Generating /etc/rlinetd.conf for rlinetd...........................[ ZROBIONE ]
Uruchamianie uslugi rlinetd........................................[ ZROBIONE ]
Rebuilding utftpd configuration... done
*** triggerin in tftpd for utftpd
*** triggerin in utftpd for tftpd
*** triggerun in tftpd for utftpd
*** triggerun in utftpd for tftpd
*** postun tftpd.
Zatrzymywanie uslugi rlinetd.......................................[ ZROBIONE ]
Generating /etc/rlinetd.conf for rlinetd...........................[ ZROBIONE ]
Uruchamianie uslugi rlinetd........................................[ ZROBIONE ]
Removing user tftp.
*** triggerpostun in utftpd for tftpd
Adding user tftp UID=15.
Zatrzymywanie uslugi rlinetd.......................................[ ZROBIONE ]
Generating /etc/rlinetd.conf for rlinetd...........................[ ZROBIONE ]
Uruchamianie uslugi rlinetd........................................[ ZROBIONE ]

Na czym polegać ma tu to co mi tu przeszkadza (?) ano to że jak widać
%trigger{in,un} wykonują sie symetrycznie dla obu stron. Logika w tym jest 
tak, że w zamyśle triggery wywoływane są wtedy keidy zmienai się status 
pakietu na który zakąłdany jest trigger .. no i niestety przy takich 
operacjach krzyrzowych jak ta przykładowa rzeczywiscie zmienia sie status 
obu pakietów bo jeden jest właśnie instalwoany a drugi wyinstalowyaany.

Jest nieco gorzej niż by się chciało ale nadal nie beznadziejnie :-)

Rozwiazanie może być takie żeby wykorzystać tu dwa triggery:
- %triggerun do sygnalizowania żeby nie usuwać użytkownika i żeby nie 
  restarttować w %postun całości (co bedzie też wymagało modyfikacji 
  %postun),
- triggerpostun do tego żeby sygnał ściagnać i dopiero tutaj 
  przerestartować całość.

Sygnał między tymi skryptami mówgłbyć byc przekazywany plikiem np. 
/var/run/<metapackage_name>.trigger. Czyli w tym wypadku byłby to plik
/var/run/tftpdaemon.trigger.

W pierwszym momencie jak rozmawiałem o tym z Andrzejem to padł pomysł 
żeby zamiast <metapackage_name> była użyta nazwa użytkownika czyli tftp w 
tym wypadku.

IMHO to troche za wąsko ponieważ np. przy fimngerd występuje podobny
przypadek ale tam tylko trzeba przrestartować rc-inetd i zrobić to
mozliwie mało razy.

W innych przypadkach także może chodzić nie tylko o restart czegos czy nie
usuwanie użytkowbnia co wiele innych operacji. W tym sensie użycie
bardziej ogólnego semafora /var/run/<metapackage_name>.trigger byłoby
bardziej sensowne.

Nie wiem czy lokacja w katalogu /var/run jest do przyjęcia. Ważne że musi 
być w stałej lokacji. Jakby ktoś miał jakis inny pomysł (może osobny 
katalog na operacje triggerów w postaci np. /var/lib/rpm/triggersdir/ 
który należałby do rpm-a ?)

Tak czy inaczej do finalnego rozwiązania jest już blisko :)
Już to co mam teraz daje efekt poprawny, a to o czym jeszcze myslę to żeby 
zredukować ilość restartów przy tego typu operacjach do maks dwuch (teraz 
są trzy :)

koments ?

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*