Obsoletes czy nie obsoletes

[Jakub Bogusz]

On Thu, Aug 21, 2003 at 10:28:39PM +0200, Paweł Gołaszewski wrote:
> On Sat, 16 Aug 2003, Radoslaw Zielinski wrote:
[...]
> > >> - co z userdel http w %postun ?
> > > To trzeba rozwiązać bardziej ogólnie... Pakiety z użytkownikami to
> > > przesada; ale jakiś mechanizm śledzenia pakietów używających
> > > użytkowników/grup w rpm-ie (może być przy pomocy osobnych skryptów,
> > > bez ruszania kodu) by się przydał.
> > [...]
> > 
> > Mnie się ten pomysł podoba.  Widziałbym to np. tak:
> > 
> > Baza: /var/lib/rpm/service-users.db, format: "<user>:<uid>:<usługi>",
> > gdzie poszczególne usługi byłyby oddzielone przecinkami.  Analogicznie
> > /usr/lib/rpm/service-groups.db.
>   ^^^^^
> chyba var :)

A to zależy, czy to baza aktualnego stanu użytkowników, czy wszystkich
potencjalnych dla wszystkich dystrybucyjnych pakietów.

> > Międzymordź: /usr/lib/rpm/<cośtam>, uruchamiany w dwóch trybach,
> > rejestrowania i wyrejestrowywania;
> 
> Nie wiem czy nie powinna powstać 3 tryb, czyli check - sprawdzanie 
> nieużywanych userów.

Oraz używanych nieistniejących oraz zgodności danych z oczekiwanymi
przez aplikację.

> > np (nie mam pomysłu na nazwę):
> > 
> >  # <cośtam> -R -u http:51 -s apache # rejestracja usera http dla apache
> >  # <cośtam> -R -g http:51 -s apache # rejestracja grupy http dla apache
> > 
> > Jeśli zwróci 0, to trzeba założyć, jeśli 1, już jest.  Wyrejestrowanie:
> > 
> >  # <cośtam> -U -u http:51 -s apache
> >  # <cośtam> -U -g http:51 -s apache
> > 
> > Jeśli zwróci 0, można usunąć.  Podawanie/sprawdzanie uid/gid mogłoby być
> > opcjonalne; te pola mogłyby istnieć tylko dla informacji administratora.

Same skrypty mogą od razu użytkowników zakładać i usuwać.
Przy okazji uruchomić update-db i kopnąć nscd w razie potrzeby (chociaż
to powinno być w samych {user,group}{add,del} - o ile pierwsze w końcu
chyba zostało popoprawiane, to drugie nie).

Sprawdzanie uid/gid - chodzi o aktualne warunki w %pre?
Można by zrobić z tego opcję w sysconfig (abort/warn/ignore, z domyślnym
abort) - tylko trzeba pamiętać, że aktualnie część pakietów używa
liczbowych uidów/gidów - więc może być problem...

Komunikaty o zakładaniu/usuwaniu użytkowników zrobiłbym co najwyżej
opcjonalne (mnie one drażnią - jak i inne przejawy zbędnej gadatliwości
skryptów przy instalacji pakietów - informacje o dodawaniu/usuwaniu
użytkowników/grup i tak idą do logów).

> > Jeśli będzie zgoda na tego typu rozwiązanie (i specyfikacja), to w
> > wolnym czasie napiszę helpera.
> 
> hhhmmm....
> Zastanawiam się czy jednak to nie powinna być gotowa baza userów z 
> osobnego pakietu (jakieś rpm-usersdb). Wydaje mi się, że tak będzie 
> lepiej, w specu będzie tylko np.:
> <cośtam> -U -u http -s apache
> Będzie to rejestrowało użytkownika.
> 
> Całe dane usera będą w bazie usersdb, np. /usr/lib/rpm/(users|group).db. 
> Zmiana usera to będzie jedna korekta w bazie, a nie dłubanie we wszystkich 
> specach.

Tylko te zmiany w bazie wymagają też zmian w systemie (w %pre lub
triggerze nowej wersji pakietu), jeśli pakiet już został zainstalowany.
No i zmiana uida/gida wymaga chown plików należących do danego
użytkownika/grupy i być może modyfikacji plików konfiguracyjnych...

> Teraz pytanie - jak takie rozwiązanie zachowa się w praktyce? Mam na myśli 
> sytuację np.: wymiana http z jednego na drugi.

W porządku - w %pre nowo instalowanego pakietu licznik użycia zostanie
zwiększony do 2[1], w %postun usuwanego zmniejszony do 1 - czyli użytkownik
cały czas będzie istniał.


[1] obojętne, czy będzie reprezentowany przez pojedynczą liczbę, czy np.
listę nazw pakietów

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