Czy wiesz o tym, że katalog /tmp w Linuxie ma w specjalny sposób zdefiniowane uprawnienia? Owszem każdy może w tym katalogu pisać, ale wzajemna modyfikacja plików przez użytkowników z tej samej grupy nie działa. W sumie ma to sens, bo gdyby w takim /tmp każdy mógł robić wszystko, to zrobiłby się niezły bałagan.

Najpierw przyjrzyjmy się jak to działa w „normalnych katalogach”:

rafal@fermat:~$ sudo mkdir /home/shared
rafal@fermat:~$ sudo chmod 777 /home/shared

Teraz „stajemy się użytkownikiem user2, który ma swoją własną grupę user2:

rafal@fermat:~$ sudo su - user2
$ id
uid=1002(user2) gid=1002(user2) groups=1002(user2)
$ cat >> /home/shared/test.txt
my test user2
$ ls -l /home/shared/test.txt
-rw-rw-r-- 1 user2 user2 14 maj 20 11:26 /home/shared/test.txt

Teraz spróbujemy ten plik zmodyfikować. Modyfikację wykona użytkownik user1, który jest też członkiem grupy user2:

rafal@fermat:~$ sudo su - user1
$ id
uid=1001(user1) gid=1001(user1) groups=1001(user1),1002(user2)
$ cat >> /home/shared/test.txt
my test user 1
$ ls -l /home/shared/test.txt    
-rw-rw-r-- 1 user2 user2 29 maj 20 11:27 /home/shared/test.txt

Jak widać zmiana się udała. To teraz zobaczmy jak to zadziała w katalogu tmp z ustawionym sticky bit. Do akcji wracza znowu user2:

rafal@fermat:~$ sudo su - user2
$ cat >> /tmp/test.txt
my test user2 
$ ls -l /tmp/test.txt
-rw-rw-r-- 1 user2 user2 14 maj 20 11:29 /tmp/test.txt
$ ls -ld /tmp
drwxrwxrwt 24 root root 12288 maj 20 11:29 /tmp

Teraz modyfikacje próbuje wykonać user 1 – bez sukcesu:

rafal@fermat:~$ sudo su - user1
$ cat >> /tmp/test.txt
-sh: 1: cannot create /tmp/test.txt: Permission denied

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!