Page MenuHomePhabricator

give John Lewis permissions to send commands in icinga for fermium/mailman
Closed, ResolvedPublic

Description

same as for the services team (T105228) but for volunteer @JohnLewis , let him send commands in icinga to be able to link tickets to alerts, shush notifications for a specific host or acknowledge a known alert

13:56 <JohnFLewis> I check icinga regularly and on several occasions have poked ops to ack things, silencing annoying repeating comments when ops aren't around is also a thing I can do which has happened in the past

Details

Related Gerrit Patches:
operations/puppet : productionicinga: fix contact name of John Lewis
operations/puppet : productionlists: add mailman-admins to contact groups
operations/puppet : productionicinga: add contact group for mailman admins

Event Timeline

Dzahn created this task.Jul 8 2015, 8:59 PM
Dzahn raised the priority of this task from to Needs Triage.
Dzahn updated the task description. (Show Details)
Dzahn added subscribers: Dzahn, JohnLewis.
Restricted Application added subscribers: Matanya, Aklapper. · View Herald TranscriptJul 8 2015, 8:59 PM
Dzahn updated the task description. (Show Details)Jul 8 2015, 9:00 PM
Dzahn set Security to None.
Krenair added a subscriber: Krenair.Jul 8 2015, 9:09 PM
jeremyb added a subscriber: jeremyb.Jul 8 2015, 9:16 PM
RobH added a subscriber: RobH.EditedJul 8 2015, 9:20 PM

This has already been slightly discussed in IRC, but I'll note it on task for the record.

Having rights to acknowledge and silence alerts in icinga has a very large scope, in that it could affect every single server and service. We don't currently (that I am aware of) split our icinga permissions into service level groups. So anyone with the ability to ack one service can do so for all services.

As such, this is on par with a sudo level request, and falls into the requirement of an operations meeting approval. A three day wait without objection will NOT suffice for this request.

(Unless I am mistaken about how icinga's authorization levels work; which is quite possible.)

RobH added a comment.Jul 8 2015, 9:28 PM

Daniel pulled up the varying icinga permission groups: P926

Dzahn triaged this task as Medium priority.Jul 9 2015, 2:17 AM
RobH added a comment.Jul 13 2015, 8:54 PM

This was discussed in the operations meeting. The overall concensus seemed to be that full access for all icinga alerting and commands for all services is too large a scope.

This request will have to stall with the sub-task of breaking up our icinga config into services groups, so each dev/engineering/services group can control their own service acknowledgements and maintenance windows within icinga.

This is the same reply as on T105228, in that we won't hand out icinga command ability sitewide to anyone outside of roots.

fgiunchedi changed the task status from Open to Stalled.Jul 21 2015, 10:29 AM
fgiunchedi added a subscriber: fgiunchedi.
Dzahn added a comment.Aug 20 2015, 1:15 AM

just wondering, let's say the subtask was resolved, for which services is John requesting permissions? mailman?

akosiaris lowered the priority of this task from Medium to Low.Aug 27 2015, 2:21 PM
akosiaris added a subscriber: akosiaris.
JohnLewis added a comment.EditedSep 2 2015, 3:00 PM

Testing (on a 1.11 install on a separate project; though this seems consistent for 1.6) and docs show that if a contact has 'can_submit_commands' set to 1 in their contact definition - they are allowed to submit commands for their services. Which is what this ticket and the services ticket are about.

just wondering, let's say the subtask was resolved, for which services is John requesting permissions? mailman?

Yes, it would basically be that. I can't see any other service being of use in this context.

FYI doc wise: http://docs.icinga.org/latest/en/objectdefinitions.html#contact

can_submit_commands:

This directive is used to determine whether or not the contact can submit external commands to Icinga from the CGIs. Values: 0 = don't allow contact to submit commands, 1 = allow contact to submit commands.

Is in 1.6.1 and does as expected above.

Dzahn added a comment.Sep 2 2015, 11:34 PM

just wondering, let's say the subtask was resolved, for which services is John requesting permissions? mailman?

Yes, it would basically be that. I can't see any other service being of use in this context.

Yea, ok. Though in the Icinga context it's 1 host and multiple services. We mean all services running on host fermium. So
mailman I/O stats,
mailman list info, mailman ctl and the others. And all the standard services like disk space and CPU on the host that runs mailman.

Dzahn claimed this task.Sep 14 2015, 10:21 PM
Dzahn renamed this task from give John Lewis permissions to send commands in icinga to give John Lewis permissions to send commands in icinga for fermium/mailman.Oct 10 2015, 1:50 AM
Dzahn added a comment.Oct 10 2015, 1:52 AM

renamed ticket to clarify we had agreed on "only limited to services the user has access to" vs. full access and it was stalled for that reason.

now we have this ability. (T111243 could already be resolved due to that) and we can allow sending commands for just mailman and the server it is on, via hiera on a role

Dzahn changed the task status from Stalled to Open.Oct 10 2015, 1:52 AM

Change 244842 had a related patch set uploaded (by Dzahn):
icinga: add contact group for mailman admins

https://gerrit.wikimedia.org/r/244842

Change 244842 merged by Dzahn:
icinga: add contact group for mailman admins

https://gerrit.wikimedia.org/r/244842

Change 244844 had a related patch set uploaded (by Dzahn):
lists: add mailman-admins to contact groups

https://gerrit.wikimedia.org/r/244844

Change 244844 merged by Dzahn:
lists: add mailman-admins to contact groups

https://gerrit.wikimedia.org/r/244844

Dzahn added a comment.Oct 10 2015, 2:30 AM

1root@neon:/etc/icinga# grep -B3 -A1 mailman-admins /etc/icinga/puppet_services.cfg | grep -v freshness | grep -v check_period
2 check_command nrpe_check!check_check_dhclient!10
3 contact_groups admins,mailman-admins
4 host_name fermium
5--
6 check_command nrpe_check!check_check_eth!10
7 contact_groups admins,mailman-admins
8 host_name fermium
9--
10 check_command nrpe_check!check_check_salt_minion!10
11 contact_groups admins,mailman-admins
12 host_name fermium
13--
14 check_command nrpe_check!check_disk_space!10
15 contact_groups admins,mailman-admins
16 host_name fermium
17--
18 check_command nrpe_check!check_dpkg!10
19 contact_groups admins,mailman-admins
20 host_name fermium
21--
22 check_command check_ssl_http!lists.wikimedia.org
23 contact_groups admins,mailman-admins
24 host_name fermium
25--
26 check_command check_https_url_for_string!lists.wikimedia.org!/pipermail/wikimedia-l/!'The Wikimedia-l Archives'
27 contact_groups admins,mailman-admins
28 host_name fermium
29--
30 check_command nrpe_check!check_mailman_iostat!30
31 contact_groups admins,mailman-admins
32 host_name fermium
33--
34 check_command check_https_url_for_string!lists.wikimedia.org!/mailman/listinfo/wikimedia-l!'Discussion list for the Wikimedia community'
35 contact_groups admins,mailman-admins
36 host_name fermium
37--
38 check_command nrpe_check!check_mailman_queue!10
39 contact_groups admins,mailman-admins
40 host_name fermium
41--
42 check_command check_ntp_time!0.5!1
43 contact_groups admins,mailman-admins
44 host_name fermium
45--
46 check_command nrpe_check!check_procs_mailmanctl!10
47 contact_groups admins,mailman-admins
48 host_name fermium
49--
50 check_command nrpe_check!check_procs_mailman_qrunner!10
51 contact_groups admins,mailman-admins
52 host_name fermium
53--
54 check_command nrpe_check!check_puppet_checkpuppetrun!10
55 contact_groups admins,mailman-admins
56 host_name fermium
57--
58 check_command nrpe_check!check_raid!10
59 contact_groups admins,mailman-admins
60 host_name fermium
61--
62 check_command check_smtp_tls
63 contact_groups admins,mailman-admins
64 host_name fermium
65--
66 check_command nrpe_check!check_spamd!10
67 contact_groups admins,mailman-admins
68 host_name fermium
69--
70 check_command check_ssh
71 contact_groups admins,mailman-admins
72 host_name fermium

Dzahn added a comment.Oct 10 2015, 2:33 AM

following the same pattern as in T111243, this is now resolved.

email notifications and access to send commands but ONLY limited to the services of the role mailman, which he also has shell access to

Dzahn closed this task as Resolved.Oct 10 2015, 2:33 AM
Dzahn removed a project: Patch-For-Review.
JohnLewis reopened this task as Open.Oct 10 2015, 10:35 AM

Tried to test this by un silencing the mailman queue check (permissions noted above are correct) yet I get that I am not authorised to do so.

May be irrelevant but the username seemingly used for the icings set up is johnflewis while LDAP uses the Wikitech username which makes me John F. Lewis.

Dzahn added a comment.Oct 12 2015, 8:50 PM

May be irrelevant but the username seemingly used for the icings set up is johnflewis while LDAP uses the Wikitech username which makes me John F. Lewis.

It's not irrelevant. It's the problem. You'd have to be logged in as "johnflewis" in Icinga. If i look at existing contactroups like "sms" nobody uses the "cn" though.

We tested if using "John F. Lewis" as contact name breaks Icinga config and it actually seems ok (as in not breaking syntax check) but did not puppetize the change yet. Let's test together when we are both online.

Change 247322 had a related patch set uploaded (by Dzahn):
icinga: fix contact name of John Lewis

https://gerrit.wikimedia.org/r/247322

Change 247322 merged by Dzahn:
icinga: fix contact name of John Lewis

https://gerrit.wikimedia.org/r/247322

Dzahn closed this task as Resolved.Oct 19 2015, 6:35 PM

renamed the contact in private repo to match the LDAP "cn" = "John F. Lewis" and adjusted the contactgroup in public repo and this works. Icinga doesn't mind the spaces and we tested, John has permissions now for fermium services.

fgiunchedi closed subtask Restricted Task as Invalid.Sep 30 2016, 3:09 PM