-
Notifications
You must be signed in to change notification settings - Fork 5
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
Accept UUID.local
hostnames
#4
base: master
Are you sure you want to change the base?
Conversation
This extends the script to accept `UUID.local` hostnames for local-mode devices, in addition to the `UUID.balena` hostnames already accepted for remote devices. If the `.local` suffix is detected, the proxy is disabled and a direct connection is established instead.
Thanks the contribution! 👍 Would you mind updating the README file as well? Passages such as:
|
if [[ "${SSUU_SCP}" = 0 && | ||
"${arg}" =~ ^(ssh://)?((.+)@)?([[:xdigit:]]{32}|[[:xdigit:]]{62})\.balena(:[0-9]+)?$ | ||
"${arg}" =~ ^(ssh://)?((.+)@)?([[:xdigit:]]{7}|[[:xdigit:]]{32}|[[:xdigit:]]{62})\.(balena|local)(:[0-9]+)?$ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In a previous comment, I asked you to update the README file to clarify that 7-character UUIDs can be used with .local
hostnames. However, hang on — I’ve thought of something. For a remote device reachable through the Balena cloud proxy server, the UUID has a special meaning as the identifier of the device in the cloud. Therefore, a regex ensuring a hexadecimal string of a certain length makes sense. However, for a .local
hostname like abc1234.local
(7-char UUID), the UUID is merely the device’s hostname discoverable through mDNS / Ahavi and configurable through the device’s config.json file. In this case, abc1234.local
(7-char hex) is just as good as foo.local
(if config.json
specified "hostname": "foo"
), and a regex requiring a 7-char hex string would be unnecessarily restrictive.
Does that make sense? So the code could / should be changed to simply check for a .local
hostname suffix, in which case any string should be allowed as the hostname prefix. Then the README could be updated along the following lines:
Before:
The device's ssh/scp hostname has the format
'<device-UUID>.balena'
, using the device's
-full UUID (not a shortened form).
After:
The device’s ssh/scp hostname should have one of the following formats:
'<device-UUID>.balena'
- Remote devices reachable through Balena’s cloud proxy server.'<hostname>.local'
- Devices on the same local network as the client.For remote devices,
<device-UUID>
must be the device’s “full” UUID (32 or 62 characters long). For local devices,<hostname>
is the device’s hostname configured in its config.json file — by default, it is the device’s 7-character short UUID.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, in this PR’s initial approach, abc1234.balena
would not fail the regex check, but it should fail the regex check in order to alert the user of a hostname problem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure thing! That sounds like a very reasonable approach.
This extends the script to accept
UUID.local
hostnames for local-mode devices, in addition to theUUID.balena
hostnames already accepted for remote devices. If the.local
suffix is detected, the proxy is disabled and a direct connection is established instead.