Kontrolní seznam pro nový server (diskuse)

[Jendа]

Já se zaměřuji hlavně na opravu tzv. moderních vlastností.

• Přidat distribučnímu jádru parametry nosplash nomodeset a odebrat parametr quiet (proč to tam proboha všichni dávají?!)
• Zakázat GFX v GRUBu.
• Stroj, který po jednom přerušeném bootu zůstane navždy viset v GRUBu, fakt potěší. Jak tohle mohl někdo udělat jako default?

[Bystroushaak]

Stroj, který po jednom přerušeném bootu zůstane navždy viset v GRUBu, fakt potěší. Jak tohle mohl někdo udělat jako default?

Ah, díky. Tohle mě pálilo docela dlouho.

[Halis]

Ten Mercurial na /etc používáš přes etckeeper? Pokud ne tak doporučuji.

[xkucf03]

Zatím ne Verzovat jsem to začal ručně, ještě než jsem o nějakém etckeeperu věděl, a pak nebyla až taková motivace na něj přejít. Prostě dám hg commit -m "co jsem změnil" a hotovo Ten cron je tam pro jistotu, kdyby se v tom šťoural někdo jiný, kdo na to není zvyklý, tak se to aspoň zaverzuje jednou denně automaticky.

Když nad tím tak přemýšlím, tak jsem tu historii zatím nikdy nepotřeboval… Ale hodně užitečné je znát, co se změnilo od poslední verze – když zjistíš, že služby s novou konfigurací nenabíhají, tak to nemusíš ve stresu přepisovat zpátky a dáš prostě jen hg revert nebo přes diff snadno zjistíš, které řádky je potřeba opravit.

Možná ho zkusím. Dokáže se ujmout /etc, ve kterém už .hg je a začít ho používat?

[Pavel Píša]

U mě zásadně etckeeper a povolit

AVOID_DAILY_AUTOCOMMITS=1

AVOID_COMMIT_BEFORE_INSTALL=1

v /etc/etckeeper/etckeeper.conf.

To každého vychová všechny změny kontrolovat a popsat do logu.

[xkucf03]

Jak je to vychová? Může jim etckeeper nějak zabránit v editaci konfiguráků a neverzované správě systému?

Když už někdo ty změny zapomene zdokumentovat (udělat hg commit), tak mi přijde lepší, když se to zaverzuje aspoň automaticky jednou denně a víme, kdy se to zhruba změnilo (a podle logů možná i kdo to změnil), než mít nashromážděných spoustu nesouvisejících změn třeba za měsíc, kdy si konečně někdo vzpomene, že by se mělo verzovat.

[Pavel Píša]

Dokud se nazakomituje, tak nejde přes aptitude atd. instalovat/updatovat/zrušit žádný balíček. Zároveň je zajištěné, že se nesmíchají změny způsobené automatickou instalací do jednoho commitu s lokální změnou. Pokud je pak někde uložený

aptitude search '?installed?not(?automatic)' \ | sed -n -e 's/^i[ \t]\+\([^ \t]*\)[ \t].*$/\1/p' >packages

a ideálně je git automaticky pushovaný na záložní server, tak restaurace systému odpovídá

aptitude install `cat packages`

a projití nebo přímo naaplikování změn, které nebyly automatické. Problém jsou nastavení provedené přes dialogy během automatické instalace/zamíchají se s masivními změnami a pohyby souborů v etc. Proto sám vždy odklepávám default a teprve po dokončení instalace končící automatickým commitem znova vyvolám dpkg-reconfigure na dané balíčky a změnu pak pěkně vidím samotnou a s odpovídajícím popisem ji commituji.

Jako vše, i tento postup má své mouchy, na hodně podobných serverů bych i já asi přešel na puppet tak, jak to dělá náš správce serverů. Ale pokud se jedná o počítač který využívá (včetně doinstalace SW) více soudných a znalých lidí (dříve i rootfs pro laborky) a správu udělá ten, který změnu potřebuje, tak je etckeeper ideální. Spravovali jsme takto v podstatě ve třech systém pro laboratoře roky a chodilo to dobře. Vše bylo dokumentované a i při přechodu správce IT na puppet z commitů většinu relativně komplikovaných konfigurací dostal - distribuovaný rootfs s úpravami práv, autentizací proti různým serverům po škole, skripty pro speciální režim při bootu stroje ve virtuálu jako externě dostupná brána pro studenty atd. V etc. virtuálního serveru pak doprava NFS za NATy jednotlivých učeben, licenční servery. Vlastní hostitel všeho pak měl také určité množství úprav, ale o ten se staral již téměř výhradně správce (Aleš Kapica). Každý z těch, co úpravy podle aktuálních potřeb řešili pak měl ve svém profile nastavené GIT_AUTHOR_NAME a GIT_AUTHOR_EMAIL a názvy těchto proměnných byly v sudo env_keep. Takže po přihlášení na server a sudo nebo i chrootu do distribuovaného rootfs za sebou každý nechával v commitech době čitelnou stopu. Jasně, že když by chtěl, tak mohl podvádět a vydávat se za někoho jiného, ale opravdu nejsme malé děti, aby jsme si přidělávali práci, té skutečně tvořivé máme už teď tolik, že by nám stačila do důchodu.

Ale zpět k tomu tlaku na pořádek, když něco potřebuji nainstalovat a správce balíčků tvrdohlavě trvá na tom, že se nejdříve musí změny nacommitovat, jinak pracovat nebude, tak je to dobrá motivace. A i kdyby se vše mezi dvěma automatickými updaty od správce balíčků vložilo i jen do jednoho commitu, který se však od automatických pozná, tak je to pokrok. Zároveň tam zbude jméno, takže lze osobě vyčinit za to, že necommitovala po logických celcích. A vzhledem k tomu, že při vývoji SW v desítkách, možná stovce a více gitů, co používáme, musíme nějakou kulturu dodržovat, jinak by se nám projekty zcela rozpadly a nikdo by o naši práci nestál, tak ta trocha slušného chování při správě serverů není problém. A jasně, když není věc urgentní, tak jí dělá správce nebo se dohodne, kdo třeba pro hlubší znalosti o daném problému, věc otestuje, zkusí podle svých časových možností vyřešit, a pak změny zakomituje a časem informuje ostatní. I když teď už je to pravdu na těch veřejnějších službách spíš věc správce, protože se nám alespoň z pohledu potřeb výuky podařilo dojít k řešení, které koncepčně roky drží a lze adaptovat i na zvěrstava a omezení, která nám připraví různé specifické požadavky -- distribuce bootu do laborky pro jiné předměty zcela izolované od veřejné sítě atd.

[xkucf03]

Díky, to zní dobře. Vyzkouším

[KS]

Bash vyměnit za Zsh.

[v6ak]

Šifrování disku na serveru? Jak to funguje, pokud server musí nabootovat i bez lidské interakce a tedy musí mít klíč v plaintextu? Resp. jaký to má potom význam?

Nebo tu mám nějaký chybný předpoklad?

[Jendа]

Nebo tu mám nějaký chybný předpoklad?

Myslím, že máš chybný předpoklad, že server musí nabootovat bez lidské interakce. V nejjednodušším případě je šifrované vše kromě jádra a initramdisku. V initramdisku je ssh server, na který se ty nebo automat připojí a zadá klíč.

Zloděj, který server ukradl, data nedostane. Pokud ale dokáže se serverem nepozorovaně manipulovat a pak ho zase spustit, aby si toho nikdo nevšiml, může do initramdisku například vložit backdoor, který mu zadaný klíč pošle. Nebo si může z initramdisku zkopírovat klíče a udělat Mrkva-in-the-middle.

[xkucf03]

Jen na některých serverech nebo virtuálech… Je to prakticky neřešitelný problém. Význam to má hlavně pro případ běžné krádeže, reklamace disku nebo méně schopného útočníka.

[Šangala]

Mám například jednoho KVM hostitele a trvale (uvnitř) zasunutou flashku a hostitel + jedna virtuálníá mašina nastartuje automaticky ze šifrovaného oddílů (klíč je na té flashce). Další VMs a data jsou na jiném úložišti, které musí být odemknuto (buď vzdáleně, nebo prostým zasunutým jiné flashky).

Význam šifrování, i když je klíč součástí stroje, to má jen pro reklamaci či další putování daného disku/ů.

[Šangala]

K tomu prvnímu, bych doplnil, udev pravidla na MAC a zakázání NM (a jeho případné vypnutí), něco jako:

NM_CONTROLLED=no
BOOTPROTO=none
PEERDNS=no
USERCTL=no

K tomu sedmému: nastavení barev PS1.

K tomu jedenáctému: /tmp do paměti a doplnění relatime

A doplnil bych:

• Ke GRUB-u se Jenda už vyjádřil (+ odstranit rhgb ;))
• Nastavení hodnoty swapiness.
• Kontrola uid uživatele - některé distribuce začínají na 500 jiné na 1000, někdy se hodí mít stejné uid.
• Limits - 'nproc'

[Heron]

V podstatě +- stejné, až na:

firewall zakazující všechno, kromě explicitně uvedených služeb

Osobně mám za cíl nemuset mít firewall žádný, tedy mít nainstalované pouze služby, které musí být dostupné (jejich porty by se ve fw stejně povolily) a zbytek, pokud je nutný, mít nastavený třeba přes unix socket apod. Potom není fw potřeba, povoloval by vlastně stejně vše, co na daném portu poslouchá. Myslím si, že při dobře nastavených a zabezpečených službách není fw potřeba.

instalace základních nástrojů (mc, htop, emacs, java, pv, socat… podle využití serveru)

Od tohoto jsem upustil. Každý server má jiné využití a jinou sadu "základních nástrojů", je tedy zbytečné je tam instalovat dopředu. Jak bude potřeba, on si je admin stejně během pár sekund nainstaluje. Tzn. každý z těch serverů po čase dokonverguje k nějaké vlastní sadě nainstalovaných nástrojů.

[R]

Ano, to je pravda. Zakladom je, aby na vonkajsej IP adrese nepocuvalo nic, co nema. Ja napriek tomu instalujem arno-iptables-firewall - v Debiane to mam za chvilku nainstalovane. Pridava to pocit bezpecia. A ked ma ten server byt ako GW pre lokalnu siet, tak sa to tam na dva kliky zapne.

[Šangala]

…které musí být dostupné (jejich porty by se ve fw stejně povolily)

Některé(většinu) služby instaluji, ale porty neotvírám - je třeba si ssh-tunelovat ANEBO jsou porty na fw povolené jen odněkud či někam.
Mně zas přijde dvou úrovňové zabezpečení a zahození nežádoucího příchozího (ale i odchozího) provozu na fw lepší.

Od tohoto jsem upustil.

Nechtělo se mi to komentovat, ale taky tak, začnu s naprostým minimem a u každého nově instalovaného balíku se krátce zamyslím „opravdu je to třeba!?“.

[xkucf03]

To je pravda, nesmí se to přehánět, ale třeba ten mc a htop jsem zvyklý mít všude. Stejně tak pv se dříve či později hodí. Naopak tu Javu nemám všude (taky tam píšu podle využití serveru). Editor je otázka osobních preferencí…

[Jendа]

Některé(většinu) služby instaluji, ale porty neotvírám - je třeba si ssh-tunelovat

Proč je nenecháš poslouchat jen na loopbacku?

[Šangala]

To můžu taky, (jako dvojitá ochrana). Ale jinak mi přijde flexibilnější to řídit na fw „odkud na co“.

A taky se cítím klidnější, bo pokud jsem danou službu blbě nastavil neprojde to přes fw.

[trekker.dk]

Každý server má jiné využití a jinou sadu "základních nástrojů", je tedy zbytečné je tam instalovat dopředu.

Záleží na tom, o jakých nástrojích tu mluvíme. Třeba instalovat tcpdump, abys zjistil, proč ti nejde síť, když ti nejde síť...

[čavo]

V podstatě +- stejné, až na:

firewall zakazující všechno, kromě explicitně uvedených služeb

Osobně mám za cíl nemuset mít firewall žádný, tedy mít nainstalované pouze služby, které musí být dostupné (jejich porty by se ve fw stejně povolily) a zbytek, pokud je nutný, mít nastavený třeba přes unix socket apod. Potom není fw potřeba, povoloval by vlastně stejně vše, co na daném portu poslouchá. Myslím si, že při dobře nastavených a zabezpečených službách není fw potřeba.

Problém nastáva, keď má na serveri viac ľudí konto. Síce nič na porte nižšom ako 1024 nespustia, pokiaľ neuhádnu heslo na root-a, ale na ostatných portoch môžu spúšťať čo len chcú, pokiaľ to neobmedzíš pomocou FW.

[trekker.dk]

Vytvořit /etc/apt/apt.conf.d/20recommends

APT
{
        Install-Recommends "false";
};

[m-a]

Aj Install-Suggests