1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>Object Inheritance</title>
<STYLE type="text/css">
<!--
.Default { font-family: verdana,arial,serif; font-size: 8pt; }
.PageTitle { font-family: verdana,arial,serif; font-size: 12pt; font-weight: bold; }
-->
</STYLE>
</head>
<body bgcolor="#FFFFFF" text="black" class="Default">
<p>
<div align="center">
<h2 class="PageTitle">Object Inheritance</h2>
</div>
</p>
<hr>
<p>
<strong><u>Introduction</u></strong>
</p>
<p>
This documentation attempts to explain object inheritance and how it can be used in <a href="xodtemplate.html">template-based object definitions</a>.
</p>
<p>
One of my primary motivations for adding support for template-based object data was its ability to easily allow object definitions to inherit various properties from other object definitions. Object property inheritance is accomplished through recursion when Nagios processes your configuration files.
</p>
<p>
If you are still confused about how recursion and inheritance work after reading this, take a look at the sample object config files provided in the distribution. If that still doesn't help, drop an email message with a <i>detailed</i> description of your problem to the <i>nagios-users</i> mailing list.
</p>
<p>
<strong><u>Basics</u></strong>
</p>
<p>
There are three variables affecting recursion and inheritance that are present in all object definitions. They are indicated in red as follows...
</p>
<p>
<pre>
define <i>someobjecttype</i>{
<i>object-specific variables</i> ...
<font color="red">name <i>template_name</i></font>
<font color="red">use <i>name_of_template_to_use</i></font>
<font color="red">register [0/1]</font>
}
</pre>
</p>
<p>
The first variable is <i>name</i>. Its just a "template" name that can be referenced in other object definitions so they can inherit the objects properties/variables. Template names must be unique amongst objects of the same type, so you can't have two or more host definitions that have "hosttemplate" as their template name.
</p>
<p>
The second variable is <i>use</i>. This is where you specify the name of the template object that you want to inherit properties/variables from. The name you specify for this variable must be defined as another object's template named (using the <i>name</i> variable).
</p>
<p>
The third variable is <i>register</i>. This variable is used to indicate whether or not the object definition should be "registered" with Nagios. By default, all object definitions are registered. If you are using a partial object definition as a template, you would want to prevent it from being registered (an example of this is provided later). Values are as follows: 0 = do NOT register object definition, 1 = register object definition (this is the default). This variable is NOT inherited; every (partial) object definition used as a template must explicitly set the <i>register</i> directive to be <i>0</i>. This prevents the need to override an inherited <i>register</i> directive with a value of <i>1</i> for every object that should be registered.
</p>
<p>
<strong><u>Local Variables vs. Inherited Variables</u></strong>
</p>
<p>
One important thing to understand with inheritance is that "local" object variables always take precedence over variables defined in the template object. Take a look at the following example of two host definitions (not all required variables have been supplied):
</p>
<p>
<pre>
define host{
host_name bighost1
check_command check-host-alive
notification_options d,u,r
max_check_attempts 5
<font color="red">name hosttemplate1</font>
}
define host{
host_name bighost2
max_check_attempts 3
<font color="red">use hosttemplate1</font>
}
</pre>
</p>
<p>
You'll note that the definition for host <i>bighost1</i> has been defined as having <i>hosttemplate1</i> as its template name. The definition for host <i>bighost2</i> is using the definition of <i>bighost1</i> as its template object. Once Nagios processes this data, the resulting definition of host <i>bighost2</i> would be equivalent to this definition:
</p>
<p>
<pre>
define host{
host_name bighost2
check_command check-host-alive
notification_options d,u,r
max_check_attempts 3
}
</pre>
</p>
<p>
You can see that the <i>check_command</i> and <i>notification_options</i> variables were inherited from the template object (where host <i>bighost1</i> was defined). However, the <i>host_name</i> and <i>max_check_attempts</i> variables were not inherited from the template object because they were defined locally. Remember, locally defined variables override variables that would normally be inherited from a template object. That should be a fairly easy concept to understand.
</p>
<p>
<strong><u>inheritance Chaining</u></strong>
</p>
<p>
Objects can inherit properties/variables from multiple levels of template objects. Take the following example:
</p>
<p>
<pre>
define host{
host_name bighost1
check_command check-host-alive
notification_options d,u,r
max_check_attempts 5
<font color="red">name hosttemplate1</font>
}
define host{
host_name bighost2
max_check_attempts 3
<font color="red">use hosttemplate1</font>
<font color="red">name hosttemplate2</font>
}
define host{
host_name bighost3
<font color="red">use hosttemplate2</font>
}
</pre>
</p>
<p>
You'll notice that the definition of host <i>bighost3</i> inherits variables from the definition of host <i>bighost2</i>, which in turn inherits variables from the definition of host <i>bighost1</i>. Once Nagios processes this configuration data, the resulting host definitions are equivalent to the following:
</p>
<p>
<pre>
define host{
host_name bighost1
check_command check-host-alive
notification_options d,u,r
max_check_attempts 5
}
define host{
host_name bighost2
check_command check-host-alive
notification_options d,u,r
max_check_attempts 3
}
define host{
host_name bighost3
check_command check-host-alive
notification_options d,u,r
max_check_attempts 3
}
</pre>
</p>
<p>
There is no inherent limit on how "deep" inheritance can go, but you'll probably want to limit yourself to at most a few levels in order to maintain sanity.
</p>
<p>
<strong><u>Using Incomplete Object Definitions as Templates</u></strong>
</p>
<p>
It is possible to use imcomplete object definitions as templates for use by other object definitions. By "incomplete" definition, I mean that all required variables in the object have not been supplied in the object definition. It may sound odd to use incomplete definitions as templates, but it is in fact recommended that you use them. Why? Well, they can serve as a set of defaults for use in all other object definitions. Take the following example:
</p>
<p>
<pre>
define host{
check_command check-host-alive
notification_options d,u,r
max_check_attempts 5
<font color="red">name generichosttemplate</font>
<font color="red">register 0</font>
}
define host{
host_name bighost1
address 192.168.1.3
<font color="red">use generichosthosttemplate</font>
}
define host{
host_name bighost2
address 192.168.1.4
<font color="red">use generichosthosttemplate</font>
}
</pre>
</p>
<p>
Notice that the first host definition is incomplete because it is missing the required <i>host_name</i> variable. We don't need to supply a host name because we just want to use this definition as a generic host template. In order to prevent this definition from being registered with Nagios as a normal host, we set the <i>register</i> variable to 0.
</p>
<p>
The definitions of hosts <i>bighost1</i> and <i>bighost2</i> inherit their values from the generic host definition. The only variable we've chosed to override is the <i>address</i> variable. This means that both hosts will have the exact same properties, except for their <i>host_name</i> and <i>address</i> variables. Once Nagios processes the config data in the example, the resulting host definitions would be equivalent to specifying the following:
</p>
<p>
<pre>
define host{
host_name bighost1
address 192.168.1.3
check_command check-host-alive
notification_options d,u,r
max_check_attempts 5
}
define host{
host_name bighost2
address 192.168.1.4
check_command check-host-alive
notification_options d,u,r
max_check_attempts 5
}
</pre>
</p>
<p>
At the very least, using a template definition for default variables will save you a lot of typing. It'll also save you a lot of headaches later if you want to change the default values of variables for a large number of hosts.
</p>
<hr>
</body>
</html>
|
