Polskie Forum Użytkowników Debiana

Wstęp:
Jako że moja ostatnia praca wiązała się trochę z koncepcjami, oraz że parę dni temu po aktualizacji kilku pakietów (m.in. nvidia), xorg zaczął się zawieszać gdy włączają się kompozycje, stwierdziłem, że przydałoby się coś co pozwoliłoby w łatwy sposób przywracać poprzednią konfiguracje systemu. Co wpadło mi do głowy opiszę poniżej.


Przywracanie poprzedniej konfiguracji systemu/ Wycofywacz złych zmian (nazwy robocze) - opis pomysłu:

1. Pomysł dotyczy przywracania poprzedniej konfiguracji systemu po nieudanej aktualizacji lub aktualizacji, w wyniku której nastąpiły późniejsze komplikacje (np. zawieszanie xorga, błąd drukarki itp.).
2. Podczas instalacji/aktualizacji/kasowania pakietów systemowych (np. deb, rpm) konieczne byłoby logowanie do pliku jakie zmiany zostały wprowadzone (np. aktualizacja pakietu lib_coś_tam z 6.8 do 7.0). I teraz wymyśliłem 2 opcje:
   
   1. W przypadku Debiana "odkryłem" ostatnio repozytorium snapshots przechowujące archiwalne pakiety, dlatego możliwe byłoby tylko rejestrowanie jakie pakiety zostały zmienione, a w przypadku potrzeby ich przywrócenia, ściąganie ich z serwera snapashot.debian.org (konieczność zbudowania metody wyszukującej pakiety na serwerze).
      Zalety: - oszczędność miejsca na dysku (nie trzeba robić kopii zapasowej wszystkich plików).
      Wady: - konieczność ręcznego przywracania systemu (w przypadku gdy w wyniku aktualizacji przestanie działać internet).
   2. Tworzenie na dysku kopii zapasowej zastępowanych plików (lista plików należących do danej paczki jest (chyba w każdym Linuksie zawierającym paczki) przechowywana w systemie). Przed aktualizacją następowałby odczyt (i logowanie) listy plików paczki, która zostanie zastąpiona.
      - Pliki zapasowe byłyby automatycznie kasowane po określonym czasie. Przewiduje trzymanie tylko ostatniej wersji aktualizowanego pakietu (aktualizacja libABC 6.8 do 7.1 następnie do 7.2, skasuje kopię zapasową 6.8).
      Zalety: - brak konieczności posiadania połączenia z internetem, - rozwiązanie dostępne nie tylko dla dystrybucji mających repozytorium ,,snapshot'' (np. Debian).
      Wady: - zużycie miejsca na dysku.
3. Niezależnie od sposobu rejestrowania zmian zakładam kopię zapasową na dysku (zamienionych/usuniętych) plików konifguracyjnych.
4. Konieczność napisania programu umożliwiającego wycofania zmian sprzed konkretnej daty aktualizacji systemu.
5. Zakładam przywrócenie wszystkich pakietów, które zostały w danym dniu zaktualizowane (chociaż w przyszłości można by pomyśleć nad wyborem konkretnej paczki jeżeli zależności na to pozwolą - do zastanowienia)
6. Tto może być punkt najtrudniejszy, rejestracja wprowadzonych zmian musiałaby się odbywać zaraz przed wywołaniem właściwego instalatora paczek (np. apt-get), bo pewnie ciężko będzie wynegocjować na programistach "instalatorów paczek", żeby sami rejestrowali wprowadzane zmiany (ale tak byłoby chyba najlepiej).
   Wydaje mi się jednak, że są techniczne możliwości stworzenie takiej nakładki.
7. Jako że instalatory (np. dpkg) potrafi zwracać wynik swojej operacji myślę, że możliwe wyłapanie, czy aktualizacja została przeprowadzona pomyślnie, czy nie (automatyczne przywracanie raczej niekoniecznie w takim przypadku ale można by zarejestrować taki fakt - jeżeli użytkownik sam nie naprawi programu np.

   Kod: Zaznacz cały

   apt-get -f install

   to wtedy sugerować mu wycofanie zmian).

Zakończenie:
Pomysł zrodził się z powodu błędu w najnowszym oprogramowaniu nvidii (albo złej interakcji z nowym xorgiem - do końca nie wiem), W moim przypadku rozwiązaniem jest albo czekanie na nową wersje (poprawkę) albo przywracanie poprzedniej wersji (co czasem ze względu na zależności między paczkami może nie być proste, a w ekstremalny sytuacjach nawet niemożliwe).

Wydaje mi się, poziom złożoności (interakcji) oraz możliwa liczba konfiguracji uniemożliwiają stworzenie w 100% bezbłędnego oprogramowania (czy bez możliwych "nieprawidłowych interakcji" z innymi paczkami/oprogramowaniem), dlatego dobrze byłoby posiadać możliwość łatwego wycofania zmian wprowadzonych przez nowe paczki (oprogramowanie). Stad przedstawiony powyżej pomysł.

Czekam na wasze komentarze, opinie, propozycje oraz co sądzicie o takim rozwiązaniu. Jeżeli byłby przychylne można byłoby taki pomysł zaprezentować szerszej publiczności (pytanie gdzie, bo nigdy nie robiłem czegoś takiego), a to być może pozwoliłoby na jego realizacje.
Co do moich możliwości prezentuje tylko i wyłącznie pomysł/koncepcje, nie znam się na programowaniu.

Linux to nie Windows, że możesz przywracać z konkretnego dnia.
Ja robię tak: cały system plików z katalogu głównego /, mam skopiowany na inną partycję. W razie padu. Uruchamiam liveCD i kopiuje z tej innej partycji system z powrotem na /. Wcześniej trzeba skasować to co było na / albo używać narzędzia rsync.

Yampress pisze:Linux to nie Windows, że możesz przywracać z konkretnego dnia.

Linux to nie Windows, więc w przeciwieństwie do niego, może wszystko.

Yampress pisze:Ja robię tak: cały system plików z katalogu głównego /, mam skopiowany na inną partycję. W razie padu. Uruchamiam liveCD i kopiuje z tej innej partycji system z powrotem na /. Wcześniej trzeba skasować to co było na / albo używać narzędzia rsync.

A ktoś inny ma na to jeszcze inne sposoby. Tylko, że to nie na ten temat.

Generalnie chodzi mi o to, że kolega wysunął całkiem ciekawą propozycję, a Ty od razu musisz go gasić. Jeśli Ci się nie podoba pomysł, zaznacz to, wytłumacz dlaczego, ale nie neguj od razu całej idei... Bez obrazy, szanuję Cię, ale nieco mnie zbulwersowała taka krytyka. Mało konstruktywna, za to mocno destrukcyjna.

Co do tematu:

Pomysł jak najbardziej dobry, należałoby go oczywiście jeszcze dopracować. Problem jest taki, że póki nie stworzysz dokładnego planu projektu i sam nie zaczniesz go pisać, nikt Ci nie pomoże. Bardzo łatwo jest wymyślić ogólny zarys funkcjonowania aplikacji, ale zakodować to to już nieco inna sprawa. Wszystko rozbija się o organizację. Nikt nie zrobi niczego dla Ciebie za darmo, zwłaszcza póki projekt nie ma jasno ustalonych wytycznych, które należałoby realizować. W darmowych projektach otwarto źródłowych zazwyczaj zaczyna się od pracy jednej, może kilku osób, a dopiero potem dołącza się społeczność. Potem - czyli kiedy projekt ma już ręce i nogi, można go wypróbować i okazuje się użyteczny.