Ubuntu szerver alaptelepítés (22.04 LTS)

Ebben a leírásban Ubuntu Focal Fossa (20.04 LTS), illetve Jammy Jellyfish (22.04 LTS) 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 mindkét kiadásra egyaránt alkalmazható (az esetleges eltérések külön fel vannak tüntetve). Az eljárás "bármilyen" szerverre alkalmazható.

Ez a leírás elsősorban technikai (checklist jellegű), az elméleti megfontolásokat az Ubuntu szerver házirend tartalmazza.

Work in progress! Kritikával olvasd!

Előfeltételek

Fizikai gép vagy üres VM esetén

• Működő hardver, konzol hozzáférés, tudjon a telepítő médiumról (valós vagy virtuális CD-ről, USB-ről) bootolni.
• Lásson ki (védett, NAT-olt) hálózaton keresztül az Internetre.
• Megfelelő architektúrájú Ubuntu Server boot médium - 64 bites (Intel) CPU és legalább 2 GB RAM esetén a 64 bites lemezképet használjuk!

Előtelepített VM esetén

• Lehetőleg csak az alap szolgáltatásokkal, grafikus felület nélkül telepített VM, SSH-n vagy virtuális konzolon root (sudo root) hozzáféréssel.
• Lásson ki (védett, NAT-olt) hálózaton keresztül az Internetre.

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

Ez a szakasz csak fizikai gép vagy üres VM esetén érdekes - az Ubuntu Live Server 20.04 telepítő médiumról bootolva a telepített rendszer első tényleges indulásáig tart, és a védett hálózatra(!) csatlakozó telepítendő gép számára működő Internet kapcsolatot igényel.

• Nyelv tetszés szerint lehet English vagy Hungarian.
• A billentyűzet legyen Magyar - mivel az adminisztrátorok kliensgépe általában magyar billentyűzetkiosztású, sok kellemetlenséget megelőzhetünk ezzel.
• A telepítés legyen Ubuntu Server - a minimized-ben nincs benne egy halom, nekünk fontos csomag. Jobb a békesség :). A 3rd party drivers virtuális gépen általában szükségtelen, de fizikai szervergép esetén kapcsoljuk be.
• Ha van fix IP-nk, azt már itt állítsuk be. Belső hálózaton lévő lévő gépnél (általában ilyen környezetben telepítünk) érdemes a belső DNS szerver (ami gyakran a gateway) mellé másodlagosan egy publikus DNS szervert is felvenni (ha nincs jobb ötletünk, legyen 8.8.8.8).
• Particionálás TODO! - ha nem kívánunk R/O illetve nem futtatható partíciókat, általában maradhat az Ubuntu alapértelmezése (1G /boot, a többi a /). Alapértelmezett particionálás esetén, virtuális gépen (nézetem szerint) nem szükséges LVM-et használni, a hypervisor ezt a funkciót biztosítja. Ha nincsenek különleges igények, titkosítatlan ext4 fájlrendszert használhatunk (ez az alapértelmezés is).
• Az első (sudo-képes) felhasználó számára (egyéb igény híján) használjuk a sysadmin (GECOS: System Administrator) felhasználónevet. Ebben a stádiumban a jelszó még lehet triviális.
• Kérjünk SSH szerver telepítést.
• Ne kérjünk előtelepítést (featured snaps), teljesen kontrollálni szeretnénk a telepítendő szolgáltatásokat.

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

Ha eddig konzolon dolgoztunk volna, innen a telepítést kényelmesebb SSH-n bejelentkezve folytatni. Lépjünk be a telepítés során létrehozott, sudo-képes (UID: 1000-es) Linux felhasználóként - előtelepített VM esetén lehetséges, hogy ilyen még nincsen, ez esetben root-ként - és hajtsuk végre az alábbiakat:

UMASK beállítások

Ezeket a beállításokat érdemes a lehető legkorábban elvégezni, így a továbbiakban létrehozandó fájlok egységes fájlrendszeri jogosultságokkal jönnek létre.

