Content
- page: Things to do before upgrading - Preparing for the upgrade
- page: Complete upgrade of Debian 9 (Stretch) to Debian 10 (Buster)
- page: What to do after upgrades - System check
2. page content
Continuation
Az previous page we have reviewed the steps required before upgrading to prepare your system for the new major version, and on this page we will continue to upgrade your distribution to Debian 10 (Buster).
A new version of the description has been prepared:
Updating the Debian distribution
If all is well around our packages, we can start upgrading to the main version.
Complete update of current distribution
First, run the normal apt-get update command followed by the full distribution update:
apt-get upgrade
apt-get dist-upgradeAz apt-get dist-upgrade command is equivalent to apt full-upgrade command, so you can use any of them here to run the full update.
I didn't have anything to update here now:
But in other cases, there were already examples of him updating for a long time at this time.
Recheck packages
If the previous full update involved many package updates, we will double-check our packages as described above:
- Search for withheld packages
- Search for broken packages
- Remove packages that have become redundant
We are only checking these here now.
If you have updated nothing or only a few packages like here, you can skip this check step because no significant changes have been made to the package database.
Modifying APT source list files for Debian 10
Open the sources.list file:
nano /etc/apt/sources.listWhat I have on this Debian 9 server looks like this:
# # 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
Make a backup copy of the file:
cp /etc/apt/sources.list /etc/apt/sources.list.bakThen rewrite every word in the file, or the part that starts with it, to "buster." You can do this manually in the editor, or even a simple one thirstwith the command:
sed -i 's/stretch/buster/g' /etc/apt/sources.listThe point is that eventually every word “stretch” is rewritten to “buster”. So for me, after the modification, it looks like this:
# # 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
Also, don’t forget about the list file directory, where there may be more luggage racks list files containing: a /etc/apt/sources.list.d/ in the library. There are third-party programs that prefer to place their own list files here when they are installed, so their packages are updated accordingly. So run the replace command on these as well, so if there are files here, the command will overwrite them as well:
sed -i 's/stretch/buster/g' /etc/apt/sources.list.d/*.listOf course, let's review each file to make sure everything is modified correctly.
If you are done with the change, run it JUST updating the package database, updating the package NOT YET let's run!
apt-get update
He ran here without error. If there is an error somewhere, a third-party package that does not contain Debian 10 packages may not have been removed. In this case, it is a good idea to check the software's website to see if you can find a different url for Debian 10, etc.
Simulation of libraries upgrade
Here we still run a simulation and see which packages can be upgraded and which cannot. To do this, run the following command:
apt list --upgradableFor me, the output is:
Here we can even query the error code of the command output, so we can be sure of the success of the package update if we get a value of 0. Furthermore, it is interesting to run again and count the number of lines written in a pipeline. This will show you how many packages will be updated in the next section.
Basic update
After the simulation, we first perform a basic update that updates only those packages that do not require the installation or removal of other packages. To do this, issue the standard command:
apt-get upgrade
As shown here, this example will update 467 packages and will not install new ones or delete existing ones. Then continue with the Yes option.
The package manager works for a while and then stops in some cases while we wait for our intervention.
However, if you upgrade on exactly the same server as I mentioned at the beginning of this description, chances are you'll get the same issues.
Here are some of the following:
- Scrollable sections that display text that you can exit with the "q" key - continuing the upgrade process.
- Text mode color dialog windows, where you are asked questions about the update, which you can answer by choosing from several options.
- Show configuration conflicts where we compare previously modified configurations to the default settings of newer versions of packages, where we need to decide which version to use
In the following, we can expect such things, which will be those that appear everywhere, and those that will only occur in a particular configuration where that particular program or service is installed. Now let's look specifically at my example:
APT list changes
The first is APT package manager changes, it will be visible to everyone:
Displays the apt package manager version log. In this interface, you can use the mouse scroll wheel and the up and down keys to scroll through the text, and you can exit the update process by pressing the "q" key.
libc6 configuration
Then the libc6 configuration is coming, it will be visible to everyone:
┌────────────────────────────────────────────────────────┤ 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> │ │ │ └───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
Select "Yes" here and move on.
Configuration conflict: limits.conf
The following question already asks about a custom setting, /etc/security/limits.conf about file:
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] ?
If you have the same server installed, so Debian 9 is the perfect server at the time of installation we have modified this file in this section. After clicking the link, scroll down a bit to find the modification to the limit.conf file, so if this configuration conflict appears, we've probably set up this file, which is why it's different from the one in the updated package.
For this type of question (and others like this), we have the following options:
- Y vagy I: installs the maintainer version of the package, ie overwrites our settings with the default settings for the new version of the package.
- N vagy O: keeps our current settings, so it ignores the configuration file packaged for the new version.
- D: Displays the differences between the two configuration versions
- Z: launches a shell shell to examine itself from the command line in this situation
For these types of questions, always look at the differences first so we can make the right decision. Accordingly, select option D first:
--- /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
In the section shown here, the header has changed, two lines of comments, and below are our settings for what you want to "remove" according to the new configuration.
So there is a difference here only because of our own changes, so let’s keep them, we haven’t included any novelties that would require us to replace them. From this comparison section, press "q" to return to the previous menu, then select N option, ie keep our old settings.
Configuration conflict: jk_init.ini (Jailkit)
After a little configuration, the following host is asking for another configuration conflict, namely changing the Jailkit settings:
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] ?
Jailkit is a collection of utilities that restrict user accounts from accessing specific files and using commands. The program was installed during the construction of the Debian 9 server, which is managed by ISPConfig. Although the software is regular .deb not from the Debian 9 repositories, as the jailkit package was not available, but from the we had to generate the binary package from the source, which can then be installed as a normal package in dpkg with the command.
Since Debian 10 (Buster) Backports repository - which is installed on this server - already includes the jailkit package, so this package will also receive official updates from now on. This is why this configuration conflict has occurred, which we now need to resolve.
Here, too, let's look at the changes first, so choose D option. The list of changes is pretty long here, so I haven’t copied it here right now, but if we look at it, a lot of things are set differently here. And since we didn't set this up, we'll accept the settings in the latest version here, so choose Y option.
Configuration collision: Spamassassin
Spamassassin is a spam filtering program that is also a when you installed the server. Now because of this changed configuration, ask us:
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] ?
Let's look at the changes first: D key.
--- /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.
Here you want to remove the "ENABLED = 1" switch, as this will not be supported in future versions. So here too, we accept the changes in the latest version. First, go back to q and select Y option.
Then we set up a few more packages and we get the prompt back.
Full distribution update
Once the existing packages have been upgraded with the basic upgrade, you will still need to perform a full upgrade to complete the upgrade to Debian 10. This section installs the latest available version of all packages and all their possible dependencies.
To do this, run the full upgrade command you used before - here using the Debian 10 repositories:
apt-get dist-upgradeFor me, the output is:
In this step, you upgrade 302 packages here, install 159 pieces, and delete 16. You will need 551 Mb of disk space for all this. So here, too, the package manager will have a lot to do, where we’ll also go through the parts that require user intervention, which will be similar in type to the ones we’ve come across during the basic upgrade. Select Yes to continue.
APT list changes
A change log also appears at this stage of the upgrade process, but here is a list of the major programs that will now undergo important updates:
You can review this in the same way if you want, then q to return to the update.
Here are a few minutes of installation and configuration, and then the next dialog will appear.
Configuration collision: Dovecot
Dovecot is an open source and free POP3 /IMAP mail server for Unix-like operating systems. This mail server is still available at when creating a server has been installed, so this issue now arises where the current configuration of Dovecot conflicts with the settings in the new version:
┌─────────────────────────────────────────────────────┤ 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> │ │ │ └──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
Here, the system asks us essentially the same configuration conflict, only here we can choose from a light striped menu.
Since we installed the program at the time, but we didn't have much to do with its settings, we accept the settings for the latest version: "install the package maintainer's version". Of course, we can still see the changes beforehand if we are curious about it.
Configure GRUB
The next part that requires interaction - at least for me - is configuring GRUB. This part doesn't normally appear in anyone else, so I didn't want to put it in at the beginning, but I thought if it would appear in someone else, I wouldn't be afraid of it.
The point here is that I cloned the original my virtual server, and I am performing this update on the copy, so the unique ID of the virtual machine's hard disk has changed (UUID-je). The configuration program noticed this, so it thinks that the GRUB boot loader is not installed on your hard disk and now asks you to specify the installation location:
┌────────────────────────────────────────────────────────┤ 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> │ │ │ └──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
Here, select the main unit, ie the hard disk itself, which is on top, so do not install it on the partition. Then press OK.
Configure roundcube core
A Roundcube webmail client as well previously installed on the serverwhen he asked almost the same question:
┌──────────────────────────────────────────────────────┤ 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> │ │ │ └────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
The key is to automatically configure the database required for RoundCube to work dbconfig-common using. Once during the installation, we set it to handle it automatically, so we created our own database and the corresponding control user. Now it asks if you want dbconfig-common to automatically update the database structure. So now select Yes.
You would try to log in in the next step, but you have issued an error window:
┌──────────────────────────────────────────────────────┤ 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> │ │ │ └────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
You cannot connect to the database server. This does not always happen, but it will most likely cause an error here because you have not yet configured all the programs and started the services, including the database server.
So if we stumble upon such an error, we can fix it by opening another terminal window and logging in there as root. Then let's take a look at mysqld:
systemctl status mysqld.serviceThen you can see that the little dot is gray and it also says "Stopped" in the log. So it was stopped and started several times during the upgrade process. It hasn't been restarted right now, so we got the error. Let's restart it manually and look at it again:
systemctl restart mysqld.service
systemctl status mysqld.service
In the meantime, you can see how he started checking the tables on the WordPress website, which I already printed out, I didn't expect ...
Then go back to the previous terminal where you received the error message. Here you can choose from four options:
- abortion: interrupts the entire update process.
- retry: retry the operation (here it will ask for, among other things, database access data.)
- retry (skip questions): retries the operation, but does not ask here, but tries to continue with the existing configuration
- ignore: skips the Roundcube setting and continues without it. In this case, we will have a malfunctioning Roundcube system that we could not upgrade. In this case, manual recovery is more complicated.
So based on these, the first and last options are excluded, choose the third option: "retry (skip questions)"
It will then restart the operation from the beginning, so we will get back to the first Roundcube configuration question, (Perform upgrade on database for roundcube with dbconfig-common?) Press Yes again, then it will proceed successfully.
For me, it worked with both options, so we can continue with either, but it’s more convenient to move on by skipping the questions.
You will then be prompted for a configuration update in the following panel:
┌─────────────────────────────────────────────────────┤ 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> │ │ │ └──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
Write here whether a change has been made to the config.inc.php configuration file and whether to replace it.
Here, if we look at the changes, two things change substantially, and the other changes are only between the lines commented on:
The "localhost" will be removed from the default server location, and the smtp user below will be automatically replaced by the Roundcube user.
Here I suggest we keep the old setting. This is because if we take out the default "localhost" server, another field will appear in the Roundcube login window under the user and password, the server. This can make logging inconvenient and unnecessary, as we use mail on localhost anyway, unless we have a multiserver configuration where mail is on another server. So I keep the old setting here.
Configuration conflict: MariaDB
In this step, the configuration of the MariaDB database server conflicts with the settings of the newer version:
(we can still see the above mentioned errors in this picture)
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] ?
Let’s look at the changes here too (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 #
If we look closely at the changes, with one exception, there are only formal changes here, so the columns of the fields are tabulated differently and some of the commented rows are replaced. The one exception is that you want to delete the following line:
sql-mode="NO_ENGINE_SUBSTITUTION"
And this setting we put it in here (scroll down a bit on the linked page), so that should stay in it. About the role of "NO_ENGINE_SUBSTITUTION" in What's New in Debian 10 I wrote earlier in my article.
Return to the menu accordingly (q) and select to keep my settings (N).
Configuration conflict: Pure FTPd
A A PureFTP FTP server has been uploaded to this server. In this step, I have the settings for PureFTPd with the settings for the newer version:
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] ?
Let’s look at the differences (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"
It is immediately apparent here that the PureFTP system was managed by ISPConfig when the server was installed, which is why its settings are included. So here we have to keep our old settings, otherwise we won't be able to handle it FTP users via the ISPConfig interface.
Go back (q) and select to keep the old settings (N).
Configuration conflict: BIND DNS server
A BIND DNS server installed here. Here is what conflicts with the newer version configuration:
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] ?
Let’s look at the changes (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; };
};
These have also been set up by ISPConfig, which you now want to reset. On this Debian 10 server, the DNS zones work with the same settings, so let's keep our old settings if we have the same ones. Back (q) and then N.
Then it rolls a little more, sets this and that, and finally we get back our prompt where we get the error code, we get 0, which is a successful operation:
And we even got a letter. :)
So the distribution and upgrade to the main version would be ready.
Restart server
If you're done with this, restart the server to load the latest kernel:
reboot
Let's not go far yet, because the next page let's take a look at our entire system, now Debian 10 (Buster), and check everything on it, and even do a big cleanup in our boot.
- How to upgrade your home computer from Debian 8 (Jessie) to Debian 9 (Stretch)
- How to upgrade our perfect server based on Debian 10 (Buster) to Debian 11 (Bullseye)
- New features and changes to the Debian 10 (Buster) operating system
- Perfect server: Debian 9 (stretch) V1.0
- Perfect server: Debian 10 (Buster) V1.0
- Encyclopedia - APT (Advanced Packaging Tool)
Navigation
- To post registration and login required
- 127 views