`tailscale update` is not compatible with Deb 822 style sources

[evilhamsterman]

What is the issue?

The command to update Tailscale on Debian systems tries to run apt-get update with only the Tailscale repository. However it is only looking for the expected classic repo.list style file https://github.com/tailscale/tailscale/blob/02c6af2a69a8d33b2841fa094fa1d29bd16dd099/clientupdate/clientupdate.go#L428, if you use a newer Deb 822 style file https://repolib.readthedocs.io/en/latest/index.html which named repo.sources it fails as it is unable to find the file.

$ sudo tailscale update
This will update Tailscale from 1.62.0 to 1.64.0. Continue? [y/n] y
open /etc/apt/sources.list.d/tailscale.list: no such file or directory

Steps to reproduce

Install Tailscale using a Deb 822 style file for example

X-Repolib-Name: tailscale
Types: deb
URIs: https://pkgs.tailscale.com/stable/ubuntu
Suites: jammy
Components: main
Signed-By: /etc/apt/keyrings/tailscale.gpg

When an update is available run tailscale update

Are there any recent changes that introduced the issue?

No response

OS

Linux

OS version

Ubuntu 22.04

Tailscale version

1.62 1.64

Other software

No response

Bug report

BUG-dc901c8a61efc7d44a8ffd7adfd3efa04c9998230924a1547702243203fe98bd-20240418190354Z-d026f66c2f6eb607

[bradfitz]

What wrote the 822 style file?

https://tailscale.com/install.sh didn't, did it?

Do we document that 822 style anywhere in our KB?

[evilhamsterman]

We use Ansible to manage instances and prefer to use the new style because the Ansible module just needs the URL to your key and repository as provided here https://tailscale.com/kb/1187/install-ubuntu-2204 to generate and manage the repository.

[bradfitz]

Okay, I think I understand now, but to be clear and to help prioritize: nothing in Tailscale or Debian actually wrote that file, right? It was entirely "self-inflicted" if it were, by you writing that file format and then trying to use tailscale update? But another question, though: if you're using Ansible to have a declarative config of your fleet, why are you running imperative commands like tailscale update to manually update things? That seems counter to why you'd be using Ansible? Or are you using auto-updates and not actually invoking tailscale update manually?

[evilhamsterman]

Yes it is "self-inflicted" and we are using auto-updates, but I manually ran tailscale update when I noticed none of the machines were auto updating. We use Ansible to ensure we have Tailscale but auto-updates to make sure we are always running the latest version.

It would be fine if the code just ran a regular apt-get update I'm not sure what the reasoning is to only update the Tailscale repo. Updating the apt database is not a disruptive action. If you're concerned that someone doesn't want to regularly update the apt database they likely don't want to auto update Tailscale either.

[evilhamsterman]

I see how it would be more difficult to handle both formats since you can also use the command to switch tracks. That might be a reason to switch to 822 style, while not defined to be a YAML file it is parseable as YAML for a use case like this.

[awly]

@evilhamsterman are you using https://github.com/artis3n/ansible-role-tailscale by chance?

[evilhamsterman]

No it's our own playbook. I'm considering switching to using the old style .list for now. We just default to using the 822 module because it is easier, one module instead of at least two.

[evilhamsterman]

This is the module it was only recently added so many roles don't use it but more may https://docs.ansible.com/ansible/latest/collections/ansible/builtin/deb822_repository_module.html

[awly]

Thanks for the info!

I think we will keep our restriction/expectation of /etc/apt/sources.list.d/tailscale.list being the source for a few reasons:

• this keeps our update code more robust (fewer bugs)
• we avoid accidentally updating important transitive dependencies (tailscale depends on iptables, which depends on libc) which would trigger restarts of many other services without -o Dir::Etc::SourceList=sources.list.d/tailscale.list
• this way we keep track switching working (tailscale update --track=...) trivially

Given that it's a preference and not a hard requirement on your side to use dev822 format, switching to the expected tailscale.list format and path will unblock auto-updates. You can also use unattended upgrades as an alternative mechanism to auto-update Tailscale with dev822.

[stephanGarland]

I see this is closed, but I'd like to also support the addition of DEB822 as an option. I'm in precisely the same predicament as OP with Ansible. I create machine images for Proxmox with Packer + Ansible, but I don't consider them immutable and allow various things to self-update.

Is it possible / desired to have something like this (forgive my horrible Go):

tailscaleList := "/etc/apt/sources.list.d/tailscale.list"
tailscaleSources := "/etc/apt/sources.list.d/tailscale.sources"
var debianTailscaleSource string

if _, err := os.Stat(tailscaleList); err == nil {
    debianTailscaleSource =  strings.TrimPrefix(tailscaleList, "/etc/apt/")
} else if _, err := os.Stat(tailscaleSources); err == nil {
    debianTailscaleSource = strings.TrimPrefix(tailscaleSources, "/etc/apt/")
}

sourceOption := fmt.Sprintf("Dir::Etc::SourceList=%s", debianTailscaleSource)
cmd := exec.Command("apt-get", "update",
        "-o", sourceOption
        "-o", "Dir::Etc::SourceParts=-",
        "-o", "APT::Get::List-Cleanup=0",
)

[awly]

@stephanGarland that's a pretty good suggestion! We'd also have to update https://github.com/tailscale/tailscale/blob/12ad1423d0fd9db3df682de8f099d871a7f35928/clientupdate/clientupdate.go#L421-L425 where we switch the release track name in the file if requested. So it at least need to implement parsing for DEB822 formats.

[stephanGarland]

where we switch the release track name in the file if requested. So it at least need to implement parsing for DEB822 formats.

I’m a bit busy with work ATM (and also have little actual experience with Go), but don’t mind taking a crack at this soon-ish if you need a volunteer. If you’re going to implement it, by all means do so. Undoubtedly faster than I could manage.

[awly]

No worries, I'm happy to implement it, probably next week though.

[evilhamsterman]

If it's a possibility to implement I have another thought, perhaps a bit beyond this issue but a thought. Why not switch your own install script to 822 format? They aren't pushing it very hard but it is eventually intended to become the default and the old .list style will be deprecated.

Support was added in apt 1.1 which came out almost a decade ago in 2015 which means all non EOL Debian and derivatives support it. You could get rid of the legacy path in your install script, along with apt-key, third party keyrings became the preferred method around Bullseye but we're supported prior especially with 822. It is designed to be more easily machine parsable and human readable. Lots of reasons it should just become the default apps go to instead of .list style.