最近のFirefoxは他のタブとcookie等と共有しないcontainer tabsという機能がある。
だが、私の使っているFirefoxでは有効になっていなかった。
NetBSDだけでなくWindowsでも同様である。
いずれにしても、利用したい機能ではあるので、about:configで以下の2つを設定して、有効化した。
privacy.userContext.enabled privacy.userContext.ui.enabled
最近のFirefoxは他のタブとcookie等と共有しないcontainer tabsという機能がある。
だが、私の使っているFirefoxでは有効になっていなかった。
NetBSDだけでなくWindowsでも同様である。
いずれにしても、利用したい機能ではあるので、about:configで以下の2つを設定して、有効化した。
privacy.userContext.enabled privacy.userContext.ui.enabled
とあるVPSサービスを使ったサーバーがあるのだが、これはディスクの残容量が非常に少ない。 なので、そのVPSのディスクにtarballを作って、それを手元にコピーして来るということができない。 しかも、sshでログインできないユーザーだけが読み込みできるディレクトリーやファイルも存在する (rootが所有者で、パーミッションが700なディレクトリーや600なファイルがあると思えば良い)。 ryoonというユーザーがsshでログインできるユーザーであり、 rootユーザーがsshでログインできないユーザーである。
ここで、バックアップ元のVPSのホスト名をremoteserverとし、バックアップ先のサーバーのホスト名をlocalnetserverとしよう。
remoteserverはグローバルIPアドレスを持ち世界中のどこからもアクセスできるが、localnetserverは自宅のローカルネットワーク内にあるサーバーで外部からはアクセスできない。
つまり、localnetserverからremoteserverへsshで接続できるが、逆は不可能である。
以下のようにremoteserverで設定した上で、localnetserverで操作すれば、rootユーザーとしてtarballを作って手元にパイプ経由で取得できる。
以前はssh portforwardingを使って複雑な操作をしていたのだが、そのようなことは不要にできる。
remoteserver$ cat /home/ryoon/sudo-askpass #!/bin/sh echo "sudoコマンドへ渡すryoonユーザーのログインパスワード" remoteserver$ chmod 700 /home/ryoon/sudo-askpass
このsudo-askpassコマンドを使って、sudoコマンドにryoonユーザーのログインパスワードを渡すようにして(つまりsudoコマンドに-Aオプションを与えて)、tarコマンドを実行させる。
また、remoteserverにはUTF-8なファイル名を持つファイルがあり、BSD tarコマンドはこれに対して警告メッセージを表示する。
これがlocalnetserverにパイプ経由で送られて来るtarballに含まれていると不正なtarballになってしまうので、標準エラー出力は/dev/nullに捨てる。
/path/to/parent/directoryというディレクトリー内にあるbackuptargetdirectoryというディレクトリーをバックアップするとすれば、以下のようにlocalnetserverで実行すれば良い。
localnetserver$ ssh ryoon@remoteserver "SUDO_ASKPASS=/home/ryoon/sudo-askpass sudo -A tar cfp - -C /path/to/parent/directory backuptargetdirectory" > backup.tar
私はremoteserverもlocalnetserverも非力なマシンを利用していて、転送量へは課金されない環境なので、圧縮せずtarアーカイブのまま扱っている。
CPUもストレージもパワフルなマシンに移動させた後にxz -T 0 -9で圧縮することになる。
NetBSD-currentでは、IntelのIntegrated GPUはKabyLake Refreshの世代までしかサポートされていないはずである。 もちろん、KabyLake Refresh以前の世代でもFFmpegでH.265にエンコードできる。 だが、思ったより速く処理できない。 NetBSD上だと、VA-API経由なのがいけないのかもしれないし、他の要因なのかもしれない。 Fedora Linuxでも変わったようには見えなかったので、そもそも思ったより速く処理はできるのかもしれない。
と言うことで、手元にある最新のIntel CPUで試してみることにした。 だが、そのCPUを搭載したマシンは他の仕事もあるので、Windows 11 Pro 25H2がインストールされている。 この環境のままで、FFmpegでH.264のビデオファイルをH.265にトランスコードすることにした。
具体的には、CODEX FFMPEGからFFmpeg 8.1.1 (ffmpeg-8.1.1-full_build.7z)をダウンロードして展開し、 以下のようなコマンドでトランスコードすれば良い。 どうやら、-sharedの方の配布物ではちゃんと動かないようだった。
/path/to/ffmpeg-8.1.1/bin/ffmpeg.exe \
-hwaccel qsv \
-hwaccel_output_format qsv \
-i input.mp4 \
-c:a copy \
-c:v hevc_qsv \
-tag:v hvc1 \
-preset veryfast \
-vf vpp_qsv=deinterlace=2 \
-global_quality 30 \
output.mp4
H.264形式のファイルであるinput.mp4は、インターレースなファイルなのだが、そうであっては不便なので、
-vf vpp_qsv=deinterlace=2を指定して、Intel QSVのデインターレースフィルターを使って解消している。
ちなみに、これだと実時間の5から7倍の速度でトランスコードできる。 また、ディスプレイがオフになると、場合によってはエラーが発生する。 ディスプレイを常時オンにする設定をしておけば、エラーは発生しない。
about:configで、signon.autologin.proxy=trueと設定すると、ユーザー認証付きHTTPプロキシーサーバーへのログイン情報を保存している場合に、自動的にHTTPプロキシーサーバーにログインするようにできる。
つまり、ユーザーIDとパスワードを入力する画面(ログイン情報を保存しているので、いずれも入力済み)が表示され、ログインを明示的にする必要がなくなる。
DigitalOceanのオブジェクトストレージであるSpacesにWindows 11からアクセスしたい。 だが、そのためのソフトウェアを、インストーラーでWindows 11にインストールのは避けたい。 単にアーカイブファイルを展開しただけで使いたい。 かつ、そのWindows 11マシンはユーザー認証付きHTTPプロキシーサーバーを経由しないとDigitalOceanにはアクセスできない。
このような条件で使えるものを探すと、Rcloneが条件を満足するものだった。
まず、Downloadページから、Intel/AMD - 64 BitのWINDOWS用のバイナリーをダウンロードする。 現在のバージョンは、1.74.3なので、rclone-v1.74.3-windows-amd64.zipをダウンロードすれば良い。 これの中にはrclone-v1.74.3-windows-amd64というサブディレクトリーがあるので、それを適当な場所に配置してPATH環境変数に設定しておく。
Rcloneにはインタラクティブに設定ファイルを生成する仕組みがあるが面倒である
C:\Users\(ユーザーID)\AppData\Roaming\rcloneディレクトリーにあるrclone.confに以下のように記載すれば良い。
シンガポールリージョンを使うので、以下ように設定した。
[sg] type = s3 provider = DigitalOcean access_key_id = XXXXXXXXXXXXXXXXXXXX secret_access_key = YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY region = sgp1 endpoint = sgp1.digitaloceanspaces.com acl = private
ここで、DigitalOcean SpacesのコンソールでBucketのAccess Keysを生成した際に表示される「Access Key ID」の値をaccess_key_idに設定し、secret keyの値をsecret_access_keyに設定する。
endpointには、Bucketの「Origin Endpoint」がhttps://BUCKETNAME.sgp1.digitaloceanspaces.comであれば、sgp1.digitaloceanspaces.comを設定する。
同様にregionはsgp1を設定する。
rcloneは、https://のURIへのアクセスには、HTTP_PROXY環境変数が使われないようである。
HTTPS_PROXY環境変数を定義しておく必要がある。
以下のように定義しておく。
HTTPS_PROXY=http://(ユーザーID):(パスワード)@10.11.12.13:8080
ファイルをアップロードするには、以下のように実行すれば良い。
> rclone copy FILETOUPLOAD.txt sg:BUCKETNAME
Bucketにあるファイルを一覧する。
> rclone lsl sg:BUCKETNAME
71 2026-06-25 13:44:06.694000000 FILETOUPLOAD.txt
3255961 2026-06-05 15:23:56.000000000 rclone.1
ファイルをダウンロードする。
> rclone copy sg:BUCKETNAME/FILETOUPLOAD.txt .
あらかじめ起動しておいたMosquittoにPython Paho MQTT library (pkgsrc/net/py-paho-mqtt 2.1.0)を使って、Mosquittoの受信したデータを、InfluxDB 1 (pkgsrc/databases/influxdb)に保存する。 なぜInfluxDBに保存するのかと言うと、最終的にMosquittoで受信したデータをGrafana (pkgsrc/www/grafana)で表示するためである。
乱数をMosquittoに送信し、それを購読して、InfluxDBに保存する。
#!/usr/pkg/bin/python3.14
#
# Subscribe mosquitto MQTT server and store data into InfluxDB 1
#
import time
import random
import ssl
from paho.mqtt.enums import MQTTProtocolVersion
import paho.mqtt.client as mqtt
from influxdb import InfluxDBClient
# Connection information for InfluxDB 1.x
INFLUXDB_HOSTNAME = 'localhost'
INFLUXDB_PORT = 8086
INFLUXDB_DATABASE = 'mqtt001'
INFLUXDB_USERID = 'admin'
INFLUXDB_PASSWORD = 'ADMIN_PASSWORD'
# Connection information of MQTT
MQTT_BROKER = 'MYHOSTNAME'
MQTT_PORT = 8883
MQTT_TOPIC = 'topic/0001'
# Instantiate InfluxDB
influx_client = InfluxDBClient (
host=INFLUXDB_HOSTNAME,
port=INFLUXDB_PORT,
username=INFLUXDB_USERID,
password=INFLUXDB_PASSWORD,
database=INFLUXDB_DATABASE
)
# Create database at first at once
influx_client.create_database(INFLUXDB_DATABASE)
# Callback function for MQTT subscription
def on_message (client, userdata, message):
payload = message.payload.decode('utf-8')
timestamp = int(time.time() * 1000000000) # in ns
# debug print
print (f'Received: {payload}')
json_body = [
{
"measurement": "sensor_data",
"tags": {
"device": "dev001_reg700"
},
"fields": {
"value": float(payload)
},
"time": timestamp
}
]
# Write data to InfluxDB
influx_client.write_points(json_body)
# Create MQTT client
mqtt_client = mqtt.Client(
callback_api_version=mqtt.CallbackAPIVersion.VERSION2,
protocol=MQTTProtocolVersion.MQTTv5
)
# Assign callback function on receiving
mqtt_client.on_message = on_message
# Setup TLS connection
tls_context = ssl.create_default_context()
tls_context.verify_mode = ssl.CERT_REQUIRED
mqtt_client.tls_set_context(tls_context)
# Use user ID and password auth
PUBSUB_ID = 'user001'
PUBSUB_PW = 'password001'
mqtt_client.username_pw_set(
username=PUBSUB_ID,
password=PUBSUB_PW
)
# Connect to broker
mqtt_client.connect(
host=MQTT_BROKER,
port=MQTT_PORT,
keepalive=60
)
# Start to subscribe
mqtt_client.subscribe(topic=MQTT_TOPIC)
## debug print
print (f'Subscribe topic: {MQTT_TOPIC}')
# main loop in another thread
mqtt_client.loop_start()
# Testing publishing
while True:
value = round(random.uniform(10, 30), 2)
mqtt_client.publish(MQTT_TOPIC, str(value))
print(f'Published: {value}')
time.sleep(1)
pkgsrc/net/mosquitto-2.1.2nb1を使う機会があったのだが、なるべく安全な方法で利用したいと思っていた。 TLS証明書を利用して暗号化された経路で通信し、接続にはユーザーIDとパスワードによるユーザー認証を利用し、ユーザー毎にアクセス制限を設定したい。 また、受信した情報はファイルに保存しておきたい。
設定は/usr/pkg/etc/mosquitto.confに書けば良い。
Let's Encryptで取得したTLS証明書が使える。 以下のように設定すれば良い。 これは、pkgsrc/security/acmeshを使って取得したものだが、どのような方法で取得しても良い。
certfile /var/db/mosquitto/.acme.sh/MYHOSTNAME.net_ecc/fullchain.cer keyfile /var/db/mosquitto/.acme.sh/MYHOSTNAME_ecc/app4.ryoon.net.key cafile /var/db/mosquitto/.acme.sh/MYHOSTNAME_ecc/ca.cer
ユーザー毎にアクセス制限を設定するためにも、ユーザーIDとパスワードによりユーザー認証をした上で接続する必要がある。 これは、以下のように設定すれば良い。
password_file /var/db/mosquitto/mosquitto.passwd
この中身は、mosquitto_passwd(1)で生成すれば良い。
以下のようにユーザーIDとパスワードをmosquitto.passwdとして用意しておき、mosquitto_passwdコマンドでパスワードをハッシュ化したファイルに変換すれば良い。
ハッシュアルゴリズムも選択できるようだ。
$ cat mosquitto.passwd user001:password001 user002:password002 $ mosquitto_passwd -U mosquitto.passwd $ cat mosquitto.passwd user001:$7$1000$qmp3mSmMucnEwhH3vLWRLquFBPYVQFdALWJwvihS7UI6d2cTKSma77hbTeYFSoJ+M/WTowwzUg7klW+7ClbNng==$YxIm/PFeBoiCN9xBvV9XR1XWK6VqIJrwE432iX7b5ygnoyKKMRSHf9rk/9Lw02Gp9FWfhwnPU8ugzPJUIDzImA== user002:$7$1000$x8FPjLROciMpi7q7OIkV+cdzEf+Eo02kGMuPaWALcoS9Vt7G9J/um376TaGuSDOj76HSvL8HIla8HHQx7DkJGQ==$3V1pN+4ApuSBPtnyzxfSWSnUb01Q0EjQ6LmkAQb+VetHuxCkcJkzEhQyG2Y6F7MWgG1DqfyrJIWCF7pYqHuquQ==
まず、アクセス制限の内容を読み込むように/usr/pkg/etc/mosquitto.confに以下のように設定する。
acl_file /var/db/mosquitto/mosquitto.acl
その上で、/var/db/mosquitto/mosquitto.aclを以下のように設定する。
user001は全てのトピックに読み書きでき、user002は全てのトピックに書き込みだけできるようにする。
データと投入するクライアントはuser002でアクセスして来ることを想定し、user001で接続することを想定している。
user001は書き込みはできなくても良いのだが。
$ cat /var/db/mosquitto/mosquitto.acl user user001 topic readwrite # user user002 topic write #
/var/db/mosquitto/mosquitto.dbに保存するように設定する。
autosave_interval 60 autosave_on_changes true persistence true persistence_file mosquitto.db persistence_location /var/db/mosquitto
他にも設定してある内容は以下のようだ。
# mosquitto daemonを動かすユーザー user mosquitto # 待ち受けるポート istener 8883 # ログとしてsyslogに出力するレベル log_type debug
最近のFirefoxは他のタブとcookie等と共有しないcontainer tabsという機能がある。 だが、私の使っているFirefoxでは有効になっていなかった。 NetBSDだけでなくWindowsでも同様である。 いずれにしても、利用したい機能ではある...