Sat, Dec 04, 2021

packagesの説明文書を訳しつつ、使えるものを探してみました(F編その1)

この記事は openSUSE Advent Calendar の5日目です。

今回は fbi を紹介します。

パッケージ名 fbi
バージョン Retrieving package fbi-2.14-3.8.x86_64
動作 ○
少々物騒な名前ですが、フレームバッファ上にイメージを表示させるツールです。こんな感じで表示されます。

画面の下にはステータスが表示されています。
また、 -t オプションで、指定された秒数毎にループして複数の画像を表示させることもできます。そのとき、 –blend オプションを使用すると前後の画像をオーバラップすることができます。
コンソール上でちょっと画像をチェックしたり、X 環境なしで簡単なフォトビューワを作るときには便利に使えそうです。

Ryzen 7 5700G 搭載の新しいPCでopenSUSE Leap 15.3を使う

openSUSE Advent Calendar 2021 の 4日目です。書き手がまだまだ足りませんので、ぜひ気軽に投稿をお願いします。

今日は新しいPCの話です。これまでは、2012年に組んだ Core i7-3770S のデスクトップ PC を Windows 10 で、Dynabook VZ72 (i7-7500U) で openSUSE Leap を使ってきました。このデスクトップPCのほうが、まもなく10年ということもあり、時々フリーズしたり、性能不足なところもあり、半導体が高騰している微妙なタイミングですが、完全に壊れる前に買い換えることにしました。

構成

新しい PC の構成は次のとおりです。

  • CPU: Ryzen 7 5700G
  • M/B: Gigabyte X570S
    • ネットワークカードは RTL8125 2.5GbE
  • メモリー: SanMax Technologies PC4-25600 16GB CL22 Skhynix × 2
  • SSD: CFD CSSD-M2B5GPG3VNF (512GB, PCIe Gen 4×4)
  • ケース: Fractal Design Define 7 Compact
  • 電源: Antec NeoECO GOLD 550W(旧PCから流用)

マザーボードが無駄にX570なのは、実家の DeskMini A300 の PC の調子が悪く、故障箇所の切り分けを行うために旧CPUに対応したX570にしました。ちょっと無駄です。さらに、GPU 内臓の Ryzen 7 5000G は PCIe が Gen 3 になってしまうので、X570 の意味がありません…。残ったメリットは、増設した場合のメモリークロックくらいでしょうか。

今回こそコンパクトな PC にしたいと思っていたのですが、この状況でマザーボードの選択肢が少なく、結局 ATX ケースになってしまいました。Fractal Design の 5インチベイのないコンパクトラインのケースなのですが、今まで使っていた 15年以上前の ATX ケースよりずいぶん大きいです。最近、デスクトップ PC をわざわざ買う人は、ハイエンドのグラッフィックカードを付けるからか仕方がないですね。HDD は NAS に移してしまったので、3.5インチや2.5インチベイも使っておらず、中身はすっからかんです。そのうち簡易水冷でも導入して有効活用することにしましょう。

openSUSE Leap を入れる

これまで、デスクトップでは Windows を使っていましたが、最近、Steam で配信されているゲーム(AOCとか)は Linux でも動くので、ホスト OS を openSUSE にしてしまうことにしました。加えて、openSUSE 界隈で流行っているかもしれない、PCI pass-through を使って、物理 GPU を Windows ゲストに直接接続すれば快適な Windows ゲスト環境が作れるはず…と考えていました。結局、Windows ゲストはちょっと試しただけで使っていないのですが、この話はまた今度。

さて、openSUSE Leap のカーネルは、新しいハードウェアに対応できるようにパッチがたくさん入っていますが、ちょっと古いです。そのため、最新のハードウェアでは一部の機能が使えないことがあります。今回、Leap は普通にインストールできましたが、画面の解像度が 4K にならないし、もっさりしていて、少なくともグラフィックドライバまわりが動いてない感じでした。

そんなときは、最新のカーネルを OBS から持ってきます。Leap 向けの最新カーネルは以下の OBS プロジェクトでビルドされています。このリポジトリを登録して、kernel-default や kernel-frimware-* をインストールすれば OK です。
https://build.opensuse.org/project/show/Kernel:stable:Backport
このリポジトリは openSUSE Leap としてメンテされているものではありませんのでご注意ください。

新しいPCは?

8コア、16スレッドということで、やっぱりパッケージのビルド作業が快適になりました。CPU内蔵のGPUですが、Full HDでゲームをする分には十分で、グラフィックカードを増設するのはだいぶ先になりそうです。

Thu, Dec 02, 2021

packagesの説明文書を訳しつつ、使えるものを探してみました(H編その3)

この記事は openSUSE Advent Calendar の3日目です。

今回は ntop を紹介します。

パッケージ名 htop
バージョン htop-3.1.1-1.1.x86_64
動作 ○
詳細
top のおしゃれバージョンです。CPU使用率を色つきのグラフで表示したり、プロセスの状況を色つきで見やすく表示したりします。

ファンクションキーを使って、整列する順番を変更することも出来ます。

そのほかにも、直接 top の画面からプロセスを終了したり(割り込み発生させたり)、Tree表示をさせることも出来ます。

pstree、kill コマンドの代替にもなりますので、便利に使えそうです。

Wed, Dec 01, 2021

packagesの説明文書を訳しつつ、使えるものを探してみました(H編その2)

この記事は openSUSE Advent Calendar の2日目です。

今回は highlight を紹介します。

パッケージ名 highlight
バージョン highlight-4.1-1.3.x86_64
動作 ○
詳細
テキストを読み込んで、色を付けて表示するツールです。出力形式は平文のほかに HTML や RTF、ODT、SVG などが選べます。オプションを付けないと平文が生成されます。

HTML出力をすると、色を付けたHTMLテキストが生成されます。ODT への変換もメニューにあるのですが、結果ファイルは、LibreOffice 7.1 では開けませんでした。そのかわり、RTF 形式では、LibreOffice 7.1で開くことが出来ました。


テキストを簡単に見やすくして表示させる場合には便利に使えると思います。

Tue, Nov 30, 2021

packagesの説明文書を訳しつつ、使えるものを探してみました(H編その1)

この記事は openSUSE Advent Calendar の1日目です。

今回は、 headmore を紹介します。

パッケージ名 headmore
バージョン headmore-1.2-1.16.x86_64
動作 △
テキストベースのVNC クライアントです。しかし、一応画面は表示されるのですが(ここではWindowsに繋いでいます)、GUIな画面をテキストで表示しているため、大まかな雰囲気が掴めるという感じでしかありません。ものすごくズームすれば、大まかな形は分かりますが。


取りあえずコンソールから、GUIな画面がおおよそどうなっているかを簡単に確認するときには便利に使えるかもしれません。

Sat, May 08, 2021

Grafana Cloud でお家サーバーをモニタリング

この記事は小江戸らぐ 5月のオフな集まりの発表ネタです。

2回目の夏を迎えるに当たり、自宅ファイルサーバーの熱とファンの音が気になり、モニタリングしてみることにしてみました。今回は他の用途でも興味があった Grafana を使ってみました。Grafana は CPU 使用率やメモリ使用量といったハードウェアから、データベースやアプリケーションの性能といった様々なメトリクスを可視化・分析するための Web アプリケーションです。インタラクティブに操作できたり、かっこいい見た目だったりで、最近よく見かけます。

小江戸らぐ向け注記: よくカロスさんの発表に出てきます。K8s のクラスタやラズパイの環境センサーの表示で使っていますね。

Grafana Cloud

今回はちょっと横着して、Grafana の SaaS である Grafana Cloud を使いました。Grafana といえば、多くの場合、メトリクス収集と時系列データベース機能を持つ Prometheus と組み合わせ、これら2つをどこかにインストールして使います。Grafana Cloud では Grafana 本体と Prometheus のデータベース部分は Grafana Cloud で動いているものを使うことができます。データの収集は Prometheus からデータベース部分などを簡略化した Grafana Agent で収集できます。

気になるお値段ですが、Free プランがあります。メトリクスの保持期間は2週間というのがポイントになりますが、ちょっと試して見るには十分です。無料プランの主なスペックはこんな感じです:

  • 10,000 系列(種類)までの Prometheus または Graphite のメトリクス
  • 50 GB のログ
  • 14日間のメトリクスとログの保持期間
  • 3人までのチームメンバー

アカウントを作るためにクレジットカードなどの情報は特に必要ありません。 Grafana Cloud のページでアカウント作成に進み、GitHub などの SSO でログインすればすぐ準備完了です。

メトリクス収集

次に、メトリクスの収集を始めましょう。雷のアイコン(⚡) > Walk through をクリックすると、スクリーンショットのように Grafana Cloud がサポートしているプラットフォームのメトリクス収集を簡単にセットアップできるガイドが用意されています。今回は Linux Server を使用します。Prometheus では Node Exporter と呼ばれているものです。

Linux Server をクリックすると、セットアップするためのスクリプトが表示されます。「Choose your OS」には openSUSE が見当たりませんが、「RedHat – based」で OK です。Go言語で実装されたアプリなので、システムライブラリにほとんど依存していません。

あとは、その下に表示されたスクリプトを実行すれば OK です。Grafana Agent の RPM のインストールと設定ファイルの作成、起動まで一気に行われます。セットアップが終わると、最初から用意されているダッシュボードに収集した情報が表示されます。(datasource で grafanacloud-xxxx-prom を選択)

ダッシュボードの作成

もちろん、ダッシュボードを自分で組み立てることもできます。ここではパネルを配置し、Visualization を Time Series にして次を追加してみました。収集されているメトリクスの一覧がドロップダウンメニューに表示されるので、ここからそれっぽいものを選んで追加することができます。

  • node_cpu_scaling_frequency_hertz
  • instance:node_cpu_utilisation:rate1m
  • node_hwmon_temp_celsius

各系列のスタイルや、単位、Y軸の設定は、ちょっとわかりにくいですが Overrides タブで系列を選んで個別に設定できます。

このファイルサーバーは普段ほとんどアイドル状態なのですが、CPU クロックが思った以上に落ちていないことが分かりました。ファンコントロールのターゲット温度が45℃設定なのですが、55℃くらいをキープしているようです。

おわりに

Grafana Cloud を使って自宅ファイルサーバーの監視を簡単にしてみました。そして Grafana Agent が CPU 時間を他と比較して使ってしまっていますので、場合によっては収集する項目を減らすなどを考えたほうが良いかもしれません。

Thu, May 06, 2021

packagesの説明文書を訳しつつ、使えるものを探してみました(A編)

前回は S でしたが、今回は A です。

パッケージ名 ansifilter
バージョン ansifilter-2.18-1.5.x86_64
動作 △
詳細
テキスト中の ANSI エスケープシーケンスを取り去ったり、HTMLなどの形式に変換できます。たとえば、script コマンドで、ANSI エスケープシーケンス付きのメッセージを記録したのち、それをテキストとして利用するときなどには便利に使えます。

ただし、漢字についてはうまくいかない場合がかなりあります。また、HTML 変換については、エスケープシーケンスを落として変換、すなわち、色とかの情報がまるまる落ちて変換されます。ここはちょっと惜しいところです。
漢字が含まれていない、typescript の結果を整理する場合などには便利に使えそうです。

パッケージ名 arping2
バージョン arping2-2.21-1.5.x86_64
動作 ◎
詳細
ICMP のほかに、ARP を使って相手との疎通を確認するツールです。ICMP echo に反応しない機器との疎通を確認できます。但し、root でないと動きません。

# ping -c 4 192.168.A.BB
PING 192.168.A.BB (192.168.A.BB) 56(84) bytes of data.

--- 192.168.A.BB ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3058ms

tw:~ # arping2 -c 4 192.168.A.BB
ARPING 192.168.A.BB
42 bytes from a6:3a:xx:yy:zz:98 (192.168.A.BB): index=0 time=487.929 usec
42 bytes from a6:3a:xx:yy:zz:98 (192.168.A.BB): index=1 time=362.456 usec
42 bytes from a6:3a:xx:yy:zz:98 (192.168.A.BB): index=2 time=356.881 usec
42 bytes from a6:3a:xx:yy:zz:98 (192.168.A.BB): index=3 time=389.354 usec

--- 192.168.A.BB statistics ---
4 packets transmitted, 4 packets received,   0% unanswered (0 extra)
rtt min/avg/max/std-dev = 0.357/0.399/0.488/0.053 ms

たとえば、Windows Server の既定状態のような機器との疎通を確認するには便利に使えそうです。

Sun, May 02, 2021

Btrfs のサブボリュームを別のディスクに移動する

自宅サーバーをセットアップした際に、すべてを HDD にインストールしていたのですが、今回、/home と /boot、過去のスナップショットデータ以外を SSD に引っ越しました。このとき、Btrfs のサブボリュームとしての引っ越しをしてみました。

最初に openSUSE の Btrfs のサブボリューム構成についておさらいです。Snapper が有効化された状態のサブボリューム構成は次のようになっていました。Btrfs の / には @ というサブボリュームが1つだけあります。@ の中にマウントしたシステムの / にあるディレクトリに対応したサブボリュームがあります。ちなみに /@ が / としてマウントするのではなく、それぞれのサブボリュームごとに /etc/fstab でマウントしています(例: /@/home が /home)。Snapper を使用している場合は 1 番目のスナップショットが現在の / です。

以下のリストに無い、/@/.snapshots/1/ や /@/boot/grub2/ はサブボリュームではなく、その上にあるサブボリューム内のディレクトリです。

/@
/@/.snapshots
/@/.snapshots/1/snapshot
略
/@/.snapshots/61/snapshot
/@/boot/grub2/i386-pc
/@/boot/grub2/x86_64-efi
/@/home
/@/opt
/@/root
/@/srv
/@/tmp
/@/usr/local
/@/var
/@/var/lib/machines