Az Ubuntu alapértelmezett UMASK beállításai szerint a (nem root) felhasználók állományai rw-rw-r-- (664), könyvtárai rwxrwxr-x (775) jogosultságokkal jönnek létre, amit túl engedékenynek tartunk; rw-rw---- (660) és rwxrwx--- (770) jogokat szeretnénk beállítani. A root számára meghagyjuk a rw-r--r-- (644) és rwxr-xr-x (755) alapértelmezett jogosultságokat.

Mindenki számára (007)

Az összes felhasználót érintően a /etc/login.defs-ben módosítsuk az UMASK értékét:

sudo nano /etc/login.defs

Módosítsuk a fájlban, majd CTRL-O, enter, CTRL-X:

[...]
UMASK 007
[...]

Speciálisan a root számára (022)

A root számára írjuk elő a tradícionális UMASK értéket (login és non-login shell esetére is):

sudo nano /root/.bashrc

Szúrjuk be a file végére, majd CTRL-O, enter, CTRL-X:

[...]
umask 022

sudo használata esetén (022)

Írjuk elő, hogy a sudo használata esetén ne a hívó UMASK-ja érvényesüljön, hanem az itt megadott:

sudo visudo

Szúrjuk be a Defaults szakasz végére, majd CTRL-O, enter, CTRL-X:

[...]
Defaults        umask=0022
Defaults        umask_override
[...]

A beállítások érvényesítéséhez itt célszerű a gépet újraindítani.

Ellenőrzés

Bejelentkezés	Parancs	Eredmény
UID=1000 felhasználóként	umask	0007
sudo -i	umask	0022
su -	umask	0022

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

Amennyiben kis méretű root partícióval dolgozunk, célszerű a home könyvtárakat permanensen a /var-ba áthelyezni, és symlinkelni:

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

Figyelem: szigorú (secure) partíció csatolás esetén ez azt eredményezi, hogy a home könyvtárakban csak trükkökkel lehet scripteket futtatni!

A sysadmin felhasználó alapbeállításai

Ebben a szakaszban a telepítés során létrehozott (UID: 1000) sudo-képes Linux felhasználó számára készítünk alapbeállításokat.

Amennyiben előtelepített VM-en dolgozunk és ez a felhasználó még nem létezne, hozzuk létre az alábbi (root-ként kiadott) parancsokkal:

adduser --gecos "System Administrator" sysadmin  # kér egy jelszót a felhasználó számára
adduser sysadmin sudo

A jelszó lehetőleg ne triviális, preferáltan generált legyen (pl. innen). A jelszóval belépést SSH-n tiltani fogjuk és csak a virtuális konzolra tartjuk fent, illetve a sudo-hoz fogjuk majd használni a jelszót.

Lépjünk be sysadmin (vagy ha más néven hozták létre, az UID: 1000-es) felhasználóként, és hajtsuk végre az alábbiakat:

Profilbeállítások

• Bár az alaptelepített nano teljesen használható, részemről az mcedit-et preferálom - opcionálisan legyen ez az alapértelmezett editor;
• Az alapértelmezett (pl. az ls kimenetében megjelenő) dátum formátuma a locale szerinti helyett parse-olhatóbb legyen;

nano $HOME/.profile

Szúrjuk be a file végére, majd CTRL-O, enter, CTRL-X:

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

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

A beállítások a legközelebbi bejelentkezésnél érvényesülhessenek.

Biztonsági beállítások

Tegyük priváttá a felhasználó HOME könyvtárát:

chmod -R o-rwx $HOME
chmod g+rwx $HOME    # feleljen meg az UMASK-nak
ls -lad $HOME        # drwxrwx--- sysadmin sysadmin

Mivel a sysadmin alapvetően nem interaktív felhasználó, hanem egy indirekt belépés a root jogosultság eléréséhez, nem hagyjuk, hogy a shelljére vonatkozó beállításokat megváltoztassa:

sudo echo  # hogy alább már ne kérjen jelszót

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

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

mkdir /home/$user/.ssh
touch /home/$user/.ssh/authorized_keys

Amennyiben vannak publikus kulcsaink a sysadmin felhasználóként történő bejelentkezéshez, töltsük fel és másoljuk be azokat az authorized_keys állományba. Ezután zárjuk le ezt az állományt:

chmod 400 /home/$user/.ssh/authorized_keys
chmod 500 /home/$user/.ssh/
sudo chattr +i /home/$user/.ssh/authorized_keys

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

Az SSH démon beállítása

A leírt telepítés során az ssh szerver és kliens már települt, most nézzük át az sshd beállításait:

• Tiltsuk le a root belépését ssh-n keresztül! Házirendünkben a root felhasználóhoz nyilvános kulcsot senkitől sem fogadunk el (így a root-hoz mindig két lépés kell: sudo-képes felhasználóként, pl. sysadmin-ként kell belépni - kulccsal vagy jelszóval - és sudo-zni). Ha valamiért szükséges automata root login, akkor megtartjuk az alapértelmezett, csak kulccsal történő belépést; ha nincs ilyen igény, a közvetlen belépést teljesen letiltjuk. A konzolos belépésre ez a beállítás nem hat, a virtuális vagy valódi konzolon továbbra is beléphetünk root-ként.
• Opcionálisan, amennyiben a sudo-képes felhasználónkhoz már feltöltöttünk nyilvános kulcsot (és működését ellenőriztük!), tiltsuk le a jelszóval történő belépést mindenki számára. Ez automatikusan megvéd a próbálgatásos (brute force) támadásoktól. A konzolos belépésre ez a beállítás nem hat, a virtuális vagy valódi konzolon továbbra is beléphetünk jelszóval.
• 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).

Mindezeket legegyszerűbben egy új, overlay beállító állományban adhatjuk meg:

sudo nano /etc/ssh/sshd_config.d/custom.conf

Vegyük fel az alábbiakat, majd CTRL-O, Enter, CTRL-X:

# What ports, IPs and protocols we listen for
#Port XXXXX
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no

Indítsuk újra az ssh démont (ha nem változtattunk TCP portot, a meglévő munkamenet nem fog megszakadni):

sudo systemctl restart sshd

Szoftverforrások beállítása

Az alap segédeszközök telepítése előtt ellenőrizzük, hogy minden repositoryhoz hozzáférünk-e:

apt-cache policy | grep http | awk '{print $2 $3}' | sort -u
# látjuk-e mind a négyet: main, restricted, universe, multiverse (opcionálisan backports is)

Ha valamelyik (általában az utolsó kettő) hiányozna, adjuk hozzá:

sudo add-apt-repository universe
sudo add-apt-repository multiverse

Frissítsük a telepített csomagokat:

sudo apt update; sudo apt upgrade

A terjesztés alapértelmezésben tartalmazza a Snaps Store (korábban Ubuntu Software Center) kezelőprogramját, erre azonban szervergépen nincs szükségünk. Eltávolításához adjuk ki az alábbi parancsokat:

sudo apt purge snapd
sudo apt autoremove
sudo rm -rf /root/snap

Alap segédeszközök

sudo apt install acl htop mc needrestart net-tools tofrodos unzip zip

A Midnight Commanderben hasznos beállítani (mc, F9, Beállítások, Alapbeállítások) a saját szövegszerkesztő használatát (F9, Beállítások, Saját szövegszerkesztő, OK).

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).

Lokalizáció

Ellenőrizzük az időzónát:

timedatectl

Szükség esetén állítsuk be (budapesti lokalizációt feltételezve):

timedatectl list-timezones | grep Budapest  # Europe/Budapest
sudo timedatectl set-timezone Europe/Budapest
timedatectl                                 # ellenőrzés

Ha még nem létezne, készítsük el a magyar nyelvi lokalizációt:

locale -a  # ha hu_HU.UTF8 nem szerepelne 

sudo locale-gen hu_HU.UTF-8
sudo update-locale

