beerco

Member
Nov 25, 2005
5
0
151
cpaddons_report.pl

in this file only the cpanel list of addons is displayed to distribute to virtual sites

sub _get_available_hashref {
eval q{require "/usr/local/cpanel/cpaddons/cPAddonsAvailable.pm";};
if ($@) {
print
"<p>Sorry - The list of available addons could not be found or fetched!</p> <!-- $@ -->\n";
%cPAddonsAvailable::list = ();
}
return \%cPAddonsAvailable::list;
}

/usr/local/cpanel/cpaddons/cPAddonsAvailable.pm is hard coded. But in your documentation

http://www.cpanel.net/docs/cpaddons/Distributing_Your_Addons.htm

/usr/local/cpanel/cpaddons/cPAddonsAvailable/Vendor.pm
/usr/local/cpanel/cpaddons/cPAddonsAvailable/*

is the directory for 3rd party scripts. Even if you get the 3rd party script right and the sync server it never shows up in the "Manage cPAddon Scripts" section because of this bug, forcing you to overwrite cPAddonsAvailable.pm and other cPanel configuration files with a 3rd party RPM.

I will have to overwrite the config files with our RPM because of this error to properly install our 3rd party software.

I will possibly have to install an /etc/init.d daemon to make sure cPanel doesn't overwrite the software installed by our rpm.

Please fix this so that I can take less extereme measures in the future. For now I will make an RPM to overwite the cPanel files and a daemon to make sure cPanel never interferes with our software. That's all I can do to insure that our software runs properly in light of this half finished framework.
 
Last edited:

beerco

Member
Nov 25, 2005
5
0
151
Here is my hack so cPanel can't break our app.

vi /usr/local/cpanel/whostmgr/docroot/cgi/cpaddons_report.pl

sub _get_available_hashref {
eval q{require "/usr/local/cpanel/cpaddons/cPAddonsAvailable.pm";};
if ($@) {
print
"<p>Sorry - The list of available addons could not be found or fetched!</p> <!-- $@ -->\n";
%cPAddonsAvailable::list = ();
}
eval q{require "/usr/local/cpanel/cpaddons/beercoExtra.pm";};
return \%cPAddonsAvailable::list;
}

vi /usr/local/cpanel/cpaddons/beercoExtra.pm

use cPAddonsAvailable;

$cPAddonsAvailable::list{'beerco::Email::phpmail'} = {
'security_rank' => 5,
'VERSION' => '0.1',
'version' => '3.1.1',
};


I shouldn't have to do this. The path to cPanel addons should not be hard coded. Can you imagine if the path to httpd.conf was the only one hard coded and there was no conf.d for additional info? It's supposed to transverse the directories and scan for configuration files. I guess somebody forgot to do that. But it says it works in the cPanel docs and it doesn't. Perhaps if cPanel could make their software work to it's own SDK specs, perhaps people would want to integrate more with it. This is just sloppy.
 

beerco

Member
Nov 25, 2005
5
0
151
If our RPM runs a diff patch on /usr/local/cpanel/whostmgr/docroot/cgi/cpaddons_report.pl

in the %post section of the .spec file, which means post rpm install, will cpanel attempt to overwrite /usr/local/cpanel/whostmgr/docroot/cgi/cpaddons_report.pl at a later time?

In other words, if our RPM patches the mistake only for our customers, will cpanel clobber it?

That's all I need to know. If not it will be fine. If so I will have to have the RPM install a file monitoring daemon to repatch automatically should cpanel try to clobber the change.

Please, somebody with the answer let me know.

I will post this issue in bugzilla. But I can not avoid the fact that all cpanel users right now DO NOT have that patched. I will still have to do it this way, patching the cpaddons_report.pl with our RPM.

It tells you to make your own namespace and put it in a vendor directory, then it ignores all vendor directories except for cPanel's which is in the main dir (/usr/local/cpanel/cpaddons/cPAddonsAvailable.pm) and doesn't even follow the convention that they put out. ???

EDIT:

The bugzilla entry for this bug can be found here:
http://bugzilla.cpanel.net/show_bug.cgi?id=4548
 
Last edited: