Archiwum kategorii: Fedora

Zapełniony /boot na Fedorze?

Amazon Linux 2023, Fedora, Nobara, Red Hat Enterprise Linux, , , ,

Fedora i wiele innych dystrybucji zakłada przy instalacji dedykowaną partycję /boot. Nie jest ona jakoś przesadnie wielka, bo i nie musi. Gdy jednak wgrywamy aktualizacje na bieżąco, może dojść do sytuacji w której dojdzie do jej przepełnienia. Przy próbie aktualizacji systemu komendą dnf może to wyglądać jak poniżej:

Error Summary
-------------
Disk Requirements:
   At least 29MB more space needed on the /boot filesystem.

Co więc zrobić gdy /boot ma twoim jest pełny? Komenda poniżej skasuje wszystkie kernele inne niż ten na którym pracujesz:

sudo dnf remove --oldinstallonly -y

A może nie chcesz kasować wszystkich na wypadek konieczności powrotu do starszej wersji? Możesz skasować bez np. dwóch najnowszych:

dnf remove --oldinstallonly --setopt installonly_limit=2 kernel

Komendy te możesz zastosować też na Amazon Linux 2023, Nobara Linux, czy Red Hat Enterprise Linux od wersji 8 w górę.

Logo Linux Fedora
Fedora Linux

–

Nobara Linux Logo
Nobara Linux

–

logo programu Podman

docker/podman search

Docker, Fedora, podman, Red Hat Enterprise Linux, , , ,

docker search – przydatna funkcjonalność, do przeszukiwania repozytoriów.

Osobiście używam główne do znalezienia dostępnych kontenerów UBI od red hata. 🙂

docker search registry.access.redhat.com/ubi

Inne używane czasami zastosowanie, to wyszukanie przygotowywanych przez fedoraproject kontenerów np. w danej wersji fedory:

[root@laPtak ~]# podman search registry.fedoraproject.org/f39
NAME                                                 DESCRIPTION
registry.fedoraproject.org/f39/flatpak-kde5-runtime  
registry.fedoraproject.org/f39/flatpak-kde5-sdk      
registry.fedoraproject.org/f39/flatpak-kde6-runtime  
registry.fedoraproject.org/f39/flatpak-kde6-sdk      
registry.fedoraproject.org/f39/flatpak-runtime       
registry.fedoraproject.org/f39/flatpak-sdk

Tak znalezione kontenery można pobrać później korzystając z komendy docker/podman pull.

Moduły nvidia nie ładują się

Aplikacje, Fedora, nvidia,

Po reinstalacji systemu na Fedora 38, zainstalowałem jak zawsze drivery nvidii. Niestety tym razem okazało się, że po reboocie moduły się nie załadowały, a próba skorzystania z karty graficznej o większej mocy kończy się błędami, w których przewijało się słowo 'key’, oraz

X Error of failed request:  BadValue (integer parameter out of range for operation)

Przyczyna? Nieoczywista. Włączyłem secure boot, a moduły kernela nie były podpisane.

Weryfikacja:

[root@laPtak ~]# mokutil --sb-state
SecureBoot enabled

Naprawa:

sudo dnf remove kmod-nvidia-*
sudo dnf install akmod-nvidia

Następnie wykonaj instrukcję z pliku:

/usr/share/doc/akmods/README.secureboot
Logo Linux Fedora
Ściana z czerwonej cegły, a za nią monitor. Obok napis firewalld

firewalld – przekierowywanie portów

Fedora, Linux, , ,

Lubię firewalld. Nie zawsze jednak pamiętam składnię firewall-cmd.
Szybka notatka jak zestawić przekierowanie portu na inne ip i port.

Uruchom jako root:

# firewall-cmd --permanent --zone=public --add-forward-port=port=80:proto=tcp:toport=8080:toaddr=10.1.1.10

Rezultatem tej komendy będzie ustanowienie przekierowania z portu 80(port) twojej maszyny, na port 8080(toport) maszyny o adresie 10.1.1.10(toaddr). Jeżeli chcesz przekierować porty wewnątrz jednego hosta, pomiń część 'toaddr’.

Co dalej? Standardowo:

# firewall-cmd --reload
# firewall-cmd --list-all

