サブドメインで公開していたバーチャルホストをaliasを使ってメインサイトの配下に配置する

例えば、

  • www.hoge.com →サービスのメインサイト
  • help.hoge.com →サービスのヘルプサイト(バーチャルホスト)

のような形で運用していたものを、ファイル構成などを変更せず、

  • www.hoge.com
  • www.hoge.com/help

のように、メインサイト配下に内包して見せたい場合。主にSEO対策。

 

まず、help.hoge.comのapache設定ファイル(httpd.confなど)の内容をコピーしておく。

※今回はPlesk9下のバーチャルホストで動いているので、httpd.includeの内容をコピーしておく。

 

次に、alias用のapache設定ファイルを作成する。Plesk9配下で動いている場合は、confの下にvhost.confという名前で作成する必要がある。

参考にしたサイト)

 

SSL用にもこの設定ファイルをコピーしておく。Pleskの場合SSL用のファイル名は、vhost_ssl.confにする必要がある。内容はとりあえず同じでOK。

 

作成した設定ファイルをapacheに読み込んでもらうようにする。

参考にしたサイト):https://ex-cloud.jp/support/question/g-437

 

ヘルプサイトがワードプレスやCMSを使用している場合、.htaccessでリダイレクト設定(SEF 設定)を行っている場合があるので、静的URLでも動くよう修正する。

参考にしたサイト)

 

最後にWEBサーバをリロード

 

後はGoogleにインデックス登録してもらえるように、Search Console からsitemap.xmlなどを送信しておけばよいでしょう。

 

phpmyadminで大きなサイズのファイルをインポートする

.sqlファイルをインポートするときなど、制限があるとアップロードが途中で止まってしまう。

エラー:「アップロードしようとしたファイルが大きすぎるようです。…」など。

解決法としては、

  • エクスポート時にファイルを圧縮しておく。
  • Bigdumpを利用する。
  • sshで接続し、SCP転送する。

などがあるが、VPSやクラウド環境などの場合は、php.iniを編集した方が早いかも。

編集後、このままだと反映されないので、WEBサーバを再起動する必要があります。

以上。

参考サイト)

 

apacheのバーチャルホスト設定

すでにバーチャルホスト無しで動いている環境で、バーチャルホストを追加する場合の設定。すぐ忘れるのでメモ。

以下条件。極力オリジナルのhttpd.confは触らない方針で。

  • OS:CentOS 5.5
  • WEBサーバ:Apache 2.2.3
  • apache設定ファイルを置くディレクトリ:/etc/httpd/conf.d

最初にまず、デフォルトのServerNameを無効化。

バーチャルホスト用の設定ファイルを作る。

 

以下のように記述。
ポイントは、デフォルトのドメインでアクセスしたときの設定も<VirtualHost>ディレクティブで改めてしなければならないということ。
つまりバーチャルで追加したいFQDNのバーチャルホスト設定をしただけではダメ。

 

参考URL)

cerbot-auto renew でpythonパッケージのインストールが進まない

letsencryptの証明書更新時に、「cerbot-auto renew」でpythonパッケージのインストールが進まない話。
→ 結果、待つしかない(笑)

導入編は、こちらを参照。

さてcronによる証明書の自動更新設定を行っていたはずだが、下記のような「期限が迫ってるよ~。早く証明書更新してね~。」的なメールが届く。
———————————————
Hello,

Your certificate (or certificates) for the names listed below will expire in
9 days (on 12 Mar 17 08:02 +0000). Please make sure to renew
your certificate before then, or visitors to your website will encounter errors.

hoge.jp

For any questions or support, please visit https://community.letsencrypt.org/.
Unfortunately, we can’t provide support by email.
(以下略)
———————————————

おかしーなーと思ってrootあてのメールを見ると、以下のメッセージが。
———————————————

FATAL: Amazon Linux support is very experimental at present…
if you would like to work on improving it, please ensure you have backups
and then run this script again with the –debug flag!

———————————————

debugフラグをつけてコマンドを実行せい!とのことなので、言われたとおりにやってみるが、、

