0. はじめに
元システムエンジニアです。
最近はコンサルとかアドバイザー系の業務が中心だったため、製品検証の機会が少なかったのですが、とある案件にかかわることがきっかけでLinuxの検証環境の構築が必要になりました。
今回の用途は、製品検証のために、運用系の検証（SyslogとかSNMP Trapとか）を行ったため、そのあたりのお話となります（どんな内容下記になる方は、目次をご覧ください）。
年齢が年齢のため、何かに記録しておかないと、すぐ忘れてしまうので、Qiitaにメモを残すことにします。
（何か月後かに同じような検証をするときに、再度調べなおすのが手間なので）
ちなみにこういう情報共有系って、何が良いのか迷いますよね。
（昔はExcelで作って、会社のファイルサーバに置いていたような…）
1. AlmaLinuxを構築しよう
検証環境は案件に応じて構築しますが、今回はLinux環境です。
昔はCentOSを使っていましたが、今はAlmaLinuxですかね、やっぱり。
（今回は8.10と9.6を使用します）
1-1. インストール時
基本的にポチポチするだけなので、今回は省略。
（さあ、この判断が吉と出るか凶と出るかは、未来の自分のみぞ知る）
2. AlmaLinuxを設定しよう
2-1. AlmaLinuxバージョン確認
さあ、まずはインストールされているバージョンを確認してみましょう。
$ cat /etc/almalinux-release
AlmaLinux release 8.10 (Cerulean Leopard)
AlmaLinux 9.6の場合は、こんな感じです。
$ cat /etc/almalinux-release
AlmaLinux release 9.6 (Sage Margay)
2-2. IPアドレスの確認
TeraTerm等でリモート接続するので、まずはIPアドレスを確認しましょう。
$ ip addr show | grep inet | grep -v inet6
inet 127.0.0.1/8 scope host lo
inet 172.27.32.121/20 brd 172.27.47.255 scope global dynamic noprefixroute eth0
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
外部接続用は"eth0"なので、今回のIPアドレスは"172.27.32.121"ですね。
これがあれば、TeraTerm等から接続できますね。
2-3. ホスト名の変更
次にホスト名を変更しましょう。
（インストール時に変更しとけよ、と思いつつ…）
まず、ホスト名の確認です。
$ hostnamectl status
Static hostname: localhost.localdomain
Transient hostname: linux.local
Icon name: computer-vm
Chassis: vm
Machine ID: ebca3a09b35b49598fe01b5237167dd7
Boot ID: 090293c47d57491897a8a591acbe477e
Virtualization: microsoft
Operating System: AlmaLinux 8.10 (Cerulean Leopard)
CPE OS Name: cpe:/o:almalinux:almalinux:8::baseos
Kernel: Linux 4.18.0-553.el8_10.x86_64
Architecture: x86-64
Static hostnameが"現在のホスト名"。
では、ホスト名を変更しましょう。今回はホスト名を"alma8"に変更します。
$ sudo hostnamectl set-hostname alma8
では、ホスト名が変更されたかどうか、確認しましょう。
$ hostnamectl status
Static hostname: alma8
Icon name: computer-vm
Chassis: vm
Machine ID: ebca3a09b35b49598fe01b5237167dd7
Boot ID: 090293c47d57491897a8a591acbe477e
Virtualization: microsoft
Operating System: AlmaLinux 8.10 (Cerulean Leopard)
CPE OS Name: cpe:/o:almalinux:almalinux:8::baseos
Kernel: Linux 4.18.0-553.el8_10.x86_64
Architecture: x86-64
きちんとホスト名が"alma8"に変更されていることが確認できました。
ちなみに別の環境だと、こんな感じになります。
$ hostnamectl status
Static hostname: unyo
Icon name: computer-vm
Chassis: vm
Machine ID: 2f7f65b4e3464fa48d6d84295c2428fb
Boot ID: 96f9b5762da949b09b717847108ed0b5
Virtualization: vmware
Operating System: AlmaLinux 9.6 (Sage Margay)
CPE OS Name: cpe:/o:almalinux:almalinux:9::baseos
Kernel: Linux 5.14.0-570.12.1.el9_6.x86_64
Architecture: x86-64
Hardware Vendor: VMware, Inc.
Hardware Model: VMware Virtual Platform
Firmware Version: 6.00
こちらはVMware Workstation Pro上の仮想マシン、先ほどのはHyper-V上の仮想マシンです。
同じような仮想環境でも、情報量が異なるのは面白いですね。
さて、ついでに/etc/hostsも確認します。
$ cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
はい、旧ホスト名が残ってますね…
修正しましょう（どんな手を使ってもいいですが、私はviで）。
$ sudo vi /etc/hosts
いい感じで編集します。
さて、きちんと変更されたか確認しましょう。
$ cat /etc/hosts
127.0.0.1 localhost alma8
#::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
いったんIPv6は使用しないので、コメントアウトで。
2-4. SELinux
さて、次にSELinuxの設定確認です。
古のシステムエンジニアは、必ずと言っていいほどSELinuxに苦しめられています（苦しめられたことがない人は、とても幸せなSE生活を送ってますね）。
セキュリティ的には優秀なやつなんですが、検証のときは、ね…
有効無効を確認せずに検証すると、残業時間が増えますので、確認方法を覚えておきましょう。
- SELinux設定の確認
$ sestatus
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: enforcing
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Memory protection checking: actual (secure)
Max kernel policy version: 33
"enabled"になっていますね、アブナイアブナイ…
とりあえず無効にしましょう。
sudo vi /etc/selinux/config
SELINUX=enforcing になっている行を
SELINUX=disabled に変更します。
保存して、再起動
$ sudo reboot
OS起動後にSELinux設定を確認します。
$ sestatus
SELinux status: disabled
無効化されました、これで一安心。
なお、ログは残すけど実際にはブロックしない"Permissive"という設定にすることもできます。
その場合、SELINUX=permissive に設定します。
アプリ等の動作確認をしたい場合は、この設定が便利ですね。
2-5. Secure Boot
さて、LinuxにはSecure Boot設定というものもあります。
（まあ実は、Windowsにもあったりします）
こやつはこやつで、いろいろしでかしますので、設定確認は必須です。
（いや、セキュリティ的にはいいやつなんですよ、でも検証環境だと…）
- Secure Boot設定の確認
$ mokutil --sb-state
SecureBoot enabled
Ohhh...有効化されてますね…
この設定、残念ながらコマンドでOFFにできる類のものではないので、OFFにしたい場合はご注意ください。
ハードウェア設定や、各仮想環境の設定をご確認ください。
また、一部環境（某仮想環境やクラウド）では、そもそもSecure Bootを使えない場合もあります。
ちなみに今回Qiita用の環境構築には、わざわざHyper-Vを使用しております。マッチポンプですね。
（VMware Workstation ProはSecure Boot未対応のため、環境を作れませんでした）
なお、Secure Bootがサポートされていない環境（VMware Workstation Proなど）でmokutilを実行すると…
# mokutil --sb-state
bash: mokutil: コマンドが見つかりませんでした...
コマンド mokutil' を提供するためにパッケージ 'mokutil' をインストールしますか? [N/y]
そもそもコマンドがインストールされていないようです。
試しに、インストールしてみると…
コマンド mokutil' を提供するためにパッケージ 'mokutil' をインストールしますか? [N/y]y
* キューで待機中...
* パッケージの一覧をロード中。...
以下のパッケージはインストールされるべきものです:
efivar-libs-38-3.el9.x86_64 Library to manage UEFI variables
mokutil-2:0.6.0-4.el9.x86_64 Tool to manage UEFI Secure Boot MoK Keys
変更したまま継続しますか？ [N/y] y
* キューで待機中...
* 認証を待ち受け中...
* キューで待機中...
* パッケージの一覧をロード中。...
* パッケージをダウンロード中...
* データを要求中...
* 変更をテスト中...
* パッケージのインストール中...
EFI variables are not supported on this system
という感じで、インストールできませんでした…
ある環境ではできることが、別の環境ではできないってやつですね。
（こういうささやかな情報が、詳細設計や要件ヒアリングにじみーに効いてきます…が、それはまた別のお話）
2-6. ファイアウォール
さて、お次はファイアウォールです。
AlmaLinuxではfirewalldを利用しています。
- ステータス確認
$ systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; preset>
Active: active (running) since Wed 2025-10-08 16:17:28 JST; 42s ago
Docs: man:firewalld(1)
Main PID: 851 (firewalld)
Tasks: 2 (limit: 22768)
Memory: 40.6M
CPU: 457ms
CGroup: /system.slice/firewalld.service
mq851 /usr/bin/python3 -s /usr/sbin/firewalld --nofork --nopid
10月 18 08:17:28 unyo systemd[1]: Starting firewalld - dynamic firewall daemon.>
10月 18 08:17:28 unyo systemd[1]: Started firewalld - dynamic firewall daemon.
Active欄を確認すると、"active(running)"となっているため、稼働していることがわかります。
なお、起動/停止は次の通りです。
- 起動
$ sudo systemctl start firewalld
- 停止
$ sudo systemctl stop firewalld
- バージョン確認
続いて、バージョンを確認してみましょう。
$ sudo firewall-cmd --version
1.3.4
バージョン番号だけ表示してくれます、シンプルですね。
なお、パッケージ情報からバージョンを確認することもできます。
$ rpm -qa | grep firewalld
firewalld-filesystem-1.3.4-9.el9_5.noarch
firewalld-1.3.4-9.el9_5.noarch
- ネットワークインターフェースと、ゾーンと、サービスの関係の話
さて、firewalldを設定する際に必要な知識として、ネットワークインターフェース/ゾーン/サービスがあります。
ネットワークインターフェースは、説明不要ですね？
サーバ等が、他のサーバ等と通信するための出入り口となるものです。
（逆に、こういう用語を簡単に説明するのが難しかったりしますね…精進せねば…）
ネットワークの基礎的なことは「3分間NetWorking」を見てください。
本もあります（私も持ってます）。
※改めて発行日付を見たら、結構昔の本ですね…最近はもっと良い本があるのかしら？
さて、お次はゾーンです。
ゾーンは、ファイアウォールで制御したい内容を取りまとめたものです。
公式ドキュメントでは「trust level（信頼レベル）」と表現しています。
そのため、信頼度に応じて、複数ゾーンを定義することになります（例えば「機密ゾーン」「社内ゾーン」「公共ゾーン」など）。
最後に、サービスです。
サービスは、ファイアウォールによる具体的なアクセス制御の定義です。
例えば、httpsによる通信を許可するとか、ftpによる通信を拒否するとか、です。
ネットワークインターフェース/ゾーン/サービスの関係は、次の通りです。
インターフェースは、1つのゾーンにのみ所属できます（複数ゾーンには所属できません）。
ゾーンは、1つのインターフェースを持つこともできますし、複数インターフェースを持つこともできます。
ゾーンは、1つのサービスを持つこともできますし、複数サービスを持つこともできます。
サービスは、1つのゾーンに紐づけることもできますし、複数ゾーンに紐づけることもできます。
では、firewalldの設定を確認してみましょう。
- （アクティブ）ゾーンの確認
$ firewall-cmd --get-active-zones
public
interfaces: ens160
この環境では、「public」ゾーンのみアクティブです。
紐づいているネットワークインターフェースは「ens160」ですね。
「アクティブ」とは、有効になっているという意味です。
逆に、無効になっているゾーンも存在します。
調べ方は次の通りです。
- すべての（アクティブ/インアクティブ含む）ゾーンの確認
$ sudo firewall-cmd --list-all-zones
block
target: %%REJECT%%
icmp-block-inversion: no
interfaces:
sources:
services:
ports:
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
dmz
target: default
icmp-block-inversion: no
interfaces:
sources:
services: ssh
ports:
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
（略）
いっぱい表示されるので、ここでは省略します（ご自身の環境がある場合は、確認してみてください）。
※コマンドが微妙に違うんですよね、getとlist…
- 特定ゾーンの詳細設定確認
それでは、特定ゾーンの詳細を確認していましょう。
今回は「public」ゾーンの詳細を確認します。
$ sudo firewall-cmd --zone=public --list-all
public (active)
target: default
icmp-block-inversion: no
interfaces: ens160
sources:
services: cockpit dhcpv6-client ssh
ports:
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
色々ありますが、上から順にみていきましょう。
まず「target」です。これはルールに該当しないものをどう扱うかを決めるものです。
「default」の場合、「明示的に許可したもの以外は拒否する」となります。
firewallとしては一般的な考え方ですね。
「icmp-block-inversion」は、ICMP通信をどう扱うか決めるものです。
「icmp-blocks」とセットで使用するので、後ほどまとめて説明します。
「sources」は、特定のIPアドレス/ネットワーク範囲からの通信をどう扱うか決めるものです。
明示的に許可したいものを追加します。
「services」は、サービスによる通信をどう扱うか決めるものです。
具体的なサービスは/usr/lib/firewalld/servives/以下にXML形式で定義されています。
今回は「cockpit dhcpv6-client ssh」となっているので、3つのサービスによる通信が許可されています。
※実際によく使うのは、sshですね。
具体的に定義内容を見てみましょう。
$ cat /usr/lib/firewalld/services/ssh.xml
<?xml version="1.0" encoding="utf-8"?>
<service>
<short>SSH</short>
<description>Secure Shell (SSH) is a protocol for logging into and executing commands on remote machines. It provides secure encrypted communications. If you plan on accessing your machine remotely via SSH over a firewalled interface, enable this option. You need the openssh-server package installed for this option to be useful.</description>
<port protocol="tcp" port="22"/>
</service>
SSHというサービスが、プロトコル=TCP、ポート=22で定義されていますね。
※気になる方は他のサービスがどういう定義なのか、調べてみてくださいね。
「ports」は、特定ポートによる通信をどう扱うか決めるものです。
主にサービスとして定義されていないポートが対象となります。
「protocols」は、特定プロトコルによる通信をどう扱うか決めるものです。
特定プロトコルだけまるっと許可したい、という用途にぴったりです。
「forward」は、パケット転送をどう扱うか決めるものです。
「yes」の場合、「転送を許可する」となります。
※この環境では「no」でよい気がしますね（パケット転送しないので）。
「masquerade」は、マスカレードをどう扱うか決めるものです。
パケット転送に似ている機能ですが、IPアドレスを書き換える点が異なります。
「no」の場合、「マスカレードを許可しない」となります。
マスカレードは、内部のIPアドレスを持っている通信を外部に転送する場合、必要になります。
これは、内部IPアドレスのまま外部に送ってしまうと、戻りの通信先が無くなってしまう（外部から内部IPアドレスには通信できない）ためです。
※内部IPアドレスは、192.168.0.xみたいなプライベートIPアドレスのことです。
「forward-ports」は、特定ポートの通信を別のポート番号に変更するか決めるものです。
「forward」「masquerade」を使っている場合は、設定が必要ですね。
「source-ports」は、送信元の特定ポートによる通信をどう扱うか決めるものです。
※送信先ポートの場合は「ports」で設定します。
「icmp-blocks」は、特定のICMP通信をどう扱うか決めるものです。
ややこしいのは、前述の「icmp-block-inversion」次第で動きが変わります。
例えば、「icmp-block-inversion: no」の場合、「icmp-blocks」で指定したICMP通信を拒否します（指定したもの以外は許可）。
逆に、「icmp-block-inversion: yes」の場合、「icmp-blocks」で指定したICMP通信を許可します（指定したもの以外は拒否）。
「rich rules」は、特定ルールに基づく通信をどう扱うか決めるものです。
今まで紹介した単純なルールだけでは制御しにくい場合に使用します。
※これが使いこなせると、立派なfirewalld使いですが、運用を考えるとルールはシンプルにしておきたいですね
さて、具体的な設定方法ですが、次の「2-7. Syslogサーバ」の中で紹介していきます。
2-7. Syslogサーバ
さて、次はSyslogサーバです。
検証するときに、ログを確認したい場面は多々あると思います。
サーバのローカル環境でファイルに保存するのもありですが、集約管理も魅力的ですよね。
今回は、Syslogサーバを立てて、他のサーバからのログを受け付ける前提で進めます。
- パッケージの確認（インストール済みかどうか）
$ rpm -q rsyslog
rsyslog-8.2412.0-1.el9.x86_64
- ステータス確認
$ systemctl status rsyslog
● rsyslog.service - System Logging Service
Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; >
Active: active (running) since Thu 2025-10-16 09:14:13 JST; 12min >
Docs: man:rsyslogd(8)
https://www.rsyslog.com/doc/
Main PID: 1105 (rsyslogd)
Tasks: 3 (limit: 22768)
Memory: 3.0M
CPU: 154ms
CGroup: /system.slice/rsyslog.service
mq1105 /usr/sbin/rsyslogd -n
10月 18 09:14:13 unyo systemd[1]: Starting System Logging Service...
10月 18 09:14:13 unyo rsyslogd[1105]: [origin software="rsyslogd" swVer>
10月 18 09:14:13 unyo systemd[1]: Started System Logging Service.
10月 18 09:14:13 unyo rsyslogd[1105]: imjournal: journal files changed,>
Active欄を確認すると、"active(running)"となっているため、稼働していることがわかります。
- 設定
いろいろ設定変更が必要です。
- 受信の許可
- ログの保存先
それでは、順番に見ていきましょう。
- 受信の許可
リモートからのログを受信できるようにします。
ここでは514/UDPと514/TCPを受信できるようにします。
rsyslogのメイン設定ファイルは/etc/rsyslog.confですが、
追加設定は/etc/rsyslog.d/以下に.confファイルを置いていきます。
（これはrsyslog.confに「include(file="/etc/rsyslog.d/*.conf" mode="optional")」という設定があるためです）
設定ファイルは/etc/rsyslog.d/10-accept.confとします。
ファイルの内容は次の通りです。
# Enable UDP 514
module(load="imudp")
input(type="imudp" port="514")
# Enable TCP 514
module(load="imtcp")
input(type="imtcp" port="514")
- ログの保存先
次に、リモートから受信したログをファイルに保存します。
設定ファイルは/etc/rsyslog.d/20-save.confとします。
ファイルの内容は次の通りです。
template(name="RemoteLogs" type="string"
string="/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log")
*.* ?RemoteLogs
& stop
string="/var/log/～"の部分が、ログの保存先になります。
この会の例では接続元ホスト名毎にディレクトリを、
プログラム毎にファイルを分けています（が、この辺りは皆さんの自由です）。
.の部分が、ログの記録内容となります。
最初のの部分は、facilityです。
次のの部分が、priorityです。
今回の例では全部取得することにしていますが、実際は要件に合わせて設定してください。
（検証段階ではpriorityはこのままでもいいですが、実運用だとerror以上が多いかと）
- ファイアウォール設定変更
さて、次はfirewalldの設定変更です（「2-6. ファイアウォール」で先送りにしたやつです）。
今は514/UDPと514/TCPの通信を遮断している（許可していない）設定になっているため、これを変更します。
$ sudo firewall-cmd --add-port=514/udp --permanent
$ sudo firewall-cmd --add-port=514/tcp --permanent
設定追加が成功すると、「success」と表示されます。
次に、追加した設定を読み込ませます。
$ sudo firewall-cmd --reload
success
- Syslogサーバ設定チェック
さて、追加設定したconfファイルの構文（設定）が正しいか、チェックします。
$ sudo rsyslogd -N1
rsyslogd: version 8.2412.0-1.el9, config validation run (level 1), master config /etc/rsyslog.conf
rsyslogd: End of config validation run. Bye.
特にエラーもないため、大丈夫そうですね。
- Syslogサーバ再起動
では、再起動です。
$ sudo systemctl restart rsyslog
状態を確認しましょう。
$ sudo systemctl status rsyslog
● rsyslog.service - System Logging Service
Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; >
Active: active (running) since Thu 2025-10-16 15:04:44 JST; 26s ago
Docs: man:rsyslogd(8)
https://www.rsyslog.com/doc/
Main PID: 3178 (rsyslogd)
Tasks: 9 (limit: 22768)
Memory: 3.5M
CPU: 18ms
CGroup: /system.slice/rsyslog.service
mq3178 /usr/sbin/rsyslogd -n
10月 18 15:04:44 unyo systemd[1]: Starting System Logging Service...
10月 18 15:04:44 unyo rsyslogd[3178]: warning during parsing file /etc/>
10月 18 15:04:44 unyo rsyslogd[3178]: [origin software="rsyslogd" swVer>
10月 18 15:04:44 unyo systemd[1]: Started System Logging Service.
10月 18 15:04:44 unyo rsyslogd[3178]: imjournal: journal files changed,>
問題なさそうです。よしよし。
- ポート起動確認
それでは、514/UDPと514/TCPのポートが起動しているかどうか、確認しましょう。
$ sudo ss -lntup | grep 514
udp UNCONN 0 0 0.0.0.0:514 0.0.0.0:* users:(("rsyslogd",pid=3178,fd=4))
udp UNCONN 0 0 [::]:514 [::]:* users:(("rsyslogd",pid=3178,fd=5))
tcp LISTEN 0 25 0.0.0.0:514 0.0.0.0:* users:(("rsyslogd",pid=3178,fd=6))
tcp LISTEN 0 25 [::]:514 [::]:* users:(("rsyslogd",pid=3178,fd=7))
514/UDPと514/TCPが起動していて、かつプロセス名が「rsyslogd」になっています。
問題なさそうですね。
- ログ記録確認
それでは、実際に他のサーバから、Syslogサーバにログ転送できるかどうか確認してみましょう。
今回構築したサーバとは別のサーバ（Linux）にログインし、loggerコマンドで次のようにログを送信します。
$ logger -n <SyslogサーバIPアドレス> -P 514 -d "Syslog test from A-Server to Syslog-Server."
ここで＜SyslogサーバIPアドレス＞には、先ほどまで構築/設定していたSyslogサーバのIPアドレスを入力します。
さて、今度はSyslogサーバにログインし、ログを確認しましょう。
ログファイルは/var/log/remote/<ホスト名>/<プログラム名>.logです。
$ cat /var/log/remote/<ホスト名>/<プログラム名>.log
Oct 18 15:39:36 <ホスト名> <プログラム名> Syslog test form A-Server to Syslog-Server.
いい感じでログが記録されていますね、成功です！
（運用を考慮すると、ログのローテーションは別途考えないといけないのですが、これはまたの機会に）
2-8. SNMP Trap受信サーバ（SNMP Trap Receiver）
さて、お次はSNMP Trapの受信です。
（SNMP全般だと、正直それだけで１冊本が書けるレベルなので、今回はSNMP Trapの話に絞ります）
※ちなみに「私が」本が書けるとは言っていませんので、そのあたりはお察しください！
SNMP Trapは、ネットワーク機器やハードウェアアプライアンス等が自身の異常等を通知する仕組みです。
（SNMP=Simple Network Management Protocol）
このSNMP Trapを受け取るのがSNMP Trap受信サーバ（SNMP Trap Receiver）です。
ネットワーク機器やハードウェアアプライアンスを取り扱う場合、SNMP Trapを受信できる環境があった方が、検証が捗ります。
というわけで、SNMP Trap受信サーバ（SNMP Trap Receiver）を構築してみましょう。
- インストール有無確認
では最初に、必要なパッケージがインストールされているか、確認しましょう。
$ rpm -qa | grep net-snmp
net-snmp-libs-5.9.1-17.el9.x86_64
ライブラリはインストール済みですが、SNMP本体や関連ツールはインストールされていないようです。
- インストール
それでは、インストールしましょう。
$ sudo dnf install net-snmp net-snmp-utils -y
（長いので、省略）
インストール済み:
lm_sensors-libs-3.6.0-10.el9.x86_64 mariadb-connector-c-3.2.6-1.el9_0.x86_64
mariadb-connector-c-config-3.2.6-1.el9_0.noarch net-snmp-1:5.9.1-17.el9.x86_64
net-snmp-agent-libs-1:5.9.1-17.el9.x86_64 net-snmp-utils-1:5.9.1-17.el9.x86_64
perl-File-Copy-2.34-481.1.el9_6.noarch perl-Term-ReadLine-1.17-481.1.el9_6.noarch
完了しました!
- インストール後の確認
$ rpm -qa | grep net-snmp
net-snmp-libs-5.9.1-17.el9.x86_64
net-snmp-agent-libs-5.9.1-17.el9.x86_64
net-snmp-5.9.1-17.el9.x86_64
net-snmp-utils-5.9.1-17.el9.x86_64
- SNMP Trap受信設定
では、SNMP Trapを受信するために必要な設定をしていきましょう。
対象となるファイルは/etc/snmp/snmptrapd.confです。
既にファイルがある場合は、編集するので事前バックアップを取っておきましょう。
$ sudo cp -p /etc/snmp/snmptrapd.conf /etc/snmp/snmptrapd.conf.bak
snmptrapd.confに記載する内容は次の通りです。
authCommunity log,execute,net public
logOption f /var/log/snmptrapd.log
１行目はSNMP Trapを受信する際の設定です。
決まり文句のauthCommunityに続けて、SNMP Trap受信設定（log,execute,net）、コミュニティ名（public）を定義します。
SNMP Trap受信設定の部分は、SNMP Trapに対して許可する権限を設定します。
logは、ログに記録することを許可
executeは、スクリプトの実行を許可
netは、ネットワーク経由のSNMP Trapを受信することを許可
という意味になります。
最後のコミュニティ名は、送受信の両方で一致させる必要がある文字列です。publicは有名なコミュニティ名で、主に検証用途で使用します。
２行目はログの追加設定です。
「f」は、ファイル出力という意味になります。出力先のファイル名を指定します（今回の場合は/var/log/snmptrapd.log）。
- SNMP Trap受信サーバ設定チェック
それでは次に、設定があっているか（構文として問題ないか）確認しましょう。
$ sudo snmptrapd -f -Lo -n -d
NET-SNMP version 5.9.1
エラーが出なければ問題ありません。なお、プロンプトが返ってきませんので、Ctrl + Cを使いましょう。
- サービス起動確認
次はサービス起動確認です。
まず、サービスの状態を確認しましょう。
$ sudo systemctl status snmptrapd
○ snmptrapd.service - Simple Network Management Protocol (SNMP) Trap Daemon.
Loaded: loaded (/usr/lib/systemd/system/snmptrapd.service; disabled; preset: disabled)
Active: inactive (dead)
inactiveですね。
まあ、先ほどインストールしたばかりなので、当然と言えば当然ですね。
それでは、起動していきましょう。
$ sudo systemctl enable --now snmptrapd
Created symlink /etc/systemd/system/multi-user.target.wants/snmptrapd.service → /usr/lib/systemd/system/snmptrapd.service.
自動的にリンクが作成されましたね。
なお、--nowは、同時に起動もしてくれる便利な引数です。
覚えておきたいですね！
では、状態を確認しましょう。
$ sudo systemctl status snmptrapd
● snmptrapd.service - Simple Network Management Protocol (SNMP) Trap Daemon.
Loaded: loaded (/usr/lib/systemd/system/snmptrapd.service; enabled; preset: disabled)
Active: active (running) since Mon 2025-10-19 15:58:53 JST; 6min ago
Main PID: 34240 (snmptrapd)
Tasks: 1 (limit: 22768)
Memory: 2.3M
CPU: 26ms
CGroup: /system.slice/snmptrapd.service
mq34240 /usr/sbin/snmptrapd -Lsd -f
10月 19 15:58:53 unyo systemd[1]: Starting Simple Network Management Protocol (SNMP) Trap Dae>
10月 19 15:58:53 unyo snmptrapd[34240]: NET-SNMP version 5.9.1
10月 19 15:58:53 unyo systemd[1]: Started Simple Network Management Protocol (SNMP) Trap Daem>
Active: active (running)になっていますね。問題なしです。
- ポート起動確認
それでは、ポートが起動しているかどうか、確認しましょう。
$ sudo ss -lntup | grep 162
udp UNCONN 0 0 0.0.0.0:162 0.0.0.0:* users:(("snmptrapd",pid=34240,fd=7))
ポートも問題ないですね。
- ファイアウォール設定
ファイアウォールの設定も変更しましょう。
SNMP Trapは162/UDPを使用します。
$ sudo firewall-cmd --add-port=162/udp --permanent
success
追加した設定を読み込ませます。
$ sudo firewall-cmd --reload
success
- SNMP Trapテスト
それではSNMP Trapを試しに飛ばしてみましょう。
今回は、同じサーバ間で試します。
$ snmptrap -v2c -c public localhost '' NET-SNMP-EXAMPLES-MIB::netSnmpExampleHeartbeatNotification
上記は、SNMP Trapを送る時の一例です。
では、Trap受信できているか、確認しましょう。
$ sudo journalctl -u snmptrapd -n 5 --no-pager
10月 19 17:57:37 unyo systemd[1]: Stopped Simple Network Management Protocol (SNMP) Trap Daemon..
10月 19 17:58:04 unyo systemd[1]: Starting Simple Network Management Protocol (SNMP) Trap Daemon....
10月 19 17:58:04 unyo snmptrapd[34848]: NET-SNMP version 5.9.1
10月 19 17:58:04 unyo systemd[1]: Started Simple Network Management Protocol (SNMP) Trap Daemon..
10月 19 17:58:42 unyo snmptrapd[34848]: 2025-10-20 17:58:42 localhost [UDP: [127.0.0.1]:44936->[127.0.0.1]:162]:
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (2754205) 7:39:02.05 SNMPv2-MIB::snmpTrapOID.0 = OID: NET-SNMP-EXAMPLES-MIB::netSnmpExampleHeartbeatNotification
最後の行にきちんと表示されていますね。成功です。
念のため、別のサーバからもSNMP Trapを送ってみましょう。
別のサーバにログインし、次のコマンドを実行します。
$ snmptrap -v2c -c public ＜SNMP Trap受信サーバのIPアドレス＞ '' NET-SNMP-EXAMPLES-MIB
::netSnmpExampleHeartbeatNotification
さて、元のサーバに戻り、次のコマンドを実行します。
$ sudo journalctl -u snmptrapd -n 1 --no-pager
10月 19 18:27:16 unyo snmptrapd[34848]: 2025-10-19 18:27:16 unyo [UDP: [192.168.92.134]:44196->[192.168.92.134]:162]:
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (2925538) 8:07:35.38 SNMPv2-MIB::snmpTrapOID.0 = OID: NET-SNMP-EXAMPLES-MIB::netSnmpExampleHeartbeatNotification
※「192.168.92.134」は、私が構築したSNMP Trap受信サーバのIPアドレスです
※「unyo」は、私が構築したSNMP Trap受信サーバのホスト名です
よかった、こちらも問題なさそうです。
9. まとめ
今回は、Linuxサーバの構築に必要な基本設定と、ファイアウォール、Syslog、SNMP Trapについてまとめてみました。
私が最近使ったものにフォーカスしたため、皆さんには物足りない内容になっているかもしれませんが、これをベースに自分で調べて、構築して、試行錯誤してもらえればよいかなと思っています。
9-1. 先送り
今回、先送りにしたもの（今後記載したいもの）は次の通りです。
- SNMP（今回紹介したSNMP Trap以外の部分）
- メール
- それぞれの仕組みの通信の強化（UDP→TCPとか、暗号化とか）
この辺り、いずれ記事にできればと思っています。
90. おわりに
90-1. それでもシステムエンジニアを名乗りたい自分へ
生成AIの脅威に怯えつつ、この記事を書いています。
以前は調べ物をするときはGoogle検索（ググる）が中心だった私ですが、
最近はもっぱら生成AIと壁打ちです。
（ChatGPT課金勢です）
アバウトな問い合わせに対しても答えてくれるし、
昔の知識しか持っていない私にも、最新情報を教えてくれます。
あと、何回同じような質問をしても、嫌がらずに/めんどくさがらずに答えてくれるところ。徳の高い僧侶と対話している感じ。
※個人の見解です
正直、私のような古のシステムエンジニアこそ生成AIを活用するべきだと感じています。
生涯現役！
えるしっているか、さいきんのしすてむえんじにあは、ifconfig/netstatをつかわない
※ifconfig → ip addr show
※netstat → ss
97. 参考文献
98. 更新履歴
- 2025.10.27 初版