adsperpage

Libre/Open Office

2016年8月22日月曜日

【Windows 7 pro sp1 64bit】ディスククリーンアップと時間のとてもかかるシステム再起動

Windows 7 pro sp1 64bit において、長らく使用していたPCのハードディスクの空き容量を調べると、
特にヘビーな使い方をしていないにもかかわらず、なぜか50GBもの容量が消費されていた。


Cドライブにあるフォルダを順にプロパティー表示していき、圧迫しているフォルダを探索していった。
すると、C:¥Windows¥winsxs というフォルダが、21GBもの容量を消費していることがわかった

この winsxs というフォルダについてネットで調べてみると、windowsシステムに関するものであり、
Windows Updateに伴って使用容量が増えるらしいことがわかった。(†1)

むやみに削除するわけにはいかないものだとわかったので、次の方法で空き容量を得ることにした。



★できる限りこのwinsxsフォルダの圧迫を解消しディスクの空き容量を増やす方法

(注意!)
以下の操作によって、次回のWindowsの起動には非常に時間がかかる
これはクリーンアップ処理の続きが再起動後にも行われるためである。
再起動後にようやくディスクの空き容量が増えることにも注意したい。

そのため、時間的も心にも余裕のあるときに試すべきである。
(気が急いてついついリセットボタンなんか押してしまうことになれば、システムが壊れるかもしれないし。)


DOSプロンプトから、次のコマンドを実行し、「ディスククリーンアップ」を起動する。
Cleanmgr.exe

起動後、クリーンアップするドライブを選択するダイアログが表示された。
ここでは、windowsフォルダのあるドライブ(Cドライブ)を選択した。

しばらく待たされたあと、ダイアログが開いた。
Windows Update 関係のデータをクリーンアップできるらしいことがわかった。
21GBのうち、5GBだけ節約することができるらしかったので、ダイアログに従って早速クリーンアップを実行した。

「不要なファイルを整理しています」と表示され、自動的にクリーンアップが行われる。

しかし、このクリーンアップの完了後、ディスクのプロパティーを見てもまだ使用容量に変化がなかった。



〇クリーンアップが完了して実際にディスクの容量が増えるのは、再起動後

Windowsの再起動を試みた。
すると、次にデスクトップが表示されて使用できるようになるまでに非常に時間がかかった。(†3)

私の場合、再起動後にデスクトップが表示されるまで、30分待たされた
こんなにも時間がかかるとは思っていなかったので、ドキドキだった。
リモートで接続していたので、「お待ちください」の文字だけを前にして、気が気でなかった。
もう帰ってこないのではないかと思ったほどだ。
(パソコンの前に居るのなら、処理中のハードディスクの動作を知られるだろうから少しは安心できただろう。)

長いこと待たされて、再びデスクトップがよみがえり、ディスクの容量を確認すると予定されていたとおりに増えていた。(5GB)
winsxsフォルダを確認すると、その分だけ削減されていることがわかった。(21GB→15GB)

やれやれ。



<参考>
(1)Cドライブの容量不足は「WinSxS」フォルダーの肥大化が原因?
< http://www.atmarkit.co.jp/ait/articles/1411/04/news031.html > 2016年8月22日

(2)Windowsの不要ファイルを一気に削除する方法/ディスク クリーンアップの使い方
< http://freesoft.tvbok.com/tips/optimise_vista/disk_cleanup.html > 2016年8月22日

(3)Windows7の不要な更新プログラムを削除したら空き容量が3.39GBも増加
 < http://newsbit.jp/blog/index.php?itemid=142 > 2016年8月22日

2016年8月20日土曜日

【Windows】USB 3.0ポートに接続されたデバイスが高速なSuperSpeedモードで認識されているか確かめる方法

Windowsにおいて、USB 3.0ポートに接続されている機器が「Super Speed」モードで認識されているかどうか調べる方法について


USB 3.0ポートに機器を接続したからといって、
その機器が「Super Speed」モードで認識されていなければ、高速通信できない。
たとえば、USB 3.0に対応しているフラッシュメモリもその本来の能力を発揮できないことになる。
また、LANインターフェイスも同様である。


以下では、高速な「Super Speed」モードと、低速な「High Speedモード」について参照し、
現在の接続機器の接続モードの調べ方について取り上げている。



◇USB 3.0規格とSper Speedモード

