Standardowo, na nowym systemie Raspberry Pi, nie trzeba podawać hasła. System bootuje się z już zalogowanym w konsoli graficznej użytkownikiem pi. Tak się jednak zdarzyło, że wskutek prób i błędów, instalacji kilku programów i ich odinstalowaniu, po re-boocie, sytem zaczął pytać o hasło. Hmm, nie jest to problem, ale problemem było to, że po podaniu hasła, system znowu o nie pytał i nie wpuszczał na pulpit, i tak w kółko….

Całe szczęście awaria dotyczyła tylko interfejsu graficznego. Po naciśnięciu Control-Shift-F2, można się przełączyć do systemu znakowego i tam już pomyślnie zalogować.

Bez owijania w bawełnę – u mnie problemem były uprawnienia do pliku .Xauthority. Wskutek zabaw, stało się tak, że właścicielem pliku był root. Możesz to łatwo sprawdzić uruchamiając w katalogu domowym polecenie:

ls -al

Prawdopodobnie wystarczy zmienić właściciela pliku na pi, ale ja go usunąłem i… wszystko wróciło do normy!

https://raspberrypi.stackexchange.com/questions/45914/raspbian-graphical-login-screen-stuck-cant-login

https://forums.raspberrypi.com/viewtopic.php?t=194764

Nie podoba Ci się pomysł korzystania z monitora i klawiatury podłączonych do Raspberry Pi? Skonfiguruj SSH i VNC! Na Raspberry Pi nie potrzebujesz do tego nawet znajomości zaawansowanych komend. Przygotowano dla nas polecenie raspi-config, które w trybie znakowym prezentuje zestaw menu pozwalający zmienić konfigurację tak, jak chcesz.

Zacznijmy od zmiany hasła dla użytkownika pi. Domyślnie to haslo to raspberry, każdy je zna, więc dla własnego bezpieczeństwa zmień je (bez zmiany hasła połączenie zdalne VNC nie będzie działać).

W linii komend wpisz

sudo raspi-config

W oknie wybierz opcję „Change User Password”:

Dalej trzeba będzie dwa razy wpisać nowe hasło (które się nie wyświetla podczas wpisywania) i gotowe!

No to jak tu włączyć SSH? Zacznij znowu od uruchomienia raspi-config i wybierz opcję „2 Interfacing Options”. W nowym menu wybierz „P2 SSH”. Teraz program poprosi Cię o potwierdzenie i… gotowe!

Od tej pory można już łączyć się do systemu zdalnie korzystając z polecenia ssh lub pod windows korzystając np. z popularnego klienta ssh Putty.

A gdyby chcieć pracować w systemie graficznym, to przydałoby się np. VNC. Tak jak poprzednio zacznymay od uruchomienia raspi-config, a następnie w menu wybieramy „2 Interfacing options” i w kolejnym menu „P3 VNC”.

Żeby podłączyć się do serwera też potrzebny jest klient zdalny. W tym przypadku najlepiej jest skorzystać z RealVNC Viewer. Po uruchomieniu programu, podaj adres ip serwera Pi, a następnie zaloguj się korzystając z konta użytkownika pi i jego hasła (pamiętaj o zmianie hasła domyślnego).

Co Ci się może nie podobać, to uzyskiwana rozdzielczość, ale i w tym przypadku z pomocą przyjdzie raspi-config. Tym razem z menu wybierz „7 Advanced Options”, potem A5 Resolution” i wybierz jedną z dostępnych wartości. U mnie, na windows mam rozdzielczość 1920×1080, dlatego dla Raspberry Pi wybrałem 1280×720. Dzięki temu okno ładnie się skaluje i nie muszę pracować w trybie pełno-ekranowym. Niestety po zmianie rozdzielczości trzeba wykonać restart

Jeśli przy połączeniu do serwera dochodzi do timeout, to można pomyśleć o zmianie wartości ConnectionTimeout w pliku /etc/ssh/ssh_config.

Otwórz ten plik edytorem, odszukaj linijki ConnectionTimeout, która domyślnie ma wartość 0 (i jest zakomentowana) i zmień jej wartość np. na wysokie 5m, np. tak:

sudo vi /etc/ssh/ssh_config

ConnectionTimeout  5m

Następnie zrestartuj serwis SSH:

sudo /etc/init.d/ssh restart

Gotowe!

Powershell Remoting albo działa albo nie 🙂  Ewentualne problemy moga się wiązać z filtrowanym ruchem sieciowym ale też z samą konfiguracją usługi WinRM, bezpieczeństwem i uwierzytelnieniem. Jeśli komputery stoją w tej samej domenie, to wiele rzeczy będzie działać „od strzału” ale jeśli komputery nie są w domenie, to mogą być problemy. Dlatego zobaczmy, jak skonfigurować remoting między lokalnym komputerem, a maszyną wirtualną w Azure.

1. Utwórz maszynę wirtualną z publicznym adresem IP. Załóżmy, że u mnie ten adres to: 20.168.197.227
2. Upewnij się, że winrm działa. Domyślnie tak powinno być, ale lepiej się upewnić
   Get-Service winrm
   
3. Wykonaj „szybką konfigurację” winrm. Domyślnie serwer będzie tylko skonfigurowany do HTTP, ale zaraz nad tym popracujemy
   winrm quickconfig
   
4. System operacyjny musi pozwalać na ruch przychodzący dla sesji zdalnych, dlatego otwieramy porty:
   netsh advfirewall firewall add rule name=”WinRM-HTTP” dir=in localport=5985 protocol=TCP action=allownetsh advfirewall firewall add rule name=”WinRM-HTTPS” dir=in localport=5986 protocol=TCP action=allow

   

5. Zauważ, że na tym etapie nasłuchujemy tylko na połączenia HTTP:
   winrm e winrm/config/listener
   
6. Wprawdzie do pełnego uwierzytelnienia sesji potrzebny byłby pełnoprawny certyfikat, to jednak w uproszczonej sytuacji można bazować na self-signed certificate. Dlatego utwórzmy certyfikat:
   $cert = New-SelfSignedCertificate -DnsName “20.168.197.227” -CertStoreLocation cert:\LocalMachine\My
   
7. Teraz można już skonfigurować listener HTTPS:
   winrm create winrm/config/Listener?Address=*+Transport=HTTPS „@{Hostname=`”20.168.197.227`”;CertificateThumbprint=`”$($cert.ThumbPrint)`”}”
   
8. Teraz polecenie uruchamiane w kroku 5, zwróci już więcej informacji:
   winrm e winrm/config/listener
   
9. Maszyna wirtualna w Azure, z pewnością korzysta jeszcze z ochrony Network Security Group. Tam również trzeba dodać wyjątki na akceptację połączeń na portach 5985 i 5986. Jak znaleźć NSG? Będzie prawdopodobnie przypisane do interfejsu sieciowego maszyny wirtualnej lub do podsieci, w której znajduje się komputer.
   Kliknij „Add inbound port rule” i zdefiniuj reguły pozwalające na połączenia skądkolwiek dokądkolwiek na portach 5985 i 5986:
   
10. To koniec konfiguracji na maszynie zdalnej. Będąc za to na maszynie lokalnej, warto sprawdzić, czy komunikacja jest rzeczywiście otwarta. Reguły NSG potrzebują czasami trochę czasu do aktywacji:
    Test-NetConnection -ComputerName 20.168.197.227 -port 5985
    Test-NetConnection -ComputerName 20.168.197.227 -port 5986
    
11. Ok, to pora na testowe połączenie. Można to zrobić tak:
    $options = New-PSSessionOption -SkipCACheck
    $credentials = Get-Credential
    cmdlet Get-Credential at command pipeline position 1
    Supply values for the following parameters:
    Credential
    $session = New-PSSession -ComputerName 20.168.197.227 -UseSSL -SessionOption $options -Credential $credentials
    Invoke-Command -Session $session { echo $env:COMPUTERNAME }
    remotesrv
    echo $env:COMPUTERNAME

    Tworzymy tu obiekt opcji, w którym deklarujemy się zaakceptować self-signed certificate, następnie pobieramy nazwę użytkownika i hasło, po czym można utworzyć obiekt sesji. Ten obiekt sam w sobie zawiera już połączenie do zdalnej maszyny. Dlatego w następnym kroku, można już uruchomić Invoke-Command do zdalnej maszyny i zapytać ją jak się nazywa. Tą nazwę można porównać z nazwą lokalnego komputera. Nazwy powinny się różnić:
    

Oryginalna instrukcja:

https://techdiksha.com/configuring-winrm-azure-virtual-machine/

Zdarza mi się, że po spotkaniu/szkoleniu umówię się z uczestnikami, że otworzymy sobie wspólnego czata. Czasami czatować da się bezpośrednio w Teams w ramach czatu dostępnego podczas spotkania, ale niekiedy konfiguracja jest taka, że po spotkaniu czat znika i już.

Załóżmy więc, że mam po prostu 20 adresów email. Czy czeka mnie teraz wpisywanie każdego adresu do pola wyszukiwania i klikanie dla każdego uczestnika osobno? Wcale nie!

Można stworzyć odpowiedni URL o takiej oto postaci:

https://teams.microsoft.com/l/chat/0/0?users=bartek@adres1.com,borys@adres2.com,darek@adres3.com,&topicName=BurzaMozgow&message=Cześć!

Ot po prostu w parametrze users= należy podać rozdzielone przecinkami adresy email, po topicName podać nazwę grupki do utworzenia, a po message pierwsza wiadomość.

Kiedy adres URL będzie już gotowy, przeklej go do przeglądarki, naciśniej Enter i…. uruchomi się Teams z gotową do wysłania do wszystkich osób wiadomością. Popraw co trzeba, kliknij wyślij i gotowe!

Zwykle otrzymując komunikat ModuleNotFoundError wskazujący na jakąś tam nazwę np. tutaj sklearn rozwiązujemy problem komendą:

pip install sklearn

Ale w Python 3.x trzeba zainstalowć w tym przypadku inny moduł 🙂 – ot taka niespodzianka:

pip install scikit-learn

I niech błędy trzymają się od nas z daleka!

PG Admin daje możliwość zapisania haseł wykorzystywanych do połączenia się do serwerów PostgreSQL. Dzięki temu administrator nie musi ich wprowadzać za każdym razem na nowo. Czy to dobra praktyka, żeby najważniejsze hasła zapisać lokalnie na dysku (nawet w zaszyfrowanej postaci)? Powiedziałbym, że nie, ale się da…. Jeśli zapomnisz tego hasła do haseł (master password) to możesz je łatwo zresetować. Oto jak:

1 – Na stronie pytającej o master password wybierz „Reset Master Password”

2 – Potwierdź, że definitywnie nie pamiętasz master password i zgódź się na zapomnienie wszystkich pozostałych haseł (oznacza to tyle, że do kazdego serwera przy połączeniu trzeba będzie podać nazwę użytkownika i hasło):

3 – Teraz można zdefiniować nowy master password:

4 – Teraz przy połączeniu do serwera, trzeba podać hasło związane z tym serwerem i wybranym użytkownikiem. Mam nadzieję, że je pamiętasz, a jeśli nie, to zajrzyj tu: https://www.mobilo24.eu/postgresql-zapomniane-haslo-jak-zresetowac-haslo/