Administrator systemów dla środowisk Linux i Windows. Automatyzacja złożonych procesów IT za pomocą Ansible i Puppet, zarządzanie infrastrukturą serwerową, taką jak wirtualizacje, serwery WWW, zapory sieciowe, serwery proxy itp. Full-Stack-Webdeveloper z HTML, S/CSS, JavaScript, TypeScript, PHP i Python, MariaDB i PostgreSQL; w tym rozwiązania API.
Tutaj znajdą Państwo wybór moich dotychczasowych projektów zawodowych. Każdy projekt reprezentuje moje umiejętności i zaangażowanie w różnych obszarach administracji i tworzenia oprogramowania.
03.2025 – 10.2025
@rtus (Artus) to system obsługi spraw (VBS) do dokumentacji czynności policyjnych i zdarzeń karnych. System umożliwia systematyczne wprowadzanie, zarządzanie i analizę zebranych danych. @rtus jest rozwijany przez Dataport, dostawcę usług IT dla administracji publicznej.
Landesbetrieb Daten und Information (LDI) odpowiada za wdrożenie i eksploatację dla Nadrenii-Palatynatu i Saary. W tym kontekście zostałem zaangażowany jako zewnętrzny specjalista do wsparcia projektu.
Mój zakres zadań obejmował administrację systemową środowiska serwerów Linux opartego na RHEL i Debian, a także automatyzację procesów wdrażania i konserwacji za pomocą Ansible. Szczególny nacisk położony był na dalszy rozwój istniejącej Ansible Collection: optymalizowałem wydajność, tworzyłem nowe pluginy w Pythonie i implementowałem dodatkowe role. Istniejące komponenty zostały zrefaktoryzowane w celu zapewnienia lepszej idempotencji.
Realizacja techniczna obejmowała administrację i automatyzację serwerów backendowych @rtus opartych na JBoss/Wildfly. Równolegle wprowadzałem członków zespołu w Ansible i Git, aby umożliwić im samodzielny dalszy rozwój infrastruktury.
Powiązane z ncsolution GmbH
2024
Po tym, jak 30 czerwca 2024 CentOS 7 osiągnął koniec wsparcia (EOL) i wciąż istniały z nim niektóre VM-y, konieczna była alternatywa. CentOS 8 nie wchodził już w grę, ponieważ został wycofany już 31 grudnia 2021 i tym samym również osiągnął EOL. CentOS Stream byłby opcją, ale jest zupełnie inną koncepcją niż jego poprzednicy. Dla środowiska produkcyjnego ze względu na Rolling Release nie nadaje się, ponieważ jest mniej stabilny i przewidywalny. Pozostawała więc tylko migracja do RHEL, SUSE, Oracle lub wolnych alternatyw Rocky Linux i AlmaLinux. Ze względu na darmowe użytkowanie, lepsze narzędzia, lepszą dokumentację i dostępne wolne serwery lustrzane zdecydowałem się na AlmaLinux.
Najpierw więc CentOS 7 został wyposażony w repozytoria CentOS od AlmaLinux, przeprowadzono aktualizacje i za pomocą Leapp podniesiono do AlmaLinux 8. Tutaj można było zaktualizować zainstalowane programy, a następnie podnieść system do AlmaLinux 9. Na koniec ponownie zaktualizowano zainstalowane programy i naprawiono różne błędy, tak aby ponownie istniał bezpieczny i funkcjonalny system. Niestety trzeba to było zrobić ręcznie na wszystkich systemach, ponieważ były one różnie skonfigurowane i każdy miał swoje własne problemy.
Migracja na AlmaLinux zapewniła stabilną bazę na kolejne lata. Aktualizacje, a przede wszystkim aktualizacje bezpieczeństwa, są znów możliwe i wszystkie zainstalowane programy są ponownie w aktualnym stanie. Na koniec serwery zostały dodane do zadania aktualizacji Ansible i są teraz regularnie aktualizowane.
Powiązane z CSD Holding GmbH (Strehlow)
2024
Wraz ze stale rosnącą liczbą serwerów miesięczna konserwacja serwerów stawała się coraz bardziej czasochłonna. Aby zautomatyzować zadania konserwacyjne i skrócić całkowity czas, podjęto wspólną decyzję o wprowadzeniu Ansible dla serwerów Linux w heterogenicznej infrastrukturze Windows-Linux.
Wdrożyłem serwer Ansible oparty na Debianie z Semaphore UI jako interfejsem użytkownika. Integracja z istniejącym serwerem GitLab umożliwiła strukturalny rozwój Ansible Collections z oddzielną gałęzią rozwojową i tymczasowymi gałęziami funkcjonalnymi. Semaphore UI pobierał Collections wyłącznie ze stabilnej gałęzi Main.
W celu zmniejszenia miesięcznego nakładu konserwacyjnego i jednoczesnej aktualizacji serwerów Linux opracowałem Collection z dwiema centralnymi rolami: codziennymi aktualizacjami i cotygodniowymi restartami w razie potrzeby. System inteligentnie restartował serwery tylko w przypadku rzeczywistej potrzeby. Konserwacja ograniczyła się dzięki temu do prostego sprawdzenia historii zadań na serwerze Ansible zamiast ręcznych pojedynczych aktualizacji.
Dział rozwoju dostrzegł potencjał i poprosił o wsparcie w optymalizacji zużycia pamięci RAM ich aplikacji IIS. W związku z tym opracowałem kolejną Collection ze specjalistycznymi rolami do koordynowanego recyclingu App-Pool. Rozwiązanie uwzględniało zależności i implementowało inteligentne czasy oczekiwania między restartami. Nocne wykonywanie tej automatyzacji zapewniło znacznie lepszą wydajność i stabilność w godzinach pracy.
System Ansible znacząco zmniejszył nakład konserwacyjny, zwiększył stabilność systemów i stworzył możliwości dla innych ważnych zadań.
Powiązane z CSD Holding GmbH (Strehlow)
2024
Jako pierwszy projekt po zatrudnieniu w Strehlow przejąłem modernizację serwera wdrażania Windows, który znajdował się w stanie krytycznym. Sytuacja wyjściowa była problematyczna: serwer dystrybuował przestarzałą wersję Windows 10 bez oddzielnego zadania aktualizacji, przez co aktualizacje podczas wdrażania przebiegały w sposób niekontrolowany, a następnie trwały jeszcze bardzo długo. Główne oprogramowanie SaniVision było ze względu na swoją złożoność instalowane ręcznie plik po pliku, co było czasochłonne i podatne na błędy. Dodatkowe oprogramowanie leżało co prawda zaktualizowane na udziale sieciowym, ale nie było zintegrowane z WDS. Przy niektórych modelach sprzętu karty sieciowe nie były rozpoznawane po starcie PXE, przez co jako obejście konieczne były adaptery USB-C. Touchpady i inny sprzęt również nie działały w Windows PE.
Najpierw naprawiłem istniejący udział sieciowy poprzez integrację aktualnej wersji Windows 10 i korektę istniejących instalacji oprogramowania i skryptów. Równolegle opracowałem pierwszą wersję skryptu PowerShell do automatycznej instalacji złożonego oprogramowania SaniVision.
Utworzono zupełnie nowy udział sieciowy z uporządkowaną strukturą i zintegrowano Windows 11. Zaimplementowano wszystkie niezbędne sterowniki Windows PE, dzięki czemu standardowe porty sieciowe i touchpady stały się dostępne w Windows Deployment Wizard. Zoptymalizowano sekwencje zadań i aktywowano zadanie aktualizacji. Skrypt SaniVision został przerobiony, dodano nowe skrypty instalacyjne dla kolejnego oprogramowania i poprawiono prezentację graficzną dla lepszego wykrywania błędów. Pierwszy udział sieciowy został zachowany jako system zapasowy.
Na podstawie zdobytych doświadczeń utworzono trzeci, wysoce zoptymalizowany udział sieciowy. Skrypty otrzymały wykrywanie zależności i ulepszoną obsługę błędów. Wdrożono inteligentny mechanizm aktualizacji: nowe wersje wystarczyło skopiować do odpowiedniego katalogu, a skrypt automatycznie rozpoznawał najwyższą wersję i ją instalował. Skrypty wykrywania sprzętu umożliwiły, że zadania sterowników instalowały tylko sterowniki specyficzne dla danego urządzenia. Zmniejszyło to liczbę sekwencji zadań do jednej standardowej sekwencji zamiast kilku wariantów specyficznych dla urządzeń. Pierwszy udział sieciowy został po zakończeniu tej fazy ostatecznie usunięty.
Rezultatem była w pełni zautomatyzowana, nienadzorowana instalacja z minimalnym współczynnikiem błędów. Czas wdrażania został znacznie skrócony, konserwacja uproszczona, a niezawodność całego systemu wyraźnie zwiększona.
Przebudowa serwera WDS miała jeszcze jeden pozytywny efekt. Instalacje i skrypty, które jako obejście zostały przeniesione do PDQ Deploy & Inventory i tam po każdej instalacji Windows musiały być ręcznie uruchamiane, mogły zostać ponownie zintegrowane z serwerem WDS. Dzięki temu przywrócono wyraźny podział zadań obu systemów. Serwer WDS przejmował odtąd wszystkie ogólne instalacje, podczas gdy PDQ koncentrował się wyłącznie na aktualizacjach i specjalnych instalacjach oraz skryptach.
Powiązane z CSD Holding GmbH (Strehlow)
2023
Firma SCHUBERTH GmbH zleciła nam opracowanie systemu wdrażania do szybkiej i jednolitej instalacji ich Thin-Clientów. Wymagania obejmowały rozwiązanie oparte na Linuksie z automatycznym logowaniem i natychmiastowym uruchomieniem wstępnie skonfigurowanego VMware Horizon Client.
Po początkowych opóźnieniach przejąłem wiodącą rolę w rozwoju. Rozwiązanie opierało się na Debianie z automatyzacjami Preseed. Opracowałem skrypt, który automatycznie składał wszystkie potrzebne komponenty w bootowalny obraz ISO. Proces obejmował konfigurację pliku Preseed dla ustawień Debiana oraz integrację różnych mechanizmów instalacji Horizon Client, funkcji autostartu i skryptów logowania. Skrypt modyfikował standardowy ISO Debiana, tworząc wymagane struktury katalogów, integrując wszystkie niezbędne pliki, dostosowując menu GRUB i generując z tego nowy obraz ISO. Za pomocą tego obrazu można było tworzyć dowolną liczbę bootowalnych pamięci USB z identycznym wynikiem instalacji.
Proces instalacji przebiegał w pełni automatycznie: po uruchomieniu z pamięci USB można było za pomocą menu GRUB rozpocząć nienadzorowaną instalację. Instalator Debiana wykonywał samodzielnie wszystkie kroki, przy czym Late-Commands przejmowały instalację Horizon Client oraz implementację wszystkich wymaganych skryptów i dostosowań systemowych.
W trybie produkcyjnym system uruchamiał się automatycznie, skrypt monitorujący sprawdzał i w razie potrzeby korygował ustawienia systemowe. Ograniczony użytkownik był automatycznie logowany, po czym Horizon Client uruchamiał się w trybie pełnoekranowym. Skrypt monitorujący nieprzerwanie nadzorował działanie klienta i przy zakończeniu natychmiast inicjował wyłączenie systemu.
Rozwiązanie znacząco uprościło administrację, uszkodzone systemy mogły być ponownie zainstalowane w ciągu kilku minut, czasochłonne analizy błędów odpadały. Użytkownicy końcowi korzystali z bezproblemowej integracji, ponieważ mogli pracować bezpośrednio ze swoim znajomym środowiskiem VMware Horizon bez potrzeby znajomości Linuksa. Instalacja Thin-Clientów była przeprowadzana samodzielnie przez administratorów SCHUBERTH, podczas gdy my pozostawaliśmy do dyspozycji w kwestii dostosowań i rozszerzeń.
Powiązane z LOOMA GmbH
2019 – 2023
Zarząd LOOMA GmbH zdecydował się na strategiczną reorientację, odchodząc od klasycznego domu systemowego z rozliczaniem godzinowym, umowami serwisowymi i reaktywnym wsparciem, w kierunku modelu MSP ze stałymi cenami za sprzęt i usługi zarządzane, w tym proaktywne wsparcie i zautomatyzowane procesy.
Faza planowania koncentrowała się na opracowaniu różnych pakietów usług i wyborze odpowiednich narzędzi do monitoringu i zarządzania. Opracowano krytyczne kwestie: Jak proaktywnie rozwiązywać istniejące problemy klientów? Jakie wartości dodane powstają dla klientów? Aspekty prawne, takie jak kwestie odpowiedzialności przy szkodach czy niewypłacalności klienta, były uwzględniane tak samo jak wyzwanie przekonania dotychczasowych klientów do nowego modelu i zintegrowania ich istniejącej infrastruktury. Kolejne ważne pytanie pojawiło się podczas fazy planowania: co, jeśli infrastruktura istniejącego lub nowego klienta nie może zostać zintegrowana z modelem MSP? Kto musi wtedy przejąć wsparcie dla tych komponentów?
Wdrożenie odbywało się stopniowo z trzema kluczowymi usługami: Managed Workplace, Managed Security i Managed Server. Dla jednolitych i specyficznych dla klienta instalacji Windows zastosowano serwer WDS, który przez sieć (PXE) mógł jednocześnie udostępniać wiele urządzeń. Jako rozwiązanie monitoringu początkowo wdrożono Paessler PRTG, ostatecznie jednak Zabbix. Jako rozwiązanie RMM po wykorzystaniu ManageEngine i SolarWinds zastosowano ostatecznie Datto RMM. Własny system ticketowy został opracowany za pomocą n8n/Zapier i Bubble, który mógł wykonywać zautomatyzowane procesy przez API i Webhooks i został później rozszerzony o wsparcie AI. Umożliwiło to odwzorowanie pakietów MSP, jak również wyspecjalizowanych usług, takich jak infrastruktura telematyczna (TI) dla gabinetów. Architektura bezpieczeństwa opierała się na produktach Sophos z centralnym zarządzaniem przez Sophos Central, podczas gdy komponenty sieciowe Ubiquiti były centralnie zarządzane przez chmurę Ubiquiti. Istniejące instalacje Office i serwery Exchange klientów zostały zmigrowane do Microsoft 365.
Jak już podejrzewano w fazie planowania, reakcje klientów były mieszane. Podczas gdy niektórzy dotychczasowi klienci odrzucili nowy model i odeszli, zarówno inni istniejący, jak i nowi klienci zostali z powodzeniem pozyskani dla modelu MSP. Na podstawie pierwszych doświadczeń usługi były ciągle optymalizowane. Staranne przygotowanie umożliwiło od razu proaktywne rozwiązywanie problemów i wczesne wykrywanie zakłóceń. Automatyzacje, takie jak centralnie sterowane aktualizacje Windows, znacząco zmniejszyły nakład pracy i gwarantowały klientom stabilne, bezpieczne systemy.
Powiązane z LOOMA GmbH
2020
EQO Energiekonzepte GmbH odnotowała kilka kradzieży na placach budowy swoich farm solarnych i zleciła nam opracowanie mobilnego systemu monitoringu. Wymagania były jasno zdefiniowane: system miał być dyskretny, ale szybki i nieskomplikowany w montażu na miejscu. Ponieważ na wszystkich placach budowy dostępny był prąd budowlany, można było zrealizować standardową instalację 230 V.
Po sporządzeniu szczegółowego planu komponentów i uzgodnieniu z klientem nastąpiła realizacja techniczna. System opierał się na routerze LTE do połączenia internetowego i komponentach Ubiquiti do monitoringu: przełącznik PoE, Cloud-Key do zarządzania i uploadu do chmury oraz różne kamery Ubiquiti. Wszystkie komponenty zostały zamontowane w zamykanej skrzynce rozdzielczej na płycie perforowanej i zabezpieczone opaskami kablowymi.
Konfiguracja umożliwiała automatyczne nagrywanie przy wykryciu ruchu z bezpośrednim uploadem do chmury Ubiquiti. Przy wyzwoleniu osoby odpowiedzialne otrzymywały powiadomienia e-mail z dołączonymi fragmentami zdjęć z nagrań. Po szczegółowym przeszkoleniu pracownik EQO samodzielnie przejmował montaż i demontaż systemu w zmieniających się lokalizacjach.
Pomimo sporadycznych fałszywych alarmów spowodowanych przez dzikie zwierzęta, wiatr czy śnieg, system spełniał swoje zadanie: nieuprawnione wejścia i kradzieże były dokumentowane, dzięki czemu częściowo udało się im zapobiec lub przynajmniej je zarejestrować w sposób umożliwiający identyfikację tablic rejestracyjnych lub osób. Bezpieczeństwo na placach budowy zostało trwale poprawione.
W kwestii pytań, zmian i wsparcia pozostawaliśmy do dyspozycji firmy również po wdrożeniu.
Powiązane z LOOMA GmbH
2019
Stadtwerke Wernigerode planowały wprowadzenie systemu Digital Signage do dwóch obszarów zastosowań: wewnętrznie do informowania pracowników w zakładach oraz jako system reklamowy w centrach obsługi klienta. Wybór padł na Xibo jako centralną platformę.
Moje zadanie w tym projekcie polegało na kompletnej konfiguracji serwera. Jako bazę techniczną wybrałem Debian z serwerem Apache HTTP Server i MySQL. Na tym zbudowałem CMS Xibo i przeprowadziłem wymagane konfiguracje systemowe.
Instalację i podłączenie odtwarzaczy Xibo przeprowadzili administratorzy Stadtwerke samodzielnie, co zapewniło bezproblemową integrację z istniejącym środowiskiem IT.
Po zakończeniu projektu pozostawałem dostępny jako wsparcie 3rd-Level-Support i przejąłem szkolenie pracowników w obsłudze nowego systemu. Ta ciągła opieka zapewniła, że Stadtwerke mogły optymalnie korzystać z systemu Digital Signage i samodzielnie tworzyć kampanie.
Powiązane z LOOMA GmbH
2004 – 2014
Po 2000 roku liczne urzędy i instytucje federalne przeniosły się do Berlina. Decyzja o stolicy z 1991 roku zapoczątkowała długotrwały proces przeprowadzek, który częściowo ciągnął się aż do późnych lat 2010. Ponieważ zadania i procedury przy tych projektach były w dużej mierze identyczne, podsumowuję je tutaj.
Uczestniczyliśmy w kilku tych przeprowadzkach w różnych fazach. Zakresy projektów były różne: w przypadku niektórych urzędów przejmowaliśmy przygotowanie infrastruktury IT w Berlinie, w przypadku innych demontaż techniki w Bonn. W wielu przypadkach towarzyszyliśmy kompletnemu procesowi przeprowadzki od demontażu po nową instalację.
Zakres zadań obejmował często również instalację i konfigurację kompletnych stanowisk pracy. Do tych rozległych rolloutów stosowaliśmy początkowo Remote Installation Services (RIS), później przeszliśmy na nowocześniejsze Windows Deployment Services (WDS). Te zautomatyzowane rozwiązania wdrożeniowe, łącznie ze skryptami PowerShell, umożliwiły nam efektywne i standaryzowane konfigurowanie setek stanowisk pracy.
Powiązane z Das Systemhaus Datentechnik Berlin GmbH
2005
Pierwotnie chodziło jedynie o stworzenie możliwości, dzięki której klienci mogliby samodzielnie kalkulować ceny transportu ładunków ponadgabarytowych. Funkcja ta została później zintegrowana z chronionym obszarem klienta z funkcją logowania i ciągle rozszerzana. Stopniowo dochodziły kolejne funkcje, w tym rejestracja zleceń odbioru i informacje AVIS.
Początkowy kalkulator ładunków ponadgabarytowych rozwinął się w kompleksowy kalkulator cen transportu. Oprócz ładunków normalnych i ponadgabarytowych można było teraz kalkulować również usługi dodatkowe, takie jak dostawy tego samego dnia i następnego dnia oraz ubezpieczenia transportowe.
Już z pierwszą wersją General Express wyprzedził partnera systemowego GO! Express & Logistics o krok. Końcowy etap rozbudowy stanowił nawet unikalny w skali Niemiec system.
Backend portalu zrealizowałem w PHP i MySQL, do frontendu zastosowano XHTML, CSS i JavaScript. Realizacja techniczna odbywała się na serwerze WWW z obsługą PHP i bazą danych MySQL u Strato.
Portal cieszył się dużą popularnością wśród klientów z Berlina i był później nawet wykorzystywany przez klientów GO! w całych Niemczech. Z niewielkimi dostosowaniami i rozszerzeniami pozostawał z powodzeniem w użyciu aż do zamknięcia działalności General Express (2010).
Powiązane z Michel Abele (jednoosobowa firma prowadzona jako działalność dodatkowa, Berlin)
2004
W tym niezwykłym projekcie chodziło o przeniesienie serwerów mediowo-komunikacyjnych (MeCom) Niemieckiego Biura Depeszowego (ddp, wówczas jeszcze ProSieben) bez większych przestojów z centrum danych ProSieben w Unterföhring do centrum danych Level-3 w Berlinie. Szczególne wyzwanie polegało na tym, że serwery mogły być transportowane wyłącznie w czasie wolnym od pracy redakcji, a ewentualne uszkodzenia transportowe musiały być natychmiast naprawione.
Okno czasowe było niezwykle krótkie: demontaż serwerów mógł się rozpocząć dopiero po wylogowaniu się ostatniego reportera, zazwyczaj między północą a pierwszą w nocy. W Berlinie systemy musiały być ponownie w pełni gotowe do pracy najpóźniej o szóstej rano na początek pracy redakcji, a najpóźniej o ósmej na początek głównej pracy redakcji.
Przy dystansie około 580 kilometrów między Unterföhring a Berlinem, głównie autostradą, normalna jazda trwałaby od pięciu do sześciu godzin. To przekroczyłoby okno czasowe. Rozwiązanie było proste i skuteczne: Audi RS6 Avant szefa pozwoliło skrócić czas jazdy do czterech do czterech i pół godziny, dzięki czemu można było dotrzymać krytycznych ram czasowych.
Projekt składał się z dwóch faz. W pierwszej fazie przygotowano kompletną infrastrukturę w berlińskim centrum danych Level-3. Komponenty sieciowe i okablowanie zostały skonfigurowane tak, aby administratorzy systemów ProSieben mogli dostosować konfiguracje sieciowe podczas transportu. Druga faza obejmowała dojazd do Unterföhring, demontaż trzech serwerów MeCom, jazdę do Berlina i tamtejszy montaż.
W realizacji ostatni reporter wylogował się około 0:30. Po sprawnym demontażu serwerów „jazda" rozpoczęła się o pierwszej w nocy. Po przyjeździe do Berlina serwery zostały zamontowane w szafie rackowej, uruchomione i wymieniono dwa uszkodzone dyski twarde. Punkt szósta rano redakcja mogła planowo rozpocząć pracę.
Powiązane z Das Systemhaus Datentechnik Berlin GmbH
2003
Po tym, jak tickety wsparcia w formie papierowej często ginęły lub były zapominane, a status realizacji był trudny do śledzenia, w zespole podjęto decyzję o opracowaniu własnego cyfrowego systemu ticketowego.
W fazie planowania stworzono prosty dokument wymagań, przy czym wszyscy pracownicy mogli wnosić swoje wymagania i pomysły. Realizacja techniczna odbyła się za pomocą PHP, XHTML i CSS, a w backendzie baza danych MySQL zapewniała przechowywanie danych. Jako podstawa służył system Debian z serwerem Apache HTTP Server na własnym sprzęcie. Wspólnie z kolegą przejąłem konfigurację i programowanie systemu. Po zakończeniu wprowadziliśmy pozostałych kolegów do nowego systemu.
Z biegiem czasu rozwiązanie było ciągle rozszerzane o dodatkowe funkcje. Ważnym modułem był zintegrowany system inwentaryzacji. Zarządzał on centralnie przydzielonymi przez klientów zakresami numerów i zapewniał, że nie mogły wystąpić podwójne przydzielenia. Wcześniej regularnie dochodziło do duplikowania numerów inwentarzowych lub pomijania całych zakresów.
To, co zaczęło się jako rozwiązanie problemu, rozwinęło się w kompleksowe narzędzie, które daleko wykraczało poza pierwotne zarządzanie ticketami. Dział wsparcia mógł znacząco zwiększyć swoją efektywność, ponieważ tickety stały się transparentne i centralnie możliwe do śledzenia. System działał stabilnie aż do likwidacji firmy, przy czym mój kolega i ja przejęliśmy ciągłą konserwację i opiekę.
Powiązane z Das Systemhaus Datentechnik Berlin GmbH