Sunday, November 30, 2014

Proces nr 1 systemu Linux - systemd

Od ponad 18 lat procesem nr 1 w systemie GNU/Linux jest init, którego obecnie zastąpić ma niejaki systemd. Zmiana tego procesu wywołuje znaczną różnice w korzystaniu z systemu Linux. Zapewne to jest powodem tego, iż wielu użytkowników system Linux znienawidziło go oraz jego autora. W tym tekście postaram się wyjaśnić jaki jest cel wymiany procesu init na systemd oraz co z tego wynika.

Otóż po załadowaniu jądra do pamięci musi zostać uruchomiony jakiś program aby coś robić. W Linuksie pierwszym procesem, który może, a nawet musi uruchomić inne procesy - głównie powłokę - jest init. Gdyby w procesie uruchamiania systemu nie została uruchomiona powłoka poprzez proces login to niemożna byłoby w żaden sposób sterować systemem - chyba, że zostanie uruchomiona usługa SSH. Jak widać pierwszy proces pełni bardzo ważną rolę w systemie i co najważniejsze działa najdłużej w systemie - w sensie czasu, a nie czasu zużycia procesora. Tak więc nie dość, że init jest pierwszym procesem, który zostaje uruchomiony i ostatnim, który jest zamykany to wszystkie pozostałe procesy w systemie są mu podrzędne w hierarchii procesów. Oczywiście nadal można oderwać się poprzez podwójnego forka, ale to już inny temat. Chodzi o to, że proces init będąc rodzicem wszystkich usług system może wykonywać prace, których nie mógłby wykonywać żaden inny proces - jest tylko jeden taki proces - jest nim proces nr 1.

Chodzi o to, że 20 lat temu wymyślono proces init, który był uruchamiany przez jądro, następnie sam odpalał skrypty z lokalizacji /etc/init.d/ i na tym jego praca się "kończyła" - mimo iż działa nadal. Przez wiele lat to wystarczało i nikt nawet nie myślał to zmieniać. Więc dlaczego dziś musimy to zmieniać?

Więc, po pierwsze to wcale nie musimy tego robić, ale obecnie system Linux używany jest do wielu różnych zadań, a jego jądro jest wyposażone w wiele mechanizmów, których wcześniej nie było. Taka kombinacja nowych możliwości i potrzeb zainicjowała poszukiwanie nowych sposobów na usprawnienie systemu. W systemie Linux bardzo często pewne jego części są przepisywane w całości na nowo, to się dzieje cały czas, tylko nie wszystkie te zmiany są widoczne gołym okiem. Z procesem init jest inaczej - dostrzeżono jego potencjał, który może rozwiązać problemy do tej pory nierozwiązane i zdecydowano się to zrobić. Mało tego, wymyślono nowe sposoby wykorzystywania pierwszego procesu i wszystkie te pomysły wcielono do systemd. Wielu uważa, że są to durne pomysły i krytykuje je, ale co ciekawe to tak naprawdę to wszystkie one wcale nie są nowe. Gdyby dokładnie to przeanalizować to okazałoby się że większość z nich doczekała się swojej implementacji w jakiś sposób. Tu różnica polega na tym, że zrobiono to kompleksowo i centralnie. Mało tego, systemd nie jest wcale pierwszy i nie mam tu na myśli Upstart lecz launchd.

Launchd to zamiennik procesu init w systemie Mac OS X, okazał się sukcesem i ktoś po prostu postanowił zrobić to samo w systemie Linux - w wyniku czego został skrytykowany - własnie tak. Jednak krytyka z czasem milknie i największe dystrybucje zaczynają wdrażać nową implementację procesy init - czyli systemd. Launchd nie miał być tylko lepszą wersją pierwszego procesu, lecz całym framework-iem służącym do zarządzania usługami. Tak też zbudowany jest systemd. Systemd to nie jeden demon lecz wiele demonów, dlatego, że koncepcja systemd obejmuje zastąpienie innych demonów takich jak inetd, acpid, udev, syslog, watchdog, cron i atd. Z pomysłu rozbudowania procesu init powstała całą warstwa, która oddzielała jądro od userlandu, i tak należy traktować systemd. Poniższy schemat obrazuje jak wiele elementów system zostało wcielone do tej warstwy.

Architektura systemd - Wikipedia
Systemd to pierwszy krok do podziału demonów na te służące do zarządzania systemem i te oferujące usługi systemowe, takie jak poczta, www itp.. Nawet proces logowania i sesji będzie realizowany w ramach frameworku systemd. Wcześniej pisałem o podwójnym forku, otóż systemd maksymalnie używa mechanizmu cgroups, który uniemożliwia dla uruchamianych procesów ucieczkę od rodzica, a tym samym brak kontroli nad takim procesem. W systemd poszczególne grupy cgroups nazywane są odcinkami (ang. slice) i możemy zobaczyć ich podział chociażby wydając poniższe polecenie.

ps xaf -eo pid,user,args,cgroup

