AutoUpdater Problem

[trialotto]

@Wizzie (and @IgorG),

In reaction to to your statement

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?

I feel that I have to add some general (neutral) comments, regarding your statement and my personal experience with Parallels.

Wizzie, your question is, in a sense, a valid one, even though I would not like to add the labels "emotional, angry and fatigued".

Naturally, you are paying for regular updates and support, which is an ongoing process.

It can be frustrating to see that some of the core Plesk packages are Plesk specific compiled and, as one of the consequences, updates can be somewhat "late", leaving the sysadmin with some problem set during a specific interval.

However, in a sense, Plesk can only assign two main goals of updates: one being patching, based upon (amongst others) feedback on this forum and support questions, and one being "growth of Plesk", based upon the desire to create an all inclusive hosting panel.

Your statement should be confined to area of "patch updates", given the nature of your statement.

Wizzie, I am sure that you can imagine that is fairly hard to destill true problems (requiring patch updates) from all the entries in this forum, given that this forum is full of admins that are not to be seen as "advanced admins", that are using their own setup (causing many Pleks unrelated issues), that are not describing the issues properly etc.

Sure, you are an advanced admin, I am aware of that.

But I am also aware that no resolution to your problems has been found, giving rise to the need of posting a question on this forum.

Your specific issues are very likely to be related to Apache (and the infamous memory leakage) and that could explain the (unrelated) backup issues (unrelated in the sense that the memory and/or CPU outage due to Apache is causing the backup process(es) to stall or even fail).

The "Apache bug" is widespread and as long as Apache does not bother to improve it, Parallels cannot resolve that issue either.

Your specific issues with Plesk Panel can also be (indirectly) related to Wordpress installations being hacked (and Wordpress is fairly hard to clean up, once infected).

The hack of Wordpress sites is widespread and the best method of resolving is making a clean install, Parallels cannot improve vulnerabilities in Wordpress.

Your specific issues can even be related to other "problems", not mentioned by you.

As can be seen, the above indicates that is fairly difficult to support you in your problems, wich applies to both Parallels and benevolent sysadmins on this forum.

However, that still does not mean that you are wrong, in a sense your statement still consists some core truth.

In my experience, it should be considered by Parallels to make development choices that make Plesk less vulnerable to "outside challenges".

For instance, the Wordpress vulnerabilities have been resolved partially by implementing updates in the Plesk Panel itself (introduced some periods ago).

A full resolution would be preventing Wordpress installations, but no-one would desire that.

In addition, Parallels can implementing auto-updates from a trusted ftp server, but most sysadmins would want to control that themselves.

In short, Parallels often has to find a balance and that balance is not always in the interest of the Plesk Panel admin.

The above is one illustration regarding Wordpress, but similar illustrations apply to all Plesk components.

In general, it is rather impossible to make Plesk Panel fully fault-proof.

However, these kind of discussions, even though being abstract, can shed a light of the future for Plesk improvements.

In my humble opinion, a forum like this is apt for discussion, but not for bug fixing for and by the community.

A Launchpad system would be more appropriate for signalling (actual) bugs and designing patch code.

But then again, you still have the current issues encountered on your Plesk installation.

I am willing to help you with that, if you can give me the adequate log outputs (for starters) and, if and only if necessary, root acccess to the server (probably not necessary).

Kind regards......

PS As an edit afterwards: if your system is not that huge, I can also provide a alternative fashion of checking your Plesk installation: testing it in a separate VM. If you want that, mail me, so we can discuss the details in order to start that process.

 

[Wizzie]

Dear friends,

I admit i overreacted a little being pushed around by clients and not having any chance to deliver a deadline, not to speak that i didn't had one myself.
After that update i had the panel taking ages to load pages, apache randomly stopping, mod_fcgid failing, vhosts randomly stop working and smtp rejecting all authetications on standard ports.
It was a bit disturbing to me because it took me a while to fix all these. The sad part was that i had no idea what hitted me in the first place, where to look and where to start first as they where all random from the panel issues to apache and smtp issues.
So, i apologize to the plesk team for any possible discomfort that i may help create!

@trialloto: We are amongs technicals here so you can sure understand my level of frustration while having to constantly to debug a standard installation with no customisations whatsoever. I also felt strange when i was directed to the payed support with the option to get my money back if someone has the same opinion as i do about those issues, since i am paying for a product that should work out of the box without problems. But it's all ok now.

 

[trialotto]

@Wizzie,

It is really not necessary to apologize or to state that you overreacted, it is quite cumbersome to be in that specific situation (I know that all too well).

With respect to the (paid) support part: the rule of thumb is not to use it (to be honest).

With respect to the issues encountered: it would be nice if you can state some concrete issues and resolutions thereof, since that is what makes this forum valuable.

With respect to the update process, one (in general) should desire two improvements:

a) a clean (proper working) installation AND a separate installation (mirror) for testing specific updates ("good practice", a task for sysadmins)

Note: in the past, I personally did that and that was strictly necessary. Nowadays, updates should not be a problem, even though the exceptional case always will exist.

b) a method of staged updating ("implementing good practice in production environments", a task for Parallels development team

The latter point b is of relevance for Parallels, since it would be very likely to significantly decrease the number of issues after updating.

For this to be succesfull, a separation between patch updates (no staging required, in theory) and regular updates (staging desirable, not required) should be present.

Kind regards.....

 

[trialotto]

@sergey,

A reaction to your last post follows below, with quotes for the sake of clarity.

.... 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.

True, please tell me/others what specific extensions you are thinking of.

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.

It is an "example" of (very simple) api clients, without any explanation and/or code regarding the api itself.

It is not likely that anyone will contribute to these (mostly old) client examples, given the facts that (on the one hand) the client libraries of the various codes (python, c#) have changed by now and (on the other hand) the api remains very basic and old.

For instance, creating a proper c# api client library also gives code that allows for (easy) creation of a modern api service running on the Plesk instance, with this modern api service being more safe and/or easy to administer that the old (rpc) api.

The above should apply to all major codes (python, perl, etc).

In a sense, the github project is based upon too old code concepts.

Nobody is investing time in that, I am pretty sure of that.

Definitely. As a lightweight solution we have this forum - http://talk.plesk.com/forums/solutions-and-extensions.725/ (Solutions and Extensions)

I have browsed that forum earlier and, to be honest, nothing new under the sun.

I even get the feeling that it is essentially one part "wishlist" and one part "advertisement".

In general, not much code there.

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.

Nice distinction between admins and devs, by the way.

Please consider a Launchpad environment, for the sake of code sharing and bug fixing.

That way, both devs and admins can interact and streamline the development process, under supervision of superusers, associated with Parallels and/or trusted by Parallels.

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.

Again, Launchpad could be a good solution, since it will allow and therefore encourage Plesk users/admins to report on or to contribute code to specific branches, subsystems, OSes, target-specific scripts etc.

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?

As far as I am aware of, Plesk installations in the cloud are solely based on "images", being snapshots of pre-installed Plesk on specific VMs with specific VM sizes and similar VM configurations settings.

For instance, a cloud provider has to deliver 3 images when using three VM sizes.

Problem then is resizing an existing Plesk image to a larger or smaller VM: currently, most providers do not allow for dynamic resizing/scaling.

Please note that scaling has a dual meaning: on the one hand it is "increasing the number of VMs in a joint set of VMs" and the other hand it is "resizing one specific VM" (being the change of VM specs).

Scaling in the meaning of "resizing" is often not possible due to "image constraints".

Scaling in the meaning of "changing VM numbers in a given VM set" is possible in theory, but in practice it often will not be feasible at all.

The above is merely an illustration, the actual problems are too many and too diverse to be mentioned.

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.

This actually represents a current flaw in structural design of Plesk.

In ONE server, the installed virtualization server software can allow for Plesk clustering, fail-over etc.

In TWO or MORE servers, it depends on the virtualization server software AND the chosen infrastructure, primarily that of the filesystem and the OS.

In the CLOUD, virtualization environments are given parameters, often not allowing clustering, fail-over etc.

Simply said, ONE Plesk installation

- CAN be distributed over multiple servers (huge degree of difficulty), AND
- CAN even be distributed over multiple (public or private) cloud servers (huge degree of difficulty), BUT
- CANNOT be SCALED from one VM to another VM with different specs,

since the latter would be merely installing Plesk on a fresh (virtual) server, hence requiring the adoption of the "image method" that most cloud providers and/or cloud software use.

In short, there is an absolute difference between clustering (fail-over, load-balancing etc.) and scaling.

However, it is absolutely true that clustering (irregardless the reason thereof) is often not necessary, but that often has nothing to do with the potential of virtualization techniques.

In essence, even though scaling and (cloud-based) clustering and scaling should be considered to be two separate discussions, the problems in both those areas are the result of one structural design "flaw".

This "flaw" is not really an actual design flaw, but a better word seems to lack.

This "flaw" is the usage of the OS-disk by Plesk for installation purposes.

That seems the logical thing to do, but in a cloud it often is not.

Both the OS and ephemeral disk are provisioned and re-provisioned at creation time of a VM.

The Plesk installation is therefore "lost" when scaling the VM, as such requiring a new provision of the VM.

The problem here is not that there is a functional flaw in the design of the infrastructure, the design of Plesk can be maintained as is.

The problem here is that one cannot easily define config directories and/or define the place (or even VMs) at which specific processes should be running.

A simple solution and a great step forward would be an "advanced" installer (not the command line one), that allows for installation on multiple machines.

To be honest, that would result in some license policy issues (one-server-one-license model), but that is not completely true: processes like MySql, drwebd, syslogd should be able to run from various places/VMs.

Note that I do not mention Apache, since currently an extensive reconfiguration of Nginx could allow for the use of a clustered Apache web server, residing on external VMs.

We have some other thoughts about Plesk future as well. Do you consider attending any hosting events this year in person?

Regards

Actually, ICT is not my core business, so you can imagine that those hosting events are not attended.

Maybe it is an idea to start with some mails and consider to pick one afternoon of one of those events?

Kind regards.....

 

[SibProgrammer]

It is an "example" of (very simple) api clients, without any explanation and/or code regarding the api itself.

The explanation of API is here - http://download1.parallels.com/Plesk/Doc/en-US/online/plesk-api-rpc/ Repo with the examples of API usage of cause doesn't contain the API reference. Most popular language for web dev is PHP (still, you may hate it, but it is what it is). For PHP there is a more high level library: https://github.com/plesk/api-php-lib (still under development). Primary goal of these repos is to help the newcomer to start using the API.

It is not likely that anyone will contribute to these (mostly old) client examples, given the facts that (on the one hand) the client libraries of the various codes (python, c#) have changed by now and (on the other hand) the api remains very basic and old.
For instance, creating a proper c# api client library also gives code that allows for (easy) creation of a modern api service running on the Plesk instance, with this modern api service being more safe and/or easy to administer that the old (rpc) api.

This is not about "examples". This is about Plesk API itself. Also there is almost no reason to "contribute" to examples, because they are already created for most popular languages.

P.S. Anyway it looks like offtopic for current thread.

 

[Thomas_Lartaud]

Hi,

i didn't read everything there, but the first question remember me that 2 weeks ago, after an auto-updater update that failed (because im using OVH distribution, and that OVH had not update their mirrors URLS), my postfix stopped working.
using ssh root, i took a look at the postfix config file :

nano /etc/postfix/main.cf

search for the string "milter" in the file.
i had this :

smtpd_milters = , inet:127.0.0.1:12768

The syntax looks wrong, so i commented it out to be :

# smtpd_milters = , inet:127.0.0.1:12768

restarted the server, and it worked again ...
Dunno if this fix was the thing that made postfix work again, but i just wanted to report this to the parallels team.

Cheers.

 

[Sergey L]

Thanks Thomas, we will check

 

[IgorG]

search for the string "milter" in the file.
i had this :

smtpd_milters = , inet:127.0.0.1:12768

The syntax looks wrong, so i commented it out to be :

Could you please clarify why do you think that this syntax is incorrect?
Thanks.

 

[SibProgrammer]

Discussion about XML-RPC API & examples was moved: http://talk.plesk.com/threads/xml-rpc-api-examples.331776/

 

[Sergey L]

Hi @trialotto,

I have browsed that forum earlier and, to be honest, nothing new under the sun.
I even get the feeling that it is essentially one part "wishlist" and one part "advertisement".

A bit surprised with this impression. There are some "howto" questions, sure, but participants of that forum were the ones who filled http://ext.plesk.com, most of their extensions are live and functioning code.

Again, Launchpad could be a good solution, since it will allow and therefore encourage Plesk users/admins to report on or to contribute code to specific branches, subsystems, OSes, target-specific scripts etc.

Maybe it is good software, yet we would start with contributors, rather than with a platform.
Once volume of contributors grows, a platform will come up surely to help handling it.
As of today, we get some fix proposals from customers, from people on standalone blogs, but not through the forum usually.

CANNOT be SCALED from one VM to another VM with different specs

Perhaps we shall start separate conversation on this as I don't fully understand a problem here and we are quite distant from original topic already.

Lets continue in separate thread for Cloud problems - http://talk.plesk.com/threads/plesk-problems-in-clouds.331777/.

regards

 

[Thomas_Lartaud]

Could you please clarify why do you think that this syntax is incorrect?
Thanks.

As i said, i don't know if modifying this fixed the problem, or maybe that rebooting changed something else, and fixed the problem itself.
I don't know if this syntax could cause the problem (starting by a comma), so i apologize if it's not.

 

[trialotto]

Hi @trialotto,

....

Perhaps we shall start separate conversation on this as I don't fully understand a problem here and we are quite distant from original topic already.

Lets continue in separate thread for Cloud problems - http://talk.plesk.com/threads/plesk-problems-in-clouds.331777/.

regards

Sergey,

That seems to be the proper thing to do.

Kind regards...