Śledzenie programów

Kiedy instaluję prosty program, często z niego korzysta make && make installi nie ma nawet celu dezinstalacji .

Jeśli chcę zaktualizować program, czy jest to standardowy protokół, aby założyć, że przepisuje on bezproblemowo stary program?

Jak śledzić te programy; czy większość ludzi po prostu „odpala i zapomina”, a jeśli nie podano celu dezinstalacji, czy muszę ręcznie usunąć wszystko?

Zainstaluj każdy program w dedykowanym drzewie katalogów i użyj Stow lub XStow, aby wszystkie programy pojawiały się we wspólnej hierarchii. Stow tworzy dowiązania symboliczne z katalogu specyficznego dla programu do wspólnego drzewa.

Bardziej szczegółowo wybierz na przykład katalog najwyższego poziomu /usr/local/stow. Zainstaluj każdy program pod /usr/local/stow/PROGRAM_NAME. Na przykład: zainstaluj pliki wykonywalne /usr/local/stow/PROGRAM_NAME/bin, strony podręcznika /usr/local/stow/man/man1itd. Jeśli program używa autoconf, uruchom ./configure --prefix /usr/local/stow/PROGRAM_NAME. Po uruchomieniu make installuruchom stow:

./configure --prefix /usr/local/stow/PROGRAM_NAME
make
sudo make install
cd /usr/local/stow
sudo stow PROGRAM_NAME

A teraz będziesz mieć takie symboliczne linki:

/usr/local/bin/foo -> ../stow/PROGRAM_NAME/bin/foo
/usr/local/man/man1/foo.1 -> ../../stow/PROGRAM_NAME/man/man1/foo.1
/usr/local/lib/foo -> ../stow/PROGRAM_NAME/lib/foo

Możesz łatwo śledzić, jakie programy zainstalowałeś, wyświetlając zawartość stowkatalogu i zawsze wiesz, do którego programu należy plik, ponieważ jest to symboliczne łącze do lokalizacji w katalogu tego programu. Odinstaluj program, uruchamiając, stow -D PROGRAM_NAMEa następnie usuwając katalog programu. Możesz sprawić, że program będzie tymczasowo niedostępny, uruchamiając go stow -D PROGRAM_NAME(uruchom, stow PROGRAM_NAMEaby udostępnić go ponownie).

Jeśli chcesz szybko przełączać się między różnymi wersjami tego samego programu, użyj /usr/local/stow/PROGRAM_NAME-VERSIONjako katalogu programu. Aby zaktualizować wersję 3 do wersji 4, zainstaluj wersję 4, a następnie uruchom stow -D PROGRAM_NAME-3; stow PROGRAM_NAME-4.

Starsze wersje Stow nie wykraczają daleko poza podstawy, które opisałem w tej odpowiedzi. Nowsze wersje, a także XStow (który nie był ostatnio utrzymywany) mają bardziej zaawansowane funkcje, takie jak możliwość ignorowania niektórych plików, lepsze radzenie sobie z istniejącymi dowiązaniami symbolicznymi poza katalogiem stow (np. man -> share/man), Obsługa niektórych konfliktów automatycznie (gdy dwa programy dostarczają ten sam plik) itp.

Jeśli nie masz dostępu do konta root lub nie chcesz go używać, możesz wybrać katalog w katalogu domowym, np ~/software/stow. W takim przypadku dodaj ~/software/bindo swojego PATH. Jeśli mannie znajdzie automatycznie stron podręcznika, dodaj ~/software/mando swojego MANPATH. Dodaj ~/software/infodo swojego INFOPATH, ~/software/lib/pythondo swojego PYTHONPATHitd., W zależności od przypadku.

Możesz użyć checkinstall, aby utworzyć pakiet (pakiety kompatybilne z RPM, Deb lub Slackware). W ten sposób możesz użyć menedżera pakietów distros, aby dodać / usunąć aplikację (ale nie aktualizować)

Używasz checkinstallzamiast make installpolecenia (używając parametru -D dla Deb; -R to RPM, a -S to Slackware):

root@nowhere# ./configure
root@nowhere# make
root@nowhere# checkinstall -D

checkinstall domyślnie skompiluje i zainstaluje pakiet, lub możesz go zbudować tylko bez instalacji.

checkinstall jest dostępny w większości repozytoriów dystrybucji.

W przeważającej części był to powód, dla którego paczki, porty i inne typy menedżerów zapobiegały tego typu zdarzeniom.

Powiedziałbym, że ręczne usuwanie jest jedynym sposobem na ręczną instalację, chyba że ktoś inny zna lepszą odpowiedź na ten temat, o której być może nie wiem.

Jeszcze jedna alternatywa pochodzi ze wskazówek Linux From Scratch :

Większa kontrola i zarządzanie pakietami za pomocą użytkowników pakietów

3 Użytkownicy pakietu
3.1 Wprowadzenie

Podstawową ideę tego schematu można łatwo wyjaśnić. Każdy pakiet należy do określonego „użytkownika pakietu”. Podczas instalowania pakietu kompiluje się i instaluje pakiet jako ten użytkownik pakietu, powodując, że wszystkie zainstalowane pliki są własnością użytkownika pakietu. W rezultacie wszystkie zwykłe zadania zarządzania pakietami można wygodnie realizować za pomocą standardowych narzędzi wiersza poleceń. Proste ls -l <file>powie ci na przykład, do którego pakietu <file>należy, a find -user ...polecenie pozwala wykonać operację na wszystkich plikach należących do określonego pakietu, np. Usunąć je, aby odinstalować pakiet.

