2018年1月16日火曜日

Windows Server 2012以降で.Net Framework 3.5をインストールする方法 (代替ソースパスの設定)

Windows Server 2012以降のOSでは、「サーバーマネージャー」の「役割と機能の追加」にて、.Net Framework 3.5を単純にインストールしようとすると失敗する。


この場合、「代替ソースパス」を指定することで解消するが、代替ソースパスを知らないと、どこを指定してよいものかわからないので、本手順にて代替ソースパスの設定手順について記載する。

手順

1. 予め、Windows Serverのインストールメディアをマウントしておく。今回はDドライブにマウントした想定で手順を記載する。

2. 「サーバーマネージャー」の「役割と機能の追加」を開き、「機能」の項目にて、「.Net Framework 3.5 Features」にチェックを付ける。


3. 確認画面で、「代替ソースパスを指定する必要がありますか?」という警告が表示されることを確認する。


4. ダイアログボックス下部の「代替ソースパスの指定」の文字をクリックする。


5. 代替ソースパスの指定にて、以下を指定する。今回はDドライブにWindows Serverのインストールメディアがマウントされている想定なので、環境に合わせてドライブレターは変更すること。また、この指定パスは、Windows Server 2012以降のインストールメディアで、すべて共通となっている。

 D:\sources\sxs


6. 「インストール」ボタンを押してしばらくすると、インストールが正常に完了するはずである。



2018年1月11日木曜日

Windows Server 2016で定期的にログイン失敗 (イベントID 4625)が発生する問題

Windows Server 2016の評価版をインストールし使い始めたのだが、ログイン失敗(イベントID 4625)が1日に1、2回程度の間隔で定期的に発生するということがわかった。

この事象には、以下記事で述べたログイン失敗検知をZabbixで実装しているため気付くことができた。

・Zabbixを使ってWindowsとLinuxのログイン失敗を監視する
https://tech-mmmm.blogspot.jp/2017/06/zabbixwindowslinux.html

特にログイン失敗を監視していないような環境では特に気にしなくてもよいかもしれないが、発生条件と対策について調べてみた。しかし、本件に関する対策は、2018年1月時点では存在しないようである。本記事では、本事象の発生条件と、実施した対策について記載する。

事象

以下がイベントログ セキュリティの失敗の監査のメッセージとして表示される。セキュリティIDが「NULL SID」でログオンプロセスが「Advapi」となっており、通常ユーザーのログイン失敗ではないと想定される。

------------------------------
ログの名前:         Security
ソース:           Microsoft-Windows-Security-Auditing
日付:            2018/01/06 7:48:39
イベント ID:       4625
タスクのカテゴリ:      ログオン
レベル:           情報
キーワード:         失敗の監査
ユーザー:          N/A
コンピューター:       t1082w216.intrat.local
説明:
アカウントがログオンに失敗しました。

サブジェクト:
セキュリティ ID: SYSTEM
アカウント名: T1082W216$
アカウント ドメイン: INTRAT
ログオン ID: 0x3E7

ログオン タイプ: 5

ログオンを失敗したアカウント:
セキュリティ ID: NULL SID
アカウント名: -
アカウント ドメイン: -

エラー情報:
失敗の原因: ログオン中にエラーが発生しました。
状態: 0xC0000073
サブ ステータス: 0xC0000073

プロセス情報:
呼び出し側プロセス ID: 0x138
呼び出し側プロセス名: C:\Windows\System32\svchost.exe

ネットワーク情報:
ワークステーション名: -
ソース ネットワーク アドレス: -
ソース ポート: -

詳細な認証情報:
ログオン プロセス: Advapi  
認証パッケージ: Negotiate
移行されたサービス: -
パッケージ名 (NTLM のみ): -
キーの長さ: 0

~(以下略)~
------------------------------

発生条件

以下URLに同様の事象について記載されていた。

・KB3213986 Causes Logon Failures When Starting BITS Service - Please fix
https://windowsserver.uservoice.com/forums/304618-installation-and-patching/suggestions/18475483-kb3213986-causes-logon-failures-when-starting-bits

発生条件は、以下2つであることが記載されている。
  1. KB3213986がインストールされている
  2. BITS (Background Intelligent Transfer Service)が起動時
実際にイベントログを見ると、BITS起動のログとログイン失敗のタイミングは、秒数まで含めて、同一タイミングとなっていた。



また、先ほど記載したURLでは、この問題を修正するようMicrosoftに提言する内容となっているが、コメント欄を見る限りでは、残念ながら修正したという内容は記載されていない。

実施した対策 (効果なし)

①パッチのアンインストールを試みる

原因となっているOSパッチ「KB321396」は、Windows Server 2016に最初からインストールされており、アンインストールも不可となっていた。
※アンインストール可能な場合は、以下画面の「整理」の欄に「アンインストール」が表示される。


②OSパッチを最新化する

Windows Updateを行い、OSパッチを最新化してみたが、事象は改善しなかった。

③BITSを停止させる

BITSを停止することで解消するか確認してみた。「サービス」を開き、「Background Intelligent Transfer Service」を確認すると、「スタートアップの種類」が「手動」になっているはず。こちらを「無効」変更した。


しかし、無効にしてもOSが定期的に手動に変更してしまうようで、BITSを停止しても事象は改善しなかった。

上記3点の対応を実施しても事象は改善しないことがわかった。特に影響はなさそうな事象ではあるので、監視で検知しないよう監視マネージャー側で抑止するしかなさそうだ。

2018年1月4日木曜日

squid入門

プロキシサーバーといえばデファクトスタンダードともいえるsquid。このsquidの基本的な設定について記載する。

プロキシサーバーとして動作する設定ではあるが、本記事の内容だけでは、パフォーマンス面やセキュリティ面において考慮不足となる事項が多数ある点に注意すること。

squidのバージョン

今回設定したsquidのバージョンは以下の通り。
# squid -v
------------------------------
Squid Cache: Version 3.5.20
------------------------------

squid.conf

squidの設定ファイルである、/etc/squid/squid.confファイルをコメント付きで以下に記載する。細かな説明は後述する。

# cat /etc/squid/squid.conf
------------------------------
# 接続クライアントのネットワークを指定
acl localnet src 192.168.33.0/24
acl localnet src 192.168.11.0/24

# 許可するポートを指定
acl SSL_ports port 443
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
acl Safe_ports port 70          # gopher
acl Safe_ports port 210         # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280         # http-mgmt
acl Safe_ports port 488         # gss-http
acl Safe_ports port 591         # filemaker
acl Safe_ports port 777         # multiling http
acl CONNECT method CONNECT

/etc/squid/blacklistファイルに拒否するドメインを記載
acl blacklist dstdomain "/etc/squid/blacklist"

http_access deny blacklist

http_access deny !Safe_ports    # Safe_portsで指定したポート以外を拒否
http_access deny CONNECT !SSL_ports # SSL_portsで指定したポート以外を拒否

# キャッシュマネージャーへのアクセスはlocalhostのみ許可
http_access allow localhost manager
http_access deny manager

# 接続クライアントの許可設定
http_access allow localnet      # localnetで指定したネットワークを許可
http_access allow localhost     # localhostを許可
http_access deny all            # すべてを拒否

# 待ち受けポートを8080に指定
http_port 8080

# キャッシュの設定
cache_mem 256 MB
cache_dir ufs /var/spool/squid 200 16 256

# coredump出力先を設定
coredump_dir /var/spool/squid

#キャッシュ更新間隔の設定
refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern ^gopher:        1440    0%      1440
refresh_pattern -i (/cgi-bin/|\?) 0     0%      0
refresh_pattern .               0       20%     4320

# エラーページにバージョンを表示させない
httpd_suppress_version_string on
------------------------------

squid.confの説明

acl

その名の通りACL (Access Control List)を設定する。ここで作成したACLをhttp_access文で指定し、アクセス制御を行う。

今回は以下を設定している。
  • localnet:squidを利用するクライアントのネットワークアドレス
  • SSL_ports:httpsで利用するポート
  • Safe_ports:httpで利用するポート
  • CONNECT:httpsで利用するメソッド
  • blacklist:アクセスを拒否するドメインを指定する。/etc/squid/blacklistファイルにテキストで羅列する

http_access

実際のアクセス制御を設定する。今回は以下を設定している。
  1. blacklistに記載されたドメインへのアクセスは拒否
  2. Safe_ports以外のポートを利用したアクセス要求は拒否
  3. SSL_ports以外のポートでCONNECTメソッドを利用するアクセス要求は拒否
  4. キャッシュマネージャー(※)へのアクセスはlocalhostのみ許可
  5. squidへのアクセスはlocalnetとlocalhostのみ許可
  6. 上記に該当しない通信はすべて拒否
※キャッシュマネージャー:squidの統計情報を表示するCGIユーティリティ

http_accessは上から順番に評価されていくので、複雑な設定をする際は評価順を考慮すること。

http_port

squidが待ち受けるポート番号を指定する。今回は8080で設定。

cache_mem / cache_dir

cache_memはキャッシュとして使用するメモリ量を指定する(デフォルト256MB)。

cache_dirは、キャッシュとして使用するディスク量を指定する。cache_dir文において、「ufs」を指定しているが、ufsとはsquidで使用されるファイルフォーマットとなる。ufsを指定した際の構文は以下の通りとなる。

cache_dir ufs Directory-Name Mbytes L1 L2

Mbytesは確保するファイル容量となる。L1、L2はキャッシュディレクトリに作成するディレクトリの分割数を示す。L1=16、L2=256がデフォルトであり、特に変更する必要はないだろう。

なお、squidのキャッシュディレクトリを作成する際は、以下コマンドを実行する。

# squid -z

coredump_dir

coredumpを出力する際のディレクトリを指定する。

refresh_pattern

キャッシュの更新期間に関する設定を行う。構文は以下の通り。

refresh_pattern [-i] regex min percent max [options]

今回、squid.confでは以下の通り設定している。

------------------------------
#キャッシュ更新間隔の設定
refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern ^gopher:        1440    0%      1440
refresh_pattern -i (/cgi-bin/|\?) 0     0%      0
refresh_pattern .               0       20%     4320
------------------------------

例えば、ftpサイトのキャッシュは、最低1440分(1日)保持、最大10080分(7日)保持される。1日~7日の間は、対象ファイルの「鮮度」を計算して、キャッシュ要否を判断する。鮮度の計算は以下となり、この計算結果が20%を下回った場合はデータはまだ新しいものと判断し、キャッシュされたデータを読み込む動作をする。

 鮮度 = キャッシュ経過時間 / 対象ファイルの作成日からの経過時間

httpd_suppress_version_string

squidのエラーページのフッターにsquidのバージョン表示をさせない設定となる。一般的に使用しているソフトウェアのバージョン情報は利用者に開示しないことがセオリーとなるので、設定しておいた方がよいだろう。

【変更前】
------------------------------
Fri, 29 Dec 2017 12:45:04 GMTにt3023ce72 (squid)が生成しました。
------------------------------



【変更後】
------------------------------
Fri, 29 Dec 2017 12:47:20 GMTにt3023ce72 (squid/3.5.20)が生成しました。
------------------------------


設定の反映方法

以下コマンドでsquidをreloadすればよい。

# systemctl reload squid

参考

・Squid configuration directive cache_dir
http://www.squid-cache.org/Doc/config/cache_dir/

・Squid configuration directive cache_mem
http://www.squid-cache.org/Doc/config/cache_mem/

・Squid configuration directive refresh_pattern
http://www.squid-cache.org/Doc/config/refresh_pattern/


2017年12月18日月曜日

プロセス監視スクリプト (Windows版)

前回、Linux版のプロセス監視スクリプトを作ったので、同じ仕組みでWindows版を作ってみた。

★Linux版はこちら↓

・プロセス監視スクリプト (Linux版)
https://tech-mmmm.blogspot.jp/2017/12/linux.html

実現方法

本スクリプトの設計概要を図示する。Linux版のスクリプトをもとにPowerShellで書き直しただけなので、作りは基本的に同一となっている。


エラーメッセージについてはテキストログではなく、Windowsイベントログ (アプリケーション)に出力をさせるようにする。イベントログにメッセージを出力させる際に、メッセージソースの登録が必要となるため、事前に管理者権限でPowerShellのプロンプトを開き、以下コマンドを実行しておくこと。

PS > New-EventLog -LogName Application -Source "Process Check Script"

スクリプト

以下にスクリプトのコードを記載する。GitHubにも置いてみた。

https://github.com/TetsuOkamoto/check-process-windows

・スクリプトファイル名:check-process.ps1
・設定ファイル名:check-process.conf

タスクスケジューラーへの登録

タスクスケジューラーにて本スクリプトを1分間隔で実行するように設定する。こちらの方法については、以下別記事を参照。

・タスクスケジューラーを使って1分間隔で実行するタスクを作成する方法
https://tech-mmmm.blogspot.jp/2017/12/1.html

Zabbixを使った監視テスト結果

Zabbixでは、Windowsイベントログ (アプリケーション)に「エラー」のイベントが出力された際に通知するようトリガーを設定すればよい。

実際に監視対象のプロセスを停止した際に、以下のように、プロセスダウンを検知することができた。

------------------------------
2017.12.17 08:23:20

Trigger: Eventlog Application
Trigger status: PROBLEM
Trigger severity: Average
Trigger URL:

Item values:

1. Eventlog Application (t1081w12r:eventlog[Application,,"Error",,,,skip]): Process "WinShot" down
2. *UNKNOWN* (*UNKNOWN*:*UNKNOWN*): *UNKNOWN*
3. *UNKNOWN* (*UNKNOWN*:*UNKNOWN*): *UNKNOWN*

Original event ID: 3607
------------------------------

2017年12月16日土曜日

プロセス監視スクリプト (Linux版)

サーバーのプロセス監視は、監視ソフトウェア(ZabbixやJP1など)を使えば当たり前のように実現できるが、ふと、スクリプトでも簡単に実装できるのでは?ということを思ったので、スクリプトを作成してみた。

実現方法

本スクリプトの設計概要を図示する。


このスクリプトは、psコマンドにて監視対象のプロセス数を取得し、設定ファイル(check-process.conf)に記載されたプロセス数との比較を行う。

プロセスダウンを検知した際は、/var/log/messagesにエラーメッセージを出力し、Zabbixのログ監視で検知させることにする。エラーメッセージ出力タイミングは、プロセスダウンの初回発生時のみとした。これにより、1分毎にエラー検知することを防止する。

以下に、本スクリプトで発生するメッセージを記載する。

 ・プロセス初回ダウン時 → [ERROR] Process XXX down
 ・プロセス継続ダウン時 → [INFO] Process XXX still down
 ・プロセス回復時    → [INFO] Process XXX up

この処理をcronで1分間隔で実行するよう登録し、定期的なプロセス監視を実現する。

スクリプト

以下にスクリプトのコードを記載する。

なお、本スクリプトはGitHubにも配置してみた(GitHub初心者なので、ただアップロードしただけ)。

https://github.com/TetsuOkamoto/check-process-linux

・スクリプトファイル名:check-process.sh

・設定ファイル名:check-process.conf

cronへの登録

スクリプトを/root/scriptディレクトリに配置した場合を例とする。この場合、cronには以下の通り設定を追加する。

# crontab -e
------------------------------
*/1 * * * * /root/script/check-process.sh
------------------------------

Zabbixを使った監視テスト結果

実際に本スクリプトを使って監視テストを実施してみた。Zabbixにて/var/log/messagesに「ERROR」の文字列あった場合に検知するトリガーを設定し、意図的にchronyd (時刻同期デーモン)を停止してみた。

問題なく設定できていれば、以下のようなプロセスダウンのメッセージ通知がされるようになる。

------------------------------
Trigger: messages
Trigger status: PROBLEM
Trigger severity: Average
Trigger URL:

Item values:

1. messages (t3023ce72:log[/var/log/messages,"@messages word",,,skip]): Dec 14 22:23:01 t3023ce72 root: [ERROR] Process "/usr/sbin/chronyd" down
2. *UNKNOWN* (*UNKNOWN*:*UNKNOWN*): *UNKNOWN*
3. *UNKNOWN* (*UNKNOWN*:*UNKNOWN*): *UNKNOWN*

Original event ID: 3579

------------------------------

2017年12月11日月曜日

タスクスケジューラーを使って1分間隔で実行するタスクを作成する方法

とあるPowerShellのスクリプトを1分間隔で実行したかったので、タスクスケジューラーで繰り返し実行のタスクを作ることにした。しかし、「トリガー」タブの「繰り返し間隔」の選択項目を見ると、5分間より短い間隔の指定ができないように見える。


Linuxのcronであれば簡単に設定できることが、タスクスケジューラーではできないのかと困っていたのだが、実はこの「繰り返し間隔」は直接入力が可能である。

というわけで、試しに「5 分間」→「1 分間」に編集して保存してみる。


「詳細」欄を確認すると、「00:01:00 ごとに繰り返し」となっている。


実際にタスクを作成して、「次回の実行時刻」を確認すると、1分後が指定されていることが確認できた。


ちなみに、1分以下を指定できるか確認したところ、「繰り返し間隔は、1 分以上 31 日以下の値を指定する必要があります」というエラーメッセージではじかれた。Windowsのタスクスケジューラーの最少実行間隔は、1分のようだ。



2017年12月9日土曜日

rsyslog + logrotateでログ保管サーバーを構築する

ネットワーク機器などの障害調査を目的として、Syslogでログ転送を行いログを保管しておくという設計はよくある話ではある。有名な製品としては、Spulnk社のSplunk、インフォサイエンス社のLogstorage、OSSではGraylogやLogtashなど多数のソフトウェアが存在している。

とはいえ小規模な環境で有償のソフトウェアを導入することは、費用面や構築負荷といった面で割に合わないこともあるため、とりあえずログを保管するだけで詳細な分析は不要であれば、OSの標準機能で実装してしまう方が手っ取り早い。

今回はLinuxの標準機能であるrsyslogとlogrotateを組み合わせて、ログ保管サーバーの構築を行う。

環境

今回は仮想スイッチVyOSのログをSyslogにて受信し、5日分のログを保管できるように設定することにする。


参考までに、VyOSのSyslog設定を以下に記載する。

# show system syslog
------------------------------
 global {
     facility all {
         level notice
     }
     facility protocols {
         level debug
     }
 }
 host 192.168.33.22 {
     facility all {
         level debug
     }
 }
------------------------------

rsyslogの設定

UDP/514ポートを使ったSyslog受信設定を行ったうえで、送信元のIPアドレスをもとに出力ファイルを指定する。

設定は以下の通りとなる。

