Zdarza sie, że do terraformowej definicji trzeba zaimportować istniejące już na Azure obiektu. Służy do tego polecenie import:

terraform import azurerm_recovery_services_vault.vault1 /subscriptions/XXX/resourcegroups/recovery-delme/providers/Microsoft.recoveryservices/vaults/recoservvault

Co zrobić jeśli komenda zakończy się błędem?

azurerm_recovery_services_vault.vault1: Importing from ID "/subscriptions/XXX/resourcegroups/recovery-delme/providers/Microsoft.recoveryservices/vaults/recoservvault"…
data.azurerm_resource_group.example: Reading…
data.azurerm_resource_group.example: Read complete after 0s [id=/subscriptions/XXX/resourceGroups/recovery-delme]
╷
│ Error: parsing "/subscriptions/XXX/resourcegroups/recovery-delme/providers/Microsoft.recoveryservices/vaults/recoservvault": parsing segment "staticResourceGroups": parsing the Vault ID: the segment at position 2 didn't match
│
│ Expected a Vault ID that matched:
│
│ > /subscriptions/XXX/resourceGroups/example-resource-group/providers/Microsoft.RecoveryServices/vaults/vaultValue
│
│ However this value was provided:
│
│ > /subscriptions/XXX/resourcegroups/recovery-delme/providers/Microsoft.recoveryservices/vaults/recoservvault
│
│ The parsed Resource ID was missing a value for the segment at position 2
│ (which should be the literal value "resourceGroups").

O co chodzi? Pierwsza różnica, jaką widać dotyczy nazwy resourceGroups, raz napisaną przez małe, a raz przez wielkie „G”. Rzeczywiście. Terraform, a może dokładniej ARM jest czuły na wielkość liter. Wystarczy zapisać resourceGroups tak, jak chciałby Terraform i wszystko zadziała jak należy!

Zwykle w MS Teams pracuje się z wykorzystaniem tylko jednego konta. Wystarczy jednak jedna nagląca potrzeba i można się przelogować na inne konto. Taka jednorazowa przygoda może zakończyć się tym, że przy kolejnych uruchomieniach Teamsa zobaczymy okienko pytające o to, z którego konta chcemy korzystać (Pick an account to continue):

I jak tu teraz usunąć to dodatkowe konto??

Mamy co najmniej 3 miejsca do przeszukania:

1. Kliknij Settings (ustawienia) >> Accounts (konta) >> Access work and school (dostęp do pracy i szkoły) >> przejrzyj konta i ewentualnie usuń niepotrzebne
2. W tym samym miejscu, czyli Settings >> Accounts >> Email & Accounts >> przejrzyj konta i usuń co nie jest potrzebne
3. Sprawdź konta wylistowane tutaj: https://myaccount.microsoft.com/

Pomysły zaczerpnąłem z Removing a saved account on MS Teams App on desktop – Microsoft Community, a u mnie zadziałała metoda nr 2

Wydaje się, że Remote Desktop Protocol, to rozwiązanie raczej ze świata Windows i z Linuxem mu nie po drodze, ale… czasami inaczej się nie da.

Zaczynamy od zainstalowania xrdp:

sudo apt-get update
sudo apt-get install xrdp

XRDP porzebuje oczywiście nasłuchiwać na porcie 3389, dlatego trzeba otworzyć ten port:

sudo ufw allow 3389/tcp

Teraz można uruchomić XRDP:

sudo systemctl restart xrdp

Teraz po stronie klienta, czyli zazwyczaj na komputerze z Windows można nawiązać połączenie przez RDP. Wystarczy podać nazwę użytkownika z Linuxa i zalogować się. Czasami zdarza się, że otrzymujemy po prostu puste okno/ekran, albo sesja początkowo poprawnie nawiązywana nagle się skończy. W takim przypadku:

• upewnij się, że na systemie Linux nie ma w tej chwili aktywnej sesji GUI
• w pliku .xsession dodaj linijkę definiującą odpwiedniego managera okien, np.:
  gnome-session –session ubuntu

Przenosząc swój komputer między różnymi sieciami WiFi, chcesz czasami wyraźnie wskazać, do której sieci należy się podłączyć. Jeśli korzystasz z GUI, to nie ma z tym problemu. Co innego, jeśli pracujesz w linii komend. Oto krótka ściąga, co można zrobić w takim przypadku.

Włączanie i wyłączanie WiFi

Polecenie

wifi on

pozwala na włączenie lub wyłączenie WiFi. Istnieją też krewniacy tej komendy, jak np. bluetooth czy nfc:

Wyświetlenie zdefiniowanych połączeń WiFi

Komenda

nmcli connection

okazuje skonfigurowane na komputerze połączenia (sieci wifi, do których kiedyś tam nawiązano już połączenie). Aktualnie podłączona sieć jest zaznaczona kolorkiem i ma wartość w kolumnie DEVICE, wskazującą na urządzenie, przy pomocy którego zestawiono to połączenie.  Tutaj widać np. aktywne połączenie do sieci Taxi przy pomocy urządzenia/interfejsu wlp1s0:

Listowanie dostępnych sieci WiFi

Polecenie

nmcli device wifi list

