Merge ~ec0/charm-nagios:readonly-account into ~nagios-charmers/charm-nagios:master
- Git
- lp:~ec0/charm-nagios
- readonly-account
- Merge into master
Status: | Merged |
---|---|
Merge reported by: | Xav Paice |
Merged at revision: | ccb6415bb5d73e6ea7636bc27cbf656fa0187cdb |
Proposed branch: | ~ec0/charm-nagios:readonly-account |
Merge into: | ~nagios-charmers/charm-nagios:master |
Diff against target: |
476 lines (+419/-7) 3 files modified
config.yaml (+5/-0) hooks/templates/nagios-cgi.tmpl (+383/-0) hooks/upgrade-charm (+31/-7) |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Xav Paice (community) | Approve | ||
Haw Loeung | Needs Information | ||
Review via email: mp+318564@code.launchpad.net |
Commit message
Description of the change
Adds support for creating a nagiosro user, by exposing an additional ro-password charm setting. If ro-password is set, the nagiosro will be created, and added to the authorisation roles required to allow read-only access to the Nagios web interface. This commit also adds the cgi.cfg for Nagios into management by the charm, as it is needed to control authorisation for specific users.
James Hebden (ec0) wrote : | # |
> James, is nagios-cgi.tmpl directly from the nagios package? If so, should we
> instead parse and update that instead of shipping our own copy of it?
It is from the package, with some edits made to include template tags which are rendered by charm hooks. I feel that templating this file ongoing is the best approach, rather than parsing and modifying, as we've also taken this approach with other config files in this charm, and generally I believe it to be a better approach to take when charming.
Generally, my preference is to template rather than parse and update for the following reasons -
We should be authoritative with our config files when managing them with a charm. If Juju is managing a config file, regardless of how much of the config file we are managing via templated variables, it makes sense to make sure that any local modifications to a config file are controlled and that we can be sure of the configuration file in its entirety to prevent issues when parsing the config file, and to prevent issues with the generated config file not configuring the software for the intended purpose due to modifications the charm did not implement. This setting isn't a great example of this, as it's fairly self-contained - however I'm trying to think holistically about the approach here.
We also don't need to worry about squashing packaged updates to the software, as we can accommodate these with per-version templates if per-version config changes are needed, per what is done in the OpenStack charms, if that ever becomes an issue. I doubt very much we'll get into that issue with Nagios, but if we ever did we can accommodate it, and I also think this is a good way to make sure we capture the entire working config for an individual version of software.
Haw Loeung (hloeung) wrote : | # |
A package update will not likely replace the existing config, so Juju
will still be authoritative (.orig?).
My point is more of now we have to manage and maintain the config
file. If that changes upstream in the latest nagios package (say with
new config options / features), we'd have to pull it into the
charm. So now the next upgrade-charm could potentially ship out a new
config with options to an environment that has nagios packages that
probably doesn't yet support the new configs (Xenial on Trusty for
example)?
I'm more in favor of just reading in the current config and only
modifying/adding the config otpions we're interested in (in this case,
it's just authorized_
in a new distro or nagios release where cgi.cfg has introduced newer
config options, then it would still just work (unless ofcourse the
authorized_
Xav Paice (xavpaice) wrote : | # |
In this case, we're already managing a chunk of the config files and I don't see an alternative for that particular config (no conf.d option for cgi.cfg).
While we could use a sed equivalent to alter the config on that one file, we don't take that approach with nagios.cfg and I'd rather take a consistent approach. If this was a fresh charm we could argue otherwise. Any new config options that package updates add to that file _SHOULD_ have sensible defaults built in and not require setting at all, if we wish to add config items for those settings later then we'd need to modify the charm anyway.
I've tested this change and find it to be working well, and we have multiple customers that are affected by the change not getting merged.
Preview Diff
1 | diff --git a/config.yaml b/config.yaml |
2 | index 3eb834a..7ae04fb 100644 |
3 | --- a/config.yaml |
4 | +++ b/config.yaml |
5 | @@ -144,3 +144,8 @@ options: |
6 | Password to use for Nagios administrative access. If not |
7 | provided, a password will be generated (see documentation for |
8 | instructions on retrieving the generated password.) |
9 | + ro-password: |
10 | + type: string |
11 | + default: '' |
12 | + description: | |
13 | + Password to use for read-only Nagios access. If left blank, the nagiosro account will not be created. |
14 | diff --git a/hooks/templates/nagios-cgi.tmpl b/hooks/templates/nagios-cgi.tmpl |
15 | new file mode 100644 |
16 | index 0000000..11cb275 |
17 | --- /dev/null |
18 | +++ b/hooks/templates/nagios-cgi.tmpl |
19 | @@ -0,0 +1,383 @@ |
20 | +################################################################# |
21 | +# |
22 | +# CGI.CFG - Sample CGI Configuration File for Nagios |
23 | +# |
24 | +################################################################# |
25 | + |
26 | + |
27 | +# MAIN CONFIGURATION FILE |
28 | +# This tells the CGIs where to find your main configuration file. |
29 | +# The CGIs will read the main and host config files for any other |
30 | +# data they might need. |
31 | + |
32 | +main_config_file=/etc/nagios3/nagios.cfg |
33 | + |
34 | + |
35 | + |
36 | +# PHYSICAL HTML PATH |
37 | +# This is the path where the HTML files for Nagios reside. This |
38 | +# value is used to locate the logo images needed by the statusmap |
39 | +# and statuswrl CGIs. |
40 | + |
41 | +physical_html_path=/usr/share/nagios3/htdocs |
42 | + |
43 | + |
44 | + |
45 | +# URL HTML PATH |
46 | +# This is the path portion of the URL that corresponds to the |
47 | +# physical location of the Nagios HTML files (as defined above). |
48 | +# This value is used by the CGIs to locate the online documentation |
49 | +# and graphics. If you access the Nagios pages with an URL like |
50 | +# http://www.myhost.com/nagios, this value should be '/nagios' |
51 | +# (without the quotes). |
52 | + |
53 | +url_html_path=/nagios3 |
54 | + |
55 | + |
56 | + |
57 | +# CONTEXT-SENSITIVE HELP |
58 | +# This option determines whether or not a context-sensitive |
59 | +# help icon will be displayed for most of the CGIs. |
60 | +# Values: 0 = disables context-sensitive help |
61 | +# 1 = enables context-sensitive help |
62 | + |
63 | +show_context_help=1 |
64 | + |
65 | + |
66 | + |
67 | +# PENDING STATES OPTION |
68 | +# This option determines what states should be displayed in the web |
69 | +# interface for hosts/services that have not yet been checked. |
70 | +# Values: 0 = leave hosts/services that have not been check yet in their original state |
71 | +# 1 = mark hosts/services that have not been checked yet as PENDING |
72 | + |
73 | +use_pending_states=1 |
74 | + |
75 | +# NAGIOS PROCESS CHECK COMMAND |
76 | +# This is the full path and filename of the program used to check |
77 | +# the status of the Nagios process. It is used only by the CGIs |
78 | +# and is completely optional. However, if you don't use it, you'll |
79 | +# see warning messages in the CGIs about the Nagios process |
80 | +# not running and you won't be able to execute any commands from |
81 | +# the web interface. The program should follow the same rules |
82 | +# as plugins; the return codes are the same as for the plugins, |
83 | +# it should have timeout protection, it should output something |
84 | +# to STDIO, etc. |
85 | +# |
86 | +# Note: The command line for the check_nagios plugin below may |
87 | +# have to be tweaked a bit, as different versions of the plugin |
88 | +# use different command line arguments/syntaxes. |
89 | + |
90 | +nagios_check_command=/usr/lib/nagios/plugins/check_nagios /var/cache/nagios3/status.dat 5 '/usr/sbin/nagios3' |
91 | + |
92 | + |
93 | +# AUTHENTICATION USAGE |
94 | +# This option controls whether or not the CGIs will use any |
95 | +# authentication when displaying host and service information, as |
96 | +# well as committing commands to Nagios for processing. |
97 | +# |
98 | +# Read the HTML documentation to learn how the authorization works! |
99 | +# |
100 | +# NOTE: It is a really *bad* idea to disable authorization, unless |
101 | +# you plan on removing the command CGI (cmd.cgi)! Failure to do |
102 | +# so will leave you wide open to kiddies messing with Nagios and |
103 | +# possibly hitting you with a denial of service attack by filling up |
104 | +# your drive by continuously writing to your command file! |
105 | +# |
106 | +# Setting this value to 0 will cause the CGIs to *not* use |
107 | +# authentication (bad idea), while any other value will make them |
108 | +# use the authentication functions (the default). |
109 | + |
110 | +use_authentication=1 |
111 | + |
112 | + |
113 | + |
114 | + |
115 | +# x509 CERT AUTHENTICATION |
116 | +# When enabled, this option allows you to use x509 cert (SSL) |
117 | +# authentication in the CGIs. This is an advanced option and should |
118 | +# not be enabled unless you know what you're doing. |
119 | + |
120 | +use_ssl_authentication=0 |
121 | + |
122 | + |
123 | + |
124 | + |
125 | +# DEFAULT USER |
126 | +# Setting this variable will define a default user name that can |
127 | +# access pages without authentication. This allows people within a |
128 | +# secure domain (i.e., behind a firewall) to see the current status |
129 | +# without authenticating. You may want to use this to avoid basic |
130 | +# authentication if you are not using a secure server since basic |
131 | +# authentication transmits passwords in the clear. |
132 | +# |
133 | +# Important: Do not define a default username unless you are |
134 | +# running a secure web server and are sure that everyone who has |
135 | +# access to the CGIs has been authenticated in some manner! If you |
136 | +# define this variable, anyone who has not authenticated to the web |
137 | +# server will inherit all rights you assign to this user! |
138 | + |
139 | +#default_user_name=guest |
140 | + |
141 | + |
142 | + |
143 | +# SYSTEM/PROCESS INFORMATION ACCESS |
144 | +# This option is a comma-delimited list of all usernames that |
145 | +# have access to viewing the Nagios process information as |
146 | +# provided by the Extended Information CGI (extinfo.cgi). By |
147 | +# default, *no one* has access to this unless you choose to |
148 | +# not use authorization. You may use an asterisk (*) to |
149 | +# authorize any user who has authenticated to the web server. |
150 | + |
151 | +authorized_for_system_information=nagiosadmin |
152 | + |
153 | + |
154 | + |
155 | +# CONFIGURATION INFORMATION ACCESS |
156 | +# This option is a comma-delimited list of all usernames that |
157 | +# can view ALL configuration information (hosts, commands, etc). |
158 | +# By default, users can only view configuration information |
159 | +# for the hosts and services they are contacts for. You may use |
160 | +# an asterisk (*) to authorize any user who has authenticated |
161 | +# to the web server. |
162 | + |
163 | +authorized_for_configuration_information=nagiosadmin |
164 | + |
165 | + |
166 | + |
167 | +# SYSTEM/PROCESS COMMAND ACCESS |
168 | +# This option is a comma-delimited list of all usernames that |
169 | +# can issue shutdown and restart commands to Nagios via the |
170 | +# command CGI (cmd.cgi). Users in this list can also change |
171 | +# the program mode to active or standby. By default, *no one* |
172 | +# has access to this unless you choose to not use authorization. |
173 | +# You may use an asterisk (*) to authorize any user who has |
174 | +# authenticated to the web server. |
175 | + |
176 | +authorized_for_system_commands=nagiosadmin |
177 | + |
178 | + |
179 | + |
180 | +# GLOBAL HOST/SERVICE VIEW ACCESS |
181 | +# These two options are comma-delimited lists of all usernames that |
182 | +# can view information for all hosts and services that are being |
183 | +# monitored. By default, users can only view information |
184 | +# for hosts or services that they are contacts for (unless you |
185 | +# you choose to not use authorization). You may use an asterisk (*) |
186 | +# to authorize any user who has authenticated to the web server. |
187 | + |
188 | + |
189 | +{%if ro_password%} |
190 | +authorized_for_read_only=nagiosro |
191 | +authorized_for_all_services=nagiosadmin,nagiosro |
192 | +authorized_for_all_hosts=nagiosadmin,nagiosro |
193 | +{% else %} |
194 | +authorized_for_all_services=nagiosadmin |
195 | +authorized_for_all_hosts=nagiosadmin |
196 | +{% endif %} |
197 | + |
198 | + |
199 | + |
200 | +# GLOBAL HOST/SERVICE COMMAND ACCESS |
201 | +# These two options are comma-delimited lists of all usernames that |
202 | +# can issue host or service related commands via the command |
203 | +# CGI (cmd.cgi) for all hosts and services that are being monitored. |
204 | +# By default, users can only issue commands for hosts or services |
205 | +# that they are contacts for (unless you you choose to not use |
206 | +# authorization). You may use an asterisk (*) to authorize any |
207 | +# user who has authenticated to the web server. |
208 | + |
209 | +authorized_for_all_service_commands=nagiosadmin |
210 | +authorized_for_all_host_commands=nagiosadmin |
211 | + |
212 | + |
213 | + |
214 | +# READ-ONLY USERS |
215 | +# A comma-delimited list of usernames that have read-only rights in |
216 | +# the CGIs. This will block any service or host commands normally shown |
217 | +# on the extinfo CGI pages. It will also block comments from being shown |
218 | +# to read-only users. |
219 | + |
220 | +#authorized_for_read_only=user1,user2 |
221 | + |
222 | + |
223 | + |
224 | + |
225 | +# STATUSMAP BACKGROUND IMAGE |
226 | +# This option allows you to specify an image to be used as a |
227 | +# background in the statusmap CGI. It is assumed that the image |
228 | +# resides in the HTML images path (i.e. /usr/local/nagios/share/images). |
229 | +# This path is automatically determined by appending "/images" |
230 | +# to the path specified by the 'physical_html_path' directive. |
231 | +# Note: The image file may be in GIF, PNG, JPEG, or GD2 format. |
232 | +# However, I recommend that you convert your image to GD2 format |
233 | +# (uncompressed), as this will cause less CPU load when the CGI |
234 | +# generates the image. |
235 | + |
236 | +#statusmap_background_image=smbackground.gd2 |
237 | + |
238 | + |
239 | + |
240 | + |
241 | +# STATUSMAP TRANSPARENCY INDEX COLOR |
242 | +# These options set the r,g,b values of the background color used the statusmap CGI, |
243 | +# so normal browsers that can't show real png transparency set the desired color as |
244 | +# a background color instead (to make it look pretty). |
245 | +# Defaults to white: (R,G,B) = (255,255,255). |
246 | + |
247 | +#color_transparency_index_r=255 |
248 | +#color_transparency_index_g=255 |
249 | +#color_transparency_index_b=255 |
250 | + |
251 | + |
252 | + |
253 | + |
254 | +# DEFAULT STATUSMAP LAYOUT METHOD |
255 | +# This option allows you to specify the default layout method |
256 | +# the statusmap CGI should use for drawing hosts. If you do |
257 | +# not use this option, the default is to use user-defined |
258 | +# coordinates. Valid options are as follows: |
259 | +# 0 = User-defined coordinates |
260 | +# 1 = Depth layers |
261 | +# 2 = Collapsed tree |
262 | +# 3 = Balanced tree |
263 | +# 4 = Circular |
264 | +# 5 = Circular (Marked Up) |
265 | + |
266 | +default_statusmap_layout=5 |
267 | + |
268 | + |
269 | + |
270 | +# DEFAULT STATUSWRL LAYOUT METHOD |
271 | +# This option allows you to specify the default layout method |
272 | +# the statuswrl (VRML) CGI should use for drawing hosts. If you |
273 | +# do not use this option, the default is to use user-defined |
274 | +# coordinates. Valid options are as follows: |
275 | +# 0 = User-defined coordinates |
276 | +# 2 = Collapsed tree |
277 | +# 3 = Balanced tree |
278 | +# 4 = Circular |
279 | + |
280 | +default_statuswrl_layout=4 |
281 | + |
282 | + |
283 | + |
284 | +# STATUSWRL INCLUDE |
285 | +# This option allows you to include your own objects in the |
286 | +# generated VRML world. It is assumed that the file |
287 | +# resides in the HTML path (i.e. /usr/local/nagios/share). |
288 | + |
289 | +#statuswrl_include=myworld.wrl |
290 | + |
291 | + |
292 | + |
293 | +# PING SYNTAX |
294 | +# This option determines what syntax should be used when |
295 | +# attempting to ping a host from the WAP interface (using |
296 | +# the statuswml CGI. You must include the full path to |
297 | +# the ping binary, along with all required options. The |
298 | +# $HOSTADDRESS$ macro is substituted with the address of |
299 | +# the host before the command is executed. |
300 | +# Please note that the syntax for the ping binary is |
301 | +# notorious for being different on virtually ever *NIX |
302 | +# OS and distribution, so you may have to tweak this to |
303 | +# work on your system. |
304 | + |
305 | +ping_syntax=/bin/ping -n -U -c 5 $HOSTADDRESS$ |
306 | + |
307 | + |
308 | + |
309 | +# REFRESH RATE |
310 | +# This option allows you to specify the refresh rate in seconds |
311 | +# of various CGIs (status, statusmap, extinfo, and outages). |
312 | + |
313 | +refresh_rate=90 |
314 | + |
315 | +# DEFAULT PAGE LIMIT |
316 | +# This option allows you to specify the default number of results |
317 | +# displayed on the status.cgi. This number can be adjusted from |
318 | +# within the UI after the initial page load. Setting this to 0 |
319 | +# will show all results. |
320 | + |
321 | +result_limit=100 |
322 | + |
323 | + |
324 | +# ESCAPE HTML TAGS |
325 | +# This option determines whether HTML tags in host and service |
326 | +# status output is escaped in the web interface. If enabled, |
327 | +# your plugin output will not be able to contain clickable links. |
328 | + |
329 | +escape_html_tags=1 |
330 | + |
331 | + |
332 | + |
333 | + |
334 | +# SOUND OPTIONS |
335 | +# These options allow you to specify an optional audio file |
336 | +# that should be played in your browser window when there are |
337 | +# problems on the network. The audio files are used only in |
338 | +# the status CGI. Only the sound for the most critical problem |
339 | +# will be played. Order of importance (higher to lower) is as |
340 | +# follows: unreachable hosts, down hosts, critical services, |
341 | +# warning services, and unknown services. If there are no |
342 | +# visible problems, the sound file optionally specified by |
343 | +# 'normal_sound' variable will be played. |
344 | +# |
345 | +# |
346 | +# <varname>=<sound_file> |
347 | +# |
348 | +# Note: All audio files must be placed in the /media subdirectory |
349 | +# under the HTML path (i.e. /usr/local/nagios/share/media/). |
350 | + |
351 | +#host_unreachable_sound=hostdown.wav |
352 | +#host_down_sound=hostdown.wav |
353 | +#service_critical_sound=critical.wav |
354 | +#service_warning_sound=warning.wav |
355 | +#service_unknown_sound=warning.wav |
356 | +#normal_sound=noproblem.wav |
357 | + |
358 | + |
359 | + |
360 | +# URL TARGET FRAMES |
361 | +# These options determine the target frames in which notes and |
362 | +# action URLs will open. |
363 | + |
364 | +action_url_target=_blank |
365 | +notes_url_target=_blank |
366 | + |
367 | + |
368 | + |
369 | + |
370 | +# LOCK AUTHOR NAMES OPTION |
371 | +# This option determines whether users can change the author name |
372 | +# when submitting comments, scheduling downtime. If disabled, the |
373 | +# author names will be locked into their contact name, as defined in Nagios. |
374 | +# Values: 0 = allow editing author names |
375 | +# 1 = lock author names (disallow editing) |
376 | + |
377 | +lock_author_names=1 |
378 | + |
379 | + |
380 | + |
381 | + |
382 | +# SPLUNK INTEGRATION OPTIONS |
383 | +# These options allow you to enable integration with Splunk |
384 | +# in the web interface. If enabled, you'll be presented with |
385 | +# "Splunk It" links in various places in the CGIs (log file, |
386 | +# alert history, host/service detail, etc). Useful if you're |
387 | +# trying to research why a particular problem occurred. |
388 | +# For more information on Splunk, visit http://www.splunk.com/ |
389 | + |
390 | +# This option determines whether the Splunk integration is enabled |
391 | +# Values: 0 = disable Splunk integration |
392 | +# 1 = enable Splunk integration |
393 | + |
394 | +#enable_splunk_integration=1 |
395 | + |
396 | + |
397 | +# This option should be the URL used to access your instance of Splunk |
398 | + |
399 | +#splunk_url=http://127.0.0.1:8000/ |
400 | + |
401 | + |
402 | + |
403 | diff --git a/hooks/upgrade-charm b/hooks/upgrade-charm |
404 | index 9aff222..da660eb 100755 |
405 | --- a/hooks/upgrade-charm |
406 | +++ b/hooks/upgrade-charm |
407 | @@ -32,9 +32,11 @@ ssl_config = hookenv.config('ssl') |
408 | charm_dir = os.environ['CHARM_DIR'] |
409 | cert_domain = hookenv.unit_get('public-address') |
410 | nagios_cfg = "/etc/nagios3/nagios.cfg" |
411 | +nagios_cgi_cfg = "/etc/nagios3/cgi.cfg" |
412 | pagerduty_cfg = "/etc/nagios3/conf.d/pagerduty_nagios.cfg" |
413 | pagerduty_cron = "/etc/cron.d/nagios-pagerduty-flush" |
414 | password = hookenv.config('password') |
415 | +ro_password = hookenv.config('ro-password') |
416 | |
417 | |
418 | # Checks the charm relations for legacy relations |
419 | @@ -249,6 +251,18 @@ def update_config(): |
420 | |
421 | host.service_reload('nagios3') |
422 | |
423 | +def update_cgi_config(): |
424 | + template_values = {'ro_password': ro_password} |
425 | + with open('hooks/templates/nagios-cgi.tmpl', 'r') as f: |
426 | + templateDef = f.read() |
427 | + |
428 | + t = Template(templateDef) |
429 | + with open(nagios_cgi_cfg, 'w') as f: |
430 | + f.write(t.render(template_values)) |
431 | + |
432 | + host.service_reload('nagios3') |
433 | + host.service_reload('apache2') |
434 | + |
435 | # Nagios3 is deployed as a global apache application from the archive. |
436 | # We'll get a little funky and add the SSL keys to the default-ssl config |
437 | # which sets our keys, including the self-signed ones, as the host keyfiles. |
438 | @@ -286,12 +300,19 @@ def update_apache(): |
439 | |
440 | host.service_reload('apache2') |
441 | |
442 | -def update_password(password): |
443 | - """Update the charm and Apache's record of the admin interface password.""" |
444 | - with open('/var/lib/juju/nagios.passwd', 'w') as f: |
445 | - f.write(password) |
446 | - subprocess.call(['htpasswd', '-b', '/etc/nagios3/htpasswd.users', |
447 | - 'nagiosadmin', password]) |
448 | +def update_password(account, password): |
449 | + """Update the charm and Apache's record of the password for the supplied account.""" |
450 | + account_file = ''.join(['/var/lib/juju/nagios.', account, '.passwd']) |
451 | + if password: |
452 | + with open(account_file, 'w') as f: |
453 | + f.write(password) |
454 | + subprocess.call(['htpasswd', '-b', '/etc/nagios3/htpasswd.users', |
455 | + account, password]) |
456 | + else: |
457 | + """ password was empty, it has been removed. We should delete the account """ |
458 | + os.path.isfile(account_file) and os.remove(account_file) |
459 | + subprocess.call(['htpasswd', '-D', '/etc/nagios3/htpasswd.users', |
460 | + account]) |
461 | |
462 | warn_legacy_relations() |
463 | write_extra_config() |
464 | @@ -302,8 +323,11 @@ if ssl_configured(): |
465 | enable_ssl() |
466 | update_apache() |
467 | update_localhost() |
468 | +update_cgi_config() |
469 | +update_password('nagiosro', ro_password) |
470 | if password: |
471 | - update_password(password) |
472 | + update_password('nagiosadmin', password) |
473 | + |
474 | |
475 | subprocess.call(['hooks/mymonitors-relation-joined']) |
476 | subprocess.call(['hooks/monitors-relation-changed']) |
James, is nagios-cgi.tmpl directly from the nagios package? If so, should we instead parse and update that instead of shipping our own copy of it?