トップページ > コンピュータ > UNIX系 > Linux > Redhat > CentOS

2011年09月17日

正体不明のPerlプロセスは、トロイだった・・orz

先日の投稿で記した通り、切り分けを行いました。MovableTypeが怪しいんじゃないかと言う私の予想で、このブログを停止していたのですが、症状が再現してしまいました。Perlプロセスが動くもので他には？という考えに、ちょっとしたBBS系のCGI等が頭に浮かびましたが、今日は仕事が休みだったので、プロセスを生かしたまま、reniceで優先度を下げて保持し調査をしました。

/proc/プロセスID/

この辺りを調べて、/usr/sbin/apache/logというコマンドが実行されているぽいことが分かりましたが、そのファイルやディレクトリは存在しません。ネットで検索してみたところ、同じ症状に困っている人（英文）を見つけましたが、どうやらちょっとウチとは違うみたいです。ただ、クラッキングを受けている可能性が高いことはわかりました。

という訳でApacheからアクセス出来るディレクトリを調査することにしました。

  • /tmp/new.txt

  とう名前のファイルで、中身を見たら怪しげなPerlスクリプトでした。どうやらバックドアを仕掛けられたみたいです。Windows環境にSCPで持ってきたとたんに、Micrsoft Security Essensialが警告を出しました。

  • Backdoor.Perl/Shellbot.S
# This code is based on atrix (brazil) shellbot, somebody ripped all the credits, but its obviusly a rip.
# so the original author is atrix. the spread perl code was developed by sirhot (i am almost  sure) he is from morocco.
# Note to David Jacoby: Expect a few improvements for the next release.
#
# The following comments are only left in the code to ridiculize this guy.
# --------------------------------------------------------------
# Morgan has hacked you!
# Morgan Argentina, santiago del estero
# http://irc.irc-argentina.org/x.conf
# http://img521.imageshack.us/img521/3779/morganlammer6tu.png

やられた・・完全にやられてしまいました。こいつのせいでPerlプロセスがCPUリソースを食いまくっていたわけですね。スクリプトの冒頭部分のみですが、こういうのを残してる時点で誰かが作ったものを使ってるだけの、いわゆる「スクリプトキディ」て奴でしょう。おそらくrootは取られていないと思います。（カモフラージュなのかも知れないけど）

しかしどうやって/tmpに放り込んだのか？（所有権がApacheになっているのでApacheを利用しているのは分かりますが手口を全く知りません。興味ないジャンルなので知るハズもないけどこういう手口も勉強しないといけないのかなぁ。）

Micrsoft Security Essensialが検出したってことは、Windows環境でも知られているという事だから、ClamAV辺りでも検出出来るかな？とテストしてみたら一発で見つけてくれました。

という事でClamAVをインストールしとくことにしました。どんだけ効果があるか分かりませんが、今回の場合はインストールしておけば未然に防げたという事ですからね。ClamAVは下記サイトを参考にさせていただきました。非常にわかりやすかったです。

アンチウィルスソフト導入(Clam AntiVirus) - CentOSで自宅サーバー構築

これでMTの疑惑は晴れましたが、とっととWordPressに移行するべきなんだろうな。

