W katalogu /var/log/journal odkładają się logi generowane przez journal. Logi to jedna z ważniejszych rzeczy w pracy administratora, więc to dobrze, że się tam odkładają. Jeśli jednak jest ich zbyt dużo, to też niedobrze.

Po pierwsze można sprawdzić, ile miejsca te logi zajmują:

journalctl --disk-usage

Po drugie, można usunać stare logi, zostawiając tylko wskazaną ilość miejsca:

journalctl --vacuum-size=200M

No i po trzecie, można skonfigurować journal, do przechowywania tylko zadanej ilości logów. Plik konfiguracyjny to /etc/systemd/journald.conf. Linijka definiująca ile miejsca można przeznaczyć na logi to SystemMaxUse:

SystemMaxUse=200M

Po zmianach w pliku journald powinien zostać zrestartowany:

sudo systemctl restart systemd-journald

Więcej informacji o journal.conf:

man journal.conf

Co to ja  właściwie zainstalowałem? No cóż – takie pytanie można zadawać sobie czasami i całkiem na trzeźwo. Żeby sprawdzić, co ostatnio było instalowane na Ubuntu można posłużyć się poleceniem:

grep install /var/log/dpkg.log

Jeśli plik w między czasie już się zrollował, to można dodać jeszcze jego wcześniejszą wersję:

grep install /var/log/dpkg.log /var/log/dpkg.log.1

Mając taką komendę można następnie budować sprytniejsze raporty, o których można poczytać tutaj:

https://unix.stackexchange.com/questions/12578/list-packages-on-an-apt-based-system-by-installation-date

W moim przypadku w/w komenda była wystarczająca

Pod Hyper-V pracuje maszyna wirtualna z Linux. Część z plików została wykasowana z Linuxa, ale rozmiar dysku wirtualnego pozostał duży (ok 45 GB). Dostępny w konsoli Hyper-V edytor dysku, mimo wydania komendy zmniejszenia dysku, nie zmniejszył rozmiaru, albo zrobił to w minimalnym zakresie. Co robić?

1. Kilka operacji do wykonania na systemie gościa – Linuxa. Oczywiście na początku kasujemy wszelkie niepotrzebne pliki (ale to nie główny temat tego wpisu). Następnie na dysku na którym występuje problem (u mnie to dysk podmontowany w katalogu root) należy wykonać takie oto polecenia:

su
cd /
cat /dev/zero > zero.dat ; sync ; sleep 1 ; sync ; rm -f zero.dat

O co chodzi? Hyper-V zoptymalizuje tylko „wyzerowane” sektory. Ta komenda całe puste miejsce dysku zapełnia zerami. Dzięki temu, za chwilę komendy Hyper-V zobaczą to puste miejsce. Polecenie zapełnia dysk na 100% używając też miejsca wykorzystywanego przez juz usunięte pliki i o to właśnie chodzi. Jeśli na systemie linux działa jakaś ważna aplikacja, to zapełnienie dysku może być dla niej poważnym problemem – przemyśl ten krok 😉

2. Wyłącz linuxa.

3. Na systemie hosta, w powershellu uruchomionym jako administrator:

Optimize-VHD "C:\HV-Machines\exported u20\U20\Virtual Hard Disks\U20.vhdx" -Mode Full

To polecenie dokonuje pełnej optymaliacji dysku usuwając wyzerowane sektory. W moim przypadku rozmiar dysku spadł z 45 GB do 33, a wcześniej uruchamiany kreator nie zwalniał praktycznie nic.

Źródła:

How to compact VHDX files in the most efficient way – C:Amie (not) Com! (c-amie.co.uk)

virtual machine – Linux VHDX size on Hyper-V – Stack Overflow

Mówią, że Windows to system prosty, zbyt prosty, że prawdziwi profesjonaliści wybierają Linuxa, bo na Windows można umrzeć z nudów. Tak? To jak spowodować, żeby pliki mp4 automatycznie uruchamiały się np. z odtwarzaczem VLC?

