Serwery – co potrzebujemy…

Wpis wyewoluował bezpośrednio z wątku o serwerach:  http://www.goldenline.pl/forum/serwery-hardware/1230952. Co powinien posiadać admin opiekujący się serwerami (zakładam serwery a nie PCciki przerobione na serwery) HP/Dell/IBM/Fujitsu-Siemens?

Zawsze warto wykupić możliwie redundantne rozwiązania. W przypadku serwerów innych niż blade, będą to na pewno: zasilacze (zazwyczaj dwa), dyski, być może RAID on RAM, oraz onboardowe karty sieciowe (teaming). To pozwoli nam na kontynuowanie pracy maszyny nawet w przypadku wydawałoby się awarii krytycznej – jak zasilacz, dysk czy kość pamięci.

Zawsze powtarzałem swoim ’studentom’ – jeżeli wiecie jak naprawić (wyłączając) sprzęt i jak ‘załatać’ do najbliższego okna serwisowego – wybierzcie to drugie rozwiązanie

ZAWSZE, zwłaszcza w przypadku wielu takich samych serwerów warto posiadać:

• minimum jeden dysk każdego rozmiaru/interfejsu jaki używamy, lub jeden NAJWIĘKSZY uzywany przez nas. Dla przykładu: mamy dyski 36GB ,72GB ,144 GB SAS. Kupujemy jeden 144 SAS, który obsłuży nam awarię wszystkich pozostałych – do czasu gdy przybędzie nowy model (gwarancja) lub go zakupimy. Ważne: dyski tej samej pojemności muszą posiadać identyczny P/N lub kompatybilne FRU. Z tym zazwyczaj w markowych maszynach problemu nie ma, zdarza się jednak że dostaniemy innym kanałem dysk o identycznej pojemności który jednak ‘nie zaskoczy’. A nie zaskoczy dlatego iż 1 GB nie jest w każdej firmie równy tej samej pojemności. Drobne różnice w ilości sektorów/cylindrów/talerzy lub samo logiczne ich przestawienie spowoduje iż dysk o deklarowanej pojemności po prostu w macierzy ‘nie zaskoczy’. Stąd kolejna uwaga: kupując dysk do macierzy, którego PN nie zgadza się z deklarowanym przez producenta tejże kupmy kolejny dysk z serii pojemności (zamiast 36GB kupmy 72GB)

• minimum jeden, wskazana para zasilaczy sieciowych (power supply) dla posiadanego modelu. Dlaczego parę a nie jeden? Zasilacze też ludzie, jak głosi przysłowie i lubią siadać parami. Coś takiego wydarzyło mi się dwa razy w życiu, w dwóch różnych modelach serwerów. Rozumiem że można zapewne to wytłumaczyć wadą fabryczną, ale nowe zasilacze przybyły dopiero po 48h

• czasem, nadmiarowo jeden lub 2 fany (wentylatory) systemowe – łatwe do odnalezienia i zakupienia

• zawsze warto posiadać nadmiarowe taśmy/kable, łatwo jest uszkodzić sobie np. taśmę do backplane’ów

• warto posiadać jeden napęd DVD (combo) więcej – to już raczej opcja dodatkowa.

• kartę sieciową PCI 32 oparta o jeden z popularnych chipsetów – np. Realtek-8139/3Com-905

• last but not least – stacja 1.44 na USB. Wiem, wiem, artefakt, ale kilka razy się przydała

Odpowiadając na pytania na forum – co najczęściej ulega awarii?

W kolejności od najczęściej występujących:

• dyski magnetyczne,
• dyski optyczne,
• dyski magnetooptyczne,
• zasilacze,
• kontrolery RAID (onboard/standalone)
• płyty rozszerzeń (riser board/daughterboard)

Nie ma maszyn odpornych na awarie.

PS. Z newsów – w zapasach posiadam własna matę antystatyczną (uziemianą) oraz opaskę antystatyczną podłączaną do niej. Przyznam się iż jeden z ‘kolegów’ w nowej pracy zaskoczył mnie negatywnie, zwijając się prawie ze śmiechu widząc jak z opaską w ręku zabieram do zbadania bebechów serwera. Na nic tłumaczenia o ‘najlepszych praktykach’ na nic wykład o ESD – argumenty: takowy ‘negatyw’ posiada PC-ta, zawsze naprawiał go z jedną nogą w powietrzu i nigdy nic się nie wydarzyło.

Pozostało mi zapytać: ‘Jakiż to powód tak częstego naprawiania PC?’

O tempora, o mores

Co sądzę o Apple i kulcie Mac’a? :)

Po ostatnich rewelacyjnych zabawach z iPhone, iPod stwierdzam że najmniej śmieszną rzeczą z tejże filozofii jest iBill

My nie dla Twoja języka massa….

Google Picasa jest jednym z programów któego używam do katalogowania i przeglądanie zdjęć. Dzisiaj, zgrywając z aparatu nowe jesienno-parkowe impresje z ostatniego tygodnia, uruchamiając program zostałem odesłany do informacji: http://picasa-readme.blogspot.com/2009/09/picasa-35-now-with-name-tags-build-7967.html

Super. Sprawdzam funkcję ‘Sprawdź aktualizację’ w mojej Picasa 3.1 – hmmm… melduje że nie ma. Idę więc na wskazaną przez Google stronę: http://picasa.google.com/ myśląc o ręcznej aktualizacji. I cóż się okazuje? Dla nas (Google wybiera język polski) jako najświeższa,  istnieje tylko wersja 3.1. No cóż … bywa, pewnie nie zdążyli z tłumaczeniem. Poradzę sobie bez problemu w English.

Ale … ehem … jak… to … spowodować? Zmiana języka domyślnego Google nie spowodowała efektu. Kombinowanie z domenami ‘uk/pl’ również … Może prymitywny atak ‘HTML download’?

Link do wersji 3.1 to : http://dl.google.com/picasa/picasa3-setup.exe

Pierwsza próba: http://dl.google.com/picasa/picasa3.5-setup.exe – FAIL

Druga próba:http://dl.google.com/picasa/picasa3-5-setup.exe – FAIL

Trzecia próba: http://dl.google.com/picasa/picasa35-setup.exe – OK

Ściągać, instalować, działać …. Wstyd Google, wstyd.

W krzywym zwierciadle … Odcinek I – odwieczna wojna działów technicznych z handlowymi ;)

Z dawnych czasów, archiwów czeluści  – wtedy powstał tenże rysunek

Pożegnanie z ekipą…

Jak wspominałem kilka postów temu – postanowiłem w celu oczyszczenia atmosfery, zmienić pracę, a co za tym idzie: specjalizację. Temat – rzeka, pewnie jeszcze się kilka razy napatoczy, ale tym razem szerzej o ludziach z którymi pracowałem.

Niektórych z Was znałem od wielu lat, z niektórymi przetoczyłem się przez inne firmy, niektórych dostałem w wyniku ‘wrogiego przejęcia’ innych zasobów, znakomitą część rekrutowałem sam. Przez te kilka lat przemęczyliśmy się – jak to zwykle bywa – z meandrami korporacyjnych mądrości, z ‘gwiazdami’ przepływającymi przez firmę co kilka miesięcy, z ‘geniuszami’ mającymi swoje 5 minut, z ciekawymi pomysłami klientów – ot standardzik.

Krótko i na temat: jedyne czego mi będzie brakować, to właśnie atmosfery, rozmów i humoru panującego w naszym środowisku.

Na potwierdzenie moich słów mogę jedynie pokazać co mnie spotkało przy odejściu – zostałem zwabiony do siedziby, gdzie po krótkim ’speechu’ zostałem zaopatrzony na przyszłość w:

Tak, cyfrową ramkę na zdjęcia załadowaną co lepszymi zdjęciami z imprez (prywatnych i firmowych)

Znając moje zamiłowanie do tequilli nie mogło obyć się bez zestawu ‘zrób to sam’

I ‘last but not least’, rzecz która zaparła mi dech w piersiach – dodam że podpisana przez całość ekipy

Szanowni,

mam nadzieję, że tradycyjnie spotkamy się jeszcze w innych firmach, innych projektach, na innych stanowiskach, w innych miejscach. Ostatnie 6 lat pracy z Wami było fantastycznym doświadczeniem, kiedy z ekipy 6 osobowej zakończyliśmy pracę jako 90 osobowy team. Dziękuję Wam za prezenty – zapewniam że ramka stanie na honorowym miejscu w nowej pracy

Na koniec – test zestawu, Wasze zdrowie: skrzyżowanie margherity z martini;)

Zimbra – słów kilka.

Ci z Was którzy znaja już Zimbrę – www.zimbra.com – zapewne nie potrzebują dalszych ‘wskazówek’, ‘tips & tricks’ i tym podobnych wspomagaczy.

Dla tych którzy instalują ją po raz pierwszy – garść przemyśleń.

1. Nie walcz z systemem. Skoro Zimbra otwarcie mówi jakie systemy wspiera – zamiast kombinować, backportować, szukać tysięcy porad i wskazówek  ‘dlaczego u mnie AKURAT TA FUNKCJA NIE DZIAŁA’ – użyj jednej z supportowanych dystrybucji. Odwdzięcza się to faktem mniejszego nakładu pracy i nerwów. Co z tego że wygooglane hasło “Debian Lenny Zimbra” zwraca n-tysięcy wyników skoro będziesz nad tym siedział tydzień, a i tak wynik daleki będzie od zadowalającego.

2.Nie korzystaj z sugestii w przypadku instalerów systemowych – zwłaszcza daruj sobie podpowiedzi instalatora OpenSUSE jak to potrzebujesz LAMP (Linux, Apache, MySQL, PHP) zainstalowanego w systemie. Nie instaluj, nie wybieraj opcji jak ‘Internet Server’, ‘WWW Server’, “LAMP’, ‘Mail Server‘ i tym podobnych. Przed rozpoczęciem instalacji musisz upewnić się że w sytemie nie kręcą się żadne daemony w stylu ‘courier’, ‘postfix’,'apache’, ‘httpd’ itp. Sprawdź zwłaszcza (netstat -ap) czy wszystkie żądane przez Ciebie porty nie są okupowane przez jakiś program (25,110,143,993,7071) itp.

Czasem większą walką jest usuwanie (wraz z ‘purge’) niedobitków uparcie porozstawianych usług niż świadoma rezygnacja z nich podczas instalacji.

3.FQDN jest podstawą. Skoro nie masz w pełni ustawionego FQDN, nie chciało Ci się wykupić domeny, nie przekierowałeś rekordów MX, instalujesz Zimbrę ‘testowo’ i na maszynie wirtualnej – wejdź na forum i poczytaj jak to załatwić. Oszczędzi Ci to sporo problemów podczas instalacji i konfiguracji. Absolutna podstawą jest poprawny wynik ‘hostname -f’

4. Nie żałuj zasobów. Wybrałeś instalację AV, filtrów antyspamowych i interfejs oparty ma AJAX’ie? Nie jęcz że Java pochłania Ci 100% czasu CPU. Takie ‘piki’ to niestety norma – zwłaszcza w przypadku słabszego sprzętu.

5. Jeżeli podczas instalacji dzieją się dziwne rzeczy, usługi odmawiają startu, porty są pozajmowane lub nieresponsywne – sprawdź przynajmniej dwie rzeczy:

SELinux - przestaw na ‘disabled’

Firewall -  jakiegokolwiek używasz (Shorewall, clean iptables, Webmin Linux Firewall, SuSE Firewall2) musi pozwalać na dostęp do wskazanych wyżej portów.

Satysfakcja z działającego zgodnie z regułami systemu jest nie do przecenienia

BFF – Best Friends Forever :)

Nowa praca, nowi znajomi, nowi przyjaciele ‘do końca życia’. Czasem zdarza się jednak iż przyjaźń jest wyjątkowa.

Oto mój nowy BFF z nowego miejsca pracy

Daily Coffee Show

PS. Mały update – zgłosił się kolega, który (po przeciwnej stronie barykady) pracował z nami nad tymże pamiętnym projektem. Zbrodnią byłoby NIE zamieszczenie JEGO wersji Daily Coffee Show . Hi Surreal  – you’re right – it was a fucking honor

Update 2009-08-21. Mamy kolejny kubek z kolekcji projektów dla HP – tym razem od Gola. Kto jeszcze realizował z nami ten projekt? Wysyłajcie zdjęcie swoich kubków

I kolejny update – tym razem Lublin i kubek od Swite

Kto nie RISC’uje daleko nie jedzie ;)

Historia zaczyna się jak wszystkie – był sobie serwer HP 9000. W radosnym roku 1995 został uruchomiony w jednej z państwowych instytucji obsługując cały oddział i zapewniając niezbędne aplikacje, pod kontrolą systemu HP-UX. Chociaż dookoła tejże maszyny jak grzyby po deszczu wyrastały nowe maszyny, nowe szafy, nowe zwirtualizowane środowiska, maszyna wciąż okazywała się potrzebna zapewniając odpowiednie konektory do pracujących baz danych.

W tymże roku 1995 został opracowany podstawowy scenariusz DR (Disaster Recovery) odtwarzania pełnego systemu z napędów taśmowych. Procedura przetrwała, same napędy jak i taśmy niekoniecznie W związku ze zbliżającym się widmem awarii zostałem poproszony o przygotowanie planu ratunkowego pozwalającego na pełne odtworzenie systemu wraz z bieżącymi runetime’ami.

Dłuższą chwilę zajęło wyszukiwanie informacji o maszynie w części ‘Discontinued’ na stronie HP. WIzja lokalna potwierdziła założenia – magistrala SCSI (FAST), złącza wewnętrzne w standardzie HS50, wraz z dyskiem na taśmie znajdują się CDROM SCSI oraz napęd taśmowy – jeden z pierwszych DDS’ów

Szatański plan ewoluował w następujące formie

Wariant A

Odszukujemy dystrybucję Linuxa wydaną dla PA-RISC (koniecznie live) i zmuszamy IPL’a maszyny do startu z tejże. Mają uruchomionego Linuxa możemy dostarczyć odpowiednie narzędzie do wykonania snapshotu sektorów startowych, tablicy partycji oraz samego systemu. Przygotowujemy procedurę odzysku – operację odwrotną dla procedury zabezpieczenia danych, również opartą o dystrybucję Linux wydaną dla PA-RISC.

Wariant B

Wykorzystując sytuację iż cały system pracuje na pojedynczym dysku SCSI  2.1 GB w standardzie Fast-SCSI HS50 – patrz poniżej – odnajdujemy odpowiedni kontroler SCSI, uruchamiamy maszynę pod kontrolą systemu Linux, odnajdujemy informację o możliwościach odczytu tablicy partycji systemu HP-UX i za pomocą odpowiedniego narzędzia wykonujemy kopię wskazanego dysku do obrazu a następnie na dysk ‘awaryjny’. Dodam iż odszukanie kontrolera ze złączem Fast nie sprawiło większego problemu, natomiast dysku o pojemności większej niż 2.1 GB już tak

Wariant C

Idziemy na żywioł

Wariant A odpadł bardzo szybko – brak odpowiedniej dystrybucji live

Wariant B wykrzaczył się w połowie – OpenSuse w wersji 11.0 i 11.1 nie były w stanie odnaleźć na wskazanym dysku żadnych partycji. Ponieważ – czysto teoretycznie – powinny to zrobić, musieliśmy założyć iż kontroler HP 9000 nieco inaczej odczytuję geometrię dysku, stąd niepowodzenie w odczycie tejże dla kontrolera Tekram i systemu Linux.

Ostatnią deską ratunku okazało się banalne skopiowanie zawartości dysku za pomocą dd – ten soft nigdy nie przestanie mnie zadziwiać oraz przerzucenie obrazu również za pomocą dd na dysk awaryjny. W tymże dysku (jako że kontroler HP9000 należał do nieco prehistorycznych) należało jeszcze upewnić się iż auto-spinning jest zapewniony a ID i LUN ustawione właściwie. Dodam że cała operacja odczytu dysku zakończyła się w ok. 15 minut, drugie tyle zajęło skopiowanie obrazu dd.

Dysk zapasowy włożony w czeluści serwera został prawidłowo rozpoznany i obsłużony przez IPL, system wystartował poprawnie, konektory się podniosły. Hurra dla Linuxa ?

Walka z oporną materią…

- Z tego będzie cała nowa drukarka – powiedział Darek.

- A może nawet dwie – dodał rozmarzony

Pure-ftpd…. not so pure ;)

Z racji WAŻNEGO POWODU musiałem w trybie szybkim przenieść zasoby serwera FTP pod nowy serwer pracujący pod kontrolą OpenSUSE 11.1. Z samych serwerów FTP miałem do wyboru (w pakietach) vsftpd i pure-ftpd. Walka z vsftpd – zwłaszcza dotycząca użytkowników wirtualnych szybko zakończyła się zniechęceniem – sięgnałem więc pod drugi zintegrowany pakiet w 11.1 – pure-ftpd.

Instalacja i konfiguracja – zwłaszcza wirtualnych użytkowników – bardzo przyjemna. Siadłem jednak na 2 problemach.

Po pierwsze – pure-ftpd nie akceptuje linków symbolicznych o ile używa chrootowania dla userów – stąd linkowanie do zasobów POWYŻEJ domyślnego chroota niestety nie działa.

Rozwiązaniem okazał się mount z parametrem -bind np.

#mount --bind /home/ftp/store /home/ftp/serwis/store

Dzięki któremu zasoby /home/ftp/store są widoczne dla użytkowników chrootowanych w /home/ftp/serwis. Można to na spokojnie dopisać do boot.local nie przejmując się fstabem.

Drugim problemem związanym z pure-ftpd była jego niechęć do pracy w passive mode. Oczywiście odpowiedni zakres portów został dozwolony na firewallu – niestety LIST po logowaniu kończył się zwiechą.

Rozwiązaniem problemu okazało się:

- doinstalowanie pakietu :

| pure-ftpd | pure-ftpd: fix to honor PassivePortRange in /etc/pure-ftpd.conf | patch

- poprawa składni w konfiguracji /etc/pure-ftpd/pure-ftpd.conf polecenia PassivePortRange

ze składni:

PassivePortRange          30000 30100

na

PassivePortRange          30000:30100

Tak, tak, jedna mała spacja.

I cóż – działa

Train and certify

Nie lenić się – zdawać. Link “How To” – tutaj : sprawdź jak łatwo możesz to zrobić

Daily Coffee Show

Dziecko mi się dało złapać w sidła konsumpcjonizmu – uzyskany na otwarciu sklepu Żabki nowy kubek stał się JEGO i TYLKO JEGO!

Nie mówiąc o tym że ze dwa dni marudził o tym kubku. W końcu – czego się nie robi dla potomstwa

Wsi spokojna, wsi wesoła*

Walcząc z przytłaczającym niedzielnym lenistwem postanowiłem wywieźć Dziecko do lubelskiego skansenu. Wstyd powiedzieć, ale przez cały czas jaki tu zamieszkujemy nie znalazła się okazja aby odwiedzić tenże przybytek. Dziecię super zadowolone postanowiło nakleić pozwolenie na aparat na swoją czapkę podróżnika (ten świecący żarówiasto fragment) licząc w skrytości ducha na możliwość strzelenia paru fotek. Efekty? Poniżej.

Łany zboża i uśmiech Dziecięcia

Tak, tak – TE łany.

Które następnie przerabiamy na papu w takich urządzeniach.

W malinowych chruśniaku, lub jeżeli kto woli ‘Dom malwami malowany’. Eee zielsko …..

Studnie głębokie i szerokie…

Koń nie chciał wydawać odgłosu paszczą … Ciekawe …

Kozy nic sobie nie robiły z pobliskiego ‘Nie karmić zwierząt’. Koszyki piknikowe raz-dwa znikały w ich przepastnych gastro-fabrykach. Ciekawe jakie mleko powstaje z paluszków z sezamem?

Dziecię precyzyjnie rozpoznało Bonifacego. Poszukiwania Filemona trwają …

Sympatyczniejsza wersja Powiśla. Może dlatego że w Lublinie?

Gdybym był bogaty …. Ale i tak fajne były tam karabiny. Tylko Bionicli jak na lekarstwo.

*) tytuł LINK

XFCE 4.4.3, normalny ‘user’ i shutdown

No się nie da.  Ale się da.

Wujek Google polecał metode ze zmianą sudoers np. na taką:

%shutdown ALL=(root) NOPASSWD: /usr/sbin/xfsm-shutdown-helper

Samo w sobie nie działa. Dokonujemy jeszcze odpowiedniego wpisu w pliku /etc/PolicyKit/PolicyKit.conf

<define_admin_auth group=”operator” />
<match action=”org.freedesktop.hal.storage.mount-removable”>
<return result=”yes” />
</match>
<match action=”org.freedesktop.hal.storage.mount-fixed”>
<return result=”yes” />
</match>
<match action=”org.freedesktop.hal.storage.eject”>
<return result=”yes” />
</match>
<match action=”org.freedesktop.hal.storage.unmount-others”>
<return result=”yes” />
</match>
<match action=”org.freedesktop.hal.power-management.reboot”>
<return result=”yes” />
</match>
<match action=”org.freedesktop.hal.power-management.shutdown”>
<return result=”yes” />
</match>
<match action=”org.freedesktop.hal.power-management.hibernate”>
<return result=”yes” />
</match>
<match action=”org.freedesktop.hal.power-management.suspend”>
<return result=”yes” />
</match>

I działa. Hurra.

The Day The Music Died

Nie ulega wątpliwości że dzisiaj pożegnaliśmy znaczący fragment beztroskich lat 80-90. Rocznik 73 zachwycał się “Thrillerem‘ w szkole podstawowej, liceum przywitało nas przy dźwiękach ‘BAD“, dźwięki z ‘Dangerous‘ towarzyszyły nam na półmetku, matura bezdyskusyjnie związana jest z ‘HIStory: Past, Present and Future Book I‘.

Furda skandale, furda ‘Neverland’.

The Day The Music Died

Ciekawa dyskusja projektowa