Pamiętaj, że samo przekierowanie portu może nie wystarczyć. Musisz go mieć otwartego. W tym celu wykonaj dodatkowo komendę:

# firewall-cmd --add-port=80/tcp --permanent
# firewall-cmd --reload

I zweryfikuj czy pojawia się na liście otwartych portów:

#firewall-cmd --list-all

Przekierowanie oczywiście można też usunąć.
Wystarczy zamienić w komendzie dodawania słówko add na remove:

# firewall-cmd --permanent --zone=public --remove-forward-port=port=80:proto=tcp:toport=8080:toaddr=10.1.1.10

Firewalld powinien ogłosić sukces, a nam pozostaje tylko załadować zmiany do pamięci komendą firewall-cmd –reload.

Logo Linux Fedora

Jak zaktualizować Fedorę?

Fedora, ,

Kolejnych kilka komend, których notorycznie zapominam. Jak zaktualizować Linux Fedora?

Chyba najprościej z terminala. Co prawda jest też jakiś kreator graficzny, ale nie jestem fanem.

# dnf upgrade --refresh
# dnf install dnf-plugin-system-upgrade
# dnf system-upgrade download --releasever=XX*
# dnf system-upgrade reboot
  • W miejsce XX wpisujemy numerek wersji. Supportowany jest upgrade o 1 lub 2 oczka w górę. Szczerze mówiąc na skok o dwa się jeszcze nie odważyłem, ale o 1 idzie bez problemów.
Napis ssh na czarnym tle

SSH długi czas logowania

Fedora, Linux, ,

GSS – Przy próbie połączenia się po ssh, dodaj -vvv do polecenia. Odpalisz w ten sposób szczegółowy debug. Jeżeli w logu zatrzymujesz się przy wpisach podobnych do tych:

debug1: Unspecified GSS failure.  Minor code may provide more information 
Ticket expired

Rozwiązaniem jest zedytowanie pliku /etc/ssh/sshd_config i ustawienie:

GSSAPIAuthentication no

Jeżeli pracujesz na Fedorze/RHEL/CentOS’ie, to ustawienie to bywa zdublowane w pliku /etc/ssh/sshd_config.d/50-redhat.conf. Również w nim zmień wartość na no.

RevDNS – Zdarza się, że opóźnienie powodowane jest sprawdzaniem nazwy hosta, z którego się łączysz. Żeby wyłączyć to sprawdzanie ustaw:

UseDNS no

W celu zatwierdzenia zmian, zrestartuj serwer sshd. Na Fedorze zrobisz to bezpiecznie komendą:

# systemctl restart sshd

btmp – powyższe nie pomogło? Sprawdź jak duży jest twój plik /var/log/btmp.
Czemu? Przykładowo na Fedorach, w /etc/pam.d/postlogin skonfigurowane jest:

session     optional      pam_lastlog.so silent noupdate showfailed

Opcja showfailed, sprawdza w btmp ile było nieprawidłowych prób zalogowania się na Twój login. Jeżeli serwer jest publiczny, to zapewne nie było ich mało. Rozwiązanie?
Skasuj btmp, zainstaluj logrotate i skonfiguruj częstsze czyszczenie tego logu.
Na Fedorze będzie wyglądać to tak.

# dnf install logrotate
# systemctl enable logrotate.timer

Logrotate standardowo czyści btmp. Definicję znajdziesz w pliku /etc/logrotate.d/btmp. Dzięki włączeniu timera, logrotate uruchomi się raz dziennie.

Ustawienie strefy czasowej (systemd).

Aplikacje, Fedora, HypriotOS, Linux, ,

W paczce systemd możemy znaleźć narzędzie do zarządzania ustawieniami czasu w Linuksie. Narzędzie pokazuje obecny status, pozwala też w prosty status ustawić TZ.

Weryfikacja:

$ timedatectl
Local time: Sat 2020-05-23 15:39:25 CEST
Universal time: Sat 2020-05-23 13:39:25 UTC
RTC time: Sat 2020-05-23 13:39:25
Time zone: Europe/Paris (CEST, +0200)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

Chcę, żeby serwer pracował zgodnie z czasem polskim. Komenda 'timedatectl list-timezones’ pozwala znaleźć odpowiadającą nam strefę czasową, czyli w tym przypadku 'Europe/Warsaw’.


