You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/inventory.md
+18-3Lines changed: 18 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,6 +14,7 @@ The new inventory is structured in 4 major pieces, explained in its own section:
14
14
-`namespaces`: where you put together all the above. A namespace is be defined by a `source`, an `auth` and a `device`
15
15
16
16
Here is an example of an inventory file with a bunch of different options, but non-exhaustive, for each section:
17
+
17
18
```yaml
18
19
sources:
19
20
- name: netbox-instance-123
@@ -86,6 +87,7 @@ namespaces:
86
87
- It is possible to [map different sources to the same namespace](#mapping-different-sources-to-the-same-namespace)
87
88
88
89
## <a name='sensitive-data'></a>Sensitive data
90
+
89
91
A sensitive data is an information that the user doesn't want to store in plain-text inside the inventory.
90
92
For this reason, SuzieQ inventory now supports three different options to store these kind of informations
91
93
@@ -94,6 +96,7 @@ For this reason, SuzieQ inventory now supports three different options to store
94
96
- `ask`: the user can write the sensitive information on the stdin
95
97
96
98
Currently this method is used to specify passwords, passphrases and tokens.
99
+
97
100
## <a name='inventory-sources'></a>Sources
98
101
99
102
The device sources currently supported are:
@@ -121,9 +124,11 @@ Whenever a source has many fields in common with another, you don't have to rewr
121
124
- suzieq-copy
122
125
123
126
```
127
+
124
128
### <a name='source-host-list'></a>Host list
125
129
126
130
The host list contains the IP address, the access method (SSH or REST), the IP address of the node, the user name, the type of OS if using REST and the access token such as a private key file. Here is an example of a native suzieq source type. For example (all possible combinations are shown for illustration):
131
+
127
132
```yaml
128
133
- name: dc-01-native
129
134
type: native # optional, if type is not present this is the default value
Now you can set the path of the ansible inventory in the source:
157
+
152
158
```yaml
153
159
- name: ansible-01
154
160
type: ansible
155
161
path: /path/to/ansible.json
156
162
```
157
163
164
+
Since Ansible devices cannot really be split up, the device and auth sections apply to **all** the devices in the Ansible inventory file. This is a limitaion of the Ansible source input. We always assume ssh as the transport unless otherwise specified in the device section of the SuzieQ inventory file.
158
165
!!! info
159
-
The Ansible source assumes REST transport with Arista EOS and PanOs devices by default, and SSH for the others
166
+
From 0.21.0, with Ansible inventories, the device type and transport are taken from the specification in the device section of the suzieq inventory file. You must specify the transport as rest if you want to use rest as the transport for EOS devices. By default, we assume ssh as the transport. For PANOS also, you must specify the device type and transport. Before version 0.21.0, Ansible inventory assumed REST as the transport for EOS, even if the user specified the transport as SSH in the device section.
160
167
161
168
### <a name='source-netbox'></a>Netbox
162
169
@@ -173,6 +180,7 @@ Since Netbox is a _dynamic source_, the data are periodically pulled, the period
173
180
If the user manually sets `ssl-verify: true` with an http netbox server, an error will be notified.
174
181
175
182
Here is an example of the configuration of a netbox type source:
183
+
176
184
```yaml
177
185
- name: netbox-dc-01
178
186
type: netbox
@@ -183,6 +191,7 @@ Here is an example of the configuration of a netbox type source:
183
191
period: 3600 # How frequently Netbox should be polled
184
192
ssl-verify: false # Netbox certificate validation will be skipped
185
193
```
194
+
186
195
#### Selecting devices from Netbox
187
196
188
197
Starting from 0.19, it's possible to specify more than one tag to be matched, defining a list of one or more rules.
@@ -198,6 +207,7 @@ A device is polled by SuzieQ if it matches at least one of the defined rules.
198
207
- alpha
199
208
- bravo, charlie
200
209
```
210
+
201
211
For example, the source above tells SuzieQ to select from Netbox all the devices having the `alpha` OR `bravo & charlie` tags.
202
212
203
213
!!!Warning
@@ -210,6 +220,7 @@ Netbox type source is capable to assign each device to a namespace which corresp
210
220
To obtain this behaviour, we need to declare a `namespace` object with `name: netbox-sitename`.
211
221
212
222
Here is an example:
223
+
213
224
```yaml
214
225
sources:
215
226
- name: netbox-dc-01
@@ -270,6 +281,7 @@ In case you want to ignore the check of the device's key against the `known_host
270
281
```
271
282
272
283
Moreover if all the devices inside a namespace run the same NOS, it is possible to specify it via the `devtype` option:
284
+
273
285
```yaml
274
286
- name: eos-devices
275
287
devtype: eos
@@ -294,13 +306,15 @@ This section is optional in case SuzieQ native and ansible source types. Here a
294
306
Currently for both SSH and REST API, the only supported is username and password, therefore you will not be able to set api keys.
295
307
296
308
The simplest method is defining either username and password/private key.
309
+
297
310
```yaml
298
311
- name: suzieq-user
299
312
username: suzieq
300
313
password: plain:pass
301
314
```
302
315
303
316
In case a private key is used to authenticate:
317
+
304
318
```yaml
305
319
- name: suzieq-user
306
320
keyfile: path/to/private/key
@@ -326,6 +340,7 @@ A `cred-file` is an external file where you store credentials for all the device
326
340
Each device credentials can be specified via its `hostname` or its `address`
327
341
(with Netbox, it's encouraged the usage of `hostname`).
328
342
The credential file should look like this:
343
+
329
344
```yaml
330
345
- namespace: testing
331
346
devices:
@@ -348,6 +363,7 @@ The credential file should look like this:
348
363
349
364
In the `namespaces` section sources, auths and devices can be put together to define namespaces.
350
365
For example the following namespace will be defined by the source named `netbox-1`, the auths named `dc-01-credentials`, and the device named `ssh-jump-devs`:
366
+
351
367
```yaml
352
368
namespaces:
353
369
- name: example
@@ -430,15 +446,14 @@ Suppose we have this inventory valid for version 0.15.x:
The new inventory format consists of four sections (sources, auths, devices, namespaces) which are described above. We need to add the devices specified in the old inventory format in a new source inside the `sources` section and link it to a namespace.
434
449
450
+
The new inventory format consists of four sections (sources, auths, devices, namespaces) which are described above. We need to add the devices specified in the old inventory format in a new source inside the `sources` section and link it to a namespace.
435
451
436
452
Here is how the new format will look like:
437
453
438
454
!!! important
439
455
Sections [auths](#auths) and [devices](#devices) are optional. See the full documentation to know how to use them.
440
456
441
-
442
457
```yaml
443
458
sources:
444
459
- name: eos-source # namespace is defined below, this is only a name to be used as reference
0 commit comments