Hostnév és szerepnév beállítása

Ellenőrizzük, és szükség esetén változtassuk meg a gép hostnevét:

hostnamectl | grep -i static                # lekérdezés
sudo hostnamectl set-hostname new_hostname  # változtatás

A domain névvel kiegészített hostnevet (fully qualified hostname) a /etc/hosts állomány szerkesztésével állíthatjuk be (a sorrend fontos!):

sudo mcedit /etc/hosts

127.0.0.1 localhost
127.0.1.1 new_hostname.domain.name new_hostname
[...]

Ellenőrzés:

hostname         # new_hostname
hostname --fqdn  # new_hostname.domain.name

Opcionálisan, 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 az alábbiak szerint azonosan szerkesszük meg

• a sysadmin (illetve UID: 1000) felhasználó,
• a root felhasználó,
• illetve a később létrehozandó felhasználók számára elkészített template .bashrc állományokat:

sudo mcedit $HOME/.bashrc
sudo mcedit /root/.bashrc
sudo mcedit /etc/skel/.bashrc

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

# Include the server role string.
if [ -n "$ROLENAME" ]; then
    PS1=${PS1/@\\h/@\\h ($ROLENAME)}
fi
[...]

Magát a szerepnevet az /etc/profile.d/custom.sh állományban adhatjuk meg:

sudo mcedit /etc/profile.d/custom.sh

[...]
# Server role string.
export ROLENAME="testing"

A következő bejelentkezéstől kezdve a konzol promptban a szerepnév is megjelenik, pl. így:

root@x206-kdzwy54 (testing):~#

A Linux disztribúció frissítéseinek kezelése

Házirendünk szerint a disztribúciós csomagok frissítésére az Ubuntu alapértelmezett unattended-upgrades szolgáltatását fogjuk használni (alternatíva lenne: cron-apt), de az automatikus Ubuntu frissítéseket kikapcsoljuk, csak a frissítések figyelését tartjuk meg, és a telepítendő frissítésekről a napi jelentésből fogunk tájékozódni.

• Ha nem lenne telepítve, telepítsük a szolgáltatást:

sudo apt install unattended-upgrades apt-config-auto-update

• Kikapcsoljuk az automatikus frissítést:

sudo mcedit /etc/apt/apt.conf.d/20auto-upgrades

[...]
APT::Periodic::Unattended-Upgrade "0";

• Engedjük a sima (nem security) update-ek figyelését is:

sudo mcedit /etc/apt/apt.conf.d/50unattended-upgrades

[...]
        "${distro_id}:${distro_codename}-updates";
[...]

• A beállítások érvényesítéséhez újraindítjuk a szolgáltatást:

sudo systemctl restart unattended-upgrades

A vonatkozó napi jelentést alább fogjuk beállítani.

Firmware frissítések

Opcionális telepítések - virtuális gép esetén ne telepítsük ezeket, mert a fizikai 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 fizikai 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.

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

cat /proc/cpuinfo | grep microcode

Intel CPU microcode

Ha Intel CPU-t használunk, telepítsük az Inteltől származó, de az Ubuntu terjesztés által karbantartott frissítő csomagot:

sudo apt 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.

AMD CPU microcode

TODO!

Technikai levelezés beállítása

A technikai levelezésre elsődlegesen a szerver állapotjelentéseinek 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. Jelen leírásban MTA-ként az Ubuntuban alapértelmezett Postfixet fogjuk használni:

sudo apt install bsd-mailx  # hozza magával a Postfixet

A telepítő kérdéseire az alapértelmezésekkel válaszoljunk (Internet site és _HOSTNAME_).

smarthost beállítása

Amennyiben a telepítés alatti szervergép önállóan nem képes levelet küldeni, de elérhető olyan gép amelyik hajlandó a szerver leveleit továbbítani, állítsuk be azt relay host-nak:

sudo mcedit /etc/postfix/main.cf

