Facebook
Twitter
Hi,
We have a recurring problem within Plesk 8.6 (Centos) whereby IPs that we remove from the Plesk control panel (as sites with dedicated IPs are migrated to other platforms) reappear at a later date on the servers interface.
Usually this is triggered when we remove another IP. For example last night we removed an IP after migrating a customer, and 9 IPs that had been previously removed were all readded to the interface (so navigating to them brought up the Apache test page for that server). They don't show up in Plesk until we do a "Reread IP" but then they are added to Plesk.
Should we be expecting Plesk to remove these IPs entirely from the server, or should we be doing it manually? I can't help but notice that the IPs do leave when we initially remove them from Plesk, whilst there are remnants of config files within Centos /etc/syconfig/networking/ .
I am wary of adding a script to remove these config files when it could conflict with something in the background that Plesk is doing (wrong probably).
Paul.
We have a recurring problem within Plesk 8.6 (Centos) whereby IPs that we remove from the Plesk control panel (as sites with dedicated IPs are migrated to other platforms) reappear at a later date on the servers interface.
Usually this is triggered when we remove another IP. For example last night we removed an IP after migrating a customer, and 9 IPs that had been previously removed were all readded to the interface (so navigating to them brought up the Apache test page for that server). They don't show up in Plesk until we do a "Reread IP" but then they are added to Plesk.
Should we be expecting Plesk to remove these IPs entirely from the server, or should we be doing it manually? I can't help but notice that the IPs do leave when we initially remove them from Plesk, whilst there are remnants of config files within Centos /etc/syconfig/networking/ .
I am wary of adding a script to remove these config files when it could conflict with something in the background that Plesk is doing (wrong probably).
Paul.