Przy okazji wątku dyskusji na GL przypomniała mi się krótka dyskusja w temacie wykorzystania nowszych kontrolerów macierzowych i redundancji jako takiej w pewnym projecie.

Warunki dyskusji były następujące: grupa świeżo upieczonych “projektowych” techników, workstacje pracujące pod kontrolą systemu Linux, wykorzystujące dwa identyczne (co do rozmiarów) dyski na których określone partycje systemowe (/) były zabezpieczone RAID 1, tzw. software’owym (mdraid) . Na tychże workstacjach kręciły się silniki bazodanowe PostgreSQL’a, niewielkie bazy, niewielka ilość operacji.

Argumentem z jakim wyskoczył któryś z techników było:

T – Technik

J- Ja

T: A dlaczego nie wykorzystać RAID’ów które wbite są w kontrolery nowoczesnych płyt głównych – prawie każda z nich posiada coś takiego na poziomie hardware’owym’?

J: No cóż, proszę sobie wyobrazić sytuację – pada płyta główna, automatycznie traci Pan dostęp do danych na dyskach.

T: Dlaczego?

J:Bo aby dostać się do danych musi Pan posiadać IDENTYCZNĄ płytę główną, z IDENTYCZNĄ konfiguracją oraz często z IDENTYCZNĄ wersją BIOS. Czyli, przy okazji dowolnej awarii płyty głównej traci Pan dostęp dysków, danych a także do backupów które to na tych dyskach istnieją na oddzielnych partycjach.

T:No tak, to rzeczywiście problem. Ale, w takim wypadku, dlaczego nie skorzystać ze śmiesznie tanich kontrolerów macierzowych sprzedawanych po klasyczne 30 zł, identycznych co do marki.

J: Jasne. Pomysł w istocie przedni, ale proszę policzyć. Ma pan 3000 workstacji, do każdej trzeba dokupić kontroler za 30 zł. Zakładając że średni czas życia workstacji to 3 lata, po 3 latach trzeba wymienić około połowy tychże kontrolerów, które należy zakupić na początku projektu – za 2 miesiące może ich nie być. Teraz pomnóżmy to przez siebie – w ciągu miesiąca musimy wydać 135,000 PLN, które  zamrozimy na czas trwania projektu.

T: No ale to się opłaca – wydajność takiej workstacji będzie o poziom wyższa niż na RAIDz’ie software’owym, warto zainwestować prawie 140 tysięcy w kontrolery.

J:Wie Pan, możemy to sobie bardzo łatwo sprawdzić za pomocą iozone, zawsze mnie jednak uczono że nie ma macierzy software’owych ani hardware’owych, wszystkie są software’owe, tylko pytanie na jak niskim poziomie operacji tenże software pracuje

Tajemnicą bowiem poliszynela jest iż tanie, wbite w płyty główne kontrolery, do większości operacji przeliczania redundancji (RAID5) wykorzystują procesor systemowy. Cała idea takiego ‘przyspieszenia’  idzie wtedy w diabły. Bezpieczeństwo przechowywania danych na tak utworzonych macierzach, zależnych w 100% od typu płyty głównej (i wydajności CPU) jest bardzo kiepskim pomysłem.

Dzień Ojca – najlepsza pobudka o 6:37 jaką miałem w życiu.

Oczywiście po to aby wręczyć poniższe DZIEŁO. Niniejszym prezentuję społeczeństwu

Zmiana nastroju – Kimchi na pokładzie.

Zmieniając lekko nastrój i tematykę bloga – kimchi jest szalenie popularną potrawą/dodatkiem pochodzenia koreańskiego. Jest dla Korei bardziej narodowa od naszego schabowego, pierogów ruskich, francuskich żab i ślimaków razem wziętych Serwowana jako dodatek do każdego nieomal dania, dostępna w licznych regionalnych odmianach (każdy region, baa każda wioska ma swoją strzeżoną recepturę) – niesamowicie pikantna, pyszna i zdrowa. Doczekała się swoich odmian: zupy z kimchi, oraz ryżu smażonego z kimchi

Historycznie – przygotowywana jako źródło witamin na długie koreańskie zimy – dzisiaj stała się po prostu całorocznym dodatkiem. W Polsce dostępna w miejscach nielicznych, przeważnie w restauracjach orientalnych, różniąca się smakiem (od przepysznych po zupełnie niejadalne). Bardzo łatwa do zrobienia, warunkiem jej smaku jest jednak długie “dojrzewanie” jak by powiedzieli niektórzy.

