技術

2017年03月18日

僕が管理しているいくつかの linux サーバーですが、いつセットアップされたのか調べたいと思うときがありました。いやこれは完全に個人的な興味なんですが。

で、いくつかの方法を調べたのですが、いまいちよくわからないというのが正直なところです。

以下の方法が確実っぽい?
ファイルシステムの作成日時を確認

・マウントされているデバイスを確認
#df
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 45G 2.0G 41G 5% /
tmpfs 495M 0 495M 0% /dev/shm
/dev/sda1 488M 108M 355M 24% /boot

このなかで /dev/sda3 を作成したのは、インストール時なので作成日を見ればいいようです。

# tune2fs -l /dev/sda3 | grep 'Filesystem created'
Filesystem created: Mon May 6 00:59:29 2013
手元にあるサーバーでは、上記のようになっていました。そしてこれはなんとなく正しいように思います。

キックスタートの cfg ファイルの作成日時
ll /root/anaconda-ks.cfg
-rw-------. 1 root root 1019 5月 6 01:02 2013 /root/anaconda-ks.cfg

これもインストール時に作成されるので、消していなければ正しい値のように思われます。
そして、僕の環境では、上記2つのファイルが近似していました。深夜に作業しているのは不明です。覚えていません。ゴールデンウィークに作業していたんでしょうねw

以下のコマンドでRPMから日時も確認できます。
#rpm -qi basesystem | grep Install
Install Date: 2013年05月06日 01時00分32秒 Build Host: c5b2.bsys.dev.centos.org

ファイルの変更日時から
# stat /* | grep Change | sort
Change: 2013-05-06 00:59:42.137000001 +0900
Change: 2013-05-06 01:00:29.204000000 +0900
Change: 2013-05-06 01:00:32.031000000 +0900



stock_value at 10:19|この記事のURLComments(0)TrackBack(0)

2017年03月17日

CentOS 7 にインストールしました。

※インターネットに接続できることや、SELinuxがOFFにすることなどの、基本的な設定はしています。

必要なモジュールのインストール
#yum install perl
#yum install perl-Data-Dumper
#yum install perl-Digest-MD5
#yum install ld-linux.so.2

管理画面を表示させるために、Apacheの導入と、SSLモジュールが必要です。
#yum install httpd
#yum install mod_ssl

カスペルスキーモジュールのインストール
#rpm -ivh klms-8.0.1-721.i386.rpm
→ /opt/kaspersky/klms/bin/klms-setup.pl を実行するように言われる・・・あとで。

#rpm -ivh klms_ja-8.0.1.721-7.noarch.rpm
#rpm -ivh klmsui-8.0.1-721.x86_64.rpm
→ /opt/kaspersky/klmsui/bin/klmsui-setup.pl を実行するように言われる。・・・あとで。


セットアップツールの実行
# /opt/kaspersky/klms/bin/klms-setup.pl

※メモがここまでだったので、後日またちゃんと記事にしたいと思います。



stock_value at 23:03|この記事のURLComments(0)TrackBack(0)

2017年03月16日

僕はサーバーを管理することが多く、中のコンテンツについては、あまり興味もありませんし、なにより知識がありません。
今回、 cakephp を動作させているサーバーで作業していました。

httpd.conf の設定も完了し、このときには動作は問題ありませんでした。
Site A
Site B
Site C
バーチャルホストで複数のサイトを振り分け、ログを見る限りではそれぞれに問題無く振り分けられ、また静的なファイルについては、正しく表示されることも確認しました。

そしてコンテンツ管理者が Site A-C に cakephp を設置し動作させたところ、Site Aは正しく表示されるのですが、それ以外のURLはすべて同じようにSiteAが表示されてしまいました。

最初に言われたのは、.htaccess は有効になっていますか?と。もちろん今回の件は htaccess が利用されることを聞いていたので、・・・そしてhtaccessを利用するのはあたりまえだし・・・ 設定は終わらせていました。それに話を聞く限りでは SiteA の cakephp は正しく動作しているようです。

と、このような状態で httpd.conf の各種設定を改めて確認しました。しかしながら僕が確認した範囲ではすべてが正しく動作しているようでした。

ということでまずは基本的な動作確認
1. ログの確認
2. rewrite log の取得
3. cakephp の設定確認

1. ログの確認
VirtualHost で設定している箇所から、ログファイルの場所を確認します。
SiteAや、SiteBにアクセスしたときに http のログファイルが正常に表示され、アクセスされていること、レスポンスが正しいことを確認します。
この確認によって ServerName や ServerAlias の設定が正しいことを確認します。
VirtualHost が複数あって、ServerName などに設定している値が重複していると、上位行が優先されるので、下位行は設定が活きません。
意外とありがちなミスですね。

2. rewrite log の取得
VirtualHost の設定項目に以下のログ取得項目を記載します。 reload も忘れずに。
・・・以前もこのことブログに書いたと思っていたら、やっぱり前回も cakephp 絡みでした
RewriteLog /tmp/rewrite-SiteA.log
RewriteLogLevel 9

これで、 正しいサイトの htaccess が読み込まれていること、意図通りの動作になっていることをを確認します。
そして、上記設定を確認したところ問題ありませんでした。

ここまで確認したところ、やはり conf ファイルは問題なさそうでした。そのため次は cakephp の設定が疑わしくなります。特にSiteAは問題無いので、SiteB-Cですね。

3. cakephp の設定確認
パス定数と変更方法やURLの取得
知識が足りない僕ができることは限られています。DBの接続情報を確認したり、テキストベースで行われている設定ファイルを確認したり。

で、上記参考サイトの通り、cakephp を動作させるパスの設定を確認しました。
webroot/index.php
そしてどうやら以下の APP_DIR に間違いがあることに気づきました。
define('APP_DIR', 'app');

ここを書き換えたところ、SiteA-Cまで問題無く表示されるようになりました。

stock_value at 10:01|この記事のURLComments(0)TrackBack(0)

2017年03月15日

いままで気づかなかったのが不思議なくらいです。
ずいぶんと前にセットアップした CentOS ですが、最近になって気づきました。

iptables のファイルを編集していたときに、たくさんの行を貼り付けていると貼り付けられたすべての行が、意図せず勝手にコメントアウトされているのです。

このような不便な機能を無効にするには、vi で以下のコマンドをセットすればOKでした。
:set paste

で、この勝手なコメントアウトは不便なため毎回上記コマンドを入力していたのですが、いい加減デフォルトで無効にする方法を調べました。

いろいろな方法が記載されていたのですが、なんだかよくわかりません。
以下の方法で簡単にできました。

# vi /etc/vimrc

いろいろ記載がありましたので、最初の方に以下の行を追加
set paste

※前後行はこんな感じでした
set nocompatible " Use Vim defaults (much better!)
set bs=indent,eol,start " allow backspacing over everything in insert mode
"set ai " always set autoindenting on
"set backup " keep a backup file
set viminfo='20,\"50 " read/write a .viminfo file, don't store more
" than 50 lines of registers
set history=50 " keep 50 lines of command line history
set ruler " show the cursor position all the time

これで自動コメントアウト機能が無効になりました。

※以下のプラグインが理由でしょうか?削除しても効果あるのかもしれません。
/usr/share/vim/vim74/autoload/paste.vim

stock_value at 09:05|この記事のURLComments(0)TrackBack(0)

2017年03月14日

現状すべて不明です。以下の症状があったのでメモ。
ps -ef コマンドを実行し、プロセスの稼働状況を確認すると、
php /tmp/phpd.local というプロセスが存在していました。

なんと!

調べても出てこないのですが、きっと何か悪さをするプログラムに違いありません。とりあえずプロセスを終了させ、Apacheの再起動をしました。

しかしなんだったのでしょうか。

stock_value at 12:56|この記事のURLComments(0)TrackBack(0)

2017年03月13日

昨日の記事の続きです。
iptables restore を行うとメモリが枯渇するようだということに気づきました。

そしてルールは大量です。
で、気になったのですが iptables は一体どのぐらいのルールをかけるのだろうか、と。

なお僕は数台のサーバーを管理していますが、その中でルール数が多いのは2台。

1台は以下の通り1Gのメモリです。(そしてこちらが今回のトラブルです)
# free -h
total used free shared buffers cached
Mem: 988M 562M 426M 0B 3.7M 20M
-/+ buffers/cache: 538M 450M
Swap: 4.0G 33M 4.0G

# iptables -nvL |wc -l
46796
iptables のルール数は上記の通り約47,000


もう1台は以下の通り
# free -h
total used free shared buffers cached
Mem: 9.6G 7.1G 2.5G 548M 498M 4.4G
-/+ buffers/cache: 2.2G 7.4G
Swap: 4.9G 230M 4.7G

# iptables -nvL |wc -l
54593
iptables のルール数は上記の通り約54,000


これで、ルールをなるべく統一したいので、マージしながら作業していました。
そしてある程度マージが完了し、ルール数を調整しながら iptables のルール再読込行ったところ、問題が発生しました。
ちなみに上記の46796で、やく2,000ルール増やすともうダメです。結構ギリギリのラインみたい。

で、いろいろ確認していると、 iptables がルールを読み込むときには、スワップ領域ではないところにメモリを確保するようです。そしてそれはルール数に依存するようです。

なお iptables の最大のルール数は32bitの場合に 3800万のようです。

1つのルールごとに少しずつ消費するようなのですが、結局1Gでは超過してしまうということのようです。
ということで、メモリを増設して様子を見たいと思います。

stock_value at 13:29|この記事のURLComments(0)TrackBack(0)

2017年03月12日

iptables の大量コピーをおこなったのです。

OSの History ログでは以下のようになっていました。
2452 17/XX/XX 11:02:19: vim /etc/sysconfig/iptables
2453 17/XX/XX 11:06:06: service iptables reload

そして message ログは以下の通り
XX 11:05:59 XXX named[60450]: client X.X.X.X#51951: query (cache) 'XXXX' denied
XX 11:36:11 XXX kernel: imklog 5.8.10, log source = /proc/kmsg started.
XX 11:36:11 XXX rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="61530" x-info="http://www.rsyslog.com"] start

これは 11:05:59 に oom-killer によって rsyslog のプロセスが落とされ、それに気づいて rsyslog を再起動したのが 11:36 ということです。

で、時間から考えるに、iptables ファイルの編集とiptables ルールの再読み込みが可能性としては一番高いように思います。

そして気になる動作がありました。
このとき僕は poderosa を利用し ssh にて大量のコピーを行ってました。やく55,000行です。そしてこのとき、一度にすべての行を貼り付けたのですが、途中で止まってしまいました。
それでも4万行近くは貼り付けられたので、残りの部分を再度貼り付けました。そしてファイル編集は完了したのです。

iptables の reload を行うと、監視しているサーバーからアラートが上がりました。ping応答がないと。DNS応答がないと。うわ!iptables の内容間違えたかな。そのように考えていたのです。

iptables -F をしてフィルターをクリアしても、回復しません。ということで、ポートのLISTENなどを確認しました。
しかしLISTENしていない・・。これでプロセスが落ちたことはわかりました。

いくつか検証をしているうちに、ログが一切表示されていないことがわかりました。そして service rsyslog start で起動すると、ログが出力され oom-killer が動作していることに気づきました。


で、その後何回かチャレンジしていたところ、 iptables restore で毎回 out of memory が発生していることに気づきました。
iptabbels はメモリを食うのでしょうか・・。

stock_value at 12:43|この記事のURLComments(0)TrackBack(0)