Facebook
Twitter-
Please be aware: Kaspersky Anti-Virus has been deprecatedWith the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
-
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.
AutoUpdater Problem
- Thread starter MarcusR
- Start date
U
UFHH01
Guest
Hi MarcusR,
did you try to investigate the issue with logs and/or configuration files, depending on mail and ftp ? Or do you use any additional firewall, which might block the access? Did you try to investigate if the services were running before restarting "psa" ?
did you try to investigate the issue with logs and/or configuration files, depending on mail and ftp ? Or do you use any additional firewall, which might block the access? Did you try to investigate if the services were running before restarting "psa" ?
Last edited by a moderator:
U
UFHH01
Guest
Hi MarcusR,
even that I already mentioned it, but we can only guess what might be the cause of your issue, which is only time-investment without the advantage to be able to really help you. If your own investigations don't result to any point, where you could be able to solve your issue, then you could always add your depending log- and configuration - files to any of your posts, so that people willing to help you, could be able to help with your investigations. Just pointing to your issue, no mather how often it appears, is mostly not enough to get some help.
even that I already mentioned it, but we can only guess what might be the cause of your issue, which is only time-investment without the advantage to be able to really help you. If your own investigations don't result to any point, where you could be able to solve your issue, then you could always add your depending log- and configuration - files to any of your posts, so that people willing to help you, could be able to help with your investigations. Just pointing to your issue, no mather how often it appears, is mostly not enough to get some help.
Wizzie
New Pleskian
I have a similar issue after the fraking autoupdate but with apache.
I cannot access any of the websites, excepting for the moments when plesk allows me to.
I cannot make any backups either.
Should i answer the support phone, or should i ask them to pay me for support when they pay me to use the flawless services of plesk panel?
L.E. Now it works
L.E. Now it doesn't
L.E. Now it works again
L.E. Oh wait, it stopped again.
I cannot access any of the websites, excepting for the moments when plesk allows me to.
I cannot make any backups either.
Should i answer the support phone, or should i ask them to pay me for support when they pay me to use the flawless services of plesk panel?
L.E. Now it works
L.E. Now it doesn't
L.E. Now it works again
L.E. Oh wait, it stopped again.
Last edited:
U
UFHH01
Guest
Hi Wizzie,
Plesk software doesn't replace a system administrator, it just helps them to make hosting easier. This doesn't mean, that there will never be any failures/issues/problems and to solve such things it is necessary to investigate the cause. If you would like some help with your investigations, please start with posting log - entries and depending configuration files, because guessing suggestions out of the blue is a rather timewasting hobby.
Plesk software doesn't replace a system administrator, it just helps them to make hosting easier. This doesn't mean, that there will never be any failures/issues/problems and to solve such things it is necessary to investigate the cause. If you would like some help with your investigations, please start with posting log - entries and depending configuration files, because guessing suggestions out of the blue is a rather timewasting hobby.
Wizzie
New Pleskian
Hi there UFHH01,
I know that plesk software does not replace a system administrator, it gives him some more work to do.
I am used to see various errors and problems but never seen a panel with the amount of issues i have encountered here. I did not get this kind of trouble even from the boring and buggy Kloxo.
Is the only server where i use plesk and god knows that i always have to investigate something. When i ask for support i'm being told to go pay some more.
Had my share of plesk as a timewasting hobby.
Take 1 vps, 3 wordpress websites and less than a dozen of email accounts but not at last, less than 1k visitors/day.
Take 6core cpu, 32gb ram, 2tb storage and ubuntu 14.04.
Take fraking everything as you designed it, with default settings.
Where is my mistake in all these?
Each and every update something crashes, something stalls or slows down, something reports incredible resource usage for few emails and few visitors, and so on.
As i was saying, never had that much trouble with cpanel or even free panels like kloxo.
I work in a datacenter, i'm not a noob and as you can see in almost two years since i am using plesk i had little to ask, but again god knows i've spent a lot of time debugging.
I know that plesk software does not replace a system administrator, it gives him some more work to do.
I am used to see various errors and problems but never seen a panel with the amount of issues i have encountered here. I did not get this kind of trouble even from the boring and buggy Kloxo.
Is the only server where i use plesk and god knows that i always have to investigate something. When i ask for support i'm being told to go pay some more.
Had my share of plesk as a timewasting hobby.
Take 1 vps, 3 wordpress websites and less than a dozen of email accounts but not at last, less than 1k visitors/day.
Take 6core cpu, 32gb ram, 2tb storage and ubuntu 14.04.
Take fraking everything as you designed it, with default settings.
Where is my mistake in all these?
Each and every update something crashes, something stalls or slows down, something reports incredible resource usage for few emails and few visitors, and so on.
As i was saying, never had that much trouble with cpanel or even free panels like kloxo.
I work in a datacenter, i'm not a noob and as you can see in almost two years since i am using plesk i had little to ask, but again god knows i've spent a lot of time debugging.
@Wizzie,
Seems to me you do have a proper hardware config, but the presence of the VPS AND (in specific) the Wordpress sites do worry me.
The essence of your problems is apache showing erratic behaviour, being: stopping and starting many times, in a short time span.
This is often the result of watchdog doing the work, as intended. In this case with some undesired results.
However, that only (properly) explains the starting part (of apache), if and only if you have the health monitoring module (watchdog) installed.
Do you have this module installed?
Anyway, the starting and restarting of apache is (probably) not the issue to focus on.
The proper cause of the current problem is apache stopping (and that is not very likely to be the result of updates or alike).
Erratic behaviour of apache can be explained by
- a faulty NIC,
- poor apache settings (I know, the default plesk apache settings are not optimal, but they will do),
- the VPS consuming a lot of bandwidth and/or causing hickups in the NIC/data transfer,
- hacked wordpress installations (mostly old versions, with some tiny line of code in one of the many php scripts)
and so on.
I almost forget one thing: the hosting provider (in your case: probably the data center) is causing some hickups in data transfer.
I presume that it is not the VPS, at least in this case, even though 14.04.1 LTS has its problems when using KVM.
I personally think that you should
a) update all wordpress installations AND check them for hacks (can do no harm, it is good practice to check wordpress installations often),
b) monitor data traffic (that is, ascertain that it is continuous).
It can be the case that discontinuous data transfer will queue web (apache) requests, with apache suffocating in a short time span (due to plesk default apache settings).
Increase the memory for apache a little bit, that will probably resolve many issues with Apache.
And focus on the fact that the cause of "apache stopping" is the cause of the problems you encounter.
Keep me posted, I am rather curious...........
Kind regards....
Seems to me you do have a proper hardware config, but the presence of the VPS AND (in specific) the Wordpress sites do worry me.
The essence of your problems is apache showing erratic behaviour, being: stopping and starting many times, in a short time span.
This is often the result of watchdog doing the work, as intended. In this case with some undesired results.
However, that only (properly) explains the starting part (of apache), if and only if you have the health monitoring module (watchdog) installed.
Do you have this module installed?
Anyway, the starting and restarting of apache is (probably) not the issue to focus on.
The proper cause of the current problem is apache stopping (and that is not very likely to be the result of updates or alike).
Erratic behaviour of apache can be explained by
- a faulty NIC,
- poor apache settings (I know, the default plesk apache settings are not optimal, but they will do),
- the VPS consuming a lot of bandwidth and/or causing hickups in the NIC/data transfer,
- hacked wordpress installations (mostly old versions, with some tiny line of code in one of the many php scripts)
and so on.
I almost forget one thing: the hosting provider (in your case: probably the data center) is causing some hickups in data transfer.
I presume that it is not the VPS, at least in this case, even though 14.04.1 LTS has its problems when using KVM.
I personally think that you should
a) update all wordpress installations AND check them for hacks (can do no harm, it is good practice to check wordpress installations often),
b) monitor data traffic (that is, ascertain that it is continuous).
It can be the case that discontinuous data transfer will queue web (apache) requests, with apache suffocating in a short time span (due to plesk default apache settings).
Increase the memory for apache a little bit, that will probably resolve many issues with Apache.
And focus on the fact that the cause of "apache stopping" is the cause of the problems you encounter.
Keep me posted, I am rather curious...........
Kind regards....
I must say a few words. From time to time people come and write about the problems with Plesk post-updates/post-upgrades. They do not provide detailed descriptions of the problems. They just wrote about how everything is bad in Plesk after the next update. Nothing more. I understand that this may be emotion, anger, fatigue. But!
Guys, all of you know that in our Plesk community we always glad to help people who come with specific problem that is described in detail, with the logs, errors, and so on. Parallels staff and experienced and respected Plesk experts trying to help everyone in this case.
In addition, if you paid for the official support service and if it is found that your problem was caused by product bug without available solution or workaround from Parallels, then your purchase will be re-funded.
Guys, all of you know that in our Plesk community we always glad to help people who come with specific problem that is described in detail, with the logs, errors, and so on. Parallels staff and experienced and respected Plesk experts trying to help everyone in this case.
In addition, if you paid for the official support service and if it is found that your problem was caused by product bug without available solution or workaround from Parallels, then your purchase will be re-funded.
@IgorG
I can understand the nature of your remark and to a certain degree (a high level), you are right.
In essence, Plesk works fine with or without upgrading and certainly when using clean new installations as a starting point.
However, some of the errors encountered by Plesk administrators are related to
- bugs and bug fixes, stacked upon each other after each upgrade (i.e. some of those bugs or bugfixes do leave an improper system and/or database)
- issues occurring, when upgrading in the case of a huge difference between version numbers (i.e. old version and new version are very apart)
- specific default settings that are suboptimal and are not needed for Plesk to run,
and the above is just a brief summary of points that Parallels can and should address.
As a first illustration, the Apache default settings are a little bit dubious, often ending up in Apache crashing, due to a lack of memory and/or high cpu consumption.
It should be noted that some minor changes can prevent most of the Apache settings.
Currently, those settings (like memory_limit) are static values, but is easy to implement dynamic value logic, setting values according to the available memory on the machine.
As a second illustration, Plesk consists of some base packages from Parallels (often binaries) and some general Open Source packages.
The Open Source packages are vulnerable in the standard fashion, in the sense that it is good practice to update regularly to the latest stable version of the packages.
Parallels delivers these Open Source packages mostly in a static version, i.e. during upgrades of Plesk, the Open Source packages are not updated to latest stable release.
This often results in problems with those Open Source packages and, as a result, there seems to be a problem with Plesk (and it is not a problem caused by Plesk).
A workaround is often found in upgrading specific Open Source packages.
Parallels can do that also, in order to increase customer satisfaction.
As a final note (not illustration), most of the problems occur on CentOs based systems, if you analyze the Parallels forum.
It seems to me that some basic issues have been present in making Plesk available for CentOs.
In an Ubuntu and/or (normal) debian installation, many of the problems encountered with CentOs are not present.
Parallels can at least give the advice that other OS (than CentOs) should be preferred.
In summary, there is some responsibility for Parallels and Parallels can improve some of the services delivered.
However, not all issues reported are really issues related to and/or caused by Plesk, from that point of view you are right.
Anyway, there are enough error reports and/or customer dissatisfaction that requires some steps to be taken by Parallels.
Kind regards.....
I can understand the nature of your remark and to a certain degree (a high level), you are right.
In essence, Plesk works fine with or without upgrading and certainly when using clean new installations as a starting point.
However, some of the errors encountered by Plesk administrators are related to
- bugs and bug fixes, stacked upon each other after each upgrade (i.e. some of those bugs or bugfixes do leave an improper system and/or database)
- issues occurring, when upgrading in the case of a huge difference between version numbers (i.e. old version and new version are very apart)
- specific default settings that are suboptimal and are not needed for Plesk to run,
and the above is just a brief summary of points that Parallels can and should address.
As a first illustration, the Apache default settings are a little bit dubious, often ending up in Apache crashing, due to a lack of memory and/or high cpu consumption.
It should be noted that some minor changes can prevent most of the Apache settings.
Currently, those settings (like memory_limit) are static values, but is easy to implement dynamic value logic, setting values according to the available memory on the machine.
As a second illustration, Plesk consists of some base packages from Parallels (often binaries) and some general Open Source packages.
The Open Source packages are vulnerable in the standard fashion, in the sense that it is good practice to update regularly to the latest stable version of the packages.
Parallels delivers these Open Source packages mostly in a static version, i.e. during upgrades of Plesk, the Open Source packages are not updated to latest stable release.
This often results in problems with those Open Source packages and, as a result, there seems to be a problem with Plesk (and it is not a problem caused by Plesk).
A workaround is often found in upgrading specific Open Source packages.
Parallels can do that also, in order to increase customer satisfaction.
As a final note (not illustration), most of the problems occur on CentOs based systems, if you analyze the Parallels forum.
It seems to me that some basic issues have been present in making Plesk available for CentOs.
In an Ubuntu and/or (normal) debian installation, many of the problems encountered with CentOs are not present.
Parallels can at least give the advice that other OS (than CentOs) should be preferred.
In summary, there is some responsibility for Parallels and Parallels can improve some of the services delivered.
However, not all issues reported are really issues related to and/or caused by Plesk, from that point of view you are right.
Anyway, there are enough error reports and/or customer dissatisfaction that requires some steps to be taken by Parallels.
Kind regards.....
@trialloto,
We are very thankful for this elaborated feedback.
Yes, we do recognize the impact of small problems stacked over and over for several years. We were also reported by support teams in a number of hosting companies, that those broken configurations are often the cause of migration/upgrade failure. Once they fix those inconsistencies everything works well again, but very few users would have sufficient knowledge for this job. For that reason we plan to ship in the next version integrity scanner and self-repair tool. Work in progress already.
Monitoring and updating of "open source" packages is planned for the next release too. We definitely agree it is critical task to stay up2date given all recent vulnerabilities.
You can see and upvote the conversation at Keep server up2date with "apt-get" or "yum" (update PHP, Apache, MySQL, etc)
Default settings are another pain point, we agree. Generally Plesk doesn't intend to substitute professional admin and in many companies server image is carefully prepared for intended load. However installing Plesk on raw server still seems quite common case. We consider adding some auto-configuration for defaults, though it is quite specific task and good infrastructure provider would have more knowledge here than us. Here is some conversation about the topic - Ideal Server Tuning Table.maybe you and others would like to upvote the proposal.
I am not sure whether all issues necessarily happen on CentOS, yet definitely makes sense to check it additionally.
However our observation is that
- Ubuntu is better maintained than CentOS
- and that people choosing Ubuntu in average would be more skilled
that may definitely contribute to the topic.
Sincerely yours!
We are very thankful for this elaborated feedback.
Yes, we do recognize the impact of small problems stacked over and over for several years. We were also reported by support teams in a number of hosting companies, that those broken configurations are often the cause of migration/upgrade failure. Once they fix those inconsistencies everything works well again, but very few users would have sufficient knowledge for this job. For that reason we plan to ship in the next version integrity scanner and self-repair tool. Work in progress already.
Monitoring and updating of "open source" packages is planned for the next release too. We definitely agree it is critical task to stay up2date given all recent vulnerabilities.
You can see and upvote the conversation at Keep server up2date with "apt-get" or "yum" (update PHP, Apache, MySQL, etc)
Default settings are another pain point, we agree. Generally Plesk doesn't intend to substitute professional admin and in many companies server image is carefully prepared for intended load. However installing Plesk on raw server still seems quite common case. We consider adding some auto-configuration for defaults, though it is quite specific task and good infrastructure provider would have more knowledge here than us. Here is some conversation about the topic - Ideal Server Tuning Table.maybe you and others would like to upvote the proposal.
I am not sure whether all issues necessarily happen on CentOS, yet definitely makes sense to check it additionally.
However our observation is that
- Ubuntu is better maintained than CentOS
- and that people choosing Ubuntu in average would be more skilled
that may definitely contribute to the topic.
Sincerely yours!
Pascal_DEVIF
New Pleskian
Hi,
Same kind of problem here.
FTP always have to be restarted after Plesk update or it don't answer ...
I should be happy to communicate you any log.
What do you need ?
Same kind of problem here.
FTP always have to be restarted after Plesk update or it don't answer ...
I should be happy to communicate you any log.
What do you need ?
@sergey,
A very long time ago, I was rather active on this forum and/or with Plesk development and, as a result, I recognize the nature and content of your post.
To be honest, some general issues are "old as Methusalem" and other alleged (general) issues are more or less the result of (a lack of) knowledge of Plesk customers.
In general, I have indicated in the past that I am willing to contribute to Plesk AND I still am willing to contribute, just as many others are.
Even though Plesk is proprietary software, the lack of a launchpad and/or github and/or other ways to commit (code) is impeding the evolution of Plesk and, more specific, the active and fast resolution of many general (and de facto minor) issues regarding some small problem.
It would certainly be nice if Parallels opens up for code commits, since all administrators (and Parellels) would be reinventing the wheel.
In response to your post, the following.
In my personal experience, a manual fix aggravates the issue in the short AND long run.
In contrast, a new installation of Plesk always works the best for resolving issues.
Note that the above hints the area where issues are resulting from, being the upgrade process.
The above hint also is confirmed by the fact that one can easily upgrade packages (that are part of Plesk), without any failures occuring afterwards.
Naturally, all the above hints that a self-repair tool should be emphasizing the rollback of installations, instead of "repairing" them.
In a sense, a big improvement in that area has already been realized in the form of the new installer, with an option to delete specific programs/components.
By the way, a long time ago, I was working on that installer functionality, but Parallels was faster (to my delight).
A question: I recall, if I am not mistaken, that in previous versions a self-repair tool already existed. Is that correct? If so, are you redesigning or creating a new tool?
With respect to the integrity scanner: can you eloborate?
In general, this would be one or two lines of code, added to the Plesk core.
However, many of the hard core admins do want to keep control, for various (right and, to be honest, many wrong) reasons.
I am not sure whether this should be a functionality in Plesk, although some warnings in Plesk Panel could be silencing the discussion about Open Source package updating.
You certainly do not have to agree, as I have explained in my reaction in the topic - Ideal Server Tuning Table.
I have made some comments and a proposal for a method for approaching the configuration issue, naturally in the topic - Ideal Server Tuning Table.
This really made me smile or even laugh.
It is true, even though optional (not being core) Ubuntu packages are more and more developed in an environment, that is subject to "the less skilled committing", "muck of code prophecy for Open Source" or even "conflicts of interests" (i.e. large companies entering the development environment).
Nevertheless, Parallels could benefit by allowing some users to suggest some hotfixes and committing them.
For instance, in a far away past, I was very surprised to see that I resolved some (very minor) issue and seeing the patch for that issue introduced several months afterwards.
I can imagine that Parallels cannot or does not want to analyze all commits, but it can certainly help to have commits from non-Parallels employees.
Would that be an idea?
Finally, I can report some other things/improvements, but it seems to be inappropriate to mention them at this time and/or in this topic.
However, one major "thing" or even an issue: how about supporting cloud infrastructures, such as Azure?
I am rather curious, but the latter question is not of the highest importance, I would rather have a general response, in specific to the possibility to contribute to Plesk.
Kind regards.....
A very long time ago, I was rather active on this forum and/or with Plesk development and, as a result, I recognize the nature and content of your post.
To be honest, some general issues are "old as Methusalem" and other alleged (general) issues are more or less the result of (a lack of) knowledge of Plesk customers.
In general, I have indicated in the past that I am willing to contribute to Plesk AND I still am willing to contribute, just as many others are.
Even though Plesk is proprietary software, the lack of a launchpad and/or github and/or other ways to commit (code) is impeding the evolution of Plesk and, more specific, the active and fast resolution of many general (and de facto minor) issues regarding some small problem.
It would certainly be nice if Parallels opens up for code commits, since all administrators (and Parellels) would be reinventing the wheel.
In response to your post, the following.
In my personal experience, a manual fix aggravates the issue in the short AND long run.
In contrast, a new installation of Plesk always works the best for resolving issues.
Note that the above hints the area where issues are resulting from, being the upgrade process.
The above hint also is confirmed by the fact that one can easily upgrade packages (that are part of Plesk), without any failures occuring afterwards.
Naturally, all the above hints that a self-repair tool should be emphasizing the rollback of installations, instead of "repairing" them.
In a sense, a big improvement in that area has already been realized in the form of the new installer, with an option to delete specific programs/components.
By the way, a long time ago, I was working on that installer functionality, but Parallels was faster (to my delight).
A question: I recall, if I am not mistaken, that in previous versions a self-repair tool already existed. Is that correct? If so, are you redesigning or creating a new tool?
With respect to the integrity scanner: can you eloborate?
In general, this would be one or two lines of code, added to the Plesk core.
However, many of the hard core admins do want to keep control, for various (right and, to be honest, many wrong) reasons.
I am not sure whether this should be a functionality in Plesk, although some warnings in Plesk Panel could be silencing the discussion about Open Source package updating.
You certainly do not have to agree, as I have explained in my reaction in the topic - Ideal Server Tuning Table.
I have made some comments and a proposal for a method for approaching the configuration issue, naturally in the topic - Ideal Server Tuning Table.
This really made me smile or even laugh.
It is true, even though optional (not being core) Ubuntu packages are more and more developed in an environment, that is subject to "the less skilled committing", "muck of code prophecy for Open Source" or even "conflicts of interests" (i.e. large companies entering the development environment).
Nevertheless, Parallels could benefit by allowing some users to suggest some hotfixes and committing them.
For instance, in a far away past, I was very surprised to see that I resolved some (very minor) issue and seeing the patch for that issue introduced several months afterwards.
I can imagine that Parallels cannot or does not want to analyze all commits, but it can certainly help to have commits from non-Parallels employees.
Would that be an idea?
Finally, I can report some other things/improvements, but it seems to be inappropriate to mention them at this time and/or in this topic.
However, one major "thing" or even an issue: how about supporting cloud infrastructures, such as Azure?
I am rather curious, but the latter question is not of the highest importance, I would rather have a general response, in specific to the possibility to contribute to Plesk.
Kind regards.....
@pascal,
Do the following:
1 - cat /root/.autoinstaller/microupdates.xml (to establish version and microupdate, the microupdate version should be 33)
2 - have a look in /tmp/autoinstaller3.log and check for warnings (start at the date at which the latest microupdate has been installed, see step one)
One could also do: grep -in "warning" /tmp/autoinstaller3.log (and report them on this forum, if step 2 does not give you a hint where to search).
Kind regards....
Do the following:
1 - cat /root/.autoinstaller/microupdates.xml (to establish version and microupdate, the microupdate version should be 33)
2 - have a look in /tmp/autoinstaller3.log and check for warnings (start at the date at which the latest microupdate has been installed, see step one)
One could also do: grep -in "warning" /tmp/autoinstaller3.log (and report them on this forum, if step 2 does not give you a hint where to search).
Kind regards....
And we are really happy to see you back here!
While we are not really going into open source, there is actually way to customize Plesk widely via its SDK. As you can see in the available extensions (https://ext.plesk.com/) - it allows a lot of various stuff implemented.
There is some presence on github as well - https://github.com/plesk
Unfortunately exposing whole Plesk core would be very hard to maintain by now - a small fix can perfectly work in a particular environment, but we have to run tests on several hundreds of possible setups. However we consider putting certain parts of Plesk on github, so that those parts can be branched and tuned by volunteers.
Naturally, all the above hints that a self-repair tool should be emphasizing the rollback of installations, instead of "repairing" them.
In a sense, a big improvement in that area has already been realized in the form of the new installer, with an option to delete specific programs/components.
By the way, a long time ago, I was working on that installer functionality, but Parallels was faster (to my delight).
There were some tools able to recover some parts of Plesk. i.e. "bootstrapper" was able to recover incomplete installations or failed upgrades with high success rate. We are reusing and extending such tools, also consolidating under single entry point for easier learning.
Over time bugs, failed operations or improper customizations/workarounds may leave some "trail" - i.e. some internal records will remain disconnected or not fully removed, or keep it in other form of inconsistent status. So there will be a scanner walking through the internal data structure, matching against proper data patterns and then reporting/fixing issues discovered.
Your posting in plesk.uservoice.com is a great value to us. Some proposals are controversial and we truly love to hear different opinions.
Hosting seem to be slightly more comlicated than just "one size fits all"
You are absolutely right that those scripts can be developed out of Plesk and we are aware of several proprietary scripts doing this job for some providers. They are quite huge sometimes. In many other cases it would be a preconfigured image, maybe even manually tuned, and then used for producing 100s-1000s of servers.
Forcing some "ideal" configuration from Plesk would definitely conflict with such tunings and will put unnecessary responsibility on us, so we would rather have it as "optional" for those who cannot have advantage of skilled admin or pre-tuned setup.
This is discussable.
Being big company applies certain constraints on how we operate, but there are always some options. i.e. we could start with something lightweight - opening special forum for patch proposals. A lot of scripts in Plesk are open and can be patched. We can probably review, adjust to our policies and include into the next update. More than that - we could probably accept config patches and convert them into code on our side.
Actually many admins have very extensive scripting over Plesk (but not everyone would want to share them).
If there will be big enough activity at this level, we can consider moving to next step.
Does it sound reasonable to you?
We are available actually. You can find Plesk in Amazon catalog.
For Digital Ocean and Azure their policies don't let us to put pre-made images, so we have some guidelines in the internet:
1) How to make Plesk in Digital Ocean
2) How to make Plesk in Azure
@sergey,
In response to your post the following, with quotes (to keep some distinction).
To be honest, it is showing a lack of extensions (several years after the introduction of the SDK), given the fact that Plesk Panel is widely implemented.
Again, to be honest, the above can also be reflecting the fact that a lot of the extensions are not required, i.e. out-of-the-box Plesk is good enough.
This would certainly be wise for testing compatibility of new Open Source packages, since it is a minor task to install those packages and "see what happens" (and by using the Github project page, the parallels forums would be containing less "alleged error" messages).
Maybe the core Plesk code cannot be shared, from a company´s (i.e. Parallels) perspective).
However, some of the code is already residing on the server, after installation, giving the possibility to tweak some of the code.
A Github project page would then create a more streamlined method of coördination.
By the way, any Github project initiative should be implemented properly (for instance, the https://github.com/plesk/api-examples is not an effective way of doing things).
Sounds very good! Primarily the part of reporting issues would be a nice enhancement.
Problem and/or challenge would be (again) the "zoo of OS-es" supported.
In general, I noticed that many "advanced Plesk users" are willing to share knowledge, scripts etc.
The general problem here is that a platform for sharing (code, scripts etc.) is not available, with the one exception of this forum, giving rise to the pitfall that individual and/or stand-alone issues are targeted (and after some period, one really does give up, if some issues continuously re-emerges).
Is a "sharing platform" a good idea?
In the light of the above, some standard customization can be assigned to the community, without Parallels being involved and/or responsible.
Stating the obvious: yes, it sure does.
However, some words of caution are needed here:
a) Patches and config patches should be distinguished, for many reasons, amongst others that config patches are often subject to opinions (i.e. preferences of the admin) or situations (set-ups, OS-es etc.), implying that config patches are not and/or should not be the most important and, even when applied, should be carefully reviewed for general applicabilty and overall desirability,
b) Patch proposal (not being config patches) should be considered as a potential danger, leading to development outside the code of a lean-mean-and-efficient Plesk Core, as such not in line with the (proper) goal of improving the Plesk Core itself,
and, as a result, one (i.e. Parallels primarily) should guide the process of development, being either patch or other development.
In a certain sense, the opening of a special forum for patch proposals is only a starting point, but it can be reasonably expected not to be an effective one, given the above and the fact that it will give rise to "ideas" and less to "code", let alone "guided code development" (allowing realisation of the desired patch).
But then again, keeping in mind that we need ideas, the special forum is required and, in combination with some Github (patch) repo, we should get where we want.
By the way, the "advanced admins" you are talking about, those persons are more likely to share code on Github than on a special forum, given the general purpose function of Github and the absence of limitations of specific questions on the Parallels forums (by which I mean that most of the generic, simple issues reported on these forums do not require an extensive, highly advanced script as created by many "advanced admins").
A final note, you are aware that opening up for patch proposals can also increase the number of problems regarding stability of Plesk?
I am aware of Plesk in the Amazon catalog and the internet guidelines.
However, the Azure (internet) guidelines are targeted at Windows (and not Linux) and, furthermore, Amazon and Azure and Digital Ocean instructions are concerning creation and/or usage of images for Plesk.
The above (obviously) does not include and/or embrace the full possibility of the cloud.
Moreover, the inherent dangers of the cloud are not mentioned at all.
For instance, automatic scaling of a VM on Azure is not possible with custom images.
In short, there is (at least) a huge gap in the documentation.
In addition to the above, the following.
Plesk can be made to run on multiple (clustered) VMs in the cloud, even though it is rather difficult (not impossible) to make the installation proper and stable.
Parallels should be aware that the one-machine-one-license model is out of date, given the recent developments in the cloud.
I would rather have clear instructions regarding cloud setup (not instructions on how to setup Plesk on a single VM, that is straightforward and almost equivalent to installations on a single dedicated server) AND (code-based) support for cluster-based cloud setup (on multiple VMs).
The idea should not be that a deployment in the cloud becomes a single-instance Plesk Server.
The idea should be that deployment in the cloud becomes a choice between various deployment methods: cluster, fail-over, load-balanced etc.
In my humble opinion, the above is a highly ideologic target on my behalf, but one that should fit into Parallels future targets nicely.
And, in a sense, in realising this target, some work can be done by the community, which can be expected to contribute happily to this target (that is my firm belief).
Kind regards....
In response to your post the following, with quotes (to keep some distinction).
To be honest, it is showing a lack of extensions (several years after the introduction of the SDK), given the fact that Plesk Panel is widely implemented.
Again, to be honest, the above can also be reflecting the fact that a lot of the extensions are not required, i.e. out-of-the-box Plesk is good enough.
This would certainly be wise for testing compatibility of new Open Source packages, since it is a minor task to install those packages and "see what happens" (and by using the Github project page, the parallels forums would be containing less "alleged error" messages).
Maybe the core Plesk code cannot be shared, from a company´s (i.e. Parallels) perspective).
However, some of the code is already residing on the server, after installation, giving the possibility to tweak some of the code.
A Github project page would then create a more streamlined method of coördination.
By the way, any Github project initiative should be implemented properly (for instance, the https://github.com/plesk/api-examples is not an effective way of doing things).
Sounds very good! Primarily the part of reporting issues would be a nice enhancement.
Problem and/or challenge would be (again) the "zoo of OS-es" supported.
In general, I noticed that many "advanced Plesk users" are willing to share knowledge, scripts etc.
The general problem here is that a platform for sharing (code, scripts etc.) is not available, with the one exception of this forum, giving rise to the pitfall that individual and/or stand-alone issues are targeted (and after some period, one really does give up, if some issues continuously re-emerges).
Is a "sharing platform" a good idea?
In the light of the above, some standard customization can be assigned to the community, without Parallels being involved and/or responsible.
This is discussable.
i.e. we could start with something lightweight - opening special forum for patch proposals. A lot of scripts in Plesk are open and can be patched. We can probably review, adjust to our policies and include into the next update. More than that - we could probably accept config patches and convert them into code on our side.
Actually many admins have very extensive scripting over Plesk (but not everyone would want to share them).
If there will be big enough activity at this level, we can consider moving to next step.
Does it sound reasonable to you?
Stating the obvious: yes, it sure does.
However, some words of caution are needed here:
a) Patches and config patches should be distinguished, for many reasons, amongst others that config patches are often subject to opinions (i.e. preferences of the admin) or situations (set-ups, OS-es etc.), implying that config patches are not and/or should not be the most important and, even when applied, should be carefully reviewed for general applicabilty and overall desirability,
b) Patch proposal (not being config patches) should be considered as a potential danger, leading to development outside the code of a lean-mean-and-efficient Plesk Core, as such not in line with the (proper) goal of improving the Plesk Core itself,
and, as a result, one (i.e. Parallels primarily) should guide the process of development, being either patch or other development.
In a certain sense, the opening of a special forum for patch proposals is only a starting point, but it can be reasonably expected not to be an effective one, given the above and the fact that it will give rise to "ideas" and less to "code", let alone "guided code development" (allowing realisation of the desired patch).
But then again, keeping in mind that we need ideas, the special forum is required and, in combination with some Github (patch) repo, we should get where we want.
By the way, the "advanced admins" you are talking about, those persons are more likely to share code on Github than on a special forum, given the general purpose function of Github and the absence of limitations of specific questions on the Parallels forums (by which I mean that most of the generic, simple issues reported on these forums do not require an extensive, highly advanced script as created by many "advanced admins").
A final note, you are aware that opening up for patch proposals can also increase the number of problems regarding stability of Plesk?
I am aware of Plesk in the Amazon catalog and the internet guidelines.
However, the Azure (internet) guidelines are targeted at Windows (and not Linux) and, furthermore, Amazon and Azure and Digital Ocean instructions are concerning creation and/or usage of images for Plesk.
The above (obviously) does not include and/or embrace the full possibility of the cloud.
Moreover, the inherent dangers of the cloud are not mentioned at all.
For instance, automatic scaling of a VM on Azure is not possible with custom images.
In short, there is (at least) a huge gap in the documentation.
In addition to the above, the following.
Plesk can be made to run on multiple (clustered) VMs in the cloud, even though it is rather difficult (not impossible) to make the installation proper and stable.
Parallels should be aware that the one-machine-one-license model is out of date, given the recent developments in the cloud.
I would rather have clear instructions regarding cloud setup (not instructions on how to setup Plesk on a single VM, that is straightforward and almost equivalent to installations on a single dedicated server) AND (code-based) support for cluster-based cloud setup (on multiple VMs).
The idea should not be that a deployment in the cloud becomes a single-instance Plesk Server.
The idea should be that deployment in the cloud becomes a choice between various deployment methods: cluster, fail-over, load-balanced etc.
In my humble opinion, the above is a highly ideologic target on my behalf, but one that should fit into Parallels future targets nicely.
And, in a sense, in realising this target, some work can be done by the community, which can be expected to contribute happily to this target (that is my firm belief).
Kind regards....
That's not AppStore boom for sure, yet for a year since Extension Catalog was launched Plesk got 2x more extensions than for the 10 years before.
People are easy to make custom script, but developing distributable soft is much less common unfortunately.
There are still lots of areas to cover with extensions.
Sure, this code is would be the first candidate.
I am personally not so much of a github expert, but if you would be willing to share more on what's wrong about api-examples, I can communicate to those who made it.
Definitely. As a lightweight solution we have this forum - http://talk.plesk.com/forums/solutions-and-extensions.725/ (Solutions and Extensions)
Yes, a lot of caution would be required. Generally our observation is that there may be two types of people:
- admins, whose code does right things in not less-than-perfect" way
- devs, whose code does "less-than-perfect" things in a right way
We have devs in staff who can code things right, but we may lack sometimes admin knowledge.
For that reason we are far more interested in a knowledge shared, than in a code contributed.
When in touch with friendly providers, we use this opportunity to get copies of scripts fixing or working around issues in the product for self-improvement.
If you have any fixes to share, we can think about dedicated sub-forum for that. We will need someone to start.
Generally we will be happy to see ideas as well, as long as they are specific - more of a solution or a know-how, than a feature request. i.e. this script of mine does bind restart (merely an example) better than yours because of ... If discussed in the community and agreed to be a better way - why not?
Coding for Plesk can be challenging however - zoo of OSes requires us to have a range of internal frameworks addressing those differences. What looks like a shell script when installed may be some meta-language in the code. It may potentially be discouraging.
Can you share more?
Of course, special handling for cloud features may be required - i.e. we need special scipts for reconfiguring IPs
But what is a problem of scaling?
We did research clustered setups some time ago. Highload, failover, etc. As of today it is inconclusive unfortunately. While some people would do them, in many other companies it is seen as unnecessary due to VMs can easily be scaled up (and even clustered) purely by virtualization platform itself. Not really sure what makes people think different, but both sides have quite strong opinion.
We have some other thoughts about Plesk future as well.
Do you consider attending any hosting events this year in person?Regards
Last edited:
Wizzie
New Pleskian
Dear Igor, i respect the developers work no matter what that is, and i respect anyone's work.
I might be one of those emotionally, angry and fatigued person that you talked about in your early post but i ask you one thing alone, i am paying subcriptions for a software that will make my work easier and allow me to develop the business that i've started or paying to be a software tester and contribute to your software development?
Thank you for your kind words.
Please tell me how we can release great product for developing your business if we not hear voice of users of this product? Agree that if we only hear the words that our product is very bad, we can not make it better. Without constructive criticism, without detailed reports of problems, without feedback we can not know that is bad in our product, that it is necessary to alter and so on. Therefore you on this forum are helping us to do this. And this is absolutely free because it is just cooperation in Plesk community
