@wielkipiecLinux na poważnie – wdrażanie Red Hatów na skalę korporacyjną

Linux na poważnie – wdrażanie Red Hatów na skalę korporacyjną

20 maja 2015, 21:51

Nakreślmy najpierw krajobraz: pracuję jako (młodszy) administrator na wyższej uczelni. Laboratoria komputerowe na wydziale są zdominowane przez Windows 7, stanowisk jest łącznie ponad 150. Mimo, że wiele osób twierdzi, że systemy są na nich instalowane ręcznie, z oczywistych powodów tak nie jest, to przecież szalenie czasochłonna i w dodatku małpia robota. Wdrażanie oprogramowania to nie jest nowe zagadnienie, rozwiązano ten problem lata temu. Obecność narzędzi instalacji nienadzorowanej jest dobrym kryterium odróżniania prawdziwych systemów operacyjnych od zabawek. Oznacza to zatem, że Windows zdecydowanie posiada takie narzędzia – w istocie, nawet dwa. Obecnie wszystkie scenariusze wykorzystują usługę Windows Deployment Services, na moim ukochanym Windows Server.

Niestety, nie możemy wstawić Windows Server. Istnieją całkiem niezłe powody, dlaczego nie możemy tego zrobić, jest to w planach (podobnie, jak Active Directory), ale na pewno nie na topie listy priorytetów. Nie czas i miejsce na wyjaśnienia tego stanu rzeczy, wspomnę jedynie, że w ultraheterogenicznym środowisku pełnym staroci oraz naprawdę dziwacznych maszyn, Microsoftowa implementacja DNS jest nieokiełznanym i nieprzewidywalnym żywiołem. W poprzedniej pracy wdrażałem WDS na podobną skalę, ale w środowisku jednolitym i działał on niezawodnie, jak na Windows Server przystało. Tutaj nie mam takiego luksusu, los rzuca mi straszne wyzwania i przyspiesza łysienie.

Nietypowe wyzwania

Anyway, ustaliliśmy, że nie da się w moim przypadku wdrażać Windows narzędziami do wdrażania Windows. To trochę niedobrze. Zwłaszcza, jeżeli chce się za wszelką cenę stosować do reguły KISS – nie można stworzyć jakiegoś nietypowego rękodzieła, brudnego wihajstra „na chwilę”, bo na pewno zostanie on „dożywotnim rozwiązaniem tymczasowym”, które każdy boi się ruszać, bo jak się posypie, to będzie totalny paraliż. Wiem, bo sam sobie już kiedyś zrobiłem taką krzywdę. Ponadto, podobne rozwiązanie zostawił mój poprzednik. Miał on zdecydowanie wyższy level, niż ja i miną lata, zanim nie będzie mi wstyd się do niego porównywać, ale jego narzędzie reinstalacji oprogramowania nosiło silne znamiona tymczasowości. Oj bardzo. Oczywiście przestało działać w drugim tygodniu mojej pracy – popsuł się dysk twardy. Podczas odzyskiwania kopii zapasowej popsuł się dysk z kopią zapasową, ten sam model. WD Green 2TB. Miałem kiedyś taki dysk w domowym desktopie. Popsuł się.

Ocalała dokumentacja całego rozwiązania, ale próby odtworzenia go na jej podstawie byłyby z góry skazane na klęskę – to nie był żaden przystępny podręcznik, tylko zbiór ściąg, zrozumiały tylko dla autora (czego on sam nie musiał być świadom). Przypominało to bardziej elfickie runy, łacińskiego alfabetu użyto prawdopodobnie tylko dla zmyłki. Nie pozostało mi nic innego, tylko zacząć od nowa. Ale na pewno nie mogłem zacząć od zera. Początkowo wiedziałem jedynie, że muszę użyć PXE i nie mogę spojrzeć w stronę Windows Server. Zakładając, że ktoś mądrzejszy ode mnie już dawno rozwiązał ten problem, sięgnąłem do manuala Fedory. Rzecz jasna, jest narzędzie do automatycznej instalacji systemu. W ten sposób, w sytuacji absolutnego kryzysu czasowego, zdecydowałem się wdrożyć na dużą skalę nieprzetestowane rozwiązanie oparte na systemie Fedora 21 w wersji beta. I w dodatku wykorzystać je do instalowania Windowsów. Nie mogłem się nikomu przyznać do tego, jak idiotycznego zadania mam zamiar się podjąć i postanowiłem zademonstrować je dopiero, gdy wszystko zadziała w 100% na wszystkich stanowiskach. Co w istocie nastąpiło, ku mojemu silnemu zdziwieniu. Ciekawe, kiedy dysk się popsuje.