# cat /etc/rsyslog.conf | grep -v -e "^#" -e "^$"
------------------------------
$ModLoad imuxsock # provides support for local system logging (e.g. via logger command)
$ModLoad imklog   # provides kernel logging support (previously done by rklogd)
$ModLoad imudp     ←UDPによるSyslogメッセージ入力を許可
$UDPServerRun 514   ←UDPの待ち受けポートを514に設定
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
$IncludeConfig /etc/rsyslog.d/*.conf
:fromhost-ip, isequal, "192.168.33.31" -/var/log/t3031vy11.log
& ~
↑送信元IPアドレスに対して、出力先のログを指定。"& ~"を付けることで、直前の条件に一致したログを破棄する
*.info;mail.none;authpriv.none;cron.none                /var/log/messages
authpriv.*                                              /var/log/secure
mail.*                                                  -/var/log/maillog
cron.*                                                  /var/log/cron
*.emerg                                                 *
uucp,news.crit                                          /var/log/spooler
local7.*
------------------------------

:fromhost-ipの行はプロパティベースのフィルターと呼ばれる。構文は以下の通りとなる。

:PROPERTY, [!]COMPARE_OPERATION, "STRING" LOGFILE

左から順に見ていこう。

①PROPERTY

今回はIPアドレスでフィルターするため、「fromhost-ip」で指定する。利用できるPROPERTYの値は以下を参照。

・rsyslog Properties
http://www.rsyslog.com/doc/master/configuration/properties.html

②[!]COMPARE_OPERATION, "STRING"

今回はIPアドレスで「一致」を条件とするため、「isequal, "192.168.33.31"」とする。isequalの前に!を付ければ否定となり「一致しないこと」が条件となる。その他比較処理については、以下表を参照すること。

  • contains:テキストを含む。大文字小文字を区別する
  • contains_i:テキストを含む。大文字小文字を区別しない
  • isequal:テキストと一致
  • regex: POSIX BRE (Basic Regular Expression)による比較
  • ereregex: POSIX ERE (Extended Regular Expression) 正規表現による比較
  • isempty:空かどうかを比較 (この際の”STRING"の記載方法が不明)

③LOGFILE

出力先のログファイルを指定する。ログファイル名の前に「-」を指定すると書き込みが非同期で行われ、パフォーマンスが向上するが、サーバー停止時に一部ログの欠損が発生する可能性がある。

logrotateの設定

以下の内容でファイルを新規作成する。今回は日次5世代のローテーション設定を行う。

# cat /etc/logrotate.d/remotelog
------------------------------
/var/log/t3031vy11.log {
    missingok      ←ログファイルが存在しない場合でもエラーとしない
    notifempty     ←ログファイルが空ならローテーションしない
    daily        ←日次で実行
    compress      ←圧縮。デフォルトではgzを圧縮コマンドとして利用
    rotate 5      ←5世代の過去ファイルを保管
    postrotate     ←ローテーション後コマンド(次行~endscriptまで)を実行
        /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
    endscript      ←コマンドの終わり
}
------------------------------

このファイルの作成ディレクトリである/etc/logrotate.dは、/etc/logrotate.confでインクルードされているため、ファイルを置くだけで設定を反映することができる。

なお、logrotateはただのコマンドとして提供されており、サービス化されていない。そのため、設定反映の際に、サービス再起動や設定ファイルの再読み込み作業は不要となる。

設定確認コマンドは以下の通りとなる。

# logrotate -d /etc/logrotate.conf
------------------------------
reading config file /etc/logrotate.conf
including /etc/logrotate.d
reading config file ConsoleKit
reading config info for /var/log/ConsoleKit/history

~(中略)~

reading config info for /var/log/t3031vy11.log

~(中略)~

rotating pattern: /var/log/t3031vy11.log  after 1 days (5 rotations)
empty log files are not rotated, old logs are removed
considering log /var/log/t3031vy11.log
  log does not need rotating
not running postrotate script, since no logs were rotated

~(以下略)~
------------------------------

logrotateの実行時間について

ここでlogrotateの実行時間についても記載しておく。logrotateはanacronで制御されており、日次、週次、月次の実行処理があらかじめ設定されている。

実際にanacronの実行制御の設定を見てみる。

# cat /etc/anacrontab
------------------------------
SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
RANDOM_DELAY=45       ←各ジョブのdelay in minutes + 最大45分の遅延
START_HOURS_RANGE=3-22   ←3時-22時の間でジョブを実行(サーバー停止等がなければ3時開始)

#period in days delay in minutes job-identifier command
1       5       cron.daily       nice run-parts /etc/cron.daily  ←日次処理
7       25      cron.weekly      nice run-parts /etc/cron.weekly  ←週次処理
@monthly 45     cron.monthly     nice run-parts /etc/cron.monthly  ←月次処理
------------------------------

上記より、日次処理の場合、3:05~3:50の間でlogrotateが実行されることがわかる。

次に、日次処理の設定ファイルが配置されている/etc/cron.dailyディレクトリ内のlogrotateファイルの設定を確認する。logrotateコマンドを実行し、終了コードが0以外の際にloggerコマンドでエラーを吐くという、シンプルなスクリプトとなっている。

# cat /etc/cron.daily/logrotate
------------------------------
#!/bin/sh

/usr/sbin/logrotate /etc/logrotate.conf   ←logrotateコマンドを実行
EXITVALUE=$?
if [ $EXITVALUE != 0 ]; then
    /usr/bin/logger -t logrotate "ALERT exited abnormally with [$EXITVALUE]"
fi
exit 0
------------------------------

実際に作成されたログファイルを確認してみると、3:05~3:50の間でgz形式で圧縮されたファイルが5つ生成されていることがわかる。

# cd /var/log/
# ls -l t3031vy11.log*
------------------------------
-rw------- 1 root root 1233016 12月  4 10:06 2017 t3031vy11.log
-rw------- 1 root root  305117 11月 30 03:48 2017 t3031vy11.log-20171130.gz
-rw------- 1 root root  229191 12月  1 03:44 2017 t3031vy11.log-20171201.gz
-rw------- 1 root root  262123 12月  2 03:29 2017 t3031vy11.log-20171202.gz
-rw------- 1 root root  373297 12月  3 03:49 2017 t3031vy11.log-20171203.gz
-rw------- 1 root root  294881 12月  4 03:25 2017 t3031vy11.log-20171204.gz
------------------------------

参考

・rsyslog
http://www.rsyslog.com/

・20.2. RSYSLOG の基本設定
https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/system_administrators_guide/s1-basic_configuration_of_rsyslog

・第21章 システムタスクの自動化
https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/6/html/deployment_guide/ch-automating_system_tasks