No to ustawiamy i weryfikujemy:

$ sudo timedatectl set-timezone 'Europe/Warsaw'
$ timedatectl
Local time: Sat 2020-05-23 15:41:38 CEST
Universal time: Sat 2020-05-23 13:41:38 UTC
RTC time: Sat 2020-05-23 13:41:38
Time zone: Europe/Warsaw (CEST, +0200)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

Chcesz automatycznie synchronizować czas na swoim serwerze? Rzuć okiem na artykuł opisujący jak skonfigurować ntp z użyciem serwisu systemd-timesyncd.

logo systemd

Synchro czasu ntp Linux (systemd)

Aplikacje, Fedora, HypriotOS, Linux, , ,

Kolejny już wpis o synchronizacji czasu ntp. O dziwo pozmieniało się od 2014 roku, kiedy cały dumny opisałem jak w sposób nieprzesadzony synchronizować czas na Linuxach. 😉

Ktoś mądrzejszy ode mnie wdrożył to o czym pisałem – debilizmem jest stawianie serwera ntpd, jeżeli nasz Linux ma być tylko klientem. Wdrożył w systemd, także dystrybucje które go używają, powinny mieć to rozwiązanie out of box (na pewno mają Fedora, Arch i HypriotOS).

No to po kolei. Sprawdzamy czy faktycznie posiadamy taki serwis:

[szydell@laPtak ~]$ systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; disabled; vendor preset: disabled)
Active: inactive (dead)
Docs: man:systemd-timesyncd.service(8)

Jest. Sprawdzamy czy nasz system nie korzysta już czasem z jakiegoś dostawcy czasu. Jeżeli korzysta, to wyłączamy.

Chronyd (Fedora):

$ sudo systemctl status chronyd
● chronyd.service - NTP client/server
Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2020-05-22 12:39:12 CEST; 59min ago
...

$ sudo systemctl disable chronyd.service --now
Removed /etc/systemd/system/multi-user.target.wants/chronyd.service.

Ntpd (HypriotOS/Debian):

