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.

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ć 😉

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!

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

Jeśli pracownik ma być zatrudniony tylko na określony czas, to warto od razu podczas tworzenia konta ustawić datę końca ważności tego konta.

USERNAME='test'
EXPIRY=$(date -d "+45 days" '+%Y-%m-%d')
sudo adduser -m -c "$USERNAME" -e $EXPIRY -G operator $USERNAME

A co, jeśli ten początkowy okres trzeba przedłużyć?

Po pierwsze, łatwo można sprawdzić datę wygasania konta (zignoruj kwestie wymuszania zmiany hasła – tu skupiamy się na ważności konta, a to dwie różne rzeczy):

sudo chage --list test
Last password change                                    : Jun 06, 2024
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : Aug 31, 2024
Minimum number of days between password change          : 0
Maximum number of days between password change          : 99999
Number of days of warning before password expires       : 7

Teraz można zmodyfikować konto:

sudo usermod -e 2024-09-30 test

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!

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 😉