Scrapdiary

DesigningとEngineeringの架け橋

さくらのレンタルサーバーでマルチドメイン利用時のDOCUMENT_ROOT

連日さくらネタ。

www.sakura.ne.jp

さくらのレンタルサーバでは「マルチドメイン」といういわゆるバーチャルホスト機能が手軽に使えます。ただコントロールパネルでの設定と実際の稼働環境での認識に差異がありハマったので備忘録です。

コントロールパネルでの設定値

その際コントロールパネルの設定にて当該ドメインに対応するディレクトリを指定します。指定したディレクトリ以下にファイルを配置すると、そこを起点に当該ドメインでアクセスした場合にコンテンツとして展開されます。

 

  • ドメイン設定: site1.hostname.tld
  • パス設定:   /home/user_name/www/site1

 

上記の場合、DNSを設定した後にsite1.hostname.tldへアクセスすると、/home/user_name/www/site1 以下に設置したファイルがドキュメントルートとみなされて表示されます。

 

  • サーバ上パス: /home/user_name/www/site1/index.html
  • アクセスURI: site1.hostname.tld/index.html

 

サーバ上のファイル、この場合マルチドメインで設定したディレクトリの直下に配置したファイルは、マルチドメインで設定したドメインのホスト直下にマッピングされます。

つまり、コントロールパネル上パス設定したディレクトリはそのドメインで稼働させているホストのドキュメントルートとして機能していると理解できます。

環境変数での参照値

しかし、このドメインのホストでApacheから渡される環境変数(例はPHP)を確認すると

 

  • $_SERVER['DOCUMENT_ROOT']:/home/user_name/www

 

という値が返されます。

DOCUMENT_ROOTという環境変数は比較的よく参照される値かと思われますが、これがマルチドメインで設定したディレクトリの指定と異なる仕様というのは少々ツライところです。

詳細は不明ですが、恐らくApache側でのバーチャルホスト設定は初期ドメイン1つであって、マルチドメインについては別の方法でマッピングしているということなのでしょうか…。

 

ただホスト名に関する値はマルチドメインで設定した値になっていました。

 

  • $_SERVER['HTTP_HOST']:site1.hostname.tld

 

こちらはコントロールパネルで設定したものと合致しますので、なぜDOCUMENT_ROOTだけが合致しないのかは不可解です。

 

何が問題だと認識しているのか

この仕様ですと、マルチドメインにて展開したコンテンツ内にDOCUMENT_ROOTを参照する記述をした処理が含まれると、コンテンツ内で正しいパスが把握できなくなってしまいます。

WordPressを標準(クイックインストール)で提供しているのでWordPress本体は問題なさそうなのですが、例えばテーマやプラグインなどでDOCUMENT_ROOTを参照する処理が含まれていた場合には不都合が発生していまいます。

FAQ等事例に記述が見つけれれなかったので公式サポートにて技術の方に確認させていただきましたが、これは仕様(本投稿時点)とのことですのでマルチドメイン機能を使ってPHPCGIを利用する場合には注意が必要です。

 

この環境変数「DOCUMENT_ROOT」はバーチャルホストで稼働させる際には難いものと理解していましたが、そもそもDOCUMENT_ROOTを安易に参照する処理は推奨されないものなんでしょうか。

 

ま、その名の通り環境に左右されるからあまりよくないのでしょうね。

 

 

<追記>

お名前.comのレンサバでもユーザのホームディレクトリよりかなり上位のディレクトリがセットされていたので、レンタルサーバ系では比較的よくある仕様なのかも。

さくらのレンタルサーバーで「SNI SSL」が設定できない時の対処法

さくらのレンタルサーバにてSNI SSLの設定を行おうとして軽くハマったので備忘録です。

www.sakura.ne.jp

状況

コントロールパネルにて「ドメインSSL設定」から該当するドメインに対しSSL証明書をインストール後に「ドメイン設定」>「ドメイン詳細設定」でSNIを有効にしようとするも

 

このドメインでは利用できません

 

という原因を説明する気が一切感じられないエラーメッセージが出るのみ。エラーメッセージは簡潔にしたい気持ちはわかるのですが、これでは何をどうしたらいいのかわからず、さくらのFAQやネットで事例を探すも特に有益な情報が得られず。

 

chunkynews.com

 

上記を参考に「時間」を待ってみたのですが解決せず、仕方なく最終手段でサポートにお伺いを立てました。

解決方法

サポートの方の回答は「このドメインDNSがさくらのサーバを向いていないため」ということでした。

今回、サーバ移行のために事前準備として利用していたので、SSLで利用するドメインは現在稼働している状態でした。そのためコントロールパネル上の設定を有効にできなかったようです。

SNI SSLの設定を有効にするには、DNSのレコードをさくら側に向けた後であれば可能になるそうです。

 

しかしさくらのレンタルサーバのコンパネはなぜ90年代ネット黎明期のデザインなんだろうか。強いこだわり感じる。

 

 

 

ところで今日は「猫の日」らしいですね。 

アンダー・プロトコル: 政財暴一体で600億円稼いだ男の錬金哲学

アンダー・プロトコル: 政財暴一体で600億円稼いだ男の錬金哲学

 

Wordpressの更新で「ダウンロードに失敗しました。:ファイルのチェックサムが期待値と一致しません。」のエラー

Wordpressを4.8にアップグレードを行おうとGUIから実行するも

https://downloads.wordpress.org/release/ja/wordpress-4.8.zip から更新をダウンロードしています…

ダウンロードに失敗しました。: ファイルのチェックサム (6c0797eea5561cdaa9b4edc75ba296dd) が期待値 (d95fd389479bf85939e0b36d9ae1d1a4) と一致しません。

インストール失敗

と表示されてしまい、何度実行しても更新がインストールされません。

Permissionかと考えwp-contents以下のディレクトリを調整しましたが、いっこうに改善されませんでした。

仕方ないので、coreのソースファイルを読んでみると以下の箇所で発生していました。 

github.com

チェックサムのエラーはこの「verify_file_md5()」という関数で出力されています。
それを呼び出している「download_url()」の$responseにて、実際にダウンロードしたファイルのチェックサムと比較するための「期待値」を受け取っています。

検証してみると、Wordpressダウンロードサイトhttps://downloads.wordpress.org)にて該当するZIPファイルをGETで取得する際のheader情報に「Content-MD5」というプロパティがあり、それを「期待値」とする仕様のようです。

wgetコマンドでheader情報を取得してると

$ wget -S --spider https://downloads.wordpress.org/release/ja/wordpress-4.8.zip
Spider mode enabled. Check if remote file exists.
--2017-07-26 11:00:39-- https://downloads.wordpress.org/release/ja/wordpress-4.8.zip
Resolving downloads.wordpress.org... 66.155.40.186, 66.155.40.187, 66.155.40.188, ...
Connecting to downloads.wordpress.org|66.155.40.186|:443... connected.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 26 Jul 2017 02:00:40 GMT
Content-Type: application/zip
Content-Length: 9436096
Connection: keep-alive
Cache-control: private
Content-Disposition: attachment; filename=wordpress-4.8-ja.zip
Last-Modified: Fri, 23 Jun 2017 02:03:03 GMT
X-Frame-Options: SAMEORIGIN
Content-MD5: d95fd389479bf85939e0b36d9ae1d1a4
X-nc: EXPIRED lax 186
Accept-Ranges: bytes
Length: 9436096 (9.0M) [application/zip]
Remote file exists.

「Content-MD5: d95fd389479bf85939e0b36d9ae1d1a4」が渡ってきます。
ですが、この値がWordpressが稼働するサーバ上で実際にダウンロードしたファイルに対してmd5_file()を実行して生成したチェックサム値と一致しません。

「Content-Length: 9436096」と「Length: 9436096 (9.0M) [application/zip]」とheaderは伝えているのだけど、実際にダウンロードされたファイルのサイズをfilesize()でチェックすると「2060288」(1.9M)なので、GETリクエストしているファイルと実際にダウするファイルが違っているように見受けられる。

これってWordpress側のheader情報が間違っているように感じるのだけれど、特に「4.8にアップロードできない」という声を聞かないので自分の環境特有の問題なんだろうか…。

 

調べてみたけど解決策がなくて困ったというお話でした。

 

パーフェクトPHP (PERFECT SERIES 3)

パーフェクトPHP (PERFECT SERIES 3)

 

CKEditorをCDNから利用する時のカスタマイズ方法

WebでWYSIWYGなエディタで使いやすいいCKEdiotorですが、サクッと導入したい時にファイル一式をホストするよりCDN経由で読み込む方が圧倒的に楽です。

CKEditorの特長の一つにカスタマイズのしやすさがあります。公式サイトでもツールを公開していますので、取捨選択・レイアウトも楽です。

Toolbar Configurator

利用サイトに自前でホストする場合はckeditor/config.jsを編集してカスタマイズするのですが、CDN経由の場合のエディタカスタマイズ方法が分からず、いろいろ解説サイトやドキュメントを(さっと)見たのですがすぐにわかりませんでした。

結果としてはCDN経由ではconfig.jsをCKEditorに明示的に指定してあげる必要があるようです。以下のサイトでCDN経由で利用する場合の注意点が書いてありました。

CKEditor CDN

CKEditor本体の読込み

CKEditor CDN setup

上記をhead内に記載し、エディタを適用したい要素にclass名で「ckeditor」と指定するか、別途scriptタグで置換します。注意点としては、このCKEditor.replace();はエディタを指定した要素より後に書く必要があります。

config.jsの指定

CKEditor customConfig setting

config.jsを指定するためのcustomConfigパラメータにファイルのパスを設定します。これもエディタを指定した要素より後に書かないと機能しません。

後は指定したconfig.jsを作成しカスタマイズを行うことでお好みのエディタの利用が可能になります。

カスタマイズ例

CKEditor customized example : 'config.js'

編集用の要素を絞ったのと、エディタ内でCSSやstyleを使えるようにする「config.allowedContent = true;」を追記しました。外部や不特定多数の利用が想定される場合にはこの設定をするとXSSなどのセキュリティリスクが高めてしまうので、利用には注意が必要です。タグの利用には個別の設定も可能なようなので、上記のようなケースでは「config.extraAllowedContent」で制御するべきとのことでした。

blog2.gods.holy.jp

Adobe Creative Cloudが正常に稼働しなくなった場合の対処方法

今まで5年ほどCreative Cloudを使っていますが、ログアウト出来なかったり、「App」の項目が表示されず各アプリのアップグレードができなかったりすることが多々ありました。どうやらアプリをアップグレード中に通信の切断が発生するとレジュームが出来ずに操作不能に陥るようです。

その際Creative Cloudを何度再起動してもダメだったので、Adobeのサポートの方に相談して解決方法を教示いただきましたので、再発の際の備忘録としてまとめます。

1. Creative Cloudアプリケーションの終了

Creative Cloudアプリケーションを開いて画面右上の歯車のマークをクリックし、環境設定>ログアウトのち再度歯車マークをクリックして「終了」を選択します。
終了がクリックできない場合は、アクティビティモニタを起動して「Creative Cloud」と「CoreSync」を選択し終了させます。

2. アンインストールの実行

以下ページのツールをダウンロードし、実行してCreative Cloudをアンインストールします。

helpx.adobe.com

3. 設定ファイル・キャッシュファイルの削除

3-1. ~/Library/の中

デスクトップのなにもないところをクリックし画面上部メニューバー、アップルマークの右側が「Finder」となっていることを確認してメニューバー中央あたりにある「移動」をクリックしOptionキーを押しっぱなしにすると「ライブラリ」という項目が出て来ますのでそちらをクリックします。

  • ~/Library/Application Support/Adobe/OOBE/opm.db ファイルを削除します。
  • ~/Library/Application Support/Adobe/AAMUpdater/1.0 フォルダを削除します。

3-2. /Library/の中

再度デスクトップのなにもないところをクリックし、「移動」をクリックして「コンピューター」を開きます。

  • /Library/Application Support/Adobe/OOBE というフォルダを OOBE.old と名前の変更をします。
  • /Library/Application Support/Adobe/SLCache フォルダを開き中にあるファイルを削除します。

4. Adobe Application Manager設定ファイルの削除

アプリケーションフォルダを開いて、ユーティリティも開き「Adobe Application Manager」というフォルダを削除します。

5. Adobe Application Managerの再インストール

以下ページのアプリケーションをダウンロードして実行し、インストールします。

Adobe - Adobe Application Manager:For Mac:Adobe Application Manager

6. Creative Cloudの再インストール

以下ページのアプリケーションをダウンロードして実行し、インストールします。

creative.adobe.com

一旦上記を実行しCreative Cloudが正常に機能するか確認します。

 

このような回答テンプレートを用意しているということは、サポートの方も問題を認識しているのかと思われます。高額なsubscriptionを組んでいますので、このようなことをせずに普通にアプリが使えて、最新版にアップグレードできるようAdobeさんには品質改善していただきいたいです。

Adobe製品はアップグレードするごとに「重く」なりクラッシュなどの「不具合」が多くなってくる印象があります。新機能やCloud連携など素晴らしい部分も多々あるのですが、バージョンすることで「基本的なところがしっかり動く(It just work.)」ことを大切にして欲しいです。

【EC-CUBE 2.13】購入後などにメールが送信されない場合の対策

EC-CUBEからメールが送られてこない場合の対応について備忘録。基本的な対策はこちらのエントリーを参考にしました。

バージョンが2.13に上がって設定等が微妙に変わってますので補足・補完。
インストール時に設定した「WEBサーバ設定」のオプション設定の「メールサーバー設定」>「メーラーバックエンド」の値は ~/data/config/config.php に移動しています。

もしsendmailを選んでいたら、稼働させているサーバのsendmailのパスを「which sendmail」などで調べ、パスがEC-CUBEデフォルトと違っていたらカスタマイズします。

自分が検証していたバージョン・環境では継承するfunctionで親のparent:: getBackendParamsに引数$backendを渡すとうまくいきました。

 

sendmailのパスは定数化して管理画面の「システム設定」>「パラメータ設定」で設定できるようにして欲しいですね。

 

涙の手紙【ハーレクイン文庫版】

涙の手紙【ハーレクイン文庫版】

 

 

【EC-CUBE 2.13】 支払い方法未選択で購入できてしまう時のテンプレートでの対処法

ダウンロード商品を購入する場合のプロセスの中で「支払い方法」を選ぶステップにて、支払い方法を選ばず(ラジオボタンをチェックせず)に次に進めてしまうみたいです。

コアclassを修正するのもいいんですが、マイナーバージョンアップでのマージが大変そうなのでそれは避けたい。class_extendsの機構を使うのも考えたのだけど、構造的に面倒そうだったのでテンプレートで対応する方法を考えました。 

~/data/Smarty/templates/default/shopping/payment.tplの184行目あたりにて、選択済みのセッション値がなく、ループでfirstだったら初期値としてchecked="checked"が入る形に。

テンプレート自体もバージョンアップで変わるから、あまり意味ないかもしれませんが独自テンプレートで実装すればそのままいけるかと思います。

 

EC-CUBE軽くを検証していてますが、結構「おや?」なところがあって、それが仕様なのか不具合なのか判断が難しいですね。

 

激落ち キューブ 36P

激落ち キューブ 36P