Debian - partycjonowanie

[Fizyda 34]

Dziś postanowiłem zabrać się w końcu za zaczęcie konfigurowania swojego VPSa o którym pisze na forum i pisze, a mało robię . Na początku chciałem sobie wszystko sprawdzić na wirtualnej maszynie, bo po co płacić mam za serwer który nie będzie używany jak należy . Stworzyłem sobie w Virtual Boxie maszynę o parametrach jakie będzie miał VPS. Nawet taktowanie rdzenia się zgadza . Zaczynam instalację nazwa, domena, partycjonowanie no i mamy problem.

Nie byłbym sobą gdybym nie miał tutaj żadnych wątpliwości.

Początkowo serwer będzie miał dysk o pojemności 10GB, ale z całą pewnością w przyszłości (zależnie od rozwoju stron i potrzeb) będzie zmiana pakietu na wyższy lub dokupiony drugi serwer i część usług zostanie na niego przeniesionych. Mało istotne to jest z partycjonowaniem, ale w pierwszym przypadku będę może potrzebował rozszerzyć już istniejące partycje, a ta informacja zaraz będzie miała znaczenie.

Jeszcze słowem wstępu chciałbym zaznaczyć, że szyfrowanie w moim przypadku nie jest niezbędnym elementem, zdecydowałem się je wprowadzić by od samego początku wyrabiać sobie dobre nawyki i tworzyć względnie bezpieczne serwery.

 

Nie rozpatruję problemu tylko i wyłącznie w kategorii VPS, gdzie nie gdzie uciekam trochę w teoretyczne rozwiązania.

Dobra teraz do sedna sprawy, z czym mam problem.

• Partycja pod punkt montowania /boot
  • jaki powinna mieć rozmiar? Myślałem o 500 MB, ale gdzieś czytałem że wystarczy nawet i 100MB
  • jaki system plików? Przekonany byłem że ext4 z księgowaniem, lecz gdy zapuściłem sobie z ciekawości kreatora to stworzył on ją z ext2
• poza partycją dla /boot, chcę mieć jeszcze (może źle się wyraziłem, myślę że przydadzą się):
  • / - 1~2 GB
  • /var - 1 GB
  • /home - reszta
  • może jeszcze /swap pytanie czy jest potrzebna i ewentualnie jaki rozmiar, serwer początkowo będzie miał 2 GB RAM
  Oczywiście partycje tworzone byłby w takiej kolejności jak opisałem poczynając od początku dysku (z uwzględnieniem /boot). Pytanie czy jest to sensowne i dobrze pomyślane
• kolejna sprawa, chcę wprowadzić LVMki. O ile naturalnym jest aby montować na nich /var, /home i może /swap by móc elastycznie zwiększyć ich rozmiar np. gdybym musiał dokupić dodatkową pamięć (dysk). Zastanawiam się jednak czy nie dołożyć jeszcze do tego /, a może i /boot. Ostatnie już raczej jest przegięciem, ale warto spytać się jak widzą to osoby z doświadczeniem
• pora na wspomniane szyfrowanie
  • chcę zaszyfrować pliki poczty, stron WWW, bazy danych - będę chciał skonfigurować wszystko tak by pliki te były trzymane w /home konkretnego użytkownika. Chcę by user1 był jakby kontem w ramach którego mogę podpiąć pod publiczne pliki WWW wybraną lub kilka domen i właśnie jego katalogu domowym znajdowały by się te pliki, zapisywałyby się maile dla userów z jego domen (vhosty postfixa+dovecota i vusers) oraz tutaj też byłby pliki z bazami danych do MySQL.
    Zdaję sobie sprawę jak to ciężko będzie zrobić i wiem jak to mniej więcej skonfigurować na apche i postfixie+dovecot, z MySQL jeszcze się uczę, ale raczej powinno być to możliwe. Jeśli uznam że np. jest to dla mnie za trudne pliki te wylądują w /www, /mail, /db na LVM i w tedy też te zasoby będę chciał zaszyfrować.
  • czy warto i jaki sens ma szyfrowanie plików konfiguracyjnych systemu? Nie wiem czy szyfrować jeszcze /var i / ogólnie słabo to widzę bo serwer nie wstanie bez wpisania hasła, a raczej chciałbym tego uniknąć.
    Jeśli chodzi o hasło wyżej to dla uproszczenia uznajmy że będzie ono zapisane na pamięci USB wpiętej do serwera do którego lokalizacja będzie podana w fstab (w serwerze dedykowanym będzie to tak zadziałać?). Wiem w VPS tego się tak nie da zrobić, ale myślę tutaj nie koniecznie tylko o VPS, ale też przyszłościowo.
  • TYLKO Z CIEKAWOŚCI: szyfruje się wszystko włącznie z /boot?
