Folks, please save me from this nightmare!
My main backup server has been running fine for years but it was
upgraded a while back to ubuntu mantic. Earlier in the year I discovered
that the update from mantic to ubuntu noble completely failed, rendering
the system (helva) inoperable, and I reverted using the btrfs snapshot.
Since then I have been trying to migrate services off the server onto
other systems so I can at some point refresh the OS from scratch. The
bareos tape hardware is however on this system and very hard to move
elsewhere.
As part of the helva migration the bareos director was moved to a new VM
running ubuntu noble (greyarea-bareos), and I initially set it up with a
self-compiled build of bareos, built on helva ubuntu/mantic, which
installed on both systems and seemed to work fine. However the
ubuntu/noble director refused to talk to the mantic storage daemon,
complaining of some version issue.
helva-sd (100): lib/bsock.cc:85-0 Construct BareosSocket
helva-sd (200): lib/bsock.cc:737-0 Identified from Bareos handshake:
greyarea-bareos-dir-R_DIRECTOR version not recognized
helva-sd (200): lib/try_tls_handshake_as_a_server.cc:61-0 TlsPolicy
for greyarea-bareos-dir is 1
helva-sd (200): lib/try_tls_handshake_as_a_server.cc:75-0 Connection
to greyarea-bareos-dir will be denied due to configuration mismatch
helva-sd (100): lib/bsock.cc:137-0 Destruct BareosSocket
I then updated both bareos director and storage to the current community
build (24.0), but that failed on helva because it needs python3.10 which
mantic doesn't include (it uses 3.11) and isn't available on the
deadsnakes/jammy ppa either (and I had essentially all of bareos installed).
To work around that, I have apt purged all the mantic system's bareos
packages and then reinstalled just the basic storage and file packages
(esp: not python). This enables me to install the (exact same) community
version of bareos 24 built for jammy -- great. Having reset the config
for storage (using Ansible) I can use bconsole on helva to talk to the
director on greyarea-bareos. However, I still get this error if I use
said console session to ask the director for the status of the storage
daemon (that is run bconsole on helva & ask director (greyarea-bareos)
to talk to storage on helva):
16-Dec 16:32 greyarea-bareos-dir JobId 0: Fatal error: Network error
during CRAM MD5 with 2a02:8010:6182:4100::
16-Dec 16:32 greyarea-bareos-dir JobId 0: Fatal error: Director
unable to authenticate with Storage daemon at
"helva.cam.ivimey.org:9103". Possible causes:
Passwords or names not the same or
TLS negotiation problem or
Maximum Concurrent Jobs exceeded on the SD or
SD networking messed up (restart daemon).
Initial thought would be that I'm using the wrong password (because
"MD5"), but I'm sure that's not it :- In
bareos-sd.d/director/bareos-dir.conf I have the name of the bareos
director (eg "bareos-dir") and the password showin in the director's
bareos-dir.d/storage/LTODrive.conf (Storage resource). Is there another
password setting that could cause this issue?
I also notice, however, that the IP6 address on the network error line
is incorrect: this is the address of my IP6 gateway, not that of
greyarea-bareos or helva. I am positive that DNS is working properly on
both hosts, and the name on the 'unable to auth' line is the correct
one, so I have no idea why the wrong address is shown.
I have also explicitly set TLSEnable:yes and TLSRequire:no for most/all?
links (so that a TLS error wouldn't result in a total fail?), and this
is the only job!
I am somewhat at a loss as to how to proceed now... any thoughts?
Ruth
--
You received this message because you are subscribed to the Google Groups
"bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/bareos-users/4a9cd275-f5fb-4f76-8fac-eaebbc317a44%40gmail.com.