Jednak zarządzanie pakietami to nie wszystko, co jest dobre dla użytkowników pakietu. Ponieważ użytkownicy pakietu nie mają praw root, instalacja pakietu jest ograniczona pod względem możliwości. Jedną rzeczą, której użytkownik pakietu nie może na przykład zrobić, jest zastąpienie plików innym użytkownikiem pakietu. Konflikty między różnymi pakietami, które chcą zainstalować plik binarny, bibliotekę lub plik nagłówka o tej samej nazwie, są bardziej powszechne niż mogłoby się wydawać. W przypadku użytkowników pakietu nigdy nie ryzykujesz, że instalacja pakietu B zniszczy pliki z pakietu A w ciszy, bez zauważenia. Każda próba zrobienia tego podczas instalacji pakietu B spowoduje błąd „Odmowa zezwolenia” lub „Operacja niedozwolona”, dzięki czemu masz szansę podjąć odpowiednie kroki. Inną rzeczą, której użytkownicy pakietu nie mogą robić, jest instalowanie plików binarnych root setuid. Decyzja o utworzeniu binarnego katalogu głównego setuid jest również czymś, czego rozsądny administrator nie chce pozostawić twórcy pakietu oprogramowania.

Zwykle konta użytkowników pakietów nie mają prawidłowego hasła, więc tylko użytkownik root może su dla użytkownika pakietu, co zapewnia, że ​​użytkownicy pakietu nie otworzą dodatkowej drogi do systemu i podważą bezpieczeństwo. Ale i tak możesz ustawić hasła, aby zezwolić współadministratorowi, który chcesz mieć możliwość zainstalowania i zarządzania niektórymi pakietami oprogramowania, bez dostępu do faktycznego konta root. Ten współadministrator może na przykład instalować, usuwać, zmieniać dodatkowe biblioteki, które mogą być konieczne dla jego grupy roboczej. Nie byłby jednak w stanie usunąć ani zmodyfikować bibliotek, które do niego nie należą, takich jak libc.

Po tej pierwszej prymitywnej sugestii znalazłem rozwinięty wariant:

crablfs - oparty na użytkownikach system zarządzania pakietami

To crablfsnajnowszy przykład zarządzania pakietami przy użyciu unikatowych identyfikatorów UID i GID do zarządzania pakietami, ale na sourceforge ponownie ewoluuje w ulfs:

uLFS: Twój zarządzalny i wielokrotnego użytku Linux od zera

Dla przyczynowych użytkowników zainstalowanych pakietów myślę, że rozwiązanie LFS dla „użytkowników pakietów” jest lekkie, mniej inwazyjne i eleganckie. W skrócie, zainstalować pakiety w /usr/locallub /home/user/locali zapisuje pliki przy użyciu unikalnych identyfikatorów UID i GID dla każdego pakietu, ale umieścić wszystkie pliki w tradycyjnych miejscach, wspólnych katalogów /usr/local/bin, /usr/local/libjak to jest we wszystkich dystrybucjach Linuksa nurtu ... niedrożność plik i niechciany plik nadpisywania lub usuwanie unika go zgrabna sztuczka na Linuksa wyjaśniona przez Matthiasa S. Benkmanna w more_control_and_pkg_man.txt, która wymaga tylko normalnej manipulacji uprawnieniami do plików i katalogów, na przykład lepkich uprawnień do katalogów, aby uniknąć niechcianych nadpisań plików:

3.3 Grupy

Każdy użytkownik pakietu należy do co najmniej 2 grup. Jedną z tych grup jest grupa „instaluj”, do której należą wszyscy użytkownicy pakietu (i tylko użytkownicy pakietu). Wszystkie katalogi, w których pakiety mogą instalować rzeczy, należą do grupy instalacyjnej. Obejmuje to katalogi takie jak / bin i / usr / bin, ale wyklucza katalogi takie jak / root lub /. Katalogi należące do grupy instalacji zawsze można zapisać w grupie. Byłoby to wystarczające dla aspektów zarządzania pakietami, ale bez dalszego przygotowania nie zapewniłoby to dodatkowego bezpieczeństwa ani kontroli, ponieważ każdy pakiet mógłby zastąpić pliki z innego pakietu (zmiana byłaby widoczna w danych wyjściowych zls -l, chociaż). Z tego powodu wszystkie katalogi instalacyjne otrzymują atrybut sticky. Pozwala to użytkownikom tworzyć nowe pliki oraz usuwać lub modyfikować własne pliki w katalogu, ale plików innych użytkowników nie można modyfikować ani usuwać. W pozostałej części tej podpowiedzi, ilekroć użyty zostanie termin „katalog instalacyjny”, odnosi się on do katalogu należącego do instalacji grupowej, zapisywalny w grupie i lepki. IOW, aby zmienić się <dir>w katalog instalacyjny

chgrp install && chmod g + w, o + t

Dla mnie wygląda to na proste i sprytne rozwiązanie! Użyłem tego schematu w mojej kompilacji LFS i jest to działające rozwiązanie ...

1. Możesz zrobić puste RPM jako przypomnienie.
2. Możesz sprawdzić, jak prawidłowo zapakować oprogramowanie w RPM.
3. Możesz zostawić kopię tarplików z instalacji w /usr/src/non-rpmscelu przypomnienia (tak zwykle robię).