クラウドやろうぜ！

2018年5月26日土曜日

CentOS5でphpのcurlからTLS1.2対応をさせる話

PCIDSSの対応で各決済会社のTLS1.2縛りが始まりました。

乗り遅れてしまった！！　やばい！間もなくじゃない？
的な話もチラホラ聞きます。

phpで作られているシステムであれば、curl等を用いて決済情報に確認を
しにいったりリクエストを投げたりしているところが多いのではないでしょうか。

CentOS6以降であれば普通にyumで対応出来ちゃうのですが、
CentOS5系ですとyumでは無理。
proxyで逃げるという策もあるのですが、サーバーも立てられない環境だと、
なかなか安易に逃げれない。
という訳で、今回はphp-curlを更新して対応させちゃう話です。

/usr/localにはソースインストールしているような形跡が無い前提で、
php-5.3.19の環境を元に書いていますので、
その辺は自身の環境と読み変えて下さい。

全て最新を入れたいところなのですが、
全て最新だとなかなかいろいろと問題が出るので、
TLS1.2に対応出来ているという形で収めます。

opensslをダウンロードします。

wget --no-check-certificate https://www.openssl.org/source/old/1.0.1/openssl-1.0.1u.tar.gz
tar xzvf openssl-1.0.1u.tar.gz
cd openssl-1.0.1u

既存環境を汚したくないのでprefixを指定してconfigureします。

./config --prefix=/usr/local/openssl shared
make
make install

完了です。

次にcurlをインストールするのですが、opensslのlibを読み込めるように、
ldconfigでpathを読めるように以下を追記しておきます。
vi /etc/ld.so.conf
---------
/usr/local/openssl/lib
---------
ldconfig

curlですがs3等で画像の存在確認をして表示をさせるようなシステムだと、
最新のcurlでは--outputオプションをつけないとbinaryは表示出来ない為、
エラーになるケースが見受けられました。

以下は新しいcurlで実施していますが、エラーが出るようでしたら
curlを7.19くらいに落とすと上手くいきます。
ただ7.19をダウンロードするにも公式からTLSではじかれるので、
7.58.0をインストールしてから
curl -k curlのURL -o ファイル名
でもいいと思います。
ca情報が古い場合はpemファイルを上記と同じようにcurl -k でゲットして配置しなおします。
詳しくはこちら。
うまい棒ブログ(id:hogemさん)
サーバのSSL CA(認証局)証明書が古くてcurl がエラーになる件
http://hogem.hatenablog.com/entry/20120705/1340284071

さて、続きやります。今回は7.58.0をゲットして入れます。
今回も環境汚染しないようにcurlをprefix指定して別にインストールします。
新しいsslを読み込んで作りたいので新しくインストールしたopensslディレクトリを指定します。

wget --no-check-certificate https://execve.net/mirror/curl/curl-7.58.0.tar.gz
tar xzvf curl-7.58.0.tar.gz
cd curl-7.58.0
./configure --prefix=/usr/local/curl --with-ssl=/usr/local/openssl
make
make install

以下でバージョン確認するとopenssl-1.0.1uを参照しているのがわかると思います。
/usr/local/curl/bin/curl --version

新しくインストールしたcurlを元にphp-curlを作り直します。
今回の環境はphp-5.3.19がyumでインストールしてあったので、同じバージョンをダウンロードします。
切り戻せるように元からあるモジュールはバックアップしておきましょう。

mv /usr/lib64/php/modules/curl.so /usr/lib64/php/modules/curl.so.old
※32bit環境であればlib64をlibにして下さい。

wget http://museum.php.net/php5/php-5.3.19.tar.gz
tar xzf php-5.3.19.tar.gz
cd php-5.3.19/ext/curl/
phpize

新しくインストールしたcurlをディレクトリとして指定します。
./configure --with-curl=/usr/local/curl
make
make install

これで完了です。
php -i で確認するとcurlの参照opensslが1.0.1の新しいものに
なっていると思います。

以下のようなテストスクリプトでphpの実行ファイルを作成し、
実行した際にページの情報が表示されればokです。

-----------------------------------
<?php
$url = "対象サイトのURL";
$ch = curl_init();

curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$html = curl_exec($ch);
var_dump($html);
curl_close($ch);
-----------------------------------

意図しない表示崩れ等を起こすと困るので、
apacheを再起動(gracefulやreloadでもok)して表示を確認しましょう。

今回はcurlでしたが他のphpモジュールで対応したい場合でも、
そのモジュールが参照するパッケージを新しくソースインストールして、
新しい方を参照する形で作り直せば通ると思います。

同じようにCentOS5のgitのsshやcurlでハマッてる人をよく見かけますが、
上記と同じようにopensslを元にsshやcurlを作れば大丈夫です。

ここまで書いといてあれですけど、
既に陳腐化しているシステムを無理くりやっているだけなので、
本来であればCentOS7に移行するのが筋です。

あくまでワークアラウンドでお考え下さい。

