2006年01月30日

Fedora Core3でのWikiの使用

本来は障害対応の手順を解説する予定でしたが予定を変更ます。
Fedora Core3でのWikiの設定にてこずったので,備忘録として書いておきます。

Wikiを使ってみようとインストールしたのですが,うまく動きません。
別件で使用しているレンタルサーバには簡単にインストールできました。どうもWikiのインストールが下手だからというわけでもないようです。
どうもファイルの書き込みでエラーになるようです。しかも,/tmpへは書き込みできるのに,htmlの下には書き込めないようです。

なぜ,こんな現象が発生するのか。
調べたところ,SELinuxが原因と判明しました。

SELinuxでは,ファイルの読み書きに制限を与えます。そのため,CGIやPHPからファイルの書き込みを行うとエラーとなります。
エラーにさせない方法は二つ。

  • SELinuxを使わない
  • SELinuxでhtmlを書き込み可能とする
今回は一般公開しているサーバでもなかったし,調べるのも面倒だったので,SELinuxを使わない方法で対処しました。

まず,SELinuxを使用しているか調べます。

[root@localhost ~]# getenforce
Enforcing

Enforcingと表示されたらSELinuxが有効となっています。 これは,setenforceコマンドで無効にできます(setenforce Permissive)。
しかし,setenforceコマンドではOSを起動するたびに設定する必要があります。
そこで,/etc/sysconfig/selinux を編集し,起動時にPermissiveモードに設定してもらいます。
具体的には SELINUX=enforcing の行をコメントにし,SELINUX=permissive を追加します。

[root@localhost ~]# vi /etc/sysconfig/selinux
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - SELinux is fully disabled.
#SELINUX=enforcing
SELINUX=permissive
# SELINUXTYPE= type of policy in use. Possible values are:
#       targeted - Only targeted network daemons are protected.
#       strict - Full SELinux protection.
SELINUXTYPE=targeted

これで問題なくhtmlの下に書き込めるようになり,Wikiも動作するようになりました。
もうひとつの方法は別の機会に紹介します。


posted by まる at 00:46| Comment(0) | TrackBack(0) | プログラマ Chips | このブログの読者になる | 更新情報をチェックする

2006年01月24日

障害解析手順

最近プロジェクトに配属された新人と話していたら,障害が発生した場合の対処方法を知らないと言われました。
このサイトを見て勉強しろ!と言おうと思い,過去の記事を調べたんですが,まだ書いてなかったんですね。
とっくに書いたつもりになってました。

そこで,今回は障害解析手順を説明します。

  1. 現象の確認
    顧客は「よく分からないけど、動かない」といってくるので,現象を明確にします。
    ・「動かない」と主張しているのは、どのような状況なのか。
     エラーメッセージを出力しているのか,アプリケーションが無応答となっているのか,OSがフリーズしているのか
    ・障害が発生する直前にした操作は何か。
     障害の発生した直前の操作に、障害解析のヒントが隠されています。どのような操作をしたかは教えてもらいましょう。
この時点で既知の不具合や,仕様の場合は分かるかもしれません。
  1. 資料採取
    OSがフリーズしていおらず,画面に何か出力されているのであれば,Alt+PrintScreenで画面のスクリーンショットを取ってもらいます。
    同時に使用しているOSのログ(Linuxだったら/var/log/以下のファイル,Windowsだったらイベントビューアの内容)も念のため送付してもらいます。
    イベントビューアは[名前を付けて保存]でファイルの種類をテキストまたはCSVにして出力してもらいます。イベントログ形式は,そのPCでしか出力されないメッセージがあるのでNGです。
    システムがログを出力していれば,ログを送付してもらいます。自分の作成したシステムでは,ログだけで障害が解析できるようにしておくべきです。
できれば,このフェーズまでで障害原因をつきとめたいところです。
そうもいかない場合は次に進みます。
  1. 開発環境での再現実験
    顧客から聞いた情報と資料をもとに再現実験を行います。開発環境で再現するようであれば,開発環境で原因の追究を行います。

  2. 実運用環境での再現実験
    障害が開発環境では再現できないけど,顧客環境で再現できるのであれば,実運用環境で再現実験をするしかありません。この場合,なるべく少ない回数で原因を追究できるようにしましょう。状況がゆるすのであれば,罠かけ用モジュールを設置するのも一つの手段です。
それでも駄目なら最後の手段です。
  1. あきらめる
    実運用環境でも再現しないのであれば,次回の障害発生に期待するしかありません。今回の解析で原因を絞り込めなかった理由を追求し,ログの出力を追加する等の対策を行い,次の障害発生を待ちます。

5はただの逃げなので,1,2ででどうにかしたいところです。マルチスレッドやメモリ破壊の問題は再現しづらく,原因も絞込みにくいので,原因不明のままになることも多いのですが…。力不足を感じます。

posted by まる at 00:36| Comment(0) | TrackBack(0) | プログラマ Chips | このブログの読者になる | 更新情報をチェックする

2006年01月17日

助け合いの精神を

プロジェクト管理なんて仕事をしてると,プログラマからいろんな相談を受けることになります。
機能要求が実装と合わないので,機能要求を実装に近くなるように調整してくれとか。実装アルゴリズムの相談に乗ってくれとか。果ては期日に間に合いそうにないので,助けてほしいとか。

アルゴリズムの相談のような,プロジェクトマネージャーの仕事じゃないと思える相談も混じっています。しかし,悲しいことに相談を断る権利はプロジェクトマネージャにはないのです。プロジェクトマネージャには仕事の範囲なんてありません。みんなの雑用係がプロジェクトマネージャーです。

その場では断れても,問題が顕在化した際に責められるのは筆者です。プロジェクトが失敗してから上司に怒られるよりは,プログラマと友好な関係を築いておいたほうが,精神的にも楽じゃないですか。ついでに貸しを一個つくれるわけですし。

プログラマの皆さんもプロジェクトマネージャが他のプログラマのことで困っていたら助けてあげましょう。きっと,プロジェクトマネージャからの信頼と,たくさんの仕事が待っていることでしょう。運がよければ給料をあげてもらえるかもしれませんよ。あ…そこ,逃げていかないで。

posted by まる at 01:24| Comment(0) | TrackBack(0) | 管理者 Chips | このブログの読者になる | 更新情報をチェックする

2006年01月10日

美しいコード

プログラマはコードの美しさを語りますが,プログラマ以外の人種からは何が美しいのかさっぱりです。 ときどき人からも聞かれるので,コードの美しさについて分析してみましょう。
  1. 読みやすいコード

  2. これはフツーの人でも理解できます。ソースコードを見れば一目瞭然。
    コーディング規約に従って書いてあるようなコードです。コーディング規約ではクラス・変数の命名規則,中括弧の取り扱い,インデントの間隔(タブ/空白4文字等),コメントのつけ方,Javadoc用コメントの有無,現場によっては関数当たりのステップ数や,空行の入れ方まで規定してあるようなものもあります。
    コーディング規約で統一していると,プログラマごとのコードのクセがなくなり,ソース全体が読みやすくなります。が,自分の好きなスタイルでしか書かないプログラマがいると簡単に崩壊します。ソースコードのレビューなどで,ソースをチェックしておくべきでしょう。

  3. 変更しやすいコード

  4. プログラムはしょっちゅう仕様が変わります。そこで,あらかじめ変更が見込まれる部分は,変更しやすいようにしてあるコードです。定数は変数としておき,データ間の関係を疎にし,データとアルゴリズムの間の従属性を減らします。
    仕様変更がかかってプログラムを修正する際に,あまりに簡単に変更ができるため,「美しい…」と言葉がでます。
    変更しやすいコードを書くプログラマというのは,えてして変更に弱いというのも面白いところです。

  5. 論理的に簡潔なコード

  6. ここまでくると,プログラマ以外には理解しづらいでしょう。プログラムではさまざまな条件分岐や繰り返しがあります。たとえば,xの値が0.3と0.5の場合はAの処理をして,xの値が1.5と2.0の場合はBの処理をする処理を書く場合を考えます。
    提示された条件を満たすだけであれば,0.3と0.5の場合を書いて,1.5と2.0の場合を書けば問題ありません。 if( x == 0.3 || x == 0.5 ){
      A();
    } else if( x == 1.5 || x == 2.0 ){
      B();
    }
    そこを一歩ひねって抽象化します。この場合は,xが1より大きいか小さいかにより分けてみます。 if( x < 1 ){
      A();
    } else {
      B();
    }
    こんな簡単な例だと当たり前のように思えます。しかし,複雑な条件を簡潔にまとめたコードを目の当たりにすると,思わず「美しい…」という言葉が漏れてしまいます。自分が書いたコードだったら,自分をほめたい気分になります。
posted by まる at 00:02| Comment(0) | TrackBack(0) | プログラマ Chips | このブログの読者になる | 更新情報をチェックする

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。


×

この広告は180日以上新しい記事の投稿がないブログに表示されております。