さて、今回は /@/home と /@/boot/* を HDD に残し、その他を SSD に移動することにしました。パーティション全体であれば、dd で、ファイルレベルであれば rsync と色々な方法がありますが、今回は Btrfs のサブボリュームを他の Btrfs ファイルシステムに転送する btrfs send を使いました。

作ってみたスクリプトを先に貼り付けて、ポイントを個別に説明します。使い方はコピー元を /dev/sda1、コピー先を /dev/sdb1 とし、次のように使います。3番目の引数はスキップするサブボリュームのパターンです。/dev/sdb1 は mkfs.btrfs でフォーマットしてある前提です。
$ btrfs-subvols-copy.sh /dev/sda1 /dev/sdb1 "@/home|@/.snapshots/[2-9][0-9]*|@/boot"

#!/bin/sh

set -eu

exclude=$3

# mounting root volumes
workdir=`mktemp -d`
echo "working directory is '$workdir'"
cd $workdir
mkdir src
mkdir dest

# ルートのサブボリュームをマウントマウントする
echo "mounting root subvolumes of src and dest"
mount -t btrfs -o subvol=/ $1 $workdir/src
mount -t btrfs -o subvol=/ $2 $workdir/dest

src=$workdir/src
dest=$workdir/dest

backup_date=`date -u +'%s'`

# サブボリュームの一覧を出力
for subvol in `btrfs subvolume list --sort=path $src | awk '{print $9}'`; do
    echo -n ">> $subvol: "
    if [[ $subvol =~ $exclude ]]; then
        echo "matched to a exclude pattern, skipped"
    elif [ -e $dest/$subvol ]; then
        echo "the destination subvolume already exists, skipped"
    else
        echo "create readonly tmp snapshot"
        tmpsnap=$subvol.tmpsnap
        # スナップショットを作って送る
        echo "creating a read-only temporary snapshot to send] $src/$tmpsnap"
        btrfs subvolume snapshot -r $src/$subvol $src/$tmpsnap
        echo "copying"
        btrfs send $src/$tmpsnap | btrfs receive $dest/`dirname $tmpsnap`

        # 送信用のスナップショットを消す
        echo "deleting the temporary snapshot: $src/$tmpsnap"
        btrfs subvolume delete $src/$tmpsnap

        # .tmpsnap を外す
        echo "renaming the copied subvolume"
        mv $dest/$tmpsnap $dest/$subvol

        # property を元のサブボリュームと同じにする
        echo "copying subvolume properties"
        for prop in `btrfs property get $src/$subvol`; do
            btrfs property set $dest/$subvol ${prop/=/ }
        done

        echo "done"
    fi
done

echo "unmounting src and dest"
umount $workdir/src
umount $workdir/dest
echo "cleaning up working directory"
rmdir src
rmdir dest
rmdir $workdir

まずは、送信元、先のボリュームのマウントです。

# ルートのサブボリュームをマウントマウントする
echo "mounting root subvolumes of src and dest"
mount -t btrfs -o subvol=/ $1 $workdir/src
mount -t btrfs -o subvol=/ $2 $workdir/dest

送信元と先をマウントするだけなのですが、注意点が1つあります。Btrfs では任意のサブボリュームを選んでマウントすることができますが、何も指定しないと / ではなく、デフォルトのサブボリューム(btrfs subvolume set-default で設定可能)がマウントされてしまいます。特に Snapper を使用していると、1番目の Snapper スナップショットがデフォルトになっていますので、明示的に subvol でマウントしたいサブボリュームの指定が必要です。

次に、送信元のサブボリュームのリストアップです。

# サブボリュームの一覧を出力
for subvol in `btrfs subvolume list --sort=path $src | awk '{print $9}'`; do

--sort=path を指定して、親ディレクトリを含むサブボリュームを先にリストし、サブボリュームのツリー構造の親サブボリュームとディレクトリを先にコピーするようにします(存在しないとエラーになってしまいます)。

次に送信するところです。

# スナップショットを作って送る
        echo "creating a read-only temporary snapshot to send] $src/$tmpsnap"
        btrfs subvolume snapshot -r $src/$subvol $src/$tmpsnap
        echo "copying"
        btrfs send $src/$tmpsnap | btrfs receive $dest/`dirname $tmpsnap`

btrfs send コマンドを使ってコピーするのですが、送信できるのは読み取り専用のサブボリュームなので、一度スナップショットを読み取り専用で作成し、このスナップショットを送ります。コピーは btrfs sendbtrfs receive のペアで行えます。サブボリュームの名前(パス)は送信元と同じものが作成されます。そのため、スナップショットの名前になってしまうので、あとで mv が必要でちょっと不便です(スナップショットを別のディレクトリに作成する方法もあり)。

注意が必要なことが1つあります。この送り方では Snapper のスナップショットを送れません。Snapper のスナップショットはスナップショット間で共通するデータを共有していますが、この方法ではこの共有が解けて複製されてしまいます。btrfs send のオプションにベースとなったスナップショットを指定し、差分だけを送る機能があるようなので、もう少し工夫すると実現できるかもしれません。

最後に、サブボリュームのプロパティのコピーです。

# property を元のサブボリュームと同じにする
        echo "copying subvolume properties"
        for prop in `btrfs property get $src/$subvol`; do
            btrfs property set $dest/$subvol ${prop/=/ }
        done

送信前に読み取り専用のスナップショットを作成していますので、読み取り専用を含めた、送信後サブボリュームのプロパティをもと同じに戻します。

Wed, Apr 28, 2021

packagesの説明文書を訳しつつ、使えるものを探してみました(S編)

前回は T でしたが、今回は S です。

パッケージ名 scout
バージョン scout-0.2.4+20210325.6c2d9f3-1.1.noarch
動作 △
詳細
コマンドが見つからない場合、パッケージ内にあれば、そのパッケージを表示してくれるツールです。たとえば、

> scout bin sdl-config
 リポジトリ                            | パッケージ        | パス       | バイナリ
----------------------------------+--------------+----------+------------
 zypp (openSUSE-20210325-0)       | libSDL-devel | /usr/bin | sdl-config
 zypp (download.opensuse.org-oss) | libSDL-devel | /usr/bin | sdl-config

というような感じになります。
ただ、日本語で表示するとカラムがずれてしまうこと、マニュアルに書いた例題が、上記以外では動作しないこと(python のエラーになります)があるので、使えるかどうかは微妙なところです。

パッケージ名 sc
バージョン sc-7.16-13.26.x86_64
動作 ◯
詳細
コンソールで動くスプレッドシートです。但しちょっとくせがあります。文字はそのまま入力できず、必ずプレフィックスをつける必要があります。例えば、数字や数式を入力する際には、まず = キーを押してから、入力したい文字列を入れます。
文字列も入りますが、日本語文字列は、UTF-8環境では入りませんでした。
カーソル移動は矢印キーのほかに、h、j、k、l の vi 風キーバインドでも使えます。
関数は @sum とか @lookup とか、@logとか、最低限のものは揃っているようです。
sc は、大昔のPC を知っている人ならば、 VisiCalc だと思えば感覚が掴めるかと思います。

パッケージ名 socat
バージョン socat-1.7.4.1-1.4.x86_64
動作
詳細
種々のソケットによる通信を中継してくれるツールです。IPv6 にも対応し、種々のネットワークオプションや細かな制御のためのオプションも用意されています。
一番簡単な使い方としては、ファイアウォールの内側にあるサーバに対して、入口のサーバに socat を設定しておき、socat 経由で接続するというやり方でしょう。あるいは直接ルーティングされていないセグメントへの接続時にも使えます。
たとえば、192.168.x.0 のセグメントから、172.31.y.0 のセグメントにあるサーバを経由し、 172.16.z.0 のセグメントにあるマシンに繋ぐには以下のようにします(ここでは、daytime プロトコルを起動しておいてそこに繋ぎます)。

socat tcp4-listen:8089,reuseaddr,fork tcp:172.16.z.zz:13

結果はこうなります。

% telnet 172.31.y.yy  8089
Trying 172.31.y.yy...
Connected to susedev.
Escape character is '^]'.
28 APR 2021 18:00:15 JST
Connection closed by foreign host.

このようにすることで、2段階のログインをしなくとも172.16.z.0 のセグメントにあるマシンに接続することが出来ます。

Fri, Apr 16, 2021

packagesの説明文書を訳しつつ、使えるものを探してみました(T編)

前回は Q でしたが、今回は T です。

パッケージ名 tcptraceroute
バージョン tcptraceroute-1.5.beta7-lp152.48.5
動作 ○
詳細
tcp を使った traceroute と同等の機能を実行するツールです。ICMP ではなくて、TCPで特定のポートを叩く形で traceroute 相当の出力を表示します。インストール時にはlibnet9-1.2~rc3-lp152.3.4 も必要となります(自動でインストールされます)。また、Thumbleweed には入っていません。LEAP のみです。
とあるサーバにtraceroute をしてみてもうまく動かなかったのですが、ポート 22 を指定して tcptraceroute を実行したところ、うまく表示できました。

% traceroute -n 210.171.174.178
traceroute to 210.171.174.178 (210.171.174.178), 30 hops max, 60 byte packets
 1  172.31.255.254  0.875 ms  0.529 ms  0.612 ms
 2  124.155.82.121  26.090 ms  25.900 ms  25.712 ms
 3  124.155.82.69  25.762 ms  25.571 ms  25.651 ms
 4  124.155.82.2  25.465 ms  25.627 ms  25.441 ms
 5  202.224.52.170  62.408 ms  62.183 ms  61.993 ms
 6  202.224.52.5  24.652 ms  27.474 ms  27.147 ms
 7  202.224.52.13  27.300 ms  16.913 ms  16.556 ms
 8  203.190.230.13  16.553 ms  16.760 ms  16.508 ms
 9  61.211.190.90  16.626 ms  16.458 ms 61.211.190.98  16.564 ms
10  219.124.151.210  16.147 ms  20.514 ms  19.783 ms
11  210.171.170.10  19.491 ms  19.283 ms  8.395 ms
12  210.171.170.34  7.396 ms  18.154 ms  17.967 ms
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

% tcptraceroute -n 210.171.174.178 22
Selected device eth0, address 172.31.255.189, port 57123 for outgoing packets
Tracing the path to 210.171.174.178 on TCP port 22 (ssh), 30 hops max
 1  172.31.255.254  0.614 ms  0.723 ms  0.702 ms
 2  124.155.82.121  4.183 ms  3.435 ms  3.461 ms
 3  124.155.82.69  4.362 ms  4.036 ms  3.909 ms
 4  124.155.82.2  3.690 ms  3.572 ms  4.257 ms
 5  202.224.52.170  6.843 ms  6.607 ms  10.887 ms
 6  202.224.52.5  6.634 ms  6.954 ms  6.597 ms
 7  202.224.52.13  5.601 ms  4.822 ms  5.065 ms
 8  203.190.230.13  5.674 ms  6.073 ms  7.402 ms
 9  61.211.190.90  6.423 ms  5.553 ms  6.690 ms
10  219.124.151.214  5.680 ms  6.735 ms  5.742 ms
11  210.171.170.10  6.646 ms  6.523 ms  7.012 ms
12  210.171.170.34  5.233 ms  7.322 ms  6.962 ms
13  192.168.3.252  10.616 ms  6.878 ms  10.268 ms
14  210.171.174.178 [open]  8.053 ms * *

ただ、万能ではないようです。Azure の中にある仮想マシンに、 tcptraceroute をポート 3389 や port 22 で実行してみたのですが、やはり繋がりませんでした。

パッケージ名 tdiff
バージョン tdiff-0.8.5-3.6.x86_64
動作 ◎
詳細
ディレクトリの比較をするコマンドです。diff とは違い、ファイルの差分を取るわけではありません。ディレクトリ中のファイルについて、日付や属性などを比較するためのツールです。たとえば、このような感じになります。

# tdiff . /home/ribbon
tdiff: (top-level): mode: 0700 0755
tdiff: (top-level): uid: root(0) ribbon(1000)
tdiff: (top-level): gid: root(0) users(100)
tdiff: (top-level): nlink: 9 21
tdiff: .bash_history: uid: root(0) ribbon(1000)
tdiff: .bash_history: gid: root(0) users(100)
tdiff: .bash_history: size: 1382 3546
tdiff: .bash_history: contents differ
tdiff: .bashrc: only present in /home/ribbon
tdiff: .cache: uid: root(0) ribbon(1000)

また、-v オプション( -vv,-vvv,-vvvv もあります)を指定すると統計情報を出力します。

tdiff: inode cache statistics:
 Hashing statistics for inode cache (@0x55916e3e4610):
    Table size              :      101
    Entry count             :       11
    Occupied buckets        :       10
    Distribution efficiency :    90.91%
    Average bucket length   :      1.1
    Max bucket length       :        2
tdiff: end

そのほかにもオプションが多数あります。数字の0 から 9 までのオプションを指定すると、チェックする項目が徐々に増えていくようになっています。

# tdiff -0 .local /home/ribbon/.local
# tdiff -1 .local /home/ribbon/.local
tdiff: share/RecentDocuments: only present in /home/ribbon/.local
tdiff: share/baloo: only present in /home/ribbon/.local
tdiff: share/flatpak/.changed: only present in .local
(略)
# tdiff -2 .local /home/ribbon/.local
tdiff: (top-level): mode: 0755 0700
tdiff: share/RecentDocuments: only present in /home/ribbon/.local
tdiff: share/baloo: only present in /home/ribbon/.local
tdiff: share/flatpak: mode: 0700 0755
tdiff: share/flatpak/.changed: only present in .local
(略)
# tdiff -3 .local /home/ribbon/.local
tdiff: (top-level): mode: 0755 0700
tdiff: (top-level): uid: root(0) ribbon(1000)
tdiff: (top-level): gid: root(0) users(100)
tdiff: share: uid: root(0) ribbon(1000)
tdiff: share: gid: root(0) users(100)
tdiff: share/RecentDocuments: only present in /home/ribbon/.local
tdiff: share/baloo: only present in /home/ribbon/.local
tdiff: share/flatpak: mode: 0700 0755
tdiff: share/flatpak: uid: root(0) ribbon(1000)
tdiff: share/flatpak: gid: root(0) users(100)
tdiff: share/flatpak/.changed: only present in .local
(略)

tdiff は、ファイルの有無や、属性の違いなどを一気に調べるときに便利に使えそうです。