Linux に mysql をインストールするときに /etc に my.cnf ファイルがない問題を解決する

今日、mysql ポートを変更したいと思ったのですが、/etc/ ディレクトリに my.cnf ファイルがないことがわかったので、オンラインで解決策があるかどうか調べました。

Linux で my.cnf が見つからないというブログをたくさん読みましたが、そのすべてで my-medium.cnf を etc に移動して my.cnf に名前を変更するように書かれていましたが、私の場合も my-medium.cnf がありません。後で知ったのですが、5.7.18 以降では公式がバイナリ パッケージで my-default.cnf ファイルを提供しなくなったそうです。

詳細については、https://dev.mysql.com/doc/refman/5.7/en/binary-installation.html を参照してください。

では、ポート番号を変更するにはどうすればよいでしょうか?実際には、/etc/mysql/mysql.conf.d を変更するだけで済みます。

補足: mysql を起動すると、/etc/my.cnf は無視されるというメッセージが表示されます。

今日、テスト開発者との問題に対処していたところ、MySQL インスタンスの起動に失敗することを発見しました。プロセスは次のとおりでした。

MySQL インスタンスが閉じられていることが判明しました。MySQL インスタンスを起動するコマンドを実行すると、警告が表示されます。

# サービス mysql.server を起動します
警告: 誰でも書き込み可能な設定ファイル '/etc/my.cnf' は無視されます
MySQL の起動に成功しました!

次の内容を示す mysql 起動ログを確認します。

151014 11:39:24 mysqld_safe /data/mysql/data のデータベースを使用して mysqld デーモンを起動しています
警告: 誰でも書き込み可能な設定ファイル '/etc/my.cnf' は無視されます

これはおそらく、権限がグローバルに書き込み可能であり、どのユーザーでも書き込みができることを意味します。 MySQL は、このファイルが他のユーザーによって悪意を持って変更される可能性があることを懸念しているため、この構成ファイルを無視します。この方法では、mysql をシャットダウンできません。

このとき、MySQL データベースの設定を照会すると、my.cnf で設定された一部のパラメータが MySQL インスタンスで有効になっていないことがわかります。

これは、/etc/my.cnf も 777 権限に変更されているためです。

# ls -la /etc/my.cnf
-rwxrwxrwx 1 ルート ルート 1120 7月 31 10:28 /etc/my.cnf

/etc/my.cnf の権限が多すぎるため、インスタンスを起動またはシャットダウンできなくなります。権限を 644 に変更する必要があります。操作は次のとおりです。

# ls -la /etc/my.cnf
-rwxrwxrwx 1 ルート ルート 1120 7月 31 10:28 /etc/my.cnf
# 
# 
# chmod 644 /etc/my.cnf
# 
# ls -la /etc/my.cnf
-rw-r--r-- 1 ルート ルート 1120 7月 31 10:28 /etc/my.cnf
#

/etc/my.cnf を確認し、インスタンスを再起動します。

151014 14:05:54 mysqld_safe mysqld は pid ファイル /data/mysql/data/yq-xg-dev122.pid から終了しました
151014 14:06:08 mysqld_safe /data/mysql/data のデータベースを使用して mysqld デーモンを起動しています
151014 14:06:08 [注意] プラグイン「FEDERATED」は無効になっています。
151014 14:06:08 InnoDB: InnoDB メモリヒープが無効になっています
151014 14:06:08 InnoDB: ミューテックスと rw_locks は GCC アトミック組み込み関数を使用します
151014 14:06:08 InnoDB: 圧縮テーブルは zlib 1.2.3 を使用します
151014 14:06:08 InnoDB: LinuxネイティブAIOの使用
151014 14:06:08 InnoDB: バッファプールを初期化しています。サイズ = 128.0M
151014 14:06:08 InnoDB: バッファプールの初期化が完了しました
151014 14:06:08 InnoDB: サポートされている最高のファイル形式は Barracuda です。
151014 14:06:08 InnoDB: バックグラウンドスレッドの開始を待機しています
151014 14:06:09 InnoDB: 1.1.8 が起動しました。ログ シーケンス番号 18872844901
151014 14:06:09 [警告] 'proxies_priv' エントリ '@ root@xinge122' は --skip-name-resolve モードで無視されます。
151014 14:06:09 [メモ] イベント スケジューラ: 0 件のイベントが読み込まれました
151014 14:06:09 [注記] /usr/local/mysql/bin/mysqld: 接続準備完了。
バージョン: '5.5.19-log' ソケット: '/tmp/mysql.sock' ポート: 3306 MySQL コミュニティ サーバー (GPL)

/etc/my.cnf の権限を通常のものに変更すると、MySQL インスタンスを正常に起動できることがわかります。

この事例から、次のようなインスピレーションを得ることができます。

Linux オペレーティング システムのルート ディレクトリ内のディレクトリとファイルの権限を変更することは非常に危険です。

たとえば、/etc/ssh ディレクトリの権限が変更されると、ssh は使用できなくなります。/etc/security または /etc/init.d/sshd ファイルが変更されると、root ユーザーはシステムにログインできなくなります。

したがって、システム権限、特に気軽に変更できない /etc/ ディレクトリ下のファイル権限には注意する必要があります。

開発と運用保守の両方を標準化する必要があり、ルートユーザーとしての直接操作は可能な限り避ける必要があります。ソフトウェアとアプリケーションの保存場所も別のディレクトリに配置し、各アプリケーションは別のユーザーが操作する必要があります。

システムファイルを安易に変更しないでください。特に、/etc/ 関連のシステムファイルを安易に変更しないでください。変更する場合は、まずテストして、変更する前に問題がないことを確認してください。

上記は私の個人的な経験です。参考になれば幸いです。また、123WORDPRESS.COM を応援していただければ幸いです。間違いや不備な点がありましたら、遠慮なくご指摘ください。