Hi @ all friends of Plesk,
Hi
@learning_curve, to the Plesk support team I reported (and discussed) the problem
"Adding multiple IP configurations (IPv4 + IPv6) in /etc/network/interfaces by Plesk system on Ubuntu 20.04 server when you click on
Repair IP in Plesk IP settings
".
One day I experienced having the same configuration for several IPs multiple times (one IP had 4 times the same configuration, better to describe as cloned configurations).
For this issue I made a support ticket, gave access to my server, and it was confirmed as bug
PPPM-12941 by Plesk support on 22th of April in 2021.
It has to do with the IP repairing system. But they also discovered that there is another problem with misconfiguration in etc/network/interfaces for which Ionos is responsible. Two bugs brought my server offline every 6 to 12 hours.
As for changing the network configuration so only one of either Netplan or ifupdown is used - the tool for managing the network is chosen on the system level, and it is done on all Linux servers, regardless of whether Plesk is installed. When Plesk is installed on a server, for adding or deleting IP addresses to the network interfaces, it just uses the tool that is already used in the system, it does not manage the lower-level configuration of which tool is used for managing the network in the system. In the moment both are active/running: Netplan "and" ifupdown, this seems to be the big problem.
THE PLESK-IONOS-UBUNTU-SOLUTION:
I was able to solve all problems together by only returning to the default network/interfaces configuration with the main IPv4 from provider Ionos. Removing all additional IPs (two IPv4 and three IPv6), only the main server IPv4 existing. Much work to edit all subscriptions and DNS (I use the additional IPs for own domain nameservers).
In former times it was absolutely necessary to edit network/interfaces for using additional IPs, but not in present times. Today
you only have to add the IPs over Plesk interface,
NO editing network/interfaces. Then re-do all the changes in subscriptions and the IPs with their corresponding nameservers. So, in the end, server is running fine and smooth again with no need to repair IPs.
Greets