• Programy domyślne – nie działa
• Instalacja kodeków – nie działa
• Instalacja / Deinstalacja Films & TV – nie pomaga
• Grzebanie po rejestrze – odpada.
  Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.mp4\UserChoice
  Skojarzenie pliku z programem jest dodatkowo zabezpieczone przez sumę kontrolną i nie wiem jak ją wyliczyć…. ale ktoś wiedział…

Pobierz program

https://kolbi.cz/SetUserFTA.zip

A następnie uruchom polecenie:

SetUserFTA.exe" .mp4 "C:\Program Files (x86)\VideoLAN\VLC\vlc.exe"

Sprawdź. U mnie działa. Koniec.

How to make VLC or Windows Media Player to open mp4 files without asking additional questions?

• download https://kolbi.cz/SetUserFTA.zip
• run command

   SetUserFTA.exe" .mp4 "C:\Program Files (x86)\VideoLAN\VLC\vlc.exe"

• done!

Azure CLI uruchamiane z linii komend jest zdecydowanie prostsze niż wykonywanie tej samej czynności z poziomu PowerShell. No dobrze, może nie zawsze, ale zdarza się. Na przykład do utworzenia alertu, w przypadku PowerShella trzeba utworzyć kilka różnych obiektów programistycznych, które w końcu łączy się w całość. Nie jest to problem dla programisty, ale administrator może mieć odmienne zdanie.

Niestety z CLI jest taki problem, że zbudowanie poleceń, które nawzajem wykorzystywałyby swoje wyniki wymaga znajomości języka skryptowego BASH. BASH jest starszy, żeby nie powiedzieć „toportniejszy” od nowoczesnego PowerShella.

Ostatnio spotkałem jednak eleganckie rozwiązanie na usunięcie grupy zasobów, której nazwa rozpoczyna się od zadanego ciągu znaków. No po prostu bardzo mi się to spodobało:

az group list --query "[?starts_with(name,'lab-dev-de')].name" --output tsv

To polecenie poszuka takich grup. Warto je uruchomić przed usuwaniem, bo właśnie te grupy zasobów zostaną usunięte w kolejnym kroku. Korzystamy z opcji group list, czyli wylistuj grupy zasobów, których nazwa zaczyna się od czegoś tam.

No i polecenie usuwające:

az group list --query "[?starts_with(name,'lab-dev-de')].[name]" --output tsv | xargs -L1 bash -c 'az group delete --name $0 --no-wait --yes'

Zaczynamy od polecenia szukającego określonej grupy zasobów i potokiem przekazujemy do xargs, którego zadaniem jest uruchomić komendę z parametrami. polecenie to az group delete, a parametr to $0 – czyli nazwa grupy zasobów. Reszta parametrów jest przekazywana statycznie. O nic nie spyta tylko weźmie i usunie. Wygodne (i niebezpieczne)

Azure DevOps daje specjalistom dostęp do zestawu narzędzi takich jak

• boards,
• pipelines,
• repos,
• artifacts i
• test plans.

Wszystkie te narzędzia są ze sobą zintegrowane pozwalając z jednej strony przypisać zadania członkom zespołu, a z drugiej strony wykonać zmiany w kodzie, które zostaną automatycznie zbudowane i przetestowane, a informacja o zakończeniu zadania może być automatycznie odnotowana w Azure Boards śledzącym postęp pracy.

W świecie IT występują dziesiątki narzędzi dających podobne funkcjonalności do Azure DevOps, ale Azure DevOps jest zintegrowaną platformą. Wybór odpowiednich narzędzi może też być determinowany przez typ realizowanego projektu. Jeśli projekt jest open source, to prawdopodobnie chętniej skorzystamy z GitHub, bo to również jest rozwiązanie typu open source. Z kolei, jeśli realizujemy zadanie wewnętrzne w firmie już korzystającej z Azure DevOps, to naturalnym wyborem będzie właśnie Azure DevOps.

