Difyをクローン化

gitの確認

difyをクローン化するのに、「git」を利用するので、「git」のインストール状況を確認します。
windows ターミナルを開き、wsl を起動し、「git -v」で状況を確認します。

PS C:\Users\hogehoge2> wsl

$ git -v
git version 2.43.0
インストールされていない場合には、インストール
$ sudo apt update
$ sudo apt install git

Gitでdifyをクローン化する

「git clone ・・」でクローン化を実行すると、カレントディレクト下「dify」ディレクトリへソースコードがクローン化されます。
windowsターミナルで、「wsl」を実行し、ubuntu環境へ入ると、デフォルトでは、winndowsユーザーのディレクトリへセットされた状態で起動します。
好みの問題だと思いますが、この場所へ「dify」環境を作成してもいいと思いますが、筆者はubuntuのユーザーホームディレクトリ下に作成しようと思います。
wsl、ubuntuプロンプトで、「cd」を実行すると、ユーザーのホームディレクトリへ移動します。
その場所で「git clone・・」すると、そのディレクトリ直下に「dify」さらにその下に「docker」ディレクトリが作成されています。
「ls」コマンドで確認できます。
「dify/docker」ディレクトリへ「cd」コマンドで移動しておきます。
「pwd」コマンドで、現在のディレクトリが確認できます。

hogehoge2@hoge-PC:/mnt/c/Users/hogehoge2$
$ cd
$ git clone https://github.com/langgenius/dify.git
Cloning into 'dify'...
remote: Enumerating objects: 153846, done.
remote: Counting objects: 100% (536/536), done.
remote: Compressing objects: 100% (359/359), done.
remote: Total 153846 (delta 396), reused 178 (delta 177), pack-reused 153310 (from 3)
Receiving objects: 100% (153846/153846), 87.73 MiB | 5.07 MiB/s, done.
Resolving deltas: 100% (111131/111131), done.
$ ls
dify
$ cd dify/docker/
$ pwd
/home/hogehoge2/dify/docker

Difyコンテナ起動

「git clone」を実行したディレクトリに、「dify/docker」ディレクトリが作成されています。
その中に「.env.example」のサンプル環境変数ファイルが作成されています。
通常ファイルは「ls」コマンドで確認できますが。「.」で始まるファイルは表示されません。
その場合「ls -la」コマンドを実行すると、表示されます。
コピーは「cp <オリジナルファイル名>　<複写ファイル名>」で複写できます。
「.env.example」ファイルを、正式な環境変数「.env」としてコピーし、「docker compose」コマンドで、コンテナを起動させます。

$ pwd
/home/hogehoge2/dify/docker
$ cp .env.example .env
$ docker compose up -d
[+] Running 80/80    
✔ web Pulled             149.7s
✔ sandbox Pulled         221.1s
 ✔ ssrf_proxy Pulled      88.2s
 ✔ db Pulled             224.4s
 ✔ worker Pulled         402.2s
 ✔ plugin_daemon Pulled  404.6s
 ✔ nginx Pulled           36.4s
 ✔ weaviate Pulled       225.1s
 ✔ redis Pulled          221.2s
 ✔ api Pulled            402.2s
[+] Running 12/12
 ✔ Network docker_default             Created    0.1s
 ✔ Network docker_ssrf_proxy_network  Created    0.0s
 ✔ Container docker-web-1             Started    3.7s
 ✔ Container docker-ssrf_proxy-1      Started    4.0s
 ✔ Container docker-sandbox-1         Started    3.7s
 ✔ Container docker-redis-1           Started    3.7s
 ✔ Container docker-weaviate-1        Started    3.7s
 ✔ Container docker-db-1              Healthy    10.7s
 ✔ Container docker-worker-1          Started    9.3s
 ✔ Container docker-plugin_daemon-1   Started    9.3s
 ✔ Container docker-api-1             Started    9.5s
 ✔ Container docker-nginx-1           Started    10.0s

docker compose upでエラー発生！AIに聞いてみる。

上記は正常な例ですが、古いPCをテストマシンとして利用した時、「docker compose up」で下記エラーがでた事がありました。

dependency failed to start: container docker-db-1 is unhealthy

この時もgeminiに聞いてみたところ、「docker logs docker-db-1」でログを確認してくれとの事なので、ログを直接貼り付けると、

Ai

ログを見る限り、データベースの初期化自体は正常に完了しています (PostgreSQL init process complete; ready for start up.)。 その後の起動プロセスも進んでいますが、2025-04-29 00:02:07.998 UTC [557] FATAL: the database system is starting up という致命的なエラーが出力されています。

このエラーは、PostgreSQLサーバーが起動してリカバリなどの内部処理を行っている最中に、外部からの接続要求（この場合はおそらくDockerのヘルスチェックや、依存するDifyコンテナからの初期接続試行）があった場合に発生することがあります。

つまり、データベースサーバー自体は最終的に database system is ready to accept connections の状態になりますが、Dockerのヘルスチェックがサーバーの準備が完全に整う前に接続を試み、上記の FATAL エラーを受け取ってしまい、それが原因でコンテナが unhealthy と判定されている可能性が高いです。

解決策:

Dockerのヘルスチェック設定を調整し、データベースが完全に起動して接続可能になるまで、チェックを待つように設定を変更するのが最も有効な対策です。

データベースサービス (db または postgresql) の healthcheck 設定を見つける:
services のセクションにある、データベースコンテナに対応するサービス定義（通常は db という名前）を探します。その中に healthcheck というブロックがあるはずです。

YAML
services:

db: # ... その他の設定 ...
healthcheck: # ここに設定があります
　　・
test: ["CMD-EXEC", "pg_isready -U <db_user> -d <db_name>"] # 例
interval: 10s
timeout: 5s
retries: 5
start_period: 30s # <-- この値を調整します

docker-compose.yml を開く: Difyを起動するために使用している docker-compose.yml ファイルをテキストエディタで開きます。

じじぃ

docker-compose.yamlを確認した所、「start_period:」の設定がありません。

Ai

start_period が指定されていない場合、コンテナが起動を開始すると同時にヘルスチェックが始まります。今回のデータベースのログで見たように、起動直後の一時的な準備期間中に接続を試みると FATAL: the database system is starting up のようなエラーが発生することがあります。

interval: 1s と非常に短い間隔でチェックが実行されるため、データベースが完全に準備できる前に多くのチェックが走ってしまい、すぐにリトライ回数（retries: 60）を使い果たして unhealthy と判定されてしまう可能性が高いです。

解決策:

start_period を追加し、必要に応じて interval も調整しましょう。

1. healthcheck 設定に start_period を追加する: データベースが起動して準備ができるまでの猶予期間として、start_period を設定します。
   例えば 30s または 60s (30秒または60秒) を指定します。
   YAML
   services:
db: # ... その他の設定 ...

healthcheck:
test: [ 'CMD', 'pg_isready', '-h', 'db', '-U', '${PGUSER:-postgres}', '-d', '${POSTGRES_DB:-dify}' ]
interval: 5s # 例: 毎秒ではなく5秒ごとにチェックに緩和
timeout: 3s
retries: 10 # 例: リトライ回数を調整 (intervalを長くすればretriesは少なくても良い)
start_period: 60s # <- この行を追加 (例: 60秒待つ)
   
   ポイント: start_period の間は、ヘルスチェックが失敗してもコンテナは starting 状態のままとなり、unhealthy とは判定されません。start_period が経過した後に初めて、ヘルスチェックの失敗が unhealthy の判定に使われます。
2. interval も少し長めにすることをお勧めします: interval: 1s は開発時などに素早く確認したい場合には便利ですが、本番に近い環境や安定性を重視する場合は 5s や 10s に設定することが一般的です。これにより、データベースへの不要な負荷も軽減されます。
3. docker-compose.yml を保存する。
4. Docker Compose を再起動する: 変更を反映させるために、コンテナを再作成して起動します。

アドバイス通りに、編集して再度「docker compose up -d」を実行すると、正常になりました。
いやぁ～、AIさまさま、ですね～
おそらく、ネット検索では、解決できなかったと思います。
ただし、古いPCだったのが、一番の原因かもしれません。
５年ほど前のPCでは、このエラーはでなかったので、レアなケースかもしれませんが、AIの利用例として紹介しました。

Dify起動

初期画面

「docker compose up」が正常に終了すると、Webブラウザで「http://localhost/install」へアクセスすると「dify」の初期設定が開きます

Difyの動作と試用

とりあえず、起動しました。
以前このサイトでも説明していますが、簡単なチャットボットを作成し試してみます。
LLMモデルはオンラインの「gemini」を登録し、動作を確認できました。
オンラインであれば、「LM Studio」や「Ollama」など、ローカルLLMを利用するアプリは必要ないので、すぐに確認できます。

Difyを自動起動

Difyを動作させるには、Dockerが起動していなくてはいけません。
それには、WSL上で、ubuntuも起動している必要があります。
手動でやる場合、

・windowsターミナル起動
・wslコマンドで、ubuntuターミナル起動
・ubuntuターミナルでカレントディレクトリを、Difyのクローンディレクトリに移動
・「docker compose up -d」 コマンド実行

このような手順が必要ですが、問題なのは、ターミナルを閉じるとdockerも終了してしまうことです
Difyを使うには、dockerが起動していなくてはいけません。
windowsアプリの「docker desktop」であれば、標準で自動起動設定だったと思いますし、起動後もシステムトレイのアイコンで起動が確認できます。右ボタンで状態確認や終了も簡単です。
ubuntu経由の場合には、GUIでの確認ができないので、ここが面倒なところですね～。
自動起動方法をいろいろ調べると、windowsバッチファイルを作成し、スタートアップフォルダに登録する事で、windows起動時に、自動起動できそうです。
ただ、
「コマンドプロンプト　⇒　ubuntuターミナル　⇒　docker」
のタスクが必要で、ターミナルは開いた状態にしておく必要があります。
このようなバッチファイルを作りたいですが、どんなコードにすればいいのか・・？
うまいコードを考え付かなかったので、difyの試しもかねて起動しているチャットボットで設定しているgeminiに考えてもらいました。

@echo off
title Starting Dify via WSL

echo Starting WSL and navigating to ~/dify/docker...
echo Running 'docker compose up -d'...
echo WSL window will remain open after commands.

REM WSLを起動し、bashシェル内でコマンドを実行します。
REM cd ~          : ホームディレクトリに移動 (念のため)
REM cd ./dify/docker : dify/docker ディレクトリに移動
REM docker compose up -d : docker compose をバックグラウンドで起動
REM exec bash     : 上記コマンド実行後、インタラクティブなbashシェルを開始して終了させない
wsl.exe -e bash -c "cd ~/dify/docker && docker compose up -d && echo '--- Dify containers started (or attempted to start) ---' && exec bash"

echo WSL window launched. This batch window can be closed if desired.
REM pause REM Optionally uncomment this line to keep the batch window open until a key is pressed

すごいです。
ほとんど実際の起動には影響がない「REM」や「echo」文がほとんどですが、
「REM」文を使っての説明文や、「echo」での実行中のメッセージにも手抜きがないですね！
このコードをコピーしてエディターで、「start_dify.bat」というファイルで保存しました。
バッチファイルの単独実行では問題ありませんでした。
後はこのファイルのショートカットを、スタートアップフォルダへコピーするだけです。

・上記の作成したバッチファイルを、適当は場所へ保存します
　私は、ユーザーフォルダ「C:\Users\「ユーザー」」へ保存しました。
・次に、このファイルのショートカットを作成します。
・このショートカットを「スタートアップフォルダ」へ保存します。
　スタートアップフォルダは、エクスプローラーのアドレスバーへ「shell:startup」と入力すると開くことができます。

特に必須ではないですが、ターミナルは起動状態にさせるので邪魔になる場合、作成したショートカットファイルを、マウス右ボタンで「プロパティ」を開きます。
「プロパティ」の「ショートカット」タブの「実行時の大きさ」を「最小化」に設定すると、起動時にタスクバーに最小化状態で起動できます。

これで、再起動すると、自動起動したターミナルはタスクバーへ最小化状態ですが、環境によっては起動途中の場合があるので、すぐに使用したい場合には、一度開いてDockerの状態を確認したほうがいいと思います。
正常に起動できると、Webブラウザのアドレスバーに「http://localhost/install」でdifyが起動できます。
場合によっては、「http://localhost/signin」にリダイレクトされる場合もあります

この画面が開くと、ローカルPCでは、Difyを利用する事ができますが、今回はサーバーとして利用したいので、LAN上の別のPCからのアクセスも必要です。

Difyをサーバー化して、他のPCからもアクセスさせる

同じLAN上であっても、「localhost」では、他のPCではアクセスできません。
前回後半で少し話題にしましたが、「windowsホスト」「WSL(ubuntu)」「Docker」と複雑な通信環境なので面倒です。

DifyPCのIPアドレス調査

IPアドレスは、windowsターミナルでは「ipconfig」コマンド
WSLターミナルでは、「ip addr」で確認できます。
この情報を、Aiに添付して聞いてみました。

Ai

詳細な情報ありがとうございます！ipconfig と ip a の結果から状況がより明確になりました。
原因の特定
・Windows ホスト:
　あなたの Windows PC の Wi-Fi アダプターには 192.168.0.94 という IP アドレスが割り当てられています。
　これはご自宅などの LAN 内の IP アドレスです。
・WSL (Ubuntu):
　Windows Subsystem for Linux (WSL) 環境内の Ubuntu には、eth0 インターフェースに 172.31.226.6 という IP アドレスが割り当てられています。
　これは WSL が使用する仮想ネットワーク内の IP アドレスです。

Ai

WSL2 環境で Docker コンテナを動かしている場合、Windows ホストからそのコンテナ内のサービスにアクセスするには、通常以下のいずれかのアドレスを使用します。
１．localhost:
　Windows ホストのブラウザで http://localhost/chat/…と入力する。
　WSL2 は localhost 経由でのポートフォワーディングをサポートしています。
　（これが最も一般的な方法です）
２．WSL の IP アドレス: http://172.31.226.6/chat/…
　(今回アクセスできている方法)

・http://192.168.0.94/chat/… でアクセスできないのは、WSL2 と Docker のネットワークアーキテクチャ上、自然なことです。
サービスが Windows ホストの物理的な IP アドレスに直接公開されているわけではないためです。
・もし、LAN 内の他の PC (例: 192.168.0.100) からもこの Dify 環境にアクセスしたい場合は、追加の設定が必要になる可能性があります:

１．Windows ファイアウォールの設定: Windows のファイアウォールで、外部からのポート 80 (または Dify が使用しているポート) への着信接続を許可する必要があります。
２．ポートフォワーディング (状況による): WSL2 のネットワーク設定によっては、Windows ホストの 192.168.0.94 のポート 80 へのアクセスを、WSL の 172.31.226.6 のポート 80 へ転送する設定が必要になる場合があります。
これは 「netsh interface portproxy」 コマンドなどで設定できますが、まずは localhost や WSL の IP でアクセスできることを確認するのが先決です。

要約:
・Windows ホストからアクセスする場合: http://localhost/chat/… または http://172.31.226.6/chat/… を使用してください。
・http://192.168.0.94/chat/… でアクセスできないのは仕様であり、問題ではありません。

Windowsのアドレスからは、アクセスできない。

じじぃ

http://localhost や http://172.31.226.6 からはアクセスできています。
今回は、LAN上の別のPCからhttp://192.168.0.94 にアクセスしたいため、自分PCで試したら、アクセスできませんでした

Ai

なるほど、LAN上の他のPCからアクセスできるようにしたい、ということですね。承知いたしました。

ご自身のPC (192.168.0.94) から http://192.168.0.94/chat/... にアクセスできなかったのは、まさにその設定がまだされていないためです。Windowsホストのネットワーク(192.168.0.x) と WSL内部のネットワーク (172.31.x.x) は分離されており、外部（LANを含む）から直接WSL内のサービスにアクセスするには、「ポートフォワーディング（ポート転送）」という設定が必要になります。

設定手順

以下の手順を管理者権限で実行してください。

1. Difyが使用しているポートを確認 (重要):
   • まず、DifyがWSL内でどのポート番号で待ち受けているか確認します。HTTPなので通常は 80番 ですが、Dockerの設定によっては異なるポート（例: 3000番など）がホスト(WSL)に公開されている場合があります。
   • Docker Composeを使っている場合は docker-compose.yml ファイルの ports: セクションを確認してください。例えば ports: - "80:80" や ports: - "3000:80" のようになっています。左側の数字がWSL側で公開されているポート番号です。
   • docker ps コマンドを実行しても確認できます。PORTS 列に 0.0.0.0:80->80/tcp や 0.0.0.0:3000->80/tcp のように表示されます。0.0.0.0: の後の数字がWSL側で公開されているポート番号です。
   • 以降の説明では、Difyがポート 80 を使用していると仮定します。もし異なるポート（例: 3000）だった場合は、コマンド内の 80 をその番号に読み替えてください。
2. Windows ファイアウォールでポートを開放:
   • LAN内の他のPCからのアクセスを許可するために、WindowsのファイアウォールでDifyが使用するポート（ここでは80番）を開ける必要があります。
   • 管理者としてPowerShellを開き、以下のコマンドを実行します。
     powershell New-NetFirewallRule -DisplayName "Allow Dify Access from LAN" -Direction Inbound -LocalPort 80 -Protocol TCP -Action Allow
     (もしコマンドプロンプトを使いたい場合は、管理者として開き netsh advfirewall firewall add rule name="Allow Dify Access from LAN" dir=in action=allow protocol=TCP localport=80 を実行)
3. ポートフォワーディングの設定:
   • Windowsホスト (192.168.0.94) のポート80に来た通信を、WSL (172.31.226.6) のポート80に転送するように設定します。
   • 管理者としてPowerShell（またはコマンドプロンプト）を開き、以下のコマンドを実行します。 powershell netsh interface portproxy add v4tov4 listenport=80 listenaddress=0.0.0.0 connectport=80 connectaddress=172.31.226.6
     • listenport=80: Windows側で外部からの接続を待ち受けるポート番号。
     • listenaddress=0.0.0.0: Windowsの全てのIPアドレス（192.168.0.94 を含む）で待ち受ける設定。特定のIP (192.168.0.94) だけを指定することも可能です。
     • connectport=80: 転送先のWSL内でDifyが待ち受けているポート番号。
     • connectaddress=172.31.226.6: 転送先のWSLのIPアドレス。
4. 動作確認:
   • 設定後、まずご自身のPCのブラウザから http://192.168.0.94/chat/84aj9r6azPSYjXt8 にアクセスできるか試してください。 (ポートが80以外の場合は http://192.168.0.94:ポート番号/chat/... のように指定)
   • アクセスできれば、LAN内の他のPCからも同じアドレス (http://192.168.0.94/chat/...) でアクセスできるはずです。

注意点:

• WSLのIPアドレスの変動: WSLを再起動すると、WSLのIPアドレス (172.31.226.6) が変わる可能性があります。もしアクセスできなくなった場合は、ip a コマンドでWSLの新しいIPアドレスを確認し、手順3のポートフォワーディング設定を一度削除して再作成する必要があります。
  • 削除コマンド: netsh interface portproxy delete v4tov4 listenport=80 listenaddress=0.0.0.0
  • 再作成コマンド: (新しい connectaddress を指定して再度実行)
• 管理者権限: ファイアウォールとポートフォワーディングの設定には管理者権限が必要です。
• ポート番号: Difyが使用しているポート番号を正確に確認し、コマンド内の 80 を適宜修正してください。

この手順で、LAN内の他のPCからアクセスできるようになるはずです。試してみてください。

docker ps コマンドで実行中のコンテナーを提出

じじぃ

docker ps では下記になっています。
$ docker ps
・・
・
・

Ai

docker ps の出力結果、ありがとうございます。

コンテナ docker-nginx-1 の PORTS 列にご注目ください。

PORTS
0.0.0.0:80->80/tcp, [::]:80->80/tcp, 0.0.0.0:443->443/tcp, [::]:443->443/tcp

これは、以下のことを意味しています。

• 0.0.0.0:80->80/tcp: WSLホスト（172.31.226.6 など）の ポート 80 (HTTP) へのTCP接続を、docker-nginx-1 コンテナ内部のポート 80 に転送する。
• [::]:80->80/tcp: 上記のIPv6版。
• 0.0.0.0:443->443/tcp: WSLホストの ポート 443 (HTTPS) へのTCP接続を、docker-nginx-1 コンテナ内部のポート 443 に転送する。
• [::]:443->443/tcp: 上記のIPv6版。

docker-web-1 コンテナ自体は内部的にポート 3000 を使っていますが、外部（WSLホスト）からのアクセスは docker-nginx-1 コンテナがポート 80 (HTTP) と 443 (HTTPS) で受け付けています。Nginx がリバースプロキシとして動作し、リクエストを docker-web-1 や docker-api-1 などに振り分けている構成です。

結論

あなたが LAN 上の他の PC からアクセスしたい HTTP のポート番号は 80 です。

したがって、先ほどのポートフォワーディング設定のコマンドは、ポート番号 80 を使って実行してください。

1. ファイアウォール開放 (ポート 80): New-NetFirewallRule -DisplayName "Allow Dify Access from LAN (HTTP)" -Direction Inbound -LocalPort 80 -Protocol TCP -Action Allow
2. ポートフォワーディング設定 (ポート 80):
   powershell netsh interface portproxy add v4tov4 listenport=80 listenaddress=0.0.0.0 connectport=80 connectaddress=172.31.226.6

これで、 http://192.168.0.94 (ポート80は省略可能) でアクセスできるはずです。

もし将来的にHTTPS (https://192.168.0.94) でアクセスしたい場合は、同様にポート 443 用のファイアウォールルールとポートフォワーディング設定を追加する必要があります。

ファイヤーウォールとポートフォワーディング設定

ファイアウォールを開放し、ポートフォワーディング設定をしろ、のアドバイスです。
教わったコードを実行してみます。

１．ファイアウォール開放 (ポート 80):

PowerShell
PS C:\Users\hoge2>　New-NetFirewallRule -DisplayName "Allow Dify Access from LAN (HTTP)" -Direction Inbound -LocalPort 80 -Protocol TCP -Action Allow

コントロールパネル→システムとセキュリティ→windows Defender ファイアウォール→詳細設定
受信の規則で
コマンドで指定したAllow Dify Access from LAN(HTTP)が設定されているのが、確認できます。
コマンドではなく、この画面で、GUI設定する事もできます。

2．ポートフォワーディング設定 (ポート 80):

管理者権限のPowerShell の、「netsh」コマンドで設定します。

PowerShell（管理者）
PS C:\Users\hoge2> netsh interface portproxy add v4tov4 listenport=80 listenaddress=0.0.0.0 connectport=80 connectaddress=172.31.226.6

「netsh interface portproxy show v4tov4」で確認できます。

PS C:\Users\hoge2> netsh interface portproxy show v4tov4
ipv4 をリッスンする:         ipv4 に接続する:
Address         Port        Address         Port
--------------- ----------  --------------- ----------
0.0.0.0         80          172.31.226.6    80

アクセスできた～

これで無事に「http://192.168.0.94/instal」でアクセスできました。
LAN上の別のPCからも、アクセス確認できました。
おそらく、ネット検索では、ここまで的確なアドバイスを見つけるのは至難の業だと思います。
ちょっと前までは、言語生成AIをうまく使うには、プロンプトが重要だと言われていましたが、最近の言語生成AIはかなり言語の理解力が向上していると感じます。
上記のじじぃの質問でもわかりますが、ほとんど「プロンプト」など意識していません。
とにかくわからない事やPCからの出力を、自分の言葉で質問しているだけです。
それでもかなり的確な回答をくれます。
たまには、間違った回答もありますが、それでエラーが発生した場合、そのエラーやログをそのまま突っ込めば、新たな回答をくれます。
すごい時代になりました。

DifyにLLMを設定して、カスタムチャット環境を構築

やっとDifyサーバーが起動できました。

次に、このDifyにLLMモデルを設定することで、チャットボットをはじめカスタムLLMアプリを開発する事ができるようになります。
左図の例では、
一番上の「Gemini」はオンラインで公開されているLLMです。
二番目は、「LM Studio」でダウンロードしたローカルLLMです。
三番目は、「Ollama」で読み込んでいるローカルLLMです。
このように、「Dify」ではオンライン、ローカルあまり意識せず、使用するLLMを自由にカスタマイズできます。

DifyにLLMの設定方法

ネット上でも、多くの情報があると思いますが、このサイトでも以前の記事で紹介しています。

オンラインLLMの登録

ローカルでDifyとLM_Studio を連携させ、ローカルでチャットボットを作る。

LM StudioとDifyをローカルで連携させたのでレポートします。記事を書いている時に、Dify設定にLM Studioのプラグインを発見したので、そちらの設定も追加してます。

www.kazuban.com

2025.03.23

LM Studio モデルの登録

ローカルでDifyとLM_Studio を連携させ、ローカルでチャットボットを作る。

LM StudioとDifyをローカルで連携させたのでレポートします。記事を書いている時に、Dify設定にLM Studioのプラグインを発見したので、そちらの設定も追加してます。

www.kazuban.com

2025.03.23

Ollama　モデルの登録

DifyとOllamaを連携させ、ローカルチャットボット環境を作る

前回はLM StudioとDifyの連携でしたが、今回は、Ollamaと連携させてみました。どちらもそれぞれ特徴があるので、使い分けてもいいと思います。 私的には、スタンドアローンで使うならLM Studio。Difyとの連携であればOllama かな？と思っています。

www.kazuban.com

2025.03.30

あとがき

Windowsアプリ「Docker Desktop」を使わず、「Ubuntu」にインストールした「Docker Engine」で「Dify」をサーバー化する方法を紹介しました。
「Docker Desktop」はWindows環境向けのツールであり、構築の手間は比較的少ないですが、Ubuntuサーバー上で動作させる際は、仮想化環境の設定やネットワーク通信の複雑さが生じるため、トラブルシューティングがやや難しくなります。
今回は、AIのアシストにより、Difyサーバーを構築することができました。
設定プロセスだけでなく、AIを活用した実践例として、このやり取りもご参考にしていただければ幸いです。

話題のDifyをインストールしてみた。失敗談あり。

話題のDifyをローカルインストールしてみました。普通にやれば何てことない作業ですが、余計な事したので時間がかかってしましました。

www.kazuban.com

2025.03.15

この状態では、「WSL」環境には、別途Linuxはインストールされていません。
「wsl -l -v」コマンドで確認できます。

PS C:\Users\hoge> wsl -l -v
  NAME              STATE           VERSION
* docker-desktop    Running         2

現在は、仮想環境として「Docker Engine」のみが動作し、そのコンテナとして「Dify」が動作しています。
この状態でも、「Dify」を利用する場合には問題ありませんが、せかっくの「WSL」なので「ubuntu」環境に「Docker」を構築し、「Dify」コンテナを構築し直そうと思います。
また、windowsアプリ「Docker Desktop」は、ライセンス的に完全オープンではありませんし、「Dify」もLinuxとの組み合わせのほうが、貧弱スペックマシンでは、パフォーマンスが向上しそうな気がしています。

Docker Desktop と WSLを完全アンインストール

再度、クリーンな状態から再インストールしたい場合もあると思います
gemini君に教えてもらった、クリーンインストール方法をメモしておきます。

Docker Desktop のアンインストール

★Docker Desktopのアンインストール
1. 「設定」アプリを開く:
　Windowsキー + Iキーを押すか、スタートメニューから「設定」を選択します。
2. 「アプリ」を開く:
　「アプリ」をクリックします。
3. 「アプリと機能」を開く:
　左側のメニューから「アプリと機能」を選択します。
4. Docker Desktopを選択してアンインストール:
　アプリの一覧から「Docker Desktop」を見つけて選択し、「アンインストール」をクリックします。
　画面の指示に従ってアンインストールを完了させます。

★ 関連するファイルの削除 (オプション)
Docker Desktopのアンインストール後、残りのファイルを手動で削除することで、より完全にアンインストールすることができます。

1. 以下のフォルダを削除:
　`C:\Program Files\Docker`
　`C:\ProgramData\DockerDesktop`
　`C:\Users\<ユーザー名>\AppData\Local\Docker`
　`C:\Users\<ユーザー名>\AppData\Roaming\Docker`
2. Hyper-Vを無効化 (Docker DesktopでHyper-Vを使用していた場合):
　「コントロールパネル」>「プログラム」>「Windowsの機能の有効化または無効化」を開きます。
　「Hyper-V」のチェックボックスをオフにして、「OK」をクリックします。
　コンピュータを再起動します。
3. WSL 2を無効化 (Docker DesktopでWSL 2を使用していた場合):
　管理者としてPowerShellを開きます。

　`wsl --unregister docker-desktop`と`wsl --unregister docker-desktop-data`コマンドを実行します。
　「コントロールパネル」>「プログラム」>「Windowsの機能の有効化または無効化」を開きます。
　「Linux用Windowsサブシステム」のチェックボックスをオフにして、「OK」をクリックします。
　コンピュータを再起動します。
4. 環境変数の削除 (Docker関連の環境変数を設定していた場合):
　「システム環境変数の編集」を検索して開きます。
　「環境変数」ボタンをクリックします。
　ユーザー環境変数とシステム環境変数から、Dockerに関連する変数を削除します。
★注意点:
　上記のフォルダやファイルは、環境によって異なる場合があります。
　レジストリを編集する場合は、誤った操作をするとシステムに問題が発生する可能性があるため、注意が必要です。
　Docker Toolboxを使用していた場合は、VirtualBoxもアンインストールする必要があります。

wslを完全に削除する

★ WSLディストリビューションのアンインストール
　WSLに、既にLinuxディストリビューションがインストールされている場合、
　まず、これらを個別にアンインストールします。
1. 管理者権限でPowerShellまたはコマンドプロンプトを開きます。
2. `wsl --list --verbose` または `wsl -l -v` コマンドを実行し、インストールされているディストリビューションの一覧と名前を確認します。
3. `wsl --unregister <ディストリビューション名>` コマンドを実行します。
　例：`wsl --unregister Ubuntu-24.04`
4. 他のディストリビューションに対しても同様の手順を繰り返します。
**補足:**
　ディストリビューションをアンインストールすると、そのディストリビューションに関連付けられたすべてのデータが削除されます。
　必要なデータがある場合は、事前にバックアップしてください。
　Microsoft Storeからインストールしたディストリビューションは、通常のWindowsアプリと同様にアンインストールすることも可能です。

★WSL機能の無効化
　ディストリビューションをアンインストールした後、WSL機能を完全に無効化することもできます。
1. 「コントロールパネル」>「プログラム」>「Windowsの機能の有効化または無効化」を開きます。
2. 「Windows Subsystem for Linux」と「仮想マシン プラットフォーム」のチェックボックスをオフにします。
3. 「OK」をクリックし、コンピューターを再起動します。
**補足:**
　WSL機能を無効化すると、すべてのWSL関連機能が利用できなくなります。
　Hyper-Vを有効にしている場合は、Hyper-Vも無効にする必要があります。
**その他の注意点**
　 WSL関連のファイルやフォルダが残っている場合は、手動で削除することも可能です。ただし、システムの重要なファイルを誤って削除しないように注意してください。
　レジストリを編集する場合は、誤った操作をするとシステムに問題が発生する可能性があるため、注意が必要です。

これらの手順に従うことで、WSLを完全に削除することができます。

ハードディスクのチェック

古いPCにインストールしていると、ハードディスクの調子が悪いのか？WSLが正常にインストールできない事がありました。
Windows付属のチェッカーで回復する可能性がありますので、メモしておきます。

★システムファイルチェッカー（SFC）の実行:
システムファイルの破損を修復します。
管理者権限でコマンドプロンプトを開き、
「sfc /scannow」と入力して実行。

★DISMコマンドの実行:
SFCで修復できないシステムイメージの破損を修復します。
管理者権限でコマンドプロンプトを開き、
「DISM /Online /Cleanup-Image /RestoreHealth」と入力して実行。

WSLにUbintu24.04をインストール

「Docker Desktop」と「WSL」のアンインストール方法を紹介しました。
今回は、WSLに「Ubuntu24.04」を構築し、「Docker Engine」環境を構築しますが、まだ「Docker Desktop」の環境は残しておきたいので、Windowsに新しいユーザーアカウントを作成し新しい環境で作業したいと思います。

Windows新しいアカウント作成

新しいユーザーの作成方法は、ネット上に情報がありますので、検索してみてください。
新しいユーザーでサインインし、新たに「WSL」環境を構築する場合では、こちらを参考してしてください。
新しいユーザーでサインインした初期状態では「wsl -l -v」で確認すると、なにも環境がないのがわかります。

PS C:\Users\hoge2> wsl -l -v
Linux 用 Windows サブシステムにインストールされているディストリビューションはありません。
この問題を解決するには、以下の手順に従ってディストリビューションをインストールしてください:

'wsl.exe --list --online' を使用して利用可能な配布を一覧表示する
および 'wsl.exe --install <Distro>' を使用してインストールしてください。

Ubuntu24.04インストール

いよいよインストールを始めますが、２つの方法
「Microsoft Store 経由」と「wsl コマンド経由」があります。
どちらでもいいと思いますが、アンインストールなどアプリの管理は「Microsoft Store 経由」のほうが簡単です

インストール自体はどちらも、簡単です。

「Microsoft Store 経由」
・Microsoft Store を開き、「Ubuntu 24.04」を検索。
・ 「入手」をクリック。
・ インストールが完了したら、「起動」をクリックします。

「wsl コマンド経由」
・PowerShell またはコマンドプロンプトを管理者権限で開く。
・「wsl --list --online」　でLinux ディストリビューションが一覧表示できる
・希望のディストリビューションをインストール
・「wsl --install -d Ubuntu-24.04」
・インストールが完了後「Ubuntu」起動

ユーザーとパスワード設定

「ubuntu」の起動は、「Microsoft Store 経由」であれば、「スタートメニュー」にアイコンが作成されています。
「wsl コマンド経由」の場合は、ターミナルを起動し「wsl」コマンドで起動できます。
「ubuntu」の最初の起動では、Unixユーザ名の作成を求められます。
特に、WIndowsユーザーと同じ必要はないので、適当なユーザー名とパスワードを設定します。

・
Enter new UNIX username: hoge2
New password:
Retype new password:
passwd: password updated successfully
Installation successful!
・

root パスワード設定

こちらでもレポートしましたが、「ubuntu」では管理権限が必要な場合には「sudo」コマンドで行い、「root」ユーザーは極力使わないを基本にしているみたいです。
したがってデフォルトでは「root」パスワードは設定されていません。
ただ、管理者権限が必要なコマンドやフォルダのアクセスなど、設定やメンテナンスの場合一回一回「sudo」を使うのは面倒です。
「root」での作業は、注意が必要ですが、管理者コマンドの連続の場合、筆者は使用しています。
その場合、筆者は「root」パスワードを設定しています。
「root」パスワードは、「sudo passwd root」コマンドで設定できます。

$ sudo passwd root
[sudo] password for hoge2:
New password:
Retype new password:
passwd: password updated successfully

設定されました。
「root」になりたい時には、「su」コマンドを使用します。
「root」になると「$」プロンプトが「#」に換わります。
元のユーザに戻るには「exit」コマンドを実行します。
現在のユーザーは「whoami」で確認できます。

$ su
Password:
# whoami
root
# exit
exit
$ whoami
hoge2

パスワード入力なしで「sudo」を実行する

通常は「sudo」コマンドを使用しますが、いちいちパスワードを聞かれるので、結構面倒です。
パスワードなしで「sudo」を実行できる設定は「visudo」コマンドの特殊なエディターで設定します。

$ sudo visudo
・
・
# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL
・
## Same thing without a password
%sudo  ALL=(ALL)       NOPASSWD: ALL
・
・

開いた設定ファイルに、
「%sudo ALL=(ALL) NOPASSWD: ALL」
この設定値を追加し上書き保存します。
この設定で、「sudo」グループのユーザーは「sudo」が実行でき、パスワードが不要になります。
ただし、「sudo」コマンドを実行できるのは、「sudoグループ」登録されているユーザーのみなので、現ユーザーを「suduグループ」に登録します。

$ sudo usermod -aG sudo $USER
$ newgrp sudo

この設定で、現ユーザーは「sudoグループ」に登録され「sudo」コマンドが実行できます。

Docker Engine をインストール

「ubuntu」を操作できるユーザー設定が完了したので、いよいよ「Docker Engine」をインストールしていきます。

古いバージョンのアンインストール

古いバージョンがインストールされている可能性がある場合には、念のため次のコマンドを実行してアンインストールしておきます

$ sudo apt-get remove docker docker-engine docker.io containerd runc

完全に削除するには、次のコマンドでボリュームやイメージデータを削除します

$ sudo rm -rf /var/lib/docker
$ sudo rm -rf /var/lib/containerd

Docker Engine インストール手順（Ubuntu 編）

・依存パッケージのインストール

$ sudo apt-get update
$ sudo apt-get install -y ca-certificates curl gnupg lsb-release

・ディレクトリを作製し、Docker の公式 GPG 鍵を追加

$ sudo mkdir -p /etc/apt/keyrings
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

・Docker リポジトリを追加

$ echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

・パッケージ更新＆インストール

$ sudo apt-get update
$ sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

・Docker の動作確認

$ sudo docker run hello-world

↑ これで「Hello from Docker!」が出れば OK！

・dockerコマンド実行は、「sudo」 が必要ですが、実行ユーザーがdockerグループであれば、不要になります。
下記コマンドで、douckerグループに参加させます。

$ sudo usermod -aG docker $USER
$ newgrp docker

コンテナの削除

動作確認で「hello-world」コンテナを作製しましたが、コンテナ削除操作を覚書しておきます。

★コンテナの一覧を表示
$ docker ps -a

★コンテナ削除
$ docker rm <CONTAINER ID または NAMES>

★hello-world イメージ自体を削除
★動作している場合に、エラーになるので、コンテナ削除後にイメージ削除
　 ※"hello-word"のCONTAINER IDを表示する
　 $ docker ps -a -q --filter ancestor=hello-world
$ docker rm $(docker ps -a -q --filter ancestor=hello-world)
$ docker rmi hello-world

★全てのコンテナと全てのコンテナイメージを削除
  -f オプションを付加すると、強制的に削除されるので注意
$ docker rm -f $(docker ps -a -q)
$ docker rmi -f $(docker images -a -q)

★ボリュームの削除: 全ボリュームを削除します。
$ docker volume rm $(docker volume ls -q)

★ネットワークの削除: ネットワークを削除します。
$ docker network rm $(docker network ls -q)

★キャッシュのクリア: 必要に応じて、Dockerのキャッシュをクリアします。
$ docker system prune -a

★すべての停止中コンテナと未使用イメージのみを一掃
　実行中のコンテナは削除しない
$ docker system prune

WSL、Ubuntu24.04、Docker Engine、環境完了

WSL、ubuntu、docker の環境が出来上がりました。
次に、dockerでDifyの環境をセットアップする予定ですが、windowsアプリの「docker Desktop」の場合は、ある程度アプリがやってくれそうですが、今回は「Ubuntu24.04」環境に「Docker」をインストールしたのでネットワーク環境が複雑になりそうな気がしています。

ubuntu、docker の通信状態

windows環境とwsl環境で、通信状態を調べてみます。

Windowsターミナルで、ipconfig コマンド

PS C:\Users\hogehoge2> ipconfig
Windows IP 構成
・
Wireless LAN adapter Wi-Fi:
   接続固有の DNS サフィックス . . . . .:
   IPv6 アドレス . . . . . . . . . . . .: 240f:110:2717:1:f62b:3484:aafb:ade5
   一時 IPv6 アドレス. . . . . . . . . .: 240f:110:2717:1:b1bf:2b2:5d5d:2a98
   リンクローカル IPv6 アドレス. . . . .: fe81::84c1:d56e:ece:1ad8%15
   IPv4 アドレス . . . . . . . . . . . .: 192.168.0.94
   サブネット マスク . . . . . . . . . .: 255.255.255.0
   デフォルト ゲートウェイ . . . . . . .: fe81::fab7:98ff:fe4b:95b8%15
・                                          192.168.0.1
イーサネット アダプター vEthernet (WSL):
   接続固有の DNS サフィックス . . . . .:
   リンクローカル IPv6 アドレス. . . . .: fe81::f749:f04d:c08e:932%44
   IPv4 アドレス . . . . . . . . . . . .: 172.31.224.1
   サブネット マスク . . . . . . . . . .: 255.255.240.0
   デフォルト ゲートウェイ . . . . . . .:

WindowsホストマシンIPアドレス、家庭内LAN：
192.168.0.94/24

WSL Windows側IPアドレス、WindowsとWSL間の通信するためのゲートウェイ：
172.31.244.1/20

wslで、ip a コマンド

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:c8:2e:42 brd ff:ff:ff:ff:ff:ff
    inet 172.31.226.6/20 brd 172.31.239.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe81::215:5dff:fec8:2e42/64 scope link
       valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether ba:b5:41:49:d7:3c brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever

WSL Docker側IPアドレス、WSL環境はこのアドレスで、Windowsと通信：
172.31.226.6/20

docker0 のIPアドレス、Dockerがコンテナにネットワーク機能を提供するためにWSL 2のLinux環境内に作成するブリッジネットワークインターフェースです
172.17.0.1/16

ネットワーク環境・・複雑ですね

次回、DockerにDifyのコンテナを作成しようと思います。
LAN内でも別のPCからのアクセス可能にしたいので、設定状況をレポートします。

WordPressを動作させる

最新のWordPressをダウンロードとドキュメント・ルートへ設置

・ホームディレクトリの仮のダウンロードディレクトリに移動
・WordPress 最新版のダウンロード
・圧縮ファイルを展開
・WordPress ディレクトリ全体を、Apacheのドキュメント・ルートへ移動
・必要に応じて、「wordpress」ディレクトリ名を自分の環境へ変更
・WordPressディレクトリ全体の、ユーザーとグループの変更

$ cd ~/Downloads/
$ wget https://ja.wordpress.org/latest-ja.tar.gz
$ tar xvzf latest-ja.tar.gz
$ sudo mv ./wordpress/ /home/www/html/
$ cd /home/www/html/
$ sudo mv ./wordpress/ ./blog/
$ sudo chown -R apache:apache ./blog/

MariaDBにデータベースと管理ユーザーの設定

「CREATE DATABASE」でWordPress用のデータベースを作成し
「GRANT ALL ON」でデータベースへ全権限を持つ ユーザを作成します。
mariaDBに wordpress用のデータベースを作成前に、設定情報をメモしておきます。
・データベース名：WpDb
・ユーザー名:WpAdmin
・パスワード:WpPasswd
・データベースホスト:local

$ mysql -u root -p[パスワード] <----- -pの後スペースなし
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 32
Server version: 10.11.8-MariaDB-0ubuntu0.24.04.1 Ubuntu 24.04

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> CREATE DATABASE WpDb;  <--- データベース作成
Query OK, 1 row affected (0.001 sec)

MariaDB [(none)]> SHOW DATABASES;  <---- データベース確認
+--------------------+
| Database           |
+--------------------+
| WpDb              |
| information_schema |
| mysql              |
| performance_schema |
| sys                |
+--------------------+
5 rows in set (0.001 sec)
          <---------- 作成したデータベースの管理者ユーザーの作成
MariaDB [(none)]> GRANT ALL ON WpDb.* TO 'WpAdmin'@'localhost' IDENTIFIED By 'WpPasswd';
Query OK, 0 rows affected (0.008 sec)

MariaDB [(none)]> USE mysql   <---- 管理者ユーザーのデータベースは「mysql」
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
MariaDB [mysql]> SELECT user,host from user;  <---- ユーザーデータベースの確認
+-----------------+-----------+
| User            | Host      |
+-----------------+-----------+
| WpDb           | localhost |
| mariadb.sys     | localhost |
| mysql           | localhost |
| root            | localhost |
+-----------------+-----------+
4 rows in set (0.003 sec)

MariaDB [mysql]> SHOW GRANTS FOR 'WpAdmin'@'localhost'; <--- 権限の確認
+------------------------------------------------------------------------------------------------------------------------+
| Grants for WpAdministrator@localhost                                                                                   |
+------------------------------------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO `WpAdmin`@`localhost` IDENTIFIED BY PASSWORD '*1234567AABBB2024A1B2222CC33344A2014Z' |
| GRANT ALL PRIVILEGES ON `WpDb`.* TO `WpAdmin`@`localhost`                                                |
+------------------------------------------------------------------------------------------------------------------------+
2 rows in set (0.000 sec)

MariaDB [mysql]> quit
Bye

WordPress 初期設定

さあ、準備が完了したので、アドレスバーに公開サイトURLを入力すると「初期画面」が出てくるはずですが、前回の「RockyLinux」同様、エラーが出てしまいました。

「php-mysql*」の状態を調べてみます

$ dpkg -l | grep php-mysql
l$ apt list php-mysql*
一覧表示... 完了
php-mysql/noble 2:8.3+93ubuntu2 all

「RockyLinux9」では、「php-mysqlnd」が必要でしたが、「ubuntu2.4」では「php-mysql」のようなのでインストールします

$ sudo apt install php-mysql

インストール後再度公開サイトへアクセスすると、無事に初期設定　画面がでてきました。

「さぁ、始めましょう！」をクリックする事で、次の「ようこそ」画面で必要情報を入力する事でサンプルページが出てきます。

確認が済んだら、設定した「データベースのユーザー名」などの情報は、/home/www/html/blog/wp-config.phpに書かれているので、アクセス権は厳しくしておきます

$ cd /home/www/html/blog
$ sudo chmod 600 ./wp-config.php

Apacheの、rewriteモジュールとAllowOverrideの設定

WordPress設定のパーマリンクで「基本」以外の設定にしたい場合、Apache上でURLの書き換えを行う「mod_rewrite」モジュールを有効にする必要があります。
したがって、「mod_rewrite.so」モジュールが組み込まれている必要があります。
またパーマリンクの設定で、「基本」以外に設定した場合、URLの書き換えを行う設定がWordPressのディレクトリ内の「.htaccess」として作成されます。
apacheは「.htaccess」を見つけると、この設定を有効にしますが、AllowOverride がNoneで設定されていると「.htaccess」は無視されます。
「mod_rewriteモジュール」と「AllowOverride ディレクティブ」の確認を行います

$ ls /etc/apache2/mods-enabled/ | grep rewrite
　・・     <--- 有効になっていない

$ ls /etc/apache2/mods-available/ | grep rewrite
rewrite.load
　・・     <--- 設定ファイルはあるので、有効にする

$ sudo a2enmod rewrite
Enabling module rewrite.
To activate the new configuration, you need to run:
  systemctl restart apache2

　・・     <--- AllowOverrideの設定ファイルを作成
$ cd /etc/apache2/conf-available
$ sudo vi ./wordpress.conf
<Directory "/home/www/html/blog">
    AllowOverride All
</Directory>
　・・     <--- 設定ファイル保存し、有効にする
$ sudo a2enconf wordpress
Enabling conf wordpress.
To activate the new configuration, you need to run:
  systemctl reload apache2

WordPress バックアップとリストア

バックアップの詳細はこちらで紹介しているので、興味あればご確認ください
今回以前自作した、バックアップとリストアのスクリプトをダウンロード可能にしました。
環境をあわせれば、使用できると思いますし、スクリプトなのでご自身の環境に合わせる事で使用できると思います。

スクリプトの環境

基本的は構造は下記になります。

・「自分のホームディレクトリ」に「bin」ディレクトリを作成
・「bin」にスクリプトを保存し、スクリプトには実行権限「+X」もしくは「700」に設定
・「自分のホームディレクトリ」にバックアップ用「Backup」ディレクトリを作成
・「Backup」に「MariaDB」と「WordPress」のバックアップ用ディレクトリを作成

$ cd <—– ホームディレクトリに移動
$ mkdir ./bin <—– スクリプトを保存するディレクトリ
$ mkdir ./Backup <—– バックアップ保存用ディレクトリ
$ mkdir ./Backup/MariaDB <——– MariaDBデータ保存用ディレクトリ
$ mkdir ./Backup/Wp-content <—— WordPressコンテンツ保存用ディレクトリ

スクリプトのダウンロードと展開

下記からダウンロードし、展開して使用します。
https://www.kazuban.com/soft/wordpress-back-restore.tar.gz

$ cd 
$ wget https://www.kazuban.com/soft/wordpress-back-restore.tar.gz
$ tar xvzf wordpress-back-restore.tar.gz
$ cd .bin
$ chmod 700 ./*
$ ls
MariaDB_Backup.sh  MariaDB_Restore.sh  Tidyup_backfile.sh  Wp-ContentRestore.sh  Wp-Content_Backup.sh

５個のスクリプトが展開されます。
・MariaDB_Backup.sh　　　MariaDBデータベースのバックアップ
・MariaDB_Restore.sh　　　MariaDBデータベースの復元
・Tidyup_backfile.sh 　バックアップデータの整理
・Wp-ContentRestore.sh　　WordPressコンテンツの復元
・Wp-Content_Backup.sh　　WordPressコンテンツのバックアップ

自分の環境に合わせて、編集

MariaDBデータベースのバックアップスクリプト

自分の環境に合わせて、変数を編集します。

#!/bin/sh
#
#  MariaDB_Backup.sh    2023/12
#
#------------------------------------
BackupDir="/home/hogehoge/Backup/MariaDB"   <-------- バックアップディレクトリ
MysqlUser="WpAdmin"                        <-------- WordPressのユーザー
MysqlUserPasswd="WpPasswd"                 <-------- WordPressユーザーのパスワード
TidyUpScript="/home/hogehoge/bin/Tidyup_backfile.sh" <---- データ整理スクリプト
DaysAgo="4"               <-------- データを整理する日数
LOG="mariadb_backup.log"　<------- ログファイル名
#------------------------------------
　　・
　　・

実行すると、バックアップを開始します。
設定されている、バックアップディレクトリに、
「実行時の日付」-MariaDB.bak　の名前で保存されます
もし、古いバックアップがある場合、その作成日が「DaysAgo=”4″」より古い場合削除されます

MariaDBデータベースの復元スクリプト

自分の環境に合わせて、変数を編集します。

#!/bin/sh
#
#  MariaDB_Restore.sh    2024/02
#
#------------------------------------
BackupDir="/home/hogehoge/Backup/MariaDB"     <-------- バックアップディレクトリ
MySqlPasswd="Password"                        <-------- MariaDBのパスワード
DataBase="WpDb"                               <-------- WordPressデータベース
#------------------------------------
PreBackup="Y"   # Do you want to back up? Y/N <---- 事前バックアップの有無
PreBackupFile="Pre-Backup.bak"                <------事前バックアップのファイル名
MysqlUser="WpAdmin"                           <----- WordPressデータベースユーザー
MysqlUserPasswd="WpPassword"                    <-------- WordPressユーザーのパスワード
BackupScript="/home/hogehoge/bin/MarinaDB_Backup.sh"
#------------------------------------
echo "--------------------"
　　・
　　・

復元スクリプトは、引数なしで実行すると、バックアップディレクトリに保存されているファイルのリストを表示するので、再度バックアップしたい日付のファイルを引数に指定して実行します。
「PreBackup=”Y”」に設定されている場合には、
復元前の状態のバックアップととり、確認後復元を開始します

$ ./MariaDB_Restore.sh     <---- 引数なしで実行
--------------------
/home/hogehoge/Backup/MariaDB　　<----- バックアップディレクトリ内のファイルを表示
20240625-MariaDB.bak
20240626-MariaDB.bak
20240627-MariaDB.bak
20240628-MariaDB.bak
20240629-MariaDB.bak
--------------------
MariaDB_Restore.sh [Backup file name]
--------------------
-- You are able to select from the list above.--
--------------------

$ ./MariaDB_Restore.sh 20240629-MariaDB.bak　<---- ファイルを指定して再実行
--------------------
/home/hogehoge/Backup/MariaDB
20240629-MariaDB.bak
--------------------
--------------------
preliminary backup start.  <----- 実行前データバックアップ
mysqldump -u WpAdmin -pWpPassword -h localhost -A  > 20240629-Pre-Backup.bak
-- The backup is complete. --
--------------------
-- Mysql restore start --
mysql -u root -pPassword WpDb < 20240629-MariaDB.bak
Restore?(y/n):y   <----- 確認

WordPress内容の復元スクリプト

自分の環境に合わせて、変数を編集します。

#!/bin/sh
#
#       WP-contentRestor.sh   2024/02
#
#--------------------------------------------
BackupDir="/home/hogehoge/Backup/Wp-content" <---- WordPressのバックアップディレクトリ
WordPressWpContentDir="/home/www/html/blog/wp-content"　　<----WordPressコンテンツ本体 
#------------------------------------
echo "--------------------"
　　・
　　・

MariaDBと同様に、引数なしで実行すると、バックアップディレクトリに保存されているファイルのリストを表示するので、再度バックアップしたい日付のファイルを引数に指定して実行します
復元前の状態のバックアップととり、確認後復元を実行します

$ ./Wp-ContentRestore.sh
--------------------
/home/hogehoge/Backup/Wp-content　　<----- バックアップディレクトリ内のファイルを表示
20240625-Wp-content.tar.gz
20240626-Wp-content.tar.gz
20240627-Wp-content.tar.gz
20240628-Wp-content.tar.gz
20240629-Wp-content.tar.gz
wp-content_backup.log
--------------------
Wp-content_Backup.sh [????????-Wp-content.tar.gz] 
--------------------
-- You are able to select from the list above.--
--------------------

$ ./Wp-ContentRestore.sh 20240629-Wp-content.tar.gz　<---- ファイルを指定して再実行
--------------------
/home/hogehoge/Backup/Wp-content
20240625-Wp-content.tar.gz
20240626-Wp-content.tar.gz
20240627-Wp-content.tar.gz
20240628-Wp-content.tar.gz
20240629-Wp-content.tar.gz
wp-content_backup.log
--------------------
--------------------
/home/hogehoge/Backup/Wp-content
tar xzf 20240629-Wp-content.tar.gz  <----展開、容量により時間がかかります
---- Restore --------
sudo mv /home/www/html/blog/wp-content /home/www/html/blog/wp-content-20240629
sudo mv /home/hogehoge/Backup/Wp-content /home/www/html/blog/wp-content /home/www/html/blog/wp-content
sudo chown -R apache:apache /home/www/html/blog/wp-content/
Restore completed!
--------------------

WordPress内容のバックアップスクリプト

自分の環境に合わせて、変数を編集します。

#!/bin/sh
#
#       WP-content_Backup.sh    2020/03
#                               2023/12
#
#--------------------------------------------
BackupToDir="/home/hogehoge/Backup/Wp-content" <-- WordPressのバックアップディレクトリ
BackupSorceDir="/home/www/html/blog/wp-content"<----WordPressコンテンツ本体
TidyUpScript="/home/hogehoge/bin/Tidyup_backfile.sh" <---- データ整理スクリプト
DaysAgo="4"               <-------- データを整理する日数
LOG="wp-content_backup.log"　<------- ログファイル名
#--------- Help -----------------------------
　　・
　　・

バックアップは引数なしで実行が始まります。
事前にWordPressのディレクトリを日付付きのファイルに圧縮して保存します

$ ./Wp-Content_Backup.sh
tar czf 20240629-Wp-content.tar.gz /home/www/html/blog/wp-content/  <---- 事前バックアップ
rm 20240625*  <--- バックアップファイル整理
rm 20240626*

バックアップ自動化

Linux の「Crontab」コマンドで、スケジューリングする事で自動的にバックアップする事も可能になります。
「crontab -e」でスケジュールを編集し、「crontab -l」で確認できます。
また、「MAILTO=」を設定する事で、指定ユーザーに結果をメールを送信してくれます

$ crontab -e
MAILTO=root
00 1 * * *       /home/hogehoge/bin/MariaDB_Backup.sh
30 1 * * *       /home/hogehoge/bin/Wp-Content_Backup.sh

$ crontab -l
MAILTO=root
00 1 * * *       /home/hogehoge/bin/MariaDB_Backup.sh
30 1 * * *       /home/hogehoge/bin/Wp-Content_Backup.sh

これで、プラグインを使用しなくても、Wordpressのバックアップが可能になりました。

Ubuntu24.04LTSでWordPressを構築する記事一覧

インストール・SSH・ファイヤーウォール

Apache2のインストールと設定

SSL、PHP、MariaDB、Let’s Encrypt証明書でhttps化

WordPress インストール、バックアップと復元

ファイヤーウォール設定の確認

ここでのファイヤーウォールは、「firewalld」を使用しています。
今までの設定を確認してみます。

$ firewall-cmd --get-active-zones
admin
  sources: 192.168.0.0/24
public (default)
  interfaces: wlp8s0

$ sudo firewall-cmd --list-all --zone=public | grep services
  services: dhcpv6-client http https
$ sudo firewall-cmd --list-all --zone=admin | grep services
  services: dhcpv6-client http https ssh

「https」の許可は完了しています。

sslモジュールを有効化

「ubuntu」では、有効なモジュールは「/etc/apache2/mods-enabled/」にシンボリックリンクとしてファイルが存在すれば、有効になっています。
私の環境では、有効になっていないようですので、「a2enmod ssl」で有効にします。

$ sudo a2enmod ssl
Considering dependency mime for ssl:
Module mime already enabled
Considering dependency socache_shmcb for ssl:
Enabling module socache_shmcb.
Enabling module ssl.
See /usr/share/doc/apache2/README.Debian.gz on how to configure SSL and create self-signed certificates.
To activate the new configuration, you need to run:
  systemctl restart apache2

$ sudo systemctl restart apache2

Certbot クライアントのインストールと証明書取得

Let’s Encrypt から証明書を取得するには、「Certbot」を利用するので、パッケージを確認してみます。

$ apt list | grep certbot
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

certbot/noble 2.9.0-1 all
　　・
　　・
python3-certbot-apache/noble 2.9.0-1 all
　　・
　　・

パッケージの確認ができたので、インストールします

$ sudo apt update
$ sudo apt upgrade
$ sudo apt install certbot
$ sudo apt install python3-certbot-apache

インストールが完了したら、証明書をゲットします。
コマンドオプションは「certonly」「–webroot」で取得できますが、
対象のサーバでWebサーバーが動作しており、外部から８０番ポートへアクセスできる必要があります。

$ sudo certbot certonly --webroot -w /home/www/html/ -d www.hogehoge.com -d hogehoge.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Enter email address (used for urgent renewal and security notices)
 (Enter 'c' to cancel): hoge@hogehoge.com <------自分のEメールアドレスを入力

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at
https:// letsencrypt.org/documents/LE-SA-v1.4-April-3-2024.pdf. You must agree in
order to register with the ACME server. Do you agree?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: y　<----- 利用規約を読んでください

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you be willing, once your first certificate is successfully issued, to
share your email address with the Electronic Frontier Foundation, a founding
partner of the Let's Encrypt project and the non-profit organization that
develops Certbot? We'd like to send you email about our work encrypting the web,
EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: y  <--------- 電子フロンティア財団からEメールが届いてもいいか？
Account registered.
Requesting a certificate for www.hogehoge.com and kazuban.com
Requesting a certificate for www.hogehoge.com and kazuban.com

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/www.hogehoge.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/www.hogehoge.com/privkey.pem
This certificate expires on 2024-09-12.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
 * Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
 * Donating to EFF:                    https://eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Successfullyで取得できました。またコメントにより、
証明書ファイル：/etc/letsencrypt/live/www.hogehoge.com/fullchain.pem
鍵ファイル：/etc/letsencrypt/live/www.hogehoge.com/privkey.pem
が保存された事がわかります。
証明書の設定は「/etc/apache2/sites-available」の「default-ssl.conf」を編集し
「a2ensite default-ssl」で有効にします。

$ cd /etc/apache2/sites-available
$ sudo cp -p default-ssl.conf default-ssl.conf.org
$ sudo vi ./default-ssl.conf
<VirtualHost *:443>
        #ServerAdmin webmaster@localhost
        ServerAdmin root@hogehoge.com

        #DocumentRoot /var/www/html
        DocumentRoot /home/www/html
　　　　　　・
　　　　　　・
        #   A self-signed (snakeoil) certificate can be created by installing
        #   the ssl-cert package. See
        #   /usr/share/doc/apache2/README.Debian.gz for more info.
        #   If both key and certificate are stored in the same file, only the
        #   SSLCertificateFile directive is needed.
        #SSLCertificateFile      /etc/ssl/certs/ssl-cert-snakeoil.pem
        #SSLCertificateKeyFile   /etc/ssl/private/ssl-cert-snakeoil.key
        SSLCertificateFile  /etc/letsencrypt/live/www.hogehoge.com/fullchain.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/www.hogehoge.com/privkey.pem
　　　　　　・
　　　　　　・
</VirtualHost>

$ sudo a2ensite default-ssl

PHPのインストール

インストール

$ sudo apt install php
$ sudo apt install php-fpm
$ php -v
PHP 8.3.6 (cli) (built: Apr 15 2024 19:21:47) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.3.6, Copyright (c) Zend Technologies
    with Zend OPcache v8.3.6, Copyright (c), by Zend Technologies

WordPressサイトを参考に拡張モジュールをインストールします
パッケージ管理が違うので、すでに違うパッケージでインストール済みだったり
パッケージ名が見つからない場合がありましたが、とりあえず、このまま進みます

インストール済み
$ sudo apt install php-exif
$ sudo apt install php-fileinfo
$ sudo apt install php-opcache
$ sudo apt install php-iconv
$ sudo apt install php-ftp
$ sudo apt install php-sockets
$ sudo apt install php-shmop

インストール実行
$ sudo apt install php-curl
$ sudo apt install php-dom
$ sudo apt install php-mbstring
$ sudo apt install php-xml
$ sudo apt install php-igbinary
$ sudo apt install  php-intl
$ sudo apt install php-imagick
$ sudo apt install php-zip
$ sudo apt install php-redis
$ sudo apt install php-ssh2

パッケージが見つかりません
$ sudo apt install php-hash
$ sudo apt install php-openssl
$ sudo apt install php-pcre
$ sudo apt install php-filter
$ sudo apt install php-bc
$ sudo apt install php-image

fpm版のphpインストールと切り替え

ApcheのMPMは、「preforkMPM」「workerMPM」「eventMPM」の３種類あるようですが
Apache2.4系から導入されたのが「eventMPM」で、CPUとメモリの使用量が少ないようです。
「centos」ではデフォルトで「eventMPM」になっていますが、「Ubuntu」は「preforkMPM」がデフォルトのようなので、下記サイトを参考に「eventMPM」に切り替えたいと思います。
https://qiita.com/Nelson605/items/e3a8d10c1415dd0c5c0b
https://doudonn.com/saba/2491

$ sudo apt install php8.3-fpm
$ sudo a2enmod proxy_fcgi setenvif
$ sudo a2enconf php8.3-fpm
$ sudo a2dismod php8.3
$ sudo systemctl restart apache2

$ sudo a2dismod mpm_prefork
$ sudo a2enmod mpm_event
$ sudo systemctl restart apache2
$ sudo systemctl restart php8.3-fpm

php-fpm設定ファイルの変更

php-fpmの設定は「/etc/php/8.3/fpm/pool.d/www.conf」で行います。
php-fpmを動作させるユーザーとグループについては、Apache側での設定に合わせる必要があります。また、listenオーナーとlistenグループも、Apacheに合わせます。
バックアップ後編集していきます。

$ sudo cp -p www.conf www.conf.org
$ sudo vi /etc/php/8.3/fpm/pool.d/www.conf
　　・
　　・
;user = www-data
;group = www-data
user = apache
group = apache
　　・
;listen.owner = www-data
;listen.group = www-data
listen.owner = apache
listen.group = apache
　　・
　　・

HTTP/2を利用する。
eventMPMモジュールとhttp2モジュールを有効

SSLサーバー証明書がとれたので、HTTP/2も利用したいと思います
有効なモジュールは「apachectl -M」で確認できます。
「mpm_event_module」は有効になっていましたが、「http2_module」はなっていなかったので有効にします。
「a2enmod http2」で有効にし、「apache2」を再起動後、「apachectl -M」で再確認します

$ sudo a2enmod http2
$ sudo  systemctl restart apache2

$ apachectl -M | grep http2
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message
 http2_module (shared)

「http2」は有効になりましたが、エラーがでました。
「VirtualHost *:80」に設定したからいいと思っていましたが、メインにも設定した方がよさそうです
「/etc/apache2/apache2.conf」にも設定を追加しました
「apache2ctl configtest」で確認し、OKだったので、再起動するとエラーは消えました。

$ sudo vi /etc/apache2/apache2.conf
　　・
　　・
ServerName www.hogehoge.com
　　・
$ sudo apache2ctl configtest
Syntax OK
$ sudo  systemctl restart apache2
$ apachectl -M | grep http2
 http2_module (shared)

http2通信の確認

Google Chrome での確認方法を紹介します。
・アドレスバーにサイトのURLを入力し表示させる。
・「F12」キーを押す。
・「Ctrl」＋「R」で再読み込み
・「Network」「Protocol」・「h2」で確認

php.iniの設定

このサイトでも「RockyLinux9」での設定を説明していますが、同様に設定したいと思います。
「ubuntu」での設定は、「/etc/php/8.3/fpm/php.ini」で行います。
念のためバックアップを取り、編集します。

$ sudo cp -p /etc/php/8.3/fpm/php.ini /etc/php/8.3/fpm/php.ini.org
$ sudo vi /etc/php/8.3/fpm/php.ini

expose_php = Off

;post_max_size = 8M
post_max_size = 128M

;upload_max_filesize = 2M
upload_max_filesize = 128M

;date.timezone =
date.timezone = "Asia/Tokyo"

;mbstring.language = Japanese
mbstring.language = Japanese

;mbstring.internal_encoding =
mbstring.internal_encoding = UTF-8

;mbstring.http_input =
mbstring.http_input = UTF-8

;mbstring.http_output =
mbstring.http_output = pass

;mbstring.encoding_translation = Off
mbstring.encoding_translation = On

;mbstring.detect_order = auto
mbstring.detect_order = auto

;mbstring.substitute_character = none
mbstring.substitute_character = none

$ sudo systemctl restart php8.3-fpm
$ sudo systemctl restart apache2
$ sudo systemctl is-enabled php8.3-fpm.service 
enabled

Webブラウザで確認

PHP設定の情報を出力させるコマンド「phpinfo()」を実行させるファイル「index.php」を作成します

$ cd /home/www/html
$ su
パスワード: 
# echo '<?php phpinfo(); ?>' > index.php

「index.php」ファイルが作成されたら、Webブラウザのアドレスバーから確認できます。

「index.php」は、確認が終了したら、必ず削除しましょう。

MariaDBのインストールと設定

「ubuntu」での「MariaDB」パッケージを確認してみます。

$ apt list mariadb*
一覧表示... 完了
　　・
　　・
mariadb-server/noble-updates,noble-security 1:10.11.8-0ubuntu0.24.04.1 amd64
　　・

インストール

提供されているので、インストールします。

$ sudo apt update
$ sudo apt upgrade
$ sudo apt install mariadb-server
・

$ systemctl status mariadb　
● mariadb.service - MariaDB 10.11.8 database server
     Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; preset: enabled)
     Active: active (running) since Sat 2024-06-22 08:54:42 JST; 7min ago
$ sudo systemctl is-enabled mariadb
enabled

自動的に起動と自動起動設定も完了していました。

基本的なセキュリティ設定

「mysql_secure_installation」で設定します。

# mysql_secure_installation
・
Enter current password for root (enter for none): <-- パスワード入力だけど
OK, successfully used password, moving on...           設定していない場合は「Enter」
・
・                                           
Switch to unix_socket authentication [Y/n] n <--- 「unix_socket」認証に切り替えるか？
・
・
Change the root password? [Y/n] Y <---- MariaDBのrootユーザに変更するか
・
New password:               <---- パスワード入力
Re-enter new password:      <---- パスワード入力
Password updated successfully!
・
・
By default, a MariaDB installation has an anonymous user, allowing anyone
Remove anonymous users? [Y/n] Y     <----- ログインできる匿名ユーザーを削除するか？
 ... Success!
・
Disallow root login remotely? [Y/n] Y  <-- リモートからのrootログイン不許可？
 ... Success!
・
Remove test database and access to it? [Y/n] Y  <-- 「test」データベースの削除？
・
 ... Success!
・
Reload privilege tables now? [Y/n] Y  <---- 設定した特権テーブルを反映させるか？
 ... Success!
・
・
Thanks for using MariaDB!

文字コードの設定

文字コードを「utf8mb4」に設定します。
「CentOS」系では「/etc/my.cnf.d/mariadb-server.cnf」を編集しましたが、
「ubuntu」では、このファイルは見つかりません。
探してみると、「server」用と「client」用の２種類で設定するようです
・/etc/mysql/mariadb.conf.d/50-server.cnf
・/etc/mysql/mariadb.conf.d/50-client.cnf
いつものように、バックアップして編集しますが、「50-server.cnf」はデフォルトで「utf8mb4」に設定されていたのでそのまま使用し「50-client.cnf」のみ編集します。

$ cd /etc/mysql/mariadb.conf.d/
$ sudo cp -p 50-client.cnf 50-client.cnf.org
$ sudo vi ./50-client.cnf
　　・
　　・
[client-mariadb]
# ---- 2024/06/23 add
default-character-set = utf8mb4   <------- 追加
　　・
$ sudo systemctl restart mariadb
$ sudo systemctl status mariadb

確認してみます

$ mysql -u root -p
Enter password:       <------ root パスワード入力
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 31
Server version: 10.11.8-MariaDB-0ubuntu0.24.04.1 Ubuntu 24.04

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> show variables like "chara%";
+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | utf8mb4                    |
| character_set_connection | utf8mb4                    |
| character_set_database   | utf8mb4                    |
| character_set_filesystem | binary                     |
| character_set_results    | utf8mb4                    |
| character_set_server     | utf8mb4                    |
| character_set_system     | utf8mb3                    |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
8 rows in set (0.004 sec)

MariaDB [(none)]> quit
Bye

「RockyLinux9」で設定した時は、システム再起動しないと反映されませんでしたが、今回はすぐに反映されていました。
ここまでで、「WordPress」を動作させる環境が整いました。
次回、「WordPress」を動作させます。

Ubuntu24.04LTSでWordPressを構築する記事一覧

インストール・SSH・ファイヤーウォール

Apache2のインストールと設定

SSL、PHP、MariaDB、Let’s Encrypt証明書でhttps化

WordPress インストール、バックアップと復元

「ubuntu」のapache は「apache2」パッケージで提供されているようですが、名前の違いだけではなく、設定作法が「centos」はかなり違っています。

Apache2インストール

「RockyLinux9」へのインストールは、こちらで紹介しています　ので参考にしてください。
「ubuntu」は「apt install apache2」でインストールします

$ sudo apt update
$ sudo apt upgrade
$ sudo apt install apache2

「ubuntu」は、「apt」でインストールすると、自動的に起動設定が終了しているようですね。

$ systemctl status  apache2
● apache2.service - The Apache HTTP Server
     Loaded: loaded (/usr/lib/systemd/system/apache2.service; enabled; preset: enabled)
     Active: active (running) since Sat 2024-06-20 11:03:54 JST; 9min ago
       Docs: https://httpd.apache.org/docs/2.4/
   Main PID: 73404 (apache2)
      Tasks: 55 (limit: 9342)
     Memory: 5.6M (peak: 6.8M)
        CPU: 108ms
     CGroup: /system.slice/apache2.service
             ├─73404 /usr/sbin/apache2 -k start
             ├─73406 /usr/sbin/apache2 -k start
             └─73407 /usr/sbin/apache2 -k start
$ systemctl is-enabled apache2
enabled

firewalld に許可

前回、ファイヤーウォールは、「firewalld」に切り替えたので「apach2」にも、こちらを参考に、http と https を許可しておきます。
これで、Webブラウザのアドレスバーに、IPアドレスを打ち込むとデフォルトページが表示されるはずです。

apache2 設定作法

「ubuntu」では、「ＣentOS系」とは設定作法がかなり違うようです。
インストール直後の「apach2設定ディレクトリ」を確認してみると

/etc/apache2/
├── apache2.conf
├── conf-available
│   ├── charset.conf
│   ├── ・
├── conf-enabled
│   ├── charset.conf -> ../conf-available/charset.conf
│   ├── ・
├── envvars
├── magic
├── mods-available
│   ├── access_compat.load
│   ├── ・
├── mods-enabled
│   ├── access_compat.load -> ../mods-available/access_compat.load
│   ├── ・
├── ports.conf
├── sites-available
│   ├── 000-default.conf
│   └── default-ssl.conf
└── sites-enabled
    └── 000-default.conf -> ../sites-available/000-default.conf

途中、省略していますが「/etc/apache2」直下には
「apache2.conf」「magic」「envvars」「ports.conf」のファイルがあり
さらに「conf-*」「mods-*」「sites-*」で、
それぞれ「available」「enabled」が付いた名前のディレクトリがあります。

独特なのは、「*-available」と「*-enabled」のディレクトリです。
基本的には、「*-enabled」内のファイルだけが組み込まれますが、「*-enabled」内のファイルは、「*-available」内のファイルのシンボリックリンクになっています。
作法としては、「*-available」内に、設定ファイルを保存し、必要なファイルのみ「*-enabled」にシンボリックリンクを作成する方法です。
シンボリックリンク作成と削除は、専用コマンドが用意されています。

「conf-*」用は「a2enconf」で作成。「a2disconf」で削除
「mods-*」用は「a2enmod」で作成。「a2dismod」で削除
「sites-*」用は、「a2ensite」で作成。「a2dissite」で削除

apache2 のディレクトリ設定変更

筆者は、RockyLinux9 の設定と同様の設定にします。
まずは、「apache2.conf」の、<Directory>のデフォルト設定はコメントとし
Rockyと同様にしました。

・
・
<Directory />
    AllowOverride none
    Require all denied
</Directory>

<Directory "/home/www">
    AllowOverride None
    # Allow open access:
    Require all granted
</Directory>

<Directory "/home/www/html">
    Options FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>
・
・

ホスト名関連は、「sites-enabled」内の「000-default.conf」で設定します。
上述したように、「*-enables」は「*-available」のシンボリックリンクが入っているのでどちらのファイルを編集しても同じです
ただし、バックアップを残す場合には「*-available」のファイルをバックアップします。

$ cd /etc/apache2/sites-available/
$ sudo cp -p 000-default.conf 000-default.conf.org
$ cd /etc/apache2/sites-available/
$ sudo vi ./000-default.conf
・
・
#ServerName www.example.com
　　　↓
ServerName www.hogehoge.com
・
・
ServerAdmin webmaster@localhost
　　　↓
ServerAdmin root@hogehoge.com
・
・
DocumentRoot /var/www/html
　　　↓
DocumentRoot /home/www/html
・

apache2 が作業するユーザーとグループの変更

apache2が処理を要求する時のユーザーとグループを設定します
まずは、メインの設定ファイル、「/etc/apache2/apache2.conf」を覗いてみます。

$ vi /etc/apache2/apache2.conf
・
・
# These need to be set in /etc/apache2/envvars
User ${APACHE_RUN_USER}
Group ${APACHE_RUN_GROUP}
・
・

設定ファイルにあるように、
${APACHE_RUN_USER}
${APACHE_RUN_GROUP}
この二つの環境変数で設定されていて、この環境変数は、変数上記のコメントにあるように「/etc/apache2/envvars」で設定されています。
「ubintu」はデフォルトでは「www-data」になっていますが、私は「centos」にあわせて「apache」に変更しようと思います。
バックアップを取り、変更します。
続けて、「apache」ユーザーを作成し、ホームディレクトリを「/home/www」とします。

# Since there is no sane way to get the parsed apache2 config in scripts, some
# settings are defined via environment variables and then used in apache2ctl,
# /etc/init.d/apache2, /etc/logrotate.d/apache2, etc.
export APACHE_RUN_USER=www-data
export APACHE_RUN_GROUP=www-data
　　↓
export APACHE_RUN_USER=apache
export APACHE_RUN_GROUP=apache
　　・
　　・

$ sudo useradd -d /home/www -s /sbin/nologin apache

ドキュメントルートディレクトリの作成

Webに公開するコンテンツ格納ディレクトリを設定変更したので、
実際にそのディレクトリを作成します。

# mkdir /home/www
# mkdir /home/www/html
# chown apache:apache /home/www/html/
# ls -la /home/www

# systemctl restart apache2

セキュリティ対策

ICONページ一覧が表示されないようにする

ICONページ一覧の設定は、/etc/apache2/mods-enabled/alias.confで行います。
設定ファイルを開いてみます。

$ vi /etc/apache2/mods-enabled/alias.conf
　　・
　　・
# We include the /icons/ alias for FancyIndexed directory listings.  If
# you do not use FancyIndexing, you may comment this out.

Alias /icons/ "/usr/share/apache2/icons/"

<Directory "/usr/share/apache2/icons">
        Options FollowSymlinks
        AllowOverride None
        Require all granted
</Directory>

「ubuntu」では、「/etc/apache2/conf-enabled」のファイルをメイン設定として読み込みます。
ただし「conf-enabled」内のファイルは、「conf-available」内のファイルのシンボリックリンクになっているので、ファイルのバックアップを取る場合には
「/etc/apache2/conf-available/」内のファイルをバックアップをとり編集します。

「icons」ディレクトリの設定では「Options Indexes」がないので、一覧が表示される事はないと思いますが、その下のファイルをWebブラウザで指定すると表示されます。
特に必要ないので全てコメントにしようと思います。

$ cd /etc/apache2/mods-available
$ sudo cp -p alias.conf alias.conf.org
$ sudo vi alias.conf
　・
#Alias /icons/ "/usr/share/apache2/icons/"

#<Directory "/usr/share/apache2/icons">
#        Options FollowSymlinks
#        AllowOverride None
#        Require all granted
#</Directory>
　・
$ sudo systemctl restart apache2

Apacheバージョン情報を隠す

こちらと同様に、バージョン情報とOSの情報を隠します。
「telnet」で確認します。

$ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
OPTIONS / HTTP/1.1        <-------入力
host:localhost            <-------入力
                          <-------「Ebter」キー
HTTP/1.1 200 OK
Date: Sun, 23 Jun 2024 09:16:28 GMT
Server: Apache/2.4.58 (Ubuntu) <---- Apacheバージョン情報
Allow: GET,POST,OPTIONS,HEAD
Content-Length: 0
Content-Type: text/html

Connection closed by foreign host.

「/etc/apache2/conf-enabled」の「security.conf」で行いますが、上記と同様に
「/etc/apache2/conf-available/security.conf」のバックアップをとり編集します。

$ cd /etc/apache2/conf-available
$ sudo cp -p security.conf security.conf.org
$ sudo vi ./security.conf

#ServerTokens Minimal
ServerTokens OS
#ServerTokens Full
　　↓
#ServerTokens Minimal
#ServerTokens OS
#ServerTokens Full
ServerTokens ProductOnly

#ServerSignature Off
ServerSignature On
　　↓
ServerSignature Off
#ServerSignature On

$ sudo systemctl restart apache2 

telnetで再確認

$ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
OPTIONS / HTTP/1.1        <-------入力
host:localhost            <-------入力
                          <-------「Ebter」キー
HTTP/1.1 200 OK
Date: Sun, 23 Jun 2024 09:18:18 GMT
Server: Apache 　　<---- Apacheバージョン情報は消えた
Allow: GET,POST,OPTIONS,HEAD
Content-Length: 0
Content-Type: text/html

Connection closed by foreign host.

X-Frame-Optionsヘッダ設定

クリックジャッキングを防ぐための対策に有効だと言う事なので、
X-Frame-Optionsヘッダ設定をしておこうと思います。
「mod_headers」機能が有効になっているかの確認をします。
有効なモジュール構成は、「/etc/apache2/mods-enabled」に登録されているはずですが、なさそうです。
「*-enabled」はシンボリックが登録されているだけなので、「*-available」内を調べてみます。
「/etc/apache2/mods-available」に「headers.load」が保存されていたので、有効にすることで使用できるようになりますが、設定ファイルも必要です。
X-FRAME-OPTIONSオプションを追加する設定ファイル「headers.conf」を作成します。
次にこのファイルのシンボリックリンクを「*-enabled」に作成しますが、作成するには、「a2enmod」コマンドでおこないます。
リンクが作成できたら、「telnet」で確認してみます。

$ cd /etc/apache2/mods-available
$ sudo vi headers.conf
　　・
#--- 2024.06.23 hogehoge
Header append X-FRAME-OPTIONS "SAMEORIGIN"
　　・

$ sudo a2enmod headers
Enabling module headers.
To activate the new configuration, you need to run:
  systemctl restart apache2

$ sudo systemctl restart apache2
$ telnet localhost 80　　　<---- telnetで確認
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
OPTIONS / HTTP/1.1        <-------入力
host:localhost            <-------入力
                          <-------「Ebter」キー
HTTP/1.1 200 OK
Date: Sun, 23 Jun 2024 09:23:57 GMT
Server: Apache
Allow: GET,POST,OPTIONS,HEAD
X-FRAME-OPTIONS: SAMEORIGIN    <---- 有効確認
Content-Length: 0
Content-Type: text/html

Connection closed by foreign host.

ドキュメントルートにindex.htmlを作成

デフォルトのトップページ「index.html」を作成しておきます。
保存後、ファイルの所有者を「Apache」のユーザー「apache」に変更し再起動しておきます。

$ cd /home/www/html/
# vi ./index.html 
・
<html>
  <body>
    <h1>This website is currently under maintenance.</h1>
  </body>
</html>
・
# chown -R apache:apache /home/www/html/
# systemctl restart apache2

CGIスクリプトを利用する

もし必要であえば、CGIスクリプトを利用できるようにしておきます
「a2enmod cgid」で、「cgid」モジュールを有効にし「serve-cgi-bin.conf」に動作させたいCGIスクリプトを登録するディレクトリの設定を行い、そのディレクトリがなければ作成します。
「AddHandler cgi-script .cgi」では、「.cgi」拡張子のみCGIスクリプトとして使用できます

$ sudo a2enmod cgid
Enabling module cgid.
To activate the new configuration, you need to run:
  systemctl restart apache2

$ cd conf-available/
$ sudo cp -p serve-cgi-bin.conf serve-cgi-bin.conf.org
$ sudo vi ./serve-cgi-bin.conf

<IfModule mod_alias.c>
        <IfModule mod_cgi.c>
                Define ENABLE_USR_LIB_CGI_BIN
        </IfModule>

        <IfModule mod_cgid.c>
                Define ENABLE_USR_LIB_CGI_BIN
        </IfModule>

        <IfDefine ENABLE_USR_LIB_CGI_BIN>
                #AddHandler cgi-script .cgi
                <Directory /home/www/html/script>
                        AllowOverride None
                        Options ExecCGI FollowSymLinks
                        Order allow,deny
                        Allow from all
                        AddHandler cgi-script .cgi
                </Directory>
        </IfDefine>
</IfModule>

$ sudo mkdir /home/www/html/script
$ sudo systemctl restart apache2

apache2設定終了

「apache」の設定は、「RHEL系」とはかなり違っていて、結構時間がかかりました。

Ubuntu24.04LTSでWordPressを構築する記事一覧

インストール・SSH・ファイヤーウォール

Apache2のインストールと設定

SSL、PHP、MariaDB、Let’s Encrypt証明書でhttps化

WordPress インストール、バックアップと復元

ubuntu24.04 インストール

こちらから、Ubuntu Desktop 24.04 LTS　のディスクイメージを入手します。
インストールメディアはUSBメモリで作成しました。

自動パーティションで立ち上がらない

インストール領域は、自動パーティションを選択し、問題なくインストールは完了しましたが、
再起動後、立ち上がりません。
ブートローダが起動しない感じです。
ハードウェアの不良も疑い、試しに手持ちのRHEL系「Rocky-8.x86_minimal.iso」を上書きインストールしてみましたが、問題なく起動しました。
ハードの不良ではなさそう！なので、自動パーティショニングがうまくいってない感じです。
再度、「Ubuntu24.04」をインストールを試みます。
正常に起動した「Rocky9」では、/dev/sda1の1G領域に「/boot」、/dev/sda2に残り領域と設定されていたので、再インストールでも、自動を使わず手動パーティショニングで/dev/sda1を「/boot」に、/dev/sda2を「/」のマウントポイントの設定で再インストールしたところ無事に起動できました。
ブートローダが書き込まれる「/boot」のファイルシステムがなにか悪さしていたような気がしますが、よくわかりません。
「RHEL」を自動パーティションさせた状態に、「ubuntu」を自動パーティションでインストールするとうまくいかない感じですが、とりあえず、起動したので、良しとしましょう！

Ubuntuと、CentOS 、かなりの違います

もとは同じ「linux」ですが、ＲedHat系とDebian系では、いろいろ違うみたいですね。
かなり戸惑ってしまいました。

rootパスワード

「ubuntu」では、インストール時に、「root」パスワードを設定する項目がありません。
基本的に「su」で「root」になって作業しない！がコンセプトなのでしょうか？
だた、「su」になったほうが楽な場合もあるので、「rootパスワード」を設定しておきます。

$ sudo passwd root
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully

特定のユーザーにsudo 権限を設定

ユーザーの実行制限を記述してあるudoersファイルを編集し「sudo」でパスワードなしで実行できるように設定しておきます。
このファイルを編集するには、安全に編集するコマンド「visudo」で行います。
コマンド名は、「CentOS」と同じですが、若干の違いがありました。
「visudo」は「centos」では、純粋な「viエディタ」と同じ操作でしたが、「ubuntu」では、一般的なエディタに近い操作感だったので、戸惑いました。

$ sudo visudo
・
・
# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL
・
## Same thing without a password
%sudo  ALL=(ALL)       NOPASSWD: ALL
・
・

この設定で、「特定グループ」に属するユーザーに、全てのコマンド実行の許可が、パスワードなしで与えられます。
「ubuntu」では「sudoグループ」が「特定グループ」になりますので、ユーザーを「sudol」グループに追加します。

$ sodo usermod -aG sudo $USER
$ newgrp docker

ssh

「ubuntu24.04 LTS」は標準で「ssh」はインストールされているみたいですが、他のPCからは接続できません。
とりあえず、インストール状態を調べてみます。
「centos」 では、パッケージ管理ソフトは「dnf」なので「dnf list –installed | grep openssh」で調べられます。
ubuntu のパッケージ管理ソフトは「apt」ですが、オプションはほぼ同じようなので、
「apt list –installed | grep openssh」で調べられそうですが「WARNING:・・・」が出力されました。
調べてみると、下記サイトが参考になります。
https://qiita.com/taro-hida/items/666c1b1cdc851b038215
現状では、「WARNING」がでるだけで、検索結果は表示してくれますが、インストール済みパッケージを調べるには「dpkg -l」でも調べられ、こちらであれば、パイプ処理でも「WARNING」はでません。
いずれかで調べると「openssh-client」はインストールされていましたが、「openssh-server」がインストールされていませんでしたので、インストールし、再起動時にも「ON」にする設定します。
ただ、「ubuntu」は、インストールすると自動的に起動と再起動時の設定も完了しているようです。

sudo apt install openssh-server
sudo systemctl enable ssh
systemctl is-enabled ssh

さらに、「鍵認証方式で運用」「リモートからのRootログイン拒否」「sshのポート番号変更」の設定をします。
このサイトでも、RockyLinuxで設定方法を紹介していますので、参考にしてみてください。
https://www.kazuban.com/blog/rockylinux9-3-ssh/#toc6
https://www.kazuban.com/blog/rockylinux9-3-ssh/#toc9
https://www.kazuban.com/blog/rockylinux9-3-ssh/#toc11

設定が終了したら、sshを再ロードしますが、サービス名が「centos」とは違うみたいで注意が必要です。
「sshd.service」ではなく「ssh.service」のようです。

$ sudo systemctl reload sshd.service
Failed to reload sshd.service: Unit sshd.service not found.
・
・not found でエラーになりました
・
$ sudo systemctl reload ssh.service
・・・ssh.service なら、エラーになりませんでした

ところが、ポート番号などの変更が反映されていません。
ネット探索しましたが、わかりませんでしたが、再起動「reboot」したところ反映されました。
また、後ほど気が付きましたが、いつの間にか、「sshd.service」名も「ssh.service」のシンボリックリンクとして作成されていて、「sshd.service」でも動作可能になっていました。

時計同期

centosでは、「chronydサービス」が動作していましたが、「ubuntu」では動いていません。
「ubuntu24.04 LTS」では、「systemd-timesyncd」を使うようです。

# sudo systemctl status chronyd
Unit chronyd.service could not be found.
・
・
sudo systemctl status systemd-timesyncd
● systemd-timesyncd.service - Network Time Synchronization
     Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; preset: enabled)
     Active: active (running) since Sat 2024-05-01 10:38:06 JST; 12s ago
       Docs: man:systemd-timesyncd.service(8)
   Main PID: 35255 (systemd-timesyn)
     Status: "Contacted time server [2001:df0:232:eea0::fff4]:123 (ntp.nict.jp)."
      Tasks: 2 (limit: 9342)
     Memory: 1.4M (peak: 1.9M)
        CPU: 59ms
     CGroup: /system.slice/systemd-timesyncd.service
             └─35255 /usr/lib/systemd/systemd-timesyncd

またNTPサーバーは、デフォルトで「ntp.ubuntu.com」が設定されているようです。
このままでも、問題ないと思いますが、国内の「ntp.nict.jp」に設定します。
「sudo vi /etc/systemd/timesyncd.conf」の最終行に
「NTP=ntp.nict.jp」
を追加しました。

$ sudo vi /etc/systemd/timesyncd.conf
・
・
[Time]
#NTP=
#FallbackNTP=ntp.ubuntu.com
#RootDistanceMaxSec=5
#PollIntervalMinSec=32
#PollIntervalMaxSec=2048
#ConnectionRetrySec=30
#SaveIntervalSec=60
NTP=ntp.nict.jp
・
・
$ systemctl status systemd-timesyncd

ファイヤーウォール

RockyLinux9では、firewalld が一般的ですが、ubuntuでは、「ufw」ツールがデフォルトでインストールされていて、すでに、自動起動していました。

$ systemctl status ufw.service
● ufw.service - Uncomplicated firewall
     Loaded: loaded (/usr/lib/systemd/system/ufw.service; enabled; preset: enabled)
     Active: active (exited) since Wed 2024-05-01 20:04:54 JST; 1 day 19h ago
       Docs: man:ufw(8)
   Main PID: 800 (code=exited, status=0/SUCCESS)
        CPU: 7ms

筆者は、centosサーバーで「firewalld」を利用していので、「ubuntu」にもパッケージがあれば
そちらを利用しようと思います。

$ apt list firewalld
一覧表示... 完了
firewalld/noble,now 2.1.1-1 all

パッケージがありましたので、「ufw」は停止して、「firewalld」をインストールします。

$ sudo systemctl stop ufw
$ sudo systemctl disable ufw
$ sudo systemctl status ufw
○ ufw.service - Uncomplicated firewall
     Loaded: loaded (/usr/lib/systemd/system/ufw.service; disabled; preset: enabled)
     Active: inactive (dead)
       Docs: man:ufw(8)

$ systemctl is-enabled ufw
disabled

$ sudo apt install firewalld

「firewalld」は、インストールできました。
設定は、以前記事にした、centosでの設定と同様に設定しました。
詳細は、下記を参照しいてください。

RockyLinux9.３で自宅サーバーを再構築V03・firewalldでアクセス制御

firewalldを少し詳しく調べていました。 一例として、sshサービスを、LAN内（指定アドレス）からのみ接続可能な設定にしました。

www.kazuban.com

2024.01.06

Ubuntu24.04LTSでWordPressを構築する記事一覧

インストール・SSH・ファイヤーウォール

Apache2のインストールと設定

SSL、PHP、MariaDB、Let’s Encrypt証明書でhttps化

WordPress インストール、バックアップと復元