[...]
relayhost = [host]:[port]
smtp_sasl_auth_enable = yes
smtp_sasl_security_options = noanonymous
smtp_sasl_password_maps = hash:/etc/postfix/password
smtp_generic_maps = hash:/etc/postfix/generic
[...]
inet_protocols = ipv4

• Ha szükséges, állítsuk be az authentikációt (ha nem szükséges, akkor is hozzuk létre és hash-eljük az állományt üresen):

sudo mcedit /etc/postfix/password

smtp.isp.com       username:password

sudo chmod 600 /etc/postfix/password
sudo postmap hash:/etc/postfix/password

• Ha szükséges, változtassuk meg a kimenő levelek feladóját olyanra, amelyet a smarthost elfogad (ha nem szükséges, akkor is hozzuk létre és hash-eljük az állományt üresen):

sudo mcedit /etc/postfix/generic

valodi@felado.cim    amit.szeretnenk@felado.cim

sudo postmap hash:/etc/postfix/generic

• Érvényesítsük a beállításokat:

sudo systemctl restart postfix

Teszt levélküldés

echo 'Teszt' | mail -s 'Teszt' valid@email.address; sudo tail -f /var/log/mail.log

Sikertelenség esetén TODO!

A root forward beállítása

A rendszer által a root postafiókjába küldött leveleket érdemes (a helyi postafiókban - /var/mail/root - megtartás mellett) a rendszergazdák valódi email címére továbbítani:

sudo mcedit /root/.forward

rendszergazdak@email.cime
\root

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

Teszteléshez küldjünk egy levelet a root lokális postafiókjába:

echo Teszt | mail -s Teszt root; sudo tail -f /var/log/mail.log

Ha ezt a levelet megkapjuk, a továbbiakban a rendszer cron, cron.daily, stb. leveleit is meg fogjuk kapni.

A továbbítás + másolat beállítású (technikai) postafiókokat érdemes naplószerűen rotálni:

sudo mcedit /etc/logrotate.d/mail  # új file

# Forwarded local mailboxes

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

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

Napi jelentés beállítása

A napi jelentés a /etc/cron.daily alatti scriptek lefuttatásának kimenete. Az alaptelepítés által itt elhelyezett scriptek nagyon szűkszavúak, normális esetben semmilyen kimenetet nem adnak. Érdemes lehet néhány általános jelentéskészítő scriptet ide elhelyezni.

Megjegyzés: azt hiszem, az Ubuntuban azért nincsenek napi jelentő scriptek, mert a fejlesztők filozófiája szerint az eseményekről azonnali értesítést kell kapni, ennélfogva a napi jelentés felesleges. Másfelől engem megnyugtat, ha naponta kapok a szerverektől egy "kösz, jól vagyok" levelet :-)

RAID állapot

Opcionálisan, fizikai gépen, Linux software RAID használata esetén célszerű. Az mdadm szól ugyan, ha szétesik egy RAID, de csak egyszer. Az alábbi script viszont naponta.

sudo touch /etc/cron.daily/raidstatus
sudo chmod 755 /etc/cron.daily/raidstatus
sudo mcedit /etc/cron.daily/raidstatus

#!/bin/bash
# Cron job to check that raid devices are functional.
# On error cron will mail the faulty mdstat to root.
#   raid1.c and raid5.c list devices as U (operational) or _ (not)
#   a _ device may be either hot, standby or bad
# Merlin Hughes <merlin@merlin.org>
# Modified by <kovacs.zoltan@kzoli.hu>

[ -e /proc/mdstat ] || exit 0

mdstat=`cat /proc/mdstat`

echo -e "\nRAID status:"
# Underscore between square brackets shows a faulty disk
if echo "$mdstat" | grep -q -e '\(\[.*_.*\]\)'; then
    echo 'WARNING: Some disks in your RAID arrays seem to have failed!'
    echo 'Below is the content of /proc/mdstat:'
    echo
    echo -e "$mdstat"
else
    echo "RAID is OK."
fi

Tárhely foglaltság

