Anoop P Alias

Well-Known Member
Mar 31, 2015
103
16
18
Kochi,Kerala,India
cPanel Access Level
Root Administrator

plesk4lyf

Active Member
PartnerNOC
May 21, 2018
38
7
8
Sydney
cPanel Access Level
Root Administrator
Hi Anoop,

Although the script hook method is deprecated, they are still working and I've been using without an issue:

Guide to Standardized Hooks - Script Hooks - Developer Documentation - cPanel Documentation

/scripts/restoreacct
The /scripts/restoreacct script's hooks trigger each time that the system restores an account.

pre hook script:

/scripts/prerestoreacct

This script accepts the following arguments:

  • cpuser — The account's new (local) username.
  • olduser — The account's old (remote) username.
  • extractdir — The directory to which the system will extract the cpmove file.
post hook script:

/scripts/postrestoreacct

This script accepts the following arguments:

  • user — The account's new (local) username.
  • olduser — The account's old (remote) username.
  • domain — The account's main domain.
  • user_homedir — The absolute path to the account's home directory.
Just place a script that bash can execute. Here's an example if you want to test it:

1. Make a file /scripts/postrestoreacct

2. Put in it:
#!/bin/bash

ARRAY=([email protected])
ARRAYLENGTH=${#ARRAY[@]}
for (( ARG=0 ; ARG < $ARRAYLENGTH ; ARG++ ))
do

echo "ARG$ARG=${ARRAY[$ARG]}"

done

3. chmod it to execute:
chmod +x /scripts/postrestoreacct

4. Restore a test account

If done correctly, you should see in the output of the restore log

[ 7511][RESTORE:1 ][A:demouser ]: Progress: 79% (2019-02-27 04:42:23 +0000)
[ 7511][RESTORE:1 ][A:demouser ]: PostRestoreActions
[ 7511][RESTORE:1 ][A:demouser ]: Updating Caches …
[ 7511][RESTORE:1 ][A:demouser ]: Enabling IPv6 for account …
[ 7511][RESTORE:1 ][A:demouser ]: Updating Nameserver IP Address Report
[ 7511][RESTORE:1 ][A:demouser ]: Syncing contact information
[ 7511][RESTORE:1 ][A:demouser ]: Running postrestore script
[ 7511][RESTORE:1 ][A:demouser ]: ARG0=demouser
[ 7511][RESTORE:1 ][A:demouser ]: ARG1=demouser
[ 7511][RESTORE:1 ][A:demouser ]: ARG2=demowebsite.com
[ 7511][RESTORE:1 ][A:demouser ]: ARG3=/home/demouser

[ 7511][RESTORE:1 ][A:demouser ]: PostRestoreActions

Knowing the argument positions to the script, you can do simple things to trigger on restore, like change a theme:
uapi --user="$1" Styles update type=default name=basic

Or set to the system version of PHP:
whmapi1 php_set_vhost_versions version=inherit vhost-0="$3"
 

cPanelLauren

Product Owner II
Staff member
Nov 14, 2017
13,274
1,296
313
Houston
As indicated by @plesk4lyf the hooks system is really the way to go and if the event isn't hookable you can create a hookable event Guide to Standardized Hooks - Hookable Events in Custom Modules - Developer Documentation - cPanel Documentation though I wouldn't use the script hooks as they are deprecated. They are still usable at this time though.

The whostmgr functions would be what you want to look at Guide to Standardized Hooks - Whostmgr Functions - Developer Documentation - cPanel Documentation
 

santrix

Well-Known Member
Nov 30, 2008
229
3
68
Dear cPanel

I think you simply cannot compare the simplicity of /scripts/postrestoreacct with the new standardized hooks system, and there is also no way currently to replicate its behaviour using the hooks system. While /scripts/postrestoreacct doesn't discriminate between restored and transferred accounts it is sublimely simple to use.

Consider the case where you wish to do something immediately after EACH account in a large account transfer job has finished being transferred - say, add custom DNS records. There is no trivial way to detect this event using the standardized hooks and certainly no event triggered way.

You have to register a script with the Transfers::Session hook and then find .data.session_details.sessionid from that and then use fetch_transfer_session_log to read the master.log and then search that for all events where contents.action == start and contents.queue == RESTORE and grab the contents.local_item value - this just allows you to enumerate all of the cpanel accounts that were part of the transfer - but you won't be able to do any of this until AFTER the whole transfer session has ended - which might be hours after the first account is transferred. No good.

The only way to speed things along during the transfer session is to repeatedly search the master log of the transfer session looking for lines containing contents.action == [finish or whatever undocumented value signifies an account has finished transferring, if there is one, because you haven't documented it] and contents.queue == RESTORE and grab the contents.local_item values as you go - which is messy, and not event triggered.

This is so insanely over the top for most people who buy a cPanel license I can't believe this is what you're expecting people to do instead of simple adding one line to /scripts/postrestoreacct

What is needed here is a hook, say Transfers::Account - with a pre and post phase that just passes the details of the actual cpanel account that is being transferred AT THAT TIME.
 
Last edited: