Changes

Page history
fix typos found by harper authored by anarcat's avatar anarcat
Hide whitespace changes
Inline Side-by-side
service/crm.md
View page @ 2bcb5280
...@@ -34,7 +34,7 @@ blocking at various providers if not correctly rate-limited. ...@@ -34,7 +34,7 @@ blocking at various providers if not correctly rate-limited.
For this, we have various knobs and tools: For this, we have various knobs and tools:
* [Grafana dashboard watching the two main mailservers](https://grafana.torproject.org/d/Ds5BxBYGk/postfix-mtail?orgId=1&from=now-24h&to=now&var-node=eugeni.torproject.org&var-node=crm-int-01.torproject.org) * [Grafana dashboard watching the two main mail servers](https://grafana.torproject.org/d/Ds5BxBYGk/postfix-mtail?orgId=1&from=now-24h&to=now&var-node=eugeni.torproject.org&var-node=crm-int-01.torproject.org)
* [Place to enable/disable mailing](https://crm.torproject.org/civicrm/admin/job?reset=1&action=browse) (grep for `Send sched`...) * [Place to enable/disable mailing](https://crm.torproject.org/civicrm/admin/job?reset=1&action=browse) (grep for `Send sched`...)
* [Where the batches are defined](https://crm.torproject.org/civicrm/admin/mail?reset=1) * [Where the batches are defined](https://crm.torproject.org/civicrm/admin/mail?reset=1)
* The [Civimail](https://crm.torproject.org/civicrm/mailing?reset=1) interface should show the latest mailings (when * The [Civimail](https://crm.torproject.org/civicrm/mailing?reset=1) interface should show the latest mailings (when
...@@ -52,11 +52,11 @@ in yellow and errors (bounces) in red. ...@@ -52,11 +52,11 @@ in yellow and errors (bounces) in red.
A few commands to inspect the email queue: A few commands to inspect the email queue:
* list the queue, with more recent entries first * List the queue, with more recent entries first
postqueue -j | jq -C .recipients[] | tac postqueue -j | jq -C .recipients[] | tac
* find how many emails in the queue, per domain: * Find how many emails in the queue, per domain:
postqueue -j | jq -r .recipients[].address | sed 's/.*@//' | sort | uniq -c | sort -n postqueue -j | jq -r .recipients[].address | sed 's/.*@//' | sort | uniq -c | sort -n
...@@ -114,15 +114,15 @@ to find the victim's email: ...@@ -114,15 +114,15 @@ to find the victim's email:
Once you have the email address: Once you have the email address:
1. head for the [CiviCRM search interface](https://crm.torproject.org/civicrm/contact/search?reset=1) to find that user 1. Head for the [CiviCRM search interface](https://crm.torproject.org/civicrm/contact/search?reset=1) to find that user
2. remove the from the "Tor News" group, in the `Group` tab 2. Remove the from the "Tor News" group, in the `Group` tab
Another option is to go in Donor record > Edit communication Another option is to go in Donor record > Edit communication
preferences > check do not email. preferences > check do not email.
Alternatively, you can just send an email to the `List-Unsubscribe` Alternatively, you can just send an email to the `List-Unsubscribe`
address or click the "unsubscribe" links at the bottom of the email. address or click the "unsubscribe" links at the bottom of the email.
The [handle-abuse.py](https://gitlab.torproject.org/tpo/tpa/fabric-tasks/-/blob/HEAD/handle-abuse.py) script in `fabric-tasks.git` automatically The [`handle-abuse.py`](https://gitlab.torproject.org/tpo/tpa/fabric-tasks/-/blob/HEAD/handle-abuse.py) script in `fabric-tasks.git` automatically
handles the CiviCRM bounces that way. Support for other bounces should handles the CiviCRM bounces that way. Support for other bounces should
be added there as we can. be added there as we can.
...@@ -130,7 +130,7 @@ Special cases should be reported to the CiviCRM admin by forwarding ...@@ -130,7 +130,7 @@ Special cases should be reported to the CiviCRM admin by forwarding
the email to the `Giving` queue in [RT](howto/rt). the email to the `Giving` queue in [RT](howto/rt).
Sometimes complaints come in about Mailman lists. Those are harder to Sometimes complaints come in about Mailman lists. Those are harder to
handle because they do not have individual bounce adresess... handle because they do not have individual bounce addresses...
## Granting access to the CiviCRM backend ## Granting access to the CiviCRM backend
...@@ -227,7 +227,7 @@ about the error: ...@@ -227,7 +227,7 @@ about the error:
To debug this, first find the "Scheduled Job Logs": To debug this, first find the "Scheduled Job Logs":
1. Go to Administer > System Settings > Scheduled Jobs 1. Go to Administer > System Settings > Scheduled Jobs
2. Find "Torcrm Resque Processing" 2. Find "TorCRM Resque Processing"
3. Click "view log" 3. Click "view log"
Here's a screenshot of such a log: Here's a screenshot of such a log:
...@@ -301,7 +301,7 @@ stack. ...@@ -301,7 +301,7 @@ stack.
The Puppet classes used on the CiviCRM server is The Puppet classes used on the CiviCRM server is
`roles::civicrm_int_2018`. That naming convention reflects the fact `roles::civicrm_int_2018`. That naming convention reflects the fact
that, before [donate-neo][], there used to be another roled named that, before [donate-neo][], there used to be another role named
`roles::civicrm_ext_2018` for the frontend, retired in `roles::civicrm_ext_2018` for the frontend, retired in
[tpo/tpa/team#41511](https://gitlab.torproject.org/tpo/tpa/team/-/issues/41511). [tpo/tpa/team#41511](https://gitlab.torproject.org/tpo/tpa/team/-/issues/41511).
...@@ -383,7 +383,7 @@ Apache answers to the following virtual hosts: ...@@ -383,7 +383,7 @@ Apache answers to the following virtual hosts:
* `staging.crm.torproject.org`: staging site * `staging.crm.torproject.org`: staging site
* `test.crm.torproject.org`: testing site * `test.crm.torproject.org`: testing site
The monthly newsletter is configured on CiviCRM and also archived on The monthly newsletter is configured on CiviCRM and archived on
the <https://newsletter.torproject.org> static site. the <https://newsletter.torproject.org> static site.
## Storage ## Storage
...@@ -449,7 +449,7 @@ Upstream also has their own [GitLab instance](https://lab.civicrm.org/). ...@@ -449,7 +449,7 @@ Upstream also has their own [GitLab instance](https://lab.civicrm.org/).
CiviCRM has a `torcrm` extension under CiviCRM has a `torcrm` extension under
`sites/all/civicrm_extensions/torcrm` which includes most of the CiviCRM `sites/all/civicrm_extensions/torcrm` which includes most of the CiviCRM
customizations, including the Resque Processor job. It replaces the customization, including the Resque Processor job. It replaces the
old `tor_donate` Drupal module, which is being phased out. old `tor_donate` Drupal module, which is being phased out.
## Related services ## Related services
...@@ -511,7 +511,7 @@ make sure both ends can talk to each other. ...@@ -511,7 +511,7 @@ make sure both ends can talk to each other.
There's also [Prometheus](howto/prometheus) monitoring with graphs rendered by There's also [Prometheus](howto/prometheus) monitoring with graphs rendered by
[Grafana](howto/grafana). This includes an elaborate [Postfix dashboard](https://grafana.torproject.org/d/Ds5BxBYGk/postfix-mtail?orgId=1&from=now-24h&to=now&var-node=eugeni.torproject.org&var-node=crm-int-01.torproject.org) [Grafana](howto/grafana). This includes an elaborate [Postfix dashboard](https://grafana.torproject.org/d/Ds5BxBYGk/postfix-mtail?orgId=1&from=now-24h&to=now&var-node=eugeni.torproject.org&var-node=crm-int-01.torproject.org)
watching to two mailservers. watching to two mail servers.
We started working on [monitoring the CiviCRM health better](https://gitlab.torproject.org/tpo/web/civicrm/-/issues/78). So We started working on [monitoring the CiviCRM health better](https://gitlab.torproject.org/tpo/web/civicrm/-/issues/78). So
far we collect metrics that look like this: far we collect metrics that look like this:
...@@ -551,12 +551,12 @@ civicrm_torcrm_resque_processor_status_up 1 ...@@ -551,12 +551,12 @@ civicrm_torcrm_resque_processor_status_up 1
``` ```
Those show the last timestamp of various jobs, the status of those Those show the last timestamp of various jobs, the status of those
jobs (`1` means ok), and whether the "kill switch" has been raised jobs (`1` means OK), and whether the "kill switch" has been raised
(`1` means ok, that is: not raised). (`1` means OK, that is: not raised).
Authentication to the CiviCRM server was particularly problematic: Authentication to the CiviCRM server was particularly problematic:
there's an open issue to convert the HTTP-layer authentication system there's an open issue to convert the HTTP-layer authentication system
to basic auth ([tpo/web/civicrm#147](https://gitlab.torproject.org/tpo/web/civicrm/-/issues/147)). to basic authentication ([tpo/web/civicrm#147](https://gitlab.torproject.org/tpo/web/civicrm/-/issues/147)).
We're hoping to get more metrics from CiviCRM, like detailed status of We're hoping to get more metrics from CiviCRM, like detailed status of
job failures, mailing run times and other statistics, see job failures, mailing run times and other statistics, see
...@@ -573,7 +573,7 @@ Note that the donate front-end also exports its own metrics, see the ...@@ -573,7 +573,7 @@ Note that the donate front-end also exports its own metrics, see the
TODO: what to test on major CiviCRM upgrades, specifically in CiviCRM? TODO: what to test on major CiviCRM upgrades, specifically in CiviCRM?
There's a [test procedure in donate.torproject.org](service/donate#tests) that should There's a [test procedure in `donate.torproject.org`](service/donate#tests) that should
likely be followed when there are significant changes performed on likely be followed when there are significant changes performed on
CiviCRM. CiviCRM.
...@@ -602,8 +602,8 @@ documentation](#mysql-backup-system). ...@@ -602,8 +602,8 @@ documentation](#mysql-backup-system).
Upstream has a [documentation portal](https://docs.civicrm.org/) where our users will find: Upstream has a [documentation portal](https://docs.civicrm.org/) where our users will find:
- [user guide](https://docs.civicrm.org/user/en/latest) - [User guide](https://docs.civicrm.org/user/en/latest)
- [sysadmin guide](https://docs.civicrm.org/sysadmin/en/latest/) - [Sysadmin guide](https://docs.civicrm.org/sysadmin/en/latest/)
# Discussion # Discussion
...@@ -631,7 +631,7 @@ TODO: ...@@ -631,7 +631,7 @@ TODO:
CiviCRM's deployment has simplified a bit since the launch of the new CiviCRM's deployment has simplified a bit since the launch of the new
[donate-neo](service/donate) frontend. We inherited a few of the complexities of [donate-neo](service/donate) frontend. We inherited a few of the complexities of
the original design, in particular the fragility of the coupling the original design, in particular the fragility of the coupling
between frontend and backend through the Redis / ipsec tunnel. between frontend and backend through the Redis / IPsec tunnel.
We also inherited the "two single points of failure" design from the We also inherited the "two single points of failure" design from the
original implementation, and actually made that worse by removing the original implementation, and actually made that worse by removing the
...@@ -655,7 +655,7 @@ separation between the CiviCRM backend and the middleware API evolved ...@@ -655,7 +655,7 @@ separation between the CiviCRM backend and the middleware API evolved
from an initial strict, two-server setup, into the current three-parts from an initial strict, two-server setup, into the current three-parts
component after the static site frontend was added around 2020. The component after the static site frontend was added around 2020. The
original two-server separation was performed out of a concern for original two-server separation was performed out of a concern for
security: we were worried about exposing CiviCRM to the public, security. We were worried about exposing CiviCRM to the public,
because we felt the attack surface of both Drupal and CiviCRM was too because we felt the attack surface of both Drupal and CiviCRM was too
wide to be reasonably defended against a determined attacker. wide to be reasonably defended against a determined attacker.
... ...
......