Przepisów w sieci jest mnóstwo, jeden z najpopularniejszych każe dam kapustę pekińską wymoczyć w solance (9 części wody/1 część soli), solidnie w niej ‘umyć’, odsączyć, natrzeć solą i odłożyć na ok. 2 godziny.

W międzyczasie przygotowujemy drugą część: dwie długie białe rzodkiewki tniemy na wąskie paski. Do tego dodajemy solidny kawałek imbiru pokrojony w maleńkie kawałeczki. Dodajemy pokrojoną cebulę dymkę (szczypiorek z braku laku), jak na poniższym obrazku.

C

Przygotowujemy pastę paprykową – dwie szklanki tejże solanki, dosypujemy do niej tyle słodkiej papryki w proszku aż zrobi się z tego gęstawa breja. Do tejże pasty dodajemy pół (słowo – nie więcej) torebki ostrej papryki chili  w proszku. Całość brei mieszamy z przygotowanymi wcześniej dodatkami tworząc coś takiego:

Ostatnim etapem jest przygotowanie do ‘kiszenia’. W dużym (sugeruję koniecznie niemetalowym) naczyniu układamy warstwami: warstwę odsączonej i opłukanej z soli kapusty pekińskiej, na to warstwę naszej ‘brei’. Warstwami aż do wypełnienia naczynia. Dociążamy talerzem i czymś ciężkim (jak widać, poniżej w sposób tradycyjnie staropolski

Teraz przychodzi czekanie – odstawiamy naszą zdobycz na minimum tydzień (tak, tak siedem dni) do chłodnego miejsca – lodówka może być. Po tygodniu wyjmujemy całe, przygotowane warstwowe ‘placki’, tniemy je na wąskie paseczki i w takiej formie do słoików i znowu do lodówki.

Jak to jeść? Kimchi jest nieco za ostre aby jeść je samo – genialnie jednak sprawdza się jako dodatek do ryżu z warzywami, mięskiem, makaronów, kanapek na zimno i tym podobnych zestawień – wszędzie gdzie występuje jako dodatek. Zdarzało mi się je jednak jeść z samym pieczywem – cóż mogę powiedzieć, smakuje rewelacyjnie

DRBL – z czym się to je, część II – instalacje OS

Jak działa to w praktyce ? Otóż bardzo fajnie. System jest wyposażony w odpowiedni skrypt który sam pobierze i zainstaluje mini-instalacje powyżej zebranych dystrybucji. Oznacza to – iż chcemy np. mieć możliwość instalacji Debiana (Etch i Lenny) zarówno w wersji 32 jak i 64 bitowej, uruchamiamy odpowiedni skrypt (net-install) z parametrem Debian i za chwilę możemy cieszyć się dodatkowymi opcjami dodanymi do menu PXE.

Dalsza część usprawniania instalacji to oczywiście parametry przekazywane do instalatora w trakcie jego uruchomienia. Możemy wybrać jedno z właściwych repozytoriów Debiana, przekazać parametry instalacji …. lub możemy skorzystać z w pełni zautomatyzowanych systemów instalujących (FAI dla Debiana, AutoYAST dla SuSE)

W czasie pracy najwięcej czasu poświęciłem projektowi AUTOYAST, który dostępny jest dla systemów SuSE (openSuSE, Novellowe SLED i SLES). Ten w pełni dojrzały projekt pozwala nam na totalną i pełną konfigurację instalowanego systemu przez zestaw dyrektyw i parametrów zapisywanych w składni XML. Mamy wpływ na każdy etap procesu instalacji – zaczynając od parametryzacji dysków, partycji, filesystemów, rozmiarów instalacji, wybranych pakietów, startujących usług, konfiguracji wszelakich usług, uruchamiania dodatkowych skryptów (zarówno w fazie PRE jak i POST instalacyjnej), na integracji z LDAP i wykorzystaniu informacji z tegoż systemu do parametryzacji wszelakich instalacji.

Ba, dzięki podziałowi na fazy PRE i POST możliwe są takie rzeczy jak przygotowywanie własnych modułów do obsługi sprzetu (np. nietypowych lub nieobsługiwanych standardowo kart sieciowych, dostarczenie ich w fazie PRE a następnie kontynuacja instalacji w fazie POST)

System posiada własny edytor, dla zaawansowanych zostaje wersja XML do edycji ręcznej. Narzędzie jest bardzo wygodnie – wynikiem procesu projektowania jest plik XML którego lokalizację przekazujemy za pomocą PXE i DRBL’a do instalatora. Przygotować możemy nieskończoną ilość takich profilowanych instalacji dołączając je kolejno do menu instalatora.

Przykładowa dyrektywa instalacji stosowanych przeze mnie:

label Instalacja
# MENU DEFAULT
# MENU HIDE
MENU LABEL Instalacja zaplecze v.2.xx
# MENU PASSWD
TEXT HELP
* Instalacja systemu operacyjnego SLED 10 SP1
ENDTEXT
kernel linux
append initrd=initrd.200902 ramdisk_size=128000 splash=silent showopts install=http://172.16.0.1:/sled server=172.16.0.1 serverdir=/sled autoyast=http://172.16.0.1/sled/autoyast-net-raid.xml language=pl_PL

Jak wygląda wydajność takiego rozwiązania? Systemy sprofilowane (SLED 10 SP1) na maszynach klasy Intel Celeron (1.8/2.0) z 1 GB RAM, z pełnym oprogramowaniem projektowym instalują się około 45 minut. Niesamowitym plusem takiego rozwiązania, przy zastosowaniu szybszych interfejsow Gigabitowych jest fakt, iż jednocześnie może trwać instalacja wielu maszyn. W testach przeprowadzanych przez nas do 5 maszyn jednocześnie spowolnienie instalacji było niewidoczne (sieć lokalna, interfejsy i switche gigabitowe).

Przy wzroście ilości maszyn do 10 na raz czas instalacji per wzrósł o ok.5 do 7 minut. Oznacza to, iż średniej klasy maszyna (desktop jako serwer) jest w stanie przeprowadzić około 80 instalacji dziennie w 8 godzinnym cyklu pracy. Zakładając możliwość dostawienie drugiego interfejsu – liczba wzrasta do 150 w cyklu 8 godzinnym.

Warto zaznaczyć iż instalacja jest totalnie bezobsługowa – można nawet nie wykorzystywać monitorów do obserwacji procesu. Prostym wpisem w autoyast całość instalacji kończymy shutdownem – oznacza to iż każda z maszyn które własnie go wykonały są gotowe do spakowania do pudełka lub wykorzystania w projekcie.

Rozwinięciem idei  instalacji bezdotykowej jest zastosowanie sieci serwerów DRBL jak na poniższej ilustracji:

Poszczególne serwery rozproszone w innych lokalizacjach (inny budynek, inne miasto, inny kraj) pozwalają na wykonywanie dokladnie tych samych czynności w oddziałach, używając tych samych (lub odpowiednio zmodyfikowanych korzystając z LDAP/AD) parametrów.

Za całość procesu synchronizacji odpowiadać może subsystem RSYNC skonfigurowany tak aby weryfikować i naprawiać ewentualne błędy za pomocą weryfikacji sum kontrolnych MD5.

Najciekawiej wygląda zarządzanie zmianą w tego typu projekcie – z racji niewielkich rozmiarów zarówno samego autoyast.xml , jak i poszczególnych pakietów wchodzących w sklad instalacji, aktualizację założeń instalacji, aktualizację pakietów instalacyjnych można przeprowadzić dosłownie w kilka minut.

W praktyce przesłanie samych założeń instalacji trwa około 2 minut w przypadku 6 dodatkowych rozproszonych lokalizacji. Gdy w grę wchodzą pakiety dodatkowe wykorzystujemy przetwarzanie równoległe – wiele jednoczesnych procesów synchronizacji (wykorzystujących fakt iż łacze serwera centralnego jest wielokrotnie bardziej wydajne niż łącza poszczególnych serwerów oddziałowych.

Ponieważ jednocześnie, oprócz samych opisow instalacji przesyłać można obraz wykonane za pomocą systemu Clonezilla sam DRBL okazał się doskonałym uzupełnieniem codziennej pracy systemowo-projektowej.

Wyobraśmy sobie projekt w którym z częstotliwością np. miesięczną zmieniają się obrazy instalacyjne stacji roboczych i nośników. Dystrybucja tychże na nośnikach DVD/USB okazywała się koszmarem – zawsze zdarzało się iż wersja jak została zainstalowana różni sie od wersji obowiązujacej. Dokładając do tego czas rozproszenie i przygotowania nośników okazało się to sporym problemem.

Rozwiązanie przyszło w postacji maszyny DRBL – zawsze dostępnej z tym samym menu co ostatnio. Zawartość obrazów mogła zostać zaktualizowana, instalator mógł wykonywać zupełnie nowe czynności, jednakże z punktu widzenia instalującego NIC się nie zmieniało. Zawsze witał go ten sam, widziany ostatnio obrazek