Aktualizacja oprogramowania ( kompilacja ze źródeł ) na przykładzie qemu 2.8 z deb9 do >= 2.12
: 07 września 2018, 19:48
Cześć,
Pewnym powracającym dla mnie problemem przy korzystaniu z Debiana ( w sumie to chyba każdego Linuksa ) jest aktualizacja oprogramowania do wersji innej niż ta w repozytoriach. Ostatnio problem ten dotknął mnie kilka tygodni temu kiedy bawiłem się Open Broadcast Software, a teraz powrócił w przypadku wirtualizacji przez Qemu.
Z moich doświadczeń w korzystaniu z Linuksa wynika, że jeśli nie przywiąże się większej uwagi do kompilacji oprogramowania ze źródeł można się skazać na nie lada problemy przy późniejszej próbie aktualizowania dystrybucji. np. taki apt-get dist-upgrade może nam wykrzaczyć cały system, bo oprogramowanie o innej wersji niż dostępna w repozytoriach korzysta np. z jakiejś fikuśnej wersji pewnej biblioteki / integruje się z jądrem lub x^n innych problemów ...
Moją wymarzoną wersją rozwiązania tego problemu jest wykorzystanie docker'a lub jakiejś formy wirtualizacji w celu odseparowania zarówno procesu kompilacji, plików wynikowych oraz nawet samego uruchamiania danej aplikacji. W przypadku takiego Qemu czy OBS sprawa wydaje mi się być znacznie cięższa, bo musimy dać tym aplikacjom odpowiedni dostęp do hardware lub jądra.
Teraz pytania ( przepraszam za ten przydługi wstęp ):
1) Czy spotkaliście się z jakimś hmm menadżerem pakietów korzystającym z wirtualizacji lub kontenerów? Jak się nazywa i jeśli nie to czy uważacie taki projekt za coś co miałoby sens?
2) Jak radzicie sobie kiedy potrzebujecie innych wersji oprogramowania niedostępnych w repozytoriach?
3) Czy można jakoś wykorzystać źródła oprogramowania będące w oficjalnym repo do kompilacji nowszej wersji i jeśli tak to jak?
4) Co zrobić jeśli "zasyfi" się system oprogramowaniem nie będącym w oficjalnym repo Debiana?
5) ./configure --prefix=( / , /usr/local/ czy /opt ) ?
5.a) Co zrobić jeśli oprogramowanie nie pozwala na ustawienie prefix'a ?
6) statyczne linkowanie czy dynamiczne? ( wydaje mi się że statyczne jest bezpieczniejsze )
6.a) jeśli statyczne to co zrobić jeśli oprogramowanie na to nie pozwala ?
7) Czy można jakoś system monitorować żeby wiedzieć jakich zmian dokona wywołane polecenie? - Mam tu na myśli głównie make install, ale może ono przecież wywoływać różne skrypty )
7.a) Czy można zrobić jakoś diff całego systemu? ( Może jakoś Terraform lub Ansible ) - np. Robię kompilację w odizolowanym środowisku ( chroot, kontener czy wirtualka ) po czym robiąc pełny diff tegoż środowiska wiedziałbym co dokładnie zostało zmienione.
Jeśli dotarliście aż do tego momentu to bardzo dziękuję za cierpliwość i poświęcony czas.
Byłbym na prawdę zobowiązany jakbym otrzymał chociaż część odpowiedzi, bo przez brak odpowiedniego workflow w tym aspekcie często tracę bezsensownie całe dni; tak niestety nie godziny tylko dni. Albo rozwiązują problem z oprogramowaniem "na szybko" przysparzam sobie problemów później ... Ehh. :/
edit>
Aaaaaa tak się rozpisałem, a zapomniałem się zapytać o Qemu ...
8) Zacząłem korzystać z wersji zdokeryzowanej tj. Mam jednak wrażenie, że to nie jest do końca to co chciałem ... Wydaje mi się że pliki które mam zainstalowane na hoście są niezgodne z tymi w kontenerze i zachodzi tutaj cichy konflikt ... cichy, bo nie mogę zainstalować systemu gościa ... nie bootuje mi się instalator, ale nie mam żadnych komunikatów o błędach. Czy może tak się właśnie dziać? Tj. Czy oprogramowanie działające w kontenerze które korzysta np. z pewnego modułu jądra ( tutaj KVM np. ) może nie zgłaszać konfliktu mimo tego że wymaga powiedzmy innej wersji tego modułu?
Pewnym powracającym dla mnie problemem przy korzystaniu z Debiana ( w sumie to chyba każdego Linuksa ) jest aktualizacja oprogramowania do wersji innej niż ta w repozytoriach. Ostatnio problem ten dotknął mnie kilka tygodni temu kiedy bawiłem się Open Broadcast Software, a teraz powrócił w przypadku wirtualizacji przez Qemu.
Z moich doświadczeń w korzystaniu z Linuksa wynika, że jeśli nie przywiąże się większej uwagi do kompilacji oprogramowania ze źródeł można się skazać na nie lada problemy przy późniejszej próbie aktualizowania dystrybucji. np. taki apt-get dist-upgrade może nam wykrzaczyć cały system, bo oprogramowanie o innej wersji niż dostępna w repozytoriach korzysta np. z jakiejś fikuśnej wersji pewnej biblioteki / integruje się z jądrem lub x^n innych problemów ...
Moją wymarzoną wersją rozwiązania tego problemu jest wykorzystanie docker'a lub jakiejś formy wirtualizacji w celu odseparowania zarówno procesu kompilacji, plików wynikowych oraz nawet samego uruchamiania danej aplikacji. W przypadku takiego Qemu czy OBS sprawa wydaje mi się być znacznie cięższa, bo musimy dać tym aplikacjom odpowiedni dostęp do hardware lub jądra.
Teraz pytania ( przepraszam za ten przydługi wstęp ):
1) Czy spotkaliście się z jakimś hmm menadżerem pakietów korzystającym z wirtualizacji lub kontenerów? Jak się nazywa i jeśli nie to czy uważacie taki projekt za coś co miałoby sens?
2) Jak radzicie sobie kiedy potrzebujecie innych wersji oprogramowania niedostępnych w repozytoriach?
3) Czy można jakoś wykorzystać źródła oprogramowania będące w oficjalnym repo do kompilacji nowszej wersji i jeśli tak to jak?
4) Co zrobić jeśli "zasyfi" się system oprogramowaniem nie będącym w oficjalnym repo Debiana?
5) ./configure --prefix=( / , /usr/local/ czy /opt ) ?
5.a) Co zrobić jeśli oprogramowanie nie pozwala na ustawienie prefix'a ?
6) statyczne linkowanie czy dynamiczne? ( wydaje mi się że statyczne jest bezpieczniejsze )
6.a) jeśli statyczne to co zrobić jeśli oprogramowanie na to nie pozwala ?
7) Czy można jakoś system monitorować żeby wiedzieć jakich zmian dokona wywołane polecenie? - Mam tu na myśli głównie make install, ale może ono przecież wywoływać różne skrypty )
7.a) Czy można zrobić jakoś diff całego systemu? ( Może jakoś Terraform lub Ansible ) - np. Robię kompilację w odizolowanym środowisku ( chroot, kontener czy wirtualka ) po czym robiąc pełny diff tegoż środowiska wiedziałbym co dokładnie zostało zmienione.
Jeśli dotarliście aż do tego momentu to bardzo dziękuję za cierpliwość i poświęcony czas.
Byłbym na prawdę zobowiązany jakbym otrzymał chociaż część odpowiedzi, bo przez brak odpowiedniego workflow w tym aspekcie często tracę bezsensownie całe dni; tak niestety nie godziny tylko dni. Albo rozwiązują problem z oprogramowaniem "na szybko" przysparzam sobie problemów później ... Ehh. :/
edit>
Aaaaaa tak się rozpisałem, a zapomniałem się zapytać o Qemu ...
8) Zacząłem korzystać z wersji zdokeryzowanej tj.
Kod: Zaznacz cały
FROM debian:sid-20180831
# https://hub.docker.com/r/tianon/qemu/~/dockerfile/
# https://github.com/tianon/dockerfiles/tree/master/qemu
RUN apt-get update && apt-get install -y --no-install-recommends \
procps \
net-tools \
ovmf \
qemu-system \
qemu-utils \
&& rm -rf /var/lib/apt/lists/*
EXPOSE 22
EXPOSE 5900