• jak to zorganizować by mieć jak największą elastyczność, LUKS w LVM czy LVM w LUKS? oczywiście możliwe że pod spotem jest jeszcze jakaś macierz w RAID lub RAID softwarowy, ale nie powinno mieć to znaczenia bo po prostu dodaję macierz do grupy i szyfruję powstałą partycję LVM, ewentualnie szyfruję macierz jak partycję i dodaję do grupy LVM (dobrze rozumiem?)
  LUKS - rozumiem zaszyfrowanie partycji/dysku
• załóżmy że system uległ awarii i trzeba dobrać się do danych awaryjnie np przez LiveCD, jak bardzo takie skopiowanie danych utrudnia LVM i LUKS?

Znajdzie się ktoś kto oświeci i pomoże takiemu biednemu paranoikowi jak ja .

PS. Na serwerze będzie też ftp ProFTPd z vuserami i vhostami.

[GT_Lukasz 20]

Jak widzę takie pytania , mam ochotę odesłać cię tu, a więc to zrobię

 

http://ubuntu.pl/czytelnia/2008/09/23/partycjonowanie-dysku-twardego/

 

 

 

• załóżmy że system uległ awarii i trzeba dobrać się do danych awaryjnie np przez LiveCD, jak bardzo takie skopiowanie danych utrudnia LVM i LUKS?

Pytasz czy szukasz drogę na skróty?

[Pan Kot 1535]

Za dużo pytań, na które odpowiedzi można znaleźć w linku powyżej, więc tylko dodam 3 grosze tam gdzie uważam to za słuszne.

 

Jeśli nie ma szyfrowania, to robienie oddzielnej partycji /boot jest głupotą i anarchizmem z kernela 2.4, gdy rzeczywiście miało to sens, z racji że można było na tej partycji robić wiele rzeczy takich jak ustawianie flagi boot, wrzucenie tam gruba (zamiast do mbra) i więcej. Obecnie nie ma to żadnego sensu (poza szyfrowaniem, o którym za chwilę) i jeśli nie masz dostatecznie dobrego powodu, żeby robić taką partycję to sobie odpuść.

 

Jeśli chcesz mieć łatwą możliwość skalowania/resizowania partycji, to obowiązkowo trzeba wrzucić to do LVM. Najlepiej wszystkie partycje, czyli cały dysk, bo tylko takie rozwiązanie ma jakikolwiek sens, chociaż nie widzę żadnego sensu w partycjonowaniu serwera w 2016 roku. Po co chcesz stworzyć dodatkowe partycje? Jaki masz w tym cel? Mi jest znany tylko jeden dobry powód - szyfrowanie, ale do tego jeszcze wrócę jak napisałem wyżej. Dawno temu robiło się zabieg mający na celu rozrzucenie "zapełniających się" ścieżek takich jak /tmp czy /var/log na oddzielne partycje, żeby upewnić się, że nie zajadą dysku na 100% i będzie możliwe zalogowanie się do serwera. Ja uważam to za kompletny bezsens, od tego jest logrotate i syslog, żeby poprawnie skonfigurować te aspekty, a w najgorszym przypadku quota od limitowania konkretnych ścieżek. Po co sobie robić fizyczne bariery, gdy można zrobić wirtualne.

 

I teraz dochodzimy do magicznego szyfrowania.

 

Powiem to od razu, zanim w ogóle przejdę do szczegółów. SZYFROWANIE NA SERWERACH NIE MA ŻADNEGO SENSU, więc wybij sobie to z głowy zanim w ogóle się na to zdecydujesz, a żeby nie zostać gołosłownym to już mówię dlaczego.

 

PO PIERWSZE, jeśli chcesz szyfrować rootfs czyli /, to obowiązkowo musisz zrobić dodatkową NIEZASZYFROWANĄ partycję /boot, na której ustawi się kernel z grubem. Żeby odszyfrować dysk potrzebujesz zbootowany kernel, który ma odpowiednie do tego narzędzia - sam bootloader GRUB, i to jeszcze umieszczony w 446 bajtach mbra (o ile ktoś nie ma GPT), nie ma żadnych narzędzi do odszyfrowania dysku, więc skończysz z niebootującym serwerem jeśli tego nie zrobisz.

 

Następna kwestia, ext2 to kolejny anarchizm, którego się już nie używa. Partman w debianie nadal go proponuje na partycję /boot głównie z tego powodu, że nadal pozostaje bardziej kompatybilny ze starym sprzętem, starym grubem, starymi windowsami i starymi biosami, ale jeśli nie masz setupu z 2001 roku, i nie próbujesz zainstalować debiana 3.1 Sarge, to absolutnie nie ma żadnego powodu do pakowania się w ext2, który jest o wiele bardziej podatny na awarie niż ext4 z journalingiem.

 

Teraz przechodzimy do sedna całego szyfrowania. Czy zdajesz sobie w ogóle sprawę PO CO szyfrujesz dysk? Po to, żeby nieuprawniona osoba mająca dostęp do dysku twardego twojego serwera nie była w stanie go odszyfrować i wejść w posiadanie informacji z niego. Teraz przeczytaj co sam napisałeś - jeśli serwer ma w ogóle się bootować, to musi znać to hasło. Jeśli zna to hasło, a dostęp do dysków ma wyłącznie twój provider (hosting), to po jaką cholerę utrudniasz sobie życie, degradujesz wydajność i mocno komplikujesz cały serwer? W imię czego przepraszam, że jak włamywacz włamie się do wybitnie strzeżonego DC, rodem z mission impossible, to wejdzie w posiadanie dysku z twojego serwera, a USB z hasłem już nie? Albo może myślisz, że jak policja zrobi wjazd na dyski to oczywiście będą tak wybitni, że na wiadomość o wymaganym kodzie do odszyfrowania rozłożą ręce, włożą dysk z powrotem i pójdą szukać dalej?

 

Jeszcze wybitniejszym pomysłem jest szyfrowanie tylko jednej partycji takiej jak /home, i trzymanie klucza deszyfrującego bezpośrednio na partycji rootfs, jeszcze najlepiej w skrypcie na starcie co deszyfruje /home. To już są wybitne przypadki osób, które minęły się z powołaniem.

 

JEDYNE zastosowanie szyfrowania na serwerach jest wtedy, gdy masz do niego albo fizyczny albo przez KVM dostęp, jesteś w stanie zarówno psychicznie jak i fizycznie wpisywać hasło przy każdym reboocie serwera, i dane są na tyle ściśle tajne, że nigdzie tego klucza nie zapisujesz i nikomu on nie jest użyczany. BTW, nawet w tym wypadku osoba robiąca wjazd na dysk po prostu sfreezuje aktualny stan serwera (są do tego specjalne narzędzia) i zrobi kopię dysku dokładnie taką jaka jest, a ty nawet nie zauważysz, że coś się dzieje. Szyfrowanie ma sens gdy komputer jest wyłączony, dyski i pamięci zimne, a policja robi Ci nalot na chatę i wyjmuje dysk. Wtedy z uśmiechem na ustach możesz powiedzieć "oj panowie, chyba zapomniałem klucza". Serwer z definicji działa 24/7, czyli jedyny powód do szyfrowania dysku automatycznie przestaje mieć jakiekolwiek znaczenie.

 

