今回の記事では、Linuxのインストール後に行うOSの基本的な設定箇所の例と、その設定時のコマンドなどを解説していきます。
尚、当記事の例ではRHEL系OSを前提としています。
今回の記事を作成するにあたり使用したLinuxのディストリビューションは「AlmaLinux 9.5」です。
当記事に記載した設定を順に進めてもらうことで、最低限の基本的な設定が完了するような構成にしてあります。
Linuxをインストールした後何から設定していけばよいか迷うような場合は、当記事を参考にしていただければ幸いです。
当記事の前提条件
当記事で紹介している設定例やコマンドは以下の環境及び構成を前提としています。
同じLinuxでも、UbuntuなどのDebian系ディストリビューションではコマンドが違う可能性があります。
また、rootでのログイン有無によっても異なる為、ご了承ください。
- RHEL系ディストリビューションのバージョン9
- OSインストール時にユーザーの作成をしない
- OSインストール時にホスト名の設定及びネットワークの設定をスキップ
- 最小構成でのOSインストール
- sshの設定が済むまでroot及びコンソール前提での操作
ホスト名の設定
OSインストール後の初回起動時に、まず実施していくべきなのは「ホスト名の設定」です。
ホスト名の登録方法は幾つかありますが、当記事では「hostnamectl」コマンドを使用します。
尚、詳しい「hostnamectl」の説明については、以下のリンク先にあるRHELの公式ドキュメントも参考にしてください。
まず、一時的な変更であれば以下のコマンドです。
hostnamectl [ホスト名]
但し、この場合はOSの再起動で元に戻ります。
通常は永続的に反映させる必要があるため、以下のコマンドを実行します。
hostnamectl set-hostname [ホスト名]
set-hostname を追加して設定したいホスト名をhostnamectlに渡すことで、/etc/hostname にも書き込まれ、そのホスト名が永続化されます。
OSの再起動は不要です。
# hostnamectl set-hostname example.com
# hostnamectl set-hostname web-srv01
コマンド実行後、いったんログイン中のユーザーをログオフしてログインし直すと、コンソールのlocalhostの表記が設定したホスト名に変わります。
[root@localhost ~]#
↓
[root@example ~]#
あと、このコマンドを使用せず、vi などで /etc/hostname を開き、直接ホスト名を書き込む方法でも設定できます。
IPアドレス等のネットワーク設定
ホスト名を設定したら、次にIPアドレス等のネットワーク設定を実施します。
尚、この段階までは、物理サーバーであればLANケーブルを抜いた状態、仮想マシンであれば仮想NICをネットワークから切断しておき、必要な設定が一通り完了してからネットワークに接続するようにしてください。
IPアドレスなどのネットワーク設定も幾つか方法がありますが、当記事では「nmcli」コマンドを使用します。
nmcli はNetworkManagerのコマンドラインユーティリティーです。
nmcli コマンドでは様々な機能があるため、より詳細な解説は以下に掲載した、RHELの公式ドキュメントをご確認ください。
nmcli は様々なネットワーク周りの設定が可能なのと、設定値や状態の確認が可能ですが、当記事では主にipv4における基本的な設定方法ついて紹介していきます。
先ず、nmcli の基本構文は以下です。
man から抜粋
nmcli [OPTIONS...] {help | general | networking | radio | connection | device | agent | monitor} [COMMAND] [ARGUMENTS...]
現在のNICのデバイス名を確認する場合は以下になります。
# nmcli device
DEVICE TYPE STATE CONNECTION
lo loopback connected (externally) lo
ens192 ethernet disconnected --
TYPE が ethrnet となっている行がNICです。
因みに、以前のRHEL系Linuxでは、NICのデバイス名として「eth0」などの表記をしていましが、現在のLinuxでは「ens〇〇」といった表記になっています。
nmcli コマンドでIPアドレスなどの設定を行う場合は、オプションでconnectionを使用し、NICのconnection名を指定して設定を進めていきます。
既定ではNICのデバイス名とコネクション名は同一ですが、念の為以下のコマンドで確認しておきます。
# nmcli connection
NAME UUID TYPE DEVICE
ens192 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ethernet ens192
lo xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx loopback lo
当例では、NICのconnection名は「ens192」です。
connection管理用コマンドの構文は以下になります。
man から抜粋
nmcli connection {show | up | down | modify | add | edit | clone | delete | monitor | reload | load | import | export | migrate} [ARGUMENTS...]
様々なオプションがありますが、このなかでまず知っておくべきなのは、「show」「up」「down」「modify」ぐらいで大丈夫です。
nmcli コマンドでIPV4ベースでIPアドレス等の設定をする場合の具体的な構文の例は以下です。
nmcli connection modify [コネクション名] ipv4.[設定項目1] [設定値1] ipv4.[設定項目2] [設定値2] ・・・
nmcli の次で、connection を指定していますが、これは con と略すことも可能ですし、c でも通ります。
また、その次の modify を指定することで、設定変更が可能ですが、設定が無ければ追加します。
尚、この modify も、mod と略することも可能ですし、m だけでもコマンドは通ります。
複数の設定項目をスペースで繋げて nmcli コマンドに渡し1行にまとめることも可能ですし、複数行に分けて設定することも可能です。
例えば、nmcli コマンドを使用して、コネクションに対して静的なIPアドレスを設定する場合は以下のコマンドになります。
# nmcli connection modify ens192 ipv4.method manual ipv4.address 192.168.1.100/24
尚、参照先DNSの設定のように、一つのコネクション名に対して複数の値を設定したい場合は以下のように記述ができます。
# nmcli connection modify ens192 +ipv4.dns 1.1.1.1 +ipv4.dns 8.8.8.8
逆に、設定を削除したい場合は以下のように記述できます。
# nmcli connection modify ens192 -ipv4.dns 8.8.8.8
ルーティングを追加したい場合は以下です。
# nmcli connection modify ens192 +ipv4.routes "192.168.0.0/24 192.168.1.254"
上記のようにconnectionに設定をしても、それだけではNICに設定値は反映されません。
反映させるには、connectionの設定を reload で再読み込みをするか、connectionの down 及び up を実行する必要があります。
但し、sshなどリモートで操作している場合は、当然downを実行した直後にネットワークが切断されてしまい、それ以降ネットワーク越しでの接続が出来なくなってしまうため、down及びupを実行する場合は、コマンドを一行にまとめて同時に実行させます。
# nmcli connection reload
# nmcli connection down ens192 && nmcli connection up ens192
「nmcli connection show [connection名]」で現在の設定値を一覧で確認できます。
必要な設定の項目名もこの一覧を参考にしながら設定を進めていくことになります。
# nmcli connection show ens192
connection.id: ens192
connection.uuid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
connection.stable-id: --
・・・途中省略・・・
ipv4.method: manual
ipv4.dns: 1.1.1.1,8.8.8.8
ipv4.dns-search: --
ipv4.dns-options: --
ipv4.dns-priority: 0
ipv4.addresses: 192.168.1.100/24
ipv4.gateway: 192.168.1.254
ipv4.routes: { ip = 192.168.0.0/24, nh = 192.168.1.254 }
ipv4.route-metric: -1
ipv4.route-table: 0 (unspec)
ipv4.routing-rules: --
ipv4.replace-local-rule: -1 (default)
ipv4.dhcp-send-release: -1 (default)
ipv4.ignore-auto-routes: いいえ
ipv4.ignore-auto-dns: いいえ
ipv4.dhcp-client-id: --
ipv4.dhcp-iaid: --
ipv4.dhcp-dscp: --
ipv4.dhcp-timeout: 0 (default)
ipv4.dhcp-send-hostname: はい
ipv4.dhcp-hostname: --
ipv4.dhcp-fqdn: --
ipv4.dhcp-hostname-flags: 0x0 (none)
ipv4.never-default: いいえ
ipv4.may-fail: はい
ipv4.required-timeout: -1 (default)
ipv4.dad-timeout: -1 (default)
ipv4.dhcp-vendor-class-identifier: --
ipv4.link-local: 0 (default)
ipv4.dhcp-reject-servers: --
ipv4.auto-route-ext-gw: -1 (default)
・・・以降省略・・・
新規ユーザーの作成
Linuxにおける既定の管理ユーザーとして全ての権限を持つ root のみを使用してサーバーを運用することはセキュリティ上のリスクが大きいため、通常は権限を限定したユーザーを作成し、そのユーザーを使用してサーバーを運用します。
また、権限が必要な作業をするときだけ su コマンドを実行して操作するユーザーを root に切り替える、または、root 権限が必要になるコマンド実行時のみ sudo を付与して実行するといった運用が一般的です。
また、サーバー用途でLinuxを運用する場合、システム管理者は ssh でサーバーにリモート接続をして操作をすることが一般的ですが、root が ssh でログインできてしまうとセキュリティ上の大きなリスクになるため、ssh では root でのログインを無効化し、通常の権限を付与したユーザーでログインさせるようにしておくことが必要です。
当記事では、新しくユーザーを作成し、そのユーザーが必要によって sudo コマンドで root 権限でコマンドを実行できるよう設定します。
先ずユーザーを作成します。
# useradd sample_user
次に作成したユーザーのパスワードを設定します。
# passwd sample_user
次に、作成したユーザーで sudo をできるようにするために、wheelグループにユーザーを追加します。
尚、usermod コマンドのオプション「-G」でセカンダリグループへの処理になり、「-a」を更に指定することで、セカンダリグループの変更ではなく追加をします。
# usermod -aG wheel sample_user
これで対象のユーザーは、sudo が使えるようになります。
尚、作成したユーザーをsshで接続できるようにするやり方は、後述するsshの設定部分で説明します。
パッケージ管理ツールに参照先プロキシを設定
Linuxでは、ソフトウェアのインストールやアップデートなどを簡単に行うために「パッケージ管理ツール」が利用できます。
RHEL系ディストリビューションにおける「パッケージ管理ツール」としては以下があります。
- rpm：RHEL系ディストリビューションで昔から使われているパッケージ管理ツール
- yum：厳密にはrpmベースのパッケージ管理ツールのメタ管理システム
- dnf：yumの後継のあたるパッケージ管理ツールのメタ管理システム
Linuxの初期設定時においては、パッケージ管理ツールを利用して、必要とするパッケージを導入していくことになりますが、サーバーとして利用する場合、セキュリティ上の理由により、インターネットへ直接アクセスさせないネットワーク構成にしている場合も多く、その場合はパッケージ管理ツール側で参照先プロキシサーバーを設定し、そのプロキシサーバーを介してパッケージのダウンロードをさせるといった構成が一般的です。
今回の記事では、dnf を使用する場合の参照先プロキシの設定について紹介します。
まず、dnf の設定ファイルを vi エディタなどで開きます。
# vi /etc/dnf/dnf.conf
記事で使用している AlmaLinux 9.5 では以下のようになっています。
[main]
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=True
best=True
skip_if_unavailable=False
この[main]ディレクティブ内に以下の記述を追加します。
proxy=http://[プロキシホスト]:[ポート番号]
例えば以下のように追記します。
[main]
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=True
best=True
skip_if_unavailable=False
proxy=http://192.168.1.10:3128
これで、dnf 実行時に毎回プロキシを介してインターネットにアクセスするようになります。
尚、余談ですが、dnf コマンドは yum とも互換性があり、上記のコマンドを yum に置き換えても同様に動きます。
新しいOSでも yum は利用でき、yum の設定ファイルである /etc/yum.conf もありますが、yum.conf は dnf.conf のシンボリックリンクであるため、上記のように dnf.conf を編集することで yum.conf にも反映されます。
ls コマンドで以下のように表示されることから、yum.conf がシンボリックリンクだということがわかります。
# ls -l /etc/yum.conf
lrwxrwxrwx. 1 root root 12 10月 2 21:55 /etc/yum.conf -> dnf/dnf.conf
sshの有効化とサーバー設定
sshサーバー機能を有効化し、ssh によるリモート接続を受け付けるようにします。
また、ssh で接続できるユーザーを明示的に指定しつつ、root でのログインは許可しないように設定しておくことも必要です。
まずは、ssh がインストールされているか確認します。
# dnf list installed | grep -i openssh
openssh.x86_64
openssh-clients.x86_64
openssh-server.x86_64
必要なのは、openssh-server.x86_64 です。
もし上記のコマンドの実行結果に何も出力されなければ、以下のコマンドで ssh をインストールします。
# dnf -y install openssh-server
次に、sshd_config を vi エディタなどで開き編集します。
# vi /etc/ssh/sshd_config
sshd_config 内の以下の設定値を変更します。
# PermitRootLogin prohibit-password
PermitRootLogin no
# ssh でログイン可能なユーザーを指定
# AllowUsers [ユーザー名]
AllowUsers sample_user
# 複数名を指定する場合はスペースを空けて並べる。
# AllowUsers [ユーザー名] [ユーザー名]
AllowUsers sample_user sample_user2
[PermitRootLogin]は ssh 接続時に root のログインを許可するか否かの設定です。
既定値は prohibit-password です(RHEL9以降)。
これは通常のパスワード認証などは許可しないが、公開鍵認証などであれば許可する設定です。
どのような認証方式であれ、root でのログインを許可することはセキュリティ上のリスクになるため、no としておいた方がよいです。
また、[AllowUsers]は既定のsshd_configには項目がないため、書き足してください。
他にも、パスワード認証でのログイン自体を無効にしたり、ポート番号を変更するなどの設定が可能であり、必要によって編集してください。
sshd_config の編集後、sshd の再起動で反映されます。
# systemctl restart sshd
尚、ssh でアクセスを受け付けるには、ファイアーウォール(firewalld)の設定変更が必要です。
こちらについては後述します。
NTPクライアントの設定
サーバーにとってシステム時刻は重要です。
よって、サーバーが常に正確な時刻を保持するように、信頼のおけるNTPサーバーを参照し、時刻を同期するようにしておく必要があります。
Linuxでは、NTP用のサービスとして、昔からある「ntpd」と、現在の標準である「chrony」が広く利用されています。
尚、NTPをクライアントとして使用する場合でも、NTP用サービスのインストールが必要です。
当記事では、「chrony」を使用する構成で説明していきます。
まずは chrony がインストールされているか確認します。
# dnf list installed | grep -i chrony
何も検出されなければインストールされていないので、インストールします。
# dnf install -y chrony
インストールしたら設定ファイルを vi エディタ等で開いて必要な箇所を編集します。
# vi /etc/chrony.conf
NTPクライアントとして使用する場合は、編集が必要な箇所は僅かです。
まず、冒頭に記述されている参照先のNTPサーバーを書き変えます。
新しいAlmaLinux の場合は、既定値として「2.almalinux.pool.ntp.org」が指定されているので、そこをコメントアウトして、参照先のNTPサーバーを指定します。
#pool 2.almalinux.pool.ntp.org iburst
server 192.168.1.200 iburst
server 192.168.1.201 iburst
尚、既定値では「pool」で設定されていますが、NTPサーバー単体を指定するのであれば「server」で結構です。
参照先NTPサーバーが複数あれば複数行記述します。
後は、既定値として設定項目自体がないのですが、リッスンするポート番号として 0 を指定します。
それにより、chronyがどのポートでもリッスンしないことになり、純粋にクライアントとして使用できます。
chrony.conf の末尾など適当なところに以下のようの記述してください。
port 0
chrony のサービスが既に立ち上がっているなら「restart」、まだ起動していないなら「start」します。
# systemctl start chronyd
# systemctl restart chronyd
firewalldの設定
サーバーが属しているネットワークの出入り口にファイアーウォール機器やUTMなどの置いて通信をフィルタリングしている場合であっても、サーバーのOS側で必要な通信のみ通すように制限を掛けることは必要です。
Linuxでは「firewalld」というサービスで通信のフィルタリングが行えます。
firewalld を無効化してフィルタリングをしないこともできますが、可能な限り有効にして運用するのが望ましいです。
尚、今回の記事では、OSの初期設定において ssh のサーバー機能を利用できるようにしています。
よって、firewalld を有効したのち、ssh の通信を通す設定が必要になります。
まずは firewalld の状態を確認します。
状態を確認するには、「firewall-cmd」を使うか、「systemctl status」を使用します。
尚、「systemctl status」の方が詳細に状態を確認できます。
# firewall-cmd --state
# systemctl status firewalld
もし起動していなければ起動します。
# systemctl start firewalld
firewalldにおけるzoneについて
firewalldにおける zone について簡単に説明しておきます。
firewalld における「zone」とは、サーバーのネットワークインターフェースやIPアドレスを特定の zone に関連付けることで、zone 毎に異なるアクセス制御ポリシーを設定するための仕組みです。
firewalld で元々用意されている zone は、「public」以外にも複数あり、以下のコマンドで確認ができます。
# firewall-cmd --get-zones
block dmz drop external home internal nm-shared public trusted work
既定の zone は「public」です。
zone を指定せずにポリシーを設定した場合は public に追加されます。
複雑なアクセス制御を行わないのであれば、 public にだけ設定を入れれば十分です。
尚、現在の zone を確認する場合に「アクティブゾーン」と「デフォルトゾーン」という概念があるので、そこも簡単に説明しておきます。
アクティブゾーン：現在ネットワークインターフェースなどの割り当てがされているゾーン
デフォルトゾーン：新しいネットワークインターフェースなどが追加された場合に自動的に適用されるゾーン。
共に以下のコマンドで確認できます。
# firewall-cmd --get-active-zones
# firewall-cmd --get-default-zones
firewalldにsshの通信を許可
firewalld に ssh の通信を許可します。
# firewall-cmd --add-service=ssh --zone=public --permanent
尚、上記コマンド例では、zone に「public」を明示的に指定しています。
public は既定のzoneであるため、zone の設定を変更していない場合は、zone の指定を省略できます。
「permanent」を指定することで、登録したポリシーを永続化します。
この指定を入れないと、一時的な登録となり、OSを再起動したタイミングなどで登録したポリシーが元に戻ります。
登録したポリシーを確認するには以下のコマンドです。
# firewall-cmd --list-all
登録しただけでは実際のアクセス制御の挙動に反映されないため、登録した設定を「reload」で反映させます。
# firewall-cmd --reload
historyに日時を追加
Linuxでは「history」コマンドを実行することで、現在のユーザーが過去に実行したコマンドを一覧で出力できます。
日頃の運用において、過去にどんなコマンドを入力したか確認することは頻繁にあるため、非常に便利なコマンドですが、個々のコマンドがいつ実行されのかは表示されません。
いつ実行されたかもわかると更に便利になるため、その設定も最初からしておくことをおすすめします。
まず、history コマンドで表示される過去のコマンドの一覧は、各ユーザーのホームディレクトリ直下の「.bash_history」に記録されています。
それぞれのユーザーでログインしたうえで、以下のコマンドを実際に開くこともできます。
# cat ~/.bash_history
尚、上記コマンド内の ~ は「チルダ」と呼び、現在のユーザーのホームディレクトリを指します。
現在 root でログインしているなら、「/root」と同じであり、例えば sample_user という名前のユーザーでログインしているなら、「/home/sample_user」と同じです。
また、今回の「.bash_history」もそうですが、ファイル名の先頭に . が付いています。
これは隠しファイルです。
特定のディレクトリの内容を表示するには ls コマンドを使いますが、ls を実行しただけでは表示されません。
ls の -a オプションを付けることで隠しファイルが表示されます。
# ls -a ~/
# ls -a /home/sample_user/
history コマンドの出力結果に実行日時を付与するには、「~/.bashrc」を編集します。
vi エディタなどで開き、中身の末尾に以下の内容を追記してください。
export HISTTIMEFORMAT='%F %T '
.bashrc を編集したら、一度ログアウトして、再度ログインしてもらえれば反映されます。
尚、.bashrc の編集以前に実行したコマンドの history については、当然日時が記録されていないため、実行日時が記録された history の最も過去の実行時の日時で表示されます。
journald ログの永続化
「journald」は、Linuxのログ管理システムの一つであり、以前の syslog に代わるものとして設計され、より強力で柔軟なログ管理機能を提供します。
journalctl コマンドとオプションを組み合わせてログを読み取ることができ、いざという時にとても頼りになります。
但し、既定では journald のログは /run/log/journal/ に保存され、OSの再起動に伴い消えます。
よって、再起動でもログが消えないように永続化をしておくことをおすすめします。
まずは、設定ファイルをviエディタ等で開きます。
# vi /etc/systemd/journald.conf
私の環境では、既定値は以下の状態になっています。
[Journal]
#Storage=auto
#Compress=yes
#Seal=yes
#SplitMode=uid
#SyncIntervalSec=5m
#RateLimitIntervalSec=30s
#RateLimitBurst=10000
#SystemMaxUse=
#SystemKeepFree=
#SystemMaxFileSize=
#SystemMaxFiles=100
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#RuntimeMaxFiles=100
#MaxRetentionSec=
#MaxFileSec=1month
#ForwardToSyslog=no
#ForwardToKMsg=no
#ForwardToConsole=no
#ForwardToWall=yes
#TTYPath=/dev/console
#MaxLevelStore=debug
#MaxLevelSyslog=debug
#MaxLevelKMsg=notice
#MaxLevelConsole=info
#MaxLevelWall=emerg
#LineMax=48K
#ReadKMsg=yes
Audit=
Storage：
永続化をする場合、コメントアウトされている Storage を有効にし、値を auto から persistent に変更します。
persistent に変更することで、systemd が ログを /var/log/journal/ に保存するようになります。
また、ディレクトリが無ければ自動的に作成します。
他にも必要によって、以下の設定を追加、変更します。
SystemMaxUse：
永続化した場合に、RuntimeMaxUse ではなく、こちらが使われます。
journald が使用できる最大ディスクサイズ(単位：G や M)を指定します。
こちらもコメントを外して SystemMaxUse を有効しつつ、ディスク容量が枯渇しないように適切な値を指定しておきます。
SystemKeepFree：
永続化した場合に、RuntimeKeepFree ではなく、こちらが使われます。
systemd が残す必要のあるディスク領域のサイズ(単位：G や M)を指定します。
SystemMaxFileSize：
永続化した場合に、RuntimeMaxFileSize ではなく、こちらが使われます。
ログの1ファイルあたりの最大サイズ(単位：G や M)を指定します。
SystemMaxFiles：
永続化した場合に、RuntimeMaxFiles ではなく、こちらが使われます。
/var/log/journal/ に配置されるログファイルの最大個数を指定します。
/etc/systemd/journald.conf を編集したら、systemd-journald を再起動します。
# systemctl restart systemd-journald
以下のコマンドでジャーナルファイルの整合性チェックができますが、保存先が /var/log/journal/ で動作しているかの確認も可能です。
# journalctl --verify
尚、RHEL の公式ドキュメントの journald.conf に対する解説では、SystemKeepFree でパーセントを指定できるとなっており、この記述が誤りなのかは不明ですが、実際にパーセントで指定して systemd-journald を再起動し、その際の起動プロセスを journalctl -xe などで確認すると、値がエラーとなり、SystemKeepFree の設定が無視されて起動しているのが確認できます。
SELinuxの無効化
「SELinux（Security-Enhanced Linux）」は、Linuxの強制アクセス制御（MAC）を提供するセキュリティ機能です。
すべてのプロセスやファイルにセキュリティコンテキスト（ラベル）を付与し、ポリシーに基づいてアクセスを制限します。
主にサーバー環境で利用され、強固なセキュリティを実現します。
尚、最近のLinuxでは既定で有効になっています。
セキュリティ上非常に有効な機能であり、本来であれば有効な状態のままサーバーを運用することが望ましいのですが、SELinuxの機能の特性上、様々な操作や実行をブロックすることになり、SELinuxが有効な環境に不慣れな場合は構築や運用の手間が発生します。
また、仕組みは複雑で学習コストが高く、アプリケーションによってはSELinuxに対応していない場合もあり、無効にして稼働させざるを得ない場合もあります。
よって、SELinuxを無効化する方法についても紹介しておきます。
まず、SELinuxが有効になっているかを確認します。
getenforce コマンドで現在のSELinuxの動作モードを確認できます。
# getenforce
Disabled：無効
Enforcing：有効
Permissive：有効(ブロックはせず記録のみ行う)
SELinuxを一時的に無効化するには以下のコマンドです。
# setenforce 0
有効な状態に戻すには、「setenforce 1」を実行します。
尚、SELinuxを永続的に無効にするには、OSのブートパラメーターとしてSELinuxを読み込まないように変更する必要があり、それには grubby コマンドを使用します。
一応 grubby がインストールされているかは以下のコマンドで確認できます。
# dnf list installed | grep -i grubby
SELinuxをOSのブート時に読み込ませないようにするには以下のコマンドを実行した後、再起動をしてください。
# grubby --update-kernel ALL --args selinux=0
# reboot
尚、再度SELinuxをOSのブート時に読み込ませるようにする場合は以下のコマンドを実行して再起動を行います。
# grubby --update-kernel ALL --remove-args selinux
# reboot
/etc/selinux/config を編集する無効化方法について
過去のSELinuxでは、/etc/selinux/config ファイルを編集して、SELINUX=enforcing を SELINUX=disabled に書き変える方法が周知されていましたが、この方法で無効化した場合、OS起動時にハングアップする可能性があるとのことです。
RHEL 8 では、/etc/selinux/config ファイルの SELINUX=disabled オプションを使用して SELinux を無効にする非推奨の方法を引き続き使用できます。
その結果、カーネルは SELinux が有効な状態で起動し、起動プロセスの後半で無効モードに切り替わります。
その結果、メモリーリークや競合状態が発生し、カーネルパニックが発生する可能性があります。
Red Hat Enterprise Linux 8 公式ドキュメント – SELinux の無効化
よって、SELinuxを無効化する場合、configファイルを編集して無効化するのではなく、grubby コマンドから無効化する方法で対応してください。
最後に
今回の記事では、RHEL系Linuxをインストールした後に行うOSの基本的な設定項目の紹介や、実際の設定例を簡単に紹介してみました。
私自身、OSインストール後に何から設定しようか迷うこともあり、自分自身の備忘録も兼ねて記事にまとめました。
記事で紹介した基本設定を行い、その後は、そのサーバーの用途によって、Apacheをインストールしたり、データベースをインストールするといった流れを想定しています。
今回の記事がどなたかの参考になれば幸いです。
それでは皆さまごきげんよう。
