Cała aktywność

Istnieje również plugin dla dnf python3-dnf-plugin-local https://blog.holtzweb.com/posts/fedora-repository-local-mirror-over-LAN/ https://fedoramagazine.org/use-the-dnf-local-plugin-to-speed-up-your-home-lab/

Dwa słowa: dnf reposync. To tworzy lokalną kopię repozytorium, którą można potem przyrostowo aktualizować. Mam kilkanaście maszyn wirtualnych z CentOS 10 i oszczędza to kupę czasu. Pobrane pliki najlepiej wystawić w sieci lokalnej po http i poprawiać konfigurację dnf przed każdą cotygodnoową aktualizacją. Ja mam do tego prace ansiblowe: podmian konfiguracji dnf na wszystkich hostach, wyczyszenie cache dnf i aktualizacja na wszystkich hostach. Na reposync Fedory będziesz potrzebował z 500 gigabajtów przetrzeni dyskowej. Może więcej. Dawno nie sprawdzałem.

Ze względu na słaby i limitowany dostęp do internetu pomyślałem o stworzeniu lokalnego repozytorium dla kilku kompów w sieci domowej (wszyscy korzystają z Fedory ). Oszczędziło by to czas aktualizacji na kompach i wymagało tylko jednorazowgo ściągnięcia aktualizacji z internetu, a następne kompy korzystały by z lokalego repozytorium. Aktualizuję praktycznie tylko z dnf w konsoli. A więc po kolei: 1. Stworzyłem katalog współdzielony na Synology NAS, udostępniłem dla wszystkich kompów w sieci lokalne. 2. Zamontowałem ten katalog na kompach przez NFS 3. Na wybranym komputerze zainstalowałem libdnf5 Actions plugin 4. Wykorzystując ten plugin, w pliku moja.actions: # Prints the date and time and information about the end of the transaction. # Since package_filter is empty, it executes the commands once. post_transaction::::/usr/local/bin/CreateLocalRepo.sh wywołuję skrypt CreateLocalRepo.sh: W tym pliku kopiowałem wszystkie pakiety z cache`a lokalego kompa na katalog współdzielony NAS`a i wywoływałem createrepo na tym katalogu. Niestety wiązało się to z ponownym przesyłaniem plików z NAS do kompa celem stworzenia plików repo. Trochę usprawniłem proces createrepo instalując Fedora w dockerze na NAS i wywołując zdalnie createrepo na dokerze z Fedorą na Synology NAS. Zawartość skryptu poniżej: #!/bin/sh echo "Coping packages to localRepo" > /dev/stdout cp -n /var/cache/libdnf5/*/packages/* /srv/fedoraLocalRepo/packages/ date > /dev/stdout echo "Docker Create localRepo" > /dev/stdout sshpass -p "xxxxxxxx" ssh [email protected] "/usr/local/bin/docker exec 45a498a4bdad createrepo /home/Repo" > /dev/stdout Teraz proces działa poprawnie, nie ma potrzeby ponownego przesyłania plików z NAS`a do kompa. Proszę o pomoc w usprawnieniu procesu, chciałbym przede wszystkim widzieć komunikaty ze skryptu CreateLocalRepo.sh na konsoli, z której wywołuję #dnf upgrade. Może wypadałoby korzystać z jakiś zmiennych, które wskazują cache`a libdnf5 ? Dzięki za wszelkie uwagi i pomoc. Tak na marginesie to działa . Pominąłem opis konfiguracji nowego repo na pozostałych komputerach.

Możesz, bo instalator i tak sprawdza stosowne sumy kontrolne. Jak linuksowi się pozmienia tablica partycji na karcie sd, albo pejdrajwie, to graficzne menedżery plików trochę się gubią i czasem trzeba odmontować dysk z parametrem "lazy", albo po prostu wyciągnąć pendrajwa z gniazdka. Podręcznik programu umount wyjaśnia ten problem. Ja mam pecha do pendrajwów. Kupuję najtańsze szroty, które owszem działają dobrze do jakiejś połowy swojej pojemności, a potem bywa różnie i przekłamują zapisywane dane. Czasem szybciej mi jest wypalić płytę dvd i mam potem czystą tackę do mieszania farbek.

