忍者ブログ
  ちゃんとカテゴリ分けされておりませんので、 記事をお探しならブログ内検索が便利です。 ご活用くださいませー+.(≧∀≦)゚+.゚
Admin*Write*Comment
[1]  [2]  [3]  [4]  [5]  [6]  [7]  [8

WEB+DB PRESSという書籍を社内で購読しているのですが、
そこにPHPの実行環境を切り替える記事がありまして、
エンジニアの一人が導入できないって?っていうから
トライしてみました。

便利は便利なんですけど、これはネックになるかな?って思ったのが
  1. ApacheのLoadModuleを逐一手動で切り替える必要がある
  2. phpbrew自体PHPでできている
1.はconf.dなどで切り出して差し替えるなどしてほしかったなー★
モジュール先をシンボリックにしても大丈夫そうなのに…
2.はきついですね。。。
システム要件にphp5.3とあるので、5.3がデフォルトで入る環境でないと
結局自分でphpをコンパイルして導入することになるので、
その程度の知識があればphpbrewなんかなくても運用できそうだし、、、
phpbew自体がPHPってことはphpbrewでphpを切り替えると、
切り替えた後のPHPでphpbrewを動作させることになるので、
ドツボにはまることがあります。
※たとえば --oldオプションなどでphp5.1.6とか導入した場合
個人の意見としてはすごいナンセンスだと思います。。。

なにはともあれ、下記に導入した手順を載せておきまーす
# apache & mysql は導入済みが前提
# もし新規のサーバに入れるなら下記コマンドを実行するの
yum -y install httpd httpd-devel mysql mysql-server mysql-devel

# 依存パッケージのインストール
# 切り替えに使用するPHPはコンパイルして導入するみたいなので
# コンパイルに必要なモジュールをインストールしておきます
yum -y install gcc gcc-c++
yum -y install libxml2-devel
yum -y install bzip2-devel
yum -y install openssl-devel
yum -y install readline-devel
yum -y install libxslt libxslt-devel
yum -y install bison
yum -y install libtool-ltdl-devel
yum -y install libicu-devel
yum -y install flex
yum -y install patch
rpm -Uvh 'http://elders.princeton.edu/data/puias/unsupported/6/x86_64/libmcrypt-2.5.8-9.puias6.x86_64.rpm'
rpm -Uvh 'http://elders.princeton.edu/data/puias/unsupported/6/x86_64/libmcrypt-devel-2.5.8-9.puias6.x86_64.rpm'
rpm -Uvh 'http://apt.sw.be/redhat/el6/en/x86_64/rpmforge/RPMS/mhash-0.9.9-1.el6.rf.x86_64.rpm'
rpm -Uvh 'http://apt.sw.be/redhat/el6/en/x86_64/rpmforge/RPMS/mhash-devel-0.9.9-1.el6.rf.x86_64.rpm'

# wget のインストール
# 本家手順ではcurlを使用しているのですが、なぜかダウンロードができないので…
yum -y install wget
cd /usr/local/src

# PHP5.3に依存するみたい
# https://github.com/c9s/phpbrew/wiki/Requirement
# なのでここで5.3を入れてしまいましょう
cd /usr/local/src
test -f ./php-5.3.28.tar.gz || \
  wget 'http://jp1.php.net/get/php-5.3.28.tar.gz/from/this/mirror' -O ./php-5.3.28.tar.gz
test -d ./php-5.3.28 && \rm -rf ./php-5.3.28
tar zxf php-5.3.28.tar.gz
cd php-5.3.28
./configure \
  --prefix=/usr/local/php \
  --with-zlib \
  && \
  make -j2 && \
  make install
export PATH="${PATH}:/usr/local/php/bin"
# ==> PHP 5.3.28 (cli)
php -v 

# phpbrew のインストール
cd /usr/local/src
test -f phpbrew || \
  wget 'https://raw.github.com/c9s/phpbrew/master/phpbrew'
\cp ./phpbrew /usr/local/bin/phpbrew
chmod +x /usr/local/bin/phpbrew

# phpbrewの初期設定
/usr/local/php/bin/php /usr/local/bin/phpbrew init
if grep -q 'source ~/.phpbrew/bashrc' ~/.bashrc
then
  echo 'skip'
else
  echo 'source ~/.phpbrew/bashrc' >> ~/.bashrc
  echo 'export PATH="${PATH}:/usr/local/php/bin"' >> ~/.bashrc
  source ~/.bashrc
fi

# インストールできるphpのバージョン一覧
phpbrew known
# コンパイルオプションの一覧
phpbrew variants

# 複数バージョンのインストール
phpbrew install 5.5.12 +default +mysql +mb +ftp +apxs2
phpbrew install 5.4.28 +default +mysql +mb +ftp +apxs2
phpbrew install 5.3.27 +default +mysql +mb +ftp +apxs2 +intl


# 異なるバージョンへの切り替え
phpbrew switch php-5.5.12
php -v
phpbrew switch php-5.4.28
php -v
phpbrew switch php-5.3.27
php -v

# 切り替え環境の終了(元のPHPに戻る)
/usr/local/php/bin/php /usr/local/bin/phpbrew switch-off


# アンインストーる
\rm -rf ~/.phpbrew
\rm -f /usr/local/bin/phpbrew
実行環境
Scientific Linux6.4 (minimal)

参考サイト
https://github.com/c9s/phpbrew
https://github.com/c9s/phpbrew/issues/167
http://blog.mktime.com/archive/290.html
http://d.hatena.ne.jp/donbulinux/20091217/1261049589
http://hack.aipo.com/archives/324/
http://www.stuartmacfarlane.co.uk/configure-error-unable-to-detect-icu-prefix-or-no-failed-please-verify-icu-install-prefix-and-make-sure-icu-config-works

拍手

PR



あたしとしては珍しくsqlite3を使ってみようと思い立ったのですb
Windows環境だし、そんなに複雑なトランザクションも必要ないし、ってところでー♪

と息巻いてみたもののいきなりエラーにあたる…

OperationalError: unable to open database file

なぜに開けなし!! <( ̄□ ̄;)>
ググっても、パスが間違っているか、書き込み権限系ばかり。。。
さんざん迷いに迷って、たどり着いたのが…
パスにマルチバイトを含んでいたからでした。。。
非常にお粗末・・・ぐぅ

と、いうことで
sqlite3.connect() の引数はユニコードで渡そうねって話でした。

実行環境
Windows7 6.1.7601 Service Pack 1 ビルド 7601
sqlite3 2.6.0
Python2.7.3

参考サイト
http://d.hatena.ne.jp/dayflower/20070123/1169546863
http://php-sql-gdgd.jugem.jp/?eid=60

拍手




pg_dumpの分割 でも触れましたが、DBのダンプファイルをダンプの時点で分割しておかないとリストアの時結構大変です。
それでも1ファイルでダンプしちゃったなら、前述の方法などで分割するしかないですが、できることならダンプの時点でテーブルごとに分かれているのが理想です。
pg_dumpのオプションでなんとかなればいいのですが、3流エンジニアにはドキュメントを理解する能力がありませんでした。。。
ということで仕方ないので、例によってpythonスクリプトでダンプするためのShellスクリプトを作成し、実行することでテーブルごとにダンプファイルを作成するための簡単なものを作成しました。


python

db_name = 'db_name' 
output_path = './db_dump'
gzip = False

import subprocess
import os
os.mkdir(output_path)

if gzip:
  out_cmd = 'gzip --best -c'
  ext = '.dmp.gz'
else:
  out_cmd = 'cat'
  ext = '.dmp'

cmd = ['echo', r'\dt']
sp = subprocess.Popen(cmd, stdout=subprocess.PIPE)
cmd = ['psql', db_name, '-t']
tp = subprocess.Popen(cmd, stdin=sp.stdout, stdout=subprocess.PIPE)

open('pg_dump.sh', 'wb').write('') # initialyze
for line in tp.stdout:
  if not line.strip():  continue
  table_name = line.split('|')[1].strip()
  cmd_line = 'pg_dump {0} -t {2} | {3} > {1}/{0}_{2}{4}\n'.format(
                                                              db_name,
                                                              output_path,
                                                              table_name,
                                                              out_cmd,
                                                              ext
                                                            )
  open('pg_dump.sh', 'ab').write(cmd_line)

exit()

# The shell script from here.
sh -x ./pg_dump.sh

確認環境
Python 2.7.3
PostgreSQL 9.3.0

検索タグ
python, postgresql

拍手




またまた唐突にtorをインストールしてくれと言われました。。。
会社として本当にそんなツールを使うのだったら、ダメだと思うの。。。
まぁ、用途は(あたしは)きいてませんしー
聞かない聞かない
見なかったことにするのはこの業界で生き残る技術よ♡

rpm -qi wget || \
  yum -y install wget
rpm -qi automake || \
  yum -y install automake
rpm -qi make || \
  yum -y install make
rpm -qi gcc-c++ || \
  yum -y install gcc-c++
rpm -qi libevent-devel || \
  yum -y install libevent-devel
rpm -qi openssl-devel || \
  yum -y install openssl-devel
rpm -qi php || \
  yum -y install php

cd /tmp
test -f tor.tgz ||
wget 'https://gitweb.torproject.org/tor.git/snapshot/c0441cca8b483882f5676b98081f0fe4b52d3ae1.tar.gz' -O tor.tgz 
tar zxf tor.tgz
cd tor-*/

./autogen.sh && \
./configure --prefix=/usr/local/tor --disable-asciidoc && \
make clean && \
make -j2 && \
make install

mkdir -p /usr/local/tor/var/{log,tmp,run}

php -r ' 
$conf = "";
$ip = "0.0.0.0";
$conf .= sprintf("SocksPort %s:9100\n", $ip);
$conf .= "Log notice file /usr/local/tor/var/log/notices.log\n";
file_get_contents("/usr/local/tor/etc/torrc", $conf);
'

# 起動
cd /usr/local/tor/var/tmp
nohup /usr/local/tor/bin/tor -f /usr/local/tor/etc/torrc &
_pid=$!
cd /usr/local/tor/var/run
echo -n ${_pid} > tor.pid

# 停止
cat /usr/local/tor/var/run/tor.pid | xargs kill

# 確認
php -r ' 
$ch = curl_init ();
curl_setopt ($ch, CURLOPT_URL, "http://taruo.net/e/");
curl_setopt ($ch, CURLOPT_TIMEOUT, 60);
curl_setopt ($ch, CURLOPT_PROXY, "127.0.0.1:9100");
curl_setopt ($ch, CURLOPT_PROXYTYPE, CURLPROXY_SOCKS5);
curl_setopt ($ch, CURLOPT_RETURNTRANSFER, TRUE);
curl_setopt ($ch, CURLOPT_FAILONERROR, true);
curl_setopt ($ch, CURLOPT_FOLLOWLOCATION, 1);
$result = curl_exec($ch);
print curl_errno ($ch);
print strip_tags($result);
curl_close ($ch); 
' | grep -A1 -e REMOTE_HOST -e REMOTE_ADDR

さんざんPHPとかねじ込んできた割に、最後はgrepというのがあたしらしいわねー
でわでわ

拍手




Linux上で作業していた時に表計算ソフトからDBにつなげたらいいなーって思ったら案外簡単にできるようでした。

http://superuser.com/questions/391242/how-do-i-connect-to-a-postgresql-server-using-libreoffice-base

今回はPostgreSQLの場合です。

Version
Calc:4.2.0.4 (en version)
Postgres: 9.2.4(source compile)

拍手




完全によそ様の引用です ( ̄▽ ̄;)
Python2.7.3で確認済み

colors = {
    'clear': '\033[0m',
    'black': '\033[30m',
    'red': '\033[31m',
    'green': '\033[32m',
    'yellow': '\033[33m',
    'blue': '\033[34m',
    'purple': '\033[35m',
    'cyan': '\033[36m',
    'white': '\033[37m'
}
for k, v in colors.iteritems():
    print '%s%s' % (v, k)

参考元:
http://d.hatena.ne.jp/heavenshell/20090909/1252509749

拍手




MySQLの場合、MASTER側でエラーが起きるようなSQLを発行してもSLAVE側にそのSQLが流れてしまう場合があり、SLAVEで実行した際に同じようにエラーになり、止まってしまうことがあるようです。
原因は多々あると思いますが、現在止まっているSQLを無視して問題ないと判断できる場合はそのSQLの実行をスキップして次に進めることができるみたいです。
その対処方法の備忘録です。

-- 現在のSLAVEの稼働状況を確認
SHOW SLAVE STATUS \G
-- 厳密には停止の必要はないけれどここではSLAVEの機能そのものをいったん再起動します
STOP SLAVE;
-- 現在出ているエラーをスキップします
SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
-- SLAVE(レプリケーション)を再開します
START SLAVE ;
-- 少し待ちます
SELECT SLEEP(2);
-- 再度SLAVEの稼働状況を確認します
SHOW SLAVE STATUS \G

拍手




postgresql は普段あまり使わないDBなのでついついスキーマ変更用のSQLを忘れてしまいますね。゚・(>Д<)・゚。

ということで備忘録。
postgresql 9.2 の場合です。
8とか7はおそらく違います。


ALTER TABLE table_name ALTER COLUMN column_name
  SET
    DATA TYPE data_type;


table_name:  対象のテーブル名
column_name: スキーマ変更対象のカラム名
data_type: 新しいスキーマ
 ex.)
 varchar(255)
 bigint


