ブログ移設しました。

bloggerから記事を移設しました。


HUGOで記事を書いてみると思いのほか書きやすかったので移動。

金曜日, 5月 22, 2015

俺のためじゃない。pythoniaのため

履歴として

検証環境：docker

[root@6f9b1cb04894 ~]# cat /etc/redhat-release 

CentOS release 5.11 (Final)

package

yum -y install zlib-devel openssl-devel readline-devel ncurses-devel sqlite-devel expat-devel bzip2-devel tcl-devel tk-devel gdbm-devel  unzip 

python 2.7.9

wget https://www.python.org/ftp/python/2.7.9/Python-2.7.9.tgz
cd Python 2.7.9
tar xvzf Python-2.7.9.tgz 
./configure --prefix=/usr/local/python2.7.9 --enable-shared --with-threads  && make && make install

shared lib

vi /etc/ld.so.conf
/usr/local/python2.7.9/lib
ldconfig

vim .bashrc
export PATH=/usr/local/python2.7.9/bin:$PATH

distribute-0.7.3(easy_install)

wget --no-check-certificate https://pypi.python.org/packages/source/d/distribute/distribute-0.7.3.zip#md5=c6c59594a7b180af57af8a0cc0cf5b4a
unzip distribute-0.7.3.zip 
cd distribute-0.7.3
python setup.py install 

s3cmd

wget http://downloads.sourceforge.net/project/s3tools/s3cmd/1.5.2/s3cmd-1.5.2.tar.gz?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fs3tools%2Ffiles%2Fs3cmd%2F1.5.2%2F&ts=1432226044&use_mirror=jaist
tar xvzf s3cmd-1.5.2.tar.gz 
cd s3cmd-1.5.2
python setup.py install 

 あとがき、いろいろ追っていると、pythonが少しかわいそうな境遇。
perl5.xと似た匂いもあるけど、そんなんんじゃなくて、出ても、Python3系を使わないぞ！そんな記事を見たとき、少し落胆した。

 Google Appe Engineってその辺どうなんかねー。
前に使ったとき2.7系だったの覚えてる。
投稿者 時刻: 0 件のコメント:
ラベル: , ,

火曜日, 5月 19, 2015

仮想化技術について

Dockerなる仮想化について調べていると、最初は、ハイパーバイザー+chef？とかそういう印象を受けました。

しかし、調べていくうちにこれってjailやchroot（使ったことないけど）に似ていないか？そんな気持ちで仮想化技術のことを帰り道調べてました。

知らぬはエンジニアの恥。今さら聞けない【コンテナ/仮想化技術】11選 - paiza開発日誌 : http://paiza.hatenablog.com/entry/2014/10/21/%E7%9F%A5%E3%82%89%E3%81%AC%E3%81%AF%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E6%81%A5%E3%80%82%E4%BB%8A%E3%81%95%E3%82%89%E8%81%9E%E3%81%91%E3%81%AA%E3%81%84%E3%80%90%E3%82%B3%E3%83%B3

今更聞けないか。。。

結構みかけた、使った技術が多いですね。
さて、この記事でも書かれているように、Dockerってchroot型なんですね。

ただ、chrootだけでは実現できない機能もあるので、chrootで我慢できないなら、dockerでいいのかな？と思います。

BSDの兄貴がまえからDockerなんてできとったわい！とか、cgroupsについて書かれていたのがあったのでぺたり。
コンテナの歴史と Linux カーネルのコンテナ関連機能についての割とどうでも良い愚痴 - TenForwardの日記 : http://d.hatena.ne.jp/defiant/20141218/1418860851

BSDの兄貴、ここでも2000年は輝きまくってる。（とはいえ、BSDなひとは「FreeBSD bhyve」が登場したのはうれしいかぎりなのかな？）

んで、どれ使う？

どことは言わない、Windowsで使いそうなもの:VirtualBox
俺しか使わない、速度を上げたい:kvm

まだやりきっていないけど、こうしたい。
VMイメージ製造機:vagrant
ホストOSでリソースを極力削って運用したいもの:Docker
chefをお供に(Dockerでも)

かな。

今のマシンにxenいれて慣れるのも面倒だし。
Xenの基本 – ドメイン0とドメインU | OpenGroove : http://open-groove.net/xen/domain0-domainu/
投稿者 時刻: 0 件のコメント:
ラベル: ,

まぁ、リバースプロキシやるよ。

夢を見ていた。
1IP<=>multi domainって、さくっとリバースプロキシやらなくてもいいんじゃない？
もしかしたら、いけんじゃね？とか思っていましたが、出来なかったんで、リバースプロキシにしたよって話を書きます。

この記事でやりたいこと

multi domain<=>1IPをやりたい。
外部のサブドメイン（そのマシンに対してのトップドメイン、サブドメインは*の状態）で仮想マシンに対して通信をさせるようにしたい。(httpd,sshなどなど
前に血迷った記事書いた。あれはあれで別の方向で育てる。

とある面倒な事

なんか、開発しててこんなことがあったりしますね。
  1. 開発・検証環境あげないと、アプリでは確認できない。
    1. ローカルに対してドメインでアクセスできないから。
    2. virtualhostで開発PCではhostsとかに書いて名前解決できているけど、スマフォには適用させることができないから。
自社内に、DNSサーバーを持っている　かつ　DNSに対して変更を加えるのが容易ならいいかもしれませんね。
開発環境は外に持っていなくてもいいと一つ経費かかるのが減りますし。

本音は自分で触るサーバーがあるので、その辺を整える時に一つしかIP持っていないけど、アクセスする時にはFQDNでアクセスしたい。

そんな時は、Http reverse proxyですぞ。

構成的には、

こんな感じ。

環境を作っていくぞ。

https://gist.github.com/tluna/75b8fcb89ff437036e82#file-1
こんな感じ。

各々rails入れていくぞ。

reverse proxyを設定するぞい。

https://gist.github.com/tluna/75b8fcb89ff437036e82#file-3-reverse-proxy

あとは、ホストPCからアクセスできるか確認、あれ？繋がらないを繰り返しましょう。　原因は、だいたい凡ミスです。
これで、VM上のサービスをいつでもみれるね。よかったね。。。
DNSがいじれるなら、欲しいだけ、ドメインを切るが良いさ。
ただ、上記の設定は問題がありますね。

  1. 静的ファイルをスクリプトファイル側が管理しないといけない。
    1. んー。VMじゃなかったら、これは、staticなパスをきればいいけど、VMだったら、このまま？それとも、追加で各々にnginxまたいれるの？（いやかな。）
  2. 4xx,5xxのページを用意していない。
    1. さくっと用意できるならすれば良い。
代わりに良い点としては、
  1. 簡単なLBが作れちゃう。
    1. 検証していないけどな！
    2. http://ameblo.jp/yuu-sys-guard/entry-11873359237.html
  2. 大変なコンパイル作業とapacheからの解放。
    1. 個人的にこれがでかいかな。
  3. バックエンド側は種類が豊富。
    1. 楽しい楽しい選定タイム。
まだ重たくて重たくて仕方がない、LBをこさえるか。なんて状態になったことがないですし、そういうのは用意されていることが大半なので、まぁ、開発だけかな。これ。


あとがき：
これを書き始めたときにopenflowの構築に足を突っ込んだ（昨日）。　これはこれで面白いと思ったので、今度はvmをちゃんと用意してその中でopenflowしたいかな。
投稿者 時刻: 0 件のコメント:
ラベル: ,

火曜日, 5月 12, 2015

daemontoolsを入れる。

小ネタです。

centosにdaemontoolsを入れたいと思った(perl関連)

daemontoolsは要はデーモン化してくれるやつだ。(監視もね。)

https://github.com/kteru/daemontools-rpm

こんなのを公開してくれている人がいる。　使わない手はない。

buildrpm.shを叩く時には、rootで(rpmbuildのインストール先はrootじゃないと書き込みできないところなんでね）
といいたいところだけど、この点を考えてくれよな！
http://blog.tnmt.info/2011/04/29/rpmbuild-for-beginner/

[root@tluna x86_64]# pwd 

/root/rpmbuild/RPMS/x86_64

上記ディレクトリに入れてくれます。(64bit)
投稿者 時刻: 0 件のコメント:
ラベル:

水曜日, 5月 06, 2015

openssl更新後、パッケージとの共存

現在想定しているパッケージのうち、opensslを利用しているじゃね？と思って調べてみた状況は以下の通り。
  • openssl
    • さて、これはどうしてやろうか。そのまま入れ替えてしまえ
  • openssh(
    • ibcryptoだけじゃね？
  • perl
    • やべー、みあたらねぇ。
  • php
    • パスをコンパイル時点で指定してるんじゃ => 要再ビルド？
  • httpd
    • mod_sslで使っている。きっと、シンボリックリンクだけでいいはず？　エラーが出たらビルドしなおす。

がありますね。

前回はパッケージを使ってインストールすると、どういう風にプログラム側からopensslを欲しているかを確認しました。

一部わからないものがありましたが、それに関してはこのopenssl適用作業実施時にエラーなりが出た時に分析と対処によってはっきりさせていきたいです。

linuxをちゃんと理解して、opensslのライブラリを参照している人たちがどういう風に参照しているかを知っていれば問題ないのでしょうが、残念ながらopensslに依存しているぞ！っていうパッケージがあまりにも多すぎる。

そして、面倒になったので、CentOSだけにします。
もしかしたら、Debianもあとあと書くかもしれません。

OpenSSL入れ替え

openssl本体

https://gist.github.com/tluna/1d4df2d4da86fd1d0180#file-centos-change-openssl

opensslのso達

単にmoduleを入れ替えるだけではだめ。
もしかして、srpmとか見たら、専用のパッチとか当たってたりするのかな。(versionに関しては明示するようにしても、エラーになるし）

影響を受けて、wget, ssh sshd perl phpが全滅というお粗末さ。（phpは仕方がないにしてもよ。)

ものすごい時間かかってますね。これ。

引き続きしらべるけども。(virtualboxに引きずられてMacごと強制終了されちゃっているっぽい現象が)

あー。。。。仮説だけど、それぞれのプログラムってddlのバージョンが1.0.1eであることを期待してたり、、、する？
と思って色々やってみたけど、以下の原因でだめ

試してみたのは、openssl1.0.1e openssl1.0.1m ともにsoファイルにバージョン情報の付与をするかのオプションを追加。追加なしのパターンを用意

openssh

libcrypto.soでエラー(ssh/sshdともに)

httpd

libphp5.so,mod_ssl.soでそもそもsegmentation fault。。。。辛い。

php

version提示するようにしても、そんなバージョンしらんと言われる。

perl

通る。どっちでもOK

んー。srpmに入っていたパッチの中でバージョン情報に関するパッチを適用するとか、結構追って追ってしないとダメっぽい気がしてきた。

少し動的リンクについて見てみると、今のやり方では通らない気がしてきた。
 共有ライブラリーを解剖する http://ibm.co/1Ig3Jjv
投稿者 時刻: 0 件のコメント:
ラベル:

perl php httpdのopensslの利用(パッケージ)

一旦、まずは、使ってきそうなperl,php,httpdの関連パッケージをインストールしていく。

パッケージインストール

perl(どっちももうはいっているはず) php httpdなどをインストール
環境構築のため、cpanmをwget後、以下の作業を実施。　ここは、各ディストリ共通。
環境変数
モジュールインストール
んで、リクエストを送ってみる。

Apache

ごめん、この辺ログに残していなかったので、CentOSとDebianに分けてやったことを列挙

CentOS

確か、
  • サーバーのオレオレ証明書を発行（これは不要かも。）
  • mod_sslインストール後に自動的にhttpsの設定有効になっていたと思う。
  • service httpd restart 

Debian

  • a2enmod ssl
  • a2ensite default-ssl
  • service httpd restart 
こんな感じ。
こういうときに思うのだけど、debianの方がこういうところ洗練されている感じがします。(CentOSが洗練されているのは、きっと、RPMだけじゃないか？と思っている今日この頃。)


確認していく

さて、一通りパッケージインストールで作成できましたね。

各言語、及びhttpdのモジュールからopensslがどういう風にリンクされているかを見ていきましょう。

PHP

どうもSharedObjectファイルが見当たらないので、php自体に組み込み？
centosはphp -iでコンパイル時にopensslの場所を指定してることはわかったのだけど。
libssl.soへのリンクあり
curl.soにはリンクあるなぁ。

perl

Net::SSLeayでリンクされているSO発見。
libssl.soへのリンクあり
CentOS
Debian

Apache

libssl.soへのリンクあり
CentOS
Debian

openssh(sshd)

CentOS
Debian
https://gist.github.com/tluna/61f495ebfeaf16c99ba6#file-debian-sshd

前に書いた「他のプログラムから色々依存関係があるから」っていう理由で、差し替えるだけですむものはいいですが、そうじゃないコンパイルオプション時点で決まってしまうものについては、更新しても新しいものを見てくれそうにないですね。

その辺を次記事で書いていきますか。。。（メンドクセェなこれ）
投稿者 時刻: 0 件のコメント:
ラベル:

月曜日, 5月 04, 2015

opensslのインストール

opensslのインストールについて書いていきますか。

そもそも、opensslって各ディストリでは、ランタイムとdevelみたいなのがあって、ライブラリの組み込みがないのであれば、develは必要ないのかなと思っています。

さて、そんなわけで、debianとcentosのパッケージから見ていきましょう。

はじめに

検証用のvmを作成するので、vagrantでどんどん作っていきましょう。
mkdir -p openssl/centos
mkdir -p openssl/debian
cd openssl/centos
vagrant init centos6.64
cd ../debian
vagrant init debian7.8.64

これで二つのOSのVMができたので、確認をしていきましょう。。。

vagrantで接続する時には、sshで接続するので、ダメですね。
一度作成した後は、Virtualboxのコンソール画面でopenssl削除してから作業開始ですね。

と、アンインストールを試してみたいと思ったのですが、色々なライブラリから呼ばれて強制削除じゃないとダメみたいですね。

そしたら、各インストールされるファイルを確認しますか。

パッケージで何が入るのか。

openssl-develもインストールして一緒に確認して。(もう利用している環境で入れているわけではないなら、ちゃんとrpmファイルをダウンロードして確認ね？)
これだけはいるんだね。
https://gist.github.com/tluna/26eccbc8d248dc076e71

んー、予想外なのはファイル名的にopensslとdevの関係にあるパッケージがどうも同期を取ろうとは思っていない感じがすることですね。

さて、これらのファイルに上書きするようにインストールをしないようにしなきゃなね。（切り戻しをパス変更だけでできるように）

ソースインストール

さて、 今度はソースインストールするとどう配置されるか。ですね。　念のため、各ディストリごとに見ていきますか。

1.0.1系だと勝手に決めつけて作業を進めます。
wget https://www.openssl.org/source/openssl-1.0.1m.tar.gz
tar xvzf openssl-1.0.1m.tar.gz
cd openssl-1.0.1m.tar.gz
だめだ。vimとタイポするので、vimいれよ。


はいってるよね。
  * make
  * Perl 5
  * an ANSI C compiler
  * a development environment in form of development libraries and C
    header files
  * a supported Unix operating system

CentOS

んー、ディストリのビルドオプションがわからないですね。 centosのsrpm持ってきて中身を見るか。

srpm展開して、その中のtar.gxを展開したら予想だにしないオプションの列挙が。


だんだん頭が痛くなってきた。 no-sharedな訳ないでしょ。
実はインストール時点で./Configureしているのかしら。 とおもったら、srpmはspecファイルでしたね。


結構色々なオプションを定義しているのね。

Debian

やばい。srpmみたいなのあるのかしら。どう考えてもなさそうだ。　その中放浪していると、openssl version -a でコンパイルオプションまで見れるんだね。

centosとdebianを比較してみるとコンパイルオプションに差があるのがきになりますけど。

https://gist.github.com/tluna/a9a9a3869e21a2f5f9b1

とりあえず、インストールしてみてprefix以外のところにファイルが配置されないか、確認しますか

インストール前後でファイルの一覧差分を確認しましたが、prefix以外だとopensslのソースディレクトリで差分があるくらいで、インストールの切り戻しは容易だね。
アンインストールもprefix指定のディレクトリを削除するだけでOKということの確認も取れたわけだ。

debianとcentosも同一オプションにしたいな。（めんどいので）
なので、両方の差分をとってコレっぽいと思ったのを使うとに。
https://gist.github.com/tluna/a9a9a3869e21a2f5f9b1#file-centos-sourceinstall-configure-option

インストールの結果はあとあとしかわかんないので、この記事はここまで。次の調査にうつる。
make testでこけるので、オプションを--prefix以外削除。　ocnfigureの段階で自動的につけてくれるオプションもあるはずなので、それで進めてみる。
投稿者 時刻: 0 件のコメント:
ラベル: , ,

日曜日, 5月 03, 2015

OpenSSLビルド・影響範囲調査

どうも。またまた環境周りのことで対処が速攻決断できない事象があったので、一度自分で実践と調査することに。

先に結論

現在opensslをソースインストールあと、lib64でlibssl.so、libcrypt.soを入れ替えて試してみましたが、パッケージでいれたものは、perl以外成功にはならず。
なので、そのままでもいける方法が見つからないのであれば、既存のライブラリを残したまま、opensslを別でコンパイルして、LD_LIBRALY_PATHに追加して、各プログラムをソースコンパイルですかね。。。
何かわかったら、更新します。　知っている方いらっしゃいましたら、ご教示願います。。。

きっかけ

perl周りで複数のDB繋いで遊ぶみたいなことをやってたんだけど、そこのエントリーは、また次にする。。。

んで、OpenSSLってなんでいきなり話題にあがったかというと、
話としてはこの辺がトリガー

CVE-2015-0291のほうがすごい深刻な問題だと感じたけど、CVE-2015-0204のほうだけ対応できればいいということが判明。
そうなると外部通信時にデータ抜かれるだけっぽいし、まぁいいかな？と思ったけど、そういうわけにもいかないので、調べてみることに。

 そもそも、OpenSSLってライブラリとして利用しているものが多すぎて影響範囲がわかんねぇよ。ってところからのスタートです。
※今回の話は影響調査〜構築までとなりそうなので、以下のシリーズの７〜20までは読んでないと意味わからないかもね。
http://www.atmarkit.co.jp/ait/kw/buildlamp.html

 恥ずかしながら、知らないことばかりでした。

 さて、話を戻すと、OpenSSLで私が使っている中で影響を受けそうなのは、
  • webサーバー
  • php,perlなどのプログラミング言語（外部通信するなら）
  • sshd, ssh, wget, curl,etc
  • RDBMS(ビルドオプション次第かな。)
これらのプログラム、デーモンが影響を受けますね。
ただ、きになるのは、更新された後、そのまま動くんですか？　本当に新しくなったものを利用しているんですか？
ですね。

ソースで入れたのは各々で認識しているはずなので、それは置いといて、yum,aptで入れた人はどういう状態なのか確認しておくとしましょう。

vagrant box list 
centos6.64     (virtualbox, 0)
centos7.64     (virtualbox, 0)
debian7.8.64   (virtualbox, 0)

freebsd10.1.64 (virtualbox, 0)

perlでDB操作する時用にvagrantのboxは自作してあるので、この中からcentos6とdebian7.8で確認していくとしましょう。
freebsdは書いていくと説教されそうなのでやめとこう。

で、各々のものに関してはきっと確認していくポイントが違いそうなので、各々のページを作って後でまとめをこのページに書くかな。

基本的に作業ログに関しては全てgistに登録して、結果だけブログに記載するようにしたいです。

各プログラムの確認及び更新作業
なお、調査当初から見ていこうとしている順番が異なっています。
どうしても、公式パッケージ環境構築=>公式パッケージ環境確認=>opensslビルド=>適用作業＝>確認となるので、上記の順番に変更を行いました。

あっ、openssl周りでwindowsからssh系の作業ができるやつははサーバー云々とかとは別に新しいプログラムが出ているはずなので、ちゃんと更新してますよね？
彼らはきっとopensslについては静的リンクになっているか、opensslのライブラリがディレクトリ内にいるはずなので、ちゃんと更新しましょう
投稿者 時刻: 0 件のコメント:
ラベル:
登録: 投稿 (Atom)