アカウント名:
パスワード:
この種のシステムとして先行するものは、例えばWindows Update であり、例えばRedHat Networkでしょうか。
Windows Updateでは、自分自身の構成情報をＭＳに送らずに、 インストールされているOS種別等の最小限の情報を送り、 その時点で利用可能なセキュリティパッチとツール最新版の 情報を取得しているのだと思います。それを見てどれをインストール するか、利用者自身が選択し、その指示に従いダウンローダが 動き、ダウンロードした実行形式のファイルを実行するのだろうと 思います。そして、実行履歴を自身のデータベースに記録し、 二重に処理することを防いでいるのだろうと思います。
RedHat Networkは同じくインストールされているOSのバージョン を送り、その時点で利用可能な最新のRPMリストを取得し、それを 自身のバージョンと比較し、新しいRPMが利用できるものを 表示しているのだと思います。それを見てどれをインストール するか、利用者自身が選択し、その指示に従いダウンローダが 動き、取得したRPMファイルについてrpmコマンドを実行する のだろうと思います。何がインストールされたかは、RedHat のデータベースに記録され、管理されているように見えます。
このFreeBSD Updateはどのような仕組みなので しょうか？ バージョン情報を送ると、交換すべきファイルのリストと チェックサムが送られてきて、交換可能と判断されたファイル をダウンロードし、新しいものと取り替えていくのかなと 思います。準備されるバイナリは -RELEASE-pXX のツリー で提供される、各SAに対応した比較的小さいパッチから生成 されるバイナリだと思います。 特にパッチ管理データベースは構築しない のではないでしょうか。彼は利用状況をモニタして いると言ってますが、それはアクセス状況とファイル転送量 程度だろうと考えます。このシステム自身がセキュリティ攻撃 の対象とならないように、認証やなりすまし防止、改ざん防止、 悪意をもつローカルユーザ等に対してもある程度対策はな されているのだと 思います。
前２者は有料の市販OSのサポートであったり、有料の保守サービス です。FreeBSD Updateは今のところボランティアサービスです。 この違いが、サービスの構造にどのような影響を与えていくのか、 興味がつきません。
apt-get update && upgrade ってのもありますなぁ
パッケージの更新だけなら、pkg_addとか、turbopkgとか、 SuSEの「何とか」とか、「窓の杜」(笑)とか もあるわけだし。
Debian（のstable）に関しては、パッケージの更新とセキュリティパッチの配布はほぼ同意です。 stableとしてリリースされたら以降は
最古参かどうかは置いといて 「忘れちゃいけませんぜ」ってことで
また元コメントにボランティア云々ってのがあったから その面でも apt がありますなぁ～ってことでして
そういった意味でも やはり「忘れちゃいけませんぜ」だよねぇ
そんな僕は Vine ユーザ なので新旧の話題にはついていけませんが
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
Windows Update, RHN, and FreeBSD Update (スコア:4, 参考になる)
この種のシステムとして先行するものは、例えばWindows Update であり、例えばRedHat Networkでしょうか。
Windows Updateでは、自分自身の構成情報をＭＳに送らずに、 インストールされているOS種別等の最小限の情報を送り、 その時点で利用可能なセキュリティパッチとツール最新版の 情報を取得しているのだと思います。それを見てどれをインストール するか、利用者自身が選択し、その指示に従いダウンローダが 動き、ダウンロードした実行形式のファイルを実行するのだろうと 思います。そして、実行履歴を自身のデータベースに記録し、 二重に処理することを防いでいるのだろうと思います。
RedHat Networkは同じくインストールされているOSのバージョン を送り、その時点で利用可能な最新のRPMリストを取得し、それを 自身のバージョンと比較し、新しいRPMが利用できるものを 表示しているのだと思います。それを見てどれをインストール するか、利用者自身が選択し、その指示に従いダウンローダが 動き、取得したRPMファイルについてrpmコマンドを実行する のだろうと思います。何がインストールされたかは、RedHat のデータベースに記録され、管理されているように見えます。
このFreeBSD Updateはどのような仕組みなので しょうか？ バージョン情報を送ると、交換すべきファイルのリストと チェックサムが送られてきて、交換可能と判断されたファイル をダウンロードし、新しいものと取り替えていくのかなと 思います。準備されるバイナリは -RELEASE-pXX のツリー で提供される、各SAに対応した比較的小さいパッチから生成 されるバイナリだと思います。 特にパッチ管理データベースは構築しない のではないでしょうか。彼は利用状況をモニタして いると言ってますが、それはアクセス状況とファイル転送量 程度だろうと考えます。このシステム自身がセキュリティ攻撃 の対象とならないように、認証やなりすまし防止、改ざん防止、 悪意をもつローカルユーザ等に対してもある程度対策はな されているのだと 思います。
前２者は有料の市販OSのサポートであったり、有料の保守サービス です。FreeBSD Updateは今のところボランティアサービスです。 この違いが、サービスの構造にどのような影響を与えていくのか、 興味がつきません。
Re:Windows Update, RHN, and FreeBSD Update (スコア:1)
apt-get update && upgrade ってのもありますなぁ
Re:Windows Update, RHN, and FreeBSD Update (スコア:0)
Windows Updateとか出てきたのはその後。
Re:Windows Update, RHN, and FreeBSD Update (スコア:4, 参考になる)
＃面倒だとは思うんですが、書き捨てするより皆が面白くなるほうに
もっていくほうが結局プラスになるとおもうので。
無理な場合は一言断っておくと不毛な言い合いを避けられるし。
といってるだけだと面白くないので調べてみました。
間違いあったら指摘をよろしく。
debian.or.jpに置いてある資料 [debian.or.jp]をみると1999/3の時点でaptは動いてるようですね。
aptのchangelogをみると1998/3が最初のリリース。
RHNという形かどうかはわからないのですが、update agentによって更新ができる形になったのは
Redhat6.1 [redhat.com]の頃からのようです。このリリースは1999年10月の事ですね。
Windows updateはどうやらWindows98から搭載の機能のようですね。
発売開始が1998 年 6 月 30 日 [microsoft.com]となっています。
ただ、今の形になったのはもう少し後だったような気もするんですが…
ということは古い順にapt, Windows update, RHNの順かな？
ただ、ちゃんと使い物になっていたかどうかあたりはこれだけだとわかりませんね。
Re:Windows Update, RHN, and FreeBSD Update (スコア:0)
パッケージの更新だけなら、pkg_addとか、turbopkgとか、 SuSEの「何とか」とか、「窓の杜」(笑)とか もあるわけだし。
Re:Windows Update, RHN, and FreeBSD Update (スコア:0)
Debian（のstable）に関しては、パッケージの更新とセキュリティパッチの配布はほぼ同意です。
stableとしてリリースされたら以降は
Re:Windows Update, RHN, and FreeBSD Update (スコア:1)
最古参かどうかは置いといて 「忘れちゃいけませんぜ」ってことで
また元コメントにボランティア云々ってのがあったから その面でも apt がありますなぁ～ってことでして
そういった意味でも やはり「忘れちゃいけませんぜ」だよねぇ
そんな僕は Vine ユーザ なので新旧の話題にはついていけませんが
Re:Windows Update, RHN, and FreeBSD Update (スコア:0)
コマンドライン一発じゃないとダメって話じゃないよね？（ってかそれだったらWindowsUpdateもダメだし）
Re:Windows Update, RHN, and FreeBSD Update (スコア:0)
あれはどうやってたんでしたっけ．
Re:Windows Update, RHN, and FreeBSD Update (スコア:0)
そのためサーバー側で用意すべきものは、最新のアップデートエンジンとアップデートに関する情報だ