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 <消したいドメイン名>

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

のとおりに構成すれば問題ない？と思う。

発生したエラー

以前自分用に作成したリバースプロキシ用のテンプレート

nginxリバースプロキシの設定

前提nginxとか既に入っている想定。設定設定があるディレクトリへ移動cd /etc/nginx/sites-available/設定を行うドメイン名のファイルを作成今回は、このあと Let's encrypt で SSL 化を行う想定で、...

asaino.net

2025.03.28

を使用して、HAOS に対してサブドメインを割り当てようとしたところ、以下のようなエラー（以降、IP エラーと呼ぶ）が発生した。

ロガー: homeassistant.components.http.ban
ソース: components/http/ban.py:136
統合: HTTP (ドキュメンテーション, 問題)
最初に発生: 01:50:19 (19 発生)
最終ログ: 02:00:10

Login attempt or request with invalid authentication from buffalo.setup (192.168.11.1). Requested URL: '/auth/token'. (Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/135.0.0.0 Safari/537.36)

結論を言うと、原因は大元のサイトでは書かれていた設定のいくつかが不足していることである。

正しい設定

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    server_name ha2.asaino.net;

    location / {
        proxy_pass http://192.168.11.107:8123;  # 転送先のバックエンドサーバを指定

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $host;
    }

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/ha2.asaino.net/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/ha2.asaino.net/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}
server {
    if ($host = ha2.asaino.net) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    listen 80;
    server_name ha2.asaino.net;
    return 404; # managed by Certbot
}

足りなかったのは、

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;

        proxy_set_header X-Forwarded-Host $host;

の部分。

沼ポイント

ここからが、数時間オーダーで沼った要因である。

この IP エラーは、不正な IP からアクセスがあったときに、セキュリティとしてアクセスを制限する機能である。それゆえ、一度不正なアクセスがあった場合には、そのアカウントに対してのアクセスを相当厳しく制限するようである。
従って、一度この IP エラーが出た場合、以下の手順でログイントークン削除する必要がある。

1. ローカルネットからダッシュボードにアクセス
2. 左下、アカウント
3. セキュリティ
4. トークンを更新
5. すべてのトークンを削除する

余談

今回使用した HAOS の HTTP において、この IP エラーはよくある問題のようである。また、これが発生する条件は複数あり、軽く調べたところ、未解決のままクローズしている Issue が何件も見つかった。
それゆえ、「もしかしたら自分じゃどうしようもないようなエラーか？」とか思ってグダグダいろいろ試したのも、このエラーに数時間を費やした要因の１つでもあった。