Obsoletes czy nie obsoletes

[Paweł Gołaszewski]

On Sat, 23 Aug 2003, Jakub Bogusz 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.

To tutaj rozumiem jako baza stanu aktualnego.

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

Może faktycznie to będzie prostsze...

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

Poprawić u źródła...

> Sprawdzanie uid/gid - chodzi o aktualne warunki w %pre?

Mniej więcej.

> Można by zrobić z tego opcję w sysconfig (abort/warn/ignore, z domyślnym
> abort) -

O so chosi?

> tylko trzeba pamiętać, że aktualnie część pakietów używa liczbowych
> uidów/gidów - więc może być problem...

To może być błąd/niedoróbka w nich.

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

eee - ja je lubię :)
W jaki sposób zrobisz je opcjonalne? Jakiś config rpm-a?

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

hhhmm... to racja.
Ale sytuacja jest identyczna jeżeli pakiet sam rejestruje się w bazie... 
Tego chyba nigdy nie unikniesz, niestety.

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

Dobra - tylko co jeżeli między %pre a %post instalacja zostanie 
przerwana/wywali się? Nie będzie można usunąć pakietu.

-- 
pozdr.  Paweł Gołaszewski 
---------------------------------
worth to see: http://www.againsttcpa.com/
CPU not found - software emulation...