I finalnie podkreślam, że szyfrowanie nie jest darmowe, degraduje wydajność I/O oraz CPU i nie ma żadnego zastosowania na serwerach, co zaznaczyłem zanim w ogóle zacząłem wyjaśniać dlaczego.

 

Poza tym, kupując VPSa w firmie w 99.9% przypadków nie będziesz miał nawet MOŻLIWOŚCI zmienić układu partycji, zawsze będziesz miał jedną partycję rootfs i ew. swap (też nie zawsze). A jak partycjonujesz dedyka to jeśli nie masz dostatecznie dobrego powodu do rozrzucania tego na kilka partycji, to tego nie robisz - rootfs i swap, nic więcej, nic mniej, i żadne LVMy tylko fizyczne partycje. Swap ustawiasz na nie więcej niż 2 GB, bo w przypadku zajechania hdd 2 GB swapu i tak serwer będzie całkowicie zamrożony i nieresponsywny. Poza tym jeśli zajdzie ogromna potrzeba, zawsze można zrobić swap w pliku i włączyć go jako ekstra.

 

TL;DR - rootfs na ext4, i max 2 GB swapu

 

I lepiej traktuj swoją wirtualkę na vboxie jak pełnoprawnego dedyka, bo VPSy z którymi się spotkasz w najlepszym wypadku będą miały KVMa i będą przypominać takiego dedyka, a w najgorszym i średnim będą zwykłymi wirtualkami na OpenVZ.

Edytowano Marzec 27, 2016 przez Archi (zobacz historię edycji)

[Fizyda 34]

Archi bardzo Ci dziękuję, kolejny raz pokazałeś, że można liczyć na Ciebie, Twoją wiedzę i doświadczenie. W linku podanym przez GT_Lukasz nic ciekawego dla mnie nie znalazłem, ale w Twojej wypowiedzi pojawiły się odpowiedzi na wszystkie moje pytania. Przekonałeś mnie bo jako jedyny podałeś sensowne argumenty (pytałem o to samo jeszcze na innych forach), zazwyczaj padały odpowiedzi "puknij się w łeb co ty robisz rób to tak".

Mam do Ciebie jeszcze tylko ostatnie pytanie ponieważ napisałeś:

 

A jak partycjonujesz dedyka to jeśli nie masz dostatecznie dobrego powodu do rozrzucania tego na kilka partycji, to tego nie robisz - rootfs i swap, nic więcej, nic mniej, i żadne LVMy tylko fizyczne partycje.

Czemu nie na LVM? Jeśli będę miał mało miejsca na dysku i dokupię kolejny to gdy postawiłem / na LVM a swap na partycji bez problemu mogę rozszerzyć /. Oczywiście mówię to o dwóch urządzeniach - dyskach nie partycjach.

 

Nie wiem czy dobrze zrozumiałem

 

Swap ustawiasz na nie więcej niż 2 GB, bo w przypadku zajechania hdd 2 GB swapu i tak serwer będzie całkowicie zamrożony i nieresponsywny.

chodzi o zużycie/uszkodzenie dysku?

[Pan Kot 1535]

Tyle, że do VPSa nie dokupisz drugiego dysku, a jeśli to zrobisz do dedyka to pierwsze co zrobisz to zaorasz całość i postawisz RAID1, a nie LVMa na dwa dyski.

 

Przy swapie chodziło mi o jego użycie.

[Fizyda 34]

Teraz już wszystko jasne i wiem co mam robić. Jeszcze raz dzięki Archi wesołego jajka i mokrego dyngusa.

