RHELでkudzuデーモンはoffにしませんか？

linuxジプシーです。とある大企業系列のサーバ設計に携わった時にRHELのchkconfigの設定でkudzuは再起動時に時間がかかるので構築終了時にoffにすることとしました。
しかし今度の現場（日系大企業）の設計ではonです。設計部門に設定根拠を示してもらいたいのですが、なにぶんぺーぺーなもので自信がありません。構築チームのリーダーに尋ねても、前例踏襲だ！との回答です。大企業って意外と技術力低いと思ってしまいますが、独立系or大企業系の設計者の皆さんのご意見を伺いたいです。よろしくお願いいたします。

No.4 回答者： nolix 回答日時： 2012/06/19 19:12

kudzuは、もはや不要ですね。

小さなISP管理者より

この回答へのお礼

ご回答ありがとうございます。参考になりました。

お礼日時：2012/06/23 07:18

No.3 ベストアンサー 回答者： dev_null 回答日時： 2012/06/16 16:48

> kudzuは再起動時に時間がかかるので構築終了時にoffにすることとしました。

365日24時間稼働するということなら再起動にかかる時間は無視して構わないのではないでしょうか。

設計ポリシで、余計なものは入れない、動かさないということなら off にすることもあるかと思います。

4、5年前ならリソース確保のメリットもあるかもしれませんが、最近のマシン性能から考えるとそのメリットが限りなく小さくなりつつあり、余計なことはしないという選択もありだと思います。

この回答へのお礼

ご回答ありがとうございます。確かにkudzuをoffにする設計検証をしたのは、まさしく5,6年前でした。
最近の高スペックマシンでは検証していません。参考になりました。ありがとうございます。

お礼日時：2012/06/17 00:44

No.2 回答者： entree 回答日時： 2012/06/16 09:02

本来はハードやディストリ・ベンダーは自分ところで開発した全ての機能、組み

合わせについてテストされているべきです。

しかし、実際にはおそらくそうではないでしょう。

何が言いたいかというと、Red Hat がkudzu をoff にしても他の全ての機能を正
しく使えるかどうかまで、おそらくテストしていないということです。（Red Hat
がテストをサボったとかではなく、そういうものです）

それに、Red Hat のkudzu のデフォルトが on なら、大抵の人は on で使います
ので、World Wideでの実績も on の時のほうが圧倒的にあります。そして、多く
の人が利用している機能に対する不具合にはパッチも出やすいものです。

Red Hat 自身や利用者が on の時にやったテストと同じ事を開発サイドでやろう
とするとどれだけの稼働とコストがかかることやら・・・

つまり、デフォルトを変更することは、構築したシステムの品質を保証するとい
う観点で非常に不利です。デフォルトを採用することの重要性についてご理解く
ださい。

「何もしなければバグは生まれない」という理屈と似ています。

もちろん、デフォルトは一切変更してはならないといっているわけではありませ
ん。起動時間に対する要件があり、kudzu を on にしていると達成できない場合、
安定性がさほど求められていない場合はリスクを負ってもoff にすることを検討
すべきでしょう。

でも、大規模システムで安定性を求められないことはまずありません。例えば銀
行のシステムとかが停止したら、社会的にも影響が大きく新聞沙汰になることさ
えありますから。

この回答へのお礼

ご回答ありがとうございます。
>それに、Red Hat のkudzu のデフォルトが on なら、大抵の人は on で使います
このご意見には納得できません。非正規雇用で色んな会社、現場を渡り歩いてきましたが、
「設計段階で使用しないデーモンはoffにする」と言うポリシーは、一般的でした。セキュリティの観点や、リソース節約の観点から考慮すべきものととの思想が当たり前だと思うのですが、、、、、、、

お礼日時：2012/06/17 01:00

No.1 回答者： hanabutako 回答日時： 2012/06/16 07:24

技術力の高低というよりも、大企業はリスク回避志向が強いということだと思いますよ。

典型的な読み人知らずなうわさ話に、「俺の目の黒いうちはpatchを当てるな」なんて話があります。セキュリティホールがあるのはわかっているけれど、対策することでこれまでどおり動かなくなる可能性が1%でもあるなら、その選択をしないということです。現在それに対する攻撃が行われていないわけで、対策のために動作しなくしたら、責められることはあっても褒められることはないですからね。

kudzuもそのたぐいのことでしょう。これまでkudzuが入った構成でちゃんと動いているんだから、その構成を変えたくないということではないでしょうか。あえて過去に何かあったという理由をつけるなら、かつて途中で設計が変わって、あとからハードウェアを追加したことがあった時にkudzuに期待していたためにハマったとかでしょうか。

リスク回避志向が強いと、当然成功例を真似する志向が出てきます。しまいには、過去の成功例を盲目的にコピーするということになりますから、当然、前例踏襲主義になるでしょう。それに、大企業では生え抜きの年功序列が普通だと思います。そうなると、前例の否定は先輩や上司がこれまでやってきたことの否定です。そういう危ない橋は普通渡りませんよ。

というわけで、「前例踏襲だ！」という回答はそのままではないでしょうか。大企業では、前例は金科玉条のようなものですよ。(で、そういうのをやってられないと思ったら、会社をやめるわけです)

この回答へのお礼

ご回答ありがとうございます。

>過去の成功例を盲目的にコピーするということになりますから、当然、前例踏襲主義になるでしょう。それに、大企業では生え抜きの年功序列が普通だと思います。そうなると、前例の否定は先輩や上司がこれまでやってきたことの否定です。そういう危ない橋は普通渡りませんよ。

私は非正規雇用のLinuxジプシーで、かつ構築設計の仕事をしていますので、雇用期間はせいぜい1年～2年。短いと3ヶ月だけとか、また3,4,5重派遣とかは当たり前で当然ギャラも安いです。ですので危ない橋もがんがん渡ってきました。前例踏襲主義に陥る理由も理解できますが、このままでいいのでしょうか？若い人材が育たなくなり（自分で調べる能力の欠如）などさまざまな弊害が噴出しいるのが、今日この頃の現状だと思います。このままでは日系大企業は全滅するじゃないかとの危機感を持っています。まあ自分の会社ではないのでどうでもいいことかもしれませんが。

kudzuの話題から大きくそれてしまいました。失礼しました。
>あとからハードウェアを追加した
このような場合は手動でkudzuデーモンを起動するなどの手順を徹底しておけばいいことだと思います。
私が危惧しているのは設計者が初期設定:onの各デーモンの機能を理解しているのか？という点です。

お礼日時：2012/06/17 01:30