Azure: Bicep – instalacja

2024-06-20

Bicep to łatwiejszy, od typowego ARM, sposób na definiowanie zasobów Azurowych za pomocą kodu. W odróżnieniu od np. Terraforma, Bicep działa tylko dla Azure, oraz praktycznie nie wymaga instalacji dodatkowego oprogramowania. No to jak go zainstalować?

  • Zacznijmy od rzeczy opcjonalnej. Pisząc skrypty Bicep fajnie jest używać wygodnego edytora. Dlatego warto zainstalować rozszerznie Bicep dla Visual Studio Code. Wybieramy oczywiście narzędzie opublikowane przez Microsoft
  • Druga sprawa to instalacja Bicepa, tylko, że instalacja nie odbywa sie poprzez uruchomienie jakiegoś dodatkowego programu. Zakładając, że masz już na swoim komputerze AZ CLI, to wystarczy wykonać polecenie:
  • az bicep install
  • Wersję Bicepa można sprawdzić uruchamiając:
  • az bicep version
  • Powyższe polecenia zadziałają tylko jeśli AZ CLI jest w odpowiednio wysokiej wersji – ale utrzymywanie na komputerze nowej wersji oprogramowania to chyba dość naturalny krok
By Rafał Kraik in Azure

Windows: Duży folder winSxS

2024-06-16

Na systemie Windows, każda kolejna aktualizacja dostarcza nowe pliki, które zamieniają stare pliki – to oczywiste, trzeba stare błędy zamienić nowymi 😉

Pliki dostarczane w aktualizacjach zapisują się w katalogu winSxS, który z czasem może urosnąć do sporych rozmiarów. Nie zaleca się wykasowania tych plików, ale można je już „na stałe” wbudować we wzorcowy system windows. Służy do tego komenda:

Dism.exe /online /Cleanup-Image /StartComponentCleanup

Komendę należy uruchomić jako administrator. Niestety, czasami można w efekcie zobaczyć komunikat:

The operation could not be completed due to pending operations.

W takim przypadku można spróbować:

  • uruchomić komputer ponownie (a jakże – przecież to Windows!). Ma to na celu zakończenie ciągle jeszcze niedokończonych operacji
  • wycofać takie niedokończone operacje posługując się poleceniem:
    Dism.exe /online /Cleanup-Image /StartComponentCleanup /RevertPendingActions
    (a po tej operacji uruchomić ponownie komputer – a jakże – to Windows!)

W moim przypadku te kroki pomogły. Można było wyczyścić spory katalog winSxS i odzyskać nieco przestrzeni dyskowej i przy okazji przyśpieszyć komputer.

By Rafał Kraik in Helpdesk

Linux: Hash hasła

2024-05-07

W Linuxie nowego użytkownika dodasz komendą

adduser new_user_name

Jedna z opcji tego polecenia pozwala na przesłanie hasła, ale to hasło nie jest w postaci tekstu, tylko w postaci zahaszowanej. A jak taki hash uzyskać? Można tak:

pass=$(echo „Pa$$w0rd” | openssl passwd -1 -stdin)

Korzystamy tu z polecenia openssl, które

  • wygeneruje hash hasła (słowo passwd)
  • hasło będzie hashowane algorytmem MD5 (-1), a gdyby przesłać parameter -6, to były to algorytm SHA512
  • hasło czyta ze standardowego wejścia. Tutaj tym standardowym wejściem jest komenda echo
  • hash będzie zapisany w zmiennej pass

Teraz więc można już utworzyć użytkownika z hasłem:

sudo adduser -m -p „$pass” $u

No i uwaga – zdecydowanie nie jest to zalecane rozwiązanie, bo… jeśli ktoś będzie sprawdzał jakie komendy są uruchamiane w czasie, kiedy ta komenda będzie uruchamiana to może przechwycić hash hasła, a stąd już otwiera sie droga do złamania hasła w oparciu o hash, ale w pewnych sytuacjach takie podejście też się może przydać 😉

By Rafał Kraik in Linuxy

Visual Studio Code pyta o konto GitHub

2024-05-06

