ラベル Linux の投稿を表示しています。 すべての投稿を表示
ラベル Linux の投稿を表示しています。 すべての投稿を表示

2013年12月7日土曜日

CentOSにmDNSを設定する

ノートPCにインストールしたCentOSに, mDNSに設定したときのメモ.

経緯

このCentOSは, 持ち運び可能なサーバとして運用している. ポータブルな環境に固定IP設定するのは微妙だし, IPアドレス直打ちでアクセスするにしても, 毎回IP確認するのは面倒くさい.
そこで, mDNSを設定して「ホスト名.local」でアクセスできるようにした.

ホスト名の設定

まずは, ホスト名を設定する.
NETWORKING=yes
HOSTNAME=hoge.local

nss-mdnsのインストール

nss-mdnsパッケージは, CentOSの標準リポジトリにないのでEPELを追加する.

◆EPELのインストール
$ wget http://ftp-srv2.kddilabs.jp/Linux/distributions/fedora/epel/6/x86_64/epel-release-6-8.noarch.rpm
$ sudo rpm -ivh epel-release-6-8.noarch.rpm
nss-mdnsをインストールするだけなので, 普段はEPELを有効にしないようにしておく(/etc/yum.repos.d/epel.repoの[epel]セクションで「enable=0」にする).

◆nss-mdnsのインストール
$ sudo yum --enablerepo=epel install nss-mdns

nss-mdnsの設定

名前解決の手段として使用するには, /etc/nsswitch.confの修正が必要だが, nss-mdnsをインストールすると自動で修正されているはず.
hosts:      files mdns4_minimal [NOTFOUND=return] dns

Firewallの設定

system-config-firewall-tuiを起動して, 「マルチキャスト DNS (mDNS)」を信頼したサービスに追加しておく. 追加すると, 224.0.0.251:5353宛のUDP通信が許可される.

再起動

いろいろ設定を変更したので, rebootして設定を反映させる(もちろん各サービスの再起動でも可).

2013年9月11日水曜日

COREファイルの出力先

COREファイルの出力先についてよくわからないことがある.

COREファイルの出力先は, 「/proc/sys/kernel/core_pattern」に定義されており, RHEL6/CentOS6はデフォルトで以下のように定義されている.
|/usr/libexec/abrt-hook-ccpp <hogehoge>
<hogehoge>の部分はRHELとCentOSで異なっていた.
Linux2.6.19以降, 上記のようにCOREファイルをパイプ後方のプログラムの標準入力に渡すことができるようだ. この場合, 「abrt-hook-ccpp」というプログラムに渡している.
つまり, バグ報告プログラム「ABRT」にCOREファイルを渡すということが読み取れる.

ということは, COREファイルは「ABRT」に渡されるのだから, 実行ファイルと同じディレクトリには出力されなくなっているのではないだろうか?
ちょっと調べてみると, このページには, 実行ファイルと同じディレクトリにCOREファイルを出力するのであればcore_patternの記述を変更しなさいと書かれている(3. Ruling out ABRTのところ).

ところが, RHEL6.1がインストールされたとある環境では, core_patternで「ABRT」に渡しているのにもかかわらず, COREファイルが実行ファイルと同じディレクトリに出力されていた. もしかして「ABRT」が正常に機能していない場合は, 実行ファイルの場所に出力される仕様なのか?

【2013/09/12 追記】
以下のドキュメントを見つけた.

How to Enable Creation of Core Dump Files Due to Crashed Applications in Fedora Linux Distribution

この中に以下の記述がある.
$sysctl -a|grep core_pattern
kernel.core_pattern = |/usr/libexec/abrt-hook-ccpp /var/cache/abrt %p %s %u %c

“abrtd” creates a sub-directory (named something like “ccpp-1279914365-14618″) in the directory “/var/cache/abrt” as shown in the value of the variable. This also means that the core files will also be stored in that sub-directory in the “/var/cache/abrt” directory (in addition to the current directory where application was run). ABRT daemon also creates other files in addition to the core dump files in the sub-directory to further help users in debugging the crash issue.
 つまり, abrt-hook-ccppにパイプすると, 実行ファイルと同じディレクトリにCOREファイルを出力するのに加えて, バグレポート用にCOREファイルを「/var/cache/abrt/ccpp-<hoge>(RHEL6.1では, /var/spool/abrt/ccpp-<hoge>)」配下にも出力するということだ.

実際にプロセスをKILLしてみたところ, COREファイルが両方に出力されることを確認できた. この状態だとCOREファイルのサイズが倍になるということだから, 知らずにシステム設計してしまうと, ディスク使用量の見積もりを間違えて大変なことになるな.

2013年9月9日月曜日

セキュリティコンテキストの設定

SELinuxが有効になっているCentOS6上にpukiwikiを設置しようとして, セキュリティコンテキストの設定に手こずった.
SELinuxが有効になっている場合, とあるセキュリティコンテキストが設定されているディレクトリ配下のファイルには, セキュリティコンテキストが適切に設定されている必要があるようだ(経験上そうらしいというだけしか知らない).
SELinuxを無効にするのが手っ取り早いのだが, 悔しいのであえて有効のままやった.

手こずった経緯を書くのは面倒なので, 結論と注意事項くらいにまとめる.
今回, ドキュメントルートは「/var/www/html」とし, pukiwikiのディレクトリ名を「wiki」にして設置した. この場合, セキュリティコンテキストは以下のように設定する.
# semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/html/wiki/(attach|backup|cache|diff|wiki)(/.*)?"
# semanage fcontext -a -t httpd_sys_htaccess_t "/var/www/html/wiki/(.*/)?\.ht[^/]*"
# restorecon -R /var/www/html/
これでうまくいった.
「semanage」コマンドは, セキュリティコンテキストを定義するコマンドなのだが, デフォルトではインストールされていないので, 以下を参考にインストールしておく.

【参考】
RHEL 6: semanage SELinux Command Not Found

「restorecon」は, 定義したセキュリティコンテキストを適用するコマンド. このコマンドは, 私の環境にデフォルトでインストールされていた.ちなみに, 適用されたセキュリティコンテキストは「ls -Z」で確認することができる.
# ls -aZ /var/www/html/wiki
・・・
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_htaccess_t:s0 .htaccess
-rw-r--r--. apache apache system_u:object_r:httpd_sys_htaccess_t:s0 .htpasswd
-rw-rw-rw-. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 COPYING.txt
-rw-rw-rw-. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 INSTALL.txt
-rwxrwxrwx. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 README.en.txt.gz
-rw-rw-rw-. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 README.txt
-rwxrwxrwx. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 UPDATING.en.txt.gz
-rw-rw-rw-. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 UPDATING.txt
drwxrwxrwx. apache apache unconfined_u:object_r:httpd_sys_rw_content_t:s0 attach
drwxrwxrwx. apache apache unconfined_u:object_r:httpd_sys_rw_content_t:s0 backup
drwxrwxrwx. apache apache unconfined_u:object_r:httpd_sys_rw_content_t:s0 cache
drwxrwxrwx. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 counter
・・・
はじめ, セキュリティコンテキストをすべて「httpd_sys_content_t」で設定したら(/var/www/html/index.htmlがそうだったから), pukiwikiにアクセスしたときに以下のエラーがでてしまった.
Runtime error
Error message :

Directory is not found or not writable (DATA_DIR)
Directory is not found or not writable (DIFF_DIR)
Directory is not found or not writable (BACKUP_DIR)
Directory is not found or not writable (CACHE_DIR)
そこで, 「semanage fcontext -l | grep wiki」で調べたら, mediawiki用に「httpd_sys_rw_content_t」が定義されていたので真似をした. 「httpd_sys_htaccess」は, ググってたら見っけた.