ちょwwwwはやwwwwww ― 2008年04月16日 10時50分46秒
harapeko.jp の後継サーバはこいつにしてみました。専用サーバのくせして安いのはいいが、CentOS プリインストールのまま何もいじってないしコントロールパネルみたいな便利なものもセキュリティやら監視やらの特別なサービスもなあんもないよー、全部 ssh で設定がんがってねーという、実に漢らしいサービス内容に惚れ込みましたw。収容データセンターがソフトバンク IDC だってのが微妙に気にはなりますが。。。
で、オンライン登録時に「納品できるのに 2週間ぐらいかかります」とか表示されてたので、まぁ現行 harapeko.jp ドメイン消滅やら登記完了やらが重なってむしろ丁度いいかな、設定に時間かかったらドメイン取り直したのにもてあましちゃってあれかもしれないけど、とりあえず気長に待つかぁ、とか思っていたわけですが、登録した翌日には納品書が届きましたよ。これにはさすがに驚いた。設定も完了していて、既に自由に使える状態に。これはうれしい誤算だ。w
そんなわけで、取り急ぎ、apache だけ設定を済ませてみました。いや、 mod_perl とか組み込んでないし全然完璧じゃないですが、とりあえず動いてるっちゅーことで。
sendmail と sftp も設定しちゃわないとなぁ。。。
さくらレンサバに入れたTracから通知メールが飛ばせない ― 2008年04月03日 16時05分58秒
前々から使っているさくらレンタルサーバ上に、最近 Trac を入れて使おうとしているのですが、メール通知の設定をしても、通知メールがうまいこと飛んでこなくて困っています。
trac.ini の [notification] ディレクティブの設定内容は以下の通り (ドメイン名、メールアドレスは便宜上変えてあります)。
[notification] always_notify_owner = true always_notify_reporter = true always_notify_updater = true mime_encoding = base64 smtp_always_bcc = #smtp_always_cc = example@example.sakura.ne.jp smtp_default_domain = smtp_enabled = true smtp_from = example@example.sakura.ne.jp smtp_password = smtp_port = 587 smtp_replyto = example@example.sakura.ne.jp smtp_server = example.sakura.ne.jp smtp_subject_prefix = __default__ smtp_user = use_public_cc = false use_short_addr = false use_tls = false
smtp_always_cc のコメントアウトをはずすと、そこで指定したメールアドレスがレンタルサーバー上に設定されたアドレスであれば、そのアドレスにだけはメールが届きます。
smtp_always_cc をコメントアウトしたままの場合、以下のような動作になるようです。
-
Ticket の報告者がレンタルサーバー上に設定されたメールアドレスを設定している場合、通知メールは問題なく配信される。
-
Ticket の報告者がレンタルサーバー外の (例えば ISP などが提供する) メールアドレスを設定している場合、通知メールは届かない。そして、
log/trac.logには以下のようなエラーログが出力される。2008-04-03 16:13:26,873 Trac[web_ui] ERROR: Failure sending notification on change to ticket #3: {u'murachi@example.ne.jp': (553, '5.3.0 <murachi@example.ne.jp>... Please receive your mail before sending')} Traceback (most recent call last): File "/home/example/local/lib/python2.4/site-packages/trac/ticket/web_ui.py", line 562, in _do_save tn.notify(ticket, newticket=False, modtime=now) File "/home/example/local/lib/python2.4/site-packages/trac/ticket/notification.py", line 129, in notify NotifyEmail.notify(self, ticket.id, subject) File "/home/example/local/lib/python2.4/site-packages/trac/notification.py",line 216, in notify Notify.notify(self, resid) File "/home/example/local/lib/python2.4/site-packages/trac/notification.py",line 115, in notify self.send(torcpts, ccrcpts) File "/home/example/local/lib/python2.4/site-packages/trac/ticket/notification.py", line 275, in send NotifyEmail.send(self, torcpts, ccrcpts, hdrs) File "/home/example/local/lib/python2.4/site-packages/trac/notification.py",line 368, in send self.server.sendmail(msg['From'], recipients, msgtext) File "/usr/local/lib/python2.4/smtplib.py", line 691, in sendmail raise SMTPRecipientsRefused(senderrs) SMTPRecipientsRefused: {u'murachi@example.ne.jp': (553, '5.3.0 <murachi@example.ne.jp>... Please receive your mail before sending')}
別に通知機能自体は今すぐ必要なわけではないんですが、何でこうなっちゃうのかだけは一応知っておきたいので、とりあえずメモってみます。。。
そもそもさくらのレンサバの sendmail がそういうものなのかなぁ。。。あ、ちなみに smtp_port が 587 になってますが、25 のままでももちろんダメでした。
とりあえず調べてみたらエラーの内容はなんとなくわかってきた。
SMTPRecipientsRefusedは、 Python のモジュールsmtplibが送出する例外で、すべての受取人が (sendmail コマンドによって) 弾かれた場合にのみ発生するらしい。- ログの最終行の
553という数字は、 sendmail コマンドが返すエラーコードで、不正中継っぽいもの (spam の踏み台である可能性があるケース) を弾いたときのものっぽいです。
さくらのレンサバの sendmail コマンドのポリシーがどうなってるのかがいまいちよくわからんのですが、その辺の設定が仮に変えられるのだとして、その為に spam の踏み台になるリスクが生まれるんだとするとそれはさすがにまずいので、この辺は良く調べてから対応したほうがよさそう。そもそも回避できないのかもしれないけど。。。
当面は通知なしで運用しようかな。(←ひよったw)
はまちちゃんとこに IPA からよくわからないメールが届いた件 ― 2007年02月06日 00時24分12秒
??? なんか、お礼のメールが来たみたいだけど、これってよーするに「受理しました」ってことなの? それとも「受理はしてない (だから仕事はしない) けど、とりあえずお礼のメールだけ返してうやむやにしておきます」ってこと? おいら、じぇんじぇんわかりましぇん >< 。
受理された脆弱性はその概要がここに表示されるらしい (Tue Feb 6 10:43:43 JST 2007 追記: Web サイトの脆弱性はここに表示されるわけではないっぽいです。謹んで訂正) んだけど、はまちちゃんとこにきたメールに書かれてるような書式の ID は見当たらないし、Yahoo! がどうこう、なんて記述も見当たらないし。。。
はまちちゃんが言いたいこともわかるけど (おいらも一部似たようなこと書いたし)、その気持ちが IPA たんには伝わりにくそうな態度しかとってなかったっていう意味では五十歩百歩かなぁ。面白かったけど。
とにもかくにも、IPA がちゃんと仕事をしてくれることを願ってやみません。。。
はてブのコメントにて指摘がありました。JVN はあくまで「ソフトウェア製品の脆弱性関連情報」を扱うサイトであって、Web サイトが脆弱であることに関連する情報を扱っているわけではない、ということかと思われます (なのよね?)。謹んで訂正。。。
ああ、そうか。 ― 2007年02月03日 10時22分32秒
このコメント書いてから、ふと思ったんだけど、氏名公表しちゃっても構わない人が、氏名公表したくない人の代わりに報告してあげればいいんだ。
ちうわけで、ぜーじゃくせー発見したけど IPA に氏名公表したくない、ってひとは、以下のアドレスまでその内容をメールしてくだちゃれ。暇だったらおいらが代わりに IPA に報告するかもしれないし、しないかもしれませんw
main-window (あ) harapeko.jp
# はまちちゃんにもメールしてみますた。
リファラースパムがどーたらこーたら ― 2007年01月21日 00時54分02秒
んー、よーするに Referer が本当にリンク元になってるかどうか、その URL にアクセスして調べるようにすればよくね? なんて言ってみる。まぁ、大手サイトだとそんなん重くてやってらんないだろうけど (トラックバックの「言及リンク」チェックほど甘くは無いか)。
うちみたいに、月 10,000 PV 行かないようなサイトならそれなりに有効な気がする。
アクセスログ調べるときにうざいって言うだけの話なら、統計取るときに調べてはじくスクリプト書けば ok だわね。
綺麗なコードを心がける。 ― 2007年01月13日 03時45分00秒
- キミのコードが汚い理由 (@IT)
賛否両論出ているようですが。。。おいらとしては概ね賛同。
コードを綺麗に書くことによって得られる最大の利点は、メンテナンス性にあります。可読性の低いコードは、修正や拡張が困難になる。ソフトウェア資産は蓄積されてゆくものだから、メンテナンス性の低いコードが量産されれば、それをメンテナンスし続ける企業にとっては不良債権にもなりかねないわけです。
実際それが原因で一方的に契約を切られた挙句、1年間近く無償の瑕疵保証対応に駆り出され続けた某社の人たちを現場で見てきたわけですが。。。
で、話を記事のほうに移すわけですが、冒頭のサンプルプログラムに対する批判が多いっすね (^_^; 。客観性を排除してこのサンプルに限って議論するなら、リスト 2 が優れているのは、二人のプレイヤーの対称性、可換性を、うまく表現している点にあると思う。「一般化できる問題は、できる限り一般化する」というのはプログラミングにおける基本中の基本。プレイヤー 1 よりプレイヤー 2 の方が勝っている場合と、逆の場合とで、別個にコードの記述が存在するようでは、後の仕様変更で、片方のケースしか仕様変更が適用されなかったというミスに繋がりかねない。これを「メンテナンス性の欠如」と言わずして、なんと言おうか。
但し、リスト 1 の方が、リスト 2 よりも可読性は高そうだ。恐らく、このサンプルがいまいち納得されにくくなっている一番の要因は、この点にあるんじゃないかと思う。リスト 2 に対しては、適切なコメント付けが必要になるんではないかと思う。逆にいえば、適切なコメントが追加されるのであれば、リスト 2 がリスト 1 より劣っていると言える理由は、他にはなくなるんじゃないかと思う。インデントに関する好みとか、細かい部分での意見の分裂はあるかもしれないけど。
汚いコードができる理由については、最初、3 つの項目を見たときには、「なんか微妙に体育会系っぽい意見だなぁ」とか思ってしまったわけですが、読み進んでいくうちに概ね納得しました。まぁ、プログラミングって、キータイプが速けりゃ仕事も早く片付くってもんでもないし、一般化・抽象化できる要素を洗い出す作業に時間をかけるより、コピペしちゃったほうが早い、ってのも確かなんだよね。ブラッシュアップ工数を見積もりに計上したいってのが、多くの開発者にとっての本音でもあり。。。
学習については、、、おいらの体験談を明かすならば、大学ではもっぱら C と BASIC とアセンブリ言語ぐらいしか講義としては扱われなかったってこともあって、当時 C++ や Java で取り入れられ始めていた「例外」って概念を知らなかった。入社一年目の仕事で、とある C++ で書かれたプログラムのメモリエラー検出を、new 演算子が返すポインタの NULL チェックでやるのをやめて、bad_alloc 例外を検出する方法で書き直そう、という話があって、そのときおいらが担当していたモジュール (NG 喰らった前任者が残していった、それこそ不良債権w) でも対応作業を行ったわけですが、なんだか 2000 行近くある関数内の至るところに new が散りばめられていて (^_^; 、まぁ、関数内全部 try で括っちゃえばよかったんですが、それをやらずに散りばめられた new ごとに対応する try ~ catch を書いて、なんてことをやっていたら、後のコードレビューで流石に顰蹙買ってしまいまして、なんてことをやらかしたこともあったもんで、、、ただ体験的に綺麗なコードを書くことを心がけることの重要性を知らしめるのも重要っちゃ重要なのですが、やっぱりプログラミングスタイルを決定付ける様々な概念に対して、知識を深めることもまた、同時に同じくらい重要なんだろうなぁという気はするのでありまする。
熱意ってのは、よーするに優先度の問題ってことかな。大切なことだとは分かっていても、どうしても軽視してしまいがち、ってのはあるかもしれないね。だからこそ、それを適切に評価する機会を設けるってのは、大切なことだと思う。コードレビュー、ちゃんとやってますか?
無線LANセキュリティ関連メモ ― 2006年12月28日 00時38分51秒
- 訂正ありご注意→セキュリティのセの字も考えてないライブドアの公衆無線LANサービス (Web屋のネタ帳 さま)
MACアドレスのよくある誤解その2: 「MACアドレスはその機器(PC等)の持ち主しか知りえない」
そんなわけない。Windowsのコマンドプロンプトを開いて「arp -a」とたたいてみよう。
- livedoor Wirelessのラの字も考えてないWeb屋のネタ帳の誤読記事 (最速インターフェース研究会 さま)
実際のところは事前にWEPキー(申込み時にユーザー毎に割り当てられる10文字程度の英数字)を機器にあらかじめ設定しておくことが必要
これも間違い。そういう形態でサービス提供することは不可能だと思う。書いていい話なのかどうかわからないけど自分が知る限りlivedoor WirelessのWEPキーはユーザー毎ではなく全ユーザー共通。これは低価格の公衆無線LANでは(たぶん)一般的なんじゃないかと思う。複数使い分けられるのはあった気がする。 - livedoor Wirelessの話の続き (最速インターフェース研究会 さま)
2. 技術的な抑止力があるかどうか
担当者じゃないんで知りませんが、同じMACアドレスが物理的に離れたアクセスポイントで使われてたら不正利用だってのはわかるよね。あとMACアドレスで製品名わかるはずなのでゲーム機でSPAM送信してたらおかしいとか、そういう。 - HiromitsuTakagiのブックマーク / 2006年12月27日
不正アクセス禁止法2条の定義の「識別符号」。ISBN4-8037-0915-7によると「識別符号は利用権者等に付されるものでなければならない」「機器に付される識別情報は識別符号に該当しない」とあるが、3条2項2号に該当するか?
なるほど。。。いろいろと勉強になりますた。そんだけ。w
そういやおいらの周囲には NDS 持ってる人が結構いるから、このへん↓もついでにリンクしとこう。
- ニンテンドーDS を考慮した無線 LAN のセキュリティ設定 (Landscape - エンジニアのメモ さま)
- 暗号化に WEP しか使えないニンテンドーDS は無線 LAN のセキュリティを弱くする (同上)
不安な方は設定修正いたしまする。>関係者各位
議事録ドリブン ― 2006年12月13日 11時37分16秒
- eXtreme Meeting
- 「議事録ドリブン」で会議の生産性をあげるツール登場 (CNET Japan)
まずはツアーを見て頂きたい (ナレーターおねーちゃんの絵が微妙だとか言うな)。Sargasso XM というツールの出来についてはどうかは知らないが、この「議事録ドリブン」という考え方は圧倒的に正しいと思うし、そのスタイルを強制する為のシステムであるという点に大きな意義があるように思う。
この製品を使わずとも、職場の人間に、先のツアーを見せてあげるだけでも、次回以降の会議がかなり有意義なものになるのではないだろうか。
- 会議とは、議事録を共同で作成する作業である。
- 会議はテーマを明確にし、そのテーマに沿った議論のみを行うべきである。
- 会議の目的は議論ではなく、結論を出すことである。
経営情報 ― 2006年12月07日 11時00分42秒
- オープンシステム移行による弊害を断罪する (@IT)
経営情報学についてはあんまり興味のないおいらなのですが、上記記事が結構面白かったので、著者の方のサイトを覗いてみました。
経営と情報に関する私の主張の中で、ERPパッケージ批判という記事があり、まだこれぐらいしか目を通していないのですが、これがまた面白い。要チェックです。
Yahoo! ブログの転載機能 ― 2006年12月07日 03時04分37秒
TB どもです。やっと話が見えてきました。
なるほど。Yahoo! ブログには、Yahoo! ブログシステムローカルで機能する「転載」機能が存在し、転載したい記事の「転載」ボタンを押すだけで、自分の Yahoo! ブログに記事を転載できるようになっている。この機能を中心とした話題だったわけですね。
昔、試しに使っていてそのままにしていた Yahoo! ブログがあったので、自分のブログだけで転載機能を試してみました。
自分で試して見て解った点を以下に列挙します。
- 転載機能を用いてコピーした記事は、編集できない。転載時の内容がそのまま保たれる。
- 上記で転載元と転載先の内容が異なるのは、転載を行ってから転載元を編集しなおした為。この場合、現時点では、転載元と転載先の記事は同期しない模様 (つまり、ハードリンクのようなものではなく、あくまでコピーであるということ)。
- オリジナルの記事を作成もしくは編集時に、転載機能を許可するか拒否するかを設定可能。
- 転載機能によってコピーした記事は編集できないため、転載を拒否する設定に変更することはできないっぽい。転載元の記事がコメント・トラックバックを受け付ける設定の場合は、これらも拒否する設定には変更できないっぽい。
この機能を実装した Yahoo! は、サーバーのキャパシティによほどの自身があるのでしょう。。。
個人的な見解を申し上げます。
Yahoo! ブログが機能として提供している以上、Yahoo! ブログシステム内の仲間同士で、この機能を用いて記事の転載を行いあうこと自体は、多くの場合、それほど問題は無いように思います。
ただ、「転載」という用語自体はごく一般的なものですので、「ご自由に転載してください」のような記述をした場合、Yahoo! ブログ以外のブログ等をもつ人が、手動で記事をコピーし、転載する行為も認めることになるという点には、注意する必要があるかもしれません (Yahoo! ブログが SNS だったならば、問題にはならないのですが)。
あとは、まぁ、各自の良識の範囲内で使われればよろしいのではないかと思います。





最近のコメント