※ここに書いてある内容は一般的な対応方法では無いので
　くれぐれも実施後は確認を怠らず注意の上、自己責任でお願いします。

それでは、よいクラウド構築を。

2017年12月23日土曜日

IDCFクラウドで追加ネットワークに仮想マシン作成時からIPを指定する

※IDCF Cloud Advent Calendar 2017 に参加してます。

気付いたら1年ぶりの投稿でした。
ブログって意識してないとホント書きませんね。
という訳で、アドベントカレンダーがあったので書くきっかけにしてみました。

IDCFクラウドで追加ネットワークって仮想マシン作成時に、
コントロールパネルからIP指定して起動出来ないんですよね。
・追加ネットワークだけ使いたい（裏側のDBとか）
・プライベートネットワークと接続している
・別途マネージドFW/LBを契約している
とかとか。そんな時に超不便。
なのでcloudstack-apiを使用してさくっとIP指定して作ってしまいます。

cloudstack-apiのインストール方法は下記。
http://docs.idcf.jp/cloud/introduction/#install
ちなみに、上記のマニュアルは一部古くて、curlは以下が正解です。

curl -kL https://bootstrap.pypa.io/get-pip.py | python

2018年2月には現在ベータ版のidcfcloud-apiの仮想マシン機能がリリース予定らしいので、
その時はidcfcloud-apiに書き換えちゃいましょうね。
それまでの間って短いなーって感じですが、短い間でも楽しなきゃ損なので。

基本形はこれ。

/usr/bin/cloudstack-api deployVirtualMachine \
--serviceofferingid $SERVICEOFFERINGID \
--templateid $TEMPLATEID \
--zoneid $ZONEID \
--group $GROUP \
--keypair $KEYPAIR \
--name $NAME \
--networkids $NETWORKIDS \
--ipaddress $IPADDR

順を追って確認しましょう。
先ずは serviceofferingidですが、仮想マシンのタイプです。
以下コマンドで起動したい仮想マシンのタイプのidをメモ。

cloudstack-api listServiceOfferings -t name,id

templateidも同じように以下コマンドで起動したいテンプレートのidをメモ。
※セルフテンプレートの場合は以下。公式のを使う人は templatefilterをselfからfeaturedに変更

cloudstack-api listTemplates --templatefilter self -t displaytext,id,name,ostypename,status,zonename

次はzoneidを確認。

cloudstack-api listZones -t name,id

groupを確認。
※新しく指定する場合は必要なし。

cloudstack-api listInstanceGroups -t name

keypairを確認。
※指定するときは名前。finger printは確認の意味で。

cloudstack-api listSSHKeyPairs -t name,fingerprint

networkidを確認。

cloudstack-api listNetworks -t name,id,cidr

上記コマンドで確認した内容を前述の以下コマンドで流せば作成できます。
$NAMEの部分は作成したい仮想マシンの名前。
$IPADDRの部分は指定したいIPアドレスを代入してください。

/usr/bin/cloudstack-api deployVirtualMachine \
--serviceofferingid $SERVICEOFFERINGID \
--templateid $TEMPLATEID \
--zoneid $ZONEID \
--group $GROUP \
--keypair $KEYPAIR \
--name $NAME \
--networkids $NETWORKIDS \
--ipaddress $IPADDR

ちなみにnetworkidsは複数指定可能なので、仮想ルーターのデフォルトNWと追加NWを両方出来ます。

これをshellとかにして引数にIPアドレスと名前を指定出来るようにしておけば、
オートスケールに使ったり出来るし、結構万能に使えます。

「なんで追加ネットワークのIP指定出来ないんだよ！」
って発狂気味の皆さんはぜひお試しください。

それではよいクラウド構築を。

2016年12月19日月曜日

IDCFクラウドでゾーンを移設するメリットと方法

※本記事はIDCF Cloud Advent Calendar 2016に寄稿しています。

どうも。どんことtaka3110です。
前回はゾーン別のスペックについて書いてみました。
今回はゾーン移設を実際にやってみます。
手順を書いた長い記事ですので、面白いことは書いてません。あしからず。。

メリットについては前回のブログで書いた通り、
スペックが違う為、初期のゾーンから移設するという選択だけで、
性能アップが見込めます。

今回、wordpressとメール的な環境を想定してみました。
移設元は「メールサーバー + Webサーバー」(Web+DB)という内容です。

前提としては、
----
移設元環境
・IDCF提供のテンプレートを使用して構築されている
・仮想ルーターIPを使用している
・Webサーバーとメールサーバーに使用している
----
としています。

やり方はいくつかあります。
このブログでも紹介しましたが、rsyncでOSより上をまるっと移設する方法や、
１から構築してデータのみを移設する方法もあります。

今回はテンプレートファイルを作成し、それをリージョン移設して構築したいと思います。
今回はteslaから東日本2のluxに移設します。

極力ダウンタイムを減らしたいので、
Webについてはsorryサーバーを表示させ、メールはセカンダリを指定してみます。
今回の記事でもsorryサーバーとセカンダリメールサーバーの構築をしたいと思います。
移設前にはスムーズに作業、確認を行うためにDNSのTTLを下げておきましょう。
最低でも600以下にしておく事をお勧めします。