Po reinstalacji systemu się zaczęło… za każdym razem, kiedy trzeba było skomunikować sie z GitHubem: fetch, pull, push… pojawiało się okienko pytające (zresztą bardzo uprzejmie) o to, które konto GitHub powinno być wykorzystane.

Przyczyna jest taka, że rzeczywiście w ramach różnych projektów wykorzystywałem różne konta GitHub. Tymczasem podczas połączenia w remote pojawiał się po prostu namiar na repo na github:

git remote -v
origin https://github.com/org/repo.git (fetch)
origin https://github.com/org/repo.git (push)

Jakby tu dodać informacje o użytkowniku? Da się! Trzeba tylko przedefiniować remote:

git remote set-url origin https://user-name@github.com/org/repo.git

Po tej zmianie git remote -v zwraca już poprawne wartości:

git remote -v
origin https://user-name@github.com/org/repo.git (fetch)
origin https://user-name@github.com/org/repo.git (push)

a Visual Studio Code przestalo pytac o uzytkownika!

By Rafał Kraik in Git

Git: self signed certificate in certificate chain

2024-05-01

Taki komunikat możesz zobaczyć, gdy brakuje certyfikatów wymaganych do bezpiecznego przesłania danych. Pamiętajmy, że certyfikaty nie tylko pracują w szyfrowaniu danych, ale też w uwierzytelnieniu rozmawiających ze sobą systemów.

Obejściem problemu (ale nie rozwiązaniem) jest wyłączenie kontroli certyfikatu – po prostu będziemy akceptować wszystkie certyfikaty jak leci – potencjalnie również te nie podpisane

git config –global http.sslVerify false

Więcej informacji:

git – SSL certificate problem: self signed certificate in certificate chain – Stack Overflow

By Rafał Kraik in Git

Terraform: Index value required

2024-04-11

Operacje na terraform state to coś, czego raczej należy unikać, ale czasami coś tam trzeba zadziałać…

Polecenie

terraform state list

zwraca listę wszystkich zasobów którymi zarządza Terraform. Na tej liście w moim przypadku pojawił sie taki oto wpis:

module.net_conf.azurerm_private_endpoint.private_endpoint[„update_key”]

Ten oto wpis trzeba było usunąć. Zwykle wystarcza do tego polecenie terraform state rm, po którym podaje sie nazwę obiektu do usunięcia, o tak:

terraform state rm module.net_conf.azurerm_private_endpoint.private_endpoint["update_key"]

Niestety polecenie kończyło się brzydkim błędem:

│ Error: Index value required
│   on  line 1:
│  (source code not available)
│Index brackets must contain either a literal number or a literal string.

No jak to! Przecież w nawiasie jest „literal string”!

Przyczyna – problemy z interpretacja w linii komend cudzysłowa. Komendę oryginalnie uruchamiałem w powershell. Przeniosłem ją do cmd i delikatnie zmieniłem:

terraform state rm module.net_conf.azurerm_private_endpoint.private_endpoint[\"update_key\"]

Po tej zmianie, wszystko zadziałało!

By Rafał Kraik in Azure

AWS: Błąd połączenia do EC2 z Putty

2024-04-06

Podczas tworzenia instancji EC2 na AWS można wygenerować klucz pozwalający na połączenie się do EC2 za pomocą Putty. Niestety, przy takiej próbie połączenia można dostać też nieciekawy błąd: „Server Refused our key”

Poza sprawdzeniem standardowych rzeczy:

  • czy łączymy się do właściwego serwera
  • czy korzystamy z właściwego konta użytkownika
  • czy korzystamy z właściwego klucza – w sensie do właściwego serwera, ale też właściwego typu (Putty oczekuje PPK, a nie PEM).

można jeszcze sprawdzić:

  • czy połączenie konfigurujemy na adres IP czy na nazwę. Lepiej jest wskazywać na nazwę
  • w adresie można jednocześnie podać nazwę użytkownika i hasło wpisując
    username@server_address
    np.:
    ec2-user@<my.public.addres.name>
  • czy na komputerach jest właściwa data i czas
  • no i wreszcie czy mamy najnowszą wersję Putty.

U mnie pomogła właśnie ta ostatnia wskazówka. Putty było za stare 😉

By Rafał Kraik in AWS