⇧ 創造性を発揮できるとは言うものの、感覚が人それぞれで異なるから、何をもって高品質と見なすのか難しいですな...
稼働していたVerticaのPIDがfirewalld.serviceの起動でkillされたのですが...
ポート番号を開放するために、firewalldのコマンドで
firewall-cmd --list-all
したところ、
FirewallD is not running
⇧ と表示されて、firewalldのサービスが止まってるんだ、じゃあ、furewalldのサービスを開始して...と脊髄反射的に、
systemctl start firewalld.service
systemctl status firewalld
⇧ を実行してしまった後に、ふと、firewalldのサービスを開始して良いのか気になって、有識者の方に確認したところ、ポート番号の開放とか不要ということが分かって、
systemctl stop firewalld.service
systemctl stop firewalld.service
⇧ firewalldのサービスを停止したのだけど、見事に、稼働していたPID（Process ID）が無くなっていたということに気付くまでに時間がかかったというね...
そうです、いつの間にかVerticaのPID（Process ID）がお亡くなりになったんですよ...
いや、まさか、firewalldのサービスを起動したら、死ぬ仕様なんて流石に想定してないというか...
1つ目のアプリケーション構築作業だったので、他のアプリケーションへの影響が無いというのが不幸中の幸いと言うべきか...
よく分からないのが、
⇧ Verticaに必要なポート番号の一覧があって、おそらく、firewalldのサービスを停止する前に、ポート番号の開放を行ってから、firewalldのサービスを停止したと思うんよね、推測になってしまうのだけど。
で、
Vertica requires multiple ports be open between nodes. You may use a firewall (IP Tables) on Redhat/CentOS and Ubuntu/Debian based systems. Note that firewall use is not supported on SuSE systems and that SuSE systems must disable the firewall. The installer reports issues found with your IP tables configuration with the identifiers N0010 for (systems that use IP Tables) and N011 (for SuSE systems).
⇧ とあり、RedHat/CentOSは、firewallが使えるっぽい書きっぷりなんよね...
firewalldのデフォルトの「public」ゾーンの仕様はPIDをKIllするっぽい？
ネットの情報を漁っていて、
■注意事項
稼働中(提供中)のサーバでFirewalldサービスを起動すると「public」ゾーンとなり
提供していたサービスが利用できなくなるので注意してください。
この場合は、「trusted」ゾーン設定をして、拒否するポリシーを設定するように
すると安全にFirewalldサービスを起動することができます。
⇧ 上記サイト様によりますと、なるほど、問答無用で稼働していたPIDがkillされたってことなんかな...
Red Hatの公開しているドキュメントによると、
firewalld は、D-Bus インターフェイスを使用して動的にカスタマイズ可能なホストベースのファイアウォールを提供するファイアウォールサービスデーモンです。ルールが変更するたびに、ファイアウォールデーモンを再起動しなくても、ルールの作成、変更、および削除を動的に可能にします。
サービスは、ネットワーク接続に 1 つ以上の ポート または アドレス を使用します。ファイアウォールは、ポートに基づいて接続のフィルターを設定します。サービスに対してネットワークトラフィックを許可するには、そのポートを 開く 必要があります。firewalld は、明示的に開いていないポートのトラフィックをすべてブロックします。trusted などのゾーンでは、デフォルトですべてのトラフィックを許可します。
⇧ 上図のような仕組みらしいんだけど、
⇧ firewalldが最終的にPIDに与える影響が分からん...
WikipediaのNetfilterの説明で、
⇧ Netfilterのパケットのフローが載ってますと。
firewalldが有効になった場合、明示的に開放していないポート番号のトラフィックがブロックされるのは分かったのだけど、その際に、それまで存在していたPIDがどう処理されてるのかが分からんのよね...
ネットの情報だと、
Architecture of the standard Linux kernel.
⇧ 上図が、標準的なLinuxのアーキテクチャということらしいので、最終的に、Linux Kernelが、PIDを処理してると思うんだけど...
ちなみに、
⇧ ドキュメントには、特に、PIDがkillされるような記載は見当たらない...
結局、firewalldの開始とそれまで稼働していたPIDとの関係が分からんのだけど、例の如く、ChatGPTに聞いてみたところ、
firewalldが開始されると、それまで稼働していたPID（プロセスID）に関しては、通常は以下のような手順で終了させられます。
- firewalldの設定: firewalldのpublicゾーンは、コンピュータを信頼できないパブリックエリア向けに設定されます。 デフォルトでは、特定のサービス（例えば、SSHやDHCPv6クライアント）が許可されることがあります。それ以外のトラフィックはブロックされる可能性があります。
- サービスへのアクセスの制限: firewalldがpublicゾーンで設定されている場合、SSHやDHCPv6クライアントなど、許可されたサービスに対するアクセスが許可されます。 それ以外のサービスやポートへのアクセスは、通常はブロックされます。
- 他のプロセスの影響: もし他のプロセスが許可されたサービス（SSHやDHCPv6クライアント）を使用している場合、そのプロセスは正常に動作し続けることが期待されます。 しかし、他のプロセスが許可されていないサービスやポートを使用している場合、そのプロセスが依存している通信がブロックされる可能性があります。 その結果、依存関係にあるプロセスが意味を持たなくなる可能性があります。
- プロセスの終了: ブロックされたトラフィックに依存する他のプロセスが意味を持たなくなった場合、そのプロセスは終了する可能性があります。 プロセスが終了すると、そのプロセスが使用していたリソースが解放され、そのPIDが消えることになります。
⇧ という回答。
う～む、そのプロセスは終了する可能性がありますとか曖昧だなぁ...
結局のところ、PIDがkillされたのかどうかは分からんと...
PIDがsignalで状態を変化させられているという前提が正しいと仮定するならば、
⇧ 上記サイト様にありますように、signalの送信元を特定できれば、どのサービス起因でPIDがkillされたのか把握できるんかな。
そもそも、PIDを消すことができるのが、kill以外にあるのかが分からんのだけど...
firewalldがPIDをkillしたのかどうかは分からんのだけど、何となく、firewalldが機能してるのがデファクトスタンダードだと思い込んでいたのだけど、内部で利用するようなシステムであれば、確かに、firewalldが無くてもセキュリティ的には問題無いということですかね。
稼働してたVerticaのPIDがfirewalld.serviceの起動でkillされたが、VerticaのPIDを再生成したい
で、時を戻すことはできないので、killされてしまったであろうVerticaのPIDはどうすれば再度生成できるのか？
Restarting Vertica on host
This tool restarts the Vertica process on one or more hosts in a running database. Use this tool if the Vertica process stopped or was killed on the host.
https://docs.vertica.com/24.1.x/en/admin/using-admin-tools/admin-tools-reference/restarting-on-host/
⇧ なるほど、ツールが用意されているらしい。
危うく、マシンのrebootしようとしてましたが、
上記のエラーの対処後、データベースプロセスを起動します。$ /opt/vertica/bin/admintools -t start_db –d <databasename>
⇧ まずは、「/opt/vertica/bin/admintools」コマンドを実行しろということだとは思うのですが、Verticaのプロセスが全て落ちてる中で「<databasename>」ってどうやって確認すれば良いんですかね？
公開されてる情報に例外が無いなら、
b. VerticaログとdbLog$ /home/dbadmin/<databasename>/<nodename>_catalog/
$ /home/dbadmin/<databasename>
⇧ 上記のディレクトリの名前が「<databasename>」になっているということで、ディレクトリの名前を確認すれば良いとは思うのだけど、結構、ドキュメント通りになってないことがあるあるだから、いまいち信用できぬ...
ネットの情報で幾度となく騙されてきたから（特にOracle Databaseとか）、本当に信じて良いのか分からんのよね...
ちなみに、上記のツールでVerticaのPIDが再生成できない場合は、
⇧『Verticaテクニカルサポートまでお問い合わせください』ということで運用でカバーされているということみたいですな...
ブラックボックスですな...
とりあえず、迂闊にfirewalldのサービスを起動してはいけないということが知れたのは良いのですが、設定周りは罠が多いですな...
2024年2月5日（月）追記：↓ ここから
firewalldで影響を受けたのは、Dockerもでした...
起動順序の問題でiptablesはDockerデーモンの前に起動しなければならないようで
おそらくDockerデーモンが先に起動されたことでエラーになっていました。
【解決方法】docker networkを作成する際に発生するFailed to Setup IP tables（iptables failed）エラーの対処 | とあるクリエイターのエンジニアブログ
⇧ 上記サイト様にありますように、firewalldを開始・停止したことで、iptablesとDocker deamonの起動順がおかしなことになったと思われる。
firewalld、鬼門過ぎるんだが...
2024年2月5日（月）追記：↑ ここまで
毎度モヤモヤ感が半端ない...
今回はこのへんで。
