remoteit/tasks/enable-or-disable.yml: Don't fail if svc(s) missing

[holta]

This PR allows remoteit_enabled: False to be enforced without failing, e.g. after remote.it "Device Package" 4.15.2 (released yesterday) is installed by apt.

Just FYI:

1. Most IIAB users/operators won't know to touch /etc/remoteit/registration prior to running apt dist-upgrade (or, equivalently apt install remoteit) and so apt will visually provide them a remote.it "Claim Code" (whether they want it or not!)

2. They should however then (if they choose!) retain the option of running the following, to turn off remote.it services:

   cd /opt/iiab/iiab
   ./runrole remoteit
   

Building on:

• PR New command /usr/bin/iiab-remoteit to quickly obtain a new Claim Code for https://remote.it (allows remote connections to manage an IIAB) #3161

[holta]

This PR allows remoteit_enabled: False to be enforced without failing

cd /opt/iiab/iiab
./runrole remoteit

FYI prior to merging this PR, this (new) error would result trying to stop & disable systemd service connectd :

TASK [remoteit : Disable & Stop remote.it services {connectd, schannel}] *******
failed: [127.0.0.1] (item=connectd) => {"ansible_loop_var": "item", "changed": false, "item": "connectd", "msg": "Could not find the requested service connectd: host"}
changed: [127.0.0.1] => (item=schannel)

[holta]

README for those wanting more details:

https://github.com/iiab/iiab/tree/master/roles/remoteit#readme

[jvonau]

When would the remoteit role ever be used a second time once installed given the push to use the helper scripts? The need to 'touch' 'registration' would not be needed if the file was not removed post install.

[holta]

When would the remoteit role ever be used a second time once installed given the push to use the helper scripts? The need to 'touch' 'registration' would not be needed if the file was not removed post install.

Just talked to @jvonau about this.

It's somewhat complicated by the fact that /etc/remoteit/registration and remoteit_enabled: False are both independently acting as very similar flags, somewhat violating SSOT.

On the bright side, the current state of affairs isn't tragic, in that remote.it is somewhat over-advertised, pushing IIAB operators to get to know the product if they run apt update and then apply those updates every fews months, entirely at their own risk.

On the negative side, these 2 flags are somewhat contradicting, so I'll think about whether a cleaner alignment of these 2 flags (i.e. both flags co-habiting with each other in a more sane way) can be enacted without too much complication.

[holta]

complicated by the fact that /etc/remoteit/registration and remoteit_enabled: False are both independently acting as very similar flags, somewhat violating SSOT

Just a clarification:

Both enable-or-disable.yml and /usr/bin/iiab-remoteit will need to be substantially reworked, if we go ahead with this simple-but-not-quite-so-simple change (-:

Long Story Short: /etc/remoteit/registration cannot be ruthlessly wiped, as it might contain valid remote.it registration.
So a number of conditionals would need to be set up, to act on the existence of this file — but only if it contains zero bytes.

Recap: I'm not against the idea, but it will/would require deliberate/careful design thinking (and quite a number of testing paths to verify!)