Cześć, dziś tworzyłem pendrive rozruchowy z system. Procedura przebiegła poprawnie. Natomiast po wyłączeniu programu zauważyłem w nautilusie "wolumin 31gb" kliknąłem aby go odmontować ale dostałem odmowę i "No object for D-Bus interface". Odczekałem parę minut i spróbowałem raz jeszcze. Po drugiej nieudanej próbie wyciągnąłem go z portu. Aktualny system i aktualny program fedora media writer. dmesg GPT:Primary header thinks Alt. header is not at the end of the disk. GPT:4684615 != 60437491 GPT:Alternate GPT header not at the end of the disk. GPT:4684615 != 60437491 GPT: Use GNU Parted to correct GPT errors. to chyba do tego zdarzenia by pasowało. Robię coś nie tak? Nigdy nie miałem problemu z FMW. Później mam błędy ale to do innego hdd usb - chyba dysk mi pada. edit. Dziś na innym pendrive spróbowałem utworzyć. Oto co zauważyłem. Po włożeniu pendrive (była na nim fedora 41) w nautilusie był on opisanie stosownie co do zawartości, mianowicie fedora 41 itd. Po stworzeniu nowego nośnika na nim z fedora 42, po wejściu do nautilusa pendrive nadal był opisany jako fedora 41, oczywiście przy próbie odmontowania go, dostaję odmowę i " no object for D-Bus interface". Czy mogę takiego nośnika bezpiecznie użyć do instalacji systemu?

ok

