Project

General

Profile

Feature #12161

Monitor that our internal XMPP server is up

Added by intrigeri 11 months ago. Updated 3 days ago.

Status:
Confirmed
Priority:
Normal
Assignee:
Category:
Infrastructure
Target version:
Start date:
01/21/2017
Due date:
% Done:

0%

QA Check:
Info Needed
Feature Branch:
Type of work:
Sysadmin
Blueprint:
Starter:
Affected tool:

Related issues

Blocked by Tails - Feature #12162: Give the internal XMPP service admins the credentials they need Resolved 01/21/2017

History

#2 Updated by intrigeri 9 months ago

  • Blocked by Feature #12162: Give the internal XMPP service admins the credentials they need added

#3 Updated by intrigeri 9 months ago

  • Target version changed from Tails_2.12 to Tails_3.1

I'll take it easy too.

#4 Updated by intrigeri 6 months ago

  • Target version deleted (Tails_3.1)

I'll re-add a target version once there's something to monitor.

#5 Updated by intrigeri 6 months ago

  • Assignee deleted (intrigeri)

intrigeri wrote:

I'll re-add a target version once there's something to monitor.

Ditto for the assignee.

#6 Updated by intrigeri 5 months ago

  • Assignee set to intrigeri
  • Target version set to Tails_3.2

It's up!

#7 Updated by intrigeri 5 months ago

The only candidate plugin in Debian is https://tracker.debian.org/pkg/nagios-check-xmppng:

  • homepage: https://exchange.icinga.com/jandd/check_xmppng
  • last upstream release: 2016-06-18
  • very low popcon but that's somewhat expected
  • no support for SOCKS5 so we would need to wrap it somehow with torsocks (I think we do that already for SMTP → WhisperBack relay)
  • no reply on https://bugs.debian.org/846873 for almost 8 months; we're not affected by it but that's somewhat concerning wrt. the maintenance of the Debian package; now, that's not any worse than importing 3rd-party plugins from the Internet into our own Git repo without any process set up to update them, so well, I think we can live with that.
  • in jessie-backports, Stretch, and testing/sid

#8 Updated by intrigeri 5 months ago

  • Target version changed from Tails_3.2 to Tails_3.5

#9 Updated by intrigeri 3 days ago

  • Assignee changed from intrigeri to Dr_Whax
  • QA Check set to Info Needed

Taking a step back, I'm now in doubt. I wonder what's the actual value of implementing this:

  • This is purely internal infrastructure, if it's down only almost-core Tails contributors are affected; the dev process and users are not.
  • A few of us are on tails-bar all the time so chances are we'll notice if this service is down as fast as a monitoring check would.

So the only case when doing this work would be useful is when a monitoring check would report a problem to the on-call sysadmin, and the on-call sysadmin fixes it, all this before any tails-bar user notices the problem. Given our average latency for reacting to such non-critical issues raised by our monitoring system, I doubt this ever happens.

So I propose we reject this ticket and encourage our sysadmins to hang out on tails-bar when they're on duty (to increase the chances they notice any issue at the same time as other users of the service).

DrWhax, bertagaz, groente: what do you think?

Also available in: Atom PDF