Plesk Modules

Copyright Notice
ISBN: N/A
SWsoft.
13755 Sunrise Valley Drive
Suite 325
Herndon
VA 20171 USA
Phone: +1 (703) 815 5670
Fax: +1 (703) 815 5675

© Copyright 1999-2007,
SWsoft Holdings, Ltd.
All rights reserved

Distribution of this work or derivative of this work in any form is prohibited unless prior written
permission is obtained from the copyright holder.

Patented hosting technology protected by U.S.Patents 7,099,948; 7,076,633.
Patents pending in the U.S.Linux is a registered trademark of Linus Torvalds.

ASPLinux and the ASPLinux logo are registered trademarks of SWsoft.
RedHat is a registered trademark of Red Hat Software, Inc.
Solaris is a registered trademark of Sun Microsystems, Inc.
X Window System is a registered trademark of X Consortium, Inc.
UNIX is a registered trademark of The Open Group.
Intel, Pentium, and Celeron are registered trademarks of Intel Corporation.
MS Windows, Windows 2003 Server, Windows XP, Windows 2000, Windows NT, Windows 98,
and Windows 95 are registered trademarks of Microsoft Corporation.
IBM DB2 is a registered trademark of International Business Machines Corp.
SSH and Secure Shell are trademarks of SSH Communications Security, Inc.
MegaRAID is a registered trademark of American Megatrends, Inc.
PowerEdge is a trademark of Dell Computer Corporation.
Request Tracker is a trademark of Best Practical Solutions, LLC
All other trademarks and copyrights referred to are the property of their respective owners.

3

Contents

Preface 5
Who Should Read This Guide ................................................................................................... 5
About This Guide ...................................................................................................................... 5
Typographical Conventions ....................................................................................................... 6
Feedback .................................................................................................................................. 6

Basics 7
Overview................................................................................................................................... 7
Logical Module Structure........................................................................................................... 9
Module Front-end Part................................................................................................... 10
Module Back-end Part ................................................................................................... 10
Resource Files .............................................................................................................. 10
Install and Uninstall Scripts............................................................................................ 10
Third-party Code ........................................................................................................... 10
Physical Module Structure ....................................................................................................... 11
admin/bin Folder ........................................................................................................... 12
admin/htdocs Folder ...................................................................................................... 12
admin/plib Folder ........................................................................................................... 13
admin/sbin Folder .......................................................................................................... 14
admin/conf Folder.......................................................................................................... 14
Interaction Between Plesk and Modules .................................................................................. 15
Plesk Internal API.......................................................................................................... 15
Registering Implementation of Interface ......................................................................... 16
Plesk External API......................................................................................................... 17
Comparison Between External and Internal API............................................................. 17
Plesk Module Manager .................................................................................................. 17

Implementation and Samples 19
Designing GUI of Module ........................................................................................................ 19
Plesk Modules API ........................................................................................................ 20
Entry Point to GUI ......................................................................................................... 21
Creating PHP Forms (Requirements and Recommendations) ........................................ 21
Utilizing FastTemplate Technology ................................................................................ 22
Implementing Module Help System ......................................................................................... 24
Creating Single-language Help ...................................................................................... 24
Creating Multi-language Help ........................................................................................ 25
Binding Help Files with Forms ....................................................................................... 25
Localizing Module ................................................................................................................... 26
Creating Localization Files............................................................................................. 26
How Localization Works ................................................................................................ 27
Creating Module Front-end Part .............................................................................................. 27
Implementing Event Listeners ................................................................................................. 29
Customizing system settings for the module ............................................................................ 29
Using Mail Handlers with qMail................................................................................................ 30
Using Pluggable Antivirus Filters ............................................................................................. 31

Creating Distribution Package 33

Preface 4

Creating Install and Uninstall Scripts ....................................................................................... 33
Creating an RPM package ...................................................................................................... 36
Creating an SH package ......................................................................................................... 37
Creating a DEB package ......................................................................................................... 40

5

CHAP TER 1

Preface

In this section:
Who Should Read This Guide ........................................................................ 5
About This Guide........................................................................................... 5
Typographical Conventions ............................................................................ 6
Feedback ...................................................................................................... 6

Who Should Read This Guide
This guide is devoted to the developers who plan to do the following:
 Extend the administering functionality of Plesk 'on the spot', without issuing a new
version of Plesk
 Link Plesk with additional applications or services using simple install and
registration procedure

About This Guide
This guide is meant to provide necessary information on Plesk modules - a kind of
plug-ins built into Plesk and providing access to its own functionality or to the
functionality of an external service from Plesk Control Panel.

Chapter Basics presents the plug-in technology of Plesk. This part of documentation
explains the tenets of Plesk modules architecture.

Chapter Implementation and Samples focuses on the details of module implementation
and touches upon the facilities provided by Plesk for better integration with Plesk
modules.

Chapter Creating Distribution Package explains how to create a module distribution
package ready for commercial use.

Preface 6

Typographical Conventions
The following kinds of formatting in the text identify special information.

Formatting convention Type of Information Example
Special Bold Items you must select, such as Go to the QoS tab.
menu options, command
buttons, or items in a list.
Titles of chapters, sections, Read the Basic Administration
and subsections. chapter.
Italics Used to emphasize the The system supports the so
importance of a point, to called wildcard character
introduce a term or to search.
designate a command line
placeholder, which is to be
replaced with a real name or
value.
Monospace The names of style sheet The license file is located in the
selectors, files and directories, httpdocs/common/license
and CSS fragments. directory.
Preformatted On-screen computer output in # ls –al /files
your command-line sessions; total 14470
source code in XML, C++, or
other programming languages.
Preformatted Bold What you type, contrasted with # cd /root/rpms/php
on-screen computer output.

Feedback
If you have found a mistake in this guide, or if you have suggestions or ideas on how to
improve this guide, please send your feedback to userdocs@swsoft.com. Please
include in your report the guide's title, chapter and section titles, and the fragment of
text in which you have found an error.

7

CHAP TER 2

Basics
This chapter states the concepts of Plesk plug-in technology known as Plesk Modules:
 The Overview section shows the purpose of modules in Plesk architecture, explains
the difference between modules and other ways of extending the logic of Plesk, and
shows why modules are more useful for the customer.
 The How a Module Builds into Plesk Architecture section gives a common idea of
what a module presents, how it is structured, and how this structure mounts in the
file and folder structure of Plesk.
 The Plesk Modules Support Architecture section explains how Plesk supports
modules and what internal mechanisms of Plesk are involved. This section
specifies the boundary between the area of Plesk support and the area of the
module’s activity (with regard to each operation that can be performed against the
module).

In this section:
Overview ....................................................................................................... 7
Logical Module Structure ............................................................................... 9
Physical Module Structure ............................................................................. 11
Interaction Between Plesk and Modules ......................................................... 15

Overview
Plesk provides the mechanism of extending its base functionality with additional
modules. A module is a kind of plug-in built into Plesk and providing access to its own
functionality or to the functionality of an external service from Plesk Control Panel
(PCP).

Purpose

The main advantage of Plesk is the opportunity to manage a wide range of functionality
from a single control panel. In this sense, integrating additional applications and
services with Plesk via the mechanism of modules gains benefit as follows:
 PCP provides means for installing/uninstalling modules easily
 modules integrate with Plesk Language system
 modules integrate with Plesk Help system
 modules use skins provided by Plesk
 Plesk provides Modules API specially designed to create Plesk-specific modules

Basics 8

 modules are registered in Plesk, which prevents from casual deletion of 'module'
applications

 a module installed in Plesk cannot be used from outside – it can be used from PCP
only

The extension technology used in Plesk creates an illusion of seamless interaction
between a module and Plesk: once embedded, the module will be displayed on PCP
along with native modules of Plesk. Nevertheless, a module is an autonomous software
unit. It can be installed independent of Plesk, it does not depend on Plesk
modifications, and Plesk does not depend on the module’s modifications either.

Where Applicable

The Plesk Modules technology extends Plesk with new administering facilities and
provides control of them from PCP. You need to create the code of the new
functionality, but it is not necessary to issue a new version of Plesk – the new
functionality will be just embedded into Plesk in the form of a module. Also, this
technology helps extend the logic of Plesk by integrating it with ready-made
applications or services. Integrated units become accessible from PCP.

There are several modules shipped with Plesk:
 Acronis TrueImage Server management module

 Battlefield 1942 Server Manager (a game server)

 Counter-Strike Game Server

 Samba Fileserver Configuration module

 Firewall

 Remote Admin for SiteBuilder

 Virtual Private Networking module (establishes secure connections on base of
standard channels)

 Watchdog (monitoring of Plesk Control Panel services)

Basics 9

Logical Module Structure
Custom modules that serve as Plesk extensions and can provide their own GUI and
logic. They can be added to Plesk and removed from it when necessary, thus
presenting independent extension units of Plesk.

A module consists of the following parts:

Figure 1: Logical structure of a module
 Front-end part (on page 9)
 Back-end part (on page 10)
 Resource files (on page 10)
 Install and uninstall scripts (on page 10)
 Third-party code (on page 10)
The figure also shows references between Plesk and the module. The front -end part
communicates with Plesk GUI, and Plesk Internal and External API. For info on the
API, refer to the Interaction Between Plesk and Modules (on page 15) section.

Module Manager tool from Plesk GUI controls install and uninstall scripts of the
module. For details, refer to the Plesk Module Manager (on page 17) section.

Basics 10

Module Front-end Part
This part of a module is always present. It is responsible for interaction between Plesk
and module core functionality. Front-end part of the module can process Plesk forms
data, interact with Plesk interfaces, display the module GUI, send data to third-party
utility located outside Plesk, and do other tasks implemented in PHP files.

File types: PHP files, configuration files.

Module Back-end Part
This part makes up the core of the module. It is optional, because you can use a
remote service that implements the required functionality. The back-end code is
integrated with Plesk by the front-end part of a module.

Typical back-end files are executables, dynamic libraries, scripts, or a combination of
them. They can perform low-level (system) operations to data coming from front-end
part, communicate with databases, use UNIX shell, or change system settings for
smooth execution of the module.

File types: PHP script files, C utilities, configuration files.

Resource Files
This part of a module includes GUI icons, images, help files, localization files,
templates or static HTML pages.

File types: GIF, HTML, PHP (localization files), and TPL (templates) files.

Install and Uninstall Scripts
These scripts are included in the RPM/SH/DEB distribution package. They are
necessary for operations like creating/destroying database objects,
registering/unregistering the module package in a special table of Plesk database,
generating/destroying system objects (files, folders), and so on.

File types: executable script files.

Third-party Code
A module can provide access to a third-party service located on a remote server. Plesk
does not impose any restrictions on the code. If the module use remote core
functionality, back-end part of the module is optional. If the module uses only back-end
part as a core, the third-party code part is optional.

Basics 11

Physical Module Structure
Plesk allocates resources of installed modules in its file and folder hierarchy as shown
below.

<plesk_root_dir>/ This is the root directory of Plesk. Here
<plesk_root_dir> stands for the full path to the
directory where Plesk is installed. In UNIX, this path is
normally /usr/local/psa. In Debian, it is /opt/psa.

admin/ This folder is meant to store everything required for
module administering. Namely, this folder contains PHP,
binary and image files.

bin/ This folder stores back-end part of a module meant for
low-level (system) operations (normally, compiled C
programs). Besides binary files, this folder stores symlinks
to binary utilities located in the sbin/ folder and executed
with setuid root privileges. To see the internal structure of
this folder, click here.

htdocs/ This folder stores front-end part as well as resource files,
e.g. HTML help files, icons displayed on navigation
buttons. To see the internal structure of this folder, click
here.

plib/ This directory stores PHP files used by front-end and
back-end part of the module. Also, the directory stores
resource files of the module, e.g. PHP localization files and
templates. To see the folders nested within this one, click
here.

sbin/ This folder stores back-end part of a module meant for
low-level operations on the system (normally, compiled C
programs) that should be executed with setuid root
privileges. Also, this folder contains a setuid root wrapper
utility meant for this task. To see the internal structure of
this folder, click here.

conf/ This folder contains the configuration file of Apache server
that runs Plesk. Also, this folder can contain special files
(one for an individual module) that modify this
configuration for a certain module. To see the internal
structure of this folder, click here.

var/ This folder is meant to store auxiliary files and components
of Plesk – log files, SSL certificates, etc. In case of
modules, this folder can contain the uninstall script for a
module wrapped into a SH distribution package.

Basics 12

admin/bin Folder

modules/ This Plesk folder contains a <module_name>
folder for each installed module.

<module_name>/ This folder stores binary utilities and symlinks of
a particular module.

This Plesk folder is meant to store binary files (executables, libraries, compiled C
programs) and symlinks of binaries located in folder
<plesk_root_dir>/admin/sbin.

Here a module can locate binaries referring to back-end part. Also, here the module
can store symlinks of the binaries that require setuid root privileges. These symlinks
reference the mod_wrapper utility of Plesk located in the
<plesk_root_dir>/admin/sbin folder beside the binaries that match the module’s
symlinks.

admin/htdocs Folder

This Plesk folder stores files somehow related with GUI, i.e. meant for the display in the
browser. A module locates its source files in this folder as follows.

modules/ This Plesk folder contains a
<module_name> folder for each
installed module.
<module_name>/ The folder stores PHP files that
define GUI of a certain module,
including the index.php file that
serves as an entry point to GUI of
a module. Also, this folder
contains the following nested
folders:
locales/ This is the ‘root’ folder for one or
several branches, each meant for
a certain locale.
<locale_name 1>/ This folder isolates help files
referring to the first supported
locale.

Basics 13

help/ The folder contains HTML help
files for this locale.
<locale_name 2>/ This folder isolates help files
referring to the second supported
locale.

…

<locale_name N>/ This folder isolates help files
referring to the N supported
locale.

images/ This folder stores GIF image files
(icons) of the module’s GUI.

admin/plib Folder
This directory stores PHP files used by front-end and back-end part of the module.
<module_name>/ This Plesk folder isolates a branch that stores
localization files for all installed modules in
the locales folder. Also, it stores the
locale.php file that ships with the module
and resolves the current locale of Plesk.
locales/ This folder can store localization files of two
types: messages_<locale_name>.php
stores error/warning messages and GUI text,
and conhelp_<locale_name>.php stores
context help messages. Each locale
supported by the module can have one or
both these files in this folder.
templates/ This Plesk folder isolates a branch storing
template files used by FastTemplate engine
to generate GUI pages.
<module_name>/ This folder contains TPL files (HTML
templates that define the layout of module
pages)

Basics 14

admin/sbin Folder

This Plesk folder is meant to store binary files (executables, libraries, compiled C
programs) having symlinks of the same name in folder
<plesk_root_dir>/admin/bin.

<module_name> This folder stores binary utilities of a particular
/ module.

Here a module can have binaries of its back-end part, that need to be executed with
setuid root privileges. These binaries should be located in this folder, as Plesk stores its
mod_wrapper utility here. This utility serves as a wrapper for module utilities.
Symlinks of setuid binaries reference this mod_wrapper utility, so when called via a
symlink, mod_wrapper finds a binary of the same name in the
<plesk_root_dir>/admin/sbin folder and executes it as a utility with root access
permissions.

admin/conf Folder

Plesk uses this folder to store the httpsd.conf configuration file. The settings set in
this file can be modified for a certain module if place the
httpsd.<module_name>.include configuration file for this module beside the main
file.

Basics 15

Interaction Between Plesk and Modules
This section describes Internal and External API used by Plesk for UNIX.

Plesk Internal API
The Internal API of Plesk for UNIX provides access to a part of core Plesk functionality.
Interfaces use PHP "interface" syntax.

Third-party developers can use Internal Plesk API by providing implementations of one
or more defined interfaces. The core can also provide base classes to facilitate
implementations of the interface.

Components using Internal Plesk API, might require implementation registration. Refer
to the Registering Implementation of Interface (on page 16) section for details.

Component is to be registered, if it uses the following interfaces:
 Event listener (on page 15)
 Pluggable antivirus filter (on page 15)
Component can use mail handlers to handle incoming and outgoing correspondence.
In this case the handlers should be registered in the Mail Manager utility (mailmng).
For implementation details, refer to the Using Mail handlers with qMail section (on page
30). For other details, refer to the Mail Handlers section from API Reference.

If an interface does not require registration of the implementation, you can use the
functionality, provided by the interface, by simply adding the following string to the
beginning of your PHP files:
include pm.php;
For the detailed description of Plesk Internal API functionality, refer to the API
Reference.

Event Listener
A registered object implementing the EventListener interface will be notified of all events
occurring in Plesk business logic.

At the time of notification, the event in question has completely happened and
committed. The event handler cannot prevent the action from succeeding. If an attempt
to perform some action fails, the core does not issue notifications through this
mechanism.

For implementation details, refer to the Implementing Event Listeners (on page 29)
section.

Basics 16

Pluggable Antivirus Filter
A registered object implemented the VirusFilter interface can manage antivirus filters for
incoming and outgoing correspondence.

For implementation details, refer to the Implementing Pluggable Antivirus Filters
section.

Registering Implementation of Interface
To register an implementation of an interface, the extension must add a PHP file (that
will use the interface functionality) to the directory
$PRODUCT_ROOT_D/admin/plib/registry/$INTERFACE/.

$INTERFACE is the directory named the same as interface.

$PRODUCT_ROOT is a directory on the server where Plesk is located.

The PHP file must have the suffix .php and be named so as to not cause clashes with
other extensions. It is recommended to use the name of the extension as part of the file
name. Files within the directory are processed by the core in lexicographical order,
should that matter.

The PHP file must start with a long PHP tag (<?php). It is not necessary to include any
PHP files, as everything that is necessary will be imported by the core before parsing
the extension file. The file can include other PHP files shipped with the extension, but
they must be located outside the registry directory. The file is expected to declare a
class implementing the interface, create an instance of the class, and register the
instance.

To register the implementation, the PHP file must end with a return statement,
returning the object instance to the caller. Several implementing instances can be
returned in an array. The extension may choose to not provide an implementation
under certain circumstances; this can be indicated by returning null or not executing
return at all. The core guarantees that it shall not invoke the same extension file twice,
so singleton policy enforcement measures are not necessary.

Basics 17

Plesk External API
External API is designed cross-process for communication between Plesk and other
applications. Invocations of external API's can cross host boundaries, and are
programming language neutral.

Plesk for UNIX offers the following documented external API's:

 XML-RPC

 Command line interface

Comparison Between External and Internal API
This table shows differences between External API and Plesk Internal API.

Property External API Plesk Internal API
Control flow Cross-process In-process
Usable over network Yes No
Scope Plesk or OpenFusion Plesk
Programming language Not restricted Same on both sides
Invocation overhead High Low
Security model Authenticated Full trust
Data representation Platform neutral Native

Plesk Module Manager

Module Manager is a part of Plesk that provides GUI to operate modules, namely, to
install the specified module to Plesk, to display the list of all modules registered in
Plesk and accessible for use, to display GUI of the selected module, and to uninstall
the module.

Basics 18

To get a better vision of where Plesk support ends and the module's work begins, there
is a table presented below:

Task What Module Manager does What Module does
Allows the user to select an
RPM/DEB/SH package via GUI.
- triggers unpacking of the - having got the command to unpack
package to the server. itself, the RPM/DEB/SH package
deploys its contents (file and folder
structure) to the server directories
specified in the package.
Module
install - the RPM/DEB/SH package registers
itself in the RPM/DEB/SH system
procedure
managed by the operating system.
- after the module is registered, the - the module is registered in the
user can apply the Update specified tables of Plesk database.
operation on the Modules page to
see the button of the new module
on it.

Viewing Uses GUI to display the buttons of
all available modules registered in
all
Plesk database.
modules
available
Once the user has pressed the - the default page should provide
module’s button, Module Manager graphics means to run the module
displays the default page of the and/or navigation means to move to
Opening module (an entry point of the other pages of the module.
module’s module’s GUI).
GUI and
performin - at least one (main) page of the
module should provide an opportunity
g
to return to Module Manager (Plesk
operation GUI concept implies that any page
s on contains a link of a higher-level page).
module

Allows the user to select the - the RPM/DEB gets the command to
candidates for deletion in the list of delete the contents of its package and
available modules via GUI, and to performs the task. In case of a shell
trigger the uninstall procedure as package (SH) Module Manager
well. deletes the package on its own by
triggering the uninstall script stored in
Module’s the
uninstall <plesk_root_dir>/var/modules
procedure / <module_name> folder.

- after the module is uninstalled, - the module unregisters itself in Plesk
the user can apply the Update database.
command on the Modules page and
see that the module’s button is
disappeared.

19

CHAP TER 3

Implementation and Samples
This chapter focuses on important issues of using Internal Plesk API in practice. It is
supposed that hierarchical structure of a module has already been made. The only
thing left is to fill it with a proper working code.

In this section:
Designing GUI of Module ............................................................................... 19
Implementing Module Help System ................................................................ 24
Localizing Module .......................................................................................... 26
Creating Module Front-end Part ..................................................................... 27
Implementing Event Listeners ........................................................................ 29
Customizing system settings for the module ................................................... 29
Using Mail Handlers with qMail ...................................................................... 30
Using Pluggable Antivirus Filters .................................................................... 31