PS
new.txtの正体が少しわかってきました。
何かしらの方法で[http://cococody.home.ro/new.txt]からダウンロードさせられてました。
テキストファイル形式ですが、明らかにボットウイルスらしいのでアクセスは自己責任で。

更に追記
おそらくphpMyAdminのsetup.phpの脆弱性を突かれた可能性ありです。私自身phpMyAdminの存在をすっかり忘れていて（最初に使ったっきり）、これはうっかりしていたと反省です。ただし脆弱性が公表されているバージョンよりも新しいものを使っていましたが、ログの解析によると何度かsetup.phpが実行された痕跡があり、その時間とほぼ同じ時刻に上記のnew.txtをダウンロードしようとして弾かれていました。ApacheのErrorログに記されていましたので私が確認したものは未遂だったと思われますが、もしかしたら例のApache Kellerの対策が遅れた数日間の間に仕込まれた可能性があります。これについては対策済です。VPSは便利ですがむき出しのネットワークに接続されていて、無国籍（明らかに不要なアクセスはフィルタリング してますが・・）の攻撃を受けるという事を再認識しました。やりすぎは無い位のセキュリティ対策をしておくべきだと認識しました。
教訓：phpMyAdminには最低限の備えとしてベーシック認証をかけとけ。

投稿者 sasapurin : 13:34 | コメント (0) | CentOS , Linux | トラックバック | このエントリーを含むはてなブックマーク

2011年05月02日

今更ながらscreenコマンド便利過ぎ！

LinuxやBSDなどのUNIX系サーバーを使う人なら欠かせないのがSSH。私は通常業務はWindows7で行っているので、SSHクライアントとしてはPuTTYが欠かせない。PuTTYから社内のLinuxサーバへ接続し管理の為の操作を行ったり、社内アプリのメンテナンス（プログラムはプログラマーが組んだ）を行ったり。

作業はLinuxサーバが行うので、手元で動くのはSSHクライアントであるPuTTYだけ。テキスト情報なので非常に軽い動作で、サーバーがガリガリ作業をしていても全くこちらには影響が無い。

そんな便利なSSHだが不便な事がある。SSHでシェルに接続してそのままコマンドを実行すると、処理が終わるまでPuTTYを終了出来ない。つまりPCもシャットダウン出来ないのだ。これはバッチ処理などの時間がかかる作業には困ってしまう。screenを知らない頃は、PCの電源を入れたまま退社して翌日状態をチェックしていた。

PuTTYからSSHでシェルにログインし、screenを実行する。ここからコマンドを投入しておけば、screen上でプロセスが動いているので、切断（デタッチ）してもサーバーは処理をし続ける。この方法だとWindowsマシンはシャットダウンしても問題なしだ。翌日PCを起動してPuTTYを起動して、SSHでシェルにログインしてscreenに-rで入るだけで状態が確認出来る。

更に凄いことにscreenは一つだけでなく、沢山の仮想ターミナルを作れるので、色々な処理をさせるコマンドを実行しておいて、screen上で切り替えるだけでいくつものプロセスをSSHセッション一本で操作できてしまう。

最近時間がかかる作業が多くなったし、自宅サーバからレンタルVPSに引っ越した事もあって、screen大活躍である。今更だけどこの今の感動を記しておきたかった。

投稿者 sasapurin : 17:57 | コメント (0) | CentOS , Linux , UNIX系 | トラックバック | このエントリーを含むはてなブックマーク

2011年04月11日

さくらVPSへの引越しを楽に行う(rsync)

先日は、さくらVPSへとりあえずMovable Typeで稼動しているブログのみ引越しさせたが、各種のWebアプリを動かしているのでちまちまとやっていては時間も手間もかかってしょうがないので、同じCentOS 5を使っているということで、一気にrsyncで関連ファイルをCOPYしてしまうことにした。COPYというよりは同期を取るというのが正しいかな？

まず既存自宅サーバのWebサービスを停止させる。これはrsyncの最中にCMSが更新処理を行った際に、また同期を取り直す必要があるからそれを省くため。当然Webサービスは停止するがhttpdをストップさせれば済むことだ。 

# servece httpd stop

そして同期したいディレクトリでrsyncを実行する。どうやらCentOS 5はrsyncがデフォルトでインストールされるらしく、双方でrsyncコマンドが入っていた。同期を取るので自分は分かりやすく、自宅サーバの方で行った。vps.sasapurin.comは先日zoneeditでさくらのVPSをAレコードで登録しているので名前解決済みだ。 

$ cd
$ rsync -a --exclude ./Maildir -e ssh ./ vps.sasapurin.com:/home/sasapurin/

たったこれだけで、 Maildirを除くフォルダがそのまんまSSHで転送され同期が取れる。.bashrcなどの設定ファイルもついでなので自宅サーバーの設定に同期させてしまう。

ウチはネットがADSLなもんで結構時間がかかるが、二回目からは差分同期してくれるのでrsyncを使わない手はない。さてほうっておいて晩ご飯でも食べよう。

rsyncについては、UNIX系のOSの解説本なら大抵取り上げられているし、今時はネットで検索したら分かりやすく解説してくれているサイトもたくさん見つかるので、私はあえて詳しいことは触れません。とりあえず一つだけ参考サイトを記しておきます。

楽に同期させられる方法としてrsyncコマンドを覚えていれば十分です。いやぁ、VPSって素晴らしく快適だ。シェルが使える（root権限がある）ってやっぱ最高っすよ。自宅サーバとは、大容量ファイルをLANで転送した時の速度が違う位で、それ以外はなんら変わりないですね。

投稿者 sasapurin : 19:18 | コメント (0) | CentOS | トラックバック | このエントリーを含むはてなブックマーク

2011年04月06日

このブログをさくらVPSに引越し

さくらVPS（512）を使用する計画です。初期費用なしの、月額980円なので夏場の自宅サーバーの電気代とエアコン代を考えると確実に安いなという算段をしまして、VPSでいくことに決めました。

とりあえず昨夜からちょっとずつ準備をしているのですが、MySQL+phpMyAdminに、Apacheをセットアップして、WordPressにて正常稼動を検証。そしてこのブログを引っ越しさせました。MTはPerlなのでモジュールを揃えるのが毎回ウザいですが、まぁ儀式みたいなもんですかね。mt-check.cgiで検証します。

自宅サーバーの時はSQLサーバが別立てにしていたので、mt-config.cgiにてDBサーバーのIPアドレスを指定していた部分をlocalhostに修正。MySQLにはダンプしたものをインポート、MTのファイル軍はあらかじめtar.gz形式でアーカイブして転送した後に展開したので作業は基本的にこれだけです。

いやぁ、UNIX系のOSはアプリの環境の引越しも見通しが良くていいな。Windowsアプリだとアプリのインストールはインストーラでやってからデータファイルや設定ファイルなどを上書きするとか、レジストリ修正するとか細工が必要なのでこういう見通しのよさは毎度ながら嬉しいものです。

さて、メモリー512MB、HDDは20GBの一番安いプランですが、デュアルコアなのでメモリーの実装量が少ない点だけが心配な位で、CentOSの最小構成から構築しているのでまぁなんとか行けるだろうと見ています。後は既存のWordPressなシステムとか、細々したものを引越しさせる予定です。これらは少々面倒ですが少し時間をかければ問題なく引越しできるはずです。

ちなみに、名前解決は、さくらVPSのIPアドレスをAレコードで追加して、バーチャルホストで各種Webサービスを動かすので、引越しが終わったらCNAMEの実体を自宅サーバから、さくらのサーバに変更するのみです。ネットワークのスキルも身につけておいて本当によかったと思っています。

少しずつ整理されていく状況は達成感もあるし楽しいですね。

投稿者 sasapurin : 00:44 | コメント (0) | CentOS | トラックバック | このエントリーを含むはてなブックマーク

2011年03月31日

さくらのVPSとか便利なのに・・

個人的にはインフラ屋なもんで、UNIX系、Windows系問わずネットワークも含めて設定するスキルは身につけているし、色々失敗もしたし、効率の良い方法とかも経験から蓄積しているので、さくらのVPS等の安価なVPSサービスがこれだけ増えてくると、各種フレームワークの環境整備まで行えば、Pythonやら、PHPやら、Ruby（Rails）、Javaなどで色々出来ちゃって、数年前の状況がアホらしくなるほどコストパフォーマンスが上がっていることを嬉しく思う。

夏なんか発熱の多い自宅サーバーは、稼動させると熱生じる->冷却のためにエアコン稼動と、月額の電気代なんぼいるねんみたいなのが実情なので、リアルハードウェアを自宅に置くことは、もはや余程の物好きか変わり者位だといわれてもおかしくないのが実情である。昨年の夏は、T105も冷却ファンがブンブン回ってえらい電気代をはじき出してくれたものだ。今年の夏までには間違いなくVPSに引越しさせて、発熱を抑えてエアコンの稼動効率を上げて電気代を節約したいと考えている。

さぞかしVPSが流行るだろうなと思ったものだが、現実はそういうものではなさそうだ。VPSを安価に借りたもののセットアップが出来ずに断念するケースが結構あるらしい。インフラ屋の私にとってはリアルサーバーだろうがVPSだろうが大した違いは無いので最小構成のCentOS等から環境を構築するのが当たり前なので、どうして？という言う気持ちなのだが、そこでようやくインフラ屋が不足している事に気づいた。

いや、大手が抱えてるインフラ屋は沢山いるはずである。課題はそういうところではなく、安価にVPSを利用したいというニーズに応えられるインフラ屋が居 ないという訳だ。確かにサーバーに素のOSをインストールし、そこからセットアップしていくには、色々なポリシーなり、求める環境が多岐にわたる訳で、そ れらに柔軟に対応できるスキルをもった人しかVPSを活用できないというのは、以前として変わらない状況なのだと気づいた訳だ。

専用サーバーとほぼ同様にroot権限を持ち、自由に環境をセットアップできる自由さを持ったVPSだが思ったほど普及しないところはそこにあると言うことは、案外見落とされていた実情なのかも知れない。自由すぎて不便とでも言うべきか。

おそらく今後は、VPSでも数パターンの構成済みイメージからサーバーを稼動させられる仕組み（サービス）がリリースされるのは必至だろう。Javaアプリを使いたいニーズ、PHPのフレームワークを使いたいニーズ、Ruby、Python・・・各種フレームワーク。

データベースもそうだな。個人的には、PostgreSQL+phpPgAdminの設定がめんどくさいという印象を持っている。一応数回苦戦したので肝は押さえたけどこれでつまずく人はいると思う。こういうのをセットアップ済みのイメージ（Ghost）からデプロイして使用開始できるならかなり敷居は低くなるはずだ。さくら辺りが対応させてきそうだな。

ま、個人的には素のVPSサーバーを使わせてもらえれば十分なので、付加価値をつけたプランよりもかなり割安に何も無いプランを展開してくれると幸せこの上ないが。いまだにプログラミングが出来ない技術者に甘んじているが、インフラ屋としてのスキル身につけておいてよかったぜと思うことが出来た珍しいケースかも知れない。インフラ屋は所詮は裏方仕事だからね。自分専用の比較的高性能なサーバー（DELL T105 クアッドコア）を手に入れた時以上の喜びを今感じているかも知れない。

VPS万歳～！

投稿者 sasapurin : 03:23 | コメント (0) | CentOS | トラックバック | このエントリーを含むはてなブックマーク

2010年03月12日

Movable Typeが500エラーで止まる

どうも最近、mt.cgiでの更新時、500エラーで止まることが多い。かと言って確実にエラーが出るわけでも無い。Perl CGIの動作が不安定というところだろうか。根本的に調査しないとダメっぽい。

先に結論
うちのMovable TypeはDELLのT105というAMD社のOpteron クアッドコアサーバ上で動いている、VMWare社のESXiという仮想サーバ上のCentOSのWebサーバで稼動している。最終的にはこのESXi仮想サーバーに問題があったらしく、全てのゲストOSを停止してから、ESXiを再起動したら全てクリアーとなった。

以下に顛末を記しておく。将来の自分のためにね。

Repopulate Form
Repopulate Form
Repopulate Form

休日、ようやくSSHでログインしてみて、topコマンドを叩いて見た。
・・・・なんだこりゃ？

topで表示されるプロセスリストがチラチラして何かがリソースを食いまくっているであろうことが容易に想像できる。しかしチラチラしすぎてプロセス名が読み取れない。何が原因なんだこれ？

topのプロセス監視更新時間を長くしてみた。普通は秒単位らしいが下記のようにしないとほとんどチラチラが落ち着かず何がリソースを食っているのか読めなかった。

$ top -d 100

やっとこさ捕まえたプロセスは「hald-addon-stor」と表示されたので、こいつをGoogleで検索した。すると正式なプロセス名は、「haldaemon」だと分かった。storってのが気になるがなんとなくstorage（ストレージ）の様な気がする。HDD異常？

cat /var/log/messages | grep kernel > /home/sasapurin/20100311error.txt

ログからカーネル系のエラーを抽出してみる。これでじっくり分析できる。と思って調べてみたが全然原因らしきものが見つからない。ログに残らない原因って何だ？

ふと思った、このWebサーバーは、VMWare ESXiサーバ上で動いている。もしかしたらESXi（言い換えれば仮想化ホストサーバ）の不具合でおきているのではないか？OS上のプロセスも問題ない しもうそれしか考えられない。ESXiの状態を確認してみて驚愕した・・普段は大人しいWebサーバがCPUリソースを食いまくっている・・・やっぱり異常だったんだ。

もうこうなったら、ホストの問題であってくれと願うばかり。仕方ないので全てのゲストOSをシャットダウンして、敢えてメンテナンスモードではなく通常モードでVMWare ESXiサーバを再起動した。

まず、仮想サーバー上で動かしているWindowsサーバが上がってきた。これは自動起動設定しているので正常な状態だ。このWindowsサーバのAD（つまりDNS）を使ってLAN内部の名前解決をしているので一番最初に上がって欲しいのだ。次に遅延をかけている今回の問題となっているWebサーバが起動してきた。起動中はCPUリソースは大人しいぞ。この調子で上がってくれ・・

最終的に確認したら、症状はピタっと納まった。CentOSは普段どおりのリソース消費に納まり、SSHから入ってtopコマンドを入れてみてもチラチラ暴走の気配は無くなった。今回気づいたMovableTypeよりエントリーを投稿してみる。500エラーは出なくなった。良かったー、要するに500エラーの原因は、Webサーバ（CentOS）がホストの異常により不安定な状態に陥りリソース食いまくりの暴走モードと鳴っていたという事だ。何もプログラムの追加や変更をしていないのに急にMTが500エラーを出す様になったので今回はある程度原因を絞りやすかった。

ただ、理論的に追いかけていかないと分かりづらかったのは、仮想サーバーにしているため、CPUリソースを食いまくっても、割り当てている上限で止まってしまい、仮想サーバー全体には影響を及ぼさなかったことだ。リアルサーバーの場合は処理能力が致命的に低下したりするので、気づきやすいが、今回はOpteronのクアッドサーバーだったので、ハードウェア的にはまだ余裕があった為、他のゲストOSには影響がほとんど無かった。逆に言えば仮想化しているおかげでお隣さんに被害を与えなかったとも言えるが、結局はVMWare ESXiサーバの再起動を余儀なくされたので、被害は全部に及んだとも言える。

まだまだESXiサーバとの付き合いは浅いし、職場にも導入してしまったので癖やトラブル時の対応を自宅ででも有る程度把握しておかねばと思う次第である。とりあえず実害は殆ど無かったので良しとしよう。まだまだESXiサーバも改善の余地アリってところだろうか？VMWare社には頑張って原因を調べてもらって改善パッチをリリースしていただきたく願う。

投稿者 sasapurin : 10:30 | コメント (0) | CentOS , Movable Type , Webアプリ , コンピュータ | トラックバック | このエントリーを含むはてなブックマーク

2009年07月01日

CentOSでFFFTPから削除できない

Karesansuiを使ってXen仮想環境を快適に使っている。一つベースとなる環境を作っておけば、それをコピーして新しい環境として利用できるので、クローンの生成は非常に効率的である。

しかし、ベースとする環境の設定が不十分だと、クローン環境にもそのまま継承されてしまい思わぬトラブルに悩まされることになる。今日は下記のようなことになった。

クローンした仮想環境でWindowsのFFFTPから不要ファイルを削除しようとしたら、削除できなくて困ったといいう相談を受けた。確認してみたがパーミッションの問題でもないし、ユーザーアカウント=オーナー番号も同じなので削除できないのは変だなぁと首をかしげた。

もちろんSSHで入り込んでbashを使えばコマンドラインから削除は出来る。何があかんのかなぁ？とFFFTPで操作しているのを見せてもらい、空のフォルダを削除できないという状況を確認した。そして思った・・本当に空なのかな？

bashシェルからsuでそのユーザーアカウントになり、当該フォルダをls -laで見たところ、ドットファイルがあった。やっぱり空では無かった！！

#ドットファイルとは、.htaccess という感じに"."から始まるファイル名。UNIX系OSでは隠しファイルになるので、lsコマンドでは見えずaオプションをつけないと見えない。FFFTPの挙動はUNIXコマンドとは違うと分かっていたので、おそらく再帰的にフォルダ階層を掘り下げてリスティングし、ファイルを一個ずつ削除しているものと思われる。

故に、ドットファイルが見えないからFFFTPは削除しておらず、空でないフォルダは削除できないという図式だろう。bashシェルからドットファイルを削除してからFFFTPで実験したら問題なくフォルダを削除できた。

解決方法は色々あるだろうが、手っ取り早く思いつくのは下記の方法だ

  1. WindowsなどからFTPコマンドでアクセスして、FTPコマンドで削除する方法。
  2. FTPサーバの設定を変更してドットファイルを可視状態にしてFFFTPでも削除できるようにする方法。
根本的な事を考えるとFTPサーバの設定を変えちゃった方がいいだろう。どうせ自前のサーバなんだし。（レンタルサーバでは出来ない可能性が高いけど）

CentOS5.3環境で作っているテスト環境は、FTPサーバとしてvsftpdをインストールしてある。vsftpdでドットファイルを可視状態にするには、下記のようにvsftpd.confを編集して再起動すれば良い。FFFTPでも見られるようになり、削除も出来るようになった。

#vi /etc/vsftpd/vsftpd.conf
force_dot_files=YES
# Service vsftpd restart

これは必須な設定だと思えるので、CentOSセットアップ手順書というか備忘録に記しておくことにした。

投稿者 sasapurin : 13:09 | コメント (0) | CentOS , UNIX系 , オープンソース系 | トラックバック | このエントリーを含むはてなブックマーク

2009年06月30日

YAMAHA RTX1100をCentOSのシリアルポートから

YAMAHA RTX1100を最初に設定するには、シリアルポートから行わないとどうしようもない。
ところが最近はシリアルポートが無いPCが多くなった・・・

ふとLinux Serverを見るとシリアルポートがあるではないか。
どうせここに設置するんだし、常時接続しておけばSSH経由で
WindowsPC->Linuxサーバ->シリアルポート->RTX1100
という風にリモートできるわけですな。

しかし実際にやってみると苦労もあった。もう二度と同じ苦労はしたくないので備忘録しておく。

下記のようにした

  1. シリアルケーブルでLinuxサーバとRTX1100接続
  2. WindowsPCからSSH(PuTTYとか）でLinuxサーバに接続(文字コードはSJIS)
  3. Linuxサーバのscreenコマンドで接続する
    # screen /dev/ttyS0 9600　->　文字化けするのでSJIS化する
  4. エディタでscreenの設定ファイルを編集する
    # vi /etc/screenrc
    encoding sjis
    defencoding sjis
  5. 再びscreenコマンドで接続する
    # screen /dev/ttyS0 9600
  6. 空ENTERを押したらRTX1100がパスワードを聞いてくる。
  7. 後はおのれとYAMAHAルーターコマンドの格闘
以上な感じの手順で快適なリモート設定が出来るようになった。シリアルポート付きのノートパソコンがあればまぁこんな事しなくてもいいかなとは思うけど、席に座ってWindows上で調べながらPuTTYで操作できるから快適だよね。PuTTYはコピペできるからコマンドのコピペも楽だし。

投稿者 sasapurin : 20:11 | コメント (0) | CentOS , Network系 , ハードウェア | トラックバック | このエントリーを含むはてなブックマーク

2009年06月26日

CentOSにPostgreSQL 8.2系をインストール

普段はMySQLしか使ってないので、PostgreSQLのことは良く分からないのだが、職場の同僚がどうしても8.2系か8.3系を使いたいって言うので、8.2系をインストールすることにした。

インストールするにしても、yumの管理が楽なのでこれは守りたいところ。リポジトリ無いのかな？と思って調べてみたら有った。ありがたいことだ。（今後メンテされるかどうかは分からないが）

http://yum.pgsqlrpms.org/reporpms/8.2/

# rpm -ivh http://yum.pgsqlrpms.org/reporpms/8.2/pgdg-centos-.2-4.noarch.rpm
# yum search postgresql
# yum info postgresql.i386
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: ftp.nara.wide.ad.jp
* updates: ftp.nara.wide.ad.jp
* addons: ftp.nara.wide.ad.jp
* extras: ftp.nara.wide.ad.jp
Available Packages
Name : postgresql
Arch : i386
Version : 8.2.13
Release : 1PGDG.rhel5
Size : 1.6 M
Repo : pgdg82
Summary : PostgreSQL client programs and libraries
URL : http://www.postgresql.org/
License : BSD
Description: PostgreSQL is an advanced Object-Relational database management
                  : system (DBMS) that supports almost all SQL constructs (including
                  : transactions, subselects and user-defined types and functions). The
                  : postgresql package includes the client programs and libraries that
                  : you'll need to access a PostgreSQL DBMS server. These PostgreSQL
                  : client programs are programs that directly manipulate the internal
                  : structure of PostgreSQL databases on a PostgreSQL server. These
                  : client programs can be located on the same machine with the
                  : PostgreSQL server, or may be on a remote machine which accesses a
                  : PostgreSQL server over a network connection. This package contains
                  : the command-line utilities for managing PostgreSQL databases on a
                  : PostgreSQL server. If you want to manipulate a PostgreSQL database
                  : on a local or remote PostgreSQL server, you need this package. You
                  : also need to install this package if you're installing the
                  : postgresql-server package.

投稿者 sasapurin : 11:00 | コメント (0) | CentOS | トラックバック | このエントリーを含むはてなブックマーク

2009年06月12日

Karesansui 1.0.1 64bit and AMD Support

先日、お試ししていい感じになったXenハイパーバイザをWebサービス上で管理できる「Karesansui」が早速バージョンアップして、Ver 1.0.1になった。

バージョンアップ内容の目玉としては、

  1. AMDプロセッサ対応
  2. 64bit OSサポート

と、待ち望んでいた条件が整ったので早速片手間ながら32bit環境を捨てて64bitで作り直した。幸いゲストOSはテストに使ったけれど要らなくなったので削除してしまっても問題ない。一ヵ月後とかに出されたらぶーぶー文句言ってただろうが、このタイミングに64bit対応はまだ環境再構築に間に合うからうれしい。

CentOS 5.3 x86_64を再インストール。もちろんXenハイパーバイザをシンプルにインストールだ。

アッサリインストールが終わり、Wheelユーザを作ってからはSSHで作業する。自分のデスクにあるWindowsXPパソコンからPuTTYを使ってSSHだ。LAN内部の使用で外部には公開していないので暗号化Key等は考慮していない。

PuTTYからのインストールだと、テキストインストール画面の体裁が崩れる。これは前回インストーラを修正してやった時と同じだから改善されていない。

Karesansuiの導入もスコッと終わり、ゲストOSをインストールしてみる。CentOS 5.3 X86(32bit)をインストールした。GUIは全くなしで極々シンプルにね。これは私のいつもの手法。FeeeBSDで慣れた手法なので最小構成からインストールしていく。

一連の手順は社内のWikiに記しておいたので何の問題も無く32bit環境から64bit環境に変更出来た。まぁゲストOSをため込んでいたらこうは行かないけどね。早い内に64bit対応させて下さった開発陣にお礼を言いたいものだ。

完全仮想化までサポートしてくれたらXen対応カーネルが付いていないVineなんかでもテスト出来るんだけどね。これからのディストリビューションはXen対応のカーネルを添付して欲しい、もしくはDLできる様にして欲しいものだ。

一度通った道なので苦労もなくすんなり出来た。後は最小構成インストールのksファイル(キックスタート)を共有出来るようにしてスコッと手抜きインストール出来るようにしたいものだな。

投稿者 sasapurin : 16:42 | コメント (0) | CentOS , Linux , UNIX系 , Webアプリ , オープンソース系 , コンピュータ | トラックバック | このエントリーを含むはてなブックマーク

2009年05月30日

Karesansui Project

職場のOpteronサーバでXen環境を構築する計画で時間が無くて保留していたんだが、 「Karesansui Project」のリリースをきっかけに行動を起こしてみた。

karesansui-project.info

早い話、XenハイパーバイザをGUIで（ブラウザ経由で）管理できるというOSSプロジェクトである。CentOS 5.3が対応となっている。

チュートリアルの図が下記のようになっていて、HostOSはCentOS5.3-32Bitと書いてあるのが気になりつつも、手元に64bitのDVDしか用意してないのでチャレンジしてみた。

チュートリアル画像の表示

見事に玉砕した・・・

karesansui-1.0.0-1-install-pack.tar.gz　をダウンロード後解凍し、
karesansui-install　を実行したところ下記のメッセージが帰ってきた・・・

ERROR: Processor 'x86_64' is not supported by Karesansui.

オーマイガッ

どうせなら64bitで構築したいから、karesansuiが64bitに対応するのを待つしかないかな。

それとも32bitで検証するか・・・やっぱり初物に飛びつくのは人柱覚悟でって事か。

推奨スペックがいまいち分かりにくい。
CPU : Intel Core 2 Duo以上

Opteron 2.2GHzはもちろんデュアルコアなのだが、 Intel Core 2 Duo以上なのか否か？
リリースされたばかりのプロジェクトだけに、まだ情報が洗練されてないよな・・

ERROR: Processor 'athlon' is not supported by Karesansui.

オーマイガッ！！！

またかよっ。Intel CPUしかサポートしてないとは書いてないで・・ちゃんと明記してくれよな。

要するに現状は下記要件をクリアしないとすんなりとインストールすることは出来ないらしい

  1. CentOS 5.3 32bit　(64bitは未サポート）
  2. Intel Core2 Duo マシン　（AMDは未サポート）
  3. メモリー 2GB以上
  4. HDD 100GB以上

無駄な時間を使ってしまった。もういい、CitrixのXenServerでいく事に決めた。

と思っていた矢先、MLにてAMDプロセッサへの対応についての投稿があり、Karesansuiとしては制限をかけてはいないので、インストーラ（スクリプト）のバグだろうというコメントがついた。そして2つのファイルを編集すればOpteronサーバでもインストーラが走った。

ML以外にはまだ情報が無いようなので備忘録を兼ねて引用しておく。
（MLのアーカイブが公開されていたのでスレッドトップにリンクしとく）

近いうちにバグ修正されるだろうが。修正するファイル（インストーラ）は下記の2つ

installer/installer/const.pyに下記の部分を探して+のついている行を追記

@@ -38,6 +38,10 @@ SUPPORTED_DISTROS = [
("centos", "5-3"),
("redhat", "5Server-5.3"),
]
+SUPPORTED_ARCHS = [
+ "^(i[3456]86)$",
+ #"^(x86_64)$",
+]

 

installer/installer/install.pyに下記の部分を探して+のついている行を追記-のついている行を削除
@@ -140,13 +140,15 @@ def precheck(opts):
# architecture check (now supported arch is x86 only)
if ret is True:
import platform
- arch = platform.processor()
- x86_regex = re.compile("^(i[3456]86|athlon)$")
- if x86_regex.search(arch):
- pass
- else:
- print >>sys.stderr, _("ERROR: Processor '%s' is not supported by Karesansui.") % arch
- ret = False
+ arch = platform.machine()
+ for support_arch in SUPPORTED_ARCHS:
+ _regex = re.compile(support_arch)
+ if _regex.search(arch):
+ ret = True
+ break
+ else:
+ print >>sys.stderr, _("ERROR: Processor '%s' is not supported by Karesansui.") % arch
+ ret = False
return ret

投稿者 sasapurin : 19:04 | コメント (0) | CentOS , Linux , オープンソース系 | トラックバック | このエントリーを含むはてなブックマーク

トップページ > コンピュータ > UNIX系 > Linux > Redhat > CentOS

日本時間

スポンサードリンク

最近のエントリー

Movable Type

アーカイブ

Technorati

Technorati search

» ここにリンクしているブログ

アーカイブ