Turris OS 6.0.2 is now released

[Pepe]

I presume that Tailscale will stay at 1.24.2 in OpenWRT 21.02 for the lifetime of that release. Correct?

It could be, but Tailscale should be updated in the OpenWrt master branch, and then it could be backported. Still, since the newer Tailscale version requires a newer version of Golang, thus it could be complicated to have it backported to OpenWrt 21.02, so you will see if you will create a pull request to OpenWrt packages feed.

I presume that Tailscale will stay at 1.24.2 in TOS until TOS upgrades to a newer OpenWRT. Correct?

As I said, currently, in all OpenWrt supported versions, there is the same version of Tailscale. If someone updates it in the meantime in OpenWrt 22.03, then you will see the new Tailscale version once we update Turris OS to OpenWrt 22.03. Otherwise, the version would be the same if nobody steps in.

Given the pace of Tailscale development, if we wanted to ensure that TOS has a version of Tailscale that is as up to date as possible (TBD what “possible” means), how would we go about it?

Short version: The community should step it, and prepare OpenWrt build system, or you can use scripts to prepare the Turris environment. You need to get familiar with how to compile packages for OpenWrt. Then you can test it on your router, upstream it.

@mato

Edit: We can also take this to a Gitlab issue if you like, so as not to spam this thread.

That will be closed immediately since this does not belong to our GitLab as I said in the first place because it is an upstream issue not ours.

[mato]

@Pepe

Still, since the newer Tailscale version requires a newer version of Golang, thus it could be complicated to have it backported to OpenWrt 21.02

Yes, that’s problematic but not impossible.

@Pepe

If someone updates it in the meantime in OpenWrt 22.03, then you will see the new Tailscale version once we update Turris OS to OpenWrt 22.03.

What sort of timeframes are we talking about here? If someone were to update Tailscale in OpenWRT, how long would you expect it for that upstream version to make it into TOS? To be clear, I’m not asking for a commitment from you here, I’m just trying to understand the process involved as it stands today.

@Pepe

That will be closed immediately since this does not belong to our GitLab as I said in the first place because it is an upstream issue not ours.

So, what you’re saying is that the current preferred (only?) way for Tailscale to get shipped in TOS is via upstream OpenWRT? If I were to submit a set of patches to TOS directly that updated Tailscale in TOS then those wouldn’t be accepted?

Alternatively, if someone were to provide a maintained package repository with upstream Tailscale packages that work on TOS 6.0, would you be willing to point TOS + Tailscale users at that repository? (Via the Wiki, documentation, etc?)

[Pepe]

@mato

What sort of timeframes are we talking about here? If someone were to update Tailscale in OpenWRT, how long would you expect it for that upstream version to make it into TOS? To be clear, I’m not asking

We are following or tracking the OpenWrt branches, so each Turris OS version uses the latest changes, which were in that time for the relevant OpenWrt version. I’m sure that this is described somewhere (in Turris Build repository documentation, or you can find it in user-docs repository).

You can check the git-hash file on repo.turris.cz for each branch.

@mato

So, what you’re saying is that the current preferred (only?) way for Tailscale to get shipped in TOS is via upstream OpenWRT?

Yes, everything belongs to upstream and since most packages come from OpenWrt as it is, then it should be there.

@mato

If I were to submit a set of patches to TOS directly that updated Tailscale in TOS then those wouldn’t be accepted?

Why would we increase our maintainership and efforts if it happens that it does not compile or it does not run as it should? It could be broken anytime that it means that we will need to take a look, at why it is broken, and what we can do about it. That’s why it should be sent to upstream in the first place. Everything is about priorities and some things have higher priority than others.

@mato

Alternatively, if someone were to provide a maintained package repository with upstream Tailscale packages that work on TOS 6.0, would you be willing to point TOS + Tailscale users at that repository? (Via the Wiki, documentation, etc?)

Nope, we are not going to that. It will mean that we will need to support it. Our support has different duties than supporting any package in OpenWrt. We provide support only for things, which you can do in reForis and configure it, there.

[tac2]

I guess you could roll on a personal patchset if you require specific sw versions?

Or build your personal TOS build?

If the way with upstream openwrt is not ”fast” enough

[mato]

@tac2

I guess you could roll on a personal patchset if you require specific sw versions?

Or build your personal TOS build?

I could do all of those things. But, if I’m doing it solely for my own use, I may as well keep using the static binaries provided by Tailscale and /etc/rc.local. I was just trying to figure out if it was worth and possible to maintain a “better” and up to date integration of Tailscale for TOS from which others could benefit.

AFAICT there’s no way to to ship such a thing to users, so there’s no point in working on it.

[iron-maiden]

@Pepe explained it enough, you can maintain it yourself if you need newer version and moreover you can do pull request in order other Turris users may benefit also

There are thousands of packages which cant be maintained per user request. Turris OS 6.0 is simply based on OpenWrt 21.02. If you are not happy you can try Turris OS 7.0.

[mato]

@iron-maiden I’m not asking anyone to maintain anything, I was trying to understand what the process was for a package (specifically, Tailscale) to make it from upstream into TOS.

I understand that now, and the constraints involved so thanks @pepe for explaining. Having slept on it, I have an idea for an automated process to get upstream Tailscale updates that’s as “maintenance-free” as possible. Will try and implement it and come back when I have something that works.

[dhopfm]

@mato

AFAICT there’s no way to to ship such a thing to users, so there’s no point in working on it.

If maintaining the OpenWrt package doesn’t fit your requirements (in terms of update frequency or whatever) then you could still run your own repository and package feed and point users to it through a forum thread such as this one. If there’s substantial interest in that feed then I’m sure that it will be possible to reference it in more prominent places as well.

[mato]

@dhopfm

If maintaining the OpenWrt package doesn’t fit your requirements (in terms of update frequency or whatever) then you could still run your own repository and package feed

Yeah, that’s the idea. I’ll see if I can figure out an automated and transparent way of doing that using the binaries built by upstream (which sidesteps the issue of needing a newer Golang in the OpenWRT base).

[Cryx]

@mvasilek

Fixed initial user creation for Nextcloud

But it doesn’t work… My MOX is up to date, Nextcloud was freshly added to system afterwards, but the problem is still there.

[dhopfm]

Please start a new thread and describe the problem.

[keiler3k]

This problem is also present on my Turris Omnia since TOS6.0.
The issue tracker only mentions Turris 1.1.

root@turris:~# sentinel-fwlogs
Packet handling failed: Resource temporarily unavailable

From the issue tracker I gather that the problem is not fixable at the moment?

[mato]

@mato

Will try and implement it and come back when I have something that works.

Following up on this as promised, I’ve developed some automated tooling to build packages of upstream Tailscale for Turris OS. Github repo is here and feedback welcome in a separate forum thread.