Hi! Thanks for coming back! Sadly it's not sorted.
On Wed, 24 Jul 2024, at 12:21 PM, Stephan Sürken wrote: > > hi, thx for the report. > > Just ftr, we just updated the docs for the (always a bit klunky) remote > pairing, which > should make the process more clear: > > http://mini-buildd.installiert.net/extra/mini-buildd/manual/master/administrator.html#remote > > Maybe that helps, but your error might be something else, still. I had a run through the docs - going through the instructions one by one and posting some output" I am running two instances of 2.3.3 on test machines - an arm raspi and a x86VM. This is on my tailnet, and I'm using IPv4 addresses only. Both instances have been started with: PYTHONWARNINGS="default" /usr/sbin/mini-buildd --log-level DEBUG --debug=exception,http,webapp 1) On instance 0 (100.90.178.95), I added instance 1 (100.83.1.23) and prepared. I get confirmed working - in my terminal (and in the browser on the remotes page) I see: I: prepare succeeded: Remote 'http://100.83.1.23:8066' with GnuPGPublicKey 'F68BE6E5BB499EB6' (mini-buildd archive pi4-buildmachine <mini-bui...@rpi4-20240713.tail0fd4.ts.net>) [mini_buildd.models(models.py:414)] 2) On instance 1, i added instance 0, prepared and activated. I see: I: prepare succeeded: Remote 'http://100.90.178.95:8066' with GnuPGPublicKey 'CD5EDDD5E58D2245' (mini-buildd archive debian-wannabuild <mini-buildd@debian-wannabuild>) [mini_buildd.models(models.py:414)] I: activate succeeded: Remote 'http://100.90.178.95:8066' with GnuPGPublicKey 'CD5EDDD5E58D2245' (mini-buildd archive debian-wannabuild <mini-buildd@debian-wannabuild>) [mini_buildd.models(models.py:414)] 3) On instance 0, I run check and it fails: W: check failed: Remote 'http://100.83.1.23:8066' with GnuPGPublicKey 'F68BE6E5BB499EB6' (mini-buildd archive pi4-buildmachine <mini-bui...@rpi4-20240713.tail0fd4.ts.net>): Our instance is not activated on remote (HTTP 400 Bad request syntax or unsupported method) [raised in: models.py:694] [mini_buildd.models(util.py:171)] Traceback (most recent call last): File "/usr/lib/python3/dist-packages/mini_buildd/models.py", line 410, in mbd_action action(o, **kwargs) File "/usr/lib/python3/dist-packages/mini_buildd/models.py", line 332, in mbd_check obj.mbd_check() File "/usr/lib/python3/dist-packages/mini_buildd/models.py", line 694, in mbd_check raise util.HTTPBadRequest("Our instance is not activated on remote") mini_buildd.util.HTTPBadRequest: Our instance is not activated on remote (HTTP 400 Bad request syntax or unsupported method) On the remote end at instance 1, I see: D: Called with returncode 0: gpg --homedir /var/lib/mini-buildd/var/tmp/gnupg-pubkey-gp7gy7sg --display-charset UTF-8 --batch --import [mini_buildd.call(call.py:69)] D: Remote handshake ok: 'Remote 'http://100.90.178.95:8066' with GnuPGPublicKey 'CD5EDDD5E58D2245' (mini-buildd archive debian-wannabuild <mini-buildd@debian-wannabuild>)': CD5EDDD5E58D2245: mini-buildd archive debian-wannabuild <mini-buildd@debian-wannabuild> [mini_buildd.api(api.py:1098)] Similarly, a check on instance 1 at this stage will generate the same errors on instance 0. At this point, in 'Builders', on each instance i can see Ourselves and the Remote, but the Remote is sat at 'Prepared' - I can see the load change. I can't force packages from one to the other on upload by having different architectures on each machine either. I get a 'not for me' response. Is it possible a lack of FQDNs is related here? Do i need to line up hostnames etc? As a test, I threw a third, clean server into the mix: if I add an 'instance 2' into the mix and do the same process between instance 1 & 2 with instance 0 in it's not completely setup state, instance 1 provides me a GPG error about instance 0 on the terminal - I suspect this is a red herring due to something in the chain not having keys and can, for the moment, be discounted: W: Remote handshake failed for 'Remote 'http://100.90.178.95:8066' with GnuPGPublicKey 'CD5EDDD5E58D2245' (mini-buildd archive debian-wannabuild <mini-buildd@debian-wannabuild>)': 'tuple' object has no attribute 'signatures' [raised in: gnupg.py:191] [mini_buildd.api(util.py:171)] Traceback (most recent call last): File "/usr/lib/python3/dist-packages/mini_buildd/gnupg.py", line 189, in gpgme_verify return self.context.verify(signed_message.encode(config.CHAR_ENCODING), signature) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/gpg/core.py", line 558, in verify raise errors.BadSignatures(results[1], results=results) gpg.errors.BadSignatures: 763F9CDBA743467F1DBD7799A869AB277D7CCCA7: No public key During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/mini_buildd/api.py", line 1096, in _run r.mbd_verify(signed_message) File "/usr/lib/python3/dist-packages/mini_buildd/models.py", line 591, in mbd_verify data, _ = _gnupg.gpgme_verify(signed_message) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/mini_buildd/gnupg.py", line 191, in gpgme_verify raise GpgmeVerifyFailed(f"{e}", e.results.signatures if e.results is not None else None) from e ^^^^^^^^^^^^^^^^^^^^ Cheers! -- Hibby Debian Developer Packet Radioist MM0RFN
