Archiwum kategorii: Linux

KeePass, jako alternatywa dla Google Authenticator, czyli 2-step Verification

Przyznam się bez bicia, że do niedawna jeszcze korzystałem z Google Authenticator, do podwójnej weryfikacji (tzw. 2-step Verification, aka. 2fa). Gdzieś z tyłu głowy siedzi sobie myśl, by uwolnić się od Google, ile tylko się da, a dodatkowo GAuth ma pewien problem – nie da się zrobić kopii zapasowej kluczy. Już raz utraciłem dostęp do kont i musiałem go odzyskiwać. Jedyna opcja na kopię, to przeniesienie kluczy na inne urządzenie i potem powrót na urządzenie właściwe.

To było takim zapalnikiem by poszukać innego rozwiązania. Pierwszym wyborem miał okazać się Aegis Authenticator. W zasadzie tylko dlatego, że rozwiązywał problemy/braki, które posiadał GAuth, czyli:

  1. Możliwość zrobienia kopii zapasowej (nie bez powodu #1 na liście);
  2. Nie jest od Google i/lub jest OpenSource;

Ale gdzieś pomiędzy komentarzami, przewinął się KeePass. I tutaj było moje zdziwienie, bo z ów menadżera haseł korzystam z mniejszymi, lub większymi przerwami od bardzo dawna. Nie wiedziałem, że posiada on taką funkcję wbudowaną. Dodatkowo dzięki niemu jest możliwość korzystania z haseł jednorazowych bezpośrednio na komputerze, z pominięciem telefonu. Rozwiązanie o tyle genialne w swojej prostocie, że:

  1. Nie potrzebuję telefonu by się zalogować;
  2. Jak zgubię telefon, nie tracę dostępu do kont;
  3. Mam bazę w kilku miejscach (czytaj bezpieczeństwo).

Wziąłem się więc za pełną migrację z GAuth na KeePass.


Niedziałające WiFi na starym laptopie z Debianem 10.10

Na dnie szafy spoczywał u mnie stary laptop MaxData. Z racji na to, że Windows XP jest mocno po terminie, a laptop w takowy fabrycznie był wyposażony, to pozostało mi zainstalować jakiegoś pingwinka. Wielkiego pola do manewru tutaj też nie było, ponieważ działa on jeszcze na 32 bitowej architekturze. Wstępnie miał tam stanąć {{Ubuntu}}, lecz x86 porzucili w 2018 roku (owszem jest jeszcze LTS 18.04). Stanęło na {{Debian|Debiana}}, który wspiera jeszcze x86. Jeden jedyny problem, jaki napotkałem w trakcie konfiguracji, to niedziałające WiFi. Co też po krótkim researchu udało się ogarnąć.

Włączenie repozytoriów non-free

Pierwsza rzecz do zrobienia – włączenie repozytoriów non-free. Problemem bowiem okazuje się sterownik, który nie wspiera tak starego modułu WiFi. No i oczywiście potrzeba połączyć się kabelkiem z siecią ;).

sudo nano /etc/apt/sources.list
deb http://deb.debian.org/debian buster main contrib non-free
deb-src http://deb.debian.org/debian buster main contrib non-free
 
deb http://deb.debian.org/debian-security/ buster/updates main contrib non-free
deb-src http://deb.debian.org/debian-security/ buster/updates main contrib non-free
 
deb http://deb.debian.org/debian buster-updates main contrib non-free
deb-src http://deb.debian.org/debian buster-updates main contrib non-free
sudo apt update
sudo apt upgrade

Instalacja „starego” sterownika

sudo apt install firmware-iwlwifi

Tyle. Ma działać.


Instalacja WireGuard na Ubuntu 19.10

Po kilku latach korzystania z {{VPS}} na {{OpenVZ}} u ViPower.pl – nadszedł czas na zmiany. Po pierwsze, zmiana usługodawcy – i tutaj padło na OVH.pl. Po drugie, postanowiłem zmienić system wirtualizacji na {{Kernel-based_Virtual_Machine|KVM}}. Po trzecie, w związku z przenosinami, chciałem zmienić dystrybucję z {{CentOS}} na {{Ubuntu}}. A po czwarte i ostatnie, skoro już wszystko konfigurowałem od zera, naszło mnie na zmianę {{OpenVPN}} na {{WireGuard}}, o którym czytałem sporo dobrego.

Konfiguracja i instalacja {{WireGuard|WireGuarda}} to czysta poezja. W przeciwieństwie do {{OpenVPN}} nie było żadnych kombinacji i komplikacji. Tym bardziej, że w moim przypadku tunel działa zarówno w celu przekierowywania całego ruchu przez serwer, jak i tworzenia sieci wewnętrznej. Jedyne problemy, na jakie napotkałem, dotyczyły wyłącznie konfiguracji firewalla i przekierowywania przez niego ruchu. Wszystkie opisy, jakie znajdywałem, nie rozwiązywały mojego problemu. Pomocny okazał się mój wpis sprzed lat z konfiguracji OpenVPN i te same reguły dla iptables.


Ubuntu 16.10 jako główny OS, podejście xxx

Lat temu kilka, porzuciłem Windowsa, jako mój główny system operacyjny, na rzecz Ubuntu, Mandrivy oraz openSUSE. Tak przez dwa lub więcej lat. Później nadszedł czas, że powróciłem do Windowsa, bowiem W7 miał wszystko, co potrzebowałem i działał bezproblemowo. Czego o Linuksie nigdy powiedzieć tego nie mogłem – sprawiało mi to frajdę, że coś tam trzeba było zrobić.

W roku pańskim 2017 postanowiłem dać szansę pingwinkowi. Postawiłem na Ubuntu, który to postrzegany jest za najbardziej user friendly. Rozwija się najszybciej i w dobrym (wg mnie) kierunku. Cóż rzec mogę… zachwycił mnie od pierwszego wejrzenia, po instalacji i aktualizacji.


Optymalizacja zużycia RAM przez MySQL na serwerze

{{MySQL}} od wersji 5.6 ma domyślnie włączone [1]Jak nietrudno się zatem domyślić – najważniejszą zmianą jest wyłączenie schematów performance_schema, które bardzo lubi konsumować {{RAM}}. Oczywiście poniekąd jest to dobre, bo czas dostępu się zmniejsza i jak to zauważył michal_s na kanale #wordpress-pl (@freenode.net), to „RAM jest wyłącznie po to, aby go używać„. Zgadzam się z tym w 100%. Jednakże w przypadku serwerów, na których mamy nieco mniejsze zaplecze, a baza zaczyna pochłaniać pamięć – pasuje coś z tym zrobić.

I tak w moim przypadku użycie {{RAM|RAMu}} przez {{MySQL}} (samego procesu MySQL) sięgało 600-700 MB, gdzie cały VPS posiada 1 GB. Dochodziło do sytuacji, gdzie ubijane były procesy, a sama baza się też wyłączała. Po niżej opisanych zabiegach zoptymalizowałem wykorzystanie pamięci do ~200 MB (ogółem, a nie samej bazy).

Nie jest to opis z serii „jestem pro wyjadaczem”, więc nie spodziewajcie się wodotrysków. Publikuję tutaj jedynie kilka zmian w domyślnej konfiguracji, które optymalizują wykorzystanie RAM.

Wyjaśnienia

Wyjaśnienia
1 Jak nietrudno się zatem domyślić – najważniejszą zmianą jest wyłączenie schematów