Tartalom

A 3. oldal tartalma

Folytatás

Az előző oldalon elvégeztük a disztribúció Debian 11 (Bullseye) rendszerre történő frissítését, ezen az oldalon pedig átnézzük az alaprendszert, valamint a magasabb szintű szerver szolgáltatásainkat és elvégezzük a szükséges utólagos beállításokat.

Alaprendszer ellenőrzése

A szerver újraindítását követően először az alaprendszert ellenőrizzük, hogy minden rendben van-e.

Verzió és kiadási információk lekérdezése

A verzió és kiadási információkat az alábbi parancsokkal kérdezhetjük le ugyanúgy, mint a frissítés előtt is:

uname -a
lsb_release -a
hostnamectl
cat /etc/os-release
cat /etc/debian_version

Linux debian10 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64 GNU/Linux

[...]

No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 11 (bullseye)
Release:        11
Codename:       bullseye

[...]

   Static hostname: debian10
         Icon name: computer-vm
           Chassis: vm
        Machine ID: c898b9a88b1d44d3864e6dafb76e2e10
           Boot ID: 489a24f650a942af9463dc8c7586fb9c
    Virtualization: oracle
  Operating System: Debian GNU/Linux 11 (bullseye)
            Kernel: Linux 5.10.0-21-amd64
      Architecture: x86-64

[...]

PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

[...]

11.6

Itt már a Debian 11 látható mindenhol, tehát minden rendben van. Egyedül csak a hosztnév maradt (ebben a példában) "debian10", de ez ugye egy saját beállítás, ami nálam éppenséggel megegyezik a korábbi Debian főverzióval, tehát ennek nincs semmi jelentősége. Éles környezetben nem az operációs rendszerének verzióját állítja be az ember, én itt csak a leírások miatt használok ilyen gépneveket, hogy jobban megkülönböztethessem őket egymástól.

A Debian 11 (Bullseye) változatban az 5.10 LTS kernel működik, ami - az 5.10-es kernel 2020. december 13-ai kiadásától számítottan - összesen 5 éven át kap támogatást. További részletek a Debian 11 kiadásról:

• A Debian 11 (Bullseye) operációs rendszer újdonságai, változásai

Csomagok ellenőrzése

Itt most - a régi disztribúció frissítős leírással ellentétben - ezzel a résszel folytatjuk, így először átnézzük az alaprendszert, és majd utána haladunk tovább a magasabb szintű szerver szolgáltatások felé.

Ebben a részben újra átnézzük a Debian csomagokat, és szükség elvégezzük a megfelelő módosításokat, hogy az alaprendszerünk tökéletes formában legyen.

Feleslegessé vált csomagok eltávolítása

Távolítsuk el ismét a feleslegesé vált csomagjainkat az alábbi apt paranccsal:

apt --purge autoremove

Amint láthatjuk itt nálam van 62 eltávolítandó csomag, ami után 527 MB tárhely szabadul fel.
Folytassuk az I opcióval.

Elavult csomagok keresése és eltávolítása

Az elavult csomagok akkor "keletkeznek", amikor frissítjük a teljes Debian rendszert, és az újonnan beállított csomagtárakban már nem érhetők el ezek a csomagok, hanem például az adott szoftverből már egy újabb főverzió jelent meg, így már csak ehhez érkezik frissítés. Ilyenkor célszerű eltávolítani ezeket a csomagokat. Első körben csak keressünk rá ezekre a csomagokra, hogy lássuk hogy a frissítés után milyen csomagokat jelölt a rendszer elavultnak. Ehhez az alábbi parancsok bármelyikét használhatjuk:

aptitude search '~o'
aptitude search ?obsolete

Nem fért ki egy ablaba, de még az apt-show-versions paranccsal is le tudjuk kérdezni ezeket:

apt-show-versions | grep 'No available version'

Itt nagy eséllyel lesznek mindenkinél ilyen csomagok. Ezeknek a listába történő összegyűjtését és törlését tömören az alábbi módon végezhetjük:

Első körben gyűjtsük össze ezeknek a csomagoknak csak a neveit, és készítsünk belőlük egy szöveges fájlt, ami ezt a listát tartalmazza:

aptitude search '~o' | awk '$4 == "-" {print $3; next}; {print $2}' > elavult_csomagok.txt

Aztán nézzük át ezt a listát, és szedegessük ki közülük azokat, amikről tudjuk, hogy még szükségünk van rájuk, pl. régen forrásból telepítettük, és még használjuk valamire, stb. Ehhez nyissuk meg a listát tartalmazó fájlt, és módosítsuk:

nano ./elavult_csomagok.txt

Miután kiszedtük a listából azokat a csomagokat, amikre még biztosan szükségünk van, mentsük le, és töröljük az alábbi paranccsal a listában maradt csomagokat:

apt-get --purge remove $(cat elavult_csomagok.txt)

Ennek a menetéről kicsit részletesebben már írtam a korábbi disztribúció frissítős leírásokban, alább megtekinthetjük az ide vonatkozó részeket:

• Hogyan frissítsük otthoni gépünket Debian 8 (Jessie) rendszerről Debian 9 (Stretch)-re - Elavult csomagok kezelése
• Hogyan frissítsük Debian9 (Stretch) alapú tökéletes szerverünket Debian 10 (Buster) rendszerre (3. oldal) - Elavult csomagok keresése és eltávolítása

Feleslegessé vált csomagok ismételt eltávolítása

Futtassuk ezt is újra, ilyenkor még itt is előfordulnak újabb felesleges csomagok:

apt --purge autoremove

Csomaggyorsítótár kiürítése

Végezetül ürítsük ki a csomaggyorsítótárat, amibe sok csomag megfordult már a frissítés alatt:

du -sh /var/cache/apt/archives
apt-get clean
du -sh /var/cache/apt/archives

Itt is közel fél GB-nyi cuccot törölt a gyorsítótárból.

Végül nézzünk egy upgrade-et:

apt-get upgrade

Itt már teljesen rendben vannak a csomagjaink, az alaprendszerünk naprakész.

Magasabb szintű szerver szolgáltatások ellenőrzése, beállítása

Ebben a részben nézzük át a tökéletes szerver magasabb szintű összetevőit, szolgáltatásait, és szükség esetén elvégezzük a beállításukat.

ISPConfig

Ahhoz hogy a Debian 11 számára megfelelően legyenek konfigurálva az ISPConfig által felügyelt szolgáltatások is, le kell futtatnunk az ISPConfig frissítő script-jét, hogy újrakonfigurálja a szolgáltatásokat. A frissítést "force" módban kell elvégezni, hogy mindenképpen lefusson. Ilyet nemrég csináltunk egy korábbi leírásban. Futtassuk az alábbi parancsot:

ispconfig_update.sh --force

Select update method (stable,nightly,git-develop) [stable]: [Enter]

Shall the script create a ISPConfig backup in /var/backup/ now? (yes,no) [yes]: [Enter]

Majd jön még további két kérdés, ezekre is üssünk enter-eket:

Reconfigure Permissions in master database? (yes,no) [no]: [Enter]
Service 'firewall_server' has been detected (currently disabled) do you want to enable and configure it?  (yes,no) [no]: [Enter]

És itt jön a lényeg:

Reconfigure Services? (yes,no,selected) [yes]: [Enter]

Itt megkérdezi, hogy szeretnénk-e újrakonfigurálni a szolgáltatásokat. Lényegében emiatt futtattuk most ezt az egészet, így itt is nyomjunk egy entert, mivel az igen válasz az alapértelmezett.

Majd a frissítő script teszi a dolgát...

Configuring Postfix
Configuring Dovecot
Configuring Spamassassin
Configuring Amavisd
Configuring Getmail
Configuring BIND
Configuring Pureftpd
Configuring Apache
Configuring vlogger
Configuring Apps vhost
Configuring Jailkit
Configuring AppArmor
Configuring Database
Updating ISPConfig

Ezután jön még három újabb kérdés, amiből az első kettő az ISPConfig SSL tanúsítványára vonatkozik, az utolsó pedig a crontab-ra:

ISPConfig Port [8080]: [Enter]
Create new ISPConfig SSL certificate (yes,no) [no]: [Enter]
Reconfigure Crontab? (yes,no) [yes]: [Enter]

Itt ha nem szeretnénk változtatni a jelenlegi SSL beállításon, akkor az első kettőre nyomjunk entert, majd a végén a crontab újrakonfigurálásához is egy entert.

Ezzel tehát ahol szükséges volt, az ISPConfig elvégezte a megfelelő módosításokat.

PHP

Ebben a részben a PHP konfigurálását végezzük el, amelyet a jobb áttekinthetőség és kezelhetőség kedvéért több alrészre osztottam.

PHP 7.4 telepítése (opcionális)

A Debian 10-ben még a 7.3-as volt az alapértelmezett PHP változat, de a Debian 11 (Bullseye) esetén már a PHP 7.4. Mivel most Debian főverziót frissítettünk, így alapértelmezetten nem rendelkezünk ezzel a verzióval, hacsak nem telepítettük fel korábban választható PHP verzióként. Amennyiben annak idején nem tettük ezt meg, akkor most pótolhatjuk, amennyiben szeretnénk használni.

Persze ma már életszerűbb, hogy egyszerűen átugorjuk a PHP 7.x ágát, és a 8.x ágat használjuk, de ha mégis szükségünk lenne a - Debian 11-ben amúgy alapértelmezetten elérhető - PHP 7.4 verziójára, vagy egyszerűen csak szeretnénk, hogy a 7.x ágból is rendelkezzünk a legfrissebb változattal - mert még vannak olyan weboldalaink, amik a 7.x ágat igénylik -, akkor a telepítés menetéről és az ISPConfig kezelőpanelkünkben történő beállításukról az alábbi linkeken tájékozódhatunk:

• Hogyan telepíthetünk újabb PHP verziókat Debian 9 (Stretch) LAMP szerverünkre PHP-FPM módban - PHP 7.4
• Hogyan állíthatunk be egyedi PHP verziókat ISPConfig rendszerű szerverünkön - PHP 7.4

Természetesen ezekről az oldalakról bármelyik PHP verzió telepítését elvégezhetjük, amennyiben szükségünk van rájuk, és korábban nem vettük igénybe ezeket.

PHP 7.4 alapértelmezetté tétele (opcionális)

A Debian 11 (Bullseye) rendszerben a hivatalos csomagtárban a PHP 7.4 érhető el, ennek megfelelően - friss telepítések esetén - ez is kerül alapértelmezettként beállításra. Azonban mivel most egy Debian 10 (Buster) rendszerről frissítettünk fel, ezért ez az alapértelmezés ebben az esetben a korábbi rendszerünk örökségeként a PHP 7.3 marad.

Akár most telepítettük fel a PHP 7.4-et, akár még korábban, az alapértelmezés beállítását célszerű elvégezni (persze ha nem telepítettük fel egyáltalán, akkor hagyjuk ki ezt a részt). Ez a rész természetesen nem kötelező, nem lesz semmi bajunk ha ezt nem állítjuk át, de ha teljesen precízek szeretnénk lenni, akkor ezt is rendbe tesszük.

Amennyiben tehát el szeretnénk végezni ezt a beállítást, akkor hajtsuk végre a következőket

Alapértelmezés beállítása az ISPConfig kezelőpanelben

Az ISPConfig kezelőpanel is külön kezeli az alapértelmezett PHP verziót a további feltelepített verzióktól. Ebből adódóan a kezelőpanelben is el kell végezni ezt a beállítást.

Lépjünk be az ISPConfig panelünkbe adminként, majd navigáljunk az alábbi menübe:

System -> Server Config -> (saját hosztnevünk opciója) -> Web fül -> 

És itt lejjebb görgetve a PHP Settings kinyíló panel:

Itt írjunk át minden "7.3" -as hivatkozást, részt "7.4"-re, hogy így nézzen ki utána:

Majd mentsük le az űrlapot.

Alapértelmezés beállítása a rendszer többi részében

Nem csak az ISPConfig kezeli a PHP-t, hanem a rendszer egyéb részei is használják. Például ha a parancssori (CLI) -ben futtatunk egy PHP scriptet, akkor is az alapértelmezettként beállított PHP fut, vagy ha konkrétan nem előre beállított PHP-FPM konfigurációban futtatunk valamilyen webes felületet, például amikor a mod_php nem érhető el (például a HTTP/2 beállítás miatt), akkor az Apache "átterel" minden PHP kérést az alapértelmezett PHP-FPM verzió alapértelmezett "www" pool-jába. Ezért a rendszer többi része számára is be kell állítanunk az alapértelmezéseket.

Ezeknek a beállításához futtassuk az alábbi update-alternatives parancsokat:

update-alternatives --config php
update-alternatives --config php-cgi
update-alternatives --config php-fpm.sock

Itt válasszuk ki mindegyik esetben a 7.4-es PHP-t:

Az FPM esetén itt valami gubanc van, mert nincs a listán a PHP 7.4, pedig telepítve van ezen a szerveren. Így most válasszuk a 7.3-at és mindjárt javítjuk is. Ha másnál is ilyen történne - ami elég ritkán, de elő szokott fordulni -, akkor telepítsük újra a php7.4-fpm csomagot, ez megoldja a problémát:

apt-get install --reinstall php7.4-fpm

Majd ismételjük meg a beállítást:

update-alternatives --config php-fpm.sock

Ezután cseréljük le az alapértelmezett PHP-FPM handlert is, végül indítsuk újra az Apache-ot:

a2disconf php7.3-fpm
a2enconf php7.4-fpm
systemctl restart apache2

phpMyAdmin

A phpMyAdmin webes adatbáziskezelő felülettel is van még dolgunk. Először nézzünk rá a kezdőoldalára, aztán folytassuk a munkát.

Itt két dologgal kell most foglalkoznunk:

• PHP verzió: 7.3.33 (jobboldalon a középső panelen: ez nem váltott át 7.4-re az alapértelmezések beállítása után sem)
• phpMyAdmin verzió: 5.1.0 (jobboldalon az alsó panelen: van ennél már frissebb hivatalos phpMyAdmin kiadás is: az 5.2.0)

A hátralévő részben ezeket fogjuk még megoldani.

PHP-FPM verzió beállítása (opcionális)

Amennyiben annak idején a phpMyAdmin telepítésekor beállítottuk a PHP-FPM-et a Debian 10 LAMP szerver készítésekor, akkor ezt a 7.3.x verziót láthatjuk, mivel egy 7.3-as PHP-FPM külön pool-ba állítottuk be akkor, ezért nincsenek hatással erre a fentebbi alapértelmezések beállítása.

Ha viszont akkor ezt nem állítottuk be, akkor itt nagy valószínűséggel a 7.4-es verziót láthatjuk, ami a fentebb beállított PHP alapértelmezésnek köszönhető.
Ebben az esetben kétféleképpen futhat a phpMyAdmin: vagy Apache modulként (a 7.4-es mod_php verzióval), vagy ha a mod_php le van tiltva, akkor az alapértelmezett PHP-FPM poolban (ilyenkor szintén a 7.4-es alapértelmezés szerinti verzióban).

Akármelyik szituáció is áll fenn szerverünkön, mindegyikkel jól működik a phpMyAdmin. Viszont ha szeretnénk hogy jobban finomhangolható legyen a phpMyAdmin-t futtató PHP környezet, akkor futtassuk egy külön PHP-FPM pool-ban. Ha ezt korábban nem tettük meg, akkor a fenti linken megtudhatjuk ennek előnyeit is, valamint a beállítás menetét is. Természetesen a korábbi leírás követése esetén már ne a 7.3-as verziót használjuk, hanem a legújabbat, ami a szerverünkön elérhető.

Ha pedig korábban már elvégeztük ezt a beállítást szerverünkön, akkor csak módosítani kell ezeket a beállításokat; ehhez kövessük az alábbi részeket. Ezen a szerveren a legújabb telepített és beállított PHP a 8.0, ezért én most erre fogom átállítani a phpMyAdmint futtató PHP-FPM környezetet. (Itt mindenki a saját, legfrissebb PHP verziójával haladjon végig tovább.)

Amennyiben nem tudjuk, hogy hogyan van beállítva a phpMyAdmin webes adatbáziskezelő panelünk, mert nem emlékszünk rá, vagy mert mástól "örököltük" a szervert, vagy csak simán bizonytalanok vagyunk ebben, akkor a phpMyAdmin kezdőoldalán megjelenő PHP verziónak megfelelő PHP-FPM-re futtassunk egy állapot lekérdezést. Például nálam a 7.3-as esetén:

systemctl status php7.3-fpm.service

