Co jest najprzyjemniejsze po całym dniu pracy? Dźwięk zamykanej klapki laptopa. Pyk i masz wolne. Ufff

Ale co wtedy dzieje się na systemie? To zależy od tego jak jest skonfigurowane zdarzenie Lid closure.

Na moim ulubionym Ubuntu chcę, aby po zamknięciu klapki, system się zhibernował. Oto, co należy zrobić, żeby system się hibernował po zamknięciu laptopa.

• Najpierw sprawdzamy, czy hibernacja w ogóle działa. Sprawdzisz to poleceniem

sudo systemctl hibernate

• Po ponownym włączeniu można prześledzić, co odbiło się w logach:

sudo cat /var/log/syslog | grep "hibernation"

Powinno się tu udać wypatrzyć między innymi zdarzenia hibernation entry i hibernation exit

• teraz pozostaje konfiguracja zdarzenia „zamykania klapki laptopa”. Otwórz plik  /etc/systemd/logind.conf

sudo vim /etc/systemd/logind.conf

Tutaj trzeba poszukać linijek

HandleLidSwitch=hibernate
HandleLidSwitchExternalPower=hibernate

HandleLidSwitch odpowiada za zdefiniowanie akcji, która ma być wykonana po zamknięciu klapki, gdy komputer nie jest podłączony do ładowarki, a HandleLidSwitchExternalPower odpowiada za tą samą sytuację, gdy komputer jest podłączony do ładowarki.  U mnie obie akcje są skonfigurowane na hibernate.

• Po zapisaniu pliku należy zrestartować usługę systemd-login:

sudo systemctl restart systemd-logind.service

• Właściwie już można zamknąć klapkę, poczekać, otworzyć, zalogować się i zajrzeć do pliku /var/log/syslog, żeby upewnić się, czy hibernacja została rzeczywiście wykonana:

sudo cat /var/log/syslog | grep "hibernation"

• Jeśli nie, to spróbuj jeszcze zrestartować komputer. Koniec końców powinno zadziałać

Świeżo po instalacji znakomite narzędzie jakim jest PGAdmin4 nieco rozczarowało, bo działało okropnie wolno… Oto co pomogło (przynajmniej w pewnym stopniu).

Domyślnie serwer postgresql nasluchiwal na porcie 127.0.0.1 i w tym przypadku to śmiało wystarczało 🙂

Polecenie

show listen_addresses; 
 listen_addresses 
------------------
 localhost

pokazywało tylko adres localhost. Gdzieś jednak znalazłem info, żeby przełączyć go również na obslugę ipv6:

alter system set listen_addresses = '127.0.0.1,::1';
ALTER SYSTEM

Po restarcie:

sudo systemctl restart postgresql

listen_addresses zmienił swoją wartość na

show listen_addresses;
 listen_addresses 
------------------
 127.0.0.1,::1

A pgadmin4 po rozłączeniu i ponownym połączeniu działał znacznie lepiej 🙂

PGAdmin4 to aplikacja webowa stworzona w Python-Flask pozwalajaca na prace z baza danych PostgreSQL w interfejsie graficznym. Oto jak zainstalowac PGAdmin4 na Ubuntu:

Jak zwykle należy rozpocząć od aktualizacji:

sudo apt update

Teraz podłączamy repozytorium z PGAdmin4:

curl https://www.pgadmin.org/static/packages_pgadmin_org.pub | sudo apt-key add
sudo sh -c 'echo „deb https://ftp.postgresql.org/pub/pgadmin/pgadmin4/apt/$(lsb_release -cs) pgadmin4 main” > /etc/apt/sources.list.d/pgadmin4.list && apt update’

I już można instalować:

sudo apt install pgadmin4

Niestety to nie koniec instalacji. Na tym kroku na komputerze powinien już działać Apache2 i w katalogu /etc/apache2 powinien się nawet znajdować plik odpowiadający za konfigurację PGAdmin4. Niestety na razie jeszcze nieaktywny. Żeby go uaktywnić trzeba jeszcze uruchomić polecenie:

sudo /usr/pgadmin4/bin/setup-web.sh

Podczas konfiguracji trzeba podać poprawny adres email i potwierdzić instalację i restart usługi Apache2. Kiedy wszystko się zakończy można zacząć pracę z PGAdmin4 odwiedzając stronę:

http://127.0.0.1/pgadmin4

Zwróć uwagę, że logowanie do pgadmin jest dwuetapowe. Najpierw należy sie zalogować do aplikacji webowej pgadmin i tu możesz wykorzystać adres email i hasło wprowadzone podczas pracy setup-web.sh.

Następnie dodając serwer PostgreSQL należy podać nazwę użytkownika itniejącego w tej bazie danych.

Dodajmy, że instalując pgadmin4 na komputerze, instaluje się też aplikacja standalone pgadmin-desktop. Bardzo wygodna, jeśli myślisz o skonfigurowaniu środowiska tylko dla siebie, chciażby dlatego, że skrypty nie będą się zapisywały w dziwnej lokalizacji /var/lib/pgadmin/storage/<user_name>, tylko tam, gdzie sam/a zechcesz 🙂

W konfiguracji pewnego programu musiałem podać subnetid, ale w portalu Azure nie udało mi się tej informacji znaleźć. Jest id dla VNET, ale dla subnet widać już tylko dość praktyczne informacje, a subnetid, raczej taką nie jest.

Po pierwsze wyświetliłem wszystkie informacje o podsieciach sieci:

az network vnet subnet list --resource-group MY_RESOURCEGROUP_NAME --vnet-name MY_VNET_NAME

Polecenie jak najbardziej zadziałało i wyświetliło to co trzeba, ale lista była dość długa, a mi przecież chodziło tylko o szczegóły jednego obiektu. No to jazda dalej:

az network vnet subnet show --resource-group MY_RESOURCEGROUP_NAME --vnet-name MY_VNET_NAME --name  MY_SUBNET_NAME

No i to był już całkiem fajny wynik

Czasami na serwerze trzeba zainstalować tylko narzędzia klienckie, np sam tylko psql. Oto kroki do wykonania w takim przypadku. Załóżmy, że na serwerze chcę zainstalować narzędzia z wersji 14.

Jak zwykle należałoby zacząć od aktualizacji systemu i pakietów do najnowszych wersji:

sudo apt update && sudo apt upgrade

Podczas instalacji na systemie przydadzą się też pakiety pnupg2 wget i vim. Być może już są zainstalowane, ale na wszelki wypadek można uruchomić:

sudo apt -y install gnupg2 wget vim

Jeśli masz szczęście, to potrzebne pakiety mogą już być widoczne w repozytorium i wystarczy je tylko zainstalować. Sprawdzisz to poleceniem:

sudo apt-cache search postgresql | grep postgresql

W wyniku możesz poszukać czegoś w tym stylu „postgresql-client-14”. Załóżmy jednak, że pakietu tam nie ma. W takim przypadku można wskazać na repozytorium, gdzie takie pakiety są:

sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'

Repozytorium wymaga klucza, który należy pobrać:

wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -

No i teraz ponownie można odświeżyć listę pakietów:

sudo apt -y update

Po czym pakiet postgresql-client-14 (a nawet i cały pakiet postgresql-14) powinny już być dostępne i dlatego można je zainstalować:

sudo apt -y install postgresql-client-14

Do sprawdzenia wersji psql uruchom:

psql --version

To bardzo wygodne, kiedy łącząc się przy pomocy putty do Linuxa, nie trzeba podawać hasła. Takie rzeczy są w świecie Linuxowym znane jako uwierzytelnienie kluczem prywatnym. O tym jak taki klucz wygenerować pisałem tutaj: Mobilo » Blog Archive » Linux: Generowanie klucza SSH do logowania bez hasła (mobilo24.eu)

Niestety ten klucz prywatny nie nadaje się do bezpośredniego użycia w putty. Można go skonwertować. Oto jak:

1. Otwórz program Putty Gen – jest elementem pakietu putty
2. Wybierz polecenie Convertions >> Import Key. Poszukaj pliku klucza prywatnego. Jeśli go nie widzisz w katalogu, to w oknie „Load private key” zmień filtr na wyświetlane pliki na All Files (*.*)
3. Jeśli trzeba podaj hasło do otwarcia pliku.
4. Zapisz klucz prywatny klikając „Save Private Key”.
5. Skorzystaj z klucza w putty:
   1. Connection >> Data – podaj nazwę użytkownika w polu auto-login username
   2. Connection >> SSH >> Auth – wskaż na plik ppk z zapisanym w 4-tym kroku kluczem.  Ścieżka powinna się pojawić w polu private key file for authentication
   3. Zapisz zmiany dokonane w sesji
6. Wykonaj testowe połączenie

Jeśli masz problem z połączeniem zobacz, jak go zdiagnozować: Mobilo » Blog Archive » Linux: ssh: debug: server refused our key (mobilo24.eu)

Prosta sprawa – ale prosta, dopiero jak się wie. Póki się nie wiedziało… to efekt był taki, że mimo logowania za pomocą klucza prywatnego i publicznego klient dostawał ciągle odpowiedź „server refused our key”.

Mniej więc tutaj chcę się skupiać na rozwiązaniu konkretnego problemu, a bardziej na tym, jak diagnozować ten problem. A diagnozowanie jest proste.

1. Na serwerze (bo przecież to server odrzuca klucz) przejdź do pliku konfiguracyjnego sshd:

sudo vim /etc/sshd/sshd_config

2. W tym pliku dodaj linijkę:

LogLevel DEBUG3

3. Zrestartuj sshd:

sudo systemctl restart sshd

4. Przeprowadź kolejne logowanie, które pewnie zakończy się błędem „server refused our key”

5. Przeszukaj zawartość pliku /var/log/auth.log lub /var/log/secure (nazwa pliku może się różnić w zależności od wersji).

No i na tym można by skończyć, bo przykładowy wpis w pliku log może być taki:

Jun 24 18:18:48 u20 sshd[22912]: debug1: temporarily_use_uid: 1000/1000 (e=0/0)
Jun 24 18:18:48 u20 sshd[22912]: debug1: trying public key file /home/boss/.ssh/authorized_keys
Jun 24 18:18:48 u20 sshd[22912]: debug1: Could not open authorized keys '/home/XXX/.ssh/authorized_keys': No such file or directory
Jun 24 18:18:48 u20 sshd[22912]: debug1: restore_uid: 0/0
Jun 24 18:18:48 u20 sshd[22912]: debug1: temporarily_use_uid: 1000/1000 (e=0/0)
Jun 24 18:18:48 u20 sshd[22912]: debug1: trying public key file /home/XXX/.ssh/authorized_keys2
Jun 24 18:18:48 u20 sshd[22912]: debug1: Could not open authorized keys '/home/XXX/.ssh/authorized_keys2': No such file or directory
Jun 24 18:18:48 u20 sshd[22912]: debug1: restore_uid: 0/0
Jun 24 18:18:48 u20 sshd[22912]: debug3: mm_answer_keyallowed: publickey authentication test: RSA key is not allowed

Innymi słowy, chociaż klucz publiczny miał być w katalogu .ssh, to jednak go tam nie było 🙂 Głupotka….

Zauważ, że ten rodzaj błędu był logowany na poziomie debug1, a my w pliku konfiguracyjnym napisaliśmy debug3. Ten zwiększony poziom szczegółowości może się przydać np. jeśli w kluczu straciła się jedna literka. Ten rodzaj informacji jest logowany na poziomie 3.