CPRules.pl - Perl program to convert a Check Point FW-1 configuration to HTML or to export this information to an ASCII file.
This is version 2.00 of CPRules. This version is compatible with NGX R62 and lower. This means that the layout of objects can have changed and the necessary parameters are added.
See for other fixes the ``History of CPrules.doc'' as included in the package.
As the management of a FW is a security-sensitive subject, one can not allow others to access the management servers. With 'others' being non-administrators of the firewall, like internal or external customers. In many cases it is even prohibited by the security policy of your company and sometimes the mgmt LAN is even physically disconnected!
However in many cases it is very convenient to have a copy of the configuration available for viewing by a select group of 'others'. This can be for a helpdesk for trouble shooting purposes (not needing to call you every five minutes), a customer demanding to have an insight in their FW configuration or just for backup purposes.
On the other hand, it's not wise to leave this kind of configurations lying around for everybody to see (you're auditors would have a field day). So you might not want everything being published, but only a subset of the configuration (f.i. only the FW rulebase itself). Such a subset would enable the customer (being either internal or external) to request meaningfull changes without having to bother the administrators first.
To be able to do all this, we need a tool to convert the Check Point files to a readable format. This tool would need to be configurable to allow administrators to define what to publish and how. CPRULES is designed to accomodate in just that wish.
There has been repeated requests to be able to export the data to ASCII format, so it could be imported in a database or converted to different output formats. It can also open the way to import the objects (or a selection) into a different program, although other tools are also available for this.
Searching the internet the only tool available to convert Check Point configurations was a perl script called FW1RULES, written and maintained by Volker Tanger <volker.tanger@wyae.de>. Admittedly this program did serve very well and is widely used. This program was originally written to cope with Check Point FW-1 version 4.1 code and has later been adapted to support NG configurations as well. It drastically needed a rewrite of the code due to additions and changes made in the past. That is basically where CPRULES has taken of.
There are two ways to configure the program. The first and easiest way is through the configuration file called CPRules.ini. The second option is to use the commandline parameters. The advantage of the .ini file is that many parameters can be set per rulebase. This is not possible through the commandline switches.
The software will read the CPRules.ini file first and adds the commandline switches later on. This enables you to use a default setup and overwrite it at will from the commandline. If you are handling more management stations, this would enable you to call the program for every management server in turn, only differing the location of the Check Point files.
Default behaviour is to process all policy packages found in the objects_5_0.C file. In some cases you just want to get the results for one policy/rulebase or a subset of them. Both is possible through the (include and exclude) commands in the CPRules.ini file. Through the commandline it is only possible to process one (-b switch) or all policies.
As discussed above, the CPRules.ini is the preferred way to configure the behaviour of the program. The CPRules.ini is searched for in the current directory and if not found, in the working directory of CPRules, i.e. the folder where the script itself is located.
The configuration options are divided in several sections: CPRules file locations, Check Point file locations, HTML file locations and Policy specific settings. The next four corresponding paragraphs will outline the commands.
The program has two main functions, creating HTML files or exporting objects to ASCII files. The parameters for both can be included in the same .ini file, although the program will only output HTML or ASCII whichever is requested.
The first section of the CPRules.ini file holds all the path and file names needed by the software itself. Below are the options needed to create the HTML files.
TmplPath - The program uses templates to build the HTML pages. Templating allows you to make changes to the output without messing with the program. For more details about the syntax, see the documentation of the 'template.pm' file. This parameter defines the location of the template files. The program searches for the folder 'Templates' in both the current- and the working directory.
TmplPath=./tmpl
HTMLPath - The output of the program are HTML pages per policy. This will result in subfolders in the HTML folder per policy (f.i. ./html/MyRulebase). This parameter defines the location of the HTML files.
HTMLPath=./html
The second section of the CPRules.ini file contains the location of the Check Point files that are needed. How the files get there is completely up to you, as long as they are accessible. Note: Check Point files are case-sensitive, so be careful not to misspell the filenames.
FW1Rules - Check Point stores all the rulebases in one file, called 'rulebases_5_0.fws'. This is the only rulebase file needed. This parameter defines the location and name of this file relative to the work folder.
FW1Rules=./rulebases_5_0.fws
FW1SLPRules - Check Point stores the desktop security rulebase in a database file called 'slprulebases_5_0.fws' (Secure LAN Policy). This parameter defines the location and name of this file relative to the work folder.
FW1SLPRules = ./slprulebases_5_0.fws
FW1Objects - Check Point stores all the objects, services, etc in one database file called 'objects_5_0.C'. This parameter defines the location and name of this file relative to the work folder.
FW1Objects=./objects_5_0.C
FW1Users - The users of Check Point are currently not stored in a 'normal' database file. However in the GUI of R55 there are indications this might change. The file used is called 'users.C' and has the same structure as the 'objects_5_0.C' file. This parameter defines the location and name of this file relative to the work folder. If this file is not present yet, one has to rely on the exported users and groups. See below EXP_Users and EXP_Groups.
EXP_Users - Till now the users of Check Point are stored in the file 'fwauth.NDB', which is not readable. The users can be exported from this database by using the command:
fwm dbexport -f <filename>
This parameter defines the location and name of this exported users file relative to the work folder. The program will use CPUsers.pl to create the 'users.C' file from the export file(s).
EXP_Groups - As with the users, the groups of Check Point are stored in the file 'fwauth.NDB', which is not readable. The groups can be exported from this database by using the command:
fwm dbexport -g -f <filename>
This parameter defines the location and name of the exported groups file relative to the work folder. The program will use CPUsers.pl to create the 'users.C' file from the export file(s). If the groups file is not included, vital information will be missing, as comments, groups in groups information and administrator groups.
The third section of the CPRules.ini file holds all the path and file names used in the resulting webpages. Note that these paths are hardcoded in the HTML code produced! So you'd better check the paths to the files are correct and they are accessible when viewing the HTML results!
IconPath - The objects all have different icons per type or class. These icons have been extracted from the Check Point files and stored in a separate folder. This folder is needed for correct displaying of the HTML pages, so the path is relative to the HTML directory. The default value assumes the 'icons'-folder is a subfolder of the HTML folder. This path will be hardcoded in the HTML pages, so be sure the icons are actual there!
IconPath=../icons
CSSPath - The location of the stylesheets used. There is currently only one stylesheet used, called cprules.css.
CSSPath=../css
ScriptPath - The HTML output uses three java scripts: menu.js, back2top.js and visible.js. This parameter defines the location of those scripts relative to the HTML files.
ScriptPath=../scripts
MainLogo - This defines the location of the main logo of the program. This could be the logo of the ISP providing the service, or a self-designed CPRules logo. Note that this will be hardcoded in the HTML files, so be sure it can be found during viewing.
The policy specific section holds additional commands to alter the output of the program. As the program creates the output files per policy, these settings must be adaptable per policy. To accomplish this, section headers with the name of the policy are used to define the setting for this specific policy.
To make life easier, a [Default] section can (and will) be used to hold all 'default' settings. If a specific setting is not specified in a policy section, the corresponding setting in the [Default] section will be used. So in many practical situations, there will be no other policy sections at all!
Default behaviour of the program is to process all policies found in the objects_5_0.C file. The Include and Exclude commands can be used to alter this behaviour. You should never have to combine both statements, but you are allowed to.
Exclude - Do NOT generate HTML for this policy. If the first (include/exclude) command found is an Exclude command, all other policies are INcluded automatically.
Include - Do generate HTML for this policy. If the first (include/exclude) command found is an Include command all other policies are EXcluded automatically.
Note: If a policy is both included and excluded (???), the first entry will prevail.
Example:
Include=MyCompany Exclude=Standard
Logo - The HTML pages always have a logo in the left top of the page (see MainLogo). The Logo parameter is used to define the image in the right top of the pages. This is designed to be the logo of the customer which rulebase is shown here. Note that this will be hardcoded in the HTML files, so be sure it can be found during viewing.
Logo=./html/MyCompany.jpg
AllObjects - By default (0) the HTML pages will only list those objects actually used in the policy. This parameter (if set to '1') will change this behaviour and will list all objects available. That might come in handy during testing or when documenting the configuration.
AllObjects=0
GlobalProps - By default (1) the Global Properties will be included in the output files. To suppress the Global Properties, set the value to '0'.
GlobalProps=1
Example:
[Default] Logo=./html/MyCompany.jpg AllObjects=0 GlobalProps=0 [CompanyB] Logo=./html/CompanyB/OtherLogo.gif AllObjects=1 GlobalProps=1
All the default values that can be set in the CPRules.ini can also be set using a commandline switch. For a more detailed description see that section. There is always a verbose version and a short version available and the switches are case-insensitive.
To set the path to the HTML template folder (default: ./tmpl):
--TmplPath <path> -t <path>
To set the path to the HTML folder (default: ./html):
--HTMLPath <path> -h <path>
To set the path to the folder with icons relative to the HTML folder (default: ../icons):
--IconPath <path> -i <path>
To set the path to the folder which holds the css stylesheets (default: ../css):
--CSSPath <path> -c <path>
To set the path to the folder which holds the java-scripts used (default: ../scripts):
--ScriptPath <path> -s <path>
To define the logo in the upper left top of the HTML pages (default: (none)):
--MainLogo <path and filename> -m <path and filename>
To define the location of the Check Point rulebase file (default: ./rulebases_5_0.fws):
--FW1Rules <path and filename> -r <path and filename>
To define the location of the Check Point Desktop Security rulebase file (default: ./slprulebases_5_0.fws):
--FW1SLPRules <path and filename> -slp <path and filename>
To define the location of the Check Point object database (default: ./objects_5_0.C):
--FW1Objects <path and filename> -o <path and filename>
To define the location of the Check Point users database (if available):
--FW1Users <path and filename> -u <path and filename>
To define the location of the exported users file:
--EXP_Users <path and filename> -eu <path and filename>
To define the location of the exported groups file:
--EXP_Groups <path and filename> -eg <path and filename>
To specify one specific policy only (default: all policies). The '--Rulebae' and '-b' switches are supported for backwards compatibility only:
--Policy <policy name> -p <policy name> --Rulebase <rulebase name> -b <rulebase name>
To define the logo in the upper right top of the HTML pages (default: (none)):
--Logo <path and filename> -l <path and filename>
To define if all objects should be listed by default, the following switch should be used. This switch turns the setting ON (it's OFF by default):
--AllObjects
To define if the Global Properties should be excluded from the output, the following switch should be used. This switch turns the setting OFF (it's ON by default):
--NoGlobalProps
Examples:
The typical installation of the CPRules will often be static. The icons, templates and html files are in a fixed location, so only the location of the Check Point files needs to be defined. All other parameters are defined in the .ini file. Such a setup would result in a commandline as shown below (commandline is displayed over more lines for readability):
cprules --FW1Objects /data/fwmgmt2/objects_5_0.C
--FW1Rules /data/fwmgmt2/rulebases_5_0.fws
--FW1Users /data/fwmgmt2/users.C
--AllObjects
To run the program for one rulebase only with the corresponding logo:
cprules --Rulebase MyCompany --Logo ./MyCompany.gif
The CPRules.ini is the preferred way to configure the behaviour of the program. The CPRules.ini is searched for in the current directory and if not found, in the working directory of CPRules, i.e. the folder where the script itself is located.
The configuration options are divided in several sections: CPRules file locations, Check Point file locations, HTML file locations and Policy specific settings. The next four corresponding paragraphs will outline the commands.
The first section of the CPRules.ini file holds all the path and file names needed by the software itself. To export to ASCII there is only one parameter interesting to use.
ExportPath - This parameter defines the location of the exported files. As with the HTML files this will result in subfolders per policy (f.i. ./export/MyRulebase).
ExportPath=./export
This section is mandatory for both HTML output as for exporting objects to ASCII. Please check out the section about this in the chapter about creating the HTML output for all the details.
See the corresponding section in the chapter about creating the HTML output, except for the definition of the export definition file.
ExportDef - When exporting objects using the '-e' switch on the commandline, there has to be a definition file which defines what and how to export the objects. As with all parameters this can be defined per policy. This parameter defines the definition file. for more information on the definition file, see the corresponding chapter.
Note: The example below only uses the parameters you want to use to export data to ASCII. As the .ini file can also be used to create HTML files, other options will be present. Those will be ignored when exporting to ASCII (and vice versa).
Example:
[Default] AllObjects=0 ExportDef=./CPExport.def [CompanyB] AllObjects=1 ExportDef=./CompB_CPExport.def
All the default values that can be set in the CPRules.ini can also be set using a commandline switch. For a more detailed description see that section. There is always a verbose version and a short version available and the switches are case-insensitive.
To export objects to ASCII files instead of creating HTML files, always use the 'export' switch:
--Export -e
To define the location of the exported files (default: ./export):
--ExportPath <path> -ep <path>
To define the definition file of the exported objects:
--ExportDef <path and filename> -ed <path and filename>
See the corresponding section in the chapter about creating the HTML output.
See the corresponding section in the chapter about creating the HTML output.
Example
To export ALL objects as defined in the export definition file specified:
cprules --Export --ExportDef ./defs/MyExport.def --AllObjects
The objects in the CheckPoint database can be exported to ASCII using the '-e' switch. This mode requires the definition of how to export which objects. The default file used for this is CPExport.def. A different file (per policy) can be used by using the ExportDef parameter in the CPrules.ini file or the --ExportDef commandline switch.
The export-definition file is NOT a template file. This might become an addition in the future, but till now the objecs can only be exported as a (comma/tab/...-) delimited file. This will be sufficient for exporting objects to another format, but creating advanced reports is not possible yet.
The CPExport.def consists of several sections, each defining a different table to be exported and how this should be exported. The possible parameters are described below.
Note: The files defined are overwritten and not appended, so make sure a different outputfile name is defined per section!
table - The table parameter defines the CheckPoint table to be used. Most tables come from objects_5_0.C but they are not restricted to that file (the rule-bases are typically extracted from the rulebases_5_0.fws file).
Example:
table=network_objects
name - The name parameter defines the name of the objects to be exported. This parameter is mandatory when exporting rulebases to distinguish between the different type of rulebases. for the normal security rulebase this would be 'rule', for a NAT rulebase it would be 'rule_adtr'. The latter does export the MANUAL NAT rules only, not the automatic NAT rules as these are properties of the objects themselves!
Example:
name=rule
When exporting objects, the parameter holds a wildcard for the name of the objects. So as with the class parameter, the value specified is treated as a regular expression. This parameter can be repeated several times to include more names.
Example:
name=^CUS_ name=FW
The first name statement will include all objects starting with 'CUS_'. The second statement will include all objects which holds the string 'FW' in the name somewhere.
class - The class parameter is probably the hardest one of all parameters. Every object does have a class defined (:AdminInfo:ClassName), if it is a 'normal' object or a rule in a rulebase. The class parameter defines which type of objects will be included in the export file. Several classes can be combined in one table by repeating the class parameter. To make it easier, this parameter is interpreted as a regular expression. That means the program searches for a match in the actual classname of the object. if no class is specified, all objects will be included.
Example:
class=udp_service class=^tcp
The first class statement includes all objects which have 'udp_service' in the classname. The second line includes all classnames that starts with 'tcp'.
headers - The headers parameter is optional and defines the column headers of the objects exported. The list is (white)space delimited, so unfortunately the headers themselves can not include spaces. When the class parameter is ommited, the fieldnames will be used as the header text.
Example:
headers=Name IP_address SubnetMask NAT_address GroupMembers Comments
fields - The fields parameter defines the fields of the objects to export. The list is (white)space delimited. The names of the fields can be found in the CheckPoint database files, see a few examples below. There are however a few reserved words:
Example:
fields=name ipaddr netmask valid_ipaddr type members comments
Note: In case a field holds more objects (f.i. members of a group), all objects will be listed separated by the list-separator parameter.
Note: if a field can not be found as attribute of an object, it is left empty.
separator - The separator is to define which separator is to be used in the exported file. Any character or string of characters can be used, but there are three reserved words: COMMA, TAB and SPACE. These will be translated to their respective character codes. Default value is a COMMA (',').
Example:
separator=TAB
list-separator - The list-separator parameter is used to defined which character is used to separate several objects within one field (see fields description). As with the separator parameter three reserved words can be used: COMMA, TAB and SPACE. Default value is a colon (':').
Example:
list-separator=:
outputfile - The outputfile parameter defines the name of the output file and the location of this file. if no path is specified the normal exportpath will be appended (by default './export/<Policy name>/'). if no outputfile is specified the <name of the section>.exp is used instead.
Example:
outputfile=tcp_resources.csv
Finally an example of an entire table definition is presented. This example exports all objects in the database, comma delimited:
[All network_objects] table=network_objects class= headers=Class Type Location IP Subnetmask fields=AdminInfo:ClassName type location ipaddr netmask separator=, outputfile=all_network_objects.csv
This chapter describes how the output of CPRules is setup and how it can be altered. This section is for advanced users. Normal operation of the software would not need any alterations to these settings.
The default setup creates all HTML pages with all (used) object types converted to HTML. This might well not be what you want. The page, table and section definitions enables you to change the layout to your taste.
Tip: Make a backup of the original files before changing the files described here.
Tip: Run a report and check it out before you start modifying the layout definitions.
Which tables are presented on which HTML pages and which section is presented in which table, is defined in the file called: CPPages.def. This configuration file enables you to determine what to present to your customers. Although it is possible NOT to show an entire table or NOT to show a specific section, it is NOT possible to alter the content of the specific section.
In CPPages.def the layout can be defined per policy by creating a separate section per policy. There is also a section included called [Default]. This section will be used if there is no section defined specifically for a policy. This enables you to specify a different layout for every policy if necessary, but use the default for the other policies.
The layout of a policy contains pages, tables and sections. Of these three only the page names are free to choose! The table names are defined in the Constants.pm file (described in the next paragraph). The sectionnames are hardcoded in the source files. Trying to change them might have interesting results :-).
Page - Every page definition starts with a Page={page_name} command.
table - Every table on a page is listed beneath the page definition and denoted by one or more Table={table_name} commands.
section - Every table holds one or more Section name=[OPEN|CLOSED|SKIP] definitions to define the sections to be displayed.
For the pages and tables this is straightforward. To show the structure an example without sections is shown below.
Example:
[MyRulebase] Page = Rulebase Table = Rules Table = NATRules
Page=MyPage Table=Hosts Table=Services
Page=My2ndPage Table=Resources Table=OPSEC
Now many tables consists of several sections. Every section can be SKIPped (not displayed), OPEN or CLOSED. The latter two means that the section is folded open or closed. Clicking on the section name will revert this. By default all sections are CLOSED, but this can be altered. First impressions show that larger databases display much better with all sections CLOSED, but smaller databases might well turn out better with OPENed sections.
The below (partial) example shows one page with three tables in which the Topology section is OPENed, but the other sections are CLOSED.
Example:
[MyRulebase] Page = Gateways Table = CheckPoint Check Point Products = CLOSED Cluster Members = CLOSED Sofaware Settings = CLOSED Topology = OPEN ... Table = Gateways Topology = CLOSED VPN = CLOSED Web Server = CLOSED FireWall-1 GX = CLOSED Advanced = CLOSED Table = OSEDevices Topology = CLOSED SNMP = CLOSED Setup = CLOSED
Warning: Changing table definitions is not straight-forward. You need to have thorough understanding of the Check Point database structure! However it provides an manageable way (for the author) to cope with future changes/additions Check Point comes up with.
The table definitions are in a package called Constants.pm. This Perl package holds all Check Point related constants used in CPRules.
The hash used for the table definitions is %HTMLTable and it is a bit complex. The purpose is to define which objects are to be displayed in which table AND to define the order in which they are presented within the table. A restriction is that all objects within one HTML table must be member of the same Check Point table. This table is reflected in the value of TABLE. At this time it is not possible to combine objects from different Check Point tables into one HTML table.
All Check Point objects do have a 'class' (in the database this is defined in 'AdminInfo:ClassName'). Objects of the same class have to be grouped together in one table although they can have different types. It is fine to combine different classes within one table. The best table to show this grouping is the Services table:
SERVICES => {
TABLE => 'services',
CLASS => {
'tcp_service' => '1:TCP',
'compound_tcp_service' => '2:Compound TCP',
'tcp_citrix_service' => '3:Citrix TCP',
'udp_service' => '4:UDP',
'rpc_service' => '5:RPC',
'icmp_service' => '6:ICMP',
'other_service' => '7:Other',
'dcerpc_service' => '8:DCE-RPC',
'gtp_service' => '9:GTP',
'gtp_v1_service' => '9:GTP'
}
},
The SERVICES table above is getting the objects from the Check Point table 'services'. The numbers followed by a colon (':')in the text define the order in which they will be presented in the HTML page. For instance the services with type 'tcp' are presented before the services with type 'udp'. The remainder of the text is passed to the routine that creates the HTML pages and is currently used as header text for the service subsections (see the examples).
If the CLASS of an object is not sufficient to determine the different members, it is possible to define other keys to select on. An example to explain this is seen in the gateway table definition:
GATEWAYS => {
TABLE => 'network_objects',
CLASS => {
'gateway_plain' => {
'VPN' => { '' => '1:Gateway Node' },
'VPN:AdminInfo:ClassName' => { 'vpn' => '2:Interoperable Device' }
}
}
},
The class 'gateway_plain' holds two different types of gateways. To distinguish between them we need to look at the 'VPN-ClassName' of the objects. See above how that is defined in the hash %HTMLTable. Note the 'VPN:AdminInfo:ClassName' to denote the path to the key of the object used.
There is one final possibility. The rules in a rulebase are not separate objects, but are part of a list of objects (normally rules). This case is reflected in the %HTMLTable by not defining a TYPE, but by defining a LIST:
RULES => {
TABLE => 'rule-base',
LIST => 'rule'
},
For more specific details check the code, to see what is passed exactly to the corresponding routines and how that can be handled.
Templating is used to differentiate between the codewriter and the layout people and have the best of both worlds. Implementing this is easier said than done. In this case we needed to have enough options for the codewriter to determine the layout of the tables and sections in the tables, but without needing to write actual HTML code. To fix this dilemma, we have included a template file called section.tmpl which defines the different formats information can be displayed (see below). This file is used in several other files as INCLUDE file. Now the codewriter has/can have a number of pre-defined layouts and the layout people can define the actual HTML code and influence the actual result.
This is not a codewriters guidebook. For examples of the described options one better examine the source code and the template files. The templating engine is discussed in a separate document (template.pm) and that is the place to learn about data structures used.
The section.tmpl file is used to add a section to a table. This template can be included in other template files with the 'include' statement (see the documentation of 'Templates'). The template will normally be included inside a loop, to allow for several section to be added. The layout of an object is seldom covered within one table ...
One section is always delimited by a BEGIN and END statement. Not closing of a section might result in ``interesting'' layouts :-). The following section delimiters are currently defined:
SF_BEG ... SF_END SECTION_BEGIN ... SECTION_END SECTION_HEADER COL_BEG ... COL_NXT ... COL_END
The SF stands for 'Section Folded'. It defines a section that can be folded closed or opened (see the Page Layout section). Clicking on the header of the section closes or opens the section.
{ SF_BEG => [{ SECTION => html('Topology'),
OBJ_NAME => $name,
STATE => ($state eq $_OPEN) }
] },
...
{ SF_END => 1 }
The definition above shows the three main parameters to us with SF_BEG:
SECTION - This defines the displayed name fo the section
OBJ_NAME - This defines the name of the object. This is important to uniquely identify the section name. It is used by the javascripts to open and close the section when clicked upon!
STATE - This boolean defines the section to be 'OPEN' or 'CLOSED'. In the above example, the variable $state holds the value that is assigned to this section in the 'CPpages.def' file and $_OPEN is a constant that defines the string 'OPEN'.
There are two special case of the SF_BEG statement that can be used to define special subsections and can be added to the parameter list of SF_BEG.
SUB - The SUB defines a new folded section within the current one. The SUB definition makes it possible to use a different layout for the text to indicate it is a subsection.
BUTTON - The BUTTON definition shows a button in stead of the subsection header. Clicking the button will open the section just as with a SUB definition. An example is shown below.
{ SF_BEG => [
{ SECTION => html('Advanced...'),
BUTTON => 1,
OBJ_NAME => $name,
STATE => 0 }
] },
...
{ SF_END => 1 }
The SECTION_BEGIN and SECTION_END definitions create a box or placeholder to hold the content of the section included within. Currently this is visualized by drawing a line around the section (the FIELDSET command is used for that), indicating this information is related.
{ SECTION_BEGIN => html("Office Mode for Remote Access") },
...
{ SECTION_END => 1 }
The SECTION_HEADER defines a header just like used with the SECTION_BEGIN statement, but it does not begin a section (and thus has not to be closed). It is solely used as a delimiter in the text.
{ SECTION_HEADER => html("Other related sections") }
To place two or more sections next to each other, columns can be used. The COL_BEG starts the columns, the COL_NXT initiates a new column and the COL_END closes the columns off.
{ COL_BEG => 1 },
....
{ COL_NXT => 1 },
...
{ COL_NXT => 1 },
...
{ COL_END => 1 }
To layout a section there are a few possibilities.
In some case you just need to include a simple text message or 'note' in a section. This option will do that for you. The layout of the text is determined by the CLASS suboption, which relates directly to classes defined in the cprules.css stylesheet. It is advised to use only meaningfull names, so the purpose remains clear. Currently we have defined the classes:
This is probably the most important section and certainly the most used. The section creates a table to layout the data. Every line in the table consists of a maximum of five (5) fields or columns. As this section is a table, the fields are nicely lined up beneath each other.
Below we discuss the parameters that can be used to layout the individual lines in the table. Without understanding of HTML tables this will be hard to understand.
The standard options in the SECTION:
Advanced option in the SECITON:
{ SECTION => [
{ CP2 => 1, C1 => 2,
OBJ_VAL1 => html('Renegotiate IKE (phase 1) Security associations every'),
OBJ_VAL2 => GetKey($obj, 'isakmp.phase1_rekeying_time'),
OBJ_VAL3 => html('Minutes') },
{ CP2 => 1, C1 => 2,
OBJ_VAL1 => html('Renegotiate IPSEC (phase 2) Security associations every'),
OBJ_VAL2 => GetKey($obj, 'isakmp.phase2_rekeying_time'),
OBJ_VAL3 => html('Seconds') },
{ INACTIVE => (GetKey($obj, 'isakmp.phase2_use_rekeying_kbytes') eq 'false'),
CP3 => 1,
OBJ_VAL1 => $CheckTick,
OBJ_VAL2 => html('Renegotiate IPSEC (phase 2) Security associations every'),
OBJ_VAL3 => GetKey($obj, 'isakmp.phase2_rekeying_kbytes'),
OBJ_VAL4 => html('KBytes') },
{ INACTIVE => (GetKey($obj, 'isakmp.phase2_use_rekeying_kbytes') eq 'true'),
OBJ_VAL1 => $Check,
OBJ_VAL2 => html('Renegotiate IPSEC (phase 2) Security associations every') }
] },
The TABLE section generates an actual table with lines in and around it and a special header line. It behaves generally the same as the SECTION above but lacks a few layout options.
This is a special section, as it uses the same syntax as the routine HTMLMemberList. This routine is used to get the HTML code for all the members of an object (f.i. the Participating Gateways in a VPN community). Nothing more nothing less.
This special section is used to include a ' ' in a tablecell. In case a cell is empty, the browser might not display the borders of the cell either. This section just adds a space to the cell, so the browser won't treat it as an empty cell.
The version history is supplied in a history file together with the bugfixes. This file can be viewed on the webpage http://www.wormnet.nl/cprules/history/History of CPrules.doc
Bug reports and requests for modifications can be send to Peter-Paul.Worm@wormnet.nl
Peter-Paul Worm (Peter-Paul.Worm@wormnet.nl)