Azure DevOps integruje się z Microsoft Account, co pozwala na przypisywanie odpowiednich uprawnień i definiowanie ról. Sam dostęp do konta można zabezpieczać przez multifactor authentication. Mamy tu też już predefiniowane role i policy, które pozwalają zaimplementować wewnętrze polityki bezpieczeństwa organizacji. Dostęp może być też definiowany w luźny sposób, np. wykorzystując tylko access token.

GitHub, chociaż open source też ma mnóstwo zalet, które są dostarczone w może trochę inny sposób:

• codespace pozwala na tworzenie chmurowego środowiska programistycznego,
• repos pozwalają na przechowywanie kodu aplikacji w kontrolowany sposób, integruje się z git,
• przy pomocy actions pozwala automatyzować budowanie i dostarczanie aplikacji,
• przy pomocy już wcześniej opublikowanych pakietów na GitHub, możemy się z nimi łatwo integrować,
• zawiera również narzędzia skanujące kod przed popularnymi zagrożeniami.

Zarówno AzureDevOps, jak i GitHub są dostępne w wersji płatnej i darmowej.

Azure DevOps nie jest przy tym zamknięty na świat Microsoft. Projekty można migrować niezależnie, można korzystać z wielu narzędzi, platform, a nawet budować rozwiązania do konkurencyjnej chmury.

Azure Boards to narzędzie pozwalające planować pracę podobnie jak w Kanban. Boards może być połączony także z GitHub. Zwykle praca jest dzielona co najmniej na 3 etapy: „to do”, „in progres” i „done”. Zadania dodatkowo klasyfikuje się do odpowiedniej kategorii, jak np. „bug”.

Zadania są zdefiniowane raz, ale mogą być wyświetlane z punktu widzenia jednego użytkownika, całej firmy albo jednego repozytorium. Zdefiniowane zadania mogą być aktualizowane w mniej lub bardziej automatyczny sposób przy pomocy szablonów. Dobra klasyfikacja zadań pozwala w kolejnym kroku na dobre raportowanie, a to z kolei pozwala na ustalenie czy są osiągane KPI.

Azure Board może być połączone z kontem GitHub pozwalając prezentować na Azure Boards postęp prac nad projektem publikowanym na GitHub.

https://learn.microsoft.com/en-us/azure/devops/boards/github/connect-to-github?view=azure-devops

Odpowiednikiem Azure Board na GitHub jest Git Project Board. Cel obu tych narzędzi jest podobny – śledzenie postępu prac nad projektem programistycznym.

Zmiany wprowadzane przez programistów powinny koniec końców zostać opublikowane w postaci kodu. Ten kod jest umieszczany w systemie kontroli wersji, którym może być Azure Boards lub GitHub. Co warto zauważyć można korzystać z Azure Boards, ale swój kod publikować na GitHub. W systemie kontroli wersji  zachowywana jest cała historia wykonywanych zmian przez wszystkich programistów. Dzięki temu można w dowolnej chwili sprawdzić stan określonej linii kodu w dowolnym pliku. W razie potrzeby można więc wrócić do wcześniejszej wersji.

Dobrą praktyką w tworzeniu kodu jest:

• Tworzenie małych zmian
• Publikowaniw tylko plików, które budują projekt (żadnych plików personalnych)
• Częsta aktualizacja kodu (push/pull)
• Weryfikacja kodu przed wyslaniem do repozytorium
• Czytanie (!!!) komunikatów zwracanych przez git
• Łączenie wykonywanych zmian z przypisanymi zadaniami (Azure Boards)
• Współpraca – niezależnie od pozycji w zespole

Kod źródłowy jest utrzymywany w centralnej lokalizacji i wykorzystywany przez wielu programistów jednocześnie. Z drugiej strony kod przechowywany może być w postaci dystrybuowanej. Dystrybucja polega na tym, że cały kod aplikacji jest w pierwszej kolejności ściągany lokalnie na komputer użytkownika i tam programista zarządza kodem tworząc np. nowe branch, czy commitując swoje zmiany. Dopiero w pewnym momencie wysyła te zmiany do centralnej lokalizacji, którą jest GitHub Repo lub Azure Repo.