users - pomysł do przemyslenia....

[Jakub Bogusz]

On Thu, May 15, 2003 at 09:11:35AM +0200, Rafal Cygnarowski wrote:
> Czesc!
> 
> Myslalem nad tym, o czym pisal Andrzej: 'zliczanie pakietow
> wykorzystujących danego usera, grupy' i to o czym pisal Tomek:
> 'minimalizacja restartow'.
> 
> Pomysl:
> Po skonczonej instalacji rpm moglby wywolac polecenie
> pld-postinstall-script. Patch na rpm-a bylby w tym przypadku banalny,
> wrecz jednolinijkowiec.
> 
> Do zadan tego polecenia nalezaloby:
> - sprawdzenie, czy istnieja potrzebni uzytkownicy i grupy

Rozumiem, że tylko kontrolnie - bo muszą istnieć przed instalacją
pakietu.

> - czy dany uzytkownik/grupa nie stal sie zbedny
> - czy uzytkownik/grupa ma poprawny id

To za późno... przed instalacją pakietu też trzeba sprawdzać.

> - czy uzytkownik ma poprawny katalog
> - restart uslugi, jesli zachodzi taka potrzeba
> 
> Jak mogloby wygladac to w praktyce:
> 1) Pakiet users:
> - wymagany przez rpm
> - udostepnialby Proviedes: user-* i group-*
> - dzieki powyzszemu punktowi zaleznosc miedzy users a innymi pakietami
> sprawdzalaby sie do prostego: Requires(pre): user-<nazwa_uzytkownika>
> - zawieralby skrypt manage_users tworzacy i usuwajacy userow/grupy w
> razie potrzeby
> - zawieralby w katalogu /usr/share/users/defs/ pliki z definicjami
> uzytkownikow i grup (nazwy, id, katalogi domowe itd...)
> - 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).

> - manage_users wywolany w pld-postinstall-script (po zakonczonej
> instalacji/update-u/kasowania) sprawdzalby katalog
> /usr/share/users/wish, czy nastapily tam jakies zmiany i na ich
> podstawie kasowal tych uzytkownikow, ktorzy sa zbedni
> 
> 2) Pakiet zalezny od users (np. tftp)
> - Requires(pre): user-tftp
> - zaleznosc Requires: user-tftp wydaje mi sie byc zbedna ze wzgledu na
> zaleznosc rpm-a od users (moge byc w bledzie...)
> - 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.

> 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ć.


-- 
Jakub Bogusz    http://cyber.cs.net.pl/~qboosh/