CentOS 7システムでPXEブートサーバーを設定するときに奇妙なTFTPの問題が発生しました。タイムアウトの問題が発生しないと、TFTPサーバーはファイルを取得できません。ブートプロセスこれまで、DHCPサーバーからIPアドレスとファイル名を正しく取得しました。ただし、TFTPサーバーから起動ファイルを検索しようとすると、「TFTP open timeout」というメッセージが表示されます。ローカルコンピュータでPXEサーバーへのTFTP接続を手動で設定すると、サーバーにすぐにアクセスできます。ただし、「get pxelinux.0」コマンドを使用しようとすると、別のタイムアウトメッセージが表示されます。ファイアウォールが正しく設定されており、ファイアウォールを完全にオフにしても違いはありません。 SeLinuxも無効になります。ポート69でtcpdumpを実行すると、次のメッセージが表示されます。
12:34:33.477401 IP 172.16.1.202.ah-esp-encap > tools.dmz.tuxme.dk.tftp: 27 RRQ "pxelinux.0" octet tsize 0
12:34:35.481131 IP 172.16.1.202.acp-port > tools.dmz.tuxme.dk.tftp: 27 RRQ "pxelinux.0" octet tsize 0
12:34:39.490793 IP 172.16.1.202.msync > tools.dmz.tuxme.dk.tftp: 27 RRQ "pxelinux.0" octet tsize 0
12:34:45.477712 IP 172.16.1.202.gxs-data-port > tools.dmz.tuxme.dk.tftp: 27 RRQ "pxelinux.0" octet tsize 0
12:34:53.441801 IP 172.16.1.202.vrtl-vmf-sa > tools.dmz.tuxme.dk.tftp: 27 RRQ "pxelinux.0" octet tsize 0
12:35:03.384065 IP 172.16.1.202.newlixengine > tools.dmz.tuxme.dk.tftp: 32 RRQ "pxelinux.0" octet blksize 1456
12:35:39.414843 IP 172.16.1.202.newlixconfig > tools.dmz.tuxme.dk.tftp: 32 RRQ "pxelinux.0" octet blksize 1456
12:36:51.422568 IP 172.16.1.202.tsrmagt > tools.dmz.tuxme.dk.tftp: 32 RRQ "pxelinux.0" octet blksize 1456
12:38:39.406732 IP 172.16.1.202.tpcsrvr > tools.dmz.tuxme.dk.tftp: 32 RRQ "pxelinux.0" octet blksize 1456
残念ながら、システムログに有用な情報は表示されません。
Jan 15 13:13:19 tools xinetd[6993]: EXIT: tftp status=67 pid=7954 duration=0(sec)
Jan 15 13:13:21 tools xinetd[6993]: START: tftp pid=7955 from=172.16.1.202
Jan 15 13:13:21 tools in.tftpd[7955]: no user tftp: Success
Jan 15 13:13:21 tools xinetd[6993]: EXIT: tftp status=67 pid=7955 duration=0(sec)
Jan 15 13:13:25 tools xinetd[6993]: START: tftp pid=7956 from=172.16.1.202
Jan 15 13:13:25 tools in.tftpd[7956]: no user tftp: Success
Jan 15 13:13:25 tools xinetd[6993]: EXIT: tftp status=67 pid=7956 duration=0(sec)
Jan 15 13:13:31 tools xinetd[6993]: START: tftp pid=7957 from=172.16.1.202
Jan 15 13:13:31 tools in.tftpd[7957]: no user tftp: Success
/var/lib/tftpboot ディレクトリの権限は 0755 です。
これは私の設定ファイルです。
/etc/xinetd.d/tftp:
service tftp
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -c -v -u tftp -p -U 117 -s /var/lib/tftpboot
disable = no
per_source = 11
cps = 100 2
flags = IPv4
ベストアンサー1
tcpdump出力には要求のみが含まれ、応答はまったくないようです。実際にこれが発生すると、タイムアウトエラーが発生します。
server_argsxinetdのTFTP設定行には、ユーザーとして実行するように求められます-u tftp。この観点から見ると、録音されたこのメッセージは重要です。in.tftpdtftpin.tftpd
Jan 15 13:13:21 tools in.tftpd[7955]: no user tftp: Success
「ユーザーなし tftp」と表示されます。このtftpユーザーアカウントは実際にシステムに存在しますか？
ログメッセージの最後の内容をSuccess理解するには、Cプログラミングの知識が必要です。これは、呼び出してperror()から終了する前に必要なクリーンアップ操作を実行する最小限のエラー処理関数に由来します。
このperror()関数は呼び出し元からメッセージを取得し、変数の現在の値に対応する標準エラーメッセージを追加しますerrno。これは、以前のシステムコールが失敗した状況で使用するように設計されています。カスタムメッセージは、エラーが発生したときにプログラムが実行していた操作を説明し、標準メッセージは発生した問題の種類を明確にする必要があります。
ただし、プログラマーがエラー処理機能を使用して見つかったエラーを報告すると、標準エラーメッセージの一部が表示されますSuccess。
私の考えでは、in.tftpdプロセスが開始され、xinetdユーザーに切り替える準備ができていて、tftpユーザーが存在しないことがわかったようです。したがって、in.tftpdプロセスはそのログメッセージを出力し、クライアントに何も送信せずに終了します。
最後に「成功」という誤解を招く簡潔なメッセージは、「唯一の道具がハンマーであればすべてを釘で見る傾向がある」という昔の概念の一例である。この場合、プログラマは出力形式が適切でない状況で唯一のエラー処理機能を使用している可能性があります。
また、これらの要求は少し奇妙に見えます。
12:34:33.477401 IP 172.16.1.202.ah-esp-encap > tools.dmz.tuxme.dk.tftp: 27 RRQ "pxelinux.0" octet tsize 0
12:34:35.481131 IP 172.16.1.202.acp-port > tools.dmz.tuxme.dk.tftp: 27 RRQ "pxelinux.0" octet tsize 0
12:34:39.490793 IP 172.16.1.202.msync > tools.dmz.tuxme.dk.tftp: 27 RRQ "pxelinux.0" octet tsize 0
12:34:45.477712 IP 172.16.1.202.gxs-data-port > tools.dmz.tuxme.dk.tftp: 27 RRQ "pxelinux.0" octet tsize 0
12:34:53.441801 IP 172.16.1.202.vrtl-vmf-sa > tools.dmz.tuxme.dk.tftp: 27 RRQ "pxelinux.0" octet tsize 0
tsize 0クライアントが合計ファイルサイズが0バイトのTFTP転送を待っていることを示します。
UEFIバージョン2.3に存在していたUEFI PXE仕様では、DHCPサーバーがロードする必要があるファイルサイズをPXEクライアントに知らせる必要があることをご存知でしたか？ ISC DHCP サーバーを使用している場合は、必須オプションを次のように指定できます。
option boot-size <size value>;
<size value>ブートファイルのサイズ（バイト）を512で割って丸める必要があります。