Unattended

Nie mam tutaj na celu opisania, jak krok po kroku stworzyć środowisko instalacji – powstały już tuziny takich wpisów i w większości przypadków jedynie dublują wiedzę z dokumentacji, w oględny i nierzadko błędny sposób. Chodzi mi o podejście praktyczne: jak to działa, czy jest godne zaufania, czy nadaje się do firm, jakie problemy pojawiają się po drodze, no i jaka jest wydajność całego systemu.

Boot from LAN

Zanim o szczegółach, przypomnijmy sobie, jak działają narzędzia instalacji nienadzorowanej. Starsi czytelnicy na pewno pamiętają czasy popularyzacji „szerokopasmowego” internetu (osiedlówki rzędu 128 kbps wypierające połączenia komutowane), które wymagały wymiany wewnętrznego modemu PCI na kartę sieciową, oczywiście z chipem RTL8139. Owe karty sieciowe miały niezagospodarowane gniazdo na „BOOT ROM”. Nikt nigdy nie miał układu, który pasował do tego mitycznego złącza, plik README.DOC na dyskietce(!) ze sterownikami mętnie informował, że to służy do jakichś szemranych rozwiązań w wielkich firmach, w zgniłej Ameryce.

Realtek RTL8139, z pustym socketem BOOT ROM.

Z biegiem czasu, karty sieciowe zawitały na płytach głównych jako układy wbudowane, a BOOT ROM znajdował się w BIOSie, możliwy do uruchomienia po zmianie jednego parametru w „Advanced Peripherals”. Włączenie go pozwala wybrać kartę sieciową jako źródło uruchamiania komputera, na równi z dyskiem twardym, DVD, czy pendrivem. Boot from LAN poprosi wtedy serwer DHCP o adres IP, podsieć i bramę oraz adres „next server” – komputer, z którym należy negocjować otrzymanie obrazu ładowania. Następnie zostanie zestawione połączenie z owym komputerem, który zaoferuje obraz startowy systemu operacyjnego, wysyłając go przez protokół TFTP. T oznacza tutaj „Trivial” i jest to przedrostek w pełni zasłużony: w przeciwieństwie do FTP/SFTP, nie ma tu uwierzytelniania ani szyfrowania, a w dodatku całość działa przez UDP. Cóż, LAN BOOT ROM to głupi ROM, więcej nie umie. This is by design – głupie systemy rzadziej się psują.

PXE

Otrzymany obraz jest w całości, niemal żywcem, ładowany do pamięci i zachowuje się jak bootloader. Pozwala uruchomić system operacyjny, który też dostaniemy przez sieć. Będzie on działał z ramdysku, nie potrzebujemy żadnych twardych dysków, przynajmniej na tym etapie. Po wybraniu w bootloaderze systemu sieciowego (możemy wszak nakazać „chain loading” i kontynuować z systemem z HDD), uruchomi się środowisko PXE. Służy ono do uruchomienia instalatora systemu. Na tym etapie nie da się już odróżnić, czy uruchomiliśmy instalator z sieci, czy z płytki. O to właśnie nam chodzi. Windowsy mają od tego serwery RIS/WDS, Linuksy używają programu o niezwykle mylącej i mało twórczej nazwie „syslinux/pxelinux”.

Ponieważ jednak w dalszym ciągu musimy przeprowadzić instalacje, samo uruchomienie przez PXE nic nam nie daje. Pozwala jedynie zniwelować problem hałasującego napędu DVD – instalator bez zmian będzie nam zadawać miliony pytań, przez które musimy przebrnąć ręcznie. Musi zatem istnieć dalszy krok, a jest nim tzw. plik odpowiedzi. Instalator zajrzy do niego i wszystkie pytania, na które podaliśmy odpowiedź, wypełni sam. Optymalnym rozwiązaniem jest odpowiedzieć na wszystkie – ale to trudne. Zwłaszcza, jak komputery nie są identyczne. I ponownie: Windowsy mają od tego AIK/Sysprep, a Linuksy… miliony rozwiązań, z których działa pięć, a wykorzystuje się dwa. Ja użyłem redhatowego instalatora o nazwie Kickstart.

