[Bug 257939] databases/mariadb105-server: wsrep_sst_mariabackup broken since 10.5.11

From: <bugzilla-noreply_at_freebsd.org>
Date: Thu, 19 Aug 2021 09:31:15 +0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257939

            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_at_freebsd.org
          Reporter: ltning-freebsd_at_anduin.net
          Assignee: brnrd_at_freebsd.org
             Flags: maintainer-feedback?(brnrd_at_freebsd.org)

We are using MariaDB in a Galera Cluster setup, and the 10.5.10 to 
10.5.11 upgrade brought huge changes to the wsrep_sst_common and 
wsrep_sst_mariabackup scripts. These changes make them entirely 
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. 
This is easily (and probably compatible with Linux) fixed by removing 
the --tmpdir option and rather prefixing mktemp with 'TMPDIR=$tmpdir ;' 
inside the same $() around line 935 of wsrep_sst_mariabackup:
   < xtmpdir=$(mktemp '-d' --tmpdir "$tmpdir")
   > xtmpdir=$(TMPDIR="$tmpdir" ; mktemp '-d')

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

This is obviously not a fix, as I don't fully understand what's going on 
- 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 
really broken that they're making linux-ism assumptions all over the 
place.. And the change set between these two releases seems pretty big 
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
Received on Thu Aug 19 2021 - 09:31:15 UTC

Original text of this message