Bywa (a właściwie to już norma), że Linux, do którego chcesz się zalogować nie akceptuje hasła, tylko pary pasujących kluczy prywatnego i publicznego. Jak skonfigurować klienta po stronie windows w takiej sytuacji?

Plik .ssh/config zapisany w podkatalogu .ssh w twoim katalogu domowym (a wiec w c:\users\) powinien zawierać wpis:

Host vm1
HostName 1.2.3.4
IdentityFile C:\Users\myuser.ssh\vm1.pem
User user1

Plik C:\Users\myuser.ssh\vm1.pem powienien z kolei zawierać klucz prywatny, razem z tekstem BEGIN i END:

—–BEGIN OPENSSH PRIVATE KEY—–
<…>
—–END OPENSSH PRIVATE KEY—–

I to tyle. od tej pory można uruchamiać polecenie

ssh vm1

i logowanie powinno się odbyć bez podawania hasła (o ile klucz nie jest chroniony przez passphrase i konfiguracja po stronie serwera jest poprawna)

Kiedy w bicep próbujesz utworzyć określony zasób używasz pewnych typów zasobów, które oprócz nazwy, muszą też być obsługiwane przez odpowiednie API. A skąd takie API wziąć? Można je wylistować:

az provider show --namespace Microsoft.Authorization --query "resourceTypes[?resourceType=='denyAssignments'].apiVersions"

przykladowy wynik to:

[
[
"2024-07-01-preview",
"2024-05-01-preview",
"2022-04-01",
"2019-03-01-preview",
"2018-07-01-preview",
"2018-07-01"
]
]

Dzięki temu można teraz budować ciąg dlaszy w postaci bicep

@description('Tworzy deny assignment blokujący zapis do Storage Account Blob Container')

resource storageAccount 'Microsoft.Storage/storageAccounts@2025-01-01' = {
name: 'delmedrritjo'
location: 'westeurope'
scope: resourceGroup()
}

resource denyAssignment 'Microsoft.Authorization/denyAssignments@2022-04-01' = {
name: '123e4567-e89b-12d3-a456-426614174000'
location: 'westeurope'
scope: storageAccount
properties: {
denyAssignmentName: 'deny-write-storage-container'
permissions: [
{
denyActionNames: [
'Microsoft.Storage/storageAccounts/blobServices/containers/write'
'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write'
]
}
]
principals: [ // Dodajemy użytkownika, dla którego stosujemy blokadę
{
id: '90e-XXXXX-d98' // Object ID użytkownika
type: 'User' // Określenie typu Principal (może być 'User', 'Group', 'ServicePrincipal')
}
]
description: 'Blokada zapisu do Storage Account Blob Container'
}
}

i wysylac go do wykonania:

az deployment group create --template-file main.bicep --resource-group delme

Dajmy na to że masz dwa konta na GitHub. Chcesz przenieść repozytorium z jednego konta na drugie. W takim przypadku można wykonać „bare copy”. Oto jak:

1. Najpierw ściągnij źródłowe repozytorium z oryginalnego repo do siebie lokalnie na komputer. Użyj polecenia clone z parameterem –bare

git clone --bare https://github.com/original_account/original_repo.git

1. Teraz utwórz nowe puste repo na docelowym koncie
2. Wyślij repozytorium używając polecenia push z przełącznikiem mirror:

git push --mirror https://github.com/destination_account/destination_repo

Administratorzy lubią blokować zbyt wiele… w takim przypadku może się okazać, że zablokowane zostanie uruchamianie powershella jako administrator, ale… jeśli admin co nieco przegapił to takie ograniczenie da się obejść. Oto jak.

Zakładam, że nadal masz możliwość uruchomienia cmd jako administrator. Uruchom więc go.

Teraz w cmd wpisz polecenie:

powershell -command "start-process powershell -verb runas"

Co się tutaj dzieje?

• cmd uruchamia powershella
• ten powershell wykonuje tylko komendę start-process
• ta komenda start process uruchamia kolejnego powershella, ale…
• … uruchamia go wraz z verb runas, czyli „jako administrator”

W efekcie w nowym oknie uruchomi się powershell, który będzie działać z podniesionymi uprawnieniami „as administrator” pomimo tego, że administrator zabronił.

Polecenie powershell odpowiada za powershella w wersji 5.x i można go zamienić na pwsh czyli powershell w wersji 7.x

Niektóre zasoby w Azure, jak np. managed identity mogą mieć kilka identyfikatorów, całkiem jak my: nr PESEL, numer dowodu, numer paszportu. Każdy z tych ID może być wykorzystywany tylko w określonej sytuacji.

Oto główne różnice między id, principal_id i client_id w Azure dla managed identity:

1. id:
   • Jest to ogólny identyfikator każdego zasobu w Azure. Może to być storage account, dysk, baza danych, czy właśnie managed identity, np.: azurerm_user_assigned_identity.example.id
2. principal_id:
   • Jest to identyfikator przypisanej tożsamości użytkownika (Managed Identity) lub aplikacji (Service Principal) w EntraID. Używamy go np. do nadawania uprawnień, np.:azurerm_user_assigned_identity.example.principal_id
3. client_id:
   • To specyficzny przypadek, bo jest to identyfikator aplikacji zarejestrowanej w Azure EntraID. Używamy go do konfiguracji mechanizmów uwierzytelniania – ale uwaga, tylko w takich jak OAuth, czy np. do uzyskiwania tokenów dostępu: azurerm_user_assigned_identity.example.client_id

Zainstaluj Java JDK w wersji 17, np. do katalogu c:\spark\java

Zainstaluj WinUtils w wersji 3.3.6 (jeśli używasz Windows 11) np do katalogu c:\spark\hadoop

Zainstaluj Spark 3.5.5 z Hadoop 3.3, np. do katalogu c:\spark\spark

Zainstaluj Python 3.11, np. do katalogu c:\spark\python. Wykonaj dodatkową kopię pliku python.exe i nazwij ją python3.exe

Zdefiniuj zmienne środowiskowe np. dla użytkownika:

HADOOP_HOME –> c:\spark\hadoop

JAVA_HOME –> C:\spark\java

SPARK_HOME –> C:\spark\spark

PATH –> C:\spark\python\Scripts\;C:\spark\python\;%JAVA_HOME%\bin;%SPARK_HOME%\bin;%HADOOP_HOME%\bin;%USERPROFILE%\AppData\Local\Microsoft\WindowsApps;

Zakładając, że masz już zainstalowany Apache Spark, a teraz chcesz zacząć na nim własne eksperymenty, to pewnie przydałoby się jakieś „lekkie” środowisko – miminum z działającym Jupyter Notebook. Oto moja propozycja

W wybranym katalogu utwórz środowisko wirtualne

python -m venv venv

Aktywuj je

.\venv\scripts\activate

Zainstaluj moduły

pip install findspark

pip install pyspark

pip install jupyter

Uruchom Jupyter Notebook

jupyter notebook