Clamp the min and max version for DSM 7.0 and DSM 7.2 packages when we
are building packages for the synology package centre. This change
leaves packages destined for pkgs.tailscale.com with just the min
version set to not break packages in the wild / our update flow.
Updates https://github.com/tailscale/corp/issues/22908
Signed-off-by: Mario Minardi <mario@tailscale.com>
Add separate builds for DSM7.2 for synology so that we can encode
separate versioning information in the INFO file to distinguish between
the two.
Fixes https://github.com/tailscale/corp/issues/22908
Signed-off-by: Mario Minardi <mario@tailscale.com>
Synology requires version numbers are within int32 range. This
change updates the version logic to keep things closer within the
range, and errors on building when the range is exceeded.
Updates #cleanup
Signed-off-by: Sonia Appasamy <sonia@tailscale.com>
Update logs for synology builds to more clearly callout which variant
is being built. The two existing variants are:
1. Sideloaded (can be manual installed on a device by anyone)
2. Package center distribution (by the tailscale team)
Updates #cleanup
Signed-off-by: Sonia Appasamy <sonia@tailscale.com>
We already had a path on the web client server struct, but hadn't
plumbed it through to the CLI. Add that now and use it for Synology and
QNAP instead of hard-coding the path. (Adding flag for QNAP is
tailscale/tailscale-qpkg#112) This will allow supporting other
environments (like unraid) without additional changes to the client/web
package.
Also fix a small bug in unraid handling to only include the csrf token
on POST requests.
Updates tailscale/corp#13775
Signed-off-by: Will Norris <will@tailscale.com>
This uses the new react-based web client for all builds, not just with
the --dev flag.
If the web client assets have not been built, the client will serve a
message that Tailscale was built without the web client, and link to
build instructions. Because we will include the web client in all of our
builds, this should only be seen by developers or users building from
source. (And eventually this will be replaced by attempting to download
needed assets as runtime.)
We do now checkin the build/index.html file, which serves the error
message when assets are unavailable. This will also eventually be used
to trigger in CI when new assets should be built and uploaded to a
well-known location.
Updates tailscale/corp#13775
Signed-off-by: Will Norris <will@tailscale.com>
Add `dist.Signer` hook which can arbitrarily sign linux/synology
artifacts. Plumb it through in `cmd/dist` and remove existing tarball
signing key. Distsign signing will happen on a remote machine, not using
a local key.
Updates #755
Updates #8760
Signed-off-by: Andrew Lytvynov <awly@tailscale.com>
This builds the assets for the new web client as part of our release
process. The path to the web client source is specified by the
-web-client-root flag. This allows corp builds to first vendor the
tailscale.com module, and then build the web client assets in the vendor
directory.
The default value for the -web-client-root flag is empty, so no assets
are built by default.
This is an update of the previously reverted 0fb95ec
Updates tailscale/corp#13775
Signed-off-by: Will Norris <will@tailscale.com>
This caused breakages on the build server:
synology/dsm7/x86_64: chdir /home/ubuntu/builds/2023-08-21T21-47-38Z-unstable-main-tagged-devices/0/client/web: no such file or directory
synology/dsm7/i686: chdir /home/ubuntu/builds/2023-08-21T21-47-38Z-unstable-main-tagged-devices/0/client/web: no such file or directory
synology/dsm7/armv8: chdir /home/ubuntu/builds/2023-08-21T21-47-38Z-unstable-main-tagged-devices/0/client/web: no such file or directory
...
Reverting while I investigate.
This reverts commit 0fb95ec07d.
Signed-off-by: Will Norris <will@tailscale.com>
This builds the assets for the new web client as part of our release
process. These assets will soon be embedded into the cmd/tailscale
binary, but are not actually done so yet.
Updates tailscale/corp#13775
Signed-off-by: Will Norris <will@tailscale.com>
As far as I can tell from the DSM documentation and known undocumented
fields, there is no 'version' field in this config file that DSM cares
about.
Updates #8232
Signed-off-by: David Anderson <danderson@tailscale.com>
This platform is technically an armv7, but has no hardware floating
point unit. armv5 is the only target Go understands to lack floating
point, so use that.
Updates #6860
Signed-off-by: David Anderson <danderson@tailscale.com>