$ sudo systemctl status ntp
● ntp.service - Network Time Service
Loaded: loaded (/lib/systemd/system/ntp.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2020-05-12 09:17:07 UTC; 1 weeks 3 days ago
...

$ sudo systemctl disable ntp --now
Synchronizing state of ntp.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable ntp
Removed /etc/systemd/system/multi-user.target.wants/ntp.service.

$ sudo apt purge ntp
Reading package lists… Done
Building dependency tree
Reading state information… Done
The following packages will be REMOVED:
ntp*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 1,848 kB disk space will be freed.
Do you want to continue? [Y/n]
(Reading database … 28459 files and directories currently installed.)
Removing ntp (1:4.2.8p12+dfsg-4) …
Processing triggers for man-db (2.8.5-2) …
(Reading database … 28404 files and directories currently installed.)
Purging configuration files for ntp (1:4.2.8p12+dfsg-4) …
Processing triggers for systemd (241-7~deb10u3+rpi1) …

Konfiguracja serwisu systemd-timesyncd leży w pliku /etc/systemd/timesyncd.conf.
Ustaw NTP i FallbackNTP. Resztę parametrów można skasować. Wartości domyślne są ok.

Przykładowy config (główne serwery ntp z polski. Awaryjne z zasobów Fedory i Debiana):

# cat systemd/timesyncd.conf
[Time]
NTP=0.pl.pool.ntp.org 1.pl.pool.ntp.org 2.pl.pool.ntp.org 3.pl.pool.ntp.org
FallbackNTP=0.fedora.pool.ntp.org 1.fedora.pool.ntp.org 2.fedora.pool.ntp.org 3.fedora.pool.ntp.org 0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org

Uruchomienie:

[szydell@laPtak ~]$ sudo systemctl enable systemd-timesyncd.service --now
Created symlink /etc/systemd/system/dbus-org.freedesktop.timesync1.service → /usr/lib/systemd/system/systemd-timesyncd.service.
Created symlink /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service → /usr/lib/systemd/system/systemd-timesyncd.service.

[szydell@laPtak ~]$ sudo timedatectl set-ntp true

Efekty zmian można szybko zweryfikować:

[szydell@laPtak ~]$ timedatectl
Local time: pią 2020-05-22 14:48:08 CEST
Universal time: pią 2020-05-22 12:48:08 UTC
RTC time: pią 2020-05-22 12:48:08
Time zone: Europe/Warsaw (CEST, +0200)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

[szydell@laPtak ~]$ timedatectl timesync-status
Server: 162.159.200.123 (0.pl.pool.ntp.org)
Poll interval: 1min 4s (min: 32s; max 34min 8s)
Leap: normal
Version: 4
Stratum: 3
Reference: A490853
Precision: 1us (-25)
Root distance: 11.786ms (max: 5s)
Offset: +2.133ms
Delay: 12.974ms
Jitter: 0
Packet count: 1
Frequency: -13,327ppm
VueScan logo

VueScan Linux, problem z wykrywaniem skanera sieciowego Epson XP-640

Aplikacje, Fedora, , , ,

Problem niestety jest szerszy, bo dotyczy sposobu w jaki działa protokół wykrywania urządzeń w sieci, który to dopuszcza aby urządzenie samo nawiązywało połączenie do komputera, np. w celu dosłania dodatkowych szczegółów dotyczących ich konfiguracji. FirewallD takie połączenia traktuje jak 'niezamówiony ruch’, nie potrafi ich śledzić i dropuje.

Testy z wykorzystaniem avahi-browse i tcpdump’a pokazały, że problemem jest blokowanie odpowiedzi zwrotnej generowanej przez skaner. Nie chciałem całkowicie wyłączać firewalld (a takie rozwiązanie krążą głównie po sieci), ale niestety nie udało mi się jak na razie znaleźć eleganckiego rozwiązania.

Nieeleganckie rozwiązanie:

# firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="<tutaj-wpisz-ip-skanera>" accept'
# firewall-cmd --runtime-to-permanent

Zrzuty z analizy:

Start VueScan z poziomu tcpdump’a

[szydell@laPtak ~]$ sudo tcpdump src or dst 192.168.88.247
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlp3s0, link-type EN10MB (Ethernet), capture size 262144 bytes
23:42:09.219064 IP 192.168.88.247.mdns > laPtak.53278: 0- [4q],,, 4/0/10 PTR EPSON XP-640 Series._printer._tcp.local., PTR EPSON XP-640 Series._pdl-datastream._tcp.local., PTR EPSON XP-640 Series._scanner._tcp.local., PTR EPSON XP-640 Series._uscan._tcp.local. (1306) 23:42:09.219160 ARP, Request who-has 192.168.88.247 tell laPtak, length 28 23:42:09.317428 ARP, Reply 192.168.88.247 is-at 9c:ae:d3:12:68:97 (oui Unknown), length 28 23:42:09.317454 IP laPtak > 192.168.88.247: ICMP host laPtak unreachable - admin prohibited, length 556 23:42:09.420803 IP 192.168.88.247.mdns > laPtak.53278: 0- [4q],,, 4/0/10 PTR EPSON XP-640 Series._printer._tcp.local., PTR EPSON XP-640 Series._pdl-datastream._tcp.local., PTR EPSON XP-640 Series._scanner._tcp.local., PTR EPSON XP-640 Series._uscan._tcp.local. (1306)
23:42:09.420892 IP laPtak > 192.168.88.247: ICMP host laPtak unreachable - admin prohibited, length 556
23:42:09.731152 IP 192.168.88.247.mdns > laPtak.53278: 0- [4q],,, 4/0/10 PTR EPSON XP-640 Series._printer._tcp.local., PTR EPSON XP-640 Series._pdl-datastream._tcp.local., PTR EPSON XP-640 Series._scanner._tcp.local., PTR EPSON XP-640 Series._uscan._tcp.local. (1306) 23:42:09.731245 IP laPtak > 192.168.88.247: ICMP host laPtak unreachable - admin prohibited, length 556 23:42:10.046472 IP 192.168.88.247.mdns > laPtak.53278: 0- [4q],,, 4/0/10 PTR EPSON XP-640 Series._printer._tcp.local., PTR EPSON XP-640 Series._pdl-datastream._tcp.local., PTR EPSON XP-640 Series._scanner._tcp.local., PTR EPSON XP-640 Series._uscan._tcp.local. (1306)
23:42:10.046562 IP laPtak > 192.168.88.247: ICMP host laPtak unreachable - admin prohibited, length 556
23:42:10.344299 IP 192.168.88.247.mdns > laPtak.53278: 0- [4q],,, 4/0/10 PTR EPSON XP-640 Series._printer._tcp.local., PTR EPSON XP-640 Series._pdl-datastream._tcp.local., PTR EPSON XP-640 Series._scanner._tcp.local., PTR EPSON XP-640 Series._uscan._tcp.local. (1306) 23:42:10.344386 IP laPtak > 192.168.88.247: ICMP host laPtak unreachable - admin prohibited, length 556 23:42:10.649270 IP 192.168.88.247.mdns > laPtak.53278: 0- [4q],,, 4/0/10 PTR EPSON XP-640 Series._printer._tcp.local., PTR EPSON XP-640 Series._pdl-datastream._tcp.local., PTR EPSON XP-640 Series._scanner._tcp.local., PTR EPSON XP-640 Series._uscan._tcp.local. (1306)
23:42:10.649358 IP laPtak > 192.168.88.247: ICMP host laPtak unreachable - admin prohibited, length 556
23:42:10.956049 IP 192.168.88.247.mdns > laPtak.53278: 0- [4q],,, 4/0/10 PTR EPSON XP-640 Series._printer._tcp.local., PTR EPSON XP-640 Series._pdl-datastream._tcp.local., PTR EPSON XP-640 Series._scanner._tcp.local., PTR EPSON XP-640 Series._uscan._tcp.local. (1306) 23:42:10.956131 IP laPtak > 192.168.88.247: ICMP host laPtak unreachable - admin prohibited, length 556 23:42:11.263326 IP 192.168.88.247.mdns > laPtak.53278: 0- [4q],,, 4/0/10 PTR EPSON XP-640 Series._printer._tcp.local., PTR EPSON XP-640 Series._pdl-datastream._tcp.local., PTR EPSON XP-640 Series._scanner._tcp.local., PTR EPSON XP-640 Series._uscan._tcp.local. (1306)
23:42:11.263416 IP laPtak > 192.168.88.247: ICMP host laPtak unreachable - admin prohibited, length 556
23:42:11.569615 IP 192.168.88.247.mdns > laPtak.53278: 0*- [4q],,, 4/0/10 PTR EPSON XP-640 Series._printer._tcp.local., PTR EPSON XP-640 Series._pdl-datastream._tcp.local., PTR EPSON XP-640 Series._scanner._tcp.local., PTR EPSON XP-640 Series._uscan._tcp.local. (1306)
23:42:14.288668 ARP, Request who-has laPtak tell 192.168.88.247, length 28
23:42:14.288694 ARP, Reply laPtak is-at 34:e1:2d:ee:21:18 (oui Unknown), length 28

avahi-browse

[root@laPtak ~]#  avahi-browse -rt _scanner._tcp
+ wlp3s0 IPv6 EPSON XP-640 Series                           _scanner._tcp        local
+ wlp3s0 IPv4 EPSON XP-640 Series                           _scanner._tcp        local
= wlp3s0 IPv4 EPSON XP-640 Series                           _scanner._tcp        local
   hostname = [EPSON126897.local]
   address = [192.168.88.247]
   port = [1865]
   txt = ["note=" "scannerAvailable=1" "UUID=cfe92100-67c4-11d4-a45f-9caed3126897" "mdl=XP-640 Series" "mfg=EPSON" "adminurl=http://EPSON126897.local.:80/PRESENTATION/BONJOUR" "ty=EPSON XP-640 Series" "txtvers=1"]
Failed to resolve service 'EPSON XP-640 Series' of type '_scanner._tcp' in domain 'local': Timeout reached
postfix logo

postfix, brak public/pickup

Fedora, postfix,

Do lokalnego dostarczania poczty miałem zainstalowane estmp. Chyba jest to rozwiązanie 'standardowe’ w Fedorze. Dziwnie działało, potrafiło mi zjeść całego core’a, także beż żalu zmieniłem na lepiej mi znanego postfixa.

W logach odkryłem, że z postfixem też coś nie halo:

laPtak postfix/postdrop[7937]: warning: unable to look up public/pickup: No such file or directory

Rozwiązanie:

sudo mkfifo /var/spool/postfix/public/pickup
sudo systemctl restart postfix