Linux często jest wykorzystywany do automatyzacji chmury, np. Azure. Jeśli trzeba synchronizować pliki, można użyć azcopy, ale najpierw trzeba je zainstalować. Oto jak:

Najpierw skopiuj pakiet na swój komputer (najlepiej do jakiegoś tymczasowego katalogu):

wget https://aka.ms/downloadazcopy-v10-linux -O azcopy.tar.gz

Teraz rozpakuj te pliki

tar -xf azcopy.tar.gz

Następnie skopiuj je do katalogu docelowego:

sudo cp ./azcopy_linux_amd64_*/azcopy /usr/bin/

A teraz pozostaje sprawdzić, czy azcopy się uruchamia i w jakiej wersji występuje:

azcopy --version

A jeśli trzeba jeszcze zaintalować az cli to wystarczy jedno dodatkowe polecenie:

curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash

Git łącząc się do GitHub korzysta z Personal Access Token (PAT). Może zdarzyć się tak, że ten PAT chcesz albo musisz zmienić. Co wtedy?

Na Windows uruchom Credential Manager i w nim wyszukaj klucza do wymiany. Można go nawet usunąć i po prostu wprowadzić nowy.

Na Linuxie przyda się znajomość paru poleceń. Oto one:

git config --show-origin credential.helper

To polecenie sprawdzi na co wskazuje parameter credential.helper. Credential.helper (jak nazwa wskazuje) mówi o tym, kto nam pomaga w dostarczaniu credentials czyli właśnie uwierzytelnienia przed GitHub. Spodziewany wynik to:

file:.git/config        store

Znaczy to tyle, że credentials są przechowywane na dysku. Można się o tym przekonać wyświetlając plik .git-credentials:

cat ~/.git-credentials

Najprawdopodobniej zostanie wyświetlone coś w tym stylu:

https://<username>:<old_token>@github.com

No i teraz można postąpić tak, jak pod Windows, tzn. usunąć wybrany wpis lub nawet cały plik. Przy okazji wykonywania najbliższego polecenia łączącego się z GitHub zostaniemy zapytani o nowy PAT, który zapisze się w .git-credentials itp. itd….

Jeśli masz ochotę to w podobnej sytuacji można też posłużyć się poleceniem

git credential reject

To polecenie jest jednak trochę „dziwne”, bo wszystko robi „po ciuchu”. Jeśli chcesz usunąć poświadczenia do serwera GitHub – tego publicznego, a nie np. GitHub Enterprise dostępnego w twojej organizacji, to po uruchomieniu powyższego polecenia, kiedy kursor przeskoczy do kolejnej linii należy napisać:

protocol=https
host=github.com

Działa to jak zwykły „filtr” decydujący o tym co usunąć. Wszystkie wpisy w pliku .git-credentials, które rozpoczynają się od https i dotyczą serwera github.com zostaną usunięte.

Kiedy uruchamiasz

ssh username@servername

to zależnie od konfiguracji może paść pytanie o passphrase. Passphrase to haslo, ktorym jest chroniony klucz prywatny wykorzystywany podczas połączenia. Generalnie ma to sens, bo przechowywanie private key w niezaszyfrowanym pliku to proszenie się o kłopoty, niestety każdorazowe wprowadzanie hasla, po to żeby otworzyć klucz prywatny, żeby podczas logowania nie podawać hasła… to nieco dziwne rozwiązanie. Co można wobec tego zrobic?

Na Linux można by uruchomić polecenie

ssh-add

Okazuje się, że na Windows można to zrobić bardzo podobnie. Usługa odpowiadająca za zabezpieczanie klucza hasłem jest częścią pakietu OpenSSH-Server, ale nie zawsze jest włączona. Oto jak ją włączyć:

Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent
Get-Service ssh-agent

Kiedy usługa już działa, a ty masz plik z private key, to wpisz, podobnie jak na Linux:

ssh-add

Gotowe! Agent SSH „poda haslo” w momencie, kiedy klient ssh bedzie go potrzebować.

Pakiet OpenSSH zawiera też polecenie służące do generowania klucza, gdyby to było potrzebne:

ssh-keygen

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