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
2024-04-16
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
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!
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 😉
2024-03-16
Jedno hasło ważne przez 9999 dni? To nie jest dobry pomysł:
sudo chage --list testuser
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
Na szczęście na Linuxie można zmieniać daty ważności hasła i wymaganą częstotliwość zmian.
Żeby haslo było ważne jeszcze tylko przez 90 dni użyj:
sudo chage --expiredate $(date -d +90days +%Y-%m-%d) testuser
Dodatkowo, można jeszcze określić politykę zmiany hasła dla użytkownika:
- wymuś zmianę, co 180 dni (to i tak dużo)
- ostrzegaj o wygasaniu hasła 14 dni wcześniej
- pozwól na ponowną zmianę hasła dopiero po 3 dniach od poprzedniej zmiany:
sudo chage --mindays 3 --maxdays 180 --warndays 14 testuser
Teraz konto wygląda tak:
sudo chage --list testuser
Last password change : Jun 06, 2024
Password expires : Dec 03, 2024
Password inactive : never
Account expires : Oct 14, 2024
Minimum number of days between password change : 3
Maximum number of days between password change : 180
Number of days of warning before password expires : 14
2024-03-14
Ogólnie git diff wymaga wskazania CO z CZYM ma być porównane:
git diff <commit_hash> <commit_hash> <file_name>
Ponieważ branch można postrzegać jako ostatni commit w zadanej gałęzi kodu, to zadziała również:
git diff <branch_name1> <branch_name2> <file_name>
Czasami jednak opuszczamy CO ma być porównane i regulujemy to wyłącznie opcjami. Oto takie przypadki:
Zobacz czym różni się kod w working directory od kodu w staging area:
git diff <file_name>
Czym różni się kod w staging area od skommitowanego kodu w repo
git diff --staged <file_name>
git diff --cached <file_name>
Czym różni się kod w working directory od skommitowanego kodu w repo:
git diff HEAD <file_name>
2024-03-11
Jeśli jesteś ofiarą błędu „Server execution failed”, to
- otwórz Managera zadań (Ctrl+Shift+Esc),
- przejdź na „szczegóły”
- odszukaj procesu „Windows Media Player” i zakończ go
Jest szansa, że po tej akcji, pliki będą sie poprawnie odtwarzać 😉