———————————————
# /usr/local/src/letsencrypt/certbot-auto renew –debug
->
Bootstrapping dependencies via Amazon Linux…
yum is /usr/bin/yum
Loaded plugins: priorities, update-motd, upgrade-helper
amzn-main/latest | 2.1 kB 00:00
amzn-updates/latest | 2.3 kB 00:00
epel/x86_64/metalink | 6.0 kB 00:00
epel/x86_64 | 4.3 kB 00:00
epel/x86_64/updateinfo | 741 kB 00:00
epel/x86_64/primary_db | 5.9 MB 00:00
remi-safe | 2.9 kB 00:00
remi-safe/primary_db | 718 kB 00:04
991 packages excluded due to repository priority protections
Package gcc-4.8.3-3.20.amzn1.noarch already installed and latest version
Package augeas-libs-1.0.0-5.7.amzn1.x86_64 already installed and latest version
Package 1:openssl-1.0.1k-15.96.amzn1.x86_64 already installed and latest version
Package 1:openssl-devel-1.0.1k-15.96.amzn1.x86_64 already installed and latest version
Package libffi-devel-3.0.13-16.5.amzn1.x86_64 already installed and latest version
Package system-rpm-config-9.0.3-42.28.amzn1.noarch already installed and latest version
Package ca-certificates-2015.2.6-65.0.1.16.amzn1.noarch already installed and latest version
Package python27-2.7.12-2.120.amzn1.x86_64 already installed and latest version
Package python27-devel-2.7.12-2.120.amzn1.x86_64 already installed and latest version
Package python27-virtualenv-12.0.7-1.13.amzn1.noarch already installed and latest version
Package python27-tools-2.7.12-2.120.amzn1.x86_64 already installed and latest version
Package python27-pip-6.1.1-1.23.amzn1.noarch already installed and latest version
Nothing to do
Creating virtual environment…
Installing Python packages…
——————————————————————————-
この状態でうんともすんとも言わなくなった!
10分待とうが20分待とうが進まないので、再度コマンド発行して、一日放置してみるも、無操作によりsshクライアントとの接続が自動切断、、、

翌週、気を取り直してもう一度試すと、、、え?通った!
——————————————————————————-

Installation succeeded.
Saving debug log to /var/log/letsencrypt/letsencrypt.log

——————————————————————————-
Processing /etc/letsencrypt/renewal/hoge.jp.conf
——————————————————————————-
Cert is due for renewal, auto-renewing…
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for hoge.jp
Waiting for verification…
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0001_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0001_csr-certbot.pem

——————————————————————————-
new certificate deployed with reload of apache server; fullchain is
/etc/letsencrypt/live/hoge.jp/fullchain.pem
——————————————————————————-

Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/hoge.jp/fullchain.pem (success)
——————————————————————————-

最初はpipのミラーサイトがダメになったのかな?とも思っていろいろ調べたが、結局通信状態の問題もしくは一時的にミラーが落ちてたっぽい。
とりあえず待つしかなかったってことね。

参考サイト)

 

Amazon LinuxでletsEncryptを導入

今回使用したamazon linuxのバージョンは以下。
——————————-
# cat /etc/system-release
-> Amazon Linux AMI release 2016.09
——————————-
WEBサーバはapache2.4。なおWEBサーバの設定の詳細は割愛します。

githubからletsencryptインストール
——————————-
# cd /usr/local/src
# git clone https://github.com/letsencrypt/letsencrypt
# cd letsencrypt
# sudo ./letsencrypt-auto –help –debug
——————————-

※使用するドメインで外部から80番にアクセスできないと認証できないので、あらかじめファイアウォールの解放と、httpd.confの設定を行っておきます。

証明書作成
——————————-
# ./letsencrypt-auto certonly –standalone -d ドメイン名
——————————-

画面の案内に沿って進める。
完了後、サーバ証明書が作成されているか確認
——————————-
# ls -lat /etc/letsencrypt/live/
——————————-

作成した証明書を、ssl.confに指定
——————————-
# vi /etc/httpd/conf.d/ssl.conf
->
:
SSLCertificateFile /etc/letsencrypt/live/ドメイン名/fullchain.pem
:
SSLCertificateKeyFile /etc/letsencrypt/live/ドメイン名/privkey.pem
:
——————————-
※fullchain.pemを指定した場合は中間証明書(SSLCertificateChainFile)の指定は不要。

