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.

Baldur's Gate 3

Baldur’s Gate 3 Steam/Linux, problemy z instalacją

Aplikacje, Gry, , ,

Zapewne szybko to poprawią, ale kiedy to piszę Baldur’s Gate 3 Steam nie działa po instalacji. Rozwiązanie okazuje się być dość proste:

sudo dnf install python3-pip python3-setuptools python3-libs pipx
pipx install protontricks
protontricks 1086940 dotnet48

O co chodzi? Protontricks to Winetricks skonfigurowane do pracy ze Steamem.
1086940 to id gry Baldur’s Gate
A dotnet48, to brakujący kawałek softu przez który gra nie próbuje nawet wystartować.

Chroot w rescue mode (np. OVH)

Aplikacje, Linux, ,

Miałem ostatnio sytuację z niedziałającym VPS’em w OVH. Jedyna opcja na naprawę VPS to – rescue mode i dostanie się 'z boku’ do systemu.

Jak to zrobić dobrze?

# mkdir -p /mnt/myos
# mount /dev/sdXX /mnt/myos
# mount -t proc proc /mnt/myos/proc
# mount --rbind /dev /mnt/myos/dev
# mount --rbind /sys /mnt/myos/sys
# chroot /mnt/myos /bin/bash

W moim przypadku dyskiem vps’a jest /dev/sdb1. Jeżeli nie wiesz jaki dysk powinieneś podać, użyj komend 'lsblk’ i 'blkid’.

Możemy teraz wprowadzać zmiany mniej więcej tak samo jakby nasz system działał.

Jeżeli używamy selinuxa i wprowadzaliśmy jakieś zmiany, dobrze jest na koniec prac wykonać:

# touch /.autorelabel

wymusi to przebudowanie etykiet selinuxa dla wszystkich plików.

Na koniec ctrl-d, żeby się wylogować z chroota i restart do normalnego trybu. Trzymam kciuki za poprawność wprowadzonych zmian. 🙂

logo OVH.com
logo Helm Charts

Helm instalacja

DevOps, Kubernetes

Niby wszystko opisane na stronie, ale jakoś nie do końca…

A co to ten Helm?
To narzędzie do zarządzania 'Kubernetes charts’. A Charts to nic więcej jak definicje jak uruchamiać aplikacje na Kubernetesie. Taki system pakietów.

Repo Debian/Ubuntu x86_64:

curl https://helm.baltorepo.com/organization/signing.asc | sudo apt-key add -
sudo apt-get install apt-transport-https --yes
echo "deb https://baltocdn.com/helm/stable/debian/ all main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list
sudo apt-get update
sudo apt-get install helm

Fedora – nie ma repozytorium 🙁
Repo powyżej nie działa też na Raspbery HypriotOS. Brakuje pakietu dla architektury.
Ale to nie problem.
Fedora – Opcja 1 (wrzucenie binarki skryptem):

$ curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3
$ chmod 700 get_helm.sh
$ ./get_helm.sh

Fedora – Opcja 2 (snapd):

(jeżeli nie masz snapd)
$ sudo dnf install snapd
$ sudo ln -s /var/lib/snapd/snap /snap
(instalacja helma)
$ sudo snap install helm --classic

HypriotOS – Opcja 1 (snapd):

$ sudo apt install snapd
$ sudo snap install helm --classic
(uruchamianie)
$ /snap/bin/helm

HypriotOS – Opcja 2 (binarka):

  1. Ze strony z releasami Helma ściągnij sobie odpowiednią binarkę.
  2. Rozpakuj
  3. Przenieś plik 'helm’ np. do /usr/local/bin

Logo Firefox

Firefox, która zakładka żre CPU? Monitoruj wydajność Firefoxa

Aplikacje, ,

Trywialna sprawa. Bazylion zakładek. Top pokazuje, że 'Web Content’ obciąża cały core. U mnie wydajność Firefoxa ściśle przekłada się na prędkość działania wentylatorów, także to ważne pytanie – jak namierzyć która?

Okazuje się, ze nowsze wersje Firefoxa mają Manager zadań. Żeby go uruchomić, wystarczy w pasku na URL wpisać:

about:performance

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