Replace Redis for alternate key/value server & rename "Redis" appliance

[JedMeister]

Redis have changed their licence (see redis/redis#13157), so we should probably change to an alternate fork.

There appear to be 2 main options - licensed differently:

Redict is LGPLv3:
https://codeberg.org/redict/redict

valkey is BSD 3-clause:
https://github.com/valkey-io/valkey

As we install Redis from the Debian repos, we won't need to address this until v19.0

[JedMeister]

FWIW at least on first appearances "Valkey" seems to be winning the "post-redis open source key-value server war".

Not that's it's necessarily the only reason to chose Valkey as the "Redis appliance" successor, but It's backed by 3 of the "big cloud" providers; AWS, Google & Oracle - plus many other big, well known companies. Staff members of those first three appear to be the core maintainers. From a long term maintenance perspective that might be the best way to go?

Redict seems to have pretty limited recent development (last commit ~2 months ago). Valkey is much more active (last commit ~7 hours ago) and ~200 more commits that Redict. Valkey has 14.5k stars here on GH. Not that all that is the be all and end all, but it seems like the better option for us.

[pshankinclarke]

Hi @JedMeister, after following this thread I put together a TurnKey Linux Valkey appliance as a drop-in for the Redis one. I started from the Redis appliance and swapped the backend to valkey-server from Debian bookworm-backports. I also updated the candidates wiki and added a whiteboard entry. Repo: https://github.com/pshankinclarke/turnkey-valkey
. I kept the changes minimal so it tracks TKLDev/Valkey updates easily. Happy to adjust anything to better match TurnKey conventions.

[JedMeister]

@pshankinclarke - Nice work! You rock.

I've only had a quick glance, but it good. I'm currently pretty snowed under trying to get things in place for our next major version release - v19.0; based on Debian Trixie (as always a bit behind schedule...). I'm hoping that I'll have an initial v19.0 RC release of Core and TKLDev within the next couple of weeks.

So considering where things are at, it might be best to release your new appliance as v19.0 - based on Trixie. I'll try to remember to post back as soon as we have an updated TKLDev.

[pshankinclarke]

Thanks @JedMeister! Releasing a Trixie-based v19.0 appliance sounds great. In anticipation, I've pushed a minimal v19-trixie branch that switches the appliance to Debian Trixie's valkey-server (instead of Bookworm backports): https://github.com/pshankinclarke/turnkey-valkey/tree/v19-trixie.

If you haven’t already seen it, there were recent Lua-scripting CVEs affecting Valkey/Redis. Upstream Valkey fixed them in 8.1.4 / 8.0.6. Trixie’s package is currently 8.1.1+dfsg1-3, so if v19 lands before Debian ships the patched build, I plan to temporarily run an upstream build of Valkey and switch back to the Debian package once it’s updated.

[JedMeister]

Apologies (again) for slow response.

It looks like the relevant Valkey vulnerabilities have been addressed - see https://security-tracker.debian.org/tracker/DSA-6022-1

FYI we're getting pretty close to an initial v19.0 release but have hit up against a couple of issues that are blocking release. Hopefully we can resolve them soon and move forward.