Pokazywanie postów oznaczonych etykietą programowanie. Pokaż wszystkie posty
Pokazywanie postów oznaczonych etykietą programowanie. Pokaż wszystkie posty

19 października 2020

Valgrind - pomaga wyszukać wycieki pamięci w programach

Chwilę pomyślałem sobie dzisiaj o problemach jakie mogą mieć urządzenia wbudowane z oprogramowaniem i przyszła mi taka myśl: 

Ciekawe, czy zależnie od języka programowania w standardzie możemy dostawać wycieki pamięci lub nie?

Z punktu widzenia różnych znanych mi systemów w urządzeniach mobilnych zastanawia mnie słabe rozwiązanie tego problemu - tzn. klikanie zwolnij zaalokowaną pamięć telefonu na żądanie. Inny wariant, to dedykowane programy z klasy "odśmiecacze pamięci", czyli dedykowane oprogramowanie, którego celem jest przegląd wszelkich niezwolnionych bloków i za zgodą usera próba zwolnienia. Brzmi znajomo, może Twój telefon z Androidem też przymula po otwarciu kilku aplikacji (nie koniecznie gier) ... i dopiero restart naprawia sprawę. Cóż, może mamy tam do czynienia z tzw. wyciekiem pamięci operacyjnej. Koncept nieskomplikowany do sprawdzenia na prostym przykładzie. 


Wprowadzenie do wycieków pamięci

Wyciek pamięci (ang. memory leak) to zaalokowanie pamięci w systemie operacyjnym przez program, który nie zwalania pamięci po zakończeniu swojego działania. 

Wszystko fajnie, kiedy bawimy się telefonem i po np: tygodniu działania zaczyna zamulać, robimy restart i działa dalej. Inaczej sprawa się ma na rynku np: serwerów, czy sprzętu ratującego życie, medycznego, diagnostycznego, kalibracyjnego. Są branże, gdzie wycieki pamięci to nie jest norma a poważny błąd. Każdy bajt wykradziony z puli w takich systemach wbudowanych, to proszenie się o zawieszenie systemu / programu / procesu, czyli o niestandardową awarię.

Nie jest tylko tak, że wycieki pamięci generują programiści danego softu. Mogą istnieć ukryte wycieki pamięci, które generują zewnętrzne bibioteki lub biblioteki współdzielone lub systemowe. Ta klasa błędów posiada dość szeroki zasięg ze względu na magię używania dwóch podstawowych instrukcji niższego poziomu w jężyka programowania t.j. C dobrze znanych. Są to:

 - alloc / malloc / calloc / tallloc i pochodne - rezerwują pamięć w programie dla zmiennej

- free i pochodne - zwalniają przydzieloną pamięć (po podaniu zmiennej z przydziału pamięci jako argumentu) 

Właściwie to chodzi tutaj o fakt, że nie wywołuje się FREE tam gdzie zachodzi *ALLOC. Niby takie proste w opisie a do osiągnięcia nirvany jest sporo kombinacji i pracy ;-)


Valgrind - ratunek na wycieki pamięci w oprogramowaniu

Na szczęście w fazie tworzenia oprogramowania, debugowania i testowania, jesteśmy w stanie sprawdzić jak zachowuje się oprogramowanie i dokonać rozpoznania wycieków pamięci. Narzędziem najpopularniejszym na rynku otwartego oprogramowania jest Valgrind 




Narzędzie to doczekało się dojrzałej wersji i bardzo bogatego portfolio, jeśli chodzi o wspierane architektury.

Valgrind obejmuje obecnie siedem narzędzi o jakości produkcyjnej: 
- detektor błędów pamięci 
- dwa detektory błędów wątków 
- pamięć podręczną i profiler predykcji rozgałęzień 
- wykres wywołań generujący pamięć podręczną 
- profiler przewidywania rozgałęzień 
- dwa różne profilery sterty. 
Zawiera również eksperymentalny generator podstawowych wektorów blokowych SimPoint. 
Działa na następujących platformach: X86 / Linux, AMD64 / Linux, ARM / Linux, ARM64 / Linux, PPC32 / Linux, PPC64 / Linux, PPC64LE / Linux, S390X / Linux, MIPS32 / Linux, MIPS64 / Linux, X86 / Solaris , AMD64 / Solaris, ARM / Android (2.3.x i nowsze), ARM64 / Android, X86 / Android (4.0 i nowsze), MIPS32 / Android, X86 / Darwin i AMD64 / Darwin (Mac OS X 10.12).

W Ubuntu możemy zainstalować narzędzie valgrind z takiego onelinera:

$ snap install valgrind  --classic



Test dwóch znanych języków programowania - Python i Golang - na wycieki pamięci w najprostszym programie

Wracam tutaj do założenia mojego wpisu. Mamy dwa bardzo popularne dzisiaj języki programowania: Python i Golang, którymi posługuję się biegle na codzień. Pomyślałem, spróbuję napisać jednolinijkowca i zobaczymy, czy valgrind coś wykryje :-) Poniżej zrzut z testu i rezultaty:


Program w Python + valgrind


$ cat memleaks_test.py 
print("a" * 255)

$ python3 memleaks_test.py 
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Ok, odpalmy teraz z badaniem wycieków pamięci i co widzimy:

....
==19177== Invalid read of size 4
==19177==    at 0x5139AE: PyGrammar_RemoveAccelerators (in /usr/bin/python3.8)
==19177==    by 0x67EE59: Py_FinalizeEx (in /usr/bin/python3.8)
==19177==    by 0x6B614C: Py_RunMain (in /usr/bin/python3.8)
==19177==    by 0x6B63BC: Py_BytesMain (in /usr/bin/python3.8)
==19177==    by 0x4C890B2: (below main) (libc-start.c:308)
==19177==  Address 0x51f0020 is 384 bytes inside a block of size 732 free'd
==19177==    at 0x4A39078: free (vg_replace_malloc.c:538)
==19177==    by 0x51ACB8: PyGrammar_AddAccelerators (in /usr/bin/python3.8)
==19177==    by 0x5FD6C4: PyParser_New (in /usr/bin/python3.8)
==19177==    by 0x517293: ??? (in /usr/bin/python3.8)
==19177==    by 0x67BA7A: PyParser_ASTFromStringObject (in /usr/bin/python3.8)
==19177==    by 0x67BEFD: PyRun_StringFlags (in /usr/bin/python3.8)
==19177==    by 0x600581: ??? (in /usr/bin/python3.8)
==19177==    by 0x5C4D7F: ??? (in /usr/bin/python3.8)
==19177==    by 0x56B26D: _PyEval_EvalFrameDefault (in /usr/bin/python3.8)
==19177==    by 0x5F7145: _PyFunction_Vectorcall (in /usr/bin/python3.8)
==19177==    by 0x56B26D: _PyEval_EvalFrameDefault (in /usr/bin/python3.8)
==19177==    by 0x569559: _PyEval_EvalCodeWithName (in /usr/bin/python3.8)
==19177==  Block was alloc'd at
==19177==    at 0x4A37ECB: malloc (vg_replace_malloc.c:307)
==19177==    by 0x51ACCF: PyGrammar_AddAccelerators (in /usr/bin/python3.8)
==19177==    by 0x5FD6C4: PyParser_New (in /usr/bin/python3.8)
==19177==    by 0x517293: ??? (in /usr/bin/python3.8)
==19177==    by 0x67BA7A: PyParser_ASTFromStringObject (in /usr/bin/python3.8)
==19177==    by 0x67BEFD: PyRun_StringFlags (in /usr/bin/python3.8)
==19177==    by 0x600581: ??? (in /usr/bin/python3.8)
==19177==    by 0x5C4D7F: ??? (in /usr/bin/python3.8)
==19177==    by 0x56B26D: _PyEval_EvalFrameDefault (in /usr/bin/python3.8)
==19177==    by 0x5F7145: _PyFunction_Vectorcall (in /usr/bin/python3.8)
==19177==    by 0x56B26D: _PyEval_EvalFrameDefault (in /usr/bin/python3.8)
==19177==    by 0x569559: _PyEval_EvalCodeWithName (in /usr/bin/python3.8)
==19177== 
==19177== 
==19177== HEAP SUMMARY:
==19177==     in use at exit: 301,190 bytes in 135 blocks
==19177==   total heap usage: 2,186 allocs, 2,051 frees, 3,158,779 bytes allocated
==19177== 
==19177== LEAK SUMMARY:
==19177==    definitely lost: 0 bytes in 0 blocks
==19177==    indirectly lost: 0 bytes in 0 blocks
==19177==      possibly lost: 1,632 bytes in 3 blocks
==19177==    still reachable: 299,558 bytes in 132 blocks
==19177==         suppressed: 0 bytes in 0 blocks
==19177== Rerun with --leak-check=full to see details of leaked memory
==19177== 
==19177== Use --track-origins=yes to see where uninitialised values come from
==19177== For lists of detected and suppressed errors, rerun with: -s
==19177== ERROR SUMMARY: 1106 errors from 128 contexts (suppressed: 0 from 0)

Kilkaset bajtów program pożarł ;-) a to nowina dla wszystkich milionów użytkowników języka Pytohn :-) Polecam prztestować bardziej skomplikowane programy oraz serwery aplikacji.



Program w Golang + valgrind


$ cat main.go 
package main

import "fmt"
import "strings"

func main() {
fmt.Println(strings.Repeat("a", 255))
}


$ go build main.go 
$ ./main 
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa


Program w GOlangu robi dosłownie to samo i badamy go przy pomocy valgrind:


==19372== Conditional jump or move depends on uninitialised value(s)
==19372==    at 0x40C4FD: runtime.mallocgc (/snap/go/6633/src/runtime/malloc.go:1152)
==19372== 
==19372== Conditional jump or move depends on uninitialised value(s)
==19372==    at 0x40C4B1: runtime.mallocgc (/snap/go/6633/src/runtime/malloc.go:1136)
==19372==    by 0x4474A8: runtime.growslice (/snap/go/6633/src/runtime/slice.go:230)
==19372==    by 0x43593E: runtime.allgadd (/snap/go/6633/src/runtime/proc.go:473)
==19372==    by 0x43D1F8: runtime.newproc1 (/snap/go/6633/src/runtime/proc.go:3572)
==19372==    by 0x45DBD2: runtime.newproc.func1 (/snap/go/6633/src/runtime/proc.go:3528)
==19372==    by 0x461605: runtime.systemstack (/snap/go/6633/src/runtime/asm_amd64.s:370)
==19372==    by 0x43745F: ??? (<autogenerated>:1)
==19372== 
==19372== Conditional jump or move depends on uninitialised value(s)
==19372==    at 0x40C4FD: runtime.mallocgc (/snap/go/6633/src/runtime/malloc.go:1152)
==19372==    by 0x4474A8: runtime.growslice (/snap/go/6633/src/runtime/slice.go:230)
==19372==    by 0x43593E: runtime.allgadd (/snap/go/6633/src/runtime/proc.go:473)
==19372==    by 0x43D1F8: runtime.newproc1 (/snap/go/6633/src/runtime/proc.go:3572)
==19372==    by 0x45DBD2: runtime.newproc.func1 (/snap/go/6633/src/runtime/proc.go:3528)
==19372==    by 0x461605: runtime.systemstack (/snap/go/6633/src/runtime/asm_amd64.s:370)
==19372==    by 0x43745F: ??? (<autogenerated>:1)
==19372== 
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
==19372== 
==19372== HEAP SUMMARY:
==19372==     in use at exit: 0 bytes in 0 blocks
==19372==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==19372== 
==19372== All heap blocks were freed -- no leaks are possible
==19372== 
==19372== Use --track-origins=yes to see where uninitialised values come from
==19372== For lists of detected and suppressed errors, rerun with: -s
==19372== ERROR SUMMARY: 3447 errors from 761 contexts (suppressed: 0 from 0)

... i ku naszemu zdziwieniu jednak GOlang nie ma wycieków pamięci na takim samym banalnym programie.



Podsumowanie

Bardzo ciekawa obserwacja pomyślałem sobie, jak łatwo przy pomocy valgrind znajdziemy wycieki pamięci. Szczególnie kiedy chciałbym coś napisać na urządzenie wbudowane, którego wielkość pamięci RAM to nie są GB a MB, przemyślę jednak w jakim języku napisać kod. 
Nie chciałbym wpaść w totalne błędne wnioski, że nie można tego robić w Pythonie i tylko w GOlang, gdyż może to być błąd mojej wersji i w kolejnej zostanie naprawiony. Oczywiście, tak błachy błąd dla jednych programistów jest powodem do kolejnych eksperymentów dla innych. 

W związku z tym zapraszam do wypowiedzi, jakie macie doświadczenia z valgrind? Z jakich ciekawych sytuacji wyratował Was ten tool w pracy zawodowej? 


20 sierpnia 2020

Ponad rok na Kali Linux z punktu widzenia 15 lat pracy na Ubuntu Linux

Kali Linux, jak każda dystrybucja bazująca na Ubuntu Linux, który z kolei bazuje na bazie Debian Linux to sprawa dość nieskomplikowana w codziennym użyciu dla DevOps, developerów i adminów. Linux kernel, jest tam aktualizowany, można używać pełnego zestawu narzędzi wizualnych np: gnome i to się spina bez bólu na desktopie. Nie zauważymy różnicy na desktopie w codziennym użytkowaniu.

 


Nie to jednak jest w Kali Linux fajne i praktyczne, że działa podobnie do Ubuntu Linux. Jak większość z was wie, Kali Linux stał się ulubioną dystrybucją: ludzi z gimnazjum, "hackjerów" ;-), white hackerów, testerów penetracyjnych,  red teamów i wielu innych profesji skoncentrowanych wokół bezpieczeństwa systemów i aplikacji w IT, ale też amatorów różnych rozrób i problematycznych sytuacji. 

To jest temat na odrębny wątek, jak ludzie - w tym dzieci - mogą uszkodzić coś lub wpaść w kłopoty, kiedy "przyhaczą" coś na Kali Linux. 

Musimy zdawać sobie sprawę, że z natury zawód związany z tzw. SECURITY w IT to ludzie często na tyle zaawansowani technicznie, że żarty to nie jest ich główne zajęcie a niesamowite analizy włamań/malware/trojanów/wirusów/skany sieci/diagnozy powłamaniowe/predykcje ryzyk/odkrywanie ukrytych otwartych portów i usług/szybkie i trafne decyzje. Szacunek! 

Natomiast, kiedy czasami czytam i słucham różnych opowieści, jak przysłowiowy Janusz "przyhaczył" dzięki Kali coś grubego ... ja tego nie popieram i tym wpisem nie zachęcam do takich działań. Chiałem to napisać, aby z pełną świadomością oznajmić, że jeśli używasz Kali Linux, to nie jest tak, że jesteś bezpieczny i niewidzialny. Po prostu masz w rękach narzędzia, którymi możesz też zrobić z wirtualnego problemu namacalny realny incydent. Tego nie popieram i ten wpis jest nie jest instrukcją użycia narzędzi a subiektywną opinią, którą przedstawiam w celach edukacyjnych. Bawicie się Kali Linux na własne ryzyko, wszelkie poniesione szkody, komplikacje, inne zdarzenia są wyłącznie Waszą odpowiedzialną decyzją. A za dzieci odpowiadają rodzice w większości cywilizowanych krajów.  

Jak pewnie większość z Was zdaje sobie sprawę, w Kali Linux mamy wielki potencjał do testów bezpieczeństwa. Tzn. są tam fantastycznie skatalogowane zestawy narzędzi do różnych typów działań w obszarze tzw. bezpieczeństwa IT. Oto lista kategorii, w których w Kali Linux możemy dotrzeć do profesjonalnych narzędzi pentesterskich tzn. otwartego oprogramowania, wolnego od licencji, dzięki któremu możemy wyszukiwać różne informacje, dane, błędy, naruszenia i wady systemów operacyjnych, protokołów oraz aplikacji.