● php7.3-fpm.service - The PHP 7.3 FastCGI Process Manager
     Loaded: loaded (/lib/systemd/system/php7.3-fpm.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2023-01-27 12:43:59 CET; 3h 2min ago
       Docs: man:php-fpm7.3(8)
    Process: 742 ExecStartPost=/usr/lib/php/php-fpm-socket-helper install /run/php/php-fpm.sock /etc/php/7.3/fpm/pool.d/www.conf 73 (code=exited, status=0/SUCCESS)
   Main PID: 587 (php-fpm7.3)
     Status: "Processes active: 0, idle: 5, Requests: 47, slow: 0, Traffic: 0req/sec"
      Tasks: 6 (limit: 4675)
     Memory: 57.3M
        CPU: 2.166s
     CGroup: /system.slice/php7.3-fpm.service
             ├─  587 php-fpm: master process (/etc/php/7.3/fpm/php-fpm.conf)
             ├─  731 php-fpm: pool phpmyadmin
             ├─  734 php-fpm: pool phpmyadmin
             ├─  735 php-fpm: pool www
             ├─  741 php-fpm: pool www
             └─26206 php-fpm: pool phpmyadmin

jan 27 12:43:58 debian10 systemd[1]: Starting The PHP 7.3 FastCGI Process Manager...
jan 27 12:43:59 debian10 systemd[1]: Started The PHP 7.3 FastCGI Process Manager.

Ha itt látunk "phpmyadmin" nevű pool-hoz kapcsolódó process-eket (ahogyan ebben a példában is), akkor korábban elvégeztük a beállítást. Ha itt csak az alap "www" pool két process-ét látjuk (esetleg weboldalainkat még), de phpmyadmin-t nem, akkor nincsen beállítva. Persze itt fontos, hogy az adatbázis kezelő kezdőoldalán megjelenő PHP verzióra ellenőrizzünk rá, mert annak a verziónak az FPM-jében fordulhat csak elő, a többi verziónál nem.

Ezek alapján tehát három opció közül választhatunk:

• Ha bonyolultnak találjuk ezt a részt, és inkább nem szeretnénk hozzányúlni, akkor nyugodtan ugorjuk át, enélkül is fog működni a phpMyAdmin panelünk.
• Ha nem látjuk a fenti állapot kimenetében a "phpmyadmin" tételeket, akkor nincs beállítva. Ha be szeretnénk állítani, akkor a fentebbi linkre, vagy ide kattintva megtaláljuk a beállítás elvégzéséhez szükséges információkat.
• Ha látjuk a kimenetben a "phpmyadmin" -t tartalmazó sorokat, akkor már be van állítva, és ebben az esetben csak módosítani kell a beállításokat. 

Itt most a harmadik opcióval folytatjuk, tehát van már egy korábbról elvégzett PHP-FPM beállításunk a phpMyAdmin felületünkre, és most ezt fogjuk módosítani az újabb PHP verzióra.

FPM pool átállítása

Első körben mozgassuk át a jelenlegi pool-t a 8.0-ás FPM-be. Ehhez futtassuk az alábbi parancsot:

mv /etc/php/7.3/fpm/pool.d/phpmyadmin.conf /etc/php/8.0/fpm/pool.d/

Ezután szerkesszük ezt az áthelyezett fájlt:

nano /etc/php/8.0/fpm/pool.d/phpmyadmin.conf

A fájl tartalma kimásolva:

; Pool-unk neve
[phpmyadmin]

; Futtató felhasználó
user = www-data
group = www-data

; Socket fájl
listen = /run/php/php7.3-phpmyadmin-fpm.sock

; Socket fájl tulajdonosa és módja
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

; Process management beállítások
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
pm.max_requests = 0

; log fájl
access.log = /var/log/phpmyadmin/php-fpm-access.log
access.format = "Log: %t \"%m %r%Q%q\" %s time:%{mili}dm mem:%{kilo}MKB cpu:%C%%"

; Ezekben a fájltípusokban futhatnak php kódok
security.limit_extensions = .php .html

; Környezeti változók
env[HOSTNAME] = $HOSTNAME
env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /var/lib/phpmyadmin/tmp
env[TMPDIR] = /var/lib/phpmyadmin/tmp
env[TEMP] = /var/lib/phpmyadmin/tmp

; PHP beállítások
php_admin_flag[log_errors] = on
php_flag[display_errors] = off
php_admin_value[session.gc_maxlifetime] = 3600
php_admin_value[error_log] = /var/log/phpmyadmin/php-errors.log
php_admin_value[memory_limit] = 128M
php_admin_value[upload_max_filesize] = 256M


; További PHP beállítások, amiket a 'gyári' phpMyAdmin Apache konfigból vettünk át
php_flag[magic_quotes_gpc] = off
php_flag[track_vars] = on
php_flag[register_globals] = off
php_value[include_path] = .
php_admin_value[upload_tmp_dir] = /var/lib/phpmyadmin/tmp
php_admin_value[open_basedir] = /usr/share/phpmyadmin/:/etc/phpmyadmin/:/var/lib/phpmyadmin/:/usr/share/php/php-gettext/:/usr/share/php/php-php-gettext/:/usr/share/javascript/
php_admin_value[mbstring.func_overload] = 0

Az itt lévő PHP környezeti beállításokkal most nem foglalkozunk, ezekről szintén olvashatunk a fentebb linkelt oldalon. Itt amivel most dolgunk van az az alábbi sor, ami rögtön az elején van a 9. sorban:

listen = /run/php/php7.3-phpmyadmin-fpm.sock

Ezt módosítsuk a saját új PHP verziónkra:

listen = /run/php/php8.0-phpmyadmin-fpm.sock

A socket fájl neve egyébként mindegy hogy micsoda, csak mindenhol ugyanannak kell lennie. Valamint, ha következetesen módosítjuk ilyenkor, akkor később is tudni fogjuk, hogy mi melyik FPM-hez tartozik. Ha átjavítottuk a fájl nevét (mindenki a saját legfrissebb PHP verziójára), mentsük le.

Ezután nyissuk meg a phpMyAdmin Apache konfigurációs fájlját:

nano /etc/apache2/conf-available/phpmyadmin.conf

Majd itt is a fentieknek megfelelően javítsuk át a korábbi socket fájl nevet az alábbi sorban:

		SetHandler "proxy:unix:/run/php/php7.3-phpmyadmin-fpm.sock|fcgi://localhost"

Ezt módosítsuk az alábbira:

		SetHandler "proxy:unix:/run/php/php8.0-phpmyadmin-fpm.sock|fcgi://localhost"

Ezután sorrendben így indítsuk újra az alábbi szolgáltatásokat:

systemctl restart php7.3-fpm.service
systemctl restart php8.0-fpm.service
systemctl restart apache2.service

Végül nézzünk vissza a phpMyAdmin felületre:

És itt már láthatjuk a 8.0.27-es PHP verziót - az én példámban.

Ezután ellenőrizhetjük a két PHP-FPM szolgáltatást is:

systemctl status php7.3-fpm.service
systemctl status php8.0-fpm.service

Itt is láthatjuk, hogy a phpMyAdmin pool-ja átkerült a 8.0-ás FPM szolgáltatás felügyelete alá. A 8.0-ban itt még van egy web1 pool is, amiben a szerveren lévő Drupal 9-es weboldal fut. A www pedig az alapértelmezett pool mindegyik FPM verzió esetén amiben akkor kerül futtatásra valami, amikor a mod_php letiltásra kerül, és emiatt az alapértelmezett FPM konfiguráció átirányítja a kérést a saját www pool-jába, amennyiben az adott weboldal vagy webalkalmazás nem rendelkezik külön, saját beállított pool-al sem, ellentétben például az itteni phpMyAdmin-al. Persze mindezeket csak érdekességképpen írtam le, nincs ezekkel különösebb dolgunk.

phpMyAdmin frissítése

Itt is szükség lesz egy kis visszaemlékezésre...

Annak idején a Debian 10 (Buster) LAMP szerver telepítésekor a phpMyAdmin-t az elején csak kézzel lehetett telepíteni a forrásából, mivel a Debian 10 stabil csomagtára nem tartalmazza a phpmyadmin csomagot. Idővel azonban a Debian 10 backports tárolójába bekerült a phpmyadmin csomag, így onnantól lehetett már az APT csomagkezelő segítségével is telepíteni a megszokott módon.

Itt ebben a részben most tehát ez alapján kell eljárnunk:

• Ha már a Debian 10 backports tárolójából telepítettük rendesen csomagból a phpMyAdmint, akkor itt nincs további teendőnk, mert akkor az már a disztribúció frissítést követően a Debian 11 csomagtárából már frissült is. Azért ebben az esetben is ellenőrizzük a phpMyAdmin felületén annak verzióját, ha még nem tettük.
• Ha pedig még a korábbi időszakban kézzel, forrásból telepítettük annak idején a phpMyAdmin-t, vagy nem emlékszünk a phpMyAdmin példányunk eredetére, akkor még ezt a rövid részt készítsük el, hogy naprakész legyen a phpMyAdmin rendszerünk.

A phpMyAdmin frissitéséhez az ISPConfig fejlesztői készítettek egy automatikus frissítő scriptet, aminek használatával fogjuk itt frissíteni mi is a phpMyAdmin példányunkat. A script ellenőrzi az imént említett szituációkat is, így ha csomagból került feltelepítésre, akkor nem csinál semmit, csak kiírja, hogy a phpMyAdmin példányunk naprakész (természetesen amennyiben valóban frissítettük a többi csomagunkkal együtt), majd kilép. Így tehát ezt a scriptet bármelyik esetben biztonságosan futtathatjuk. Továbbá a script nem nyúl az Apache konfigurációhoz sem, ezért a korábbi egyedileg beállított PHP-FPM részeket sem érinti.

A script a curl parancsot is használja (valamint mi is ezzel futtatjuk), ennek működéséhez telepítsük a curl csomagot:

apt-get install curl

Majd futtassuk az alábbi parancsot, ami automatikusan frissíti nekünk a webes adatbáziskezelőnket:

curl https://git.ispconfig.org/ispconfig/tools/-/raw/master/auto_update_phpmyadmin.sh -sL | sh

phpMyAdmin version is out of date, installed version: 5.1.0, latest version: 5.2.0
Starting phpMyAdmin update.
phpMyAdmin has been updated to the latest version (5.2.0).
If you had any custom config files other than the config.inc.php and/or a .htaccess file, you have to copy them yourself from /usr/share/phpmyadmin-bak-5.1.0-230127162801/ to /usr/share/phpmyadmin/

Itt nálam frissítette az 5.1.0 verzióról az 5.2.0-ra.
Megnézzük "bentről" is:

Frissült is, de közben lett is egy új hibaüzenetünk is alul:

"A $cfg ['TempDir'] (/var/lib/phpmyadmin/tmp 1) nem elérhető. A phpMyAdmin nem képes a sablonok elrejtésére és lassú lesz."

Ezzel a hibával már egy korábbi leírásban foglalkoztunk, és egy másik leírásban tartós javítást készítünk hozzá. De addig sincs vele semmi gond, használható a panel ezzel is.

Ha szeretnénk beállítani ezt az automatikus frissítő scriptet cron feladatba is, hogy ezután teljesen automatikusan futhasson a háttérben naponta, akkor adjuk ki az alábbi parancsokat:

curl https://git.ispconfig.org/ispconfig/tools/-/raw/master/auto_update_phpmyadmin.sh -L -o /etc/cron.daily/auto_update_phpmyadmin
chmod +x /etc/cron.daily/auto_update_phpmyadmin

Az első parancs ismét letölti a scriptet, de most nem futtatja, hanem elhelyezi egy fájlban a /etc/cron.daily/ könyvtárban, a második parancs pedig futtathatóvá teszi.

Webes felületek ellenőrzése

Végül fussunk át a webes alkalmazásainkon és a weboldalainkon, hogy minden megfelelően működik-e (a phpMyAdmint már láttuk, így ezt itt kihagyjuk).

Weboldal

Töltsük be ismét a weboldalunkat. Ebben a példában is a Drupal oldal állapotjelentését tekintem meg:

Az adatbázis verzió változás itt is látszik: 10.3.36 -> 10.5.18. Itt minden rendben (a Drupal jellegű figyelmeztetésekkel itt most nem foglalkozunk).

ISPConfig

Ezt már láttuk a frissítés óta, de ránézhetünk újra:

Roundcube Webmail

A Roundcube is hibátlanul működik.

Munin

A Munin is rendben van.

Monit

A monit is működik, és az általa monitorozott szolgáltatások és erőforrások is rendben vannak.

Ezzel készen is állunk mindennel, a rendszer használatra kész.

Konklúzió

A Debian 10 (Buster) rendszerünk immár Debian 11 (Bullseye) verzióra hallgat, amiben minden csomag és szolgáltatás frissítésre került. Sok disztribúció frissítős leírással lehet találkozni a neten, a legtöbbjük megoldja néhány sorban, de én ezzel szándékosan nem akartam közéjük tartozni, így készítettem egy részletes leírást. Nem beszélve arról, hogy ez nem egy sima asztali rendszer frissítése volt, hanem egy webszerveré, amin sok szolgáltatás, konfiguráció és egyedi megoldás van, amiket át kellett nézni egyesével. Így remélem sokak számára hasznos leírással tudtam szolgálni .

Lapozó