17-May-2026
[Synergy→Deskflowへ移行]

Synergyの動作が時々怪しいことがあって(OpenBSD側はサーバ、Windows側はクライアント)、これの後継たるDeskflowへ移行します。しかし、OpenBSD-portsにそのパッケージは無いので、どうにかして動かすところから始める必要があります。どうにかして動かす部分については、きちんとした形にまとめたいと考えています。

Synergy→Deskflowへの移行で一番大きな変更点は、TLSによる暗号化がデフォルトで有効になっている点でしょうか。暗号化を使用した場合に問題が発生した場合は~/.config/Deskflow/Deskflow.confの[security]セクションにtlsEnabled=falseを書けば無効にできますが、これはなるべく使いたくありません。

とはいえ、何も準備をせずいきなりdeskflow-coreのみ動かすとサーバ/クライアント共に「WARNING: fingerprint does not match trusted fingerprint」が表示されてしまい、TLSを無効化しない限り接続できません。解決方法は以下のdeskflow(GUI frontend)を一旦使う方法か、別解があります。

  1. サーバ/クライアント双方でdesklowを起動し、どちらもTLS接続が有効になっていることを確認
  2. (クライアント側のみ)サーバに接続
  3. 「クライアントを信頼し接続を許可しますか?」(サーバ側)/「このサーバーに接続しますか?」(クライアント側)の問いが表示されるので、fingerprintを確認し問題が無ければ両方とも「接続を許可」する

サーバ側では、接続を許可したクライアントのfingerprintを~/.config/Deskflow/tls/trusted-clientsに保存します。ここに情報があれば、deskflow-coreのみでサーバを立ち上げても大丈夫です。クライアント側でも同様に、サーバのfingerprintをtrusted-serversに保存していますね。

過去の日記で、Synergyに言及している一番古いものは06-Jan-2008。18年ちょっとの間、大変お世話になりました(OpenBSDも4.2の頃から使っているので、もうそんな年月が経過したのですね…)。

(別解)

deskflowで使用するTLSの鍵ファイル(deskflow.pem)は、Barrier.pemの作成方法を参考に、openssl req -x509 -nodes -subj /CN=Deskflow -newkey rsa:4096 -keyout deskflow.pem -out deskflow.pem で作ることができます。

trusted-clients/trusted-serversに登録するfingerprintについては、Deskflow - ArchWikiが参考になります。自分は openssl x509 -sha256 -noout -fingerprint -in deskflow.pem | sed 's/://g' | sed 's/=/ /g' | awk '{printf("v2:sha256:%s\n", $3)}' >> trusted-xxxx (クライアント側のdeskflow.pemを使うならtrusted-clients、サーバ側ならtrusted-servers)としました。57.4kg(23:25)

10-May-2026
[ネットワーク周りの見直し、こちらはてこずっています]

我が家のインターネット回線、J:COM(CATV)の320Mbpsプランだと上りが10Mbpsと異常に遅いため、色々と契約を見直したついでに下り1Gbps/上り100Mbpsのプランへ切り替えました。常識的に考えれば光回線化するでしょ普通ではあるのですが、家に穴を開けるのがとっても嫌という理由によりCATV回線のままで増速です。

とはいえ、NanoPi R2Sバイナリで無理やり動かしているNanoPi R2CではWAN側をUSB2.0接続のUSB-LANアダプタで代替しているためかあまり速度が出ていないような感じです。それならケーブルモデムと一緒に貸与されたルータ(ZTE H6729Q)を使ってみるか、と交換してみたら

上の三つはまだ許容範囲だとしても、流石にIPv6使用不可をやられてしまうのは厳しいので、NanoPi R2Cに戻しました。折角なのできちんとNanoPi R2Cバイナリで動かすようにして、ルータ近くに配置したマシンでテストしたところ400Mbpsくらい出ることを確認しました。その一方で、ルータ→天井裏ハブ机上のハブを経由したマシンでは100Mbpsしか出ていません。この二つのハブは稼働してから約7年、調子が悪くても不思議ではありません…駄目元で机上のハブの電源を入れ直したら直ったので、当面はだましだまし使うことになりそうです。57.3kg(22:30)

05-May-2026
[思っていたより簡単なんですね、virtfs]

仮想マシン群、11-Aug-2022の手順でNFS越しにホストマシンとのデータ共有を行っているのですが…割と高い確率でArch Linux仮想マシンの起動時にNFSのマウントに失敗するので、virtfsを試します。

詳しいことはDocumentation/9psetupを見るとして、QEMUのコマンドラインオプションに-virtfs local,path=/export,mount_tag=vm6,security_model=mappedを追加して(vm6は仮想マシンごとにユニークなタグ)、Linuxゲスト側はmount -t 9p -o trans=virtio vm6 /exportでマウント。mount/umountに問題がないこと確認したら、echo "vm6 /export 9p _netdev,nofail,rw,trans=virtio 0 0" >> /etc/fstabでfstabを修正。なお、テスト/本番時においてはNFSマウントを解除しておくことも重要です。

同様な問題を抱えたSlackware仮想マシンもvirtfs化を試みたものの、mount -t 9p〜が通りません。カーネル起動時に「9pnet_virtio: probe of virtio0 failed with error -2」が発生しているため、カーネルの入れ替えが必要そうです。手間ですが起動後にmount -aでNFSをマウントできるため、それで対応することにします。57.0kg(24:00)