主様 のすべての投稿

ffmpeg 複数インタフェースカードの対応

複数のNICが搭載されたサーバマシンで、マルチキャストで配信されているストリーミング映像を受信しようとして、ガッツリと嵌りました。

環境

環境は以下の感じです。

マシン環境

OSCentOS 7.7.1908
NIC5枚 (利用したのは2枚だけ)
eth0〜eth5がある状態でeth0とeth1だけ使用。
(「eth?」は環境によって違うので適当に読み替えてください。)

ネットワーク

ネットワーク環境について説明する。
今回の環境では、ネットワーク1とネットワーク2がある。
ネットワーク1は、インターネットなど外部環境と接続している。
ネットワーク2は、マルチキャストで映像配信が行われており、その映像をキャプチャし、映像処理を施した後にネットワーク1側で提供する。

課題になった現象

今回、課題になった現象は、eth0側の通信は出来るのだが、eth1側からffmpegによる映像キャプチャが出来ないという現象が発生した。

色々と調べてみたのだが、eth1側のマルチキャストをルーティングにテーブルに設定することでキャプチャが可能になるように記載があちらこちらで見受けられたのだが、実際にはそれだけではダメだった。

解決策

このままのネットワーク構成でも実現できる可能性はあったが、結局は、eth0側のデフォルトゲートウェイによりマルチキャストの受信を行おうとしいて受信できない状態になっていると理解した。

そこで、eth0とeth1を入れ替えた。

ここでも問題が生じた。
新たにeth0となったネットワーク2側のデフォルトゲートウェイにより、外部との通信が遮断されてしまったのだ。
外部のアドレスは不特定なため、簡単にルーティングテーブルを指定することが困難であると判断し困惑した。

問題は、本来、ネットワーク1側のゲートウェイを介して外部に接続しなければならないのにも関わらず、ネットワーク2側のゲートウェイで捕捉されてしまい、ネットワーク1側に流れないということと判断した。

そこで、ネットワーク2側のデフォルトゲートウェイの設定を削除した。

次に行ったことは、ルーティングテーブルに224.0.0.0/4を登録した。

ここでも嵌った!

ドキュメントでは、/etc/sysconfig/network-script/route-eth0に以下の様に記述する方法があり、ネット上でもその記載方法が記されていた。

T.B.D

しかしながら、その設定ではなく、別の方法による記述が求められた。

ちなみに、ip routeコマンドでルーティングを/etc/rc.localに記載したのだが、起動時にコマンドを実行しても、ルーティングテーブルを確認すると設定が行われていない状況であった。

GUIを用いて、以下のルートを指定した。
<<<<現状はメモ状態なので、近日中に更新予定>>>>

224.0.0.0/4 ゲートウェイは0.0.0.0

これで上手く通信が出来るようになった。

以上でも問題解決が出来た。
ffmpeg自体はNICの指定が出来ないことから、無理やりするには色々と課題があるようだ。
環境を構築して、確認を行うことをお勧めする。

ファイルやディレクトリの変更をトリガーにしてプログラムを起動する。incronがダメなら、inotifyで!

ファイルやディレクトリを監視したい!

ここでも過去に取り上げていますが、incronを用いて任意に指定するファイルやディレクトリの更新を監視することが出来ます。
ところが、incronは何度かバグが発生し、且つ、メンテナンスが遅れ遅れになっていることもあり、利用することを断念しました。

