Debian szerver alaptelepítés (Wheezy)
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ó.
Tartalomjegyzék
- 1 Előfeltételek
- 2 Telepítési beállítások
- 3 A frissen telepített rendszer beállításai
- 4 Naplózás és napi jelentés beállítása
- 5 Tűzfal beállítása
- 6 Monitorozás
- 7 Watchdogok
- 8 Kernel cseréje
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.
- A naplózás beállítását ld.: Debian szerver logolás (Wheezy).
- A napi jelentésre szolgáló scriptek és beállításokat ld.: Debian szerver napi jelentés (Wheezy).
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!