Home > Admin

Admin Archive

Scientific Linux 6.1 での yum リポジトリ設定


今朝 Scientific Linux 6.0 環境を 6.1 環境へアップグレードする方法 を書きましたが、6.0 時代に設定した yum のリポジトリ設定が上書きされ、初期化されていました。どうやら SL 6.1 で yum のリポジトリ設定ファイルの構成が変わったようです。

具体的には次のようになりました。

  • /etc/yum.repos.d/sl.repo が上書きされた。
    • 古い設定は /etc/yum.repos.d/sl-other.repo.rpmsave に保存されています。
    • 中身が sl, sl-security(元々 sl-updates.repo にあった設定), sl-source になった
  • /etc/yum.repos.d/sl-updates.repo が無くなった。
    • 古い設定は /etc/yum.repos.d/sl-updates.repo.rpmsave に保存されています。
    • 旧 sl, sl-updates に含まれていた sl-fastbugs を含む他のリポジトリは yum-conf-sl-other パッケージを別途入れなければならなくなった。

というわけで、SL 6.1 になったら次のようにインストール・設定するようにしました。普段設定しているやり方で紹介します。6.0 から更新された方も設定が上書きされているので同じように設定すれば良いです。

yum に関連したパッケージのインストール

yum に関連したパッケージをインストールします。

  • yum-conf-sl-other: sl-fastbugs を使うためにインストールします。
  • yum-plugin-fastestmirror: ミラーリポジトリリストのうち最もレスポンスの早いミラーリポジトリを使うためにインストールします。
  • yum-plugin-priorities: 外部リポジトリと混ぜて使用する際に標準リポジトリのバージョンを優先するためにインストールします。
    • 2011-08-28修正: torakitty さんにコメントでご指摘いただいたように yum-plugin-priorities が yum-conf-sl-other と誤って記述していたのを修正しました。

# yum -y install yum-conf-sl-other yum-plugin-fastestmirror yum-plugin-priorities

オリジナルの設定ファイルのバックアップ

オリジナルの設定ファイルをバックアップします。

yes no | cp -ai /etc/yum.repos.d/sl.repo /etc/yum.repos.d/sl.repo.default
yes no | cp -ai /etc/yum.repos.d/sl-other.repo /etc/yum.repos.d/sl-other.repo.default

sl.repo の設定

リポジトリミラーとして国内ミラーを優先して使うように設定します。

  • sl: 標準で有効化し、priority を最優先の 1 にします。
  • sl-security: 標準で有効化し、priority を最優先の 1 にします。
  • sl-source: 標準で無効化し、priority を最優先の 1 にします。
cat << '_EOF_' > /etc/yum.repos.d/sl.repo
[sl]
name=Scientific Linux $releasever - $basearch
mirrorlist = file:///etc/yum.repos.d/mirrors-sl
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-sl file:///etc/pki/rpm-gpg/RPM-GPG-KEY-dawson
priority=1

[sl-security]
name=Scientific Linux $releasever - $basearch - security updates
mirrorlist = file:///etc/yum.repos.d/mirrors-sl-security
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-sl file:///etc/pki/rpm-gpg/RPM-GPG-KEY-dawson
priority=1

[sl-source]
name=Scientific Linux $releasever - Source
mirrorlist = file:///etc/yum.repos.d/mirrors-sl-source
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-sl file:///etc/pki/rpm-gpg/RPM-GPG-KEY-dawson
priority=1
_EOF_
cat << '_EOF_' > /etc/yum.repos.d/mirrors-sl

http://ftp.ne.jp/Linux/packages/scientificlinux/$releasever/$basearch/os/

http://ftp.jaist.ac.jp/pub/Linux/scientific/$releasever/$basearch/os/

http://ftp.riken.jp/Linux/scientific/$releasever/$basearch/os/

http://ftp.scientificlinux.org/linux/scientific/$releasever/$basearch/os/

http://ftp1.scientificlinux.org/linux/scientific/$releasever/$basearch/os/

http://ftp2.scientificlinux.org/linux/scientific/$releasever/$basearch/os/

ftp://ftp.scientificlinux.org/linux/scientific/$releasever/$basearch/os/
_EOF_
cat << '_EOF_' > /etc/yum.repos.d/mirrors-sl-security

http://ftp.ne.jp/Linux/packages/scientificlinux/$releasever/$basearch/updates/security/

http://ftp.jaist.ac.jp/pub/Linux/scientific/$releasever/$basearch/updates/security/

http://ftp.riken.jp/Linux/scientific/$releasever/$basearch/updates/security/

http://ftp.scientificlinux.org/linux/scientific/$releasever/$basearch/updates/security/

http://ftp1.scientificlinux.org/linux/scientific/$releasever/$basearch/updates/security/

http://ftp2.scientificlinux.org/linux/scientific/$releasever/$basearch/updates/security/

ftp://ftp.scientificlinux.org/linux/scientific/$releasever/$basearch/updates/security/
_EOF_
cat << '_EOF_' > /etc/yum.repos.d/mirrors-sl-source

http://ftp.ne.jp/Linux/packages/scientificlinux/$releasever/SRPMS/

http://ftp.jaist.ac.jp/pub/Linux/scientific/$releasever/SRPMS/

http://ftp.riken.jp/Linux/scientific/$releasever/SRPMS/

http://ftp.scientificlinux.org/linux/scientific/$releasever/SRPMS/

http://ftp1.scientificlinux.org/linux/scientific/$releasever/SRPMS/

http://ftp2.scientificlinux.org/linux/scientific/$releasever/SRPMS/

ftp://ftp.scientificlinux.org/linux/scientific/$releasever/SRPMS/
_EOF_

sl-other.repo の設定

リポジトリミラーとして国内ミラーを優先して使うように設定します。

  • sl-fastbugs: 標準で有効化し、priority を最優先の 1 にします。
  • sl-debuginfo: 標準で無効化し、priority を最優先の 1 にします。
  • sl-testing: 標準で無効化し、priority を最優先の 1 にします。
  • sl-testing-source: 標準で無効化し、priority を最優先の 1 にします。
cat << '_EOF_' > /etc/yum.repos.d/sl-other.repo
[sl-fastbugs]
name=Scientific Linux $releasever - $basearch - fastbug updates
mirrorlist = file:///etc/yum.repos.d/mirrors-sl-fastbugs
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-sl file:///etc/pki/rpm-gpg/RPM-GPG-KEY-dawson
priority=1

[sl-debuginfo]
name=Scientific Linux Debuginfo
mirrorlist = file:///etc/yum.repos.d/mirrors-sl-debuginfo
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-sl file:///etc/pki/rpm-gpg/RPM-GPG-KEY-dawson
priority=1

[sl-testing]
name=Scientific Linux Testing - $basearch
mirrorlist = file:///etc/yum.repos.d/mirrors-sl-testing
enabled=0
gpgcheck=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-sl file:///etc/pki/rpm-gpg/RPM-GPG-KEY-dawson
priority=1

[sl-testing-source]
name=Scientific Linux Testing - Source
mirrorlist = file:///etc/yum.repos.d/mirrors-sl-testing-source
enabled=0
gpgcheck=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-sl file:///etc/pki/rpm-gpg/RPM-GPG-KEY-dawson
priority=1
_EOF_
cat << '_EOF_' > /etc/yum.repos.d/mirrors-sl-fastbugs

http://ftp.ne.jp/Linux/packages/scientificlinux/$releasever/$basearch/updates/fastbugs/

http://ftp.jaist.ac.jp/pub/Linux/scientific/$releasever/$basearch/updates/fastbugs/

http://ftp.riken.jp/Linux/scientific/$releasever/$basearch/updates/fastbugs/

http://ftp.scientificlinux.org/linux/scientific/$releasever/$basearch/updates/fastbugs/

http://ftp1.scientificlinux.org/linux/scientific/$releasever/$basearch/updates/fastbugs/

http://ftp2.scientificlinux.org/linux/scientific/$releasever/$basearch/updates/fastbugs/

ftp://ftp.scientificlinux.org/linux/scientific/$releasever/$basearch/updates/fastbugs/
_EOF_
cat << '_EOF_' > /etc/yum.repos.d/mirrors-sl-debuginfo

http://ftp.ne.jp/Linux/packages/scientificlinux/$releasever/archive/debuginfo/

http://ftp.jaist.ac.jp/pub/Linux/scientific/$releasever/archive/debuginfo/

http://ftp.riken.jp/Linux/scientific/$releasever/archive/debuginfo/

http://ftp.scientificlinux.org/linux/scientific/$releasever/archive/debuginfo/

http://ftp1.scientificlinux.org/linux/scientific/$releasever/archive/debuginfo/

http://ftp2.scientificlinux.org/linux/scientific/$releasever/archive/debuginfo/

ftp://ftp.scientificlinux.org/linux/scientific/$releasever/archive/debuginfo/
_EOF_
cat << '_EOF_' > /etc/yum.repos.d/mirrors-sl-testing

http://ftp.ne.jp/Linux/packages/scientificlinux/6rolling/testing/$basearch/

http://ftp.jaist.ac.jp/pub/Linux/scientific/6rolling/testing/$basearch/

http://ftp.riken.jp/Linux/scientific/6rolling/testing/$basearch/

http://ftp.scientificlinux.org/linux/scientific/6rolling/testing/$basearch/

http://ftp1.scientificlinux.org/linux/scientific/6rolling/testing/$basearch/

http://ftp2.scientificlinux.org/linux/scientific/6rolling/testing/$basearch/

ftp://ftp.scientificlinux.org/linux/scientific/6rolling/testing/$basearch/
_EOF_
cat << '_EOF_' > /etc/yum.repos.d/mirrors-sl-testing-source

http://ftp.ne.jp/Linux/packages/scientificlinux/6rolling/testing/SRPMS/

http://ftp.jaist.ac.jp/pub/Linux/scientific/6rolling/testing/SRPMS/

http://ftp.riken.jp/Linux/scientific/6rolling/testing/SRPMS/

http://ftp.scientificlinux.org/linux/scientific/6rolling/testing/SRPMS/

http://ftp1.scientificlinux.org/linux/scientific/6rolling/testing/SRPMS/

http://ftp2.scientificlinux.org/linux/scientific/6rolling/testing/SRPMS/

ftp://ftp.scientificlinux.org/linux/scientific/6rolling/testing/SRPMS/
_EOF_

設定の確認

yum コマンドを実行して設定を確認します。

# yum update
Loaded plugins: fastestmirror, priorities
Loading mirror speeds from cached hostfile
 * sl: ftp.ne.jp
 * sl-fastbugs: ftp.ne.jp
 * sl-security: ftp.ne.jp
Setting up Update Process
... 省略 ...

上記のように Loading mirror の後、sl, sl-fastbugs, sl-security が表示されれば設定が出来ています。

まとめ

SL 6.1 用の yum リポジトリの設定方法を紹介しました。SL 6.0 からリポジトリ設定ファイルの構成が変わっていますので、SL 6.1 環境では設定をし直した方が良いです。

設定中の priority は、RHEL/Scientific Linux/CentOS 5 から RHEL/Scientific Linux/CentOS 6 へ で触れた yum-conf-* を入れたら、1 より大きい数字を設定しておかないと優先度が反映されないので注意が必要です。

Scientific Linux 6.0 環境を 6.1 環境へアップグレードする方法


概要

Scientific Linux 6.1 (SL 6.1) がリリースされました。

早速 SL 6.0 環境を yum update で 6.1 にアップグレードしようとしてみましたが、RHEL/CentOS と違ってそのままでは 6.1 にアップグレードされませんでした。

Scientific Linux では /etc/yum.repos.d/sl.repo などで定義されている $releasever の変数の中身が 6 ではなく 6.0 とマイナーバージョンまで含めて入っているようで、最新マイナーバージョンの yum リポジトリが参照されず更新されないようです。

これは商用製品などで特定マイナーバージョンでないと動作保証が得られない環境がある方には嬉しい仕様です。以前仕事で携わったところで、環境構築をしている方々が RHEL 5.x では自動的にマイナーバージョンが上げることを把握しておらず、タイミング良く新しいマイナーバージョンがリリースされ、その夜の自動更新でバージョンが上がってしまい問題が発生したことがあったので、そういったマイナーバージョンを固定したい環境では役立つでしょう。

一方で、ずっと古いマイナーバージョンのままにするのも良くないので、アップグレードして良いタイミングになったら次のようにしてアップグレードします。

現在バージョンの確認

現在のバージョンを確認します。

# cat /etc/redhat-release
Scientific Linux release 6.0 (Carbon)
# rpm -qa sl-release --qf '%{v}\n'
6.0

$release 変数の中身が 6.0 になっています。

sl-release の更新

一気にすべてのパッケージを 6.1 のものに更新しても良いと思いますが、まずは sl-release だけを更新します。

# yum --releasever=6.1 update sl-release
... 省略 ...
Dependencies Resolved

========================================================================================================================
 Package                         Arch                        Version                      Repository               Size
========================================================================================================================
Updating:
 sl-release                      x86_64                      6.1-2                        sl                       32 k

Transaction Summary
========================================================================================================================
Install       0 Package(s)
Upgrade       1 Package(s)

Is this ok [y/N]: y
Downloading Packages:
sl-release-6.1-2.x86_64.rpm                                                                      |  32 kB     00:00

更新されたバージョンの確認

更新されたバージョンを確認します。

# cat /etc/redhat-release
Scientific Linux release 6.1 (Carbon)
# rpm -qa sl-release --qf '%{v}\n'
6.1

6.1 になりました。

すべてのパッケージを更新

すべてのパッケージを更新します。

# yum update
... 省略 ...
Transaction Summary
========================================================================================================================
Install       1 Package(s)
Upgrade     147 Package(s)

Total download size: 132 M
Is this ok [y/N]: y

これで無事 Scientific Linux 6.1 環境へのアップグレードが完了しました。

今日(2011-07-29)時点では、Scientific Linux 6.0 のリポジトリで既に RHEL 6.1 の更新を先取りした最新 Kernel まで更新されていたので、既にその最新 Kernel を使用していたのであれば OS ごと再起動しなくても良いですが、更新前に最新 Kernel を使っていなかった場合や、いろいろ更新されたのですっきりしたい方は一度 OS ごと再起動しておくと良いです。

RHEL/Scientific Linux/CentOS 5 から RHEL/Scientific Linux/CentOS 6 へ


概要

  • [2011-07-17追記]: sl-fastbugs の国内リポジトリミラーを追加しました。

CentOS 6.0 がリリースされ、これから Red Hat Enterprise Linux 6.0 (RHEL 6.0) 系 に更新するのに Scientific Linux 6.0 (SL 6.0) と CentOS 6.0 のどちらに更新しようか迷っている方が多いと思います。

そんな方向けに 5.x から 6.0 になって何が変わったのか、そして、SL と CentOS で何が違うのか気付いた点をまとめておきます。前者は有償サポートのある RHEL 6.0 へ移行する際にも参考になると思います。

RHEL 6.0、SL 6.0、CentOS 6.0 の収録パッケージの違い

まずは、一番気になるであろう RHEL 6.0、SL 6.0、CentOS 6.0 の収録パッケージの違いをまとめます。6.0 では、収録パッケージの違いは SL も CentOS も下記にあげるように最小限に留まっており、基本的にオリジナルの RHEL 6.0 リリース時点と同じバージョンが収録されています。

RHEL 6.0 と SL 6.0 の違い

SL 5.x では、RHEL 5.x に R や graphviz などのパッケージも加えていましたが、6.0 では最低限の追加しかされていません。

下記は SL 6.0 に追加・修正されているパッケージの一覧です。それぞれのパッケージの詳細は、Scientific Linux 6.0 Release Notes に書かれています。

追加されたパッケージ

  • SL_desktop_tweaks-6-3.src.rpm
  • SL_enable_serialconsole-4.0-1.src.rpm
  • SL_no_colorls-1.0-3.src.rpm
  • SL_password_for_singleuser-3.0-1.src.rpm
  • glib-1.2.10-33.el6.src.rpm
  • gtk+-1.2.10-70.el6.src.rpm
  • icewm-1.2.37-1.2.src.rpm
  • imlib-1.9.15-14.el6.src.rpm
  • livecd-tools-0.3.6-3.el6.src.rpm
  • liveusb-creator-3.9.2-sl6.0.7.rolling.src.rpm
  • openafs-firstboot-1.6-1.sl6.src.rpm
  • openafs.SLx-1.6.0-91.pre2.src.rpm
  • revisor-2.2-2.sl6.4.src.rpm
  • sl-release-6.0-6.0.0.37.sl6.0.92rolling.src.rpm
  • sl-revisor-configs-1-6.0.src.rpm
  • yum-autoupdate-2-1.src.rpm
  • yum-conf-adobe-6-1.src.rpm
  • yum-conf-atrpms-6-1.src.rpm
  • yum-conf-elrepo-6-1.src.rpm
  • yum-conf-epel-6-1.src.rpm
  • yum-conf-rpmforge-6-1.src.rpm
  • yum-conf-sl6x-1-1.src.rpm

最小構成で自動的にインストールされるのは、sl-release と yum-autoupdate のみです。

修正されたパッケージ

  • anaconda-13.21.82-1.sl6.2.src.rpm
  • epydoc-3.0.1-5.1.el6.0.sl6.src.rpm
  • guile-1.8.7-4.el6.0.sl6.src.rpm
  • httpd-2.2.15-5.sl6.src.rpm
  • kdepim-runtime-4.3.4-4.el6.0.sl6.src.rpm
  • linuxdoc-tools-0.9.65-3.el6.0.sl.src.rpm
  • mod_auth_kerb-5.4-6.el6.0.sl6.src.rpm
  • nss-3.12.7-2.el6.0.sl6.src.rpm
  • opal-3.6.6-4.el6.0.sl6.src.rpm
  • pilot-link-0.12.4-6.el6.0.sl6.src.rpm
  • plymouth-0.8.3-17.sl6.2.src.rpm
  • redhat-logos-60.0.14-1.sl6.1.src.rpm
  • report-0.18-7.sl6.src.rpm
  • rome-0.9-4.2.el6.0.sl6.src.rpm
  • ruby-1.8.7.299-4.el6.0.sl6.1.src.rpm
  • sl-bookmarks-6-1.sl6.src.rpm
  • sl-indexhtml-6-1.sl6.src.rpm
  • sl-release-6.0-6.0.1.src.rpm
  • sl-release-notes-6.0-0.1.rolling.src.rpm

追加パッケージのうち運用時に便利なのは、yum-autoupdate と yum-conf-* です。yum-autoupdate は後述しますが、yum による自動更新を実行するツールです。yum-conf-* は、外部リポジトリを使用するリポジトリファイルです。メジャーな外部リポジトリは収録されていて、すぐに外部リポジトリを使用できるのは使い勝手が良いです。

RHEL 6.0 と CentOS 6.0 の違い

CentOS のインストールメディアはなるべく RHEL と同じになるように追加パッケージは基本的にありません。ただし、extras リポジトリで独自のパッケージを追加していくので、一概に SL と比較できません。なお、執筆時点では、6.0 の extras リポジトリはまだ空です。したがって、CentOS 5.x で extras リポジトリにあるものを期待して使用していた方は、今すぐ 6.0 に乗り換えると困るかもしれません。

下記は CentOS 6.0 に追加・修正されているパッケージの一覧です。CentOS 6.0 リリースノート には、削除したパッケージも書かれています。

追加されたパッケージ

  • centos-indexhtml-6-1.el6.centos.src.rpm
  • centos-release-6-0.el6.centos.5.src.rpm

修正されたパッケージ

  • anaconda-13.21.82-1.el6.centos.1.src.rpm
  • firefox-3.6.9-2.el6.centos.src.rpm
  • httpd-2.2.15-5.el6.centos.src.rpm
  • kabi-whitelists-20100820-1.el6.centos.src.rpm
  • kabi-yum-plugins-1.0-2.el6.centos.src.rpm
  • kde-settings-4.3.1-1.el6.centos.src.rpm
  • luci-0.22.2-14.el6.centos.src.rpm
  • openssl098e-0.9.8e-17.el6.centos.src.rpm
  • plymouth-0.8.3-17.el6.centos.src.rpm
  • redhat-bookmarks-6-1.el6.centos.src.rpm
  • report-0.18-7.el6.centos.src.rpm
  • yum-3.2.27-14.el6.centos.src.rpm

CentOS 6.0 では、リリース時点で自動更新のためのツールが含まれていません。従来あった yum-updated や yum-cron も無くなっているため、自動更新をするには何らかの仕組みを自分で用意する必要があります。

5.x と 6.0 の違い

5.x から 6.0 になってメジャーバージョンが変わったこともあって、いろいろと大きく変わっています。主に下記の点が変わっています。

インストールモード

インストールモードにはこれまで同様、Text mode と Graphical mode がありますが、Text mode では次のことができなくなっています。

  • ストレージの構成とパーティションレイアウトの修正
  • インストールパッケージの選択

5.x の時にも Text mode では、Linux MD や LVM の VG を一部編集することができない制限がありましたが、6.0 からはストレージの構成とパーティションレイアウトの修正も出来なくなったので、多くの場合、Graphical mode でインストールする必要があります。

なお、搭載メモリが 652MB 以下の場合、自動的に Text mode でインストーラが起動します。それ以外で Text mode でインストールしたい場合は、インストーラメディアブート時の grub メニューで Tab を押して、ブートパラメータの末尾に text を付けて起動すれば良いです。

Graphical mode では、Shift + Print Screen を押すと、画面のスクリーンキャプチャが下記のディレクトリに保存されるので記録を残したい方はこれを利用すると良いです。

  • /root/anaconda-screenshot/screenshot-NNNN.png

インストールパッケージ

インストールパッケージはサーバとして使用するなら インストールタイプを Minimal にし、Customize now をチェックして、次のパッケージグループを足すのが良いでしょう。他の必要なサーバソフトウェアは後から yum で入れれば良いです。

  • Base System
    • Base
  • Development
    • Additional Development
    • Development tools

CentOS 6.0 の場合、デフォルトで Minimal が選択されています。一方、Scientific Linux 6.0 の場合、デフォルトで Desktop が選択されているので一番下にある Minimal を選択する必要があります。さらに、Scientific Linux 6.0 の場合、Minimal にしても次のパッケージグループがインストールするようにチェックされています。

  • SL Addons
    • Misc Scientific Linux Packages
  • Scalable Filesystem Support
    • Scalable Filesystems

これらが不要な場合はチェックを外してしまって問題ありません。参考までにチェックしたままだと、それぞれ下記のパッケージがインストールされます。内容から判るとおり xfs を使わない限り必要ないです。

Misc Scientific Linux Packages

このパッケージグループには下記のパッケージが所属していますが、optional 指定になっているため、実際にはインストールされません。

  • SL_desktop_tweaks
  • SL_enable_serialconsole
  • SL_enable_serialconsole-192
  • SL_enable_serialconsole-384
  • SL_enable_serialconsole-1152
  • SL_no_colorls
  • SL_password_for_singleuser
  • revisor

Scalable Filesystems

  • xfsprogs
  • xfsdump

また、CentOS では yum-plugin-fastestmirror が自動的にインストールされますが、SL ではインストールされません。

NIC の識別

6.0 から NIC の識別には /etc/udev/rules.d/70-persistent-net.rules が使用されています。このファイルには、ethX と NIC の MAC アドレスを紐づける設定が書かれていて、NIC を増減しても常に同じ NIC に同じ ethX が割り当てられることが保証されます。しかし、VM などでイメージをコピーして使いまわす時にはこの仕組みが邪魔となり、VM コピーに伴い NIC の MAC アドレスが変わると NIC を認識できなくなります。

したがてって、VM イメージをコピーする時には、次のどちらかの方法で対処する必要があります。

  1. /etc/udev/rules.d/70-persistent-net.rules を削除して再起動します。
    • 再起動後、自動的にファイルが生成されます。
  2. /etc/udev/rules.d/70-persistent-net.rules を修正して再起動します。
    • MAC アドレスを正しいものに書き換えるか、不要な NIC の情報を削除します。
    • 再起動後、自動的にファイルが修正されます。

国内リポジトリミラー

SL も CentOS も国内リポジトリミラーは充実しています。必要に応じて mirrorlist を修正すると良いです。

SL 6.0

  • sl (/etc/yum.repos.d/sl.repo)
http://ftp.riken.jp/Linux/scientific/$releasever/$basearch/os/

http://ftp.ne.jp/Linux/packages/scientificlinux/$releasever/$basearch/os/

http://ftp.jaist.ac.jp/pub/Linux/scientific/$releasever/$basearch/os/
  • sl-security (/etc/yum.repos.d/sl-updates.repo)
http://ftp.riken.jp/Linux/scientific/$releasever/$basearch/updates/security/

http://ftp.ne.jp/Linux/packages/scientificlinux/$releasever/$basearch/updates/security/

http://ftp.jaist.ac.jp/pub/Linux/scientific/$releasever/$basearch/updates/security/
  • sl-fastbugs (/etc/yum.repos.d/sl-updates.repo)
    • CentOS 6 では updates に含まれている バグ fix

http://ftp.riken.jp/Linux/scientific/$releasever/$basearch/updates/fastbugs/

http://ftp.ne.jp/Linux/packages/scientificlinux/$releasever/$basearch/updates/fastbugs/

http://ftp.jaist.ac.jp/pub/Linux/scientific/$releasever/$basearch/updates/fastbugs/

CentOS 6.0

  • base (/etc/yum.repos.d/CentOS-Base.repo)
http://ftp.riken.jp/Linux/centos/$releasever/os/$basearch/

http://ftp.ne.jp/Linux/packages/CentOS/$releasever/os/$basearch/

http://ftp.jaist.ac.jp/pub/Linux/CentOS/$releasever/os/$basearch/

http://ftp.iij.ad.jp/pub/linux/centos/$releasever/os/$basearch/
  • updates (/etc/yum.repos.d/CentOS-Base.repo)
http://ftp.riken.jp/Linux/centos/$releasever/updates/$basearch/

http://ftp.ne.jp/Linux/packages/CentOS/$releasever/updates/$basearch/

http://ftp.jaist.ac.jp/pub/Linux/CentOS/$releasever/updates/$basearch/

http://ftp.iij.ad.jp/pub/linux/centos/$releasever/updates/$basearch/

自動更新

SL 6.0 と CentOS 6.0 の自動更新について説明します。

SL 6.0

SL 6.0 では yum-autoupdate が自動的にインストールされます。このパッケージは、SL 独自に追加されているパッケージであるため CentOS ではインストールされません。

yum-autoupdate の設定ファイルは、/etc/sysconfig/yum-autoupdate にあります。デフォルトでは下記のパッケージが自動更新から除外されています。

  • kernel*
  • openafs*
  • *-kmdl-*
  • kmod-*
  • *firmware*

これらも自動更新したい場合は設定ファイルの EXCLUDE を空にするか、コメントアウトすれば良いです。

$ diff -u /etc/sysconfig/yum-autoupdate.default /etc/sysconfig/yum-autoupdate
--- /etc/sysconfig/yum-autoupdate.default       2011-02-17 07:19:32.000000000 +0900
+++ /etc/sysconfig/yum-autoupdate       2011-06-06 14:01:48.736885290 +0900
@@ -24,7 +24,7 @@
 # EXCLUDE
 #   This is a space deliminated list
 #   Example:  EXCLUDE="kernel* openafs* *-kmdl-* kmod-* *firmware*"
-EXCLUDE="kernel* openafs* *-kmdl-* kmod-* *firmware*"
+#EXCLUDE="kernel* openafs* *-kmdl-* kmod-* *firmware*"

 # DEBUG
 #     true - turn on debug mode (be more verbose)

yum-autoupdate は /etc/cron.daily/yum-autoupdate から毎朝実行されます。また、更新パッケージがある時は root 宛に更新したパッケージ一覧が記載されたメールが送信されます。この宛先は設定ファイルで変更できます。

CentOS 6.0

前述したように CentOS 6.0 では自動更新の仕組みが提供されていません。今後、何らかの公式のパッケージが提供されるかもしれませんが、実運用に困る方は下記のような /etc/cron.daily/yum.cron などを作っておくのが良いと思います。

cat << '_EOF_' > /etc/cron.daily/yum.cron
#!/bin/sh

/usr/bin/yum -R 120 -e 0 -d 0 -y update yum
_EOF_
chmod 755 /etc/cron.daily/yum.cron

その他の 5.x から 6.0 になって変わったこと

その他、SL と CentOS に限らず、RHEL 5.x から 6.0 になって個人的に影響があった変更点を箇条書きします。

その他の違いや詳細は、Red Hat 社の Red Hat Enterprise Linux 6 移行計画ガイド を見ると良いです。

  • デフォルトのファイルシステムが ext3 から ext4 に変更されました
  • Xen が無くなり、KVM のみになりました
    • KVM: -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0×4 がない時、-balloon virtio をオプション指定しないとバルーンメモリが有効になりませんでした
  • iptables で ! を使う時はオプションの前にしないとエラーになるようになりました
    • NG: -s ! 10.0.0.0/24
    • OK: ! -s 10.0.0.0/24
  • BIND の caching-nameserver は bind パッケージに統合されました
  • Dovecot の設定書式が変わりました
  • OpenLDAP の設定書式が変わりました
    • 設定も DB で持てるようになりました
  • LDAP クライアント化するのに nscd に加えて nslcd デーモンが必要になりました

まとめ

メジャーバージョンが 5.x から 6.0 になったことで多くのパッケージにもメジャーバージョンが更新されました。パッケージによっては設定書式が変わっていて一から調べなおす必要があることもあります。

6.0 では SL 6.0 と CentOS 6.0 で大きな違いはありません。個人的には yum-autoupdate と yum-conf-* が気に入ったのと、SL の方がリリースサイクルが早そうだという理由でこれから作るサーバで OS を決めて良い時はすべて SL にしようと考えています。

SL を使用する難点としては、まだ VPS サーバなどでは CentOS の方がサポートされていることが多いことですが、これも最近の状況からすると徐々に SL のシェアが増えるんじゃないかなと思います。

Munin Plugin: ipmitool_sensor_ 1.5 & 1.6


Munin Plugin である ipmitool_sensor_ plugin の新しいバージョン 1.5 をリリースしました。

[2011-02-07追記]: コメントにて kikumoto さんよりご指摘いただいたとおり、temp_upper_warning と temp_upper_critical が逆になっていたので修正したバージョン 1.6 をアップロードしました。

このバージョンの変更点は下記のとおりです。

  • temp_upper_warning と temp_upper_critical の設定が有効に動作していなかったのを修正

設定値を取得するところで指定する設定名を typo していて正常に動作していませんでした。なお、今回の修正は、メールでご指摘いただきました(メールでお名前載せてよいか確認し忘れたのでとりあえず未記載で)。ご指摘ありがとうございました。

久しぶりに Munin Exchange を除いてみたところ、IPMI 関係の Plugin は現在 7 個あるようです。

各ページに飛ぶとダウンロード数が出ます。ipmitool_sensor_ plugin は、今のところ 431 回ダウンロードされていて、ipmi plugin の中では一番使っていただけているようでした。IPMI という超マイナー需要向けの Plugin なので、他カテゴリの Plugin に比べたら全然少ない回数ですが嬉しいです。

DellのサーバマシンのBIOS設定をLinux上から行う方法


  • 要約: activateCmosToken 0xXXXX でDellのサーバマシンのBIOS設定は変えられます (但し、サポート外)

既に CentOS 5.x をインストール済みの Dell PowerEdge 830 サーバで、OS上でメモリがなぜか256MBしか認識されていませんでした。何か壊れてるのかと思い、既にインストールしてあったDell提供のサーバ管理ソフトウェア OpenManage でハードウェア情報を確認してみると、1GBのメモリが2枚認識されており、合計2GBと表示されていました。

そこで調べてみるとDellのサーバマシンのBIOSには、巨大なメモリが見えるとインストールが失敗するようなOSインストール用に OS Install Mode という設定があり、これが Enable になっているとメモリが256MBしか見えないようにハード的に制約を加えるようです。

というわけで、BIOSの設定を変えれば良いことが判りました。でも、このサーバは遠隔地に置いてあって、現地に行くのがちょっと大変です。こういう時にリモートKVMが使える別売りのDell Remote Access Controller(DRAC)が入っていれば、BIOS画面を直に見ながら簡単に設定できるのですが、残念ながらこのマシンにはDRACは入っていませんでした。というわけで、Linux上からBIOSの設定を変えられないのかなと調べたら変えられました。方法としては次の2つあります。

  1. OpenManage 上のBIOS設定で変更
  2. smbios に含まれるコマンドで変更

1は、WEB UIから設定する方法ですが、設定できる項目に限りがありました。基本的な項目以外は設定できないと思って良いでしょう。今回設定を変えたかった OS Install Mode も設定できませんでした。以下に、PowerEdge 830 で設定可能な項目と設定されていた値を記しておきます。

  • 一般
    • Num Lock: オン
    • Diskette: 自動
    • NIC: PXE で有効
    • USB: BIOS サポートありで有効
    • IDE: 自動
    • Boot Sequence: デバイスリスト
    • Speaker: オン
    • CPU Logical Processor (HyperThreading): 有効
    • AC Power Recovery Mode: 最終
    • Embedded SATA Controller: ATA
    • SATA Port 0: 自動
    • SATA Port 1: 自動
    • SATA Port 2: オフ
    • SATA Port 3: オフ
    • IDE Primary Drive 0: 自動
    • IDE Primary Drive 1: オフ
    • Demand-Based Power Management: 無効
  • シリアル通信
    • Serial Port 1: 不明
    • Console Redirection After Boot: 有効
    • Console Redirection: シリアルポート 1
    • Console Redirection Failsafe BAUD Rate: 19200

OpenManage はyumで簡単にインストールできるので、上記で設定した項目があれば、OpenManage で設定するのが良いと思います。

2は、コマンドラインから設定する方法です。smbios と libsmbios は、OpenManage を入れると一緒にインストールされるDellのサーバマシンのBIOSにアクセスするためのユーティリティ群です。

こちらはおそらくDellのサーバマシンに用意されているBIOSの設定項目すべてを設定できるのだと思います。ただし、BIOSの設定を変える activateCmosToken というコマンドは Unsupported Binaries に分類されています。従って、この記事を読んで設定したらBIOSが壊れてマシンが起動しなくなることもあるかもしれません。そうなっても自分で責任とれる方以外は絶対に行わない方が良いでしょう。

というわけで、設定の仕方です。設定を行うのはactivateCmosToken コマンドを使います。基本構文は次のとおりです。

# /usr/sbin/activateCmosToken 0x"Token Value"

Token Valueというのは、BIOS設定の項目とというる値に対してユニークに割り振られている値になります。Token Valueの一覧は以下にあります。先頭の項目がToken Valueになります。

見てみれば判りますが、よくあるBIOS設定項目、最新の技術に関する設定項目、そして、Dell独自の設定項目があります。

現在の値を確認するには、isCmosTokenActive コマンドを使います。activateCmosToken 同様、引数に 0x"Token Value" を取ればいいだけです。出力の BITFIELD が 1 の場合、それが有効になっているという意味です。

では具体的に OS Install Mode を設定を変え、設定が変わっているか確認します。Token Value List より、OS Install Mode のとりうる値は Enable と Disable の2つで、それぞれに 0x008a と 0x008b の Token Value が割り当てられています。片方の Token Value に対して activateCmosToken を実行すると、もう片方の Token Value の BITFIELD が無効を示す 0 に自動的に変わります。

  • Limit System Memory (OS Install Mode) を無効化する方法
# /usr/sbin/activateCmosToken 0x008b
DMI type 0xd4  Handle 0xd401  Index Port 0x70  Data Port 0x71  Type 0x008b  Location 0x55 AND(fe) OR(0)  BITFIELD: 1
# /usr/sbin/isCmosTokenActive 0x008a
Running...
DMI type 0xd4  Handle 0xd401  Index Port 0x70  Data Port 0x71  Type 0x008a  Location 0x55 AND(fe) OR(1)  BITFIELD: 0
# /usr/sbin/isCmosTokenActive 0x008b
Running...
DMI type 0xd4  Handle 0xd401  Index Port 0x70  Data Port 0x71  Type 0x008b  Location 0x55 AND(fe) OR(0)  BITFIELD: 1
  • Limit System Memory (OS Install Mode) 有効化する方法
# /usr/sbin/activateCmosToken 0x008a
DMI type 0xd4  Handle 0xd401  Index Port 0x70  Data Port 0x71  Type 0x008a  Location 0x55 AND(fe) OR(1)  BITFIELD: 1
# /usr/sbin/isCmosTokenActive 0x008a
Running...
DMI type 0xd4  Handle 0xd401  Index Port 0x70  Data Port 0x71  Type 0x008a  Location 0x55 AND(fe) OR(1)  BITFIELD: 1
# /usr/sbin/isCmosTokenActive 0x008b
Running...
DMI type 0xd4  Handle 0xd401  Index Port 0x70  Data Port 0x71  Type 0x008b  Location 0x55 AND(fe) OR(0)  BITFIELD: 0

以上です。設定はマシンを再起動すると反映されます。

実際に上記の OS Install Mode を無効化する方法で実際に設定しました。その結果、次のように正常にメモリ2GB認識されるようになりました。

  • 設定前
# free
             total       used       free     shared    buffers     cached
Mem:        252164     232364      19800          0       9264     129620
-/+ buffers/cache:      93480     158684
Swap:      2097144        236    2096908
  • 設定後
# free
             total       used       free     shared    buffers     cached
Mem:       2059368     220968    1838400          0      10396     134724
-/+ buffers/cache:      75848    1983520
Swap:      2097144          0    2097144

無事、サーバのある現地に行くことなく、BIOS設定を変えることができました。遠隔地にあるサーバマシンのBIOS設定をどうしてもリモートで変えたい場合は、試してみると良いかもしれません。ただし、サポート外の方法ですので、BIOSが壊れて起動しなくなるかもしれないことは覚えておいてくださいね!

仮想化環境をテストする環境


最近XenとKVMのHVM環境を比較して試していますが、これまで1台のマシン環境を毎回壊して作り直していました。これが毎回面倒なため、現在、他の用途だったマシンを2台潰して再構築しています。

仮想化環境をテストするのに、PVM環境をテストするなら適当な仮想化環境上(例: VMwareの上でXen PVM環境)で問題ないものの、HVM環境をテストするにはVT対応のCPUが載った実機が必要になるので面倒です。最近のCPUでないとVT対応していないし、VMをたくさん動かすにはメモリもたくさん必要で、そこらへんに余ってる古いマシンで試せず困りものです。

最終的にあと2台用意してXenとKVMを2ノードづつ計4台の環境にしたいものの残り2台をどうしようかな。

XenからKVMへ、ファイルからLVMへ


この日記が動いてるサーバはまだXenですが、新しく仮想マシンをたくさん作る機会があったので、XenからKVMに乗り換えました。OSはdebootstrapになっていますが、virt-installで強引なことしているのでDebianじゃなくてCentOSに入れ替わっています。

# gnt-instance list
Instance           Hypervisor OS          Primary_node    Status     Memory
admin1.example.org   kvm        debootstrap node1.example.org running      1.0G
admin2.example.org   kvm        debootstrap node2.example.org running      1.0G
cron1.example.org    kvm        debootstrap node1.example.org running      1.0G
db1.example.org      kvm        debootstrap node1.example.org running      1.0G
ftp1.example.org     kvm        debootstrap node2.example.org running      512M
irc1.example.org     kvm        debootstrap node1.example.org running      512M
lvs1.example.org     kvm        debootstrap node2.example.org running      512M
lvs2.example.org     kvm        debootstrap node1.example.org running      512M
mail1.example.org    kvm        debootstrap node1.example.org running      1.0G
mail2.example.org    kvm        debootstrap node2.example.org running      1.0G
nouse.example.org    kvm        debootstrap node2.example.org ADMIN_down      -
template.example.org kvm        debootstrap node1.example.org ADMIN_down      -
web1.example.org     kvm        debootstrap node2.example.org running      1.0G
web-ssl1.example.org kvm        debootstrap node1.example.org running      1.0G
web-ssl2.example.org kvm        debootstrap node2.example.org running      1.0G

ディスクイメージもファイルからLVMへ乗り換えました。I/O的にも早くなりましたし、1仮想マシンに1LV割り当てたのでライブマイグレーションも出来るようになりました。

# cat /proc/drbd
version: 8.3.2 (api:88/proto:86-90)
GIT-hash: dd7985327f146f33b86d4bff5ca8c94234ce840e build by mockbuild@v20z-x86-64.home.local, 2009-08-29 14:07:55

 1: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
    ns:1030228 nr:0 dw:1030228 dr:515856 al:499 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
 2: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----
    ns:0 nr:684592 dw:684592 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
 3: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
    ns:282556 nr:0 dw:282556 dr:432780 al:226 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
 4: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----
    ns:0 nr:594628 dw:594628 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
 5: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
    ns:281224 nr:0 dw:281224 dr:433112 al:242 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
 6: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----
    ns:0 nr:281116 dw:281116 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
 7: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
    ns:281048 nr:0 dw:281048 dr:432008 al:227 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
 8: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----
    ns:0 nr:283900 dw:283900 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
 9: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
    ns:286256 nr:0 dw:286256 dr:430084 al:242 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
10: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----
    ns:0 nr:281384 dw:281384 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
11: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
    ns:306608 nr:0 dw:306608 dr:532548 al:286 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

13: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
    ns:681680 nr:0 dw:681680 dr:823276 al:468 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
14: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----
    ns:0 nr:571076 dw:571076 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

100: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
    ns:48640 nr:0 dw:48640 dr:217 al:23 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
101: cs:Connected ro:Secondary/Secondary ds:UpToDate/UpToDate C r----
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:188

今回KVMを使ってみて、XenとKVMでは、ホストマシン上でのCPU(uptime)とメモリ(free)の表示が違っていることに気付きました。

Xenを使った時のuptimeの表示は、ホスト側も特殊なDom0 Kernelなのでゲスト側でCPUに負荷が掛かってもホスト側のuptimeにその負荷具合が反映されませんでした。一方、KVMの場合はゲストマシンは1プロセスとして見えるので、ゲスト側に負荷を与えるとホスト側のuptimeの表示に負荷具合が反映されました。

Xenを使った時のfreeの表示は、dom_mem0を指定していない場合、割り当てたメモリ分だけtotalの値が減り、ホスト側では見えなくなります。一方、KVMの場合は起動時に指定したメモリを上限とし、実際にゲスト上でメモリが使用されるとホスト側のfreeが消費されてusedが増えていき、totalの値は常に物理メモリの量のままでした。つまり常に動的なバルーン機能が働いているような状態。もしくは、Sparseファイルのメモリ版のような状態。

どちらが良いかは好みですが、ホスト側で状況を把握できるKVMの方が良い気がしています。あと、最近はXenよりKVMが推されているようなので今後はXenとKVMどちらでも良い場合はKVMを使っていこうと思っています。

DRBD 8.3.x + Heartbeat 2.1.4 + CRMのDRBDリソース を使用する場合の修正


  • DRBD 8.3.x + Heartbeat 2.1.4 を使用する場合、この修正が必要です。
  • DRBD 8.2.x + Heartbeat 2.1.4 を使用する場合、この修正は不要です。

DRBD 8.3.x にアップデートしたら、HeartbeatでCRMのDRBDリソースが上手く動かなくなりました。以下のようなエラー。

lrmd[11950]: 2009/09/03_14:15:12 info: rsc:drbd1:0: start
crmd[11953]: 2009/09/03_14:15:12 info: do_lrm_rsc_op:
 Performing op=drbd1:1_start_0 key=xx:4:0:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)
crmd[11953]: 2009/09/03_14:15:12 info: do_lrm_rsc_op:
 Performing op=drbd1:0_start_0 key=xx:4:0:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)
lrmd[11950]: 2009/09/03_14:15:12 info: RA output: (drbd1:0:start:stdout) 1:
 Failure: (124) Device is attached to a disk (use detach first)
 Command 'drbdsetup 1 disk /dev/VolGroup01/DRBD1 /dev/VolGroup01/DRBD1 internal
  --set-defaults --create-device' terminated with exit code 10
drbd[12636]:    2009/09/03_14:15:12 ERROR: drbd1 start: not in Secondary mode after start.
crmd[11953]: 2009/09/03_14:15:12 info: process_lrm_event:
 LRM operation drbd1:0_start_0 (call=16, rc=1) complete

原因はDRBDリソースが drbdadm state コマンドを使っているせいです。8.3からは drbdadm role コマンドを使うのが正しいそうです。以下、drbdadmコマンドの実行例です。

# drbdadm state drbd1
drbdadm state' is deprecated, use 'drbdadm role' instead.
Primary/Secondary

1行目の警告が邪魔してHeartbeatが上手く動かないようです。しょうがないので手動でDRBDリソース /usr/lib/ocf/resource.d/heartbeat/drbd を修正しましょう。以下、修正後のdiffです。

# diff /usr/lib/ocf/resource.d/heartbeat/drbd.default /usr/lib/ocf/resource.d/heartbeat/drbd
235c235
<       DRBD_STATE=$(do_drbdadm state $RESOURCE)
---
>       DRBD_STATE=$(do_drbdadm role $RESOURCE)

これで上手く起動するようになります。たぶん、Heartbeat 2.1.5 がリリースされれば修正されたものがインストールされます。

ちなみに Heartbeat 2.1.3 の Master/Slaveリソースはバグってて、1個のMaster/Slaveリソースでフェイルオーバが始まると他のすべてのMaster/Slaveリソースも一旦ダウンしてしまうので使わない方が良いです。

CentOS 4 と CentOS 5 のDRBDパッケージに8.3.x系が加わる予定


後輩から教えて貰いました。CentOS 4 と CentOS 5 のDRBDパッケージにDRBD 8.3系が加わるようです。来週リリースされるらしいので準備しておきましょう。

今までCentOS 5では、DRBD 8.0系と8.2系があって、それぞれdrbd-8.0.x, kmod-drbd-8.0.xとdrbd82-8.2.x, kmod-drbd82-8.2.xというパッケージがありましたが、これにdrbd83-8.3.x, kmod-drbd83-8.3.xが加わるようです。

パッケージ名が違うので勝手に入ることはないと思いますが既に使っている方は把握しておいた方が良いでしょう。既に使っていて8.3系に更新する場合は、上記のブログではセカンダリノードから更新していく手順が書かれています。

手元の環境はたすき掛けにしているので、結果的に一気にやることになりますね。

[追記] 9/2にリリースされました。

Windows Vista 64-bit版 から Windows 7 64-bit版 へ


そんなことしてる暇もない気がすごくするものの、ちょっと前にビデオドライバを入れ直したあたりから動作が怪しくなっていたVista 64-bit版環境から脱出するためにWindows 7 64-bit版をクリーンインストールして移行してみた。Vista 64-bit版で動いていたソフトやJava関係は軽く使ってみた感じどれも問題無さそう。ウィルスバスター2009 64-bit版も一応動くらしいけど念のためこれだけまだ入れてない。

ホーム > Admin

検索
フィード
メタ情報

Return to page top