シングスブログ

中小企業のマーケティングやブランディングのコンサルティング。事業開発、組織運営のPDCA改善やウェブサイトの成果改善、ウェブアプリ開発などウェブマーケティングを中心にサービスを提供しています。

ログ監視ツール Logwatch を使ってみる (アップデート版)

以前の記事から Logwatch のコマンドが変わっていたので、再度書き直しました。

以前から変わったところは、出力のところ。
前は、logwatch --print とするだけで標準出力できましたが、
logwatch --output stdout と出力指定をする必要があります。

Logwatch は、いろいろなログをまとめて集計し、レポートとして毎日定期的にメールで届けてくれる。不正アクセスや不具合の発見とサーバの監視に便利なツール。

Logwatch のインストール

Logwatch は Perl で書かれていて Perl 5.8 以上が必要です。

yumからのインストールは、

$ yum install logwatch

で、

ソースからのインストールは、こちらから

Logwatch をインストールした時点で cron に登録されているので、毎日指定した時刻または anacronでランダムな時刻に Logwatch のスクリプト (/etc/cron.daily/0logwatch) が実行されてレポートが届く。

logwatch の設定

logwatch の設定は、/usr/share/logwatch/default.conf/logwatch.conf を編集する。標準設定のままで十分ですが、以下の項目を確認して設定。

#ログが保存されているディレクトリ
LogDir = /var/log
#メールの送信先
MailTo = user@hoge.com
#アーカイブされたログも含めるかどうか
Archives = Yes
#レポートの日付範囲を3つのオプションから。All, Today, Yesterday
Range = Yesterday
ログの詳細度、Low (=0), Med (=5), High (=10) または 0から10までの数字で
Detail = High
# チェックの対象となるサービスを /usr/share/logwatch/scripts/services/ 以下、あるいは All で指定。
Service = All
# メールコマンドパス
mailer = "/usr/sbin/sendmail -t"

サービスごとの個別設定は、/usr/share/logwatch/default.conf/services/ に用意されている。各サービスの設定ファイルを編集することで個別設定できる。

logwatch コマンドを使ってみる

標準出力

logwatch --output stdout

または、デフォルトで標準出力

logwatch

出力は、標準出力 (stdout) ほか、メール (mail) とファイル (file) への出力がある。

特定のサービスだけ出力

logwatch --output stdout --service http

複数のサービスにも

logwatch --output stdout --service http --service sshd

ログの詳細度を変えてみる

logwatch --output stdout --detail 10 --service http

メールに出力

logwatch --output mail --mailto user@hoge.com

ファイルに出力

logwatch --output file --filename /path/to/logwatch.txt

logwatch --help

Usage: /sbin/logwatch [--detail ] [--logfile ] [--output ]
   [--format ] [--encode ] [--numeric] [--no-oldfiles-log]
   [--mailto ] [--archives] [--range ] [--debug ]
   [--filename ] [--help|--usage] [--version] [--service ]
   [--hostformat ] [--hostlimit ] [--html_wrap ]

--detail : Report Detail Level - High, Med, Low or any #.
--logfile : *Name of a logfile definition to report on.
--logdir : Name of default directory where logs are stored.
--service : *Name of a service definition to report on.
--output : Report Output - stdout [default], mail, file.
--format : Report Format - text [default], html.
--encode : Enconding to use - none [default], base64.
--no-oldfiles-log: Suppress the logwatch log, which informs about the
                   old files in logwatch tmpdir.
--mailto : Mail report to .
--archives: Use archived log files too.
--filename : Used to specify they filename to save to. --filename  [Forces output to file].
--range : Date range: Yesterday, Today, All, Help
                             where help will describe additional options
--numeric: Display addresses numerically rather than symbolically and numerically
           (saves  a  nameserver address-to-name lookup).
--debug : Debug Level - High, Med, Low or any #.
--hostformat: Host Based Report Options - none [default], split, splitmail.
--hostlimit: Limit report to hostname - host1,host2.
--hostname: overwrites hostname
--html_wrap : Default is 80.
--version: Displays current version.
--help: This message.
--usage: Same as --help.
* = Switch can be specified multiple times...

関連サイト

WordPressをサーバH2Oで動かす (WordPressアプリケーションサーバとしてのH2O)

常時SSL とプロトコル HTTP/2 に対応するため、サーバ環境を新しくしてウェブサイトを移行しました。 新しい試みとしてサーバ構成を CentOS7 + PHP7 + MariaDB + H2O + WordPress にしてみました。

次世代の HTTPサーバ H2O を中心に速い WordPress を目指してサーバを構築。

今回 WordPress を HTTPサーバ H2O でどのように動かせばいいのか見てみたいと思います。

HTTPサーバ H2O とは

H2O は、プロトコル HTTP/2 に最適化されたウェブサーバです。

ここ数年でセキュリティ面で SSL が必須になりつつあり、ネット環境も新しい通信規約 (プロトコル) が求められている時代に最適なウェブサーバのひとつになっていくのだろうと注目していました。

H2O の開発は、2014年から元DNAの @kazuho さんが中心にオープンソースとして進められています。Perl を使っている方はウェブアプリを作るときに Server::Starter でお世話になっているのでは。ボクもいつもお世話になっています。 Server::Starter は、H2O のバックグラウンドにも使われていて start_server が動いているのが見て取れます。こういうところにも使われているのかとほんと感心しますね。

HTTP/2 時代を見据えているだけあってサーバの性能もベンチマークを見るとレスポンスが Apache や Nginx より速い。 他にも H2O の技術要素に注目したいものがたくさんあるのですが、詳しく知りたい方は、公式サイトやスライドも上がっているのでそちらを見ていただければと思います。

WordPress をサーバ H2O で動かす

2015年6月に FastCGI機能を実装したバージョン 1.3.0 がリリースされて、PHP が動くようになりました。 サーバ H2O で WordPress を動かすには、2 つの方法があります。

ひとつめは、WordPress を PHP-FPM や HHVM で管理。Nginx で従来やっている馴染みのあるやり方をそのまま踏襲。H2O も fastcgi.connect でホストに繋げてレスポンスを返してくれる。

今回採用したもう一個の方は、H2O 自体で管理する方法。 fastcgi.spawn で起動してH2Oの下で PHP のプロセスを管理してくれます。 PHP-FPM や HHVM をインストールしてコンフィグの設定起動、運用の手間がなくなります。

今回の試みとして思っていたことで、 WordPress とかPHPアプリを動かすアプリケーションサーバとしてH2Oは、最適なんじゃないかなぁと。

実際 H2O の下に php-cgi が動いているのが見て取れます。

WordPress を動かすサーバ設定 (/etc/h2o/h2o.conf) もYAML書式でシンプルに書けます。

以下これだけでWordPressが動きます。

paths:
  "/":
    file.dir: /path/to/wordpress
    redirect:
      url: /index.php/
      internal: YES
      status: 307
    file.custom-handler:
      extension: .php
      fastcgi.spawn: "PHP_FCGI_CHILDREN=10 exec /usr/bin/php-cgi"

実にシンプル。YAMLでわかりやすいのがいいですね。(本番運用には、自動更新やダッシュボードへのアクセスのところでもう少し手を入れる必要があるのですが。)

で今回の試したサーバ設定は、

  • 常時SSL
  • www にURL正規化
  • http から https にリダイレクト
  • WordPress ツールバーからダッシュボード (www.example.com/wp-admin/) へアクセス
  • WordPressの自動更新ができるように
  • FastCGI のスループットチューニング
  • 他もろもろ

で以下のような本番運用サーバ設定 (/etc/h2o/h2o.conf) になりました。

user: nobody
 
listen:
  port: 80
listen:
  port: 443
  ssl:
    certificate-file: /path/to/fullchain.pem
    key-file: /path/to/privkey.pem
 
hosts:
  "localhost":
    paths:
      "/":
      redirect:
        status: 301
        url: https://www.example.com/
 
  "www.example.com:80":
    paths:
    "/":
      redirect: https://www.example.com/
  "www.example.com:443":
    paths:
      "/":
        file.dir: /var/www/wordpress
        redirect:
          url: /index.php/
          internal: YES
          status: 307
 
file.index: [ 'index.php', 'index.html' ]
 
file.custom-handler:
  extension: .php
  fastcgi.spawn:
    command: "PHP_FCGI_CHILDREN=10 exec /usr/bin/php-cgi"
    user: example
  fastcgi.timeout.keepalive: 10000
 
access-log: "| exec sudo rotatelogs /var/log/h2o/access.log.%Y%m%d 86400"
error-log:  "| exec sudo rotatelogs /var/log/h2o/error.log.%Y%m%d 86400"
 
pid-file: /var/run/h2o/h2o.pid
http1-upgrade-to-http2: ON
http2-reprioritize-blocking-assets: ON

WordPressを動かすH2Oサーバ設定のポイント

WordPress ツールバーからダッシュボード (www.example.com/wp-admin/) へアクセス

通常の設定では、WordPress ツールバーからダッシュボード (www.example.com/wp-admin/) へアクセスは、トップページを返してしまいます。

ダッシュボードにアクセスできるように file.index で index.php を追加して www.example.com/wp-admin/ で www.example.com/wp-admin/index.php にアクセスするようにしました。

WordPressの自動更新ができるように

H2O はデフォルトで nobody の下で動きます。 H2Oの管理下にある PHP も nobody で動きます。 WordPressの自動更新は、WordPressのファイル所有者の下でPHPが動かないと自動更新が働きません。 fastcgi.spawn には、どのユーザ user で動かすか指定できるので、WordPressのファイル所有者を指定して動かします。

FastCGI のスループットチューニング

fastcgi.spawn での PHP への接続は、デフォルトでは1回限りの接続です。これだとWordPressが動くたびにコネクションが発生します。 fastcgi.timeout.keepalive で Keep-Aliveを 10 秒に指定。一定時間 FastCGI の接続を継続させてスループットを改善してみました。

まだまだキャッシュ周りやいろいろチューニングができそうなので、運営しつつ試してみたいと思います。

参考サイト

sudo「コマンドが見つかりません」PATHが初期化されているときの対処法

sudo でコマンドを実行すると、「command not found」とエラーに。環境変数 PATH が通っていないと思って設定しても変わらず。実は sudoers の設定でセキュリティ上環境変数が初期化されている。そのときの対処備忘メモ。

現象

  1. sudo でコマンドを実行
  2. 「command not found」 (コマンドが見つかりません) とエラーに
  3. .bash_profile にパスを設定してみる
    vi ~/.bash_profile
    
    PATH=$PATH:$HOME/bin:/sbin:/usr/sbin
    

    から

    PATH=$PATH:$HOME/bin:/sbin:/usr/sbin:/usr/local/bin
    

    に変更。

  4. sudo でコマンドを実行
  5. 再び「command not found」 (コマンドが見つかりません) とエラーでパスが通っていない

さらに突き詰めると、

sudoers の env_reset オプションが有効になっている

原因

sudoers の env_reset オプションが有効になっている場合、セキュリティ上環境変数が初期化されて secure_path に設定しているパスが使われるので、環境変数 PATH が通らない。

解決

3つの方法でパスを通す

sudoers はデフォルトでは env_reset オプションが有効になっている。無効化するか、環境変数を引き継ぐか、または secure_path にパスを設定することで環境変数 PATH を通す。

sudoers は visudo コマンドで編集できる。設定が間違っていたらエラーチェックもしてくれるので、直接ファイルを編集することは控える。

1. 無効化する場合

コメントアウトして env_reset オプションを無効化。

#Defaults env_reset

2. 環境変数を引き継ぐ場合

以下を追記

Defaults env_keep += "PATH"

そして以下をコメントアウト

#Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin

.bash_profile に設定したパスが通ります。

3. パスを設定する場合

Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin

から

Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin

に変更してパスを追加

sudo でコマンドを実行して確認。 complete!!

教訓

環境変数 PATH の設定の他、env_reset が有効化されているかどうかも確認しよう。

関連サイト

「#!/usr/bin/perl –」はFTP転送モードの問題? 実はFTPサーバ設定の問題

Perl のパス 「#!/usr/bin/perl -w」では正常に動くのに、「#!/usr/bin/perl」では「Internal Server Error」に。

cgiスクリプトの記述や設定が正しくなかったり、サーバ内部でエラーが発生した場合に返されるのが「Internal Server Error (HTTPステータスコード500)」。エラーがあるのは分かるが、原因がわからない、Webエンジニアにとって頭を悩ます「Internal Server Error」。

その原因も様々。原因が明らかにできなければ対策も解決もできない。Perl パスの問題かと思いきや、FTPの転送モードの問題?、実はFTP サーバ設定の問題というちょっと複雑。そんな問題に直面した備忘メモ。

現象

  1. FTP を使ってアスキーモードでファイルをアップロード
  2. Perl のパス 「#!/usr/bin/perl」 では cgi が 「Internal Server Error (HTTPステータスコード500)」に
  3. Perl のパス 「#!/usr/bin/perl -w」 または 「#!/usr/bin/perl --」 では正常に動作する
  4. 改行コードが問題と思ってファイルの改行コードを「LF」に変換
  5. 再度、FTP を使ってアスキーモードでファイルをアップロードしても同じ現象に
  6. 「あれれ」無限ループにはまる。

さらに突き詰めると、

シェル上でスクリプトを走らせると、

/usr/bin/perl^M: bad interpreter: No such file or directory

とエラーに

さらに突き詰めると、

FTP サーバに vsftpd を使っている

原因

FTP サーバ vsftpd では、ファイルの改行コードが変換されないこと。

解決

改行コードを「LF」に変換するだけという、単純なものではありません。

実際は、ファイルをアスキーモードでFTPアップロードしても、改行コード「LF」に変換されません。

それは、FTP サーバ vsftpd ではアスキーモードでのダウンロード・アップロードのデフォルト設定が無効になっているから。

ということで vsftpd の設定をしてみる。

1. vsftpd の設定をする

シェル上で vsftpd.conf を編集。

vi /etc/vsftpd/vsftpd.conf

設定内容を

ascii_download_enable=NO
ascii_upload_enable=NO

から

ascii_download_enable=YES
ascii_upload_enable=YES

に変更して有効に

2. vsftpdを再起動

service vsftpd restart

3. ファイルを再度アップロードする

4. 確認。Perl のパス「#!/usr/bin/perl」でうまく表示できた。

complete!!

教訓

FTPの転送間違えの他、視野を広げてFTP サーバの設定も診てみよう。

関連サイト

専用サーバ運営では必須の不正アクセス対策 SSHのポート番号変更

サーバを運営していると、SSH経由でユーザ名とパスワートの総当たりで不正な接続を試みる攻撃 (ブルートフォースアタック) を受けることが多い。ログ監視ツール Logwatch から毎日送られてくるレポートでも多数確認できる。root には数千件の数で試みられているのが見受けられることも。

対策は、ssh のポート番号を変更すること。デフォルトのポート番号 22 での接続を避ける。

デフォルトのポート番号 22 から別の番号に変更することで断続的な不正アクセスを無くして、サーバの負荷軽減にもなる。

ということで、sshのポート番号を変更。

設定ファイルを編集。

$ vi /etc/ssh/sshd_config

デフォルトではコメントアウトでポート番号 22 が使われているので、任意のポート番号 **** に変更。ポート番号は、使用されていない 0~1023 (ウェルノウンポート) 以外のポート番号に変更しましょう。

#Port 22
Port ****

SSHを再起動。

$ /etc/init.d/sshd restart

iptablesの設定

iptables でファイアウォールの設定をしている場合、変更したポートを通す必要があります。設定せずに ssh の接続を切ってしまうと、ssh に接続できなくなるので要注意。

$ vi /etc/sysconfig/iptables
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

から

-A INPUT -p tcp -m tcp --dport 任意のポート番号 -j ACCEPT

に変更。

iptablesを再起動して、設定を再読み込み。

$ /etc/rc.d/init.d/iptables restart
iptables: Setting chains to policy ACCEPT: filter [  OK  ]
iptables: Flushing firewall rules: [  OK  ]
iptables: Unloading modules: [  OK  ]
iptables: Applying firewall rules: [  OK  ]

接続確認

接続確認は、念のため元のターミナルでの接続を保ちつつ、新規ウインドウでターミナルを立ち上げて接続を確認することをおすすめします。

まずはポート番号 22 で接続。

$ ssh ユーザID@ホスト名
$ ssh: connect to host **.**.**.** port 22: Connection refused

ポート番号 22 では接続が拒否される。

変更したポート番号で接続。

$ ssh -p ポート番号 ユーザID@ホスト名

接続できれば完了。