USB 3.0では、新たにSSモードと呼ばれる「Super Speed」モードが追加された
このSSモードでは、理論値で最大「5Gbit/sec (625MB/sec)」までの高速通信をサポートしている
( ところで、このモードはUSB 3.1においては、「USB 3.1 Gen 1」と呼ばれている。)


◇USB3.0ポートの下位互換性による低速モードサポート

ところが、USB 3.0ポートに接続している場合でも、旧来のHigh Speedモードで認識されている場合がある
これは、USB 3.0ポートが下位互換を実現しているため、High Speedモードなどを同じ物理接続で利用可能なことと関係している。



■USB 3.0ポートに接続した機器が低速モードで認識されている場合

USB 3.0ポートに接続したUSB型フラッシュメモリなどのUSB 3.0対応デバイスは、
SS (Super Speed)モードで認識されていなければ、高速なデータ通信を行うことはできない。
その場合、書き込みが遅くなる。最大で40MB/sec程度でしか読み書きできない状態になる。

USB 3.0ポートに、USB 3.0対応デバイス(USBフラッシュメモリなど)を接続しているにも関わらず、
データ通信速度が低速だと感じられたときは、実際にSS (Super Speed)モードでデバイスが認識されているかどうか確認した方が良い。(確認方法については下記)

SS (SuperSpeed)モードで認識されていなければ、その対応デバイスを抜き差しすることで再認識させる必要がある。



■USBポートに接続された機器がどの通信モードで接続されているか確認する方法

Windowsでは、下に挙げるソフトウェアを使って接続状況を確認することができた。

USB Device Tree Viewer V3.0.4

USBポートに接続したデバイスの状態を一覧することができる。
Super Speed で接続されている場合は、そのデバイス名の左側に表示されるUSBアイコンに、
「S」マークが記載される。
低速なHigh Speedモードなら、「H」マークが記載される。



<参考>
・Verifying USB connection speed (USB 3 or USB 2?)
< http://superuser.com/questions/478184/verifying-usb-connection-speed-usb-3-or-usb-2 > 2016年8月20日

・USB Device Tree Viewer
< http://www.uwe-sieber.de/usbtreeview_e.html > 2016年8月20日

・USB 3.0
< https://en.wikipedia.org/wiki/USB_3.0 > 2016年8月20日

2016年6月14日火曜日

【Linux CentOS 6.7】ファイルのタイムスタンプを変更する方法

次のようにすると、ファイルのタイムスタンプを任意に書き換えられる。
# touch -a -m -t 201606140001 target
上の例は、targetというファイルについて、
アクセス日時、変更日時を、共に、2016年06月14日 00時01分 に書き換えるコマンドである。


下記、touch --help の引用である。
Mandatory arguments to long options are mandatory for short options too.
  -a                     change only the access time
  -c, --no-create        do not create any files
  -d, --date=STRING      parse STRING and use it instead of current time
  -f                     (ignored)
  -h, --no-dereference   affect each symbolic link instead of any referenced
                         file (useful only on systems that can change the
                         timestamps of a symlink)
  -m                     change only the modification time
  -r, --reference=FILE   use this file's times instead of current time
  -t STAMP               use [[CC]YY]MMDDhhmm[.ss] instead of current time
  --time=WORD            change the specified time:
                           WORD is access, atime, or use: equivalent to -a
                           WORD is modify or mtime: equivalent to -m

<参考>
・ How can I change the date modified/created of a file?
< http://askubuntu.com/questions/62492/how-can-i-change-the-date-modified-created-of-a-file > 2016年6月14日

2016年5月28日土曜日

【Dovecot 2.0.9】【Procmail 3.22】【Postfix 2.6.6】ヴァーチャルユーザ宛メールをprocmailを経由しdovecot-ldaコマンドへ転送しローカルメールボックスに保存する設定【Linux CentOS 6.7】


下記ページでは、Postfixのバーチャルユーザー宛てメールを、
ヴァーチャルトランスポート機能を用いて、dovecot-ldaコマンドへ転送することで、
受信者のローカルメールボックスに保存できるようにした。
http://akira-arets.blogspot.jp/2016/05/postfix-dovecot-lda-instead-of-virtual.html


ここでは、これをさらに改造し、
ヴァーチャルトランスポート機能を用いて、
いったんprocmailを経由して、そこから同様にdovecot-ldaコマンドへ転送する方法について記載している

procmailの詳しい設定は扱っていないが、procmailを用いることによって、
たとえば、受信メールをdovecot-ldaへ転送する前に、何か処理を加えることが可能になる。
これによって、受信メールの複製を別の所へ転送したり、
迷惑メールを予め処理したりすることも可能になる。


[root@test postfix]# vim /etc/postfix/master.cf
(略)
procmail  unix  -       n       n       -       -       pipe
  flags=DRhu user=vmail:vmail argv=/usr/bin/procmail -t -m SENDER=${sender} RECIPIENT=${recipient} /etc/procmailrc.dovecot-lda
(略)

[root@test etc]# vim /etc/procmailrc.dovecot-lda

SHELL=/bin/bash
PATH=/usr/sbin:/usr/bin
#MAILBASEDIR=/home/VMAIL/DOMAIN
#DEFAULT=$MAILBASEDIR/postmaster
LOGFILE=/home/VMAIL/LOG/procmail.dovecot-lda.log
LOG=""
VERBOSE=yes

# Pass to dovecot-lda
:0
| /usr/libexec/dovecot/dovecot-lda -f $SENDER -d $RECIPIENT

[root@test etc]# mkdir -p /home/VMAIL/LOG/
[root@test etc]# touch /home/VMAIL/LOG/procmail.dovecot-lda.log
[root@test etc]# chown vmail.vmail /home/VMAIL/LOG/procmail.dovecot-lda.log

[root@test postfix]# vim /etc/postfix/main.cf
(略)
#virtual_transport = dovecot
virtual_transport = procmail
dovecot_destination_recipient_limit = 1
procmail_destination_recipient_limit = 1
(略)


■ Postfixを再起動した

[root@test postfix]# service postfix restart
Shutting down postfix:                                     [  OK  ]
Starting postfix:                                          [  OK  ]

Postfixが受信したヴァーチャルユーザー宛てのメールが、
procmailを経て、dovecot-ldaに転送され、メールボックスに保存されるようになった。



2016年5月9日月曜日

【Dovecot 2.0.9】【Postfix 2.6.6】Postfixのvirtualプロセスの代わりにdovecot-ldaを用いてメールボックスに保存する設定【Linux CentOS 6.7】

□使用環境について

# uname -a
Linux test.localdomain 2.6.32-573.12.1.el6.x86_64 #1 SMP Tue Dec 15 21:19:08 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

また、各ソフトウェアのバージョンは次の通り。

Name        : postfix
Arch        : x86_64
Epoch       : 2
Version     : 2.6.6
Release     : 6.el6_7.1


Name        : dovecot
Arch        : x86_64
Epoch       : 1
Version     : 2.0.9
Release     : 19.el6_7.2


□Postfixのvirtualプロセスとの対比し、dovecot-ldaを概観する

通常、Postfixにおいてバーチャルユーザー宛てのメールは、
virtualプロセスによってメールボックスに保存される。

virtualプロセスを利用するためには、例えば次のようにして、
Postfixの設定ファイルで、メールボックスと受信メールの関連などについて指定する必要があった。

< /etc/postfix/main.cf >
virtual_alias_maps = hash:/etc/postfix/virtual
virtual_gid_maps = static:5000
virtual_mailbox_base = /home/VMAIL
virtual_mailbox_domains = example.com
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_minimum_uid = 5000
virtual_uid_maps = static:5000
virtual_transport = virtual

< /etc/postfix/vmailbox >
virtualuser1@example.com example.com/test1/
virtualuser2@example.com example.com/test2/
virtualuser0@example.com example.com/test0/

virtualプロセスを使用した際には、maillogには、次の様に記載される。
確かに、virtualプロセスに処理が任されていることがわかる。
May  1 03:48:01 test postfix/virtual[1789]: 895AB9F881: to=<test@example.com>, relay=virtual, delay=0.12, delays=0.08/0.02/0/0.01, dsn=2.0.0, status=sent (delivered to maildir)


このvirtualプロセスを使用しない方法もある。
代わりにdovecot-ldaコマンドによってメールボックスに保存することができる

dovecotを使ってIMAPサーバなどを構築していて、
ここに「メールアドレスとメールボックスの関連づけ」設定が既にあれば、Postfixもこれを利用できる。
受信メールの対応するメールボックスへの保存をdovecotに任せるわけだ。

例えば、次のページのようにして、dovecotでIMAPサーバを構築できる。
http://akira-arets.blogspot.jp/2016/01/dovecot-basic-imap-setting.html
このような環境がある場合、Postfixはdovecot-ldaコマンドを使うことで、
受信メールのメールボックスへの保存もdovecotに任せられる。
dovecotは「メールアドレスとメールボックスの関連付け」を利用して受信メールを保存する。

こうすると、Postfix側では「メールアドレスとメールボックスの関連付け」を管理する必要がなく、
dovecot側に一元化できるメリットがある。
また、Postfix側でvirtualプロセスのための多数の設定(main.cf)を行わなくて済むことにもなる。

さらに、この方法でメールボックスに保存することは、
dovecotのキャッシュファイルが更新されるなどのメリットもある。
IMAPクライアントはdovecotに接続するとき、メール一覧を取得する。
このときキャッシュがなければメールヘッダが読み取られるので時間を要する。
しかしdovecot側にキャッシュがあれば、これが早くなる。



□dovecot-ldaを用いて受信メールをメールボックスに保存するための設定について

既に、次のページのようにしてDovecotでIMAPサーバの構築ができているものとする
http://akira-arets.blogspot.jp/2016/01/dovecot-basic-imap-setting.html

また、次のページのようにしてPostfixでvirtualユーザーの受信メールを取り扱えるようにしているものとする。
http://akira-arets.blogspot.jp/2016/01/fetchmail-postfix-virtualmailbox.html

そして以下では、Postfixがvirtualドメイン宛てメールのメールボックスへの保存を、
Dovecotに任せるために必要な追加的設定について、Dovecot側とPostfix側とに分けて記述している。



◆ Dovecot側の設定 ◆


■Dovecotが受信メールを保存できなかった場合に送信元に通知するための設定を行った。

[root@test conf.d]# vim /etc/dovecot/conf.d/15-lda.conf
##
## LDA specific settings (also used by LMTP)
##

# Address to use when sending rejection mails.
# Default is postmaster@<your domain>.
postmaster_address = postmaster

# Hostname to use in various parts of sent mails, eg. in Message-Id.
# Default is the system's real hostname.
hostname = test.machine

# If user is over quota, return with temporary failure instead of
# bouncing the mail.
#quota_full_tempfail = no

# Binary to use for sending mails.
#sendmail_path = /usr/sbin/sendmail

postmaster_address は、受信拒否の通知メールで使う送信元アドレスを設定する。
hostname は、この送信メールのMessage-Idなどで使用されるホスト情報を設定する。
quota_full_tempfail は、容量オーバーの際に受信拒否せずに一時的に失敗している旨を通知するか設定する。
sendmail_path は、sendmailコマンドのパスを設定する。


■auth-userdbソケットのパーミッションを調整した。

後半のPostfixの設定で扱うように、dovecot-ldaコマンドはユーザーvmailで実行される。
ユーザーvmailがアクセスできるように、auth-userdbソケットのパーミッションを調整した。

このauth-userdbソケットから、dovecot-ldaはメールボックス情報の検索を行うようだ。


○auth-userdbソケットが生成される場所を確認した。

[root@test conf.d]# less  /etc/dovecot/conf.d/10-mail.conf

(略)
# UNIX socket path to master authentication server to find users.
# This is used by imap (for shared users) and lda.
#auth_socket_path = /var/run/dovecot/auth-userdb
(略)

auth-userdbソケットをvmailユーザーが読み書きできるようにした。

[root@test conf.d]# vim /etc/dovecot/conf.d/10-master.conf
(略)
service auth {

  # auth_socket_path points to this userdb socket by default. It's typically
  # used by dovecot-lda, doveadm, possibly imap process, etc. Its default
  # permissions make it readable only by root, but you may need to relax these
  # permissions. Users that have access to this socket are able to get a list
  # of all usernames and get results of everyone's userdb lookups.
  unix_listener auth-userdb {
    mode = 0600
    user = vmail

    #group =
  }

  # Postfix smtp-auth
  #unix_listener /var/spool/postfix/private/auth {
  #  mode = 0666
  #}

  # Auth process is run as this user.
  #user = $default_internal_user
}
(略)
もし、この設定をしていなければ、運用時に受信メールのメールボックスへの保存に失敗する。
次のような、内部エラーが発生し、deferrd にされる。
May  6 01:56:17 test dovecot: lda: Error: userdb lookup: connect(/var/run/dovecot/auth-userdb) failed: Permission denied (euid=5000(vmail) egid=5000(vmail) missing +r perm: /var/run/dovecot/auth-userdb, euid is not dir owner)
May  6 01:56:17 test dovecot: lda: Fatal: Internal error occurred. Refer to server log for more information.
May  6 01:56:17 test postfix/pipe[18592]: 28FCA9FC2F: to=<test@domain>, relay=dovecot, delay=0.15, delays=0.08/0.02/0/0.05, dsn=4.3.0, status=deferred (temporary failure)


■Dovecotの再起動を行い、auth-userdbソケットのパーミッションを確認した。


再起動前には、次の様に、auth-userdbは、rootがオーナーになっている。
[root@test conf.d]# ls /var/run/dovecot/ -Al
total 12
srw-------  1 root    root        0 Mar 16 17:17 anvil
srw-------  1 root    root        0 Mar 16 17:17 anvil-auth-penalty
srw-------  1 root    root        0 Mar 16 17:17 auth-client
srw-------  1 dovecot root        0 Mar 16 17:17 auth-login
srw-------  1 root    root        0 Mar 16 17:17 auth-master
srw-------  1 root    root        0 Mar 16 17:17 auth-userdb
srw-------  1 dovecot root        0 Mar 16 17:17 auth-worker
srw-------  1 root    root        0 Mar 16 17:17 config
srw-------  1 root    root        0 Mar 16 17:17 dict
srw-------  1 root    root        0 Mar 16 17:17 director-admin
srw-------  1 root    root        0 Mar 16 17:17 director-userdb
srw-rw-rw-  1 root    root        0 Mar 16 17:17 dns-client
srw-------  1 root    root        0 Mar 16 17:17 doveadm-server
lrwxrwxrwx  1 root    root       25 Mar 16 17:17 dovecot.conf -> /etc/dovecot/dovecot.conf
drwxr-xr-x. 2 root    root     4096 Sep 22  2015 empty
srw-rw-rw-  1 root    root        0 Mar 16 17:17 lmtp
drwxr-x---. 2 root    dovenull 4096 Mar 16 17:17 login
-rw-------  1 root    root        6 Mar 16 17:17 master.pid


○Dovecotの再起動を行った。

[root@test conf.d]# service dovecot restart
Stopping Dovecot Imap:                                     [  OK  ]
Starting Dovecot Imap:                                     [  OK  ]

○パーミッションが、設定した通りになっていることを確認した。

[root@test conf.d]# ls /var/run/dovecot/ -Al
total 12
srw-------  1 root    root        0 May  5 23:01 anvil
srw-------  1 root    root        0 May  5 23:01 anvil-auth-penalty
srw-------  1 root    root        0 May  5 23:01 auth-client
srw-------  1 dovecot root        0 May  5 23:01 auth-login
srw-------  1 root    root        0 May  5 23:01 auth-master
srw-------  1 vmail   root        0 May  5 23:01 auth-userdb
srw-------  1 dovecot root        0 May  5 23:01 auth-worker
srw-------  1 root    root        0 May  5 23:01 config
srw-------  1 root    root        0 May  5 23:01 dict
srw-------  1 root    root        0 May  5 23:01 director-admin
srw-------  1 root    root        0 May  5 23:01 director-userdb
srw-rw-rw-  1 root    root        0 May  5 23:01 dns-client
srw-------  1 root    root        0 May  5 23:01 doveadm-server
lrwxrwxrwx  1 root    root       25 May  5 23:01 dovecot.conf -> /etc/dovecot/dovecot.conf
drwxr-xr-x. 2 root    root     4096 Sep 22  2015 empty
srw-rw-rw-  1 root    root        0 May  5 23:01 lmtp
drwxr-x---. 2 root    dovenull 4096 May  5 23:01 login
-rw-------  1 root    root        6 May  5 23:01 master.pid



◆ Postfix側の設定 ◆


■Postfixで、dovecot-ldaコマンドが使えるように、定義を行った。

○dovecot-ldaコマンドの場所を確認した。

[root@test conf.d]# find / -name dovecot-lda
/usr/libexec/dovecot/dovecot-lda
ところで、下に示すようにdovecot-ldaコマンドへの、リンクがdeliverという名前で張られているが、
以下では、dovecot-ldaというファイルを直接用いる。

[root@test conf.d]# ls /usr/libexec/dovecot/deliver -Al
lrwxrwxrwx. 1 root root 11 Jan  8 16:36 /usr/libexec/dovecot/deliver -> dovecot-lda

dovecotという名前で、dovecot-ldaコマンドの実行方法について定義した。

[root@test postfix]# vim master.cf
dovecot  unix  -       n       n       -       -       pipe
  flags=DRhu user=vmail:vmail argv=/usr/libexec/dovecot/dovecot-lda -f ${sender} -d ${recipient}

/* オプションについての説明 */

<dovecot-ldaコマンドの引数>

引数 -f には、送信元アドレスを指定する。
Postfixのマクロ ${sender} を用いる。これは、受信メールのエンベロープの送信元アドレスを意味する。

引数 -d には、宛先アドレスを指定する。
Dovecotは、このアドレスを用いて保存先メールボックスを検索、決定する。
マクロ ${recipient} は、受信者アドレスを意味する。

他にも、様々な引数があり、たとえば、直接メールボックスを指定することも可能である。


<user>

このコマンドを実行するユーザー:グループを指定する。
ここでは、共に vmail が指定されているため、dovecot-ldaは、vmailユーザーで実行される。


<flags>

D
Delivered-To: recipient をヘッダーに付加し、エンベロープ受信者が指定される
これを用いるには、main.cfで transport名_destination_recipient_limit=1 でなければならない。 (後述)
ところで、既にヘッダーに、Delivered-To: が同じ受信者で含まれていれば、
メール配送がループしているとして検知 され、配送不能としてリターンされる。

R
Return-Path: をヘッダーに付加し、エンベロープ送信者が指定される。

h
コマンドラインにおいて受信者アドレスの @よりも右側の文字列 を、小文字に揃える。

u
コマンドラインにおいて受信者アドレスの @よりも左側の文字列 を、小文字に揃える。



■virtualユーザ宛てメールが定義済みdovecotに渡るように設定した。

[root@test postfix]# vim main.cf
直接関連する項目を挙げている。(その他の設定は省略している。)
virtual_transport = dovecot
dovecot_destination_recipient_limit = 1

上で定義済みの dovecot を指定している。
また、この定義 dovecot へは、受信者(RCPT TO)が複数あれば、1つにつき、1メールずつ送るように指定している。
これは、定義した dovecot の flags に、「 D 」が指定されているために要件となる。



■ Postfixの再起動の後に、動作テストを行った。

○Postfixの再起動

# service postfix restart


○動作テスト

fetchmailからPostfixにメールを転送した。
下記のように、Postfixは、定義済みの dovecot にリレーされた。
May  6 02:37:27 test postfix/qmgr[18000]: 5FD459FB53: from=<test@fromdomain>, size=7736, nrcpt=1 (queue active)
May  6 02:37:27 test dovecot: lda(test@todomain): msgid=<c o n f i d e n t i a l>: saved mail to INBOX
May  6 02:37:27 test postfix/pipe[18896]: 5FD459FB53: to=<test@todomain>, relay=dovecot, delay=86, delays=86/0.02/0/0.05, dsn=2.0.0, status=sent (delivered via dovecot service)
May  6 02:37:27 test postfix/qmgr[18000]: 5FD459FB53: removed
受信メールは、dovecotのIMAPサーバにメールクライアントを接続することで、受信できた。




<参考>

◇Dovecotに関して

・Dovecot LDA
< http://wiki2.dovecot.org/LDA > 2016年5月6日

・Dovecot LDA with Postfix
< http://wiki2.dovecot.org/LDA/Postfix > 2016年5月8日

・LDA Indexing
< http://wiki2.dovecot.org/LDA/Indexing > 2016年5月8日


◇Postfixに関して

・PIPE(8)
< http://www.postfix.org/pipe.8.html > 2016年5月8日

・PIPE(8)
< http://www.postfix-jp.info/trans-2.2/jhtml/pipe.8.html > 2016年5月7日

・[postfix-jp: 4024] Re: 複数RCPTコマンド時の挙動について
< http://www.postfix-jp.info/ML/arc-2.5/msg00023.html > 2016年5月7日

・[Dovecot] Why : dovecot_destination_recipient_limit = 1 ?
< http://www.dovecot.org/list/dovecot/2009-November/044173.html > 2016年5月7日

2016年3月14日月曜日

【YAMAHA RTX1200】ルーターログをCentOS6.7のrsyslogに転送し指定したファイルに記録する【Linux CentOS 6.7 64bit minimal】

RTX1200のログを、CentOS 6.7のrsyslogで受信し、ファイルに記録するための設定を行った。


◆動作環境は次の通りである。

・rsyslogでログを受信する側は、CentOS 6.7 minimalで、iptablesは動作させていない。
(iptablesを停止させているので、安全なネットワーク上で動作させている。)

