Windows10に対して、リモートデスクトップでログインしている時に、そのログイン先のWindows10をシャットダウン/再起動する方法。
スタートメニューの電源ボタンを押しても、「切断」しか表示されない。
Alt+F4で、シャットダウン等のメニューを表示できるので、ここからシャットダウン/再起動する。
＜2016/9/25 追記＞
「Windows 10 Anniversary Update」を適用後の場合、以下になります。
リモートデスクトップで Windows10（1607） をシャットダウン/再起動する方法 - しょぼんメモリ （´・ω・｀）
他にもっと簡単な方法があるかもしれないけど、必要な度に調べるのが面倒なのでメモ。
接続中のDB名を取得
test_db=> SELECT current_database(); current_database ------------------ test_db
接続中のDBサイズの取得
test_db=> SELECT pg_size_pretty(pg_database_size(datname)) FROM pg_database WHERE datname=(SELECT current_database()); pg_size_pretty ---------------- 46 MB
VIEWの作成
test_db=> CREATE VIEW getDBsize AS SELECT pg_size_pretty(pg_database_size(datname)) FROM pg_database WHERE datname=(SELECT current_database());
VIEWの確認
test_db=> SELECT * FROM getdbsize; pg_size_pretty ---------------- 46 MB
接続中のDBだけでなく、全てのDBのサイズを取得する場合
test_db=>SELECT datname, pg_size_pretty(pg_database_size(datname)) FROM pg_database;
参考
http://www.postgresql.jp/document/8.4/html/functions-info.html
http://www.postgresql.jp/document/8.4/html/functions-admin.html
CentOS 6.7 の rsyslog で他のサーバ等から syslog を TCP/UDP で受け取り、ログを PostgreSQL へ登録しようとした時のこと。
環境は以下の通り。全てのサーバは同一セグメント内にある。
【syslog を受け取るサーバ】
CentOS 6.7
2.6.32-573.8.1.el6.x86_64
rsyslog-5.8.10-10.el6_6.x86_64
rsyslog-pgsql-5.8.10-10.el6_6.x86_64
postgresql-server-8.4.20-4.el6_7.x86_64
【syslog を送るサーバ】
・1台目
CentOS 5.11
2.6.18-407.el5PAE
rsyslog-3.22.1-7.el5
・2台目
CentOS 6.7
2.6.32-573.8.1.el6.x86_64
rsyslog-5.8.10-10.el6_6.x86_64
・3台目
CentOS 7.1
3.10.0-229.el7.x86_64
rsyslog-7.4.7-12.el7.x86_64
syslog を受け取るサーバでは、rsyslog-pgsql モジュールを使い、ログを PostgreSQL のテーブルへ登録する。
PostgreSQL では、予め以下のようなテーブルを用意してある。
syslog_db=> \d log_tbl テーブル "public.log_tbl" カラム | 型 | 修飾語 -------------+--------------------------------+----------------------------------------------------- id | integer | not null デフォルト nextval('log_id_seq'::regclass) generated | timestamp(0) without time zone | facility | smallint | priority | smallint | hostname | text | programname | text | message | text |
syslog を受け取るサーバの /etc/rsyslog.conf の主な設定は以下の通り。
※後述しますが、下記の設定は$template 行の末尾が誤っています。
# Provides UDP syslog reception $ModLoad imudp $UDPServerRun 514 $AllowedSender UDP, 127.0.0.1, 192.168.1.0/24 # Provides TCP syslog reception $ModLoad imtcp $InputTCPServerRun 514 $AllowedSender TCP, 127.0.0.1, 192.168.1.0/24 # syslog -> PostgreSQL $ModLoad ompgsql $template Mypgsql,"INSERT INTO log_tbl (generated, facility, priority, hostname, programname, message) values ('%timegenerated:::date-rfc3339%', %syslogfacility%, %syslogpriority%, '%hostname%', '%programname%', '%msg%')",sql *.* :ompgsql:localhost,syslog_db,db_user,db_pass;Mypgsql
rsyslog-pgsql にバンドルされているデフォルトのテーブル定義（/usr/share/doc/rsyslog-pgsql-5.8.10/createDB.sql）を使わず、自分で定義したテーブルへデータを登録するため、Mypgsql というテンプレートにSQLを定義。
これで syslog のデータを受け取ったものをDBへINSERTしていく。
この環境でログの受信をテストしていると、CentOS 5.11 のサーバを再起動した時に、受け取った側のサーバの rsyslog プロセスのCPUが高くなり、暫く待っても収まらない問題に遭遇。
送り側のOSの問題か切り分けるだめ、他のCentOS 6/7のサーバを再起動しても、上記と同じく問題が発生したので、受け側の問題と推測。
CentOSが起動する際に送られる syslog を受け取った側の rsyslog がおかしくなるようだった。
暫く待ってもDBの処理が終わらず、以下のエラーを出してDB処理が終了する。
Dec 13 11:52:59 syslog_srv rsyslogd: db error (1): no connection to the server
3台のサーバから、シェルでfor/loggerを使って10000万回のテストメッセージを出力し、TCP/UDPで転送してみても再現できなかったので、受け側のrsyslog の負荷の問題ではなさそうだった。
また、DBへの登録はせず、TCP/UDPで受け取ったsyslog をテキストへ保存すると問題は発生しない。
/var/log/messages のログを眺めると、CentOS起動時のログにシングルクォートが。
/etc/rsyslog.conf に設定したテンプレート部分のSQL文が、エスケープされていないのではないかと思い、logger コマンドで以下を試した。
$ logger test r\"syslog →test r"syslog でDBに登録される $ logger test 'r"syslog' →test r"syslog でDBに登録される $ logger test r\'syslog →DBに登録されない $ logger test "r'syslog" →DBに登録されない
犯人は、シングルクォートでした。
公式ドキュメントを見ると、SQL を指定する際は書式が2種類ある。
http://www.rsyslog.com/doc/v5-stable/configuration/templates.html
sql - format the string suitable for a SQL statement in MySQL format. This will replace single quotes (“’”) and the backslash character by their backslash-escaped counterpart (“\’” and “\\”) inside each field. Please note that in MySQL configuration, the NO_BACKSLASH_ESCAPES mode must be turned off for this format to work (this is the default).
stdsql - format the string suitable for a SQL statement that is to be sent to a standards-compliant sql server. This will replace single quotes (“’”) by two single quotes (“’‘”) inside each field. You must use stdsql together with MySQL if in MySQL configuration the NO_BACKSLASH_ESCAPES is turned on.
Either the sql or stdsql option must be specified when a template is used for writing to a database, otherwise injection might occur. Please note that due to the unfortunate fact that several vendors have violated the sql standard and introduced their own escape methods, it is impossible to have a single option doing all the work. So you yourself must make sure you are using the right format. If you choose the wrong one, you are still vulnerable to sql injection.
これらはエスケープ方法が異なる。
sql の場合、 ' は \ でエスケープされる。MySQL で利用。
stdsql の場合、 ' は '' でエスケープされる。
PostgreSQLの場合、stdsql を使わなければならない。
さっそく、/etc/rsyslog.conf の $template 行の末尾を sql → stdsql に修正。
# syslog -> PostgreSQL $ModLoad ompgsql $template Mypgsql,"INSERT INTO log_tbl (generated, facility, priority, hostname, programname, message) values ('%timegenerated:::date-rfc3339%', %syslogfacility%, %syslogpriority%, '%hostname%', '%programname%', '%msg%')",stdsql *.* :ompgsql:localhost,syslog_db,db_user,db_pass;Mypgsql
rsyslog サービスを再起動して、syslog 送信側の各サーバを再起動してみると、受け側の rsyslog はCPUの負荷も上がらず、DBにも正常に登録された。
そもそも何故、設定ファイルに sql と書いたかというと、、、
以前同じように syslog をDBに登録した時はMySQLを使った事があり、今回はその時の構築メモを見ながらPostgreSQLを使ったのでハマった。
なお、rsyslog-pgsql にバンドルされている /usr/share/doc/rsyslog-pgsql-5.8.10/createDB.sql を使うと構文エラーが出る。
$ psql -f /usr/share/doc/rsyslog-pgsql-5.8.10/createDB.sql psql:/usr/share/doc/rsyslog-pgsql-5.8.10/createDB.sql:1: ERROR: "'Syslog'"またはその近辺で構文エラー 行 1: CREATE DATABASE 'Syslog' WITH ENCODING 'SQL_ASCII'; ^ psql:/usr/share/doc/rsyslog-pgsql-5.8.10/createDB.sql:2: \connect: FATAL: データベース"Syslog"は存在しません
PostgreSQL では大文字と小文字を区別する場合、文字をダブルクォーテーションで括るので、テンプレートを修正する。
ついでにDBのエンコードも環境に合わせる。
CREATE DATABASE 'Syslog' WITH ENCODING 'SQL_ASCII'; ↓ CREATE DATABASE "Syslog" WITH ENCODING 'UTF8';
これでrsyslog-pgsql にバンドルされているテーブル定義へログを登録できるようになるが、カラムを自分で定義したい場合には以下を参考にSQLを定義すると良い。
http://www.rsyslog.com/doc/v5-stable/configuration/templates.html
http://www.rsyslog.com/doc/v5-stable/configuration/properties.html
http://www.rsyslog.com/doc/v5-stable/configuration/property_replacer.html
上記は、rsyslog v5.x の場合で、7系や8系は、URLが異なる。
CentOS 6.7 では、rsyslog7 パッケージが利用できるので、7系のリンクもメモ。
http://www.rsyslog.com/doc/v7-stable/configuration/templates.html
http://www.rsyslog.com/doc/v7-stable/configuration/properties.html
http://www.rsyslog.com/doc/v7-stable/configuration/property_replacer.html
少し前の話だけど、Windows7/64bit にインストールしているThunerbirdが、自動アップデートした後でコントロールパネルに2つ出てくるようになった。
バージョン 38.2 → 38.3 に更新された時のこと。
古い 38.2 を削除しようと思ったが、メールデータも一緒にどちらも消えてしまうのが怖くて放置していたら、38.3 → 38.4 に更新された時に直った。
【リリース情報】
【環境】
Windows 7/64bit
Intel 82578DC
11月の定例 Windows Update を適用したところ、Wake On LANでPCを起動できなくなった。
デバイスマネージャからNICのドライバを確認し、今回の Windows Update でバージョンが変わっていない事を確認。
NICのプロパティにて、Wake On LAN関連の設定が有効になっている事も確認。
BIOS の設定も問題ない。
ネットで事例を探しても見つからず、NICのドライバを更新してみる事に。
Intelのサイトからドライバをダウンロードして、更新後にOSを再起動すると・・・
DHCPのアドレス取得にも失敗してネットワークに繋がらない。
デバイスマネージャを確認すると、デバイス（NIC）のロードに失敗して認識せず（デバイスマネージャで変な印が表示される）。
デバイスマネージャで、該当のNICを無効→有効にすると、認識してネットワークに繋がるようになる。
OSを再起動してみると、また同じようにNICを認識しなかった。
仕方がないので、ドライバをロールバックしたところ、Wake On LANも正常に動作するようになり、OS起動時にNICの認識も失敗しないようになった（おかしくなる以前の状態に戻った）。
更新前のドライバ
更新後のドライバ
結局、
・NICのドライバを更新してみたらOS起動後に自動認識しなくなった
・ドライバを元に戻したら全て直った
となり、何が原因か分からないけど、メモっておく。
実家のPCがインターネットに繋がらなくなったので、何が原因か調べたら無線ルータだった。
使用していたのは、バッファロー社の「WHR-G301N」という製品。
購入してから4-5年くらい経っていると思う。
本体のLEDを確認すると、POWERとDIAGが高速に点滅。
マニュアルでも見ようとネットに、、、そのネットが使えない訳で、スマホ経由でマニュアルを確認。
同じような症状は見受けられない。
本体を見ていると、妙な音がするので耳を近づけてみると、「カチカチカチカチ」「チッチッチッチッ」のような変な音が本体から聞こえる。
スマホ経由でググってみると、先達を発見。
なるほど、ACアダプタが原因で電源ON/OFFを繰り返しているのか、、、。
という訳で、同じ型番をもう1つ持っていたのでACアダプタだけを交換してみると、ホントに問題なく動作。
まずは環境。
OS：CentOS 5.11
ClamAV：clamav-0.98.7-1.el5、clamav-db-0.98.7-1.el5
WordPress：4.3.1
ewww-image-optimizer：2.5.3
2015/11/18 の2時過ぎに実行されたClamAVによるスキャンで、ewww-image-optimizer 2.5.3 に含まれている「optipng.exe」が、ウィルスとして検知された。
ClamAVのレポートは以下の通り（一部省略）。
/wp-path/plugins/ewww-image-optimizer/optipng.exe: Win.Adware.Softpulse-223 FOUND ----------- SCAN SUMMARY ----------- Known viruses: 4106106 Engine version: 0.98.7 Infected files: 1
「optipng.exe」を仮想化環境（Linux）へコピーし、オンラインで検査。
VirusTotal - Free Online Virus, Malware and URL Scanner
2015/11/18の9時頃にチェックしたところ、結果は 2/54。
ウィルスとして検知したのは、ClamAV と TheHacker の2つのみ。
TheHacker の場合は、Posible_Worm32 として検知していた。
また、前日や前々日などのバックアップから同ファイルを抽出し、ハッシュ値は同じ。
サイズ：98304 byte
MD5：e3d154829ea57a0bdd88b080f6851265
SHA256: fad3a0fd95706d53576f72593bf13d3e31d1c896c852bfd5b9ba602eca0bd2b6
サーバの他のログやプロセス等を調査して問題が無い事を確認。
プラグインを停止して、ネットで情報収集すると、以下を発見。
WordPress › Support » Virus found virustotal.com
Plugin Author の nosilver4u 氏が
looks like a false positive, but I am looking into it further. So far, everything matches what I've downloaded (months ago) from official sources.
と言っている。その後、誤検知の報告もされた模様。
/var/log/clamav/freshclam.log を見直して、パターンファイルの更新履歴からバージョンとシグネチャ部分を抜粋すると、次の通り。
2015/11/14：version: 21061, 4099803 signatures 2015/11/17：version: 21062, 4111644 signatures
一方、ClamAVのスキャン結果には「Known viruses: 4106106」とあり、signatures の数を見ても、この間にパターンに取り込まれたと思われる。
このままプラグインを停止した状態で、ClamAV のパターンが更新されるか様子を見ることに。
翌日、2015/11/19 に ClamAV で再びスキャンしてみたところ、検知されなくなった。
パターンファイルは、version: 21062, 4116258 signatures だった。
2015/11/19 の9時頃に以下で再びチェック。
VirusTotal - Free Online Virus, Malware and URL Scanner
結果は 1/54 で、検知されたは TheHacker のみ、こちらも ClamAV では検知されなくなった模様。
ewww-image-optimizer 2.5.3 に含まれている「optipng.exe」は、ClamAV によりウィルスと検知されたのは、誤検知だったと思われる。
