パスワードを忘れた? アカウント作成
9561 story

FreeBSD 4.11-RELEASE 公開 53

ストーリー by Oliver
時代遅れとは言わせない 部門より

tag 曰く、 "FreeBSD 4.11-RELEASEが正式アナウンスされました。4.10がリリースされたのが昨年5月末ですから、8か月ぶりの更新です。予定ではこれが本当に最後の最後の 4-STABLE ブランチからのリリースに なるはずです。多少の不安はあるものの、5.X のブランチが 5-STABLE になっています。4-STABLE は今後はメンテナンスフェーズとなるようです。 ぱっと見で 4.10 との違いは

  1. ここ8か月間に起きた CVS、fetch、procfs を中心としたセキュリティホールの修正
  2. 各種デバイスドライバの修正、機能追加
  3. GNOME 2.8.2 と KDE 3.3.2 への更新
  4. インストールディスクの1枚目が2種類あり、GNOME 用と KDE 用になったこと

というところでしょうか。詳細はリリースノートを参照。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2005年01月26日 8時35分 (#684464)
    ただ今 FreeBSD 4.10をインストール中です・・・
  • by yasudas (5610) on 2005年01月26日 9時36分 (#684481) 日記
    >多少の不安はあるものの、5.X のブランチが 5-STABLE になっています

    不安があっても、STABLEなんですか...
    http://dictionary.goo.ne.jp/search.php?MT=STABLE&kind=ej&mode=0&base=1&row=1
    それとも、こっちの意味のSTANBLE?
    • STABLE の意味 (スコア:3, 参考になる)

      by tag (10007) on 2005年01月26日 9時47分 (#684485) 日記
      用語の問題になってしまいます。FreeBSD での STABLE ブランチ ではメインの開発を行わず、安定的な走行を目指しています。 それに対して、CURRENT ブランチでは最新の開発が行われ、場合に よってはカーネル構築の失敗、パニックの頻発も覚悟する場所と なっています。つい先日もVFSが導入された途端、MPSAFEなlockfが うまく動かず、パニックを発生しているようです。

      ここで言う多少の不安とは、製品レベルの安定性の保証という 意味での不安だと思います。これは衆目の一致するところで、 安定性第一の現場に導入するにはまだ注意が必要です。 安定第一の人のために、今回の 4.11-RELEASE が公開されたわけ です。

      親コメント
      • by Technical Type (3408) on 2005年01月26日 13時41分 (#684598)
        Windows みたいな Unstable そのもので、おまけにパッチ当てまくりしないと使い続けられないような OS を不安なくサーバーやらシステムに使える程の度胸がある人なら、5.0 だって何も不安なく使えたでしょう。 5.3 なら、もう胸を張って大威張りで使ってください。サーバー用途でも安定性の点では問題無いでしょう。 (少なくとも Windows よりは)

        ただ 5.X 系は 4.X 系とは結構違いがあるので、ちょっと勉強し直さないと駄目かな。まあ、時代の進歩ってやつですね。 (と言いつつ、私が管理してるのは慣れてる 4.X 系の方がまだ多いですね)

        親コメント
  • by primo (15965) on 2005年01月26日 9時59分 (#684491)
    サーバのHDD(4.6R)を交換するところなので、コレ(4.11R)にします。 ただのファイル置き場なので、いちばん安定してるヤツがいいです。
  • by Anonymous Coward on 2005年01月26日 10時25分 (#684505)
    まだ、ですよねぇ?

    # 2台現役なんです、はい。
    • by wildcard (416) on 2005年01月26日 13時25分 (#684590)
      正直な話、PC9800系はそろそろ捨てる準備をしたほうがいいと思う。
      性能云々ではなくコンデンサやモーター類の寿命が来ている機械も少なくないはず。
      火災が起きてからでは遅い。
      親コメント
      • 確かに。
        なんか電解コンデンサはふくらみ始めたらもうやばいとは聞いたことがあるけど、他には何かヤバげな兆候ってあるんでしょうか。
        • by Anonymous Coward on 2005年01月26日 16時58分 (#684708)
           電解コンデンサの上部のフタ(切り込みが入ってる)がふくらんでいたらご臨終間近です。2ch自作板風に言うと妊娠で、電解液の圧力が高まっている(=ガス化している)ということです。
           妊娠した電解コンデンサが数個しかない場合はほとんど影響はありません。けれど、これがあまりに多くなると、突然電源が落ちる等の不可解な現象が生じるようになります。
           また、この他にもドライアップといって知らない間に電解液が抜けている場合もあります。

           電解コンデンサには温度によるグレードがあって、安物は85度で1000時間です。最近のコンピュータではそれよりは高級な105度や115度で数千時間のものが使われているようです。この寿命は温度が10度下げるごとに2倍になります。コンピュータのクーリングにはくれぐれも気をつけましょう。

           マザーボードの集積度がそんなに高くないのなら、電解コンデンサを全交換してしまうのも手です。電解コンデンサが爆発すると電解液のなれの果てがそこら中にこびりついて実に手に負えなくなります(猛烈にくさいし)。
          親コメント
          •  98ではないと思うけど、台湾製のマザーボードに使用されている日本製でないコンデンサは、かなりの確率で妊娠の時期が異常に早いのが最近多いですよね。
             たとえ、105度とか使ってあっても安心はできないです。一時期電解液の問題も話題になっていたし、念のため一度ケースを開けてマザーボードを確認してみるといいかもしれませんね。
             私が面倒見ているPCの中には、使用開始から2、3年しか経ってい
            • 電解コンデンサの大量死 [geocities.co.jp]ですね。

              # PC組むとき、大量死が恐かったのでASUSマザーボードを買った記憶が…
              # まだ1年ちょっとしか立っていませんが、しっかり動いてくれてます。
              --
              1を聞いて0を知れ!
              親コメント
            •  数年前のコンデンサの死亡騒ぎは電解液が不良品だったそうで。大量死したコンデンサを製造していたメーカは、みな同じところから電解液を買っていたとか。そういうわけで最近のは安心なんじゃないかと思いますよ。

               とにかく、電子製品の中で最も寿命の短いのが電解コンデンサです(可動部を除く)。その短い寿命を伸ばすためにも冷やしてあげてくださいね。
  • by Anonymous Coward on 2005年01月26日 11時27分 (#684535)
    FreeBSD 4.11-RELEASE Announcement [freebsd.org]
    the latest release of the FreeBSD Legacy development branch
  • by Anonymous Coward on 2005年01月26日 12時51分 (#684578)
     4.9-RELEASEを使っていてインストール後停電以外で落としたしたこともなく非常に安定していて特に不満もないんですが、4.11にアップグレードするのって皆さん普通どうやってやるんでしょう?

    どなたか参考までに教えてください。
    • by Jadawin (2174) on 2005年01月26日 13時43分 (#684599) 日記
      cvsupでソースツリーの同期をとって、make&install&mergemasterが簡単でしょ
      う。私の場合、cvsupを毎日やって変更の量や場所のあたりをつけて、重要そ
      うなら更新、そうでなくても週に一度は更新という運用をしています。

      ちなみに、/usr/src/Makefileによると正確な手順は次の通り。

      # 1. `cd /usr/src' (or to the directory containing your source tree).
      # 2. `make buildworld'
      # 3. `make buildkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC).
      # 4. `make installkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC).
      # 5. `reboot' (in single user mode: boot -s from the loader prompt).
      # 6. `mergemaster -p'
      # 7. `make installworld'
      # 8. `mergemaster'
      # 9. `reboot'

      慣れないとmergemasterが何をやっているのか分からない感じですが、基本は
      自分がいじったファイルはmergeする、それ以外は新規をインストールするこ
      とです。

      #サーバ用で色々と設定いじっていると大変かも。

      カーネルに問題があった場合でも、一つ前のバージョンのカーネルとモジュー
      ルはkernel.oldというディレクトリにリネームされてるだけですから、簡単に
      戻せます。installworldしてから、トラブルが見つかった場合ですが、カーネ
      ルに由来するものなら、カーネルだけ戻しても「多分」大丈夫です。そうで
      なければ、動作確認ができている日付のソースをcvsupして構築しなおしです。

      完全に動作しなくなることは、滅多にありません。個人的には、6-currentを
      使っていた頃に、IDEのドライバがおかしくてブート後の挙動がおかしいことが
      一回だけありましたが、カーネルを置き換えで復旧できました。

      #こんなもんでわかります?
      親コメント
      • by Anonymous Coward on 2005年01月26日 14時24分 (#684611)
        私は4.x系列ではずっと前からこんな風にやっているのですが何か問題あります?
        順番とか違うので気になります。

        make -j 4 buildworld
        make installworld
        make buildkernel ほげほげ
        make installkernel ほげほげ
        mergemaster
        reboot

        "-j 4"って今は特に必要ないのかな?
        もう定型化しちゃった作業なのでこれまでずっと変えずにやってます。特に問題ないみたいですし。
        親コメント
        • by tag (10007) on 2005年01月26日 14時51分 (#684630) 日記
          正式には、先のコメントで厳密に記述された方法で行うべきです。 システムコール関係の修正が行われた場合、正しいOS、正しい コンパイラ、正しいライブラリが揃った環境下で新しい環境を 作らないと、最悪の場合ブートしなくなります。

          システムコールがらみの変更がない場合には、適当にはしょって make してもほとんどの場合は大丈夫でしょう。ツール類の更新 にあたって、セキュリティ的な問題に対応する ために、/etc/passwd 等の追加修正が時々あります。この時は、 ちゃんと mergemaster -p をしないとインストールに失敗する ことがあります。

          要はどの程度の修正が新環境に加わったかです。安全を取るなら 厳密な手順に従って作業したほうが良いと思います。

          親コメント
        • by Jadawin (2174) on 2005年01月26日 15時06分 (#684644) 日記
          -jは、ジョブ数の指定ですね。マルチプロセッサのマシンなら確実に速くなり
          ますが、ユニプロセッサだとどうかなぁ。コンパイルは結構ディスクアクセス
          が入りますから、若干は速くなるかも。

          #明らかに必須ではないです。付けて間違いでもありません。

          あと、順序の問題ですが、おっしゃる順序だとコマンド群だけ新しくなって、
          カーネルとバージョンの不整合を起こす可能性があります。それにマルチユー
          ザ環境でこういう作業は気持悪いですね。ユーザやサービスが実行するシェル
          スクリプトで、ループの一回目と二回目でコマンドの挙動が変わらないとも限
          らない。

          #さて、最悪何がおきる???

          また、mergemasterをそこで一発かけるだけだと、動作するために専用のアカウ
          ントが必要なサービスが新規に追加された場合や、SSHやPAMの設定が変わった
          時とかにうまく行かない場合がありそうです。

          #どちらの話も、現実的にはそれ程大きな確率と大きな危険性ではないかも。
          #「問題があっても対処可能」と言い切れる状況の人ならO.K.。
          親コメント
          • >#さて、最悪何がおきる???
            installworldの途中でshがコア吐いてmake失敗する。
            5.1->5.2のときにやっちゃいました。更新されてしまったコマンド群の大部分が軒並コア吐く状態に。たしか、lsもmountも動かなかったような気がする。ログアウトしたらログインすら出来ないかも知れない状況でかなり焦りました。reboot位は動いた気がする(笑)
            で、幸いにも5.0だか5.1だかのCDがあって、そいつから起動して/binなんかを入れ、なんとかmake動く状態にして復旧しました。
            4.xからcvsupで更新してたので、雑誌についてきていたそのCDは使ったことなかったのですが、あって本当に助かりましたよ。
            親コメント
          • >-jは、ジョブ数の指定ですね。

            はい、そんな説明を昔にjp.freebsd.orgのどこかで読んでそのまま指定しています。確か、普通のインテルCPUで"4"が一番多くの人にとって最適値だというような説明があったと思います。今はあまり気にしなくてもいいのかな?
            大体、CSVUPでソースを常に最新に保ちつつ一ヶ月に一度くらいの頻度でmakeworldしています。特にsingle user modeに落ちずに、というかリモートでmakeworldしているので落ちれない、毎回思い切ってやってます。4.3-STABLEあたりからずっとそれできているので怖くてそれ以外の手順は試せずにいるのが実情だ
            • >はい、そんな説明を昔にjp.freebsd.orgのどこかで読んでそのまま指定しています。確か、普通のインテルCPUで"4"が一番多くの人にとって最適値だというような説明があったと思います。今はあまり気にしなくてもいいのかな?

              確かに、ユニプロセッサでも-j2の方が速くなるとMLにありました。

              #自分で確かめるのが一番。

              >昔(3.xの頃?)に正式手順でkernelをbuildした後でrebootしたら立ち上がらなくなった経験があって、それがトラウマになっていて作業中にrebootをするのはかなりためらわれます。(^^;)

              迷信ですよぉ。それは。全部理解した上で利便性を重視して標準的な手順から
              外れるのは止めません。しかし、その理由ではちょっとおすすめできないっす。

              #いかれる確率は、小さいながらも確実に増えますよ。
              親コメント
              • by Anonymous Coward on 2005年01月27日 13時14分 (#685135)
                > 確かに、ユニプロセッサでも-j2の方が速くなるとMLにありました。

                ハンドブックくらい読もうよ。以下、 20.4.6.2. ベースシステムの構築とインストール [freebsd.org]より
                次のコマンド
                # make buildworld
                を実行してください。ここで make に -j オプションをつけると、同時にいくつかのプロセスを生成させることができます。 この機能はマルチ CPU マシンで特に効果を発揮します。 構築過程の大部分では CPU 性能の限界より I/O 性能の限界の方が問題となるため、シングル CPU マシンにも効果があります。

                普通のシングル CPU マシンで以下のコマンド
                # make -j4 buildworld
                を実行すると、make(1) は最大 4 個までのプロセスを同時に実行します。メーリングリストに投稿された経験的な報告によると、 4 個という指定が最も良いパフォーマンスを示すようです。

                もし、複数の CPU を備えたマシンで SMP 設定が行なわれたカーネルを 利用しているなら、6 から 10 の間の値を設定し、速度がどれくらい 向上するか確認してみてください。

                ただし、この機能はまだ実験段階であるということに注意してください。そのため、ソースツリーへ変更が加えられたときにこれが正常に機能しなくなる可能性があります。もし、このオプションを用いてシステムの構築に失敗した場合には、障害を報告する前に、もう一度オプションを付けずに試してみてください。
                英語版でも、章構成が違うものの、内容は同一 [freebsd.org]ですので、これが今現在も最新の状況なのでしょう。
                #記憶にある限り、5年以上前から変わっていません。
                親コメント
            • 正直、頭悪すぎ…
      • 今は一応、
        # 5.5. '/usr/src/etc/rc.d/preseedrandom'
        が入ってます。tempファイル作るのに/dev/random使うからの様ですが、なくても実害はない気がしますけど。
        親コメント
      • 単純な疑問なんですが、その場合 freebsd-update って適用できるんでしょうか? 配布バイナリであるかどうかのチェックをどうやっているのかよく分かっていないのですが。
    • by tag (10007) on 2005年01月26日 13時23分 (#684589) 日記
      そのサーバが一瞬たりとも運用停止できないのか、多少のダウン が許されるかで、条件が変わるかもしれません。

      僕は、CVSUPで各種OSのいくつかのブランチを追いかけています。 FreeBSD に関しても定期的にソースを追いかけて、make build、 make install を行っています。NFS が許される環境の場合は、 それで作成した /usr/src と /usr/obj を mount して、 make installkernel、make installworld、mergemaster を 順次実行します。シビアなジョブは行っていなかったり、サービス 停止できるならデーモンを止めてしまえば安全です。 mergemaster はかなり慎重に行わないと、現在の運用設定を消して しまうかもしれません。mergemaster だけに頼らず、自分で 前もって /etc の下あたりを調整しておくと良いでしょう。

      これはシビアな運用環境にないサーバの場合であって、高負荷 状態でかつ一瞬たりとも OS 環境内の矛盾が許されない場合は、 単純な更新は諦めたほうが良いと思います。

      親コメント
    • by Anonymous Coward on 2005年01月26日 14時04分 (#684607)
      # pkg_add -r cvsup
      # sed 's/CHANGE_THIS.*$/$SOME.MIRROR.SITE/
                    s/tag=RELENG.*$/tag=RELENG_4_11/' \
                    /usr/share/exapmples/cvsup/stable-supfile > my_stable_supfile
      # cvsup -g my_stable_supfile

      # less /usr/src/UPDATING

      # cd /usr/src
      # make buildworld && make buildkernel KERNCONF=$CONFIGFILE \
          && make installkernel KERNCONF=$CONFIGFILE
      # reboot
      # mergemaster -p
      # shutdown now
      # cd /usr/src
      # make installworld && reboot

      $で始まるところは適当に置換願います
      親コメント
    • うちと同じじゃん
      いつからかは確認してないけど、portsやpackagesが正常に動作しなくなってます。
      ちゃんと見てあげる時間を取ってないのと安定稼働してることから放置してるけど。

      手軽にUpgrade出来るなら有り難いな。
      • ウチも安定動作してるからで放置しちゃってます。

        proftpd がなんか起動しなくなったと思ったら、 ports に入ってる起動用スクリプトが 5.x 向けの物に置き換えられてた(っぽい)からだったりとか。

        色々やっていて止めるのが怖いから下手に弄ることもできず……

        親コメント
      • by Anonymous Coward on 2005年01月26日 21時07分 (#684862)
        cd /usr/ports ; make fetchindex
        するとマトモに動いたりしない?
        親コメント
        • 非常に参考になりました。
          明日、試してみようっと。

          ところで、こんな情報どこから仕入れてますか?
          私の記憶では、FreeBSD-users-jpメーリングリストでも流れてなかったような気がします。
          • by Anonymous Coward on 2005年01月28日 6時33分 (#685450)
            portupgrade するなら /usr/ports/UPDATING は必読。これを読んでおかないと他にもハマる時がある。ports の更新を cron で全自動で行うのなんかも、滅多に無いとはいえ危険性があるね。

            #もしかして make world する時は /usr/src/UPDATING を読むけど ports のアップデート時には読まないって人多いのかな?
            親コメント
      • #684587のACです。
        丁寧なレスを付けて頂いた方、有り難う御座いました。

        CVSupについては(#684607)を参考に、OSの更新はJadawinさん(#684599)
        の発言を参考に、というかそのまま手順に沿って行うことが出来ました。

        先ずはCVSupで目的のバージョンツリーを取得して、Makefileを読んで理解する。
        今後はこれを忘れず、他人に聞くことのないようチャレンジしてみます。
  • by Anonymous Coward on 2005年01月27日 0時02分 (#684958)
    Estimated EoL [freebsd.org]

    保守期間を見ると、4.9がありませんがもうサポートされていないってことなのでしょうか?

    また、基本的に奇数番のReleaseはEoLから削除されているような印象を持っています。
    これは気のせいなのでしょうか?

    5.3まではstable-branchになってなかったので、5.2.1とかの5系のReleaseはもうサポートされないのでしょうけど。

    基本的に偶数版のReleaseしか仕事では使っていません。
typodupeerror

吾輩はリファレンスである。名前はまだ無い -- perlの中の人

読み込み中...