・ログをsyslogに送信する側は、RTX1200(Rev.10.01.53)である。



■ログを受信するCentOS 6.7側での必要な設定

1、rsyslogがネットワークを通じてログを受信し、ファイルに保存する設定を行った。

RTXはログの送信時にudpを使うようなので、次の様にして、udp 514でListenするよう設定した。
また、RTXからのログは、SYSLOGファシリティは local5 で取り扱うことにした。

# vi /etc/rsyslog.conf
(略)
# Provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514


# Provides TCP syslog reception
#$ModLoad imtcp
#$InputTCPServerRun 514
(略)

さらに続けて、下の方(/var/log/…を含む項目の集まりの一番下)に次の情報を追加した。
(略)
# RTX
local5.*                                                /var/log/rtx1200-1.log
(略)

2、rsyslogの再起動を行った。
# service rsyslog restart


ところで、モジュールのロード($ModLoad imudp)をしていない場合、次のようなエラーが発生した。
Mar 14 19:00:48 test rsyslogd-3003: invalid or yet-unknown config file command - have you forgotten to load a module? [try http://www.rsyslog.com/e/3003 ]
Mar 14 19:00:48 test rsyslogd: the last error occured in /etc/rsyslog.conf, line 14:"$UDPServerRun 514"
Mar 14 19:00:49 test rsyslogd-2124: CONFIG ERROR: could not interpret master config file '/etc/rsyslog.conf'. [try http://www.rsyslog.com/e/2124 ]


■ログを出力するRTX側での必要な設定

(必須)

rsyslogが動作しているCentOSのアドレスを指定した。
# syslog host 192.168.0.48
SYSLOGファシリティを指定した。 (CentOS側の設定に合わせる。)
# syslog facility local5

(オプション)

出力したい「ログのタイプ」を決定する。
# syslog notice on
# syslog info on
# syslog debug off


■動作確認

○問題なく、rsyslogdが起動したことを確認した。
# tail -5 /var/log/messages

Mar 14 19:46:49 test kernel: imklog 5.8.10, log source = /proc/kmsg started.
Mar 14 19:46:49 test rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="21086" x-info="http://www.rsyslog.com"] start

○ログイン情報がログファイルに記載されているか確認した。

たとえば、RTXにログインすることによって、そのことがロギングされる。
# tail /var/log/rtx1200-1.log

確認したところ、ログは、rsyslog側だけでなく、RTX自身にも従来通りに記録されていた。



◆logrotateでログファイルを定期的に新しいものに差し替える

大量の情報が記載されるログファイルは、定期的に新しいものに切り替えたほうが良い。
また、古い情報が記載されたログファイルは、ディスクの圧迫を避けるために、削除した方が良い。
これらのことを自動的に行ってくれるのが、logrotateというプログラムである。

○logrotateの設定を行った。

# vi /etc/logrotate.d/rtx1200-1

/var/log/rtx.log {
        daily
        rotate 30
        create 644 root root
        notifempty
        missingok
        postrotate
             /usr/bin/killall -HUP rsyslogd
        endscript
}

(説明)
・daily
 毎日ログファイルを新しいファイルに切り替える。

・rotate 30
 古いログファイルは30個まで保持しておく。(古いものから削除される。)

・create 644 root root
 新しいファイルのパーミッションと所有者・グループを指定したように設定する。

・notifempty
 「not if empty」空っぽの場合はそのログファイルを切り替えない。

・missingok
 ファイルの切り替え時に発生するエラー(file not foundなど)を無視する。

・postrotate/endscript
 これらの間に記されるコマンドは、他の処理が実行された後に実行される。

・/usr/bin/killall -HUP rsyslogd
 rsyslogに、設定ファイルの再読み込みを指示している。
 (これがなければ、切り替えた新しいファイルへログが記入されていかない。)


○指定した設定ファイルでlogrotateがどう行われるか確認した。
# logrotate -d /etc/logrotate.d/rtx1200-1
reading config file /etc/logrotate.d/rtx
reading config info for /var/log/rtx.log

Handling 1 logs

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

○次のように、ログファイルが毎日自動的に差し替えされた。
-rw-r--r--   1 root  root  13588252 Mar 18 04:14 rtx1200-1.log-20160318
-rw-r--r--   1 root  root  15235739 Mar 19 04:45 rtx1200-1.log-20160319
-rw-r--r--   1 root  root    150179 Mar 20 03:31 rtx1200-1.log-20160320
-rw-r--r--   1 root  root    148226 Mar 21 03:45 rtx1200-1.log-20160321




<参考>

・ヤマハルータでログを取得する(syslog機能)公開
< http://www.marronkun.net/network/yamaha/rtrtx_000051.html > 2016年3月14日

・シスログの管理 rsyslog.conf の設定 〜 CentOS6
< http://easyramble.com/configure-rsyslog.html > 2016年3月14日

・How to Setup Rsyslog Remote Logging on Linux (Central Log Server)
< http://www.thegeekstuff.com/2012/01/rsyslog-remote-logging/ > 2016年3月14日


(logrotateについて)
・20.2. ログファイルの場所の特定
< https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s1-logfiles-locating.html > 2016年3月21日

・How to use logrotate to manage log files in Linux
< http://xmodulo.com/logrotate-manage-log-files-linux.html > 2016年3月21日


(rsyslogの応用)
・rsyslog 8.18.0.master documentation » Configuration »
< http://www.rsyslog.com/doc/master/configuration/properties.html > 2016年3月14日

・Templates
< http://www.rsyslog.com/doc/master/configuration/templates.html > 2016年3月14日


(ファシリティ―について)
・syslog facility
< https://www.furukawa.co.jp/fitelnet/f/man/100/command-config/global_config/syslog_facility.htm > 2016年3月14日

2016年3月6日日曜日

【Windows 7 pro 64bit】 Windows 10への更新通知タスクトレイアイコンを非表示にする方法

以下の方法では、数日後に、再び更新通知アイコン(田)が、タスクトレーに表示されてしまった。
どうやら、「非表示」にしたにもかかわらず、再び更新プログラムが自動的にインストールされてしまったものだと思われる。
この件について、次のページが参考になった。
http://answers.microsoft.com/ja-jp/windows/forum/windows_7-update/windows/a320b81f-cea7-45b7-9644-5164f62823ad?auth=1





Windows 10への更新通知アイコン(田)が、タスクトレーに表示されるようになってしまった。 

これでは、ユーザーが管理者の断りなく、このアイコンからWindows 10へシステムをアップデートしてしまう危険がある。

そういう事態を避けるには、そのアイコンによる通知を無効化すればよい。

この通知を禁止するには、インストール済み「KB3035583」をアンインストールし、さらに自動的にインストールされないように設定を行う
これ(KB3035583)は、タスクトレーで、Windows 10への更新を通知する役割を持っているらしい。



(手順)
1、管理者権限でコマンドプロンプトウインドウを開く。

コマンドプロンプトアイコンの右クリックメニューから、「管理者として実行する」を選択する。


2、プロンプトで次のコマンドを実行して、KB3035583 をアンインストールする。
wusa /uninstall /KB:3035583
ダイアログが表示される。これに応答していくことで削除ができた。

最後に、再起動を求められる。

再起動後には、タスクトレーにWindows 10へのアップデート通知のアイコンは表示されなくなった。


3、「Windows Update」から更新プログラムの確認を行い、KB3035583を「非表示」にする。

さきの手順で再起動をした後、再度、「Windows Update」で更新プログラムの確認を行うと、
アンインストールした KB3035583 が再び重要な更新プログラムとして、挙がってきている。

Windows 7 for x64-Based Systems 用更新プログラム (KB3035583)

ダウンロード サイズ: 722 KB - 821 KB
このままだと、再び自動的にインストールされてしまうことになり、通知が現れてしまう。

そこで、インストールしないようにチェックを外し
この項目の上で右クリックしてメニューを出して、「更新プログラムの非表示」を選択し、「OK」ボタンをクリックする。

そうすると、インストールの対象となる重要な更新から KB3035583 を外せる。

再び、自動的にインストールされなくなるので、Windows 10への更新通知は、
タスクトレーに表示されなくなる。



○不要なファイルの削除

Windows 10のアップデート通知に関するファイルが、次の場所にあるかもしれない。
Windows\System32\GWX
これも削除することができる(先に”所有者”を取得しておく)らしいが、私は試していない。




<参考>

・How to disable the “Get Windows 10” icon shown in the notification area (tray)?
< http://superuser.com/questions/922068/how-to-disable-the-get-windows-10-icon-shown-in-the-notification-area-tray > 2016年3月6日 

・Windows 7のWindows Updateで必要ない更新プログラムを非表示にする方法
< https://121ware.com/qasearch/1007/app/servlet/relatedqa?QID=012983 > 2016年3月7日