vscodeを用いたsshを利用していると、頻繁にcrashしてvscodeが落ちる。メモリ使用量を確認すると、vscode-server関連のメモリ使用量が20GBを超えている

主要因として、sshで開いていたディレクトリをhome/user直下にしていたこと。

これにより、GitHub copilot chatがhomeディレクトリ上を走査して負荷をかけていた。

一時的に、Github copilot chatを無効化すると解消した。

ターミナルでの様子

freeコマンドでメモリの使用量が30GB近くあり、普段と様子がおかしいことを確認。とりあえず、メモリ使用量の多いプロセスをps auxで調べてみる。結果としてvscode-server関連のプロセスが20GBくらいメモリを使用していた。

ps aux | grep -E 'extensionHost|fileWatcher|vscode-server|Stable-8b640eef' | grep -v grep

実行中のプロセスのcpu使用量も異常で、重複気味に立ち上がっている。crashして再度開いたときに前回のプロセスも走ってるのかな。

extensionHost  57.2%
fileWatcher    58.2%
extensionHost 106%
fileWatcher   100%
extensionHost 160%

fileWatcher    99.9%

vscode.jsonでsearch.excludeやfiles.watcherExcludeを設定してみたが、効果なし。

$ LOGDIR=$(ls -1dt ~/.vscode-server/data/logs/* | head -1)
$ grep -RniE 'workspace|workspaceFolder|rootPath|folder' "$LOGDIR" | head -100

でみてみると、copilot関連のプロセスが暴走していた。copilot chatを無効化すると落ち着いた。logを見てみると、homeディレクトリ（学習用の容量100GBくらいのデータセットも）走査していた。

gitやvscode内検索はgitignoreやsearch.excludeでこれまでどうにかなっていた。

ssh先をhomeディレクトリにするのをやめるか、copilotを無効化するかを天秤にかけた結果、copilot無効化を選択した。

今後の方針

データセットを別マウントのssdに保存する。データセットのサイズ自体が小さいので、これまで惰性でhomeディレクトリに入れていた。データセット用のマウントをhomeディレクトリ以外の場所にフォルダ作って、copilotが走査しないようにする。

惰性で溜めていたツケを払うよう催促されたが、もう少し延滞することにした。近々ちゃんと返済しないとね。

ssh先をhomeディレクトリより深い層にするのは面倒なので避けたいかな。。。よくないけどね

os update

Proxmox

Web UI から

WordPress

Web UI から

Nextcloud

snap 版なので自動アップデート

OS (Ubuntu)

Linux

Install Home Assistant on a Linux

www.home-assistant.io

今回は Proxmox を使用するので、.qcow2 イメージを使用して仮想サーバを作成する。

Alternative

Alternative ways to install Home Assistant

www.home-assistant.io

余談

昔、普通の Linux 用の iso イメージを利用して、Proxmox 上に HAOS を構築していたのだが、完全にやり方がわからなくなってしまった。ロストテクノロジーである。
そのやり方では、Proxmox 側からシャットダウン指示をかけてもうまくシャットダウンされず、物理サーバのメンテナンスに手間がかかったから、べつにいいんだけど。

手順

Proxmox にダウンロードしてきた .qcow2 ファイルをアップロードする。

scp <ダウンロードしたhaos_ova-15.0.qcow2ファイルのPath> root@<Proxmoxの ip>:/var/lib/vz/template/iso

仮想サーバを作成する。設定は以下の通り。

• BIOS：UEFI（EFI ディスクも追加）
• ストレージ：なし
• SecureBoot：OFF（UEFI のメニューから設定）

Proxmox の Shell から .qcow2 ファイルをディスクとして追加。

qm importdisk 108 /var/lib/vz/template/iso/haos_ova-15.0.qcow2 local-zfs --format qcow2

• VM のハードウェアから、追加した未使用のディスクを接続。
• オプションから、さっき接続したディスクの起動順位を一番上にする。

起動してしばらくしたら、WebUI 用の IP が表示される。

あとはウィザードに従って設定しましょう。

リバースプロキシを利用する場合

以下の記事を参考に。

Reverse proxy using NGINX

⚠ This guide has been migrated from our website and might be outdated. Feel free to edit this guide to update it, and to...

community.home-assistant.io

HAOS で Nginx リバースプロキシを使用する。

基本的に、以下のサイトのとおりに構成すれば問題ない？と思う。発生したエラー以前自分用に作成したリバースプロキシ用のテンプレートを使用して、HAOS に対してサブドメインを割り当てようとしたところ、以下のようなエラー（以降、IP エラーと呼ぶ...

asaino.net

2025.03.30

SSH 接続先サーバで動くアプリケーションの画面をリモートへ転送する。

メリット

• アプリケーションはサーバ側で開くので、サーバ側サブネットの Web コンソールにお手軽にアクセスできる
• 処理は完全にサーバで行われるので、LAN 側のみのアクセス制限がかけられている Web コンソールにもアクセスできる
  ex) Buffalo ルータの設定画面
• お好みのサイズ、アス比に変更できるので、リモートデスクトップより扱いやすい
• SSH が繋がれば安定的にアクセスできる

デメリット

• リモートデスクトップと比べて低圧縮、帯域も多く使うので、レスポンスは悪い

手順

Windows なら WSL2 をインストールしておく

少しでも快適に使うため、クライアント側で圧縮の設定をする

Host *
    Compression yes
    TCPKeepAlive yes

サーバ側に日本語のフォントパックをいれる

sudo apt-get install fonts-takao-pgothic

サーバ側でセキュリティの設定

export XAUTHORITY=/home/username/.Xauthority

X11 forwarding、圧縮を有効にしてアクセス

ssh domain -XC

お好きなアプリケーションを起動

活用例

VPN は通らないが SSH は通るネットワーク環境や、VPN の構築、運用がめんどくさいときに、Proxmox や LAN 内のみに公開しているサイトへのアクセスに便利だと思った。

ちゃんと設定しているはずなのにパスワード認証で SSH 接続できてしまう。

原因

/etc/ssh/sshd_config.d/50-cloud-init.conf にある設定 PasswordAuthentication yes が sshd_config を上書きしていた。
no に書き換えたらいい感じ。

SSH 設定メモ

書き換える項目

Port <適当に変更>
PermitRootLogin no
PasswordAuthentication no

の 3 点。

• 特定のポートを公開したい
• ポート開放ができない
• 外部に対する SSH 接続は可能なネットワークに接続している
• ポート開放が可能なネットワーク (ex. 実家) とサーバがある
  (なければ格安のレンタルサーバとかでも)

構成

ポート開放が可能なネットワークにあるサーバ 1 に SSH サーバを立てる
ポート開放ができないネットワークにある サーバ 2 から、サーバ 1 に SSH トンネルを掘る
サーバ 2 に来た通信をサーバ 1 に転送する

設定

サーバ 2 : 通信を転送するかの設定 (/etc/ssh/sshd_config)

GatewayPorts yes
AllowTcpForwarding yes

公開鍵認証もできるようにしておく。

サーバ 1 : 起動時に自動でサーバ 2 に SSH トンネルを掘る設定

portforward.sh

autossh -M 0 -N -f \
  -o ServerAliveInterval=30 \
  -o ServerAliveCountMax=3 \
  -p <ssh_port> \
  -R *:<forward_port>:localhost:<forward_port> \
  <user_name>@<domain>

-N, -f : SSH が確立したらシェルを開かず、バックグラウンドへ潜る
-R : サーバ側のポートをローカルへ転送する
* : サーバに来た全部の IP からの通信を転送

実行権限を付けて実行できるか試してみる。
起動時に自動で接続されてほしかったら、crontab -e に起動時このシェルスクリプトを実行するように書いておく。

@reboot /home/<user_name>/portforward.sh

v1 と比べて、タイムアウト他の理由で切断があったとき自動再接続するので、安定性が格段に向上。

あとがき

レオパレスの LeoNet でサーバを公開するために編み出した術。
本当はできないことをするので、何かしらの問題が起こっても自己責任で。
もっと良くするならば、autossh とかを使って、SSH 切断時のリトライとかの設定など。

VPN などを使う手法もあるかと思うが (実際別案件では VPN を使用している)、特定のポートへ通信を転送するだけなら、SSH のポートフォワードのほうが楽だし同じことができると思う。

$ sudo nginx -v
nginx version: nginx/1.24.0 (Ubuntu)

Ubuntu24 の規定リポジトリでは安定版の Nginx が直接当たらないので、以下を参考にリポジトリを追加

nginx: Linux packages

nginx.org

アップデート

sudo apt-get update
sudo apt-get dist-upgrade

Nginx1.24 → 1.28 のアップデートでは、設定ファイルのパスが違うらしいので追加する

$ cat /etc/nginx/nginx.conf

user  nginx;
worker_processes  auto;

error_log  /var/log/nginx/error.log notice;
pid        /run/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;

    include /etc/nginx/conf.d/*.conf;
+   include /etc/nginx/sites-enabled/*;
}

$ nginx -v
nginx version: nginx/1.28.0

# コンテナを止める
docker compose down

# ホスト側で所有者を www-data(UID 33) に
sudo chown -R 33:33 ./html

# 念のためパーミッションも
find ./html -type d -exec chmod 755 {} \;
find ./html -type f -exec chmod 644 {} \;

# 再起動
docker compose up -d

なぜかこの WordPress、ずっと RasPi 4 (4GB) で動いていた。
何かしらがめんどくさくて、実家で動いていた踏み台サーバに建てたのだと思われる。
それが先日、親から RasPi の冷却用ファンから異音、それも相当大きなものがなっているとの連絡が来てので、この機会にメインサーバに移行した。

しかし、RasPi は ARM 系 CPU、メインサーバは x86 CPU であるため、わざわざ Docker で構築しているにも関わらず互換性が超低い。
この特殊な移行例を、一応書き残しておく。

環境

移行元:
Ubuntu22、Pimox7、RasPi4B (4GB)
/home/username/wordpress/ に docker-compose.yml とか、WordPress のデータとかがある

移行先:
Ubuntu22、ProxmoxVE8、普通の PC

手順

1. 移行元、移行先に Samba を入れておく
   生まれも育ちも GUI なので GUI が好き
2. mox でバックアップを取る、超重要
3. 旧 WordPress を停止
   docker compose down
4. データベースをエクスポート
   docker compose exec db mysqldump -u root -p'<password>' --single-transaction --databases wordpress \> db_$(date +%F).sql
5. WordPress 本体を圧縮してエクスポート
   tar czf wp_html_$(date +%F).tar.gz html/
6. 旧サーバから新サーバの /home/username/wp_migration に、さっきエクスポートした 2 ファイルを転送
7. 新サーバに WordPress をインストール
   sudo add-apt-repository universe
sudo apt install -y docker.io docker-compose-v2
8. 新サーバの /home/username/wordpress に docker-compose.yml を配置
9. /home/username/wordpress に WordPress 本体を解凍して配置
   cd ~/wordpress
tar xzf ~/wp_migration/wp_html_<日付>.tar.gz
10. コンテナ起動
    docker compose up -d
11. データベースをリストア
    sudo docker cp ~/wp_migration/db_<日付>.sql $(sudo docker compose ps -q db):/tmp/
sudo docker compose exec db sh -c "mysql -u root -p'<password>' wordpress < /tmp/db_<日付>.sql"
12. アクセスして確認
    https://<ip>:<port>

結果

副産物として、WordPress が超早くなった。
翌々考えたら、もともと RasPi の CPU で、メモリも 512MB しかなかったものが、9 世代 i5 でメモリも 8GB 与えられるようになったのだから、これまでが低スペすぎた。

これまで頑張ってくれた RasPi 君に感謝。

Nginx を再読込する

sudo nginx -t
sudo systemctl reload nginx

ドメインの自動更新設定の削除

sudo certbot certificates
sudo certbot delete --cert-name <消したいドメイン名>