Post Views: 18
はじめに WordPressは,PHP + MySQL (mariaDB)ベースの動的なCMSです.DSMに内蔵されたWeb Station (ApacheまたはNginx) + PHPがそれぞれ処理します.
*CMS : content management system
今回,一つのNASの上に2つ(以上)のサイトを構築する手順を解説します.
以前にAI君にその方法を問うてみると「できる」と断言されました.その詳細な方法について色々と聞いてみると「それらしい答え」を出してきました.
これまでは,ネット検索では思いついた時に,その都度調査していましたが,求めているサイト/方法/手順は見つけられませんでした.あきられて新しいIP Addressを取得(費用が必要)することも真剣に考えていところです.
しかし,1カ月前,AI君は「できる」と断言しました.その後,1カ月くらい放置して自分の頭の中で熟成させていたこの案件ですが,この土日,及び+3日を使い,更にその詳細についてAI君と共に検討した結果,1台のSynology NASの上に2つのサイトを構築し安定稼働させることができました.2つ目以降のサイトの内容はこれから作っていこうと思ています.
作業概要は,
(1) DSM->File Stationで既存wordpressフォルダー複製
(2)phpMyAdminによる既存のData Baseの移行と修正
(3) Web Stationによるportal(仮想ドメイン?)の設定,
(4) DMSでのText Editorによるwp-config.php, .htaccessの修正,
等です.
当初の検討では,Conatainer Managerを使用したwordpressのコンテナ化によるマルチドメインを検討しましたが,結局は,Web StationのVirtual Host(仮想ホスト)を使用することで一つのNASの上に複数のサイト構築が可能でした.
以下に詳細を解説します.なお,Synology NASの解説は,日本語版では冗長なのでそれを避けて用語などは英語版の表記としています.
目次 構築方法 作業する前にバックアップを取ってから進めてるのが良いです.
作業前のバックアップ hyper backupで現時点での/web以下(既存のwordpressファイルが格納されているfoler)をバックアップします.その他,以下の設定で実行しておきます.
設定Folder : web Application : MariaDB 10 Web Station Backj up nowボタンを押す 参考 : [Synology] NAS (DS918+/DS920+)の バックアップを考える …
DDNSの取得 以下の方法により構築する2つ目のDomain Nameを用意する.
Synology NASの場合,2台以上のNASを持っているのであれば,External Access->DDNSからSynologyからDomain NameをNASの1台に付き1つの名前を頂ける. myDNS.jp様のサイトから複数個のDomain Nameを頂ける. Let’s Encription証明書 証明書については,Synology NASを複数持っているので,それぞれについてSynologyからDomain Nameを取得している.
表1. Let’s Encrypt の代表的なレート制限
制限の種類 内容 同一FQDNでの再発行(同一証明書内容) 1週間に5回まで 同一登録ドメイン(例:example.com)に対する新規証明書発行 1週間に50回まで 失敗した認証試行数 1時間に5回まで アカウントごとの登録レート 制限あり(通常の使用で問題なし)
Web Stationでの設定 設定の前準備(Control Panelでの作業で示している)として以下のAccess Control Profileを作成しておく.
Longin-> Porral->Advanedを開き以下の設定をつ以下する.
表2. Access Control Profile
web stationでは,以下の項目を設定することができる.web stationでの設定手順は,(3) Script language Settings →(2) Web Service →(1) Web Portalの順となる.
Web Portal Web Service Script Language Settings Error Page Settings 図1. Web Stationの設定画面 (Script Language Settingsを選択している状況)
Script Language Settingsでprofileを作成: 作業
Creatボタンを押す Create Profile – Configre general settings画面が現れる 以下項目に入力する(後で修正は可能)Profile name : <profile for 2nd site> Description : <同上など,適当に> PHP version : <インストールしているphpのバージョンがリストされるので,一つを選ぶ,ex: php8.2>Enabe PHP cache : チェックする Enable Xdebug : チェックする Enable display_erros to display PHP error message :チェックする (以上のチェックは,作成後に変更可能) Customized PHP open_basedir : Default Nextボタンをクリック Configure extensions画面が現れる全てを選択(理解できていないので全て選択,重複エラーでは重複項目のチェックを外す) Nextボタンを押す Configure FPM settings画面が現れる(FastCGI Process Manager)FPM mode : direcrt (PHP-FPMを使用せず,web serverがPHPを直接処理する) Max processes: 102 (default) Start servers : 2 (default) Min spare servers : 2 (default) Max spare servers : 4 (default) Nextボタンを押す Configure core settings画面が現れるmysqli.default_socket : /run/mysqld/mysqld10.sock (に修正, wp-config.phpの記載に合わせる) pdo_mysql.default_socket : /runmysqld/mysqld10.sock (に修正, wp-config.phpの記載に合わせる) 残りは規定値のまま Nextボタンを押す Confirm settings画面が現れる 以上 Web Service の作成: Web Serviceでは,以下の項目が表示される.
Default Service Native script language website Third-party Package website 図2. Web Stationの設定画面 (Web Seviceを選択している状況)
今回の作業では,Native script language websiteを作成する.
Web Serviceは,site Aとsite Bで共用は可能だが,今回は,専用にそれぞれ作成した.
作業:
Createボタンを押す Select a service type画面が現れるstatic websiteとContainerized script language websiteは選択しない. Native script language websiteをチェック(選択)する Service : リスト他されphpの中から「script language settings」にて作成した時に設定したphp version である「php 8.2」を選択する 右隣のプルダウンメニューには,「script language settings」で作成したprofileがリストされてるのでそれを選択する. Nextボタンを押す Configure geral setting画面が現れるName : <site B用であることが分かるような名前にする> Descriptiion : <適当に> Document root : /web/<site B> HTTP back-end server : Apache HTTP Sever 2.4 残りの項目は規定値(default) Nextボタンを押す Confirm settings画面が現れるCreateボタンを押す Virtual hostを作るには,http groupのread permissionが必要であり自動で作成するとのメッセージが出るので,「OK」ボタンを押す Native script laguage website項目に,Service typeはPHP,Nameには作成した名前でリストされる. 完了 以上 Web Portalの作成 : web Portalでは,以下の項目が表示される.
Customized Portal Default Portal 図3. Web Portal 画面
今回の作業では,Customized Portalを以下の手順で作成する.
図4. Web Profile設定
作業:
Createボタンを押す Select a portal type画面が現れる Web service portalをマウスクリックする. Set up a web service portal画面が現れるService : <作成したweb serviceがリストされるので,それを選択する> Status : Normal (選択したweb serviceが正常な場合にNormalと表示されている) Portal type : <Name-based Hostname : <domain name>, ex:????.myDNS.jp Port : 80/443 (でもOKだと思う), 今回はHTTPS: 443とした HTTPS settigs : HSTSをチェック Access control profile : <Access Control Profileの作成で作成したプロファイル名をリストから選択する. 指定しない場合はネットからフルアクセスされる Error page profile : Default error page profile (defaultのまま) Enambe access log : 今回はチェックなし Applyボタンを押す Customized portal項目に作ったPortalがリストされる 完了 以上 複数サーバー安定化 Web Protalで複数のweb serverを安定的に稼働させるために,default serverの設定をいじる必要がある.なぜなら,Multi Domain Web Serverを構築する前の状態はSingle Web Server (既存)が稼働するのみであり,それはdefault serverが担っていたため.
今回の作業では,既存のweb serverを新しくportal server (以降で説明)として設定 (既存のurl:harikirii.diskstation.me)したため,既存のurlであったdefault server (url: 同じ)が起動すると,この同じurlには,異なるservice (script languageを含む)が設定されることになり,コンフリクトを生じる可能性があると考えられた.
そこで,以下の手順により,default serverに対して適切な設定が可能になるようservice設定をいじった.この設定を完了させてから,複数(現在3つ)あるportal(web server)がレスポンスを失う自体にはなっていない(2025/06/20).
先ず,Web Portal 設定の画面では,default serverをdisable/enableは,できな仕様となっている(図5). そこで,Service設定画面から設定を以下の手順でいじる(図6). 図6に示すように,user portalが使用しているHTTP back-end serverはapacheである.念のため,default serverにはそれとは異なる「Nginx」を選択する. Serverが起動しないようにすめにたに(結果的そうだった*),PHPには「Not configured」を選択する.おそらくこの設定が重要. * NASをrebootさせてlogを確認してみると,この設定前ではharikiri.diskstation.meの起動が2回記録されていた.設定してからは,1回の起動のみが記録されるようになった. Save 以上 図5. Default serverのdisable/enableはできない(仕様)
図6. Service設定画面
更に必要な作業 今回の作業では,既存のwebサイト(harikiri.diskstation.me)は,Default serverで管理されていた(そのはずな)ので,専用のportalはリストされていなかった.
そご,harikiri.diskstation.me用に上記の作業でWeb Portalを作成した.その際,/web/<site A用のfolfer>のフォルダ構造と,harikiri.diskstation.me/<site A>というurl構造が不整合となりブラウザでの表示が出来なくなった(エラー500, 404).
修正作業は,以降に述べているように「wp-config.php」の修正,DBの複製と修正,及び「.htaccess」の修正が必要.
File Stationから,既存のwordpressディレクトリを複製して2つめwordpressディレクトリとし,wp-config.php,.htaccess,必要があればrobots.txtを修正する. 以下詳細を示す.
File Stationでの作業 (1) DSM->File Stationで既存のwordpressフォルダーの複製
/web/<site A>にwordpressがインストールされている前提とする(既存). /web/<site B>をcreate folderで作成する. <site A> foldeにあるfolder/fileの全てを<site B>に複製する. 注意) 既存を消したりしないように! (2) .htaccessの修正
以下のコードでにおいて “/” が,”/<site A/Bのfolder name>”になっているとブラウザ表示できないので,以下のコードに置き換える.
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
(3) wp-config.phpの修正
MariaDB10のデータベース(DB)は,2つ目のuser2で別DBを作成し,exportしたuser1のDBをuser2のDBにimportされていることを前提にしている.
define( 'DB_NAME', 'DB2' );
define( 'DB_USER', 'user2' );
define( 'DB_PASSWORD', '********' );
define( 'DB_HOST', 'localhost:/run/mysqld/mysqld10.sock' ); // MariaDBパッケージならlocalhostでOK(未確認)
define('DB_CHARSET', 'utf8mb4');
define('DB_COLLATE', '');
/volume1/web/<site A filder name>/wp-config.php
に以下の2行を require_once
より前 (強制)に追加: これらの環境変数は,DBのwp_optionsのsiteurlとhomeより優先する(by 4o).DBで設定しているなら必要ない.
define( 'WP_HOME', 'https://harikiri.diskstation.me' ); define( 'WP_SITEURL', 'https://harikiri.diskstation.me' );
(4) robots.txtの修正
robots.txt (小文字)についてもサイトに合わせて修正してください.
Control Panelでの作業 Login Portal -> Advanced -> Access Control Profileでprofile作成画面を開き当該profilelを作成する.
access control profileは,web stationの設定で使用する.Web Stationの設定が完了後,後から当該profileを作成・設定も可能.
機能:
サイトの内容を編集している間やその他のIP Addressを拒否/許可することが可能.ネットからのアクセスを拒否する設定のprofileを作り,web station->web portal->”で,作成したportalのAccess control profile”に指定するとprofileに従ってアクセス制限される. サイトの投稿が整いサイトを公開したい場合,公開用のprofileを前述と同様のところに指定するか,何も指定しなければフルアクセスとなる. access control profileを作る Login Portal->Advancedを開き,Access Control Profileを開く Createボタンを押し,2つ目のサイト用にprofileを作成する MariaDB 10 WordPressはMariaDB 10のデータベース(DB)にページを保存しており,2つ目のサイト構築にも専用のDBが必要である.
今回は,既存のuser1が持っているデータベース(DB1)をphpMyAdminからexportしてDB1をダウンロード,新しいuser2で作成したDB2にimport して,これをSite-2用のデータベースとして修正し稼働できることを確認する.同時にphpMyAdminの使い方の習得を並行して行った.
以下のphpMyAdminで行う操作は,慎重に行ってください.
特に置換を実施する際,先に検索でヒットするテーブルやレコードを確認しておき,その後に,置換の作業をするようにすれば理解しながら進められます.
既存DB1のexport phpMyAdminにuser1(root権限)でログイン site-2用のDB1をexport ログアウト 新しいuserとDBの作成 phpMyAdminに既存のuser1(root権限)でログイン 新しくuser2を作成 新しくDB2 (文字コードはutf8mb4_unicode_ci)を作成 user2にDBのアクセス権限を与えるGRANT ALL PRIVILEGES ON DB2.* TO user2’@’localhost’; FLUSH PRIVILEGES; DB2を選択 メニューのimportを選択 先にexportしたDB1を選択 実行(DB2にDB1(の内容:全ての表)をimportする) siteurlとhomeのurlの修正 site 2用のDB2をクリック wp_optionsテーブルをクリック option_nameカラムにsiteurlか,homeがあるレコードを探す.両方ともに以下の処理をする option_valueにあるurlを確認する もしもwordpressがインストールされているfolder名が含まれていれば,そのfolder名 を削除する(web stationで明示しているのでここには必要ない) 項目 説明 siteurl
WordPress本体(wp-login.php
, wp-admin
, プラグインなど)が存在するインストール先URL home
サイト訪問者に表示されるホームURL(TOPページ)
<wp_posts表の修正> web station -> web service -> document rootにwordpressがあるfolderを明示的に指定しているので,DB上では必要ない.wp_postsには投稿のguidカラムがあり,”https://harikiri.diskstation.me/myblog/?p=1″のように一意にidが設定されている.このままでもサイトは稼働するが,site 2の投稿なので,投稿数は多いため置換機能で正しい値に一括置き換えする.
site 2で使用しているDB2をクリック DBの横にある「+」をクリック 全てのテーブルが表示される テーブルwp_postsをクリックしてレコードを表示させる 「検索」をクリック 表示された「検索と置換」ボタンをクリック 検索条件に,”/site 1のurl/<folder名>”を入力する 置換文字列に,”site 2のurl”を入力する (注: folder名は必要ない) カラムに,”guid”を選ぶ 実行 置換する投稿のリストが表示される 問題なければ,”置換”ボタンを押す 以上 その他の表 その他の表にもwordpressに導入しているpluginなどによっては,前述の処理が必要な場合があると考えられる.
必要に応じて確認して修正する.
まとめ 前提1: 既存のWordPressはSynology PackageではなくWordPressからダウンロードして導入している. 前提2: MariaDB 10はSynology Packageから導入している. 前提3: phpMyAdminはSynology Packageから導入している. DBは既存からexportし異なるuser権限(user2)でDB2を作りimportした. ディレクトリ分離: /web以下のフォルダ構造は,/web/<site 1用のフォルダ>に既存のwordpressファイルが格納されており,そのファイル群を今回新しく複製 (copy)して/web/<site 2用のフォルダ>に2つめのwordpress 用とした.それぞれは,独自にブラウザで表示と管理ができるMulti Domainにすることができた. harikir.diskstation.me(当サイト)用にportalを作りenable (又は作成直後)にすると,ブラウザは,コード500のエラー(internal sever error)や404エラー(ファイルがない)を吐いたが,wp-config.phpや.htaccessの修正で解決できた. wp-config.phpの修正データベースに関する環境変数の修正 /web/<site ?用のフォルダ>と,urlでは<site A/B用のwordpressフォルダ名を使用しないので齟齬がある.この修正が必要だった. RT6600ax Routerでの設定でポート転送していても,web stationの設定により問題なく2つのサイト(一つのNAS上の2つのwordpress)に振り分けられる.ホスト名(ドメイン名)は,やり取りされるHTTPリクエストのヘッダーに含まれるためドメイン名で振り分けされている(ようだ). 検討の過程で,reverse proxyによるport設定も試したが,web stationでの設定しているため,二重の設定となるためreverse proxyの設定は必要でない. 既存のsite 1のみで稼働させていた時は,default serverが使用されていた(と考えられる).今回の検討では,明示的に管理したかったので,2つのサイトにそれぞれCustomized Portal (仮想host / server)を構築した. AI君が言うには,default severは,定義された任意のドメインに一致しないリクエストが来た場合に応答する「最後の受け皿」となる仮想hostとのこと. web stationにあるこのdefault serverは削除することはできない. 今回構築したこの「複数サイト構成」の呼び方:(by 4o) 呼び方 対応 解説 マルチドメイン(Multi-Domain) ✅ 適切 異なるドメイン名(FQDN)で異なるWebサイトを運用する構成。 今回のように harikiri.diskstation.me
と もう一つのurl
がそれぞれ独立して動作していれば、これは正しくマルチドメイン構成です。 マルチサイト(WordPress Multisite) ❌ 非該当 WordPressの1インスタンス内で複数のサイト(サブディレクトリやサブドメイン)を運用する機能。 今回はWordPressインスタンスを2つ別々に構築しているため、マルチサイトではありません。 シングルサイト ×2(独立サイト) ✅ 技術的にはこちらも正しい 単に2つのWordPressがNAS上に別個に存在している構成なので、2つの独立したWordPressサイトと呼んでも間違いではありません。
ただし、「WordPressのマルチサイト構成」ではない ことには注意が必要です。マルチサイトはひとつのWordPressの中で複数のサイトを管理する仕組みで、今回のように個別にWordPressをインストールし、それぞれのドメインで運用している 場合は、それぞれが独立した「シングルサイト」です。
FAQ: DBの修正を終えてWebブラウザで表示させたとき,表示はするが表示までの時間が長い場合,以下をチェックする.DBの修正をミスしている.具体的には,site Aとsite Bのurlや/web/<folder A>と/web/<folder B>の置換のミス.以下のように設定を確認する. テーブルのwp_optionsにあるsiteurl とhome を含むレコードが,サイトのurlであることを確認する. テーブルのwp_postsのカラムのカラムのguidは,url+”?p=<数字>” (ex: harikir.diskstation.me/<wordpressがあるfoler名>/?p=1)となっているか.正しく置換できているか確認する. どうしても正常にできない場合は,再度,DBをimportし直すところから始める.具体的には,当該DBを削除し,改めて当該DB名でDBを作成.その後,本編でも解説しているように,既存のDBのエクスポートファイルをimportして,修正作業をやり直す. 管理者でログインしてもログイン画面にならない場合の対処例基本的な作業は,再度,DBをimportし直すところから始める. DBのwp-optionsのsiteurlとhomeを修正する. ブラウザから当該サイトを表示させてみる.フロントページの表示ができら以下に進む. wp_postsのguidには,オリジナル(site 1)のurlが記載されているので,当該サイト(site 2)のurlに置換する. ブラウザで表示していみる. 以上,ステップバイステップで確認していく. 環境変数(この記事中で説明しているwp-config.phpなど)をミスした場合,web server (portal)のレスポンスが失われることがある.その場合,MariaDB10の再起動,web stationのportalの再起動をしてやれば,レスポンスは回復する.NASのrebootは必要ない(はず).MariaDB10のreboot : package centerからMariaDB10をクリック(openボタンではない)し,現れる「Open」ボタンの右横の矢印でStopを選択する.停止できたら,同じ要領でRunを選択する. Portalのreboot: Web StationのWeb Portalをクリック.表示されるportalをクリックして選択.Actionボタンのリストからdisableをクリック.disableできたら,同じ要領でenableボタンをクリックする. HTTPエラーコード一覧(代表例) ステータスコード 名前 意味・原因の概要 要確認 404 Not Found 要求されたページが存在しない 。 → URLの間違い、削除済み、リンク切れなど。 portalがdisableに..htaccessが無い. 403 Forbidden アクセスが禁止されている 。 → パーミッションエラー、アクセス制限、IP制限など。 Access control profileなどで外部からのアクセス制限など. 500 Internal Server Error サーバー内部で予期せぬエラー が発生。 → プログラムのバグ、設定ミス、.htaccessの誤りなど。 別のserverの.htaccessを使用している..htaccess内のpath指定が不整合
あとがき これから既存サイトの運用の様子を見ながら,2つ目のサイトの構築を進めていく.
といったもの,以下に示すようなイベント(問題)があったが,改善ができたので.2025/06/18にこの投稿を再公開した.
そのご更に対策を打ち安定性を高めた.
2025/06/20, 3台のweb server (multi domain)の安定稼働には,default serverのservice設定を適切にすることでレスポンスを失う事態にはまだいたっていない.このまま稼働を継続する.
2025/06/18, 結局,アクセスできなくなる現象(404)が生じた後に,MariaDB10をrebootすることで解消できることが分かった.その後,2~3時間すると,また,両サイトともに404エラーとなり,その後復旧しないというトラブルは引き続き変わらない.AI君と相談し原因・対策を検討した結果,2つ目のサイト用に別のuser2でのDB2を作成することで,当該トラブルは解消されている(12時間ほど2サイト構成で稼働).
2025/06/17, 昨日に続き,サイドInternetからいずれのHome Pageにもアクセスできなくなる現象が起きた.更に,Google Analiticsの新規ユーザー数が低下したことからアクセスされていないようだった. 対策として,Web Stationから,新たに構築した2つ目のPortal(virtual host)をDesableし,且つ,Routerはrebootせずに,Networkプロバイダーとの接続をやり直すことで,オリジナル(harikir)は復旧してブラウザで表示されるようになった.Multi Domainの設定に不具合が残っていると考えられる.夜中はアクセスが少なくなるので,夜中から早朝で追加のテストを実施し様子を見ることにする.
2025/06/16, 1つ目(オリジナル)および2つ目もinternet(外部)からアクセスできなくなる現状が起きた.この日の対策は,Routerのrebootで解決したので,Routerが原因ではないかと考えてた.
編集履歴 2025/06/15, Mrはりきり 2025/06/16, 追記(ブラウザ表示レスポンスが遅い場合の原因と対処) 2025/06/17, 追記(ログインできるが管理者画面にならない時のWebStationの設定対処法,Let’s Encription関係, internetからアクセスできない現象が多発したがportalのdisableで測復旧することから,正しくない設定が残っていると考えられる) 2025/06/18, internetからアクセスできない(404)問題は,MariaDB10に原因があることが分かり,別user2で別DB2を作ることで404を解決できた.Let’s Encriptionは,settingsでサイト用に証明書を設定することでセキュリティ問題を解決した. 2025/06/19, 3つのサイトに増やして稼働テスト中,何度となくMariaDBをrebootして復旧.なにかミスしている. 2025/06/20, default serverのsirviceの設定を修正することで3つのportalを安定稼働できるようになった.