The Webpages section

The web pages section defines what web pages are generated as well as what they look like. A few statements (like the skin and Logskin statements) are of a global nature while others (like title, table, etc.) are only applicable in conjunction with a Page statement.

Mainly you will define the basic look of your web pages via the skin and Logskin statements, then you describe the pages you would like to be generated and their contents via the Page statement and its "children" (title, refto, table, ref, itemref, image). Each page description starts with a Page statement as e.g.

 %Page top The_main_page

It will create a web page called top.html with title "The main page"

[Note]Note

The page-title must not contain spaces. To bypass this limitation underscores will be replaced by spaces.

A single Page statement will not create much more than an empty page. The lines immediately following it should define some contents. Most important in this respect is the table statement. Followed by one or more groups it will insert one table per group containing the hosts or groups in the respective group and their status. So e.g. (the group names and members are taken from the example in section Defining and using groups)

%Page top The_main_page %table EUROPE USA

will create a page with filename top.html containing two tables, one containing all the members of the group EUROPE (namely paris and london), the other containing all the members of the group USA.

[Warning]Warning

That will only list the members of a group at the next hierarchy level. The command:

 %table WORLD

will list EUROPE and USA, not washington, london, paris.

You can control how deep table digs by prefixing the group name(s) with a "+" sign. Multiple "+" signs will make table go deeper in the hierarchy.

 %table +WORLD

This will list the group members two levels below WORLD (washington, london, paris).

All the other statements (except for the image statement documented in section Using Imagemaps) will not create contents themselves. Instead they modify the behaviour of the following table statement.

%title [ title | none | auto]

Specifies the tables title. if you use the special word none instead of a title tables are created without any title, the special word auto makes table use the display name (see Defining and using groups) of the groups the respective tables are created from.

[Note]Note

auto is the suggested variation.

%itemref [directory]

Specifies the sub-directory (of www) in which the file host.check.html is. So by clicking on a status light the browser will open the respective file. Two commonly used shortcut-arguments are:

%refto [name{ url | none }]

Whenever host names or group names appear in a table Big Sister will create a hypertext link pointing to url#hostname. Usually url will be the name of a page created via bb-display.cfg and is used to point from tables showing consolidated status information to more detailed tables. Big Sister will automatically create the necessary labels each time it inserts a table in a web page. Of course you are free to use URLs pointing somewhere outside the set of auto generated pages.

refto accepts a few special pseudo-URLs: refto none will suppress hypertext linking, refto self will create links pointing to the same page.

[Note]Note

refto always applies to all rows of a table.

refto name url - the refto statement explained above always takes effect on a whole table. However sometimes it is necessary to link individual hosts or group to individual pages. Another flavour of the refto statement supports exactly this. Via e.g.

Example 3.4.  Example without name argument

%Page top Top_Page
%refto detailed 
%table WORLD 
%Page detailed Host_Details 
%itemref html 
%refto http://oursite.com/serverlist.html %table EUROPE USA

This will create two web pages top.html and detailed.html. On the first page only a single table containing rows for "Good old Europe" and "The United States" is shown. These two labels are linked to the second page where there are two tables, one listing all the hosts in the group EUROPE, one listing the hosts in the group USA. The labels in this two tables are linked to a manually created descriptive page ...serverlist.html.

Example 3.5.  Example with name argument

%refto washington /servers/washington.html

you force the following table statements to link each appearing washington label to the page /servers/washington.html#washington. No matter which comes first an individual refto always overrides a global one, so that e.g.

%Page top Top_Page 
%refto EUROPE europe 
%refto USA usa
%refto all_the_rest 
%table WORLD 
%Page europe Europe 
%refto none 
%table EUROPE 
%Page usa USA 
%refto none 
%table USA

will work correctly, thus creating three pages, one being an index page show- ing consolidated status for Europe and USA pointing to the respective pages listing the servers in Europe and USA.

Example 3.6.  Example with special argument : clear

Individual refto entries are kept across Page statements. If you need to limit scope of entries you can use the special pseudo-url clear as in this example:

%Page top Top_Page 
%refto EUROPE europe 
%refto USA usa
%refto servers 
%table WORLD 
%refto clear 
%table WORLD

This will create a table with links to the Europe and USA pages, then another table with links to the servers page.

Skins

While Big Sister strictly limits the contents of web pages to a few elements (actually tables and image maps) the way web pages look is configurable via the so called skin mechanism. A skin defines the layout of pages - to give some examples skins decide if tables get borders, if the background is white or yellow, if legends are at the top or at the bottom of a page or not present at all, if status lights are round and blinking or rather triangular and static, and so on.

Most skins do not define the whole palette of possible features. Instead, there is a basic skin (the default skin) and various skins modifying only a few layout elements - e.g. the white_bg skin will change the background to white, the static_lamps skin will replace the blinking status lights by non-blinking lights, etc. A whole set of such skins is called a skin set.

Skins appear in conjunction with the Logskin and skin statement. Logskin is used to specify the skin set Big Sister uses when creating the web pages for each checks detailed status while skin sets the default skin for everything else.

Example 3.7. Example on cgi's skins

 %Logskin white_bg %skin static_lamps,structured_bg,frames

This will make Big Sister create the HTML log pages with white background in place of the default one and all the other web pages with static status lights, a textured background and using HTML frames.

Table 3.5. Some available skins

skin namewhat is it doing with my display?
title_in_table make table titles part of the table
white_bgset pages' background to white in place of the default colored back- ground
structured_bganother alternate background
static_lampsdisplay non-blinking status lights
framesframe optimized skin
bigbro13Big Brother 1.3 like look
alt_contentsiconsespecially ugly status lights in contents frame
[Note]Note

The default skin is automatically part of any skin set, there is no need for explicitly listing it!

Skins in CGI programs

Skins are actually used by CGI programs too. In order to make Big Sister administrator's life a little bit more difficult (:-)) CGIs will not read bb-display.cfg. Instead, you can set the skin they should use via the adm/resources file. An entry like

 *.skin=structured_bg,static_lamps

in /etc/bigsister/resources will set the default skin used by every Big Sister component (including CGIs) to "structured_bg" and "static_lamps". If you replace "*" by the name of one specific utility or CGI then the setting only applies to it.

You can also select a skin via an argument to the CGI program, e.g. use

 http://..../...cgi/bshistory?SKIN=structured_bg

Frames

Have you already read section concentrating on skins?

Pages displayed in frames are in fact just a special way of layouting pages, therefore you need only use a frames-enabled skin set (e.g. one including the skin frame) and you get a layout using frames.

Anyway, there is one little problem. It is not sufficient to create all the status pages, additionally an index page defining the frame set as well as the non-status frames are needed. This is the realm of the Frameset statement of bb-display.cfg:

 %Frameset index top Monitored_by_Big_Sister

It will create an index page called index.html, the initial page displayed when entering index.html is top.html and the title of the frame set is "Monitored by Big Sister".

The statement will only work if the specified skin is frame-aware. If the skin defines a menu frame only the pages defined up to the Frameset statement will be respected.