http://www.postgresql.jp/document/9.2/html/sql-altertable.html


14.10.27 追記
スキーマ長を増やすだけ(型は変えずに長さだけ変える場合)とは違い、型そのものを変更する場合は失敗する場合が多々あります。
例えば元のカラムがvarchar(10)で、integer(10)に変更を試みようとした場合でも、カラムの中には一見数字しか見えなくても型変換に失敗し、変更できないことがあります。
その場合はUSINGを使用して、元のデータと後のデータを指定してあげることで解決が可能です。
例を記載します。

ALTER TABLE table_name ALTER COLUMN available 
SET
  DATA TYPE BOOLEAN
    USING CASE
      WHEN available = 1
      THEN TRUE
      WHEN available = 2
      THEN FALSE
      END;



それでも失敗する場合は、INDEXをいったん削除しましょう。

拍手




現場でFacebookのデータをAPIで引っ張れないか?
という要件をいただきました。
わたし、、、Facebookに興味ないんですけど。。。

まぁ、そこはかとなく、仕事とプライベートってところでいざ調査開始 。+.。ヽ(*>∀<*)ノ。.+。キャハッ

簡単にわかったこととしては
https://graph.facebook.com
にアクセスするだけでJson形式のデータが返されるってことかな?

https://graph.facebook.com/[ユーザ名]
でそのユーザの何かが取れます (*´-ω・)ン?

ここまで書いて面倒になっちゃったので参考になるURLを記載しちゃいます(。-人-。)

http://facebook-docs.oklahome.net/archives/51906043.html
https://developers.facebook.com/blog/post/498/

ではでは (`-ェ´-、)ノ

拍手




ApacheのRewriteLogについて、デベロッパーの皆さんの情報を集めていたのですが、どうにもうまくいかない。
と、いうことでちゃんとした本家のドキュメントを見てみました。

http://httpd.apache.org/docs/

どうやら2.0系&2.2系と2.4系では記述の仕方が変わっていたようです。

2.0
2.2
2.4

Apacheは英語サイトでも比較的わかりやすいですし、やはり本家が一番ですね・・・

---- Sample ----

☆2.2系
# Log to a file:
RewriteLog "/usr/local/var/apache/logs/rewrite.log"

# Log to a pipe:
RewriteLog "|/path/to/parser.pl"

# output level
RewriteLogLevel 3

☆2.4系
LogLevel alert rewrite:trace3



====補足====
2.0系2.2系ではLogの出力レベルを0~9の10段階で指定が可能。
0ではまったく出力されず、9ではかなり冗長的なLogになります。
でもぶっちゃけ3以上はかなり冗長です。

2.4系では行末付近のtrace3の3を変更することで出力を制御できます。
minは未確認ですが、maxは8です。
そして出力先は選べないようで[error_log]に集約されるようです。
もちろんVirtualHostなどをきっていればそちらのLogに吐かれます。

共通していえるのは.htaccessで制御できず、Apacheの再起動が必要になるため、レンタルサーバではきつそうだということです。

----End----

拍手



ブログ内検索
カレンダー
01 2018/02 03
S M T W T F S
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28
カウンター
最新コメント
最新トラックバック
プロフィール
+ハンドル+
y_ayamori(purple)
+職業+
IT系エンジニア
+すまい+
さいたま
バーコード
ブログパーツ
アバター
Copyright © アナログを愛するデジタル生活館 All Rights Reserved.
photo by Kun material by Atelier Black/White Template by Kaie
忍者ブログ [PR]