Permissions error after upgrade

[Pagemakers]

A few of my scripts are giving permissions errors after upgrading from 7.16 to 7.5

I've tried re-installing them but I keep getting the same error.

 

[Mu-host.com]

What scripts are giving you trouble?

 

[Pagemakers]

A cgi mailing list script. I get a permissions error when I try to send the mailout. Worked fine before.

 

[Mu-host.com]

Have you hade sure that the file's actually executable (755 or equivalent) and that it is owned by the proper user that's executing the script? Another possible cause can of course be that you compile httpd manually (like I do) and have forgotten to replace suexec with the psa-suexec.

 

[Pagemakers]

More and more scripts are now failling with permissions errors!!!

Nope - I don't compile manually.

Bloody Plesk AGAIN

 

[Mu-host.com]

Give me the permissions of the script failing? Where is it located? In a vhost dir, or in the /usr/local/psa/admin/cgi-bin dir?

 

[Pagemakers]

Fixing them one by one.

Quote from my engineer:

"seems the perl upgrade broke your mailing app"

"perms on the file system seems to have been altered as well as the apache/php perms"

 

[Pagemakers]

I think all 777 permissions have been reset to 755

I thought this was fixed many months ago?

 

[Mu-host.com]

777 permissions is a "Bad Thing(tm)" though, so I don't really disagree with that. Perhaps the scripts you are using are expecting the wrong permissions?

 

[Pagemakers]

Well it may not necessarily be 777 permissions. That was just me assuming....

However, about 10% of all the scripts on our 7.50 servers stopped working.

From mailing lists to counters, in fact, come to think of it, scripts that write files to the server....

I have never had this problem before with any Plesk upgrade.

 

[Mu-host.com]

Actually, I had two clients recently report that their Movable Type CGI scripts stopped working as well, so this is probably an issue after all.

 

[mac0310]

Okay so now what?

I think it is safe to say that there are several major issues with the 7.5.0 upgrade and the question I have is who at SW-Soft should be told about this so they can stopping calling it user error and fix their own mistakes! It amazes me how much effort they put into trying to charge me for support when it is their own fault. Perhaps if they put the same amount of effort into their code we wouldn't be on this forum bitching.

 

[Pagemakers]

I've just paid somebody €300 to fix the mess after the upgrade today.

I've had clients calling all day complaining.

Why do you upgrade they ask?

To fix bugs I answer.

Sadly, we fix bugs A, B & C only to get bugs D, E & F

I agree with mac. I have paid for Plesk email support yet 95% of everything I report is a bug with the software and not something I have done.

 

[mac0310]

Question

I am relatively new to Plesk and SW-Soft with Plesk running on my servers for a month or so and the question I have is are there any formal mechanisms in place to report bugs? In my experience releases were made available to a Beta community and then unleashed on the paying public once the problems had been ironed out. I am getting the impression that SW-Soft is practically rolling out Beta material or is there something I need to be made aware of?

 

[Cranky]

You can report bugs to bugreport@sw-soft.com ... the software is tested I can assure you.

 

[jmfrisch]

This is absolutely terrible. Obviously there was very little testing done, as seems to often be the case. I am extremely unhappy with swsoft.

 

[brooks]

I understand the frustration. Do we know what actually caused these CGI scripts to fail?

 

[jmfrisch]

It seems that the SuexecUserGroup variable disappeared from the vhost Apache configuration. Therefore, unless your CGIs data files are 777 then they cannot be written to. I have been told there will be a hotfix out very shortly. Fingers crossed.

 

[brooks]

Hmm, so this is only an Apache 2 issue? I'm not sure for which OSes Apache 1 vs. Apache 2 is supported. Here's what I do know:

RH 7.3 - Apache 1.x
RH ES - Apache 2.x

So, the simple fix would be to add:

<IfModule mod_suexec.c>
SuexecUserGroup USER psacln
</IfModule>

to your vhost.conf and vhost_ssl.conf files, replacing "USER" with the actual user name of the owner of virtual host . Once a fix is released you will need to then go through and delete any *.conf file that are no longer needed.

It really amazes me how these simple things ever get by testing. But, having worked in some of the larger software companies, with significant resources dedicated to testing, I know it's not uncommon.

 

[Pagemakers]

This is what plesk told me this morning:

Sorry for the mess. It seems it's complitely our fault and our development is working on this issue. This should be fixed in one of nearest patches.

The real problem is that there is no 'SuexecUserGroup' directive in /home/httpd/vhosts/*/comf/httpd.include apache config filesthat allows apache to execute scripts with the correct permissions, namely ('ftpuser','psacln').


Well, at least they have found the problem and they are working on it.