Baszarek 5: Zwykłe Narzędzia

Wracamy do słuchania. Dzisiaj zajmiemy się wpływem narzędzi, których używam do programowania, na cały swój „warsztat” oraz, co nie było dla mnie wcześniej całkiem oczywiste, pisania zupełnie różnego kodu.

ściągnij odcinek | posłuchaj przez youtube

Zaszufladkowano do kategorii podkasty | Otagowano , | Możliwość komentowania Baszarek 5: Zwykłe Narzędzia została wyłączona

Pad serwera na OVH

Dzisiaj wieczorem udało mi się „przyłapać” OVH na niedostępności serwera. Przeglądając panel klietna zauważyłem, że z moim VPSem wszystko jest w porządku, a ssh zgłaszał przy próbie połączenia

ssh: connect to host ip.ip.ip.ip port 22: Network is unreachable

Jest to o tyle pocieszające, że po prostu coś się stało ze switchem po drodze. W tego typu przypadkach pewną pomocą może być strona http://travaux.ovh.com/vms/index_gra1.html , gdzie widać na bieżąco co się dzieje w serwerowniach.

Zaszufladkowano do kategorii stdout | Możliwość komentowania Pad serwera na OVH została wyłączona

Bash i zawijanie linii

Bash ma historię wpisywanych w terminal rzeczy. To bardzo dobrze. Używając strzałek w górę oraz w dół można przeglądać ostatnio wpisywane rzeczy. To również bardzo dobrze. W czym więc problem? Skąd właściwie bash wie, gdzie kończy się nasz prompt, a zaczyna historia? Skąd wie, gdzie umieścić znaki polecenia, które przekracza jedną linię?

Ano może sobie policzyć na której kolumnie terminala kończy się prompt, a na której zaczyna moje pisanie. Problem jest taki, że Bash liczy sobie znaki niedrukowane, na przykład kody kolorów, czy inne tego typu rzeczy. Oczywiście rachunek wychodzi błędnie, ponieważ ilość znaków w PS1 nie równa się tym wypisywanym na terminalu. Wynikiem tego są takie kwiatki:

[ lukasz@GAZEvim .bashrc

Jak temu zaradzić? Obszerne wyjaśnienie problemu jest na stronie Stack Exchange. Ja podam tylko wybrane przeze mnie rozwiązanie, polegające na wyciągnięciu niedrukowanych znaków do zmiennych i opatrzeniu ich numerkami:

green="\001$(tput setaf 2)\002"
blue="\001$(tput setaf 4)\002"
dim="\001$(tput dim)\002"
reset="\001$(tput sgr0)\002"
PS1="$green\u@\h $blue $ \n  $green->$reset  "
export PS1
unset green blue dim reset

Ło matko, co to jest? W zmiennych z kolorami oraz zmiennej resetującej kolor tłumaczymy Bashowi jak krowie na polu, że $(tput setaf 2) ma liczyć jako jeden znak. Czy te zmienne są niezbędne? Nie, ale bez nich czytelność linijki PS1 byłaby niewielka. Nazwy tych zmiennych oraz kolory ustawiane setafem nie mają oczywiście znaczenia. Dzięki nim unikamy znaków niedrukowanych w prompcie i bash wie, gdzie zacząć moje pisanie.

Zaszufladkowano do kategorii #!/kody | Otagowano , | Możliwość komentowania Bash i zawijanie linii została wyłączona

SeLinux i Nextcloud

Zainstalowałem sobie NextClouda na CentOSie 7, ale SeLinux miał wątpliwości. Zlokalizowanie stosownych katalogów do ustawienia httpd_sys_rw_content_t zajęło mi naprawdę sporo czasu. Zakładając, że używasz Apache oraz trzymasz swój program w /vaw/www/html/nextcloud, oto one:

semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/html/nextcloud/data(/.*)?'
semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/html/nextcloud/3rdparty/aws/aws-sdk-php/src/data/logs(/.*)?'
semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/html/nextcloud/config(/.*)?'
semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/html/nextcloud/apps(/.*)?'
semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/html/nextcloud/.htaccess'
semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/html/nextcloud/.user.ini'
restorecon -Rv '/var/www/html/nextcloud/'
setsebool -P httpd_can_network_connect on

Po dopełnieniu tych formalności zaczyna działać. No, prawie. Po każdej aktualizacji NextCloud zwraca wiadomość, że jest nieudana. Dotychczas nie zdarzyło mi się, żeby ta informacja była prawdziwa. Wszystko zawsze przebiega gładko.

Więcej o działaniu semanage możesz przeczytać tutaj. A więcej o Selinuksie dla NextClouda jest tutaj.

Zaszufladkowano do kategorii stdout | Możliwość komentowania SeLinux i Nextcloud została wyłączona

Flathub i CentOS i Gnome

CentOS ma swoje zalety, podobnie jak wszystkie inne klony Red Hata i sam RHEL oczywiście. Ma też swoje wady, takie jak niewielka ilość oprogramowania w repozytorium. Tak jak lubię mieć sprawdzone i wolne od dziur oprogramowanie, tak czasami potrzebuję po prostu oprogramowanie, a tu go nie ma.

Poniżej przedstawiam scenariusz instalacji najnowszej wersji rewelacyjnego Gnome-Calendar, który widzi moje kalendarze z Nextcloud. Jak dotąd nie widziałem bardziej czytelnego, lepiej zintegrowanego z resztą pulpitu oraz sieciowymi serwisami programu, oprócz Lotus Organizer 5, który jest klasą sam dla siebie. 🙂

Najpierw zainstalujemy flatpak, czyli coś pomiędzy RPM, a kontenerem. Razem ze konkurencyjnymi Snap oraz AppImage wnosi powiem świeżości w nieco staroświecki sposób dystrybucji oprogramowania na Linuskie i pozwala programistom rozprowadzić gotowe, skompilowane oprogramowanie bez pośrednictwa dystrybucji. Oczywiście zawsze coś za coś. Jeżeli program wymaga jakiś zależności, programista musi je dostarczyć, co wiąże się często z dublowaniem tych samych bibliotek w działającym systemie, co jest antytezą klasycznie linuksowego, czystego i bardzo wydajnego podejścia „jedna wersja biblioteki do wszystkiego i umawiamy się, że używamy właśnie tej”. Czasami jednak poszukiwany przez nas program wymaga nowszej, i co wtedy? Wtedy pomaga flatpak. A więc:

yum install flatpak
flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

co da nam zarówno samego flatpaka, jak i dostęp do zasobów flathuba, zawierającego wiele już przygotowanych programów. Flathub generalnie nie jest wymagany i ma się do Flatpaka mniej więcej jak Github do Gita, ale jest na nim wiele Gnomowych programów. Instalujemy więc nasz kalendarz:

 flatpak install flathub org.gnome.Calendar

Po kilku pytaniach i potwierdzeniach możemy uruchomić kalendarz jak każdy inny program.

Zaszufladkowano do kategorii $polecenia | Otagowano , , , | Możliwość komentowania Flathub i CentOS i Gnome została wyłączona

Obczajamy idraca

Ta galeria zawiera 7 zdjęć.

Serwery Della, w tym mój R710, mają w obudowie miejsce na mały komputerek o nazwie iDRAC, czyli integrated Dell Remote Access Controller. Cóż to jest? Jest to działająca nieprzerwanie płytka elektroniki, podłączona do wszelkich możliwych sensorów wewnątrz urządzenia. Ma nawet … Czytaj dalej

Więcej galerii | Możliwość komentowania Obczajamy idraca została wyłączona

Robimy klucz GPG

Co jakiś czas mam potrzebę coś zaszyfrować, a potem odszyfrować. Posługuję się programem gpg. Nie wdając się w technikalia:

gpg --gen-key

uruchomi prosty kreatorek do generowania plików kluczy. Na trzy pierwsze pytania: rodzaj klucza, rozmiar klucza i czas przedawnienia nie odpowiadam, wciskając enter i pozostawiając ustawienia domyślne, czyli RSA and RSA, 2048, 0. Następnie podaję swoje imię i nazwisko (w zasadzie można wpisać cokolwiek). Tutaj radzę unikać polskich znaków, gdyż nigdy nie wiadomo jakie locale się trafi na jakiej maszynie i prędzej czy później będziemy oglądać krzaczki. Dalej podaję email (prawdziwy, lub nie). Potem gpg prosi o krótki komentarz do klucza, którego nie wpisuję i naciskam enter.

Teraz zaczyna się magia. 🙂 Powinniśmy dać komputerowi coś do roboty, by uzbierał sobie dużą ilość losowych danych, na których gpg będzie mógł pracować. Ja akurat miałem Pythona do skompilowania, ale może to być cokolwiek. Po kilku minutach nasz błyszczący klucz prywatny oraz publiczny znajdzie się w katalogu ~/.gnupg. Dobra… ale jeżeli mam więcej niż jeden komputer? Nie mogę wygenerować nowego klucza, podpisać się na nim tym samym imieniem oraz nazwiskiem oraz oczekiwać, że będzie identyczny.

Gpg przewiduje eskport oraz import kluczy. Eksport klucza publicznego i prywatnego:

gpg -a --export > publiczny.asc
gpg -a --export-secret-keys > prywatny.asc

Pliki te należy przenieść na drugi komputer w bezpieczny sposób, na przykład przez scp. Importujemy je tak:

gpg --import publiczny.asc
gpg --import prywatny.asc

Od teraz mamy identyczne klucze na dwóch różnych komputerach. Możemy się upewnić, że są na miejscu za pomocą:

gpg --list-keys
Zaszufladkowano do kategorii $polecenia | Otagowano , , | Możliwość komentowania Robimy klucz GPG została wyłączona

Nie ma Pythona 2

Szukając Pythona do ściągnięcia ze strony Python.org trafiłem na ciekawostkę:

A gdzie 2? 🙁

nie ma Pythona 2. Jeżeli się trochę przeklikać, trafimy oczywiście na wersję 2.7.14 oraz wszystkie wcześniejsze, ale nie są w żaden sposób wyeksponowane. Jako, że zegar tyka coraz mocniej, nie ma się czemu dziwić, ale zaczynałem na Pythona 2.2 i jakoś jednak jest dziwnie. 🙂 To jak jakby po latach się zorientować, że nie można już kupić Windowsa 2000, albo gumy do żucia Turbo.

Zaszufladkowano do kategorii stdout | Otagowano , | Możliwość komentowania Nie ma Pythona 2 została wyłączona

dnf makecache

Fedora, podobnie zresztą jak kilka innych dystrybucji, ma pewną upierdliwą właściwość: menedżer pakietów co jakiś czas pobiera informacje o tym, co się zmieniło w repozytoriach. Na szybkim łączu i z szybkim procesorem nawet bym tego nie zauważył, ale na laptopie od razu wiem kiedy dnf się włącza. Szczęśliwie można się tego pozbyć:

sudo systemctl mask dnf-makecache
sudo systemctl mask dnf-makecache.timer

a dla Red Hata, CentOSa, Scientifica i starych wersji Fedory:

sudo systemctl mask yum-makecache
sudo systemctl mask yum-makecache.timer

i już. Nie to, żeby makechache nie był całkiem sensownie zrobiony: nie uruchamia się podczas pracy na baterii oraz przy pracy bez wifi. Dnf i tak będzie odświeżał cache przy okazji ręcznej instalacji, aktualizacji oraz szukania pakietów, czyli dokładnie wtedy, kiedy tego potrzebuję.

Zaszufladkowano do kategorii $polecenia | Otagowano , | Możliwość komentowania dnf makecache została wyłączona