Do czego ja używałem Kali Linux - wyłącznie do rozwiązywania na nim zadań w ramach tzw. konkursów CTF, czyli "capture the flag". Są to odbywające się weekendowo wyzwania dla zaawansowanych użytkowników komputerów, w których zagadki zaczynają się od banalnych binarnych trickach, poprzez rekonesans na gotowych wirtualnych maszynach, analizę obrazów i ukrytych w nich szyfrów, zagadnienia sieciowe, XSS, SQL Incection, wady serwerwów www, autorskie dekodowanie kart perforowanych i wiele na prawdę ambitnych zagadek  a kończą na odnajdywaniu przy pomocy dekompilacji kodu asemblera nieznanego procesora jakich instrukcji, które zawieszą kod programu :-)

Tak, około roku zabawy na takich konkursach potrafi wzmocnić umiejętności rozwiązywania "różnych" incydentów w IT. Spokojnie polecam dołączenie do zespołu lub indywidualne startowanie w konkursach CTF - co ciekawe, odkrywając flagę za każdym razem uczymy się czegoś nowego o IT. Tak, to zajęcie uczy tzw. szacunku do problemów zawodowych oraz postrzegania tego, co jest na prawdę ważne, wnikliwości i tego jak szybko jesteśmy w stanie nauczyć się np: nowego języka programowania w kilka godzin, aby móc zdebugować w nim quasi-program. 

Kali Linux to nie tyle system operacyjny do CTFów, ale przede wszystkich zwykły Linuxowy OS do codziennego użytku dla ludzi z branży IT. Chciałem w dalszej części skoncentrować się na jednym ciekawym przypadku, który rozgrzebałem technicznie i stał się na tyle podejrzany dla mnie w dystrybucji Kali Linux w odniesieniu do Ubuntu Linux, że zechciałem o nim wspomnieć.

Jakiś czas temu zrobiłem ciekawy switch i mając Ubuntu 20.04 LTS wykonałem niniejsze polecenia, które zamieniły mojego Ubuntu w Kali - to bardzo fajne tricki możliwe w Linuxowym świecie :-) 



Tak na marginesie: jak wiemy Windows zamieni się niebawem w Lindowsa i możliwe, że też jednym pstryczkiem, ale za tym stoi wielka maszyneria biznesowa, aby nie utrzymywać swojego dość wadliwego jądra. Tak mam na myśli M$, który porzuciłem ~20 lat temu w domu i pracy, co bardzo otworzyło mi oczy i nie to była dość trafiona decyzja. Tak, wiem Azure to już w większości Linux od wielu lat i M$ też wie jak kompilować jądro i dopisują swoje rzeczy do kernela ... ale ta firma nie robi nic bezinteresownie, bo każda firma z założenia zarabia. Nawet wtedy, kiedy musi porzucić swój plan budowy jądra systemu operacyjnego a bierze Linux Kernel z Open Source, pisząc wszem i wobec, że "my też to stworzyliśmy". I mają prawo tak rzec, bo commitują swoje zmiany do kernela LInuxa, ale jak wiemy, w tych czasach marketing może robić z takimi działaniami cuda.

Powracając do myśli przewodniej, jestem zadowolony z Kali Linux jako desktopowego Linuxa i polubiłem ten zestaw narzędzi do CTFów, którego używam czasami do rozwiązywania problem, które zdarzają się przy produkcji oprogramowania. Jedna sprawa mnie zmartwiła w wersji Kali 2020.3:

$ lsb_release -a

No LSB modules are available.

Distributor ID: Kali

Description: Kali GNU/Linux Rolling

Release: 2020.3

Codename: kali-rolling


Otóż po jakimś czasie - odtwarzalne na trzech różnych maszynach - pojawiły się nierozwiązywalne metodą "--fix-*" z apt-get konflikty, przy poleceniu standardowym aktualizacji paczek systemowych:

sudo apt-get upgrade

Wygląda to mniej więcej tak:

$ sudo apt-get upgrade 

Czytanie list pakietów... Gotowe

Budowanie drzewa zależności       

Odczyt informacji o stanie... Gotowe

Należy uruchomić "apt --fix-broken install", aby je naprawić.

Następujące pakiety mają niespełnione zależności:

 gnome-control-center : Wymaga: gnome-control-center-data (>= 1:3.36.4-1) ale 1:3.36.4-0ubuntu1 jest zainstalowany

 gnustep-base-runtime : Wymaga: libobjc4 (>= 4.2.1) ale nie jest zainstalowany

 libgnustep-base1.27 : Wymaga: libobjc4 (>= 4.6) ale nie jest zainstalowany

E: Niespełnione zależności. Proszę spróbować wykonać "apt --fix-broken install" bez pakietów (lub podać rozwiązanie).

i co najgorsze zachowuje się bardzo słabo w naprawie i skutki są dość słabe. Po kolei:

- wykonanie w/w apt'a z zalecanym "--fix-broken" powoduje, że nie może wykonać się do końca poprawnie, brakuje mu obrazka

$ sudo apt --fix-broken install

Czytanie list pakietów... Gotowe

Budowanie drzewa zależności       

Odczyt informacji o stanie... Gotowe

Naprawianie zależności... Gotowe

Następujące pakiety zostały zainstalowane automatycznie i nie są już więcej wymagane:

  cryptsetup-nuke-password efibootmgr finalrd fonts-wine gnome-control-center-faces gparted-common

  grub-efi-amd64-bin humanity-icon-theme kpeople-vcard libboost-filesystem1.67.0 libboost-system1.67.0

  libboost-thread1.67.0 libcapi20-3 libdb5.3:i386 libebml4v5 libfaudio0 libfprint-2-tod1

  libgsoap-2.8.91 libgtkmm-2.4-1v5 libgtkspell0 libhogweed5 libigdgmm11 libkaccounts1

  libkf5contacts-data libkf5contacts5 libkyotocabinet16v5 liblz1 libmatroska6v5 libmng2 libnettle7

  libnfsidmap2 libnumbertext-1.0-0 libnumbertext-data libopenshot-audio6 libopenshot16 libopenvdb7.0

  libpcre2-8-0:i386 libplacebo7 libpoppler82 libprotobuf-lite22 libprotobuf22 libqrcodegencpp1

  libqxp-0.0-0 libsrt1 libstaroffice-0.0-0 libstb0 libtokyocabinet9 libtsk13 libvkd3d1 libvolume-key1

  libwagon-http-shaded-java libwhisker2-perl libwine libzmf-0.0-0 node-normalize.css

  python-backports.functools-lru-cache python-bs4 python-html5lib python-lxml python-numpy

  python-soupsieve python-webencodings python3-ecdsa python3-entrypoints python3-pycryptodome rpcbind

  shim ssh-import-id ubuntu-mono wine64

Aby je usunąć należy użyć "sudo apt autoremove".

The following additional packages will be installed:

  gnome-control-center-data guile-2.2-libs inkscape libgc1 libgdl-3-5 libgdl-3-common libgsl25

  libgslcblas0 libgtkspell3-3-0 libmailutils7 libmariadb3 libobjc4 mailutils mailutils-common

  mariadb-common

Sugerowane pakiety:

  inkscape-tutorials libsvg-perl libxml-xql-perl pstoedit python3-uniconvertor gsl-ref-psdoc

  | gsl-doc-pdf | gsl-doc-info | gsl-ref-html mailutils-mh mailutils-doc

Polecane pakiety:

  python3-scour

Następujące pakiety zostaną USUNIĘTE:

  libgc1c2 libgsl23 libmailutils6

Zostaną zainstalowane następujące NOWE pakiety:

  libgc1 libgdl-3-5 libgdl-3-common libgsl25 libgtkspell3-3-0 libmailutils7 libmariadb3 libobjc4

  mariadb-common

Następujące pakiety zostaną zaktualizowane:

  gnome-control-center-data guile-2.2-libs inkscape libgslcblas0 mailutils mailutils-common

6 aktualizowanych, 9 nowo instalowanych, 3 usuwanych i 763 nieaktualizowanych.

841 nie w pełni zainstalowanych lub usuniętych.

Konieczne pobranie 0 B/28,4 MB archiwów.

Po tej operacji zostanie dodatkowo użyte 25,4 MB miejsca na dysku.

Kontynuować? [T/n] T

Konfigurowanie pakietu libgcc-s1:amd64 (10.2.0-9) ...

Konfigurowanie pakietu libseccomp2:amd64 (2.4.4-1) ...