Zabawne, bo podstawową cechą systemd miała być szybkość uruchamiania. Mimo. iż osiągnięto to poprzez mechanizm jednoczesnego uruchamiania usług, to nie ta cecha jest najbardziej widoczną dla użytkowników. Wręcz przeciwnie, jest to jedna z tych zmian, które nie są widoczne gołym okiem. Nie znaczy to, że system wcale nie uruchamia się szybciej dzięki systemd, bo to możemy dokładnie sprawdzić i przeanalizować wydając poniższe polecenie.

systemd-analyze plot> s.svg

Wynikiem jego działania będzie schemat w postaci obrazu, który przedstawia analizę procesu botowania.
Warto tu króciutko wspomnieć ja osiągnięto taki efekt, ale ważniejsze jest w tym to jakie dodatkowe możliwości daje systemd dla usług. Otóż kluczem do uruchamiania wielu usług jednocześnie jest to, że systemd tworzy sockety np. typu AF_INET dla swoich usług, następnie uruchamia te usługi. Jednak już w tym czasie inne usługi (np. B), które również zostały uruchomione ale potrzebują tej pierwszej (np. A) mogą normalnie startować, ponieważ poprzez dostępny socket usługi A myślą, że ta usługa już jest dostępna, podczas gdy tak naprawdę to systemd przetrzymuje w swojej kolejce wszystkie pakiety, które zostały wysłane do tego socketu i przekaże je do jeszcze uruchamianej usługi A, gdy ta zakończy swoje uruchamianie. Efekt będzie taki, że usługa B będzie już gotowa do działania ale brakuje jej jeszcze tylko odpowiedzi od usługi A, czyli ubocznym efektem będzie długi czas oczekiwania, co nie znaczy, że w ostatecznym rozrachunku i tak wszystkie usługi uruchomią się szybciej.
Teraz warto wspomnieć co z tego wynika. Wcześniej jeszcze tylko dodam, że koncepcja centralnego demona zarządzającego socketami to nic innego niż stary inetd. Ale powodem, dla którego komercyjne dystrybucje klasy enterprise wprowadziły systemd jest to, że dzięki takiej centralizacji wykonanej w pierwszym procesie teraz możemy zresetować serwer Apache bez utraty nawiązanych sesji np. https. Mało tego dzięki integracji demona D-Bus z systemd proces, który się zawiesi może automatycznie zostać zrestartowany.

Ciekawą sprawą jest też to, że w systemd nie tylko sockety AF_INET zostały zrównoleglone, ale zrobiono to również z socketami D-Bus (AF_UNIX), a nawet z systemem plików. O systemd można napisać jeszcze bardzo dużo, ale w tym tekście chciałem przekazać ogólną koncepcję, którą realizuje ten projekt.

Więcej informacji:
- Rethinking PID 1
- Wykipedia - systemd
Why systemd?
Here We Go Again, Another Linux Init: Intro to systemd
Understanding and Using Systemd
Intro to Systemd Runlevels and Service Management Commands


Sunday, November 16, 2014

Debian LTS - przedłużone wsparcie dla poprawek bezpieczeństwa

Parę miesięcy temu zakończył się okres wsparcia poprawek bezpieczeństwa dla systemu Debian 6 Squeeze, co wielu użytkowników bardzo martwi, zwłaszcza tych, którzy używają system w firmach i instytucjach. Debian należy do bardzo popularnych dystrybucji wybieranych przez wielu największych graczy w świeci sieciowych usług, np. hostingi.

Niestety świat idzie szybko do przodu i stara polityka systemu Debian zaczyna niektórych irytować. Mniej więcej rok temu oraz mniej więcej rok przed zakończeniem wsparcia łatek bezpieczeństwa dla Debian Squeeze (czyli w czasie wydania nowej wersji stabilnej Debian 7 Wheezy) jeden z większych hostingów [1] oświadczył, iż zamierza porzucić Debiana przez krótki okres wsparcia łatek bezpieczeństwa. Wieść ta wywołała długą dyskusję wśród developerów Debiana [2], której wynikiem było wprowadzenie inicjatywy dłuższego wsparcia zwanej Debian LTS (Long Term Support) [3].

Z jednej strony to dobra wiadomość ale z drugiej Ubuntu oraz CentOS od dawna posiadają wersje LTS swoich dystrybucji. Jednak między Debianem a wymienionymi dystrybucjami istnieje zasadnicza różnica. Debian jest w pełni projektem społecznościowym, natomiast ze Ubuntu LTS stoi Canonical, a CentOS pobiera łatki z FTP RedHat. Jak widać posiadanie wersji LTS to wspólna cecha dystrybucji oferowanych w modelu enterprise, czyli dla biznesu.

Mimo to deweloperzy Debiana podjęli wyzwanie i od paru miesięcy możemy dodać nowe repozytoria dla wersji 6 (oldstable), aby pobierać nadal łatki bezpieczeństwa po oficjalnym wsparciu:

deb http://http.debian.net/debian/ squeeze-lts main contrib non-free 
deb-src http://http.debian.net/debian/ squeeze-lts main contrib non-free

Projekt LTS rozszerza standardowe wsparcie oferowane przez zespół deweloperów Debiana o dwa lata. Oznacza to, że dzięki tej inicjatywie Debian będzie oferował w sumie 5-cio letnie wsparcie dla łatek bezpieczeństwa. Harmonogram dostępny jest na poniższej stronie [4].

Na tym można by zakończyć i cieszyć się z nowości jaką jest wsparcie LTS w Debianie, ale projekt ten dopiero raczkuje i daleko mu do swoich konkurentów. Otóż na jego realizacje potrzebne są pieniądze, bo jak stwierdzili deweloperzy nie ma co się okłamywać, że w naszym ekonomicznym świecie każdy musi z czegoś żyć. Na dzień dzisiejszy projekt LTS ma kilku sponsorów, których dotacje wystarczają zaledwie na ok 25% potrzeb. Co to oznacza, a no to, że na niektóre łatki bezpieczeństwa w tej chwili trzeba trochę poczekać, ponieważ jest więcej pracy niż pieniędzy (błędy, które nie zostały jeszcze poprawione [5]).

Powstaje więc pytanie, czy Projekt Debiana LTS poradzi sobie ze wyzwaniem, zanim inni zaczną przechodzić na Ubuntu LTS tak jak DreamHost? Czy w czasach, w których system GNU/Linux coraz bardziej asymiluje się ze światem biznesu całkowicie społeczna dystrybucja pozbawiona komercyjnego wsparcia nadąży za konkurencją? Czas pokaże.

[1] http://www.dreamhost.com/dreamscape/2013/06/03/change-is-in-the-air-dreamhost-upgrades/
[2] https://lists.debian.org/debian-devel/2013/08/msg00346.html
[3] https://wiki.debian.org/LTS
[4] http://www.freexian.com/services/debian-lts.html
[5] http://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?revision=HEAD&view=co

Thursday, November 13, 2014

SELinux - rozwalające porady

To nic nowego, że w internecie najwięcej porad o SELinux dotyczy jego wyłączenia. Również prezentacje typu ~"Przestańcie wyłączać SELinux" itp. były na porządku dziennym. Red Hat próbuje walczyć z tym, a sposób po jaki już sięgnął nie powstrzymał mnie od napisania tego wpisu - bo już nie wytrzymam :] Zanim zaprezentuje perełki tego tematu słowo wstępu.

Zapewne spotkaliście się z 'wyznawcami' najsłuszniejszego systemu jakim jest GNU/Linux, jaki to on jest bezpieczny itp. oraz z ich przeciwnikami, którzy często podają przykłady typu "gdyby był taki bezpieczny to nie włamali byś się do ..." itp.

Teraz przedstawię genezę jak dochodzi do włamań w najbezpieczniejszym systemie świata :)

Zapewne słyszeliście o tym, że w GNU/Linux konkretną rzecz można zrobić na wiele sposobów (w końcu o co Linuksiarze kłóciliby się ze sobą!). Oto 4 efektywne sposoby na wyłączenie SELinux.


Nikt teraz nie powie, że Linuksa nie można przystosować do swoich potrzeb. Do każdego gustu znajdzie się metoda na to :)

Wracając do tematu, znacie taką firmę IBM, tak, tak, to ta co promuje Linuksa i rozwiązania otwarte. Oferują również świetną dokumentację do swoich produktów, np. jak zainstalować na wirtualnej maszynie RHEL.


Oczywiście instalacja nie mogłaby się powieść bez ptk. 8


Tak zainstalowany system można z powodzeniem zaoferować klientom :)

Skoro jesteśmy przy temacie RHEL, słyszeliście o takim oprogramowaniu cPanel do zarządzania hostingiem - działa głównie na RHEL. Otóż oni też wiedzą jak dobrze postawić swój produkt na 'relku' - najbardziej podoba mi się tytuł podręcznika instalacyjnego - "Installation Guide - Disable SELinux".


Warto zwrócić uwagę na pogrubione stwierdzenie, że do instalacji niezbędne jest wyłączenie SELinux. Nie ma co się dziwić, przecież nie napiszą do swojego produktu (najlepszy ponoć) polityki, nie!

Dan Walsh chyba się załamał bo sięgnął już po metodę jaką jest kolorowanka dla "dzieci" :) Proszę Państwa przedstawiam SELINUX COLORING BOOK.


Książka powstała aby pomóc zrozumieć jak działa SELinux.

Wyjaśniono w niej, iż są procesy różnego typu (kotek i piesek).

Oraz, iż istnieją obiekty różnego typu (jedzenie dla kotka i pieska).


W końcu, wyjaśniono na czym polega mechanizm wymuszanie typów (piesek nie może jeść karmy dla kotka, system go powstrzyma).


Piesek może jeść tylko jedzenie przeznaczone dla niego.
I tak sprawy się mają z bezpieczeństwem w GNU/Linux - miłego kolorowania.

Saturday, November 8, 2014

Debian Squeeze bug 668174 with SELinux - workaround for this problem

Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668174

I use Debian Squeeze on server and want set permissive mode from some domain.
In newer version policycoreutils this bug is repaired, but in Debian Squeeze max version is 2.0.82-3.

So I change code in two place:


1. Problem with '/var/lib/selinux'

semanage permissive -a smbd_t
Traceback (most recent call last):
  File "/usr/sbin/semanage", line 460, in <module>
    process_args(sys.argv[1:])
  File "/usr/sbin/semanage", line 363, in process_args
    OBJECT.add(target)
  File "/usr/lib/pymodules/python2.6/seobject.py", line 275, in add
    os.chdir(dirname)
OSError: [Errno 2] No such file or directory: '/var/lib/selinux'


Change:

head -n 280 /usr/lib/pymodules/python2.6/seobject.py|tail -n 10
    def add(self, type):
               import glob
               name = "permissive_%s" % type
               #dirname = "/var/lib/selinux"
               dirname = "/usr/share/selinux"
               os.chdir(dirname)
               filename = "%s.te" % name
               modtxt = """
module %s 1.0;



2. Problem with '/usr/share/selinux/devel/'

semanage permissive -a smbd_t
Traceback (most recent call last):
  File "/usr/sbin/semanage", line 460, in <module>
    process_args(sys.argv[1:])
  File "/usr/sbin/semanage", line 363, in process_args
    OBJECT.add(target)
  File "/usr/lib/pymodules/python2.6/seobject.py", line 291, in add
    mc.create_module_package(filename, 1)
  File "/usr/lib/pymodules/python2.6/sepolgen/module.py", line 172, in create_module_package
    self.refpol_build(sourcename)
  File "/usr/lib/pymodules/python2.6/sepolgen/module.py", line 186, in refpol_build
    raise RuntimeError("compilation failed:\n%s" % self.last_output)
RuntimeError: compilation failed:
make: /usr/share/selinux/devel/Makefile: Nie ma takiego pliku ani katalogu
make: *** Brak reguł do wykonania obiektu `/usr/share/selinux/devel/Makefile'. Stop.


Change:

 head -n 128 /usr/lib/pymodules/python2.6/sepolgen/module.py |tail -n 10
        self.checkmodule = "/usr/bin/checkmodule"
        self.semodule_package = "/usr/bin/semodule_package"
        self.output = output
        self.last_output = ""
        #self.refpol_makefile = "/usr/share/selinux/devel/Makefile"
        self.refpol_makefile = "/usr/share/selinux/default/include/Makefile"
        self.make = "/usr/bin/make"

    def o(self, str):
        if self.output:



This is works for me :)

Friday, October 10, 2014

Migration old system from single disk to mirrored LVM volume

Last time I create procedure how to convert standalone system (install on the single disk without any replication) to LVM volume with replication on two hard drive. I can't found in Internet how do this, so I decided published this on my blog.

Scenario
I have old server installed on one hard drive, without hardware/software RAID and without LVM - summarizing without any protection for system files. I would like to protect this system from disk hardware damages. How? I want implement LVM volume, exactly mirror volume. Now I have one hard drive for system, I need a second hard drive. With two hard drive we can create mirrored LVM logical volume.

Convertion single disk to LVM mirrored volume.

Of course I would like to do this migration in the most possible easy way and which not taking too long. All procedure which it I presented here I doing in the test installation system on virtual environment (KVM) using Debian distribution.

Main problem
The biggest problem in this migration process is the low capabilities between GRUB bootloader and LVM volumes format. Of course GRUB have "lvm" module and LVM developers work to LVM more compatible with GRUB, but today GRUB can't start from e.g. LVM raid1 volume, so we must use mirrored volume.

Our main goals is to creating replication system from standalone (single disk) system.

LVM migration procedure
So we have system installed on single disk 2GB and this installation using only one partition for all system points e.g. /home, /var.

root@host1:~# df -h
Filesystem                                              Size  Used Avail Use% Mounted on
rootfs                                                  2.0G  593M  1.3G  31% /
udev                                                     10M     0   10M   0% /dev
tmpfs                                                    49M  180K   49M   1% /run
/dev/disk/by-uuid/993c1a89-40b6-456a-8478-d1c2915782fd  2.0G  593M  1.3G  31% /
tmpfs                                                   5.0M     0  5.0M   0% /run/lock
tmpfs                                                    97M     0   97M   0% /run/shm

System is installed on vda, second disk (clear by writes zero) is vdb. Disk vda has DOS partition table and one primary partitions vda1. GRUB bootloader is installed on vda in MBR.

root@host1:~# fdisk /dev/vda

Command (m for help): p

Disk /dev/vda: 2147 MB, 2147483648 bytes
244 heads, 47 sectors/track, 365 cylinders, total 4194304 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000b7ab3

   Device Boot      Start         End      Blocks   Id  System
/dev/vda1   *        2048     4192255     2095104   83  Linux

Command (m for help): q

Before we start move the old system (vda) to the new second disk (vdb) we must reconstruct structure of original disk (vda). Intention, on this is only creates the same type and count partitions, but not size of specific partitions.

In this particular examples we have 2GB partition, but we can create more or less capacity partition. Because I want continue to use old disk (vda) with new bigger disk (vdb has 3GB) in mirror, I can't create greater partition in vdb than has vda, because in vda can fit only <= 2GB mirror images (both images of mirror must by the same size). Furthermore LVM to create mirrored volume require small amount of free space.

So, for this reason we create smallest partitions that has vda < 2GB, exactly 1990MB.

root@host1:~# fdisk /dev/vdb
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel with disk identifier 0xbb09b322.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.

Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): p

Disk /dev/vdb: 3221 MB, 3221225472 bytes
16 heads, 63 sectors/track, 6241 cylinders, total 6291456 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xbb09b322

   Device Boot      Start         End      Blocks   Id  System

Command (m for help): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p): p
Partition number (1-4, default 1):
Using default value 1
First sector (2048-6291455, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-6291455, default 6291455): +1990M

Command (m for help): t
Selected partition 1
Hex code (type L to list codes): L

 0  Empty           24  NEC DOS         81  Minix / old Lin bf  Solaris        
 1  FAT12           27  Hidden NTFS Win 82  Linux swap / So c1  DRDOS/sec (FAT-
 2  XENIX root      39  Plan 9          83  Linux           c4  DRDOS/sec (FAT-
 3  XENIX usr       3c  PartitionMagic  84  OS/2 hidden C:  c6  DRDOS/sec (FAT-
 4  FAT16 <32M      40  Venix 80286     85  Linux extended  c7  Syrinx         
 5  Extended        41  PPC PReP Boot   86  NTFS volume set da  Non-FS data    
 6  FAT16           42  SFS             87  NTFS volume set db  CP/M / CTOS / .
 7  HPFS/NTFS/exFAT 4d  QNX4.x          88  Linux plaintext de  Dell Utility   
 8  AIX             4e  QNX4.x 2nd part 8e  Linux LVM       df  BootIt         
 9  AIX bootable    4f  QNX4.x 3rd part 93  Amoeba          e1  DOS access     
 a  OS/2 Boot Manag 50  OnTrack DM      94  Amoeba BBT      e3  DOS R/O        
 b  W95 FAT32       51  OnTrack DM6 Aux 9f  BSD/OS          e4  SpeedStor      
 c  W95 FAT32 (LBA) 52  CP/M            a0  IBM Thinkpad hi eb  BeOS fs        
 e  W95 FAT16 (LBA) 53  OnTrack DM6 Aux a5  FreeBSD         ee  GPT            
 f  W95 Ext'd (LBA) 54  OnTrackDM6      a6  OpenBSD         ef  EFI (FAT-12/16/
10  OPUS            55  EZ-Drive        a7  NeXTSTEP        f0  Linux/PA-RISC b
11  Hidden FAT12    56  Golden Bow      a8  Darwin UFS      f1  SpeedStor      
12  Compaq diagnost 5c  Priam Edisk     a9  NetBSD          f4  SpeedStor      
14  Hidden FAT16 <3 61  SpeedStor       ab  Darwin boot     f2  DOS secondary  
16  Hidden FAT16    63  GNU HURD or Sys af  HFS / HFS+      fb  VMware VMFS    
17  Hidden HPFS/NTF 64  Novell Netware  b7  BSDI fs         fc  VMware VMKCORE 
18  AST SmartSleep  65  Novell Netware  b8  BSDI swap       fd  Linux raid auto
1b  Hidden W95 FAT3 70  DiskSecure Mult bb  Boot Wizard hid fe  LANstep        
1c  Hidden W95 FAT3 75  PC/IX           be  Solaris boot    ff  BBT            
1e  Hidden W95 FAT1 80  Old Minix  
Hex code (type L to list codes): 8e
Changed system type of partition 1 to 8e (Linux LVM)

Command (m for help): p

Disk /dev/vdb: 3221 MB, 3221225472 bytes
16 heads, 63 sectors/track, 6241 cylinders, total 6291456 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xbb09b322

   Device Boot      Start         End      Blocks   Id  System
/dev/vdb1            2048     4077567     2037760   8e  Linux LVM

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

In contrast to vda, vdb has different type of partition - "Linux LVM". Before we can copy system to the new disk with LVM volume we must create PV, VG and LV on vdb1 (if you don't know what it is you must read the LVM documentation).

Now we can create a normal LVM volume, but before this first we must install LVM.

root@host1:~# aptitude install lvm2

root@host1:~# pvcreate /dev/vdb1
  Writing physical volume data to disk "/dev/vdb1"
  Physical volume "/dev/vdb1" successfully created
root@host1:~# vgcreate system /dev/vdb1
  Volume group "system" successfully created
root@host1:~# lvcreate -n rootfs -L 1900MB system
  Logical volume "rootfs" created
root@host1:~# lvs -a
  LV     VG     Attr     LSize Pool Origin Data%  Move Log Copy%  Convert
  rootfs system -wi-a--- 1.86g                                           

Now we got LVM volume and we can create the file system on this volume.

root@host1:~# mkfs.ext4 /dev/system/rootfs 

In this point we have all we need to start copy system files to the new partition. But as you know you can't copy from the mounted system, so we must run server from another system. For this goal we use SystemRescueCd. SystemRescueCd has the advantage of it has built in LVM supports. 

But before we start copy system files, first we do other things which minimize counts of server restart. Now we create the new GRUB menu entry which allows boot our system from vdb1 (VG system, LV rootfs). Please note that boot the bootloadrer installed in vda will boot system storage in vdb (LVM volume). We don't have there system yet, but first we creates this entry in GRUB menu.

root@host1:~# blkid /dev/system/rootfs
/dev/system/rootfs: UUID="7fa359c8-6bde-4ecd-835b-2f753fd16a49" TYPE="ext4"
root@host1:~# vim /boot/grub/grub.cfg 

Add new menu entry to GRUB
You must copy the first menu entry and changes the four things:

  1. add load LVM module ('insmod lvm') before load DOS partition
  2. change 'set root' value to LVM style: 'system-rootfs'
  3. update UUID in command 'search' on '--set' parameter
  4. change is in 'linux' command, the 'root' parameter - also must write to LVM style: '/dev/mapper/system-rootfs'.

Of course this value depends of how you name your LVM groups nad volumes, in this cases it is 'system' and 'rootfs'. The last thing you need to do now is change the name of menu entry e.g. append " LVM".

Now we can back to the copy system files process.

First we must boot our server from CD/DVD and choose default boot options. SystemRescueCd automation scans available drive to LVM metadata, but I do this manually to show that system detect our VG.
Next step we mount both partitions vda1 and vdb1, and copy all system files from it to new LVM volume.

Run server from SystemRescueCd and work on LVM volume. 
After we copy system files to the new volume we can boot our system from it. So reboot Live system and this time select from menu options 'Run from first hard drive' then we see our new entry in GRUB menu.

Boot system from vdb using bootloader on vda.
Now we boot our system from the new copy and you can see different root system file mount point.

root@host1:~# df -hT
Filesystem                Type      Size  Used Avail Use% Mounted on
rootfs                    rootfs    1.9G  596M  1.2G  34% /
udev                      devtmpfs   10M     0   10M   0% /dev
tmpfs                     tmpfs      49M  188K   49M   1% /run
/dev/mapper/system-rootfs ext4      1.9G  596M  1.2G  34% /
tmpfs                     tmpfs     5.0M     0  5.0M   0% /run/lock
tmpfs                     tmpfs      97M     0   97M   0% /run/shm

root@host1:~# lvs -a -o +devices
  LV     VG     Attr     LSize Pool Origin Data%  Move Log Copy%  Convert Devices 
  rootfs system -wi-ao-- 1.86g                                            /dev/vdb1(0)

To have a complete system on our new hard drive with LVM volume yet we miss only bootloader on this disk. So now we install GRUB on the new disk (vdb).

root@host1:~# grub-install /dev/vdb
/usr/sbin/grub-probe: error: no such disk.
Auto-detection of a filesystem of /dev/mapper/system-rootfs failed.
Try with --recheck.
If the problem persists please report this together with the output of "/usr/sbin/grub-probe --device-map="/boot/grub/device.map" --target=fs -v /boot/grub" to <bug-grub@gnu.org>
root@host1:~# grub-install --recheck /dev/vdb
Installation finished. No error reported.

I have done yet command 'update-grub' but this is not necessary, even unnecessary!

root@host1:~# update-grub
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-3.2.0-4-amd64
Found initrd image: /boot/initrd.img-3.2.0-4-amd64
Found Debian GNU/Linux (7.4) on /dev/vda1
done

Ok, from this moment we have all completed system with bootloader in new disk, totally independent from original hard drive. In this moment we finished the migration process to LVM. Now we start new process - convert normal LVM volume to mirrored LVM volume.
But first, it is the good moment to check if all service in system work properly, in particular if this is a productions server. You can now reboot system from new disk and try boot them from new disk (vdb).

Boot from new disk.
Bootloadre in new disk.

If all work properly on new disk, then you can go to the next step witch is destroy original disk - yes we need second disk to create LVM mirror volume. For this goal we delete existing data and partition on vda.

root@host1:~# fdisk /dev/vda

Command (m for help): p

Disk /dev/vda: 2147 MB, 2147483648 bytes
244 heads, 47 sectors/track, 365 cylinders, total 4194304 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000b7ab3

   Device Boot      Start         End      Blocks   Id  System
/dev/vda1   *        2048     4192255     2095104   83  Linux

Command (m for help): d
Selected partition 1

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.
root@host1:~# fdisk /dev/vda

Command (m for help): p

Disk /dev/vda: 2147 MB, 2147483648 bytes
16 heads, 63 sectors/track, 4161 cylinders, total 4194304 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000b7ab3

   Device Boot      Start         End      Blocks   Id  System

Command (m for help): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p): p
Partition number (1-4, default 1):
Using default value 1
First sector (2048-4194303, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-4194303, default 4194303):
Using default value 4194303

Command (m for help): t
Selected partition 1
Hex code (type L to list codes): 8e
Changed system type of partition 1 to 8e (Linux LVM)

Command (m for help): p

Disk /dev/vda: 2147 MB, 2147483648 bytes
16 heads, 63 sectors/track, 4161 cylinders, total 4194304 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000b7ab3

   Device Boot      Start         End      Blocks   Id  System
/dev/vda1            2048     4194303     2096128   8e  Linux LVM

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

Next we create identical LVM structure on vda like we have on vdb - first create the new PV, extend VG (system) for new PV (vda1) and last convert exist LV volume (rootfs) to the mirrored volume. LVM automatically use new free PV (vda1) from 'system' VG.

root@host1:~# pvcreate /dev/vda1
  Writing physical volume data to disk "/dev/vda1"
  Physical volume "/dev/vda1" successfully created
root@host1:~# vgextend system /dev/vda1
  Volume group "system" successfully extended

root@host1:~# vgs -a -o +devices
  VG     #PV #LV #SN Attr   VSize VFree Devices    
  system   2   1   0 wz--n- 3.94g 2.08g /dev/vdb1(0)
root@host1:~# pvs -a
  PV         VG     Fmt  Attr PSize PFree
  /dev/root              ---     0      0
  /dev/vda1  system lvm2 a--  2.00g  2.00g
  /dev/vdb1  system lvm2 a--  1.94g 88.00m
  /dev/vdc               ---     0      0
  /dev/vdd               ---     0      0

root@host1:~# lvconvert -m1 system/rootfs
  system/rootfs: Converted: 0.6%
  system/rootfs: Converted: 74.7%
  system/rootfs: Converted: 100.0%
root@host1:~# lvs -a -o +devices
  LV                VG     Attr     LSize Pool Origin Data%  Move Log         Copy%  Convert Devices                              
  rootfs            system mwi-aom- 1.86g                         rootfs_mlog 100.00         rootfs_mimage_0(0),rootfs_mimage_1(0)
  [rootfs_mimage_0] system iwi-aom- 1.86g                                                    /dev/vdb1(0)                         
  [rootfs_mimage_1] system iwi-aom- 1.86g                                                    /dev/vda1(0)                         
  [rootfs_mlog]     system lwi-aom- 4.00m                                                    /dev/vdb1(475)                    

Synchronization two volume.
In this moment we have the same data in two disk (vda1 and vdb1), to fully happy we miss only bootloader on vda.

root@host1:~# grub-install /dev/vda
Installation finished. No error reported.

Now we can reboot our system and boot it from original disk (vda).

root@host1:~# reboot

Broadcast message from root@host1 (pts/0) (Mon Oct  6 18:44:54 2014):

The system is going down for reboot NOW!
root@host1:~# Connection to 192.168.122.248 closed by remote host.
Connection to 192.168.122.248 closed.
grzesiek@probook:~$ ssh root@192.168.122.248
root@192.168.122.248's password:
Linux host1 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Oct  6 18:34:20 2014 from 192.168.122.1
root@host1:~# df -hT
Filesystem                Type      Size  Used Avail Use% Mounted on
rootfs                    rootfs    1.9G  596M  1.2G  34% /
udev                      devtmpfs   10M     0   10M   0% /dev
tmpfs                     tmpfs      49M  200K   49M   1% /run
/dev/mapper/system-rootfs ext4      1.9G  596M  1.2G  34% /
tmpfs                     tmpfs     5.0M     0  5.0M   0% /run/lock
tmpfs                     tmpfs      97M     0   97M   0% /run/shm
root@host1:~# lvs -a -o +devices
  LV                VG     Attr     LSize Pool Origin Data%  Move Log         Copy%  Convert Devices                             
  rootfs            system mwi-aom- 1.86g                         rootfs_mlog 100.00         rootfs_mimage_0(0),rootfs_mimage_1(0)
  [rootfs_mimage_0] system iwi-aom- 1.86g                                                    /dev/vdb1(0)                        
  [rootfs_mimage_1] system iwi-aom- 1.86g                                                    /dev/vda1(0)                        
  [rootfs_mlog]     system lwi-aom- 4.00m                                                    /dev/vdb1(475)                      
root@host1:~# grub-install /dev/vdb
Installation finished. No error reported.
root@host1:~#

The last, what we must do, it is install GRUB on vdb, this operaions overwrite existing menu entry witch adds command 'update-grub'.
So now we have identical two disk with LVM mirrored volume. Also we have on each fo them installed bootloader so we can boot from any of them. When one of it is crashed we can boot server from SystemRescueCd and convert missing pair mirrored volume to normal LVM volume from one good disk, and we have our system.
Remember, each time you update kernel or GRUB you must also install GRUB on vdb to be able boot your system from vbd in future. I test this and is working properly :)

Tuesday, May 20, 2014

System plików XFS dla enterprise

Ostatnimi czasy publikowane jest coraz więcej informacji na temat nowej wersji systemu Red Hat Enterprise Linux 7. Jedną z zastanawiających nowości jest domyślny system plików, którym w RHEL7 będzie XFS. Wielu użytkowników systemu GNU/Linux może to dziwić, gdyż już tak bardzo przyzwyczailiśmy się do Ext3 i Ext4, że trudno się odzwyczaić. Prędzej spodziewalibyśmy się BTRFS jako nowego domyślnego systemu plików niż XFS. Dlatego ta informacja tak pobudza ciekawość, co takiego jest w XFS, iż to właśnie on został wybrany?

Dla niektórych XFS może wydawać się nową nazwą, ale tak naprawdę system jest ten o wiele starszy od BTRFS, który wystartował w 2007 roku. System plików XFS został opracowany przez Silicon Graphics do swojego systemu IRIX, który używał XFS już od 1994 roku. Do Linuksa przeprotowano go ok. 2000 roku. Od tej pory ciągle ulepszano jego wydajność i to zapewne jest przyczyna tego że to właśnie XFS jest bardziej dopracowany niż obiecujący lecz nie dopracowany BTRFS. W XFS od dłuższego czasu znajduje się mniej błędów, niż w innych popularnych systemach plików. Kolejną różnicą do BTRFS jest to, że XFS ogranicza się do funkcjonalności mieszczących się w tradycyjnym pojęciu systemu plików, tzn. nie zamierza on oferować mechanizmu RAID czy snapshot z poziomu systemu plików. Z drugiej strony, mimo iż jest on od BTRFS starszy niemal o 20 lat to do realizacji podstawowej funkcjonalności użyto w nim równie, a może i bardziej skomplikowanych rozwiązań.

XFS może wydawać się na "staroć" ale takie rozumowanie jest błędne. Otóż ten system plików był projektem realizowanym jako daleko-wyprzedzająca wizja. Widocznie wizja, przyświecająca jego twórców była tak daleka, że dopiero przyszły czasy, w których systemy rzeczywiście będą wykorzystywać jego możliwości. Najlepiej podsumować to tak, że system plików XFS opracowany przez Silicon Graphics był wielką wizją, której celem było obsłużenie wielkich systemów plików, wielkich plików, wielkiej ilości plików i katalogów oraz wielkiej przepustowości I/O. Przy dzisiejszym "zachmurzeniu" najwięksi producenci dystrybucji GNU/Linux zostali zmuszeni do obsługi wielkich systemów plików i wybrali XFS.

Największą cechą XFS jest jego skalowalność. Ext4 jest bardzo szybki i dostatecznie dopracowany, ale do zarządzania danymi używa ciągłych struktur danych co przy większych ilościach zaczyna być problemem. Jeżeli porównasz prędkość operacji Ext4 z XFS na systemie plików o wielkości 2 TB to nie wiele będą się różnić, ale gdy zrobimy to na systemie plików o wielkości 20 TB, to zacznie wychodzić na jaw lepsze przystosowanie XFS do takich systemów. XFS od początku był projektowany na wielką skalę, i dlatego jest zaprojektowany tak, aby korzystać z różnicy budowy takich systemów plików. Do zbudowania systemu plików o wielkości 20 TB trzeba użyć wielu dysków, również maszyna będzie dysponowała wieloma procesorami/rdzeniami. XFS używa struktur AG (grupy alokacyjne) i drzew B+ do reprezentacji systemu plików. Większość operacji może wykonywać niezależnie dla konkretnego dysku twardego i AG, co dzięki dostępności wielu rdzeni pozwala wykonywać wiele operacji jednocześnie na tym samym systemie plików.

XFS wykorzystuje logiczną jednostkę danych zwaną extent, która w zależności od wielkości pliku może składać się z bloków o zmiennej wielkość. Dzięki temu, w jednym systemie plików XFS może używać małych jednostek alokacyjnych (4 kiB) i wielkich do 8 GiB. XFS używa 64-bitowej przestrzeni adresowej i 64-bitowego dziennika transakcji (file system journaling), który wykonuje operacje w sposób niepodzielny, co oznacza że operacja będzie zaksięgowana tylko w przypadku, gdy całość operacji zostanie wykonana. Kolejnym problemem z wielkimi systemami plików jest czas ich sprawdzania po niepoprawnym wstrzymaniu pracy, w XFS znacznie skrócono ten czas do minimum.

Oczywiście XFS wspiera większość podstawowych funkcji, tj. ACL, atrybuty rozszerzone, czy limity (quota). XFS oferuje nie tylko limity na użytkownika i grupę ale również na projekt, co jest raczej niespotykane w innych systemach plików. Można stworzyć jakiś projekt (ID), potem przypisać do niego określone lokalizacja (folder) i nałożyć ograniczenia.

XFS oferuje masę zaawansowanych mechanizmów podnoszących przepustowość I/O w dużych systemach plików. Czy to oznacza, że powinieneś przejść na XFS? Jeżeli nie tworzysz wielkich przestrzeni dyskowych, tylko używasz dysków 2-3 TB to nie ma sensu. Cztery dyski 2 TB, dwa w striping i na dwa kolejne RAID0 - czyli partycja o wielkości 4 TB to użycie XFS nic nie przyśpieszy. XFS należy interesować się przy 10+ TB. Oczywiście wykorzystanie XFS w przytoczonym przykładzie również nie zaszkodzi.

[1] Scalability in the XFS File System

Tuesday, February 18, 2014

Opis działania programu maxload

Pół roku temu napisałem program maxload, już wtedy byłem w trakcie pisania dokumentu, który dokumentowałby jak on działa, jednak jakoś zabrakło czasu i chęci. Mimo iż niemal 80% tekstu powstała w sierpniu 2013 roku dopiero dziś dokończyłem dzieła i publikuje w celu możliwości zapozania się z problemem i rozwiązaniem, które opracowałem.
Mam nadzieję, że program przyda się nie tylko mi, a może otrzymam jakieś recenzje na temat jego przydatności.

PDF można pobrać z Google Drive: maxload.pdf