Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 8 commits into from Apr 4, 2022

Conversation

holta
Copy link
Member

@holta holta commented Apr 3, 2022

Thanks to @jvonau's ideas at #3158 and building on:

This PR also overhauls and dramatically simplifies the installation of remote.it's Device Package, using their official 1-line installer ("curl -L https://downloads.remote.it/remoteit/install_agent.sh") as recommended by their 2022-01-24 document "Streamlined installation for Linux and Raspberry Pi platforms".

Note that apt purge remoteit* is regrettably necessary at this time [prior to running remote.it's install_agent.sh], in order to get a new Claim Code in many corner cases, and for several reasons. One of those reasons is that the Device Package .deb files (same thing you get at https://remote.it/download/) are oddly each built in slightly different ways. Without going into all the ugly details, the situation and its resolution are summarized here:

https://github.com/holta/iiab/blob/5854ab7c619b3c01446951f925c5f27eb37ed077/roles/remoteit/templates/iiab-remoteit#L32-L34

FYI this PR intentionally avoids Ansible, so that the /usr/bin/iiab-remoteit command runs as quickly and resiliently as possible, quite similar to /usr/bin/iiab-support with OpenVPN.

This PR is tested on the latest pre-release of Ubuntu Desktop 22.04, with more testing ongoing on other OS's too, including 32-bit and 64-bit RasPiOS on Raspberry Pi 4.

@holta holta added this to the 8.0 milestone Apr 3, 2022

if grep -q '^remoteit_installed:' /etc/iiab/iiab_state.yml; then
sed -i "s/^remoteit_installed:.*/remoteit_installed: True/" /etc/iiab/iiab_state.yml
else
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

_installed: True are the only entries found in iiab_state, if ! and just the echo if missing seems more appropriate, does away with the unneeded sed alteration shorting the code

Copy link
Member Author

@holta holta Apr 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense.

(Unless /etc/iiab/iiab_state.yml hypothetically changes in future, to store other kinds of state...)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Other new states sure I can see that, I doubt you are refactoring every role to drop is defined for any reason other than code churn.

@jvonau
Copy link
Contributor

jvonau commented Apr 3, 2022

The forced reinstall is a pretty big hammer and might be able to go away. I've discovered that removing /etc/remoteit/config.json and then restarting connectd results in a new config.json with a different 'id' & 'claim' being generated, looks like 'name' is generated from the hostname of the machine.

FYI this PR intentionally avoids Ansible, so that the /usr/bin/iiab-remoteit command runs as quickly and resiliently as possible, quite similar to /usr/bin/iiab-support with OpenVPN.

Just to clarify, the current logic in iiab-support that skips using ansible relies on ansible being run at least once to install the role otherwise ansible will be used used to install openvpn to place all the template files in to their correct locations.

@holta
Copy link
Member Author

holta commented Apr 3, 2022

Aside; It appears remote.it is hardly bug-free on Raspberry Pi.

If so this is unfortunate and a bit surprising, as the company has a very long history working with Raspberry Pis.

Still, let's try to get more feedback from more implementers to see what many different people's experiences are in coming weeks and months.

@jvonau
Copy link
Contributor

jvonau commented Apr 3, 2022

On ubuntu-22.04 running curl -L https://downloads.remote.it/remoteit/install_agent.sh | sudo sh by hand results in the restart services dialog box coming to the forefront and not being able to tab over to 'ok', can't see how ansible will be able to proceed given this stall
Screenshot from 2022-04-03 09-30-40

@holta
Copy link
Member Author

holta commented Apr 3, 2022

On ubuntu-22.04 running curl -L https://downloads.remote.it/remoteit/install_agent.sh | sudo sh by hand results in the restart services dialog box coming to the forefront and not being able to tab over to 'ok', can't see how ansible will be able to proceed

It's a good question as to why this in fact works without stalling from scripts and from Ansible.

I'd love to know the answer — as this happens in other situations too — specifically: such scripts do consistently work even on graphical desktop OS's, e.g. when invoked from a script or from Ansible, instead of from a graphical command-line.

(Possibly this has something to do with the particular environment variables or similar, within a graphical [I meant interactive] terminal, [versus non-interactive scripts] ?)

@holta
Copy link
Member Author

holta commented Apr 3, 2022

I've discovered that removing /etc/remoteit/config.json and then restarting connectd results in a new config.json with a different 'id' & 'claim' being generated, looks like 'name' is generated from the hostname of the machine.

This is very promising. I've seen 1 instance where this did not work, but it would seem to work a vast majority of the time.

@jvonau
Copy link
Contributor

jvonau commented Apr 3, 2022

On ubuntu-22.04 running curl -L https://downloads.remote.it/remoteit/install_agent.sh | sudo sh by hand results in the restart services dialog box coming to the forefront and not being able to tab over to 'ok', can't see how ansible will be able to proceed

It's a good question as to why this in fact works without stalling from scripts and from Ansible.

I'd love to know the answer — as this happens in other situations too — specifically: such scripts do consistently work even on graphical desktop OS's, e.g. when invoked from a script or from Ansible, instead of from a graphical command-line.

This was from a ssh session with no desktop installed.

(Possibly this has something to do with the particular environment variables or similar, within a graphical terminal ?)

no graphics just a cmdline over ssh

@holta
Copy link
Member Author

holta commented Apr 3, 2022

no graphics just a cmdline over ssh

Indeed. I should not have said a literal graphical desktop (in the style of X Windows, etc). Certainly it works from scripts/Ansible.

But I don't know the exact dynamics. I (suspect?) it has something to do with shell environment variables — that somehow establish whether it's an interactive session or not.

Likewise: The needrestart command (that recent Ubuntu-like OS's use when you apt update) shows the same behavior — it prompts you colorfully if you're running from an interactive terminal / shell — but somehow is wise enough not to get stuck when the same command runs from a script.

@holta holta marked this pull request as draft April 3, 2022 16:10
@jvonau
Copy link
Contributor

jvonau commented Apr 3, 2022

no graphics just a cmdline over ssh

Indeed. I should not have said a literal graphical desktop (in the style of X Windows, etc). Certainly it works from scripts/Ansible.

But I don't know the exact dynamics. I (suspect?) it has something to do with shell environment variables — that somehow establish whether it's an interactive session or not.

Likewise: The needrestart command (that recent Ubuntu-like OS's use when you apt update) shows the same behavior — it prompts you colorfully if you're running from an interactive terminal / shell — but somehow is wise enough not to get stuck when the same command runs from a script.

You still have to tab over to OK and then enter to proceed when using /usr/bin/iiab-remoteit, same as doing a wget of install_agent.sh then sudo bash install_agent.sh(yea I could of chmod it) only using curl directly doesn't allow one to tab over to OK. Must have an interactive tty flag somewhere that ansible and/or needrestart makes use of.

@jvonau
Copy link
Contributor

jvonau commented Apr 3, 2022

#3011 (comment) additional inspiration for this PR.

I've discovered that removing /etc/remoteit/config.json and then restarting connectd results in a new config.json with a different 'id' & 'claim' being generated, looks like 'name' is generated from the hostname of the machine.

This is very promising. I've seen 1 instance where this did not work, but it would seem to work a vast majority of the time.

Think the only time this won't work if there is a /etc/remoteit/registration file present.

@holta holta marked this pull request as ready for review April 4, 2022 02:00
@holta
Copy link
Member Author

holta commented Apr 4, 2022

Heavily tested on Ubuntu 22.04 pre-release (VM).

Time to push this and seek out broader community feedback as more people bang on this and use it in many different ways.

Many thanks to @jvonau whose insight into deleting /etc/remoteit/config.json and then restarting systemd service connectd was instrumental to the new command /usr/bin/iiab-remoteit quickly obtaining a new claim code.

(Hopefully this undocumented feature[*] will remain working as part of remote.it Device Packages for years to come, if we're lucky!)

[*] Hinted at within https://support.remote.it/hc/en-us/articles/360061228252-Oops-I-cloned-an-SD-card-

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants