RedHatがディストリビューションのメンテ期間を1年に 60
ストーリー by Oliver
MMF 部門より
MMF 部門より
Anonymous Coward 曰く、 "RedHatがディストリビューションのセキュリティホールなどに対応するアップデートパッケージの提供期間を1年間とするアナウンスを行っていました。今最新のRH8.0も来年の12月末で終了です。
これでは商用の、サーバ用OSとして安心して使えません。そういう用途にはAdvancedServerを使え、ということなのでしょうか? でも、AdvancedServerには、6.2など用に11月末にリリースされたApacheのアップグレードパッケージがまだないのですけど、使えるのでしょうか?"
普通のRed Hat Linuxは最低12ヵ月、人気のあるリリースだともっとの場合もあり、サブスクリプション方式のAdvanced Serverだと特定バージョンのリリースから最低36ヵ月ということだ。また、Alpha版とSparc版が非継続、という話もあり、黒字計上したRed Hatが(当然に)いよいよ金になる部分に注力していきている感じか。
アップデート (スコア:2, 興味深い)
「すなおにアップデートする」ではだめですか?
ASPやホスティングサービスって結構古いパッケージで構成するところが多くて、サービスのユーザーとしてはいらいらしています。
個人的にはセキュリティのこともあるので随時アップデートしてほしいものです。
# クラック発覚後に、リカバリするからということで納得したら、
# 最新版のOSを入れるんじゃなく当時のバージョンだったということがわかったときはもう。。。
Re:アップデート (スコア:3, 参考になる)
多少のサービス中断や修正作業をいとわないなら良いのですが、現実問題そうも行かない方が多いものです。
そういうのを天秤にかけて慎重にアップグレードするのだけど、それでも嵌まってしまうことが少なくないです。(お前が鈍いだけだって? ... ごもっともです ^_^;)
の
Re:アップデート (スコア:1)
ちょっと前にMSが「お金さえ払えば、いつまででもメンテするよ」とか方針を変えた事もそうですが、システムを導入する業種によってはバージョンアップによる挙動の変化なんか許されない場合もあり、メンテ期間が短いOSが使いにくい事が多々あります。
Re:アップデート (スコア:1)
ディストリビューションベンダーもサービスベンダーもユーザーそれぞれも。サービスが同じ値段であっても、多少の中断があっても最新であるほうがいいこともあるし、中断しないことが重要であることもある、と。
# 移行用マシンを用意しとけば中断なしでもアップグレード可能でしょうから。
ホスティングとかだと同一ホストに複数ユーザーがいるわけで、彼らの優先度のことを考えないで管理してる場合は、OSのアップグレードはよほどでないとできないと思う。つまりホスティング使うならアップグレードはまず無いとしなくてはいけない状況なのではないでしょうか。そういう意味だと世間の認識ではアップグレードというのはかなり低い位置づけにあるわけで、アップグレードの立場を上げるという意味ではいいきっかけであると思います。
> そういうのを天秤にかけて慎重にアップグレードするのだけど、それでも嵌まってしまうことが少なくないです。(お前が鈍いだけだって? ... ごもっともです ^_^;)
ただ、難しいからといってあきらめられるのは非常に困ることだと思うんです。実際のアップグレードのコントロールを握っているのはユーザーでもRedHatでもなくサービスベンダーなわけですから。コントロールを握っているのにやらない、でも被害は及ぶ、となるとMicrosoftみたくじゃあそのコントロールを奪ってしまえ、と考え実行するようになってしまっても不思議ではないと考えるのです。
Re:アップデート (スコア:1)
「移行用マシンを用意」というのは、ある程度の規模を超えると非現実的になると思います。特に止められないサービスであればなおさら。動作確認するために一式同じ物を揃えると金額が4桁いくのはざらですから...
その支出をどこがするの?って話は必ず出る訳で、であれば最初から「アップグレードの必要の無いサーポートされるOS」って事になります。
Re:アップデート (スコア:1)
いや、言いたかったことは
ということです。移行用マシンを、というのは単にシンプルなホスティングマシンの移行方法の例で、実際無停止のシステムということだったら、システム自体の設計からアップグレードへの対応を考える必要があると思います。そのうえでアップグレードしないという選択をするのもありでしょう。
ただみんながみんな、いつでも止めちゃいけなくアップグレードが必要ないサービスでなくてはいけない、というわけではないということです。
Re:アップデート (スコア:1)
>・サービスではそういった「ユーザーの優先度によって選べること」が重要
>・優先順位の選択肢として「アップグレード」も入れて(稼動率とかと同じレベルで扱えるようにして)
はい、それぞれ選択子が違うと思いますので「ひとくくり」にするつもりはありません。無停止のレベルによってはサクっとバージョンアップしちゃいますし。
でもまぁ~あのMSですら方向転換(どんな形であれ、継続サポートをする方向に)している中で、まだまだこれからって時にLinuxの最大?陣営がこういう方向に向かうのはどうなのかな?って思っただけです。
ますます重用なサーバーへの利用が敬遠されるようになるのでは無いかと危惧しています。
(後は素直にIBMとかフルサポートしてくれそうな所に頼むとかね>Linuxサーバー。最近SUNも始めたのかな?)
Re:アップデート (スコア:0)
AIXなんて移行期間も考えると実質2年程度しか使えないですから。
まあ、年間?億円ほどIBMに払えるなら対応してくれますけど。
# 実際、その案件の最中なのでAC
Re:アップデート (スコア:1, 参考になる)
って商売誰かしてくれれば。。。ビジネスチャ
ンスか?
某Sには真似できまい。
でも古いメンテだとモチべーションがないかも。
Re:アップデート (スコア:0)
(あ、でもメールとかもはや無停止システムかな?)
そうそうアップグレードできないと言うのはまさにその通りだと思われます。
むしろ、最近は簡単に停止できるシステムの方が少ないのでは?
(お客さんうるさいし)
てことで、未だにSolaris2.6とか動いてますよ、現役で。
そういう状態なので、
うちでは費用よりも実績が重んじられます。
本当は初期コストよりも運用費用が重視されるべきなんですけどね。
アップグレードなんてそれだけで莫大な費用が発生しますから、
(事前調査
アップグレード(Re:アップデート) (スコア:1)
「アップデート」ではなく「アップグレード」でした。
アップグレード (スコア:1)
機能ってどんなものなんでしょう。Debianのパッケージングシス
テムやSolarisのLiveUpgrade、*BSDでは比較的アップグレード
が簡単みたいですけど。RedHatで再インストールなしのアップ
グレード経験のある方の意見を求む。
ネタ投下 (スコア:2, すばらしい洞察)
半強制的にアップグレードさせるなんて某M$社のようですね。(笑)
#そんな私はFreeBSD派。
Re:ネタ投下 (スコア:1)
# そんな私は Slackware 派。 :-)
Re:ネタ投下 (スコア:1)
>make install せい、という事かもしれません。
サーバ向けソフトウェアはデフォルトの./configureで使わず、
自社でrpmやdebを作れってことでは?
私は、kernelもちろんのこと、
apache,postgresでもdeb形式で作ります。
やはり、パッケージは管理しやすいです。
# そんな私はDebian派
PCにECC Registeredメモリの利用を推奨します。
Re:ネタ投下 (スコア:2, 参考になる)
言いたかったのは、要するに「RedHat から下賜される rpm なんぞに頼らず、サーバを納入したところが面倒見ればいいじゃん。ソースあるんでしょ?」ということです。
Re:ネタ投下 (スコア:1, 興味深い)
デストリビュ―ション全体を「ホントに使いやすい物を皆で作っちゃえ!」
ってのもあるかと。
何らかの理由で「デストリビュータ自体」がなくなってしまう事もありますので。
僕は、アップデート・アップグレードは全て自主的に・自前で行っていますので、中身は殆ど原型をとどめていませんです(^^;。デストリビューション名をココで述べてもホントに意味がありません。
#そういう物でないの?Linuxって、本来。
Linuxがサーバ用途「に使える」・「にも使える」は、本来別々に捕らえるべき物であって、同列に扱うのはどうかと思いますよ。
>>AdvancedServer
は、「に使える」もので「使えなかったらフォローするよ」というもので、商品価値の大半は「フォローするよ」の範疇のはず。
#と、僕は考えています。
今のは知りませんが、昔の「Slackware」はサーバ版はなかったもののココで書いた事を地で行っていたものであったと思います。
Redhatは「Linuxで商売」しているのであって「Linuxを商品」にしているのではないでしょう?。
また、あの頃の「Slackware」はあくまで“主流”なのであって、今の「Readhat」のような“本流”ではなかったような気がしますがの。
> 半強制的にアップグレードさせるなんて某M$社のようですね。(笑)
やっぱ、ブランド名って必要なのね(^^;。
# そんな私はKondara派
##でも、Momongaは観察中(汗。
閑話休題
Re:ネタ投下 (スコア:2, すばらしい洞察)
>デストリビュ―ション全体を「ホントに使いやすい物を皆で作っちゃえ!」
>ってのもあるかと。
っていうのは余り現実的じゃ無いと感じています。
個人ユーザーな方は、今回の件では余り影響受けないでしょうし。
Re:ネタ投下 (スコア:1)
Kondaraの事例をみれば明日はわが身かと…。
#っと、言ってみる。
> 個人ユーザーな方は、今回の件では余り影響受けないでしょうし。
これって、個人の方が影響大かと思いますが。rpm・deb以外で&ディストリビュータ保証とされるアプリケーションの更新以外なんて出来ないでしょう。
僕の意見の集約はここです。
>やっぱ、ブランド名って必要なのね(^^;。
です。
Lnuxにブランド名って必要?
営業さんの腕では?
閑話休題
Re:ネタ投下 (スコア:0)
Re:ネタ投下 (スコア:0)
FreeBSD アップグレード 無料
Re:ネタ投下 (スコア:0)
>FreeBSD アップグレード 無料
どっちも無料じゃねぇか。
全部をディストリビュータが面倒を見なくても良くなっ (スコア:1, 参考になる)
実際に Linux をサーバとして提供しているものとしては、ちゃんと
したリリースとメンテナンス計画を立ててくれている方が、いつ次
のバージョンがでるのか分からないよりも、遥かに「安心」できま
す。
1年という期間は短いようですけれども、実際には Redhat8.0 の
エラータへの対処には 8.1 や 8.2 向けのものが使えます。
これまでも暗黙に、リリースは半年ごと、メンテナンス期間は
リリースから1年間、という感じでやってきています。
逆にいうと、Redhat がどのくらいの期間メンテナンスしてくれて
いるのかのことも、知らずに/調べずに顧客に納入していたとす
るのならば、タレコミ者はいい加減なベンダだともいえますな。
Re:全部をディストリビュータが面倒を見なくても良く (スコア:1)
タレコミ者がベンダやインタグレータとは限らないのではないですかね? どっちかというと、ユーザのシステム部門の人の匂いがするんですが、いかがなもんでしょう? > タレコミ者サマ
だって、ベンダの類なら自力で rpm こさえてしまえばすむ話じゃないですか。 どうせ客向けの責任は自前 (まぁ契約にもよりけりでしょうが) でとることになるわけですよね?
Re:全部をディストリビュータが面倒を見なくても良く (スコア:1)
Re:全部をディストリビュータが面倒を見なくても良く (スコア:1, 参考になる)
実際はそれを越えた古いリリースもまだサポートされ続けてるわけで、たとえば現在サポートされている一番古い 6.2 Zoot は 2000年3月末のリリースなので、エラータのページにある通りにサポートが打ち切られてもまる3年は面倒見てくれたことになります。そのページにも「最低12か月、場合によって人気のあるリリースはもっと長くサポートするかも知れない」とあるように。
Re:全部をディストリビュータが面倒を見なくても良く (スコア:0)
Anonymous Cowardなのにメールアドレスが…
ACじゃないじゃん(笑)
ACって使ってみたかっただけとちゃうんかと小一時間
# でもどうしたらこうなるんだろう?
Re:全部をディストリビュータが面倒を見なくても良く (スコア:0)
Re:全部をディストリビュータが面倒を見なくても良く (スコア:1)
Re:全部をディストリビュータが面倒を見なくても良く (スコア:0)
>という文脈だと思うのですが。
>
>逆にそういう提案が怖くてできない業者に頼るくらいなら情シス部
>門 (的なところ) が自前でやった方がマシかもしれませんね。
はは、オタクが趣味でやってるのとは違うのよ、現場は。
Re:全部をディストリビュータが面倒を見なくても良く (スコア:2, 参考になる)
前提として、RHL なんですから LAN の中の DB サーバとかじゃなくて、外界につながってる WWW サーバか何かでしょう? だとしたら、いずれ security がらみの部分 update は必須になるはずですから、納入時に「RedHat のサポートがない時は (場合によっては別料金で) ふがほげする」ということになっていて然るべきです。
もちろん、update までは面倒見ないよ、という契約であれば別でしょうが。
Re:全部をディストリビュータが面倒を見なくても良く (スコア:0)
ソリューションのなかに、メンテナンス計画まで含めていなかった
時点で、へたれベンダ以外の何ものでもないでしょ。
Re:全部をディストリビュータが面倒を見なくても良く (スコア:0)
いくら人を「へたれ」と呼んでも自分が空しいだけだろ?
計画が計画通り進むと考えている時点であんたがへたれな訳だが。
あ、あんた無職か…スマソ。
Re:全部をディストリビュータが面倒を見なくても良く (スコア:0)
マシンを持たせておき、スムーズにバージョンアップできるように
備えるのが当然なのに、そんなこともしていないのは情けないです
な。あ、低予算の仕事しか回ってこない?そりゃ悪いこと言ったね。
Re:全部をディストリビュータが面倒を見なくても良く (スコア:0)
>マシンを持たせておき、スムーズにバージョンアップできるように
サービス内容にもよるが、普通、載せてるアプリの挙動がおかしくなるのでバージョンアップはしないですよ
>備えるのが当然なのに、そんなこ
Re:全部をディストリビュータが面倒を見なくても良く (スコア:0)
アプリの挙動がおかしくなるからバージョンアップはしないです、
といっている時点でもう3流ベンダの証拠ですな。2流以上のベンダ
ならばバージョンアップに備えたサービス計画を提出することが求
められるものな。
昨今の顧客もセキュリ
意見をもっと詳細に (スコア:1, 興味深い)
「え、だってソースあるじゃん。ないの?」とどうしても思うの
ですが、そういう話じゃないんですよね?
商用ディストリビューションを選んだ理由こそに、困っている
原因があるんですよね?
「これでは商用の、サーバ用OSとして安心して使えません。」と
単に書かずに、何故にという点を書いて欲しいです。
でないと、無駄な議論の種になっちゃう。
Re:意見をもっと詳細に (スコア:0)
Re:意見をもっと詳細に (スコア:1, 興味深い)
デートが提供されなくなり古くなったディストリビューション環境では
コンパイルできないこともある」という意味かと思うのだが、それこそ
「ディストリビューションのソースがあり自分でビルドしたり古く
なったパッケージをオリジナルソースからビルドなおせば?」と思うんだよ。
数年前にフリーソフトやオープンソースがビジネス業界でも注目されて
きたとき、フリーソフトやオープンソース陣営はクローズドなソフトに
対するアドバンテージの一つとしてそういう事を言ってなかった?
だから、そういう事が理由じゃないんでしょ?
ソースがあるからには自分で全てができる。
しかし、それに伴う労力は無視できない量のコストなので、構成
済み・検証済みのものを一定期間のサポート権利も含めてお金を
払って入手する。
他の商用アプリケーションも検証済みだ。
それが商用ディストリビューションの価値なんでしょ?
認めようよ。
ソースが手元にあるからって何でもできる訳じゃないって。
もうソースが自由だってことが最大の利点じゃなくなっているって。
不思議 (スコア:1, すばらしい洞察)
mandrakeの場合は株買って救済してやれって話になるのに、RedHatの場合は株買って/製品買ってアップデート期間長く取るだけの体力を持てるように支援してやれ、って話には、ならないのね。
なんで?
俺は所詮個人ユーザなんでup2dateが動いてればいいし最新版の.iso取れればいいので買わないけど。
その代わりup2dateで後回しにされても.isoが公開中止になっても文句は言わない。
(スコア:0)
そんなわけで (スコア:0)
出て来るんじゃないか、と言ってみる。
どうでもいいが、
「日本のLinux情報」のトビラ、
いつまで夏なんだろう
サーバ用途なら (スコア:0)
Re:サーバ用途なら (スコア:2, すばらしい洞察)
#いや,何気に思った大マジの質問。
Re:サーバ用途なら (スコア:1)
いえ、どこか妥当な金額でサポートしてくれる会社があれば、検討出来るとは思います。
(自前サポートは対経費的に現実的では無いでしょう)
もし、サポートする会社があったとしても、その会社が10年後に無いようですと...
やっぱり大手ISP等のように自前でチューニングしてメンテし続けられないと難しいのかな?とは思います。
(ここで言っている「メンテ」はセキュリティパッチを当てる等の簡単な作業の話では無く、OSをバージョンアップしないで継続メンテする事について触れています。)
Re:サーバ用途なら (スコア:0)
特にRAIDコントローラなんかは…。
Debian (スコア:0)
# 当事者に近いので AC
Re:サーバ用途なら (スコア:0)
そのまま適用できないでしょ?それに、FreeBSDってBSDファミリーの
中では一番の異端児だったりするよね。
ベンダが自前で面倒をみるってことなら別にFreeBSDやD
Red Hat x.0 (スコア:0)
(オフトピ)
アップグレードしたらその上のアプリケーションの保証対象外となる事が多いので、OSのバージョンは上げたくても簡単に上げられないのが実情です。
その点、Red Hat はマイナーアップデートが別バージョンとなるのでかなり厄介です。折角 Red Hat 7.3 が出ても、商用バックアップソフトや商用データベースのサポートが得られるまでは 7.2 を使い続けるしかありません。
Windows みたいに、サービスパック化してくれるとバージョンを上げた事にならないので有難いのですが、そうならないもんですかね。
# 当事者に近いので AC
MIRACLE == RedHat (スコア:0)
いや困ると思いますよ。"MIRACLE ≒ RedHat"というのは、公知の事実です。でも、United Linuxは使える可能性はあるかも(期待)。