[kafi 2425]

Dawno temu robiło się zabieg mający na celu rozrzucenie "zapełniających się" ścieżek takich jak /tmp czy /var/log na oddzielne partycje, żeby upewnić się, że nie zajadą dysku na 100% i będzie możliwe zalogowanie się do serwera.

To jest tylko jeden z aspektów...

 

 

 

a w najgorszym przypadku quota od limitowania konkretnych ścieżek

 

quota limituje raczej udziały użytkownika na partycji, a nie konkretne ścieżki. Więc ciężko np. takiemu mysql'owi ograniczyć, żeby do DATADIR mógł zapisywać, a do logów już niekoniecznie. Druga sprawa - po co zmuszać system do ciągłego liczenia i przeliczania owej quoty, skoro można robić taki "bezpiecznik" na poziomie systemu plików (bo to, że od rotacji logów jest logrotate, to nie wątpię - ale co w momencie, gdy interwał rotacji jest zbyt mały i w ciągu kilku minut plik logów urośnie do wartości monstrualnej?).

 

Inne aspekty to ustawianie różnych flag montowania dla różnych partycji - przykładowo noexec, nosuid, nodiratime - bo po co ciągle aktualizować czas ostatniego dostępu do katalogu z logami czy po co wykonywać binarki z loga / tmp?

 

Ale fakt faktem - do większości standardowych zastosowań wygodniejsze będzie wszystko na jednej partycji.

 

 

 

 

Czemu nie na LVM?

LVM wbrew pozorom spowalnia operacje I/O. Więc jeśli nie ma uzasadnionej potrzeby jego stosowania, to warto sobie go darować.

 

A co do układu partycji - to ciekawym jest jeszcze układ

0 - /boot - troszkę miejsca

1 - swap - 2GB (więcej nie ma sensu - Archi wyżej napisał czemu)

2 - / - reszta miejsca na dysku

 

Ma on taką zaletę, że /boot jest na początku dysku (więc bootowanie nie będzie się dziwnie zachowywać na żadnej konfiguracji), a wtedy gdy będziesz chciał rozszerzyć dysk, to po prostu:

1. (a) zwiększysz rozmiar pliku VHD w przypadku wirtualizacji (b) skopiujesz go 1:1 na nowy, większy w przypadku dysku fizycznego;

2. zwiększysz rozmiar partycji root (dzięki temu, że jest ostatnia, to wystarczy tylko zmienić wskaźnik końca;

3. zwiększysz rozmiar systemu plików.

 

Gdy na końcu dysku będzie swap (a jeszcze gorzej, gdy inna partycja), taka operacja będzie nieco cięższa do wykonania.

Edytowano Marzec 29, 2016 przez kafi (zobacz historię edycji)

[Pan Kot 1535]

quota limituje raczej udziały użytkownika na partycji, a nie konkretne ścieżki. Więc ciężko np. takiemu mysql'owi ograniczyć, żeby do DATADIR mógł zapisywać, a do logów już niekoniecznie. Druga sprawa - po co zmuszać system do ciągłego liczenia i przeliczania owej quoty, skoro można robić taki "bezpiecznik" na poziomie systemu plików (bo to, że od rotacji logów jest logrotate, to nie wątpię - ale co w momencie, gdy interwał rotacji jest zbyt mały i w ciągu kilku minut plik logów urośnie do wartości monstrualnej?).

 

Inne aspekty to ustawianie różnych flag montowania dla różnych partycji - przykładowo noexec, nosuid, nodiratime - bo po co ciągle aktualizować czas ostatniego dostępu do katalogu z logami czy po co wykonywać binarki z loga / tmp?

 

Ale fakt faktem - do większości standardowych zastosowań wygodniejsze będzie wszystko na jednej partycji.

 

Jak partycja Ci się zajedzie na 100% to już jest ten moment w którym na ogół jest "za późno". Quota pozwala na sprecyzowanie procentów i wielkości, nie wyobrażam sobie fizycznej blokady /var/log, gdzie w przypadku jednego procesu żaden inny nie będzie mógł nic zapisać (a mogą to być naprawdę istotne rzeczy, takie jak lecący bruteforce na SSH, który musi wychwycić fail2ban/lfd). Właśnie cały sens tego magicznego ustrojstwa polega na tym, że jak jeden proces oszaleje, to żeby innym się nie oberwało - partycja /var/log czy podobna zamyka 1 kryminalistę wraz z 99 niewinnymi w jednej celi, idąc zasadą, że to któryś z tych 100 musi być winny. Dla mnie - całkowicie niepraktyczne, jak spodziewam się że nginx mi oszaleje to ustawiam quotę właśnie na niego, tak żeby ani miejsce na dysku ani inne procesy nie oberwały.

 

Flagi nosuid noexec itp. popieram, są fajne i rzeczywiście mogą mieć zastosowanie, ale obecnie jest to armata do wbijania gwoździ. Jak się nad tym głębiej zastanowisz to zauważysz, że w zasadzie przed niczym to nie chroni, bo exploity sobie znajdą jakąkolwiek inną ścieżkę, a nodiratime przy domyślnym relatime dużo nie wnosi (ba, może wnieść problemy przy używaniu specyficznych aplikacji). Poza tym limitujesz wiele programów, i nie mówię tutaj tylko o takich php i podobnych, które używają go jako cache, ale również o popsutych pakietach i "dziwnych" kombinacjach (tak, patrzę na Ciebie wine), które bez execa w /tmp nawet nie będą działać.

 

Sam kiedyś byłem zwolennikiem takiego montowania, ale po niezliczonych problemach i po przekalkulowaniu zalet i wad stwierdziłem, że to się mija z celem. Na exploity jest grsec, a na zapełnianie miejsca quota. Oczywiście, to tylko moje podejście, i nie twierdzę że tworzenie /tmp czy /var/log jako oddzielnej partycji musi być złe z definicji. Po prostu nie uważam tego za jakikolwiek dobry powód do tworzenia oddzielnych partycji, to może być "ekstra" dodatek jeśli już znajdziesz jakiś konkret dlaczego chcesz to rozbić na kilka partycji, ale na 100% nie jako główny powód.

Edytowano Marzec 29, 2016 przez Archi (zobacz historię edycji)

[Gość Kamikadze]

Nie wiem czy dobrze, ale ja osobiście wolę mieć wszystko na jednej partycji a później monitoruje % użytego miejsca. Mam skrypt, który "czyści" logi przy 60+% zajętego miejsca (oczywiście mam na myśli tutaj jakieś maile crona czy te mniej ważne/stare).

 

Na serwerach bez tego skryptu mam po prostu monitorowanie zużycia i jak przekroczy limit dostaję "wyjca" od serwera

Mam w tedy czas na reakcję bo zostawiam sobie zawsze zapas tych kilku / kilkunastu GB zależnie od serwera.

[gutek 23]

A jak duża może być różnica przy większej liczbie operacji I/O pomiędzy LVM i braku LVM ?

[Pan Kot 1535]

Niewielka bo overhead to najczęściej CPU a nie I/O. I/O to najniższy poziom, który jest realizowany przez kernel po milionie innych rzeczy wyżej, takich jak caching, dirty page, delayed allocation i więcej. Nikt nie powinien się nawet zastanawiać nad overheadem LVMa, bo wyżej masz tryliard innych rzeczy do optymalizacji, takich jak sysctl, I/O governor, async journaling w ext4 i inne, które mają o wiele większy wpływ niż rzeczy nisko-poziomowe.

[Kszysiu 136]

Ostatnio miałem okazję testować lvm vs raw device (fio i dd) i różnic żadnych nie widziałem. Testowałem na hdd i na ssd.