Designing GUI of Module
This code is very important and cannot be skipped as here begins the work on the
module’s front-end code which will serve as a bridge between Plesk and the module’s
core.

A GUI consists of one or several forms that allow the user to start or stop the module,
to define settings, and so on. Each form is presented in the module package by a
separate PHP file. This file should solve the task of setting necessary parameters
required by the form, plus it should contain the code that creates HTML of all GUI
elements of the form.

For details, refer to Plesk Internal API (on page 15) and Modules API Functions (API
Reference) sections


Plesk Modules API
GUI elements used to compose a form can be created using functions and classes of
Plesk Modules API. The API functions are as follows:

Forming GUI Elements

pm_comm_button

pm_link_button

pm_pathbarMaker

pm_pathbarDestructor

Navigation

pm_go_to

pm_go_to_uplevel

Plesk Modules API classes implementing GUI elements are as follows:

 The pm_Form class is designed as the HTML form generator. A special feature of
this class is FastTemplate support, though using this technology is not a
requirement. Also, this class provides parameters that help bind a form with the
relevant help file.

 The pm_cList class generates a list element displayed on the browser’s page as a
multi-column table. Supported features are sorting, filtering, paging.

 The pm_Pathbar class presents a GUI element always displayed on top of Plesk
pages and used to show the path by which the user has got to the current page.
This control is a convenient navigation means that allows the user to get to any
previous page displayed in the pathbar GUI element as a link.


Entry Point to GUI
When the user clicks on the module’s button on the Modules page, Plesk looks through
the related module package for the index.php file which serves as an entry point to
GUI of the module.

This file is a suitable place to create the main form of the module as well as to set the
table of commands recognized by the module. For instance, this table can be
implemented as a switch construct:
$cmd = get_gpc('cmd');
switch ($cmd) {
case 'beginEdit':
… // handling
break;
case 'reset':
… // handling
break;
case 'remove':
… // handling
break;
default:
… // handling
}
Each case element is the point where GUI is linked with front-end and back-end
functionality (creates objects, calls functions, handles errors, etc.).

Please note that the above example is not a recommendation on how to write the
index.php file. The only requirement is that this file is present in the module package
at <plesk_root_dir>/admin/htdocs/modules/<module_name> and provides
access to the rest of the module’s functionality directly or indirectly (referencing other
PHP files).

Creating PHP Forms (Requirements and Recommendations)
Simple modules can have all necessary GUI elements located on a single form, while
complex modules require a multi-page GUI. All forms of a complex GUI make up a
hierarchy that can be arranged in a convenient folder structure. Besides, Plesk style
requires that every form has an Up Level button.

It is proposed to locate PHP 'form' files in folder
<plesk_root_dir>/admin/htdocs/modules/<module_name> of the module
package beside with the index.php file. If these files are arranged into a folder
structure, the entire structure can be located within this folder.

Finally, a couple of words regarding the use of Plesk Modules API. Though Plesk
provides a special API for creating the module’s GUI, using it is not a requirement.
There are some advantages of using this API, that is:
 GUI elements created on basis of Modules API classes have a Plesk styled look.
 Such elements provide additional convenient features.


In respect of GUI forms, such convenient features are: Plesk Help Support provided for
help topics associated with forms, and the FastTemplate technology. And again, the
developer is free to select any convenient way to create module’s forms. The purpose
of Modules API is just to propose one particular way.

Utilizing FastTemplate Technology
If you choose in favor of pm_Form class of Modules API, this is the point to decide
whether FastTemplate is a good choice for generating forms of the module (as using
the pm_Form class does not make it necessary to use templates). This sub-topic
demonstrates the power of FastTemplate and proves that using it is really easy.

Using FastTemplate implies creating template files that define the static part of the
HTML page. These files should be created as standard HTML files, except they should
contain templates rather than static HTML text of GUI elements. These files should be
saved with the TPL extension (<file_name>.tpl) in
<plesk_root_dir>/admin/plib/templates/modules/<module_name>.

The following example demonstrates the simplicity of an HTML template file:
<div style='margin: 20px 0 10px;'>
{INFO}
</div>
<div class="toolsArea">
<fieldset>
<legend>{TOOLS_LEGEND}</legend>
<table width="100%" cellspacing="0" cellpadding="0"
border="0"><tr><td>
{START_BUTTON}{STOP_BUTTON}{REFRESH_BUTTON}
</td></tr></table>
</fieldset>
</div>
<div class="listArea">
<fieldset>
<legend>{DISKS_LIST_LEGEND}</legend>
<table width="100%" cellspacing="0" cellpadding="0"
border="0"><tr><td>
{DISKS_LIST}
</td></tr></table>
</fieldset>
</div>
Here is how this template page looks like in the browser:

Figure 2: The Disks.tpl template file


Templates are labels enclosed in curly brackets. When the FastTemplate engine
(integrated with Plesk) parses this page, templates serve as tokens to be replaced with
HTML code of certain GUI elements. The advantage is the flexibility of making pages -
each time this HTML is generated dynamically. The below figure illustrates the result of
work of the FastTemplate engine:

Figure 3: The page generated using the Disks.tpl template file

From the programming standpoint, the Disks form shown on the above figure is a tab of
the Watchdog form. So, there must be a class inherited from the abstract pm_Form
class and implementing the Watchdog form and one more ‘tab’ class that inherits from
‘Watchdog’. To utilize FastTemplate, the ‘Watchdog’ (parent) class should have its
define() method overridden as follows:
// function define ()
$templates = array(
'tab' => ‘disks.tpl’,
…
);

This code defines short names of template files (disks.tpl) and associates them
with real templates ({TAB}). (Actually, the ‘tab’ item of the $templates array stores
the code that detects the template file of the currently active tab – Services, Disks,
Security, Statistics, or Preferences. The disks.tpl file is hard-coded in this example
for better understanding. )


The ‘tab’ (child) class should contain the following code in its overridden
assign()method:
// function assign ()
$info = wd__lmsg("Disks monitoring management.");
$vars = array(
'PAGE_TITLE' => wd__lmsg("Watchdog"),
'CONTEXT' => safetyjs($context),
'INFO' => $info,
'TOOLS_LEGEND' => wd__lmsg("Tools"),
'START_BUTTON' => '',
'STOP_BUTTON' => '',
'REFRESH_BUTTON' => '',
'DISKS_LIST_LEGEND' => wd__lmsg("Disks"),
'DISKS_LIST' => $DisksList->get(),
);
This code declares templates and associates them with localized strings (via
localization keys) or functions generating HTML of relevant GUI elements.

Thus, the step devoted to GUI of the module should result in a set of PHP files
generating GUI, including the index.php one, and optionally in a set of template files,
all of them located in proper folders of the module’s package.

Implementing Module Help System
Although the help support is optional, it is recommended that GUI of the module does
provide help topics for module forms.

A standard help topic is an HTML file. You can create a single help file that would
describe the module in common words, and this file would be invoked from the main
module page and displayed in a separate browser window above other windows. Or
this file can be a multi-page manual with an index page. Besides, you can provide each
page of a multi-page module with its own help file. When the user asks for help on a
certain page of such a module, the associated help topic is displayed in a separate
browser window.

Creating Single-language Help
Determine GUI pages that require help, and create help files for them. HTML help files
can have any names, but these names should be unique within the module’s package.
By default, help files of a module are written in English (the default language of Plesk).
Once the help files are ready, add them to the module’s package. E.g. if written in
English, they are put to folder
<plesk_root_dir>/admin/modules/<module_name>/locales/en-US/help.


Creating Multi-language Help
If the multi-language help is required and English (or other) help files are already
available, they should be localized manually, their names kept unchanged.

Then all localized help files need to take a certain place within the module’s distribution
package. The <plesk_root_dir>/admin/modules/<module_name>/locales
folder can contain multiple <locale_name> sub-folders, one for each locale. All
localized help files should be distributed between package folders
<plesk_root_dir>/admin/modules/<module_name>/locales/<locale_nam
e>/help according to the locales they refer to.

Note: <locale_name> is formatted as specified in IETF RFC1766, ISO 639, and
ISO 3166 (it should look as <language code>-<country code>, e.g. en-US for
USA English, en-GB for British English, de-DE for German in Germany, de-AT for
German in Austria, etc.).

Binding Help Files with Forms
If you use pm_Form and want to invoke a certain help file, a GUI form should contain
the code as described below. The code example is extracted from the main page of the
Firewall module (ships with Plesk).
// set help support for firewall module
$vars['BODY_ONLOAD'] = "SetHelpModule('firewall');";
// associate this form with help file firewall_main.html
$vars['CONTEXT'] = 'firewall_main';
The above example demonstrates how to bind the firewall_main.html help file
with an instance of the class derived from pm_Form. This instance has a $var
member variable that stores a set of parameters, including BODY_ONLOAD (sets a
function to execute when the body of the form is loaded) and CONTEXT (is used to
store the name of the HTML help file).

This binding should be set in every PHP file implementing the form with a help file.
When help is invoked for such page, Plesk will search for help files at
<plesk_root_dir>/admin/modules/<module_name>/locales/<locale_nam
e>/help where <locale_name> matches the locale currently set in Plesk.

If you prefer to use a custom class (not derived from pm_Form) for your GUI forms, this
class can support Plesk Help System if you undertake two steps:
 HTML of the form generated by some member function of the custom class should
contain the handler of the body.onload event which in turn should contain the
following lines:
SetHelpModule('<module_name>');
SetContext('<help_file>', '');


 The body of the generated HTML page should contain the declaration of the
following Plesk script files:
<script language="javascript" type="text/javascript"
src="/javascript/common.js"></script>
<script language="javascript" type="text/javascript"
src="/javascript/chk.js.php"></script>
You can invoke help page using the get_help_url($topic, $base_dir,
$topic_mapping)PHP function. The latter returns the URL to the endpoint of the
Plesk help engine for the specified topic and base directory. The base directory should
either contain either a flat collection of static HTML pages for each topic, or an
AuthorIT-produced manual. In the latter case, the $topic_mapping parameter should
contain the topic mapping array. The $topic should contain topic ID or a topic page.

Thus, this step should result in a set of HTML help files put to the module’s distribution
package according to the supported language, and (optionally) in binding forms with
certain help files.

Localizing Module
Localization can be skipped if the module will always show its messages and GUI text
in English. In this case all strings with messages can be simply hardcoded in the
module’s code. However, if the module is a commercial product, using it becomes
more comfortable if it provides a localization feature. So, if you decide to provide such
a feature, Plesk in turn can provide you with a Plesk-enabled language support
technique which is described below.

Localization files belong to the resource files part of a module. For info on resource
files, refer to Logical Module Structure (on page 9) and admin/htdocs Folder (on page
12) sections.

Creating Localization Files
All GUI text of a module are accumulated into two localization files with fixed names:
 messages_<locale>.php (for warnings, error messages, and GUI text),
 conhelp_<locale>.php (for context help messages),
<locale> is formatted as <language code>-<country code> according to
IETF RFC1766, ISO 639, and ISO 3166 , e.g. en-US for USA English, en-GB for British
English, and so on.

A localization file contains an array of pairs like <key>=><localized_string>
where <localized_string> is a string being localized and <key> is a unique
localization key.
global $my_module_conhelp_arr;
$my_module_conhelp_arr = array(
‘module_activate’ => ‘Start the module.’,
‘module_deactivate’ => ‘Close the module.’,
…
);


Each supported locale should have one or both localization files. If a module supports
several locales and contains several localization files of the same type (e.g.
messages_en-US.php, messages_de-DE.php, etc.), the collection of localization keys
should be similar in all these files (while the translations vary for different languages).

When ready, all localization files are put into the folders of the module package
(<plesk_root_dir>/admin/plib/modules/<module_name>/locales/<loca
le>).

How Localization Works
Plesk does not inform the module about the current locale. The module should get this
information itself. You can use pm_get_locale() function from Modules API to retrieve the
current locale.

To translate messages, you should load the messages array for the locale, search key
in the array and retrieve the value of this key.
/**************/
/* locale.php */
/**************/
<?php
/**
* This function loads the module's locale files. This file
* automatically calls this function
*/
function load_module_locale()
{
// Get the current locale
$locale = pm_get_locale();
...
}
load_module_locale();
?>

So, this step should result in the localization files created and allocated properly, and in
the locale resolution file as well.

Creating Module Front-end Part
If the module’s GUI is ready, it is necessary to bind the visible part of the module with
its functional part. This binding includes:
 Reading the data entered to fields of the module forms,
 Validating this data,
 Passing this data to the functional code of the module for processing,
 Reading the result returned by the functional code,
 Passing the result to GUI,
 Handling errors on all steps of data processing.


When writing the front-end part of a module, the functions of Plesk Modules API come
to help. They can be grouped as follows:

Parameter Operations

pm_get_gpc

pm_get_locale

pm_isset_gpc

pm_set_gpc

Data Formatting and Conversion

pm_ldate

pm_ldatetime

pm_ltime

pm_plesk_mail

pm_safetyhtml

pm_size_b_printing

pm_size_kb_printing

pm_size_mb_printing

pm_size_pretty_printing

pm_time_pretty_printing

Error Handling/Messaging

pm_alert

pm_lmsg

pm_psaerror

pm_topnote

pm_warning

System

pm_util_exec

pm_util_io_exec


Besides, Plesk Modules API exposes the pm_Checker class that can be used when
writing the front-end code. This class provides a variety of member functions for data
format checkup.

Implementing Event Listeners
A component which needs to get notifications of Plesk events should register its
implementation of the EventListener interface. Read the Registering Implementation of
Interface (on page 16) section for details.

To register a PHP file, say my_events_extension.php, it should be put to the
<plesk_root_dir>/admin/plib/registry/EventListener directory
(<plesk_root_dir> stands for the full path to the directory where Plesk is installed).

The source of my_events_extension.php can look as follows:
<?php
global $ClientsCount;

class MyEvent extends EventListener {
function handleEvent($object_type, $object_id, $action, $old_values,
$new_values)
{
if ($object_type=='client')
{
$ClientsCount+=1;
}
}
}

$MyEventInstance= new MyEvent;
return $MyEventInstance;

?>

The handleEvent method of the MyHandlerInstance is called by the core once per business
logic event. The sample code counts events made by Plesk clients.

For detailed info on handlers, refer to the ... API.

Customizing system settings for the module
Sometimes smooth execution of a module requires such actions as changing owners
(and access permissions) of certain files, making up groups of special users,
customizing network settings, etc. These changes are made on the system level, and
the module can declare them in a special file. If these modifications of system settings
are not necessary, you can skip this step.


If the module requires some modifications in the current system settings, it should
contain the file named httpsd.<module_name>.include in folder
<plesk_root_dir>/admin/conf of the module’s package. This file contains a
shell script that runs system/custom utilities to perform the required modifications.

When Plesk tries to execute a module, it always checks whether the module contains
this file at the specified path, and executes the script if the file is found.

Here is the example of this script:
#!/bin/sh
echo 0 > /proc/sys/net/ipv4/ip_forward
@@IPTABLES@@ -F
@@IPTABLES@@ -X
@@IPTABLES@@ -Z
@@IPTABLES@@ -P INPUT ACCEPT
@@IPTABLES@@ -P OUTPUT ACCEPT
@@IPTABLES@@ -P FORWARD DROP

if [ -f '@@PRODUCT_ROOT_D@@/var/modules/@@MODULE@@/openvpn.pid' ];
then
kill `cat '@@PRODUCT_ROOT_D@@/var/modules/@@MODULE@@/openvpn.pid'`
rm -f '@@PRODUCT_ROOT_D@@/var/modules/@@MODULE@@/openvpn.pid'
fi
This script executes a set of commands of the iptables utility, after which the
openvpn.pid module is used to modify network settings.

Thus, if not skipped, this step should result in the file with a shell script created and put
to the proper folder of the module package.

Using Mail Handlers with qMail
To use registered mail handlers with qMail MTA (Mail Transfer Agent), you should
write additional code that manages collaboration between handlers and the MTA.

The code should do the following:

Create handlers queue

When handling a message, the code should read registered handler names from
before-queue, before-local, or before-remote directories. For info on logical
structure of handlers, refer to the Logical Structure of Handlers section of the API
reference. There is no need to stat each file, as reading the directories gives the list of
handler names. The obtained names should be sorted, and the handlers called in a
specified order.

Invoke handlers and manage handlers queue

The code which invokes handlers should be either patched into qMail or installed as
wrappers around qmail-queue, qmail-local, and qmail-remote utilities.


When calling a handler, the code should read from the handler's standard output. As
soon as the handler sends PASS, the next handler should be called receiving standard
output of the previous handler on its standard input. There is no need to continue
reading the standard output of the previous handler after this point.

The code should appropriately handle other resolutions issued by the handler on the
standard error stream and translate them to qMail exit codes. It should also monitor
handlers for termination due to signals.

Put the last handler into qmail-queue

The output of the last handler should be piped into the actual qmail-queue or
qmail-remote. For qmail-local, the output should be saved into a temporary file
because qmail-local requires seekable standard input.

For info on mail handlers, refer to the Plesk Internal API (on page 15) and Mail Handlers
(from API Reference) sections.

Using Pluggable Antivirus Filters
A component providing support for e-mail virus filtering software should register its
implementation of the VirusFilter interface. For info on component registration, refer to
the Registering Implementation of Interface (on page 16) section.

To store its own settings, the component should use private tables in the Plesk
database. The component can register an event listener to react to events like creation
and removal of mail accounts. For actual handling of mail, it is recommended that the
component registers a mail handler. For info on mail handlers, refer to the Plesk
Internal API (on page 15) and Implementing Event Listeners (on page 29) sections.

To register a PHP file, say my_filter_extension.php should be put to the
<plesk_root_dir>/admin/plib/registry/VirusFilter directory
(<plesk_root_dir> stands for the full path to the directory where Plesk is
installed).).

The source of my_filter_extension.php can look as follows:
<?php
class MyController extends VirusFilterController {
function handleForm($method, $readonly)
{
echo "<html>... static or dynamic page ...</html>";
// Checks the POST status
...
return TRUE;
}
function applyStatus($enabled)
{
// This method controls virus filter activity at the level of a
specific user.
}
}


class MyVirusFilter implements VirusFilter

{

function getName()

{

return "My Antivirus Filter";

}

function getUserController(User $user)

{

// code that checks if a user has already initiated an instance of
//the
// MyController class

return $MyControllerInstance;

}

function applyStatus($enabled)

{

// This method controls global virus filter activity.

}

}

$MyFilterInstance= new MyVirusFilter;

return $MyFilterInstance;

?>

33

CHAP TER 4

Creating Distribution Package
We consider that all components of the module’s package are ready and the package
itself is fully formed. Now it’s time to decide what distribution technology to choose.
Plesk recognizes three types of distribution packages - RPM technology, SH
technology, and DEB technology that targets Debian-based Linux.

In this section:
Creating Install and Uninstall Scripts .............................................................. 33
Creating an RPM package ............................................................................. 36
Creating a SH package .................................................................................. 37
Creating a DEB package................................................................................ 40

Creating Install and Uninstall Scripts

At this step all module files are ready for the distribution, and it is necessary to make a
decision regarding scripts that serve two points of the module’s lifetime.

Scripts That Work Before and After Installing/Uninstalling a Module

These scripts are included in the RPM/SH/DEB distribution package. When the
package is being built, these scripts are copied to reserved folders (in RPM, these are
folders PREIN, POSTIN, PREUN, POSTUN). These scripts are optional. They are
necessary for operations like creating or destroying database objects, registering or
unregistering the package in a special table of Plesk database, generating or
destroying system objects (files, folders), and so on.

The full set of such scripts is as follows (the example is given for an RPM package, the
naming format is not fixed):


RPM Package Script Expected Tasks
Folder
PREIN rpm_<module_name>_install Can set system and DB parameters,
_pre.sh configuration files, etc.
POSTIN rpm_<module_name>_install Can register the module in Plesk DB
_post.sh tables, create DB and system
objects, set various module
parameters, access permissions to
files, etc.
PREUN rpm_<module_name>_uninsta Can remove the module and all
ll_pre.sh related options from the DB, etc.
POSTUN rpm_<module_name>_uninsta Can clean out all marks of the
ll_post.sh module’s presence from Plesk DB
and system.

One of the most important tasks of installing/uninstalling modules is interacting with
Plesk database. First of all, any module must register itself in the Modules table of
Plesk database, which makes sense to be done in the postinstall script. This table has
the following fields:

Field Type Restrictions Description
id INT UNSIGNED AUTO_INCREMENT module’s id
PRIMARY KEY
name VARCHAR(255 BINARY NOT NULL, UNIQUE module’s name
)
packname VARCHAR(255 BINARY NOT NULL package name
) (can match the
module’s name)
display_nam VARCHAR(255 BINARY NOT NULL displayed
e ) module’s name
version VARCHAR(30) BINARY NOT NULL module version
release INT UNSIGNED NOT NULL package release
description VARCHAR(255 description of the
) module
icon VARCHAR(255 BINARY NOT NULL icon shown for the
) module on Control
Panel


A record written to this database should be unique (duplicate module installations are
inadmissible), so it is a good practice to check this table for a similar record already
available before the insert.

When removing a module, the related record should be cleaned out from the Modules
table, which is normally done in the preuninstall script.

Besides registering itself, a module may need to create its own internal tables in Plesk
database in order to register custom settings in them. This can be done in the
postinstall script. The naming format for such tables is module_<module_name>_*
(e.g. module_fileserver_users). SQL commands creating tables can be included
to the postinstall script directly. Also, it’s a good practice to isolate SQL code in
separate files (formatted as standard shell scripts but not declared as such) and
include them to the postinstall script. The following code can serve as an example of an
internal MySQL table:
CREATE TABLE module_fileserver_users (
id int(10) unsigned NOT NULL auto_increment,
name VARCHAR(255) CHARACTER SET ascii COLLATE ascii_general_ci
NOT NULL default '',
sys_name VARCHAR(255) CHARACTER SET ascii COLLATE
ascii_general_ci NOT NULL default '',
password VARCHAR(255) CHARACTER SET ascii COLLATE ascii_bin
NOT NULL default '',
password_type enum('plain', 'crypt') NOT NULL default 'plain',
PRIMARY KEY (id),
UNIQUE KEY name (name)
) TYPE=MyISAM;
When the module is uninstalled, all its internal tables need to be deleted from Plesk
database too. This task is performed by the preuninstall script.

When ready, these ‘pre’ and ‘post’ scripts are added to the RPM/SH/DEB package
during its build (see Step 10 of this tutorial).

Uninstall Script for SH Distribution Packages

One more situation that should be handled ‘in advance’ is the use of a SH package
when installing a module. A SH module package is a set of shell commands that install
a module. In contrast to RPM and DEB, such a package is not registered in the system ,
so the system does not remember the installation history of the module and will not be
able to uninstall it. This should be done by a special uninstall script located in
folder <plesk_root_dir>/var/modules/<module_name> of the module package.
This shell script deletes all files and folders of a module and triggers pre- and
postuninstall scripts if necessary.

The uninstall script is activated in Plesk as follows: when the administrator selects
the delete operation for a module via Plesk GUI, Plesk passes control to
ModuleManager that in turn looks for the uninstall script in
<plesk_root_dir>/var/modules/<module_name>/ and triggers it to execute.

Thus, this step should result in a set scripts meant to pre- and postprocess the
module’s install/uninstall, and (optionally) in one more uninstall script necessary if one
chooses in favor of the SH package to distribute the module.


Creating an RPM package
Since the code of the module is ready and packed into a folder structure, it remains to
wrap it into an RPM package, which implies two steps:
 creating the SPEC file for the RPM package,
 assembling the RPM package.
A standard SPEC file should have a name formatted as follows:
<package name>-<application version>-<release number>.spec
A SPEC file contains the information necessary to build an RPM package. The header
of this file contains a standard set of information that includes the application’s
description, its name, version number, release number, etc. Also, this file contains
instructions on the building process, lists of application files and lists of third-party
applications necessary for the install procedure.

The following SPEC file created for the Counter-Strike2 Server version
3.1.0.6 illustrates the above:
%define name cs-gs2
%define display_name Counter-Strike2 Server
%define cs_gs_version 3.1.0.6
%define mod_version 10000
%define display_mod_version %{cs_gs_vers}

Summary: Counter-Strike and Counter Strike:Source game server module
for Plesk
Name: %{name}
Version: %{display_mod_version}
Release: %{rels}
Copyright: GPL
Vendor: SWsoft
Group: Amusements/Games
Packager: SWSoft Inc <info@swsoft.com>
BuildRoot: %{cs_gs_buildroot}
Prefix: %{product_root_d}
Prereq: psa >= 7.5.0
Requires: psa-security = 7.5
Provides: plesk-module

%description
%{name} is Counter-Strike game server module for Plesk.
%prep
[ -f %{cs_gs_buildroot}/../rpm_cs-gs2_install_pre.sh ]
[ -f %{cs_gs_buildroot}/../rpm_cs-gs2_install_post.sh ]
[ -f %{cs_gs_buildroot}/../rpm_cs-gs2_uninstall_pre.sh ]
%pre
%include %{cs_gs_buildroot}/../rpm_cs-gs2_install_pre.sh
%post
%include %{cs_gs_buildroot}/../rpm_cs-gs2_install_post.sh
%preun
%include %{cs_gs_buildroot}/../rpm_cs-gs2_uninstall_pre.sh
%files
%defattr(-, root, psaadm)


%{product_root_d}/admin/bin/modules/%{name}
%{product_root_d}/admin/sbin/modules/%{name}

%defattr(-, root, root)
%{product_root_d}/etc/modules/%{name}/
%{product_root_d}/admin/htdocs/modules/%{name}/
%{product_root_d}/admin/htdocs/images/modules/%{name}/
%{product_root_d}/admin/plib/modules/%{name}/
%{product_root_d}/admin/plib/templates/modules/%{name}/
%{product_root_d}/admin/htdocs/images/custom_buttons/cs-small.gif
%{product_root_d}/var/modules/%{name}/
%changelog
* Tue Nov 08 2005 Plesk Inc <info@swsoft.com>
- First build
Once the SPEC file is ready, it’s time to build the RPM package. This can be done by
the following command executed under RedHat Linux:
# rpmbuild --bb --target=noarch /usr/src/redhat/SPECS/<spec_file_name
>.spec
Once this command is executed, a special message informs the user about the folder
where the resulting RPM package is located. E.g. the above example will put the RPM
package to the /usr/src/redhat/RPMS/noarch folder.

Visit http://www.rpm.org/RPM-HOWTO/build.html (http://www.rpm.org/rpm-
howto/build.html) to learn more about the process of building RPM packages.

Creating an SH package
First comes the preparatory step at which the module package gets compressed. Pack
the module into a TAR archive to merge its hierarchical folder structure into a single
file, and then compress the resulting TAR file into a ZIP archive file. E.g. module psa-
sbm2 v1.1-0021 module can be packed into the psa-sbm2.tar file and then
compressed into the psa-sbm2.tar.gz archive file.

To wrap the compressed module into a SH package, proceed through the following
steps:
 create an empty SH file;
 create the contents of this file;
 encode the module package using UUENCODE;
 append the encoded module package to the SH package.
A SH file should have a name as follows:
<application name>-<version number>-<release number>.sh
First it is necessary to create an empty SH file, e.g. psa-sbm2-1.1-0021.sh, and
make it executable using the following commands:
> psa-sbm2-1.1-0021.sh
chmod 777 psa-sbm2-1.1-0021.sh


The contents of this file should contain a header where it is specified that the package
refers to Plesk modules:
#!/bin/sh
#Provides: plesk-module
Next comes the section that describes how the module package will be decoded from
UUENCODE as well as enumerates the archive files, includes the code that will unpack
this archive, copies the module’s files to a specified location, and cleans out temporary
installation files and folders.

The following example is an extract of the SH file of the SiteBuilder module (ships with
Plesk):
#!/bin/sh
#Provides: plesk-module

initial_conf()
{
PRODNAME = "psa"
PRODUCT_NAME = "Plesk"
product_full = "Plesk"
PRODUCT_FULL_NAME = "Plesk"
product_etc = "/etc/${PRODNAME}"
}

