Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-17637

New systemd-aware script to re-create datadir

Details

    Description

      When creating the data directories with the mysql_install_db script, UMASK settings in /etc/systemd/system/mariadb.service.d/ are ignored.

      Setting UMASK in the environment works correctly, but setting /etc/systemd/system/mariadb.service.d/ as instructed in https://mariadb.com/kb/en/library/specifying-permissions-for-schema-data-directories-and-tables/ has no effect on the mysql_install_db script.

      Note that UMASK settings are respected by the server itself. This is only an issue when invoking mysql_install_db manually on systemd distributions.

      Attachments

        Issue Links

          Activity

            Converted to a feature request based on valerii's comment above.

            The fact that mysql_install_db isn't aware of an init script is irrelevant. It is not a regression, and neither is it a bug, that it is not aware of any wrappers that might or might not be optionally used to call it, as well as mysqld itself and any other MariaDB binaries.

            Please note that there is also MDEV-17640, which is a separate but related matter.

            elenst Elena Stepanova added a comment - Converted to a feature request based on valerii 's comment above. The fact that mysql_install_db isn't aware of an init script is irrelevant. It is not a regression, and neither is it a bug, that it is not aware of any wrappers that might or might not be optionally used to call it, as well as mysqld itself and any other MariaDB binaries. Please note that there is also MDEV-17640 , which is a separate but related matter.

            I don't see it as something that needs fixing at all. Files in /etc/systemd/system/mariadb.service.d/ affect mariadb when started via systemd and do not affect mariadb when not started via systemd. This is what one would expect and this is what actually happens.

            serg Sergei Golubchik added a comment - I don't see it as something that needs fixing at all. Files in /etc/systemd/system/mariadb.service.d/ affect mariadb when started via systemd and do not affect mariadb when not started via systemd. This is what one would expect and this is what actually happens.
            juan.vera Juan added a comment - - edited

            I can let the user know that engineering feels mysql_install_db does not need to support server UMASK settings, but it seems legitimate that a client would expect mysql_install_db to work in this scenario.
            My take is that since the functional requirement to have the server use a specific permissions mask when managing files would obviously apply to a utility that creates those files for that server, maybe the service configuration is not the ideal place for UMASK. If it were a global variable, it would be a much more seamless management experience for the server administrator.

            juan.vera Juan added a comment - - edited I can let the user know that engineering feels mysql_install_db does not need to support server UMASK settings, but it seems legitimate that a client would expect mysql_install_db to work in this scenario. My take is that since the functional requirement to have the server use a specific permissions mask when managing files would obviously apply to a utility that creates those files for that server, maybe the service configuration is not the ideal place for UMASK. If it were a global variable, it would be a much more seamless management experience for the server administrator.

            May be. Or may be mysqld --initialize mode could be implemented.

            serg Sergei Golubchik added a comment - May be. Or may be mysqld --initialize mode could be implemented.

            Juan: In review of the referenced page, https://mariadb.com/kb/en/library/specifying-permissions-for-schema-data-directories-and-tables/ whose parent is "Starting and Stopping MariaDB", it appears that this content is wholly about the MariaDB Server process and not about the installation process of MariaDB Server.

            It is likely that some other page or pages need to incorporate information about file and directory permissions, but I believe the note added to this page two months ago is now covering a completely separate product step, and should be reverted. I don't believe that this specific page should be extended to cover these other cases, but that we should identify in the page specific to mysql_install_db how umask is set.

            Does this approach raise concerns? If not, I will revert your change at bottom of page and add umask information on the pages for mysql_install_db

            jacob.moorman Jacob Moorman (Inactive) added a comment - Juan: In review of the referenced page, https://mariadb.com/kb/en/library/specifying-permissions-for-schema-data-directories-and-tables/ whose parent is "Starting and Stopping MariaDB", it appears that this content is wholly about the MariaDB Server process and not about the installation process of MariaDB Server. It is likely that some other page or pages need to incorporate information about file and directory permissions, but I believe the note added to this page two months ago is now covering a completely separate product step, and should be reverted. I don't believe that this specific page should be extended to cover these other cases, but that we should identify in the page specific to mysql_install_db how umask is set. Does this approach raise concerns? If not, I will revert your change at bottom of page and add umask information on the pages for mysql_install_db

            People

              juan.vera Juan
              juan.vera Juan
              Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.