"one person outside of TPA" did not make sense for internal services,
so broaden that requirement. it's fine, anyways, if we are two to
adopt the service internally.

It's really part of the support policy, so it should just be in
there. We keep a soft redirect to make sure people find it.

This bypasses the "User root" configuration in my SSH config and is
more future-proof.

This way I don't have to remember how it works.

ticket.

unattended-upgrades.

This is partly based on the announcement I sent in:

https://lists.torproject.org/pipermail/tor-project/2019-September/002509.html

Actually, "monitoring warnings" is less meaningful in some cases.

For example in the case of tls, it talks about emails from Digicert,
which is not per se a monitoring warning. Similarly, the Ganeti
documentation talks about I/O overloads and other conditions that are
not necessarily raised by the monitoring system, but could be raised
by our "human nagioses" (e.g. "humans" saying "this is slow!").

This reverts commit 85d5423f.

to the best of my knowledge...

"Pager" and "playbook" have specific meanings which are not obvious to
me. For example, we don't carry pagers and "playbooks" could be
ansible playbooks, but we don't carry those either.

I thought of naming this "Nagios warnings" but I figured I would be
more forward-compatible (in case we switch away from Nagios) and name
this "Monitoring".