Debian szerver alaptelepítés (Wheezy)

Innen: AdminWiki

Ebben a leírásban Debian Wheezy szervergép grafikus felület és specifikus szolgáltatások nélküli alaptelepítését végezzük el. A leírás "bármilyen" szerverre alkalmazható.

Előfeltételek

  • Működő hardver, konzol hozzáférés, tudjon CD-ről bootolni és lásson ki (védett, NAT-olt) hálózaton keresztül az Internetre. DHCP használata ajánlatos.
  • Megfelelő architektúrájú Debian Wheezy netinstall boot CD - 64 bites (Intel) CPU és legalább 2 GB RAM esetén a 64 bites amd64-et használjuk!

Telepítési beállítások

Ez a szakasz a telepítő CD-ről bootolva a telepített rendszer első tényleges indulásáig tart, a védett hálózatra(!) csatlakozó telepítendő gép számára működő Internet kapcsolatot igényel.

Konzolról:

  • Advanced options, Expert install
  • Choose language - Hungarian, Európa, Magyarország.
  • További helyi beállítások - en_US, en_US.UTF-8, en_US.ISO-8859-15, hu_HU - rendszerszintű helyi beállítás hu_HU.UTF-8.
  • Billentyűzet beállítása - magyar.
  • CD-ROM csatolása, telepítő összetevők - network-console
  • Hálózati hardver felderítése, hálózat konfigurálása - általában DHCP, gépnév és domain megadására ügyeljünk!
  • Telepítés folytatása távolról, SSH-n át - a jelszó legyen pl. installerpass :-)
ssh installer@IP.IP.IP.IP # Folytassuk a saját gépről!
  • Telepítő indítása (szakértő mód)
  • Felhasználók és jelszavaik felvétele - Árnyék jelszavak, root belépés engedélyezve, jelszó egyelőre legyen rootpass, sima hozzáférést majd később hozunk létre, mert az admin név a telepítő futásakor foglalt :-).
  • Óra konfigurálása - NTP (tűzfal gátolhatja), időzóna Europe/Budapest.
  • Lemezek észlelése, particionálása - itt mindenféle hitvita lehetséges, de a minimum a boot, root, tmp, var, usr elkülönítése, hogy ezeket más-más paraméterekkel lehessen mountolni. Hagyományos merevlemezt csak redundánsan legalább software RAID-1 vagy RAID-5-ben üzemeltessünk (kivéve csak backup tárterület), SSD-nek (valószínűleg) nem kell RAID.

Particionálási séma két, software RAID-1-ben üzemelő, TB nagyságrendű hagyományos merevlemez esetén

sda sdb md megjegyzés
sda1 200 MB RAID boot sdb1 200 MB RAID boot md0 RAID-1 ext4 /boot boot partíció
sda2 2-4 GB RAID sdb2 2-4 GB RAID md1 RAID-1 [swap] cserehely (0,5x - 1x - 2x RAM)
sda3 2-4-8 GB RAID sdb2 2-4-8 GB RAID md2 RAID-1 ext4 /tmp tmp partíció, akkor érdemes nagyobb mértűre venni, ha backup-restore jellegű műveletek várhatóak.
sda5 4 GB RAID sdb5 4 GB RAID md3 RAID-1 ext4 / root partíció, 2G is elég lehet
sda6 4 GB RAID sdb6 4 GB RAID md4 RAID-1 ext4 /usr usr partíció, 4G általában elég
sda7 1 GB RAID sdb7 1 GB RAID md5 RAID-1 ext4 /srv/chroot opcionális partíció, pl. jail-ben üzemeltetett bind (cache-only DNS szerver) számára.
sda8 X GB RAID sdb8 X GB RAID md6 RAID-1 ext4 /var
(1% fenntartott blokk elegendő)
var partíció, a maradék tárterület (adatbázis, www, Samba, backup, etc. számára). Opcionálisan tovább osztható.

Particionálási séma egy SSD rendszerlemez és két, software RAID-1-ben üzemelő, TB nagyságrendű hagyományos merevlemez esetén

sdb sdc md megjegyzés
sdb1 X GB RAID sdc1 X GB RAID md0 RAID-1 ext4 /mnt/storage
(1% fenntartott blokk elegendő)
szolgáltatási tárterület (adatbázis, www, Samba, backup, etc. számára). Opcionálisan tovább osztható.

TODO!

  • Alaprendszer telepítése - telepítendő rendszermag általános (pl. linux-image-amd64) és nem konkrét alverzió, az initrd általában lehet célzott.
  • A csomagkezelő beállítása - hálózati tükör legyen http, Magyarország, alapértelmezés (ftp.hu.debian.org); a nem-szabad szoftverek is kellenek, valamint a biztonsági- és változékony frissítések is.
  • Szoftverválasztás és telepítés - csomaghasználat felmérése nem kell, a mandb ne legyen SUID-os, a telepíthető szoftverek közül egyik sem kell (Standard system utilities sem!), mert mi okosabbak vagyunk, mint egy ötödikes... :-).
  • GRUB (grub2) telepítése - a fő boot rekordba kerüljön (RAID: TODO!)
  • Telepítés befejezése - rendszeróra UTC szerint járjon, CD ki, reboot.

A frissen telepített rendszer beállításai

Az alábbiakhoz ssh-n, root-ként jelentkezzünk be (más felhasználó még nincs is).

Alap segédeszközök

Az alábbiak közül a felső sor mindenképpen kell, az alsót tekintve kinek a pap, kinek a papné :-).

apt-get install bzip2 less lsof pwgen telnet unzip zip # függőség: Perl alapcsomagok
apt-get install file links mc tofrodos # + dependens könyvtárak

Most már van mcedit - phü :-) - ha már van, legyen ez az alapértelmezett editor + állítsuk be, hogy az alapértelmezett (pl. az ls kimenetében megjelenő) dátum formátuma a locale szerinti helyett (Lenny újdonság volt, a Squeeze is megtartotta) a régi (parse-olhatóbb) legyen:

-rw-r--r-- root root /etc/profile.d/custom.sh

# Custom editor.
export EDITOR="/usr/bin/mcedit"

# More parseable ls -la format.
export TIME_STYLE="long-iso"

Persze, aki nano-fan, az EDITOR-t kihagyhatja :-)

A Midnight Commanderben hasznos beállítani (F9, Beállítások, Alapbeállítások) a saját szövegszerkesztő használatát, illetve az XTerm ablak fejléc átírásának kikapcsolását (F9, Beállítások, Megjelenés, Xterm-ablakcím pipa ki, Mentés). Az mcedit-ben (F9, Beállítások, Általános) az új sorban automatikus behúzást (ha be lenne kapcsolva) és a látható tabulátorokat(!) kikapcsolni, végül az mc beállításokat elmenteni (F9, Beállítások, Beállítások mentése).

Szerepnév beállítása

Amennyiben a gép hostname által mutatott elnevezése mellett létezik annak valamilyen szerepneve, és ezt szeretnénk a konzol promptban megjeleníteni (pl. mert jellemzőbb, mint az esetleg technikai hostnév), akkor szerkesszük meg a korábban már használt /etc/profile.d/custom.sh állományt (a ROLE_NAME-et helyettesítsük a kívánt szerepnévvel):

-rw-r--r-- root root /etc/profile.d/custom.sh

[...]
# Including server role string.
PS1=${PS1/h:/h (ROLE_NAME):}

illetve a később létrehozandó felhasználók számára szerkesszük meg a /etc/skel/.bashrc állományt:

-rw-r--r-- root root /etc/skel/.bashrc

[...]
if [ "$color_prompt" = yes ]; then
    [...]
fi
unset color_prompt force_color_prompt

# Include server role string.
PS1=${PS1/h:/h (ROLE_NAME):}
[...]

A következő bejelentkezéstől kezdve a konzol promptban a szerepnév is megjelenik. Sajnos a Midnight Commander ezt a beállítást nem veszi át, így azt külön kell definiálnunk a root számára:

-rw-r--r-- root root /root/.local/share/mc/bashrc

#!/bin/bash

export PS1=${PS1/h:/h (ROLE_NAME):}

és ennek mintájára minden további interaktív felhasználó számára is.

A home könyvtárak átköltöztetése

Ezeket a kis méretű root partícióról a /var-ba helyezzük át, és symlinkeljük:

mv /home /var/home; ln -s /var/home /home

Az admin felhasználó létrehozatala

Telepítéskor az admin felhasználónév átmenetileg foglalt, így ezt a felhasználót a telepített rendszer elindítása után kell létrehozni:

groupadd admin
useradd -c Adminisztrator -g admin -d /home/admin -m -s /bin/bash admin
chmod 750 /home/admin
passwd admin

A jelszó a telepítés ideje alatt lehet gyenge, azonban azt a nyilvános hozzáférés megadása előtt(!!!) szükséges erős, generált jelszóra kicserélni.

Az admin alapvetően nem interaktív felhasználó, így ne hagyjuk, hogy a shelljére vonatkozó beállításokat interaktívan megváltoztassa:

export user='admin'
chmod 440 /home/$user/.bashrc; chattr +i /home/$user/.bashrc
chmod 440 /home/$user/.bash_logout; chattr +i /home/$user/.bash_logout
chmod 440 /home/$user/.profile; chattr +i /home/$user/.profile

Ezután készítsük elő az admin számára a nyilvános kulcsú távoli bejelentkezéshez szükséges állományokat:

export user='admin'
mkdir -m 500 /home/$user/.ssh
chown $user:$user /home/$user/.ssh
touch /home/$user/.ssh/authorized_keys2
chown $user:$user /home/$user/.ssh/authorized_keys2
chmod 400 /home/$user/.ssh/authorized_keys2
chattr +i /home/$user/.ssh/authorized_keys2

A fenti beállításokkal csak a root tud az admin felhasználó nevében történő bejelentkezéshez szükséges kulcsokat felvenni (az immutable bit levétele után).

SSH beállítása

Feltételezzük, hogy a telepítés során network-console-t használtunk, így az ssh már telepítve van. Ha mégsem lenne telepítve:

apt-get install ssh # OpenSSH szerver és kliens

Ezután:

  • Tiltsuk le a root belépését ssh-n keresztül (admin-ként kell belépni és su-zni).
  • Amennyiben nem az alapértelmezett TCP:22-es portot használjuk, állítsuk át a portszámot is (ez nézetem szerint nem célszerű, mert a közbenső tűzfalak valószínűleg nincsenek rá felkészülve).
  • Ha helyi hálózati környezetben nincs a munkaállomások IP címeinek reverse DNS feloldása, akkor az ezekről történő kapcsolódás sokáig tarthat, mert az sshd előtte megpróbálja feloldatni a címeket. Ezt a viselkedést opcionálisan kikapcsolhatjuk (publikus zónába tervezett szerver esetén inkább hagyjuk bekapcsolva), de általában erre nincs szükség.
  • Ha a telepítés nem izolált környezetben történik, célszerű lehet a telepítés idejére (amíg a jelszavak gyengék) letiltani a challenge-response típusú authentikációt. Általában erre nincs szükség.
-rw-r--r-- root root /etc/ssh/sshd_config

Port XXXXX
[...]
PermitRootLogin no
[...]
# Optionally disable reverse DNS
UseDNS no 
[...]
# Opcionálisan(!!!)
ChallengeResponseAuthentication no

Ha kizártuk a challenge-response authentikációt, akkor még ne indítsuk újra az sshd-t, előtte adjuk hozzá minden publikus kulcsunkat (Linux esetén ez a saját gépünk ~/.ssh/id_dsa-pub állománya, Windows esetén nincs fix helye, a generáláskor meg kell adni, hogy hova tegye) az admin felhasználó ~/.ssh/authorized_keys állományához. PuTTY által generált kulcsot importálni kell IETF SECSH formából OpenSSH formába:

ssh-keygen -i -f putty_kulcs >openssh_kulcs.pub

A hozzáadás után próbáljuk ki a belépést. Csak ha az authentikáció a kulccsal rendben megtörtént, indítsuk újra az ssh démont (ezzel a telepítés hátralévő részére kizártuk a kulcs nélküli távolt belépést):

/etc/init.d/ssh restart

NTP telepítése

Ha a Debian installernek nem sikerült volna az NTP (network time protocol) alapú időszinkron telepítése, akkor ezt itt pótolhatjuk:

apt-get install ntp # + dependens könyvtárak

Levelezés beállítása

A levelezésre elsődlegesen a szerver állapotjelentéseinek (logcheck, napi jelentések) továbbítása miatt van szükség. A legtöbb monitoring eszköz igényli a levélküldési lehetőséget, így azt már a telepítés elején érdemes beállítani.

Wheezy esetén minimál rendszerhez (üres tasklist) nem települ MTA, így azt külön telepítenünk kell. MTA-ként az alapértelmezett exim-et használjuk:

apt-get install exim4 bsd-mailx # + függőségek

Az Exim4 telepítője semmit nem kérdez, azaz telepítés után külön be kell állítani.

smarthost beállítása

Az alapbeállítás csak helyi levelezést engedélyez (a /var/mail/[Linux user] állományba hagyományos Unix mailbox formátumban bekerülő levelekkel). Ha a telepítéskor elérhető olyan smarthost, amelyik hajlandó a telepítés alatt álló szerver leveleit továbbítani, akkor érdemes a tényleges levéltovábbítást is beállítani:

dpkg-reconfigure exim4-config

Csak az alábbiakat kell megadni illetve megváltoztatni:

  • smarthost és SMTP/fetchmail;
  • az SMTP figyeljen minden IP-n, ne csak localhoston (tényleges levélfogadás lehetősége);
  • ha a hostname és a mail name különbözne (pl. a mail name a szerepnév), mindkettőt adjuk meg saját hostként (Other destinations for which mail is accepted);
  • adjuk meg a smarthostot, a helyi cím elrejtése akkor jön szóba, ha DNS-ben nem szerepel;
  • első alkalommal meg kell mondani, hogy a root és postmaster leveleket melyik valódi Linux felhasználó kapja (nyilván az admin, később felülbírálható a /etc/aliases állomány root: admin sorában);
  • a helyi kézbesítési mód legyen hagyományos mailbox (nem Maildir);
  • legyen sok kis beállítóállomány.

Valójában az Exim a sok kis beállítóállományt összefűzve használja, és az autogenerált file mindenki számára olvasható - ez nem jó, ha később MySQL vagy LDAP authentikációt szeretnénk, mert akkor ebben az állományban jelszavak lehetnek. Ezért egyszer és mindenkorra szigorítsuk a hozzáférést:

-rw-r--r-- root root /etc/exim4/update-exim4.conf.conf

[...]
CFILEMODE='640'
[...]

és generáltassuk újra az állományt:

/usr/sbin/update-exim4.conf; /etc/init.d/exim4 reload

Ellenőrizzük a levélküldést:

echo 'Teszt' | mail -s 'Teszt' ervenyes@email.cim; tail -f /var/log/exim4/mainlog

A levélküldés meghiúsulhat, ha a smarthost csak authentikációval hajlandó gépünktől levelet elfogadni. Ilyenkor a szükséges azonosító adatokat (név/jelszó páros) a /etc/exim4/passwd.client állományban adhatjuk meg.

sysadmin forward beállítása

A rendszer által küldött leveleket érdemes a rendszergazdák címére forwardolni. A real-admin beállítással a levelek az adott szerveren is megmaradnak a /var/mail/admin mailboxban.

touch /home/admin/.forward; chown admin:admin /home/admin/.forward; chmod 440 /home/admin/.forward

Megjegyzés: A forwardoláshoz eleinte érdemes saját e-mail címet megadni, mert a beállítások során elég sok email jöhet.

-r--r----- admin admin /home/admin/.forward

sysadmin@MYDOMAIN
real-admin

Teszteléshez érdemes egy levelet küldeni a root lokális postafiókjába, és megnézni, mi történik:

echo Teszt | mail -s Teszt root; tail -f /var/log/exim4/mainlog

Ha a tesztlevelet megkaptuk, érdemes lezárni a .forward állományt:

chattr +i /home/admin/.forward

Az így megadott immutable miatt csak a root tudja módosítani a forward beállításokat (ő is csak a korlátozás levétele után).

A helyi mailboxokat érdemes lehet logfile-szerűen rotálni:

-rw-r--r-- root root /etc/logrotate.d/mail

# A helyi mailboxok rotalasa

/var/mail/admin {
  rotate 4
  weekly
  compress
  missingok
  notifempty
  su admin mail
}

Források és frissítések beállítása

Telepítsük a telepítő CD kiadása óta megjelent, esetleges frissítéseket (ezt a telepítő önállóan is megteszi, de biztos, ami biztos):

apt-get update; apt-get upgrade

A frissítések figyelését automatizálja a cron-apt. Cron-ból futtatva, alapértelmezésben naponta egyszer ellenőrzi a distro repository-t, és letölti (de alapértelmezésben nem telepíti!) a frissítéseket. Ha talált és letöltött frissítendő csomagot, levelet küld.

apt-get install cron-apt # + dependens könyvtár

Telepítés után mentsük el a konfigurációs állományát és készítsünk egy újat:

mv /etc/cron-apt/config /etc/cron-apt/config.bak
mcedit /etc/cron-apt/config

Csak az alábbi beállításokra van szükség:

-rw-r--r-- root root /etc/cron-apt/config

# cron-apt nondeafult parameters

MAILON="upgrade"
DIFFONCHANGES=prepend

Megjegyzés: a maintainer korlátozta a letöltési sávszélességet - ez az egyetlen, nem kikommentezett beállítás a csomagból származó config állományban - ami szerver esetében valószínűleg szükségtelen, így ezt a korlátozást nem vezetjük át.

A cron-apt telepítése után, ha a frissítésekről levelet kaptunk, a letöltött csomag(ok) telepítését rendszergazdaként belépve, a szokott módon, az apt-get upgrade paranccsal végezhetjük el.

Firmware frissítések

Opcionális telepítések - virtuális gép esetén sose telepítsük ezeket, mert a reális hardware-t a futtató környezet kezeli!

A CPU microcode frissítése biztonsági frissítésnek minősül, ennek napra készen tartása reális hardware esetén erősen ajánlott. A frissítéseket a CPU gyártó (AMD, Intel, stb.) adja ki, és általában BIOS frissítésekkel jutnak el az érintett gépekre. Tapasztalat szerint csak microcode frissítések miatt a gyártók nemigen frissítenek BIOS-t, ráadásul a BIOS frissítéseket az üzemeltetők nem feltétlenül alkalmazzák, így a microcode csak ezen az úton nem igazán tartható napra készen. Emiatt a Linux terjesztések külön is tartalmazzák ezeket a frissítéseket, amelyek az operációs rendszer elindításakor, automatikusan alkalmazhatóak.

A microcode frissítő csomagok az új microcode-ot tartósan nem mentik el (nem égetik be) a CPU-ba, hanem a BIOS-ba integrált microcode frissítés minden hard bootkor fut le, az operációs rendszerhez integrált frissítés pedig annak minden elindításakor. A gép kikapcsolásakor ezek a frissítések elvesznek.

Intel CPU microcode

Futó Debian esetén az aktuális microcode verzió pl. az alábbi paranccsal olvasható ki:

cat /proc/cpuinfo | grep microcode

Ha Intel CPU-t használunk, telepítsük az Inteltől származó, de a Debian terjesztés által karbantartott (non-free szekció!) frissítő csomagot:

apt-get install intel-microcode iucode-tool

Az esetleges microcode frissítés a telepítés során azonnal (és ezt követően minden rendszerindításkor) betöltődik. A microcode verzió ismételt kiolvasásával:

cat /proc/cpuinfo | grep microcode

ellenőrizhetjük, hogy történt-e frissítés. Ha nem történt, akkor a CPU (eleve, vagy a BIOS közreműködésével) már a legfrissebb microcode-ot futtatja, viszont a csomag telepítésével gondoskodtunk arról, hogy a jövőben kiadandó esetleges frissítések is érvényesülhessenek.

Naplózás és napi jelentés beállítása

A naplókat a syslog-ng-vel állítjuk elő és a logcheck segítségével figyeljük.

Tűzfal beállítása

Valamennyi szervert bastion host-ként kell kialakítani, azaz saját (csomagszűrő) tűzfallal kell rendelkezzen, ld.: Debian bástyagép tűzfal (Wheezy).

Monitorozás

A szerver monitorozása általában adatgyűjtést jelent a hardver és egyes szoftverek állapotáról. Az adatokat valamilyen helyi vagy távoli eszközzel megjeleníthetjük, határértékek túllépése esetén riasztásokat illetve automatikus beavatkozásokat indíthatunk. A jelen leírásban elsődleges adatgyűjtő eszközként a Munin szolgál, amely egy Perl-ben írt framework hálózatba kötött számítógépek adatainak gyűjtésére és (grafikus) prezentálására.

Hardver szenzorok

Az adatgyűjtéshez szükséges a szerver hardver állapotának figyelésére szolgáló eszközök telepítése:

Adatgyűjtés, megjelenítés Muninnal

A Munin által gyűjtött adatok célszerűen webfelületen jeleníthetőek meg. Ha a telepítés alatt álló szerver egyben webszerver is (általában így van), akkor érdemes lehet az adatokat magán a webszerveren (is) megjeleníteni, emiatt a Munin telepítését az Apache telepítése utánra halasztani; ha az adatokat nem közvetlenül a szerveren, hanem távolról lekérdezve más eszközön jelenítjük meg, akkor a Munin kliens telepítése itt elvégezhető:

Watchdogok

A watchdog olyan szerkezet, amelyik igyekszik észlelni a számítógép "lefagyását" mely esetben (lehetőleg hardveresen) újraindítja azt. Az eszköz lehet hardver kártya, illetve integrálva lehet az alaplapi chipsetbe:

Kernel cseréje

Gyári kernelt csak indokolt esetben használunk, mert relatív lassú a security backport(?) és nincs benne GRSecurity támogatás. A kernelfordítást külön gépen végezzük (ld. Debian szerver kernel (Wheezy)), a kernel package-et scp-vel hozzuk át, és dpkg-vel telepítjük. - TODO! - egyelőre gyári kernelt használunk.

Posix ACL

A web policy használ Posix ACL-t (Squeeze-ben ezt a gyári kernel is támogatja), emiatt telepíteni kell az ACL kezelő segédprogramokat (getfacl, setfacl) tartalmazó Debian csomagot is:

apt-get install acl

és a későbbiekben a /etc/fstab-ban engedélyezni kell az ACL használatát.

Kiterjesztett fájlrendszeri attribútumok

Néhány alkalmazás használ kiterjesztett attribútumokat (Squeeze-ben ezt a gyári kernel is támogatja), emiatt telepíteni kell az ezeket kezelő segédprogramokat (getfattr, setfattr) tartalmazó Debian csomagot is:

apt-get install attr

és a későbbiekben a /etc/fstab-ban engedélyezni kell a user_xattr használatát.

PAX

PAX-os kernel használata esetén szükséges a PAX flag-eket beállító utility telepítése:

apt-get install paxctl

ELAVULT!

A boot record írásához (grub-install) az alábbi PaX engedélyeket kell megadni a /usr/sbin/grub és /usr/sbin/grub-probe ELF-nek:

TODO!

chpax -v /usr/sbin/grub

----[ chpax 0.7 : Current flags for /usr/sbin/grub (PeMRxS) ]----
 
 * Paging based PAGE_EXEC       : enabled (overridden)
 * Trampolines                  : not emulated
 * mprotect()                   : restricted
 * mmap() base                  : randomized
 * ET_EXEC base                 : not randomized
 * Segmentation based PAGE_EXEC : enabled

chpax -prs /usr/sbin/grub; chpax -prs /usr/sbin/grub-probe
chpax -v /usr/sbin/grub
 
----[ chpax 0.7 : Current flags for /usr/sbin/grub (peMrxs) ]----
 
 * Paging based PAGE_EXEC       : disabled
 * Trampolines                  : not emulated
 * mprotect()                   : restricted
 * mmap() base                  : not randomized
 * ET_EXEC base                 : not randomized
 * Segmentation based PAGE_EXEC : disabled

TODO: utánanézni, kevesebb nem elég-e!