systemdでサポートされているinotifyを利用する手段が次に出てきた訳ですが、当初は情報も少なくて困ったものです(^^ゞ

というところで、CentOS 7上のPython 3で利用できるか確認してみました。

結論としては、Python 2.xと比較して、ほぼデフォルト状態のPython 3で利用することが出来ました。

どんなイベントを監視できるのか?

いろんなイベントを監視できるので、詳細についてはmanで確認できます。

サンプルコード

ここで示すサンプルコードでは、指定したディレクトリ内に含まれるファイルもしくはディレクトリ移動した場合にイベントが発生します。

サンプルコードを以下に記します。

maskにpyinotify.IN_MOVED_TOを指定することで、ファイル/ディレクトリの移動を監視しています。
IN_MOVED_TOをIN_CREATEにすれば、ファイル/ディレクトリが生成されたタイミングでイベントが発生します。
ディレクトリを指定した場合には、対象ディレクトリ以下のサブディレクトリも監視対象となります。
ただし、監視中(プログラム起動後)に新たに設置されたフォルダー内部は監視対象にならないということに注意が必要です。
syslogにログを残す機能も併せて盛り込んでしまいました。

意外と簡単ですよね。

scpでIDとパスワードを自動入力させる方法(expect)。

expectを利用して、sshやscpにおけるIDとパスワードを自動入力させる方法は、いろいろなサイトで公開されています。

今回、この記事を記載した理由は「password:」で止まってしまう現象が発生しました。
多くのサイトで記載されている方法では、この「password:」で止まってしまう現象を回避出来なかったため、その方法を記載します。

実際に使用したコマンドは以下の通りです。

a.txtファイルを127.0.0.1のサーバ(今回は自分自身のサーバ)にあるuserというユーザの/home/userディレクトへコピーしています。

パスワードは「passwd」なのですが、その後ろに「\r」を追加することが肝でした。

これにたどり着くまでが長かった。。。(^^ゞ

でもこれで問題なく解決しました。

環境によって、この「\r」が必要ではない場合もあると思いますが、一応これも方法の一つと考えていただければ幸いです。

FortiGateでポートフォワーディング

セキュリティの観点から、ポートフォワーディングを行いたい時があります。
サーバ側でポートを変更する対策も考えられるところなのですが、イントラ環境ではデフォルトポートで、外部とはポートフォワーディングしたいという時があります。
そういう時は、ルータでポートフォワーディングすることもありますが、今回はUTM(FortiGate)側で対応を行います。

「ポリシー&オブジェクト」→「バーチャルIP」で、バーチャルIPを編集します。

「ポートフォワード」を有効にします。
「Externalサービスポート」に外部からアクセスするポート番号を指定します。
「ポートへマップ」にフォワードする先のポート番号を指定します。

deck.glをCentOSで動かしてみる。

はじめに

野暮用でビックデータを可視化することになってしまい、今迄はOpenLayersをゴリゴリっとしてたのですが、MVT使っても厳しかろうというところから、WebGL関連で可視化を目指すことにしました。

何にしようかと考えていたところ、UBER社が提供しているdeck.glが気になり、チョロッとお試しをdeck.glがベースとなっているkepler.glでやってみたところ、ええ感じで動くじゃないですか!

そんじゃあ、deck.glで実装決定!ということから、まずはdeck.glの環境構築に取りかかりました。

kepler.glについては、何かの機会にお話するとして(某ローカルコミュニティで発表予定)、今回はdeck.glの実装のみのお話を簡単に記録します。

対象サーバはWindowsじゃなく今回もCentOS 7です。
CentOS 8が2〜3日前に公開されたので、そこからCentOS 8で実相も考えたのですが、先の某ローカルコミュニティでの発表が来週に控えているので、既に稼働中のCentOS 7上で実装することにしました。

ちなみに、こんなこと書いていますが、実際にCentOS 7で実装してみて思ったのですが、CentOS 8で実装したとしても何も異る点は無いはずです。
理由は、実相はnode.js上で行うため、node.jsの実装方法自体が変わらない限り変更は無いということです。

参考にさせて頂いたサイトはこちらになります。

https://qiita.com/keijipoon/items/92d9551930fe52d6c90a

そろそろ、この手の記事をQiitaに書いた方が楽なんじゃないか?とか、そっちの方が見てもらえるんじゃないかとか思ってはいるのですが、趣味なんです(^^;

node.jsのインストール

node.jsのインストールは先日こちらの記事に記していますので、そのまんま実装しました。
と言うことで、参照してください。

node.jsを既にインストールされている方は、無視して次の作業を行ってください。

luma.glをインストール

コマンドライン上で以下のコマンドを実行します。

終わりです。

deck.glのインストール

こちらのサイトからダウンロードしてきます。

deck.glのインストールと言っても、取り敢えずダウンロードして、展開するだけです。

https://github.com/uber/deck.gl

適当なフォルダへ解凍します。

サンプルプログラムを動かしてみる。

なんか既にインストール終わっているみたいです。
サンプルプログラムを幾つか試しに動かしてみようと思ったのですが(2分程)、実際に動くのは参考にさせて頂いたサイトでも紹介されていたサンプルだけでした。

ということで、ほぼ同じ感じの内容ですが、以下のフォルダへ移動します。
(解凍したdeck.glの中にあります。)

後は、そのまんま実行するだけ。

終わりです。
環境さえ整っていれば、Windowsで実装するのと何も変わりませんでした。
という結果です。逆に、Linuxの方が楽じゃね?

node.jsをインストールすることから始めます。

今回は、node.jsをインストールすることが目的ではないのですが、この後に書く予定のdeck.glをインストールするために、node.jsをインストールする必要が生じたため、手順を踏んで記録に残すことにしました。

node.jsのリポジトリを登録する。

またしても、CentOS 7上に環境を構築します。
以下のサイトを開いて、最新版を確認します。

https://github.com/nodesource/distributions/tree/master/rpm

執筆時点では、setup_12.xが最新版でした。
最新版をインストールするため、以下のコマンドを実行します。

これで、基本的なインストールは完了です。

実は、過去にnode.jsをインストールしていたマシンだったので、こんなメッセージが表示されました。

「sudo yum remove -y nodejs npm」ということで、削除します。

その後の情報も確認しつつ、node.jsのパッケージをインストールします。

これで完了です。
バージョン確認を実施し、最新版のnode.jsがインストールされていることを確認しましょう。

無事インストールが完了しておりましたので、今回はここまでとなります。
続きは別途。。。

CentOS 8 リリース待ち→リリースされた2019-09-24(^^)

2019年5月7日にRHELがリリースされてからもうすぐ100日が経過しようとしている。

<2019-09-25追記>
現地時間9/24、CentOS 8がリリースされました!
これで使えるようになりますが…問題は、VirtualBoxでGUIを含む状態でインストールする場合には、問題があるようです。
以前(CentOS 7)から気にはなっていたのですが、基地の問題として残っているようです。
仮想マシンとして考えている方で条件が合致される場合は、他の仮想か技術を考えた方が良いかも知れませんね。

意味が違ったようですm(__)m
「Server With a GUI」/「サーバ(GUI)」を選択してインストールするとGUIが立ち上がらない障害がある様です。
詳しくは以下のサイトをご参照下さい。
https://wiki.centos.org/ja/Manuals/ReleaseNotes/CentOS8.1905#head-9ed7a1765d703716a543781d18c13e50868f0516

と言いつつ、読んでみてもよく解らなかったので調べてみることにしたら、こちらの記事が解り易かった。
https://qiita.com/edward999th/items/d199125dbb8286d91152

「ベース環境」の選択で「Server with a GUI」もしくは「サーバー(GUI)」を選択してインストールすると既知の問題に遭遇するらしい。
インストーラのバグか?という感じですが、原因までは調べていません。
「ワークステーション」を選択してインストールする分には問題が無いようなので、GUIを使いたい場合には別の選択肢を関g萎えた方が良さそうですね。

<2019-09-23追記>
なんか、明日(2019-09-24)にリリースされるそうです。
9月に入ってからのダタバタ劇はなんだったのか?踊らされていたのか?
とにかく、現地時間の明日にはリリースされるとのこと、期待して待ちましょう。

※2019-08-26 時点でまだリリースされていません。
※2019-09-15時点でまだリリースされていません。

※2019-09-23時点でまだリリースされていません。

<2019-09-15追記>2019年8月にリリースされたRHELに対応するため、CentOS 7.1909の更新準備が先行されているのですが、wikiを見てみると約1ヶ月くらい掛かるみたいです。10月以降にならないと開発は再開される見込みは無さそうですね。年内にリリースされるのかなぁ?

RHELのクローンとしては、CentOS/Scientific Linux/Oracle Linuxなどが知られているが、以前にCentOSよりリリースが早くて話題となったScientific Linuxは8以降のリリースを行わないとの表明が行われていますね。

単純な比較は難しいところですが、CentOSとOracle Linuxはクローンと言われているけど、Oracle Linuxは少し違いますよね。

Oracle Linux 8は7/18にリリースされました。
CentOSはまだ少し掛かりそうです。

進捗状況は以下のURLで公開されています。

https://wiki.centos.org/About/Building_8

もうカウントダウンですねw

8/15にボストン大学でDevConfが開催されるので、その頃にはRC版が出てくれそうな感じかな?
残念ながら発表はありませんでしたね(^^ゞ

9/10に動きがありました。
7.7がリリースされるそうです。そのため、8の開発が停止してしまいました。
もうすぐ!と思ったら、まだ先になりそうです。
首を長くして待ってます。

正式リリースが待ち遠しいですが、更にクラウド(VPSなど)で使えるようになるには、まだまだ時間が掛かりそうな雰囲気です。

リリースされたら、インストール方法などをまとめたいと思っています。

8/15時点では、Release Workを残すのみ!
最終段階か?と思いきや・・・

こんな感じで、まだ更新中だったりしています(^^ゞ
https://koji.mbox.centos.org/koji/index

UTC 2019-08-15 15:50頃

でも、ここまで来ると本当に「あと少し!」って感じですね。

早ければ明日にもリリースか?とか期待してしまいますが、土日は進捗が止まっているので、来週8/21辺りが最短リリースじゃないかな?と、期待してます(#^.^#)

さてさて、まだまだリリースされる感じがしない。
8/20から全く更新する気配すら感じられなくなりました。
オープンソースカンファレンスの影響だろうか?
ここまで来たら、来月中にはリリースされるでしょう。
CentOSのサイトでは、「いつリリースされるの?」というコメントが出ていたり、首を長くして待っている人がいらっしゃいますね。
もう、ほとんどの作業は済んでいるはずなので、最後の詰めがしっかりされて発表して頂ければと思います。
しばらく、期待して待ちましょう。


2019-09-10 According to this thread, work was stopped on CentOS 8 after upstream released 7.7. Since so many more users have CentOS 7.x in production, and no one has 8 yet, priority has been given to the 7.7 update… and once it is done, work will continue on 8.

https://wiki.centos.org/About/Building_8

9/10時点で7.7のリリース作業のため、8の作業が停止してしまいました。
ちょっと厳しいなぁ~
今月中のリリースはあるのか?

CentOS 7でPHPのアップデートがErrorになる

PHPがアップデートできない!

※この事例は、remiリポジトリを使用しています。またPHP71を対象としています。remiリポジトリを使っていない場合は参考にならないかも知れません。PHP71以外のバージョンでは適宜コマンドの指定を変えてください。ご注意ください!

CentOS 7.5-1804でyum updateを実施しようとしたら、アップデートが出来ませんでした。
手動でPHP以外のアップデートを済ませて再度確認を行った結果、以下のエラーが原因でした。

当然、–skip-brokenとかやる気は全く無いので、ググってみると同様の現象に見舞われている方を発見!
そのQAに書かれている内容を見て何となく方向性は判ったのだが、どうも気に掛かる。
やっぱり1個足りない気がする。。。。
危なっかしいので、万が一のことを想定しスナップショット(バックアップ)を取得してから以下の手順を順次実施した。

アップデート手順

まずは、障害を取り除く

まず最初にエラーメッセージ記載されているパッケージを以下のコマンドで削除する。

Dependencies ResolvedとDependencies Removedの項目にも書かれているが、phpMyAdminもトランザクションの影響で削除されている。
こういう時、yum -yオプションは避けた方が良いだろう。

必要なパッケージを再度インストールして更新する。

とりあえず、参考にしたサイトに記載されていた内容でインストールしてみた。その手順が以下になる。

やっぱり、phpMyAdminがインストールされていない!
phpMyAdminを明示的に入れる必要があるわけで、以下のコマンドでインストールを行う。

無事入りました!
ちなみに、こちらはremiを使ってPHP71の事例となっていますが、その他のバージョンに関しては適宜バージョン指定を変えてくださいね。

CentOS 7 メールサーバ構築

※本記事は執筆中であり、一部正確ではない部分があります。でも一応は動くはずです。

今更ですが、CentOS 7にメールサーバを構築します。
RHEL 8(RedHat Enterprise Linux 8)が公開されているのに、今更な感じは拭えませんが、多分、CentOS 8でも同じ感じで設定できるでしょう(^^;

インターネット上を散策すると、私を含めて色々な方がインストール方法をブログなどに掲載されていますが、簡単なインストール方法は分かるんだけど、実はファイアーウォールが無視されていたり。。。SELinuxを無効にするとか。。。それって良いの?という感じになったり、少し不安がよぎります。

そんなことがあって、自分に合った記事を見つけるのは意外と大変なんですよね。

ということで、この記事も私に合った記事になっていますので、参考にされる方はご自身の環境に合うか合わないかを判断した上で考えてみてください。

本記事では、メールサーバのインストールを何とか使えるレベルから少し踏み込んでセキュリティ対策も考えた状態までもって行こうと思っています。
それと合わせて、少しだけですけどデフォルトよりも少しパフォーマンスを上げてみようと思います。

こんなことやります。

まず最初に、本記事で紹介するメールサーバでは、postfixとdovecotを採用することにしました。
他のsendmailを使う方などは対象外になります。

以下の様な構成です。

サーバの種類概要パッケージ
SMTPサーバメール送信postfix
POPサーバメール受信dovecot

インストール前の準備

メールサーバを立ち上げようなんて考えている方はご存知とは思いますが、DNSの設定を行う必要があります。
ドメインを取得して、AレコードとMXレコードを設定してください。
まず、AレコードでグローバルIPアドレスとドメインを紐づけます。
次に、そのドメインとMXレコードを紐づけます。
サーバ本体とは別にファイアウォールを設置されている場合は、そちらの設定も忘れずに行います。

SMTPサーバ/postfix

SMTPサーバとしてpostfixをインストールします。

私の環境では、デフォルトでインストールが完了していました。
以下のコマンドでインストール状況を確認しましょう。

インストールされていない場合には、いつものようにyumでインストールします。
#CentOS 8ではyumがdnfへ変更されるんでしたね。

インストール自体はこれで終わりです。

postfixの設定

postfixの設定を行います。
/etc/postfix/main.cfを編集します。
編集項目のみを抜粋します。

スパム対策

スパム対策を行います。
まず、必要なパッケージをインストールします。

spamassassinを利用したスパム対策では、procmailを使用します。
postfixの設定を変更します。
/etc/postfix/main.cf の下記の内容を有効にします。

/etc/procmailrcを作成し、以下の様に編集します。

通常は、この後にfirewall-cmdでsmtpを有効にしいます。

ここまでは簡単な設定です。
SMTPサーバを外部の方が使われないのであれば良いのですが、SMTPサーバを勝手に外部の人が使うケースがあります。
そうならない為に、スパム対策が色々とあります。
そこまでの内容をここで記載するには、時間が掛かるので、今回はここまでにします。
会社などで外部からSMTPサーバへアクセス出来ないようなにしている場合にはこの程度で十分ではないかと思います。
社外からSMTPサーバを使えるようにすると、関係のない人もSMTPサーバを利用出来てしまいます。
インターネット上の公開サーバなども同じです。
その場合には、スパムホスト対策やSMTP-AUTHやCRAM-MD5認証など対策を行う必要があるでしょう。
詳しくは、別の機会に投稿したいと思います。
私の環境では、firewallでSMTPを閉じてしまいました。
外部からSMTPのサービスを使用できなくするだけでOKです。

POPサーバ/dovecot

POPサーバにはdovecotを利用します。
dovecotが入っていない場合には、以下のコマンドでインストールします。

dovecotの設定

dovecotの設定を行います。
まず、/etc/dovecot/conf.d/10-mail.confを編集します。
SSL用のpop3sも有効にしていますが、使わなければコメントアウトしておきます。

firewallの設定を行います。

サービスを起動

サービスを起動します。

mailx コマンドによる動作確認

mailxコマンドを用いて動作確認を行います。
まずは、mailxをインストールします。

mailxコマンドを実行します。

dateコマンドで日時を出力し、その結果をメールのタイトルとして送信します。
-rで送信元のメールアドレスを指定し、一番最後に送信先を指定します。

実際に受信をしてみるとわかりますが、送信してから受信完了するまでに時間が掛かる場合があります。

失敗すると、次に再送を行うまでに3分程時間を要する設定にデフォルトではなっています。

ちょっとだけチューニング

ほんの少しだけチューニングします。
/etc/postfix/main.cfの最後に以下を追加します。

詳しくは別途調べてみてください。
少し改善されていると思います。

Vulsによる脆弱性の検査

はじめに

今回はVulsを用いた脆弱性の検査を行う。
対象とするシステムはCentOS 7とする。
また、本サイトは個人運営のため、メンテナンスが不十分であり対象パッケージのアップデートに追従できていないことに注意!

流れは以下の通り。

  • Vulsインストールの下準備
  • 脆弱性情報の準備
  • Vulsによる脆弱性の検査
  • 可視化

以上について順を追って記載する。
オフィシャルなインストール方法は以下のURLに示されており、参考にしている。
https://vuls.io/docs/en/install-manually-centos.html

Vulsインストールの下準備

実行ユーザの作成

Vulsを実行するユーザの作成を行う。

sudoを許可するためにvisudoでユーザに許可をします。

セキュリティ確保の為、不要なユーザによるsudoを許可したくない場合には、作業終了後に上記の内容を削除する。
※継続的なモニタリングを行う場合には、残しておく必要あり。

ログ格納用ディレクトリの作成

vulsのログを格納するディレクトリを作成する。

go環境のインストール

以下のサイトからパッケージをダウンロードする。

https://golang.org/dl/

本資料作成時点における最新バージョンは1.12でしたので、以下のコマンドを実行し解凍する。

goの環境変数を設定する。
/etc/profile.d/goenv.shを新たに作成する。

ここでvulsの実行ユーザでgo環境の確認を行う。

環境変数を読み込む。

バージョンが正しく表示されていれば、goのインストールは成功している。

脆弱性情報の準備

NIST(アメリカ国立標準技術研究所)が提供するNVDと、IPA(情報処理推進機構)が提供するJVNから脆弱性情報を取得する。

gitのサイトを覗いてみると、どうも日本人の方がまとめてくれているみたいですね。感謝!

今度は、Linuxのディストリビュータが提供されているOVALも取得する。

各データベースを構築する。

NVDのデータベースを構築する。
相当古い情報から取得するので、時間は結構かかる。
オフィシャルのインストールマニュアルには、AWSで10分程度となっていたが、1〜2時間程度は覚悟した方が良さそう(^^;
出力さているログを見ていると、西暦が記されたファイルがちらほら見受けられるので、進捗状況が分かると思う。

JVNのデータベースを構築する。

こちらは更に古くて1998年以降のデータベースになる。
オフィシャルのインストールマニュアルには、こちらもAWSで10分程度とされているが、実際どれだけかかるのか。。。
2005年のデータまでは比較的速やかに登録が進むのだが、2006年くらいからいきなり重くなる(^^;
日本では2006年くらいから本気で取り組みを始めたということなのだろうか?(笑)

OVALのデータベースを構築する。

ここからはある意味でオプションデータベースみたいな感じもするけど、オフィシャルマニュアルに記載があるので、合わせて登録する。

gostのデータベースを構築する。
これまでよりは少し短い時間で構築できるが、それも10分程度は覚悟。
ディストリビューたから脆弱性に関するパッチが提供されていないものを検出出来るとのこと。

Exploitのデータベースを構築する。
エクスプロイトコードを表示出来るExploit DBがVuls 0.6.0から提供されているので、それを使いたい場合に追加する。ここもオフィシャルマニュアルの丸コピ


Vulsのインストール

データベースの準備が整い、これからVulsのインストールを行う。
ここは、オフィシャルマニュアルを丸コピ!
※Vulsを再インストールするとかアップデートする際には、ここでインストールするソースを含めた生成物を削除する必要があるらしい。方法については後述する「Vulsのアップデート」に記したが、オフィシャルマニュアルも合わせて確認すること。

Vulsの設定ファイルを作成する。

設定ファイルの確認を以下のコマンドで行う。

エラーが表示されなければ完了である。

Vulsによる脆弱性の検査

ローカルスキャンの方法を記載する。
ローカルスキャン以外にもリモートスキャンを行う方法等も準備されているので、必要に応じてセットアップなどを行ってやってみるのも良いかと思う。
ローカルスキャンのコマンドは至ってシンプルで以下のコマンドで実施する。

Vulsのアップデート(新規インストール時は不要)

Vulsをアップデートする時は、実行モジュールとソースを全削除してから行うらしい。
ということで、ここで記載する内容は、Vulsをアップデートする際に行う事前作業であり、新規インストール時には必要ない。

スキャン結果の確認

スキャン結果を確認してみる。
困ったことに、-format-short-textオプションが使えなくなっているみたい。
オフィシャルマニュアルにはまだその記載があるのだが、諦めて他の出力結果を試してみる。

デフォルトの出力結果を出してみた。
コマンドは以下の通り。

ちなみに、この時点で-lang=jaは全く意味が無かった(笑)
日本語が出てくれることを期待しただが。。。結果は以下の通り

Total: 200 (High:49 Medium:133 Low:18 ?:0),
全体で200の脆弱性を確認している。
各レベルに対応した数値が提示されている。

199/200 Fixed
200件中199件でアップデートパッケージが提供されている。

後の説明は省略。。。。

表は、それぞれの脆弱性に関するレポートが示される。

TUI形式で表示することも可能。

終了は、Ctrl+Cで行う。

VulsRepoを用いた解析方法などもあるようだが、今回はここまで。