Facebook
Twitter-
We value your experience with Plesk during 2024
Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
Please take this short survey:
https://pt-research.typeform.com/to/AmZvSXkx -
The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
-
We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.
Plesk 12.5.30 MU#27
- Thread starter NatalyaF
- Start date
@Kingsley,
You stated
and note the following.
The issue with the letsencrypt extension is a separate issue, that you should be taken care of separately.
In general, any installation issue should not be resolved by adding lines to the /etc/hosts file, I will (briefly) explain later.
In fact, the tcp_window_scaling settings are often the root cause of the problem: just use the command echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
If and only if that does not work (read: not even after a reboot, a reboot is recommended), you can try to use other work-arounds.
Why should you prefer to not change the /etc/hosts file?
Well, changing the /etc/hosts file implies that you, even before DNS can be referenced, assign hostnames to IPs.
For instance, adding "68.232.34.73 autoinstall.plesk.com" to /etc/hosts implies that you assign the hostname autoinstall.plesk.com to IP 68.232.34.73, before DNS can be referenced.
The problem in this is really that you assign static values (IPs and hostnames), while they can change in real life (for instance, DNS changes, IP changes, hostname changes etc.)
So, if the IP address of hostname autoinstall.plesk.com changes to 93.184.221.133, a line "68.232.34.73 autoinstall.plesk.com" in /etc/hosts will NOT help and issues reoccur.
Now, have a look at the KB article cited by @UFHH01 and you can see that at least three IPs and 4 hostnames are used.
In short, using a work-around involving /etc/hosts is not good, since it really will sooner or later result in the problems reoccurring.
Moreover, the analysis of the root cause of the problem has been done by me and I have suggested the tcp_window_scaling solution: you can really take from me that the other solutions from the KB article are not working, if the tcp_window_scaling settings are improper.
Hope the above helps.
Regards..........
You stated
and note the following.
The issue with the letsencrypt extension is a separate issue, that you should be taken care of separately.
In general, any installation issue should not be resolved by adding lines to the /etc/hosts file, I will (briefly) explain later.
In fact, the tcp_window_scaling settings are often the root cause of the problem: just use the command echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
If and only if that does not work (read: not even after a reboot, a reboot is recommended), you can try to use other work-arounds.
Why should you prefer to not change the /etc/hosts file?
Well, changing the /etc/hosts file implies that you, even before DNS can be referenced, assign hostnames to IPs.
For instance, adding "68.232.34.73 autoinstall.plesk.com" to /etc/hosts implies that you assign the hostname autoinstall.plesk.com to IP 68.232.34.73, before DNS can be referenced.
The problem in this is really that you assign static values (IPs and hostnames), while they can change in real life (for instance, DNS changes, IP changes, hostname changes etc.)
So, if the IP address of hostname autoinstall.plesk.com changes to 93.184.221.133, a line "68.232.34.73 autoinstall.plesk.com" in /etc/hosts will NOT help and issues reoccur.
Now, have a look at the KB article cited by @UFHH01 and you can see that at least three IPs and 4 hostnames are used.
In short, using a work-around involving /etc/hosts is not good, since it really will sooner or later result in the problems reoccurring.
Moreover, the analysis of the root cause of the problem has been done by me and I have suggested the tcp_window_scaling solution: you can really take from me that the other solutions from the KB article are not working, if the tcp_window_scaling settings are improper.
Hope the above helps.
Regards..........
@Kingsley
you also stated
in response to @UFHH01´s suggestion for an alternative solution.
I will not say to ignore this suggestion (it really is not nice to say that other people´s posts should be ignored), since it actually is a good alternative solution if
- your hosting provider has a buggy set of nameservers and/or a troublesome network infrastucture, (or)
- your country is "blocked" to some degree (consider Turkey and/or China, I am not aware of such a block in your country), (or)
- your hosting provider is "blocked" to some degree (consider IP ranges of the hosting provider being blocked, for instance as a result of spamming activities),
- and so on.
However, putting the Google nameservers in /etc/resolv.conf does has the disadvantage that it does not resolve specific issues: some kinds of "blocks" and/or "problems at the side of the hosting provider" can still have a negative effect. To illustrate, consider the case of "troublesome network infrastructure": any request via the Google nameservers will proceed without any problem, but the response, for instance in the form of a file download, will still be "forwarded via DNS" to your machine and can get stuck in the troublesome network (timeouts etc.).
That is the easy way to explain it, reality is a little bit more complex.
I am pretty sure that using the Google nameservers will improve your internet connectivity to some considerable extent, so please try and test (!) that.
However, it still is imperative to remove the line "199.115.104.31 pleskwin.download.swsoft.com download1.parallels.com autoinstall.plesk.com origin.autoinstall.plesk.com" from /etc/hosts.
After all, the line in question "bypasses" (simply stated) DNS and any error in that line will result in issues. See also my earlier post.
Hope the above helps.
Regards.....
you also stated
in response to @UFHH01´s suggestion for an alternative solution.
I will not say to ignore this suggestion (it really is not nice to say that other people´s posts should be ignored), since it actually is a good alternative solution if
- your hosting provider has a buggy set of nameservers and/or a troublesome network infrastucture, (or)
- your country is "blocked" to some degree (consider Turkey and/or China, I am not aware of such a block in your country), (or)
- your hosting provider is "blocked" to some degree (consider IP ranges of the hosting provider being blocked, for instance as a result of spamming activities),
- and so on.
However, putting the Google nameservers in /etc/resolv.conf does has the disadvantage that it does not resolve specific issues: some kinds of "blocks" and/or "problems at the side of the hosting provider" can still have a negative effect. To illustrate, consider the case of "troublesome network infrastructure": any request via the Google nameservers will proceed without any problem, but the response, for instance in the form of a file download, will still be "forwarded via DNS" to your machine and can get stuck in the troublesome network (timeouts etc.).
That is the easy way to explain it, reality is a little bit more complex.
I am pretty sure that using the Google nameservers will improve your internet connectivity to some considerable extent, so please try and test (!) that.
However, it still is imperative to remove the line "199.115.104.31 pleskwin.download.swsoft.com download1.parallels.com autoinstall.plesk.com origin.autoinstall.plesk.com" from /etc/hosts.
After all, the line in question "bypasses" (simply stated) DNS and any error in that line will result in issues. See also my earlier post.
Hope the above helps.
Regards.....
Pagemakers
Silver Pleskian
I've noticed that in the past few updates I not longer receive an email when the update is complete. Happens on all my servers.
Is that correct?
Is that correct?
@Pagemakers
That should not be the case.
If they are not in a spam folder (for instance, Gmail has this nasty habit), you should check in the maillog that those mails were indeed sent.
If you cannot find any traces of "update related" mails in the maillog when the next update is applied, just have a look at the update and upgrade settings, that could be the cause.
One way of working around the issue is simply selecting a different update and upgrade setting, press on OK and revert to your original settings afterwards. That occasionally works.
Regards......
That should not be the case.
If they are not in a spam folder (for instance, Gmail has this nasty habit), you should check in the maillog that those mails were indeed sent.
If you cannot find any traces of "update related" mails in the maillog when the next update is applied, just have a look at the update and upgrade settings, that could be the cause.
One way of working around the issue is simply selecting a different update and upgrade setting, press on OK and revert to your original settings afterwards. That occasionally works.
Regards......
Similar threads