WEBサーバリロード
——————————-
# service httpd reload
——————————-

ブラウザなどでhttpsでアクセスして証明書が効いているかチェック

更新用コマンド
——————————-
# /usr/local/src/letsencrypt/certbot-auto renew
——————————-

自動更新設定
——————————-
# vim /etc/crontab
——————————-
->
# letsencrypt renew #####
5 4 * * * root /usr/local/src/letsencrypt/certbot-auto renew && /etc/init.d/httpd reload
#########################
——————————-
※ちなみにcerbot-autoが使えるのはpython2.7以降。それ以前の場合は「/usr/local/src/letsencrypt/letsencrypt-auto」を使う

 

参考リンク)

apacheのSNI対応を行った場合のメリット・デメリットとapacheからのサーバ証明書切り替え処理

apache2.2.12以降で利用できるようになったSNI。

弊社サービスでも採用すれば、標準提供のワイルドカードSSL証明書と、オプションによる顧客個別のSSLサーバ証明書がうまく共存できるのではないかと考えた。

つまり、標準用とオプション用のサーバ証明書と秘密鍵を設定しておき、名前ベースのアクセスのみでサーバ証明書を切り替えられれば、標準SSL←→オプションSSLをいちいち証明書を切り替えてapacheをリロードする必要が無い。

しかし、いかんせんSNIはほぼすべてのフィーチャーフォンに未対応である。

2015年12月現在、スマホ時代が到来してフィーチャーフォンのシェアはもっぱら減少傾向にある。

運用上単純にフィーチャーフォンを排除もしくはフィーチャーフォン専用のホストを用意する場合は問題ないが、弊社のサービスはメールであり、かつ1顧客1ホストである。

特にフォームからの読者登録などの処理について、フィーチャーフォンの前提をまだ排除するわけにはいかない。

SNIを採用した場合、フィーチャーフォンのアクセス時に自動的に平文通信に切り替えてくれればまだいいのだが、SSLネゴシエーションをする段階での問題なので、無理である。

従って、フィーチャーフォンでアクセスした場合は、SNIの仕様として、デフォルトの証明書であるワイルドカードSSLの証明書が採用される。つまりフィーチャーフォンはワイルドカードにも対応していないので、結果として認証不可警告画面が出る。

これらの問題点ならびに、現在のプラットフォームはCentOS5.5+apache2.2.3なので、これらやOpenSSLをリビルドしてSNIに対応させなければならないことのリスクを考えれば、やはり標準SSL←→オプションSSLは証明書を切り替えてapacheをリロードするのが現実的であると考えた。

実現するにあたって、特に難しいことは無いが、既存のホストへのパッチ処理は最低限必要になる。

具体的には下記のような感じ。

1.ワイルドカード用のサーバ証明書・秘密鍵・ルート証明書をSCPなどで転送してapacheの設定ディレクトリ配下にコピー。

2.上記の証明書を利用するように設定したコンフィグファイル(例:ssl_wc.conf)を作成。

3.既存のssl.confをリネームして無効にする。

4.CGIが実行できる場所に、証明書の切り替えやapacheのリロードを実行するための処理を書いたshellスクリプトを追加

5.sudoユーザ設定ファイルにおいて、apacheに上記shellスクリプト(コマンド)の実行を許可する

ここまで準備を行ったら、アプリ側に、shellファイルを起動する処理を書き、GUIでサーバ証明書の切り替えを行えるようにコーディングし、これらが有効になるようにシステムファイルをバージョンアップしてもらう。

※当たり前だが、くれぐれも任意のパラメタをコマンドとして実行できてしまうような危険なshellにはしないこと。

またフォームの入力画面は、オプションSSLなしの場合は原則平文で出力し、formのaction属性(POST先)を動的に出力する。

フィーチャーフォン以外からのアクセスであれば https://+”ワイルドカードSSL用のドメイン”を出力し、フィーチャーフォンからのアクセスであれば http://+”デフォルトのドメイン”を出力する。

なお、shellの例。
————————————————————-
#!/bin/bash

# Subroutines

use_ssl_origin() {

# Checking config files…

local chg_ssl=’1′
local chg_ssl_wc=’1′

if [ ! -f “$SSL_CONF_DIR/ssl.conf.bak” ]; then
if [ ! -f “$SSL_CONF_DIR/ssl.conf” ]; then
retval=”Both ssl.conf.bak and ssl.conf are not exsist.”
return 1
else
chg_ssl=’0′
fi
fi
if [ ! -f “$SSL_CONF_DIR/ssl_wc.conf” ]; then
if [ ! -f “$SSL_CONF_DIR/ssl_wc.conf.bak” ]; then
$retval=”Both ssl_wc.conf and ssl_wc.conf.bak are not exsist.”
return 1
else
chg_ssl_wc=’0′
fi
fi
if [ $chg_ssl -eq 1 ]; then
# Updating config file…(ssl.conf.bak -> ssl.conf)
mv $SSL_CONF_DIR/ssl.conf.bak $SSL_CONF_DIR/ssl.conf || { retval=”Rename failed.(ssl.conf.bak -> ssl.conf)”; return 1; }
fi
if [ $chg_ssl_wc -eq 1 ]; then
# Updating config file…(ssl_wc.conf -> ssl_wc.conf.bak)
mv $SSL_CONF_DIR/ssl_wc.conf $SSL_CONF_DIR/ssl_wc.conf.bak || { retval=”Rename failed.(ssl_wc.conf -> ssl_wc.conf.bak)”; return 1; }
fi

# On bash, Success statsu -> 0
return 0
}

use_ssl_wc() {

# Checking config files…

local chg_ssl=’1′
local chg_ssl_wc=’1′

if [ ! -f “$SSL_CONF_DIR/ssl.conf” ]; then
if [ ! -f “$SSL_CONF_DIR/ssl.conf.bak” ]; then
retval=”Both ssl.conf and ssl.conf.bak are not exsists”
return 1
else
chg_ssl=’0′
fi
fi
if [ ! -f “$SSL_CONF_DIR/ssl_wc.conf.bak” ]; then
if [ ! -f “$SSL_CONF_DIR/ssl_wc.conf” ]; then
retval=”Both ssl_wc.conf.bak and ssl_wc.conf are not exsist.”
return 1
else
chg_ssl_wc=’0′
fi
fi
if [ $chg_ssl -eq 1 ]; then
# Updating config files…(ssl.conf -> ssl.conf.bak)
mv $SSL_CONF_DIR/ssl.conf $SSL_CONF_DIR/ssl.conf.bak || { retval=”Rename failed.(ssl.conf -> ssl.conf.bak)”; return 1; }
fi
if [ $chg_ssl_wc -eq 1 ]; then
# Updating config files…(ssl_wc.conf.bak -> ssl_wc.conf)
mv $SSL_CONF_DIR/ssl_wc.conf.bak $SSL_CONF_DIR/ssl_wc.conf || { retval=”Rename failed.(ssl.conf.bak -> ssl.conf)”; return 1; }
fi

# On bash, Success statsu -> 0
return 0
}

httpd_reload() {

/etc/rc.d/init.d/httpd reload

}

# Define values
SSL_CONF_DIR=’/etc/httpd/conf.d’

# Main
retval=”0″
if   [ “$1” = “use_ssl_origin”  ]; then
use_ssl_origin || { echo $retval; exit 1; }
elif [ “$1” = “use_ssl_wc” ];      then
use_ssl_wc     || { echo $retval; exit 1; }
elif [ “$1” = “httpd_reload” ];     then
httpd_reload
fi

exit
————————————————————-

参考リンク)
http://builder.japan.zdnet.com/etc/20402262/
http://hoge001.exblog.jp/13982612
http://another.rocomotion.jp/14140508324311.html
http://blogs.yahoo.co.jp/xkrdy982/12244910.html
http://okwave.jp/qa/q8172686.html
http://webcache.googleusercontent.com/search?q=cache:eKZwQAKc3pAJ:www.hutcraft.jp/%3FD%252F2013-08-03+&cd=3&hl=ja&ct=clnk&gl=jp
http://centos.it-study.info/web/apache2225.html
http://www.atmarkit.co.jp/ait/articles/1108/05/news122.html