Tak w skrócie działają instalatory nienadzorowane. Osobiście uznaję wyłącznie dwa: Windows Deployment Services i właśnie Kickstart. Ten drugi to ciekawa bestia: sam w sobie jest jedynie warstwą obsługi plików odpowiedzi dla redhatowego instalatora Anaconda, co oznacza, że wcale nie musimy używać PXE ani nic z tych rzeczy: jeżeli dodamy plik Kickstart do płytki z systemem, instalator użyje go, co pozwala stworzyć nienadzorowane płyty instalacyjne DVD. Ale jednocześnie, Kickstart jest częścią znacznie większego rozwiązania instalacji nienadzorowanych, o nazwie Cobbler. Pozostałymi elementami Cobblera jest serwer PXE oraz repozytorium oprogramowania, pozwalające tworzyć lokalne mirrory całego systemu oraz własne zbiory lokalnych programów, np. w konkretnych, interesujących nas wersjach. Oczywiście, wszystko w formie paczek RPM. Cobbler służy jednak do instalacji Red Hata, Fedory i CentOSa. Jak go zmusić do instalacji Windowsów? Tutaj z pomocą przyszedł Kickstart, ale idźmy po kolei i najpierw wyjaśnijmy sobie, jak działa środowisko oferowane po skonfigurowaniu Cobblera.

Serwer

Na początku potrzebujemy serwera. Już tutaj miałem problem, bo przecież poprzedni serwer zdechł. Jak napiszę zapotrzebowanie na nowy, to dostanę go za trzy miesiące – przerabiałem ten motyw ze zszywaczem. Przepaloną żarówkę w ogóle wymieniłem sam, nawet nie próbowałem o nic prosić. Pozostało to samo zrobić z serwerem: skosiłem jeden z komputerów w laboratorium. Co za różnica, 29, czy 30 stanowisk. I tak coraz więcej osób przychodzi z własnymi laptopami (na których na pewno mają legalne wersje drogiego oprogramowania, używanego na zajęciach). Wziąłem sobie komputerek z Sandy Bridge, SSD na system i HDD 1TB na soft do wdrażania. Zawczasu upewniłem się, czy przypadkiem nie jest to WD Green. Na SSD zainstalowałem system Fedora Server 21, dorzuciłem cockpit, irssi i Cobblera, który pociągnął tuziny zależności, jak serwer WWW, FTP, TFTP, xinetd, górę modułów do perla i pythona i jakieś dziwne biblioteki, o których niekoniecznie wcześniej słyszałem. To był niedobry etap instalacji, bo robiłem to pierwszy raz w życiu. Zawsze wcześniej PXE już był i działał. Tutaj musiałem się dopiąć do już istniejącej infrastruktury, która w dodatku została zestawiona przez umysł dość wyraźnie odmienny od mojego.

Oprogramowanie: Cobbler

Po instalacji i konfiguracji, Cobbler zaczął odpowiadać na żądania BOOT ROM i oferował stacjom menu trochę podobne do GRUBa. Początkowo na liście była tylko opcja (LOCAL BOOT), która w dodatku nie działała. Tutaj poczułem, że nie widzę wyraźnej granicy tego, gdzie kończy się syslinux, a zaczyna Cobbler. Wiedziałem, że to niedopatrzenie okaże się w jakiś sposób zgubne, ale była już 22:00, a ja założyłem, że użytkownicy laboratoriów nie mają gąbki zamiast mózgu i nie będą naciskać losowych przycisków, jak zobaczą „menu wyboru instalacji nienadzorowanej” zamiast ekranu logowania Windows. Nie muszę chyba mówić, że był to poważny błąd z mojej strony. Więc poza menu uszkadzania stacji, trzeba było nakarmić Cobblera jakimś systemem, który mógłby oferować przez PXE. Nie mowa tu o systemie do instalacji, tylko o czymkolwiek, na czym da się najpierw odpalić instalator. Tutaj sprawa działa podobnie, jak w Windows Deployment Services – dodaje się obraz płyty z systemem operacyjnym, a na jej podstawie definiuje się profile. Profil zawiera ustawienia takie, jak na jakich komputerach wolno z niego korzystać (poznaje po adresach MAC), jakie parametry jądra przesłać podczas uruchamiania oraz, przede wszystkim, jaki plik odpowiedzi dołączyć do uruchamianego instalatora. Zacząłem od laboratorium, gdzie stoją komputery z dwoma dyskami. Powód był prosty: na pierwszym dysku miał być Windows, na drugim Linux. Zdefiniowałem więc nowy profil, zastrzegłem jego użycie tylko w jednej sali i zabrałem się za pisanie pliku odpowiedzi. Tutaj poznałem magię Kickstarta. Podejrzewałem już wcześniej, że jest magiczny, ale teraz mogłem się o tym wreszcie przekonać.

Kickstart

Pliki odpowiedzi dla kickstarta składają się z trzech sekcji. Pierwsza to zbiór odpowiedzi na pytania Anacondy. Druga, o nazwie „pre”, jest ciekawsza: jest to zbiór czynności do wykonania przed instalacją. Najlepiej wykorzystać tę sekcję do przeprowadzenia podziału dysku na partycje. Moja ulubiona jest jednak sekcja trzecia, „post”, czyli zbiór czynności do wykonania po instalacji. Ponieważ obecnie instalatory, oraz w ogóle interfejsy, zmierzają do jak najsilniejszego „uidiocenia”, zadają coraz mniej pytań. Nie da się już na przykład ustawić domyślnego środowiska graficznego albo zmienić ustawień serwera SSH (kiedyś się dało, ale to było w 2001). Dlatego należy to zrobić później. Potęga sekcji trzeciej bierze się z tego, że jest ona zwykłym skryptem bash, uruchamianym w środowisku chroot. Mamy zatem nieograniczony dostęp do systemu i możemy korzystać ze wszystkich narzędzi, jakie w nim zainstalowaliśmy. Nadużyję tej potęgi na dalszych etapach pracy.

Aby móc przeprowadzić instalację Kickstart, plik odpowiedzi musi przejść walidację. Skoro instalacja ma być całkowicie nienadzorowana, wymusza to nie tylko odpowiedzenie na wszystkie pytania, ale i zrobienie tego w akceptowalnie rozsądny sposób. Szczegóły tworzenia pliku odpowiedzi są doskonale udokumentowane w Projekcie Fedora. Szkoda tylko, że wspomniana dokumentacja co chwilę zmienia adres z powodu niekończącej się reorganizacji struktury Wiki Fedoraproject. Obecnie, manual do Kickstarta znajduje się na githubie, ale już nie mogę się doczekać, aż wyląduje w jeszcze dziwniejszym miejscu, np. na Pastebinie. Wiem, że mogę to w każdej chwili „wygooglać”, ale chciałbym mieć poprawne zakładki. Można się jednak obyć bez dokumentacji: wystarczy użyć w Fedorze programu system-config-kickstart. Dzięki niemu odpowiemy na szereg pytań dotyczących systemu, a w odpowiedzi dostaniemy gotowy plik Kickstart. Jest jednak jeszcze lepszy pomysł. Świadczy on o tym, że twórcy instalatora Red Hata naprawdę wiedzą jak to się robi (i potrafią tego nie zepsuć po całkowitym przepisaniu instalatora od zera w wersji 18). Otóż po każdej instalacji Fedory, w katalogu domowym administratora znajduje się plik „anaconda-ks.cfg” zawierający odpowiedzi, jakich udzieliliśmy podczas instalacji. Wystarczy zatem przeprowadzić „wzorcową” instalację, a następnie zabrać z niej plik Kickstart. Powiązanie go z profilem Cobblera doda nam opcję gotowej instalacji nienadzorowanej. Jest to rozwiązaniem lepszym od system-config-kickstart również dlatego, że ten generuje niekompletne pliki. Dostaniemy na przykład język polski, ale polskich znaków już nie. Ewentualnie plik w ogóle nie przejdzie walidacji. Coś takiego przytrafiło mi się za pierwszym podejściem.

Walidacja