(Odczytywanie bazy danych ... 647544 pliki i katalogi obecnie zainstalowane.)

Przygotowywanie do rozpakowania pakietu .../gnome-control-center-data_1%3a3.36.4-1_all.deb ...

Rozpakowywanie pakietu gnome-control-center-data (1:3.36.4-1) nad (1:3.36.4-0ubuntu1) ...

dpkg: błąd przetwarzania archiwum /var/cache/apt/archives/gnome-control-center-data_1%3a3.36.4-1_all.deb 

(--unpack):

 próba nadpisania "/usr/share/pixmaps/faces/bicycle.jpg", który istnieje także w pakiecie gnome-control-center-data

enter-faces 1:3.36.4-0ubuntu1

dpkg-deb: błąd: podproces wklej został zabity sygnałem (Przerwany potok)

- uruchamia się w nieskończoność appport raportujący te błędy, przez co syslog osiąga GB wielkości i zapycha dysk, dalej jest już wiadomo bardzo trudno pracować na systemie z 0 miejsca na partycji systemowej !

- problem jest słabo opisany w sieci i jedyny motyw na odzyskanie miejsca na dysku to usunięcie z /var/crash/ plików !!!


$ ll /var/crash/gnome-control-center-data.0.crash 

-rw------- 1 root whoopsie 386566 paź  9 17:42 /var/crash/gnome-control-center-data.0.crash

$ sudo rm /var/crash/gnome-control-center-data.0.crash 


Uważam, że to jest dość ważny aspekt, aby takie narzędzie jak apt działało poprawnie i tutaj w Kali Linux spotkałem się z mega blokadą, nie pomaga dist-upgrade, nie pomaga szukanie dziury w całym przy pomocy strace, kończy się tym, co kojarzę z RedHat sprzed 20 lat, tzn. chcesz mieć spełnione zależności, to sobie je spełnij sam :-) Rozumiem, że osoba która jest wydawca pakietu mogłaby mnie wspomóc w temacie, o ile to problem z pakietem - nie wydaje mi się, bo próbowałem też dpkg i efekt jest identyczny.

Inny drobny brak w distro Kali Linux - tak mogę to określić - to niedziałająca domyślna obsługa filesystemów takich jak vboxfs (chciałbym sobie na vagrancie i virtualbox zrobić testy), czy LUKS (chciałbym odczytywać szyfrowane wolumeny). Rozumiem, że to sobie mogę doinstalować, ale niespodzianką było dla mnie włożenie pendrive z zaszyfrowanymi danymi przy pomocy LUKS w Kali Linux nie skutkuje automontowaniem i pytaniem o hasło. W Ubuntu Linux takie rozwiązania działają z paczki. Tak, wiem Kali Linux nie do tego celu był stworzony i nie chcę się o to spierać :-) Nadmieniam tylko, że nie zawsze potrzebujemy specjalnej dystrybucji, która rozwiązuje nasze potrzeby. Twierdzę, że czysta (z linii LTS) wersja Ubuntu jest na tyle wytestowana przez userów i naprawiana na bieżąco przez devów, że o wiele prościej rozwiązuje się takie codzienne zagadki jak te z aptem opisane powyżej w Kali Linux.

Reasumując - polecam pomimo opisanych incydentów Kali Linux zaawansowanym użytkownikom i profesjonalistom, zniechęcam amatorów i noobów :-)

Ubuntu Linux po kilkunastu latach trenowania/testowania/używania/pracy/zabawy/odkrywania przedstawił mi się w wersji 20.04 LTS jako system dość dobrze ustabilizowany w codziennym użytkowaniu do pracy i w zastosowaniach  domowych. Polecam Ubuntu Linux, bo jeśli z Windows znane są Wam nadmiarowe programy ochronne, które musicie tam posiadać, bo trojan i wirus czeka, aby się zemścić - to w Ubuntu Linux firewalle, snorty, auditlogi są dość uproszczone i nie wyżerają 30% CPUs a pozwalają na bezpieczną pracę i zabawę również na desktopie.

19 marca 2020

Identicon, avatar, robohash i inne graficzne reprezentacje danych

Widzieliście nieraz ikonki generowane z automatu i być może zastanawia Was, czym są, jak powstają, czy ich ilość jest skończona. W tym wpisie postaram się nakreślić ogólnie zarys koncepcji kilku powszechnych:

Naturalnie w/w identyfikatory można wygenerować sobie przy pomocy kodu OpenSource (linki pod w/w nazwami). To nie jest koniec, jeśli chodzi o eksplorację indenticon, oto lista na githubie do wyników wyszukiwania implementacji identicons w różnych językach programowania.

Rozpocznę kilkoma wygenerowanymi przykładami, które przybliżą, o czym chciałbym tutaj napisać:







Jak niektórzy zdążyli zauważyć najbliższy branży IT identicon to wizualizacja odcisku klucza OpenSSH. Kiedy generujemy klucz, jak pamiętacie pojawia się taka jak w animacji powyżej tekstowa reprezentacja.
Wszelkie identicony mają na celu pokazać w postaci obrazka odcisk/odpowiednik klucza lub napisu, który wprowadza się na wejście.

Jak pewnie niektórzy kojarzą, domyślny avatar w githubie jest właśnie generowany takim sposobem. Projekt WordPress również ma swoje odpowiedniki.
Często mamy sytuację, w której chcemy w łatwy sposób rozróżnić osoby, których tylko imię lub pseudonim znamy - tutaj przydają się identikony. Prawdopodobnie najczęstszymi ich przykładami są różne osoby na różnych platformach dyskusyjnych, takich jak czaty, fora, strony wiki lub systemy śledzenia incydentów/problemów.

Punktem wyjścia do wizualizacji dowolnych danych jest często funkcja skrótu lub z ang. hashowanie. Hashowanie w tym kontekście ma na celu przedstawienie wartości stałej długości na podstawie zmiennej długości danych wejściowych. Ta reprezentacja stałej długości jest tylko dużą liczbą, która może być następnie wykorzystana jako punkt wyjścia do rozróżnienia różnych informacji.

W momencie, kiedy mamy już liczbę możemy w powtarzalny sposób stworzyć reprezentację na jej podstawie. I tak dzięki trickom programistycznym, artystycznej fantazji i oszukiwaniu wzroku można ukrywać ale też przekazywać informację wizualną ludziom. Jest taki dość znaczący rozdział psychologii oraz dziedzin pochodnych t.j. doświadczenie użytkownika (ang. User Experience / UX), gdzie tzw. Pre-attentive Processing jest wykorzystywany. Zakładamy, że człowiek posiada ograniczoną percepcję wzrokową i aparat wzroku działa w sposób specyficzny. To oznacza, że niektórymi cechami obrazu można na odbiór informacji wpływać świadomie lub podświadomie.
Czyli np. bazując na mieszaniu koloru, nasycenia barwy, jasności, formy, położenie przestrzenne i przesunięcia można zbudować dość atrakcyjne wizualizację i ikony. Jest też ogromna dziedzina (ikono)grafiki komputerowej, która bazuje zasadniczo m. in. na tych założeniach.

Z punktu widzenia realizacji i algorytmów używanych w identicons, są to sprytne kilku linijkowe przesunięcia bitów/maskowania/mieszania z losowaniem wartości. Istnieją też opcje losowania elementów identicon z listy kilku obrazków bazowych i składanie w całość t.j. tutaj w MonsterID:



Kolejnym wartościowym przykładem użycia identiconów są portfele wirtualnej waluty (kryptowalutyEthereum:



Moim faworytem ze względu na zainteresowanie robotyką oraz atrakcyjny wygląd są RoboHASHe. 
Istnieje wiele gotowych generatorów t.j. np: ten dla RoboHash.



Obliczmy liczbę różnych robotów, które możemy wygenerować:
- Istnieje 5 różnych części ciała
- Istnieje 10 różnych kształtów dla każdej części ciała
- Istnieje 10 różnych kolorów robota
- Istnieje 10 różnych kolorów tła
W sumie to 10⁵ * 10 * 10 = 10 000 000 różnych robotów. 
Nie jest to nawet blisko liczby różnych adresów, która wynosi ~ 2²⁵⁶ = 10⁷⁷. 
Chociaż prawdopodobnie niemożliwe jest wygenerowanie czegoś zbliżonego do 10⁷⁷ różnych, 
dobrze rozpoznawalnych, dobrze zapamiętywalnych identiconów na powierzchni 128x128 pikseli, 
tylko dlatego, że zdolność ludzi do przetwarzania obrazów jest ograniczona. 
Dlatego identicons nigdy nie może być pomiarem bezpieczeństwa 
i nigdy nie zastąpi potrzeby dokładnego sprawdzenia adresu przed potwierdzeniem krytycznego transferu. 
Chociaż ich entropia jest pomijalna w porównaniu do przestrzeni adresowej, 
aby szybko uzyskać przegląd historii transakcji lub rozróżnić własne konta, identicons są bardzo cenne.

Warto zdawać sobie sprawę, że w branży IT potrzeba jest matką wynalazców i tak też w przypadku identiconów było - po prostu ludzie nie wgrywali swoich avatarów/ikonek, przez co pustka została zapewniona twórczością artystów-programistów :-)

Jeśli posiadacie swoje patenty/algorytmy na identicony, zapraszam do umieszczania w komentarzach linków do kodu lub gotowych generatorów.



Materiały:

  


9 kwietnia 2019

Startuje Google Cloud Next ’19 - keynote, chmura hybrydowa, Atheros, Kubernates

Jak każdy z Was nie mogłem się doczekać nowości ze stajni Google For Developers.
Oto po 18-tej ożywiła się transmisja live na youtube z Google Cloud Next ’19 i przez najbliższych kilka dni zapowiada się naprawdę ciekawie.
Na ten moment szef Google Sundar Pichai opowiedział co jest ważne w obecnej dekadzie. Na szybko, z tego co widać na slajdzie będą to trzy hasła:

  • Infrastructure - infrastruktura jako uniwersalne dobro do budowania świata wirtulanego
  • Innovation - innowacja rozumiana jako używanie nowoczesnych rozwiązań
  • Openness - otwartość, czyli bądźmy bliżej Open Source

Zdecydowanie jestem za, o ile faktycznie z tą otwartością w oprogramowaniu się tak dobrze przyjmie w Open Source, to każdy będzie mówił Kubernates zamiast infrastruktura serwerowa. Zdecydowanie na tym zależy firmie Google, więc specjalnie na tą okazję nazwała/stworzyła swoją adaptację czegoś, do czego możemy przemigrować z Kubernates o nazwie Anthos.


Jaka z kolei filozofia marketingowa stoi za Anthos:
  • Bazuje na technologii Open Source
  • Uruchom na żądanie, na multi i mieszanej chmurze
  • W pełni zarządzalny przez Google
Po tych frazach mam wrażenie, że Google promuje niezarządzalną werję Kubernates z UI w webie i konsolą w ich webshellu. Oczywiscie moje przypuszczenia nie były z kosmosu, oto w następnym wystąpieniu widzimy demo live, które pokazuje jak zmigrować z Kubernates do Anthos :-).

Wcześniej dowiadujemy się o głównych zaletach projektu Anthos:


 Oto zrzuty z live demo - tutaj zwrócić muszę uwagę na coś, co mi się podoba, tzn. graf przepływów pomiędzy modułami i pokazane w czsaie rzeczywistym metryki ruchu w żądaniach na sekundę (rps).
Przypomina ficzer zaczerpnięty z pewnego znanego mi projektu Open Source, którego nazwa jest taka niepasująca do dziedziny ;-) 
Niewątpliwie Google gwarantuje wysoką dostępnąć HA, automatyczną skalowalność i wiele potencjalnie typowych ficzerów w dzieiejszym świecie clouda publicznego.






Początek dla osób związanych z chmurami obliczeniowymi nie jest zaskoczeniem, domyślam się, że jak rok temu pokażą coś z dziedziny Machine Learning, jako ciasteczko na torcie i nie mogę się doczekać, co to będzie.

Osobiście gratuluję wytrwałości i sporego nakładu pracy Googlersom i firmom zrzeszonym w tych wielkich inicjatywach ... jednym słowem są to "bardzo praktyczne narzędzia"  w mojej codzinnej pracy ;)

BTW: gdzieś tam w tle widziałem obrazek sugerujący zastosowanie chmury Google w przemyśle, może coś ciekawego się trafi z mojej ulubionej dziedziny Internet of Things ... 











4 kwietnia 2019

Internet Rzeczy + Społeczeństwo zerowych kosztów krańcowych - recenzja książki Jeremyiego Rifkina

Z jednej strony piszę o technicznym mięsie branży IT a z drugiej gdzieś czuję, że to wszystko się składa w wytwarzanie dóbr. Oczywiście dobra wytwarzają społeczeństwa, czyli nie tzw. "mistyczne państwa" a pojedyńcze jednostki, które posiadają marzenia, planują coś i następnie realizują. Chciałbym w związku z tym podzielić się z Wami przemyśleniami n.t. książki, którą polecałem wielu osobom w trakcie prowadzonego ostatnio meetupu na temat Internetu Rzeczy, Sprzętu i Robotyki


Dzieło, o którym mowa to jest "Społeczeństwo zerowych kosztów krańcowych" autorstwa Jeremyiego Rifkina.



Książka jest nie przykładem wylewnego wykładu z ekonomii, ale zwiera na wstępie bardzo ciekawy - jak dla osoby technicznej - przytoczony fragment historii z kształtowania się popytu i podaży na światowej scenie. Na tle tej historii autor dociera do tematu, który zdradza podtytuł o tym, że każdy współcześnie element życia podlega kapitalistycznemu systemowi, który wspólnie karmimy naszą codzienną pracą oraz potrzebami. Coraz mniej ludzi rozumie pojęcia t.j. wspólnota, komuna (bez skojarzeń z PRL), zbiór ludzi robiących coś co wszyscy jednogłośnie chcą (bez żadnych łask i sztucznych przymusów). Tutaj na scenie pojawia się Internet Przedmiotów, który wychodzi z fazy nic nie mówiącego zwrotu i autor zaczyna odkrywać przed nami szczegóły możliwej przyszłości społeczeństw, które dzięki dzieleniu wiedzy/zasobów/dóbr będą w stanie być samowystarczalne bardzej niż od jednej pensji do kolejnej :-)

Wspólnota współpracy, o której wielokrotnie w książce wspomina autor towarzyszy IoT, blockchain, robotyka, programowanie i ogólna zgoda zbiorowości ludzkiej do przejęcia władzy nad tym co teraz zatraca się w wirtualnych wartościach.

Wg. autora pojęcie internet rzeczy skaluje się do komunikacji, energetyki i logistyki. Dzięki temu skalowaniu powstanie integralna infrastruktura, którą stworzą obywatele niezależnie od państw - tak jak stworzyli internet (World Wide Web). Ta infrastruktura XXI wieku to inicjatywa, która będzie wyzwaniem dla ludzi a nie państw, dzięki czemu koszta jakie generują organizatorzy/zarządcy/urzędnicy zostaną wyzerowane. Te koszta to będzie czas i chęci jednostek do dzielenia się dobrami. Przykładem idealnym ze świata IT jest otwarte oprogramowanie (Open Source), gdzie wolontariusze z całego świata tworzą dla idei i często w wolnym czasie, niekiedy za darmo szacuję, że jakieś 80% kodu, który utrzymuje usługi internetowe. Od otwartych języków programowania, poprzez darmowe szkielety aplikacyjne (frameworks), darmowe bazy danych, wszelkie otwarte protokoły komunikacyjne, protokoły bezpieczeństwa i inne darmowe rekomendacje (RFC), na których opiera się dzisiejszy interent.

Skuteczne wyzerowanie kosztów to przejściowo gospodarka hybrydowa wg. autora: częściowo rynek usług płatnych a częściowo wspólnoty, które dzielą się dobrami i chętnie ze sobą współpracują. Taki inny przykład zapoczątkowanego trendu opisywanego w książce to niewątpliwie Druk 3D, gdzie każdy kupując dzisjiaj tanią drukarkę jest w stanie zbudować na niej 60% części do kolejnej i co ciekawe drukować w różnej skali przedmioty, o których mogliśmy do niedawna tylko marzyć. Rynek dostarcza prąd oraz materiał do druku a otwarte portale z wieloma gotowymi projektami dają nam przykładowe i często praktyczne przedmioty do wydruku.

Wg. autora książki idealna sytuacja to minimalizacja kapitalizmu wyniszczającego naturalne cechy społeczeństw.  Zasadniczo rynek komercyjny będzie dawał podstawy do budowania rozwiązań, które razem społecznie możemy wytworzyć i oczywiście globalna myśl "jak żyć" nie musi pochodzić z reklam od TOP 10 światowych firm. 

Ja rozumiem przekaz Rifkina tak, że Internet of Things to początek technologicznych przemian. Jak wiemy np: po trendzie "mobile first", urzędzeniach noszalnych smartwatachach/wearable, które wykończyły ilością szwajcarskie zegarki zawsze zaczyna się w tych czasach od powszechności technologii. Jeśli IoT faktycznie zostanie zrozumiane przez ludzi właściwie jako dobro, z którym można żyć i czymś, czym należy się dzielić, to kierunek komercyjny przestanie mieć znaczenie. Pociągnie to za sobą trend działania firm, które będą musiały otwierać swoje zbiory danych, interfejsy do bramek z danymi, API i kod. Inaczej nie będą się liczyć na otwartym rynku. Nie wiadomo, czy to nie zajmie nam kilku dziesięcioleci zanim wizja Ryfkina z książki stanie się codziennością. Aczkolwiek znam ludzi, którzy twierdzą, że jest kilka powodów, że to naturalnie przyspieszy rozwój świata i popłyniemy w podbój kosmosu jako oczywisty kierunek ekspansji.

Wierzę w to, że jako społeczeństwo ludzie są mądrzejsi, kiedy ich działania skupiają się przy ich naturalnych potrzebach. Wiem również, że nauczanie społeczne nawyków nie idzie systemom edukacyjnym za dobrze - pomijając nieliczne szkoły t.j. duńską i fińską. Wierzę zatem, że w społeczeństwie wspólnoty - o której pisze autor - będziemy sprawniej weryfikować, czy to czego uczą nasze dzieci w szkołach będzie służyło nam nam przyszłość, czy wytwarzało tzw. "tramwajowe zombie". 

Obyśmy nie otyli od dostarczanej treści teksowej/reklamowej/audio/wideo i byli w stanie społecznie mądrze wykorzystać dobra Internetu Przedmiotów, wówczas kolejne pokolenia ludzi będą mogły nas wychwalać nie tylko na kartach historii i lubować się kolejną wojną światową, ale w codziennym życiu za to, że nie przegapiliśmy okazji do udoskonalania się ;-)

Szczerze polecam omawianą książkę i celowo nie zdradzam wszystkich sekretów zapisanych na jej kartach, abyście mogli przeczytać i przetrawić neutralnie swoje przemyślenia. Jeśli coś Wam się pojawi piszcie oczywiście w komentarzach.  







17 sierpnia 2018

Chaos Monkey - zasymulujmy awarię pod kontrolą

Od kilku lat temat Chaos Monkey jest ciekawą zabawką dla wielu inżynierów oprogramowania i SRE (Site Reliability Engineering). Postaram się naświetlić koncept i działania mające na celu poprawę jakości produktów w architekturze SOA (mikroserwisów).



Wstęp

 Zacznę od początku, bo na początku projektu jest (mikro)usługa, która komunikuje się z inną/innymi poprzez API. Obecnie modne w web developmencie jest REST API, jak każdy wie działające w oparciu o protokół HTTP (a ten na TCP/IP). W związku z tak niewielką zmianą sposób wymiany danych od kilkunastu lat, błędy jakie mogą się przytrafić podczas działania w takiej typowej architekturze również są powtarzalne. 

Mam na myśli fakt, że architekci/programiści/testerzy popełniają te same błędy i stale jest dyskusja dlaczego. Otóż dlatego, że liczy się "metodyka zwinna" wdrażania małymi krokami, a w takich krokach kompleksowe testy wydajnościowe/wysokiej dostępności niekiedy nie mają szansy zostać zrealizowane. Często zespoły mając już na produkcji zmianę mają testy na żywym organizmie. Łatwo dojść może do kolejnego poważnego incydentu, który nie zawsze opatrzony zostanie stosownym komentarzem i wiedza o przyczynie nie zostanie przedstawiona na większym forum. Tzn. inne zespoły nie dowiedzą się wcześniej niżeli przed identycznym incydentem na swoich usługach.

Jeśli nie wiecie, to takie testy prowadzą od dawna w NASA, w wojsku i w systemach medycznych oraz automatyce przemysłowej. Tzn. po wdrożeniu systemu często generuje się tzw. chaos i obserwuje, czy odpowiednie kontrolki w monitoringu zapalają się, informując operatorów o konkretnych problemach. Mogą oni podjąć racjonalne decyzje w kwestii np: przeżycia innych członków zespołu, czyli ocalić czyjeś życie. Bo jak wiemy w wielu profesjach jesteśmy skazani na błędy maszyn i ich oprogramowania. Tak, już od wielu lat oprogramowanie stanowi element naszego życia i warto dbać o jego jakość, bo istotne jest też to, że mniej niepotrzebnych nerwów - np: z powodu wad w sofcie - u człowieka wydłuża jego życie :-) To nie jest mój wymysł, ale obserwacja zachowań kolegów po ok. 20 latach pracy w IT. Jak to niektórzy mawiają, "nie każdy jest na tyle cierpliwy, aby przeżyć awarię i odnosi to dość osobiście". Po części z tym się zgodzę, bo widziałem odejścia z pracy ludzi, którzy nie zgadzali się z bylejakością i zwyczajnie z powodów zdrowotnych rezygnowali z miejsca pracy, bo dusiło ich to, że np: nie mają wpływu na podniesienie jakości.

W obecnych czasach w IT każdy człowiek w zespole, jak również zarząd mają wpływ na jakość produktów, które tworzą lub zlecają do wytworzenia. Idąc tym tropem, pojawia się "chaos", tzn. naturalna kolej rzeczy na produkcji, jeśli nie założymy, że przetestujemy system pod kątem chaotycznego/nietypowego działania. Ba niektóre firmy doszły do takiej wprawy, że testy chaosu potrafią robić na produkcji - tak, nie jest to literówka - i poziom wysokiej dostępności, jaki osiągnęli umożliwia takie działania.

Nieco historii - pewnego pięknego dnia - ok. 10 lat temu - pojawił się arttykuł "5 Lessons We’ve Learned Using AWS" na blogu Netflix, który oświecił cały świat IT w tematyce Chaos engineering.
Od tego momentu wiele firm budujących ze świadomością swoją infrastrukturę zarówno wewnętrzną, jak i hybrydową z użyciem publicznych chmur obliczeniowych, zaczyna inaczej postrzegać jakość i wysoką dostępność. To było epokowe odkrcie, bo świat chaotycznych testów jest dość fascyjnujący :-)

Co ludziom z IT dają testy chaosu

Chaos Monkey wprowadza tutaj w pracy zespołów celowe zamieszanie, które zapewnia w sposób kontrolowany poznanie wad sprzętu / oprogramowania / protokołów a także całego stosu technicznego. Wspomaga zespoły w ich pracy, o ile nie robią same takich testów w ramach kontroli jakości.

Zasada jest prosta: spróbujmy coś wyłączyć, zmienić przepustowość, zmienić jakiś timeout, rozłączać wymagane połączenia pomiędzy serwerami / usługami i mamy "niemalże" gwarantowane problemy, na którejś z warstw naszych usług. A jednak - okazało się, że jest jeszcze jakaś praca do wykonania, aby nazwać nasz system "wysoko dostępnym".

Tak, mam tutaj na myśli automatyczne generowanie "wywrotek" różnych części systemów, aby nauczyć się w praktyce, co jeszcze należy poprawić, aby nasze produkty były odporne na różnego typu błędy. Bo w sumie klienci są zadowoleni z tego, że coś co im oferujemy działa z ich punktu widzenia a naszą rolą jako inżynierów oprogramowania jest zapewnienie im tego komfortu. Tak, pomimo, że wiemy o tym, że połowa usług w jednej serwerowni padła i nie ma szansy na działanie. Ale o tym wiemy my a nie klienci i do tego zmierzają takie testy - wychwycić braki w jakości/ciągłości działania systemów możliwe wcześnie przed awarią postrzeganą przez klientów jako niedogodność. Liczy się uśmiech każdego klienta :-)

Z technicznego punktu widzenia zapewniamy testując chaosem wiedzę o tym jak działa system w kilku ważnych wymiarach:
dostępności (ang. Availability)
- wydajności (ang. Performance)
- zestaw powiązań (ang. Feature Set)
- integralności komponentów (ang. Components Integrity)
integralności danych (ang. Data Integrity)


Jakiego rodzaju scenariusze testowe są najczęściej wykorzystywane?

 
- przełączanie bazy danych (ang. Database Colocation) - kiedy dwie różne bazy działające w trybie np: master-slave lub active-active doznają symulowanej awarii lub niestabailności

- problem z niewydajnymi zrzutami/indeksami/archiwizacją bazy danych (ang. Snapshot Impact) - kiedy wzrasta ilość zrzutów / logów / procesów archiwizacji ew. indeksacji na bazie danych

- aktualizacja klastra / supervisora / urządzenia sieciowego (ang. Rolling Upgrade) - kiedy mamy do czynienia z automatyczną aktualizacją klastra, wirrualnej maszyny, firmware na urządzeniach sieciowych

- wiele, wiele innych "niesamowirtych" zjawisk w IT ...


Jak rozpocząć chaotyczne testy w naszym systemie

Na pewno od razu, po przeczytaniu tego posta ;-)

Jeśli chodzi o testy chaosu, to zakłada się zazwyczaj jakiś plan, który uwzględnia:

- poinformowanie innych zespołów, biznesu, programistów i działu jakości + monitoringu, w jakim przedziale czasu będą odbywały się takie testy i na jakim środowisku. Szanujemy nerwy innych.

- zasymulowanie obciążenia o charakterystyce zbliżonej do PRODukcji i zaplanowanie scenariuszy, które będziemy przeprowadzali. Nie wszystko na raz, bo nie łatwo będzie nam wnioskować.

- przygotujmy sobie dedykowane metryki, KPI i wskaźniki, po których poznamy, że zaszły jakikolwiek anomalie. Tak, w pierwszej fazie nauczymy się działania naszego systemu w warunkach normalnych, aby pod testami chaosu zaobserwować i nazwać anomalie.

- umówmy się w kilka osób.zespołów, że chcemy razem to zrobić, aby innym też dać szansę na odkrycie być może swoich błędów w ich ulubionej/dziedzinowej warstwie.

- przygotować się na starcie na PRODukcji o ile na innych środowiskach jest wszystko w porządku i jak najbardziej w godzinach pracy zaplanować takie testy

- koniecznie jest utworzenie formalnego raportu z testów i podzielić się nim z całą firmą, aby wiedza rozpropagowała się po znakomitej większości ludzi odpowiedzialnych. Świadomość jest cenniejsza, kiedy mamy dla ludzi lekkostrawne dane, które łatwo odczytają/odnajdą. Nie chodzi mi tylko o geeków, ale też o biznes, który może być nieświadomy np: długu technicznego.

- stałe dyskusje, szkolenia. rozwój wiedzy technicznej zespołów i uświadamianie o typach awarii ludzi od biznesu - to jest stały element branży IT


Tak dla pełnej jasności, ten artykuł ma na celu zwrócenie Waszej uwagi na metodologię testów chaosu i wprowadzenie do tematu. Nie zachęcam nikogo do wystartowania takich testów bez porozumienia z liderami technicznymi i bieznesem. Wszelkie działania, jakich dokonacie po przeczytaniu tego artykułu wykonujcie z pełną odpowiedzialnością i świadomością konsekwencji (tzn. prawdopodobnej awarii lub niedostępności biznesu).


Jakie narzędzia mamy do dyspozycji

Temat jest na tyle wartościowy, że celowo nie będę tutaj przeklejał linków a podam dwa źródła, jakie rozwinął Waszą wiedzę z tego obszaru. Oto otwiera się przed wami nieskończony ocean chaosu :-)






Jeśli macie jakiekolwiek doświadczenie z testami chaosu i pozwalacie na takie praktyki piszcie, jak postrzegacie ten art.,  co odkryliście ciekawego dzięki tej metodzie testowania. 
Otwieram dyskusję na ten temat w komentarzach.



12 lipca 2018

Cloud Builders' Day Poznań 2018 - darmowe warsztaty z chmury AWS

Jak zwyczajnie bywa ciekawy temat mnie wzywa :-) i tak trafiłem na wydarzenie "Cloud Builders' Day Poznań 2018". Chciałbym podzielić się z Wami kilkoma faktami i przybliżyć czym jest taki dzień.

W czasach hybrydowych podejść do budowania infrastruktury rozproszonych aplikacji i mikroserwisów warto poznawać chmury publiczne. Wiedziałem po kilku fajnych dniach spędzonych w konsoli AWS oraz w Berlinie na AWS Summit Berlin, jak sprytnie i szybko można stworzyć produkcyjną usługę z kilkoma linijkami kodu. Jednak kiedy chcemy wrócić do tematu, gdy nie używamy wielu uslug z chmur publicznych na co dzień i zgłębić dziedzinę, z pomocą przychodzi  wydarzenie Cloud Builders' Day. Rekomenduję każdemu, kto się zastanawia nad wzięciem udziału.
Głównie dlatego, aby w niektórych przypadkach przed rozpoczęciem napisania własnej implementacji wykonać tzw. MVP (minimalna wersja produktu), PoC (udowodnienie konceptu) na klockach przygotowanych dla nas w chmurze. To na prawdę wspaniałe narzędzie do szybkiego prototypowania a w wielu powtarzalnych przypadkach do wdrożeń produkcyjnych. Decyzję pozostawiam Wam, bo ilość zmiennych w decyzjach architektonicznych jest zależna od postawionego problemu.

Chmury publiczne bardzo dostosowują się do potrzeb developerów i czasów, dlatego pomijanie ich w branży IT jest niejako ignorancją dobrobytu jaki niesie za sobą wszechobecna technologia.

Oto slajd z rozpoczęcia warsztatów.




Moje pozytywne wrażenia zawarte są w doświadczeniu praktycznym podczas tego warsztatu, kiedy poznawaliśmy tajniki konfiguracji i budowania aplikacji oraz infastruktur dla:

  • serwerów aplikacyjnych automatycznie skalujących się zależnie od metryk obciążenia/ruchu
  • małego klastra Hadoop do analityki Big Data
  • usługi tłumaczącej pismo na mowę i wysyłającej SMSa dzięki 'funkcji lambda'
  • składowania danych w magazynie obiektów (AWS S3 object storage)
  • budowania klastrów ECR i EMR
  • narzędzi wspomagających pracę developerską
  • ambitnych zadań z Machine Learning (ML)
  • ... i kilku innych praktycznych przykładów
A wszystko w 8 godzin i dla zdobycia odznak chmurowych :-) + dobrej zabawy w programowanie pod okiem ekspertów wprost z Amazona. Dzięki prowadzącemu Tomaszowi Stachlewskiemu warsztaty odbieram jako zabieg wyrafinowany, skrojony na miarę współczesnych potrzeb oraz dopracowany w każdej minucie :-)   





3 kwietnia 2018

Everything as Code - kodem opisujemy programy i systemy IT

"Everything as Code" to koncept, który przywołuje bazę programowania, czyli kod. Oczywiście większości z nas kod kojarzy się z pisaniem programów. Jednakże każdy system jesteśmy opisać również dedykowanym kodem i w ten sposób mamy zapewnionie analogicznie jak w przypadku programów sprawniejsze rozwijanie i utrzymanie systemów informatycznych.

Zgodnie z trendami w IT doszło do takiej sytuacji, że frazes "as code" został wykorzystany do wielu produktów, które pokrótcec w tym wpisie chciałbym przedstawić. Oto najpopularniejsze pojęcia, które bardzo silnie wpływają na propagowanie omawianej filozofi "... as code" w IT.