wyświetla w tej chwili dostępne sieci WiFi. Tutaj widać, że najlepszym jakościowo dostępnym połączeniem jest Taxi, podczas gdy np. T-Mobile-B528-06DA ma gorszą jakość:

Podobne działanie ma komenda wlist. Pierwszy argument wskazuje na nazwę urządzenia/interfejsu, tak jak został on rozpoznany przez Linuxa:

iwlist wlp1s0 scanning

Przełączenie do innej sieci

Tutaj przyda się znowu polecenie nmcli, np. aby podłączyć się do sieci BURMISTRZ użyj:

sudo nmcli device wifi connect BURMISTRZ

Jeśli byłoby to pierwsze połączenie to można tu jeszcze dodać parametr password:

sudo nmcli device wifi connect BURMISTRZ password XXXXXX

Sprawdzenie, czy jesteśmy we właściwej sieci wykonasz komendą

nmcli connection

lub

nmcli device wifi list

Aktywne połączenie będzie oznaczone kolorem lub gwiazdką

Uwagi i wskazówki

Jeśli chcesz „zapomnieć” połączenie użyj komendy delete, np.:

sudo nmcli connection delete "Olympik Hotels"

Jeśli sieć WiFi nie jest pokazywana przy poleceniu listującym sieci, to możesz dodać parametr –rescan:

nmcli device wifi list --rescan yes

Załóżmy, że masz już lokalnie, na swoim komputerze pliki projektu, które chcesz umieścić w nowym repozytorium na GitHub. W takim przypadku propnuję rozpocząć od utworzenia nowego repozytorium na GitHub, co jest proste, bo to klikanie myszką. Teraz jednak chcielibyśmy do tego repozytorium wysłać lokalne pliki. Można to zrobić tak:

1. Przejdź do katalogu, w którym masz swoje pliki:

cd my_project

2. Teraz zainicjuj tworzenie nowego repozytorium, które jednak powstanie lokalnie:

git init
Initialized empty Git repository in C:/temp/test_repo/.git/

3. Teraz jeśli chcesz, to umieść w tym katalogu odpowiedni plik .gitignore. Potem możesz dodać do wysłania na repo wszystkich kwalifikujących się do tego plików z lokalnego katalogu:

git add .

4. Już na tym etapie można sprawdzić, że nowe repozytorium zostało utworzone i jesteś aktualnie w branch master:

git status
On branch master
No commits yet
Changes to be committed:
(use "git rm --cached ..." to unstage)
new file: app.py

5. Jeśli jeszcze wcześniej nie zostało to zrobione, to należy zaktualizować co najmniej dwie zmienne: user.email i user.name:

git config user.email email@domain.pl
git config user.name myusername

6. Wartości możesz wyświetlać używając parametru –get

git config --get user.email
email@domain.pl
git config --get user.name
myusername

7. Teraz trzeba jakoś połączyć ze sobą to lokalnie utworzone repozytorium, z tym zdalnym repozytorium, które znajduje się na GitHub:

git remote add origin https://github.com/username/test_repo

8. Możemy przejść do utworzenia pierwszego „commita”:

git commit -m "initial"
[master (root-commit) ff6795c] initial
1 file changed, 1 insertion(+)
create mode 100644 app.py

9. Na tym etapie można już połączyć lokalny branch master ze zdalnym branchem master:

git push --set-upstream origin master
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 200 bytes | 200.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/username/test_repo
* [new branch] master -> master
branch 'master' set up to track 'origin/master'.

W ten oto sposób pliki z katalogu lokalnego zostały wysłane na repozytorium na GitHub!

Zdarza się, że chesz, aby Jupyter startował w innym katalogu niż domyślny. Są na to metody polegające na zmianach w pliku konfiguracyjnym, ale nie wygląda na to aby to działało (przynajmniej pod Windows). Za to co pomogło:

1. Wpisz w menu start Jupyter, a kiedy program zostanie znaleziony naciśnij go prawym przyciskiem myszy i wybierz „Otwórz lokalizację pliku”
2. W katalogu, który został otworzony, znowu kliknij prawym przyciskiem myszy na ikonce odpowiadającej za Jupyter i wybierz „właściwości”
3. Teraz w polu „Element docelowy” wykasuj znajdujący się na końcu wpis %USERPROFILE% i wpisz oczekiwaną ścieżkę. W moim przypadku wpisałem „e:/” (Uwaga na kierunek slasha)
4. Zapisz zmiany klikając OK i gotowe

U mnie zadziałało od strzału!

Logujesz sie do raspberry pi przez ssh (np. Putty), a tu po pytaniu o nazwę użytkownika i hasło sesja się zawiesza. Ping wysyłany na adres komputera działa normalnie.

Oczywiście przyczyn może być wiele, ale w moim przypadku rozwiązanie było dość zagadkowe. Otóż w pliku /etc/ssh/sshd_config wystarczyło dopisać:

IPQoS cs0 cs0

Niektórzy twierdzą, że taką zmianę należy wykonać jeszcze w pliku /etc/ssh/ssh_config, ale u mnie nie trzeba było.

Ot – takie „czary mary”

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

https://community.element14.com/products/raspberry-pi/f/forum/47549/b-ethernet-problem-ping-works-but-not-able-to-ssh