【要注意】サーバー更改時にやってはいけないLinux設定ミスまとめ

  • URLをコピーしました!

サーバー更改では、

「とりあえず動かす」ために行った設定が、後から大きな障害を生む

ケースが少なくありません。

本記事では、

  • 更改時によくあるLinux設定ミス
  • なぜそれが危険なのか
  • 正しい判断・代替案

実務目線で具体的 に解説します。

目次

やってはいけない設定① とりあえずSELinuxを無効化

トラブル回避のために、

setenforce 0

SELINUX=disabled

とするのはありがちですが、

更改時に理由なく無効化するのは危険です。

なぜダメか

  • セキュリティレベルが低下
  • 後から有効化すると再トラブル

正しい対応

  • Permissive でログ確認
  • 必要なポリシー調整

やってはいけない設定② firewalld を停止したまま本番投入

systemctl stop firewalld
systemctl disable firewalld

一時的な疎通確認なら有効ですが、

そのまま本番はNG

問題点

  • 不要なポートが全開放
  • セキュリティ事故の温床

正しい対応

  • 必要ポートのみ許可
  • 設定をコード化して管理

やってはいけない設定③ sysctlを理由なくコピペ

旧サーバーの

/etc/sysctl.conf

をそのままコピーするのは危険です。

なぜ危険か

  • カーネルバージョン差分
  • 環境に合わないチューニング

正しい対応

  • 1項目ずつ意味を確認
  • 変更理由を記録

やってはいけない設定④ ulimit を確認せず移行

nofile / nproc が不足すると、

  • 接続エラー
  • プロセス起動失敗

を引き起こします。

正しい確認

ulimit -a

やってはいけない設定⑤ ログ設定の移行漏れ

rsyslog / journald の設定を忘れると、

  • 障害時にログがない
  • 監視が機能しない

という致命的な状態になります。

対策

  • ログ保存・転送先を確認
  • 実際にログが流れるか検証

やってはいけない設定⑥ デフォルトMTUのまま放置

仮想環境・クラウドでは、

  • MTU 不一致
  • 断続的な通信遅延

が発生しがちです。

確認

ip link

やってはいけない設定⑦ systemd サービスの自動起動未確認

起動していても、

再起動後に立ち上がらない

ケースは頻発します。

確認

systemctl list-unit-files --state=enabled

やってはいけない設定⑧ パフォーマンス問題を設定で隠す

性能劣化を、

  • キューサイズ増加
  • バックログ増加

だけで誤魔化すのは危険です。

理由

  • 根本原因が残る
  • 負荷増大時に破綻

更改時の正しい考え方まとめ

  • 「一時対応」と「恒久対応」を分ける
  • 設定変更には必ず理由を持つ
  • 再起動後も同じ状態か確認

まとめ

  • 更改は設定ミスが最も多い工程
  • とりあえず設定は事故の元
  • 「なぜ?」を説明できる設定だけ残す

この意識を持つだけで、

更改後トラブルの大半は防げます。

目次