This is a combined patch of various spelling fixes originally done in
Debian.
* Fix misc typos in MariaDB Server
* Fix spelling of 'allows one to'
Fix the following Lintian nags introduced in commit
c8d040938a:
I: mariadb-backup: spelling-error-in-binary "allows to" "allows one to" [usr/bin/mariadb-backup]
I: mariadb-server-core: spelling-error-in-binary "allows to" "allows one to" [usr/sbin/mariadbd]
I: mariadb-test: spelling-error-in-binary "allows to" "allows one to" [usr/bin/mariadb-client-test-embedded]
I: mariadb-test: spelling-error-in-binary "allows to" "allows one to" [usr/bin/mariadb-test-embedded]
I: mariadb-test: spelling-error-in-binary "allows to" "allows one to" [usr/bin/test-connect-t]
MDEV-37726 moved wsrep-start-position to INSTALL_RUNDATADIR
and made the latter to be created by systemd-tmpfiles.
Now postin scriptlet has to run systemd-tmpfiles explicitly
to make sure INSTALL_RUNDATADIR exists before restarting
the server.
followup for 649216e70d
With PermissionsStartOnly deprecated, remove this from the
systemd service file.
Replace Debian's ExecStartPre "install -d" with a tmpfile
configuration directive creating the directory with this.
Debian's ExecStartPost of the mariadb upgrade uses the !
special executable prefix added in systemd v231 to use
root privs.
After moving the systemd service to using environment files
instead of `systemctl set-environment` in 11.6 (MDEV-19210),
they (wsrep-new-cluster and wsrep-start-position) are located
in /var/lib/mysql along with the socket file in
Fedora/RHEL-based distros. This causes them to have incorrect
selinux permissions and therefore be not readable by systemd.
A solution is to generate these files in the run directory,
instead, which already has correct selinux label mysqld_var_run_t
mysql-selinux-1.0.12. Dissociating these files and the socket
in CMake configs can also prove useful for other things.
This also corrects some of the duplicate code in the build
scripts and made INSTALL_RUNDATADIR into a proper location
and used this for the tmpfiles where the temporary files
are created.
Debian's location is /run/mysqld/ matching its INSTALL_UNIX_ADDRDIR,
which is now a temporary location controlled by tmpfiles.
MDEV-35904 - backport MDEV-19210 to 10.11 as referenced
by unset environment variables become warnings.
We used to run `systemctl set-environment` to pass
_WSREP_START_POSITION. This is bad because:
* it clutter systemd's environment (yes, pid 1)
* it requires root privileges
* options (like LimitNOFILE=) are not applied
Let's just create an environment file in ExecStartPre=, that is read
before ExecStart= kicks in. We have _WSREP_START_POSITION around for the
main process without any downsides.
The association between PrivateDevices=false and NoNewPrivileges
as an old mistake in the kernel that has been now corrected.
This was in 2019 via Debian bug #911152.
main/statistics_json.result is updated for f8ba5ced55 (MDEV-36099)
The test uses 'delete from t1' in many places and then populates
the table again. The natural order of rows in a MyISAM table is well
defined and the test was implicitly relying on that.
before f8ba5ced55 delete was deleting rows one by one, using
ha_myisam::delete_row() because the connection was stuck in rbr mode.
This caused rows to be shown in the reverse insertion order (because of
the delete link list).
MDEV-36099 fixes this bug and the server now correctly uses
ha_myisam::delete_all_rows(). This makes rows to be shown in the
insertion order as expected.
It was mysql_install_db, and this is changed to mariadb-install-db.
likewise changed all of the support-files references to
mysql_install_db.
This install script is part of the service as a useful instigation
step, and a no-op in subseqeuent runs.
This script does however change the auth_pam_tool_dir ownership.
When running a multi-instance based on username, changing the
auth_pam_tool_dir will only cause troubles for the other users.
If you are running multiple instances on username is seems you
are unlikely do be having pam access for all users. Even
if you where the solution on auth_pam_tool_dir would be a group
permission and group access based on the users.
As such skip the changing of ownership.
As seen with openwrt and some other distros, the
determination of hostname can sometime need alternate
commmands.
This provides a cmake option HOSTNAME for non-windows machines
for the mariadb-install-db and mariadbd-safe scripts
and the support-files init scripts..
Hopefully, this ends the long story of CapabilityBoundingSet
in mariadb.service.
Started from MDEV-9095 (27e6fd9a59) which was supposed
to let --memlock work without root, but instead of
adding the necessary capability (CAP_IPC_LOCK) by putting it into
AmbientCapabilities it removed all other capabilities,
by putting CAP_IPC_LOCK into CapabilityBoundingSet
(which is the mask of allowed capabilities).
This broke pam plugin, which needed CAP_DAC_OVERRIDE,
it was fixed in MDEV-19878 (dd93028dae) by appending
CAP_DAC_OVERRIDE to CapabilityBoundingSet.
Obviously, memlock still didn't work, this was fixed
in MDEV-33301 (76a27155b4) by moving CAP_IPC_LOCK
to AmbientCapabilities.
Unfortunately, it moved too much (everything), so
MDEV-36229 (85ecb80fa3) fixed it moving CAP_DAC_OVERRIDE
back to CapabilityBoundingSet.
This caused MDEV-36591 (8925877dc8) triggering a bug in old
systemd versions. And it broke pam plugin on CentOS Stream 10,
where CAP_DAC_OVERRIDE alone was apparently not enough.
Let's finally fix this by removing CapabilityBoundingSet
completely and keeping CAP_IPC_LOCK in AmbientCapabilities,
which should've been the correct fix for MDEV-9095 from the start.
Combined AmbientCapabilities and CapabilityBoundingSet configuration
within a service file we have found by testing aren't supported in the
systemd v245 (Ubuntu 20.04) and v239 (RHEL8) for non-root users. This
resulted in a service start error EXIT_CAPABILITIES, a systemd limitation
of the version that we cannot work around consequences.
The systemd version 247 these combined capabilities have been tested to
work on Debian 11. No other supported major distros run systemd
version 246, and if they did, the missing capability of CAP_IPC_LOCK
won't be noticed as it was a convenience for --memlock users.
As such we disable the AmbientCapabilites for CAP_IPC_LOCK rather
that disabling the CapabilityBoundingSet, because doing the later
will disable authentication for MariaDB users that have configured PAM
with MariaDB.
Should a user require CAP_IPC_LOCK they can append in their own
systemd overlay file this configuration in the CapabilityBoundingSet
and configure the capability file attributes on the mariadbd executable
to have the IPC_LOCK capability. This isn't configured by default as the
presence of a capability in the MariaDB Server is detected by
openssl libraries as "insecure" which will then ignore any user configured TLS
configuration file passed though by the OPENSSL_CONF environment variable.
In resolving MDEV-33301 (76a27155b4) we
moved all the capabilities from CapabilityBoundingSet to AmbientCapabilities
where only add/moving CAP_IPC_LOCK was intended.
The effect of this is the defaulting running MariaDB HAS the capabiltiy
CAP_DAC_OVERRIDE CAP_AUDIT_WRITE allowing it to access any file,
even while running as a non-root user.
Resolve this by making CAP_IPC_LOCK apply to AmbientCapabilities and
leave the remaining CAP_DAC_OVERRIDE CAP_AUDIT_WRITE to CapabilityBoundingSet
for the use by auth_pam_tool.
Per https://github.com/systemd/systemd/issues/36529 OOM counts
as a on-abnormal condition. To ensure that MariaDB testart on
OOM the Restart is changes to on-abnormal which an extension
on the current on-abort condition.
Update pre-install script to fix package detection and standardize
MariaDB/MySQL terminology in messages for improved upgrade reliability
and reduced user confusion.
All new code of the whole pull request, including one or several files that are
either new files or modified ones, are contributed under the BSD-new license. I
am contributing on behalf of my employer Amazon Web Services, Inc.
Ensure that the GitLab CI is green again. Ideally all failures would be
fixed, but at the moment it is not feasible. As the purpose of a CI is
to protect the code base from having new testable regressions slip in,
update the CI pipeline to be all green by disabling multiple failing
test or reduce their scope.
- Avoid timeouts and make buid faster with
'-DCPACK_RPM_DEBUGINFO_PACKAGE=OFF'
- Remove 'GIT_CLONE_PATH' which isn't universally supported on all
GitLab instances
- Bump 'MARIADB_MAJOR_VERSION' to current 'main' contents (11.8). Also
update the upgrade test matrix to modern MariaDB versions.
- Remove UBsan builds as they are failing and can't quickly be fixed,
along with the MTR test that depended on it.
- Switch the CentOS 7 build to use Amazon Linux 2 instead, which has
equivalent Fedora package versions, but is still maintained and
package archive mirrors active.
- Extend skiplist to include currently failing MTR tests. These are not
quick to fix, so adding them to the skiplist will at least make the
CI green and allow us to catch any new regressions.
- Drop the default QPS limit in the mini-benchmark.sh to match what is
currently passing. The drop is large because it wasn't adjusted after
4016c905 got merged.
- Remove the currently failing faketime tests for 2028 compatibility.
- Remove unnecessary `dependencies:` definitions that have no effect in
the presence of `needs:`
- Reduce the scope of `cppcheck` to avoid timeouts from job.
- Update the ignorelists for both `cppcheck` and `flawfinder` as the
jobs were failing. This way the jobs will be green again, and reveal
is any new commits introduce issues.
- Drop the duplicate `cppcheck` and `flawfinder` job definitions that
got erroneously merged when both 9c287c0 and f4ce1e4 got merged on the
`main` branch, when the original intent was to have the latter commit
only on old MariaDB versions.
All new code of the whole pull request, including one or several files
that are either new files or modified ones, are contributed under the
BSD-new license. I am contributing on behalf of my employer
Amazon Web Services, Inc.
... and version in %prein scriptlet
%prein(MariaDB-server-11.4.3-1.el9.x86_64) scriptlet failed, exit status 1
The message is:
"The current MariaDB server package is provided by a different vendor (warning: Signature not supported. Hash algorithm SHA1 not available. MariaDB Foundation)".
The "warning: Signature not supported. Hash algorithm SHA1 not available." is taken from the STDERR.
warning: Signature not supported. Hash algorithm SHA1 not available.
gpg-pubkey-73e3b907-6581b071
rpm package vendor and version should be grepped from STDIN only.
Reviewer: Daniel Black
Mini-benchmark was using total time instead of total transactions
(events) to measure performance. This could give inconsistent results,
particulary when used to count CPU cycles. This changes the sysbench
command to use events x threads in each benchmark job, making the
benchmark more informative.
When `perf` [1] is available and enabled, mini-benchmark will measure how
many CPU cycles are required to do a fixed amount of work/queries. If
`perf` is unavailable, mini-benchmark will measure the peak queries per
second (QPS) during the execution of this work, regardless of the
duration.
[1] https://perf.wiki.kernel.org
