|
|
|
|
This step is optional. Notice it if you need to extend parameter input handling (that performs with permissions of Domain User) with actions that require permissions of System Administrator. E.g. being installed, web applications often require creating folders on the domain first, or they may require adding/changing records in a database, setting user permissions, and so on, during the install procedure or reconfiguring. All these actions require permissions of System Administrator.
To help overcome the limitation with Domain User permissions, Plesk provides support for several script files, each having a fixed name and reserved for a certain task. The names of the script files supported by Plesk are defined in its sapp_constants.php file as follows:
define('SITEAPP_SCRIPT_PREINSTALL', 'preinstall');
define('SITEAPP_SCRIPT_POSTINSTALL', 'postinstall');
define('SITEAPP_SCRIPT_PREUNINSTALL', 'preuninstall');
define('SITEAPP_SCRIPT_POSTUNINSTALL', 'postuninstall');
define('SITEAPP_SCRIPT_RECONFIGURE', 'reconfigure');
These script files can be created as UNIX shell scenarios, or they can be written in any scripting language (e.g. Perl) on condition that a relevant interpreter is installed in the system and allows file execution from CLI.
To use a reserved script when handling parameters, the developer should create it, give it a predefined name, and add it to the /scripts folder of the installation package. This guarantees that the script will be called by Plesk at a proper moment during the relevant procedure. To learn more about the tasks assigned to each reserved script as well as about the moment these scripts are executed, pass to the Scripts folder topic of the Installation package section in Reference.
A typical script file includes four kinds of operations, that is:
The passed in parameters enter a script as a string formatted as follows:
"param1=value1;param2=value2;param3=value3..."
First this string needs to be parsed and defragmented into pairs like:
<parameter_name>=<parameter_value>
Here is the example of a valid Perl code extracting parameters from a standard input stream:
#!/usr/bin/perl -w
…
my @imp_params = qw( vhost_path domain_name install_prefix ssl_target_directory admin_login admin_passwd );
Later on, these parameters are checked. Here is the code snippet that demonstrates this checkup:
#!/usr/bin/perl –w
…
my %params;
…
sub check_parameter
{
my ($param) = @_;
unless (defined $params{$param}){
return 0;
} else {
return 1;
}
}
Next comes the block of code responsible for various low-level (system) operations. E.g., the following code snippet specifies the installation path by which the web application will be installed on the domain:
#!/usr/bin/perl –w
… … …
my $proto;
my $documents_directory;
if ($params{'ssl_target_directory'} eq 'true'){
$documents_directory = 'httpsdocs';
$proto = 'https://';
} else {
$documents_directory = 'httpdocs';
$proto = 'http://';
}
After all low-level operations are described, the script must return its exit status. A script returns a zero value if its execution has been successful. A non-zero exit status indicates an error condition of some sort.
Please find the examples of valid script files preinstall, postinstall, reconfigure, and preuninstall in the Code samples section of this documentation.
Thus, this step should result in creating some reserved scripts (if needed) and in adding them to the /scripts folder of the installation package.
