UTM (Mac) から VirtualBox (校舎PC) への移行・環境構築ガイド

現在開発中の UTM (Mac) 環境から、校舎のPC (Ubuntu/VirtualBox) へ成果物を移し、レビュー可能な状態にするための手順です。

1. 移行戦略の基本

VMイメージごとのコピーはしない: UTMとVirtualBoxは形式が異なり、ファイルサイズも巨大なため、VMを丸ごとコピーするのは非効率でトラブルの元です。
「コード (Git)」+「新規構築」: 校舎PCで新たにDebian VMを作成し、そこにGit経由でコードを持っていき、make all で環境を再現する方法が最も確実（本プロジェクト趣旨にも合致）です。

2. 移行手順

Step 1: 現在の環境での準備 (UTM)

まだコミットしていない変更があれば、全てGitHub（またはGitea）にプッシュしておきます。

bash

git add .
git commit -m "Save work before migration"
git push origin main

Step 2: 校舎PCでの VM 作成

VirtualBox を起動し、「新規」から仮想マシンを作成します。
OS: Linux / Debian (64-bit)
メモリ/CPU: 余裕があれば 4096MB / 2CPU 以上推奨（最低 2048MB / 1CPU）。
ディスク: 20GB以上推奨。

⚠️ 重要なネットワーク設定 (NAT + ポートフォワード)

校舎のネットワーク環境では「ブリッジアダプター」がうまく動作しない（IPが貰えない）ことがあります。最も確実な 「NAT」 を選び、「ポートフォワーディング」 を設定します。

VirtualBoxの VM設定 > ネットワーク > アダプター1 (NAT) > 高度 > ポートフォワーディング:

名前	プロトコル	ホストIP	ホストポート	ゲストIP	ゲストポート	用途
SSH	TCP	127.0.0.1	4242	(空欄)	4242	SSH接続 / SOCKSプロキシ用
HTTPS	TCP	127.0.0.1	8443	(空欄)	443	(予備) 直接アクセス用
FTP (Control)	TCP	127.0.0.1	2121	(空欄)	21	FTP制御用 (ボーナス)
FTP (Data)	TCP	127.0.0.1	21100-21110	(空欄)	21100-21110	FTPデータ転送用 (Passive)

解説: ホスト(校舎PC)の localhost:4242 への通信を、ゲスト(VM)の 4242 へ転送します。
※ ホスト側で 443 ポートを使うにはroot権限が必要なため、HTTPSの転送は 8443 などに逃がすか、設定しなくてもOKです（SOCKSプロキシを使うならSSHだけ繋がれば全て見れるため）。

Step 3: Debianのインストール & 環境セットアップ

ISOからDebianをインストールした後、ルート権限で必要なツールを入れます。（詳細は 開発環境セットアップガイド を参照）

🛡️ ファイアウォール設定 (重要)

外部からの接続を受け付けるため、以下のポートを開放する必要があります。詳細は ファイアウォール設定 を参照してください。

443 (HTTPS): ウェブサイトアクセス用
4242 (SSH): SSH接続 / SOCKSプロキシ用
21 (FTP Control): FTP制御用
21100-21110 (FTP Data): FTPパッシブモード用

bash

# VM内のコンソールで実行
sudo apt-get update
sudo apt-get install -y git make vim sudo ufw ...
# Dockerのインストール
...

Step 4: [重要] SSHサーバーの設定

ポートフォワーディングを機能させるため、VM内のSSH設定をリポジトリに合わせて変更します。

bash

sudo vim /etc/ssh/sshd_config
# Port 4242 に変更
# PermitRootLogin no
sudo service ssh restart

Step 5: リポジトリのクローンと起動

課題提出用リポジトリからクローン:

bash

# あなたの課題提出用リポジトリ (vogsphere等) からクローン
git clone https://github.com/your-repo/inception.git
cd inception

ゲストOS内 Git Daemon の準備: ゲストOS内で git daemon を立ち上げ、ホストから直接プッシュできるようにします。設定方法は 開発ガイド: Gitワークフロー (制限環境) > 方法3: Git Daemon を参照してください。
ローカルへのプッシュ設定 (オプション): もしホストOSから手元のエディタで開発し、ゲストに同期したい場合は、ゲストOSをリモートとして追加します。
bash
```
# ホストOS側での操作
git remote add guest git://localhost/inception.git
git push guest main
```

環境起動:

bash

# ゲストOS内で実行
# .envの設定などを確認（必要なら再作成）
make all

3. 接続確認 (校舎PCホスト側から)

まず、SSHでゲストOSにログインできるか確認してください。ポートフォワーディング設定 (Host:4242 -> Guest:4242) が正しければ、以下のコマンドで接続できます。

基本: SSH接続 (シェルアクセス)

bash

ssh -p 4242 debian@localhost
# または
ssh -p 4242 debian@127.0.0.1

パスワードは設定したもの（インストール時に決めた debian ユーザーのパスワード）を入力してください。

ウェブサイトへのアクセス

校舎PCからゲストOSのウェブサイト（WordPress）にアクセスする方法は2つあります。 推奨は「方法A: SOCKSプロキシ」 です。ホスト側の設定変更が不要で、最も確実に繋がります。

方法A: SOCKSプロキシ（推奨 / 設定不要）

SSHの機能を使って、ブラウザの通信をすべてゲストOS経由にする方法です。ホストOSの /etc/hosts を汚さず、管理者権限（sudo）も不要です。

SSH接続 (ダイナミックフォワード):

bash

# -D 8080 でSOCKSプロキシを起動
ssh -D 8080 -p 4242 debian@localhost

ブラウザ設定 (Firefox推奨):
- 設定 > ネットワーク設定 > 手動プロキシ設定
- SOCKSホスト: localhost, ポート: 8080, SOCKS v5
- ☑️ SOCKS v5を使用するときはDNSもプロキシする (重要)
アクセス: ブラウザで https://local.dev（あなたのドメイン）にアクセス。

方法B: 直接アクセス（Chrome / sudoなし）

ポートフォワーディング（Host:443 -> Guest:443）を使って直接アクセスする場合、ドメインの名前解決 (local.dev -> 127.0.0.1) が必要です。しかし、校舎PCでは /etc/hosts を編集する sudo権限がない ことがあります。

その場合の裏技（Chrome起動オプション）を紹介します。

1. ゲストOS側の注意 (絶対)

ゲストOSの /etc/hosts に 127.0.0.1 local.dev を書かないでください。書くと apt-get update 時の名前解決が阻害され、ビルドが失敗します (Exit Code 100)。ゲストOSはデフォルトのままでOKです。

2. ホストOS側でChromeを特殊起動

以下のコマンドでChromeを起動すると、ホストの /etc/hosts を無視して特定ドメインをローカルに強制解決できます。ここではホスト側のポート 8443 をターゲットにしているため、マッピングもポート指定を含める点に注意してください。

bash

# Ubuntu (校舎PC) の場合
google-chrome --host-resolver-rules="MAP local.dev 127.0.0.1:8443"

# Chromiumの場合
chromium --host-resolver-rules="MAP local.dev 127.0.0.1:8443"

これでアドレスバーに https://local.dev と入力すれば繋がります。 Warning画面（自己署名証明書のため）が出たら「詳細設定 -> Webサイトへ移動」で進んでください。

方法C: Host-Onlyアダプター (推奨・ネットワーク的アプローチ)

もし enp0s8 (Host-Only Adapter) が正しく設定され、ホストと通信できているなら、SSHトンネルもポートフォワードも不要です。

ゲストIPの確認: ゲストOS内で ip addr show enp0s8 を実行し、IPを確認します（例: 192.168.56.101）。
ホストOSの /etc/hosts 編集: 校舎PC（ホスト）のターミナルで以下を実行し、ドメインとIPを紐付けます。
bash
```
echo "192.168.56.101 local.dev" | sudo tee -a /etc/hosts
```
(注意: テストが終わったら消すことを推奨します)
アクセス: ブラウザで通常通り https://local.dev にアクセスします。
- ポートフォワード不要: 直接 192.168.56.101:443 に繋ぎに行きます。
- SSH不要: ネットワークレベルで疎通しているため不要です。

💡 コラム: 127.0.0.1 と 127.0.1.1 の違い

Linux (特にDebian/Ubuntu) では、/etc/hosts に以下の2行がよく書かれています。

127.0.0.1: ループバックアドレスの標準。「自分自身 (localhost)」 を指します。ポートフォワーディングや一般的な通信では常にこれを使います。
127.0.1.1: Debian系独自の慣習で、「システムのホスト名を持つ自分」 を指すために使われます（固定IPを持たないPCが起動時にホスト名解決で詰まるのを防ぐため）。

Chromeのオプションやポートフォワーディングで 127.0.0.1 を指定するのは、標準的な「localhostへの接続」を意味するからです。127.0.1.1 は内部解決用なので、ユーザーが接続先として指定することは基本ありません。

4. データ移行の詳細手順（オプション）

開発ですでに大量の記事や設定を行っており、「どうしてもデータも持っていきたい」場合の具体的な手順です。主に 「ボリュームディレクトリ (~/data) を丸ごと持っていく」 方法が最も簡単で確実です。

準備: ホストOS等のネットワーク到達性

Mac(UTM)と校舎PC(VirtualBox)は直接通信できないため、外部ストレージ（USBメモリ、クラウドストレージ） または Gitリポジトリ（一時的） を経由する方法を案内します。

手法A: ボリュームディレクトリのアーカイブ（推奨）

この方法は、WordPressの画像ファイルもデータベースの中身もすべて維持できます。

1. 移行元 (UTM/Mac) での作業

コンテナを停止し、データディレクトリを圧縮します。

bash

# 1. コンテナ停止（データの整合性のため必須）
cd ~/Docker Infrastructure
make down

# 2. データディレクトリへ移動（デフォルトの場合）
cd /home/debian/data

# 3. 圧縮 (sudoが必要な場合があります)
# mariadbとwordpressのデータをまとめて data_backup.tar.gz にする
sudo tar -czvf ~/data_backup.tar.gz mariadb wordpress

# 4. 作成された tar.gz をホスト(Mac)に取り出す
# （scpや、Macの共有フォルダ機能などを使って取り出してください）

2. ファイル転送

作成した data_backup.tar.gz を、USBメモリやGoogle Drive経由で校舎PCに運び、さらにそこから VirtualBox VM 内に転送します。 (VirtualBoxの「共有フォルダ」機能や、SSH経由の scp が便利です)

3. 移行先 (VirtualBox/校舎PC) での作業

bash

# 1. ファイルをホームディレクトリに配置した状態からスタート
# 展開先ディレクトリを作成
mkdir -p ~/data

# 2. 展開（sudoが必要）
# ~/data の中に mariadb と wordpress フォルダが展開されるようにする
sudo tar -xzvf data_backup.tar.gz -C ~/data

# 3. パーミッション確認（念のため）
# Docker Infrastructureの仕様上、Dockerが起動時に調整してくれることが多いですが、
# どうしてもうまくいかない場合は所有権を確認
ls -la ~/data

4. 起動

bash

cd ~/Docker Infrastructure
make all

これで、以前の環境と全く同じ状態でサイトが立ち上がります。

手法B: WordPress機能を使ったコンテンツ移行（記事のみ）

「ごちゃごちゃした設定はリセットしたいが、書いた記事だけは救いたい」場合の手法です。

移行本 (UTM): WordPress管理画面 -> ツール -> エクスポート -> 「すべてのコンテンツ」 -> ダウンロード（XMLファイル）。
移行先 (VirtualBox): make all で新品の環境を立ち上げた後、管理画面 -> ツール -> インポート -> WordPress (インストーラ実行) -> XMLファイルをアップロード。
- 注意: 画像ファイルなどは別途移行が必要な場合があります。
- 注意: プラグインやテーマ設定は引き継がれません。手動設定が必要です。

手法C: WordPressプラグインを利用する（最も「ユーザー」的）

インフラ操作ではなく、WordPressのGUI機能だけで完結させたい場合、「All-in-One WP Migration」などのプラグインを使うのが一般的です。

移行元:
- プラグイン「All-in-One WP Migration」をインストールして有効化。
- 「エクスポート」→「ファイル」を選択し、.wpress ファイルをダウンロード。
移行先:
- 同プラグインをインストール。
- 「インポート」から先ほどのファイルをアップロード。
- 注意: デフォルトのアップロードサイズ制限（PHP設定 upload_max_filesize）に引っかかる可能性があります。その場合は .htaccess か php.ini の調整が必要ですが、Docker Infrastructure環境ではコンテナ再構築が必要になるため少し手間です。

手法D: データベース機能 (`mysqldump`) を使う（DBのみ移行）

「画像は消えてもいいから、記事テキストとユーザーデータ（DB）だけを技術的に正しく移植したい」場合の手順です。

1. エクスポート (UTM側)

稼働中のMariaDBコンテナからSQLデータを抽出します。

bash

# データベース 'wordpress' の中身を dump.sql に書き出す
docker exec mariadb mysqldump -u root -prootpassword wordpress > dump.sql

2. インポート (VirtualBox側)

dump.sql を転送した後、新しい環境のデータベースに流し込みます。

bash

# ファイルをコンテナ内にコピー（あるいは cat で流し込む）
cat dump.sql | docker exec -i mariadb mariadb -u root -prootpassword wordpress

メリット: SQLレベルでのバックアップなので、特定のテーブルだけ除外したりといった細かい制御が可能です。
デメリット: wp-content/uploads （画像ファイル）はDBに含まれないため、画像はリンク切れになります（別途コピーが必要）。

5. まとめ: どの方法を選ぶべきか？

手法	難易度	完全性	推奨シーン
A. ボリューム丸ごと (tar)	低〜中	◎ 完全	Docker Infrastructure移行（推奨）。最もトラブルが少ない。
B. WP標準エクスポート	低	△ 記事のみ	設定をリセットして記事だけ救いたい時。
C. WPプラグイン	低	◯ ほぼ完全	商用サーバーへの引っ越しなど（サイズ制限に注意）。
D. mysqldump	高 (CUI)	△ DBのみ	DB管理の練習や、特定データの抽出。

6. トラブルシューティング

Q. 校舎PCからSSH接続できない / enp0s8 が DOWN になっている

ゲストOSで ip address を実行し、enp0s8 が state DOWN になっている場合、インターフェースが有効化されていません。以下の手順で有効化してください。

一時的な有効化 (再起動で戻ります):
bash
```
sudo ip link set enp0s8 up
sudo dhclient enp0s8
```
これでIPアドレスが割り当てられれば成功です。
永続的な有効化: /etc/network/interfaces を編集して、起動時に自動的に有効になるようにします。
bash
```
sudo vim /etc/network/interfaces
```
以下の行を末尾に追加します（既存の記述を消さないように注意）:
```
# Host-Only Adapter
allow-hotplug enp0s8
iface enp0s8 inet dhcp
```
保存後、再起動するか sudo systemctl restart networking を実行してください。

Q. WordPressコンテナが再起動を繰り返す (Restarting...)

srcs/requirements/wordpress/tools/setup.sh が失敗して終了している可能性が高いです。以下の原因を確認してください。

データベースの接続待機時間不足: 校舎PC（VirtualBox）のディスクアクセスが遅く、MariaDBの立ち上がりに時間がかかっている可能性があります。 srcs/requirements/wordpress/tools/setup.sh の sleep 10 を sleep 30 程度に伸ばしてみてください。
アーキテクチャ不一致 (ARM vs AMD): もしMac(UTM/ARM)から ~/data/mariadb ディレクトリをそのままコピーしてきた場合、データベースバイナリの互換性がなく、MariaDBが正しく動作していない可能性があります（コンテナは起動していても接続を拒否するなど）。一度データを削除して初期化してみてください：
bash
```
make fclean
sudo rm -rf ~/data/mariadb ~/data/wordpress  # 要注意: データが消えます
make all
```
※ データ移行が必要な場合は、ディレクトリコピーではなく mysqldump (手法D) を推奨します。

全体概要 (Overview)

FTP Server

Gitワークフロー (制限環境)

UTM (Mac) から VirtualBox (校舎PC) への移行・環境構築ガイド

1. 移行戦略の基本

2. 移行手順

Step 1: 現在の環境での準備 (UTM)

Step 2: 校舎PCでの VM 作成

⚠️ 重要なネットワーク設定 (NAT + ポートフォワード)

Step 3: Debianのインストール & 環境セットアップ

🛡️ ファイアウォール設定 (重要)

Step 4: [重要] SSHサーバーの設定

Step 5: リポジトリのクローンと起動

3. 接続確認 (校舎PCホスト側から)

基本: SSH接続 (シェルアクセス)

ウェブサイトへのアクセス

方法A: SOCKSプロキシ（推奨 / 設定不要）

方法B: 直接アクセス（Chrome / sudoなし）

1. ゲストOS側の注意 (絶対)

2. ホストOS側でChromeを特殊起動

方法C: Host-Onlyアダプター (推奨・ネットワーク的アプローチ)

💡 コラム: 127.0.0.1 と 127.0.1.1 の違い

4. データ移行の詳細手順（オプション）

準備: ホストOS等のネットワーク到達性

手法A: ボリュームディレクトリのアーカイブ（推奨）

1. 移行元 (UTM/Mac) での作業

2. ファイル転送

3. 移行先 (VirtualBox/校舎PC) での作業

4. 起動

手法B: WordPress機能を使ったコンテンツ移行（記事のみ）

手法C: WordPressプラグインを利用する（最も「ユーザー」的）

手法D: データベース機能 (`mysqldump`) を使う（DBのみ移行）

1. エクスポート (UTM側)

2. インポート (VirtualBox側)

5. まとめ: どの方法を選ぶべきか？

6. トラブルシューティング

Q. 校舎PCからSSH接続できない / enp0s8 が DOWN になっている

Q. WordPressコンテナが再起動を繰り返す (Restarting...)

FTP Server

UTM (Mac) から VirtualBox (校舎PC) への移行・環境構築ガイド ​

1. 移行戦略の基本 ​

2. 移行手順 ​

Step 1: 現在の環境での準備 (UTM) ​

Step 2: 校舎PCでの VM 作成 ​

⚠️ 重要なネットワーク設定 (NAT + ポートフォワード) ​

Step 3: Debianのインストール & 環境セットアップ ​

🛡️ ファイアウォール設定 (重要) ​

Step 4: [重要] SSHサーバーの設定 ​

Step 5: リポジトリのクローンと起動 ​

3. 接続確認 (校舎PCホスト側から) ​

基本: SSH接続 (シェルアクセス) ​

ウェブサイトへのアクセス ​

方法A: SOCKSプロキシ（推奨 / 設定不要） ​

方法B: 直接アクセス（Chrome / sudoなし） ​

1. ゲストOS側の注意 (絶対) ​

2. ホストOS側でChromeを特殊起動 ​

方法C: Host-Onlyアダプター (推奨・ネットワーク的アプローチ) ​

💡 コラム: 127.0.0.1 と 127.0.1.1 の違い ​

4. データ移行の詳細手順（オプション） ​

準備: ホストOS等のネットワーク到達性 ​

手法A: ボリュームディレクトリのアーカイブ（推奨） ​

1. 移行元 (UTM/Mac) での作業 ​

2. ファイル転送 ​

3. 移行先 (VirtualBox/校舎PC) での作業 ​

4. 起動 ​

手法B: WordPress機能を使ったコンテンツ移行（記事のみ） ​

手法C: WordPressプラグインを利用する（最も「ユーザー」的） ​

手法D: データベース機能 (mysqldump) を使う（DBのみ移行） ​

1. エクスポート (UTM側) ​

2. インポート (VirtualBox側) ​

5. まとめ: どの方法を選ぶべきか？ ​

6. トラブルシューティング ​

Q. 校舎PCからSSH接続できない / enp0s8 が DOWN になっている ​

Q. WordPressコンテナが再起動を繰り返す (Restarting...) ​

UTM (Mac) から VirtualBox (校舎PC) への移行・環境構築ガイド

1. 移行戦略の基本

2. 移行手順

Step 1: 現在の環境での準備 (UTM)

Step 2: 校舎PCでの VM 作成

⚠️ 重要なネットワーク設定 (NAT + ポートフォワード)

Step 3: Debianのインストール & 環境セットアップ

🛡️ ファイアウォール設定 (重要)

Step 4: [重要] SSHサーバーの設定

Step 5: リポジトリのクローンと起動

3. 接続確認 (校舎PCホスト側から)

基本: SSH接続 (シェルアクセス)

ウェブサイトへのアクセス

方法A: SOCKSプロキシ（推奨 / 設定不要）

方法B: 直接アクセス（Chrome / sudoなし）

1. ゲストOS側の注意 (絶対)

2. ホストOS側でChromeを特殊起動

方法C: Host-Onlyアダプター (推奨・ネットワーク的アプローチ)

💡 コラム: 127.0.0.1 と 127.0.1.1 の違い

4. データ移行の詳細手順（オプション）

準備: ホストOS等のネットワーク到達性

手法A: ボリュームディレクトリのアーカイブ（推奨）

1. 移行元 (UTM/Mac) での作業

2. ファイル転送

3. 移行先 (VirtualBox/校舎PC) での作業

4. 起動

手法B: WordPress機能を使ったコンテンツ移行（記事のみ）

手法C: WordPressプラグインを利用する（最も「ユーザー」的）

手法D: データベース機能 (`mysqldump`) を使う（DBのみ移行）

1. エクスポート (UTM側)

2. インポート (VirtualBox側)

5. まとめ: どの方法を選ぶべきか？

6. トラブルシューティング

Q. 校舎PCからSSH接続できない / enp0s8 が DOWN になっている

Q. WordPressコンテナが再起動を繰り返す (Restarting...)