Blog Marcina Bojko

Linux,Windows,serwer, i tak dalej ;)

Posts Tagged ‘servers

Puppet & The Foreman & Powershell DSC – The Road So Far.

During last few weeks I was able to push and heavy test puppet-dsc code in a lots of environments and setups.

We had sysprepped Windows Server 2012 R2 images (different versions, builds and setups), a lots of Windows 10 Professional Workstations (Original, 1511, 1607 builds), few Windows 8.1 Pro – really great statistic sample.

As for now:

  • Windows Server 2012 and Windows 2012 R2 – fully supported
  • Windows 8.1/10 (original)/10 (1511) – fully supported
  • Windows Server 2016/Windows 10 (1607) – unsupported due to parsing bug in Powershell 5.1 – Work in progress
  • Windows 7/8 – not tested
  • Windows 2008 R2 – not tested

Implemented modules:

  • Chocolatey – with features and sources support (adding, removing, modyfing)
  • DSC_WindowsFeature
  • DSC_WindowsOptionalFeature
  • DSC_Service
  • DSC_Environment
  • DSC_Group
  • DSC_xFirewall
  • DSC_Reboot

More code is coming, but this fine set allows you to deploy and manage a lots of types of servers and workstations.

Written by marcinbojko

7 października, 2016 at 19:47

Puppet & The Foreman & Powershell DSC – your System Center in a box :)

Few weeks ago I started a little project – complete Puppet module called: win_manage.

My goal was to manage Windows based machines almost as easy as Linux servers, as little code inside as possible (you know, I am not a developer in any kind). And when I was thinking: KISS is no more possible with this project, I’ve found Puppet Powershell DSC module:

Adding another resources it is just a breeze, the biggest part of work was to test almost every setting provided by Microsoft, to have working examples in day-to-day SysAdmin/DevOP job.

And yes, I know – we have plenty of things like this, sold with different price plans, different support plans and so on. But if you cannot afford pricey tools like Puppet Enterprise or System Center 2012 R2 in your environment, this little project comes to help you 🙂

First things first – why?

  1. We have excellent granularity using Puppet and Foreman architecture without complicated AD GPO with filters.
  2. Nested groups/copying groups helps so much in creating cloned environment
  3. It doesn’t matter what provider do you use: physical, virtual, VMWare,Hyper-V, Azure – it just works.
  4. With additional modules like Chocolatey and our private sources (and private CDNs) the story is completed – no more AD MSI voodoo stuff. Software deployment and maintenance just got really better.
  5. One is is to deploy, second thing is to maintain and manage. Securing running services or making permanent changes in your environment is as much important as just deploy them.
  6. No more ‚just another script’ approach.
  7. Everyone can afford simple machine with simple YAML examples 😉

So my work in progress looks just like this:




Host Groups


Parameters to set

We love YAML driven configuration: setting users, rules, applications is just as easy as writing very light code:

Setting registry:

 dsc_valuename: Password
 dsc_valuedata: af af af af af af af af
 dsc_valuetype: binary
 dsc_valuename: ControlPassword
 dsc_valuedata: af af af af af af af af
 dsc_valuetype: binary

Adding features:

 dsc_ensure: present
 dsc_name: Web-Server
 dsc_includeallsubfeature: true
 dsc_ensure: present
 dsc_name: DSC-Service

Installing and maintaining latest version of packages:

 ensure: latest
 ensure: latest
 ensure: latest
 ensure: latest

So, what to do next? I will be adding additional DSC Resources to module and hopefully will be able to make it public. Stay tuned and keep your fingers crossed 😉


Written by marcinbojko

4 października, 2016 at 19:11

Compacting Virtual Disks in System Center Virtual Machine Manager 2012 R2 or Hyper-V 2012 R2

As we all know – disk space isn’t free. If you allocate disk space to your virtual machine, you always want to allocate proper, well-balanced size to shorten future downtimes. But what is proper and balanced you ask?  There is no short answer to this, but if you’re  IT person, you always will try to allocate more than is needed right at the moment.  The decision is : should I use static or dynamic disks?

For me, there is no really need to use static disks anymore as there is no real speed difference. So, the real pro using dynamic disk is their smaller size.

In production environment, using Microsoft’s hypervisor, we can expect our VM to grow over time. During the nature of virtual machines and virtual disks, the real data machine uses are not the same numbers as virtual disk sizes. It is happening due to hypervisor behaviour – deleting all data from OS in virtual machine is no more than throwing away and index card from your book. The written data are still there, so there is no easy, automated way to compact a virtual disk.

Hypervisor however, tries to allocate in a first place, blocks marked as used. So the real expanding is happening when you’re constantly changing your data, without deleting them first. The great example is with databases, log and temporary trash disks and just plain and simple oversizing. I’ve had a case when relativly small machine (20 GB CentOS with a 600 GB VD) just grew over few days filling whole 600 GB of data because of logs set to DEBUG.

So what will be the cons and of virtual disk growing overtime?

  • obviously, more space allocated at expensive storage for VMs
  • more obviously, when you’re using any kind of backup software, you’re forced to write and store in multiple copies the data you really doesn’t need
  • CBT (Change Block Tracking) Table is bigger to process, with every move
  • more network traffic with every backup job you have
  • live ‚shared nothing’ migration times grows just out of proportions. If you have a small machine with 20GB data on 600 GB sized disk, you will have to transfer this whole fatso over you network to other machine. Even with compression set at live migration, it is just really unwanted.

So what can we do? We can just zero the data you’re not using and Hyper-v cmdlets  will take the rest.

You have to plan downtime for the machine, but according to my tests, zeroing machines with 600 GB took 15 to 30 minutes. With smaller sizes it is just matter of single minutes.

Before you go:
– plan your downtime, compacting should not to be interrupted
– take extra caution. Zeroing important data or uneeded data it’s just a matter of mistake.
– delete all snapshots/checkpoints
– make sure you converted VHD to VHDX (optional)
– make sure your disk is set as dynamic disk
– make sure you have enough room for compacting or resizing. Remember – if you have 600 GB virtual disk, during this process it may grow to this size.
– remember that compacting deletes CBT table for backup software – next backup will be a Full Backup.

The most usable zeroing ways I found was:

Offline methods

– longer downtime
– more accurate (no more background write)
– faster (no more background write)
– smaller risk of processes failure due to ‚out of space’ event

  • zerofree for Linux ext2/ext3/ext4 disks
  • ntfswipe for Windows based disks
  • dd for both Linux and Windows based disks or exotic fs (btrfs/xfs)

Online methods
– less accurate (background write  is still happening)
– machines became slower or unresponsible
– slower process
– risk of applications failing due to ‚out of space’ events
– smaller downtime

– SDelete or CCleaner for Windows based disks
– dd for Linux based disks


Phase I – Zeroing Offline

Offline zeroing (done with System Rescue CD 4.x)

  • Delete all uneeded data (logs, temps, bigfiles, dowloads, caches)
  • Umount all ext2/3/4/ntfs volumes
  • for NTFS volume: ntfswipe -av /dev/volume_name
  • for ext2/3/4 volume: zerofree -v /dev/volume-name
  • for LVM: vgchange -a y;zerofree -v /dev/mapper/volume_name
Zeroing swap space:
# swapoff -a

# free
total used free shared buffers cached
Mem: 8056340 2643132 5413208 155072 606916 914796
-/+ buffers/cache: 1121420 6934920
Swap: 0 0 0

# blkid |grep swap
/dev/sdb2: UUID="adad0488-3b67-4444-b792-6a1a775b8821" TYPE="swap"
# dd if=/dev/zero|pv -treb|dd of=/dev/sdb2 bs=8192
dd: error writing ‘/dev/sdb2’: No space left on device
1,91GB 0:01:04 [30,3MB/s]
249981+4 records in
249980+4 records out
2047868928 bytes (2,0 GB) copied, 67,931 s, 30,1 MB/s

#mkswap /dev/sdb2 -U "adad0488-3b67-4444-b792-6a1a775b8821"
Setting up swapspace version 1, size = 1999868 KiB
no label, UUID=adad0488-3b67-4444-b792-6a1a775b8821
# swapon -a

# free
 total used free shared buffers cached
Mem: 8056340 3309648 4746692 159844 1112232 919708
-/+ buffers/cache: 1277708 6778632
Swap: 1999868 0 1999868

Phase I – Online zeroing

1. Delete all uneeded data (logs, temps, bigfiles, dowloads, caches)

for Windows machine
sdelete -z letter:

Linux machine
#dd if=/dev/zero|pv -treb|dd of=/ bs=4096;sync;sync;rm -rfv /;sync

Phase II – Compacting

1. Shutdown the machine

For System Center VMM 2012 R1/R2

Workspace 1_107
For Hyper-V powershell

Optimize-VHD -Path path_to_vhdx_file.vhdx -Mode Full


Workspace 1_108
System Rescue CD –
SDelete –
CCleaner Portable –
zerofree –

Written by marcinbojko

3 sierpnia, 2014 at 13:10

Bezpieczeństwo urządzeń drukujących

Dziś parę słów o urządzeniach, na które większość z nas nie zwraca większej uwagi: mianowicie urządzenia drukujące, drukująco-skanujące (MFP/MFD – Multi Function Printer/Multi Function Device) oraz popularne kserokopiarki. Przyzwyczajeni do tego, iż z wyjątkiem uciążliwych zacięć papieru oraz uzupełniania materiałów eksploatacyjnych niewiele się z nimi dzieje, przespaliśmy epokę, w której urządzenia te stały się tak samo skomplikowane jak komputery z których drukujemy.

Z uwagi na specyfikę pewnych firm (zwłaszcza w PL), opartych wciąż na przetwarzaniu papierowych wydruków, urządzenie takie często stanowi centrum nerwowe spółki. Ze stopniem skomplikowania idzie niestety podatność na ataki, exploity oraz nadużycia, które podzielić możemy na 3 podstawowe grupy.

Pierwsza z wymienionych grup to właśnie włamania i exploity wykorzystujące fakt, iż urządzenia drukujące korzystają ze zmodyfikowanych popularnych pakietów (zarówno o kodzie otwartym jak i zamkniętym) jak: Apache, Lighttpd, Java, PHP czy też ogólnie dostępne silniki bazodanowe. Wszystkie te wymienione pakiety możemy chociażby spotkać podczas korzystania z paneli lub konsol sterujących dla wskazanych urządzeń. Opieranie się na gotowym kodzie niesie za sobą niebezpieczeństwo wystąpienia błędów, które z uwagi na społecznościowy charakter oprogramowania open-source, są szybko wychwytywane i ujawniane publicznie. Cykl wytwarzania oprogramowania open-source pozwala na szybszą reakcję w celu korektę błędu, podczas gdy w przypadku oprogramowania funkcjonalnego o zamkniętym kodzie (jak np. firmware urządzeń drukujących), do czasu załatania błędów przez producenta, jesteśmy narażeni na ataki i exploity.

Na jakiego dokładnie typu zagrożenia jesteśmy narażeni?

Zdobycie hasła administracyjnego w urządzeniu pozwala na zmianę wszystkich parametrów procesu drukowania: złośliwe strony z bannerami, zmiana parametrów wydruku (kolor/odcienie szarości), zmiana rozdzielczości, zmiana ACL dla określonych IP, zmiana adresów e-mail lub ustawień serwera SMTP skojarzonego z kontem urządzenia drukującego. W kilku określonych przypadkach zdobycie dostępu do urządzenia może również spowodować zdobyciem dostępu do panelu serwisowego, gdzie zmiany dokonane przez atakującego mogą być o wiele bardziej bolesne. Istnieją udokumentowane przypadki gdy za pomocą zmiany parametrów serwisowych napastnik był w stanie doprowadzić do uszkodzenia urządzenia (sterowanie temperaturą nagrzewania)

W przypadku wdrożonych systemów autoryzacji i rozliczeń (Authorisation and Accounting), atakujący może na przykład wpłynąć na zmianę raportów o ilości wydrukowanych stron i dokumentów w rozbiciu na poszczególnych użytkowników. Łatwo można sobie reakcję kontrolującego, jeżeli na koncie któregoś z użytkowników pojawią się nazwy zadań drukowania o swojsko brzmiących nazwach bestselerów czytelniczych.

Dostęp do panelu serwisowego niesie za sobą również inne zagrożenia – część znanych mi urządzeń MFP/MFD posiada opcję ‚mirror’, czyli wysyłania WSZYSTKICH zadań, czy to wydruku, czy to skanów, na wskazany adres serwera FTP/SMB. Napastnik, wykorzystując hasło domyślne urządzenia, lub przechwytując hasło administracyjne, ustawiając prostą i dobrze udokumentowaną funkcję zapewnia sobie dostęp do wszystkich dokumentów przepływających prze wskazane urządzenie. Dotyczy to zarówno wydruków, skanów oraz popularnych kopii.

Popularny, prosty w przeprowadzeniu i stosunkowo trudny w diagnozie atak typu DoS pozwala na zatrzymanie pracy urządzenia, podczas gdy jedynym rozwiązaniem wyjścia z impasu okazuje się restart urządzenia.

Drugi typ zagrożeń jaki pojawia się przy urządzeniach drukujących ma na celu, oprócz unieruchomienia urządzenia, spowodowanie jak największych strat dla właściciela urządzenia. Nie jest tajemnicą, iż koszty materiałów eksploatacyjnych potrafią być bardzo wysokie, zwłaszcza w przypadku kolorowych urządzeń wielkoformatowych posiadających dodatkowe banki na papier. Bardzo popularną formą „outsource” dla urządzeń drukujących jest tzw. CPC (Cost Per Copy), gdzie w opłacie za każdą wydrukowaną czy zeskanowaną stronę użytkujący płaci firmie wynajmującej zryczałtowaną opłatę. Opłata zawiera w sobie przykładowo: koszt materiałów eksploatacyjnych w tym materiałów mechanicznych, jak rolki czy pasy transferowe, koszt elementów serwisowych (parts & labour), SLA itp. Umowy takie często zawierają klauzule o wyłączeniu odpowiedzialności właściciela urządzenia przy przekroczeniu średniego pokrycia strony (zazwyczaj od 2 do 8%).
W przypadku braku ograniczenia dostępu łatwo można doprowadzić do efektu gdzie dowolna osoba uruchomi zapętlone wydruki np. zdjęć w wysokiej rozdzielczości czy też wydruków próbnych (z reguły posiadających sporą gamę kolorów), błyskawicznie wyczerpując zarówno materiały eksploatacyjne (w tym wspomniane pasy transmisijne) jak i papier. W wysoko zautomatyzowanych środowiskach, gdzie oba te czynniki podlegają automatycznemu uzupełnianiu, raporty ze zużycia drukowane są np. w systemie miesięcznym, brak kontroli nad tym czynnikiem może narazić nas na spore straty.

Trzeci typ zagrożeń dotyczy dostępu do przetwarzanych treści.
– dostęp do fizycznego urządzenia, gdzie dowolna osoba może zapoznać się z treścią przetwarzanego dokumentu
Na nic najwymyślniejsze systemy zabezpieczeń w sytuacji gdy wiele osób lub działów używa tej samej puli urządzeń drukujących. Od momentu zlecenia wydruku, do momentu fizycznego odbioru zadrukowanych kartek potencjalnie dowolna (nawet postronna) osoba może dostać się do naszych danych. Bardzo częstym przypadkiem jest ustawianie urządzeń drukujących w miejscach, przez które przewija się spora ilość osób: sekretariat, recepcja, korytarz, sala konferencyjna.
– dostęp do nie zabezpieczonej sieci, w której atakujący może przechwycić dane wysłane do urządzenia drukującego.
W znakomitej większości urządzeń drukujących wystarczy przechwycić plik RAW skierowany do wydruku aby za pomocą oprogramowania rasteryzującego lub identycznego urządzenia zapoznać się z treścią wydruku.
– dostęp do kont użytkownika (boxes) zakładanych na urządzeniu.
Urządzenia MFP/MFD pozwalają na nieskomplikowane zarządzanie użytkownikami poprzez zakładanie im tzw. kont użytkownika (boxes). Brak autoryzacji powoduje iż dowolny inny użytkownik jest w stanie przejrzeć zawartość wskazanego konta, historię wydrukowanych plików, w znakomitej większości również cały bufor wydruku (przechowywany zazwyczaj na dedykowanym HDD)
– dostęp do haseł czy numerów PIN lub kart identyfikacyjnych innych użytkowników.
W przypadku używania kont użytkowników zabezpieczonych jedno lub dwucyfrowym pinem, ogólnie znanym numerem identyfikacyjnym kojarzonym z określoną osobą (PESEL), bardzo łatwo jest podszyć się pod wskazaną osobę, uruchamiając następnie bardziej wymyślne ataki.
– dostęp do skanów wysyłanych na ogólnodostępne foldery wymiany.
Jeden z popularnych błędów – ogólnodostępny folder wymiany (SMB/WIndows Share/FTP)na który wędrują wszystkie skany w myśl zasady ‚ja tak szybciutko, zaraz usunę, nikt się nie zorientuje’. Nasz podsłuchujący, posiadający prawo do odczytu dla wskazanego folderu ma wiele sposobów na skopiowanie zawartości – cyklicznie wykonywany skrypt, element wykorzystujący flagę ‚on folder change’

Równie popularny, oraz bardzo prosty sposób na zablokowanie urządzenia to … próba wykonania kopii banknotu (euro lub dolara). Tajemnicą poliszynela jest, iż urządzenia takie mają wbudowane zabezpieczenia przed zbyt dokładnym kopiowaniem zabronionych dokumentów (do których należą banknoty). W ten sposób głupi pomysł zostawi nam urządzenie zablokowane, często niezdatne do dalszej pracy bez dodatkowych zabiegów ze strony producenta.

Gdy już wiemy na jakie zagrożenia jesteśmy narażeniu postarajmy się zaprojektować bezpieczniejsze środowisko pracy naszych urządzeń drukujących.

Kontrola dostępu do fizycznego urządzenia

– secure room/copy room (Bezpieczne pomieszczenie)

Jeżeli mamy taką możliwość, urządzenia drukujące powinny być odizolowane od osób postronnych (goście, petenci) w postaci wydzielonego pomieszczenia z kontrolą dostępu. Wspomniana wyżej sytuacja, gdzie z racji braków lokalowych urządzenia stoją na korytarzach, są jawnym naruszeniem zasad bezpieczeństwa.

– jedno urządzenie per pomieszczenie zamiast kilku mniejszych.
Popularny mit zwłaszcza w instytucjach jak urzędy państwowe – każdy z urzędników po prostu musi mieć swoją drukarkę. Tymczasem tak naprawdę wystarczy jedno urządzenie sieciowe umieszczone centralnie w pomieszczeniu, tak by nie istniała konieczność porzucenia na pastwę petenta swojego stanowiska pracy. Co w przypadku gdy każdy z urzędników chce mieć swój wzór papieru lub dokumentu? Urządzenie wyposaża się w dodatkowe kasety lub banki papieru, co wciąż jest rozwiązaniem bardziej oszczędnym niż oddzielne urządzenie drukujące.

– blokada fizycznych przycisków i panelu sterującego
Z rozwojem urządzeń drukujących coraz więcej ustawień daje się wprowadzać za pomocą fizycznych przycisków lub paneli. CO więcej, spora część opcji serwisowych z domyślnymi hasłami jest dostępna w ten sposób. Oprócz oczywistych możliwości do zamiany ustawień urządzenia istnieje realne niebezpieczeństwo jego uszkodzenia poprzez ingerencję w parametry serwisowe (jakim są np. temperatury urządzeń utrwalających)

– stworzenie kont użytkownika z uwierzytelnieniem za pomocą kart aktywnych, PIN lub danych z serwera LDAP.
Bardzo przydatna opcja w przypadku gdy chcemy zabezpieczyć się przed nadużyciami lub wprowadzić rozliczenie ilości i jakości wydrukowanych materiałów w podziale na użytkownika czy dział. Dodatkowo, scentralizowana baza danych zabezpieczy nas przed dodatkową pracą utrzymywania i synchronizacji kolejnych baz.
– automatyczne wylogowywanie z nieużywanych profili i kont użytkownika
W przeciwnym wypadku kolejny użytkownik jest niemalże kuszony opcją skorzystania z ustawień poprzednika.

– włączenie opcji „follow me printing”
Bardzo przydatna opcja w przypadku gdy materiały wydrukowane powinny być dostępne TYLKO dla wskazanej osoby. W przypadku skorzystania z tej opcji możemy zrealizować zadanie drukowania bez żadnych dodatkowych ustawień, wydruk zostanie rozpoczęty dopiero po fizycznym uwierzytelnieniu się na wskazanym urządzeniu z puli. Pozwala nam to na zachowanie poufności drukowanych materiałów bez ekspozycji tychże w pojemniku z zakończonymi wydrukami.

Kontrola dostępu do interfejsu sieciowego

– wydzielenie oddzielnego VLAN dla urządzeń drukujących i przyznawanie dostępu ACL na poziomie komputerów lub użytkowników
Jest to chyba podstawowa opcja jaką należy zastosować w celu ochrony drukowanych danych. W połączeniu z serwerami (lub serwerem) wydruku pozwoli nam na zrealizowanie zasad bezpieczeństwa w prostszy sposób:
– dostęp do kolejek drukowania mają tylko uwierzytelnieni klienci
– drukarkami zarządzamy np. za pomocą Active DIrectory – dostęp do nowego urządzenia i jego instalacja wymaga w zasadzie tylko przeładowania profilu.
– serwer wydruku może swobodniej, bez indywidualnych ACL sięgać do interfejsów sieciowych urządzeń drukujących
– dla klientów Windows i Active Directory można zbudować bezpieczniejsze kanały kontaktu z serwerem wydruku (IPSec) co uniemożliwi podsłuch i możliwość przechwycenia i analizy wydruków.

Kontrola i analiza wydruków.
– dodatkowe oprogramowanie
W zależności od stopnia skomplikowania możemy powierzyć zliczanie stron serwerowi wydruku, lub zdecydować się na dodatkowe oprogramowanie. Warto wspomnieć iż większość urządzeń przechowuje informacje o wolumenie wydruku w podziale na użytkowników, jednak przy ich większej ilości niezbędne jest ręczne podsumowanie.
Na korzyść dodatkowego oprogramowania można zaliczyć fakt, iż w odróżnieniu od serwera wydruku, rozliczaniu w podziale na użytkowników podlegają również kopie wykonywane lokalnie na urządzeniu (off the glass), skany i wydruki niestandardowe (bannery, wydruki 2-kolorowe itp.)
Przykładem takiego oprogramowania może być popularny serwer wydruku PaperCut – dostępny również w wersji darmowej dla 15-użytkowników.

Written by marcinbojko

9 września, 2013 at 08:20

Cykl artykułów na blogu AVG – Co musisz wiedzieć o backupie danych? Część 2

Written by marcinbojko

27 czerwca, 2013 at 19:03

Cykl artykułów na blogu AVG – zachęcam do przejrzenia. Część I – Co warto wiedzieć o wykonywaniu kopii zapasowych.

Część I –

Written by marcinbojko

19 czerwca, 2013 at 19:52

SmartArray, CLI, Linux i jak tu zbadać jaki RAID mamy ?

Kiedyś trafiłem na denerwujący problem – mając dostęp tylko do konsoli serwera opartego na Debianie, musiałem zbadać jaki RAID  działa na nim. Serwer oczywiście HP – co niejako pod Linuxem inklinuje użycie drivera CCISS – Dodam że driver zaszyty jest we wszystkich supportowanych przez ejczpi dystrybucjach, oraz wielu nie supportowanych (Debian 5.0 bez żadnego problemu obsługuje starsze SmartArray’e).

Z pomocą przychodzi narzędzie array-info – dostępne razem z driverem cciss – a więc dostępne również w systemie po instalacji tegoż.

Wynik ?

serwer:/dev/cciss# array-info -d /dev/cciss/c0d0 -A
Unknown Controller id 0x409c0e11
Firmware revision : 2.84
Rom revision      : 2.84
1  logical drive configured.
Logical drive  0 :
Fault tolerance : RAID 5
Size            : 271.33 GiB (569018880 blocks of 512 bytes)
Status          : Logical drive is ok
Spare           : Not configured


Written by marcinbojko

7 stycznia, 2011 at 10:20

Napisane w open source

Tagged with , , , , ,

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

14 grudnia, 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

9 listopada, 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:

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

Zapraszam 😉

Written by marcinbojko

28 października, 2010 at 10:35

DRBL – mechanizm klonowania.

Wspominałem wcześniej o jednej z podstawowych funkcjonalności serwerów DRBL – mechaniźmie klonowania stacji roboczych z wykorzystaniem wspólnej pracy Clonezilli i PXE. W skrócie – serwer DRBL zapewnia nam możliwość startu źródłowej stacji roboczej za pomocą PXE, Clonezilla wraz z pakietami towarzyszącymi klonuje zawartość dysków stacji roboczych do plików. Pliki mogą być zapisywane (używając kilku wskazanych metod kompresji) za pomocą SMB/FTP/SSH/NFS lub na lokalnych dyskach. Wspierane filesystemy to min:

  • ext2,
  • ext3,
  • reiserfs,
  • xfs,
  • Jfs
  • FAT16/32,
  • NTFS 3 i 5(streams),
  • HFS+
  • Praca blokowa (block-by-block, sector-by-sector)

Idea ta pozwala na wykonanie jednoczesnych operacji na dowolnej ilości stacji roboczych – co więcej, w zależności od ilości danych i szybkości sieci, samo odtwarzanie/zapisywanie trwa od kilkunastu sekund, do kilkunastu minut.
Wyobrażcie sobie następujące zastosowanie: organizacja, w której wystepuje kilka modeli stacji roboczych. Każda z nich może spełniać inną rolę – od stacji użytkownika wprowadzającego dane po stacje księgujące, graficzne, administracyjne, techniczne – wszystko zależy od zastosowanego profilu oprogramowania lub ustawień systemowych.
Przy każdej awarii lub standaryzacji czeka nas nie lada wyzwanie:

– instalacja OS (często aktywacja ponowna – a więc wyjaśnianie dlaczego właściwie aktywuje się ta kopię po raz kolejny)
– instalacja wszystkich możliwych poprawek, service packów, Support Packów danego producenta itp.
– instalacja niezbędnego oprogramowania
– konfiguracja pod użytkownika

Każdy pracownik działu IT doskonale zna ten schemat. Aby ułatwić sobie życie: wykorzystując DRBL, na jednej ze wskazanych maszyn tworzymy instalację wzorcową (np. OS+poprawki+w miarę stałe ustawienia), resztę doinstalowując za pomocą skryptu z wykorzystaniem wolumenów sieciowych.

Z małą ilością użytkowników (stacje profilowane pod konkretnych userów a nie role) możemy pójśc o krok dalej – przygotowujemy pełny obraz: OS+poprawki+aplikacje+ustawienia charakterystyczne. Czas kompresji i rozmiar pliku wynikowego zależą ściśle od ilościu materiału do kompresji oraz maszyny na jakiej to wykonujemy.

Na szczęście sama dekompresja jest błyskawiczna – mam przygotowane obrazy pod różnych klientów w różnych instytucjach – przeciętny czas odtworzenia stacji roboczej po awarii to około 6 minut (obraz), 2-3 minuty na restart maszyny i dalsza konfiguracja za pomocą skryptu sieciowego – kolejne 3 minuty.

Idąc dalej tym sposobem – o ile jest taka potrzeba, za pomocą mechanizmu WoL możemy zaplanować wykonywanie kopii wskazanych maszyn np. co weekend.

Jak widać w czasie poniżej 15 minut można mieć pełne Disaster Recovery 😉

Co z serwerami zapytacie?
Rewelacyjnie. Wiemy bowiem, iż bez pełnego DR, w środowiskach które nie pracują jako HA – przeważnie posiadając jedną/dwie nie zwirtualizowane maszyny spełniające swoją rolę – metoda ta sprawdza się bardzo dobrze.
Zarówno w środowisku serwerów HP/DELL/IBM oraz innych firm trzecich, przy znikomym nakładzie środków i pracy możemy spokojnie wykonywać kopie OS umieszczane na dyskach macierzowych (SmartArray w HP, ServeRaid w IBM i PERC-H w Dell’u).
Minimalistyczny DR w tego typu maszynach obejmuje:
– konfigurację RAID HW
– odtworzenie OS za pomocą DRBL
– odtworzenie danych dla aplikacji/systemu z backupu.

Dla przykładu: DR zaprojektowany przeze mnie dla 200 maszyn HP DL 380 G4/G5, z Windows 2003, trzema różnymi wolumenami logicznymi (recovery OS), zajmujący około 20GB, odtwarzał się w około 8-9 minut (sieć 1Gb). Synchronizacja partycji z danymi – kolejne 10 minut.

Written by marcinbojko

21 czerwca, 2010 at 07:30

Gdzie jest ta linia ?

Z okazji posiadania pewnej ilości sprzętu pod opieką, miałem ostatnio okazję przeżyć 2 prawie symultaniczne usterki w swoich serwerach. Sam będąc do tej pory przeważnie po drugiej stronie barykady (to mnie wzywano) mogłem sprawdzić jak obecnie wygląda obsługa klienta w standardowym pakiecie gwarancyjnym dla maszyn serwerowych.

Obiekty usterek:

Serwer DELL T300 – problem z kartą DRAC (Dell Remote Access Controller) – brak komunikacji, po restarcie serwera alert o braku tejże karty. Efekt: brak dostępu za pomocą DRAC.

Serwer HP DL380 G5 – uszkodzone 2 redundantne zasilacze (jednocześnie!). Efekt: pomarańczowa dioda na obu i zero możliwości pracy serwera.

Obydwa serwer na standardowej  gwarancji: 3-3-3 (parts-labour-on site)

Sposób zgłoszenia usterki: w obu przypadkach kanał internetowy

Zgłoszenie usterki:

W obu przypadkach wykorzystałem z premedytacją kanał internetowy – nie miałem ochoty przechodzić przez etap infolinii z jej ‚W czym leży problem?”.

W obu firmach należy w pierwszym etapie założyć konto, jeżeli już takowe posiadamy po prostu logujemy się do swoich zasobów.  W przypadku rejestracji mały minus dla Della – po założeniu konta na stronie polskiej parametry logowania nie działały na stronie domyślnej (

Poszukiwanie strony „managera zgłoszeń serwisowych’” jest tak samo uciążliwe w przypadku obu firm, chociaż również minusik dla Della za precyzyjne ukrywanie jakichkolwiek informacji o kontakcie z supportem technicznym. HP ma to dosyć jasno i sprawnie opisane, łącznie z numerami infolinii, Dell jak wspomniałem wymaga dłuższego grzebania i tłumaczenia fraz z ‚polish’ na ‚english’ aby zrozumieć co autor miał na myśli.

  • Parametry

Parametry niezbędne do zarejestrowania zgłoszenia są w miarę podobne, jednakże w przypadku HP musimy precyzyjnie podawać zarówno model jak i S/N maszyny. Z tego co pamiętam ze swojej strony barykady, odnalezienie PartNumberu(Model/Type) maszyny było zawsze problematyczne – działy IT w najlepszym przypadku posiadały w ewidencji sam numer seryjny maszyny. Co prawda są one zapisane na obudowie samej maszyny, aczkolwiek dla osoby nie zaznajomionej ze schematem, może się  okazać że niezbędna jest ponowna wizyta w często odległej serwerowni i doczytywanie znaczków z obudowy.

Dell ma to rozwiązane precyzyjniej – ServiceTag zawiera w sobie jednocześnie model oraz numer seryjny maszyny, co wiąże z łatwym dostępem do informacji o jej konfiguracji. HP po zmianie S/N z 12 na 10 cyfrowe straciło tą umiejętność wprowadzając dodatkowo Model/Typ. Plusik dla Dell’a.

  • Interfejs zgłoszeniowy

Jednym słowem – Dellowy to porażka. Tragicznie wykonany, wolny i zawodny, spowodował iż jedno zgłoszenie musiałem wypełniać 4 razy. Za każdym razem po naciśnięciu „Wyślij„, po długim okresie oczekiwania pojawiał się ten sam komunikat o błędzie w przetwarzaniu zgłoszenia, „spróbuj ponownie za jakiś czas”. Spróbowałem. Efektem było, jak mi później wytłumaczył człowiek z Obsługi Klienta, założenie tylu zgłoszeń ile razy próbowałem wykonać to cholerne ‚Wyślij‚. Ten interfejs i sam mechanizm mogę polecać jedynie wyjątkowym masochistom.

W HP wszystko przebiegło bez problemów.

Obydwie firmy dostają minusik za metody odszukiwania wykonanych zleceń, w HP prawie tragiczne jest to iż trzeba posiadać cały numer RMA zlecenia aby go odnaleźć. Po dłuższym grzebaniu doszedłem w obu interfejsach do punktu gdzie z podstawowymi poleceniami nie miałem już problemów.

  • Pierwszy kontakt

Zdecydowanie Dell – oddzwonił w przeciągu 3 godzin od założenia zlecenia (zlecenie zakładane w okolicach południa). W HP pierwsza reakcja nastąpiła dopiero na drugi dzień.

Kontakt z Dellem nastapił z jawnego numeru telefonicznego człowieka z Obsługi Klienta, HP dzwoniło z tradycyjnie ukrytego profilu, tradycyjnie dla infolinii nazwisko osoby dzwoniącej wyartykułowane na przydechu, tak aby klient przypadkiem nie zapamiętał. Plusik dla Dell’a – mniej bezosobowy kontakt rodzi powoduje nieco lepszą obsługę samego zgłoszenia. Co ciekawe – w Dellu przez cały ciąg procesowy kontaktowała się ze mną JEDNA OKREŚLONA osoba, w HP było to co najmniej 2.



Ponieważ awarie nie są ze sobą równoważne,w  żaden sposób nie można porównywać przypadków na zasadzie: ‚a tutaj więcej pytań więc lepiej’. Przypadek Della i jego karty DRAC był jednak dosyć szczególny.

Po nawiązaniu pierwszego kontaktu, już drogą mailową (ze spersonifikowanego konta doradcy, z imieniem i nazwiskiem)  dostałem dalsze instrukcje postępowania: nieśmiertelny raport DSAT (narzędzie do ściagnięcia i wygenerowania raportu dołączone w postaci linku do strony Della), reset karty, próba aktualizacji BIOS, firmware karty, backboard controllera – tak nam zeszło kolejne 24 godziny. Wszystkie operacje odbywały się albo za pomocą mojego zdalnego dostępu, albo bezpośredniego działania na maszynie fizycznej (ustawianie parametrów karty DRAC możliwe jest tylko po POST maszyny) – swoją droga szkoda że Dell nie posiada takowego narzędzia z poziomu OS, tylko nawet uruchamianie softu lokalnie jest odwoływaniem się do niej via IP.

Po wysłaniu kolejnej porcji wyników testów i spostrzeżeń (wciąż na konto określonego doradcy) otrzymałem tą sama drogą kolejne polecenie – reset NVRAMU serwera oraz NVRAMU karty DRAC (obydwa oddzielne). Tu już byłem leciutko zaniepokojony, zwłaszcza iż drobiazgowy kawałek instrukcji wysłany przez doradcę zakładał fizyczna ingerencję w samą maszynę. Starałem się postawić w sytuacji klasycznego admina – reset NVRAMU na produkcyjnym serwerze mógł mieć nieprzewidziane skutki, a już zupełnie katastrofalne w przypadku niespodziewanego wyczyszczenia danych kontrolera PERC o założonych RAIDach.  Podchwytliwe pytanie do doradcy (swoją droga – nie podejrzewałem Della o takie praktyki, ale niech się facet orientuje) i zapewnienie z jego strony że czyszczenie NVRAMU nie usuwa informacji z kontrolera PERC.

Okej, bawimy się dalej. Zabawa w przestawianie zworki, 20 sekund, powrót, wejście do konsoli DRAC, reset do ustawień domyślnych.

Nic … dalej to samo …

Ostatnia wskazówka ze strony Dell – proszę sprawdzić czy podpięcie bezpośrednio do złącza DRAC z laptopem coś da. Ano dało – czystą i stabilną konekcję. Cóż nam jednak po tym skoro dalej w sieci interfejsu nie widać?

Ostatecznie problem zakończył się zmianą IP’ka karty na nieco inny niż chcieliśmy, aczkolwiek we wskazanej przez nas podsieci DRAC działać nie chciał. Żadne z nas nie wie dlaczego – ani DHPC, ani static nie rozwiązywały problemów. Na tym etapie postanowiłem zgłoszenie w Dellu zamknąć – dostałem podziękowanie za uwagę i voila … koniec.

Wniosek z sytuacji był następujący: fajnie że ktoś wdraża system utartej ścieżki, bardzo rzadko zdarzają się nieoczywiste sytuacje, które jeszcze nie istnieją w bazie rozwiązań. Świetnie że ktoś stara się rozwiązać problem myślowo, zanim wyśle ekipę silnorękich, której utrzymanie i wyjazd  przecież kosztują 😉 Super …. aczkolwiek ten mały posmak ‚weź se pan rozkręć serwer i se pan zresetuj’ pozostaje 😦

Czy jestem niezadowolony? Nie, absolutnie nie. Personalizacja doradcy, ludzki kontakt, nie wymądrzanie się wiedzą tajemną – to były atuty które spowodowały że bez większego zamieszania sprawa szła do przodu. Jednak, patrząc na to z perspektywy admina, na widoczne problemy w logach (znikająca karta) i wymogów technicznych jakie stawiano Zgłaszającemu rodzi się pytanie ‚ Czy nasi bracia w rozumie, po drugiej stronie Oceanu również są tak szczegółowo czołgani, czy też wystarczy krótki telefon na ServiceLine i oświadczenie ‚Ja się nie dotykam, przyjeźdżajcie ;)’?


Dziwne uszkodzenie –  2 zasilacze na raz. UPS do którego były podłączone nie zanotował żadnych wydarzeń związanych z brakiem czy nadmiarem zasilania – ot …. wzięło się i popsuło.

Jak mówiłem HP zareagowało mniej więcej po 12 godzinach od zgłoszenia (w porównaniu z 3 od Della) – już 12h maszyna produkcyjna (serwer plików w średniej firmie) nie działa. Anonimowy telefon (unknown), równie anonimowy doradca przedstawiający się na przydechu i pytanie „Co się stało…”. Korciło mnie aby w amerykańskim stylu odpowiedzieć ‚Coś mi nie działa …”. Na spokojnie jednak podałem problem, oczywiście usłyszałem nieśmiertelne pytania o kolory diodek (amber), czy jestem pewny że w okolicy nie wywaliło jeszcze co najmniej 20 bezpieczników i 70 UPS’ów, oraz czy aby NA PEWNO jest podpięty UPS i czy mógłbym go ominąć i podpiąć kable zasilające bezpośrednio do sieci.

No mógłbym, chociaż efekt znałem od razu. ‚Okej, to my oddzwonimy…’. Super. Czekam.

Za godzinę zadzwonił już inny kolega pytając czy wiem co to jest program CRU (Customer Replaceable Unit) i czy potwierdzam adres wysyłki. Jasne, wiem, program oszczędzania kasy po stronie HP – zamiast wysyłać serwisanta wysyła się same części licząc że proste wymiany – hot plugowy zasilacz czy dysk da radę wymienić nawet Główny Księgowy 😉 Okej, potwierdziłem adres, dostałem kolejne pytanie czy ROZUMIEM że uszkodzone części mam odesłać na koszt HP do magazynu serwisowego i czy aby na pewno to zrobię, po czym padło nieśmiertelne ‚To ja wystawiam zlecenie do logistyki’.

Dlaczego nieśmiertelne? Ano dlatego zgłoszeń elementów CRU to ja wykonałem dziesiątki i na palcach jednej ręki pijanego drwala mogę policzyć przypadki kiedy części był już na DRUGI dzień. Zazwyczaj tejże logistyce zajmowało to coś koło 36 h najbidniej.

Tu jednak zostałem mile zaskoczony – na drugi dzień koło g. 14 zjawił się kurier z paczuszką od EjczPi, która o dziwo zawierała dwa zasilacze do DL380G5. O dziwo (x2) zadziałały 😉

Wysyłka zwrotna uszkodzonych części poszła dnia następnego, co zupełnie nie przeszkodziło w dzień kolejny zadzwonić do mnie trzeciej z kolei osobie pytając czy NA PEWNO odesłałem części. Odesłałem. Słowo.

Przypadek prosty, niemal banalny – z wyjątkiem zaskoczenia ‚dlaczego dwa na raz?’ W którym z dialogów udało mi się wydusić od doradcy iż problem jest znany i opublikowany w którymś z ‚Service Advisory’. Fajnie, tylko od czasu jak EjczPi w trybie natychmiastowym wywaliło z OARS’a wszystkie ciekawsze dane serwisowe, pozostawiając prosty chłam na bazie zdjątek i parametrów, jakiekolwiek poszukiwania czegoś innego niż CaseStudy i WhitePapers stało się koszmarem.

Tyle z zabawy z serwerami 😉

Edit: O dziwo, Dilbert się ze mną zgadza – akurat zamieszczając bardzo dobry komentarz 😉

Written by marcinbojko

3 Maj, 2010 at 19:04

Napisane w Uncategorized

Tagged with , , ,

Serwery – co potrzebujemy…

Wpis wyewoluował bezpośrednio z wątku o serwerach: 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 😉

Written by marcinbojko

22 października, 2009 at 20:32

Napisane w Uncategorized

Tagged with , , , , ,

%d blogerów lubi to: