Where is 18.06.3?

I also think this is the best way to do it.

However, the router has been put into use, and it currently links 40 devices.
So reinstallation will stop most people in the company for a while.

I would like to try not to change firmware if I can.
What other methods are recommended?

If you’ve got 40 people depending on a single piece of relatively inexpensive hardware, a spare for the future would be highly recommended.

If you can function without zerotier, I would wait. If I were in your shoes, I’d be building from source all the time (control of what I build and faster security by a couple days) and testing on a second router. That’s what I do at home, even more important in a business environment.

Downgrading would not be my choice as it increases the possibility of a config issue.

5 Likes

Coming back to the initial question: Where is 18.06.3?

See jow's explanation of what happened:
http://lists.infradead.org/pipermail/openwrt-devel/2019-June/017808.html
http://lists.infradead.org/pipermail/openwrt-devel/2019-June/017809.html

This process will unfortunately also delay 18.06.3 and 17.07.7 releases until further notice.

Let's hope the problem can be fixed quickly.

5 Likes

Thanks for updates.

Is this why the package server is broken? I cannot download any of the files under https://downloads.openwrt.org/releases/18.06.2/packages/arm_cortex-a15_neon-vfpv4/base right now; the server gives a 403 Forbidden error.

I'm trying to install a package to my 18.06.02 router and it's failing to download because of that.

1 Like

but i am already building from the git v18.06.3 tag, so that is correct, right? just something is wrong with the buildbots? or is it going to be 18.06.4 instead of 18.06.3?

See above:

2 Likes

so i built it for myself correct, but only the buildbots are wrong, so that is good, as i built already 3 targets.

http://lists.infradead.org/pipermail/openwrt-devel/2019-June/017811.html

5 Likes

http://lists.infradead.org/pipermail/openwrt-devel/2019-June/017818.html

1 Like

To really screw it up just a computer into the mix.

Sounds like the procedure and strategy for managing the repository directories needs a revision or two once the crisis is averted.

These may be obvious and/or wrong, but are offered in case they are useful.

  • Releases should be protected and resiliant at the filesystem level.

For example:

  • Write permissions removed on the filesystem level as a crucial step before the componets of a release are deployed and announced.
  • "Pointer based" updates, if updates are necessary. Ie, change a symlink or the directory path in a webserver config file in order to switch from the old directory tree to the new directory tree.
  • Occasionally tested, quick and easy to restore nearline and offsite backups.

These can come in handy for other issues, too, like compromises that give an attacker non-root access to the filesystem (like a compromised webserver binary/user).

1 Like

There are plans to create an openwrt-announcement list. So eventually you can subscribe to that once it is available to get notified whenever a new version is ready to deploy.

2 Likes

It would be extraordinary!

1 Like

irrelevant fun fact: I think I have used at least one release from each version from Whiterussian onward :slight_smile:

Now two new versions have appeared: again 18.06.3 and even 18.06.4. But this time they don't cheat me! If I understand there is an automatic system that builds releases and sometimes makes mistakes. Then I will wait for the release of the new version on the main page of the project; for now we are at 18.06.2.

1 Like

18.06.4 has been officially released:

Forum Post
Website Relase Notes

Thanks. Just installed and working.

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.