[Maria-discuss] logrotate
Quick proof of concept logrotate that hasn't really been changed in a while. The aim is to get this closer to a state for distro maintainers to use directly. By using a dedicated SQL user this shouldn't conflict with an existing user root user (which users always use despite the ability create other users with SUPER privs). As users will occasional change the password on the root without taking into account that logrotate typically uses the same user. Relying on users to update /root/.my.cnf is unreliable. Giving selinux permissions to allow logrotate read files under /root is also a little excessive. Using a dedicated mysqladmin.logrotate this won't conflict with existing mysqladmin group. Adds slow query log and general log to the logrotate script. Binary logs are deliberately omitted (MDEV-11610). https://mariadb.com/kb/en/mariadb/sql_error_log-plugin/ seems to have its own rotation) Proposed changes: https://github.com/MariaDB/server/compare/10.2...grooverdan:10.2-logrotate?e... mysqladmin --local uses SET SESSION SQL_LOG_BIN=0 so I'll change its implementation to use FLUSH LOCAL ... which would preserve the need to use RELOAD only privs for logrotate. Thoughts? Difficulties? Suggestions? ref: https://jira.mariadb.org/browse/MDEV-11610 https://jira.mariadb.org/browse/MDEV-5662
Hi, Daniel! On Apr 10, Daniel Black wrote:
Quick proof of concept logrotate that hasn't really been changed in a while.
The aim is to get this closer to a state for distro maintainers to use directly.
By using a dedicated SQL user this shouldn't conflict with an existing user root user (which users always use despite the ability create other users with SUPER privs). As users will occasional change the password on the root without taking into account that logrotate typically uses the same user. Relying on users to update /root/.my.cnf is unreliable. Giving selinux permissions to allow logrotate read files under /root is also a little excessive.
Using a dedicated mysqladmin.logrotate this won't conflict with existing mysqladmin group.
1. What user logrotate is normally run as? 2. Does logrotate really need to connect to mysqld do issue "FLUSH"? Why not send SIGHUP instead? This needs no user and no password.
Adds slow query log and general log to the logrotate script. Binary logs are deliberately omitted (MDEV-11610).
https://mariadb.com/kb/en/mariadb/sql_error_log-plugin/ seems to have its own rotation)
Proposed changes:
https://github.com/MariaDB/server/compare/10.2...grooverdan:10.2-logrotate?e...
I don't have logrotate installed locally, so I've googled for "man logrotate", and the man page said it's "sharedscripts", not "shared". Why did you have "shared" - different logrotate version? I have no opinion on "daily" vs "weekly" and "rotate 3" vs "4".
mysqladmin --local uses SET SESSION SQL_LOG_BIN=0 so I'll change its implementation to use FLUSH LOCAL ... which would preserve the need to use RELOAD only privs for logrotate.
Right, good idea. Regards, Sergei Chief Architect MariaDB and security@mariadb.org
Am 17.04.2017 um 21:59 schrieb Sergei Golubchik:
Hi, Daniel!
On Apr 10, Daniel Black wrote:
Quick proof of concept logrotate that hasn't really been changed in a while.
The aim is to get this closer to a state for distro maintainers to use directly.
By using a dedicated SQL user this shouldn't conflict with an existing user root user (which users always use despite the ability create other users with SUPER privs). As users will occasional change the password on the root without taking into account that logrotate typically uses the same user. Relying on users to update /root/.my.cnf is unreliable. Giving selinux permissions to allow logrotate read files under /root is also a little excessive.
Using a dedicated mysqladmin.logrotate this won't conflict with existing mysqladmin group.
1. What user logrotate is normally run as?
on typical machines as root
2. Does logrotate really need to connect to mysqld do issue "FLUSH"? Why not send SIGHUP instead? This needs no user and no password
that's what typical logrotate snippets do when supported by the daemon [root@srv-rhsoft:/etc/logrotate.d]$ cat preload /var/log/preload.log { missingok notifempty size=64k compress postrotate /bin/kill -HUP `/sbin/pidof preload 2>/dev/null` 2> /dev/null || true endscript }
On 18/04/17 05:59, Sergei Golubchik wrote:
Hi, Daniel!
On Apr 10, Daniel Black wrote:
Quick proof of concept logrotate that hasn't really been changed in a while.
The aim is to get this closer to a state for distro maintainers to use directly.
By using a dedicated SQL user this shouldn't conflict with an existing user root user (which users always use despite the ability create other users with SUPER privs). As users will occasional change the password on the root without taking into account that logrotate typically uses the same user. Relying on users to update /root/.my.cnf is unreliable. Giving selinux permissions to allow logrotate read files under /root is also a little excessive.
Using a dedicated mysqladmin.logrotate this won't conflict with existing mysqladmin group.
1. What user logrotate is normally run as?
root
2. Does logrotate really need to connect to mysqld do issue "FLUSH"? Why not send SIGHUP instead? This needs no user and no password.
I hadn't considered that: https://github.com/MariaDB/server/blob/10.1/sql/mysqld.cc#L3440..L3466 Looks a little too invasive hitting binary logs, relay logs, host, grant, threads. However another signal like USR1 could be used for a more minimal log rotate. Acceptable? Nice solution to void the complexity of managed SQL permissions. As Otto pointed out off list Debian has debian-maint user however I quite like an approach that doesn't use any SQL permissions. It make it easier for multi server slave/galera environments where this user is often out of sync with the filesystem config file that has the password in it.
Adds slow query log and general log to the logrotate script. Binary logs are deliberately omitted (MDEV-11610).
https://mariadb.com/kb/en/mariadb/sql_error_log-plugin/ seems to have its own rotation)
Proposed changes:
https://github.com/MariaDB/server/compare/10.2...grooverdan:10.2-logrotate?e...
I don't have logrotate installed locally, so I've googled for "man logrotate", and the man page said it's "sharedscripts", not "shared". Why did you have "shared" - different logrotate version?
sharedscripts is right.
I have no opinion on "daily" vs "weekly" and "rotate 3" vs "4".
mysqladmin --local uses SET SESSION SQL_LOG_BIN=0 so I'll change its implementation to use FLUSH LOCAL ... which would preserve the need to use RELOAD only privs for logrotate.
Right, good idea.
I'll see if I can make something that isn't too ugly.
Hi, Daniel! On Apr 18, Daniel Black wrote:
1. What user logrotate is normally run as? root
So, unix_socket plugin is an option. In fact, as I realize now (all to late), it's always an option, even if logrotate would be using a special "logrotate" user, we could've still created "logrotate" user in MariaDB and grant it RELOAD privilege. But "root" makes it easier, of course.
2. Does logrotate really need to connect to mysqld do issue "FLUSH"? Why not send SIGHUP instead? This needs no user and no password.
I hadn't considered that:
https://github.com/MariaDB/server/blob/10.1/sql/mysqld.cc#L3440..L3466
Looks a little too invasive hitting binary logs, relay logs, host, grant, threads.
Yes, but once a week? I'm not a DBA, I don't know if that's acceptable.
However another signal like USR1 could be used for a more minimal log rotate. Acceptable?
I wanted to reuse existing server functionality, to avoid coding something new in the server for the sake of logrotate. But if SIGHUP is too heavy, than yes, USR1 could be an option. Regards, Sergei Chief Architect MariaDB and security@mariadb.org
participants (3)
-
Daniel Black -
Reindl Harald -
Sergei Golubchik