Tartalom
- oldal: Frissítések előtt elvégzendő teendők - Felkészülés a frissítésre
- oldal: Debian 9 (Stretch) rendszer teljes frissítése Debian 10 (Buster)-re
- oldal: Frissítések után elvégzendő teendők - Rendszer ellenőrzése
A 2. oldal tartalma
Folytatás
Az előző oldalon átnéztük a frissítése előtti szükséges teendőket, amikkel felkészítettük rendszerünket az új főverzióra, ezen az oldalon pedig folytatjuk a disztribúció Debian 10 (Buster) rendszerre történő frissítésével.
Elkészült a leírás újabb változata:
Debian disztribúció frissítése
Ha minden rendben van a csomagjaink körül akkor kezdhetjük is a főverzió frissítést.
Jelenlegi disztribúció teljes frissítése
Először futtassuk a szokásos apt-get frissítő parancsot az, majd a teljes disztribúció frissítést:
apt-get upgrade
apt-get dist-upgrade
Az apt-get dist-upgrade parancs ekvivalens az apt full-upgrade paranccsal, így itt bármelyiket használhatjuk a teljes frissítés futtatásához.
Nálam itt most nem volt már frissítenivaló:
De más esetekben már volt rá példa, hogy ilyenkor még hosszasan frissítgetett.
Csomagok újbóli ellenőrzése
Ha az előző teljes frissítés sok csomag frissítésével járt, akkor újból ellenőrizzük a csomagjainkat a fentebb már leírt módokon:
- Visszatartott csomagok keresése
- Törött csomagok keresése
- Feleslegessé vált csomagok eltávolítása
Itt most csak ezeket ellenőrizzük.
Ha az ittenihez hasonlóan semmit, vagy csak alig pár csomagot frissített, akkor kihagyhatjuk ezt az ellenőrzési lépést, mert ilyenkor nem történt számottevő változás a csomag adatbázisban.
Az APT forráslista-fájlok módosítása Debian 10-hez
Nyissuk meg a sources.list fájlt:
nano /etc/apt/sources.list
A nálam lévő így néz ki ezen a Debian 9-es szerveren:
# # deb cdrom:[Debian GNU/Linux 9.6.0 _Stretch_ - Official amd64 NETINST 20181110-11:34]/ stretch main #deb cdrom:[Debian GNU/Linux 9.6.0 _Stretch_ - Official amd64 NETINST 20181110-11:34]/ stretch main deb http://ftp.hu.debian.org/debian/ stretch main contrib non-free deb-src http://ftp.hu.debian.org/debian/ stretch main contrib non-free deb http://security.debian.org/debian-security stretch/updates main contrib non-free deb-src http://security.debian.org/debian-security stretch/updates main contrib non-free # stretch-updates, previously known as 'volatile' deb http://ftp.hu.debian.org/debian/ stretch-updates main contrib non-free deb-src http://ftp.hu.debian.org/debian/ stretch-updates main contrib non-free # Backports tároló (bekerült: 2020.02.17) deb http://ftp.debian.org/debian stretch-backports main contrib non-free deb-src http://ftp.debian.org/debian stretch-backports main contrib non-free # Sury.org csomagtára (bekerült: 2020.12.08) deb https://packages.sury.org/php/ stretch main
A fájlról készítsünk egy biztonsági másolatot:
cp /etc/apt/sources.list /etc/apt/sources.list.bak
Majd írjunk át a fájlban minden "stretch" szót, vagy ezzel kezdődő részt "buster" -re. Ezt megtehetjük kézzel a szerkesztőben is, vagy akár egy egyszerű sed-es paranccsal:
sed -i 's/stretch/buster/g' /etc/apt/sources.list
A lényeg, hogy végül minden "stretch" szó legyen átírva "buster"-re. Nálam tehát így néz ki a módosítás után:
# # deb cdrom:[Debian GNU/Linux 9.6.0 _Stretch_ - Official amd64 NETINST 20181110-11:34]/ buster main #deb cdrom:[Debian GNU/Linux 9.6.0 _Stretch_ - Official amd64 NETINST 20181110-11:34]/ buster main deb http://ftp.hu.debian.org/debian/ buster main contrib non-free deb-src http://ftp.hu.debian.org/debian/ buster main contrib non-free deb http://security.debian.org/debian-security buster/updates main contrib non-free deb-src http://security.debian.org/debian-security buster/updates main contrib non-free # buster-updates, previously known as 'volatile' deb http://ftp.hu.debian.org/debian/ buster-updates main contrib non-free deb-src http://ftp.hu.debian.org/debian/ buster-updates main contrib non-free # Backports tároló (bekerült: 2020.02.17) deb http://ftp.debian.org/debian buster-backports main contrib non-free deb-src http://ftp.debian.org/debian buster-backports main contrib non-free # Sury.org csomagtára (bekerült: 2020.12.08) deb https://packages.sury.org/php/ buster main
Valamint ne feledkezzünk meg a listafájl-könyvtárról sem, ahol még előfordulhatnak további csomagtárakat tartalmazó listafájlok: a /etc/apt/sources.list.d/ könyvtárban. Vannak külső programok, amik előszeretettel helyeznek itt el saját listafájlokat a telepítésükkor, így azoknak a csomagjai ezek alapján frissülnek. Tehát futtassuk a cserélő parancsot ezeken is, így ha vannak itt is fájlok, akkor azokban is átírja a parancs:
sed -i 's/stretch/buster/g' /etc/apt/sources.list.d/*.list
Természetesen azért nézzünk át minden fájlt, hogy biztosan minden jól legyen módosítva.
Ha megvagyunk a módosítással, akkor futtassuk CSAK a csomagtár adatbázis frissítését, a csomagfrissítést MÉG NE futtassuk!
apt-get update
Itt hiba nélkül lefutott. Ha valahol hiba lenne, akkor valószínű nem került eltávolításra egy olyan harmadik féltől származó csomagtár, ami nem tartalmaz Debian 10 csomagokat. Ilyenkor célszerű utánanézni az adott szoftver weboldalán, hátha esetleg másik url címen található a Debian 10-hez a csomagtáruk, stb.
Csomagtárak frissítésének a szimulációja
Itt még futtatunk egy szimulációt, és megnézzük, hogy mely csomagok frissíthetők, és melyek nem. Ehhez futtassuk a következő parancsot:
apt list --upgradable
Nálam ennek a kimenete:
Itt még lekérdezhetjük a parancs kimenetének hibakódját is, így egyből biztosak lehetünk a csomagok frissítésének sikerességében ha 0 értéket kapunk. Továbbá még érdekességképpen lefuttathatjuk újra és egy csővezetéken megszámolhatjuk a kiírt sorok számát. Ezzel láthatjuk hogy hány csomag fog majd esetlegesen frissülni az ez utáni részben.
Alapszintű frissítés
A szimuláció után először alapszíntű frissítést hajtunk végre, ami csak azokat a csomagokat frissíti, amelyekhez nincs szükség más csomagok telepítésére vagy eltávolítására. Ehhez adjuk ki a szokásos parancsot:
apt-get upgrade
Ahogyan itt is látható, ebben a példában 467 csomagot fog frissíteni, és nem telepít újakat, nem töröl meglévőket. Ezután folytassuk az Igen opcióval.
A csomagkezelő dolgozik egy ideig, majd közben néhány esetben megáll, amikor várja a közbeavatkozásunkat.
Ha viszont pontosan ugyanilyen szerveren végezzük a frissítést, mint amit a leírás elején említettem, akkor jó eséllyel ugyanezeket a kérdéseket kapjuk.
Itt általánosságban az alábbi dolgokkal találkozhatunk:
- Görgethető, szövegeket megjelenítő részek, amikből a "q" billentyűvel léphetünk ki - folytatva a frissítési folyamatot.
- Szöveges módú színes dialógus ablakok, ahol kérdéseket tesz fel a rendszer a frissítéssel kapcsolatban, amikre többféle opció közül választva reagálhatunk.
- Konfigurációs ütközések megjelenítése, ahol az általunk korábban módosított konfigurációkat veti össze a csomagok újabb verzióinak alapbeállításaival, ahol el kell döntenünk, hogy melyik változatot alkalmazza a rendszer
A továbbiakban tehát ilyesmikre számíthatunk, amik között lesznek olyanok, amik mindenhol megjelennek, és olyanok, amik csak egy adott konfiguráció esetén, ahol az adott program vagy szolgáltatás telepítve van. Most pedig lássuk konkrétan az én példámat:
APT listchanges
Elsőként az APT csomagkezelő változásairól tájékoztat, ez mindenkinél megjelenik:
Itt megjeleníti az apt csomagkezelő változatnaplóját. Ezen a felületen az egér görgetővel, illetve a le és fel billentyűkkel van lehetőségünk görgetni a szövegben, a frissítési folyamathoz való visszatéréshez pedig a "q" billentyűvel léphetünk ki belőle.
libc6 konfiguráció
Ezután a libc6 konfigurációja jön, ez is mindenkinél megjelenik:
┌────────────────────────────────────────────────────────┤ Configuring libc6:amd64 ├────────────────────────────────────────────────────────┐ │ │ │ There are services installed on your system which need to be restarted when certain libraries, such as libpam, libc, and libssl, are │ │ upgraded. Since these restarts may cause interruptions of service for the system, you will normally be prompted on each upgrade for the │ │ list of services you wish to restart. You can choose this option to avoid being prompted; instead, all necessary restarts will be done │ │ for you automatically so you can avoid being asked questions on each library upgrade. │ │ │ │ Restart services during package upgrades without asking? │ │ │ │ <Yes> <No> │ │ │ └───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
Itt válasszuk a "Yes" opciót és lépjünk tovább.
Konfiguráció ütközés: limits.conf
A következő kérdés már egy egyedi beállításról kérdez, a /etc/security/limits.conf fájllal kapcsolatban:
Configuration file '/etc/security/limits.conf'
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
The default action is to keep your current version.
*** limits.conf (Y/I/N/O/D/Z) [default=N] ?
Amennyiben ugyanezt a szervert telepítettük, tehát a Debian 9 tökéletes szervert, akkor annak idején a telepítéskor ezen a részen módosítottuk ezt a fájlt. A linkre kattintás után kicsit lejjebb görgetve megtaláljuk a limit.conf fájl módosítását, tehát ha megjelenik ez a konfiguráció ütközéses rész, akkor biztosan mi állítottuk be ezt a fájlt, ami ezért most eltér a frissített csomagban található konfigurációtól.
Ennél a fajta kérdésnél (és a többi ilyennél is) az alábbi lehetőségeink vannak:
- Y vagy I: telepíti a csomag karbantartójának verzióját, azaz felülírja a beállításainkat a csomag új verziójához adott alapbeállításokkal.
- N vagy O: megtartja a jelenlegi beállításainkat, tehát figyelmen kívül hagyja az új verzióhoz csomagolt konfigurációs fájlt.
- D: megjeleníti a két konfiguráció változat közötti eltéréseket
- Z: indít egy shell parancsértelmezőt, hogy magunk vizsgálódhassunk ebben a szituációban a parancssorból
Az ilyen típusú kérdéseknél mindig nézzük először meg az eltéréseket, hogy a megfelelő döntést hozhassuk. Ennek megfelelően tehát először válasszuk a D opciót:
--- /etc/security/limits.conf 2019-01-15 21:05:31.443235783 +0100 +++ /etc/security/limits.conf.dpkg-new 2019-02-14 08:08:47.000000000 +0100 @@ -24,7 +24,7 @@ # - data - max data size (KB) # - fsize - maximum filesize (KB) # - memlock - max locked-in-memory address space (KB) -# - nofile - max number of open files +# - nofile - max number of open file descriptors # - rss - max resident set size (KB) # - stack - max stack size (KB) # - cpu - max CPU time (MIN) @@ -53,7 +53,4 @@ #ftp - chroot /ftp #@student - maxlogins 4 -mysql soft nofile 65535 -mysql hard nofile 65535 - # End of file
Az itt látható részen a fejléc változott, két komment sor, és lent a mi beállításaink találhatók, amit "ki szeretne venni" az új konfiguráció szerint.
Itt tehát csak a saját módosításaink miatt van eltérés, ezért tartsuk meg őket, nem került bele semmilyen újdonság, ami miatt le kellene cserélnünk. Ebből az összehasonlító részből a "q" billentyűvel léphetünk vissza az előző menübe, majd itt válasszuk az N opciót, azaz tartsa meg a régi beállításainkat.
Konfiguráció ütközés: jk_init.ini (Jailkit)
Kis konfigurálás után a következő állomás egy újabb konfigurációs ütközéssel kapcsolatos kérdés, mégpedig a Jailkit beállításainak változása:
Configuration file '/etc/jailkit/jk_init.ini'
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
The default action is to keep your current version.
*** jk_init.ini (Y/I/N/O/D/Z) [default=N] ?
A Jailkit egy segédprogram gyűjtemény, amely a felhasználói fiókokat korlátozza meghatározott fájlok hozzáférésére és parancsok használatára. A programot a Debian 9 szerver építése során telepítettünk a szerverre, amit az ISPConfig kezel. A szoftvert ugyan szabályosan .deb csomagként telepítettük, de nem a Debian 9 csomagtáraiból - mivel azokban nem volt elérhető a jailkit csomag -, hanem a programnak a forrásából kellett előállítanunk a bináris csomagot, amit aztán már normál csomagként telepíthettünk a dpkg paranccsal.
Mivel a Debian 10 (Buster) Backports tárolója - ami telepítve van ezen a szerveren - már tartalmazza a jailkit csomagot, így ez a csomag is kapja már innentől a hivatalos frissítéseket. Ezért jött elő ez a konfiguráció ütközés, amit most meg kell oldanunk.
Itt is nézzük meg előbb a változásokat, tehát válasszuk a D opciót. Itt elég hosszú a változások listája, ezért most nem másoltam ide be, de ha megnézzük, itt sok mindent másképp állít be. És mivel ezt nem mi állítgattuk így be, ezért itt fogadjuk el a friss verzióban lévő beállításokat, tehát válasszuk a Y opciót.
Konfiguráció ütközés: Spamassassin
A Spamassassin egy spamszűrő program, amit úgyszintén a szerver telepítésekor tettünk fel. Most ennek a megváltozott konfigurációja miatt kérdez bennünket:
Configuration file '/etc/default/spamassassin'
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
The default action is to keep your current version.
*** spamassassin (Y/I/N/O/D/Z) [default=N] ?
Először nézzük meg ennek is a változásait: D billentyű.
--- /etc/default/spamassassin 2021-10-26 14:41:38.629756299 +0200 +++ /etc/default/spamassassin.dpkg-new 2021-03-26 23:04:43.000000000 +0100 @@ -4,11 +4,10 @@ # WARNING: please read README.spamd before using. # There may be security risks. -# If you're using systemd (default for jessie), the ENABLED setting is -# not used. Instead, enable spamd by issuing: -# systemctl enable spamassassin.service -# Change to "1" to enable spamd on systems using sysvinit: -ENABLED=1 +# Prior to version 3.4.2-1, spamd could be enabled by setting +# ENABLED=1 in this file. This is no longer supported. Instead, please +# use the update-rc.d command, invoked for example as "update-rc.d +# spamassassin enable", to enable the spamd service. # Options # See man spamd for possible options. The -d option is automatically added.
Itt az "ENABLED=1" kapcsolót akarja kiszedni, mivel ez nem lesz támogatott a további verziókban. Így tehát itt is fogadjuk el a friss verzió változásait. Először lépjünk vissza a q billentyűvel, majd válasszuk az Y opciót.
Ezután még beállít jónéhány csomagot, majd visszakapjuk a prompt-ot.
Teljes disztribúció frissítés
Miután az alapszintű frissítéssel frissítésre kerültek a meglévő csomagok, végre kell még hajtani a teljes frissítést is, hogy befejezzük a teljes Debian 10-re történő frissítési folyamatot. Ez a rész telepíti az összes csomag legújabb elérhető verzióját, valamint azoknak az összes lehetséges függőségeit is.
A művelethez futtassuk a már korábban is használt teljes frissítő parancsot - itt már a Debian 10 csomagtárait használva:
apt-get dist-upgrade
Nálam ennek a kimenete:
Ebben a lépésben itt 302 csomagot frissít, 159 darabot telepít fel, 16-ot töröl. Mindehhez 551 Mb lemezterületre lesz szüksége. Tehát itt is sok dolga lesz a csomagkezelőnek ahol úgyszintén végighaladunk a felhasználói beavatkozást igénylő részeken, amik hasonló típusúak lesznek, mint amilyenekkel már találkoztunk az alapszintű frissítés során. A folytatáshoz válasszuk az Igen opciót.
APT listchanges
A frissítési folyamatnak ebben a fázisában is előkerül egy változásnapló, de itt a főbb programokat sorolja fel, amik fontos frissítéseken fognak most átesni:
Ezt ugyanúgy átnézhetjük, ha akarjuk, majd a q billentyűvel léphetünk vissza a frissítés folytatására.
Itt jó pár percig megy a telepítés és konfigurálás, majd előjön a következő dialógus.
Konfiguráció ütközés: Dovecot
A Dovecot egy nyílt forráskódú és ingyenes POP3/IMAP levelezőkiszolgáló az Unix-szerű operációs rendszerekre. Ezt a levelezőszervert még a szerver elkészítésekor telepítettük, tehát ezért kerül elő most ez a kérdés, amiben a Dovecot jelenlegi konfigurációja ütközik az új verzió beállításaival:
┌─────────────────────────────────────────────────────┤ Modified configuration file ├──────────────────────────────────────────────────────┐ │ 10-ssl.conf: A new version (/usr/share/dovecot/conf.d/10-ssl.conf) of configuration file /etc/dovecot/conf.d/10-ssl.conf is available, │ │ but the version installed currently has been locally modified. │ │ │ │ What do you want to do about modified configuration file 10-ssl.conf? │ │ │ │ install the package maintainer's version │ │ keep the local version currently installed │ │ show the differences between the versions │ │ show a side-by-side difference between the versions │ │ start a new shell to examine the situation │ │ │ │ │ │ <Ok> │ │ │ └──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
Itt lényegében ugyanolyan konfiguráció ütközéses kérdést tesz fel nekünk a rendszer, csak itt egy fénycsíkos menüből választhatunk.
Mivel a programot telepítettük annak idején, de a beállításaival nem volt különösebb dolgunk, ezért fogadjuk el a friss változat beállításait: "install the package maintainer's version ". Persze előtte még megtekinthetjük a változásokat, ha kíváncsiak vagyunk rá.
GRUB konfigurálása
A következő interakciót igénylő rész - legalább is nálam - a GRUB konfigurálása. Ez a rész normál esetben nem kerül elő másnál, így eredetileg nem is akartam betenni, de gondoltam hátha másnál is megjelenik, akkor nem kell megijedni tőle.
Itt annyi a lényeg, hogy én leklónoztam az eredeti virtuális szerveremet, és a másolaton hajtom végre ezt a frissítést, ezért más lett a virtuális gép merevlemezének az egyedi azonosítója (UUID-je). A konfiguráló program ezt vette észre, így azt hiszi, hogy nincs telepítve a GRUB rendszerbetöltő a merevlemezre, és most kéri, hogy adjuk meg a telepítés helyét:
┌────────────────────────────────────────────────────────┤ grub-pc konfigurálása ├─────────────────────────────────────────────────────────┐ │ A GRUB rendszerbetöltő korábban egy olyan lemezre volt telepítve, amely hiányzik vagy amelynek megváltozott az egyedi azonosítója. │ │ Fontos, hogy biztosítsuk, hogy a GRUB töltőkép ugyanolyan verziójú legyen, mint a GRUB modulok és a grub.cfg. Kérlek ellenőrizd még │ │ egyszer hogy biztosan a megfelelő eszközre írjuk a GRUB-ot. │ │ │ │ Ha nem vagy benne biztos, hogy melyik meghajtó van rendszerlemeznek beállítva a BIOS-ban, jó ötlet lehet mindegyikre feltelepíteni a │ │ GRUB-ot. │ │ │ │ Megjegyzés: A GRUB-ot nemcsak lemez, de partíció rendszerbetöltő részére is lehet telepíteni, és ha van erre alkalmas partíció, azt is │ │ felkínáljuk itt. Mivel azonban így a GRUB kénytelen a blokklista módszert (blocklist) alkalmazni, amely kevésbé megbízható, így ez nem │ │ javasolt. │ │ │ │ GRUB telepítési eszközök: │ │ │ │ [*] /dev/sda (64424 MB; VBOX_HARDDISK) │ │ [ ] - /dev/sda1 (60128 MB; /) │ │ │ │ │ │ <Ok> │ │ │ └──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
Itt válasszuk ki a főbb egységet, tehát magát a merevlemezt, ami felül van, tehát ne a partícióra telepítsük. Majd nyomjuk meg az OK gombot.
Roundcube-core konfigurálása
A Roundcube webmail kliensprogramot is feltelepítettük korábban a szerverre, amikor feltette majdnem ugyanezt a kérdést:
┌──────────────────────────────────────────────────────┤ roundcube-core konfigurálása ├──────────────────────────────────────────────────────┐ │ │ │ According to the maintainer for this package, database upgrade operations need to be performed on roundcube. Typically, this is due to │ │ changes in how a new upstream version of the package needs to store its data. │ │ │ │ If you want to handle this process manually, you should refuse this option. Otherwise, you should choose this option. During the upgrade, │ │ a backup of the database will be made in /var/cache/dbconfig-common/backups, from which the database can be restored in the case of │ │ problems. │ │ │ │ Perform upgrade on database for roundcube with dbconfig-common? │ │ │ │ <Igen> <Nem> │ │ │ └────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
Ennek az a lényege, hogy a RoundCube működéséhez szükséges adatbázist automatikusan konfigurálja-e a dbconfig-common segítségével. A telepítéskor már egyszer beállítottuk hogy igen, kezelje automatikusan, ezért akkor létre is hozta a saját adatbázisát és a hozzátartozó kontroll felhasználót. Most pedig azt kérdezi, hogy szeretnénk-e, hogy a dbconfig-common segítségével automatikusan frissítse az adatbázis struktúrát. Most tehát válasszuk az Igen opciót.
A következő lépésben be is próbálna lépni, de kiadott egy hibaablakot:
┌──────────────────────────────────────────────────────┤ roundcube-core konfigurálása ├──────────────────────────────────────────────────────┐ │ An error occurred while upgrading the database: │ │ │ │ ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) │ │ │ │ Fortunately, /var/cache/dbconfig-common/backups/roundcube_1.2.3+dfsg.1-4+deb9u10.2022-01-20-23.34.59 should hold a backup of the │ │ database, made just before the upgrade (unless the error occurred during backup creation, in which case no changes will have been applied │ │ yet). Your options are: │ │ * abort - Causes the operation to fail; you will need to downgrade, │ │ reinstall, reconfigure this package, or otherwise manually intervene │ │ to continue using it. This will usually also impact your ability to │ │ install other packages until the installation failure is resolved. │ │ * retry - Prompts once more with all the configuration questions │ │ (including ones you may have missed due to the debconf priority │ │ setting) and makes another attempt at performing the operation. │ │ * retry (skip questions) - Immediately attempts the operation again, │ │ skipping all questions. This is normally useful only if you have │ │ solved the underlying problem since the time the error occurred. │ │ * ignore - Continues the operation ignoring dbconfig-common errors. │ │ This will usually leave this package without a functional database. │ │ │ │ Next step for database upgrade: │ │ │ │ abort │ │ retry │ │ retry (skip questions) │ │ ignore │ │ │ │ │ │ <Ok> │ │ │ └────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
Nem tud csatlakozni az adatbázis kiszolgálóhoz. Ez nem minden esetben fordul elő, de nagy valószínűséggel ilyenkor itt hibát dob, mert még nem végezte el az összes program konfigurációját, és addig nem indította el a szolgáltatásokat, így az adatbázis kiszolgálót sem.
Ha tehát ilyen hibába botlunk, akkor ezt úgy tudjuk orvosolni, hogy nyitunk egy másik terminál ablakot, és belépünk ott is root-ként. Ezután ránézünk a mysqld szolgáltatásra:
systemctl status mysqld.service
Ekkor láthatjuk, hogy a kis pötty szürke, és a naplóban is írja, hogy "Stopped". Tehát a frissítési folyamat során többször is le lett állítva, és el lett indítva. Most éppen még nem lett újraindítva, ezért kaptuk a hibát. Indítsuk újra kézzel, és nézzünk rá újra:
systemctl restart mysqld.service
systemctl status mysqld.service
Közben látszik az is, ahogy elkezdte ellenőrizni a WordPress weboldal tábláit is, amit én már kinyomtam, nem vártam meg...
Ezután lépjünk vissza az előző terminálra, ahol a hibaüzenetet kaptuk. Itt négy opció közül választhatunk:
- abort: félbeszakítja az egész frissítési folyamatot.
- retry: újrapróbálja a műveletet (itt bekéri ilyenkor többek között az adatbázis hozzéférési adatokat is.)
- retry (skip questions): újrapróbálja a műveletet, de itt nem kérdez, hanem a meglévő konfigurációval próbál továbblépni
- ignore: kihagyja a Roundcube beállítását, és továbbmegy enélkül. Ilyenkor lesz egy működésképtelen Roundcube rendszerünk, amit nem tudott frissíteni. Ilyenkor a kézi helyreállítása bonyolultabb.
Tehát ezek alapján az első és az utolsó opció kizárva, válasszuk a harmadik opciót: "retry (skip questions)"
Ezután újrakezdi a műveletet az elejétől, tehát visszakapjuk az első Roundcube konfigurációs kérdést, (Perform upgrade on database for roundcube with dbconfig-common?) Erre ismét nyomjunk Igent, ekkor már sikeresen továbblép.
Nálam mindkét opcióval működött, tehát bármelyikkel folytathatjuk, de azért kényelmesebb a kérdések kihagyásával továbblépni.
Majd a következő panelen a konfiguráció frissítésről kérdez:
┌─────────────────────────────────────────────────────┤ roundcube-core konfigurálása ├─────────────────────────────────────────────────────┐ │ config.inc.php: A new version (/etc/roundcube/config.inc.php.ucftmp) of configuration file /etc/roundcube/config.inc.php is available, │ │ but the version installed currently has been locally modified. │ │ │ │ What do you want to do about modified configuration file config.inc.php? │ │ │ │ install the package maintainer's version │ │ keep the local version currently installed │ │ show the differences between the versions │ │ show a side-by-side difference between the versions │ │ start a new shell to examine the situation │ │ │ │ │ │ <Ok> │ │ │ └──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
Itt írja, hogy a config.inc.php konfigurációs fájlban változás történt, és hogy lecseréljük-e.
Itt ha belenézünk a változásokba, akkor két dolog változik érdemben, a többi változás pedig csak a kommentezett sorok között van:
Kikerül az alapértelmezett kiszolgáló helyéről a "localhost", és lejjebb pedig az smtp felhasználót automatán a Roundcube felhasználóval fogja helyettesíteni.
Itt én azt javaslom, hogy tartsuk meg a régi beállítást. Ugyanis, ha kiszedjük az alapértelmezett "localhost" kiszolgálót, akkor a Roundcube beléptető ablakán megjelenik mégegy mező a felhasználó és a jelszó alatt, a kiszolgáló. Ez kényelmetlenné teheti a belépést, és felesleges, mivel amúgy is a localhost-on használjuk a levelezőt, hacsak nem multiszerver konfigurációnk van, ahol másik szerveren van a levelezés. Tehát én itt megtartom a régi beállítást.
Konfiguráció ütközés: MariaDB
Ebben a lépésben a MariaDB adatbázis kiszolgáló konfigurációja ütközik az újabb verzió beállításaival:
(ezen a képen még láthatjuk a fentebb említett hibákat is)
Configuration file '/etc/mysql/mariadb.conf.d/50-server.cnf'
==> Modified (by you or by a script) since installation.
==> A csomag terjesztője frissített.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
Az alapművelet a jelenlegi változatod megtartása.
*** 50-server.cnf (Y/I/N/O/D/Z) [alapművelet=N:nem] ?
Itt is nézzünk bele a változásokba (D):
--- /etc/mysql/mariadb.conf.d/50-server.cnf 2019-08-27 11:56:20.001107072 +0200 +++ /etc/mysql/mariadb.conf.d/50-server.cnf.dpkg-new 2021-05-17 04:55:52.000000000 +0200 @@ -2,8 +2,7 @@ # These groups are read by MariaDB server. # Use it for options that only the server (but not clients) should see # -# See the examples of server my.cnf files in /usr/share/mysql/ -# +# See the examples of server my.cnf files in /usr/share/mysql # this is read by the standalone daemon and embedded servers [server] @@ -14,33 +13,30 @@ # # * Basic Settings # -user = mysql -pid-file = /var/run/mysqld/mysqld.pid -socket = /var/run/mysqld/mysqld.sock -port = 3306 -basedir = /usr -datadir = /var/lib/mysql -tmpdir = /tmp -lc-messages-dir = /usr/share/mysql -skip-external-locking +user = mysql +pid-file = /run/mysqld/mysqld.pid +socket = /run/mysqld/mysqld.sock +#port = 3306 +basedir = /usr +datadir = /var/lib/mysql +tmpdir = /tmp +lc-messages-dir = /usr/share/mysql +#skip-external-locking # Instead of skip-networking the default is now to listen only on # localhost which is more compatible and is not less secure. -#bind-address = 127.0.0.1 - -sql-mode="NO_ENGINE_SUBSTITUTION" - +bind-address = 127.0.0.1 #
Ha jól megnézzük a változásokat, akkor egy kivétellel itt csak formai változások vannak, tehát máshogyan vannak tabulálva a mezők oszlopa, valamint néhány kommentezett sort cserél ki. Az egy kivétel pedig hogy törölni szeretné az alábbi sorunkat:
sql-mode="NO_ENGINE_SUBSTITUTION"
Ezt a beállítást pedig itt raktuk bele (kicsit görgessünk lejjebb a linkelt oldalon), tehát ennek benne is kell maradnia. A "NO_ENGINE_SUBSTITUTION" beállításnak a szerepéről pedig a Debian 10 újdonságai cikkemben írtam korábban.
Ennek megfelelően lépjünk vissza a menübe (q), majd válasszuk a saját beállítások megtartását (N).
Konfiguráció ütközés: Pure FTPd
A PureFTP FTP kiszolgáló itt került fel erre a szerverre. Ebben a lépésben nálam a PureFTPd beállításai akadnak a frissebb változat beállításaival:
Configuration file '/etc/pure-ftpd/db/mysql.conf'
==> Modified (by you or by a script) since installation.
==> A csomag terjesztője frissített.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
Az alapművelet a jelenlegi változatod megtartása.
*** mysql.conf (Y/I/N/O/D/Z) [alapművelet=N:nem] ?
Nézzük meg az eltéréseket (D):
--- /etc/pure-ftpd/db/mysql.conf 2021-10-26 14:41:42.754154734 +0200 +++ /etc/pure-ftpd/db/mysql.conf.dpkg-new 2019-01-28 19:56:17.000000000 +0100 @@ -1,3 +1,4 @@ + ############################################## # # # Sample Pure-FTPd Mysql configuration file. # @@ -8,7 +9,7 @@ # Optional : MySQL server name or IP. Don't define this for unix sockets. -MYSQLServer 127.0.0.1 +# MYSQLServer 127.0.0.1 # Optional : MySQL port. Don't define this if a local unix socket is used. @@ -18,30 +19,29 @@ # Optional : define the location of mysql.sock if the server runs on this host. -# MYSQLSocket /var/run/mysqld/mysqld.sock +MYSQLSocket /var/run/mysqld/mysqld.sock # Mandatory : user to bind the server as. -MYSQLUser ispconfig +MYSQLUser root # Mandatory : user password. You must have a password. -MYSQLPassword 64af134388cf5f40ed6be32608b36915 +MYSQLPassword rootpw # Mandatory : database to open. -MYSQLDatabase dbispconfig +MYSQLDatabase pureftpd # Mandatory : how passwords are stored -# Valid values are : "cleartext", "crypt", "md5" and "password"
Itt egyből látszik, hogy a szerver telepítésekor az ISPConfig vette kezelésbe a PureFTP rendszert, ezért vannak benne a beállításai. Itt tehát meg kell tartanunk a régi beállításainkat, különben nem fogjuk tudni kezelni az FTP felhasználókat az ISPConfig felületén keresztül.
Lépjünk vissza (q), majd válasszuk a régi beállítások megtartását (N).
Konfiguráció ütközés: BIND DNS szerver
A BIND DNS szerver itt került telepítésre. Itt most ez ütközik az újabb verzió konfigurációjával:
Configuration file '/etc/bind/named.conf.options'
==> File on system created by you or by a script.
==> File also in package provided by package maintainer.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
Az alapművelet a jelenlegi változatod megtartása.
*** named.conf.options (Y/I/N/O/D/Z) [alapművelet=N:nem] ?
Nézzünk bele a változásokba (D):
--- /etc/bind/named.conf.options 2021-10-26 14:41:42.746153959 +0200
+++ /etc/bind/named.conf.options.dpkg-new 2021-10-25 13:42:31.000000000 +0200
@@ -5,9 +5,9 @@
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113
- // If your ISP provided one or more IP addresses for stable
- // nameservers, you probably want to use them as forwarders.
- // Uncomment the following block, and insert the addresses replacing
+ // If your ISP provided one or more IP addresses for stable
+ // nameservers, you probably want to use them as forwarders.
+ // Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
// forwarders {
@@ -18,13 +18,7 @@
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//========================================================================
- dnssec-enable yes;
- dnssec-validation yes;
+ dnssec-validation auto;
- version "unknown";
-
- allow-transfer {none;};
-
- auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};
Ezeket is az ISPConfig állította be, amit most vissza szeretne állítani alapra. Nálam ezen a Debian 10-es szerveren is ugyanezekkel a beállításokkal működnek a DNS zónák, tehát hagyjuk meg a régi beállításainkat, amennyiben ugyanezek vannak nálunk is. Vissza (q), majd N.
Ezután teker még egy kicsit, beállítgat ezt-azt, végül visszakapjuk a prompt-unkat ahol lekérdezve a hibakódot, 0-át kapunk, azaz sikeres művelet:
És még egy levelet is kaptunk. :)
Ezzel tehát készen is volna a disztribúció és a főverzió frissítés is.
Szerver újraindítása
Ha idáig megvagyunk mindennel, indítsuk újra a szervert, hogy betöltődhessen a legújabb kernel:
reboot
Még ne menjünk messzire, mert a következő oldalon átnézzük a teljes, immáron a Debian 10 (Buster) rendszerünket, és ellenőrzünk rajta mindent, valamint még a csomagtárunkban is végzünk még egy nagytakarítást.
- Hogyan frissítsük otthoni gépünket Debian 8 (Jessie) rendszerről Debian 9 (Stretch)-re
- Hogyan frissítsük Debian 10 (Buster) alapú tökéletes szerverünket Debian 11 (Bullseye) rendszerre
- A Debian 10 (Buster) operációs rendszer újdonságai, változásai
- Tökéletes szerver: Debian 9 (stretch) V1.0
- Tökéletes szerver: Debian 10 (Buster) V1.0
- Enciklopédia - APT (Advanced Packaging Tool)
Lapozó
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
- 125 megtekintés