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
|
# Configuration
## Debugging
In case a model plugin doesn't work correctly (ios, procurve, etc.), you can enable live debugging of SSH/Telnet sessions. Just add a `debug` option containing the value true to the `input` section. The log files will be created depending on the parent directory of the logfile option.
The following example will log an active ssh/telnet session `/home/oxidized/.config/oxidized/log/<IP-Address>-<PROTOCOL>`. The file will be truncated on each consecutive ssh/telnet session, so you need to put a `tailf` or `tail -f` on that file!
```yaml
log: /home/oxidized/.config/oxidized/log
...
input:
default: ssh, telnet
debug: true
ssh:
secure: false
```
## Privileged mode
To start privileged mode before pulling the configuration, Oxidized needs to send the enable command. You can globally enable this, by adding the following snippet to the global section of the configuration file.
```yaml
vars:
enable: S3cre7
```
## Removing secrets
To strip out secrets from configurations before storing them, Oxidized needs the `remove_secret` flag. You can globally enable this by adding the following snippet to the global section of the configuration file.
```yaml
vars:
remove_secret: true
```
Device models that contain substitution filters to remove sensitive data will now be run on any fetched configuration.
As a partial example from ios.rb:
```ruby
cmd :secret do |cfg|
cfg.gsub! /^(snmp-server community).*/, '\\1 <configuration removed>'
(...)
cfg
end
```
The above strips out snmp community strings from your saved configs.
**NOTE:** Removing secrets reduces the usefulness as a full configuration backup, but it may make sharing configs easier.
## Disabling SSH exec channels
Oxidized uses exec channels to make information extraction simpler, but there are some situations where this doesn't work well, e.g. configuring devices. This feature can be turned off by setting the `ssh_no_exec`
variable.
```yaml
vars:
ssh_no_exec: true
```
## Disabling SSH keepalives
Oxidized SSH input makes use of SSH keepalives to prevent timeouts from slower devices and to quickly tear down stale sessions in larger deployments. There have been reports of SSH keepalives breaking compatibility with certain OS types. They can be disabled using the `ssh_no_keepalive` variable on a per-node basis (by specifying it in the source) or configured application-wide.
```yaml
vars:
ssh_no_keepalive: true
```
## SSH Auth Methods
By default, Oxidized registers the following auth methods: `none`, `publickey` and `password`. However you can configure this globally, by groups, models or nodes.
```yaml
vars:
auth_methods: [ "none", "publickey", "password", "keyboard-interactive" ]
```
## SSH Proxy Command
Oxidized can `ssh` through a proxy as well. To do so we just need to set `ssh_proxy` variable with the proxy host information.
This can be provided on a per-node basis by mapping the proper fields from your source.
An example for a `csv` input source that maps the 4th field as the `ssh_proxy` value.
```yaml
...
map:
name: 0
model: 1
vars_map:
enable: 2
ssh_proxy: 3
...
```
## FTP Passive Mode
Oxidized uses ftp passive mode by default. Some devices require passive mode to be disabled. To do so, we can set `input.ftp.passive` to false - this will make use of FTP active mode.
```yaml
input:
ftp:
passive: false
```
## Advanced Configuration
Below is an advanced example configuration. You will be able to (optionally) override options per device. The router.db format used is `hostname:model:username:password:enable_password`. Hostname and model will be the only required options, all others override the global configuration sections.
```yaml
---
username: oxidized
password: S3cr3tx
model: junos
interval: 3600 #interval in seconds
log: ~/.config/oxidized/log
debug: false
threads: 30
timeout: 20
retries: 3
prompt: !ruby/regexp /^([\w.@-]+[#>]\s?)$/
crash:
directory: ~/.config/oxidized/crashes
hostnames: false
vars:
enable: S3cr3tx
groups: {}
rest: 127.0.0.1:8888
pid: ~/.config/oxidized/oxidized.pid
input:
default: ssh, telnet
debug: false
ssh:
secure: false
output:
default: git
git:
user: Oxidized
email: oxidized@example.com
repo: "~/.config/oxidized/oxidized.git"
source:
default: csv
csv:
file: ~/.config/oxidized/router.db
delimiter: !ruby/regexp /:/
map:
name: 0
model: 1
username: 2
password: 3
vars_map:
enable: 4
model_map:
cisco: ios
juniper: junos
```
## Advanced Group Configuration
For group specific credentials
```yaml
groups:
mikrotik:
username: admin
password: blank
ubiquiti:
username: ubnt
password: ubnt
```
and add group mapping
```yaml
map:
model: 0
name: 1
group: 2
```
For model specific credentials
```yaml
models:
junos:
username: admin
password: password
ironware:
username: admin
password: password
vars:
enable: enablepassword
apc_aos:
username: apc
password: password
```
## RESTful API and Web Interface
The RESTful API and Web Interface is enabled by configuring the `rest:` parameter in the config file. This parameter can optionally contain a relative URI.
```yaml
# Listen on http://127.0.0.1:8888/
rest: 127.0.0.1:8888
```
```yaml
# Listen on http://10.0.0.1:8000/oxidized/
rest: 10.0.0.1:8000/oxidized
```
## Triggered backups
A node can be moved to head-of-queue via the REST API `GET/POST /node/next/[NODE]`. This can be useful to immediately schedule a fetch of the configuration after some other event such as a syslog message indicating a configuration update on the device.
In the default configuration this node will be processed when the next job worker becomes available, it could take some time if existing backups are in progress. To execute moved jobs immediately a new job can be added automatically:
```yaml
next_adds_job: true
```
This will allow for a more timely fetch of the device configuration.
## Disabling DNS resolution
In some instances it might not be desirable to attempt to resolve names of nodes. One such use case is when nodes are accessed through an SSH proxy, where the remote end resolves the names differently than the host on which Oxidized runs would.
Names can instead be passed verbatim to the input:
```yaml
resolve_dns: false
```
|
