Re: Salt master on -stable and communication with minions on -current 3006.7 version
I simply built the package on 7.4. Am 7. März 2024 09:10:59 MEZ schrieb Mikolaj Kucharski : >Hi, > >I saw this thread progressed. I didn't had a time to test the diff. >However, I see positive feedback about the fix. I don't run -current >on my -stable Salt master. Would it be possible to backport Salt >version 3006.7 with the fix to OpenBSD -stable? > > >On Tue, Mar 05, 2024 at 03:29:55PM +, Mikolaj Kucharski wrote: >> Hi Robert. >> >> I've notived this problem on my Debian Bookworm machines, which recently >> got upgraded to 3006.7 and now I also see this on my OpenBSD -current, >> which also started to run 3006.7 minions. I have Salt master running >> on OpenBSD -stable with salt-3006.3 and minions after upgrade to 3006.7 >> lost communication to the master: >> >> openbsd-current-minion# tail -n10 /var/log/salt/minion >> The master public key can be found at: >> /etc/salt/pki/minion/minion_master.pub >> 2024-03-05 15:13:22,252 [salt.minion:1157][ERROR ][44088] Error while >> bringing up minion for multi-master. Is master at fde4:f456:48c2:13c0::1 >> responding? The error message was Unable to sign_in to master: Invalid >> master key >> 2024-03-05 15:13:32,719 [salt.crypt:1188][ERROR ][44088] The master key >> has changed, the salt master could have been subverted, verify salt master's >> public key >> 2024-03-05 15:13:32,721 [salt.crypt:803 ][CRITICAL][44088] The Salt Master >> server's public key did not authenticate! >> The master may need to be updated if it is a version of Salt lower than >> 3006.7, or >> If you are confident that you are connecting to a valid Salt Master, then >> remove the master public key and restart the Salt Minion. >> The master public key can be found at: >> /etc/salt/pki/minion/minion_master.pub >> 2024-03-05 15:13:32,727 [salt.minion:1157][ERROR ][44088] Error while >> bringing up minion for multi-master. Is master at fde4:f456:48c2:13c0::1 >> responding? The error message was Unable to sign_in to master: Invalid >> master key >> >> I didn't check does upgrade to 3006.7 on master help. I don't want >> to touch my -stable machines. I could setup Salt master on -current >> and test, but all this problem started on Debian and OpenBSD after >> minion upgrade to 3006.7. I do follow -stable packages and syspatch >> on my 7.4-stable machines, but giving upgrade on Debian and OpenBSD, >> I suspect compatibility issue on Salt side. >> >> openbsd-salt-master# sysctl -n kern.version >> OpenBSD 7.4 (GENERIC.MP) #3: Wed Feb 28 06:23:33 MST 2024 >> >> r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP >> >> >> openbsd-salt-master# ls -lhtnr /var/db/pkg/ | tail >> drwxr-xr-x 2 0 0 512B Jan 17 23:23 brotli-1.0.9p0 >> drwxr-xr-x 2 0 0 512B Jan 17 23:23 taskd-1.1.0p5 >> drwxr-xr-x 2 0 0 512B Feb 7 02:50 ngtcp2-0.19.1 >> drwxr-xr-x 2 0 0 512B Feb 7 02:50 nghttp3-0.15.0 >> drwxr-xr-x 2 0 0 512B Feb 7 02:50 nghttp2-1.57.0 >> drwxr-xr-x 2 0 0 512B Feb 7 02:50 git-2.42.0 >> drwxr-xr-x 2 0 0 512B Feb 7 02:50 curl-8.6.0 >> drwxr-xr-x 2 0 0 512B Feb 14 00:47 libunbound-1.19.1 >> drwxr-xr-x 2 0 0 512B Feb 14 00:47 gnutls-3.8.3 >> drwxr-xr-x 2 0 0 512B Feb 24 17:56 quirks-6.160 >> >> >> openbsd-current-minion# sysctl -n kern.version >> OpenBSD 7.5 (GENERIC.MP) #53: Sun Mar 3 22:36:54 MST 2024 >> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP >> >> >> Are you aware of this problem? Ports mailing list, did you notice this, >> by any chance? >> > >-- >Regards, > Mikolaj > -- Mit freundlichen Grüssen / Með bestu kveðju / With kind regards Uwe Werler
Re: Salt master on -stable and communication with minions on -current 3006.7 version
Hi, I saw this thread progressed. I didn't had a time to test the diff. However, I see positive feedback about the fix. I don't run -current on my -stable Salt master. Would it be possible to backport Salt version 3006.7 with the fix to OpenBSD -stable? On Tue, Mar 05, 2024 at 03:29:55PM +, Mikolaj Kucharski wrote: > Hi Robert. > > I've notived this problem on my Debian Bookworm machines, which recently > got upgraded to 3006.7 and now I also see this on my OpenBSD -current, > which also started to run 3006.7 minions. I have Salt master running > on OpenBSD -stable with salt-3006.3 and minions after upgrade to 3006.7 > lost communication to the master: > > openbsd-current-minion# tail -n10 /var/log/salt/minion > The master public key can be found at: > /etc/salt/pki/minion/minion_master.pub > 2024-03-05 15:13:22,252 [salt.minion:1157][ERROR ][44088] Error while > bringing up minion for multi-master. Is master at fde4:f456:48c2:13c0::1 > responding? The error message was Unable to sign_in to master: Invalid master > key > 2024-03-05 15:13:32,719 [salt.crypt:1188][ERROR ][44088] The master key has > changed, the salt master could have been subverted, verify salt master's > public key > 2024-03-05 15:13:32,721 [salt.crypt:803 ][CRITICAL][44088] The Salt Master > server's public key did not authenticate! > The master may need to be updated if it is a version of Salt lower than > 3006.7, or > If you are confident that you are connecting to a valid Salt Master, then > remove the master public key and restart the Salt Minion. > The master public key can be found at: > /etc/salt/pki/minion/minion_master.pub > 2024-03-05 15:13:32,727 [salt.minion:1157][ERROR ][44088] Error while > bringing up minion for multi-master. Is master at fde4:f456:48c2:13c0::1 > responding? The error message was Unable to sign_in to master: Invalid master > key > > I didn't check does upgrade to 3006.7 on master help. I don't want > to touch my -stable machines. I could setup Salt master on -current > and test, but all this problem started on Debian and OpenBSD after > minion upgrade to 3006.7. I do follow -stable packages and syspatch > on my 7.4-stable machines, but giving upgrade on Debian and OpenBSD, > I suspect compatibility issue on Salt side. > > openbsd-salt-master# sysctl -n kern.version > OpenBSD 7.4 (GENERIC.MP) #3: Wed Feb 28 06:23:33 MST 2024 > > r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > openbsd-salt-master# ls -lhtnr /var/db/pkg/ | tail > drwxr-xr-x 2 0 0 512B Jan 17 23:23 brotli-1.0.9p0 > drwxr-xr-x 2 0 0 512B Jan 17 23:23 taskd-1.1.0p5 > drwxr-xr-x 2 0 0 512B Feb 7 02:50 ngtcp2-0.19.1 > drwxr-xr-x 2 0 0 512B Feb 7 02:50 nghttp3-0.15.0 > drwxr-xr-x 2 0 0 512B Feb 7 02:50 nghttp2-1.57.0 > drwxr-xr-x 2 0 0 512B Feb 7 02:50 git-2.42.0 > drwxr-xr-x 2 0 0 512B Feb 7 02:50 curl-8.6.0 > drwxr-xr-x 2 0 0 512B Feb 14 00:47 libunbound-1.19.1 > drwxr-xr-x 2 0 0 512B Feb 14 00:47 gnutls-3.8.3 > drwxr-xr-x 2 0 0 512B Feb 24 17:56 quirks-6.160 > > > openbsd-current-minion# sysctl -n kern.version > OpenBSD 7.5 (GENERIC.MP) #53: Sun Mar 3 22:36:54 MST 2024 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > Are you aware of this problem? Ports mailing list, did you notice this, > by any chance? > -- Regards, Mikolaj
Re: Salt master on -stable and communication with minions on -current 3006.7 version
add: I have now connected minions (Alpine/Linux and OpenBSD 7.4 and current)
with version 3006.3, 3006.6 and 3006.7
to master with 3006.7.
On 06 Mar 15:11, Uwe Werler wrote:
> Hi Robert,
>
> I reinstalled salt_master with Your patch and it solves the issue.
> Reinstalled salt 3006.3 from 7.4 on some hosts and reconnected to the
> master without any issues.
>
> Thanks!
>
> Best regards
>
> Uwe
>
> On 06 Mar 08:56, Robert Nagy wrote:
> > On 06/03/24 08:43 +0100, Robert Nagy wrote:
> > > I think we can backport this until there is a new release out.
> >
> > Please try the following diff:
> >
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/sysutils/salt/Makefile,v
> > diff -u -p -u -r1.183 Makefile
> > --- Makefile1 Mar 2024 12:02:55 - 1.183
> > +++ Makefile6 Mar 2024 07:56:07 -
> > @@ -18,6 +18,8 @@ COMMENT = remote execution and configur
> > MODPY_EGG_VERSION =3006.7
> > DISTNAME = salt-${MODPY_EGG_VERSION}
> >
> > +REVISION = 0
> > +
> > CATEGORIES = sysutils net devel
> >
> > HOMEPAGE = https://saltproject.io/
> > Index: patches/patch-salt_channel_server_py
> > ===
> > RCS file: patches/patch-salt_channel_server_py
> > diff -N patches/patch-salt_channel_server_py
> > --- /dev/null 1 Jan 1970 00:00:00 -
> > +++ patches/patch-salt_channel_server_py6 Mar 2024 07:56:07 -
> > @@ -0,0 +1,52 @@
> > +52d98866200384dbaf3dbdecf66de00ff6d2195c fix: Older keys end with a
> > newline, this breaks minion auth.
> > +4e72e2f0a57b594c3f7e14cc385a066097a268b2 fix: typo's
> > +0f4c022fdaabb41962e7fde1baca7bf73122f534 Simply check against cleaned key
> > from disk.
> > +ecc39aa994c55b22c10320380abf6bd24529496d Refactor and add some tests
> > +
> > +Index: salt/channel/server.py
> > +--- salt/channel/server.py.orig
> > salt/channel/server.py
> > +@@ -52,6 +52,16 @@ class ReqServerChannel:
> > + transport = salt.transport.request_server(opts, **kwargs)
> > + return cls(opts, transport)
> > +
> > ++@classmethod
> > ++def compare_keys(cls, key1, key2):
> > ++"""
> > ++Normalize and compare two keys
> > ++
> > ++Returns:
> > ++bool: ``True`` if the keys match, otherwise ``False``
> > ++"""
> > ++return salt.crypt.clean_key(key1) == salt.crypt.clean_key(key2)
> > ++
> > + def __init__(self, opts, transport):
> > + self.opts = opts
> > + self.transport = transport
> > +@@ -371,7 +381,7 @@ class ReqServerChannel:
> > + elif os.path.isfile(pubfn):
> > + # The key has been accepted, check it
> > + with salt.utils.files.fopen(pubfn, "r") as pubfn_handle:
> > +-if salt.crypt.clean_key(pubfn_handle.read()) !=
> > load["pub"]:
> > ++if not self.compare_keys(pubfn_handle.read(),
> > load["pub"]):
> > + log.error(
> > + "Authentication attempt from %s failed, the
> > public "
> > + "keys did not match. This may be an attempt to
> > compromise "
> > +@@ -480,7 +490,7 @@ class ReqServerChannel:
> > + # case. Otherwise log the fact that the minion is still
> > + # pending.
> > + with salt.utils.files.fopen(pubfn_pend, "r") as
> > pubfn_handle:
> > +-if salt.crypt.clean_key(pubfn_handle.read()) !=
> > load["pub"]:
> > ++if not self.compare_keys(pubfn_handle.read(),
> > load["pub"]):
> > + log.error(
> > + "Authentication attempt from %s failed, the
> > public "
> > + "key in pending did not match. This may be an
> > "
> > +@@ -536,7 +546,7 @@ class ReqServerChannel:
> > + # so, pass on doing anything here, and let it get
> > automatically
> > + # accepted below.
> > + with salt.utils.files.fopen(pubfn_pend, "r") as
> > pubfn_handle:
> > +-if salt.crypt.clean_key(pubfn_handle.read()) !=
> > load["pub"]:
> > ++if not self.compare_keys(pubfn_handle.read(),
> > load["pub"]):
> > + log.error(
> > + "Authentication attempt from %s failed, the
> > public "
> > + "keys in pending did not match. This may be
> > an "
> > Index: patches/patch-salt_grains_core_py
> > ===
> > RCS file: /cvs/ports/sysutils/salt/patches/patch-salt_grains_core_py,v
> > diff -u -p -u -r1.12 patch-salt_grains_core_py
> > --- patches/patch-salt_grains_core_py 28 Apr 2023 18:30:40 -
> > 1.12
> > +++ patches/patch-salt_grains_core_py 6 Mar 2024 07:56:07 -
> > @@ -24,7
Re: Salt master on -stable and communication with minions on -current 3006.7 version
Hi Robert,
I reinstalled salt_master with Your patch and it solves the issue.
Reinstalled salt 3006.3 from 7.4 on some hosts and reconnected to the
master without any issues.
Thanks!
Best regards
Uwe
On 06 Mar 08:56, Robert Nagy wrote:
> On 06/03/24 08:43 +0100, Robert Nagy wrote:
> > I think we can backport this until there is a new release out.
>
> Please try the following diff:
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/sysutils/salt/Makefile,v
> diff -u -p -u -r1.183 Makefile
> --- Makefile 1 Mar 2024 12:02:55 - 1.183
> +++ Makefile 6 Mar 2024 07:56:07 -
> @@ -18,6 +18,8 @@ COMMENT = remote execution and configur
> MODPY_EGG_VERSION = 3006.7
> DISTNAME = salt-${MODPY_EGG_VERSION}
>
> +REVISION = 0
> +
> CATEGORIES = sysutils net devel
>
> HOMEPAGE = https://saltproject.io/
> Index: patches/patch-salt_channel_server_py
> ===
> RCS file: patches/patch-salt_channel_server_py
> diff -N patches/patch-salt_channel_server_py
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-salt_channel_server_py 6 Mar 2024 07:56:07 -
> @@ -0,0 +1,52 @@
> +52d98866200384dbaf3dbdecf66de00ff6d2195c fix: Older keys end with a newline,
> this breaks minion auth.
> +4e72e2f0a57b594c3f7e14cc385a066097a268b2 fix: typo's
> +0f4c022fdaabb41962e7fde1baca7bf73122f534 Simply check against cleaned key
> from disk.
> +ecc39aa994c55b22c10320380abf6bd24529496d Refactor and add some tests
> +
> +Index: salt/channel/server.py
> +--- salt/channel/server.py.orig
> salt/channel/server.py
> +@@ -52,6 +52,16 @@ class ReqServerChannel:
> + transport = salt.transport.request_server(opts, **kwargs)
> + return cls(opts, transport)
> +
> ++@classmethod
> ++def compare_keys(cls, key1, key2):
> ++"""
> ++Normalize and compare two keys
> ++
> ++Returns:
> ++bool: ``True`` if the keys match, otherwise ``False``
> ++"""
> ++return salt.crypt.clean_key(key1) == salt.crypt.clean_key(key2)
> ++
> + def __init__(self, opts, transport):
> + self.opts = opts
> + self.transport = transport
> +@@ -371,7 +381,7 @@ class ReqServerChannel:
> + elif os.path.isfile(pubfn):
> + # The key has been accepted, check it
> + with salt.utils.files.fopen(pubfn, "r") as pubfn_handle:
> +-if salt.crypt.clean_key(pubfn_handle.read()) != load["pub"]:
> ++if not self.compare_keys(pubfn_handle.read(), load["pub"]):
> + log.error(
> + "Authentication attempt from %s failed, the public "
> + "keys did not match. This may be an attempt to
> compromise "
> +@@ -480,7 +490,7 @@ class ReqServerChannel:
> + # case. Otherwise log the fact that the minion is still
> + # pending.
> + with salt.utils.files.fopen(pubfn_pend, "r") as
> pubfn_handle:
> +-if salt.crypt.clean_key(pubfn_handle.read()) !=
> load["pub"]:
> ++if not self.compare_keys(pubfn_handle.read(),
> load["pub"]):
> + log.error(
> + "Authentication attempt from %s failed, the
> public "
> + "key in pending did not match. This may be an "
> +@@ -536,7 +546,7 @@ class ReqServerChannel:
> + # so, pass on doing anything here, and let it get
> automatically
> + # accepted below.
> + with salt.utils.files.fopen(pubfn_pend, "r") as
> pubfn_handle:
> +-if salt.crypt.clean_key(pubfn_handle.read()) !=
> load["pub"]:
> ++if not self.compare_keys(pubfn_handle.read(),
> load["pub"]):
> + log.error(
> + "Authentication attempt from %s failed, the
> public "
> + "keys in pending did not match. This may be an "
> Index: patches/patch-salt_grains_core_py
> ===
> RCS file: /cvs/ports/sysutils/salt/patches/patch-salt_grains_core_py,v
> diff -u -p -u -r1.12 patch-salt_grains_core_py
> --- patches/patch-salt_grains_core_py 28 Apr 2023 18:30:40 - 1.12
> +++ patches/patch-salt_grains_core_py 6 Mar 2024 07:56:07 -
> @@ -24,7 +24,7 @@ Index: salt/grains/core.py
> return grains
>
>
> -@@ -2652,10 +2654,12 @@ def os_data():
> +@@ -2744,10 +2746,12 @@ def os_data():
> # derive osrelease from kernelversion prior to that
> grains["osrelease"] = grains["kernelrelease"].split("-")[0]
> grains.update(_bsd_cpudata(grains))
--
wq: ~uw
Re: Salt master on -stable and communication with minions on -current 3006.7 version
Sorry for the confusion.
I mixed the patch with an old one which tried to patch this file... My
fault.
On 06 Mar 10:26, Robert Nagy wrote:
> On 06/03/24 10:44 +0100, Uwe Werler wrote:
> > Salü Robert,
> >
> > it seems that patches/patch-salt_utils_network_py is already in the attic...
> >
> > Best regards
> >
> > Uwe
>
> Why whould we need that patch? I am confused.
>
> > On 06 Mar 08:56, Robert Nagy wrote:
> > > On 06/03/24 08:43 +0100, Robert Nagy wrote:
> > > > I think we can backport this until there is a new release out.
> > >
> > > Please try the following diff:
> > >
> > > Index: Makefile
> > > ===
> > > RCS file: /cvs/ports/sysutils/salt/Makefile,v
> > > diff -u -p -u -r1.183 Makefile
> > > --- Makefile 1 Mar 2024 12:02:55 - 1.183
> > > +++ Makefile 6 Mar 2024 07:56:07 -
> > > @@ -18,6 +18,8 @@ COMMENT = remote execution and configur
> > > MODPY_EGG_VERSION = 3006.7
> > > DISTNAME = salt-${MODPY_EGG_VERSION}
> > >
> > > +REVISION = 0
> > > +
> > > CATEGORIES = sysutils net devel
> > >
> > > HOMEPAGE = https://saltproject.io/
> > > Index: patches/patch-salt_channel_server_py
> > > ===
> > > RCS file: patches/patch-salt_channel_server_py
> > > diff -N patches/patch-salt_channel_server_py
> > > --- /dev/null 1 Jan 1970 00:00:00 -
> > > +++ patches/patch-salt_channel_server_py 6 Mar 2024 07:56:07 -
> > > @@ -0,0 +1,52 @@
> > > +52d98866200384dbaf3dbdecf66de00ff6d2195c fix: Older keys end with a
> > > newline, this breaks minion auth.
> > > +4e72e2f0a57b594c3f7e14cc385a066097a268b2 fix: typo's
> > > +0f4c022fdaabb41962e7fde1baca7bf73122f534 Simply check against cleaned
> > > key from disk.
> > > +ecc39aa994c55b22c10320380abf6bd24529496d Refactor and add some tests
> > > +
> > > +Index: salt/channel/server.py
> > > +--- salt/channel/server.py.orig
> > > salt/channel/server.py
> > > +@@ -52,6 +52,16 @@ class ReqServerChannel:
> > > + transport = salt.transport.request_server(opts, **kwargs)
> > > + return cls(opts, transport)
> > > +
> > > ++@classmethod
> > > ++def compare_keys(cls, key1, key2):
> > > ++"""
> > > ++Normalize and compare two keys
> > > ++
> > > ++Returns:
> > > ++bool: ``True`` if the keys match, otherwise ``False``
> > > ++"""
> > > ++return salt.crypt.clean_key(key1) == salt.crypt.clean_key(key2)
> > > ++
> > > + def __init__(self, opts, transport):
> > > + self.opts = opts
> > > + self.transport = transport
> > > +@@ -371,7 +381,7 @@ class ReqServerChannel:
> > > + elif os.path.isfile(pubfn):
> > > + # The key has been accepted, check it
> > > + with salt.utils.files.fopen(pubfn, "r") as pubfn_handle:
> > > +-if salt.crypt.clean_key(pubfn_handle.read()) !=
> > > load["pub"]:
> > > ++if not self.compare_keys(pubfn_handle.read(),
> > > load["pub"]):
> > > + log.error(
> > > + "Authentication attempt from %s failed, the
> > > public "
> > > + "keys did not match. This may be an attempt to
> > > compromise "
> > > +@@ -480,7 +490,7 @@ class ReqServerChannel:
> > > + # case. Otherwise log the fact that the minion is still
> > > + # pending.
> > > + with salt.utils.files.fopen(pubfn_pend, "r") as
> > > pubfn_handle:
> > > +-if salt.crypt.clean_key(pubfn_handle.read()) !=
> > > load["pub"]:
> > > ++if not self.compare_keys(pubfn_handle.read(),
> > > load["pub"]):
> > > + log.error(
> > > + "Authentication attempt from %s failed, the
> > > public "
> > > + "key in pending did not match. This may be
> > > an "
> > > +@@ -536,7 +546,7 @@ class ReqServerChannel:
> > > + # so, pass on doing anything here, and let it get
> > > automatically
> > > + # accepted below.
> > > + with salt.utils.files.fopen(pubfn_pend, "r") as
> > > pubfn_handle:
> > > +-if salt.crypt.clean_key(pubfn_handle.read()) !=
> > > load["pub"]:
> > > ++if not self.compare_keys(pubfn_handle.read(),
> > > load["pub"]):
> > > + log.error(
> > > + "Authentication attempt from %s failed, the
> > > public "
> > > + "keys in pending did not match. This may be
> > > an "
> > > Index: patches/patch-salt_grains_core_py
> > > ===
> > > RCS file: /cvs/ports/sysutils/salt/patches/patch-salt_grains_core_py,v
> > > diff -u -p -u -r1.12
Re: Salt master on -stable and communication with minions on -current 3006.7 version
On 06/03/24 10:44 +0100, Uwe Werler wrote:
> Salü Robert,
>
> it seems that patches/patch-salt_utils_network_py is already in the attic...
>
> Best regards
>
> Uwe
Why whould we need that patch? I am confused.
> On 06 Mar 08:56, Robert Nagy wrote:
> > On 06/03/24 08:43 +0100, Robert Nagy wrote:
> > > I think we can backport this until there is a new release out.
> >
> > Please try the following diff:
> >
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/sysutils/salt/Makefile,v
> > diff -u -p -u -r1.183 Makefile
> > --- Makefile1 Mar 2024 12:02:55 - 1.183
> > +++ Makefile6 Mar 2024 07:56:07 -
> > @@ -18,6 +18,8 @@ COMMENT = remote execution and configur
> > MODPY_EGG_VERSION =3006.7
> > DISTNAME = salt-${MODPY_EGG_VERSION}
> >
> > +REVISION = 0
> > +
> > CATEGORIES = sysutils net devel
> >
> > HOMEPAGE = https://saltproject.io/
> > Index: patches/patch-salt_channel_server_py
> > ===
> > RCS file: patches/patch-salt_channel_server_py
> > diff -N patches/patch-salt_channel_server_py
> > --- /dev/null 1 Jan 1970 00:00:00 -
> > +++ patches/patch-salt_channel_server_py6 Mar 2024 07:56:07 -
> > @@ -0,0 +1,52 @@
> > +52d98866200384dbaf3dbdecf66de00ff6d2195c fix: Older keys end with a
> > newline, this breaks minion auth.
> > +4e72e2f0a57b594c3f7e14cc385a066097a268b2 fix: typo's
> > +0f4c022fdaabb41962e7fde1baca7bf73122f534 Simply check against cleaned key
> > from disk.
> > +ecc39aa994c55b22c10320380abf6bd24529496d Refactor and add some tests
> > +
> > +Index: salt/channel/server.py
> > +--- salt/channel/server.py.orig
> > salt/channel/server.py
> > +@@ -52,6 +52,16 @@ class ReqServerChannel:
> > + transport = salt.transport.request_server(opts, **kwargs)
> > + return cls(opts, transport)
> > +
> > ++@classmethod
> > ++def compare_keys(cls, key1, key2):
> > ++"""
> > ++Normalize and compare two keys
> > ++
> > ++Returns:
> > ++bool: ``True`` if the keys match, otherwise ``False``
> > ++"""
> > ++return salt.crypt.clean_key(key1) == salt.crypt.clean_key(key2)
> > ++
> > + def __init__(self, opts, transport):
> > + self.opts = opts
> > + self.transport = transport
> > +@@ -371,7 +381,7 @@ class ReqServerChannel:
> > + elif os.path.isfile(pubfn):
> > + # The key has been accepted, check it
> > + with salt.utils.files.fopen(pubfn, "r") as pubfn_handle:
> > +-if salt.crypt.clean_key(pubfn_handle.read()) !=
> > load["pub"]:
> > ++if not self.compare_keys(pubfn_handle.read(),
> > load["pub"]):
> > + log.error(
> > + "Authentication attempt from %s failed, the
> > public "
> > + "keys did not match. This may be an attempt to
> > compromise "
> > +@@ -480,7 +490,7 @@ class ReqServerChannel:
> > + # case. Otherwise log the fact that the minion is still
> > + # pending.
> > + with salt.utils.files.fopen(pubfn_pend, "r") as
> > pubfn_handle:
> > +-if salt.crypt.clean_key(pubfn_handle.read()) !=
> > load["pub"]:
> > ++if not self.compare_keys(pubfn_handle.read(),
> > load["pub"]):
> > + log.error(
> > + "Authentication attempt from %s failed, the
> > public "
> > + "key in pending did not match. This may be an
> > "
> > +@@ -536,7 +546,7 @@ class ReqServerChannel:
> > + # so, pass on doing anything here, and let it get
> > automatically
> > + # accepted below.
> > + with salt.utils.files.fopen(pubfn_pend, "r") as
> > pubfn_handle:
> > +-if salt.crypt.clean_key(pubfn_handle.read()) !=
> > load["pub"]:
> > ++if not self.compare_keys(pubfn_handle.read(),
> > load["pub"]):
> > + log.error(
> > + "Authentication attempt from %s failed, the
> > public "
> > + "keys in pending did not match. This may be
> > an "
> > Index: patches/patch-salt_grains_core_py
> > ===
> > RCS file: /cvs/ports/sysutils/salt/patches/patch-salt_grains_core_py,v
> > diff -u -p -u -r1.12 patch-salt_grains_core_py
> > --- patches/patch-salt_grains_core_py 28 Apr 2023 18:30:40 -
> > 1.12
> > +++ patches/patch-salt_grains_core_py 6 Mar 2024 07:56:07 -
> > @@ -24,7 +24,7 @@ Index: salt/grains/core.py
> > return grains
> >
> >
> > -@@ -2652,10 +2654,12 @@ def os_data():
> > +@@ -2744,10 +2746,12 @@ def os_data():
> > # derive
Re: Salt master on -stable and communication with minions on -current 3006.7 version
On 2024/03/06 10:44, Uwe Werler wrote: > Salü Robert, > > it seems that patches/patch-salt_utils_network_py is already in the attic... Fortunately CVS allows readding files from the attic.
Re: Salt master on -stable and communication with minions on -current 3006.7 version
Salü Robert,
it seems that patches/patch-salt_utils_network_py is already in the attic...
Best regards
Uwe
On 06 Mar 08:56, Robert Nagy wrote:
> On 06/03/24 08:43 +0100, Robert Nagy wrote:
> > I think we can backport this until there is a new release out.
>
> Please try the following diff:
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/sysutils/salt/Makefile,v
> diff -u -p -u -r1.183 Makefile
> --- Makefile 1 Mar 2024 12:02:55 - 1.183
> +++ Makefile 6 Mar 2024 07:56:07 -
> @@ -18,6 +18,8 @@ COMMENT = remote execution and configur
> MODPY_EGG_VERSION = 3006.7
> DISTNAME = salt-${MODPY_EGG_VERSION}
>
> +REVISION = 0
> +
> CATEGORIES = sysutils net devel
>
> HOMEPAGE = https://saltproject.io/
> Index: patches/patch-salt_channel_server_py
> ===
> RCS file: patches/patch-salt_channel_server_py
> diff -N patches/patch-salt_channel_server_py
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-salt_channel_server_py 6 Mar 2024 07:56:07 -
> @@ -0,0 +1,52 @@
> +52d98866200384dbaf3dbdecf66de00ff6d2195c fix: Older keys end with a newline,
> this breaks minion auth.
> +4e72e2f0a57b594c3f7e14cc385a066097a268b2 fix: typo's
> +0f4c022fdaabb41962e7fde1baca7bf73122f534 Simply check against cleaned key
> from disk.
> +ecc39aa994c55b22c10320380abf6bd24529496d Refactor and add some tests
> +
> +Index: salt/channel/server.py
> +--- salt/channel/server.py.orig
> salt/channel/server.py
> +@@ -52,6 +52,16 @@ class ReqServerChannel:
> + transport = salt.transport.request_server(opts, **kwargs)
> + return cls(opts, transport)
> +
> ++@classmethod
> ++def compare_keys(cls, key1, key2):
> ++"""
> ++Normalize and compare two keys
> ++
> ++Returns:
> ++bool: ``True`` if the keys match, otherwise ``False``
> ++"""
> ++return salt.crypt.clean_key(key1) == salt.crypt.clean_key(key2)
> ++
> + def __init__(self, opts, transport):
> + self.opts = opts
> + self.transport = transport
> +@@ -371,7 +381,7 @@ class ReqServerChannel:
> + elif os.path.isfile(pubfn):
> + # The key has been accepted, check it
> + with salt.utils.files.fopen(pubfn, "r") as pubfn_handle:
> +-if salt.crypt.clean_key(pubfn_handle.read()) != load["pub"]:
> ++if not self.compare_keys(pubfn_handle.read(), load["pub"]):
> + log.error(
> + "Authentication attempt from %s failed, the public "
> + "keys did not match. This may be an attempt to
> compromise "
> +@@ -480,7 +490,7 @@ class ReqServerChannel:
> + # case. Otherwise log the fact that the minion is still
> + # pending.
> + with salt.utils.files.fopen(pubfn_pend, "r") as
> pubfn_handle:
> +-if salt.crypt.clean_key(pubfn_handle.read()) !=
> load["pub"]:
> ++if not self.compare_keys(pubfn_handle.read(),
> load["pub"]):
> + log.error(
> + "Authentication attempt from %s failed, the
> public "
> + "key in pending did not match. This may be an "
> +@@ -536,7 +546,7 @@ class ReqServerChannel:
> + # so, pass on doing anything here, and let it get
> automatically
> + # accepted below.
> + with salt.utils.files.fopen(pubfn_pend, "r") as
> pubfn_handle:
> +-if salt.crypt.clean_key(pubfn_handle.read()) !=
> load["pub"]:
> ++if not self.compare_keys(pubfn_handle.read(),
> load["pub"]):
> + log.error(
> + "Authentication attempt from %s failed, the
> public "
> + "keys in pending did not match. This may be an "
> Index: patches/patch-salt_grains_core_py
> ===
> RCS file: /cvs/ports/sysutils/salt/patches/patch-salt_grains_core_py,v
> diff -u -p -u -r1.12 patch-salt_grains_core_py
> --- patches/patch-salt_grains_core_py 28 Apr 2023 18:30:40 - 1.12
> +++ patches/patch-salt_grains_core_py 6 Mar 2024 07:56:07 -
> @@ -24,7 +24,7 @@ Index: salt/grains/core.py
> return grains
>
>
> -@@ -2652,10 +2654,12 @@ def os_data():
> +@@ -2744,10 +2746,12 @@ def os_data():
> # derive osrelease from kernelversion prior to that
> grains["osrelease"] = grains["kernelrelease"].split("-")[0]
> grains.update(_bsd_cpudata(grains))
--
wq: ~uw
Re: Salt master on -stable and communication with minions on -current 3006.7 version
On 06/03/24 08:43 +0100, Robert Nagy wrote:
> I think we can backport this until there is a new release out.
Please try the following diff:
Index: Makefile
===
RCS file: /cvs/ports/sysutils/salt/Makefile,v
diff -u -p -u -r1.183 Makefile
--- Makefile1 Mar 2024 12:02:55 - 1.183
+++ Makefile6 Mar 2024 07:56:07 -
@@ -18,6 +18,8 @@ COMMENT = remote execution and configur
MODPY_EGG_VERSION =3006.7
DISTNAME = salt-${MODPY_EGG_VERSION}
+REVISION = 0
+
CATEGORIES = sysutils net devel
HOMEPAGE = https://saltproject.io/
Index: patches/patch-salt_channel_server_py
===
RCS file: patches/patch-salt_channel_server_py
diff -N patches/patch-salt_channel_server_py
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-salt_channel_server_py6 Mar 2024 07:56:07 -
@@ -0,0 +1,52 @@
+52d98866200384dbaf3dbdecf66de00ff6d2195c fix: Older keys end with a newline,
this breaks minion auth.
+4e72e2f0a57b594c3f7e14cc385a066097a268b2 fix: typo's
+0f4c022fdaabb41962e7fde1baca7bf73122f534 Simply check against cleaned key from
disk.
+ecc39aa994c55b22c10320380abf6bd24529496d Refactor and add some tests
+
+Index: salt/channel/server.py
+--- salt/channel/server.py.orig
salt/channel/server.py
+@@ -52,6 +52,16 @@ class ReqServerChannel:
+ transport = salt.transport.request_server(opts, **kwargs)
+ return cls(opts, transport)
+
++@classmethod
++def compare_keys(cls, key1, key2):
++"""
++Normalize and compare two keys
++
++Returns:
++bool: ``True`` if the keys match, otherwise ``False``
++"""
++return salt.crypt.clean_key(key1) == salt.crypt.clean_key(key2)
++
+ def __init__(self, opts, transport):
+ self.opts = opts
+ self.transport = transport
+@@ -371,7 +381,7 @@ class ReqServerChannel:
+ elif os.path.isfile(pubfn):
+ # The key has been accepted, check it
+ with salt.utils.files.fopen(pubfn, "r") as pubfn_handle:
+-if salt.crypt.clean_key(pubfn_handle.read()) != load["pub"]:
++if not self.compare_keys(pubfn_handle.read(), load["pub"]):
+ log.error(
+ "Authentication attempt from %s failed, the public "
+ "keys did not match. This may be an attempt to
compromise "
+@@ -480,7 +490,7 @@ class ReqServerChannel:
+ # case. Otherwise log the fact that the minion is still
+ # pending.
+ with salt.utils.files.fopen(pubfn_pend, "r") as pubfn_handle:
+-if salt.crypt.clean_key(pubfn_handle.read()) !=
load["pub"]:
++if not self.compare_keys(pubfn_handle.read(),
load["pub"]):
+ log.error(
+ "Authentication attempt from %s failed, the
public "
+ "key in pending did not match. This may be an "
+@@ -536,7 +546,7 @@ class ReqServerChannel:
+ # so, pass on doing anything here, and let it get
automatically
+ # accepted below.
+ with salt.utils.files.fopen(pubfn_pend, "r") as pubfn_handle:
+-if salt.crypt.clean_key(pubfn_handle.read()) !=
load["pub"]:
++if not self.compare_keys(pubfn_handle.read(),
load["pub"]):
+ log.error(
+ "Authentication attempt from %s failed, the
public "
+ "keys in pending did not match. This may be an "
Index: patches/patch-salt_grains_core_py
===
RCS file: /cvs/ports/sysutils/salt/patches/patch-salt_grains_core_py,v
diff -u -p -u -r1.12 patch-salt_grains_core_py
--- patches/patch-salt_grains_core_py 28 Apr 2023 18:30:40 - 1.12
+++ patches/patch-salt_grains_core_py 6 Mar 2024 07:56:07 -
@@ -24,7 +24,7 @@ Index: salt/grains/core.py
return grains
-@@ -2652,10 +2654,12 @@ def os_data():
+@@ -2744,10 +2746,12 @@ def os_data():
# derive osrelease from kernelversion prior to that
grains["osrelease"] = grains["kernelrelease"].split("-")[0]
grains.update(_bsd_cpudata(grains))
Re: Salt master on -stable and communication with minions on -current 3006.7 version
I think we can backport this until there is a new release out. On 06/03/24 09:26 +0100, Uwe Werler wrote: > Hi all, > > it seems that it has to do with eol in minion keys: > > https://github.com/saltstack/salt/issues/66126 > There's also a PR: https://github.com/saltstack/salt/pull/66140 > > Best regards > > Uwe > > On 05 Mar 17:24, Uwe Werler wrote: > > Hi Micholaj, > > > > to upgrade minions to a higher version than the master is usually a bad > > idea. > > > > I noticed the same problem. Installed salt at my alpine machines (3006.7) > > and lost connection to the master. But after upgrading my master to 3006.7 > > my OpenBSD minions (3006.5) lost connection too. When I registered the > > minions new the keys were stored under accepted keys and immediately under > > denied keys too. I guess this has something to do with the upgrades in > > cryptography/pyopenssl. I didn't investigate further but upgraded all > > machines to 3006.7. > > > > Best regards > > > > Uwe > > > > Am 5. März 2024 16:29:55 MEZ schrieb Mikolaj Kucharski > > : > > >Hi Robert. > > > > > >I've notived this problem on my Debian Bookworm machines, which recently > > >got upgraded to 3006.7 and now I also see this on my OpenBSD -current, > > >which also started to run 3006.7 minions. I have Salt master running > > >on OpenBSD -stable with salt-3006.3 and minions after upgrade to 3006.7 > > >lost communication to the master: > > > > > >openbsd-current-minion# tail -n10 /var/log/salt/minion > > >The master public key can be found at: > > >/etc/salt/pki/minion/minion_master.pub > > >2024-03-05 15:13:22,252 [salt.minion:1157][ERROR ][44088] Error while > > >bringing up minion for multi-master. Is master at fde4:f456:48c2:13c0::1 > > >responding? The error message was Unable to sign_in to master: Invalid > > >master key > > >2024-03-05 15:13:32,719 [salt.crypt:1188][ERROR ][44088] The master key > > >has changed, the salt master could have been subverted, verify salt > > >master's public key > > >2024-03-05 15:13:32,721 [salt.crypt:803 ][CRITICAL][44088] The Salt Master > > >server's public key did not authenticate! > > >The master may need to be updated if it is a version of Salt lower than > > >3006.7, or > > >If you are confident that you are connecting to a valid Salt Master, then > > >remove the master public key and restart the Salt Minion. > > >The master public key can be found at: > > >/etc/salt/pki/minion/minion_master.pub > > >2024-03-05 15:13:32,727 [salt.minion:1157][ERROR ][44088] Error while > > >bringing up minion for multi-master. Is master at fde4:f456:48c2:13c0::1 > > >responding? The error message was Unable to sign_in to master: Invalid > > >master key > > > > > >I didn't check does upgrade to 3006.7 on master help. I don't want > > >to touch my -stable machines. I could setup Salt master on -current > > >and test, but all this problem started on Debian and OpenBSD after > > >minion upgrade to 3006.7. I do follow -stable packages and syspatch > > >on my 7.4-stable machines, but giving upgrade on Debian and OpenBSD, > > >I suspect compatibility issue on Salt side. > > > > > >openbsd-salt-master# sysctl -n kern.version > > >OpenBSD 7.4 (GENERIC.MP) #3: Wed Feb 28 06:23:33 MST 2024 > > > > > > r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > > > > > >openbsd-salt-master# ls -lhtnr /var/db/pkg/ | tail > > >drwxr-xr-x 2 0 0 512B Jan 17 23:23 brotli-1.0.9p0 > > >drwxr-xr-x 2 0 0 512B Jan 17 23:23 taskd-1.1.0p5 > > >drwxr-xr-x 2 0 0 512B Feb 7 02:50 ngtcp2-0.19.1 > > >drwxr-xr-x 2 0 0 512B Feb 7 02:50 nghttp3-0.15.0 > > >drwxr-xr-x 2 0 0 512B Feb 7 02:50 nghttp2-1.57.0 > > >drwxr-xr-x 2 0 0 512B Feb 7 02:50 git-2.42.0 > > >drwxr-xr-x 2 0 0 512B Feb 7 02:50 curl-8.6.0 > > >drwxr-xr-x 2 0 0 512B Feb 14 00:47 libunbound-1.19.1 > > >drwxr-xr-x 2 0 0 512B Feb 14 00:47 gnutls-3.8.3 > > >drwxr-xr-x 2 0 0 512B Feb 24 17:56 quirks-6.160 > > > > > > > > >openbsd-current-minion# sysctl -n kern.version > > >OpenBSD 7.5 (GENERIC.MP) #53: Sun Mar 3 22:36:54 MST 2024 > > >dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > > > > > >Are you aware of this problem? Ports mailing list, did you notice this, > > >by any chance? > > > > > >-- > > >Regards, > > > Mikolaj > > > > > > > -- > > Mit freundlichen Grüssen / Með bestu kveðju / With kind regards > > > > Uwe Werler > > -- > wq: ~uw -- Regards, Robert Nagy
Re: Salt master on -stable and communication with minions on -current 3006.7 version
Hi all, it seems that it has to do with eol in minion keys: https://github.com/saltstack/salt/issues/66126 There's also a PR: https://github.com/saltstack/salt/pull/66140 Best regards Uwe On 05 Mar 17:24, Uwe Werler wrote: > Hi Micholaj, > > to upgrade minions to a higher version than the master is usually a bad idea. > > I noticed the same problem. Installed salt at my alpine machines (3006.7) and > lost connection to the master. But after upgrading my master to 3006.7 my > OpenBSD minions (3006.5) lost connection too. When I registered the minions > new the keys were stored under accepted keys and immediately under denied > keys too. I guess this has something to do with the upgrades in > cryptography/pyopenssl. I didn't investigate further but upgraded all > machines to 3006.7. > > Best regards > > Uwe > > Am 5. März 2024 16:29:55 MEZ schrieb Mikolaj Kucharski > : > >Hi Robert. > > > >I've notived this problem on my Debian Bookworm machines, which recently > >got upgraded to 3006.7 and now I also see this on my OpenBSD -current, > >which also started to run 3006.7 minions. I have Salt master running > >on OpenBSD -stable with salt-3006.3 and minions after upgrade to 3006.7 > >lost communication to the master: > > > >openbsd-current-minion# tail -n10 /var/log/salt/minion > >The master public key can be found at: > >/etc/salt/pki/minion/minion_master.pub > >2024-03-05 15:13:22,252 [salt.minion:1157][ERROR ][44088] Error while > >bringing up minion for multi-master. Is master at fde4:f456:48c2:13c0::1 > >responding? The error message was Unable to sign_in to master: Invalid > >master key > >2024-03-05 15:13:32,719 [salt.crypt:1188][ERROR ][44088] The master key > >has changed, the salt master could have been subverted, verify salt master's > >public key > >2024-03-05 15:13:32,721 [salt.crypt:803 ][CRITICAL][44088] The Salt Master > >server's public key did not authenticate! > >The master may need to be updated if it is a version of Salt lower than > >3006.7, or > >If you are confident that you are connecting to a valid Salt Master, then > >remove the master public key and restart the Salt Minion. > >The master public key can be found at: > >/etc/salt/pki/minion/minion_master.pub > >2024-03-05 15:13:32,727 [salt.minion:1157][ERROR ][44088] Error while > >bringing up minion for multi-master. Is master at fde4:f456:48c2:13c0::1 > >responding? The error message was Unable to sign_in to master: Invalid > >master key > > > >I didn't check does upgrade to 3006.7 on master help. I don't want > >to touch my -stable machines. I could setup Salt master on -current > >and test, but all this problem started on Debian and OpenBSD after > >minion upgrade to 3006.7. I do follow -stable packages and syspatch > >on my 7.4-stable machines, but giving upgrade on Debian and OpenBSD, > >I suspect compatibility issue on Salt side. > > > >openbsd-salt-master# sysctl -n kern.version > >OpenBSD 7.4 (GENERIC.MP) #3: Wed Feb 28 06:23:33 MST 2024 > > > > r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > > >openbsd-salt-master# ls -lhtnr /var/db/pkg/ | tail > >drwxr-xr-x 2 0 0 512B Jan 17 23:23 brotli-1.0.9p0 > >drwxr-xr-x 2 0 0 512B Jan 17 23:23 taskd-1.1.0p5 > >drwxr-xr-x 2 0 0 512B Feb 7 02:50 ngtcp2-0.19.1 > >drwxr-xr-x 2 0 0 512B Feb 7 02:50 nghttp3-0.15.0 > >drwxr-xr-x 2 0 0 512B Feb 7 02:50 nghttp2-1.57.0 > >drwxr-xr-x 2 0 0 512B Feb 7 02:50 git-2.42.0 > >drwxr-xr-x 2 0 0 512B Feb 7 02:50 curl-8.6.0 > >drwxr-xr-x 2 0 0 512B Feb 14 00:47 libunbound-1.19.1 > >drwxr-xr-x 2 0 0 512B Feb 14 00:47 gnutls-3.8.3 > >drwxr-xr-x 2 0 0 512B Feb 24 17:56 quirks-6.160 > > > > > >openbsd-current-minion# sysctl -n kern.version > >OpenBSD 7.5 (GENERIC.MP) #53: Sun Mar 3 22:36:54 MST 2024 > >dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > > >Are you aware of this problem? Ports mailing list, did you notice this, > >by any chance? > > > >-- > >Regards, > > Mikolaj > > > > -- > Mit freundlichen Grüssen / Með bestu kveðju / With kind regards > > Uwe Werler -- wq: ~uw
Re: Salt master on -stable and communication with minions on -current 3006.7 version
Hi Micholaj, to upgrade minions to a higher version than the master is usually a bad idea. I noticed the same problem. Installed salt at my alpine machines (3006.7) and lost connection to the master. But after upgrading my master to 3006.7 my OpenBSD minions (3006.5) lost connection too. When I registered the minions new the keys were stored under accepted keys and immediately under denied keys too. I guess this has something to do with the upgrades in cryptography/pyopenssl. I didn't investigate further but upgraded all machines to 3006.7. Best regards Uwe Am 5. März 2024 16:29:55 MEZ schrieb Mikolaj Kucharski : >Hi Robert. > >I've notived this problem on my Debian Bookworm machines, which recently >got upgraded to 3006.7 and now I also see this on my OpenBSD -current, >which also started to run 3006.7 minions. I have Salt master running >on OpenBSD -stable with salt-3006.3 and minions after upgrade to 3006.7 >lost communication to the master: > >openbsd-current-minion# tail -n10 /var/log/salt/minion >The master public key can be found at: >/etc/salt/pki/minion/minion_master.pub >2024-03-05 15:13:22,252 [salt.minion:1157][ERROR ][44088] Error while >bringing up minion for multi-master. Is master at fde4:f456:48c2:13c0::1 >responding? The error message was Unable to sign_in to master: Invalid master >key >2024-03-05 15:13:32,719 [salt.crypt:1188][ERROR ][44088] The master key has >changed, the salt master could have been subverted, verify salt master's >public key >2024-03-05 15:13:32,721 [salt.crypt:803 ][CRITICAL][44088] The Salt Master >server's public key did not authenticate! >The master may need to be updated if it is a version of Salt lower than >3006.7, or >If you are confident that you are connecting to a valid Salt Master, then >remove the master public key and restart the Salt Minion. >The master public key can be found at: >/etc/salt/pki/minion/minion_master.pub >2024-03-05 15:13:32,727 [salt.minion:1157][ERROR ][44088] Error while >bringing up minion for multi-master. Is master at fde4:f456:48c2:13c0::1 >responding? The error message was Unable to sign_in to master: Invalid master >key > >I didn't check does upgrade to 3006.7 on master help. I don't want >to touch my -stable machines. I could setup Salt master on -current >and test, but all this problem started on Debian and OpenBSD after >minion upgrade to 3006.7. I do follow -stable packages and syspatch >on my 7.4-stable machines, but giving upgrade on Debian and OpenBSD, >I suspect compatibility issue on Salt side. > >openbsd-salt-master# sysctl -n kern.version >OpenBSD 7.4 (GENERIC.MP) #3: Wed Feb 28 06:23:33 MST 2024 > > r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > >openbsd-salt-master# ls -lhtnr /var/db/pkg/ | tail >drwxr-xr-x 2 0 0 512B Jan 17 23:23 brotli-1.0.9p0 >drwxr-xr-x 2 0 0 512B Jan 17 23:23 taskd-1.1.0p5 >drwxr-xr-x 2 0 0 512B Feb 7 02:50 ngtcp2-0.19.1 >drwxr-xr-x 2 0 0 512B Feb 7 02:50 nghttp3-0.15.0 >drwxr-xr-x 2 0 0 512B Feb 7 02:50 nghttp2-1.57.0 >drwxr-xr-x 2 0 0 512B Feb 7 02:50 git-2.42.0 >drwxr-xr-x 2 0 0 512B Feb 7 02:50 curl-8.6.0 >drwxr-xr-x 2 0 0 512B Feb 14 00:47 libunbound-1.19.1 >drwxr-xr-x 2 0 0 512B Feb 14 00:47 gnutls-3.8.3 >drwxr-xr-x 2 0 0 512B Feb 24 17:56 quirks-6.160 > > >openbsd-current-minion# sysctl -n kern.version >OpenBSD 7.5 (GENERIC.MP) #53: Sun Mar 3 22:36:54 MST 2024 >dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > >Are you aware of this problem? Ports mailing list, did you notice this, >by any chance? > >-- >Regards, > Mikolaj > -- Mit freundlichen Grüssen / Með bestu kveðju / With kind regards Uwe Werler
Salt master on -stable and communication with minions on -current 3006.7 version
Hi Robert. I've notived this problem on my Debian Bookworm machines, which recently got upgraded to 3006.7 and now I also see this on my OpenBSD -current, which also started to run 3006.7 minions. I have Salt master running on OpenBSD -stable with salt-3006.3 and minions after upgrade to 3006.7 lost communication to the master: openbsd-current-minion# tail -n10 /var/log/salt/minion The master public key can be found at: /etc/salt/pki/minion/minion_master.pub 2024-03-05 15:13:22,252 [salt.minion:1157][ERROR ][44088] Error while bringing up minion for multi-master. Is master at fde4:f456:48c2:13c0::1 responding? The error message was Unable to sign_in to master: Invalid master key 2024-03-05 15:13:32,719 [salt.crypt:1188][ERROR ][44088] The master key has changed, the salt master could have been subverted, verify salt master's public key 2024-03-05 15:13:32,721 [salt.crypt:803 ][CRITICAL][44088] The Salt Master server's public key did not authenticate! The master may need to be updated if it is a version of Salt lower than 3006.7, or If you are confident that you are connecting to a valid Salt Master, then remove the master public key and restart the Salt Minion. The master public key can be found at: /etc/salt/pki/minion/minion_master.pub 2024-03-05 15:13:32,727 [salt.minion:1157][ERROR ][44088] Error while bringing up minion for multi-master. Is master at fde4:f456:48c2:13c0::1 responding? The error message was Unable to sign_in to master: Invalid master key I didn't check does upgrade to 3006.7 on master help. I don't want to touch my -stable machines. I could setup Salt master on -current and test, but all this problem started on Debian and OpenBSD after minion upgrade to 3006.7. I do follow -stable packages and syspatch on my 7.4-stable machines, but giving upgrade on Debian and OpenBSD, I suspect compatibility issue on Salt side. openbsd-salt-master# sysctl -n kern.version OpenBSD 7.4 (GENERIC.MP) #3: Wed Feb 28 06:23:33 MST 2024 r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP openbsd-salt-master# ls -lhtnr /var/db/pkg/ | tail drwxr-xr-x 2 0 0 512B Jan 17 23:23 brotli-1.0.9p0 drwxr-xr-x 2 0 0 512B Jan 17 23:23 taskd-1.1.0p5 drwxr-xr-x 2 0 0 512B Feb 7 02:50 ngtcp2-0.19.1 drwxr-xr-x 2 0 0 512B Feb 7 02:50 nghttp3-0.15.0 drwxr-xr-x 2 0 0 512B Feb 7 02:50 nghttp2-1.57.0 drwxr-xr-x 2 0 0 512B Feb 7 02:50 git-2.42.0 drwxr-xr-x 2 0 0 512B Feb 7 02:50 curl-8.6.0 drwxr-xr-x 2 0 0 512B Feb 14 00:47 libunbound-1.19.1 drwxr-xr-x 2 0 0 512B Feb 14 00:47 gnutls-3.8.3 drwxr-xr-x 2 0 0 512B Feb 24 17:56 quirks-6.160 openbsd-current-minion# sysctl -n kern.version OpenBSD 7.5 (GENERIC.MP) #53: Sun Mar 3 22:36:54 MST 2024 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Are you aware of this problem? Ports mailing list, did you notice this, by any chance? -- Regards, Mikolaj