set_module_params()
{
module = "sbm2"
module_full = "Remote Admin for SiteBuilder2"
packname = "psa-sbm2"
module_current_version = "1.1 21"
module_ver =
"$PRODUCT_ROOT_D/admin/plib/modules/${module}/version"
module_conf =
"$PRODUCT_ROOT_D/admin/plib/modules/${module}/config.php"
module_version = "1.1"
module_release = "0021"
module_sql_file =
"$PRODUCT_ROOT_D/etc/modules/${module}/sbm2_db.sql"
}

mysql_query()
{
result = `echo "$query" | $mysql 2>/dev/null`
return $result
}

set_common_params()
{
initial_conf
set_module_params

# set mysql params
mysql_client = "$MYSQL_BIN_D/mysql"

mysql_passwd_file = "$product_etc/.${PRODNAME}.shadow"
admin_passwd = `cat "$mysql_passwd_file"’
mysql = "$mysql_client -N -uadmin -p$admin_passwd -D${PRODNAME}"
}


sbm2_install_db()
{
echo "===> Installing database"
query = `cat $module_sql_file`
mysql_query
}

sbm2_install_registration()
{
echo "===> Registering module..."
query = "
REPLACE INTO `module_2_sbm_config` VALUES ('3', 'version',
'$module_version-__release__');
REPLACE INTO Modules (`name`, `packname`, `version`,
`release`, `description`, `icon`, `display_name`) VALUES
('$module', '$packname', '$module_version', '$module_release', 'The
SBM2 module provides functionality for remote administration of
SiteBuilder2.', '/modules/$module/images/icon.gif', '$module_full');"
mysql_query
echo "===> Module has been registered successfully."
echo $module_current_version >$module_ver
}

sub_which()
{
local prog = "$1"
if [ "X$prog" = "X" ]; then
return 1
fi;
IFS =:
for E in $PATH; do
if [ -f "$E/$prog" -a -x "$E/$prog" ]; then
echo "$E/$prog"
return 0
fi
done
return 1
}

sbm2_unpack_tar()
{
uudecode $0
GTAR = `sub_which gtar`
echo "===> Installing module ${packname}"
$GTAR --owner=root --group=psaadm -C $PRODUCT_ROOT_D/admin -xzf
${packname}.tar.gz
mv -f $PRODUCT_ROOT_D/admin/app-key-handler.module-sitebuilder-2
$PRODUCT_ROOT_D/bin
mkdir -p $PRODUCT_ROOT_D/etc/modules/$module
mv -f $PRODUCT_ROOT_D/admin/sbm2_db.sql
$PRODUCT_ROOT_D/etc/modules/$module
if [ ! -d $PRODUCT_ROOT_D/var/modules/$module ]; then
mkdir $PRODUCT_ROOT_D/var/modules/$module
fi
mv -f $PRODUCT_ROOT_D/admin/uninstall
$PRODUCT_ROOT_D/var/modules/$module/
chmod 550 $PRODUCT_ROOT_D/var/modules/$module/uninstall
$PRODUCT_ROOT_D/bin/app-key-handler.module-sitebuilder-2
rm -f ${packname}.tar.gz


echo "===> OK"

}

oper = "install"
set_common_params

sbm2_unpack_tar
sbm2_install_db $oper
sbm2_install_registration

ln -s ${PRODUCT_ROOT_D}/lib / 2>/dev/null
exit 0
begin 644 psa-sbm2.tar.gz
Then the module package is encoded using the UUENCODE utility and added to the
SH file using the following command:
uuencode psa-sbm2.tar.gz psa-sbm2.tar.gz >> psa-sbm2-1.1-0021.sh

Creating a DEB package
The procedure of packing a module into the DEB package resembles that one with
RPM packages. But there are two differences, that is:
 a control file is used instead of SPEC;
 assembling the package is done using the dpkg utility.
The control file contains various values which the package management tool will use
to manage the package. Though there are no format restrictions on the control file
name, it is recommended that the developers follow a standard naming convention for
such files:
<package name>-<module version>-<release number>.control
A control file should contain the following control information necessary for the
source package:
 Source: the name of the source package. Optional.

 Section: the section of the distribution the source package goes into (in Debian:
main, non-free, or contrib., plus logical subsections, e.g. ‘admins’, ‘doc’, ‘libs’).

 Priority: describes how important it is that the user installs this package. This item
can be left as ‘optional’.

 Maintainer: the name and email address of the maintainer.

 Build-Depends: the list of packages required to build your package. This item is
optional.


 Standards-Version: the version of the Debian Policy standards this package follows,
the versions of the Policy manual you read while making your package. This item is
optional.

The information that describes the source package is as follows:
 Package: the name of the binary package. This is usually the same as the name of
the source package.

 Version: the version information related to the application itself and to Plesk.

 Installed-size: the amount of disk space (in bytes) required for a given application.

 Architecture: the CPU architecture the binary package can be compiled for.

 Depends: the packages on which the given one depends on. The package will not
be installed unless these packages are installed. This item should be used only if
the application absolutely will not run (or will cause severe breakage) unless a
particular package is present.

 Provides: this field specifies that the package targets a Plesk module.

 Description: a short description of the package.

<Here is the place where the long description goes> The Package field is specified
using the following format:

Package: psa-module-<MODULE_NAME_IN_LOW_CASE>

The Version field is formatted as follows:
Version: <MODULE_VER>-<PLESK_VERSION><MODULE_RELEASE>

Here <MODULE_VER> stands for the version of the packed module,
<PLESK_VERSION> means the version of Plesk (e.g. 80 for Plesk v8.0), and
<MODULE_RELEASE> means the ordinal number of the module’s build.

The Depends field has the following format:
Depends: psa (>= 8.0)<MODULE_REQUIRES>

I.e. the required packages should follow one another without spaces, their versions
specified in brackets as shown in the format string.

The field coming after the Description field should meet the requirements to follow: this
should be a paragraph which gives more details about the package. There must be no
blank lines, but one can put a single . (dot) in a column to simulate that. Also, there
must be no more than one blank line after the long description.


Here is a sample control file:
Source: @@PRODNAME@@-cs-gs2
Section: non-free/net
Priority: extra
Maintainer: <info@swsoft.com>
Standards-Version: 3.5.8
Build-Depends: debmake

Package: @@PRODNAME@@-cs-gs
Architecture: any
Provides: plesk-module
Pre-Depends: @@PRODNAME@@ (>= @@PRODVERSION@@)
Depends: @@PRODNAME@@-security-@@RELEASE_VERSION@@, @@PRODNAME@@ (>=
@@PRODVERSION@@)
Description: Counter Strike: Source game server module for Plesk.
To build a DEB package, one can use the dpkg utility and issue the following
command:
dpkg -b ${build_dir} ${package_file}
For example,
dpkg -b /usr/local/modulebuilder/build/ cs-gs2-3.5.8-4_deb31_80
/usr/local/modulebuilder/build/psa-module- cs-gs2-3.5.8-8004_all.deb
Visit http://www.debian.org/doc/maint-guide/index.en.html
(http://www.debian.org/doc/maint-guide/index.en.html) to learn more about the process
of building DEB packages.

Plesk Modules

More Related Content

What's hot (17)

Similar to Plesk Modules (20)

More from webhostingguy (20)

Plesk Modules