セカンダリメールサーバーを作成してそちらに向けるメリットとしては、
こちら側の意図でメールの再配信が出来るところにあります。
メールサーバーへの疎通ができない場合、送信元がリトライを行います。
リトライの回数、秒数については送信元によって違います。
セカンダリメールサーバーを用意しておくと、送信元はメール送信を完了し、
セカンダリメールサーバーで再送処理をする形になります。
作業完了後にセカンダリメールサーバーで再送処理をする事で、
移設後直ぐにメールサーバーを落としていた間のメールが届く形になります。
常時運用ではなく、今回はスポット的に使用しますが、とても簡単に構築出来ます。
なお、サービスを停止してからテンプレートを取得する手順を踏む為、
送信だけ行っている環境であればセカンダリメールサーバーの構築は今回必要ありません。

セカンダリメールサーバの構築時にluxのIPを使用するので、
移設元がIPを取得しているならば、先にIPの取得をしておきましょう。
（この記事では仮想ルーターのIPを使用します。）
また、ポートフォワードの設定も移設しておきましょう。

今回の流れ
０．移設先のIP取得とポートフォワードの設定
１．sorryサーバーとセカンダリメールサーバーの構築
２．DNSの登録とポートフォワードの設定変更
３．スナップショット、テンプレートの作成
４．テンプレートの移設
５．テンプレートから構築
６．移設後の確認
７．DNSの変更
８．セカンダリメールサーバーの再配送
９．後片付け
大体、15GBであれば1時間程度で完了する作業です。

先ずはsorryサーバー+セカンダリメールサーバーを作ります。
移設元の同じゾーンに仮想マシンを立ち上げます。
今回はCentOS6.8を選択して構築したいと思います。

仮想マシンが立ち上がったらIPアドレスを取得します。
IPアドレスを取得したら今回立ち上げた仮想マシンにNATの紐づけをします。
NATの紐づけはNATボタンから対象サーバーを選択して有効化するだけです。
この対応で全てのポートがNAT設定した対象サーバーに向けられます。
（もちろんポートフォワードでも構いません）

FWにはsorryサーバーとセカンダリメールサーバー用の許可設定を追加します。
先ずはsshのport22をMyIP等、作業環境から許可し、
httpのport80、smtpのport25をAny(0.0.0.0/0)で許可します。
（httpsのアクセスが必要な場合は443も許可しましょう）

上記まで完了したらsshでサーバーにログインしましょう。

Webサーバーを構築します。

# yum -y install httpd
# /etc/init.d/httpd start

下記にsorryページを配置しましょう。
/var/www/html/index.html

この状態で"http://取得したIPアドレス/"にアクセスして、
sorryページが表示されればOKです。

次にセカンダリメールサーバーを作成します。
既にpostfixはインストール済みになっているので、設定変更のみ行います。

# vi /etc/postfix/main.cf
----

以下をlocalhostからallへ変更
----
inet_interfaces = all
----

最終行に以下を追記
----
transport_maps = hash:/etc/postfix/transport
relay_domains = ドメイン名
----

# vi /etc/postfix/transport
以下を追記
----
ドメイン名 smtp:移設先サーバーのIP
----

例）ドメイン名がtest.orgで移設先サーバーが210.140.171.1だった場合
test.org smtp:210.140.171.1

設定を反映します。

# postmap /etc/postfix/transport
# /etc/init.d/postfix restart

以上でsorryサーバーとセカンダリメールサーバの構築は完了です。

次にセカンダリメールサーバー用にDNSを設定しましょう。
今回取得したsorryサーバー用のIPアドレスをAレコードで指定します。
mail2等、解りやすい名前で構いません。
次にMXレコードを今のものよりも大きい優先度で設定します。
例）今が10であればセカンダリは20

これでDNSが浸透すればセカンダリメールサーバの設定は完了です。

ここからは移設の作業になります。
ダウンタイムにある程度の許容があれば、データの不整合等もなくなるので、
この時点でsorryサーバーに切り替えてしまいましょう。
ダウンタイムに許容が無い場合は、sorryサーバーへの切り替えは最後に行い、
DNSの浸透を待って新しいサーバーへ同期を行いましょう。

今回はこの時点でsorryサーバーに切り替えを行う手順を取ります。
この記事ではhttp、httpsをsorryサーバーに切り替えます。
既存のサーバーのポートフォワードを一旦削除し、sorryサーバーへ向けます。
※既存のサーバーがNATでしたら別のIPを取得し、ポートフォワードで設定をし、
　そちらにDNSを向けて対応しましょう。

移設元サーバーにログインします。
既にサービスはsorryサーバーの方を向いている事を確認し、
各サービスを止めます。

# /etc/init.d/httpd stop
# /etc/init.d/mysqld stop
# /etc/init.d/postfix stop

ここからサーバーをコピーする作業を行います。
テンプレートを作成する前にnetwork deviceの情報を削除します。

# rm -f /etc/udev/rules.d/70-persistent-net.rules

また、Disk追加をしている場合は、fstabで追加Diskの行をコメントアウトしておきます。

上記が完了したらスナップショットを取得します。
スナップショットは
仮想マシン⇒（対象の仮想マシン名）⇒ボリューム⇒右下のボリューム操作へをクリック
表示されるボリューム名をクリックし、スナップショット⇒スナップショット作成で取得できます。

スナップショットが取得出来たら、スナップショットを確認します。
ステータスがBackedUpになっていればスナップショットの取得完了です。
スナップショットからテンプレート作成をクリックします。
テンプレート名やOSタイプを選択し、作成するをクリックします。

作成できたテンプレートをエクスポートします。
テンプレートから作成したテンプレートをクリックし、エクスポートをクリックします。
URLを発行するボタンが表示されるのでクリックします。
※生成中の間は他のページ等に遷移しないように注意してください。

テンプレートのURLが表示されるのでテキスト等にコピーをしておきます。

ここまで出来たら移設先の東日本2にページを切り替えます。

コンピューティングのテンプレートからテンプレート作成ボタンをクリックします。
テンプレート名～OSタイプまでを入力します。フォーマット以下は特に変更は不要です。
URLは先ほどコピーしたURLのhttpsの部分をhttpにして貼り付けます。
全て入力したらテンプレートを作成するボタンでテンプレートを作成します。

上記テンプレートを使用して仮想マシンを作成します。
今回の記事ではセカンダリメールで転送先指定をしているluxを指定しているので、
ゾーンはluxを使用します。
また、SSH keyは元のサーバーと同じものを使用します。
アップロードをクリックし、移設元サーバーで以下で表示される内容をコピーしましょう。

# cat /root/.ssh/authorized_keys

上記入力が完了したら仮想マシンを作成します。

仮想マシンにログイン出来る事を確認したら、
立ち上がっていないサービスが無いか確認しましょう。

※ログイン出来ないという時は、udevのルールが残っている可能性があります。
　コンソールからログインして削除をしてrebootしましょう。

これでサーバー側は完了です。

最後にDNSを新しいサーバーへ向けなおします。

DNSが浸透をした事を確認したら、sorryサーバーにログインし、
postfixの溜まったデータを再配送します。

# postfix flush

以下コマンドでqueueが空になっている事を確認しましょう。

# postqueue -p
Mail queue is empty

上記が完了したら、sorryサーバーは削除してしまいましょう。
旧サーバーも停止してしまいましょう。
データについては何かあった際に使う可能性がありますので、
念のため２～３日についてはサーバーはそのまま残しておく事をお勧めします。

以上で移設完了です。お疲れ様でした。

さて、画像等を使わないで文字だけでつらつらと書いてしまい、
解りづらい部分もあったかと思います。
こんなところにハマった。とか、こういうのはどうやってやるの？
質問等があればご連絡ください。
また、ユーザー会もありますので、ぜひ参加して聞いてみて下さい。

それでは、よいクラウド構築を。

2016年12月4日日曜日

IDCFクラウドのゾーンから見る性能強化と進化

※本記事はIDCF Cloud Advent Calendar 2016 Advent Calendar 2016に寄稿しています。

どうも。どんことtaka3110です。

今回は久しぶりにIDCFクラウドについてです。
東日本に新しいリージョンがリリースされました。
これでリージョンは3個、ゾーンは10個となった訳ですが、
どれを使っても同じという訳ではありません。
という訳で、今回はゾーンについて振り返りながら性能を考えてみたいと思います。

まずはどんなゾーンがあるのか。

	ゾーン	リージョン	リリース
1	tesla※	東日本	2014/10
2	pascal	東日本	2015/4
3	henry	東日本	2015/6
4	joule	東日本	2015/10
5	augusta	西日本	2015/11
6	radian※	東日本	2016/3
7	newton	東日本	2016/7
8	monstera	西日本	2016/8
9	weber	東日本2	2016/11
10	lux	東日本2	2016/11

※は現在新規アカウントでは追加不可能のようです。

約2年で10なので、2.4か月に1ゾーンという形で増えています。
割と良いスピードで増えていますね。

2015年11月のaugusta以降は全てオールフラッシュディスクでの提供となっています。
（西日本、東日本2はオールフラッシュリージョン）
したがって、Disk性能がaugustaから飛躍的に上がっています。

性能だけが違うのかというと使えるサービスにも違いがあります。
例えばGPUインスタンスを立ち上げるには現在は東日本2になります。

ゾーン別の対応インスタンス

	ゾーン	HighIO	GPU
1	tesla※	highio.5XL128のみ	非対応
2	pascal	全て可	非対応
3	henry	highio.5XL128のみ	非対応
4	joule	全て可	非対応
5	augusta	全て可	非対応
6	radian※	全て可	非対応
7	newton	全て可	非対応
8	monstera	全て可	非対応
9	weber	highio.3XL128のみ	対応
10	lux	highio.3XL128のみ	対応

HighIOインスタンスに一部違いがあります。
また、GPUインスタンスは現在(2016/12/03現在)は東日本2リージョンのみの対応です。

ゾーンで違うのはこれだけではありません。
CPUの型も違います。newton以降から新しいCPUを搭載したマシンになっています。
light.S1は以下のようになっています。（タイプによってCPUが変わる場合があります。）

	ゾーン	CPU
1	tesla※	Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
2	pascal	Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
3	henry	Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
4	joule	Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
5	augusta	Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
6	radian※	Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
7	newton	Intel(R) Xeon(R) CPU E5-2697A v4 @ 2.60GHz
8	monstera	Intel(R) Xeon(R) CPU E5-2697A v4 @ 2.60GHz
9	weber	Intel(R) Xeon(R) CPU E5-2697A v4 @ 2.60GHz
10	lux	Intel(R) Xeon(R) CPU E5-2697A v4 @ 2.60GHz

ここまで見てお分かり頂いたかと思いますが、
augusta以降からフラッシュディスクになり、newton以降からCPUが新しい型になっている為、
初期のゾーンと一番新しいゾーンでは、かなりの性能差が出ます。
勿論、値段が変わらないので新しいzoneを使った方が断然コストパフォーマンスが高くなります。

言葉よりも数値で見た方が解りやすいと思います。
light.S1で全ゾーンをhdparmで比較するとこうなります。

	ゾーン	cached reads	buffered disk reads
1	tesla※	8706.18 MB/sec	275.83 MB/sec
2	pascal	8336.05 MB/sec	264.62 MB/sec
3	henry	8823.00 MB/sec	204.79 MB/sec
4	joule	8419.01 MB/sec	290.63 MB/sec
5	augusta	8823.96 MB/sec	314.37 MB/sec
6	radian※	8593.79 MB/sec	249.83 MB/sec
7	newton	10150.15 MB/sec	316.51 MB/sec
8	monstera	9981.35 MB/sec	389.55 MB/sec
9	weber	10436.24 MB/sec	403.65 MB/sec
10	lux	10395.61 MB/sec	411.82 MB/sec

augusta以降はフラッシュディスクになっている為、buffered disk readsが性能強化されており、
newton以降はcpuが強化されているのでcached readsが増えています。
しかしながらradianがスペックの割に性能が出ていません。
勝手な想像ですが、恐らくは東日本で初めてフラッシュディスクになったゾーンですので、
仮想マシン数が多いのではないでしょうか。そういった理由も新規で選択出来なくなっている理由でしょう。
新しくIDCFクラウドを契約する方は特に気にする理由は無さそうです。
古くから使用しているユーザはサポート等に現状厳しいゾーンを聞けば答えてくれると思います。きっと。ええきっと。

さて、より分かりやすく性能を見るためにWEB2層のアプリケーションで確認してみます。
実際にlight.S1へコンテンツを載せてWRSで比較してみると以下のようになります。
※WRSとはデフォルトの状態でwordpressにabをかけて比較したものです。

	ゾーン	ab -n 1 -c 1	ab -n 10 -c 10	ab -n 100 -c 10
1	tesla※	6.30 [#/sec]	6.44[#/sec]	2.11[#/sec]
2	pascal	6.71 [#/sec]	6.3[#/sec]	2.07[#/sec]
3	henry	6.38 [#/sec]	7.12[#/sec]	2.13[#/sec]
4	joule	6.60 [#/sec]	6.56[#/sec]	2.1[#/sec]
5	augusta	7.47 [#/sec]	7.02[#/sec]	2.16[#/sec]
6	radian※	6.63 [#/sec]	5.84[#/sec]	2.08[#/sec]
7	newton	8.54 [#/sec]	8.03[#/sec]	2.65[#/sec]
8	monstera	9.72 [#/sec]	9.38[#/sec]	2.79[#/sec]
9	weber	9.98 [#/sec]	9.54[#/sec]	2.99[#/sec]
10	lux	9.87 [#/sec]	9.56[#/sec]	2.82[#/sec]

何もしなくても、初期のteslaやpascalと比べて、
最新ゾーンのweber、luxは1.5倍程度の性能差が出ています。
勿論、まだリリース直後でユーザーが少ないというのも大きな要因ですが、
newtonで見てみても大分性能差が出ている事が解ります。

ちなみにab -n 100 -c 10だけ値が低いのは、
light.S1のCPUリミッター(0.8GHz)によるものです。
light.S1は0.8GHz相当という触書になっていますが、直ぐにCPUリミッターが掛かる訳ではありません。
上記表の通り、そこまでアクセス数が多くないサイト等であれば、2.4GHz相当で使用出来ます。

新しいゾーンが出ると性能が強化されて更に進化していくIDCFクラウド。
AWSではファミリーの世代という形で性能強化されていきますが、
IDCFクラウドでは現状、ゾーン毎に進化をしていきます。

上記のように性能が強化されるのでtesla等、旧ゾーンで性能が足りなくなってきたと感じたら、
ゾーン移設を検討するのも１つの手です。
複数台構成であれば、GSLB機能もあるのでサービス停止を回避しながらゾーン移設も可能です。

次回は旧ゾーンから新ゾーンに移設する方法をご紹介しようと思います。

それではよいクラウド構築を。

2016年11月22日火曜日

CentOS5のyumな環境でATS対応させた話

どうもtaka3110ことどんです。

今回は待った無しになっているATS対応の話です。

そもそもATS対応って何じゃい？という方は、こちらをご参照下さい。

「ATS + IOSの検索結果」

簡単に言うと、AppleさんとこのIOSアプリからAppleさんが言うセキュリティに

準拠していないサイトは片っ端から弾きまっせ。覚悟しとき。

という宣告です。

ATSに対応する為には

-------------------

・ TLS ver 1.2以上であること

・以下のcipherに対応している事

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

・サーバ証明書はsha256でキーは2048bit長以上にする事

-------------------

というルールがあるらしい。

何が困ったってCentOS5系を運用しているサイトやゲームですね。

特に側ネイティブでやっているアプリなんて季節的にもCentOS5があったりするのでは？

CentOS5でATS対応するには、

・opensslをsrcからコンパイル

・apacheの最新版をsrcからコンパイル

しなければ対応出来ません。

（対応出来たよ！という方は教えて下さい・・・）

ちなみにopensslをsrcコンパイルしてmod_ssl作ればええやん的な安易な発想でしたが、

SSLCompressionの設定、ECDHEに対応していない等の罠があり結論無理でした。

yumの環境だと相当難儀な作業になります。

モジュール類、特にphpもソースコンパイルして対応となると、

もうね、それだけで面倒な作業。

という訳で、出来る限りyumでインストールされている現況を崩す事なく、

何とかATS対応出来ないかという事でやってみました。

aprを変更せずに、prefix指定でソースコンパイルすれば、

そのままyumで入れた同じモジュールを使えるのではないか説が沸きあがり、

実際にやってみたら使えたのでご紹介します。

（実際にやっても自己責任でお願いしますね・・・）

１．作業ディレクトリ作成

解りやすく作業する為に作業ディレクトリを作ります。

mkdir /root/src

cd /root/src

２．ソースゲット

最新版のソースをゲットします。

元々2.2系だったので、2.2系の最新とopensslの1.0.1の最新を入れます。

wget http://ftp.jaist.ac.jp/pub/apache/httpd/httpd-2.2.31.tar.gz

wget https://www.openssl.org/source/openssl-1.0.1u.tar.gz

３．opensslのインストール

あくまでmod_sslを作るためだけのopensslにしたいので、

prefixを指定してインストールします。

#config時の"-fPIC"は入れても入れなくても大丈夫です。入れた場合、ソースの書き換えが一部必要になります。

tar xzvf openssl-1.0.1u.tar.gz

cd openssl-1.0.1u

./config --prefix=/usr/local/openssl1.0.1 shared

make

make install

cd ..

４．apache

apacheについても既存環境を汚さないようにprefixを指定してインストールします。

ちなみにenable類は無くても大丈夫だと思います。何か、念のためやりました。

tar xzvf httpd-2.2.31.tar.gz

cd httpd-2.2.31

./configure --prefix=/usr/local/httpd-2.2.31 \

--enable-dav=shared \

--enable-dav-fs=shared \

--enable-dav-lock=shared \

--enable-proxy=shared \

--enable-proxy-connect=shared \

--enable-proxy-ftp=shared \

--enable-proxy-http=shared \

--enable-proxy-balancer=shared \

--enable-proxy-ajp=shared \

--enable-rewrite=shared \

--enable-ssl=shared \

--enable-mem-cache=shared \

--enable-so \

--enable-modules=all \

--enable-mods-shared=all \

--with-ssl=/usr/local/openssl1.0.1

make

make install

cd ..

ここまで出来れば後はapacheのmoduleと起動スクリプト類を入れ替えるだけです。

ちなみに同じようなCentOS5が他にもある場合、ここで作ったディレクトリを配布すれば、

いちからコンパイルする必要は無いです。

/usr/local配下にopenssl1.0.1とhttpd-2.2.31ディレクトリを置いてやればokです。

適用作業はこんな感じでやりました。

５．初期コンフィグのバックアップ

戻せるようにしておきましょう。

mv /usr/local/httpd-2.2.31/conf /usr/local/httpd-2.2.31/conf.org

mv /usr/local/httpd-2.2.31/modules /usr/local/httpd-2.2.31/modules.org

６．既存モジュールのcopy

yumで入れたモジュールをコピーします。

#パスは64bitの場合です。

cp -rp /usr/lib64/httpd/modules /usr/local/httpd-2.2.31/

７．既存コンフィグのコピー

既存のコンフィグを適用させましょう。

cp -rp /etc/httpd/conf /usr/local/httpd-2.2.31/

cp -rp /etc/httpd/conf.d /usr/local/httpd-2.2.31/

cp -rp /etc/httpd/common /usr/local/httpd-2.2.31/

８．設定ファイル類のディレクトリ構成設定

運用性を考えて同じディレクトリ構成にしておきましょう。

mv /etc/httpd /etc/httpd.org

ln -s /usr/local/httpd-2.2.31 /etc/httpd

９．起動ファイルの変更

戻せるようにしておくのと、tab効きするようにしておきましょう。

mv /etc/init.d/httpd /etc/init.d/httpd.org

chmod -x /etc/init.d/httpd.org

ln -s /usr/local/httpd-2.2.31/bin/apachectl /etc/init.d/httpd

mv /usr/sbin/httpd /usr/sbin/httpd.org

chmod -x /usr/sbin/httpd.org

ln -s /usr/local/httpd-2.2.31/bin/httpd /usr/sbin/httpd

１０．mod_sslのモジュールのみコピー

mod_sslは今回コンパイルしたものを使います。

cp -pi /usr/local/httpd-2.2.31/modules.org/mod_ssl.so /usr/local/httpd-2.2.31/modules/

１１．logやrunフォルダの設定

logフォルダは引き継ぐようにしておきます。

mkdir /etc/httpd/run

mv /etc/httpd/logs /etc/httpd/logs.org

ln -s /var/log/httpd /etc/httpd/logs

１２．アップデートしたopensslをmod_sslが読みに行く為の設定

最後にmod_sslがprefixしたopensslを読みに行けるようにしておきます。

echo "/usr/local/openssl1.0.1/lib" >> /etc/ld.so.conf

ldconfig

以上で完了。

古いapacheが上がっていればpkill httpdで落としてやれば、

普通に新しいapacheを上げられる筈。

これで構築したサイトを以下で見てみるとATS対応している筈。

https://www.ssllabs.com/ssltest/

ここまででとりあえず一時しのぎ的にATS対応出来たとしましょう。

でもね、そもそも論としてCentOS5を使い続けるってどうなのよ？

という疑問を投げかけざるを得ない。

という訳で、取り急ぎ時間が出来たという事で、

しっかりと計画してリプレースしましょう。

それではよいクラウド構築を。

一応、、、、もとにもどす手順も置いときます。

rm /etc/httpd
mv /etc/httpd.org /etc/httpd
rm /etc/init.d/httpd
mv /etc/init.d/httpd.org /etc/init.d/httpd
chmod +x /etc/init.d/httpd
rm /usr/sbin/httpd
mv /usr/sbin/httpd.org /usr/sbin/httpd
chmod +x /usr/sbin/httpd

2016年9月20日火曜日

YAMAHAのルーターで存在しないNWを使ってVPNする話

どうもtaka3110ことどんです。

最近、YAMAHAのルーターと戯れる事が多かったので、
少しメモ代わりに書いておきます。

題名だけ見ると大それたというか、謎めいた感じですが、
簡単に言えばNATです。はい。
ただ、双方向NAT（TwiceNAT）のドキュメントはありますが、
単方向NATでマスカレードしないのはあまりなく、でも結構使う機会がある。
というところでブログネタにした訳です。

最近ではフレッツVPNなどで店舗間でも割と簡単にフレッツ網を使ったVPNがはれます。
店舗間データのやり取りをセキュアに行いたい等、結構使う機会はあると思います。
例えば、本店と店舗のNWが全く同じ場合は、前記のTwiceNATを用いれば良いですが、
（TwiceNATの設定例：http://jp.yamaha.com/products/network/solution/vpn/connect/twice_nat/ ）
本店が「このNWで接続して下さい。」と払い出されて、店舗側が違うNWになっている場合。
これって、店舗側のNWを総入れ替えするか、NATするかの2択な訳で。
やれ工数だの改修だのを考えると、結論NATになる訳です。

ただ、もう1台ルーターを置いてやるのが綺麗なやり方。
存在しないNWではなく、存在するNWを作ってしまう。
本社ルーター -->　店舗ルーター（NEW） -（払い出しNW）-> 店舗ルーター
という感じで払い出しNWを作ってしまって、そこのIP帯でNATさせる。
というのが割と綺麗なやり方だと思います。
が、そんなポコスカとルーターを買うという訳にもいかないと思いますし、
出来るので、1台でやってしまいましょうと。

そうすると、やり方としてはざっと考えて２つあって、
・セカンダリIPをつけてルーティングさせてしまう。
・払い出しNWのIPでNATさせてしまう。
という2つかと。

で、もう存在はしてないけど、払い出しNWのIPでNATして通信出来れば良い。
という事で、今回はそんな感じの話です。

本店から払い出されたNWは10.1.10.1/24
基幹に接続するコンピュータのIPは接続元制限により10.1.10.254のみ許可。
例えばストコンが基幹にデータを送る場合は上記IPで送る必要がある。
というような感じ。

構築するNWはこんな感じです。

で、どう構築するかって話になるんですが、
先のTwiceNATのページのreverseの部分を削除すればいいだけ。
というより、TwiceNATも存在しないNWを間に挟んで同じNWを通信させてるイメージなので、
それと同じことをしてやれば良いと。

書き方も割と単純に、ほんとreverseを削除しただけのこんな感じで通ります。
（ISPの部分やVPN認証、フィルタ等の設定は別途必要）
---
#ルーティング
ip route 172.11.0.16/32 gateway pp 1
ip route 10.20.0.0/16 gateway tunnel 1

#NAT
nat descriptor type 1 masquerade
nat descriptor masquerade static 1 1 172.11.0.16 udp 500
nat descriptor masquerade static 1 2 172.11.0.16 esp
nat descriptor type 2 nat
nat descriptor address outer 2 10.1.10.1-10.1.10.254
nat descriptor static 2 1 10.1.1.254=192.168.1.50 1

pp select 1
ip pp address 172.11.0.1/32
ip pp nat descriptor 1

tunnel select 1
ip tunnel nat descriptor 2
---

やっぱり存在しないNWがあって、途中でNATにより処理する。
というのはあり得る話なんですが、少し気持ち悪いなぁ。と思うのは私だけかしら。。

割と設計的にはあり得る話ですが、ググってもなかなか出てこないので、
書いてみました。

というわけで、よいクラウド？構築を。

2016年8月27日土曜日

IDCFクラウドの追加NWの注意点

最近、IDCFクラウドの追加ネットワークでちょっとしたハマり方をしたのでメモ。

IDCFクラウドはネットワークを追加する事が出来ます。
NICも独立するので、インターネット側のNWとは別にしてVPNのネットワークを作ったり、
DBの通信にしようしたり、Heartbeat専用のネットワークを作ったり。

まぁ、いろんな設計が無停止で柔軟に出来るようになっています。

ネットワーク追加も従量課金で20円/時間で課金され、1か月1万円が課金上限になるシステムです。

参考： http://blog.idcf.jp/entry/etc/add_network/

で、今回は既存の環境から移設というところで構築したのですが、

色々な制限があり再設計する事になりました。

結論から言うと、追加ネットワークを使った設計をする時は、

実際に追加ネットワークをしてから設計するか、IPを柔軟に変更できる設計にしておくと良いです。

例えばDBと接続する際にIP指定で許可している場合、許可設定の変更をしたり、

そもそもDBのIPが変更しなければならない可能性があります。

同じハマり方をしないようにご注意というところで。

１．システム予約IPがある

後方20個のIPはシステム予約として使用出来ないIPになっています。

例えば、デフォルトで以下NWが指定されます。（もちろん変更可能）

192.168.0.0/21

上記のうち、192.168.7.235～254はシステムで予約して使用不可能になっています。

従って、後方20IPを使用したIP設計は見直しになります。

２．CIDRが/24～/21のみ

CIDRは/24～/21でしか使用できません。/25、/26のNWは作れません。

従って、/24よりも分割されたNWは設計見直しになります。

３．仮想ルーターにIPが自動で採番される

仮想ルーターにIPが自動で採番されます。これはシステム予約IPに含まれていません。

例えば、192.168.0.0/21のNWで構築した場合、どこに採番されるか解りません。

基本的には192.168.0.1が使用されるようですが、2や3が採番される可能性もあります。

仮想ルーターのIPは使用出来ないので、こちらも被った場合は設計見直しになります。

ご察しの通り、３に見事にはまりまして。

移設前はWebサーバーを192.168.0.1に割り振っていたのですが、

移設したところ仮想ルーターに192.168.0.1を取られてしまい採番出来なくなりました。

今回はteslaからnewtonへのゾーン間移設だったのですが、

移設前と移設後で仮想ルーターのIPが変わった為、このようなハマり方をした次第です。

もし、セキュリティ的にもしばりが無いようであれば、

192.168.0.0/24のNWを作る場合、

192.168.0.0/23のNWを作って、192.168.1.1～254の範囲でIP設計をすると良いと思います。

どうしても/24で作成する場合、念のため、192.168.0.1～10は使用しない等で回避が出来るかと思います。

ちなみに、NICは追加/削除をしていくとデバイス名が変わります。

CentOS7であればさほど困らないかもしれませんが、、

参考： https://www.faq.idcf.jp/app/answers/detail/a_id/569/~/%E8%BF%BD%E5%8A%A0nic%E3%81%AE%E8%A8%AD%E5%AE%9A%E4%BE%8B%EF%BC%88centos7%E7%B3%BB%E3%81%AE%E5%A0%B4%E5%90%88%EF%BC%89

CentOS6系でNICを追加/削除してeth1のつもりがeth2や3になってeth1に戻したいという場合、

udevを修正する事で変更する事が可能です。

以下ファイルにNICの情報が記載されています。

/etc/udev/rules.d/70-persistent-net.rules

上記ファイルで不要なNIC情報を削除し、最後に割り当てられているNICのnameをeth1にします。

udev rulesの反映を行う為に以下コマンドを実行します。

start_udev

これでeth1に戻ります。

あまり使う機会は無いと思いますが。。

それではよいクラウド構築を！

登録: 投稿 (Atom)