I tak trzeba jednak zaglądać do tych plików. Głównym powodem jest dokonanie podziału na partycje. Dokonuje się go w sekcji „pre”, by następnie Kickstartowi kazać użyć już przygotowanych partycji. Pozwoli to uniknąć powoływania się na wbudowany kreator podziału dysku, który moim zdaniem, po latach absolutnej niezawodności, został całkowicie zepsuty i obecnie nie da się go skłonić do pełnej współpracy. Trudno tu opisać, co mam na myśli, trzeba to przeżyć. Ale nikomu tego nie życzę. A już zwłaszcza nikomu ze zdiagnozowanym OCD: musiałby bowiem znosić marnowanie kilkunastu kilobajtów na końcu dysku, bo w instalatorze usunięto tick „wypełnij do końca”. Zatem partycje trzeba przygotować wcześniej - w sekcji „pre” w ruch idą parted oraz mke2fs (póki co). Jakie odpowiedzi umieściłem w moim pliku? Przede wszystkim ustawiłem lokalne repozytorium. Pobieranie podczas każdej instalacji pakietów z mirrora we Wrocławiu jakoś mało mi się podobało. Stworzyłem więc własnego mirrora, znacznie zwiększając prędkość pobierania pakietów. Oczywiście najpierw zrobiłem to źle: żywcem skopiowałem całe drzewo katalogów ze zdalnego FTP, a następnie wyłączyłem weryfikowanie SSL, bo przecież nie miałem kluczy. Potem (gdy było już za późno) przyszło mi do głowy, że przecież Cobbler powinien mieć funkcję generowania lokalnego repozytorium. No i jak najbardziej tak jest. W dodatku magiczne polecenie „cobbler reposync” pozwala ustawić aktualizację, dzięki czemu w sieci zawsze będziemy mieć najnowsze pakiety. Poczułem się trochę jak dureń, ale na swoje usprawiedliwienie mam fakt, że repozytorium utworzone „na chama” również działało. If it’s stupid, but works, then it’s not stupid. Do tego stopnia boję się, że gdzieś jeszcze wykorzystuję to pierwsze, błędne repozytorium, że zdecydowałem go nie usuwać. Jest już kompletnie nieaktualne, ale na wszelki wypadek niech tam leży. Dodałem też RPM Fusion, wszak są tam też zajęcia z technik multimedialnych i obliczeń równoległych na GPGPU.

Repozytorium

Nieco frustrujący jest fakt, że podanie w pliku odpowiedzi adresu do repozytorium skutkuje wykorzystaniem go jedynie na czas instalacji. Zainstalowany system z powrotem korzysta z listy zdalnych repozytoriów RPM i mimo, że zawsze wybiera najbliższe, mam uzasadnione powody podejrzewać, że mojego http://dragonair.zip400.metaldomain/cobbler/repo_mirror/f21-updatesmirror/ jednak nie ma na liście. Własne repozytoria należy dodać do systemu „ręcznie” w sekcji „post”. Oczywiście, opcja zainstalowania repozytorium wykorzystywanego podczas instalacji jest opisana w dokumentacji: zostanie dodana jako nowa funkcja instalatora w kolejnym wydaniu Fedory.

Następnie podjąłem kilka niepopularnych decyzji, jak wyłączenie firewalla oraz SELinuksa i wyzerowanie hasła dla jednego z tworzonych użytkowników (pozostali mają się logować przez LDAP). Ta koszmarna decyzja jest w pełni uzasadniona. Studenci masowo „nie ogarniają”, że na laboratoriach z sieci Apache nie obsługuje ich żądań z powodu właśnie firewalla. Jest to mało zaskakujące, gdy weźmiemy pod uwagę to, że 90% z nich traktuje używanie Linuksa jak karę i nie widzi nic absurdalnego w wykorzystywaniu Perla, Apache’a i BSD Socketów pod Windowsem. Zatrzymanie systemów firewalld i selinux było zatem koniecznością. Ciekawsze jest jednak po co usuwać hasło dla użytkownika lokalnego. Odpowiedź jest krótka i brzmi „MPI”.

Nagle: MPI

Zanim przejdziemy do ciągu dalszego zmagań z Kickstartem, krótka dygresja praktyczna, aby unaocznić, że sama instalacja oprogramowania nie wystarczy i trzeba czasem naprawdę mocno się napracować, żeby jeden mały program działał poprawnie w „niewidzialny” sposób. Zatem, MPI. Jest to framework do obliczeń rozproszonych. Dostarcza własny kompilator C oraz środowisko uruchomieniowe. Nie czas teraz na wyjaśnianie, jak pisać programy w MPI, ważne jest co innego: jeżeli chcemy uruchomić nasz program (obliczenia) MPI na wielu komputerach (węzłach) jednocześnie, na każdym komputerze musi on być w tym samym miejscu (bezwzględna ścieżka). Dlatego też studenci mają swoje konta LDAP, ale jest też pozostawiony użytkownik lokalny, o ograniczonej powłoce i uprawnieniach, po to, by wszystkie stworzone binarki MPI były na każdym komputerze w tym samym miejscu i należały do takiego samego użytkownika. Ponadto, węzły komunikują się ze sobą przez… SSH. A jak działa nawiązywanie sesji SSH?

SSH...!

