Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 19 Aug 2021 09:31:15 +0000
From:      bugzilla-noreply@freebsd.org
To:        ports-bugs@FreeBSD.org
Subject:   [Bug 257939] databases/mariadb105-server: wsrep_sst_mariabackup broken since 10.5.11
Message-ID:  <bug-257939-7788@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D257939

            Bug ID: 257939
           Summary: databases/mariadb105-server: wsrep_sst_mariabackup
                    broken since 10.5.11
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: brnrd@freebsd.org
          Reporter: ltning-freebsd@anduin.net
          Assignee: brnrd@freebsd.org
             Flags: maintainer-feedback?(brnrd@freebsd.org)

We are using MariaDB in a Galera Cluster setup, and the 10.5.10 to=20
10.5.11 upgrade brought huge changes to the wsrep_sst_common and=20
wsrep_sst_mariabackup scripts. These changes make them entirely=20
FreeBSD-incompatible. The most important changes (to us) are
  - reliance on --tmpdir option to mktemp
  - is_local_ip always returns true in a jail

The former makes the SST script fail because of invalid option.=20
This is easily (and probably compatible with Linux) fixed by removing=20
the --tmpdir option and rather prefixing mktemp with 'TMPDIR=3D$tmpdir ;'=20
inside the same $() around line 935 of wsrep_sst_mariabackup:
   < xtmpdir=3D$(mktemp '-d' --tmpdir "$tmpdir")
   > xtmpdir=3D$(TMPDIR=3D"$tmpdir" ; mktemp '-d')

The latter I had to hack by removing the commonname option passed to=20
socat on line 387 of the same file:
   < CN_option=3D'localhost'
   > CN_option=3D''

This is obviously not a fix, as I don't fully understand what's going on=20
- but I did not have more time to spend on this as our cluster was down :(

Anything you can do to help bring attention to this from upstream? It's=20
really broken that they're making linux-ism assumptions all over the=20
place.. And the change set between these two releases seems pretty big=20
in these scripts.

Alternatively, patches need to be put in place in the port itself, though I
imagine this is a less desirable option long-term.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-257939-7788>