Administrator's manual V2.0

From OneCMDB

Contents

[edit]

Overview

OneCMDB V2 is deployed within tomcat as shown by the figure below.
Image:OneCMDB V2 Overview.jpg
Desciption of the components:

  • OneCMDB Desktop
    • The front-end GUI for OneCMDB. It uses OneCMDB WSDL to communicate with OneCMDB Core and are configurable from various configuration files.
  • OneCMDB WSDL
    • Web Service interface to OneCMDB Core.
  • OneCMDB Core
    • The core functionality. Uses Spring to setup and configure.
  • Hibernate
    • Persistence engine interacts with back-end db. Supports different back-end dialects, like HSQLDB, MySQL, MSSQL etc..
  • DB
    • Back-end database.
[edit]

OneCMDB Core

The core is configured by spring. The spring bean definition are located under <install_dir>/tomcat*/ROOT/WEB-INF/
Thr following xml files are used:

  • onecmdb.xml - Static loader for classes/onecmdb.xml
  • onecmdb-remote-servlet.xml - Defines the servlet's that are available from url:
    • /http - Used to query OneCMDB Core in a RESTfull approach.
    • /classpath - Used to load classes remote, all tools under the bin-directory uses this.
  • onecmdb-xfire-webservice-servlet.xml - Defines the WSDL.
  • classes/onecmdb.xml - The main bean definition for OneCMDB.
  • classes/provider.xml - Default models to load at startup.
  • classes/datasource.xml - Defines the back-end db.
[edit]

Core Configuration

[edit]

Back-end database

See Developer's_manual_V2.0 for information.

[edit]

Initial Model

See Developer's_manual_V2.0 for information.

[edit]

Authentication Provider

OneCMDB uses Acegi Security System to authenticate users. It supports a number of different authentication providers, like Memory, LDAP (Active Directory). OneCMDB has it's own provider to support accounts stored in OneCMDB.
The providers are defined in <installdir>/tomcat*/webapps/ROOT/WEB-INF/classes/onecmdb.xml and for details in configuring check http://www.acegisecurity.org/.

[edit]

Update Service

OneCMDB core will search for new updates. It will query www.onecmdb.org for updates once every week. If a new update are found a notification will be displayed when a user login..
This can be disabled by removing the UpdateService bean in the classes/onecmdb.xml. Locate the following line 

     <ref bean="updateService" />

and comment it out like this 

     <!-- <ref bean="updateService" /> -->
[edit]

OneCMDB User Accounts

OneCMDB can be configured to authenticate a user from different types of authentication providers. The authentication provider can also provide which roles a user belongs to. This will typically be a string like ROLE_Admin. To be able to define more function to a role, a role instances must be created in OneCMDB. When a user is authenticate the OneCMDB core will loop through all roles provided and matches that with the role instances created in OneCMDB. With this approach only roles defined in OneCMDB will be used, even though the user might belong too many other roles.

Each role can then have a own desktop look, see #Desktop_Configuration for more information. Also if a user belongs to many roles, one can switch between these roles in the GUI without needing to authenticate.

[edit]

OneCMDB Desktop

[edit]

Repository

All configurations for the desktop are stored under <install_dir>/repository.
This directory can be changed by editing the file under <install_dir>/tomcat*/webapps/onecmdb-desktop/WEB-INF/classes/repository.cfg

The repository consists of the following directories:

  • Configuration - Stores generic config for the desktop.
  • Content - Any content, like icons etc. This content can be accessed from external url's.
  • CustomReports - Stores config for custom reports, like query, transform and a definition of reports shown in the desktop.
    • All reports are accessible from external URL's.
  • CustomViews - Stores config for custom views.
  • MDR - All files concerning the MDR are found here.
  • OneCMDB_Core - Stores the URL to OneCMDB core Web Service.
  • OneCMDB_Desktop - Stores configuration of the desktop, includes different views for different Roles/Users.
  • ChangeStore - All data imported to OneCMDB (Models and MDR) stores the latest committed result here.
    • Used to determine changes when the MDR/Model is opened again, especially important to handle delete correct.
[edit]

Desktop Configuration

All functions in the desktop like shortcuts and menu items on the start button is configurable through XML files. Each widget can also be configured, like which permissions (read/write/delete/classify), table columns to show, table columns order etc. Each role/user can have it's own desktop config file.
The config-files are placed under OneCMDB_Desktop folder in the repository. The following structure are used:

  • OneCMDB_Desktop
    • defaultView.xml - Default desktop config file, used when a user don't belong to a Role.
    • roles/RoleName/desktopView.xml - Desktop config file for a role with name RoleName.
    • roles/RoleName/username/desktopView.xml - Desktop config file for a specific username that belongs to role RoleName.
    • autologin/AutoLogin.xml - defines mapping between autologin id and a real username/password.
[edit]

Desktop Config file

<?xml version="1.0"?>
<OneCMDBDesktopConfig defaultWidth="1000px" defaultHeight="650px">
	<permissions>
		<readonly>true</readonly>
		<editable>false</editable>
		<deletable>false</deletable>
		<classify>false</classify>

		<default>readonly</default>
	</permissions>
	

	<menuitem text="Model Overview" iconStyle="menuitem-icon-modeloverview" asList="true">

		<widget id="cmdb-applet-widget">
			<heading>Model Overview</heading>
			<minimizable>false</minimizable>
			<params>
			</params>
			<help>http://www.onecmdb.org/wiki/index.php/User%27s_manual_V2.0#Model_Overview</help>
			<shortcut>
				<style>shortcut-model-overview</style>
				<text>Model Overview</text>
				<tooltip>Visualization of the CMDB.</tooltip>
			</shortcut>
		</widget>
	</menuitem>

	<menuitem separator="true" asList="true" />

	<menuitem text="CMDB View" iconStyle="menuitem-icon-instanceoverview" asList="true">
	...
	</menuitem>
	...
</OneCMDBDesktopConfig>

Short description on each element:

  • OneCMDBDesktopConfig - Start/End of the document.
    • defaultWidth/Height - Specifies the default widht/height of windows opened in the desktop.
  • permissions - the default permission that should be applied for all widgets. Can be overridden by specific widgets. NOTE: not all widgets support the permissions option.
  • menuitem - defines a menu item on the start button. The Menu item can contain other menu items. The text attribute defines what is shown and the iconStyle is a css tag for an icon. The asList="true" is mandatory and is used internally when parsing the config.
  • widget - Describes the widget that will be opened when the menu item is selected. The widget is identified by an id. All widgets defined can be listed by open Start->Admin->Desktop Widget List.
    • heading - defines the title on the widget.
    • params - unique parameters defined for each widget.
    • help - if a small help icon [?] should be added to the window, specifies a url to open when clicked.
    • shortcut - if this widget should be accessed as a shortcut.
[edit]

Desktop Widgets Overview

A list of available widget id's (Can be viewed by Start->Admin->Desktop Widget List in the GUI):

  • cmdb-content-browser - File Browser that supports create/edit/view of files stored on CMDB server.
    • params:
    • readonly - true/false.
  • cmdb-applet-widget - Add the <applet> tag to a frame. Will start the applet according to params.
    • params:
    • code - The java applet class to start.
    • archive - The jar achives containing classes.
    • param - Params defined by the applet. NOTE: A token parameter will be added to the applet, used for communicating with OneCMDB.
  • cmdb-url-frame-widget - Open a url in a window or a new browser window.
    • params:
    • url - The url to open.
    • newWindow - true/false Open a new browser window.
    • newWindowName - optional. Name of new browser window.
    • newWindowFeatures - optional. Features of new browser window.
  • cmdb-model-designer - Design or modify the model in OneCMDB.
    • params:
    • permissions - permissions on this widget (readonly/editable/deletable/classify).
    • rootCI - [List] Root CI's to display.
  • cmdb-model-import - Open OneCMDB model data. The model can contain template/instances/references.
    • params
    • modelRoot - Path to where models are keept.
  • cmdb-model-save
    • params:
    • modelRoot - Path to where models are keept.
    • rootCI - [List] Root CI's to display.
  • cmdb-model-delete - Remove template/instances from OneCMDB.
    • params:
    • rootCI - [List] Root CI's to display.
  • cmdb-mdr-view - The MDR window.
    • No Params
  • cmdb-model-instance-overview - A Widget that displays CI's instances in table/tree and graphs. Is the most complicated widget, see Instance_Overview_Widget_Params for more parameters.
    • params:
    • permissions - permissions on this widget (readonly/editable/deletable/classify).
    • rootCI - [List] Root CI's to display.
  • cmdb-custom-view - Show a list of custom views/reports that can be opened.
    • params:
    • customDefinition - The xml definitions containing all views.
    • rootElement - The root element name in the XML.
    • recordElement - The element to fetch iterate through.
  • cmdb-ci-property - Show properites for a specific CI.
    • params:
    • permissions - permissions on this widget (readonly/editable/deletable/classify).
    • aliad - the alias of the CI to show proerties for.
  • rootCI - specifies the where to search for references, used in the graph tab. Default is Ci.
[edit]

Data Models

Default OneCMDB have no CI model pre-loaded. The model is specified in one or many xml files.

For more information about the structure of the model files, see OneCMDB_Model_File

OneCMDB models that are currently delivered with OneCMDB are located under repository/MDR/Models/model.
The model-files are dependent on each other. There are currently no way of knowing which files are dependent on each other. Instead the files are placed with the directory structure gives information on what is requiring what. This means that files in lower level directories requires upper level files. So the Basic_Model_Demo_Instances.xml requires both Basic_Model_Template.xml and Basic_Model_References.xml.

Short description on model files:

  • BasicModel
    • Basic_Model_Template.xml - Contains all template definitions for the Basic Model.
    • Basic_Model_References.xml - Contains all reference template used by the Basic Model.
    • MDR
      • BasicModel2Nagios_MDR_Model.xml - Contains MDR model to handle transform from Basic Model to Nagios model.
      • Import2BasicModel_MDR_Model.xml - Contains MDR model to handle various imports to OneCMDB. Can be used as example to customize own import MDR.
      • NMAP2BasicModel_MDR_Model.xml - Contains MDR model to handle transform from NMAP's discovery data to BasicModel.
    • Demo_Instances
      • Basic_Model_Demo_Instances.xml - Contains demo instances of the Basic Model.
  • User_Roles
    • Demo_Users_Roles.xml - Contains instances of user cmdb-admin,cmdb-user,cmdb-guest and nagios and roles ROLE_Admin, ROLE_User, ROLE_Guest and ROLE_Nagios. Each role have it's own desktop view when logging in.
  • Nagios_Model
    • Nagios_Model.xml - Contains OneCMDB model representation of the Nagios Object Model.
  • NMAP_Model
    • NMAP_Model.xml - Contains model that is used to populate from nmap's xml discovery output.
[edit]

MDR Setup

[edit]

MDR - Quick Setup Guide

  1. Open Start->System->System Editor
  2. Browse to Root/MDR and select MDR_ConfigEntry.
  3. Create a new template with a unique alias, like MDR_MyConfig.
  4. Optinal, create own attributes.
  5. Open Start->System->System View
  6. Browse to Root/MDR and select MDR_Reposiotry.
  7. Switch to Edit Allowed.
  8. Create a new instance of MDR_Repository.
  9. Specify a Name, like MyMDR, and set Config Alias to MDR_MyConfig and press Save.
  10. Open MDR, and select MDR Details.
  11. Select MDR MyMDR and add a new config instance with the "Add" button.
  12. Specify program, say bin/myscript and press save.
  13. Go to a file browser or a shell and create the directory repository/MDR/MyMDR.
  14. Create the script under repository/MDR/MyMDR/bin/myscript.[bat|sh]
  15. Open MDR and try to execute your script.
  16. For example script check under repository/*/bin/

For more details see below.

[edit]

MDR Basics

The MDR consist of two parts

  • The MDR Model Templates
    • MDR_Repository - Instances of this template defines one MDR.
    • MDR_ConfigEntry - Belongs to a MDR_Repository instances and defines one configuration set for the MDR.
    • MDR_HistoryEntry - Keep track of execution status for each configuration. Generated by the OneCMDB.
  • repository/MDR/* - The actual config files and scripts that performs the execution of the MDR.

The Name attribute in an instances of MDR_Repository identifies a HOME_DIR for the MDR. The HOME_DIR is located under <installdir>/repository/MDR/MDR Name. A specific MDR_ConfigEntry template can be specified for each MDR instance. The reason to do that is that all attributes defined in the MDR_ConfigEntry is passed as arguments to the script executing the MDR. So if one would like to have specific configurable input parameters one creates a new template that derives from MDR_ConfigEntry that defines this attribute. Then the MDR_Repository instance specifies the template alias in the attribute configAlias.

Example 

    MDR_Repository derivedFrom MDR
       Name=NMAP_Dicovery
       configAlias=NMAP_NMAP_Config

    MDR_NMAP_Config derivedFrom MDR_ConfigEntry
       network=192.168.1.0/24
       program=bin/nmap_discovery

This example shows the NMAP MDR. Here we want to control different network's to scan. Therefore we define a new template called MDR_NMAP_Config and configure the MDR_Repsoitory instance NMAP_Discovery to use MDR_NMAP_Config. The program's path, defined in MDR_NMAP_Config, is relative to the HOME_DIR of the MDR. So the directory structure for NMAP_Discovery is as follows:

  • repository/
    • MDR/
      • NMAP_Discovery/
        • bin/nmap_discovery
[edit]

MDR exceution

The MDR normally performs the following steps

  • Collect the external data.
  • Transform the collected data.
  • Upload the transformed data.

All attributes defined in the MDR_ConfigEntry will be passed to the script specified as program (the login token, used to communicate with OneCMDB is also passed in).

If one don't specify any extension on the program, then the execution will append .bat for Windows and .sh for linux. The arguments passed in will be formatted according to

  • Linux
    • --attrAlias value
  • Windows
    • /attrAlias:value

Support for other scripting languages exists. Edit the following file repository/OneCMDB_Core/Configuration/ShellMapper.cfg. 

# Map file extensions to shell's to execute.
*.bat=CMD /C
*.sh=/bin/bash
*.pl=/usr/local/perl
[edit]

Collect data

This can be any program that can generate output in csv or xml format. If data is online accessible from a file or a db this steps is not required.

[edit]

Transform data

The program to use here is <installdir>/bin/transform.[sh|bat] which takes the following arguments: 

# bin/transform.sh -?
Options:
--url   WSDL URL excluding ?WSDL
        defaultValue=http://localhost:8080/webservice/onecmdb
--username      The user to login as.
        defaultValue=admin
--pwd   The user to login as.
        defaultValue=123
--token Used instead of username/pwd
        defaultValue=null
--model Path to model file
        defaultValue=null
--transform     Path to transform model file
        defaultValue=null
--name  Name of dataset to use in the transform
        defaultValue=null
--fileSource    URL to file data source.
        defaultValue=null
--jdbcSource    JDBC dataSource configuration
        defaultValue=null
--output        Output file, - stdout
        defaultValue=-
--valueMap      {name1}=value1,{name2}=value2
        defaultValue=null
--sourceType    Type of fileSource data xml, csv
        defaultValue=null
--transformType Type of input transform, [simple|complex]
        defaultValue=complex
--csvProperty   Properties for CSV data source, [headerLines=n,delimiter=x,colTextDel=x]
        defaultValue=headerLines=1,delimiter=|,colTextDel="
--source        Path to source description
        defaultValue=null

Example from NMAP. 

"%ONECMDB_HOME%/bin/transform.bat" --valueMap {network}=%NAME% --token %TOKEN% 
--transform conf/nmap-simple-transform.xml --fileSource file:result/nmap-network-%NAME%.xml 
--sourceType xml --name nmap-transform --transformType simple --output result/nmap-onecmdb-%NAME%.xml

Short argument description

  • --valueMap - defines values that can be used in the transform.
  • --token - identify yourself to OneCMDB.
  • --transform - how the input data should be transformed to OneCMDB data. See #Transform_Syntax for info about syntax.
  • --fileSource - the input data to transform.
  • --sourceType - the type of the input data.
  • --name - the name of the transform, specified in conf/nmap-simple-transform.xml
  • --transformType - simple means that it is easier to write the transform rules, before this was somewhat complex
  • --output - where the output should be placed, "-" will direct the output to stdout.
[edit]

Upload data

Use the following script <installdir>/bin/upload.[sh|bat] 

# bin/upload.sh -?
Options:
--url   WSDL URL excluding ?WSDL
        defaultValue=http://localhost:8080/webservice/onecmdb
--username      The user to login as.
        defaultValue=admin
--pwd   The user to login as.
        defaultValue=123
--token Used instead of username/pwd
        defaultValue=null
--postURL       URL to post changes to
        defaultValue=http://localhost:8080/onecmdb-desktop/onecmdb/change
--history       History entry for this upload
        defaultValue=null
--input Input file
        defaultValue=null

The uploaded file can then be compared with the previous committed file.

[edit]

Specifying DataSource Property File

Simple files can be specified by the --fileSource option, but to specify a jdbc connection a property file can be used. The --source option is used to specify this property file.

[edit]

JDBC DataSource Property

Example to connect to a MySQL database. The query will select all columns in the table tablename.
Note: A jar-file containing the specific jdbc driver need's to in OneCMDB classpath.(Place it under <installdir>/tomcat*/ROOT/WEB-INF/lib). 

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
	<comment>Example of a JDBC Data Source description.</comment>

	<entry key="type">jdbc</entry>
	<entry key="db.user">username</entry>
	<entry key="db.password">password</entry>
	<entry key="db.url">jdbc:mysql://hostname:port/dbinstance</entry>
	<entry key="db.driverClass">com.mysql.jdbc.Driver</entry>
	<entry key="db.query">
		select * from tablename;
	</entry>
</properties>
[edit]

CVS DataSource Property

Example that open a file formatted as row/col. 

<?xml version="1.0" encoding="ISO-8859-1"?> 
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd"> 
<properties> 
	<comment>Application Data Source description, CSV</comment> 
	
	<entry key="type">csv</entry> 
	<entry key="csv.url">file:import/cmdb_application.csv</entry> 
	<entry key="csv.headerLines">2</entry> 
	<entry key="csv.delimiter">,</entry> 
	<entry key="csv.colTextDel">"</entry> 
</properties>
  • csv.headerLines=2 means that the import will skip the first 2 lines in the import file, regarded as header lines.
  • csv.delimiter=, means that each column is separated by ,
  • csv.colTextDel=" means that the text in the column is surrounded by ".
    • Like this "value1","value2","etc.."
[edit]

XML DataSource Property

Is the simplest of them all. 

<?xml version="1.0" encoding="ISO-8859-1"?> 
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd"> 
<properties> 
	<comment>System Data Source description, xml</comment> 
	
	<entry key="type">xml</entry> 
	<entry key="xml.url">file:import/cmdb_systems.xml</entry> 
</properties>
[edit]

Transform Syntax

The purpose of the transform is to generate instances of different templates and populate them with attribute values. The values can include references to other instances. The transform is designed to support row/col input data like csv or sql query or tree structure xml data. The main structure of the transform will hold for both cases. The difference is how to select the external data. In csv/sql the select specifies the col, in xml it's an xpath expression.

Short description on the element in the examples below:

  • onecmdb-transform - the start/end tag for the xml document.
    • name - specifies a name for this transform. Must map to --name option in the transform.[bat|sh] script.
  • DataSet - defines how to transform different columns into instances and attributes of a specific template.
    • name - identifies the DataSet inside the document to be able to references it.
  • InstanceSelector - identifies which template should be used to instantiate an instance.
    • template - The name of the template to instantiate from. Can be overridden by the templateSelector attribute. Note: The template alias is case-sensitive.
    • templateSelector - Can be used if the input data contains information about which template to instantiate from.
  • AttributeSelector - identifies the mapping between the external data (column/element) to an attribute.
    • name - identifies the attribute defined in the template, it reflects the alias of the attribute. Note: The attribute alias is case-sensitive.
    • natrualKey - One or more attribute can be regarded as a naturalKey. This means that the transform will not create more than one instance where the natural key attribute values are the same. It will also match the attribute set in OneCMDB to find already committed instances in OneCMDB.
  • ComlexAttributeSelector - specifies a reference to another instance generated from another DataSet.
    • NOTE: For row/col the reference instance must exists in the same row. For XML one can change the scope (Node) by specifying selector attribute. It's relative from the current node.
    • dataSet - specifies which instance that this attribute should reference. NOTE: the attribute needs to have a Complex Type set that matches.
  • DefaultAttributeSelector - sets a value specified in the transform, not fetched from the external source. The transform also support passing in variables. See --valueMap option in the transform.[bat|sh].

CSV Example:
The input csv file contains the following columns: 

 
1System.Type,2System.Hostname,3System.IPAddress,4System.IPv6Address,5System.MAC_Address,6System.SerialNumber,7OS.Type,8OS.Version\
,9OS.Familly,10OS.LicenseKey,11Network.Name

Transforms to instances of templates System,OS (or children of these, template alias specified by the column 1,7) and Network. 

<?xml version="1.0" encoding="UTF-8"?>
<onecmdb-transform name="csv2systems">
	<DataSet name="system">
		<InstanceSelector template="System" templateSelector="1" />
		<AttributeSelector name="Hostname" naturalKey="false" selector="2" />
		<AttributeSelector name="IPAddress" naturalKey="true" selector="3" />
		<AttributeSelector name="IPv6Address" naturalKey="false" selector="4" />
		<AttributeSelector name="MAC_Address" naturalKey="false" selector="5" />
		<AttributeSelector name="SerialNumber" naturalKey="false" selector="6" />
		<ComplexAttributeSelector name="Network" naturalKey="true" dataSet="network" />
	</DataSet>
	
	<DataSet name="os">
		<InstanceSelector template="OS" templateSelector="7" />
		<AttributeSelector name="Version" naturalKey="false" selector="8" />
		<AttributeSelector name="Family" naturalKey="false" selector="9" />
		<AttributeSelector name="LicenseKey" naturalKey="false" selector="10" />
		<ComplexAttributeSelector name="InstalledOn" naturalKey="true" dataSet="system" />
	</DataSet>
	

	<DataSet name="network">
		<InstanceSelector template="Network"/>
		<AttributeSelector name="Name" naturalKey="true" selector="11" />
	</DataSet>
	
</onecmdb-transform>

Short XML Example: Input xml document (NMAP output) 

<?xml version="1.0" encoding="UTF-8"?> 
<?xml version="1.0" ?>
<?xml-stylesheet href="nmap.xsl" type="text/xsl"?>
<!-- Nmap 4.76 scan initiated Tue Feb 10 19:37:12 2009 as: D:\appl\OneCMDB2.0.0Beta\nmap-4.76\nmap.exe -T3 -sS -F 
-oX result\nmap-network-network-1.xml --host-timeout 30s 192.168.1.0/24 -->
...
<host starttime="1234291032" endtime="1234291063">
	<status state="up" reason="arp-response"/>
	<address addr="192.168.1.1" addrtype="ipv4" />
	<address addr="00:18:4D:8C:49:16" addrtype="mac" vendor="Netgear" />
	<hostnames />
	<ports>
		...
	</ports>
</host>
...

A snapshot of the transform that create instances of NMAP_Host and reference all to one NMAP_Network instance. (natrualKey="true" for the DefaultAttributeSelector) 

<onecmdb-transform name="nmap-transform">
	<DataSet name="nmap-network">
		<InstanceSelector match="/" template="NMAP_Network"/>
		<DefaultAttributeSelector name="name" value="{network}" naturalKey="true"/>
	</DataSet>
	<DataSet name="nmap-host">
		<InstanceSelector match="//host[status[@state='up']]" template="NMAP_Host"/>
		<AttributeSelector name="ipv4Address" selector="address[@addrtype='ipv4']/@addr" naturalKey="false"/>
		<AttributeSelector name="ipv6Address" selector="address[@addrtype='ipv6']/@addr" naturalKey="false"/>
		<AttributeSelector name="hostname" selector="hostnames/hostname/@name" naturalKey="true"/>
		<AttributeSelector name="macAddress" selector="address[@addrtype='mac']/@addr" naturalKey="true"/>
		<AttributeSelector name="macVendor" selector="address[@addrtype='mac']/@vendor" naturalKey="false"/>
		<ComplexAttributeSelector name="network" dataSet="nmap-network" selector="../.." naturalKey="true"/>
	</DataSet>
	...
</onecmdb-transform>
[edit]

Custom View/Report Setup

The custom views and reports are both using the Custom View Widget (id=custom-view-widget). Inside this widget one specifies

  • customDefinition - which references a xml file defining the different custom views/reports.

The xml file looks like this: 

<CustomViews>
	<CustomView>
		<name>Nagios View</name>
		<description>Specilized view for nagios.</description>
		<group>Nagios</group>
		<definition>CustomViews/Nagios/NagiosView.xml</definition>
	</CustomView>
	<CustomView>
		<name>Systems</name>
		<description>Specilized view for system/network/OS CI:s.</description>
		<group>CMDB</group>
		<definition>CustomViews/CMDB/CMDB_Systems_View.xml</definition>
	</CustomView>
...
</CustomViews>

NOTE: For custom report's the tag is set to CustomReports and CustomReport. That is configurable in the Custom View Widget by

  • rootElement - set to CustomViews/CustomReports
  • recordElement - CustomView/CustomReport

The intereting part is the definition tag. That points to a xml-document specifying specific widgets to be opened with it's own configuration, widgets available #Desktop_Widgets.

[edit]

Custom View Setup

Often the cmdb-model-instance-overview is used for custom views. It is configured to only show specific templates and filter which attribute should be visible etc. See Instance_Overview_Widget_Params for details.
Example of a custom view definition file (Showing NMAP specific templates). 

<?xml version="1.0"?>
<CustomView>
	<widgets>
		<widget asList="true" id="cmdb-model-instance-overview">
			<heading>NMAP View</heading>
			<width>800px</width>
			<height>600px</height>
			<permissions>
				<readonly>true</readonly>
				<editable>false</editable>
				<deletable>false</deletable>
				<classify>false</classify>
			</permissions>
			<params>
				<rootCI asSimpleList="true">NMAP_Host</rootCI>
				<rootCI asSimpleList="true">NMAP_Network</rootCI>
				<rootCI asSimpleList="true">NMAP_TCP_Port</rootCI>
				<rootCI asSimpleList="true">NMAP_UDP_Port</rootCI>
				<table>
					<visible>true</visible>
				</table>
				
				<tree>
					<visible>true</visible>
				</tree>
		
				<graph>
					<visible>true</visible>
					<code>org.onecmdb.rest.graph.utils.applet.AppletLaunch.class</code>
					<archive>onecmdb/content/Content/applet/onecmdb-applet.jar, onecmdb/content/Content/applet/onecmdb-applet-dependencies.jar</archive>
					<param>
						<url>${baseURL}/onecmdb/query</url>
						<rootCI>Ci</rootCI>
						<appletlaunch.callcode>org.onecmdb.rest.graph.applet.InstanceViewApplet</appletlaunch.callcode>
						<appletlaunch.color.background>FFFFFF</appletlaunch.color.background>
						<appletlaunch.splash>onecmdb/content/Content/applet/applet-loading.gif</appletlaunch.splash>
						<appletlaunch.splasherror>onecmdb/content/Content/applet/applet-error.gif</appletlaunch.splasherror>
						<appletlaunch.version>1.5.0</appletlaunch.version>
						<iconURL>${baseURL}/onecmdb/icon</iconURL>
						<graphBackgroundColor>0x454545</graphBackgroundColor>
					</param>
				</graph>
			</params>
		</widget>
	</widgets>
</CustomView>
[edit]

Custom Report Setup

All reports is accessible from a URL. The URL is as follows:
http://localhost:8080/onecmdb-desktop/onecmdb/export/systems.csv?name=CMDB/system/cmdb_system_os.cfg
Where the name option specifies the query and how to transform it. The /systems.csv is not mandatory but that will save the report under that name if save as in the browser is used.
The cmdb_system_os.cfg file looks like this: 

contentType=text/xls
xmlStyle=tree
queryFile=CustomReports/CMDB/system/query_system_os.xml
xsltFile=CustomReports/CMDB/system/transform_system_csv.xslt

Where:

  1. contentType - Specifies the mime type the page will be loaded as.
  2. xmlStyle - Specifies how the default format from OneCMDB should be produced. For details see #OneCMDB_Query.
    1. onecmdb - Default format for OneCMDB. Support both templates and instances in the same document.
    2. tree - The resulting CI instances are organized in a xml tree structure.
    3. graph - The CI instances are labeled as Node and refreneces as Edge.
  3. queryFile - Contains the actual query to OneCMDB. For details see #OneCMDB_Query.
  4. xsltFile - Optional a XSLT-file that transforms the raw data into something good-looking.

To add this to a custom report in the GUI simple define a definition file like this (uses the cmdb-url-frame-widget): 

<?xml version="1.0"?>
<CustomView>
	<widgets>
		<widget asList="true" id ="cmdb-url-frame-widget">
			<heading>Basic Model Systems</heading>
			<params>
				<url>onecmdb/export/system.xls?name=CMDB/system/cmdb_system_os.cfg</url>
			</params>
		</widget>
	</widgets>
</CustomView>
[edit]

CI Icons

Each CI have an attribute Icon. It's defined in the Root template. This attribute specifies which icon an CI will display in certain views. The benefit of having this as a user-defined attribute is that the value will propagate down to it's children. This attribute only specifies a symbolic name of an icon not the icon file itself. The mapping between the name and the actual icon file is configured in <installdir>/repository/OneCMDB_Core/Configuration/IconMapping.cfg This file looks like this: 

...
NMAP_TCP_Port=Content/Images/icons/tcp_16x16.gif
NMAP_UDP_Port=Content/Images/icons/tcp_16x16.gif


CMDBAccount=Content/Images/icons/people16.gif

# Relation icons
RelationOutboundIcon=Content/Images/icons/reference-outbound-16x16.gif
RelationInboundIcon=Content/Images/icons/reference-inbound-16x16.gif

# Specific icons.

ci.icon.linux=Content/Images/icons/linux16.gif
ci.icon.mswindows=Content/Images/icons/mswindows16.gif
ci.icon.windows_xp=Content/Images/icons/mswindows16.gif
ci.icon.windows_vista=Content/Images/icons/vista16.gif
...

One can define a icon for each template by specifying
alias=Path/To/IconFile.gif
The path is relative to the repository directory, so all icons must be placed in the repository.

Another way is to use the icon attribute's value.
ci.icon.value of icon attribute=Path/To/IconFile

[edit]

FAQ

[edit]

Change Tomcat port number 8080

See Admin FAQ

[edit]

Change the admin password/username

See Admin FAQ

[edit]

Deploy OneCMDB in an existing tomcat container

See Admin FAQ

[edit]

Appendix

[edit]

OneCMDB Query

See OneCMDB_Query

Retrieved from "http://www.onecmdb.org/wiki/index.php?title=Administrator%27s_manual_V2.0"
Community and support