Fontos, mert ezt semmilyen más eszköz nem figyeli.

sudo touch /etc/cron.daily/status-disks
sudo chmod 755 /etc/cron.daily/status-disks
sudo mcedit /etc/cron.daily/status-disks

#!/bin/bash
echo -e "\nDisk status:"
/bin/df -kh | /bin/grep -ve '^shm'     | \
              /bin/grep -ve '^tmpfs'   | \
              /bin/grep -ve '^udev'    | \
              /bin/grep -ve '^overlay' | \
              /bin/grep -ve '^/dev/loop'

Telepíthető frissítések

• Ha létezik a /etc/update-motd.d/90-updates-available állomány, akkor legegyszerűbben a minden belépéskor látható faliújság (MOTD: message of the day) vonatkozó részletét küldjük el a telepíthető frissítésekről - ehhez egyszerűen belinkeljük a meglévő widgetet:

sudo ln -s /etc/update-motd.d/90-updates-available /etc/cron.daily/updates-available

• Ha a widget nem létezik, egy egyszerű scriptet készítünk:

sudo touch /etc/cron.daily/updates-available
sudo chmod 755 /etc/cron.daily/updates-available
sudo mcedit /etc/cron.daily/updates-available

#!/bin/bash

echo -en "\n$(( $(apt list --upgradable 2>/dev/null | wc -l) - 1)) "
echo "package(s) are waiting for an upgrade."

Uptime

Inkább csak hagyományból, opcionálisan referált paraméter.

sudo touch /etc/cron.daily/uptime-info
sudo chmod 755 /etc/cron.daily/uptime-info
sudo mcedit /etc/cron.daily/uptime-info

#!/bin/bash

echo
/usr/bin/uptime

Monitorozás

A szerver monitorozása adatgyűjtést jelent a hardver és egyes szoftverek állapotáról. Az adatokat valamilyen helyi vagy távoli eszközzel megjeleníthetjük, elemeztethetjük, határértékek túllépése esetén riasztásokat illetve automatikus beavatkozásokat indíthatunk.

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

• TODO!

Ezen kívül szükséges a gyűjtött adatok elemzését és megjelenítését végző eszköz számára az adatok feladását biztosító kliensprogram telepítése:

• TODO!

Watchdog

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.

Watchdog driver

A hardver watchdog lehet hardver kártya, illetve integrálva lehet az alaplapi chipsetbe. Általában úgy működik, hogy inicializálás után elvárja, hogy az operációs rendszer (pl. egy portra írással) periodikusan jeleket adjon neki (heartbeat). Ha ez a jel az inicializálásnál beállított ideig kimarad, az eszköz resetel.

A szoftver watchdog olyan program, amelyik periodikusan figyel beállított paramétereket - load, ping time, stb. - és beállított határértékük meghaladása esetén szabályos újraindítást (reboot) végez. Ez tehát "lefagyott" gép esetén nem használható, arra az esetre való, amikor az operációs rendszer még működik, de a gép már semmi hasznosat nem csinál.

Fizikai gép esetén, ha van a gépben hardware watchdog device (és az Ubuntu tartalmazza hozzá a drivert), akkor használjuk azt; ha nincsen, akkor használjuk a software watchdog modult. Virtuális gépen a szoftveres megoldás használható.

Intel chipset built-in hardware watchdog

Intel chipset esetén (ICH4,5,6,7, stb.) - gyári kernellel - érdemes kipróbálni hogy van-e built-in watchdog:

sudo ls /dev/watchdog
# Ha megvan az eszköz, a továbbiakat átléphetjük.

# Ha nincs device, vajon be van-e töltve a kernel modul?
sudo lsmod | grep iTCO_wdt
# Ha nem lenne betöltve, próbáljuk meg:
sudo modprobe iTCO_wdt heartbeat=30

Siker esetén létezni fog a /dev/watchdog device. Ha szükséges, egy, a /etc/modules-load.d könyvtárbeli include állománnyal írjuk elő a kernel modul betöltését, hogy az már a rendszerindulástól elérhető legyen:

