2008年10月31日金曜日

同じ

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
diffで同じところだけを出すのはどうしたらいいのだ?
helpを眺めて思いつかなかったので、pythonでdifflibをつかったscriptを書いてしまった。

テクノロジーにまつわる対する態度、文化

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
日本のゲーム産業はもはやトップでない


鍵となるのは「日本がものを作る力、進歩する速度を、世界の技術革新の能力が上回ったことだ」という。そして、その速度を引き上げたのが「英語圏を中心に急成長したゲーム業界のコミュニティー」だと分析する。



その構造は完結して閉じており、すべてを自社で一貫開発する垂直統合だった。2000年代に入って、ミドルウエアなどの分業化を前提とする水平モデルへと世界が移行したときに、技術革新の速度に追いつけなくなった。


垂直統合だと、人材の流動性が低い(スキルの持ち歩きがしにくい。)/ イノベーションが起こりにくい。(会社という枠にとらわれてしまう、PointyHeadを説得しようとする無駄、機動力低下)ということかな。そうなると「業界として、給料が上がらない。あがらないと人が来なくなる。人が来ないから斜陽化に拍車がかかる。」という展開だろう。

OSSがはやるのはほかでもなく、(派遣のようなインチキな流動性ではなく)本質的に人材の流動性があがるからだ。会社とエンジニアの双方にとって好ましい。経済的必然だ。

またソフトウェアはよくスケールし一度書いたものを使いまわしたいので、グラフィックライブラリの仕様ようなものは機能的に優れたものが世界で1つあればいい。世界にゲーム会社が独占1社でない以上、OSSもしくはそれに近い形、ミドルウェアという形でシェアされることは必然だ。

知識が人間の上で動くソフトウェアだとしたら、知識・知性主導である産業には同じ現象が起こるだろう。情報を発信することにおいて、権威(楊枝)よりもコンテンツ(くいもの~~)である。知識やソフトウェアを共有する手段はここ10年で劇的に変わったことを計算に入れよう。

2008年10月27日月曜日

セキュリティ監査本

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
「実践ネットワークセキュリティ監査~リスク評価と危機管理」を一応、読み終えた。
掛け値なしに非常によい本だと思う。

出版は2005年だが、スタンスというか、活動としてのあり方が具体的な作業から見えてくる。いずれにせよこの手の話は日々updateなので。この本をスタート地点に自分なりの監査プロセスを作ってまわし、情報を収集してプロセスを改善し続けないと意味がない。ヤレヤレ。

まあ、個人レベルで運用しているサーバに求められるセキュリティと金銭のやりとりが行われているサーバでは求められるレベルが違いますが。

まずは安易な穴(global側からみてopen portが存在する、fileがupできる、open relay、SQL Injectionが可能)がないことですね。

外からはhttpかssh(22ではない)しか開いていないはずなのでhttpの設定さえただしければ大丈夫なはずだが・・・。vhostでいろいろやっているのでそこが怖いかな。

databaseをつかうwebアプリの投入前には確実にしておきたい。wikiといえどもdatabaseを使うので。databaseを攻略される→権限昇格で終了なので。databaseを攻略できて権限昇格ができる人にはchrootなんて屁みたいなものでしょう。それならこちらが攻撃を検出する能力を上げることに時間を割いたほうが効果的だろう。

所詮、攻撃予算 v.s. 防御予算なのだから。

5万円のものを守るのに50万円の金庫を使う人はいないし、5万円奪うのに50万円つかう馬鹿もいない(そういう観点からは巷の強盗殺人とかはとても理解できない)。

22portに力技攻撃とかならすでにはじいている。もっとも攻撃側のコストも小さい。完全に自動化されているから。凡人が思いつくレベルの自動攻撃は防げていることだね。

攻撃側の予算は、攻撃側が攻撃の結果得る経済利益で決まる。経済利益で動かないであろう、防御を破ることに血筋をあげる古典的ハッカーを防ぐ気はないし、うちのサーバを破ったところで彼の知的好奇心は満たされないだろう。
大体、攻撃予算が5000円もあったらホームセンターに行ってドライバを買ってきて私の住んでいる家の窓を破って物理的にサーバに進入したほうが楽だろう。10万円あったら自分でハード買ったほうが安いし。違法な踏み台がほしい以外はあまりメリットがない。その場合はうちは効率が悪いはずだ。ほかに穴だらけのマシンは一杯ネットにつながっている。

というわけで、結論としては予算5000円未満のアタック from world wideを防げればO.K.
こちらの、のこりの仕事は、いかに低予算で確実にまわすかということ。
定期的なbackupと同時にスキャンスクリプトを実行するのがよいかな。

nstalkとかniktoでスキャンした結果は、バージョン以外大丈夫だったが。バージョンはCentOSをつかっている以上、どうにもならないし、同じ状況のマシンは山盛りあるはずなので。

スキャン残したlogの抜粋。なるほどなぁ~~。

- - "GET /index.cgi?action=topics&viewcat=../../../../../../../../../../../../.
./etc/passwd HTTP/1.1" 302 125 "" "Mozilla/4.0 (compatible)"
- - "GET /WebAPP/index.cgi?action=topics&viewcat=../../../../../../../../../../
../../../etc/passwd HTTP/1.1" 302 125 "" "Mozilla/4.0 (compatible)"
- - "GET /webapp/index.cgi?action=topics&viewcat=../../../../../../../../../../
../../../etc/passwd HTTP/1.1" 302 125 "" "Mozilla/4.0 (compatible)"
- - "GET /breakcal/calendar.cgi HTTP/1.1" 302 125 "" "Mozilla/4.0 (co

tarfile

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
pythonはtarをとりあつかうtarfileモジュールがあるので、先のGitPyhonと組み合わせれば、やりたいことの8割方をカバーできそうだ。

GitPython

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
GitPythonをとってきてコードを観察中。よい意味で普通なpythonコード。SQLObjectみたいに変態じゃない。

ざらっと見た感じではcommand lineで打つコマンドや引数をpython objectにしたかんじ。
tagやHEADオブジェクトがある模様。commitへのsha1アクセスはdictかな?
validなpropertyになれないだろうから。

git.HEADとかできるらしい。

class TestHead(object):
def setup(self):
self.repo = Repo(GIT_REPO)

@patch(Git, '_call_process')
def test_repr(self, git):
git.return_value = fixture('for_each_ref')

head = self.repo.heads[0]

assert_equal('' % head.name, repr(head))

assert_true(git.called)
assert_equal(git.call_args, (('for_each_ref', 'refs/heads'), {'sort': 'committerdate', 'format': '%(refname)%(objectname)'}))


今回用がありそうなのはこの辺かな?

def test_archive_tar(self):
self.repo.archive_tar

def test_archive_tar_gz(self):
self.repo.archive_tar_gz


class Repoには、archive_tarメソッドとarchive_tar_gzメソッドがある。

def archive_tar(self, treeish = 'master', prefix = None):
"""
Archive the given treeish

``treeish``
is the treeish name/id (default 'master')

``prefix``
is the optional prefix

Examples::

>>> repo.archive_tar


>>> repo.archive_tar('a87ff14')


>>> repo.archive_tar('master', 'myproject/')


Returns
str (containing tar archive)
"""
options = {}
if prefix:
options['prefix'] = prefix
return self.git.archive(treeish, **options)


class Gitにこんなメソッドがある。

def __getattr__(self, name):
if name[:1] == '_':
raise AttributeError(name)
return lambda *args, **kwargs: self._call_process(name, *args, **kwargs)

これは参考になりますね。__getattr__でlambdaをつかった無名関数を返す。
関数が第一級objectであることとは何ぞや?ということですな。

そして_call_process

_kwargs = {}
for kwarg in execute_kwargs:
try:
_kwargs[kwarg] = kwargs.pop(kwarg)
except KeyError:
pass

# Prepare the argument list
opt_args = self.transform_kwargs(**kwargs)
ext_args = map(str, args)
args = opt_args + ext_args

call = ["git", dashify(method)]
call.extend(args)

return self.execute(call, **_kwargs)

ん~~エレガント。

2008年10月26日日曜日

