users - pomysł do przemyslenia....

[Rafal Cygnarowski]

W liście z czw, 15-05-2003, godz. 12:22, Jakub Bogusz pisze: 

> > Do zadan tego polecenia nalezaloby:
> > - sprawdzenie, czy istnieja potrzebni uzytkownicy i grupy
> 
> Rozumiem, że tylko kontrolnie - bo muszą istnieć przed instalacją
> pakietu.
tak, dlatego ponizej bylo %pre w pakiecie

> > - czy dany uzytkownik/grupa nie stal sie zbedny
> > - czy uzytkownik/grupa ma poprawny id
> 
> To za późno... przed instalacją pakietu też trzeba sprawdzać.
tego sie nie da uniknac (rpm nie przerywa instalacji, gdy skrypty
zwroca bledy, wiec lepiej bedzie tylko wypisywac komunikaty),
ale sprawdzac powinien podczas zakladania
i podczas sprawdzenia wypisac nieprawidlowosci

> > - do katalogu /usr/share/users/wish wpadalyby "prosby" od pakietow o
> > uzytkownikow/grupy w postaci plikow: <nazwa-pakietu>.{usr,grp} z nazwami
> > uzytkownikow/grup
> 
> Trochę przekombinowane chyba... wystarczyłoby parę plików.
> I tak nie można dostarczać informacji o potrzebnym użytkowniku przez
> plik (patrz niżej).
Jestes w bledzie. Patrz nizej.

> > - potrzebny bylby tylko skrypt %pre, ktory tworzylby uzytkownika tuz
> > przed instalacja pakietu, jesli taki uzytkownik nie istnieje (i
> > oczywiscie grupy do ktorych nalezy tftp, jesli te nie istnieja):
> > %pre
> > /usr/sbin/manage_users -c user-tftp
> > - zawieralby pliki /usr/share/users/wish/<nazwa-pakietu>.{usr,grp} z
> > nazwami grup i userow, ktorych pakiet potrzebuje
> 
> To nie zadziała - w %pre nie ma jeszcze rozpakowanych plików z pakietu.
zadziala, poniewaz informacje o uzytkownikach ma pakiet users, a nie
pakiet, ktory uzytkownika wymaga. Pakiet instalowany jedynie zostawia
"semafor" w postaci pliku w katalogu /usr/share/users/wish (dzieki temu
nie ma plikow, ktore plywaja bez wiedzy o nich w rpmowej bazie)

> > 3) Restarty
> > Najlepszym przykladem bedzie chyba apache :)
> > Zakladam, robimy mass aktualizacje i nie zatrzymalismy sobie apacha.
> > Dramat. 15 min z glowy na restartach. A moze wygladac to tak (bez
> > wzgledu na to czy bedzie to instalacja, czy upgrade:
> > 
> > %preun
> > tutaj tradycyjnie (zatrzymanie uslugi)
> > 
> > %post
> > touch /var/lib/runwish/start-proftpd
> > 
> > Po skonczonej instalacji odpalany bylby skrypt pld-postinstall-script,
> > ktory na podstawie plikow z /var/lib/runwish zrestartuje usluge, lub
> > wypisze, ze trzeba cos wystartowac. Dodatkowa zaleta jest taka, ze
> > nareszcie nie zgubią sie te komunikaty gdzies "w gorze" przy wiekszych
> > updatach...
> 
> A to jest dobry pomysł.
> I chodzi nie tylko o czas uaktualniania i przerwy w dostępności usługi
> - w przypadku uaktualniania php do nowej wersji po php-common całość
> potrafiła się wyłożyć i już trzeba było apache ręcznie podnosić.

a tu jest jeszcze jeden myk jesli chodzi o php: sprobuj odinstalowac php
w calosci - php-common jest zbyt wczesnie odinstalowywany. To jest
rzecz, o ktorej juz pisalem: rpm nie radzi sobie z Req(postun) - nadal
nie wiem dlaczego i pewnie szybko sie nie dowiem (musze pomeczyc
sap-a)..

pozdrawiam,
pascalek
-- 
Rafal Cygnarowski
rafi w pers.pl