Blog Marcina Bojko

Linux,Windows,serwer, i tak dalej ;)

Posts Tagged ‘opensuse

DRBL i kolejne pożyteczne narzędzia via PXE

Jak zapewne wiadomo tym, którzy przebrnęli przez poprzednie wpisy o DRBL, system ten dostarcza ciekawy mechanizm umożliwiający dostarczanie kilku pożytecznych narzędzi za pomoca  PXE bezpośrednio do komputera na którym je potrzebujemy. Iż jest to czasem błogosławieństwo chyba nie muszę opowiadać: brak dyskietki, dysku USB, CDROMU, uszkodzenie tychże i tak dalej i tak dalej.

Przykład? Konieczność wykonania akcji ratunkowej/maintenance na badanym systemie – ot klasyczny uszkodzony Windows/Linux do spacyfikowania. Zazwyczaj wykonujemy opcję startu z CD/DVD, czasem klucza USB (bez angażowania dysku twardego), a tu pokażę jak możemy to zrobić łatwiej i przyjemniej: via network. Dzisiaj zajmiemy się dostarczeniem jednego z ciekawszych systemów ratunkowych: System Rescue CD, dostępnego tu: http://www.sysresccd.org

Kilka aksjomatów:

– pokaz przeprowadzam na openSUSE 11.3 z zainstalowanym systemem i prekonfigurowanym DRBL’em w wersji 1.10.31_1

– interfejs dla podsieci DRBL to 172.16.0.1, podsieć 172.16.0.0/24

– obrazy systemów dostarczamy za pomocą http – można to zrealizować poprzez tftp, nfs, nbd – http pozostaje jednak najbardziej uniwersalny dla dodatkowych systemów podpinanych do DRBL’a, jak również stosunkowo najłatwiejszy w konfiguracji.

– zawartość serwera HTTP domyślnie znajduje się w /srv/www/htdocs

– zawartość DRBL/Tftpd domyślnie znajduje się w /tftpboot/nbi_img

– plik konfiguracyjny drbla znajduje się w /tftpboot/nbi_img/pxelinux.cfg/default

– wszystkie operacje wykonujemy jako root/sudo su

Zaczynamy od pobrania ostatniej wersji System Rescue CD – na potrzeby manuala jest to 2.3.1, ale oczywiście powinno działać z wersjami wcześniejszymi i późniejszymi, bez dokonywania zmian innych niż nazewnictwo plików i ich wersje:

# pobieramy i montujemy ISO jako filesystem
wget http://downloads.sourceforge.net/project/systemrescuecd/sysresccd-x86/2.3.1/systemrescuecd-x86-2.3.1.iso
mkdir -p /media/system
mount systemrescuecd-x86-2.3.1.iso /media/system -o loop

# zawartość pliku ISO jest dostępna w /media/system # kopiujemy z System Rescue CD jego kernel i initrd
cp /media/system/isolinux/rescuecd /tftpboot/nbi_img/rescuecd
cp /media/system/isolinux/rescue64 /tftpboot/nbi_img/rescue64
cp /media/system/isolinux/initram.igz /tftpboot/nbi_img/initram.igz.systemrescue

#Kopiujemy plik obrazu systemu do naszego domyślnego serwera http.
cp /media/system/sysrcd.dat /srv/www/htdocs/sysrcd.dat
cp /media/system/sysrcd.md5 /srv/www/htdocs/sysrcd.md5

# sprawdzamy czy mamy uruchomiony serwer http:
chkconfig -l apache2
apache2                   0:off  1:off  2:off  3:on   4:off  5:on   6:off
 
# Uwaga, - krok opcjonalny jeżeli poprzedni krok zwrócił nam same 'off'
yast2 -i apache2
chkconfig --add apache2

# testujemy nasz serwer http
wget http://172.16.0.1/index.html

--2011-10-14 18:04:49--  http://172.16.0.1/index.html
Connecting to 172.16.0.1:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 44 [text/html]
Saving to: `index.html'

100%[=====================================================================================================================================>] 
44          --.-K/s   in 0s      

2011-10-14 18:04:50 (2.19 MB/s) - `index.html' saved [44/44]
# Wygląda na to iż wszystko działa ;) # Robimy kopię ustawień DRBL'a
cp -p /tftpboot/nbi_img/pxelinux.cfg/default /tftpboot/nbi_img/pxelinux.cfg/default.old
# Swoim ulubionym edytorem (gedit/mcedit/vi/ed) dokonujemy edycji pliku: 
/tftpboot/nbi_img/pxelinux.cfg/default

mcedit /tftpboot/nbi_img/pxelinux.cfg/default
# Na końcu pliku dodajemy linie:

label System Rescue CD 2.3.1
#  MENU DEFAULT
#  MENU HIDE
   MENU LABEL System Rescue CD 2.3.1
#  MENU PASSWD
   kernel rescuecd
   append initrd=initram.igz.systemrescue netboot=http://172.16.0.1/sysrcd.dat setkmap=pl 
   nomodeset dostartx
#  TEXT HELP
#  Boot System Rescue CD via network
#  ENDTEXT

label System Rescue CD 2.3.1 64bit (required 400 MB or more)
#  MENU DEFAULT
#  MENU HIDE
   MENU LABEL System Rescue CD 2.3.1 64bit (required 400 MB or more)
#  MENU PASSWD
   kernel rescue64
   append initrd=initram.igz.systemrescue netboot=http://172.16.0.1/sysrcd.dat docache 
   setkmap=pl nomodeset dostartx
#  TEXT HELP
#  Boot System Rescue CD 64bit via network
#  ENDTEXT

I efekt:

W następnym odcinku: GParted, PartedMagic, i Hiren's Boot CD ;)

Written by marcinbojko

Październik 14, 2011 at 19:07

Filmy z wykładu DRBL Kul Lublin

Przezwyciężając lenistwo:

Część I

Część II

Część III

Część IV

Część V

Część VI

Written by marcinbojko

Grudzień 14, 2010 at 16:02

I po wykładzie…

Spotkanie odbyło się planowo – poniżej snapshot prezentacji.

Filmy mam nadzieję dam radę później 😉

Written by marcinbojko

Listopad 9, 2010 at 17:00

DRBL w Lublinie

Kontynuując współpracę z uczelniami – w dniu 4 listopada, na Wydziale Matematyczno-Przyrodniczym KUL, sala 604 będę miał przyjemność poprowadzić spotkanie dotyczące DRBL – kolejna, bogatsza o rok doświadczeń edycja spotkania z LUMD.

Spotkanie rozpoczyna się o 18:40

Skupimy się głównie na możliwościach deploymentu i migracji wielu jednostek jednocześnie, jak również na systemie pracy terminalowej dla małych klientów (biblioteki, uczelnie itp.)

Oficjalna strona Koła Naukowego Informatyków KUL: http://kni.kul.lublin.pl/Aktualnosci.aspx

Mam nadzieję, iż tym razem uda się zamieścić film z wykładu 🙂

Zapraszam 😉

Written by marcinbojko

Październik 28, 2010 at 10:35

Kto nie RISC’uje daleko nie jedzie ;)

hp9000

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 ? 😉

Written by marcinbojko

Lipiec 26, 2009 at 10:26

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 😉

Written by marcinbojko

Lipiec 16, 2009 at 12:16

Napisane w Uncategorized

Tagged with , , , ,

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.

Written by marcinbojko

Czerwiec 25, 2009 at 17:39

Napisane w Uncategorized

Tagged with , , , ,

%d bloggers like this: