PV090: UNIX – seminář ze správy systému

Organizace výuky | Jak má vypadat referát | Úkoly | Způsob hodnocení | Obsazení počítačů | Přiřazení referátů | Probíraná témata | Archív referátů


Organizace výuky

Studenti pracují na virtuálních strojích na platformě Stratus.FI.

Každý týden je vyhrazen jednomu tématu:

Přístup k počítačům

Virtuální stroje jsou pojmenovány protoXY a připojeny do dedikované privátní sítě, která je routovaná a NATovaná do Internetu serverem erigona.fi.muni.cz. Na Erigoně mají studenti účet s fakultním loginem a heslem. Tipy pro snazší přístup:

Jak má vypadat referát


Úkoly

Úkolem bývá typicky vyzkoušet v praxi věc, o které byl tu hodinu referát. Toto lze většinou stihnout v hodině, přinejhorším dokončit v průběhu týdne. Na začátku následující hodiny se provede kontrola a přidělení bodů. Při vypracování úkolů se vám budou hodit různé systémové nástroje. K některým vlastnostem úkolu je na erigoně kontrolní skript, jehož výstupy najdete v adresáři /var/pv090.

Na řešení úkolů spolupracujte! Samozřejmě není cílem, aby jeden udělal úkol za všechny nebo aby někde zveřejnil výsledné konfigurační soubory, ale nebojte se zeptat v Diskusním fóru v ISu, nebojte se poradit druhým, atd. Popište kde jste se zasekli, co vám systém píše, nechte si poradit s interpretací chybového hlášení, a podobně.


Způsob hodnocení

Podmínkou ukončení je mít uznaný aspoň jeden referát. Podmínkou uznání je včasné odevzdání HTML verze (ve správném kódování :-), prezentace referátu a rozumný obsah referátu.

Úkol

K většině úkolů existují automatizované testy. Testy budou aktivovány na druhé hodině v týdnu, spouštějí se automaticky každých cca 10 minut, a jejich výsledky můžete vidět na erigoně v adresáři /var/pv090/protoXX/název_tématu/. Zdrojové texty testů nejsou studentům k dispozici.

V případě omluvené neúčasti se doba pracovní neschopnosti nezapočítává do časového limitu.

Požadavky na ukončení:

Plán semestru, referáty

# Téma Autor
1. Instalace systému
2. Jádro systému
3. Virtualizace
4. Automatizovaná správa serverů (Ansible a podobně)
5. DNS Vít Falta
6. Public Key Infrastructure Pavol Kyčina
7. HTTP a WWW servery Robert Gemrot
8. Elektronická pošta Peter Romančík
9. Databáze uživatelů, PAM a LDAP
10. Kerberos, synchronizace času po síti
11. SNMP a monitoring sítě Lukáš Pospíšil
12. Síťové souborové systémy Miroslav Mažgut
13. Load balancery, proxy servery, high availability Ján Václav

Obsazení počítačů

Hostname Správce
proto01
proto02
proto03
proto04Syed Amdadul Hoque Fahim
proto05Vít Falta
proto06Robert Gemrot
proto07Pavol Kyčina
proto08
proto09
proto10Miroslav Mažgut
proto11Vít Patočka
proto12Lukáš Pospíšil
proto13Peter Romančík
proto14
proto15
proto16Filip Timko
proto17Ján Václav
proto20Jan Kasprzak

Probíraná témata


Instalace systému

Obsah:
Výběr distribuce/systému. Typy distribucí (konzervativnost aktualizací, rolling updates, ...). Volba souborového systému. Instalace: rozdělení disků, základní konfigurace sítě IPv4 a IPv6 Nástroje pro automatickou instalaci (kickstart a podobně).
Úkol:

Přihlaste se do webového rozhraní https://stratus.fi.muni.cz/ a podle dokumentace si vytvořte virtuální stroj:

  • Není-li ještě v systému instalační médium vámi vybraného systému, vytvořte image instalačního CD a nastavte právo use pro všechny uživatele.
  • Vytvořte prázdný disk pro virtuální stroj. Disk pojmenujte ProtoXY a přidejte mu štítek PV090. Budete potřebovat cca 20 GB dat.
  • Vytvořte šablonu pro virtuální stroj, pojmenujte ji taktéž ProtoXY a přidejte štítek PV090. Použijte síť pv090, nikoliv jinou. Stroji nastavte 4-8 GB RAM a 1–2 VCPU. Hodnotu CPU dejte 0.2.
  • Na základě šablony vytvořte instanci - virtuální stroj samotný. Název instance zvolte ProtoXY a i zde přidejte štítek PV090.

Nainstalujte na svůj počítač UNIXový systém (Linux, *BSD, ...).

Nakonfigurujte síť podle následující topologie. V případě IPv4 a IPv6 použijte statickou konfiguraci a nenechte se zmást tím, co vám kdo po síti nabízí za adresy a cesty :-). Jako DNS server v této fázi použijte vnitřní IPv4 a IPv6 adresy erigony.

topologie 1 - 2015
Topologia siete
Internet ---(vonkajsia siet)--- erigona ---(vnutorna siet)--- proto01..proto10

Adresacia jetnolivych prvkov v sieti
erigona:
- vonkajsia siet: 
		erigona.fi.muni.cz (147.251.58.76, 2001:718:801:23a::4c)
- vnutorna siet: 
		erigona.pv090.fi.muni.cz (10.0.0.1/24, fd00:dead:beef::1/64), 
		erigona.ip4.pv090.fi.muni.cz (10.0.0.1/24),
		erigona.ip6.pv090.fi.muni.cz (fd00:dead:beef::1/64)

protoXY:
- vnutorna siet:
		protoXX.pv090.fi.muni.cz (10.0.0.XY0/24, fd00:dead:beef::XY0/64),
		protoXX.ip4.pv090.fi.muni.cz (10.0.0.XY0/24),
		protoXX.ip6.pv090.fi.muni.cz (fd00:dead:beef::XY0/64)

Nakonfigurujte firewall (např. iptables, firewalld) tak, aby přístup z vašeho stroje ven nebyl omezený a přístup zvenku na váš stroj zahrnoval pouze již otevřená spojení, plus přístup na službu SSH minimálně ze stroje erigona. Konfigurace firewallu by se měla aktivovat vždy po startu systému.

Povolte přístup na službu SSH na uživatele root z počítače erigona s následujícím veřejným SSH klíčem:

        ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIH1QQHt5Z3TKGai/9kCvaL0cDWWo54JKsCLwyd91jgZm root@erigona
        

Nainstalujte následující programy, které se pak budou využívat například pro kontrolu úloh:

  • tcpdump
  • ip
  • host
  • ssh, scp
  • ping
  • which
  • blkid

Celou dobu dokumentujte, co a jak děláte, kde nastavujete něco jiného než je implicitní.

Hodnocení:
  • základní část:
    • běžící systém
    • nainstalované výše požadované programy
    • funkční IPv4 včetně ping
    • fungující přihlášení z erigony se SSH klíčem
    • nmap z erigony by měl ukazovat jen port 22/tcp
  • hodnocená část:
    • 2 body: dokumentace nainstalovaného systému
    • 2 body: IPv6 včetně směrování a SSH (hint: zkoušejte ping6 na veřejnou IPv6 adresu erigony)
    • 2 body: funkční FW pro IPv6 (včetně povolení ping)
  • bonusová část:
    • 2 body: šifrovaný filesystém (použijte LUKS a dvě hesla "pv090pv090" a "PV090PV090"). POZOR: musí zůstat funkční po celý zbytek semestru!

Jádro systému

Obsah:
Odkud se jádro bere, způsob vývoje. Zjištění informací o HW (lspci, lsusb, ...). Konfigurace (make config/xconfig/menuconfig/oldconfig), soubor .config. Principy fungování modulů, mapování modulů na PCI ID, USB ID a podobně. Instalace nového jádra, initrd a jeho generování (např. dracut, genkernel), soubor System.map. Parametry jádra při startu.
Úkol:
Stáhněte si poslední verzi jádra z kernel.org, zjistěte HW konfiguraci svého počítače, nakonfigurujte jádro na míru tomuto počítači (typ a počet procesorů, velikost paměti, architektura, atd.). Zaměřte se na to, aby v konfiguraci byly do jádra přímo zakompilovány ty části, které se na běžícím systému budou používat vždy, jako moduly byly zkonfigurovány ty ovladače a další části, které mohou být někdy na počítači použity, a vypnuty ty části jádra, které jistě s tímto počítačem nikdy nepoužijete (nekompatibilní/neexistující HW, exotické filesystémy, atd.). Výsledné jádro nainstalujte do systému a nabootujte. Pro snazší kontrolu zapněte volbu CONFIG_IKCONFIG_PROC=y (konfigurace jádra je pak dostupná jako /proc/config.gz). Toto jádro budete používat v semináři i nadále.
Hodnocení:
  • základní část:
    • systém nabootuje vlastní jádro
    • konfigurace je dostupná v /proc/config.gz
  • hodnocená část:
    • 3 body: správně nastavené všechny globální volby které mají významný vliv na efektivitu výsledného jádra (např. typ a počet procesorů, přístup k paměti, atd)
    • 1 bod: správně zvolené ovladače použitých souborových systémů a návazné konfigurační volby (NLS)
    • 3 body: vypnuté ovladače a subsystémy, které se na daném počítači nepoužijí
    • 2 body: vše výše uvedené a navíc prázdný seznam načtených modulů po rebootu

Virtualizace

Obsah:
Proč virtualizace? Úrovně virtualizace: kontejnery (chroot(2), BSD jail(2), VServer, OpenVZ/Virtuozzo, ...), emulace HW (Qemu), paravirtualizace (user-mode Linux, lguest, XEN, VMware), plná virtualizace (KVM, XEN 3, VMware). Porovnání teoretického výkonu. Virtualizace I/O zařízení, zpřístupnění fyzického HW dovnitř virtuálního stroje. Formáty virtuálních disků, prostředky pro vysokou dostupnost a migraci. Připojení virtuálních strojů do sítě. Systémy pro správu virtuálních strojů.
Úkol:

Nakonfigurujte na svém fyzickém stroji některý virtualizační systém a v něm vytvořte virtuální stroj. Do virtuálního stroje nainstalujte operační systém podle zadání úlohy 1 (Instalace systému) Použijte následující topologii sítě:

topologie 2 - 2015
Topologia siete s virtualizaciou
Internet ---(vonkajsia siet)--- erigona ---(vnutorna siet 1)--- proto01..proto10 ---(vnutorna siet 2)--- proto01..10-beta

Adresacia jednotlivych prvkov v sieti (len zariadenia kde doslo k zmenam oproti prvotnej topologii)

protoXY:
- vnutorna siet 1:
		protoXX.pv090.fi.muni.cz (10.0.0.XY0/24, fd00:dead:beef::XY0/64),
		protoXX.ip4.pv090.fi.muni.cz (10.0.0.XY0/24),
		protoXX.ip6.pv090.fi.muni.cz (fd00:dead:beef::XY0/64)
- vnutorna siet 2:
		protoXX-alpha.pv090.fi.muni.cz (10.0.XY0.1/24, fd00:dead:beef:XY0::1/64),
		protoXX-alpha.ip4.pv090.fi.muni.cz (10.0.XY0.1/24),
		protoXX-alpha.ip6.pv090.fi.muni.cz (fd00:dead:beef:XY0::1/64)

protoXY-beta:
- vnutorna siet 2:
		protoXX-beta.pv090.fi.muni.cz (10.0.XY0.2/24, fd00:dead:beef:XY0::2/64),
		protoXX-beta.ip4.pv090.fi.muni.cz (10.0.XY0.2/24),
		protoXX-beta.ip6.pv090.fi.muni.cz (fd00:dead:beef:XY0::2/64)

Nakonfigurujte korektně statické směrování IPv4 i IPv6, včetně cest k virtuálním strojům ostatních počítačů v laboratoři (použijte proto01-proto10 a proto20). V konfiguraci nepoužívejte NAT a také ne bridge, ve kterém by bylo i hlavní síťové rozhraní počítače.

Virtualizační nástroj nastavte tak, aby se virtuální počítač aktivoval automaticky po startu systému, a při jeho vypínání se buďto správně vypnul nebo hibernoval.

Pro rychlejší běh virtuálního systému doporučujeme povolit nested virtualizaci. V rozhraní OpenNebuly to nakonfigurujete tak, že dáte editovat šablonu virtuálního stroje (vybrat šablonu a kliknout na Update nahoře), a pak na záložce Other úplně vpravo v sekci Raw data do pole Data dáte následující XML text:

<cpu mode='host-passthrough'></cpu>

Pak je třeba šablonu uložit (zelené tlačítko Update) a znovu instanciovat virtuální stroj: ukončete pomocí shutdown, v záložce virtuálního stroje pak klikněte na ikonku koše a vyberte Terminate hard, a pak znovu instanciujte šablonu VM. Po nabootování byste měli v /proc/cpuinfo vidět informace o fyzickém CPU místo QEMU virtual CPU.

Hodnocení:
  • základní část:
    • běží VM, lze ping i ping6 z erigony, lze SSH z erigony
  • hodnocená část:
    • 3 body: viz úloha 1
    • 2 body: statické směrování IPv4 i IPv6
    • 1 bod: korektní vypnutí/zapnutí VM při vypnutí/zapnutí fyz. stroje
    • 1 bod: správná konfigurace FW na fyzickém stroji (zakázáno vše co nebylo požadováno dosavadními úkoly)
  • bonusová část:
    • 2 body: správně nakonfigurovaná sériová konzola na VM, přístupná z fyzického stroje.
    • 1 bod: sériová konzola funkční i pro výběr jádra a další ovládání bootloaderu VM.

DNS

Obsah:
Údaje v DNS. Základní typy záznamů. Resolver a jeho konfigurace. DNS servery (BIND, případně další). Reverzní DNS v IPv4 a IPv6. Zóna versus subdoména, delegování subdomén na jiné servery. Základní vlastnosti DNS serverů, instalace, konfigurace. Zabezpečení přenášených dat a DNSSEC.
Úkol:

Nainstalujte na oba své stroje DNS servery s těmito vlastnostmi (týká se vždy IPv4 a IPv6):

  • Počítač alpha:
    • primární server pro doménu pv090.fi.muni.cz (přidělení jmen a adres je popsáno v topologii sítě)
    • primární server pro reverzní DNS pro všechny prefixy adres v laboratoři kromě vaší jedné dvoubodové sítě mezi vašimi počítači alpha a beta.
    • reverzní DNS pro dvoubodovou síť mezi počítači alpha a beta (viz výše) delegovat na DNS server počítače beta
    • neznámé dotazy přeposílat na erigonu
  • Počítač beta:
    • sekundární DNS pro doménu pv090.fi.muni.cz (primární je alpha)
    • sekundární DNS pro reverzní zóny (viz počítač alpha)
    • primární DNS pro reverzní zóny dvoubodové sítě mezi počítači alpha a beta
    • neznámé dotazy přeposílat na alphu

Pro kontrolu je třeba povolit u všech autoritativních zón přenos zóny (zone transfer) z erigony. Vygenerovat si DNSSEC klíče a mít všechny své zóny podepsané (včetně delegace subdomény u reverzního DNS). Validovat DNS odpovědi přes DNSSEC (viz www.rhybar.cz). Při změně dat na primárním nameserveru korektně notifikovat sekundární. Umožnit reload a další ovládání nameserveru na obou strojích vzdáleně ze strojů alpha a erigona nástrojem rndc. Pro erigonu použijte rndc klíč "/HEXWwRK8joztvL3fdGUrg==" s hashovacím algoritmem hmac-md5.

Názvy zón pro které mají být některé vaše nameservery autoritativní (viz výše) jsou tyto:

  • pv090.fi.muni.cz
  • 0.10.in-addr.arpa
  • x.0.10.in-addr.arpa (pro váš prefix sítě x)
  • f.e.e.b.d.a.e.d.0.0.d.f.ip6.arpa
  • 0.y.x.0.f.e.e.b.d.a.e.d.0.0.d.f.ip6.arpa (kde fd00:dead:beef:xy0::/64 je prefix vaší dvoubodové sítě)
Hodnocení:
  • základní část:
    • běží dva DNS servery, komunikují na IPv4 i IPv6
    • smysluplně odpovídají na dotazy na jména z pv090.fi.muni.cz (A i AAAA) a na reverzní záznamy (PTR), například při dotazu z erigony nebo z vašich vlastních strojů
    • smysluplně překládají jména na adresy a naopak pro adresy mimo laboratoř
    • funguje zone transfer při přístupu z erigony (IPv4 i IPv6 pro všechny autoritativní zóny daného nameserveru)
  • hodnocená část:
    • 3 body: korektní obsah zónových souborů
    • 1 bod: přeposílání neznámých dotazů podle zadání
    • 1 bod: delegace reverzních subdomén
    • 2 body: notifikace a zone transfer na sekundární DNS při změně dat
    • 1 bod: korektní nastavení firewallu (odchozí provoz, 53/tcp, 53/udp, rndc port)
    • 1 bod: konfigurace DNS v Ansible (nebo jiném systému pro správu konfigurace)
  • bonusová část:
    • 1 bod: rndc
    • 2 body: DNSSEC validace (pro ověření je třeba mít nainstalovaný program drill na obou strojích)
    • 3 body: DNSSEC podpisy (drill -SD, drill -TD)

Elektronická pošta

Obsah:
Princip fungováni SMTP (obálka, zpráva), DNS MX záznamy versus A/AAAA záznamy. Formát zpráv (RFC 2822, MIME). Způsob ukládání zpráv (mailbox, maildir, ...). Příklad komunikace přes SMTP. Problém spamu (relaying, open relay, black-listy, delayed bounce, greylisting, antispamové filtry, SPF, DKIM, ...). Poštovní klienti (IMAP, POP3). Princip fungování konkrétniho SMTP serveru (sendmail, postfix, exim, ...) - základní konfigurace, kontrola relayingu, "doménový koš", ...
Úkol:
Nasimulujte typickou konfiguraci s jedním přeposílacím SMTP serverem a jedním doručovacím "vnitřním" SMTP serverem.
  • alpha (přeposílací SMTP server):
    • na portu SMTP/TCP přijímat spojení odkudkoli.
    • poštu pro user@cokoli.pv090.fi.muni.cz (i pro prázdné "cokoli."; pro kteréhokoli uživatele "user") převzít od kohokoli a přeposlat na počítač beta.
    • poštu pro ostatní adresy převzít jen z počítače beta nebo od sebe sama a přeposlat na relay.fi.muni.cz.
  • beta (vnitřní SMTP server):
    • na portu SMTP/TCP přijímat spojení odkudkoli.
    • poštu pro user@cokoli.pv090.fi.muni.cz (i pro prázdné "cokoli."; pro kteréhokoli uživatele "user") převzít jen od počítače alpha a od sebe sama, doručit ji lokálně příslušnému uživateli.
    • poštu pro ostatní adresy převzít jen od počítače alpha a od sebe sama, přeposlat ji na počítač alpha.
    • poštu pro lokálního uživatele pv090 přesměrovat na adresu pv090@fi.muni.cz (přeposláním na stroj alpha, viz výše).
    • poštu doručenou lokálním uživatelům zpřístupnit protokolem IMAP a POP3. Použijte uživatele test a heslo pv090.
  • Webový přístup k poště:
    • Na adrese https://protoXX.pv090.fi.muni.cz/webmail/ zprovozněte webové rozhraní pro čtení a posílání pošty.
    • Webové rozhraní bude fungovat pro uživatele test s výše uvedeným heslem.
Hodnocení:
  • základní část:
    • Mail poslaný na adresu pv090@pv090.fi.muni.cz z erigony na port SMTP počítače alpha přijde na adresu pv090@fi.muni.cz s očekávanou cestou v hlavičkách Received:
    • Mail poslaný na adresu test@pv090.fi.muni.cz z erigony na port SMTP počítače alpha projde na počítač beta a je možno jej vyzvednout protokolem IMAP nebo POP3.
    • Na firewallu povolit příslušné porty (SMTP/SMTPs na obou strojích, POP3/POP3S a IMAP/IMAPS na počítači beta).
  • hodnocená část:
    • 3 body: výše uvedené je funkční i pro adresu pv090@protoXY.pv090.fi.muni.cz, resp. test@protoXY-beta.pv090.fi.muni.cz i pro XY jiné než vaše číslo.
    • 1 bod: funkční IMAP i POP3.
    • 2 body: oba počítače nefungují jako open relay (například při pokusu o poslání zprávy na adresu pv090@fi.muni.cz z erigony na port SMTP příslušného počítače)
    • 1 bod: správně nakonfigurované SPF záznamy na vašem DNS serveru
  • bonusová část:
    • 1 bod: greylisting na počítači alpha, pro snadnější kontrolu s timeoutem jen 2 minuty.
    • 1 bod: SSL pro POP3 nebo IMAP s certifikátem od vaší CA, znějícím na správné jméno.
    • 1 bod: SSL pro SMTP s certifikátem od vaší CA, znějícím na správné jméno.
    • 1 bod: konfigurace pošty v Ansible (nebo jiném systému pro správu konfigurace)
    • 2 body: webový přístup k poště funguje podle zadání.

WWW, HTTP servery

Obsah:
Protokol HTTP (příklad komunikace, metoda GET, metoda POST). HTTP server Apache. Konfigurace, moduly, virtuální servery. SSL vrstva (certifikáty, problém s virtuálními servery). CGI skripty. Alternativní HTTP servery. Problém detekce kódování a jazyka, multiviews, HTTP hlavičky versus HTTP-EQUIV v HTML, nastavení v konkrétním HTTP serveru. Autentizace (basic autentizace, cookies). Moderní rozšíření protokolu HTTP (SPDY). Range request. HTTP proxy cache servery (princip fungování, vazba na SSL).
Úkol:
Na počítači alpha zprovoznit HTTP server, který bude poskytovat následující dokumenty:
  • Na adrese http://protoXX.pv090.fi.muni.cz/test.html bude podle preference klienta zobrazen tento český nebo tento anglický dokument. Server bude v HTTP hlavičkách poskytovat korektní informaci o jazyce a kódování. Česká varianta dokumentu musí navíc být dostupná v kódováních UTF-8 a ISO 8859-2 podle preferencí klienta. Anglická stačí jen v UTF-8.
  • Na adrese https://protoXX.pv090.fi.muni.cz/secure/ bude při použití basic autentizace s přihlašovacím jménem pv090 a heslem test dostupný tento dokument (bez basic autentizace nikoliv). Server by měl mít certifikát znějící na správné jméno, podepsaný vlastní certifikační autoritou. Zároveň by server měl poskytovat řetěz certifikátů až ke kořenové CA erigony.
  • Na adrese http://protoXX-alpha.pv090.fi.muni.cz/test.html bude tento dokument, zpřístupňěný se správnými HTTP hlavičkami ohledně jazyka a kódování.
  • Na adrese http://protoXX.pv090.fi.muni.cz/datum.cgi bude dostupný dokument typu text/plain obsahující aktuální čas od epochy jako jedno celé číslo na jednom řádku.
  • URL tvaru http://protoXX.pv090.fi.muni.cz/alpha/zbytek_url budou trvale přesměrována (permanent redirect) na adresu http://protoXX-alpha.pv090.fi.muni.cz/zbytek_url.
  • Na adrese http://protoXX.pv090.fi.muni.cz/crl/revoked.crl zpřístupněte seznam revokovaných certifikátů své certifikační autority. Nechte vystavit nový certifikát pro svoji CA, obsahující i odkaz na CRL.
  • Na adrese https://protoXX-alpha.pv090.fi.muni.cz/test.html zobrazte stejný obsah jako na http://protoXX-alpha.pv090.fi.muni.cz/test.html s vystavením certifikátu znějícím na správné jméno, podepsaným vaší CA. Tento certifikát následně revokujte.
Hodnocení:
  • základní část:
    • Na adrese http://protoXX.pv090.fi.muni.cz/ (IPv4 i IPv6) poslouchá HTTP server a odpovídá na dotazy.
    • Na adrese https://protoXX.pv090.fi.muni.cz/ (IPv4 i IPv6) poslouchá HTTPs server a odpovídá na dotazy
  • hodnocená část:
    • 1 bod: výběr jazyka podle preferencí klienta funguje na testovacím dokumentu dle zadání.
    • 1 bod: výběr kódování podle preferencí klienta funguje na testovacím dokumentu dle zadání.
    • 1 bod: basic autentizace funguje podle zadání.
    • 1 bod: HTTPs server má správný certifikát.
    • 1 bod: adresa http://protoXX-alpha.pv090.fi.muni.cz/test.html funguje podle zadání (funkční virtuální server).
    • 1 bod: přesměrování je funkční podle zadání.
    • 1 bod: dynamická stránka datum.cgi funguje podle zadání.
    • 1 bod: konfigurace HTTP serverů v Ansible (nebo jiném systému pro správu konfigurace)
  • bonusová část:
    • 1 bod: certifikát CA obsahuje korektní záznam o umístění CRL.
    • 1 bod: na uvedené adrese je korektně podepsaný CRL.
    • 1 bod: na adrese https://protoXX-alpha.pv090.fi.muni.cz/test.html běží HTTPS server s obsahem podle zadání a revokovaným certifikátem.

SNMP a monitoring sítě

Obsah:
Protokol SNMP. Strom MIB-2, OIDs a jejich překlad na jméno. Autentizace v SNMP (v1, v2c, v3). Metody SNMP (get, set, getBulk ...). SNMP trap. Konfigurace SNMP démona (například net-snmp) včetně autentizace. Generování grafů na základě SNMP veličin (například program MRTG). Obecné generování grafů (RRDtool a jeho nadstavby, např. Cacti nebo Torrus). Sledování chybovosti sítě pomocí SmokePing. Software pro monitorování síťových služeb (například Nagios, Zabbix, netdisco). Další nástroje: arpwatch, ndpmon.
Úkol:

Na počítač alpha nainstalujte SNMP agenta tak, aby poskytoval pod komunitou public odkudkoli jen tyto informace:

  • informace o systému (strom system.*)
  • informace o provozu vnějšího síťového rozhraní (toho s adresou v 10.0.0.0/24, resp. fd00:dead:beef::/64)
  • informace o třech naposledy přihlášených uživatelích (login, terminál, hostname, čas přihlášení, čas odhlášení ve stejném formátu, jako vypisuje program last(8)) na OID s názvem NET-SNMP-EXTEND-MIB::nsExtendOutLine."lastuser".1..."lastuser".3

Z erigony a z počítače alpha samotného pod komunitou pv090 zpřístupněte vše výše uvedené a navíc informace o všech síťových rozhraních počítače alpha.

Nakonfigurujte na stroji alpha Nagios nebo podobný monitorovací systém s následujícími vlastnostmi:

  • sledování SSH a DNS na všech strojích v laboratoři (včetně Erigony)
  • upozornění na výpadek e-mailem na adresu root@...-beta.pv090.fi.muni.cz
  • webový front-end s autentizací jménem pv090 a heslem test, běžící na adrese https://protoXX.pv090.fi.muni.cz/monitoring
  • přes webový front-end umožnit uživateli pv090 zadávat akce jako například plánování výpadku nebo explicitní vyžádání kontroly
  • evidovat korektní topologii sítě a z ní plynoucí závislosti mezi jednotlivými počítači v laboratoři (například virtuální stroj závisí na jeho fyzickém stroji)

Software pro kreslení grafů síťového provozu (např. MRTG) tak, aby kreslil grafy obou rozhraní počítače alpha a všech vnějších rozhraní ostatních strojů alpha v laboratoři. Grafy nechť jsou dostupné na adrese https://protoXX.pv090.fi.muni.cz/grafy.

Hodnocení:
  • základní část:
    • Z erigony funguje SNMP přístup s komunitou public a zobrazuje aspoň strom system
    • Na požadovaném URL běží webový front-end k monitorovacímu systému, ve kterém je aspoň jedna monitorovaná služba
    • Beží software pro kreslení grafů síťového provozu a kreslí aspoň jeden graf
  • hodnocená část:
    • 1 bod: SNMP agent poskytuje informace o posledních třech přihlášených uživatelích podle zadání
    • 1 bod: SNMP agent zobrazuje s komunitou public z erigony vše podle zadání a nic navíc
    • 1 bod: SNMP agent zobrazuje s komunitou pv090 z erigony vše podle zadání a nic navíc
    • 1 bod: monitorovací software obsahuje všechny sledované stroje a služby podle zadání
    • 1 bod: v monitorovacím software jsou správně nastaveny závislosti mezi stroji (topologie sítě)
    • 1 bod: funguje zadávání příkazů přes autentizovaný webový front-end
    • 1 bod: při výpadku služby (například SSH na stroji beta se pošle informační mail
    • 1 bod: software pro kreslení grafů obsahuje všechny požadované grafy
  • bonusová část:
    • 2 body: pod uživatelem pv090 a heslem testtest zpřístupněte protokolem SNMPv3 totéž co má komunita pv090. Povolte autentizaci se šifrou AES a hashem SHA1, zakažte DES a MD5.
    • 2 body: informace o síťovém provozu zpřístupněte i s 64-bitovými počítadly a tato využijte při kreslení grafů

Databáze uživatelů, PAM a LDAP

Obsah:
Autentizace v UNIXu, soubory passwd a shadow, ukládání hesel. Systém PAM (napojení dalších autentizačních mechanismů, konfigurace, zpětná kompatibilita). Vybrané zajímavé PAM moduly. Další autentizační systémy: jednorázová hesla (OPIE, S/Key, Google Authenticator), dvoufázová autentizace (HW klíče, otisky prstů).
NSSwitch a alternativní zdroje dat pro systémové databáze (LDAP, SQL, NIS, ...). Cachování dat (nscd, nsd, sssd).
Co je to LDAP. Directory services. Jak vypadá a co je to: strom objektů, LDAP Schema. Nástroje na práci s LDAP (ldapsearch, ldapadd, ...). OpenLDAP, základní nastavení (konfigurační soubory versus LDAP objekty). Unixoví uživatelé v LDAPu (PosixAccount, ShadowAccount). MigrationTools. Spolupráce se SASL. Přístupová práva k jednotlivým objektům LDAP serveru, replikace. LDAP a ukládání hesel.
Úkol:

Nakonfigurujte na počítači alpha PAM tak, aby vždy po přihlášení měl uživatel nastavenou proměnnou prostředí PV090 na hodnotu test.

Na počítači alpha nakonfigurujte LDAP server.

  • Vytvořte strom objektů se suffixem dc=pv090,dc=fi,dc=muni,dc=cz.
  • V podstromu ou=PeoplePV090 vytvořte objekt uid=pv090ldap, popisující UNIXový účet s UID 4242; jako heslo nastavte "LDAP090".
  • LDAP server musí odpovídat i na anonymní dotazy z erigony.
  • Vytvořte na stroji alpha soubor /home/pv090ldap/pokus vlastněný uživatelem pv090ldap.

Na obou počítačích nakonfigurujte NSSwitch tak, aby bral informace o uživatelích z lokálních tabulek i z LDAPu a umožněte přihlášení uživatele pv090ldap, který bude zaveden jenom v LDAPu.

Na počítači beta zprovozněte záložní LDAP server a nakonfigurujte replikaci dat z počítače alpha.

V případě zájmu vyzkoušejte konfiguraci jednorázových hesel (jako dvoufaktorovou autentizační metodu).

Hodnocení:
  • základní část:
    • Na stroji alpha běží LDAP server a obsahuje objekt uid=pv090ldap,ou=PeoplePV090,dc=pv090,dc=fi,dc=muni,dc=cz
    • Ve výpisu programu ls -l /home/pv090ldap/pokus se korektně překládá UID u souborů vlastněných uživatelem pv090ldap na jeho login
  • hodnocená část:
    • 1 bod: na stroji alpha má uživatel po přihlášení nastavenou proměnnou prostředí PV090 podle zadání
    • 1 bod: funguje přihlášení uživatele pv090ldap s heslem ze zadání
    • 1 bod: LDAP server je dostupný po IPv4 i IPv6
    • 2 body: LDAP server je dostupný taky jako LDAPS a klienti fungují včetně ověřování certifikátu LDAP serveru
  • bonusová část:
    • 1 bod: funguje replikace databáze LDAPu
    • 1 bod: fungují jednorázová hesla podle zadání

Kerberos, synchronizace času po síti

Obsah:
Kerberos: princip fungování třístranné autentizace. Základní pojmy (realm, principal, lístek, stash, KDC, TGT, single sign-on). Komunikační protokol (co je v které fázi kam zasíláno, závislost na přesném čase). Implementace (MIT, Heimdal a jejich kompatibilita). Replikace dat, vazba na DNS, cross-realm trust. Uživatelské utility. Udržování přesného času v síti: dostupné protokoly (NTP, time/rdate), hardware pro přesný čas, NTP pool.
Úkol:

Zajistěte pro oba své stroje synchronizaci systémového času (použijte protokol NTP a časový server time.fi.muni.cz nebo 1.cz.pool.ntp.org). Na obou strojích musí běžet NTP démon a odpovídat na dotazy z erigony.

Na stroji alpha zprovozněte KDC pro realm PROTOxx.PV090.FI.MUNI.CZ.

  • Do databáze hesel zaveďte uživatele pv090 s heslem "T26k0Heslo".
  • Jako lokální heslo (v shadow) nastavte tomuto uživateli "L0calPa33".
  • Nakonfigurujte SSH tak, aby se uživatel pv090 na počítači alpha mohl bez hesla (jen za použití TGT) přihlásit pod stejným jménem i na počítač beta.

Na obou strojích umožňěte přihlášení tohoto uživatele přes SSH a změnu jeho kerberos hesla příkazem passwd (poznámka: kpasswd nestačí).

Na stroj beta nainstalujte KDC a replikujte na něj databázi kerbera ze stroje alpha pro váš realm. Pozor - obvyklý problém bývá s použitím správného hostname v principalu pro synchronizaci: měl by to být hostname, na který se mapuje příslušná IP adresa, ze které přichází požadavek na replikaci.

Hodnocení:
  • základní část:
    • Na stroji alpha běží KDC pro správný realm a je možno příkazem kinit získat lístek pro uživatele pv090.
    • Oba stroje mají systémový čas zjistitelný protokolem NTP z erigony, který se liší od erigony o nejvíce 5 vteřin.
    • Oba stroje mají správně nastavenou časovou zónu.
  • hodnocená část:
    • 1 bod: na obou strojích běží NTP démon, je nakonfigurován a je synchronizován s nakonfigurovanými servery (viz příkaz peers uvnitř programu ntpdc)
    • 1 bod: je možno se přihlásit přes SSH jako uživatel pv090 s kerberovým heslem i s lokálním heslem
    • 1 bod: je možno uživateli pv090 změnit kerberové heslo příkazem passwd a následně se i s novým heslem přihlásit
    • 1 bod: uživatel pv090 se umí mezi počítači alpha a beta přihlašovat bez hesla, jen s pomocí TGT
  • bonusová část:
    • 1 bod: funguje replikace databáze kerbera aspoň z příkazové řádky
    • 1 bod: funguje automatická inkrementální replikace při změně hesla
    • 1 bod: v DNS jsou korektní informace o nastavení Kerbera pro váš realm a klienti tyto informace používají

Klasifikace provozu sítě

Obsah:
Klasifikace provozu na síti. Prioritizace datových toků. QoS v IPv4 a IPv6. Fronty packetů (RED/WRED, CBQ, TBF, HTB, SFQ, WFQ, Prio), jejich základní vlastnosti a konfigurační parametry. Bufferbloat - co to je, možná řešení (adaptive queue management). Problematika omezení šířky pásma na vstupním rozhraní. Rozdělení zátěže přes více rozhraní. Modelování síťové zátěže a způsoby monitorování okamžitého průtoku dat (iftop, iptraf, ...).
Úkol:

Na počítači alpha nakonfigurujte omezení propustnosti linky k počítači beta na 1 Mbps (Mbps = megabit za sekundu). V rámci této šířky pásma nastavte priority provozu následovně:

  • Z počítače erigona na počítač beta bude mít provoz nejvyšší prioritu, ale bude omezený na 0.5 Mbps.
  • Z počítače ftp.fi.muni.cz dejte nižší prioritu než provozu z erigony a omezte jej na 768 kbps.
  • Ostatnímu provozu nechte nejnižší prioritu bez dalšího omezení.

Požadovanou konfiguraci uložte do samostatného init-skriptu podle použité distribuce.

Poznámka: všimněte si, že kapacity výše uvedených datových toků dávají v součtu více, než je celková požadovaná kapacita linky. Zajistěte, aby při kombinaci více datových toků byl dodržen i tento celkový limit.

Příklad rozdělení šířky pásma, pokud každý z aktivních toků bude ochoten vysílat libovolně velkou přidělenou rychlostí:

Přidělená šířka pásma [kbps]
Aktivní tokyerigonaftp serverostatní
erigona512
ftp server768
ostatní1024
erigona, ftp server512512
erigona, ostatní512512
ftp server, ostatní768256
erigona, ftp server, ostatní512512cca 0
Hodnocení:
  • základní část:
    • Funguje klasifikace provozu tak, že provoz z erigony a z ftp.fi.muni.cz (každý zvlášť) je omezený na požadovanou šířku pásma.
  • hodnocená část:
    • 1 bod: konfigurace se zavádí a ruší korektním init-skriptem
    • 2 body: žádná kombinace datových toků nepřekračuje celkovou kapacitu linky
    • 1 bod: fungují správně priority jednotlivých tříd provozu
  • bonusová část:
    • 2 body: funguje i pro IPv6 například z erigony

Síťové souborové systémy

Obsah:

Co je to Samba, protokol CIFS (protokol verze 1 a 2). Součásti balíku Samba, konfigurace serveru - globální nastavení, sdílení disků a tiskáren, spolupráce se světem Windows (Samba jako domain controller, jako člen domény, ...). Sdílení hesel mezi Windows a UN*Xem. Konfigurace klienta pod Linuxem (SMBFS, CIFS).

Co je to RPC, portmapper/rpcbind. Vlastnosti systému NFS (zamykání, cachování, atd.). Verze systému NFS (v3, v4, v4.1). NFS server (démoni, konfigurační soubory). NFS klient - autentizace (Kerberos). Automounter - vlastnosti, konfigurace.

Další síťové souborové systémy (AFS, GFS, GlusterFS, Ceph/CephFS ...).

Úkol:
  • Na počítači alpha a beta vytvořte uživatele pv090nfs s UID 9999 a uživatele pv090smb s UID 7777, ke kterým se jde přihlásit pomocí SSH klíče z erigony.
  • Na počítači alpha zprovozněte NFS server verze 3 nebo novější. Vyexportujte pro počítač beta domovský adresář uživatele pv090nfs (/home/pv090nfs) jako read/write a pro erigonu tentýž adresář read-only.
  • Na počítači alpha zprovozněte Samba server, který bude nabízet pod jménem pv090smb domovský adresář uživatele pv090smb (/home/pv090smb) read/write aspoň pro počítač beta a erigona. SMB heslo uživatele nastavte na pv090test.
  • Na počítači beta nakonfigurujte automounter tak, aby automaticky připojoval domovský adresář uživatele pv090nfs pomocí protokolu NFS z počítače alpha a domovský adresář uživatele pv090smb protokolem SMB/CIFS z počítače alpha.
Hodnocení:
  • základní část:
    • K uživatelům pv090nfs a pv090smb se jde přihlásit z erigony pomoci SSH klíčů na obou strojích.
    • Z počítače beta je možno připojit přes NFS domovský adresář uživatele pv090nfs.
    • Z počítače beta je možno připojit přes SMB/CIFS domovský adresář uživatele pv090smb.
  • hodnocená část:
    • 1 bod: domovský adresář uživatele pv090nfs funguje přes NFS read-write se správnými UID na obou stranách.
    • 1 bod: domovský adresář uživatele pv090smb funguje přes SMB/CIFS read-write se správnými UID na obou stranách.
    • 1 bod: na počítači beta je nakonfigurovaný automounter pro oba domovské adresáře podle zadání.
    • 1 bod: NFS se používá nad IPv6
    • 1 bod: SMB/CIFS se používá nad IPv6
  • bonusová část:
    • 2 body: přístup přes NFS je zabezpečený autentizací přes Kerbera
    • 1 bod: NFS se používá ve verzi 4

IPv6 - pokročilé vlastnosti

Obsah:

Pokročilé vlastnosti: autokonfigurace (stavová vs. bezstavová, bezpečnostní aspekty). Mobilita. IPsec, distribuce klíčů, AH a ESP hlavička, transportní a tunelovací režim.

Úkol:
  • Na počítači alpha nainstalujte a nakonfigurujte DHCPv6 server, který bude poskytovat konfiguraci pro počítač beta. Na počítači alpha posílejte do rozhraní směrem k počítači beta oznámení směrovače (RA) s cestou přes počítač alpha. Samo DHCPv6 by nemělo oznamovat směrovač pro danou síť, tato informace by měla být předána přes RA.
  • Počítač beta nakonfigurjte, aby místo statické IPv6 adresy používal dynamickou konfiguraci sítě, získanou z RA a DHCPv6.
  • Nakonfigurujte spoj mezi počítači alpha a beta jako zašifrovaný (ESP) pomocí IPSEC.
Hodnocení:
  • základní část:
    • Funguje síť mezi počítači alpha a beta.
    • Počítač beta má dynamicky přidělenou IPv6 adresu.
  • hodnocená část:
    • 1 bod: Počítač beta má správně default gateway pro IPv6.
    • 2 body: Zašifrovaná komunikace mezi počítači alpha a beta dle zadání..
  • bonusová část:

Zálohování

Obsah:
  • Typy zálohování (ad-hoc, plné, inkrementální, ...)
  • Úložiště pro zálohy (disk, NAS, "cloud", páska)
  • Nástroje a jejich porovnání (rsync a nástroje nad ním, tar/cpio/dump+recover, Clonezilla, Bacula, Amanda)
  • Bezpečnost záloh (šifrování, bezpečnost přenosu po síti)
Úkol:

Na počítači alpha nainstalujte a zprovozněte zálohovací software pro zálohování konfiguračních souborů (zejména adresář /etc) a databází LDAPu a Kerbera ze strojů alpha a beta. Zálohy vytvářejte také inkrementálně. Udržujte minimálně jednu plnou zálohu a tři inkrementální. Pamatujte na to, že LDAP i Kerberos mohou kdykoli i během zálohování obsah databáze měnit. Vysvětlete, jak pro tyto systémy zajišťujete konzistenci záloh.

Hodnocení:
  • základní část:
    • Funguje vytvoření plné zálohy konfiguračních souborů na stroji alpha.
  • hodnocená část:
    • 1 bod: Funguje zálohování po síti ze stroje beta.
    • 1 bod: Funguje inkrementální zálohování na obou strojích.
    • 2 body: Záloha LDAPu a Kerbera má zajišťenou konzistentnost i při zápisu během zálohování.
  • bonusová část:
    • 1 bod: Záloha stroje beta je šifrovaná tak, aby ji ze stroje alpha nebylo možno přečíst.

Distribuované souborové systémy

Obsah:
  • Co jsou distribuované souborové systémy (DFS). Problematika přístupu k metadatům DFS (centralizované vs. distribuované, algoritmicky).
  • Replikace v DFS. Řešení výpadků (split-brain). Výkon jednotlivých operací v DFS, potvrzování zápisů. Vyvažování zátěže: umisťování dat na jednotlivé uzly.
  • GlusterFS, elastic hash algorithm. Podporované vlastnosti GlusterFS. Režimy fungování: distribuovaný, replikovaný, stripovaný.
  • Ceph. Ceph FS, RADOS, RBD (RADOS block device). CRUSH algoritmus. Typy uzlů: OSD, MDF a Monitor.
Úkol:

Nakonfigurujte na strojích alpha a beta DFS tak, aby na obou strojích byl dostupný jako adresář /dfs-rw v režimu read-write. Data by měla být replikována na oba stroje. Výpadek jednoho stroje by neměl způsobit nedostupnost dat.

Hodnocení:
  • základní část:
    • na stroji alpha a beta bezi DFS
    • na jednom ze strojů (alpha nebo beta) je možné se k DFS připojit v režimu R/W
  • hodnocená část:
    • 1 bod: na obou strojích je možno daný systém připojit read/write.
    • 1 bod: při výpadku jednoho konkrétního stroje (alpha nebo beta) je možno se i nadále k DFS připojit.
  • bonusová část:
    • 1 bod: je možno dynamicky (za běhu DFS) měnit úroveň replikace.
    • 1 bod: Výpadek kteréhokoli stroje nezpůsobí výpadek celého FS ani na úrovni čtení, ani na úrovni zápisu.

Povinné řízení přístupu (SELinux, AppArmor)

Obsah:
  • Povinné a volitelné řízení přístupu (MAC a DAC).
  • Popis fungování SELinuxu: co je to label, systémová politika, lokální politika.
  • Ladění: permissive mode, enforcing mode.
  • Vytváření vlastní politiky v SElinuxu.
  • Jine systémy pro povinné řízení přístupu v UNIXu a Linuxu: AppArmor a popis jeho fungování.
  • Vytvareni profilu v AppArmor.
Úkol:

Na jednom stroji zprovozněte systém povinného řízení přístupu (např. SELinux nebo AppArmor) a zabezpečte, aby tento systém fungoval i během bootu OS.

Stáhněte si testovací program, který po přeložení a spuštění dělá "konverzi dat" v zadaném adresáří. Omezte tento program bezpečnostní politikou tak, aby vstupní i výstupní soubor musel být pouze z určitého adresáře (jiný pro vstup a jiný pro výstup; zvolte adre sář, který v systému doposud nebyl), a aby program nesměl dělat nic jiného než se očekává.

Pokud program funguje, zkuste přeložit testovací program s volbou -DPROBE_SECURITY a ověřte, že po spuštění program není schopen jiné akce (čtení /etc/passwd, spuštění shellu přes exec(2), otevření síťového spojení, ... ), než je konverze dat v zadaném adresáři.

Hodnocení:
  • základní část:
    • na jednom stroji funguje systém povinného řízení přístupu (např. SELinux nebo AppArmor) v aktivnim/enforcing modu
  • hodnocená část:
    • 4 body: vlastní bezpečnostní politika/profil k dodanému testovacímu programu, která omezuje vykonávání nedovolených akcí.

Public Key Infrastructure

Obsah:
  • Co je PKI, certifikáty a certifikační autority.
  • Důvěryhodné CA a jejich instalace do systému.
  • Nástroje pro práci s certifikáty (OpenSSL).
  • DANE jako alternativa PKI.
  • Vytvoření self-signed certifikátu, atributy certifikátu.
  • Vlastní certifikační autorita. Konfigurace, vystavení certifikátu, revokace certifikátu. Protokoly pro zveřejňování informace o revokacích.
Úkol:
  • Vytvořte si vlastní certifikační autoritu. Vytvořte žádost o certifikát pro tuto certifikační autoritu a umístěte ji do souboru /root/pki/ca.csr na stroji alpha. Pro žádost o certifikát nastavte následující atributy:
    • Organization unit: PV090
    • Organization name: protoXX-ca
    • Common name: protoXX-ca
    • e-mail: ca@protoXX.pv090.fi.muni.cz
    • Typ klíče: RSA, alespon 2048 bitů
    • Typ podpisu: SHA256 nebo SHA512
  • Erigona vám vygeneruje certifikát do souboru /root/pki/ca.crt
  • Do souboru /root/pki/erigona.crt bude umístěn certifikát CA erigony jako nadřazené certifikační autority.
  • Certifikační autoritu erigony umístěte do systému na potřebná místa tak, aby certifikáty vydávané touto autoritou i vaší CA byly systémem povážovány za důvěryhodné.
Hodnocení:
  • základní část:
    • Na daném místě existuje žádost o certifikát CA.
    • Žádost má korektní atributy O, OU, CN a e-mail podle zadání.
  • hodnocená část:
    • 2 body: žádost má správné technické parametry (typ podpisu, délku a typ klíče)
    • 2 body: certifikáty CA jsou umístěny v systému na správných místech.

Automatizovaná správa serverů

Obsah:
  • Přehled dostupných nástrojů (ansible, chef, puppet, terraform, ...)
  • Idempotentní konfigurace. Popis konfigurace uložený v Gitu.
  • Podrobnější popis jednoho z nástrojů:
    • Základní nastavení, seznam spravovaných strojů, autentizace
    • Změny konfiguračních souborů, restarty služeb při změně.
    • Složitější aktivity - provázané restarty služeb, rebooty systému, závislosti jednoho systému na jiném, atd.
  • Read-only systémy (CoreOS, Atomic, ...).
Úkol:
  • Vyberte si jeden z dostupných nástrojů pro automatizovanou zprávu. Zařaďte do něj oba dva vaše stroje (alpha i beta).
  • Přeneste do tohoto nástroje konfigurace věci, které jste dosud na svých strojích konfigurovali: statická konfigurace sítě, SSH klíče, uživatele/skupiny, atd.
  • Vyzkoušejte, že po odinstalování příslušných služeb a smazání konfiguračních souborů je nástroj schopen služby opět zprovoznit.
  • Nakonfigurujte akci "aktualizace systémových balíčků" a "restart stroje beta".
Hodnocení:
  • základní část:
    • Administrační nástroj funguje a vidí oba systémy (SSH klíče a podobně).
  • hodnocená část:
    • 1 bod: reinstalace SSH klíčů
    • 1 bod: aktualizace systémových balíčků
    • 1 bod: restart stroje beta

Ladění výkonu (performance tuning)

Obsah:
  • Co je úkolem performance tuningu? Nástroje pro základní přehled (top(1), free(1), uptime, ...
  • Sledování konkrétních procesů: strace(1) ltrace(1), použití DWARF/CTF debuginfo
  • perf(1) - analýza "hot paths", cache misses, latence I/O operací, TCP retransmity, stack traces, flame graphs, ...
  • eBPF: popis, nástroje jako bcc a bpftrace, vlastnosti eBPF programu (ukládání dat - mapy, ...), příklady použití.
Úkol:
  • Zvolte si některou z činností, kterou vaše počítače protoXY a protoXY-beta provádějí. Sestavte zátěžový test této činnosti (například ab(1) pro HTTP server zpracovávající CGI aplikaci).
  • Analyzujte, co je úzkým místem dané aplikace. Na základě analýzy upravte konfiguraci aplikace (počet procesů, ...) a vyzkoušejte jaký má vliv rekonfigurace hardwaru (více paměti, více CPU, ...).
  • Svoje zjištění sepište strukturovaným způsobem (HTML stránka s tabulkami). Diskutujte i opakovatelnost měření.
Hodnocení:
  • základní část:
    • Popis konfigurace zátěžového testu, výchozí hodnoty, diskuse opakovatelnosti měření.
  • hodnocená část:
    • 2 body: zhodnocení vlivu rekonfigurace hardwaru
    • 3 body: návrh změn konfigurace, zhodnocení toho, jaký efekt toto má
    • 1 bod: prezentační stránka celého problému

Archív referátů