14.x users should be aware bind 9.11.x an ESV, is EOL December 31 2021 - yep next month.

It may receive critical security updates through only Q1, 2022, but non security related bugs, no matter how nasty, will no longer be fixed.

ISC is happy however to declare 9.16 as ESV

This likely means a lot of manual source-built updates to slackware older than 14.2 to meet deps to build 9.16

for slackware 14.2 you only need libuv, but will need to use ./configure --without-python unless you want to pl;ay dep hell in upgrading that, but its not needed so why bother.


also of note 9.18.0 is planned at this stage for release in January 2022

Thanks for the heads up!

Makes me wonder if Pat will upgrade bind in 14.2 or if I should bite the bullet and upgrade my bind servers to current.

Thanks Nobby6,

During building I found that libidn2 was also required,
however, got problems during install on slackware 14.2.
So, I have to recover and reinstall the previous version.

It might be better to have a version build by Pat.

talo

Hi, I upgraded bind to 9.16.22 on my 14.2 servers. You need to build and install libuv and optionnally python-ply.

1 members found this post helpful.

You're welcome, hrmm... isn't libidn2 part of a normal slackware 14.2 install? idnkit IIRC?
The 14.2 box I have only has stock libraries - until libuv that is, as its used for release testing of bind and apache, I try keep it as clean as I can

The issue I see with Pat upgrading is, since it needs libuv thats a new package not in 14.2 (or slackpkg install didnt find it for some reason when I asked it), so I can't see Pat risking breakage, because jooe or jill average don't read the changelog.

All my production servers run current, the last were moved over just before last Christmas, there's been no glitches apart from the major gcc version bump, and even that only affected an older 32 bit machine with mariadb (our news server software is unable to run 64bit... or ipv6

I have multiple 14.2 physical servers plus a current physical server. The production services run inside multiple 14.2 unprivileged LXC plus a current unprivileged LXC.

I've enjoyed the stability of the 14.2 servers but after so many changes in current I expect a challenging upgrade migration.

Yeah, 5 years plus, a lot has changed, I wouldn't expect you have too much pain though, but if you have a lot of perl modules, sometimes cpan -r does not catch everything, and a slow one by one process to resolve the module issues, lot of modules that needed to be manually d/l and installed in the past are now included, that's one big gotchya too, else things hit mismatches, that was few hours of fun cleaning it all up

But as we upgraded our servers we did fresh installs (we use bare metal, only 1 virtual server anywhere and thats an offsite 14.2 tertiary DNS) don't use lxc or any other virtual locally so cant comment of what might blow up, but I've done dist upgrades in previous years, mostly painless.

Hello Nobby6

Idn2 isn't in the original filelist of 14.2, but I succeeded to build an x32 and also an x64 version.
However, the system complained on named -u named (no such user). After had to add a user named in order to get
the version 9.16.22 running. It look like something around the named setting has been changed.

I am running a 14.2 (x32 & x64) slackware versions with a lot of updates, openssl-1.1.1k, samba 4.10.18, sendmail 8.16.0.41 (with outgoing DANE), some utilities are recompiled due to openssl 1.1.1, the compiler is updated to 9.2.0, the kernel 5.14.9.

I have kept 14.2 because it is a real multi-user including GRAPHICS (KDE), and I cannot do things without
such a feature.

But it works stable and it keeps the bad, bad world out.

Regards,

Talo