users - pomysł do przemyslenia....

[Jakub Bogusz]

On Thu, May 15, 2003 at 12:45:09PM +0200, Rafal Cygnarowski wrote:
> W liście z czw, 15-05-2003, godz. 12:22, Jakub Bogusz pisze: 
[...]
> > > - 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),

To trzeba go i tak w końcu poprawić.

> ale sprawdzac powinien podczas zakladania
> i podczas sprawdzenia wypisac nieprawidlowosci

Ale wtedy (jeśli użytkownik jest właścicielem plików z pakietu) pliki
się potworzą ze złymi uidami, po poprawieniu uida w passwd wszystko się
powali.

> > > - 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)

Czyli te pliki mają służyć tylko do kontroli istniejących użytkowników?

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

Czyli znowu to samo...

Czy ktoś mógłby się zapytać o to Jeffa - czy uznaje to za błąd
i zamierza poprawić, ew. zaakceptować patcha?
Podobnie z instalowaniem pakietów wymagających pakietu, którego
instalacja nie powiodła się na etapie %pre w tej samej transakcji.
Te dwie rzeczy najbardziej dokuczają korzystającym z pakietów (nie tylko
developerom).


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