Na pulpicie nigdy nawet nie podchodziłem do niemutowalnych dystrybucji. Jestem typpwym dłubaczem i lubię mieć po swojemu. Jakoś w najbliższych dwóch tygodniach będę kubernetesa stawiał na Fedorze Core OS, bo na serwerach zwykle nie ma czasu na dłubanie. :-( Wypowiem się, jak to zadziała.

Ja mam zainstalowanego z RPM, ale to bardziej z przyzwyczajenia, niż przekonania.

Cześć, czy jest do rozważenia na pulpit domowy wersja atomic? Widzę że ta koncepcja nabrała popularności np bazzite.

Dzień dobry, używacie ff domyślnego z rpm czy może z flatpak? U mnie nie wiem co do końca jest przyczyną ale czasami zacina (wersja rpm) i dostaję komunikat aby zaczekać trochę albo ubić, natomiast poczeka się z 3 sek i działa dalej.

Dziękuję za odpowiedź. Mam wujka, któremu zawdzięczam poznanie Linuxów i on mi powiedział, że sprawdzi o co chodzi więc jeszcze tych komend nie użyłem bo tak mi poradził. Ale bardzo Ci dziękuję za pomoc. Z pewnością napiszę na forum o co chodziło by inni mający podobny problem mogli skorzystać na czytaniu tego tematu.

Cześć, Mam kilka kont użytkownika na Fedorze 42 i przynajmniej od jakiś iluś lat awatary przy nazwie użytkownika miały różne kolory i zawierały pierwszą literę nazwy konta użytkownika. Na moim nowym komputerze trochę później niż normalnie miałem to w zwyczaju robić dodałem kolejne dwa konta użytkownika prócz tego pierwszego i o ile konto moje pierwsze miało kolorowy awatar z literką tak pozostałe miały szary awatar z rysunkiem ludzika. Chciałem to zmienić i wszedłem w ustawienia kont użytkownika w gnome. Tam się okazało że awatary wyświetlają się prawidłowo w ustawianiach. Tylko na ekranie logowania jest inaczej. Wymyśliłem że wybiorę jakiś obrazek na awatar z tych dostępnych domyślnie a potem go usunę i może zaskoczy. I owszem awatary szare z ludzikiem zniknęły ale niestety na ich miejsce nie pojawiły się awatary kolorowe z literką tylko kolorowe też ale takie jakieś rozmazane barwy bez litery i wyglądające jak jakiś błąd. Do tego trzeba podkreślić, że dwa awatary mają ten sam niebieski kolor co źle też wygląda. Więc piszę do Was by spytać czy można jakoś zgłosić te błędy twórcom bo z jednej strony chciałbym by każdy awatar jak zawsze miał inny kolor a przede wszystkim by każdy awatar wyglądał tak jak w ustawieniach czyli miał ładną barwę i literę. Wrzucę w załącznikach ekran logowania ze starego komputera i nowego. 1. Na tym zdjęciu nowy komputer z dziwnymi awatarami (z początku nim zacząłem się bawić pierwsze konto wyglądało jak powinno a pozostałe miały szarego ludzika): 2. Na tym zrzucie ustawienia z nowego komputera gdzie widać awatary tak jak powinny wyglądać. Niestety dwa konta mają kolor niebieski: 3. Na tym zdjęciu awatary na starym komputerze jak powinno być (za wyjątkiem ostatniego niedawno utworzonego konta gdzie jest szary ludzik - tak wyglądały awatary nowe na nowym kompie - znaczy były z szarymi ludzikami ):

To raczej pewnie jakiś błąd (nie używam gnome) Użyj terminala i spróbuj ręcznie zaktualizować aby pobrać najnowsze aktualizacje sudo fwupdmgr get-updates oraz aby zaktualizować sudo fwupdmgr update

Cześć, Już na początku korzystania z Fedory 42 na nowym komputerze w aktualizacjach znalazła się "Aktualizacja Konfiguracji Secure Boot dbx". Można ją było pobrać osobnym przyciskiem. Zrobiłem to. Od tego czasu po każdej aktualizacji przez Gnome w podsumowaniu widnieje pozycja "aktualizacja secure boot dbx". Mimo że instalowałem ją kilka tygodni temu to cały czas wygląda jakbym co aktualizacje instalował aktualizacje secure boot dbx... Czym to może być spowodowane? Mam lekką paranoje jeśli chodzi o takie dziwne rzeczy. Mógłby mi ktoś pomóc zrozumieć czemu tak się dzieje? Czy jest to tylko jakaś niedoróbka, błąd w menadżerze aktualizacji czy coś zagrażające bezpieczeństwu?

Tak. Jeżeli ni gruchy, ni z pietruchy DNF zapyta o akceptację klucza dla pakietu pochodzącego z często używanego przez nas repozytorium, trzeba być podejrzliwym i sprawdzić, czemu ten klucz nie jest już taki sam jak wczoraj, czy tydzień temu. Trzeba brać pod uwagę, że prawie nigdy nie pobieramy pakietów RPM ze strony fedoraproject.org, ale z polskich serwerów, takich jak https://ftp.icm.edu.pl/pub/linux/distributions/fedora/linux/releases/42/Everything/x86_64/os/ . Możliwe, że nie mają one zabezpieczeń na poziomie projektu Fedory i komuś uda się wysłać tam podstawiony plik htop-[jakaśwersja].fc42.x86_64.rpm , ale jakby się ten ktoś nie starał, nie podpisze tego pliku właściwym kluczem kryptograficznym, bo owego klucza nie posiada. W takim wypadku dnf pokaże ostrzeżenie przy próbie instalacji pakietu htop. Zwykle projekty takie jak Fedora, Rpmfusion, EPEL, opiekunowie repozytoriuów różnych innych dystrybucji Linuksa publikują informacje o wymianie swoich kluczy kryptograficznych.

Pisałem z telefonu i nie trafiałem w odpowiednie litery. Poprawiłem kodowanie. (-: Ty możesz te ciągi udostępniać. Zespół Fedory nie może udostępniać swoich ciągów. Im dłużej używają konkretnych kluczy prywatnych, tym większa szansa na ich przypadkowe opublikowanie. Dlatego czasem te klucze są wymieniane. Dla nas wynikają z tego tylko dwie rzeczy: dnf pokazuje nam klucz do akceptacji podczas pierwszej instalacji czegokolwiek na nowym hoście z Fedorą, dnf pokazuje nam klucz do akceptacji, kiedy zespół Fedory zdecyduje się na ich wymianę po swojej stronie.

Jeżeli jestem w stanie dobrze to wytłumaczyć to pakiet który pobierasz z zaufanej strony ma wygenerowany "wynik" (podpis wygenerowany algorytmem generującym sumę kontrolną?) Twoim zadaniem, aby mieć pewność, że plik na pewno jest zaufany, jest porównanie tego "wyniku" z tym podanym na stronie. Jeśli wartości nie zgadzają się to znaczy, że pakiet który instalujesz nie jest dostarczony przez twórcę, ale przez np.: hakera próbującego zainstalować coś "nieładnego". Czy takie wyjaśnienie jest prawidłowe? Czy ja to dobrze rozumiem? Czy to nie chodzi jednak o sumę kontrolną? Radek Głębicki

Piszesz trochę skrótami myślowymi i robisz błędy pisowni przez co nie bardzo wszystko zrozumiałem. Do tego może jestem trochę niekumaty. Co masz na myśli pisząc o pilnowaniu tych kluczy? Chodzi ci o to, że nigdy nie powinienem udostępniać publicznie tego ciągu liter i cyfr który został mi wyświetlony z prośbą o potwierdzenie?

To jeat odcisk klucza kryptograficznego, którym są podpisywane pliki costam.rpm z repozytorium Fedory. Prawie każde repozytorium z plikami rpm ma owe pliki podpisane. Dnf jednorazowo pyta użytkownika o każdy odcisk, którego odpowiadającym kluczem nie został podpisany żaden lokalnie pobrany plik rpm. Możesz się na te klucze zgadzać, ale dobrą praktyką jest ich weryfikacja. Klucze gpg rpmfusion - https://rpmfusion.org/keys Klucze gpg Fedory - https://fedoraproject.org/security Problem jest taki, że te klucze nie mogą być używane bez przerwy, z kilku powodów. Pierwszy jest taki, że ludzie mają generalnie coraz lepsze komputery, więc można używać coraz to lepszych technik kryptograficznych do generowania tego klucza. Czas jego weryfikacja na komputerach z Fedorą nie powinien być zauważalny. Drugi jest bardziej prozaiczny. Jakby tych kluczy nie pilnować, czasem ktoś go (nie)chcący wyśle mailem, albo skopiuje do publicznie wystawionego zasobu. Prewencyjnie się je co jakiś czas wymienia, albo też możliwie szybko po zgłoszeniu takiego zdarzenia.

Cześć, Mam pytanie które trudno mi zadać trochę bo nie do końca wiem o co pytam. Dziś zainstalowałem kilka pakietów tapet z poprzednich wersji Fedory. Podczas instalacji pierwszego pakietu tapet z Fedory 24 dostałem pytanie - dziwnie poważne biorąc pod uwagę to co ściągam - o jakiś klucz. W sensie pokazany mi został jakiś ciąg liter i cyfr i miałem potwierdzić że się zgadza. Podobne pytanie otrzymywałem przy aktualizacji Fedory poprzez terminal. Głupio zrobiłem, że nie skopiowałem komunikatów terminala bo mógłbym tu wkleić i się spytać prościej. Nie wiem czy nie chodzi o GNU Privacy Guard bo szukałem informacji a o kluczach ale nie bardzo wiem czy to jest to. Czy mógłby mi ktoś wytłumaczyć co to mogło być i jak na przyszłość sprawdzać czy wszystko się zgadza jeśli w ogóle jest sens to robić?

To wszystko wyjaśnia. Ale już nie ma potrzeby używać tego polecenia. Po kolejnej aktualizacji wszystko się naprawiło. Chrome działa teraz stabilnie. Dziękuję za pomoc.

Wcale nie dziwne jeśli masz wersję z flatpaka, tą się uruchamia z terminala komendą flatpak run com.google.Chrome

Po pierwsze dziękuję za odpowiedź SeeM - system jednak nie widzi takiego polecenia bash: google-chrome: nie odnaleziono polecenia... Pakiety dostarczające ten plik: 'google-chrome-beta' 'google-chrome-canary' 'google-chrome-stable' 'google-chrome-unstable' EDIT: Teraz tak patrze na ten komunikat systemu i nie znając się zupełnie na tym, jednak zaczynam sądzić, że to trochę dziwne - bo skoro mam zainstalowany Chrome to czemu system tego nie widzi i uważa że powinienem zainstalować Chrome? Bo to chyba tak należy rozumieć co? W końcu google-chrome-stable chyba już jest zainstalowany?

Można zacząć od uruchamiania Chroma w terminalu: google-chrome Niektóre aplikacje są w terminalu bardzo gadatliwe, kiedy coś im nie pasuje. Niektóre w ogóle nic nie wypisują.

Wczoraj zainstalowałem aktualizacje Chrome, ale niestety jak się zawieszał tak wciąż się zawiesza. Znacie jakieś polecenia do terminala które byłyby pomocne w diagnozowaniu problemu? Znam polecenie journalctl -f choć dokładnie nie pamiętam czemu służy. Problem z Chromem wygląda tak że Chrome się zawiesza i wylogowuje mnie do ekranu logowania co może trochę utrudnić diagnozowanie problemu tym poleceniem jeśli razem z Chromem wyłączy mi się terminal.