はてなブックマーク

RHEL/CentOS 6に標準でインストールされる rsyslog は 5.8.x。しかし、rsyslog7 という名称で rsyslog 7.4.x のパッケージも用意されていて、5.8.x からアップグレードすることが可能だ。rsyslogのドキュメントでも言われているが、バージョン5 は機能が甚だ中途半端。処理速度も遅い。当ページでは、rsyslog 7.4.10 で Syslogサーバを仕立てる上で分かった rsyslog の機能やコツについて述べる。ちなみに RHEL/CentOS 7 では最初から rsyslog 7.4.x が標準となっている。 <- バージョン5 での検証と解説はこちら RHEL/CentOS 6での rsyslog 5->7 へのアップグレード方法 RHEL/CentOS 6でも rsyslog 7.4 が rsyslog7 という名称で選択可能パッケー

RHEL/CentOS 6の標準の rsyslog は 5.8.x。rsyslogのドキュメントでも言われているが甚だ中途半端なバージョンだ。Syslogサーバに仕立てるために調べていたらコツや癖がいろいろと分かってきたので、まとめておくことにした。なお、RHEL/CentOS 6でも rsyslog7 という名称で rsyslog 7.4.x のパッケージも用意されていて、5.8.x からアップグレードすることが可能だ。ちなみに RHEL/CentOS 7 では rsyslog 7.4.x が元来標準となっている。 バージョン7 の検証は別ページにまとめた。 リモートロギングのための設定 ここでは 514/UDP でのリモートログ受け入れを基本とし、TCPについては補足的に述べるに留める。TCPの方がログ欠落の可能性は低いが、ファイヤーウォールアプライアンスなど、未だにUDPでしかログを

LINUX の場合 付属ユーティリティの ntpdate で `ntpdate -b 192.168.0.1 ' (確実に名前解決できるならホスト名でも可) する手もあるが、NTP が推奨しているのは、ちょっと面倒だが、クライアントでも認証を含めたすべての項目を設定しておき `ntpd -q' するという方法だ。タイムサーバ側と同じくデーモンとして常時起動させておく方法もあるが、ここでは cron による方法について述べる。 Linux (NTPクライアント) から Windows 2003 Server (NTPサーバ) に時刻を合わせようとしても、Linux の ntpd が Windows を NTPサーバとして信用しようとせず、時刻合わせができない場合がある。そういった時は、後述の「Linux野郎のための WINDOWS 2003/XP/2008 時刻同期解説」を参照していただくと

LDAP連携に関係するファイル一覧 /etc/ \_ dovecot.conf [root:root 644] 主設定ファイル dovecot.d/ [root:root 755] 補助設定ファイル用ディレクトリ (新規作成) \_ ldapref.conf [root:dovecotauth 640] LDAP参照定義ファイル dovecot.conf - 主設定ファイル 以下は Dovecot 1.0.7 で検証したもの。LDAP と関わりがなくても主なパラメータについては網羅し、当実装に特に深く関わるものは □地で示す。最新のディレクティブリストはオフィシャルサイト Dovecot.org の Dovecot configuration file(1.x系) で見られる。LDAP連携に関しては、Dovecot wiki の "HOWTOs / Examples / Tutorials

このサイトは、もともと作者の自分用メモとして書き始めたものです。書いてあることが全て正しいとは限りません。他の文献、オフィシャルなサイトも確認して、自己責任にて利用してください。 Postfix は、SMTP AUTH のための認証機構を外部プログラム (あるいはライブラリ) である SASL に頼っている。SASL は Simple Authentication and Security Layer の略で、ざっくり言えば、認証手続き (例：PLAINやDIGEST-MD5) と認証データ参照メカニズム(例：LDAPやSQL) との間を抽象化して、簡単に使える認証フレームワークをアプリケーションに提供する仕組みだ。RFC4422 (RFC2222 を置き換えた) で標準化されている。 Postfix から使える SASL の実装としては、カーネギーメロン大学の Project Cyrus

RedHat系では、VNCサーバは vnc-server パッケージ (RHEL/CentOS 6 以降では tigervnc-server パッケージ) で提供される。また、xinetd 起動にする場合は xinetd パッケージもインストールしておく必要がある。 hostsファイルの整形 RedHat系の /etc/hosts ファイルは伝統的に書き方が悪く、このあとの VNCサーバの設定でエラーが出る場合がある。 127.0.0.1 localhost.localdomain localhost centos51u のようになっているのを、 127.0.0.1 localhost.localdomain localhost 192.168.0.8 centos51u.mydomain.com centos51u のように直しておく。 VNCサーバのいろいろな起動方法 筆者のお薦めとし

`used only once' 警告を消す 設定変数だけを別ファイルに分けることは多いはず。しかし、その場合、 warnings を有効にすると、`used only once, possible typo' (この変数は一度しか使われていないぞ。ミススペルじゃないのか？) という警告が出ることが多い。これを防ぐには、本体スクリプトの冒頭で、 #!/usr/bin/perl use warnings; no warnings qw(once); 出力バッファリングを一時的に無効化する 或るファイルハンドルに対してのみ出力バッファリング (output buffering) を無効にするには、そのファイルハンドルを select() してオートフラッシュ変数 $| を 1 に設定する。select() を再び元の状態に戻しておくのを忘れてはならないが、ひとつの複合 select文で一息に行

11.23. SNATターゲットSNAT ターゲットは送信元ネットワークアドレス変換 (Source Network Address Translation ) を行うのに用いる。つまりこのターゲットは、パケットの IP ヘッダに書かれている送信元の IPアドレスを書き換える。こうしたことが必要となるのは、例えば、ひとつのインターネット接続を複数のホストで共用しなければならない場合だ。その際には、カーネルのフォワード機能をオンにして、ローカルネットワークから出ていくパケットの送信元 IP を、インターネットコネクションそのものの IP へと書き換えるような SNAT ルールを書けばいいわけだ。我々のローカルネットワークは通常、 IANA の定めるところの LAN 内でのみ許される IPアドレスを使用しているため、このようにしないと、外の世界では、返答のパケットをどこへ送ればいいのか知る由も

ダンプ & リストアには様々な利点がある。万が一のサーバクラッシュへの備えや、マシン間でのデータベース移植にはもちろん。しかしそれだけでない。ファイルというポータブルな形にしてしまえばバックアップは簡単。さらに、PostgreSQL のバージョンアップの際には、リストア時に新しいサーバプログラムが構造を適宜変換して取り込むので、バージョンによるデータ互換性問題も、たいてい解決してくれる。日常的には当然だが、 PostgreSQL をバージョンアップする前には必ずダンプを取っておこう。 データベースのダンプ データそのものやテーブル構造をまるごとファイルに書き出すことができる。ファイルに書き出されるのは、リストアに必要なSQLコマンド。一切合切をいっぺんにダンプできる pg_dumpall を使う方法もある。 コマンド書式： pg_dump options database > ダンプ先fi

このサイトは、もともと作者の自分用メモとして書き始めたものです。書いてあることが全て正しいとは限りません。他の文献、オフィシャルなサイトも確認して、自己責任にて利用してください。 つまずきやすい設定項目 ディレクティブ個々の解説は Apache のドキュメントや様々な書籍で見られ、改めて論じても仕方がないので、ここでは、混同しやすい似たようなディレクティブの比較を中心に、覚え書きを並べることにした。各項は、前ページの設定ディレクティブ一覧からリンクしている。 Global Environment セクションのディレクティブ バーチャルホスト設定や <Directory> ブロックの中などでは使えない、サーバの動作環境設定専用ディレクティブ群。ただし、本来 HostsDefaultセクションに属するディレクティブも、 Global Environment のディレクティブと関連性が高いものは

ネット上ではまだ 389 Directory Server よりも旧名の Fedora Directory Server (Fedora DS) のほうが通りがいいかもしれない。その歴史はきわめて複雑だ。389 DS の直接の先祖は Netscape Directory Server だ。その後 Netscape社は AOL に買収されるわけだが、それと相前後して Netscape は Sun と共同で iPlanet ブランドを立ち上げており、そこで iPlanet Directory Server が分岐。やがて AOL が iPlanet ブランドを放棄すると、iPlanet は Sun のブランドとなり、そこから Sun Java System Directory Server が派生した。2004年、Red Hat は AOL から Netsape DS を買い取り Ferora

Table of Contents7.1. はじめに7.2. conntrackエントリ7.3. ユーザ空間でのステート7.4. TCPコネクション7.5. UDPコネクション7.6. ICMPコネクション7.7. デフォルトのコネクション7.8. 追跡除外コネクションとrawテーブル7.9. 複雑なプロトコルとコネクション追跡7.10. まとめ このチャプターでは、ステート機構 (state machine) を取り上げ、その詳細を説明していく。このチャプターを読み終われば、ステート機構の働き全般について、一通りの理解ができているはずだ。また、ここではステート機構の内部でステートがどのように処理されていくかについても、多数の例を挙げながら精査していく。実際の動きを見ることで、物事がくっきりと見えてくるだろう。

あまりにも基本的なツールだからなのか、世の中では「いまさら聞けない」状態になっていてあまり良いドキュメントがなかったので、これをまとめることにした。ちなみに sudo の読み方だが、オフィシャルサイトの FAQ によると、「我々は 『スードゥー (soo-doo)』 と呼んでいるが、"pseudo" と同じ読み方 (つまり 『スード』) も一般的だ」とある。 設定 sudo の設定ファイルが /etc/sudoers。RedHat 系では PAM でも一部制御されており、/etc/pam.d/sudo ファイルも動作に影響を与えるのだが、ここでは sudoers ファイルについてのみ述べる。 sudoers ファイルを編集するには、ファイルを直接エディタで開くのではなく、root 権限で、 root# visudo とコマンドする。すると sudoers がテンポラリファイルにコピーされて

10.3. 明示的なマッチ明示的なマッチ は、-m あるいは --match オプションではっきりとロードする必要のあるマッチだ。例えばステートマッチは、実際に使用したいマッチに先立って -m state ディレクティブ (命令句) を必要とする。この仲間には、プロトコル特有のマッチも幾つかある。また或るものは、プロトコルの種別とは一切無関係 -- 例えばコネクションステートがそうだ。コネクションステートとは NEW (まだ確立していない接続の最初のパケット)、 ESTABLISHED (既にカーネルに記録されている接続)、 RELATED (既存の確立済み接続に関連した接続) などといったものだ。さらに、ごく一部のマッチには、開発途上か実験的だったり、ただ単に iptables の可能性をデモンストレーションする目的で書かれたものもある。そうしたことから、一見しただけではいったい何に使っ

ひとことで言えば、SCSI-over-TCP/IP。SCSI プロトコルを TCP/IP 上で使用する規格のことだ。iSCSI では、ストレージを提供する方つまりストレージサーバ側を「ターゲット」(Target)、利用する側を「イニシエータ」(Initiator) と呼ぶ。ソフトウェアの実装は幾つかの団体が行っているようだが、RedHat系では、ターゲットソフトウェアは tgt project (※)、イニシエータソフトウェアは Open-iSCSI のものを採用している。iSCSI 管理コマンドは使い方が幾分複雑だ。その点、当ページはコマンド実例集としてもお役に立てるだろう。当内容の検証は主に RedHat Enterprise Linux 5.5 と CentOS 5.5 上で行った。 ※ tgt と並んで有名な iSCSI ターゲット実装に IET (iSCSI Enterprise

ここでは、KVMホストから virsh あるいは virt-manager (仮想マシンマネージャ) で別の KVMホストへ接続できるようにする方法を述べる。ゲストのライブマイグレーションを行うために、事前準備として必要な作業だ。KVMホストどうしの接続とは、つまり、互いの libvirt フレームワークどうしが通信するということなので、双方で libvirtd が起動していることが大前提となる。 libvirt には、リモート接続の方式として主に 3つが装備されている。libvirt オフィシャルサイトの "Remote Support" に説明がある。 sshトンネルを介した接続： libvirt は ssh の機能であるトネリングを通してリモートの libvirt と通信する。最も準備が簡単な方法。 TCP接続： 平文での TCP 通信。libvirt の待ち受けポートのデフォルトは

Ultra Monkey 解説のはじめに「RedHat Enterprise Linux 4 と Fedora Core 5 で検証した」と書いた。しかし残念ながら heartbeat については実験に供する 2台目の Fedora Core 5 マシンの持ちあわせがないため、ここからの内容は RHEL4 でのみ検証したものであることをお断りしておかなければならない。よって、heartbeat のバージョンも 1.x が話題の中心となる (Fedora Core 5 でインストールされるのはバージョン 2.x)。 heartbeat Linux-HA プロジェクトのオフィシャルドキュメントサイトに、"Getting Started with Linux-HA (Heartbeat)" をはじめ、優れた HOWTO がたくさんある。そちらも読むべし。 ここで目指すかたち いよいよ ldire

7.5. UDPコネクションUDP コネクションそれ自体は、ステートフルなコネクションではない。どちらかといえばステートレスなコネクションだ。理由としてはいくつかあるが、まず、接続の確立もクローズも備えていないという点。そもそも UDP 接続にはシーケンス [訳者補足: sequence = 順序、手順] がない。ある順序で UDP データグラムがやりとりされる場合でも、どういう順序で送るかといった情報のやりとりは何もないのだ。それにもかかわらず、カーネル内部で接続のステートを判定することは可能だ。では、コネクションがどのように追跡されるか、 conntrack の中身はどんな風に見えるかを見ていこう。 ご覧の通り、 TCP 接続とまったく同じ要領でコネクションが確立する。これはユーザ空間から見た様子だ。内部的に見ると conntrack 情報は少し様子が違う。とはいえ、細部は本質的には変

7.4. TCPコネクションここからのセクションでは、基本的プロトコルである TCP, UDP, ICMP それぞれについて、ステートと、それがどのように処理されるかをつぶさに見ていくことにする。さらに、デフォルト つまり、これら 3 つのプロトコルに類別されない場合どうなるのかについても掘り下げる。まずは TCP プロトコルから始めることにした。というのも、 TCP はそれ自体ステートフルなプロトコルであるし、 iptables のステート機構に関わる興味深い特性がたくさんあるからだ。 TCP コネクションは常に 3 ウェイハンドシェークによって開始される。このハンドシェークによって、その先実際のデータを乗せることになるコネクションを確立およびネゴシエート (交渉) する。セッションは、まず SYN パケット、次に SYN/ACK パケットが続き、最後に、セッション確立を承認する ACK

B.2. NEWステートでありながらSYNビットの立っていないパケットiptables の仕様のうち、充分な説明がなく、多くの人 (正直、僕もそのひとりだった) が見落としている部分がひとつある。 NEW ステートを使用した時、SYN ビットの立っていないパケットでもファイヤーウォールを通過してしまうのだ。この仕様が存在するのは、場合によっては、あるパケットが、別のファイヤーウォールなどで ESTABLISHED 状態であるコネクションに、属している可能性を検討したいことがあるからだ。これのおかげで、複数のファイヤーウォールの併設が可能となり、うち 1つのファイヤーウォールではデータを一切損失することなく受けるということが可能となる。こうすれば、副ファイヤーウォールにサブネットのファイヤーウォール処理を引き継がせることができる。とはいえ、この仕様が、NEW ステートを用いると、それが接続開

このサイトは、もともと作者の自分用メモとして書き始めたものです。書いてあることが全て正しいとは限りません。他の文献、オフィシャルなサイトも確認して、自己責任にて利用してください。

Xenハイパーバイザ (Xen Hypervisor) 「ハイパーバイザこそ Xen の本体であり、Xen とは Xen Hypervisor のことである」。Hypervisor はまた、VMM (Virtual Machine Monitor = 仮想マシンモニタ) とも呼ばれる。Xen Hypervisor は一個の OS であり、実は Linux とは全く別の Nemesis というオペレーティングシステムだ。 事象的にとらえると、Xen版 dom0 カーネルのブート設定に見る通り、Xenホスト実マシンのブート時には、まず Xen そのもののカーネルイメージ xen.gz が起動され、そいつが Nemesis の上で Xen版 dom0 カーネルを起動させる。この xen.gz が Hypervisor だ。ハイパーバイザはハードウェアと全ての仮想ドメイン (dom0 も含む) と

このサイトは、もともと作者の自分用メモとして書き始めたものです。書いてあることが全て正しいとは限りません。他の文献、オフィシャルなサイトも確認して、自己責任にて利用してください。 ゲストのインストール (qemu-kvm直接編) GUI ツール virt-manager (仮想マシンマネージャ) を使えば、いとも簡単にゲストがインストールできてしまう。しかし、最初からそれに頼り切っていては QEMU/KVM の仕組みが理解できないので面白くないし、コマンドラインに比べると virt-manager には幾つか制約があり応用が利かない。そこで、当節では敢えてコマンドラインにこだわる。方法としては、qemu-kvm を直接コールするやり方と、コマンドライン版のゲストインストールヘルパー virt-install を使うやり方とがある。現実的には virt-install がお勧めだが、KVM

ゲストのインストール (virt-install編) 先のページでは、qemu-kvm コマンドでゲストのインストーラを直接起動してその後普段用の起動用 qemu-kvm スクリプトに移行するという基本的な、泥臭い、解剖学的なやり方を紹介したわけだが、当節では、virt-install コマンドでインストールする現実的なやり方を紹介する。virt-install は裏で libvirt (Xenの記事参照) を使用しているため、インストールと同時にゲスト定義が libvirt のドメイン定義データベースに登録される。そのため、インストール後に通常起動用のシェルスクリプトを用意したり libvirt のドメイン定義プールに手で加えたりといった手間が要らない。virt-install のコマンドオプションはかなり限られていて仮想マシンのパラメータをきめ細かく制御することができないという欠点はあ