Debian szerver alaptelepítés (Jessie)

A AdminWiki wikiből

Ebben a leírásban Debian (8.x) Jessie 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

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 Jessie 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 esetén is hajlanék a RAID-1 használatára (bár ezen vitatkoznak).
Particionálási séma két, software RAID-1-ben üzemelő SSD vagy 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ó.

Ha a rendszerlemez kicsi (pl. single SSD vagy SSD/RAID-1), a "nagy" tárterületet pl. az alábbiak szerint definiálhatjuk:

sdc sdd md megjegyzés
sdc1 X GB RAID sdd1 X GB RAID mdX RAID-1 ext4 vagy lvm2-ext4 /mnt/storage
(1% fenntartott blokk elegendő)
szolgáltatási tárterület (www, Samba, backup, stb. 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. A backport repository kérdéses, szerintem ráérünk később is hozzáadni(? TODO!).
  • Szoftverválasztás és telepítés - csomaghasználat felmérése nem kell, 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 a (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 első újraindítás után, konzolról bejelentkezve(!), átmenetileg engedélyezzük az ssh-val, root-ként, jelszóval (nem kulccsal) történő bejelentkezést:

-rw-r--r-- root root /etc/ssh/sshd_config

[...]
#PermitRootLogin without-password
PermitRootLogin yes
[...]

és az sshd újraindításával érvényesítsük a beállítást:

systemctl restart sshd

A továbbiakhoz nem kell a konzol; ssh-val, egyelőre 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 lsof pwgen telnet unzip zip # +: sok függőség, Perl alapkönyvtárak
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 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, pl. így:

root@x206-kdzwy54 (testing):~#

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

Ha a telepítés során network-console-t használtunk, az ssh szerver már telepítve van, de a kliens még nincs; ezt pótoljuk:

apt-get install ssh # OpenSSH szerver és kliens

Ezután:

  • Tiltsuk le a root jelszóval történő belépését ssh-n keresztül! Házirendünkben a root felhasználóhoz nyilvános kulcsot senkinek nem adunk ki (így a root-hoz mindig két lépés kell: admin-ként kell belépni - kulccsal vagy jelszóval - és su-zni). Ha valamiért szükséges automata root login, akkor megtartjuk a Jessie-ben alapértelmezett, csak kulccsal történő belépést; ha nincs ilyen igény, a közvetlen belépést teljesen letiltjuk.
  • Opcionálisan, 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).
  • Opcionálisan, 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 kikapcsolhatjuk (publikus zónába tervezett szerver esetén inkább hagyjuk bekapcsolva), de általában erre nincs szükség.
-rw-r--r-- root root /etc/ssh/sshd_config

[...]
# What ports, IPs and protocols we listen for
Port XXXXX
[...]
#PermitRootLogin without-password
PermitRootLogin no
[...]
# Optionally disable reverse DNS
UseDNS no 
[...]

Indítsuk újra az ssh démont:

systemctl restart sshd

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.

A 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 csak akkor jön szóba, ha az a DNS-ben nem szerepel (nem kell a gépre mutatnia, csak létező feloldás legyen);
  • a helyi kézbesítési mód legyen hagyományos mailbox (nem Maildir);
  • legyen sok kis beállítóállomány;
  • 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).

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; systemctl reload exim4

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 továbbítás + másolat beállítású postafiókokat érdemes lehet naplószerűen rotálni:

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

# Forwarded local mailboxes
/var/mail/admin {
  rotate 4
  weekly
  compress
  missingok
  notifempty
  su admin mail
}

Ezzel a technikai jellegű levelezést beállítottuk.

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 Debian Installer ö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; ilyenkor a frissítéseket választott időben, manuálisan telepíthetjük. A frissítések miatt egyes szolgáltatások, vagy az egész szervergép újraindítása is szükséges lehet; erre figyelmeztet az ugyancsak telepítendő needrestart csomag.

apt-get install cron-apt needrestart # +: dependens könyvtárak

Telepítés után egészítsük ki a cron-apt konfigurációs állományát:

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

[...]
MAILON="upgrade"
DIFFONCHANGES=prepend

Megjegyzés: úgy tűnik, az overlay technika nem megy, mert a /etc/cron-apt/config.d/* könyvtár - nevével kicsit ellentétben - az action.d-beli beállítások felülbírálatára szolgál, így ott az alábbi konfiguráció nem érvényesül - TODO!

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

Ebben a házirendben (egyelőre) nem használunk naplószervert, illetve nem törekszünk több gép naplóeseményeinek egységes kezelésére - TODO!

Standalone környezetben a naplókat a syslog-ng-vel állítjuk elő és a logcheck segítségével figyeljük. A napi jelentés a /etc/cron.daily alatti scriptek lefuttatásának kimenete. Minden értesítés email-ben érkezik.

Tűzfal beállítása

A Hálózati házirend szerint valamennyi szervert bastion host-ként kell kialakítani, azaz saját (csomagszűrő) tűzfallal kell rendelkezzen: Debian bástyagép tűzfal (Jessie).

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 web megjelenítő is (általában így van), akkor érdemes lehet az adatokat magán a szerveren (is) megjeleníteni, emiatt a Munin telepítését az Apache vagy Lighty webszerver 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 (akár kernel szintű) "lefagyását" mely esetben (lehetőleg hardveresen) újraindítja azt. Az eszköz lehet hardver kártya, illetve integrálva lehet az alaplapi chipset-be. Emellett hasznos lehet a szoftveres watchdog, amely működő operációs rendszer mellett, előre definiált üzemállapotokban (pl. lefagyást még nem okozó erős túlterhelés esetén) kezdeményez szabályos újraindítást:

Egyéb eszközök

Kiterjesztett fájlrendszeri attribútumok

Néhány alkalmazás használ kiterjesztett attribútumokat (ezt a gyári kernel is támogatja), emiatt érdemes telepíteni az ezeket lekérdező, beállító 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 kezelőprogram

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

Open VMware Tools

VMware környezetben futó guest szervergép esetén telepítsük a környezettel jobb együttműködést biztosító VMware Tools eszközkészlet szabad szoftver verzióját:

apt-get install open-vm-tools  # + néhány függőség

Irodalom