mrwk update: 2015

2015年12月9日

freeipa+SSSDで2FAを使ってログインする話

この記事はLinux Advent Calendar 2015の9日目の記事です。

イントロ

freeipaでは通常のパスワード認証のほかにOne Time Password(OTP)を利用した2要素認証が簡単に利用できる。googleとかgithubとかでセキュリティ固くしたいときに使うアレだ。
これを利用するときには、従来だと「パスワード文字列とOTP文字列の順にくっつけた文字列」を渡していた。
たとえば以下のような状態だとすると

username: kmoriwak
password: password
OTPのトークンの値: 123123

以下のように入力する。

Login: kmoriwak
Password: password123123

これがRHEL7.2に含まれているpam_sss (sssd-client-1.13.0-40.el7.x86_64) とコンソールのloginやgdmでは以下のようになる。

Login: kmoriwak
First factor: password
Second factor: 123123

何故このように変更されたのか? を見ていこう。

freeipa

この10年ほど、認証周りの標準は Active Directory によって先導されてきた。ADに相当するものとしてはsambaがAD互換の実装を行っているが、UNIX/Linux世界に独特な要件のサポートはいまいちと言わざるをえない状況だった。
UNIX/Linux世界にはLDAP, Kerberos, DNS, PKIなどの基盤技術はあるので、freeipaはこれらを統合したAD相当の認証基盤を作成する。
https://www.freeipa.org/page/About から引用すると:

FreeIPA is an integrated security information management solution combining Linux (Fedora), 389 Directory Server, MIT Kerberos, NTP, DNS, Dogtag (Certificate System). It consists of a web interface and command-line administration tools.

freeipaでは単純なパスワード認証だけではなく、Kerberosを使ったシングルサインオン、OTPを利用した2要素認証をサポートしている。またUNIX/Linux世界向けの機能としては、bindの設定, sshdの公開鍵, sudoポリシーを管理する。

SSSD

SSSDはActive Directoryやfreeipa、LDAPなどによる「ドメイン」と接続し、PAMとNSSのインタフェースに対してドメイン修飾つきの認証を提供する。
たとえばADで AD.EXAMPLE.COM を運用し、freeipaで IPA.EXAMPLE.COM を運用している。さらにLDAP上にも別の名前空間でuid,gidをもっているようなときに、3つ全てのドメインの情報を利用して認証をおこなうことができる。
ドメイン修飾というのは kmoriwak@AD.EXAMPLE.COMと kmoriwak@IPA.EXAMPLE.COM のようにドメインで重なる(が別のユーザにひもづく)名前がある場合に@以下にドメイン名を記載することでどのドメインかわかるようにするもので、まあだいたいメールのドメイン名みたいなものだ。
PAMとNSSが独立していると複数ドメインを扱うときにうまく連携できないためSSSDが導入され、さらにfreeipaとADとの連携を行う各種の機能や、次節で紹介するキャッシュ機能などが追加されている。

SSSDによるパスワードのキャッシュ

SSSDは認証のキャッシュを行う機能を持つ。いくつか目的があるが、可用性の向上と負荷の軽減が主なものである。
ユースケース1: 普段freeipaで認証するが、何かの問題でfreeipaに接続できない場合もログインサービスを継続したい
ユースケース2: ノートPCを持ち歩く場合に、普段はドメインのDirectory情報をつかった認証をおこなって、オフライン時にはキャッシュを利用して認証したい
ユースケース3: 頻繁に行われる認証をキャッシュしてDirectoryの負荷を下げたい

SSSDはPAM経由で平文のパスワードを受けつけ、これをSSHA2で加工して保存する。
キャッシュは各ドメインに対応したldbに保存されている。以下のようにtdbtoolで見える。

# tdbtool /var/lib/sss/db/cache_example.com.ldb show "DN=NAME=kmoriwak,CN=USERS,CN=EXAMPLE.COM,CN=SYSDB\00"
(中略)
[620] 39 30 33 5A 00 63 61 63 68 65 64 50 61 73 73 77 903Z.cac hedPassw
[630] 6F 72 64 00 01 00 00 00 6A 00 00 00 24 36 24 6B ord.... j...$6$k
[640] 76 75 50 49 53 2E 41 4F 59 68 56 56 67 4E 4F 24 vuPIS.AO YhVVgNO$
[650] 33 4A 61 2F 36 63 34 4C 6B 77 7A 32 4B 64 6A 51 3Ja/6c4L kwz2KdjQ
[660] 34 73 63 5A 7A 6D 46 75 30 49 56 7A 4B 71 61 6F 4scZzmFu 0IVzKqao
[670] 4A 37 72 52 2F 54 76 53 6E 50 6E 55 6B 75 54 30 J7rR/TvS nPnUkuT0
[680] 6B 37 32 54 45 67 67 2E 41 5A 50 41 76 66 36 69 k72TEgg. AZPAvf6i
[690] 37 49 4E 54 34 64 38 39 46 4F 59 32 45 51 35 30 7INT4d89 FOY2EQ50
[6A0] 73 7A 30 33 66 30 00 6C 61 73 74 43 61 63 68 65 sz03f0.l astCache
(以下略)

オフライン時にどの程度の時間(24時間や48時間など)キャッシュを維持するかはsssdの設定次第で変更できるが、デフォルトでは制限がおこなわれていないためオフライン時の認証には向いている。

パスワードとOTPトークンを区別したいケース

OTPのトークンは設定によるが30秒や60秒でどんどん変わってしまうのでキャッシュをすることには意味がない。
さらに2要素認証を利用するにあたって、常に2要素を接続した文字列を利用しつづけることは現実的ではない。具体的には固定的なパスワードと連携したキーリングのアンロックやディレクトリの暗号化には共通鍵を使いたいのでOTPをそのまま適用することができない。
またオフライン時に認証を継続したい場合には、OTPのトークンを検証できないためこれを使わないで認証したい。入力された[パスワードとOTPを組み合わせた文字列]をそのままハッシュ化してキャッシュすると次回オフライン時の認証は必ず失敗することになってしまう。
このためパスワードとOTPトークンをなんとか区別したい。トークンの長さが常に一定であれば簡単なのだが、残念ながらそうではない。

freeipaへの認証とOTP

freeipaへの認証は基本的にKerberosへのログインである。OTPを利用する場合の動きについては http://www.freeipa.org/page/V4/OTP#Design に詳しいが、OTP over RADIUS を使って認証時にLDAP上のユーザ属性にもとづいてfreeipa組み込みのOTPに対応する他、サードパーティのOTPにも対応できるようになっている。
このため事前にトークンの文字列長を一般に確定させる方法は存在しない(トークン長が常に一定だとも仮定できない)。実装によってはKerberosのチャレンジとしてトークン長が帰ってくる (http://tools.ietf.org/html/rfc6560)ものもあるので、これを利用してSSSDとpam_sssがトークンを除去できることもある。freeipaに内蔵のHOTP,TOTP実装はトークン長を返すのでうまく動作できる。
力技での対応策としては入力文字列を最後から1文字ずつ削除してハッシュを作る作戦があるがあまり望ましくない。たとえば入力が16文字だとして、16,15,14...と文字数を減らしていきそれぞれのハッシュ値を計算してキャッシュに維持する。しかしこれを単純に適用すると短い文字列に対するハッシュを生成し、結果としてオフライン時の認証が脆弱になる危険がある。たとえば16文字の入力から12文字削って先頭4文字に対するハッシュを維持するようなことがあればオフライン認証に対しての総当たり攻撃が非常に簡単になるだろう。

解決策

ここで最初のふるまいにもどる。SSSDとpam_sssが協調し、事前にユーザ情報から認証のタイプを確認して2つの要素を分けて入力させることでパスワードとトークンの分離をするためのヒューリスティックは不要となる。
なおpam_conv()は複数入力をサポートしておりgdmやloginは複数入力に対応するが、歴史的理由により1つの文字列しか認証用に入力できない処理系も多数存在する。そのためpam_sssの実装では、パスワードとトークンが接続された文字列と空文字列、パスワードとトークンを別々に入力の2種類に対応している。

sshdから使われる場合のみワークアラウンドとしてパスワードとトークンが接続された文字列が2回入力されるパターンに対応している。

2015年7月22日

RHELセキュリティ情報の入手と適用

修正が作成されるまで

一般にプログラムに問題があるときは、プログラムのソースコードを修正して対応します。RHELのほどんとのパッケージではアップストリームのソースコードを直接変更せずそのままにしておき、修正は複数の「パッチ(修正用の差分情報)」を追加することでおこなっています。

RHELで利用されているrpm(RPM Package Manager)では、元のソースコードとパッチ、さらにそれらを処理して実際に実行されるプログラムに変換するための情報を「ソースrpm」とよばれるパッケージにまとめます。

ソースrpmから「バイナリrpm」を作成します。これは実際に実行できるプログラムなどが入ったパッケージで、通常「rpmパッケージ」という場合にはこのバイナリrpmのことをさしています。

通常1つのソースrpmから、複数のバイナリrpmが作成されます。動作するCPUアーキテクチャや利用するライブラリ、オプションなどによって、同じソースrpmから異なるバイナリrpmが作成されます。

errataとアドバイザリ

このように作成されたソースrpmおよびバイナリrpmを公開するデータベースがerrataです。

errataに含まれている、修正を公開する単位が「アドバイザリ」です。アドバイザリは、1つまたは複数のソースrpmの修正に対応したアナウンスで、以下のような情報を含みます。

アドバイザリのID (RH?A-XXXX:YYYY というフォーマットです。 ?はS,B,Eのいずれか、XXXX,YYYYは数字です)
修正された問題の要約
発行日、最終更新日
（セキュリティ修正のみ）重要度
（セキュリティ修正のみ）関連する脆弱性情報
影響をうける製品
更新されたパッケージとそのバージョン
関連するbugzillaエントリ（通常は複数の修正が含まれています）

errataはそれぞれのアドバイザリがレコードとしてならんだデータベースになっています。

重要な特徴として、errataではそれぞれのアドバイザリに順序関係があり、同じ製品であれば新しいアドバイザリには、それ以前のアドバイザリで提供された修正が全て反映されています。

たとえばfirefoxがアドバイザリ A, B, Cの順に3回修正されたとすると、Aに含まれている修正は全てB,C にも含まれ、Bに含まれている修正はCにも含まれています。

つまり、常に最新のパッケージを適用することで、全ての既知の問題に対応できます。「Bで修正された部分は利用するがAとCの問題はそのまま放置する」というような選択肢をなくすことで、管理がシンプルになっています。

アドバイザリの種類は？

アドバイザリには3種類の分類があり、それぞれIDが以下の4文字ではじまります。

RHSA セキュリティ上の脆弱性を修正したアドバイザリ
RHBA バグを修正したアドバイザリ
RHEA 機能拡張したアドバイザリ

RHSAおよびRHBAでは、基本的に対応する問題を修正するだけで、新しい機能が追加されることはありません。機能拡張は基本的にRHEAだけで行われます。

errata情報の入手

errataの情報は公開されており、以下のwebページから参照することができます。

https://access.redhat.com/security/updates/active/

また、通知を受ける方法としてRHELでは3通りの方法を提供しています。

1. yum-updatesd によるメール送信、log出力

RHELに同梱されている yum-updatesd は定期的にカスタマーポータルに接続して更新情報を取得し、更新パッケージがあれば通知します。

通知方法にはe-mail, log出力, dbusが選択でき、デフォルト設定ではdbusによる通知を利用して、GUI環境でアップデートの通知を画面表示させます。この設定を変更することでメールやログの形でアップデートの通知を受けとることができます。

詳しくは、「man yum-updatesd.conf」としてマニュアルを参照してください。

2. Red Hat カスタマーポータルからのメールによる通知

カスタマーポータルのErrata notifications設定により、errata出荷時にメールで通知を受けとることができます。

https://www.redhat.com/wapps/ugc/protected/notif.html

3. メーリングリスト、RSSフィードによる通知

errataの更新についての通知を、RSSフィードおよびメーリングリストでおこなっています。

RHSA Announce メーリングリスト(プラットフォーム製品のセキュリティ修正)
http://www.redhat.com/mailman/listinfo/rhsa-announce

JBoss Watchメーリングリスト(ミドルウェア製品のセキュリティ修正)
http://www.redhat.com/mailman/listinfo/jboss-watch-list
errata更新のRSSフィード
http://rhn.redhat.com/rpc/recent-errata.pxt

脆弱性のCVE numberから対応するerrataアドバイザリを確認

RHSA には、Common Vulnerabilities and Exposures (CVE)の関連する脆弱性情報へのリンクが含まれています。以下のサイトで、CVE numberからerrataのアドバイザリを逆引きすることができます。ニュースサイト等で見た脆弱性が製品への影響しているかの確認や、既に出荷されていればerrataのIDを確認することができます。

https://access.redhat.com/security/cve/

yumコマンドによるセキュリティ修正の確認・対応

インターネット接続が可能であるか、Red Hat Satelliteが利用可能な環境では、yumコマンドによりセキュリティ対応をおこなうことが可能です。

サマリの表示

# yum updateinfo
Loaded plugins: langpacks, product-id, subscription-manager
Updates Information Summary: available
    3 Security notice(s)
        2 Critical Security notice(s)
        1 Important Security notice(s)
    2 Bugfix notice(s)
    2 Enhancement notice(s)
updateinfo summary done

適用可能なerrataの一覧

# yum updateinfo list available
Loaded plugins: langpacks, product-id, subscription-manager
RHSA-2015:1443 Important/Sec. bind-32:9.9.4-18.el7_1.2.x86_64
RHSA-2015:1443 Important/Sec. bind-libs-32:9.9.4-18.el7_1.2.x86_64
RHSA-2015:1443 Important/Sec. bind-libs-lite-32:9.9.4-18.el7_1.2.x86_64
RHSA-2015:1443 Important/Sec. bind-license-32:9.9.4-18.el7_1.2.noarch
RHSA-2015:1443 Important/Sec. bind-utils-32:9.9.4-18.el7_1.2.x86_64
RHSA-2015:1207 Critical/Sec.  firefox-38.1.0-1.el7_1.x86_64
RHSA-2015:1229 Critical/Sec.  java-1.7.0-openjdk-1:1.7.0.85-2.6.1.2.el7_1.x86_64
RHSA-2015:1229 Critical/Sec.  java-1.7.0-openjdk-devel-1:1.7.0.85-2.6.1.2.el7_1.x86_64
RHSA-2015:1229 Critical/Sec.  java-1.7.0-openjdk-headless-1:1.7.0.85-2.6.1.2.el7_1.x86_64
RHBA-2015:1192 bugfix         openssl-1:1.0.1e-42.el7_1.9.x86_64
RHBA-2015:1192 bugfix         openssl-libs-1:1.0.1e-42.el7_1.9.x86_64
RHBA-2015:1474 bugfix         python-chardet-2.2.1-1.el7_1.noarch
RHEA-2015:1473 enhancement    python-urllib3-1.10.2-1.el7_1.noarch
RHEA-2015:1476 enhancement    redhat-access-insights-1.0.4-0.el7_1.noarch
updateinfo list done

アドバイザリ詳細の確認

# yum info-sec --advisory RHSA-2015:1443
Loaded plugins: langpacks, product-id, subscription-manager

===============================================================================
  Important: bind security update
===============================================================================
  Update ID : RHSA-2015:1443
    Release :
       Type : security
     Status : final
     Issued : 2015-07-20 00:00:00
       Bugs : 1237258 - CVE-2015-4620 bind: abort DoS caused by uninitialized value use in isselfsigned()
       CVEs : CVE-2015-4620
Description : The Berkeley Internet Name Domain (BIND) is an implementation of
            : the Domain Name System (DNS) protocols. BIND
            : includes a DNS server (named); a resolver library
            : (routines for applications to use when interfacing
            : with DNS); and tools for verifying that the DNS
            : server is operating correctly.
            :
            : A flaw was found in the way BIND performed DNSSEC
            : validation. An attacker able to make BIND
            : (functioning as a DNS resolver with DNSSEC
            : validation enabled) resolve a name in an
            : attacker-controlled domain could cause named to
            : exit unexpectedly with an assertion failure.
            : (CVE-2015-4620)
            :
            : Red Hat would like to thank ISC for reporting this
            : issue.
            :
            : All bind users are advised to upgrade to these
            : updated packages, which contain a backported patch
            : to correct this issue. After installing the
            : update, the BIND daemon (named) will be restarted
            : automatically.
   Severity : Important
updateinfo info done

CVE IDを指定してのアップデート

# yum update --cve CVE-2015-4620

アドバイザリIDを指定してのアップデート

# yum update --advisory RHSA-2015:1443

RHELのバージョンによりyumコマンドで利用するオプションが変わります。以下のナレッジベースでRHELの5,6,7それぞれでの操作をご案内しています。

https://access.redhat.com/solutions/10021

参考情報

セキュリティガイド第3章システムを最新の状態に保つ

2015年6月22日

Red Hat Enterprise Linuxのセキュリティ対応に OpenSCAPを活用しよう

https://oss.sios.com/redhat-ch/blog/openscap_intro に投稿したものの再掲です。

「システムに既知の脆弱性や問題のある設定がないかチェックをしよう」というとき、あなたならどうしますか？本稿ではセキュリティ対応の自動化のためRHELに最近導入されたOpenSCAPおよびSCAP Security Guideを紹介します。

セキュリティ対応、どうしてますか？

「システムに既知の脆弱性や問題のある設定がないかチェックをしよう」というとき、あなたならどうしますか？緊急の対策については、文書をもとに手作業で確認するケースも多いかと思います。しかし組織内での恒常的なセキュリティ対応のためには、自動化が必要になります。

本稿ではセキュリティ対応の自動化のためRHELに導入されたソフトウェアを紹介します。

SCAP(Security Content Automation Protocol)

アメリカ政府ではあらゆるシステムにセキュリティ対応(発見・対策)をおこなう必要があり、これを自動化・定型化するための仕組みが作られてきました。SCAPはNIST(National Institute of Standards and Technology)により開発された、情報セキュリティ対策の自動化と標準化のための規格です。前提となる各種のID策定、セキュリティ上の問題の検出と対策などを記述するフォーマットなどを規定しています。

SCAPの一環として、製品についてのID(CPE)、脆弱性についてのID(CVE)、設定についてのID(CCE), 脆弱性の深刻さのスコアづけ(CVSS)、自動チェックのための言語(OVAL)、チェックリストのフォーマット(XCCDF)などが標準化されています。脆弱性情報などでCVEやCVSSの名前を見たことがある方も多いのではないかと思います。

OVAL規格では各種のOSやアプリケーションに対応しており、テスト項目を「ファイルや設定、パッケージなどの検査項目」と「どういう状態になっているか」の組み合わせで記載して専用の処理系によって自動的に検査することができるようになっています。

SCAPについて詳しくはIPAのSCAP概説ページをごらんください。関連する規格についても紹介がされています。Red Hat製品についても従来からアップデート情報をOVALフォーマットで提供しています。

この記事では、このSCAPに関連した以下の3つのソフトウェアを紹介します。

XCCDFまたはOVAL形式のファイルを処理するOpenSCAP
XCCDFフォーマットで作成された包括的なチェックリストであるSCAP Security Guide
XCCDFフォーマットのチェックリストを必要にあわせてカスタマイズするSCAP Workbench

OpenSCAP

OpenSCAPは、SCAPを実装しているオープンソースのプロジェクトで、OpenSCAP 1.0.8 でSCAP 1.2の認証をNISTから受けています。OpenSCAPはOVALまたはXCCDFで記述されたチェックリストと組織にあわせたカスタマイズにしたがって、実際のシステムを検証してレポートを作成します。一部の項目については自動的な対策も可能です。

OpenSCAPの利用方法のイメージはドキュメントに、DISAが公開しているガイドを利用してチェックを行う例などがあります。OpenSCAPはRed Hat Enterprise Linux の5.7および6.0から同梱されています。

OpenSCAPで出力されるレポート例

SCAP Security Guide

SCAP Security Guide は、Fedora, Java, Red Hat Enterprise Linux 5, 6, 7, OpenStack, JBoss Enterprise Application Server 5, JBossFuse6 のセキュリティについてついてのガイドと関連する検証メカニズムをXCCDF形式で提供しているプロジェクトです。

SCAP Security Guide内には「/var/logを別のパーティションにする」といった多数のチェック項目と説明、関連するIDや規格文書などへのリファレンス、自動でチェックや修正が可能なものについてはその手順が含まれます。これらの項目から組織のポリシーにあわせて選択してカスタマイズしたチェックリストを作ります。OpenSCAPはこのチェックリストを自動でチェックしてレポートを生成します。オプションによっては自動的な修正もおこないます。

このプロジェクトは2011年にRHEL6についての高品質なセキュリティガイドを作成するためのNSAとRed Hatの共同作業からはじまり、その後カバーする範囲や参加者を増やしつつ成長しています。RHEL 7.1からSCAP Security Guideが同梱されるようになりましたので「SCAP Security GuideをSCAP WorkbenchでカスタマイズしたチェックリストをOpenSCAPで自動的に確認し、レポートを作成する」プロセスの全体をRed Hatがサポートできるようになりました。

SCAP Workbench

SCAP WorkbenchはXCCDF内でのチェック項目を組織にあわせて選択・調整したプロファイルを作り、ローカルまたはリモートの環境をチェックする作業を簡単にするためのGUIツールです。RHEL 7.1からはサポート対象として同梱されています。

Screenshot_rhel7.1_2015-06-15_21:39:31.png

Screenshot_rhel7.1_2015-06-15_21:41:19.png

Red Hat Satelliteからの管理

Red Hat Satelliteから管理対象になっている複数台のRHELに対してOpenSCAPを実行してレポートを蓄積します。監査結果の概要や履歴を確認したり、同一のスキャンを行って前回との差分を確認するなどの機能が提供されます。以下はRed Hat Satellite 5.7でのスキャン結果概要画面の例です。

Red_Hat_Satellite_-_システム_-_システム_-_監査_-_スキャンの一覧_-_2015-06-15_22.01.17.png

RHEL上で新しいソフトウェアを利用したい!

Red Hat Enterprise Linux は初期バージョンでリリースしたソフトウェアについて10年間基本的に同じバージョンを維持します。
これは多くの場合に企業ユーザにとってうれしいポリシーですが、新しいソフトウェアを利用したい時もあります。

特にupstreamの開発が早いソフトウェアは3年もすると時代遅れになり、5年も前のバージョンだとあれもこれも使えないという状態になってしまいます。

開発ツールについても新しい言語仕様への対応、新CPUの命令セットへ対応、最適化の強化などで新しいバージョンを利用したいという声がありました。

Red Hat Software Collections の登場

これらの問題に対する解として、Red HatではRed Hat Software Collections を提供しています。
これは今までのadd-on製品などと異なり、以下のような特徴があります。

Red Hat Enterprise Linux のライフサイクルと独立して、新しいソフトウェアコンポーネントを追加・リタイアさせます。
具体的にはRHEL の10年間のサポートライフサイクルに対してSoftware Collectionsは一部の例外を除いて3年間のライフサイクルとなります。
Red Hat Enterprise Linux に同梱されているソフトウェアと競合しないよう工夫されています。
たとえば Pythonのバージョン3.3 をRHEL 6に導入しようとすると、多数の競合が発生してしまいます。
Software Collectionsでは、通常とは異なるディレクトリにインストールする仕組みを標準化することで、競合を防ぎつつ便利に利用できるようにしています。

Red Hat Software Collections 2.0

Red Hat Software Collections 2.0 (以下RHSCL 2.0)は 2015年6月に出荷されました。
Red Hat Enterprise Linux 6 および 7 で利用できるソフトウェアを提供しています。
UpstreamにあたるSoftware Collectionsプロジェクト https://www.softwarecollections.org/en/ では、FedoraやCentOSなどで利用できるリポジトリが公開されています。自作のコレクションを追加することもできます。

RHSCL 2.0に含まれる主要なソフトウェアを紹介します。

言語処理系:

gcc, gdbなどCやfortranの開発環境を含むRed Hat Developer Toolset
Perl 5.16.3, 5.20.1
PHP 5.4.40, 5.5.21, 5.6.5
Python 2.7.8, 3.3.2, 3.4.2
Ruby 1.9.3, 2.0.0, 2.2.2
V8 3.14.5.10

Webサーバ:

nginx 1.6.2
Apache httpd 2.4.12
Ruby on Rails 4.0.2, 4.1.5
Node.js 0.10
Passenger 4.0.50

データベース:

MariaDB 5.5.37, 10.0.17
MongoDB 2.4.9, 2.6.9
MySQL 5.5.37, 5.6.24
PostgreSQL 9.2.8, 9.4.1

その他にもGitなどの開発者むけツールが含まれています。

Red Hat Software Collections を使ってみよう

利用の前提

RHSCLは特に追加の費用はかかりません。通常のRed Hat Enterprise Linux 6 または7 を導入されていると、RHSCLを入手することができます。レッドハットによる直接のサポートを受けている場合はサポート対象でもあります。OEM版をご利用の場合は、OEM各社によりサポートポリシーがかわりますのでご注意ください。

購入時期によって、利用できるよう設定されていない場合があります。詳細についてはこちらをご確認ください。

リポジトリの登録と導入

Software CollectionsはRed HatのカスタマーポータルにRHELを直接接続するか、Red Hat Satellite経由で接続することで利用できます。カスタマーポータルから個別のパッケージをダウンロードすることはできませんのでご注意ください。

リポジトリを登録します。RHSCLの1.xと2.0は同じリポジトリを利用しますので、1.xを利用していた方は登録しなおす必要はありません。

# subscription-manager repos --enable rhel-server-rhscl-7-rpms
# yum install python33

RHSCLを導入すると、sclコマンドにより環境を切りかえられるようになります。

$ scl enable python33 bash $ python Python 3.3.2 (default, Mar 20 2014, 18:55:17) [GCC 4.8.2 20140120 (Red Hat 4.8.2-16)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

Red Hat Software Collections のサポート

RHSCLのサポート期間はRHELのサポート期間と独立しています。RHEL 6やRHEL 7のサポートが続いていても RHSCLのサポートは独立して切れてしまう点に注意が必要です。

RHSCL 2.0 には同じソフトウェアの複数バージョンが含まれています。この中には RHSCL 1.xからひきつづいて提供しされているものが存在しています。

登場時期によりサポート終了期間がことなります。基本的にはRHSCL 1.xで登場したものは2016年10月まで、RHSCL 2.0で登場したものは 2018年4月までというように各コンポーネントごとにリリースから3年間(Developer Toolsetは2年間)のサポート期間が設定されています。そしてRHSCLの1.xと2.xでリポジトリは同一です。

各コンポーネントについてサポート期間一覧が案内されています。

2015年5月19日

RHEL7でとったスナップショットにroot fsをロールバックするメモ

snapperで作ったスナップショットに戻したい

なにもなかったことにしたいとき、あります。

というわけでsnapperで取得したsnapshotの差分をとって…… というのではなく、まるごとそのまま前の状態にもどしましょう。

rootfs切り替え時の注意

RHELだと/bootはLVMで管理しない生パーティションのため、この手法でロールバックされません。「カーネルやinitramfsが/bootに入っているが/lib/modules以下にカーネルモジュールが入っていない」という状態になる可能性があります。root fsのmountまではinitramfsでできているはずなのでなんとかkernelパッケージを再インストールしてしのぎます。

snapperのメタデータは対象のディレクトリ直下にある .snapshots ディレクトリに作成されます。この情報も古い状態にもどってしまいますので、必要に応じてバックアップ&リストアするのがよいです。

snapperはスナップショットのlv名が衝突すると適当に数を大きくして競合しないように命名してくれるので、既にあるスナップショットを snapperが管理してくれなくなる(=古いスナップショットが消えないので容量の無駄になる)以外には大きな実害はありません。

snapperによって作成されるLVの属性を確認する

まずはsnapperが作成するLVの状態を確認します。


 [root@localhost ~]# lvs
  LV              VG   Attr       LSize  Pool   Origin Data%  Meta%  Move Log Cpy%Sync Convert
  pool00          rhel twi-aotz-- 12.00g               10.85  18.55                           
  root            rhel Vwi-aotz-- 12.00g pool00        10.02                                  
  root-snapshot10 rhel Vri---tz-k 12.00g pool00 root                                          
  root-snapshot11 rhel Vri---tz-k 12.00g pool00 root                                          
  root-snapshot12 rhel Vri---tz-k 12.00g pool00 root                                          
  root-snapshot13 rhel Vri---tz-k 12.00g pool00 root

Vri—-tz-k というのが属性で、元々のroot fsであるVwi-aotz— というのとはちょっと違いますね。

man lvs 内に各フラグの意味が書いてあります。関係するところだけひっぱってきます


              1  Volume  type:  thin (V)olume
              2  Permissions: (w)riteable, (r)ead-only
              3  Allocation policy:  (i)nherited
              4  fixed (m)inor ← なし
              5  State:  (a)ctive
              6  device (o)pen
              7  Target type: (t)hin; whereas snapshots of thin volumes using the new thin provisioning driver appear as (t).
              8  Newly-allocated data blocks are overwritten with blocks of (z)eroes before use.
              9  Volume Health: ← なし
              10 s(k)ip activation: this volume is flagged to be skipped during activation.

rootと、root-snapshot10 を比べてみると「read-onlyでactiveではなく、openされておらず、activationのときにskipされる」というのが違いです。

つまりこれを普通のボリュームにするには、「writableに変更し、activationのときにスキップしないように変更する」必要があります。起動時に自動的にLVをactivationする処理により、activeとopenは勝手に設定されます。

普段はsnapshotのデバイスがずらずらと並んでも同じUUIDを持っていたりしてxfsの誤動作の元になったりするくらいでいいことがないのでskipにしてあります。

dracutによるinitramfsで、root fsをmountする前に停止する

「じゃあ一旦umountしてからlvchangeでフラグを変更して、lvrenameすればいいんだな……」となるわけですが、 root fsが含まれているので「一旦umountして」という処理がちょっと面倒になります。

RHELの6から採用されているdracutでは、カーネルのコマンドラインオプションに rd.break=pre-mount とつけることでroot fsをマウントする直前のところで停止してshellに落ちてくれる便利機能がついています。(RHEL6だとすこしオプション名がちがってrdbreak=…です)

man dracut.cmdline より


       rd.break={cmdline|pre-udev|pre-trigger|initqueue|pre-mount|mount|pre-pivot|cleanup}
           drop to a shell on defined breakpoint

再起動して、grubのメニューから rd.break=pre-mount というオプションを一時的に追加することで、initramfsだけがマウントされている状態のシェルが起動します。

この環境ではlvchangeなどのコマンドはlvmの対話シェル内から打ちこみます。

lvmでの作業

デフォルトではinitramfs内でLVMのメタデータを変更しない設定になっているので、lvmでの作業前に /etc/lvm/lvm.conf 内の locking_mode = 4 となっている行を1に変更します。

lvmの中で以下のような変更をおこないます。今回はsnapshot10の状態に戻してみます。


lvm>  lvrename rhel/root root-original

lvm> lvrename rhel/root-snapshot10 root



lvm> lvchange -k n rhel/root   ← s(k)ip をはずす

lvm> lvchange -p rw rhel/root    ← readwriteができるようにする



lvm> lvchange -k y rhel/root-original  ← s(k)ipするようにする

lvm> lvchange -p ro rhel/root-original ← read only にする

lvm> exit

しくじると再起動するときにroot fsのmountに失敗してしまうので、随時lvsなどで思った通り操作できているか確認しましょう。

このあと reboot コマンドで再起動します。

再起動後


[root@localhost ~]# snapper create

[root@localhost ~]# lvs
  LV              VG   Attr       LSize  Pool   Origin        Data%  Meta%  Move Log Cpy%Sync Convert
  pool00          rhel twi-aotz-- 12.00g                      11.15  24.41                           
  root            rhel Vwi-aotz-- 12.00g pool00 root-original 10.00                                  
  root-original   rhel Vwi---tz-k 12.00g pool00                                                      
  root-snapshot11 rhel Vri---tz-k 12.00g pool00 root-original                                        
  root-snapshot12 rhel Vri---tz-k 12.00g pool00 root-original                                        
  root-snapshot13 rhel Vri---tz-k 12.00g pool00 root-original                                        
  root-snapshot14 rhel Vri---tz-k 12.00g pool00 root-original                                        
  root-snapshot15 rhel Vri---tz-k 12.00g pool00 root-original                                        
  root-snapshot16 rhel Vri---tz-k 12.00g pool00 root-original                                        
  root-snapshot17 rhel Vri---tz-k 12.00g pool00 root-original                                        
  root-snapshot18 rhel Vri---tz-k 12.00g pool00 root-original                                        
  root-snapshot19 rhel Vri---tz-k 12.00g pool00 root                                                 
  root-snapshot9  rhel Vri---tz-k 12.00g pool00 root-original                                        
  swap            rhel -wi-ao----  2.00g               


[root@localhost ~]# snapper list
Type   | #  | Pre # | Date                     | User | Cleanup | Description | Userdata
-------+----+-------+--------------------------+------+---------+-------------+---------
single | 0  |       |                          | root |         | current     |         
single | 9  |       | Mon May 18 18:15:10 2015 | root |         |             |         
single | 19 |       | Tue May 19 18:48:48 2015 | root |         |             |

snapperはきれいさっぱり10から18までのことは忘れています。記録がないから当然ですね。

元LVの削除

もろもろ試して、うまいこと古い状態に戻せていることが確認できたら、元のLVをlvremoveで削除します。


[root@localhost ~]# lvremove rhel/root-original
  Logical volume "root-original" successfully removed
[root@localhost ~]# lvs
  LV              VG   Attr       LSize  Pool   Origin Data%  Meta%  Move Log Cpy%Sync Convert
  pool00          rhel twi-aotz-- 12.00g               11.07  22.66                           
  root            rhel Vwi-aotz-- 12.00g pool00        10.00                                  
  root-snapshot11 rhel Vri---tz-k 12.00g pool00                                               
  root-snapshot12 rhel Vri---tz-k 12.00g pool00                                               
  root-snapshot13 rhel Vri---tz-k 12.00g pool00                                               
  root-snapshot14 rhel Vri---tz-k 12.00g pool00                                               
  root-snapshot15 rhel Vri---tz-k 12.00g pool00                                               
  root-snapshot16 rhel Vri---tz-k 12.00g pool00                                               
  root-snapshot17 rhel Vri---tz-k 12.00g pool00                                               
  root-snapshot18 rhel Vri---tz-k 12.00g pool00                                               
  root-snapshot19 rhel Vri---tz-k 12.00g pool00 root                                          
  root-snapshot9  rhel Vri---tz-k 12.00g pool00                                               
  swap            rhel -wi-ao----  2.00g

Originの表記が消えたりしていますがやはりあまり実害はないので気にしない方向で… 。

2015年5月18日

RHEL7でスナップショットとり放題設定をためしたメモ

インストール

RHEL7のインストーラではインストール対象としてLVM thinprovisioningが選択できるようになっている。ここを選択して、適当に空きが残るように容量を設定しておく。

状態を確認

操作する前に現在の状態を確認


[root@localhost log]# lsblk
NAME                    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                       8:0    0   20G  0 disk 
├─sda1                    8:1    0  500M  0 part /boot
└─sda2                    8:2    0 16.4G  0 part 
  ├─rhel-swap           253:0    0    2G  0 lvm  [SWAP]
  ├─rhel-pool00_tmeta   253:1    0   12M  0 lvm  
  │ └─rhel-pool00-tpool 253:3    0   12G  0 lvm  
  │   ├─rhel-root       253:4    0   12G  0 lvm  /
  │   └─rhel-pool00     253:5    0   12G  0 lvm  
  └─rhel-pool00_tdata   253:2    0   12G  0 lvm  
    └─rhel-pool00-tpool 253:3    0   12G  0 lvm  
      ├─rhel-root       253:4    0   12G  0 lvm  /
      └─rhel-pool00     253:5    0   12G  0 lvm  
sr0                      11:0    1  3.6G  0 rom  

[root@localhost log]# lvs
  LV     VG   Attr       LSize  Pool   Origin Data%  Meta%  Move Log Cpy%Sync Convert
  pool00 rhel twi-aotz-- 12.00g               9.38   5.18                            
  root   rhel Vwi-aotz-- 12.00g pool00        9.38                                   
  swap   rhel -wi-ao----  2.00g

lsblkに同じエントリが2回でているのが不安ですが、tmetaの方はメタデータ、tdataの方は実際のデータがはいっています。

12GBのpool00の下に12GBということになっているrootが含まれている状態。

プールの詳細

[root@localhost log]# lvdisplay /dev/rhel/pool00 
  --- Logical volume ---
  LV Name                pool00
  VG Name                rhel
  LV UUID                vuooGK-VHow-JfAo-cPQb-Egf1-fCk4-qRpLqK
  LV Write Access        read/write
  LV Creation host, time localhost, 2015-05-15 19:15:03 +0900
  LV Pool metadata       pool00_tmeta
  LV Pool data           pool00_tdata
  LV Status              available
  # open                 2
  LV Size                12.00 GiB
  Allocated pool data    9.38%
  Allocated metadata     5.18%
  Current LE             3072
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     8192
  Block device           253:3

これで、lvmにより任意のタイミングでsnapshotをとり放題です。以下のようなコマンドでスナップショットを作成できます。


lvcreate --permission r --snapshot --name snapshot  rhel/root

snapper設定の作成

さて、snapshot作り放題、なのはいいですがlvcreateで都度作成するのはしんどいです。というわけでRHEL7には、SUSE出身のsnapperが含まれています。SUSEだとYaSTと連携してGUIまでありますが、RHELだとコマンドラインのみ。しかしとても便利です。

まずは設定を作成します。デフォルトだと “root” という名前の設定で、それ以外だと-c “設定名” みたいなオプションをつけて実行することでどこの操作をしているか指定します。

[root@localhost ~]# snapper create-config -f 'lvm(xfs)' /

このコマンドで /etc/snapper/configs/rootに設定本体が作成され、
さらに設定一覧が /etc/sysconfig/snapper にあるのでここに設定名が追加されます。

今の設定一覧を確認する。”root”設定があるのがわかります。

[root@localhost log]# snapper list-configs
Config | Subvolume
-------+----------
root   | /

snapshot作成

ここまで準備をするとスナップショットの作成は簡単。snapper createコマンドだけです。


[root@localhost log]# snapper create

様子を確認します。


[root@localhost log]# snapper list
Type   | # | Pre # | Date                     | User | Cleanup | Description | Userdata
-------+---+-------+--------------------------+------+---------+-------------+---------
single | 0 |       |                          | root |         | current     |         
single | 9 |       | Mon May 18 18:15:10 2015 | root |         |             |         

[root@localhost log]# lvs
  LV             VG   Attr       LSize  Pool   Origin Data%  Meta%  Move Log Cpy%Sync Convert
  pool00         rhel twi-aotz-- 12.00g               10.00  5.73                            
  root           rhel Vwi-aotz-- 12.00g pool00        10.00                                  
  root-snapshot9 rhel Vri---tz-k 12.00g pool00 root                                          
  swap           rhel -wi-ao----  2.00g

root-snapshot9 という名前のスナップショットが作成されています。

スナップショットのマウント

以下のようにスナップショット番号を指定して、readonlyでmountすることができます。
.snapshotディレクトリ以下に適当にmountされます。


[root@localhost ~]# snapper mount 10 

[root@localhost ~]# df

Filesystem                        1K-blocks    Used Available Use% Mounted on
/dev/mapper/rhel-root              12571648 1226516  11345132  10% /
devtmpfs                            1931348       0   1931348   0% /dev
tmpfs                               1941204       0   1941204   0% /dev/shm
tmpfs                               1941204    8580   1932624   1% /run
tmpfs                               1941204       0   1941204   0% /sys/fs/cgroup
/dev/sda1                            508588  168516    340072  34% /boot
/dev/mapper/rhel-root--snapshot10  12571648 1193528  11378120  10% /.snapshots/10/snapshot

snapshot間の差分

snapperではsnapshotを一時的なディレクトリにmountして、差分を取る仕組みがあります。

さらに通常のスナップショットの他に、管理に便利なようにpreとpostというタイプが導入されています。スナップショット自体は同じなのですが、なんらかの作業前にpreスナップショットを取得、作業後にpostスナップショットを取得してペアにしています。

今回は触れませんが、pre,postのスナップショットを各種の作業前後に自動的に作成して、特に差分がなければ自動的に消す仕組みも含まれています。

preスナップショット作成


[root@localhost ~]# snapper create -t pre

適当にファイル変更


[root@localhost ~]# ls
anaconda-ks.cfg  hoge  lvmdump-localhost.localdomain-20150515103428.tgz
[root@localhost ~]# rm hoge 
rm: remove regular empty file ‘hoge’? y

postスナップショット作成


[root@localhost ~]# snapper list
Type   | #  | Pre # | Date                     | User | Cleanup | Description | Userdata
-------+----+-------+--------------------------+------+---------+-------------+---------
single | 0  |       |                          | root |         | current     |         
single | 9  |       | Mon May 18 18:15:10 2015 | root |         |             |         
pre    | 10 |       | Mon May 18 18:18:32 2015 | root |         |             |         
[root@localhost ~]# snapper create -t post --pre-number=10
[root@localhost ~]# snapper list
Type   | #  | Pre # | Date                     | User | Cleanup | Description | Userdata
-------+----+-------+--------------------------+------+---------+-------------+---------
single | 0  |       |                          | root |         | current     |         
single | 9  |       | Mon May 18 18:15:10 2015 | root |         |             |         
pre    | 10 |       | Mon May 18 18:18:32 2015 | root |         |             |         
post   | 11 | 10    | Mon May 18 18:19:42 2015 | root |         |             |

差分の確認


[root@localhost ~]# snapper status 10..11
-..... /root/hoge
c..... /var/log/messages
c..... /var/log/snapper.log

差分対象の制限(フィルタ)

hogeファイルが消えているのと、/var/log以下のログが増えていることがわかります。

ログの差分をとってもあまり嬉しくないので、/etc/snapper/filters/ に、log.txtという名前で以下のようなファイルを作成します。このパターンにマッチするものは差分チェックの対象になりません。

差分対象の制限


/var/log/*

差分の確認ふたたび


[root@localhost ~]# snapper status 10..11
-..... /root/hoge

undo

差分がとれるので、patchコマンドの要領でundoができます。

ただこのundoをした時に一貫性があるのか、もろもろ大丈夫なのかなどは特に保証されていませんので注意が必要です。


[root@localhost ~]# snapper undochange 10..11 
create:1 modify:0 delete:0

TODO

snapperにはこの他にも定期的にsnapshotをとっておいて、過去数回分を残しておくなどかなり気のきいた機能があります。裏で古いスナップショットを自動で消したり差分をしらべたりするので勝手に動くのが嫌なひとはオプションしらべてね(丸投げ)！

登録: 投稿 (Atom)