Deprecated: Function split() is deprecated in /storage/content/94/122194/onecmdb.org/public_html/wiki/includes/Parser.php on line 2719 Deprecated: Function split() is deprecated in /storage/content/94/122194/onecmdb.org/public_html/wiki/includes/Parser.php on line 2773 Deprecated: Function split() is deprecated in /storage/content/94/122194/onecmdb.org/public_html/wiki/includes/Parser.php on line 2773 Tutorial V1.0 - OneCMDB

Tutorial V1.0

From OneCMDB

Contents

Overview

OneCMDB is a configuration management database (CMDB) for data centers. Configuration stored in the database can be hardware, software, services, customers, incidents, problems, RFCs, documents, etc. OneCMDB conforms to IT Management best practice declared by ITIL, IT Infrastructure Library.



OneCMDB is ready to use as is, but you probably want to develop your own applications to extend the functionality of OneCMDB. For example develop your own graphical user interface, add/modify business logic, interface external systems, etc. Note OneCMDB License for distribution of OneCMDB software and derivated work.

OneCMDB consists of two main parts:

  • OneCMDB Core
  • OneCMDB GUI

The Core implements the business logic of configuration management and the GUI provides a web based interface to core.
Image:OneCMDBoverview.jpg

OneCMDB Core

The Core implements the business logic of configuration management in OneCMDB.
Image:OneCMDBCore.jpg

Configuration Items

You enter data into the CMDB (Core) by creating configuration items (CI). A typical CI is a server in your datacenter. A more abstract CI is a service level agreement (SLA) with a customer. A CI may reference other CIs. A typical case for using a reference is that some data is used by many CIs, and by putting that data in its own CI and reference it, you maintain the data in a single place.

Image:OneCMDBCoreCis.jpg
Each CI has a set of attributes. It's the attributes that stores the data of a CI. There are two categories of attributes:

  • identification attributes
  • user-defined attributes

Image:Ciattr.jpg

Identification attributes

The identification attributes always exists for a CI. As the name indicate we use the attributes to keep track of the CI. Identification attribute value you generally only modify when creating an CI.

Image:Ciattrident.jpg

  1. Id is a unique string that never change for a CI.
  2. Alias is used for identification when importing and exporting CIs, and in different menus in the GUI.
  3. Displayname is used by the GUI for short textual presentation of a CI and may include variables and whitespaces.
  4. Description is used by the GUI for long textual presentation of a CI.
  5. Template option is set for templates. A CI may serve as template for creating other CIs, see templates.
  6. Icon attribute is used by the GUI for graphically presenting a CI. In case of template, we decorate the icon with a small 'T'.


See OneCMDB GUI presentation of identification attributes.

User-defined attributes

To store your data in a CI you first need to add your own attributes to it. What attributes you need is completely up to you and what you need to store in the CMDB. Here is a simple example of a Server CI:
Image:Ciattruserdef.jpg


See OneCMDB GUI presentation of user-defined attributes.

Attribute value types

When you create a new attribute you must set the type of value it will contain. There are two type-categories:

  • Built-in
  • Reference

Built-in are primitive types, e.g. string and integer.
Image:Ciattrtypebuiltin.jpg

Reference is a pointer to another CI. See references.
Image:Ciattrtyperef.jpg

Attribute value list

Both built-in and reference attribute values can be lists. E.g. an attribute called "Ips" can contain a list of strings and an attribute called "Hardisks" can contain a list of references to HDD CIs.

Image:Ciattrlist.jpg


See OneCMDB GUI presentation of creating a attribute value list.

References

A reference is a pointer to another CI. There are several reason to use references:

  • It's hard to maintain data that is copied to many CIs. Instead, put the data in a single CI and let all other CIs reference it. If you want modify the data you only have to update one CI in OneCMDB.
  • You want to see who depends on a certain CI. Assume you want to shutdown a switch, which computers will then be affected? Let the switch CI have references to all computers connected to it, you will then automatically get help from OneCMDB to list all servers depending on it.
  • Detection of erroneous configuration in your datacenter. Assume a global IP address only may be used by single server. Let's store each IP address in it's own CI and let a server point to the IP (CI) it uses. OneCMDB may now help you to detect when a IP address is used by several servers by counting references to the IP CI.

Also see attributes.

You may define your own types of references. There are several reasons to define different types of CIs:

  • Impact analysis, typically prefomed when handling requests for change (RFCs) or acting proactively to incidents. E.g. you want to differ between "this system is required for the service to work" and "this subsystem is useful for the service".
  • Filtering dependencies. If you try to visualize the dependencies between a set of CIs you may have a hard time to understand anything due to compexity. Then, imaginate that you say "only show me CIs with hardware dependencies" and the picture becomes much less complex.

The default model only includes two: uses and triggers

Policies

Policies controls how OneCMDB handle changes to CIs. There are four default policies:

  1. CiPolicy
  2. AttributePolicy
  3. EventPolicy
  4. PolicyTrigger
You configure OneCMDB by editing the policy attributes.

You must restart OneCMDB to enable changes to a policy, just [Apply] is not enough.

CiPolicy

Controls the creation of new CIs and the CI attributes.

AttributePolicy

Controls CI attributes.

EventPolicy

PolicyTrigger

Jobs and triggers

Jobs are programs OneCMDB calls. You have CIs that contains the input parameters to the external program. The output from your program can be feedback to new or existing CI in the database.

In the single user edition we deliver three default jobs:

  • Automatic discovery of systems, calls the external program Nmap
  • Export, calls internal Java program that creates an XML file of your data in the CMDB
  • Import, calls internal Java program that reads an XML file and inserts the data into the CMDB


Jobs can be triggered manually or scheduled.

Change log

Every change you do to a CI is logged automatically. OneCMDB requires a Request For Change (RFC) to execute a change. In the change log you can see every change associated with a RFC id.

See OneCMDB GUI presentation of the change log.

Templates

A CI may serve as template when creating other CIs. A template CI has the template option set, see identification attributes.

Image:Template.jpg

There are several reasons to use templates:

  • It simplifies creation of new CIs.
  • It simplifies update of groups of CIs. There is a bound between the template and the created CI even after the creation. For example, when you add a new attribute to a template the attribute will also be added to all existing CIs based on the template.
  • It allows you to put restrictions on certain groups of CIs.

Inheritance

Inherit means that attributes in a template CI are copied to the CI when the CI is created. If you modify an existing CI the changes will propagate to all CIs based on it. You control the exact behavior through configurable policies, see policies.

We have a few restrictions on how you can use inheritance:

  • A CI can only inherit from a template CI.
  • A CI can only inherit from one template CI.
  • A template CI can inherit another template CI.


In the default model further down, the blue lines and triangles show inheritance while the black arrows show a reference. An inheritance triangle between two CIs points towards the parent.

To make life simple for you ;-) we actually use some other terminology for inherit throughout manuals and GUIs. We sometimes say based on, descendant or offspring. This will be corrected in coming releases.

Default model

The model defines the structure/metadata of the database. It consists of two parts, user defined and built-in CIs.

  • User defined - you can consider user defined CIs to be items close to your production, e.g. server or a document.
  • Built in - certain CIs that OneCMDB need to create a base for the user defined CIs. You could can see the built in CIs as configuration parameters of OneCMDB that you in a normal application would find in a configuration file.

For administrating your datacenter you only have to bother about the user defined CIs. If you develop OneCMDB or applications using OneCMDB then built-in CIs may be of interest to you.

The image below depicts the main part of the user-defined part delivered in single user edition.
Image:DefaultModel.gif
The model is declared in an XML file, <onecmdb_install_dir>/tomcat-5.5.17/webapps/ROOT/WEB-INF/classes/DefaultModel.xml. It includes both templates and instances, but it is possible split it into several files, see Developer's_manual.
OneCMDB will only read the file the first time you start OneCMDB. The file is used for initially populating the database. See how to reset the database.

Through OneCMDB's graphical user interface you are free to modify the model so it fits your datacenter. That is, modifying the structure of the CMDB is a configurational function provided by the user interface, not a programmatic customization of the application!

If you modify a template the changes will propagate to all instances/templates based on it, you control the exact behavior through configurable Policies.

To simplify browsing of CI:s in the GUI we have "Folder" items in the default model. The purpose of an Folder item is to list instances based of the same Template. Technically the folder has a pointer to every instance it lists.

OneCMDB GUI

Use a standard web browser to access the graphical user interface of OneCMDB. The URL depends on your installation. The single user edition starts a web server on your local computer and you access it at http://localhost:8080/. The GUI session will time-out after some time of inactivity, you are then directed to the start page.

Mode

OneCMDB GUI has two modes, user and designer mode. The major difference is that user mode doesn't show templates.

User mode

You switch to User mode by using the drop down menu in the upper-right corner of the GUI.

Image:Ss-usermode.jpg
In user mode you only see and manage instances.
The starting point is set to the instance Data Center.
An specific instance is not accessible unless you can browse to it from another instance. This means that you may have to switch to designer mode to be able to access it.

Designer mode

You switch to Designer mode by using the drop down menu in the upper-right corner of the GUI.

Image:Ss-designermode.jpg In designer mode you manage both templates and instances. All existing CIs are accessible via the ROOT template, visable at the top of the Template chain window.
The template structure is a tree. At the top you found the ROOT template and at the bottom instances.

Windows

The GUI has four Windows:

  1. Search
  2. History
  3. View/Edit
  4. Template chain




  • Use Search to find CIs in the database that have some properties that match the entered search string. The result is presented in the View/Edit window
  • History presents configuration CIs you've visited. Items are listed in visited order and may show up several times in the window.
  • View/Edit shows the current CI. Press Edit button to modify the attributes. Pointers to/from the current CI to other CIs are represented as links.
  • Template Chain shows how templates are based on each other (inheritance). It's a tree structure with a single root CI, "the stamfader". Note, Template Chain is only visible in Designer mode.

The color orange highlights the current CI and edit or view state.

You play one of two roles when using OneCMDB. The user and designer role are only separated on a gui level in the single user edition. The Team edition will support a secure separation of users.

Search

History

View/Edit

Identification attributes

User-defined attributes

Following image shows the OneCMDB GUI window for user-defined attributes. You can see user-defined attributes both in user- and designer mode, but designer mode shows additional info per attribute:



You create a list attribute by setting occurrences to greater than 1 in the OneCMDB GUI, when creating an attribute. Here is an example:


References


Descendants

Change log

Template chain

Template chain windows shows which templates your current CI inherits its attributes from, all the way up to the ROOT template.



Customized GUI

You may customize the GUI. It's a standard implementation of a web application using style sheets, JSP, taglibs, etc.
You may also develop your own graphical user interface from scratch. Put your own web application (java servlet/jsp) on the web server or develop a stand-alone application that access OneCMDB core directly.

For detailed information about customizing or developing new GUIs see Developer's manual.

Community and support