Home

ふたつの川うるおう日記

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 に比べたら全然少ない回数ですが嬉しいです。

WP FreeStyle Wiki の Plugin Directory への登録


去年の年末年始(2009-2010)に書いた WP FreeStyle Wiki を、WordPress の Plugin Directory に登録しました。

Plugin Directory に登録したことで、WordPress の管理画面のプラグインから新規追加や自動更新できるようになりました。また、同封する FreeStyle Wiki を FreeStyle Wiki 3.6.4 にバージョンアップして、Plugin Directory 用に修正した WP FreeStyle Wiki 0.2.2 をリリースしてあります。

古いサーバでJDK 6 Update 18に更新したらタイムゾーンがJSTからGMTに変わった件と対処法

  • 2010-01-20 (水)
  • Java

とある古いサーバにインストールされているJDK 6 Update 17をJDK 6 Update 18に更新したらデフォルトのタイムゾーンがJSTからGMTに変わってしまいました。他のサーバでは問題なかったのでこの古いサーバ限定の問題です。

状況を確認するためにサンプルコードを動かして確認しました。

import java.util.Date;

public class DateTest {
    public static void main(String[] args) {
        System.out.println(new java.util.Date());
    }
}

実行してみます。

# /usr/local/java/jdk1.6.0_17/bin/java DateTest
Wed Jan 20 21:42:44 JST 2010
# /usr/local/java/jdk1.6.0_18/bin/java DateTest
Wed Jan 20 12:42:56 GMT 2010

というようにJDK 6 Update 17ではJSTなのにJDK 6 Update 18だとGMTになってしまいました。JVMのタイムゾーンがGMTになる 追記と同じ原因のようで、/etc/localtime を調べてみたら /usr/share/zoneinfo/Asia/Tokyo と違うものでした。

# ls -al /etc/localtime
-rw-r--r--  1 root root 73 Feb 26  2004 /etc/localtime
# ls -al /usr/share/zoneinfo/Asia/Tokyo
-rw-r--r--  2 root root 125 Mar 22  2006 /usr/share/zoneinfo/Asia/Tokyo

というわけで、コピーして直します。

cp -a /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

再び確認します。

# /usr/local/java/jdk1.6.0_17/bin/java DateTest
Wed Jan 20 21:49:58 JST 2010
# /usr/local/java/jdk1.6.0_18/bin/java DateTest
Wed Jan 20 21:50:07 JST 2010

無事直りました。良かった良かった。

/etc/localtime が食い違ってのは、/etc/localtimeのタイムスタンプが2004-02-26 という古いサーバなので、インストール時に何かミスったか、これまでの運用の中での更新で何かがおきたのかなと思います。ただ、JDK更新したらいきなしWEBアプリが書き込むデータのタイムスタンプが9時間ずれ初めてたのでビックリしました。

Cubbyのアクションクラスで定数を利用してリファクタリングしやすくする


Cubbyのアクションクラスにはバリデーションルールの定義時やアノテーションに文字列が登場します。文字列で指定しているのでリファクタリングする時に修正漏れなどがおきそうでちょっと怖いです。そこで、それらの文字列を定数にしてしまえば、少しだけリファクタリングしやすくなりそうです。また、IDE上での参照元・参照先への移動や使われているかどうかのチェックも簡単になります。

例えば、次のようなアクションクラスがあるとします。

@Path("hoge")
public class HogeAction extends AbstractAction {

    @Binding(bindingType = BindingType.NONE)
    protected ValidationRules processApplyValidation =
        new DefaultValidationRules() {
            @Override
            public void initialize() {
                add("token", new TokenValidator());
                add("name", new TokenValidator());
                add("comment", new TokenValidator());
            }
        };

    @RequestParameter
    public HogeParameterDto hogeParameterDto;

    @Path("process")
    @Accept(POST)
    @OnSubmit("apply")
    @Form("hogeParameterDto")
    @Validation(rules = "processApplyValidation", errorPage = "/hoge/edit.html")
    public ActionResult processApply() {
        return new Forward("/hoge/edit.html");
    }

}

これを次のようにします。

import static org.example.test.entity.names.Names.*;

@Path("hoge")
public class HogeAction extends AbstractAction {

    private static final String processApplyValidationName
        = "processApplyValidation";
    @Binding(bindingType = BindingType.NONE)
    protected ValidationRules processApplyValidation =
        new DefaultValidationRules() {
            @Override
            public void initialize() {
                add(TOKEN, new TokenValidator());
                add(post().name().toString(), new TokenValidator());
                add(post().comment().toString(), new TokenValidator());
            }
        };

    private static final String hogeParameterDtoName = "hogeParameterDto";
    @RequestParameter
    public HogeParameterDto hogeParameterDto;

    @Path("process")
    @Accept(POST)
    @OnSubmit("apply")
    @Form(hogeParameterDtoName)
    @Validation(rules = processApplyValidationName, errorPage = "/hoge/edit.html")
    public ActionResult processApply() {
        return new Forward("/hoge/edit.html");
    }

}

変更した箇所を説明します。

全文を読む

Cubbyでアクションメソッドに指定するアノテーションの順番


しばらく時間が空いてからCubbyを使ったWEBアプリケーションを書く時に、アクションメソッドに指定するアノテーションの順番どうだったかなっと考えるのでまとめます。アノテーションなので適当な順番に書いても問題なく動作しますが、処理の流れを考えて次の順番で指定しています。

  1. URIを指定: @Path
  2. HTTPメソッドを指定: @Accept
  3. 同一URIへのPOST時などに実行するアクションメソッドを変える指定: @OnSubmit
  4. リクエストパラメータのバインド先を指定: @Form
  5. リクエストパラメータのバリデーションを指定: @Validation
@Path("hoge")
public class HogeAction extends AbstractAction {
    ...
    @Path("process")
    @Accept(POST)
    @OnSubmit("apply")
    @Form("hogeParameterDto")
    @Validation(rules = "processApplyValidation", errorPage = "/hoge/edit.html")
    public ActionResult processApply() {
        return new Forward("/hoge/edit.html");
    }
    ...
}

JIRA 4.xと新しいPlugin機構


Seasarプロジェクトでも利用しているJIRA のライセンスを去年の10月に自分用に購入しました。JIRAを開発しているAtlassian社が10ユーザまで利用できるGet Started for $10というライセンスを始めたので思わず買いました。JIRA 4.0になって、JIRA 3.x以前にあったエディションの違いが無くなり、$10でEnterpriseエディションが使えるというのは破格です。JIRA 3.xまではLDAPサポートにEnterprise以上が必要でとても買える金額では無かったため嬉しいです。また、このライセンスの購入費用は全額 Room to Read に寄付されるプログラムになっています。

日本円で購入したい場合は、Atlassian社のOfficial Atlassian Partnerである リックソフト株式会社 が1,050 円で販売されています。

そんなわけで、だいぶ前置置きが長くなりましたが、自分用にJIRAの環境を作りました。購入当初JIRA 4.0には 新しく導入されたガジェットの仕組みがSSL環境で上手く動かない問題 があったので、使い始めたのはこの問題がJIRA側で解決した4.0.1からです。

ただ、まだ問題があって、Seasarプロジェクトで利用していた3.xのインストール手順でwarファイルを作成し、Tomcatにデプロイするとエラーがでて上手く起動しないのです。いろいろ試してみると自分で追加していたPluginを全部外すと起動しました。そんなことをつぶやいていたらリックソフトのohnukiさんがコンタクトをくださっていろいろやりとりした結果、原因が判明しました。

原因は、JIRA 4.0からOSGiを使用した新しいPlugin機構(Version 2)がサポートされ、JIRA 3.xの時とPluginの配置の仕方が変わっていたことでした。これに気付かず、JIRA 3.xの導入の仕方で入れていたので上手くPluginがロードされなかったようです。一応、互換性のため、古いPluginの配置方法(Version 1)も使えるようですが、Tomcat 5.5.28では動作するものの、Tomcat 6.0.20では動作せず、それでエラーが出ていました。

  • 参考: Managing JIRA’s Plugins
    • Version 1: atlassian-jira/WEB-INF/lib/ 以下に配置
    • Version 2: jira.home/plugins/installed-plugins/ 以下に配置
      • jira.home はJIRA 4.0から導入されたホームディレクトリ指定

というわけで、無事やっとPluginも使えるようになりました。ohnukiさんありがとうございました!

Pluginが使えるようになったので、SeasarプロジェクトのJIRAも近日アップグレードのテストをし、アナウンスを出した後に現在の3.13.5から4.0.1に更新したいと思います。

以下、何かの参考までにVersion 1 + Tomcat 6.0.20で起動した時の例外全文を記載しておきます。

全文を読む

WP FreeStyle Wiki


tDiaryからWordPressに乗り換え、これから書いていくのに標準のエディタで書くのがどうしても面倒だったので、一番慣れ親しんでいるFreeStyle Wikiの記法で書けるPlugin、WP FreeStyle Wikiを作りました。作ったといってもかなりの強引なことをしていてFreeStyle Wikiを丸ごと中で持っており、そこへ外部コマンドで投げてレンダリングしているだけです。

これは、大晦日の31日にWordPress Pluginをなんとなく見ていたところ、makotokwさん(ありがとうございます!)が作られているPukiWiki for WordPressというPluginを見つけて、ソースを見てみたらPukiWikiを丸ごと中に持っていてそんな手があったかと、そのまま勢いで年が明ける前にFreeStyle Wiki用に改造したものです。

以下に置いてありますので使いたい方がいましたらご自由にお使いください。ライセンスは中に持っているFreeStyle Wikiと同じGPLです。

  • [2010-01-01]: WP FreeStyle Wiki 0.1 リリース
    • 最初のリリース、FreeStyle Wiki 3.6.3内蔵、そのうち中身を整理してPlugin Directoryに登録するかもしれません
  • [2010-01-01]: WP FreeStyle Wiki 0.1.1 リリース
  • [2011-01-05]: WP FreeStyle Wiki 0.2.2 リリース
    • WordPressのPlugin Directoryページに登録しました。管理画面のプラグインのインストールからもインストールできます。

記法サンプル

以下、記法のサンプルです。 [fswiki] と [/fswiki] で囲んだ部分がFreeStyle Wikiで処理されます。

全文を読む

Home

検索
フィード
メタ情報

Return to page top