Configuration as Code

Configuration as Code ( CaC ) - Konfiguracja jako kod jest praktyką traktowania wszystkich części systemu jako kodu. Oznacza to przechowywanie konfiguracji wraz z kodem źródłowym w repozytorium, takim jak git lub svn. Przechowywanie konfiguracji kompilacji, właściwości aplikacji i konfiguracji wdrażania jako kodu oznacza, że ​​są one śledzone i można je odtworzyć jednym kliknięciem. Oczywiście w sytuacji ingerencji osoby z zewnątrz do systemu łatwo przywrócić stan konfiguracji automatycznie.

Centralne zarządzanie nawet bardzo rozproszoną konfiguracją to klucz do bezpiecznego i stabilnego systemu, w którym wiemy dlaczego coś działa zgodnie z ustawieniami.

Infrastructure as code

Infrastructure as code - ( IaC ) - Infrastruktura jako kod obejmuje projekt systemu, również zapisany jako kod. W starym świecie IT infrastruktura wymagała specjalistycznych umiejętności oraz fizycznego sprzętu i kabli do zainstalowania. Systemy były cenne lub nie były często dotykane / aktualizowane, ponieważ ludzie, którzy je stworzyli, nie działają już dla firmy. Początek przetwarzania w chmurze i aplikacji natywnych w chmurze sprawił, że jest to tania i łatwa w rozlokowaniu infrastruktura wirtualna. Przechowując konfigurację środowisk wirtualnych jako kodu, można je cyklicznie przetwarzać i odtwarzać w razie potrzeby.

Automatyzacja wdrożeń to klucz do bezpiecznego i stabilnego systemu, w którym poszczególne bloki / usługi / mikroserwisy mają swoją znaną z góry rolę.


Dlaczego infrastruktura jako kod?

Wirtualizacja, chmura, kontenery, automatyzacja serwerów i sieci zdefiniowane przez oprogramowanie powinny uprościć pracę działu IT. Zapewnienie, skonfigurowanie, zaktualizowanie i utrzymanie usług wymaga mniej czasu i wysiłku. Problemy powinny być szybko wykrywane i rozwiązywane, a systemy powinny być konsekwentnie konfigurowane i aktualne.
Pracownicy IT powinni spędzać mniej czasu na rutynowych pracach, mając czas na szybkie wprowadzanie zmian i ulepszeń, aby pomóc ich organizacjom w zaspokajaniu ciągle zmieniających się potrzeb współczesnego świata. Ale nawet z najnowszymi i najlepszymi nowymi narzędziami i platformami zespoły ds. Obsługi IT wciąż uważają, że nie nadążają za codziennym obciążeniem pracą. Nie mają czasu na rozwiązywanie długotrwałych problemów z ich systemami, a tym bardziej ich modernizację, aby jak najlepiej wykorzystać nowe narzędzia.
W rzeczywistości chmura i automatyzacja często pogarszają sytuację. Łatwość dostarczania nowej infrastruktury prowadzi do ciągle rosnącego portfolio systemów i potrzeba coraz więcej czasu, aby wszystko się nie zawaliło. Przyjęcie narzędzi chmurowych i automatyzacyjnych natychmiast obniża bariery dla wprowadzania zmian w infrastrukturze. Jednak zarządzanie zmianami w sposób poprawiający spójność i niezawodność nie wychodzi z pudełka z oprogramowaniem. Potrzeba ludzi, aby zastanowili się, w jaki sposób wykorzystają narzędzia i wprowadzą systemy, procesy i nawyki, aby skutecznie z nich korzystać.

Wartościowy cytat z wartościowej książki o IaC odpowiadający na postawione pytanie. Przy okazji polecam tą książkę jako lekturę podstawową w tym temacie. Oto jak prezentuje się okładka:



Potężne narzędzia operacyjne DevOps we współczesnych systemach IT

Od wielu lat poskramiamy rozwiązania w chmurach prywatnych, publicznych i hybrydowych. Zdecydowanie więcej Dev niżeli Ops jest obecnie w codziennej pracy w nowowczesnym dziale IT.

Koncept DevOps to stałe poszukiwanie możliwości automatyzacji powtarzalnych admińskich działań poprzez rozwój warsztatu developerskiego. Automatyzacja infrastruktury poprzez kod uwypukla ten koncept.

Najczęściej kod opisujący infrastrukturę to specjalny język domenowy DSL (ang. Domain Specific Language), czyli rozwiązujący problemy określonej dziedziny. W tym przypadku problem to opis konfiguracji i kolejności instalacji poporzez skrypty automatyczne naszych maszyn, systemów i  oprogramowania na nich.
Najczęściej plików definicji nie piszemy od zera, gdyż analogicznie do języków programowania istnieją biblioteki, które ułatwiają nam wiele typowych czynności t.j. ustawienie strefy czasowej, automatyzacja aktualizacji, czyszczenie starych kerneli z listy, postawienie serwera www, itp.



Przedstawiam poniżej kilka gotowych do użycia ideii oraz narzędzi automatyzacji i wsparcia operacyjnego dla świeta DevOps (pod linkiem mój odrębny artykuł p.t. "Fenomen DEVOPS na ratunek dla skostniałych i niezbyt wydajnych zespołów w IT (programista i administrator w jednym)").


Puppet - bazując na dialekcie języka Ruby powstał pakiet pierwotnie pod banderą 'Puppet Labs' do zarządzania farmą maszyn. Obecnie Puppet doczekał się wersji 5 co potwierdza jego popularność wśród środowsk produkcyjnych. Działa dość sprawnie i zasadniczo tworzymy plik z rozszerzeniem *.pp a wnim zawieramy recepturę. Oczywiście dotyczyła będzie w praktyce całej farmy/klasy maszyn a nie jednej maszynki. Taka receptura trafia do repozytorium, z którego puppet-agent - zainstalowany na maszynce tuż po postawieniu z kanonicznego obrazu systemu - pobiera sobie przebieg działań i skutecznie je wykonuje.   


Ansible - to narzędzie do provisioningu, któro pozwala na podłączenie się do node/maszyny, wgranie tam modułów. Moduły to zasoby wykorzystywane w opisie deklaratywnym stan systemu. Moduły są następnie wykonywane. Po wykonaniu moduły są kasowane. Słowo klucz tutaj to deklaratywny stan systemu. Czyli coś co nam opisuje jaki jest pożądany końcowy stan – jeżeli coś odbiega od założeń my mamy prawo odpowiednio zareagować, jak? zależy od nas.
Ansible najlepiej nadaje się do środowisk już istniejących, np. kiedy przejmujemy "legacy system" i musimy wesprzeć się automatyzacją, to możemy dodawać nowe zmiany już w sposób kontrolowany, przy pomocy receptur pisanych w Ansible.
Plusem Ansible jest prosta konfiguracja zmiennych i zadań do wykonania na środowisku oraz brak konieczności instalowania na klientach (w puppet musimy zainstalować puppet-agent na mszynkach).

Oczywiście mamy jeszcze do dyspozycji Chef, Salt i wiele innych możliwości.

Oto porównenie kilku narzędzi automatyzacji opisu systemu jako kodu.


Kolejnymi ważnymi pojęciami, które warto kojarzyć w kontekście konfiguracji jako kodu jest:

Platform as a service - PaaS - opis całej platformy w kodzie, który pozwala na postawienie np: całego naszego systemu w innej chmurze publicznej w celu wykonania testów lub sprawnej migracji do modelu hybrydowego.

Function as a service - FaaS - funkcje w chmurze (koncepcja serverless computing), dzięki którym nie musimy budować wielu mikroserwisów. Są to funkcje zazwyczaj dostępne publicznie po protokole HTTP i oferujące ~kilka minut przetwarzania naszych danych wejściowych. W wielu chmurach publicznych umożliwiają łączenie z wieloma usługami wewnętrznymi a nawet zewnętrznumi spotkałem się z takim ciekawym przypakiem w Azure, że można np: wpisywać do Google Docs rezultaty przetwarzania danych z FaaS.


Oto ciekawe porównanie, IaaS, PaaS i FaaS:





Pamiętaj, kiedy potrzebujesz potężnych narzędzi operacyjnych. Musisz napisać kod.