Doinstalowywanie oprogramowania do Pythona jest proste, o ile się wie jak to robić, a przecież na początku nie wie się niczego. Spróbujmy więc krok po kroku zobaczyć, jak w PyCharm, w zupełnie nowym projekcie zaistalować moduł na przykładzie requests:

Na początku wybrałem polecenie „New project”

1 – nazywam projekt „jakoś tam”
2 – kontrolnie patrzę na ścieżkę, jakby trzeba było, to mogę ją zmienić
3 – tu też nic nie trzeba zmieniać, ale warto to zauważyć, że jest tworzone środowisko wirtualne
4 – na dole widać też pełną ścieżkę
5 – No i pozostaje kliknąć „Create”

Co to jest to dziwne środowisko wirtualne? Otóż jest to całkiem normalne, że programiści pracują nad różnymi projektami. Jedne wymagają takich modułów a inne innych. Na dodatek, niektóre starsze projekty będą wymagały dodatkowych modułów w nieco starszej wersji, a inne projekty będą wymagały tych samych modułów, ale w nowszej wersji. Gdyby wszystko tak po prostu intalować na komputerze, to szybko zrobiłby się bałagan i albo te starsze albo te nowsze projekty by nie działały. Dlatego wymyślono środowisko wirtualne. Jest to minimalny (choć duży) zbiór plików, który zapewnia stabilne środowisko dla tworzonego projektu. Jeśli mając to środowisko aktywne doinstalujesz jakiś moduł, to będzie on widoczny tylko w tym projekcie. Inne projekty będą miały swoje środowiska wirtualne i swoje wersje wymaganych modułów.

Idźmy dalej:

Podczas tworzenia projektu może na dłużej lub krócej mignąć takie właśnie okienko. Informuje ono o tworzeniu środowiska wirtualnego. Domyślnie zostanie ono zapisane w podkatalogu projektu. Ten podkatalog nazywa sie .env (tak! z kropką na początku)

Kiedy projekt się już utworzy zobaczysz mniej więcej to:

1 – W podkatalogu projektu znajdziesz podkatalog .env – teraz już wiesz, co to jest
2 – Przy pomocy menu kontekstowego możesz dodać
3 – plik pythona do swojego projektu. Ten plik nazwij, jak tam sobie uważasz

Co my tu teraz mamy:

1 – w treści pliku skorzystajmy z modułu, który niestety jeszcze nie jest zainstalowany. Z tego powodu „requests” jest podkreślone na czerwono
2 – na dole można kliknąć w „terminal” co wyświetli dolne okienko
3 – automatycznie w tym terminalu powinno się również aktywować środowisko wirtualne. Rozpoznasz to po napisie (.venv) na początku linijki
4 – ten napis (.venv) powinien być taki sam, jak nazwa podkatalogu
5 – teraz w terminalu można wpisać polecenie instalujące moduł requests:

pip install requests

Poleceniem do instalacji modułów jest pip. Dzięki temu, że to polecenie jest uruchamiane w środowisku wirtualnym .venv to ta instalacja nie wpłynie na pracę innych projektów, które powinny być skonfigurowane do pracy ze swoimi środowiskami

1 – kiedy instalacja się zakończy, powinien wyświetlić się komunikat o sukcesie. Może on być nieco ukryty między innymi komunikatami, więc dobrze go wypatrz. Gdyby nie było sukcesu tylko porażka, to zostanie też wyświetlony komunikat, który pozwoli dalej badać sprawę i rozwiązywać problemy
2 – może nie od razu, ale po jakieś chwili, powiedzmy po 30 – 60 sekundach słowo „requests” w edytorze kodu powinno już nie być podświetlone.
3 – wtedy można uruchomić skrypt. Poprawny wynik w przypadku naszego prymitywnego skryptu to „Process finished with exit code 0”

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

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