gitのある生活

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
運用上、rpmでpackageしてすべてyum化するので、gitで管理するブツもyum化しないといけない。一人で開発運用をやっていると、妙な環境を作って失敗して原因追及に時間を割きたくないのだ。となるとcleanにpackageを作る必要性に駆られる。


#!/bin/sh
git-archive --format=tar --prefix=gnubg-backgammonbase-edition-0.2/ -v HEAD | gzip > gnubg-backgammonbase-edition-0.2.tar.gz
rpmbuild -ta gnubg-backgammonbase-edition-0.2.tar.gz &> log

tar ballを作る機能はgitにあり(git-archive)、それをrpmbuildに渡しさえすればいい。


releaseのtagを打ったらそれ自動的に反映したversion stringを持ってほしいのだが。pythonのsetup.py bdist_rpmはどうやっているのだろう?とくに、subersionのrevisionを拾ってくる機能はありがたい。

gitではどうしたらよいのだろう。思いつくアイディアをつれづれなるままに書いてみる。

  1. version postfixを用意してあげる。

    • gitがもつsha1をつかう→×。どれだか特定はできるが、順番がわからない。

    • 日時を使う→×。古いものをcheckoutしてあとからpackageするかもしれない。

    • incrementalなtagを用意してをつかう。→?
      どうやってtagの生成を自動化するのか?



  2. version postfixをつける。

    • dirやtar ballのfile名:前出のscriptに変数を導入すればOK

    • spec file。こまった。spec fileを書き換える必要が出てくる。version 番号が埋め込まれているので。ひとつ方法としては、Makefile.amよろしく、動的に生成し、何らかの方法によってtar ballに挿入するか、rpmbuildにspec fileを別途渡すかするというもの。





とまあ、運用を視野に入れて物を作るのは面倒なのですよ。特にすべてyum一発インストールを維持しようと思うと。
もちろん、yumでインストールできるようにしてもpackageが正しくできているか検証する必要があるわけで、最近は仮想環境(VM fusion)をつかって検証しています。こいつはメンテ時の代用サーバもかねています。

あ~~あ。調べ物が多いなぁ。google先生があるだけマシなのだが。

2008年10月25日土曜日

gitのrepository, gnubg-mirror

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
http://git.tonic-water.com/
gnubgのCVSをimportしたrepositoryしかないですが。gnubgの開発チームが悟ってくれるとうれしいです。

git以外でmerge作業をやるには人生短すぎます。

2008年10月24日金曜日

gnubgのmerge

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
おわった~~。よかったなり。

autoconf

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
dnlでコメントアウトしたコードが悪さをしていた。
てか、nestって許されるのか?

7.3 Quoting を見る限りquoteが必要に読めるが?!

う~~む、AC_DEFINE自体がquoteされていないとまずいのでは?
これとかを斜め読みするとね・・・。


dnl AC_CHECK_DECLS(signbit,, AC_DEFINE([signbit(x)], [((x) < 0.0)], [define signbit]), [#include ])
dnl AC_CHECK_DECLS(lrint,, AC_DEFINE([lrint(x)], [((long) ((x)+0.5))], [define lrint]), [#include ])
AC_CHECK_DECLS(signbit,, [#include ])
AC_CHECK_DECLS(lrint,,, [#include ])


こういう風にべたべたに書けばbuildできるのだが、warningでまくり。
ガードすればいいのかな?ifndefで。

#if defined(HAVE_DECL_LRINT) && !HAVE_DECL_LRINT
#define lrint(x) ((long) ((x)+0.5))
#endif
#if defined(HAVE_DECL_SIGNBIT) && !HAVE_DECL_SIGNBIT
#define signbit(x) ((x) < 0.0)
#endif

git-bisect偉大

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
git bisect startで開始してあとはbuildしてtest、

a. 結果が悪かったらgit bisect badで、マズーとgitに教えてあげる。
b. 結果が悪かったらgit bisect goodで、ウマーとgitに教えてあげる。

repsoitoryから取り出す作業は、結果を伝えた後にやってくれる。
のーみそをまったく使わずに追い込めます。だからこの時間の作業もOK

2008年10月23日木曜日

gnubg merging(2)

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
なんとかmultithreadのところ(2007-02-01)までたどり着いたが、動かしてもloadが1cpu分までしか上がらないが・・・。rolloutじゃないからか?

gnubg merging(1)

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
change set "11/27/2006 07:43 selectable sound files(in gui)" causes --without-sound to be invalid configuration!

It undefine NUM_SOUNDS, but other part is depending on it.

and I have to add '}'.

@@ -1183,6 +1183,7 @@ play_file(soundcache *psc, const char *filename) {

/* kill after 30 secs */
alarm(30);
+ }

I bet they are not doing build tests.

2008年10月22日水曜日

はじめてのgit

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
patch元のコードのchanglogのお尻と、qgitでrev listを眺めていると、20061120 releaseのgnubgが使われていた模様。これに対してのmy patchが存在する。branchを作ってそれにpatchを当てて、そっからさきはmergeするのでよいのかな?

Open ID

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
FFTTのブログによい解説がある。

TGOpenIDLoginとその後ろでこれを支えているライブラリはいい仕事してますね。

hgに宗旨替え

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
あら~~て感じですが、ドキュメントがそろっていてpythonなので。

Fast (incremental) cvs->* conversionで、rbtreeとかが必要らしい。

当然、rpm化を考える。gem2rpmあたりか。


(LoadError)
from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
from /usr/lib/ruby/gems/1.8/gems/gem2rpm-0.5.3/lib/gem2rpm.rb:4
from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require'
from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
from /usr/lib/ruby/gems/1.8/gems/gem2rpm-0.5.3/bin/gem2rpm:6
from /usr/bin/gem2rpm:16:in `load'
from /usr/bin/gem2rpm:16

なんかうごいてねーよ。

cvs->git mirror

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
cvsのrepositoryをgitでmirrorして公開したいのだがどうしたらいいのだろう?

  • 安全であること

  • 同期を自動で取ること。cronとか


まずはgitのrepositoryの公開の仕方をしらべるか。
cvsimportだが、手元ではdiskバウンドのようだ。CPUロードもNetworkも跳ね上がってはいない。

2008年10月21日火曜日

gitでcvsをimport

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
おわらない。-oでrel-0-13を指定したのが間違いだったかな?any way、bisecしたり原因を調べたり、マージの方針を決めたりは今日一日でできる話じゃない。

まあ、rubyで7時間かかったらしいので、気長に。


gnubgはGPLなので構成管理を分離したかったし、gitを試したかったのでよかったともいう。
subversionからの移行は時間がかかるだろうが。

ほかの作業をしよう。

cvsをgitにimportする

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
あらかじめexport CVS_RSH = sshしてあるが・・・。

[nori@asama]~/Desktop/work/gnubg/git% git-cvsimport -p x -v -d :ext:anonymous@cvs.savannah.gnu.org:/web/gnubg .
The authenticity of host 'cvs.savannah.gnu.org (199.232.41.69)' can't be established.
RSA key fingerprint is 80:5a:b0:0c:ec:93:66:29:49:7e:04:2b:fd:ba:2c:d5.
Are you sure you want to continue connecting (yes/no)? y
Please type 'yes' or 'no': yes
Warning: Permanently added 'cvs.savannah.gnu.org,199.232.41.69' (RSA) to the list of known hosts.
Permission denied (publickey).
Use of uninitialized value in scalar chomp at /usr/bin/git-cvsimport line 349.
Use of uninitialized value in substitution (s///) at /usr/bin/git-cvsimport line 350.
Expected Valid-requests from server, but got:


https://savannah.gnu.org/cvs/?group=gnubgからなのだがgnu.orgの連中はverisignに金を払う気がないらしいw。

RSA: 1024 80:5a:b0:0c:ec:93:66:29:49:7e:04:2b:fd:ba:2c:d5
DSA: 1024 4d:c8:dc:9a:99:96:ae:cc:ce:d3:2b:b0:a3:a4:95:a5

サーバを認証することはできたが、こちらを認めてくれない。
まあ、memberじゃないのでしょうがない。pserverでつなぐことにするが、今度はpserverのport番号がわからないので、こちらのFWの設定を変えられない。こいつらpserverをどのportで運用しているのだろう?nmapするとレイプみたいなもんだし(笑えネ)。

2401らしいのでとりあえずやってみたら取れた。cvsでの最新版取得はできるのだが、git-cvsimportがうまくいかない。なにが原因だろう?

2008年10月17日金曜日

meaingng of life

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
Monty Pythonのmeaning of lifeを見ました。食事中の鑑賞はまったくオススメできません。

Crimsonでは、ガレー船のシーンがベンハーを彷彿とさせますな。

2008年10月16日木曜日

秋葉原偵察

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
shuttleの箱が気になりました。ありがちな箱はでかすぎるということをこの会社は理解しているようです。

gnubgクラスタを作るに使おうかなと思います。あとはLubicと裸が検討対象です。皮はほしいなぁ、ショートとか嫌だし。Atomでmini-ITXという手もあるが、Atom非力すぎ。歴史シム:シヴィライゼーション4が遅いのは痛い。グラフィック性能が足りなくて遅いのではなく、本質的に遅いのだ。gnubgのクラスタを作るにはcore 2 quadは必須のようだ。

石はコストパフォーマンスからしてQ6600だろうなぁ。Extremeは高すぎ。8coreとかあればいいのに・・・。memory useは2Gのマシンで2.4%だから40Mってことかな?guiを抜いてbuildしたら軽くなるかしら。小さなキャッシュでも十分に機能してほしいし。現状、pythonのインタプリタとgtkが入っているしなぁ・・・。

Mac関係:このキーボードには萎えました。外観しか考えてないでしょ、これ。家で使うマシンのDellのReplaceは開発マシンに使っているマウスをキャニスターに乗せて使うかなぁ。空いたラックにshuttleを詰め込む。3画面化もしたい。いま2画面だが、すでに狭く感じる。まあ、ssh+vncを同時に4つとweb browserの窓4つとかいうことしてるからなんですけどね。

なにも買わずに本屋へ。Hack本を大量購入。

  • pdf hack: やっぱりpositionとかblog entryをpdf出力したいので

  • blog hack: ユーザ視点を学ぼう

  • web解析 hack: 何でいままで持っていなかったのだろう。

  • サーバインフラを支える技術



秋葉原まで歩き回って大変健康的でした。

2008年10月15日水曜日

インパクトでかっ!

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク

Dependencies Resolved

=============================================================================
Package Arch Version Repository Size
=============================================================================
Updating:
TurboGears noarch 1.0.4.4-2.el5 epel 2.0 M
image-server noarch 1.0.rev_r2014-1 prod.backgammonbase 124 k
python-bglib-library noarch 0.0.3.rev_r2018-1 prod.backgammonbase 4.4 M
python-decoratortools noarch 1.7-1.el5 epel 27 k
python-formencode noarch 1.0.1-2.el5 epel 344 k
python-simplejson x86_64 1.9.1-1.el5 epel 96 k
python-sqlobject noarch 0.9.7-1.el5 epel 479 k

2008年10月10日金曜日

Dual Login(実装その1)

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
quick startの時にidentityを指定して生成したmodel.pyの中にあるUserに足してあげます。

auths = RelatedJoin('Auth', intermediateTable='user_auth',
joinColumn='user_id', otherColumn='auth_id')
def _get_password(self):
for a in self.auths:
if isinstance(a, ClassicAuth):
return a.password
return None
def _get_user_name(self):
for a in self.auths:
if isinstance(a, ClassicAuth):
return a.user_name
return None
@classmethod
def by_user_name(cls, user_name):
auth = ClassicAuth.by_user_name(user_name)
assert len(auth.users) < 2
for u in auth.users:
return u
return None

@classmethod
def get_by(cls, auth):
assert len(auth.users) < 2
for u in auth.users:
return u
return None

_get_user_nameと_get_password、by_user_nameはあらたに作るAuth ClassからTurboGearsのidentityがおこなうpasswordによる認証に情報を転送してもらうのに使います。


つぎにAuth関係のclassです。

class Auth(InheritableSQLObject):
users = RelatedJoin('User', intermediateTable='user_auth',
joinColumn='auth_id', otherColumn='user_id')
def flush(self):
pass

class OpenIDAuth(Auth):
url = UnicodeCol(length=255, alternateID=True,
alternateMethodName='by_url')
@classmethod
def get_by(cls, url):
try:
return cls.by_url(url)
except SQLObjectNotFound:
return None


class ClassicAuth(Auth):
user_name = UnicodeCol(length=40, alternateID=True,
alternateMethodName='by_user_name')
password = UnicodeCol(length=40)

def set_password_raw(self, password):
"""Saves the password as-is to the database."""
self._SO_set_password(password)
def _set_password(self, cleartext_password):
"""Runs cleartext_password through the hash algorithm before saving."""
password_hash = identity.encrypt_password(cleartext_password)
self._SO_set_password(password_hash)

ClassicAuthの中身はもとからあるUserのメンバをかっぱらってきただけです。
あまりいうことはないでしょう。

最後にcontrollerです。OpenIDLoginControllerに手を加えます。__init__にauth_classも渡すようにします。んで、loginFinishをつぎのように書き換えます。元のコードは、User::user_nameにopenid_urlを突っ込むという横着がされていますが、これをAuthというレイヤーを導入することでもうちょっとマトモにしただけのことです。

if response.status == 'success':
openid_url = kws['openid.identity']
auth = self.auth_class.get_by(url=openid_url)
if not auth:
auth = self.auth_class(url=openid_url)
assert isinstance(auth, model.OpenIDAuth)

info = response.extensionResponse(self.sreg_uri, require_signed=False)
# User object needs to handle this attribute if it wants to do anything
# with the data
assert isinstance(info, dict)

u = self.user_class.get_by(auth=auth)
if not u:
if info.has_key('email'):
email_address = info['email']
else:
email_address = openid_url
if info.has_key('nickname'):
display_name = info['nickname']
else:
display_name = openid_url #ugh!
u = self.user_class(email_address=email_address, display_name=display_name)
u.addAuth(auth)


もっと手間取るかとおもったが、やる気が降臨したら一瞬だった。

2008年10月8日水曜日

Dual Login デザイン案

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
auth(仮称)というクラスを用意して、そいつにlogin/logoutを持たせる。
loginの引数はvisitとログインのタイプ(openid or classic)を指定する整数値。
整数値を受け取っているのでまあ、Factoryに近いなぁ。クラス自体を渡しても悪くはない。
肝はcontrollerから呼ぶときのIFがそろっていることと、認証に用いるデータを保持するTableが見えないことだ。

中でauthopenidとauthclassicの2つに分けて(継承する?)それぞれの処理をする。
controllerかmodelかはっきりしないなぁ・・・。login処理が終わったときは
User(tgのidentityでデフォルトで用意されるもの)とVisitを関連付けるVisitIdentiryを関連付ける。関連のづけるときのプロセスはおのおのの中で実装。

2008年10月7日火曜日

Dual Login

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
ustreamのようにOpenIDとUsernameとPasswordなclassic loginの両方をサポートするのはさくっとはできないようだ。前者だけなら、TGOpenIDLogin - an OpenID consumer for TurboGears applicationsですぐ終わりなのだが。


OpenIDLoginController(User, VisitIdentity)

とかなっているが、VisitIdentityから先がidentityの中でずるずると依存しているので、Userをまったく別のUserに差し替えることはできない。

2008年10月6日月曜日

maraDNS

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
maraDNSをport53以外で動かす方法ってないの・・・。
まあ、routerでforwardしてサーバを公開する人は多数派じゃないのだろうから仕方ないが。

台数が増えてきてhostsでは手に負えなくなったので、ローカルのnameの管理をどうにかしたいのだが、外部に公開するIP addressとLANから参照するときに使うIP addressが異なるので困ったものだ。

仮想化OSの使い方?

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
侵入者の足場としてブリッジされたguest OSを用意されるとネットワーク図にないIPを持ったマシンがあることになるなぁ・・・。仮想化OSのHost側のlistされなければけっこう都合がよいのかもしれない。リソースの関係でHost側に十分な浸透が必要だが・・・。

2008年10月5日日曜日

RPMとeggの狭間で

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
eggさんはRPMと仲が悪いのです。RPMの中身なんてしったことじゃないし(platformに依存しない、python上での依存関係処理機構なので当然)。

そのくせ一部のパッケージはRPM化したときにeggのrequire.txtと整合性がなくてRPMを入れただけでは動かなかったりする。(TGのKidまわりとか。まあ一行コメントアウトするだけなんですが)

で、問題はsetuptoolsをつかったときにeggを見て依存関係を解決しようとするので、それを使ったパッケージングでRPMを作っても依存関係がeggで記述されてしまう。RPMの依存関係が手に入らない・・・。直接的に書くかなぁ。


distutils.command.bdist_rpm.pyの中をみて適当に見繕って、setup()に渡してみる。
かんけいありそうなのはこの辺だ。

('provides=', None,
"capabilities provided by this package"),
('requires=', None,
"capabilities required by this package"),
('conflicts=', None,
"capabilities which conflict with this package"),
('build-requires=', None,
"capabilities required to build this package"),
('obsoletes=', None,
"capabilities made obsolete by this package"),
('no-autoreq', None,
"do not automatically calculate dependencies"),

見当がはずれたようだ・・・。

2008年10月4日土曜日

ECC Recovered of SMART

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク


diskを変えて以来、下がりました。
「ECC(誤り訂正符号)によって検知されたエラーの回数」らしい。

ほかのbuddyのECCも減ったので、掃除の結果、温度が下がったのことが理由かもね。

VMWareのguest osの通信

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
外からrequestを受け取るつもりなら、NATするよりBridgeするほうが、楽だ。
なにせ直接IPをもてるので。このへんhttp://www.naguru.com/tech/page1/page3/tech3.htmlが参考になります。


ところでこのBridgeした場合のarpってどうなっているのでしょうね。

2008年10月3日金曜日

disk 不良(3)

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク

また再構築です。まあ、ユーザ側から見えませんが。

disk 不良(2)

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
前にもDiskを交換していた。

半年くらい前だ。http://blog.tonic-water.com/2008/02/hdd.html

さてそのときどのdiskを交換したのか?が気になる。同じ場所のdiskなら筐体に絡んで機械的・構造的な問題があるということだろう。

違う場所なら別の原因だ。

それから次のDisk交換が終わったら、raidの組みなおしを検討せねば。

あとはサービスの退避の方向を検討せねば。yakumoのVMWare上でCentOSを実行してそこに流すかな。ネットワーク周りの設定でハマリそうだが。

・・・

http://blog.tonic-water.com/2008/02/rebuild.htmlにある画像を見る限り、0番が交換されていたようだ。
4番とpairになるdiskだ。これから考えるに、disk accessが偏っておきていて、それが0番4番pairの負担が大きくなっていたのではないだろうか。disk使用率も30%以下だろうし。

ともあれ、機械的原因でなくてよかった。

disk 不良

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク


気づくのが一週間遅れた・・・。
smartctrl_exit_status 32の意味をしらべるですよ。まあ、交換は確定なのですが。

http://hddbancho.co.jp/longevityof_hdd.html
またメーカーである日立も起動回数と動作温度が寿命決定に重要だと言い切っていることから、大方の意見と真逆の起動回数説を筆者は取りたい

あげっぱなしのほうが安全らしい。メカは定格運転すべしといったことか。OnOffの多いNotePCにSSDを搭載することは理にかなってますね。SSDの読み書きの限界よりも先にHDDがへたる可能性もありますから。

http://hddbancho.co.jp/deteriorationandmeasuresof_hdd.html。。。google HDD白書を読んで4in3ユニット変えたなあ。。。壊れたときらくなより、壊れる確率を下げる方向でいったからなぁ。まあ50度以下をおおよそキープできていたので、家庭においてあるサーバとしてはまあまあなんではないでしょうか。

2008年10月1日水曜日

debugに便利かも。

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
http://web-sniffer.net/
これでheaderの確認が簡単にできる。FTTH一本でもOK。ADSLが必要かと考えていたところだ。