sudo mcedit /etc/modules-load.d/watchdog.conf

iTCO_wdt heartbeat=30

Software watchdog

Ha nincs a gépben elérhető hardware watchdog, akkor a softdog modult használhatjuk:

sudo modprobe softdog
sudo ls /dev/watchdog

Ekkor létrejön a /dev/watchdog device. Siker esetén egy, a /etc/modules-load.d könyvtárbeli include állománnyal írjuk elő a modul betöltését, hogy az már a rendszerindulástól elérhető legyen:

sudo mcedit /etc/modules-load.d/watchdog.conf

softdog

Watchdog beállítások

Ha sikerült megfelelő watchdog drivert találni, akkor telepíteni kell a watchdog Debian csomagot, ami induláskor elindítja a figyelést, majd ébren is tartja:

sudo apt install watchdog

Az eredeti állomány elmentése után készítsünk egy alkalmas /etc/watchdog.conf-ot (szoftver watchdog beállítások):

sudo mv /etc/watchdog.conf /etc/watchdog.conf.bak
sudo mcedit /etc/watchdog.conf

amelyben az alábbiakat írjuk elő:

watchdog-device = /dev/watchdog

# This greatly decreases the chance that watchdog won't be scheduled before
# your machine is really loaded
realtime                = yes
priority                = 1

# Uncomment to enable test. Setting one of these values to '0' disables it.
# These values will hopefully never reboot your machine during normal use
# (if your machine is really hung, the loadavg will go much higher than 25)
max-load-1              = 24
max-load-5              = 18
max-load-15             = 12

Indítsuk újra a watchdog daemont:

sudo systemctl restart watchdog; sudo tail -f /var/log/syslog 

Az indulásról szóló jelentést és az elfogadott paramétereket a syslogban megtekinthetjük.

Gyorsteszt: TODO!

Egyéb eszközök

Virtalizációs guest agentek

Ezek a programok a virtuális gép operációs rendszere és a hypervisor közötti kommunikációért felelnek, telepítésük virtualizált környezetben erősen javasolt.

Hypervisor	Guest agent
Proxmox	sudo apt install qemu-guest-agent
VMWare	sudo apt install open-vm-tools

Kiterjesztett fájlrendszeri attribútumok

Néhány alkalmazás használ kiterjesztett attribútumokat (ezt a gyári kernel is támogatja), emiatt opcionálisan de javasoltan érdemes telepíteni az ezeket lekérdező, beállító segédprogramokat (getfattr, setfattr) tartalmazó Debian csomagot is:

sudo apt install attr

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

PAX kezelőprogram

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

sudo apt install paxctl

Hibajavítások

multipathd, missing path

Amennyiben egy virtuális gépen a /var/log/syslog-ban tömegével látunk ehhez hasonló bejegyzéseket:

Jul  6 16:02:58 sf14 multipathd[766]: sdb: add missing path
Jul  6 16:02:58 sf14 multipathd[766]: sdb: failed to get udev uid: Invalid argument
Jul  6 16:02:58 sf14 multipathd[766]: sdb: failed to get sysfs uid: Invalid argument
Jul  6 16:02:58 sf14 multipathd[766]: sdb: failed to get sgio uid: No such file or directory

akkor módosítani érdemes a multpathd beállításain.

• Ha hozzáférünk a VMware hypervisorhoz, akkor a virtuális gép definíciójához adjuk hozzá az alábbi sort:

disk.EnableUUID = "TRUE"

• Ha ezt nem tudjuk megtenni, egészítsük ki a virtuális gépen a /etc/multipath.conf állományt egy feketelistával:

defaults {
    user_friendly_names yes
}

blacklist {
    device {
        vendor "VMware"
        product "Virtual disk"
    }
}

és indítsuk újra a démont:

sudo systemctl restart multipath-tools

Irodalom

• The official Ubuntu Server Guide
• Ubuntu 20.04 Server Installation (linuxconfig.org)

TODO!