postwwwacct & cpanel11

[mr2jzgte]

Hi Guys,

On our cp11 dev box, we've noticed that postwwwacct doesn't seem to be working via the webinterface - It's called when you run /scripts/wwwacct but not when run it via whmgr

We have a number of custom commands that we HAVE to run in order to create the accounts on the NFS server and set quotas etc..

This is a big problem for us. From doing traces, and auditing the file system it looks like /scripts/wwwacct is no longer called via the webinterface (guessing it's internal now?)

We need a resolution to this asap.
WHM 11.1.0 cPanel 11.2.5-C11736

Bug 5360

I've been authorised to offer $USD500 to cpanel for immediate resolution of this issue.

**More details**
The postwwwacct statement is still contained in cpanel code - in the create.pm module, how ever it appears when creating a user via whmgr it doesn't utilise the individual perl modules.

Regards
James

 

[cPanelKenneth]

As mentioned in the response to your bug report about this, please verify your postwwwacct script is compatible with cPanel 11.

For example if you run the script manually from the command line, does it return erros about missing perl modules and such?

Also, make certain you are using the latest version of cPanel 11. If you have any specific errors to share, please place them in the bug report as that will help us determine what is wrong as the functionality is working on our test servers.

Thank you.

 

[mr2jzgte]

The script we were calling was the following - just for testing

#!/usr/bin/perl
open(ACCTNIS,">/tmp/blah");
close(ACCTNIS);

Up until 5am this morning (+8) when upcp ran again, the postwwwacct functionality was broken..

Confirmed by running auditd over /scripts (lets you see what access files etc)

This afternoon when I got round to testing it again, the script ran perfectly and created the file, as well as appearing in the audit logs.

For reference I ran upcp several times prior to posting the request for help & bug report.

Also it appears the arguments have changed in the new version compared to cp10 - can you confirm this.

 

[bazzi]

Hi There,

I have the same problem.

The scripts are correct, but it seams that the problem lies in the ARGV[0] and so one...

We used to use this one:

# Here are the variables that are passed to this script:
# $ARGV[0] = domain
# $ARGV[1] = username
# $ARGV[2] = password
# $ARGV[3] = space (MB)
# $ARGV[4] = theme
# $ARGV[5] = ded IP (y/n)
# $ARGV[6] = cgi (y/n)
# $ARGV[7] = FP (y/n)
# $ARGV[8] = max ftp (n or #)
# $ARGV[9] = max sql (n or #)
# $ARGV[10] = max POP (n or #)
# $ARGV[11] = max lists (n or #)
# $ARGV[12] = max subs (n or #)
# $ARGV[13] = bandwidth (# or 0) in MB's
# $ARGV[14] = shell (y/n)
# $ARGV[15] = owner
# $ARGV[16] = plan
# $ARGV[17] = max park (# or unlimited)
# $ARGV[18] = max addon (# or unlimited)
# $ARGV[19] = feature list (default)
# $ARGV[20] = contact email


Is there something changed so we need to rescript all our postuserwww scripts?

 

[mr2jzgte]

Yup, they've fixed the problem I was having... but yes the arguments have changed...

there's now 48 from memory...

i.e arg[0] = the field name
arg[1] = the field value..


Use the following code, and you can figure it out for yourself

it'll print the field name and value next to it.. hope this helps, but yes, in short, you all have to rescript the existing postwwwacct scripts

#!/usr/bin/perl
open(INFO,">/tmp/args");
print INFO "$ARGV[0] ";
print INFO "$ARGV[1] 1\n";
print INFO "$ARGV[2] ";
print INFO "$ARGV[3] 3\n";
print INFO "$ARGV[4] ";
print INFO "$ARGV[5] 5\n";
print INFO "$ARGV[6] ";
print INFO "$ARGV[7] 7\n";
print INFO "$ARGV[8] ";
print INFO "$ARGV[9] 9\n";
print INFO "$ARGV[10] ";
print INFO "$ARGV[11] 11\n";
print INFO "$ARGV[12] ";
print INFO "$ARGV[13] 13\n";
print INFO "$ARGV[14] ";
print INFO "$ARGV[15] 15\n";
print INFO "$ARGV[16] ";
print INFO "$ARGV[17] 17\n";
print INFO "$ARGV[18] ";
print INFO "$ARGV[19] 19\n";
print INFO "$ARGV[20] ";
print INFO "$ARGV[21] 21\n";
print INFO "$ARGV[22] ";
print INFO "$ARGV[23] 23\n";
print INFO "$ARGV[24] ";
print INFO "$ARGV[25] 25\n";
print INFO "$ARGV[26] ";
print INFO "$ARGV[27] 27\n";
print INFO "$ARGV[28] ";
print INFO "$ARGV[29] 29\n";
print INFO "$ARGV[30] ";
print INFO "$ARGV[31] 31\n";
print INFO "$ARGV[32] ";
print INFO "$ARGV[33] 33\n";
print INFO "$ARGV[34] ";
print INFO "$ARGV[35] 35\n";
print INFO "$ARGV[36] ";
print INFO "$ARGV[37] 37\n";
print INFO "$ARGV[38] ";
print INFO "$ARGV[39] 39\n";
print INFO "$ARGV[40] ";
print INFO "$ARGV[41] 41\n";
print INFO "$ARGV[42] ";
print INFO "$ARGV[43] 43\n";
print INFO "$ARGV[44] ";
print INFO "$ARGV[45] 45\n";
print INFO "$ARGV[46] ";
print INFO "$ARGV[47] 47\n";
print INFO "$ARGV[48] ";
print INFO "$ARGV[49] 49\n";
close(INFO);

 

[cPanelDavidG]

I would recommend that for a degree of future-proofing, instead of directly hacking into the /scripts files - you use the cPanel APIs such as the XML API for cPanel 11. Documentation is available at:

http://www.cpanel.net/plugins/xmlapi/index.html

Try to avoid using /scripts hacks and kludges when APIs are available that do the job.

 

[bazzi]

thanks....

Hmmm I am not very happy with this...

But thanks for the script! We will script our postwwwact again and I will post some of them here, so other persons doesn't have to do it also...

 

[bazzi]

I would recommend that for a degree of future-proofing, instead of directly hacking into the /scripts files - you use the cPanel APIs such as the XML API for cPanel 11. Documentation is available at:

http://www.cpanel.net/plugins/xmlapi/index.html

Try to avoid using /scripts hacks and kludges when APIs are available that do the job.

OK, I had a quicklook at the documents, but I only see ways to make accounts, not do the same as a postwwwact, or am I looking completly over it?

 

[cPanelDavidG]

OK, I had a quicklook at the documents, but I only see ways to make accounts, not do the same as a postwwwact, or am I looking completly over it?

Well I couldn't help but notice that most of the original 28 parameters of postwww presented in a previous post on this thread are found in the creatacct function in the XML API:

http://www.cpanel.net/plugins/xmlapi/createacct.html

 

[bazzi]

Well I couldn't help but notice that most of the original 28 parameters of postwww presented in a previous post on this thread are found in the creatacct function in the XML API:

http://www.cpanel.net/plugins/xmlapi/createacct.html

true, but than I NEED to use the xml-api to get the xml parameters AND create the account, rigth?
So I can't use the current "Create a new account" in WHM... So you get my point?
There isn't a xml-api to take over the current postwwwact files...

Or am I completly wrong?

 

[rejected]

XML Api

In relation to the XML API is there a Perl module on the server we can then edit to add specific arguments to the keys what are parsed to httptemplate as we do not use mod_bwlimited for our Bandwith functions we are using mod_cband.

 

[cPanelDavidG]

true, but than I NEED to use the xml-api to get the xml parameters AND create the account, rigth?
So I can't use the current "Create a new account" in WHM... So you get my point?
There isn't a xml-api to take over the current postwwwact files...

Or am I completly wrong?

You are free to use whatever account creation method you want. Using an API (either the XML API or the older/cruder WHM API) does not prevent you from using the "Create a new account" feature in WHM or vice-versa.

What precisely is the functionality you are looking for that you believe is in postwwwact and not in createacct in the XML API?

 

[brianoz]

You are free to use whatever account creation method you want. Using an API (either the XML API or the older/cruder WHM API) does not prevent you from using the "Create a new account" feature in WHM or vice-versa.

What precisely is the functionality you are looking for that you believe is in postwwwact and not in createacct in the XML API?

David,

I'm confused as to why you'd even ask that, perhaps I'm missing something?

The postwwwacct feature is a hook for running a script just after an account is created. It is used for extra configuration steps, for instance, installing software dependent on their package.

Createacct (in XML API, old crude form, or as called from WHM) as you know is used for creating accounts.

These two are simply different animals and not directly related. Sure, I can call the API to create an account then take various actions post creation to emulate postwwwacct, but that doesn't help me when my billing system creates an account, or a staff member does it through WHM, I then end up with an account setup in a "broken" state as my software isn't installed.

For instance, if an account with a certain package name is installed, we enable anti-virus software for that domain. If an account with a package name containing a certain string (eg "soho" as in "soho_100mb") is installed, my postwwwacct loads and configures soholaunch ready to go.

Edited: Just realize you understand that and are asking a different question - sorry! Leaving the post as the clarification might be useful for others!

 

[rejected]

XML Api

brianoz I do have a feeling that you could modify the actual creation modules (/usr/local/cpanel/WhostMgr/Accounts/Create.pm) and hook your scripts in there but that is not called when creating via WHM and I have not tested this on the XML API

 

[cPanelNick]

With 11.2.9 you have the following options:

postwwwacct (send arguments in a hash) --- This is the new and PREFERRED way as there will be a lot more data passed in the future and this is much better way to handle it.
Example:
'plan' => 'undefined',
'maxpark' => '0',
'hasshell' => 'y',
'maxlst' => 'n',
'maxpop' => 'n',
'maxaddon' => '0',
'cpmod' => 'x',
'pass' => 'fdfd',
'maxsub' => 'n',
'domain' => 'dummy.org',
'maxsql' => 'n',
'quota' => '0',
'installfp' => 'y',
'maxftp' => 'n',
'contactemail' => '',
'hascgi' => 'y',
'user' => 'dummyor',
'useip' => 'n',
'useregns' => '0',
'bwlimit' => '0',
'forcedns' => '0',
'owner' => 'root',
'featurelist' => 'default'

Expected way to access data:
perl: my %OPTS = @ARGV;
access via $OPTS{'user'}, $OPTS{'domain'} etc
php (little bit more work, but easier in the long run):
<?php
$opts = array();
$argv0 = array_shift($argv);
while(count($argv)) {
$key = array_shift($argv);
$value = array_shift($argv);
$opts[$key] = $value;
}
?>
Then you can access
$opts['user'], $opts['domain'], $opts['quota], etc
===

legacywwwacct (sends arguments as an array):
Example:
'dummy.org',
'dummyor',
'fdfd',
'0',
'x',
'n',
'y',
'y',
'n',
'n',
'n',
'n',
'n',
'0',
'y',
'root',
'undefined',
'0',
'0',
'default',
'',
'0',
'0'

Expected way to access data:
perl: my @OPTS = @ARGV;
access via $OPTS[0] (domain) , $OPTS[1] (user)

php:
access via $argv[1] (domain), $argv[2] (user) etc

Here is how its run from whm/wwwacct:
'/scripts/legacypostwwwacct', $OPTS{'domain'}, $OPTS{'user'}, $OPTS{'pass'},
$OPTS{'quota'}, $OPTS{'cpmod'}, $OPTS{'useip'}, $OPTS{'hascgi'}, $OPTS{'installfp'},
$OPTS{'maxftp'}, $OPTS{'maxsql'}, $OPTS{'maxpop'}, $OPTS{'maxlst'}, $OPTS{'maxsub'},
$OPTS{'bwlimit'}, $OPTS{'hasshell'}, $OPTS{'owner'}, $OPTS{'plan'}, $OPTS{'maxpark'},
$OPTS{'maxaddon'}, $OPTS{'featurelist'}, $OPTS{'contactemail'}, $OPTS{'forcedns'},
$OPTS{'useregns'}

===
postwwwacctuser (sends only the new username) :

Example:
'dummyor'

Expected way to access data:
perl: my $user = $ARGV[0];

php: $user = $argv[1];


====
Few other post scripts that might be useful (although these don't have args to parse except for the suspend & kill acct ones)
postcpbackup
postupcp
postftpinstall
postexim4install
postcourierinstall
postbuildapache
postmysqlinstall
postsuspendacct <user> <reason>
postunsuspendacct <user>
postkillacct HASH (make sure to parse as a hash because keepdns or user could change order) --- user <user> keepdns <keepdns>
legacypostkillacct <user> <keepdns>

 

[cPanelDavidG]

Edited: Just realize you understand that and are asking a different question - sorry! Leaving the post as the clarification might be useful for others!

No problem, thanks for the clarification .

I thought we were discussing using postwww to create accounts, rather than also using it as a hook to detect when accounts are created regardless of what created them. Hence my confusion.

I agree, the API does not yet by itself have the capability of noticing the creation of new accounts created by other scripts/applications. Sorry about my confusion, I was confused as to what functionality you were looking for.

 

[Quizboy]

Please, think like a NEWBIE when making help docs!

I would recommend that for a degree of future-proofing, instead of directly hacking into the /scripts files - you use the cPanel APIs such as the XML API for cPanel 11. Documentation is available at:

http://www.cpanel.net/plugins/xmlapi/index.html

Try to avoid using /scripts hacks and kludges when APIs are available that do the job.

This
"help" page is just so abstract for someone wanting to make use of XML API for the first time. Thus, me!

The help talks about all kinds of parameters that can be sent in, but sent into where??? Unfortunately there's no explanation of how the connection can be made to the script (or what script for that matter), in order to start using the parameters.

Am I making a URL with all the parameters attached? If so what's the basis of htat url? Or Am I making a terminal connection? I just don't get it, and the docs provided make no attempt to explain that.

I'm using WHM 11.1.0 cPanel 11.2.12-C12180
FEDORA 2 i686 - WHM X v3.1.0
and I've tried to create an account by dropping the following urls into a browser:

http://{$whm_user}:{$whm_pass}@{$whm_host}:2086/scripts/wwwacct?plan={$user_plan}&domain={$user_domain}&username={$user_name}&password={$user_pass}&contactemail={$user_email}

which in my specific case translates to:
http://root: ***my root password*** @dinkuhosting.com:2086/scripts/wwwacct?plan=DinkuDomain&domain=xinxinxin.nl&username=xinxinxi&password=password&[email protected]

Which gave a me FILE NOT FOUND error. So then I copied the accounting.php.inc file to a public_html/ directory and tried the following two urls, and got the same FILE NOT FOUND error:

http://root:***my root password***@dinkuhosting.com:2086/accounting.php.inc?plan=DinkuDomain&domain=xinxinxin.nl&username=xinxinxi&password=password&[email protected]

http://root:***my root password***@dinkuhosting.com/accounting.php.inc?plan=DinkuDomain&domain=xinxinxin.nl&username=xinxinxi&password=password&[email protected]

Could someone please go back to the ultra basics...I mean step 1, and explain how the XML API is used...in layman's terms. Before getting into all these parameters and what not, what do I need to connect to, and how do I connect to it?

 

[DaveUsedToWorkHere]

You'll need to call the XML API as explained in http://www.cpanel.net/plugins/xmlapi/XMLAPI.html

Note that you need to call with https://domain.com:2087/xml-api/functionname as shown in the XML API examples for each function.

 

[brianoz]

...

Few other post scripts that might be useful (although these don't have args to parse except for the suspend & kill acct ones)
postcpbackup
postupcp
postftpinstall
postexim4install
postcourierinstall
postbuildapache
postmysqlinstall
postsuspendacct <user> <reason>
postunsuspendacct <user>
postkillacct HASH (make sure to parse as a hash because keepdns or user could change order) --- user <user> keepdns <keepdns>
legacypostkillacct <user> <keepdns>

It would also be really useful if we had a few pre scripts as well - prewwwacct would be great. The reason I want this is to prevent spammer domains being hosted - I'd do a live check against SURIBL (sp?) and other similar sources to see if it was a domain currently used in spam. If the script returns an error (non-zero) status the account creation should terminate.

As another example, I'd also love prekillacct so it can do a pkgacct $acct /backup/deleted/ of the account, thus making sure I have a delete-time backup of all deleted accounts.

 

[cPanelDavidG]

You'll need to call the XML API as explained in http://www.cpanel.net/plugins/xmlapi/XMLAPI.html

Note that you need to call with https://domain.com:2087/xml-api/functionname as shown in the XML API examples for each function.

Agreed, this is a great place to start.

I'll also be performing a presentation about the XML API and how to use it at our Training Seminar. Just figured I'd throw that out there for those who may be considering attending.