これはマスター設定というかサーバ全体に効いてしまうため、初期ドメインを含めたマルチドメインに対して全て同一のPHPバージョンを使うことになってしまう。

これは意外に困るのだ。
マルチドメイン可能とはいえ、実際のところひとつのサーバ契約の中に複数ドメインを入れ込むことはほぼない。
しかし、困る場面はPHPのバージョンアップである。
例えばPHP 8.2から8.3へバージョンアップをしたい時には当然試験が必要である。
まぁ「ちょっとくらいサイトが止まってもよい」という覚悟でいきなり上げることもあるかもしれないが、試験を行うのが望ましい。
ここで、ドメイン毎あるいは特定サイトに対して別バージョンのPHPを利用できるならばとても便利。

そんなときは、こんな方法がある。
PHPバージョンを指定したシェルスクリプトを間にはさむやり方だ。

まずは下記の内容をphp.cgiとして、「PHPバージョンを変更したいドキュメントルートに配置する」
----------
#!/bin/sh
exec /usr/local/php/8.2/bin/php-cgi
----------

8.2の部分は利用したいPHPのメジャーバージョン.マイナーバージョン。
sshで接続して、php-cgiが置いてある実際のパスを確認するのが良い。

このシェルスクリプトはパーミッションを705にする。

そして、.htaccessに下記を記述する。
一番上で良いのではないか。
----------
Action myphp-script /php.cgi
AddHandler myphp-script .php .html
----------
AddHandlerの .html は任意。

シェルスクリプトを通してCGIモードで動作させることになる。

さくらサーバーとしてドメイン毎のバージョン変更を管理画面からできれば嬉しいが、できなくしている理由がなにかあるのでしょう。

今回は自身のソースコード管理に使用してみる。

最初にGithubでユーザ登録を行う。
必要なのはメールアドレス、パスワード、ユーザ名。
ログイン後は念のためパスキーを追加し、2要素認証を追加する。

New repositoryからリポジトリを作成する。

visibilityは今回はPrivateにする。自身のコード管理に使うのみ。公開はしない。
.gitignoreは後でも作成できるので、ここでは何もしない。

次に情報漏洩等の対策。安全に。

Copilotに学習させない。

Copilot＞Features＞Privacyで
「Allow GitHub to use my data for AI model training」をDisabledへ変更する。
Copilot＞Features＞Visibilityで
「Show Copilot」をDisabledへ変更する。

Copilot＞Cloud agentで
「Responsitory access」をNo responsitoriesへ変更する。

まずはhttpsで接続するため、パスワードとなるトークン(Personal access token)を追加。

Developer settings＞Personal access tokens＞Fine-grained tokensで
「Generate new token」をクリックする。

ここでもできるだけ安全な方向へ。
・Expirationでトークンの有効期限を設定する。
・Repository accessを「Only select repositories」にして使えるリポジトリを限定する。
・PermissionsではContentsを追加し「Read and write」に設定

作成されたトークンをコピーする。後で使用する。

Create new fileから.gitignoreを作成する。
内容を編集する。
自身のコードではないダウンロードライブラリのようなものは除外する。
またパスワードなどの秘匿事項を記載したファイルも除外する。

あとは、ローカル（Mac）からGithubを使う準備をする。

gitコマンドの確認
git -v
git version 2.50.1 (Apple Git-155)

which git
/usr/bin/git

最新バージョンがあるかと Homebrewでインストール
brew install git

which git
/opt/homebrew/bin/git

git -v
git version 2.50.1 (Apple Git-155)

同じだった・・・。

ローカル(Mac)で初期設定
git config --global user.name ユーザ名
git config --global user.email メールアドレス

~/.gitconfig
が生成される。

一応設定内容を確認する。

ユーザ名を表示させる
git config --global user.name

メールアドレスを表示させる
git config --global user.email

リポジトリをクローンする。
なおcloneを実行するとその場所にリポジトリ名と同じディレクトリが作成される。これを考慮して管理したいソースの位置を決める。
git clone https://github.com/ユーザ名/リポジトリ名.git

リポジトリをPrivateにしたため、ここでユーザ名とパスワード（トークン）を聞かれ入力が必要。

cloneに成功すると必要ファイルが作成される。READMEはいらなかったかも。

あとは、この配下に自分が管理したいソース、例えばpublic_html/等の既存データをコピーする。

git statusで変更ファイルの確認ができる。

gitに追加される予定ファイルを確認する。
git add --dry-run .

秘密ファイルなどが含まれていたら.gitignoreを編集して除外する。解決したら実際にgitにファイルを追加する。
git add .

変更内容を確認する。
git diff --cached
※lessみたいな動作なので "q" で終する。

ローカルでコミットする。
git commit -m "コメント"
最初なので、
git commit -m "初版"
としておく。

次にGithubへアップロード（push）する。
git push origin main

データの取得はpullを使う。
git pull origin main

最後のコミットと現在のローカルの変更を比較する。
git diff HEAD
- は変更前、+ は変更後
特定のファイルだけを比較するにはファイルパスを指定
git diff HEAD -- public_html/index.php

git diff HEADはgit add済みも未実行も含んで比較する。
git diff --cachedはgit add済みのものだけ比較

なお、自宅でサーバを立てるなどISP型ではなく、接続元のIPアドレスを固定したい目的でVPN型から選んだ。

「最短5分で利用開始」をうたっている。本当に5分程度で使えるようになった。
※ステマではありません。

申込後、すぐに管理画面へログインできグローバルIPアドレスが付与される。
無料期間2ヶ月がついており、今はお試し期間になっている。

接続はWireGuardというアプリを使用する。Mac用もWindows用もある。
マニュアルもある
マニュアル）
https://support.vpn.lolipop.jp/hc/ja/articles/37132585319827-WireGuard%E3%81%AE%E8%A8%AD%E5%AE%9A%E6%96%B9%E6%B3%95-Mac
アプリをダウンロードしてインストールする。
つぎにWireGuardの設定ファイルを管理画面からダウンロードする。

設定ファイルはもちろん自分専用。

設定ファイル .conf をWireGuardにインポートする。画像はMacのもの。

「有効化」を押すとすぐに繋がる。ここまで本当に5分くらい。
切断をしたい時には「無効化」をクリックするだけ。

自身のIPアドレスを調べられるサイトで、契約したIPアドレスが表示されることを確認。
すぐ使える。

自分の使い方は、固定IPを使いたいときだけ「有効化」し用事が終わったら「無効化」する。
しかし、ロリポップではルーティング機能も無料で使える。
管理画面のルーティングに、「フルトンネル」か「スプリットトンネル」かを選択できる。

全ネットワーク接続をVPN経由つまり固定IPアドレスで接続するフルトンネルか、特定の接続先に対してのみ固定IPアドレスを使用するスプリットトンネルかの選択ができる。
スプリットトンネルについては、固定IPアドレスでアクセスするIPアドレスまたはURLを登録する。
これだけで切り替わるわけではなく、あくまでもコンフィグファイルをダウンロードして、WireGuard側で切り替える。

両方のプロファイルを登録しておいて、必要な方の接続を有効にすることが可能。

固定IPアドレスを使うことで、ssh接続やWordPressの管理画面ログインに制約を入れたり、セキュリティを高めることが可能。

RustDeskの公開サーバを使用していて決定的に困ることは現在は起きていないが、たまにログインを求められることはある。
自前サーバの利用を試してみたく、やってみることにした。

また、WebARENAの初期構築についても書いた。
VPS利用のためWebARENA Indigoを使用してみる
VPS利用のためWebARENA Indigoを使用してみる　その2

自前サーバ「セルフホスト」に関するドキュメントは下記
https://rustdesk.com/docs/ja/self-host/

ちょっと難しいのと、前回記事に書いた通り、
WebARENA＋ubuntu用として、ChatGPTに聞くと下記の手順を示された。
Step 1　WebARENA側のVPSを確認
Step 2　Ubuntuの初期確認・アップデート
Step 3　Dockerをインストール
Step 4　RustDesk Serverの配置・設定
Step 5　RustDesk Serverの起動・動作確認
Step 6　RustDeskクライアントを自前サーバーへ接続
Step 7　運用設定・最終確認

今回はいよいよ本丸というかStep 3から進める。

Step 3　Dockerをインストール

まずはDockerが入っているかどうか確認
$ docker --version
Command 'docker' not found, but can be installed with:
sudo snap install docker # version 29.8.0, or
sudo snap install docker # version 29.6.1
sudo apt install docker.io # version 29.1.3-0ubuntu3~24.04.2
sudo apt install podman-docker # version 4.9.3+ds1-1ubuntu0.2
See 'snap info ' for additional versions.

入っていない。
親切にインストール手順まで案内してくれている。
しかし、今回はRustDesk向けなので、RustDesk公式ドキュメントが推奨する下記の方法に準じてインストールすることにした。

(1)bash <(wget -qO- https://get.docker.com)
(2)wget rustdesk.com/oss.yml -O compose.yml
(3)sudo docker compose up -d

ここでもう少し丁寧にする。
・(1)に関してはインストール用スクリプトの中身を見てから実行するため、一旦ファイルに保存する手順とする。
　まぁ見てもあまりわからなかったけど。
・2回目のwget前にRustDeskディレクトリを作成し移動。
・2回目のwgetではhttps:// を明確に補うことにした。
・最後にコンテナ起動の前にdocder compose configで構文を確認する手順を入れた。
(1)wget https://get.docker.com -O get-docker.sh
(2)sudo sh get-docker.sh
(3)mkdir RustDesk
(4)cd RustDesk
(5)wget https://rustdesk.com/oss.yml -O compose.yml
(6)compose.ymlの内容を編集
(7)sudo docker compose config
(8)sudo docker compose up -d

Step 3　(1)(2)
Step 4　(3)(4)(5)(6)(7)
Step 5　(8)
とする。

(1)インストーラーをダウンロードしローカルに保存
$ wget https://get.docker.com -O get-docker.sh
--2026-09-19 21:40:13-- https://get.docker.com/
Resolving get.docker.com (get.docker.com)... 13.249.165.103, 13.249.165.78, 13.249.165.12, ...
Connecting to get.docker.com (get.docker.com)|13.249.165.103|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 23731 (23K) [text/plain]
Saving to: ‘get-docker.sh’

get-docker.sh 100%[===================================================>] 23.17K --.-KB/s in 0s
2026-09-19 21:40:14 (86.1 MB/s) - ‘get-docker.sh’ saved [23731/23731]

Dockerのインストーラーとなるスクリプトが get-docker.shとして保存された。

(2)インストーラーを実行
$ sudo sh get-docker.sh
を実行しインストール。

インストールされたかどうかを確認
$ docker --version
Docker version 29.8.1, build 4a63305

$ sudo docker compose version
Docker Compose version v5.5.1

Step 4　RustDesk Serverの配置・設定

(3)作業ディレクトリ作成
mkdir RustDesk

(4)作業ディレクトリへ移動
cd RustDesk

(5)設定ファイルをダウンロードしローカルに保存
$ wget https://rustdesk.com/oss.yml -O compose.yml
--2026-09-20 07:38:24-- https://rustdesk.com/oss.yml
Resolving rustdesk.com (rustdesk.com)... 172.66.167.80, 104.20.19.94, 2606:4700:10::ac42:a750, ...
Connecting to rustdesk.com (rustdesk.com)|172.66.167.80|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 402 [application/octet-stream]
Saving to: ‘compose.yml’

compose.yml 100%[===================================================>] 402 --.-KB/s in 0s
2026-09-20 07:38:24 (108 MB/s) - ‘compose.yml’ saved [402/402]

compose.ymlが保存された。

(6)compose.ymlの内容を編集

hbbsに常にリレーにするALWAYS_USE_RELAY=Yを入れる。後からわかったことだが、試験のときログに残らず本当に自前サーバを通っているのか？ となった。ChatGPTが言うには、P2Pが使えるときはリレーにならずログに残らないのではないかとのこと。公開サーバではなく自前サーバでリレーされていることを確認するために、一旦入れて、最後には外す。
もうひとつ、hbbrに公開鍵を登録する。
公開鍵は data/id_ed25519.pub に保存されたファイルの内容（文字列）

編集前

services:
  hbbs:
    container_name: hbbs
    image: rustdesk/rustdesk-server:latest
    command: hbbs
    volumes:
      - ./data:/root
    network_mode: "host"
    depends_on:
      - hbbr
    restart: unless-stopped

  hbbr:
    container_name: hbbr
    image: rustdesk/rustdesk-server:latest
    command: hbbr
    volumes:
      - ./data:/root
    network_mode: "host"
    restart: unless-stopped

編集後

services:
  hbbs:
    container_name: hbbs
    image: rustdesk/rustdesk-server:latest
    environment:
      - ALWAYS_USE_RELAY=Y
    command: hbbs
    volumes:
      - ./data:/root
    network_mode: "host"
    depends_on:
      - hbbr
    restart: unless-stopped

  hbbr:
    container_name: hbbr
    image: rustdesk/rustdesk-server:latest
    environment:
      - KEY=<公開鍵>
    command: hbbr
    volumes:
      - ./data:/root
    network_mode: "host"
    restart: unless-stopped

(7)設定ファイルのチェック
sudo docker compose config

name: rustdesk
services:
  hbbr:
    command:
      - hbbr
    container_name: hbbr
    environment:
      KEY: <公開鍵>
    image: rustdesk/rustdesk-server:latest
    network_mode: host
    restart: unless-stopped
    volumes:
      - type: bind
        source: /home/ubuntu/RustDesk/data
        target: /root
        bind: {}
  hbbs:
    command:
      - hbbs
    container_name: hbbs
    depends_on:
      hbbr:
        condition: service_started
        required: true
    environment:
      ALWAYS_USE_RELAY: 'Y'
    image: rustdesk/rustdesk-server:latest
    network_mode: host
    restart: unless-stopped
    volumes:
      - type: bind
        source: /home/ubuntu/RustDesk/data
        target: /root
        bind: {}

設定が正しいこと、エラーがないことを確認する。

Step 5　RustDesk Serverの起動・動作確認

(8)コンテナの起動
(cd RustDesk)
sudo docker compose up -d

[+] up 6/6
Image rustdesk/rustdesk-server:latest Pulled 3.6s
Container hbbr Started 0.5s
Container hbbs Started 0.5s

正常に起動する。

(9)コンテナが起動されていることの確認
$ sudo docker compose ps
NAME IMAGE COMMAND SERVICE CREATED STATUS PORTS
hbbr rustdesk/rustdesk-server:latest "hbbr" hbbr About a minute ago Up About a minute
hbbs rustdesk/rustdesk-server:latest "hbbs" hbbs About a minute ago Up About a minute

起動している

(10)ログを確認
$ sudo docker compose logs --tail=50
特にエラー等はなし。

(11)必要ポートの状態を確認
$ sudo ss -lntup | grep -E ':(21115|21116|21117|21118|21119)\b'
udp UNCONN 0 0 *:21116 : users:(("hbbs",pid=5392,fd=17))
tcp LISTEN 0 128 *:21119 : users:(("hbbr",pid=5345,fd=10))
tcp LISTEN 0 128 *:21118 : users:(("hbbs",pid=5392,fd=20))
tcp LISTEN 0 128 *:21117 : users:(("hbbr",pid=5345,fd=9))
tcp LISTEN 0 128 *:21116 : users:(("hbbs",pid=5392,fd=18))
tcp LISTEN 0 128 *:21115 : users:(("hbbs",pid=5392,fd=19))

TCP　21115-21119はLISTEN、UDP 21116は待ち受けになっていて正常。

一方WebARENAではファイアウォールを入れている。

TCP 21115-21117とUDP 21116は通す。TCP 21118-21119は通さない。

(12)外部からポートへのアクセスを確認
★TCP側確認
自分の端末(Mac)のターミナルから
$ nc -vz <VPSのIPアドレス> 21115
Connection to <VPSのIPアドレス> 21115 port [tcp/] succeeded!
$ nc -vz <VPSのIPアドレス> 21116
Connection to <VPSのIPアドレス> 21116 port [tcp/] succeeded!
$ nc -vz <VPSのIPアドレス> 21117
Connection to <VPSのIPアドレス> 21117 port [tcp/*] succeeded!

すべて疎通成功。

★UDP側確認
VPSでポートを監視状態にする
sudo tcpdump -ni any udp port 21116

ログが流れているが、止めずにそのまま。

自分の端末(Mac)からVPSのポートへecho
echo test | nc -u -w1 <VPSのIPアドレス> 21116

VPSに下記のような行がでればOK。
ens10 In IP <端末のIPアドレス>.<端末のポート> > <VPSのIPアドレス>.21116: UDP, length 5

ここまででRustDeskサーバの起動と必要ポートのアクセスが確認できた。

Step 6　RustDeskクライアントを自前サーバーへ接続

遠隔操作をする側、遠隔操作をされる側の両方（どちらもRustDeskクライアントという）で、自前サーバへ繋ぐ設定をする。
RustDeskを起動し、[設定]＞[ネットワーク]＞[認証/中継サーバー]
認証サーバ：サーバIPアドレス
中継サーバ：サーバIPアドレス
APIキー：空欄
Key：公開鍵

サーバでは下記のコマンドでポート21116を監視状態で待機させる。

sudo tcpdump -ni any host <サーバIPアドレス> and port 21116

すると、下記のような行が出て待機させる。

tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes

ここで、クライアントのRustDeskを再起動すると、ダンプの行が増えていく。
----------
23:59:45.516564 ens10 In IP <クライアントIPアドレス>.36459 > <サーバIPアドレス>.21116: UDP, length 15 23:59:45.516709 ens10 Out IP <サーバIPアドレス>.21116 > <クライアントIPアドレス>.36459: UDP, length 2 23:59:52.660607 ens10 In IP <クライアントIPアドレス>.23996 > <サーバIPアドレス>.21116: Flags [F.], seq 1, ack 1, win 2057, options [nop,nop,TS val 2888007100 ecr 3963494463], length 0 23:59:52.660828 ens10 Out IP <サーバIPアドレス>.21116 > <クライアントIPアドレス>.23996: Flags [F.], seq 1, ack 2, win 510, options [nop,nop,TS val 3963512531 ecr 2888007100], length 0 23:59:52.685546 ens10 In IP <クライアントIPアドレス>.23996 > <サーバIPアドレス>.21116: Flags [.], ack 2, win 2057, options [nop,nop,TS val 2888007128 ecr 3963512531], length 0 23:59:52.702757 ens10 In IP <クライアントIPアドレス>.23861 > <サーバIPアドレス>.21116: Flags [S], seq 4765219, win 65535, options [mss 1412,nop,wscale 6,nop,nop,TS val 2313083021 ecr 0,sackOK,eol], length 0 23:59:52.702827 ens10 Out IP <サーバIPアドレス>.21116 > <クライアントIPアドレス>.23861: Flags [S.], seq 1059828799, ack 4765220, win 65160, options [mss 1460,sackOK,TS val 3963512573 ecr 2313083021,nop,wscale 7], length 0 23:59:52.730407 ens10 In IP <クライアントIPアドレス>.23861 > <サーバIPアドレス>.21116: Flags [.], ack 1, win 2057, options [nop,nop,TS val 2313083048 ecr 3963512573], length 0
----------

RustDeskクライアントからhbbs の21116へ通信していることが確認できた。
操作する側のクライアントと操作される側のクライアントそれぞれでこの確認を行う。

この後は実際にクライアント同士を接続して、遠隔操作できる状態を作る。
実際に問題なくつながった。
では、「本当に自前サーバを経由しているか」をサーバ上でどう確認するかである。

ChatGPTからは、
cd ~/RustDesk
sudo docker compose logs --tail=50 hbbs hbbr
これで、ログに現れるはずだと最初言われた。しかし、何も残らなかったのだ。
そこで、P2Pでいけるときは hbbr経由(リレー)しないのではないか？ との推論のもと、
compose.ymlに
environment:
- ALWAYS_USE_RELAY=Y
を「テスト用に」入れた次第だ。

ALWAYS_USE_RELAY=Y
のときは必ずリレーされ、
sudo docker compose logs --tail=50 hbbs hbbr
のログに下記のような接続がのこる。

----------
hbbr | [2026-09-21 05:48:50.573495 +00:00] INFO [src/relay_server.rs:453] New relay request <リクエストID> from [::ffff:<操作する側IPアドレス>]:63750
hbbr | [2026-09-21 05:48:50.681926 +00:00] INFO [src/relay_server.rs:437] Relayrequest <リクエストID> from [::ffff:<操作される側IPアドレス>]:14219 got paired
hbbr | [2026-09-21 05:48:50.681994 +00:00] INFO [src/relay_server.rs:443] Both are raw
----------

これで自前サーバを使っていることが確認できた。

最終的には、
environment:
- ALWAYS_USE_RELAY=Y
を削除し、
Docker Composeを再起動
sudo docker compose up -d

Step 7　運用設定・最終確認

サーバ再起動後にも、Dockerが起動されるかどうかの確認。
コマンドは下記。

sudo systemctl is-enabled docker

enabled となれば問題ない。
しかし、実際にVPSを再起動してRustDesk再接続まで確認する。

その続き。

目的はRustDeskのサーバとして整えること。
その途中でVPSサーバが正常に使えることが必須であったため、ちょっと記事をひとつ挟んでおく。

WebARENA＋ubuntu用として、ChatGPTに聞くと下記の手順を示された。
Step 1　WebARENA側のVPSを確認
Step 2　Ubuntuの初期確認・アップデート
Step 3　Dockerをインストール
Step 4　RustDesk Serverの配置・設定
Step 5　RustDesk Serverの起動・動作確認
Step 6　RustDeskクライアントを自前サーバーへ接続
Step 7　運用設定・最終確認

今回はStep 1とStep2について書く。

Step 1 WebARENA側のVPSを確認

下記を確認
・OS
・グローバルIPがわかっていること。
・ssh接続ができていること。

これらは前回確認できている。

Step 2　Ubuntuの初期確認・アップデート

Step 1との重複もあるが、

(1)OSとバージョン確認
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 24.04 LTS
Release: 24.04
Codename: noble

(2)CPU・メモリ確認
$ free -h
total used free shared buff/cache available
Mem: 961Mi 290Mi 249Mi 976Ki 572Mi 671Mi
Swap: 0B 0B 0B

(3)ディスク容量確認
$ df -h
Filesystem Size Used Avail Use% Mounted on
tmpfs 97M 964K 96M 1% /run
/dev/vda1 19G 1.5G 17G 8% /
tmpfs 481M 0 481M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
/dev/vda16 881M 61M 758M 8% /boot
/dev/vda15 105M 6.1M 99M 6% /boot/efi
tmpfs 97M 12K 97M 1% /run/user/1000

(4)現在のユーザー確認
$ whoami
ubuntu

(5)時刻とタイムゾーン
現在の確認
$ date
Sat Sep 19 22:00:27 UTC 2026
$ timedatectl
Local time: Sat 2026-09-19 22:02:45 UTC
Universal time: Sat 2026-09-19 22:02:45 UTC
RTC time: Sat 2026-09-19 22:02:45
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

UTCになっているので、タイムゾーンをTokyoに変更する。
$ sudo timedatectl set-timezone Asia/Tokyo

変更されたかどうか確認
$ date
Sun Sep 20 07:05:37 JST 2026
$ timedatectl
Local time: Sun 2026-09-20 07:05:47 JST
Universal time: Sat 2026-09-19 22:05:47 UTC
RTC time: Sat 2026-09-19 22:05:47
Time zone: Asia/Tokyo (JST, +0900)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

(6)アップデート確認
$ sudo apt update
Hit:1 http://security.ubuntu.com/ubuntu noble-security InRelease
Hit:2 http://archive.ubuntu.com/ubuntu noble InRelease
Get:3 http://archive.ubuntu.com/ubuntu noble-updates InRelease [126 kB]
Hit:4 http://archive.ubuntu.com/ubuntu noble-backports InRelease
Get:5 http://archive.ubuntu.com/ubuntu noble-updates/main amd64 Packages [1275 kB]
Fetched 1401 kB in 2s (597 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
343 packages can be upgraded. Run 'apt list --upgradable' to see them.

パッケージリストの更新完了。

(7)アップグレード実施
$ sudo apt upgrade
Processing triggers for libc-bin (2.39-0ubuntu8.9) ...
Scanning processes... Scanning candidates... Scanning linux images...
Pending kernel upgrade!
Running kernel version:
6.8.0-31-generic
Diagnostics:
The currently running kernel version is not the expected kernel version 6.8.0-139-generic.

Restarting the system to load the new kernel will not be handled automatically, so you should consider rebooting.

Restarting services...
systemctl restart cron.service

Service restarts being deferred:
/etc/needrestart/restart.d/dbus.service
systemctl restart getty@tty1.service
systemctl restart serial-getty@ttyS0.service
systemctl restart systemd-logind.service
systemctl restart unattended-upgrades.service

No containers need to be restarted.

User sessions running outdated binaries:
ubuntu @ session #34: apt[2915], sshd[2215,2313]
ubuntu @ user manager service: systemd[1873]

No VM guests are running outdated hypervisor (qemu) binaries on this host.

アップグレードは正常に終了。
注意すべきは、
「インストールした6.8.0-139-generic.ではなく、古い6.8.0-31-genericが動いている。
　新しいカーネルを読み込むには再起動をしなさい。」
的なことですね。

一応、カーネルバージョンを調べる。
$ uname -r
6.8.0-31-generic
古いまま。

再起動をかける。
$ sudo shutdown -r now

たいして時間がかからず再起動でき、再度ssh接続してカーネルバージョンを再確認。
$ uname -r
6.8.0-139-generic

これでアップグレードが完了。

ここまでで、RustDeskサーバとして使用するためのVPSサーバのセットアップが完了。
RustDesk関係なくても、OSアップデートは必須だったかな。

次はDockerの話などを書く。

webから申込を行う。
途中まで進めて、クレジットカード登録が平日の日中（9:00〜16:00だったかな？）のみとして以降進めなくなる。
夜間に登録を進めたらその場で完結できず、後日平日日中にログインしてから決済のみを進めて登録を完了。

また、カード登録した直後に10,000円の決済があったかのような速報通知がカード会社からあり焦る。
申し込むものを間違えたのかと思った。
どうも、オーソリのみと思われ確定通知(決済)は今のところ来ていない。
これはFAQに書いて欲しい。

以後は、オンラインマニュアルの「スタートアップガイド（Indigo）」に沿って進める。
https://help.arena.ne.jp/hc/ja/sections/360009023513-%E3%82%B9%E3%82%BF%E3%83%BC%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E3%82%AC%E3%82%A4%E3%83%89

ダッシュボードにログインし、さらにコントロールパネルにログインする。

まずはSSH鍵の作成。既存の鍵を使うことも可能。
新規作成すると、公開鍵がサーバ上に登録され、秘密鍵private_key.txtがローカルにダウンロードされる。

次にインスタンスを作成する。

もちろん最初はインスタンスが何もない。

OSはUbuntuを選択。
サイズの選択が要注意。まさにここで費用が変わる。今回は最小構成の1vCPU、1GBメモリを選択。
あとは、最初に作成（または登録）したSSH鍵を指定、インスタンス名を決める。

次画面でステータスが「OSインストールを実行中です」となる。
1分ぐらい後に画面リロードするとステータスが「Stopped」となってインストールが完了した様子。
すぐに使えるのは良い。

インスタンスを起動するとステータスが「Running」に変わる。

次はsshで接続する。
ダウンロードした秘密鍵を適切な場所に置く。
自分は~/.sshに置くことにしている。
そしてパーミッション600に変える。
これを忘れて使おうとすると怒られる。（大抵初回忘れて怒られる）
Permissions 0644 for '.ssh/private_key.txt' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key ".ssh/private_key.txt": bad permissions

ポート番号は22なので省略。
インスタンスをUbuntuで作成したので、ユーザ名がubuntuになるとのこと。ユーザ名はOS毎に変わることがマニュアルに書いてある。
ssh ubuntu@IPアドレス -i ~/.ssh/private_key.txt
問題なくssh接続ができた。

次に、ファイアウォール設定を行う。
ファイアウォールを有効化すると、pingが通らなることと、ssh接続もできなくなる旨注意事項に記載がある。

インバウンドルールのところに、下記の文言がある。
「インバウンドルールを設定することで、指定したポートへのアクセスは指定したIPアドレスからのみアクセスが可能になります。それ以外のアクセスは拒否されます。」
sshを通したいのであれば、ポート22を許可する必要がある。
タイプ：カスタム
プロトコル：TCP
ポート：22
IPアドレス：アクセスを許容するIPアドレス

ファイアウォールの利用は任意であるが、利用しないとあらかたのポートが空いている状態なのだと思う。

初期設定として最低限はここまで。
次は目的としていた、RustDeskのサーバ構築を試したい。

モニタには信号なし(No Signal)が出る。
サインイン画面やデスクトップが表示される前だ。
スリープしているのか、電源が落ちているのかイマイチわからない。
電源ランプは消えて、CPUファンも回っていないので、どちらかといえば落ちているように見える。
この状態で、電源ボタンをもう一度おしても電源が入らない。
逆に電源が完全には落ちきっていないのでは？と思い電源ボタンを30秒程度長押しするものの、何も反応はない。
反応がないのでACケーブルを抜いてもう一度挿す。
そうすれば電源ボタンが反応するが、症状は同じ。

最終的には、電源ユニットの交換で症状が改善した。
たどり着くまでには様々試した。

最初の症状を見て、ハードウェア不具合寄りかな？ ソフトウェア側の問題の可能性は低いのではと考えた。

はじめに試したこと

• 静電気除去
• メモリの抜き差し
• BIOS電池の交換

これらでは改善せず

ソフトウェア的なこと

• DELLのDiagnostics → 問題は検出されず
• 回復ドライブ(WinRE)からスタートアップ修復 → 修復できません
• 回復ドライブからコマンドプロンプトで sfc /scannow
• システムの復元 → 復元ポイントがなく実施できず

ここまでで症状が改善せず。

ここから、問題切り分けフェーズへ。

• 回復ドライブで起動し40分以上放置 → 症状出ず
  ということは、ハードウェアの問題ではないかも？
• Windowsをセーフモードで起動する → 正常に起動ができてデスクトップが表示される。
  また、起動途中で「更新が進行中です。コンピュータの電源を入れたままにしてください。」の表示。
  Windows Updateの途中で電源が落ちたか、失敗して中途半端になっているか？
  ということで、ソフトウェアの問題かも？
• セーフモードのイベントビューアーで Windowsログ＞システムにて、起動ができていなかった時間帯は不穏なログはなかったが、直前には「Trend Micro Security Agent サービスは予期せぬ原因により終了しました。このサービスの強制終了は40回目です。」これが直接の原因かどうかはわからないが、セーフモードでは起動できたということは、疑わしい。
• セーフモードで再度 sfc /scannow → 「Windows リソース保護により、破損したファイルが見つかりましたが、それらは正常に修復されました」
  何かしら破損があったと考えられる。
• ファイルシステムが修復されたことを期待して、再度通常起動を試す。 → 同じ症状が発生。
  sfc /scannow の効果が直接は見られなかった。
• セーフモード起動へ戻して、次回のクリーンブートを設定する。つまり、msconifgの「サービス」で「Microsoft のサービスをすべて隠す」にチェックをしたうえで、すべてのサービスをを無効にする。
  セーフモードでは起動ができて、通常起動では起動できないわけなので、かなり期待をしてクリーンブートでもう一度通常起動を試す。 → 同じ症状が発生。

セーフモードでは起動できるわけだから、何らかのサービスやドライバロードが原因と推理をしたのに、この辺でたいぶ途方にくれる。
手動で無効にしたサービス以外にもセーフモードと通常起動に差があるのか？

この後、また状況が少し変わる。

• これまで15回から20回くらい回復ドライブ起動に成功していたが、初めて失敗する。
  Dell SupportAssistが起動してしまい、「Error: OS_BOOT_FAILURE」の表示。
  「START REPAIR」へ進むも、失敗。
  次に複数の復元ポイントが示されて、選択をして進めるも失敗
  

「RESET OPTIONS」は初期化させられるかもしれないのでやめておいた。

• 次は、ブートログをとることにした。

bcdedit /set {default} bootlog Yes

BOOTLOG_LOADED \SystemRoot\System32\DriverStore\FileRepository\iigd_dch.inf_amd64_4505016f6d2dbeec\igdkmd64.sys
BOOTLOG_LOADED \SystemRoot\System32\Drivers\fastfat.SYS
BOOTLOG_LOADED \SystemRoot\system32\drivers\ucx01000.sys
BOOTLOG_LOADED \SystemRoot\System32\drivers\USBXHCI.SYS
BOOTLOG_LOADED \SystemRoot\System32\DriverStore\FileRepository\heci.inf_amd64_e0e9fcf6c047b9a7\x64\TeeDriverW10x64.sys
BOOTLOG_LOADED \SystemRoot\System32\Drivers\ExecutionContext.sys
BOOTLOG_LOADED \SystemRoot\system32\drivers\netadaptercx.sys
BOOTLOG_LOADED \SystemRoot\System32\DriverStore\FileRepository\rt68cx21x64.inf_amd64_3c5d2ae8aa766e19\rt68cx21x64.sys
BOOTLOG_LOADED \SystemRoot\System32\drivers\RtsPer.sys
BOOTLOG_LOADED \SystemRoot\system32\DRIVERS\wdiwifi.sys
BOOTLOG_LOADED \SystemRoot\System32\drivers\Netwtw04.sys
BOOTLOG_LOADED \SystemRoot\System32\DriverStore\FileRepository\netvwifibus.inf_amd64_ab4e111fe8221178\vwifibus.sys
BOOTLOG_LOADED \SystemRoot\System32\drivers\HDAudBus.sys
BOOTLOG_LOADED \SystemRoot\System32\Drivers\msgpioclx.sys
BOOTLOG_LOADED \SystemRoot\System32\drivers\iaLPSS2i_GPIO2.sys
BOOTLOG_LOADED \SystemRoot\System32\drivers\intelppm.sys
BOOTLOG_LOADED \SystemRoot\System32\DriverStore\FileRepository\acpipagr.inf_amd64_d1093347a27ff89c\acpipagr.sys
BOOTLOG_LOADED \SystemRoot\System32\drivers\wmiacpi.sys
BOOTLOG_LOADED \SystemRoot\System32\DriverStore\FileRepository\uefi.inf_amd64_8681c4be783af156\UEFI.sys
BOOTLOG_LOADED \SystemRoot\System32\drivers\DellInstrumentation.sys
BOOTLOG_LOADED \SystemRoot\System32\drivers\NdisVirtualBus.sys
BOOTLOG_LOADED \SystemRoot\System32\DriverStore\FileRepository\swenum.inf_amd64_8b9dd76f362e3ec6\swenum.sys
BOOTLOG_LOADED \SystemRoot\System32\drivers\rdpbus.sys
BOOTLOG_LOADED \SystemRoot\System32\drivers\UsbHub3.sys
BOOTLOG_LOADED \SystemRoot\system32\drivers\RTKVHD64.sys
BOOTLOG_LOADED \SystemRoot\system32\drivers\ksthunk.sys
BOOTLOG_LOADED \SystemRoot\System32\DriverStore\FileRepository\intcdaud.inf_amd64_14fc346f005b7296\IntcDAud.sys
BOOTLOG_LOADED \SystemRoot\System32\DriverStore\FileRepository\ibtusb.inf_amd64_930110eceb58f65b\ibtusb.sys
BOOTLOG_LOADED \SystemRoot\System32\drivers\BTHport.sys
BOOTLOG_LOADED \SystemRoot\System32\drivers\BTHUSB.sys
BOOTLOG_LOADED \SystemRoot\System32\drivers\USBSTOR.SYS
BOOTLOG_LOADED \SystemRoot\System32\drivers\hidusb.sys
BOOTLOG_LOADED \SystemRoot\System32\drivers\kbdhid.sys
BOOTLOG_LOADED \SystemRoot\System32\drivers\kbdclass.sys
BOOTLOG_LOADED \SystemRoot\System32\drivers\mouhid.sys
BOOTLOG_LOADED \SystemRoot\System32\drivers\mouclass.sys
BOOTLOG_NOT_LOADED \SystemRoot\System32\drivers\dxgkrnl.sys
BOOTLOG_LOADED \SystemRoot\System32\drivers\rfcomm.sys
BOOTLOG_LOADED \SystemRoot\System32\drivers\BthEnum.sys
BOOTLOG_LOADED \SystemRoot\System32\drivers\bthpan.sys
BOOTLOG_LOADED \SystemRoot\System32\drivers\Microsoft.Bluetooth.Legacy.LEEnumerator.sys
BOOTLOG_LOADED \SystemRoot\System32\drivers\HfAudio.sys
BOOTLOG_LOADED \SystemRoot\System32\drivers\ScrHIDDriver2.sys
BOOTLOG_LOADED \SystemRoot\System32\drivers\monitor.sys
BOOTLOG_LOADED \SystemRoot\System32\cdd.dll
BOOTLOG_NOT_LOADED \SystemRoot\System32\drivers\dxgkrnl.sys

終わりの方を抜粋してChatGPTへ相談すると、通常起動のかなり後ろの方まで進んでいるとのこと。

画面が暗くなったことから、グラフィックドライバの問題か？ の疑いに対しては、
Intel UHD Graphicsドライバ (igdkmd64.sys) が正常にロードされている。
ロードされているものの、その後の初期化に失敗しているのか？
に対しては、デバイスマネージャーでIntel UHD Graphicsを無効化して通常起動を試す。→ 変わらず問題発生。
グラフィックドライバの不具合は排除できそうだ。

• CBS.logを確認する → 決定的なログはなし
  findstr /c:"[SR]" %windir%\Logs\CBS\CBS.log > "%USERPROFILE%\Desktop\SFC_Detail.txt"

もう一度まとめる。

・BIOS Diagnostics：問題なし
・WinRE（回復環境）：40分以上安定
・WinRE（回復環境）：起動せずにSupportAssistが起動することがあった、別の機会では同じくロードの手前で落ちることがあった
・セーフモード：起動できる
・クリーンブート：改善なし
・sfc /scannow：修復済み
・ブートログ：カーネル・主要ドライバは読み込み済み
・Intel UHD Graphics無効：改善なし
・CBS.log：決定的な異常なし
・chkdsk：改善なし

ソフトウェア要因については、もうできることが少なくなってきた。

たまたま互換の電源ユニットがあったため、交換をしてみたら通常起動できた。

今回の対象機種
Vostro 3681、電源 MODEL NO：H200EBS-00

交換電源
Vostro 3470、電源 MODEL NO：L200EBS-00

通常起動では問題が発生し、セーフモードや回復ドライブ起動では問題発生確率が低い点については、

電源ユニットの電源低下、容量低下等の問題で、途中で落ちていたのではないかという仮説。
通常起動ではセーフモードに比べて各種ロードが一斉に発生し、耐えられなかったのではないか。

電源が落ちた後で入れ直す時、電源ボタンを普通に押しても反応がなく、30秒程度長押しをしても何も起こらずACケーブルを拭き挿ししないと反応しなかった点については、異常状態が発生したため保護回路が動いたのではないかという仮説。

過電流、過電圧、低電圧、過熱などの異常で、電源ユニットが出力を止めることがあるらしい。
ACケーブルを抜かなければ回復しなかったのは理解できた。

「ACを抜かないと電源ボタンが反応しない」が大きなカギだったわけだ。保護回路の動きを知っていれば、早い段階で電源ユニットを疑うことができたかなと。まぁこれも経験か。

(1)起動方法1　設定から

設定＞システム＞回復で
「PCの起動をカスタマイズ」の今すぐ再起動をクリックする。

青い画面の回復メニューから

トラブルシューティング＞詳細オプション＞スタートアップ設定＞再起動＞数字の4
とたどる。

トラブルシューティング

詳細オプション

スタートアップ設定

再起動

数字の4を押す。

(2)起動方法2　Shift+再起動

Windows のスタートメニューから再起動を行う時、キーボードのShift(シフト)キーを押しながら再起動をクリックする。
そうすると、(1)と同じく回復メニューが起動する。

さて、上記2つの起動方法はWindowsが起動できているときにできること。つまりOSは起動できているが何か不調があるときに、セーフモードでも発生するかどうかを見極める場合。
問題はWindowsが通常起動できないときにセーフモードを起動したい場合。これは、セーフモードならば起動するのではないかと見極める場合。

(3)起動方法3　USB回復ドライブから起動モードを変更する

事前に回復ドライブを作成しておく。まぁ経験上、別の端末で作成した回復ドライブでも動かなかったことはない。

USBでWinREを起動する。ここで(1)、(2)の手順と同じく「スタートアップ設定」があればもちろんそれを選んで進めば良い。
「スタートアップ設定」がない場合には、詳細オプションの後にコマンドプロンプトと起動する。

まずは、Windowsがどのドライブに入っているかを調べる。Windowsが通常起動できてるときはc:ドライブであることがほとんどだが、USBブートした時には復旧対象ドライブがc:以外になっていることがある。
diskpartを起動して
list volume
で調べても良いし、dir c:、dir d:、dir e:・・と見ていってそれらしいドライブにあたりを付けても良い。

対象がc:ドライブであるとき、
cd c:
c:
bcdedit /set {default} safeboot minimal
exit　※任意

を実行する

通常はドライブ変更はプロンプトで c: のみで良さそうなところ、cd c: を入れないとうまく行かなかった（ことがあった）

bcdeditを使って、次回以降必ずセーフモードで起動となる。
諸々おわったら、通常起動へ戻す必要がある。

以下セーフモード関連のコマンド。

★セーフモードを有効にする
bcdedit /set {default} safeboot minimal

★セーフモード起動を通常起動へ戻す
bcdedit /deletevalue {default} safeboot

★セーフモードとネットワークを有効にする。スタートアップ設定では「5」に相当。
bcdedit /set {default} safeboot network

★セーフモードとコマンドプロンプトを有効にする。スタートアップ設定では「6」に相当。
bcdedit /set {default} safeboot minimal
bcdedit /set {default} safebootalternateshell yes

ついでに起動のログをとる場合のコマンド
bcdedit /set {default} bootlog Yes

ログは
C:\Windows\ntbtlog.txt

内容は下記のような。ロードされたドライバー、ロードされなかったドライバーなどが記録されている。

BOOTLOG_LOADED \SystemRoot\System32\drivers\ScrHIDDriver2.sys BOOTLOG_LOADED \SystemRoot\System32\drivers\monitor.sys BOOTLOG_LOADED \SystemRoot\System32\cdd.dll BOOTLOG_NOT_LOADED \SystemRoot\System32\drivers\dxgkrnl.sys

winmail.datの件は受け取る側の問題であると、当時は思っていた。

もう少し時間が経ち、2010年から11年頃、WindowsのWindwos Live Mailでも同じ問題が起きていると知る。
添付ファイルを送ったと本文に書いてあるが、何も付いていない、winmail.datがあるだけそして開けないということがよく起きていた。

OutlookもWindows Live Mailも同じ会社が作っているはずなのに、こんなことがあるのだろうか。

まぁ、文字化けについては本文がshift-jisのままcharsetをjisで送るとか、機種依存文字の問題とかやっぱり送る側に原因があった可能性が高いが。
そんなことを考えていたが、winmail.dat問題は2026年まだ起きている。

ChatGPTに聞くと30年以上前1990年代から30年以上も続いている問題とのこと。

本質としては、Outlookがインターネット標準ではない独自形式（TNEF）を使い続けていることにある。Outlook同士であれば問題が起きない。というか問題があることに送る側も受ける側も気が付かない。

winmail.datは単なる添付ファイルではなく、Microsoft独自形式のコンテナ、TNEF (Transport Neutral Encapsulation Format)だというのだ。

中身は、
本文の書式、フォント情報、添付ファイル、会議出席依頼、Outlook独自のプロパティ、投票ボタン、重要度、Outlook専用フラグ

こんなものが人まとまりになったデータとのことだ。

送る側がOutlookのオプションでメッセージを「リッチテキスト」ではなく「HTML形式」にすると直る、という対応指南をよく見かける。

しかし、現実には、これだけでは直らない。

メッセージ形式を「HTML形式」にしていても、Microsoft Exchange、連絡先（アドレス帳）の形式、組織ポリシーといった別の要因により、Outlookが勝手にまたは独自のルールで判定して TNEF で送ってしまうことがあるようだ。
つまり、送る側にとってもよほど詳しい人でないと、対応はできない。

最初の頃は、受け取る側の私が悪いと思っていた。
前述の通り、当時の対処は「再送をお願いする」だった。どちらかというと謝る感じ。

次の時期には、Outlookの設定が悪いと考え、やはり再送を依頼していた。この頃はどちらかというと相手のせいだと思って、設定と送付方法をちゃんとして送り直してくださいという意味合いに変わった。

その次は、MacのTNEF's Enoughでwinmail.datを開くようになった。再送依頼は面倒だし、この頃はもうあきらめている。

さらに進み、それすら面倒になるため、Windowsの端末にOutlookで同じメールを受信することにした。あきらめというよりはもはや迎合。

自分自身については、この迎合で良いと思っている。

ただ、Outlook（Classic）を持っていない、あるいは会社の方針や何かの思いを持ってThunderbirdを使っている方に、押し付けることはできない。

やはりいまだに 「winmail.datというファイルが送られてきて開けない」という問い合わせは一定数ある。

そういうときは、Winmail Openerを紹介したりインストールしたりする。

2026年の今、ネットで検索すると、Winmail Opener以外にはThunderbirdのアドオン Lookout (fix version)が使えるという記事を見かける。

実際には、互換性の問題でインストールできなかった。
そのうち対応されるだろうか。わからなかった。

フォルダとファイルの命名規則は決めており、スクリプト化することにした。
うっすらと、Automator、AppleScriptかなと考えていたけど、シェルスクリプトでできそう。

ルールは
YYYY(西暦4桁)＞フォルダ名＞YYYYMM_ファイル名.xlsx
という感じで、年次でフォルダ月次でファイルが増えていく。

単純化すると下記のような感じ
2026＞A＞202601_A_報告書.xlsx
＞202602_A_報告書.xlsx
＞202603_A_報告書.xlsx
….
＞202607_A_報告書.xlsx
＞202608_A_報告書.xlsx
….
2026＞B＞202601_B_報告書.xlsx
＞202602_B_報告書.xlsx
＞202603_B_報告書.xlsx
….
＞202607_B_報告書.xlsx
＞202608_B_報告書.xlsx
….
2026＞C＞202601_C_報告書.xlsx
＞202602_C_報告書.xlsx
＞202603_C_報告書.xlsx
….
＞202607_C_報告書.xlsx
＞202608_C_報告書.xlsx
….

A、B、Cは案件名だったり顧客名だったりして、5〜6個ある。
それぞれのフォルダ下の同じ年月のファイルを同時に開きたい。

以下はコード

#!/bin/bash

# 第一引数：年を指定　例）2026
# 　指定がない場合は実行時の年
# 第二引数：月を指定　例）07または7
# 　指定がない場合は実行時の月

if [[ -z "$1" ]]; then
  # 引数指定なし
  yyyy=$(date +%Y)
elif [[ "$1" =~ ^[0-9]{4}$ ]]; then
  # 引数で指定
  yyyy="$1"
else
  echo "エラー: 第1引数は4桁の西暦を指定してください。"
  exit 1
fi

if [[ -z "$2" ]]; then
  mm=$(date +%m)
elif [[ "$2" =~ ^(0?[1-9]|1[0-2])$ ]]; then
  mm=$(printf "%02d" "$2")
else
  echo "エラー: 第2引数は1～12の月を指定してください。"
  exit 1
fi

echo ${yyyy}
echo ${mm}

yyyymm=${yyyy}${mm}

open <path>/${yyyy}/A/${yyyymm}_A_報告書.xlsx
open <path>/${yyyy}/B/${yyyymm}_B_報告書.xlsx
open <path>/${yyyy}/C/${yyyymm}_C_報告書.xlsx

引数で年と月を受け取ることにした。
ただし引数指定がなければ実行時の年月を使うことにした。

引数の月は7でも07でも、つまり一桁で強いていしても二桁で指定してもOKにした。それ以外の桁数や数字以外の指定は正規表現で判定してエラーにした。

こんなに単純なプログラムでも、業務効率化できるのは嬉しい。