Taka sesja może być interaktywna (dostajemy powłokę) albo nie (posyłamy tylko polecenie i oczekujemy, że się wykona, nie zestawiamy pełnej sesji). Te dwa typy sesji otrzymują różne zmienne środowiskowe. Należy to zapamiętać, bo będą przez to problemy. Przede wszystkim jednak, sesja jest zestawiana na podstawie jakichś poświadczeń. Zazwyczaj rozumiemy przez to hasło. Ale nie musi tak być, jest inna metoda, lepsza. Opiera się na kluczu prywatnym i publicznym. Jeden komputer ma klucz publiczny, drugi przychodzi do niego z prywatnym, pasują do siebie, sesja zestawiana. Bez pytania o hasło. Warunkiem jest umieszczenie na kliencie i serwerze pary kluczy. Początkowo tego nie zrobiłem. Pomyślałem „studenci se zrobią na pierwszych zajęciach”. Niestety, to jest stuprocentowo pewny przepis na katastrofę. W praktyce oznacza on bowiem, że należy 30x30=900 razy umieścić parę kluczy na komputerach, w trzydziestoosobowym laboratorium. W dodatku, nie można się pomylić i np. nadpisać zbioru kluczy, albo (co gorsza) wygenerować nowych kluczy, usuwając stare. Przerwie się wtedy pierścień. Oczywiście, studenci próbowali robić to RĘCZNIE. Nikomu nie przyszło do głowy oskryptowanie tego narzędziem sshpass. A gdy sam wprowadziłem ten skrypt, wielu studentów, gdy ich kod MPI nie działał, uznawało, że totalnie dobrym pomysłem jest wygenerować sobie klucze na nowo, co przerywało pierścień i niszczyło pracę wszystkich innych. Moją decyzją było zatem stworzyć oddzielne konto do MPI, na którym nic nie wolno, ale można uruchamiać programy MPI. Bez hasła. Brak hasła działa jak używanie kluczy – SSH o nic nie pyta, więc MPI potrafi działać. Niestety, demon SSH nie pozwala na uwierzytelnianie bez hasła tak po prostu. Trzeba go mocno przekonać, żeby się na to zgodził. O tym później. Podobnie, jak o tych zmiennych środowiskowych, które się przewinęły przed chwilą.

Konfiguracja oprogramowania

Wracamy do Kickstarta. Czas na wybór, które pakiety instalować. Można podawać grupy, jak @gnome albo @office, konkretne pakiety, jak nmap, geany i openmpi-devel, a także wskazać wyraźnie, których pakietów NIE instalować. Po co? Na przykład po to, żeby uniknąć automatycznej instalacji programu Audacious, który połączony z MATE twierdzi, że nadaje się na menedżer plików, zastępując go sobą. Dwuklik na „Katalog domowy” skutkuje odpaleniem Biblioteki Multimediów. Once again – w dokumentacji o tym nie piszą, bug niezgłoszony, takie kwiatki wychodzą podczas testów. A każdy test można przeprowadzić dopiero po procesie instalacji: mała zmiana w pliku odpowiedzi i znowu czekamy na reinstalację, żeby przetestować efekt. Należy się więc zatem mało mylić. Ogólna życiowa sugestia.

Ponieważ grupy pakietów czasem nie zawierają wszystkiego, na przykład @engineering-and-scientific jakimś cudem nie zainstalowało gnuplota, dopisałem wiele pakietów do ręcznego doinstalowania. Między innymi pakiet gnome-classic-session. Studenci wpadają w panikę na czystym GNOME 3. Szkoda, że zainstalowanie tego pakietu nie ustawia domyślnej sesji na GNOME Classic. Ale od czego jest „post”?

Była już środa wieczór, w sobotę przychodzą zaoczniki, które płacą ciężkie pieniądze, żeby mieć zajęcia w sali, która jednak działa, a nie służy wyłącznie jako pomieszczenie do trzymania wózka z dzieckiem, przywożonego na zjazd (true story, w sali stały dwa wózki, od czasu do czasu płacz, przeplatany rozmowami studentek o macierzyństwie). Zbliżający się deadline jest zwyczajowym generatorem problemów w IT. Odkryłem dwa, niby małe, ale istotne.

Zawsze jest czas na problemy!

Po pierwsze, ustawienie „keyboard pl” i „lang pl” absolutnie nie wystarczyło do ustawienia polskiego układu klawiatury. Zgłoszone błędy na bugzilli wiodły na kompletne manowce, dokumentacja bezczelnie kłamała, że to przecież musi działać, a ja siedziałem i zamiast „ą” otrzymywałem brzęk PC Speakera. Okazało się, że należało ustawić język i klawiaturę w kosmiczny sposób „keyboard -‑vckeymap=pl -‑xlayouts='pl'” oraz „lang pl_PL”. Ukradłem to z pliku anaconda-ks.cfg na moim laptopie. Wtedy poszło. Znacznie gorszy problem był z boot loaderem. Co prawda władował się na właściwy dysk ale… najwyraźniej zaprojektowano go, by idealnie nie nadawał się do dokładnie takiego scenariusza, do jakiego go potrzebuję (i tylko do takiego). Otóż po pierwsze wykrywał „Windows 7” jako „Windows Vista”. Jeżeli ktoś twierdzi, że to nie problem, to przypominam, że targetem laboratorium są studenci. Większość nawet nie zauważy, ale zgodnie z maksymą, że 10% ludzi odpowiada za 90% problemów, zawsze znajdą się ciekawe osobistości, które pogrążą się w absolutnej bezradności, gdy zobaczą w menu wyboru systemu napis „Vista”. Nie wybiorą go, bo to przecież Vista. Coś jak Windows 8 + gender. Turboszatan na dopalaczach. Oni uznają tylko kradzionego Windows 7 Ultimate, aktywowanego przez setną wersję KMS Femto, ze skrótem do WinRARa na pulpicie. Nie wybiorą też Linuksa, bo przecież nie działa na nim Solidworks (rzetelny argument) i „strony nie chodzą” (brak Flasha w pewnych kręgach w dalszym ciągu czyni komputer bezużytecznym). Dlatego niezbędnym krokiem okazała się zmiana nazwy z „Vista” na „7”.

sed -i -- 's/Vista/7/g' /boot/grub2/grub.cfg

To jednak nie rozwiązało problemu. Większość zajęć prowadzi się jednak na Windowsach, więc przydałoby się, żeby to jednak Windows miał priorytet i uruchamiał się automatycznie po timeout’cie. Niestety, myśl inżynieryjna w projekcie Fedora na tym polu mocno zawiodła (gąbka zamiast mózgu) i pliki konfiguracyjne GRUB2 są rozrzucone po milionie miejsc. Główny plik grub.cfg zawiera zbiór systemów operacyjnych, i owszem. Drugi, zaszyty gdzieś w /etc, definiuje w jaki sposób odbudowywać do menu podczas detekcji systemów (na żądanie albo podczas instalacji nowego jądra). Jest jednak trzeci plik, w którym znajduje się JEDNO ustawienie (poważnie – nie ma tam nic innego). Mowa o pliku grubenv, znajduje się on na partycji /boot i – uwaga uwaga! jest ona NIEPODMONTOWANA podczas ładowania GRUB2! Montuje ją dopiero systemd, później. Dlatego boot loader nie może odczytać listy priorytetów i korzysta z domyślnej, pakietowej kolejności. W ten sposób ZAWSZE pierwszy będzie Linux, gdy wydzielimy oddzielną partycję /boot (a my potrzebujemy oddzielnej partycji /boot). Wspomniano o tym w przypisie do przypisu w starej wersji dokumentacji GRUB2 na Wiki Fedoraproject. Rozwiązanie? Ustawiłem timeout wyboru systemu operacyjnego na 300 sekund. Czas nie pozwalał mi na wymyślenie niczego mądrzejszego. Na wszelki wypadek do pliku odpowiedzi dodałem też dyrektywę „xconfig -‑startxonboot”. Na 3 komputerach z 30 – a przypominam, że teoretycznie są identyczne – domyślnie nie wstawały Xy. Po dodaniu tej linijki, problem zniknął. Dlaczego? Nie mam pojęcia, ale był już czwartek. Nie potrzebowałem już wyjaśnień, potrzebowałem cudów.

Automatyzacja to nie wszystko

Instalacja nienadzorowana nie oznacza, że całość jest procesem całkowicie automatycznym. Każdy komputer trzeba przecież uruchomić, wybrać boot przez LAN, a następnie wybrać, jaki obraz odzyskać. Dopiero wtedy zaczyna się ta automatyczna część. A jeszcze jak się trafi sala, gdzie są stare płyty Gigabyte’a, to LAN BOOT trzeba wyłączyć po każdej instalacji, bo ignoruje on kolejność bootowania i ZAWSZE pcha się jako pierwszy. Przy wyłączonym serwerze odzyskiwania, paraliżuje to stację roboczą. Przy włączonym – gwarantuję, że jakiś student w końcu odpali reinstalację systemu, bo „Reinstalacja kickstart dla Lab 411 + brudny obraz Windows” brzmiało najbliżej do „ uruchom Windows 7”.

Ponadto, uruchomienie każdej kolejnej instalacji trwa coraz wolniej. Nie mam serwera z prawdziwego zdarzenia, jest tam jeden dysk desktopowy. Przy więcej, niż 10 reinstalacjach, wszystko zaczyna niemiłosiernie zwalniać. W dodatku w jednej sali znajduje się się switch legendarnej firmy Pentagram: gdy zrobi mu się za gorąco, zrywa wszystkie połączenia, a następnie wznawia je w trybie 1 Mbit. W gigabitowej sieci. Część instalacji źle znosi utratę połączenia sieciowego i wyświetla ostrzeżenie, na które niestety trzeba kliknąć. Dopracowanie wszystkiego tak, żeby było całkowicie „unattended” jest trudne i pełne niuansów. Zdecydowanie zabrakło mi już na to czasu, a zbliżał się piątek.

Ile trwa taka reinstalacja? Około godziny. Cobbler/Kickstart stosują tutaj stare podejście do problemu. Jest to autentyczna instalacja pakiet po pakiecie, a następnie lokalna przebudowa obrazu jądra Linuksa. Znacznie wolniejsze, niż obraz dysku, ale lepiej się zrównolegla. Co by to było, jakbym pchał 10 obrazów przez tę sieć? Na pewno poza zapchaniem sieci, mocno zmniejszalbym MTBF dysku z mirrorem. A tak to każdy komputer prosi o pakiet po pakiecie… W dodatku synchronizacja repozytorium gwarantuje, że po reinstalacji oprogramowanie będzie w najnowszych dostępnych wersjach. Obciążenie sieciowe obserwowałem Cockpitem, nowym wynalazkiem Red Hata, dość mocno forsowanym. Jeszcze nie jest gotowy do zadań bojowych, ale jest obiecującym projektem, z którym polecam się zapoznać. Puszczałem po 10 reinstalacji, całość zajęła 3 godziny na jedno laboratorium (potrzebowałem 1,5 sali na sobotę). Przez ten czas wcale nie siedziałem bez ruchu. Może i obejrzałem dwa odcinki serialu na tablecie, ale jednak co chwilę musiałem coś robić. Im było później, tym leniwiej zwlekałem się z krzesła, zsuwając się z niego od niechcenia i przy okazji generując elektryczność statyczną, która kopała mnie, gdy siadałem na krzesło z powrotem.

Housekeeping

Po automatycznej instalacji przez Anacondę, Kickstart przechodził do mojej ukochanej dyrektywy „post”, która, jak wspomnieliśmy, pozwala wykonywać operacje na zainstalowanym obrazie systemu. Co takiego w niej ustawiałem? Otóż:

Zmienne środowiskowe do Open MPI. Program mpiexec leży w /usr/lib64/openmpi/bin. To wystarczyło, by połowa studentów nie miała pojęcia, jak go uruchomić. Należało więc dorzucić go do PATH. Zarówno lokalnego, jak i zdalnego. Przecież OpenMPI zestawia sesje SSH. One też potrzebują ścieżki do mpiexec.
Parametry dla SSH, włączające puste uwierzytelnianie i ogóle niepytanie nikogo o nic. Tak zwane „zero security”.
Domyślna sesja graficzna GNOME Classic, zamiast zwykłego GNOME3. Paski zadań wiecznie żywe.
Trzeba też rozpakować CUDĘ i NVidia SDK.
No i zmienić tę nieszczęsną Vistę na Siódemkę :)

Happy End

W ten sposób stworzyłem swój wzorcowy plik do automatycznego wdrażania Red Hata na względnie masową skalę. Kickstart tworzył gotowe do pracy staje robocze, ze wstępnie ustawionym oprogramowaniem, potrzebnymi paczkami oraz odpowiednim uwierzytelnianiem. Był piątek, godzina 13:00. W międzyczasie pracowałem nad dyrektywą „pre”. Po co? Przecież cała ta zabawa wyniknęła z tego, że miałem stworzyć system automatycznej instalacji Windowsów. Zrobiłem to – Kickstarty stawiały, wskutek cwanej sztuczki, również Windowsy. Jak? To temat na inną historię :)

Wszystkie moje laboratoria były gotowe na sobotę.

Nikt nie zauważył, że cokolwiek zrobiłem.