Content

3. page content

Continuation

Az previous page we have updated the distribution to the Debian 11 (Bullseye) system, and on this page we review the basic system as well as our higher-level server services and make the necessary subsequent settings.

Basic system check

After restarting the server, we first check the base system to see if everything is fine.

Query version and release information

The version and release information can be queried with the following commands in the same way as before the update:

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

Here, Debian 11 is now visible everywhere, so everything is fine. The only thing left is the hostname (in this example) "debian10", but this is a custom setting, which is exactly the same as the previous Debian main version, so it has no significance. In a live environment, you do not set the version of your operating system, I only use such machine names here for the tutorials, so that I can better distinguish them from each other.

The 11 LTS kernel works in the Debian 5.10 (Bullseye) version, which - as of the release of the 5.10 kernel on December 2020, 13 - in total You will receive support for 5 years. More details on the Debian 11 release:

• What's new and changes in the Debian 11 (Bullseye) operating system

Checking packages

Here now - a old distribution updated contrary to the description - we will continue with this part, so we will first review the basic system and then move on to higher level server services.

In this section, we'll revisit the Debian packages and make the necessary modifications to get our base system in perfect shape.

Remove packages that have become redundant

Let's remove our unnecessary packages again below apt command:

apt --purge autoremove

As you can see here, I have 62 packages to remove, after which 527 MB of storage space is freed up.
Let's keep it going I option.

Find and remove obsolete packages

Deprecated packages are "created" when we upgrade the entire Debian system, and these packages are no longer available in the newly configured repositories, but for example a newer major version of the software has been released, so this is the only way to get an update. In this case, it is a good idea to remove these packages. First, just look for these packages to see which packages have been marked as obsolete after the upgrade. You can use any of the following commands to do this:

aptitude search '~o'
aptitude search ?obsolete

It didn't fit through a window, but still apt-show-versions we can also query these with the command:

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

There is a good chance that everyone will have such packages here. The collection and deletion of these in the list can be done succinctly in the following way:

First, let's collect only the names of these packages and make a text file out of them that contains this list:

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

Then let's go through this list and select the ones we know we still need, e.g. we installed it from source a long time ago and still use it for something, etc. To do this, open the file containing the list and modify:

nano ./elavult_csomagok.txt

After we have removed from the list the packages that we definitely still need, save them and delete the packages remaining in the list with the following command:

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

I already wrote about this process in a little more detail in the previous distribution update tutorials, you can see the relevant parts below:

• How to upgrade our home machine from Debian 8 (Jessie) to Debian 9 (Stretch) - Handling outdated packages
• How to upgrade our perfect Debian9 (Stretch) server to Debian 10 (Buster) (page 3) - Find and remove outdated packages

Repeated removal of redundant packages

Let's run this again, in this case there are even more unnecessary packages here:

apt --purge autoremove

Empty the package cache

Finally, empty the package cache that many packages have already accessed during the upgrade:

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

Here, too, he deleted nearly half a GB of stuff from the cache.

Finally, let's look at an upgrade:

apt-get upgrade

Our packages are completely fine here, our basic system is up to date.

Checking and setting higher level server services

In this section, we review the higher-level components and services of the perfect server and, if necessary, configure them.

ISPConfig

To be properly configured for Debian 11, the ISPConfig services managed by , we need to run the ISPConfig update script to reconfigure the services. The update must be done in "force" mode to make sure it runs. We did one recently earlier. Run the following command:

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]

There will be two more questions, let's hit enter on them as well:

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]

And here comes the point:

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

Here it asks if we want to reconfigure the services. This is essentially why we ran this whole thing, so let's press enter here as well, since yes is the default answer.

Then the update script will do its job...

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

Then there are three more questions, the first two of which are ISPConfig SSL certificate, and the last one for crontab:

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

Here, if you don't want to change the current SSL setting, press enter on the first two, then press enter at the end to reconfigure the crontab.

With this, ISPConfig made the appropriate changes where necessary.

PHP

In this section a PHP configuration, which I have divided into several subsections for better clarity and manageability.

Install PHP 7.4 (optional)

In Debian 10, the default PHP version was still 7.3, but in Debian 11 (Bullseye) it is already PHP 7.4. Since we have now upgraded to a major Debian version, we do not have this version by default, unless it was previously installed as an optional PHP version. If we did not do this at the time, we can replace it now if we want to use it.

Of course, today it is more practical to simply skip the PHP 7.x branch and use the 8.x branch, but if we still need the PHP 11 version - which is available by default in Debian 7.4 anyway - or we simply want the 7 We also have the latest version from the .x branch - because we still have websites that require the 7.x branch - then you can find information about the installation process and their settings in our ISPConfig control panels on the links below:

• How to install newer PHP versions on our Debian 9 (Stretch) LAMP server in PHP-FPM mode - PHP 7.4
• How to set up individual PHP versions on our ISPConfig system server - PHP 7.4

Of course, we can install any PHP version from these pages if we need them and have not used them before.

Make PHP 7.4 the default (optional)

In the Debian 11 (Bullseye) system, PHP 7.4 is available in the official package repository, accordingly - in the case of recent installations - this is also set as the default. However, since we have now upgraded from a Debian 10 (Buster) system, this default in this case remains PHP 7.3 as a legacy of our previous system.

Whether you just installed PHP 7.4 or earlier, it is advisable to set the default (of course, if you have not installed it at all, then skip this part). Of course, this part is not mandatory, there will be no problem if we do not change it, but if we want to be completely precise, we will fix this as well.

If we want to make this setting, then do the following

Default setting in the ISPConfig control panel

The ISPConfig control panel also manages the default PHP version separately from the additional installed versions. Consequently, this setting must also be made in the control panel.

Enter our ISPConfig panel as an admin, then navigate to the following menu:

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

And scrolling down here is the PHP Settings drop-down panel:

Here, rewrite all "7.3" references to "7.4" so that it looks like this:

Then save the form.

Set as default for the rest of the system

PHP is not only managed by ISPConfig, but also used by other parts of the system. For example, if we run a PHP script in the command line (CLI), the default PHP will still run, or if we run some web interface in a non-preset PHP-FPM configuration, for example when mod_php is not available (for example, HTTP / 2 setting), then Apache will "redirect" all PHP requests to the default "www" pool of the default PHP-FPM version. Therefore, we need to set defaults for the rest of the system as well.

To set them, run the following update-alternatives commands:

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

In each case, select PHP 7.4 here:

In the case of FPM, there is a problem here, because PHP 7.4 is not listed, even though it is installed on this server. So now let's choose 7.3 and we'll fix it right away. If this happens to someone else - which is quite rare, but it does happen - then install the php7.4-fpm package again, this will solve the problem:

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

Then repeat the setting:

update-alternatives --config php-fpm.sock

Then replace the default PHP-FPM handler, and finally restart Apache:

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

phpMyAdmin

A phpMyAdmin we still have to deal with a web database management interface. Let's take a look at your home page first, then continue working.

Here we have to deal with two things:

• PHP version: 7.3.33 (right middle panel: this didn't switch to 7.4 even after setting defaults)
• phpMyAdmin version: 5.1.0 (on the right in the lower panel: there is also a more recent official phpMyAdmin version: 5.2.0)

We will solve these in the remaining part.

Setting PHP-FPM version (optional)

If at that time PHP-FPM was configured during the installation of phpMyAdmin when creating the Debian 10 LAMP server, then we can see this version 7.3.x, since a PHP-FPM 7.3 was then set in a separate pool, so it is not affected by setting the defaults above.

If, on the other hand, we did not set this, then we will most likely see version 7.4 here, which is due to the PHP default set above.
In this case, phpMyAdmin can run in two ways: either as an Apache module (with mod_php version 7.4), or if mod_php is disabled, then in the default PHP-FPM pool (in this case also in the default version 7.4).

No matter which situation exists on our server, phpMyAdmin works well with all of them. However, if you want the PHP environment running phpMyAdmin to be more fine-tuned, run it in a separate PHP-FPM pool. If you haven't done this before, you can find out about the advantages of this as well as the setup process at the link above. Of course, if you follow the previous description, we no longer use version 7.3, but the latest one available on our server.

And if we have already made this setting on our server, then you only need to change these settings; for this, follow the sections below. The latest installed and configured PHP on this server is 8.0, so I will now switch the PHP-FPM environment running phpMyAdmin to it. (Here, everyone should proceed with their own, latest version of PHP.)

If we don't know how our phpMyAdmin web database management panel is configured, because we don't remember it, or because we "inherited" the server from someone else, or if we're just unsure about it, then run a PHP-FPM corresponding to the PHP version displayed on the phpMyAdmin home page status query. For example, in the case of my 7.3:

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.

If we see processes connected to the pool named "phpmyadmin" here (as in this example), then the setting was done earlier. If we only see the two processes of the basic "www" pool here (maybe our websites as well), but not phpmyadmin, then it is not set. Of course, it is important here to check the PHP version displayed on the home page of the database manager, because it can only occur in the FPM of that version, not in the other versions.

Based on these, we can choose from three options:

• If you find this part complicated and you don't want to touch it, feel free to skip it, our phpMyAdmin panel will work without it.
• If we do not see the "phpmyadmin" items in the output of the above status, then it is not set. If you want to set it up, go to the link above, or ide click to find the information needed to complete the setting.
• If we see lines with "phpmyadmin" in the output, it is already set and in this case you just need to change the settings. 

Here we continue with the third option, so we already have a PHP-FPM setting for our phpMyAdmin interface that we made earlier, and we will now change this to the newer PHP version.

FPM pool conversion

First, let's move the current pool to the 8.0 FPM. To do this, run the following command:

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

Next, edit this moved file:

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

File contents copied:

; 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

We will not deal with the PHP environment settings here, you can also read about them on the page linked above. Here, what we are dealing with is the line below, which is right at the beginning in line 9:

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

Let's change this to our new PHP version:

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

By the way, the name of the socket file doesn't matter, it just has to be the same everywhere. Also, if we consistently modify it in this case, we will know later which FPM belongs to which. If we have changed the name of the file (everyone to their latest PHP version), save it.

Then open the phpMyAdmin Apache configuration file:

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

Then, in accordance with the above, correct the previous socket file name in the following line:

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

Change this to the following:

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

Then restart the following services in order:

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

Finally, let's look back at the phpMyAdmin interface:

And here we can already see PHP version 8.0.27 - in my example.

Then we can also check the two PHP-FPM services:

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

We can also see here that the phpMyAdmin pool has been transferred to the supervision of the 8.0 FPM service. In 8.0, there is also a web1 pool in which the Drupal 9 website on the server runs. And www is the default pool for all FPM versions, in which something is run when mod_php is disabled, and therefore the default FPM configuration redirects the request to its www pool, if the given website or web application does not have its own set pool, unlike, for example, phpMyAdmin here. Of course, I only wrote all of these as points of interest, we have nothing special to do with them.

Update phpMyAdmin

A little reminiscing will be needed here too...

At that time the When installing a Debian 10 (Buster) LAMP server phpMyAdmin at the beginning it could only be installed manually from source, since the The Debian 10 stable package does not include the phpmyadmin package. However, over time, Debian 10 backports the phpmyadmin package was included in its storage, so from there it was possible to install the as usual.

Here in this section, we must proceed based on this:

• If we have already installed phpMyAdmin from the package from the Debian 10 backports repository, then there is nothing else to do here, because it has already been updated from the Debian 11 package repository after the distribution update. In this case, however, we check the version on the phpMyAdmin interface, if we haven't already done so.
• And if we installed phpMyAdmin manually from source in the previous period, or if we don't remember the origin of our phpMyAdmin instance, then we should prepare this short section so that our phpMyAdmin system is up-to-date.

To update phpMyAdmin it is ISPConfig developers created an automatic update script, which we will use here to update our phpMyAdmin copy. The script also checks the situations just mentioned, so if it was installed from a package, it doesn't do anything, it just says that our phpMyAdmin copy is up-to-date (of course, if we really updated it together with our other packages), and then exits. So we can run this script safely in any case. Furthermore, the script does not touch the Apache configuration either, so it does not affect the previously individually configured PHP-FPM parts either.

The script a curl command is also used (and we also run it with this), for this to work, install the curl package:

apt-get install curl

Then run the following command, which will automatically update our web database manager:

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/

Here at my place, he updated it from version 5.1.0 to 5.2.0.
Let's take a look "from the inside":

It has also been updated, but in the meantime we also got a new error message at the bottom:

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

With this error, it's already one we dealt with in a previous description, and we will make a permanent fix for it in another description. But until then, there is no problem with it, the panel can be used with this as well.

If we want to set this automatic update script in a cron task so that it can then run completely automatically in the background every day, issue the following commands:

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

The first command downloads the script again, but now it does not run it, but places it in a file a /etc/cron.daily/ directory and the second command makes it executable.

Control of web interfaces

Finally, let's run through our web applications and websites to see if everything is working properly (we've already seen phpMyAdmin, so we'll skip that here).

Website

Please reload our website. In this example, I also look at the status report of the Drupal page:

The database version change is also visible here: 10.3.36 -> 10.5.18. Everything is fine here (we are not dealing with Drupal warnings here).

ISPConfig

We've seen this since the update, but we can see it again:

Roundcube Webmail

A Roundcube also works flawlessly.

Munin

A Munin it's okay too.

Monit

A monit also works, and the services and resources it monitors are fine.

With this, we are ready with everything, the system is ready for use.

Conclusion

Our Debian 10 (Buster) system now supports Debian 11 (Bullseye), in which all packages and services have been updated. You can find many distribution update descriptions on the net, most of them solve it in a few lines, but I deliberately didn't want to be one of them, so I made a detailed description. Not to mention that this was not an upgrade of a simple desktop system, but of a web server with many features, configurations and unique solutions that had to be reviewed one by one. In this way, I hope I was able to provide a useful description for many.

Navigation