2015年 6月 の投稿一覧

Red Hat Enterprise Linux 7でスナップショットとり放題生活をしてみよう

Red Hat Enterprise Linux 7ではスナップショットを低いコストで実現するLVM thin provisioningによる論理ボリュームがサポートされています。この記事ではLVM thin provisioning環境へのインストールと、基本的なスナップショットの作り方を説明したのち、定期的なスナップショットの取得やファイルの差分取得を簡単にできるsnapperを紹介します。

レッドハットの森若です。

今回はRed Hat Enterprise Linux 7で登場したLVM thin provisioningによるスナップショットのサポートと、このスナップショットを活用するsnapperをご紹介します。

インストール

RHEL7のインストーラではインストール対象としてLVM thin provisioningが選択できるようになっています。ここを選択して、容量を設定することでこの後説明するスナップショット機能が利用できるようになります。

状態を確認

操作する前にlsblkコマンドで現在の状態を確認しましょう。
[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に同じエントリ(rhel-rootとrhel-pool00)が2回でているので不安になるかもしれません。tmetaの方はメタデータ、tdataの方は実際のデータがはいっていてこの2つの組み合わせでrhel-rootとrhel-pool00が実現されています。
この例では12GBのpool00の下に12GBということになっているrootが含まれている状態です。
プールの詳細は、lvdisplayコマンドで確認します:
  [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が含まれています。とても便利ですのでここからはsnapperをご紹介していきましょう。
まずは管理対象のディレクトリ(通常はマウントポイント)毎にsnapperの設定を作成します。デフォルトだと “root” という名前の設定で、それ以外だと-c “設定名” のようにオプションをつけて実行します。
[root@localhost ~]# snapper create-config -f 'lvm(xfs)' / 
このコマンドにより /etc/snapper/configs/rootに設定本体が作成され、
さらに設定一覧が /etc/sysconfig/snapper にあるのでここに設定名が追加されます。
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 という名前のスナップショットが作成されています。snapperでは元の論理ボリュームのあとに”-snapshot<スナップショット番号>”をつけた名前を生成し、自動的に名付けてくれます。さらにスナップショット作成時刻や、オプションで指定することで任意のメモを付与することができます。

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

復旧作業を行うような場合には、スナップショットをマウントして、中のファイルやディレクトリを利用できます。
snapper mount サブコマンドにスナップショット番号をオプションとして指定することで、readonlyでmountすることができます。
管理対象ディレクトリ以下の、.snapshotディレクトリに例のようなディレクトリが作成され、mountされます。
以下の例ではスナップショット 10番をマウントし、dfコマンドでマウントされていることを確認しています。
[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しておいてdiffを実行しています。
さらにスナップショットの属性としてpreとpostというタイプが導入されています。スナップショットの仕組み自体は同じなのですが、なんらかの作業前にpreスナップショットを取得、作業後にpostスナップショットを取得してペアにしています。postスナップショットを作成すると、snapperが自動的に対応づけられたpreスナップショットとの差分をバックグラウンドで取得し、作業によるファイル変更情報をまとめます。
preスナップショット作成
[root@localhost ~]# snapper create -t pre 
 [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 ~]# rm hoge 
rm: remove regular empty file ‘hoge’? y 
preスナップショット10番に対応するpostスナップショットを作成
[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という名前で以下のようなファイルを作成します。このfilterディレクトリ内のファイルで指定されたパターンにマッチするファイルは差分チェックの対象になりません。
差分対象の制限
 /var/log/* 
差分の確認ふたたび
 [root@localhost ~]# snapper status 10..11
 -..... /root/hoge 

undochange

差分がとれるので、patchコマンドの要領でundoができます。
ただこのundoをした時に一貫性があるのか、もろもろ大丈夫なのかなどは特に保証されていませんので注意が必要です。この例では削除されたファイル “hoge” がスナップショットからコピーされて復旧します。
 [root@localhost ~]# snapper undochange 10..11
 create:1 modify:0 delete:0 

関連ドキュメント

snapperにはこの他にも定期的にsnapshotをとっておいて、過去数回分を残しておくなどの機能があります。ここでは説明できなかった点も多数ありますので、関連するドキュメントへのリンクを以下に記載します。

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

「システムに既知の脆弱性や問題のある設定がないかチェックをしよう」というとき、あなたならどうしますか? 本稿ではセキュリティ対応の自動化のため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からはサポート対象として同梱されています。

 

Red Hat Enterprise Linuxのセキュリティ対応に

 

Red Hat Satelliteからの管理

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

 

関連資料

 

RHEL 7.0時点のもので現在とは多少見た目がちがいますが紹介ビデオがあります

(レッドハット ソリューションアーキテクト 森若和雄)

Red Hat Directory Server 10.0リリース!

今回は2015年6月16日に出荷されたRed Hat Directory Server 10 をご紹介します。RHDSはNetscape Directory Serverを買収したRed HatがOSS化したLDAPサーバで、高い互換性によりSolarisなどからの移行時に活躍します。またOpenLDAPに無い企業向けの様々な機能も搭載しています。

レッドハットの森若です。今回は2015年6月16日に出荷されたRed Hat Directory Server 10 をご紹介します。

Red Hat Directory Server とは?

Red Hat Directory Serverは汎用のLDAPサーバで、主にアカウントにひもづく情報を格納するために利用されます。住所、氏名、生年月日、性別、電話番号、メールアドレス、認証用のパスワード、顔写真、役職などの人に直接ひもづく情報に加えて、権限管理をするためのグループ情報、ロール情報、サーバ情報や各種の設定といった多様なデータを保持します。

LDAP v3の各種規格に準拠した通常のLDAPサーバとしての基本機能に加えて企業での大規模な運用を便利にする種々の追加機能を提供しています。Red Hat Enterprise Linux 7.1以降で動作し、5年間のサポート期間が設定されています。upstream projectは389 Directory Serverです。

Red Hat Directory Serverの生い立ち

実はRed Hat Directory Serverは世界初の商用LDAP製品であるNetscape Directory Serverの直系の子孫でもあります。ミシガン大学で作成された世界初のLDAPサーバslapdから派生した商用LDAP製品として、1996年からNetscape Directory Serverの開発がはじまりました。OpenLDAPも同じslapdから派生したものです。

最初はNetscape社が一社で開発していましたが、1998年からはSun MIcrosystems社とアライアンスを組んでiPlanet Directory Serverという名前で開発・販売していました。2002年にアライアンスが終了し、その時点での製品についてAOL社(この時点でNetscape社はAOLに買収されていました)とSun Microsystems社はどちらも権利を得てSunはiPlanet Directory Server, AOLは Netscape Directory Serverとして開発を継続します。

2004年にRed HatはAOLからDirectory ServerおよびCertificate Systemの事業を開発メンバーとともに買収し、ここにRed Hat Directory Serverが誕生しました。2005年にオープンソース化し、コミュニティプロジェクトとしてFedora Directory Serverが立ちあがり、のちに改名して389 Directory Serverとなっています。

現在では389 Directory Serverプロジェクトで主な開発作業を行い、これにテスト, ドキュメント, サポートなどを付加して製品化したものがRed Hat Directory Serverとなっています。

ライフサイクルと動作環境

最近のバージョンでは、RHDS 8はRHEL5上で、RHDS 9はRHEL6上、RHDS 10はRHEL7上というように、動作環境となるRHELのバージョンをきりかえるタイミングでメジャーバージョンが更新されています。またRHDS8まではSolarisなど他社OS上でも動作する版が販売されていました。

https://access.redhat.com/support/policy/updates/directory/

Red Hat Directory Serverのサポート期間はGAから5年間です。現在サポート対象になっているバージョンと期限は以下の通りです。

  • RHDS8 (RHEL5)    2015年8月
  • RHDS9 (RHEL6)    2017年6月
  • RHDS10 (RHEL7)    2020年6月

OpenLDAPと比較したときのRed Hat Directory Server 10 の特徴は?

同じミシガン大学のLDAPサーバ由来のOpenLDAPと比較すると、Red Hat Directory Server 10には以下のような特徴があります。

  • JavaによるGUIでの管理コンソール
  • 最大20ノードまでサポートされるマルチマスターレプリケーション
  • Windows 2008 R2, 2012, 2012 R2 のActive Directoryとの同期機能
  • 任意の属性を暗号化して保存
  • マクロをもちいたACLの定義などの強力なアクセス制御機能
  • バックアップなどの管理操作をTaskとしてLDAPサーバに統合
  • プラグイン開発用インタフェースの提供
  • Class of ServiceとRoleのサポート
  • Virtual Viewにより属性によるダイナミックなツリーを提供
  • SunDSやOracle DSEEとの高い互換性

 

残念ながら英語のみで日本語訳はないものの、非常に充実したドキュメントが存在することもRHDSのポイントです。RHDS10のドキュメントには通常の利用方法の他に、LDAPサーバの構築時に必要な考慮点や、既存のRHDS 7,8,9からの移行手順なども記載されています。

RHDS8まではクライアント用ライブラリやツールがOpenLDAPと異なっていましたが、RHDS9からはOpenLDAPのクライアントがそのまま利用できるようになっています。

Solaris, HP-UX, AIXから移行するような場合は?

SunDSやOracle DSEEからLinuxへ移行するような場合、またSolarisやHP-UX、AIX向けに過去に出荷されていたRHDSからLinux上のLDAPサーバへの移行の場合にも、RHEL上のRHDSは有力な移行先の候補になります。

OpenLDAPではサポートされていないNetscape時代に拡張されたロールや時間ベースアクセス管理などの権限管理機能、管理コンソールなど多くの点で共通点があるRed Hat Directory Serverは有力な移行先の候補になるでしょう。

費用は?

RHDSはCPUのコア数やアカウント数ではなく、サーバ台数単位での価格になっています。

ソフトウェアとしては全く同じですが、クライアントから更新をうけつける通常のサーバ(195万円/台)と、クライアントからの更新をうけつけない読み込みのみのレプリカ(39万円/台)で価格が異なります。

動作環境としてRHEL Serverが別途必要で、サポートレベルはRHEL Serverのサポートレベルに準じます。

関連資料