References are important to prevent a lack of clarity and unambiguousness within the IT documentation. If you want to reference objects for third-party systems, for example, various attributes can be used for this task.
In order to detect already existing data, there are relevant strategies for data imports. For the most part, they refer to the attributes mentioned below. Details can be found in the corresponding articles.
Each object in i-doit receives an identifier (ID). This identifier is always unique for each i-doit tenant. The ID is a positive number greater than 0 and can have a length of up to 11 digits. It is automatically assigned by MySQL/MariaDB by incrementing the number by 1. A retroactive change of the ID by the user is not possible in order to prevent inconsistencies. When you delete objects (
Purge), the IDs are free again but they are not reusable.
The object ID is represented as the
Object ID attribute in the
The number from which the counter for the object IDs starts is determined during the setup of i-doit. The default starting number is 1.
The object ID is very important for the generation of the URIs. By means of the ID you can access objects in an unambiguous way via a link. The name of the variable is
objID. The naming structure is:
Object IDs are especially used for internal purposes, but they can also be helpful for the user or for third-party systems. The IDs are essential for API access, for example.
SYS-ID attribute is unique within all tenants and installations. For this purpose, a 10-digits (being the minimum) positive number is generated from the UNIX timestamp. This number is displayed in the
General category. It is synonymously used unhyphenated as
You can specify a prefix for each object type, which precedes the automatically generated number. You can set the prefix at
Administration → CMDB settings → Object type configuration → [Object type group] → [Object type] → SYSID prefix. If you do not specify your own prefix, the SYSID will begin with the
SYSID_ prefix. When you set an alternative prefix, the generation of the number changes: The object ID is used instead of the UNIX timestamp.
By default, the SYSID cannot be changed retroactively by the user. However, you can enable changes by activating the corresponding function at
Administration → CMDB settings → General settings → SYS-ID readonly.
It is absolutely essential that each object receives a title. This title is documented as an attribute in the
General category. Synonymously this attribute is also called
Object titles can also be assigned automatically. This is especially helpful for templates:
You can assign as many IP addresses to each object as you wish. This is done in the
Hostaddress category by creating a category entry for each IP address.
IP addresses are not unique per se. For example, in private networks the same addresses (
192.168.1.1 etc.) recur again and again. When
with overlapping network areas are documented in i-doit, there often will be objects with ambiguous IP addresses. Due to technologies like DHCP it becomes even harder to identify objects by using dynamically assigned IP addresses. Hence, this attribute is not suited for unambiguous referencing in most cases.
Hostname is assigned in the
Hostaddress category. For each object any number of host names can be documented, even if it is in many cases assigned unambiguously for each device (for example servers). As with the IP address (see above), a category entry is generated for each host name.
When you also specify the
DNS domain attribute per category entry, this automatically results in the Fully Qualified Domain Name (
Just like IP addresses, the name should be unambiguous but due to various reasons it can also be a recurring name. Oftentimes the FQDN is equated to the object title. The usage of host name or FQDN for referencing should be considered carefully.
As a rule, MAC addresses are unique worldwide since they are set by the manufacturers of the network components. The low risk of recurring MAC addresses is however only right in theory. Due to the increasing virtualization and the resulting change of MAC addresses by users, this attribute is not always the first choice for unambiguous referencing. As many MAC addresses as desired can be set by entering a MAC address for each port in the
Port (Network) category. When using technologies like bonding or trunking, the MAC address is documented in the
Logical port (Network) category.
In most cases the inventory of property is carried out across the entire organization and is therefore not only an IT-related topic (Asset Management). Each material property which is to be inventoried receives a unique number. In i-doit this number can be documented for each object in the
Inventory number attribute within the
Administration → CMDB settings → Object type configuration →
[Object type group] → [Object type] the automated generation of inventory numbers can be configured, if desired. Here various placeholders are available for creating a naming structure per object type.
Inventory numbers and QR codes offer an ideal combination and can be joined to labels. QR codes are generated for each object by i-doit. Such labels can be printed using the i-doit QR-code printer, for example.
Data from third-party system, for example from the inventory/ discovery area, can be imported to i-doit. In most cases, these systems also possess unambiguous identifiers or something similar. When these identifiers are imported, the category
Data Source can be used. This way, multiple used systems can be synchronized in order to reference objects on all systems unambiguously.
Internally, i-doit uses constants that unambiguously reference all kinds of data. A constant consists of capital letters (A-Z) and underscores (_). Such constants are used for some objects that already exist in the default installation of i-doit. The
Person object "admin", for example, has the constant
These constants cannot be viewed or even edited in the web GUI. For this reason, this is done in SQL in the database. Each tenant has a separate database in which the
isys_obj table exists. All objects are saved there. The column for the constant is called
Manipulations of the database endanger the functionality of i-doit. For this reason, we cannot provide any warranties for problems resulting from manipulations. Thus any activity should be well considered and agreed with us beforehand, if necessary.