ファイルの内容を8進数もしくは16進数で表示する。
参考:
[root@vmcent5 ~]# less a.txt
<?php
$i=”12″;
$k=intval($i);
?>
例1. 8進数で表示
[root@vmcent5 ~]# od a.txt
0000000 037474 064160 005160 022012 036551 030442 021062 005073
0000020 065444 064475 072156 060566 024154 064444 035451 037412
0000040 005076 000012
0000043
例2. 16進数表示
[root@vmcent5 ~]# od -tx a.txt
0000000 68703f3c 240a0a70 31223d69 0a3b2232
0000020 693d6b24 6176746e 6924286c 3f0a3b29
0000040 000a0a3e
0000043
例3. ASCII表示
[root@vmcent5 ~]# od -tc a.txt
0000000 < ? p h p \n \n $ i = “ 1 2 “ ; \n
0000020 $ k = i n t v a l ( $ i ) ; \n ?
0000040 > \n \n
0000043
新しくインストールしたマシン(FreeBSD)にcourier-imap 4.3.1をインストールしたときに設定ではまったので、自分用のメモとして残しておく。
courier-authlibの認証設定をおこない、Courier-imapに接続しようとすると次のエラーになる。
Account’s mailbox directory is not owned by the correct uid or gid
メーラから接続しても、手動で次のコマンドをたたいても同様。
telnet IP 143
0000 CAPABILITY
0001 LOGIN “ユーザ名” “パスワード”
いろいろ調べたところ、 Maildirのuidとgidが/etc/passwdと一致していないことが原因のようだ。
今まで特に気にせず正常動作しているサーバが何台かあるのだが、uidとgidが/etc/passwdと一致していたためエラーがでていなかったよう だ。今回はなぜか/etc/passwdに記載しているgidと、Maildirのgidが異なっていたためエラーになった。
結局 Maildir以下をchgrp して解決。
ちなみにソースコードではimapd.cのこのあたりでそのチェックを行っている。
if (atoi(p))
{
if ( buf.st_uid != geteuid() ||
buf.st_gid != getegid())
write_error_exit("Account's mailbox directory is not owned by the correct uid or gid");
}
No comments
FreeBSD5.5のサポートが2008年5月末で切れたので、5.5から6.3にアップしたの。作業内容を忘れないようにメモ。
バージョンアップの作業は、5.1->5.5のときと基本的に作業の流れは一緒。
まずは、HDDごとコピーをとって万一の場合のバックアップを作成。
次に/usr/src と /usr/ports を別ディレクトリに移動。
mv /usr/src /var/backup/src5.5
mv /usr/ports /var/backup/ports5.5
5.5から6系にあげる変更点として/etc/groupの追加があったので audit:*:77: を記述。
続いて /etc/fstab を開いてマウント情報をメモ。
これで準備ができたので、FreeBSD6.3のインストールCDからシステムを起動。
インストールを選択し、UPGRADEを選ぶ。
ディスクラベルエディタでmを押して各マウント位置を記入。(/etc/fatabのメモ)
続いて設定ファイルのバックアップ。/etcの内容をどこにバックアップしますか？と聞かれてデフォルト設定の/var/tmp/etc のままOKを押すと、次のエラーになった。
unable to backup your /etc/ into /var/tmp/etc. Do you want to continue anyway?
う～ん、なんでエラーになるのかわからない。。。
とりあえず/var/tmp/etc 配下をすべてrmして空っぽにしてから再度インストーラーを起動すると今度はうまくいった。原因はよくわからないがとりあえずよしとする。
6.3のカーネルコピー自体は１０分弱で完了。インストーラを終了する前に Alt+F4してコマンド入力画面にする。
#mergemaster を実行して /etc ファイルのマージ作業。
１ファイルずつ聞かれるので、途中から疲れてきて適当にマージした。
そして再起動すると….
エラーでうまく起動しない…. コマンドをたたけない….
/etcファイルのマージに失敗したようだ….
仕方ないので、バックアップディスクを利用して元の5.5の状態に戻し再チャレンジ。
6.3系のカーネルコピーが終わった段階で、今度はmergemasterを慎重に実施。
#mergemaster -siva して新ファイルがある場合は追加。
#mergemaster -sivr してマージする必要があるファイルはマージ。
これで再起動すると6.3系が起動した。
ただしPostgreSQLは起動に失敗。まぁ5.5から6.3にあげたのでライブラリがらみでアプリにエラーがでるのは予想していたので、PostgreSQLだけなら少ない方だ。apache,postfixが動いてくれたのは助かった。
#portupgrade -a
でソフトは全部バージョンアップで作り直し。(4,5時間かかった)
完了後システムを再起動。すると、PostgreSQLはまだエラー。
エラー内容を見るとsharedmemoryの容量が…とかいてある。設定ファイル(postgresql.conf)でshared_buffersを32MBから16MBに変更すると無事起動。なんだライブラリがらみのエラーではなかったのか…
これで完了かと他のソフトをチェックするとimapに接続できない。。。。どうも認証がらみで即切られている。なんだろう….
調べた結果、authdaemondが起動していないぽい。/etc/rc.confにcourier_authdaemond_enable=”YES”を記入して対処完了。いままでは書いてなくても起動していたのだが、バージョンアップで仕様が変わったのだろうか。。。
とりあえずバージョンアップ完了。まる１日作業だった。
No commentsxserver(s30)上でwordpress2.1系をEUCで動かしていたのだが、wordpress2.1系はメンテナンス中止とのことで2.2系にアップすることにした。しかし….. 2.2系はUTF-8しか対応していない。
どうするかしばらく悩んでいたのだが、なんとかUTF-8に文字コードを変換してバージョンアップすることができたのでここにメモしておく。
1. バックアップ取得
DBおよびファイルのバックアップを取得
2. DBの変換
基本はここをみた。
バックアップしたDBダンプ(この時点ではEUC-JP)をUTF-8に変換するphpmyadminのハックがxserver上でのやり方がわからず、 ここは自前サーバを用意しそこにphpmyadminをインストールした。
DBダンプを自前サーバにアップする。(その際にエラーがでるので次の処理をした)
・SET SQL_MODE=”NO_AUTO_VALUE_ON_ZERO”; の前に — をつけてコメントアウト
・wp_optionsテーブル中の rss_ で始まる行が文字化けしているので(ここだけUTF-8)、これらの行を削除。この削除によりinsert文の最後の行が変更になるので、 , を ; に書き換える。
これらの修正を入れた上で、phpmyadminのインポートで文字コードの変換なしに(EUC-JP)のままアップ。無事インポートに成功すればそのままエクスポート処理。その際に文字コードをUTF-8にする。
3. UTF-8に変換したSQLダンプをxserverにアップ
まずはSQLダンプの数か所の修正が必要。
・文字コードがUTF-8になったのでwp-optionsのblog_charsetの項目をEUC-JPからUTF-8に修正
・このままでは管理画面にアクセスするとあなたは権限がありませんみたいな表示になるので、wp_user_rolesを修正(これは漢字の文字コードがEUC-JPでは2バイトだったものがUTF-8では3バイトになることに起因している)
a:5:{s:13:”administrator”;a:2:{s:4:”name”;s:9:”管理人”;s:12:”capabilities”;a:47:{s:13:”switch_themes”;b:1;s:11:”edit_themes”;b:1;s:16:”activate_plugins”;b:1;s:12:”edit_plugins”;b:1;s:10:”edit_users”;b:1;s:10:”edit_files”;b:1;s:14:”manage_options”;b:1;s:17:”moderate_comments”;b:1;s:17:”manage_categories”;b:1;s:12:”manage_links”;b:1;s:12:”upload_files”;b:1;s:6:”import”;b:1;s:15:”unfiltered_html”;b:1;s:10:”edit_posts”;b:1;s:17:”edit_others_posts”;b:1;s:20:”edit_published_posts”;b:1;s:13:”publish_posts”;b:1;s:10:”edit_pages”;b:1;s:4:”read”;b:1;s:8:”level_10″;b:1;s:7:”level_9″;b:1;s:7:”level_8″;b:1;s:7:”level_7″;b:1;s:7:”level_6″;b:1;s:7:”level_5″;b:1;s:7:”level_4″;b:1;s:7:”level_3″;b:1;s:7:”level_2″;b:1;s:7:”level_1″;b:1;s:7:”level_0″;b:1;s:17:”edit_others_pages”;b:1;s:20:”edit_published_pages”;b:1;s:13:”publish_pages”;b:1;s:12:”delete_pages”;b:1;s:19:”delete_others_pages”;b:1;s:22:”delete_published_pages”;b:1;s:12:”delete_posts”;b:1;s:19:”delete_others_posts”;b:1;s:22:”delete_published_posts”;b:1;s:20:”delete_private_posts”;b:1;s:18:”edit_private_posts”;b:1;s:18:”read_private_posts”;b:1;s:20:”delete_private_pages”;b:1;s:18:”edit_private_pages”;b:1;s:18:”read_private_pages”;b:1;s:12:”delete_users”;b:1;s:12:”create_users”;b:1;}}s:6:”editor”;a:2:{s:4:”name”;s:9:”編集者”;s:12:”capabilities”;a:34:{s:17:”moderate_comments”;b:1;s:17:”manage_categories”;b:1;s:12:”manage_links”;b:1;s:12:”upload_files”;b:1;s:15:”unfiltered_html”;b:1;s:10:”edit_posts”;b:1;s:17:”edit_others_posts”;b:1;s:20:”edit_published_posts”;b:1;s:13:”publish_posts”;b:1;s:10:”edit_pages”;b:1;s:4:”read”;b:1;s:7:”level_7″;b:1;s:7:”level_6″;b:1;s:7:”level_5″;b:1;s:7:”level_4″;b:1;s:7:”level_3″;b:1;s:7:”level_2″;b:1;s:7:”level_1″;b:1;s:7:”level_0″;b:1;s:17:”edit_others_pages”;b:1;s:20:”edit_published_pages”;b:1;s:13:”publish_pages”;b:1;s:12:”delete_pages”;b:1;s:19:”delete_others_pages”;b:1;s:22:”delete_published_pages”;b:1;s:12:”delete_posts”;b:1;s:19:”delete_others_posts”;b:1;s:22:”delete_published_posts”;b:1;s:20:”delete_private_posts”;b:1;s:18:”edit_private_posts”;b:1;s:18:”read_private_posts”;b:1;s:20:”delete_private_pages”;b:1;s:18:”edit_private_pages”;b:1;s:18:”read_private_pages”;b:1;}}s:6:”author”;a:2:{s:4:”name”;s:6:”作者”;s:12:”capabilities”;a:10:{s:12:”upload_files”;b:1;s:10:”edit_posts”;b:1;s:20:”edit_published_posts”;b:1;s:13:”publish_posts”;b:1;s:4:”read”;b:1;s:7:”level_2″;b:1;s:7:”level_1″;b:1;s:7:”level_0″;b:1;s:12:”delete_posts”;b:1;s:22:”delete_published_posts”;b:1;}}s:11:”contributor”;a:2:{s:4:”name”;s:9:”寄稿者”;s:12:”capabilities”;a:5:{s:10:”edit_posts”;b:1;s:4:”read”;b:1;s:7:”level_1″;b:1;s:7:”level_0″;b:1;s:12:”delete_posts”;b:1;}}s:10:”subscriber”;a:2:{s:4:”name”;s:9:”協力者”;s:12:”capabilities”;a:2:{s:4:”read”;b:1;s:7:”level_0″;b:1;}}}
この状態でxserverのdatabseにアップ。ただし、私の場合は既存のdatabaseとは別に新規にdatabaseを作成してそちらにアップした。
4. wordpressのアップデート
最新の2.2.3で既存のファイルを上書きした。
そして、そのあと、wp-config.phpの次の項目をを修正。
mb_internal_encoding(”UTF-8″);
define (’WPLANG’,ja’);
新しいデータベースに接続先を変更 define(’DB_NAME’,’ ‘);
ここで、このままwp-config.phpをアップしてもwebブラウザでみるとEUC-JPのままかわらないことがあったので、いったんxserver上のwp-config.phpを削除。その状態でwebブラウザでアクセスしてセットアップ画面表示。そのあとwp-config.phpをアップするとうまくutf-8に表示がかわった。
あとはthemeファイルを修正して日本語をEUC-JPで直接記述している場合、UTF-8に修正。
.htaccess (SV30サーバなので) を次のようにしてうまく動作した。
# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
php_value default_charset UTF-8
php_value mbstring.language Japanese
php_value mbstring.internal_encoding UTF-8
php_value mbstring.http_input auto
php_value mbstring.http_output UTF-8
php_value mbstring.encoding_translation Off
php_value mbstring.detect_order Off
php_value mbstring.substitute_character none
# END WordPress
No commentsbind9.2系のサポートが2007年8月末をもって終了となる。
http://www.isc.org/index.pl?/sw/bind/versions_and_support.php
非常に大きな脆弱性に対しては今後も対応する可能性はあるが、早めにバージョンアップしておいたほうがよいであろう。
最新安定板は9.4系。
phpで記述したWebアプリケーションにクロスサイトスクリプティング、SQLインジェクションの脆弱性が存在しないかチェックしてくれるツール、pixy。
FAQ等読むとまだphp5系には未対応、マルチバイトで書かれたソースはうまく解析できない場合がある、オブジェクト指向で書かれたソースはうまく解析できないなどの問題があるが、ソースを自動でチェックするという発想がすばらしい。
pixy自体はjavaで書かれており、windowsでもlinuxでも動作する。
今回はWindows上でpixyを設定、動作させた。
[準備]
[実行]
perl を使わない場合(サンプルのgetstarted.phpをチェック)
(Pixyフォルダで) run-all.bat getstarted.php > getstarted-result.txt
※結果
Number of sinks: 2
Vulnerability detected!
- unconditional
- パスPixygetstarted.php:11
- Graph: xss2
Total Vuln Count: 1
[解説]
getstarted.phpの11行目(echo $b;)にXSSの脆弱性存在
グラフの2に脆弱性 ( Pixygraphs にtxtファイルと dotファイルが存在する。今回はxss_getstarted.php_2_dep.dot)
このgraphsフォルダには変数のフロー図が描かれている。
graphbizを用いて dotty xss_getstarted.php_2_dep.dot を実行すれば表示される。
perlを使う場合
perl run-all.pl getstarted.php > getstarted-result2.txt
※batで実行してもperlで実行しても結果は同じ
——————————————-
Tree図の作成
perl Pixyフォルダscriptstree.pl getstarted.php
※ここでdottyが起動するが大量の警告が発生する(100回ぐらい?)。
ポップアップ内容:
OKボタンを押し続けると最終的には表示される。(文字コードの問題か?)
もっと簡素化したフロー図
perl Pixyフォルダscriptsquick_cfg.pl getstarted.php
同様にエラーがでる。ただし回数はtree.plより少なめ。
SQLインジェクションのチェックのみ実施
perl Pixyフォルダscriptsrun-sql.pl getstarted.php
XSSのチェックのみ実施
perl Pixyフォルダscriptsrun-xss.pl getstarted.php
php4系のサポートが今年いっぱいで終了するとアナウンスされている。
http://www.php.net/index.php#2007-07-13-1
サポート終了後は2008年8月8日まで重要なセキュリティフィックスのみ対応予定となっているが、迅速な対応は期待できないので4系の人は早めに5系にアップしたほうがよいだろう。
4系から5系へのアップデート方法はこちら。
http://www.php.net/manual/en/migration5.php
SEO対策の重要な要素として被リンク数が挙げられるが、トラックバック送信によって獲得したリンクでも効果があるのか試してみた。
[作業概要]
※ブログの検索からトラックバック送信までは自作のトラックバックツールで自動実施した。
1日5〜10程度トラックバックを実行し、これを約2週間続けた。
すると当初圏外だった検索順位が、Yahoo 50位、Google 3位、Microsoft 7位まであがった。
検索エンジンはトラックバックリンクを無視するとかnofollow属性がついているためリンクとしてカウントされないなど一部では言われているが、現時点ではトラックバックによるリンクに効果があった。特にGoogleで顕著であった。
4travelの旅行検索APIを利用してみた。 簡単にデータが取得できる。以下はphpで記述する場合の例(メイン部分のみ抜粋)
$url = "http://api.4travel.jp/Ver1/SearchAlbum.php?format=php&inputcharset=euc&outputcharset=euc&areatype=city";
if($_POST['key1'] != ”)
{
$word = urlencode($_POST['key1']);
$url .= “&keyword=” .$word;
}
$serialized_result = file_get_contents($url);
$ryokouki_result = unserialize($serialized_result);
print “<table class=\”diary\”>\n”;
for($s=0;$s<count($ryokouki_result);$s++)
{
print “<tr><td>\n”;
print “<img src=\”" .$ryokouki_result[$s][picture]. “\”></td><td>\n”;
print “<a href=\”" .$ryokouki_result[$s][albumurl]. “\” target=_blank>”;
print $ryokouki_result[$s][albumtitle]. “</a><br />\n” ;
print $ryokouki_result[$s][description]. “\n” ;
print “</td></tr>”;
} // for
print “</table>\n”;