ブログ - サイト運営カテゴリのエントリ
最初に気づくのはアンダーバーを入力した時に入ってないのでコマンドがエラーになる.
VMwareの仮想サーバを停止し,Finderでパッケージを開いて,vmxファイルをテキストエディタで開いて以下の2行を最終行に追加して再起動すれば良いでしょう.
VMwareの仮想サーバを停止し,Finderでパッケージを開いて,vmxファイルをテキストエディタで開いて以下の2行を最終行に追加して再起動すれば良いでしょう.
keyboard.vusb.idVendor=0x05AC
keyboard.vusb.idProduct=0x020D
DB ERROR!: Please initialize an attach file database on an administrator screen.
- カテゴリ :
- サイト運営
- ブロガー :
- ujpblog 2017/12/4 23:58
技術記事を書くときに導入しているXPwikiで,アクセスするとDB ERROR!: Please initialize an attach file database on an administrator screen.がでるようになった.
原因はわからないけれど,管理ツールのデータベースのシンクロナイズを行えば良い・・・とあるけれど,その管理ツールがない!!
それで,よくよく見ると記事が削除されているものがあったので再構築.権限があまかったようだ...
メール配送を許可するIPアドレスと拒否するドメインを指定してみる.
データベースを更新.
postfixの再起動は不要.事前にmain.cfのsmtpd_client_restrictionsに指定しておく.
sh-3.2# tail -n 4 /etc/postfix/access
#20170316 NIKKEI.com
138.101.7.55 OK
138.101.7.56 OK
hinet.net REJECT
sh-3.2#
sh-3.2# postmap /etc/postfix/access
sh-3.2# ls -lat /etc/postfix|head -n 10
total 840
-rw-r--r-- 1 root wheel 16384 Mar 16 01:13 access.db
drwxr-xr-x 183 root wheel 6222 Mar 16 01:12 ..
drwxr-xr-x 41 root wheel 1394 Mar 16 01:11 .
-rw-r--r-- 1 root wheel 18462 Mar 16 01:11 access
-rw-r--r-- 1 root wheel 47079 Mar 5 11:47 main.cf
-rw-r--r--@ 1 root wheel 8960 Jul 25 2016 aliases
-rw-r--r-- 1 root wheel 208 Oct 27 2015 smtpdreject
-rw-r--r-- 1 root wheel 189 Oct 27 2015 smtpdreject.cidr
-rw-r--r-- 1 root wheel 16384 Oct 27 2015 smtpdreject.db
sh-3.2#
アクセスログから,クライアントIPアドレス毎に集計して,そのトップ10だけを表示して見る.
表示した結果がこれ.

全体の6.5%はblexhn21.webmeup.comからのアクセスか....調べると,USER-AGENTはBLEXBot/1.0となっていて,クローラの説明サイトへの誘導用URLも記載してあります.
BLEXBot/1.0; +http://webmeup-crawler.com/
ちゃんとrobot.txtを使ってアクセス制限する方法も記載しているので,まっとうなクローラーのようです.
サービスを調べたら,ここでした.
WebMeUp Backlink Tool
http://webmeup.com/
バックリンクを調べることができるサイトとのこと.バックリンクとは,他のサイトからリンクが貼られている事を示し,SEOの計算指標として使われています.
Googleで言うところのPageRankですかね.リンクをたくさん貼られているページは良いページであるという集合知的なことで検索ランキングが上位に来るわけです.
BLEXBotのアクセスで気になったのは,404エラーを発生させるエラー.どこかのサイトで適当にリンクされているのでしょう.GET /hotel/pension-bakara-v-libchavachみたいなページへのアクセスなので,全く存在しないわけで.
WebMeUpは有料サイトだけれど,無料でも月3回ほど検索できるようなので,ユーザ登録して使ってみますかね.
ちなみに2位の178.159.37.14は,ウクライナからの不正アクセス...
sourcetype=access_*|top limit=10 clientip

全体の6.5%はblexhn21.webmeup.comからのアクセスか....調べると,USER-AGENTはBLEXBot/1.0となっていて,クローラの説明サイトへの誘導用URLも記載してあります.
BLEXBot/1.0; +http://webmeup-crawler.com/
ちゃんとrobot.txtを使ってアクセス制限する方法も記載しているので,まっとうなクローラーのようです.
サービスを調べたら,ここでした.
WebMeUp Backlink Tool
http://webmeup.com/
バックリンクを調べることができるサイトとのこと.バックリンクとは,他のサイトからリンクが貼られている事を示し,SEOの計算指標として使われています.
Googleで言うところのPageRankですかね.リンクをたくさん貼られているページは良いページであるという集合知的なことで検索ランキングが上位に来るわけです.
BLEXBotのアクセスで気になったのは,404エラーを発生させるエラー.どこかのサイトで適当にリンクされているのでしょう.GET /hotel/pension-bakara-v-libchavachみたいなページへのアクセスなので,全く存在しないわけで.
WebMeUpは有料サイトだけれど,無料でも月3回ほど検索できるようなので,ユーザ登録して使ってみますかね.
ちなみに2位の178.159.37.14は,ウクライナからの不正アクセス...
1ヶ月ほど前だけれど,不正アクセス監視アラートがでて,調べたらAWSの中国リージョンだった.
cn.north.1.compute.amazonaws.com.cn
AWSからの不正アクセスをグラフ化しているのだけれど,着実に増えています.

ちなみにこれはユニーク数を取っていて同じアドレスからのアクセスはブロックしています.
さくらインターネットも同時に関ししているけれど,一時期のような勢いはないね.みんなAWSに移っていったのかな.
cn.north.1.compute.amazonaws.com.cn
AWSからの不正アクセスをグラフ化しているのだけれど,着実に増えています.

ちなみにこれはユニーク数を取っていて同じアドレスからのアクセスはブロックしています.
さくらインターネットも同時に関ししているけれど,一時期のような勢いはないね.みんなAWSに移っていったのかな.
大量にアクセスがあるcnドメインからのアクセスを止めるおまじない,てーあんもん事件をキーワードに入れてみる.
実際には,CMS上のヘッダにHTMLコメントとして.どれくらい効果があるのだろう?
実際には,CMS上のヘッダにHTMLコメントとして.どれくらい効果があるのだろう?
1ヶ月ほど前にセキュリティ対策でサーバを再起動する事があったので,そのタイミングでエコワットを出動さえてみた.

正確に言うと702時間なので29.25時間.でもだいたい1ヶ月の電気代は370円という事ですね.
夏なので放熱のためのファンが回ったり,攻撃的な大量アクセスによる負荷上昇,そして逆にブロックリストの巨大化による処理件数上昇と,動作しているものは多くなったけれど,ブロックによってトータル的には無駄な処理が減っていると捉えればよから,省電力化であると言えるのじゃないかなぁ.

正確に言うと702時間なので29.25時間.でもだいたい1ヶ月の電気代は370円という事ですね.
夏なので放熱のためのファンが回ったり,攻撃的な大量アクセスによる負荷上昇,そして逆にブロックリストの巨大化による処理件数上昇と,動作しているものは多くなったけれど,ブロックによってトータル的には無駄な処理が減っていると捉えればよから,省電力化であると言えるのじゃないかなぁ.
不正なアクセスを検知したら,直後にブロックするシステムを運営中.それでどれくらいブロックされているかグラフで表現してみた.(青い線.緑はルール数)

青いグラフが,ブロックしたログの行数.現在のログローテーションはログファイルが一定数になったらログスイッチしているので,青いグラフをみてのとおり高さは同じところを示している.
つまり,ログスイッチが発生する一定容量までの到達時間によって,ブロックしたIPアドレスからの再攻撃されている様が解るようになっている.
この動きを見ると,ブロックしたところで,それを検知して攻撃対象を変える様なことはしてない模様.単純に総当たり攻撃ですね.
グラフの傾斜が緩やかな日もあるけれど,これは土日が絡む事が多いです.つまり,平日に使っているパソコンが意図せず攻撃をコントロールされていて,使用をやめると攻撃も停止するということなのだろうと推察します.

青いグラフが,ブロックしたログの行数.現在のログローテーションはログファイルが一定数になったらログスイッチしているので,青いグラフをみてのとおり高さは同じところを示している.
つまり,ログスイッチが発生する一定容量までの到達時間によって,ブロックしたIPアドレスからの再攻撃されている様が解るようになっている.
この動きを見ると,ブロックしたところで,それを検知して攻撃対象を変える様なことはしてない模様.単純に総当たり攻撃ですね.
グラフの傾斜が緩やかな日もあるけれど,これは土日が絡む事が多いです.つまり,平日に使っているパソコンが意図せず攻撃をコントロールされていて,使用をやめると攻撃も停止するということなのだろうと推察します.
名前からしてWordPressのログイン用のURLなんだけれど,WordPressを提供してないのにこのページにダイレクトにアクセスしてくるIPアドレスは,ブロック対象だろうね.
WordPressは有名なのでわかるけれど,それ以外でもログインページに短時間ダイレクトにアクセスしてくる統一なブロック方法はないものだろうか.まぁにloginでログを引っ掛ければ良いのかなぁ.
WordPressは有名なのでわかるけれど,それ以外でもログインページに短時間ダイレクトにアクセスしてくる統一なブロック方法はないものだろうか.まぁにloginでログを引っ掛ければ良いのかなぁ.
ログインしてないとTime Machineでバックアップしてくれないというので,コンソール画面からログインしてなくてもディスクをマウントすれば良いのでは?と思い立つ.
/Volumesディレクトリに移動.
現在,/だけなので内蔵HDDしかマウントされてない.接続されているハードドライブを確認する.
disk1が認識されている.ここで,約320GBのJunoTMというボリュームがある.これをマウントしたいときは,disk1s3を指定する.disk1のスライス3番という事ね.こういうところを見るとUnixを感じるねぇ...
マウントできたか確認.
認識されてますね.
/Volumesディレクトリに移動.
sh-3.2# cd /Volumes/
sh-3.2# ls -la
total 8
drwxrwxrwt@ 3 root admin 102 Aug 20 17:23 .
drwxr-xr-x 42 root admin 1496 Aug 20 17:15 ..
lrwxr-xr-x 1 root admin 1 Aug 1 00:00 juno -> /
sh-3.2#
sh-3.2# diskutil list
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *160.0 GB disk0
1: EFI 209.7 MB disk0s1
2: Apple_HFS juno 159.6 GB disk0s2
/dev/disk1
#: TYPE NAME SIZE IDENTIFIER
0: Apple_partition_scheme *320.1 GB disk1
1: Apple_partition_map 32.3 KB disk1s1
2: Apple_HFS JunoTM 319.9 GB disk1s3
sh-3.2#
sh-3.2# diskutil mountDisk disk1s3
Volume(s) mounted successfully
sh-3.2#
sh-3.2# ls -la
total 8
drwxrwxrwt@ 4 root admin 136 Aug 22 23:35 .
drwxr-xr-x 42 root admin 1496 Aug 20 17:15 ..
drwxrwxr-x@ 15 _unknown _unknown 578 Sep 27 2012 JunoTM
lrwxr-xr-x 1 root admin 1 Aug 1 00:00 juno -> /
sh-3.2#
backupedプロセスのCPU Timeを測ってみたら,このようにどの曜日の夜中から動かなくなった.

これは,Time Machineを使う設定をしているユーザがログインしてないと,backupedが動かないから.つまり,そのないだはバックアップされてない.
サーバで動かす場合それは困るので,バックアップを取るように設定する.
実際には1行で.オフにするときはこれ.
バックアップを実行するときはこれ.
またしばらく様子見してみるか.

これは,Time Machineを使う設定をしているユーザがログインしてないと,backupedが動かないから.つまり,そのないだはバックアップされてない.
サーバで動かす場合それは困るので,バックアップを取るように設定する.
sh-3.2# defaults write /Library/Preferences/SystemConfiguration/autodiskmount
AutomountDisksWithoutUserLogin -bool yes
sh-3.2#
$ sudo defaults delete /Library/Preferences/SystemConfiguration/autodiskmount
AutomountDisksWithoutUserLogin
/System/Library/CoreServices/backupd.bundle/Contents/Resources/backupd-helper
MacOS Xの全文検索エンジン,Spotlightのインデックス作成を2回ほど止めた件.
その後,CPU TIMEを図っているのだけれど,着実に伸びている.

心当たりがあるとすれば,ログオンしっぱなしにしたという事かな.それでTime Machineストレージがインデックス対象になったのかも...
という事で,プロセスを確認.
36分も使っている.
launchedの設定を確認.
アンロードして停止する.
プロセスが停止したか確認.
無事停止した模様.
自動起動されないように,plistを編集する.
編集対象のファイルはこれ.
/System/Library/LaunchDaemons/com.apple.metadata.mds.plist
このKeepAliveがtrueになっているので,falseにする.
これでOS起動時にもmdsが起動してこないでしょう.多分.
その後,CPU TIMEを図っているのだけれど,着実に伸びている.

心当たりがあるとすれば,ログオンしっぱなしにしたという事かな.それでTime Machineストレージがインデックス対象になったのかも...
という事で,プロセスを確認.
sh-3.2# ps -ef|grep mds
0 67 1 0 25:09.24 ?? 36:52.64
/System/Library/Frameworks/CoreServices.framework/Frameworks/Metadata.framework/
Support/mds
sh-3.2#
launchedの設定を確認.
sh-3.2# launchctl list|grep mds
67 - com.apple.metadata.mds
sh-3.2#
sh-3.2# launchctl unload /System/Library/LaunchDaemons/com.apple.metadata.mds.plist
sh-3.2#
sh-3.2# ps -ef|grep mds
0 95169 45892 0 0:00.00 ttys000 0:00.00 grep mds
sh-3.2#
自動起動されないように,plistを編集する.
編集対象のファイルはこれ.
/System/Library/LaunchDaemons/com.apple.metadata.mds.plist
<key>KeepAlive</key>
<true/>
<key>KeepAlive</key>
<false/>
以前,考察してから2週間経過した.
key_buffer_sizeを256MBにしていたけれど,ほとんど使ってないので,インデックスの物理容量を計算した上で全部キャッシュに乗る程度に削減した上で2週間後の経過.
まずは現在設定を確認.
10MB.
キャッシュヒット率を計算.
前回99.999987%だったのだけれど,誤差の範囲だと思います.劣化して無い.
ブロックの利用数を見る.
Key_blocks_usedが増えているけれど,圧倒的にKey_blocks_unusedが多かった分が減っているので最適化終了という感じで.
ちなみに,再起動時からのメモリ容量.まずは再起動直後.
14.5日経過後.
VSZ(仮想メモリサイズ)は起動直後も14.5日経過後もあまり変わらない.14.5日経過後のVSZが830944ブロックなので1ブロックは4096byteなので計算すると,約3.2GB.
RSS(リアルに物理メモリ上に確保しているメモリブロック数)は起動直後は33160なので130MBで,経過後は79532なので約310MB.
設定変更前はこのような感じでした.
VSZが4GBで,RSSが130MB.このRSSが増えたのは,sort_bufferを変更した別の要因ですね.
key_buffer_sizeを256MBにしていたけれど,ほとんど使ってないので,インデックスの物理容量を計算した上で全部キャッシュに乗る程度に削減した上で2週間後の経過.
まずは現在設定を確認.
mysql> SHOW VARIABLES LIKE 'key_buffer_size';
+-----------------+----------+
| Variable_name | Value |
+-----------------+----------+
| key_buffer_size | 12582912 |
+-----------------+----------+
1 row in set (0.00 sec)
mysql>
mysql> show status like "Key_read%";
+-------------------+---------+
| Variable_name | Value |
+-------------------+---------+
| Key_read_requests | 1145304 | ←キャッシュからの読み取り要求回数
| Key_reads | 9 | ←ディスクからの読み取り要求回数
+-------------------+---------+
2 rows in set (0.00 sec)
mysql>
100 - ( ( Key_reads / Key_read_requests ) * 100 )
100 - ( ( 9 / 1145304 ) * 100 ) = 99.999214%
ブロックの利用数を見る.
mysql> show status like "Key_blocks%";
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| Key_blocks_not_flushed | 0 |
| Key_blocks_unused | 8051 |
| Key_blocks_used | 2792 |
+------------------------+-------+
3 rows in set (0.00 sec)
mysql>
ちなみに,再起動時からのメモリ容量.まずは再起動直後.
ujp:~$ ps -eo vsz,rss,pid,comm|sort -nr|grep mysqld |sed 's/\// /g'| awk '{print $1" "$2" "$3" "$NF}'
827336 33160 415 mysqld
ujp:~$
14.5日経過後.
ujp:~$ ps -eo vsz,rss,pid,comm|sort -nr|grep mysqld |sed 's/\// /g'| awk '{print $1" "$2" "$3" "$NF}'
830944 79532 415 mysqld
ujp:~$
RSS(リアルに物理メモリ上に確保しているメモリブロック数)は起動直後は33160なので130MBで,経過後は79532なので約310MB.
設定変更前はこのような感じでした.
sh-3.2# ps -eo vsz,rss,pid,comm|sort -nr|grep mysqld |sed 's/\// /g'| awk '{print $1" "$2" "$3" "$NF}'
1061844 88864 30879 mysqld
sh-3.2#
全文検索のSpotlightのバックグラウンドサービスであるmdsがサーバで動いていたので,mdsを停止してみたのだけれど,その後OSを再起動したからか,まだCPUを消費している様である.
CPU time順でリストするとこんな感じ.
そして前回と同じ様にmdsを停止してみた.
CPU time順でリストするとこんな感じ.
sh-3.2# 🆑ps -ef|awk '{print $5" "$8}'|sort -nr|head -n 10
89:34.52 /usr/sbin/DirectoryService
73:09.36 /usr/local/mysql/bin/mysqld
71:13.40 snmpd
55:24.73 /sbin/launchd
50:40.59 /usr/sbin/serialnumberd
15:56.00 /System/Library/Frameworks/CoreServices.framework/
Frameworks/Metadata.framework/Support/mds🈁
14:51.06 servermgrd
6:59.06 /usr/sbin/notifyd
5:29.03 /System/Library/CoreServices/SecurityAgent.app/Contents/MacOS/SecurityAgent
3:08.53 /sbin/emond
sh-3.2#
sh-3.2# mdutil -i off /
/:
Indexing and searching disabled.
sh-3.2#
CPUタイムをカウントしているのだけれど,使い分け的に見えてきた.
gauge
httpdを監視する時に良い.プロセスに寿命が設定されているのと複数起動していてそれを合計しているタイプ.
absolute
mysqldを監視する時に良い.ずっと1つのプロセスが起動しているタイプ.
gauge
httpdを監視する時に良い.プロセスに寿命が設定されているのと複数起動していてそれを合計しているタイプ.
absolute
mysqldを監視する時に良い.ずっと1つのプロセスが起動しているタイプ.
MacOS Xも普通にUnixなので,uptimeコマンドで確認できる.
実際に何時何分何秒に起動したかと,起動してからのシリアル値をとるには,次の様にする.
この1469977230はMon Aug 1 00:00:30 2016のことなので,現在時間との差分を求めればよい.
今現在をシリアル値で表示.
で差分を求める.
261125秒を日にちに変換してみる.
3日とでた.
sh-3.2# uptime
0:26 up 3 days, 26 mins, 1 user, load averages: 0.40 0.38 0.42
sh-3.2#
sh-3.2# sysctl -n kern.boottime
{ sec = 1469977230, usec = 0 } Mon Aug 1 00:00:30 2016
sh-3.2#
今現在をシリアル値で表示.
sh-3.2# date '+%s'
1470238355
sh-3.2#
sh-3.2# expr 1470238355 - 1469977230
261125
sh-3.2#
sh-3.2# expr 261125 / 24 / 3600
3
sh-3.2#
Windowsのタスクマネージャに相当するアクティビティモニターはアプリケーションフォルダのユーティリティフォルダの中にある.
それを起動してメモリの状態を見ると,こんな感じになっている.

これらを数値で取りたい.
まずは搭載しているメモリ.
これは4GBになる.
まずはスワップ.
アクティビティモニターではスワップ使用領域としてusedの値は表示されているが,確保されているサイズまでは表示されてない.
次にメモリ使用状況.これはtopコマンドから取り出してみた.
wiredが1142Mなので,「確保されているメモリ1.12GB」に近いか.4041Mがわからないのだけれど,53M unusedなので3,988MBとなる.
使用済みメモリ3.41GBとキャッシュされたファイル571.3MBを足すと,3891MBで近くなるか.100MBも差があるが...
それを起動してメモリの状態を見ると,こんな感じになっている.

これらを数値で取りたい.
まずは搭載しているメモリ.
MBA13:~ ujpadmin$ sysctl hw.memsize
hw.memsize: 4294967296
MBA13:~ ujpadmin$
まずはスワップ.
MBA13:~ ujpadmin$ sysctl vm.swapusage
vm.swapusage: total = 1024.00M used = 469.75M free = 554.25M (encrypted)
MBA13:~ ujpadmin$
次にメモリ使用状況.これはtopコマンドから取り出してみた.
MBA13:~ ujpadmin$ top -l 1 -s 0 | grep PhysMem
PhysMem: 4041M used (1142M wired), 53M unused.
MBA13:~ ujpadmin$
使用済みメモリ3.41GBとキャッシュされたファイル571.3MBを足すと,3891MBで近くなるか.100MBも差があるが...
インデックス検索されている場合は,インデックスはkey_buffer_sizeで指定されたメモリに展開されるので,最適な容量を考えてみる.
ということで,まず,全てのインデックスがメモリに乗るのかどうかを調べるため,インデックスのサイズを計算してみる.
このSQLは実行した時に選択されているデータベースに対してのインデックスサイズの総量です.単位はバイト数.これだと6MBなので余裕だな...
現在使っているKey_bufferを確認してみる.
1ブロックはデフォルトでは1024バイトなのだけれど一応確認してみる.
2382×1024=2,439,168byte=2.3MBでした.
現在の設定はこんな感じ.
256MBなので,これはメモリの無駄遣い.減らしましょう.10MBもあれば十分か.
キーのキャッシュヒット率を計算してみる.
キャッシュヒット率は次の式で計算.
あてはめてみる.
そりゃぁもう割り当てメモリ多すぎなので当然と言えば当然の結果.
今回,256MBから12MBに変更してみる.
ということで,まず,全てのインデックスがメモリに乗るのかどうかを調べるため,インデックスのサイズを計算してみる.
mysql> select sum(index_length) from information_schema.tables where table_schema=database();
+-------------------+
| sum(index_length) |
+-------------------+
| 6331392 |
+-------------------+
1 row in set (0.01 sec)
mysql>
現在使っているKey_bufferを確認してみる.
mysql> show status like "Key_blocks%";
+------------------------+--------+
| Variable_name | Value |
+------------------------+--------+
| Key_blocks_not_flushed | 0 |
| Key_blocks_unused | 229578 |
| Key_blocks_used | 2382 |
+------------------------+--------+
3 rows in set (0.01 sec)
mysql>
mysql> SHOW VARIABLES LIKE 'key_cache_block_size';
+----------------------+-------+
| Variable_name | Value |
+----------------------+-------+
| key_cache_block_size | 1024 |
+----------------------+-------+
1 row in set (0.00 sec)
mysql>
現在の設定はこんな感じ.
mysql> SHOW VARIABLES LIKE 'key_buffer_size';
+-----------------+-----------+
| Variable_name | Value |
+-----------------+-----------+
| key_buffer_size | 268435456 |
+-----------------+-----------+
1 row in set (0.00 sec)
mysql>
キーのキャッシュヒット率を計算してみる.
mysql> show status like "Key_read%";
+-------------------+---------+
| Variable_name | Value |
+-------------------+---------+
| Key_read_requests | 7587589 | ←キャッシュからの読み取り要求回数
| Key_reads | 242 | ←ディスクからの読み取り要求回数
+-------------------+---------+
2 rows in set (0.00 sec)
mysql>
100 - ( ( Key_reads / Key_read_requests ) * 100 )
100 - ( ( 242 / 7587589) * 100 ) = 99.999987%
今回,256MBから12MBに変更してみる.
psコマンドで,vsz(仮想メモリで割り当てた)とrss(実際に使っている物理メモリ)をリストしてみる.
なんと,スクリーンセイバーScreenSaverEngine_が11GBも仮想メモリを割り当てている.実際には20MBだけれど.
これは[システム環境設定]で,[スクリーンセイバーなし]に設定することでプロセスが終了しました.
sh-3.2# ps -eo vsz,rss,pid,comm|sort -nr|head -n 10|sed 's/\// /g'|
awk '{print $1" "$2" "$3" "$NF}'
11159160 20644 49879 ScreenSaverEngine
2791824 7760 45521 Kotoeri
2764208 16028 45420 WindowServer
2760908 11692 45492 SecurityAgent
2752628 6440 45397 loginwindow
2747344 10800 45475 ARDAgent
2744092 9984 45479 ManagedClient
2739224 4744 45484 TISwitcher
2725556 5988 45474 UserEventAgent
2710544 3736 45486 AppleVNCServer
sh-3.2#
これは[システム環境設定]で,[スクリーンセイバーなし]に設定することでプロセスが終了しました.
mysqladminでextended-statusを採ってみたら気になる値が.
テンポラリのテーブルがたくさんされているのは良いのだけれど,そのうちの幾つかがディスク上で実行されている.これを解消するしか無い.
まずは現在設定を確認.
明示的に指定が無い.サーバ上の設定を確認.
16,777,216byteなので16MBとして設定してある.倍の32MBにしてみる.
設定されたか確認.
sh-3.2# grep tmp mysql_extend-status.txt
| Created_tmp_disk_tables | 683 |
| Created_tmp_files | 0 |
| Created_tmp_tables | 32383 |
sh-3.2#
まずは現在設定を確認.
sh-3.2# grep table_size /etc/my.cnf
sh-3.2#
mysql> SHOW VARIABLES LIKE 'tmp_table_size';
+----------------+----------+
| Variable_name | Value |
+----------------+----------+
| tmp_table_size | 16777216 |
+----------------+----------+
1 row in set (0.00 sec)
mysql> SHOW VARIABLES LIKE 'max_heap_table_size';
+---------------------+----------+
| Variable_name | Value |
+---------------------+----------+
| max_heap_table_size | 16777216 |
+---------------------+----------+
1 row in set (0.00 sec)
mysql>
mysql> SET tmp_table_size=33554432;
Query OK, 0 rows affected (0.00 sec)
mysql> SET max_heap_table_size=33554432;
Query OK, 0 rows affected (0.00 sec)
mysql>
mysql> SHOW VARIABLES LIKE 'tmp_table_size';
+----------------+----------+
| Variable_name | Value |
+----------------+----------+
| tmp_table_size | 33554432 |
+----------------+----------+
1 row in set (0.00 sec)
mysql> SHOW VARIABLES LIKE 'max_heap_table_size';
+---------------------+----------+
| Variable_name | Value |
+---------------------+----------+
| max_heap_table_size | 33554432 |
+---------------------+----------+
1 row in set (0.00 sec)
mysql>
気になり始めたらどうしようもない.system.logにたくさんのログが.
根本原因はわからないのだけれど再起動で治ることもあるから様子見です.体調不良って感じだな.
Jul 30 11:53:58 ujp servermgrd[65]: -[AccountsRequestHandler(AccountsOpenDirectoryHelpers)
openLocalLDAPNodeIfNeeded]: dsLocalLDAP = (null), error = Error Domain=com.apple
.OpenDirectory Code=2000 UserInfo=0x1002c65f0 "Unable to open Directory node with name
/LDAPv3/127.0.0.1."
[c/ode]
servermgrdで検索しても何も情報が出てこないので,とりあえず再起動.
[code]sh-3.2# ps -ef|grep servermgrd
0 65 1 0 43:03.34 ?? 64:42.61 servermgrd -x
0 97757 95390 0 0:00.00 ttys001 0:00.00 grep servermgrd
sh-3.2#
sh-3.2# launchctl unload /System/Library/LaunchDaemons/com.apple.servermgrd.plist
sh-3.2# launchctl load /System/Library/LaunchDaemons/com.apple.servermgrd.plist
sh-3.2#
sh-3.2# ps -ef|grep servermgrd
0 97916 1 0 0:00.25 ?? 0:00.48 servermgrd -x
0 97936 95390 0 0:00.00 ttys001 0:00.00 grep servermgrd
sh-3.2#
プロセスでTIME順の一覧を次のように取り出してみた.
ディレクトリサービスがCPUを消費している.uptimeが15daysなので106時間というのは4.4時間.かなり多いと思う.不正アクセスを受けているから暴走ぎみなのか?
とりあえずリセットのための再起動.
sh-3.2# 🆑ps -ef|awk '{print $7" "$8}'|sort -nr|sed 's/:/ /'|grep -v "0 "| \
sed 's/\// /g'|sed 's/\./ /g'|awk '{print $1"."$2" "$NF}'
106.31 DirectoryService🈁
103.39 launchd
44.54 Finder
41.02 servermgrd
15.50 fseventsd
12.11 WindowServer
9.56 notifyd
6.55 SystemUIServer
6.15 launchd
5.40 emond
4.58 configd
1.45 syslogd
1.30 mDNSResponder
1.23 Dock
1.15 ARDAgent
1.02 coreservicesd
1.01 ntpd
1.00 snmpd
STIME.CMD CMD
sh-3.2#
とりあえずリセットのための再起動.
sh-3.2# 🆑launchctl unload /System/Library/LaunchDaemons/com.apple.DirectoryServices.plist
sh-3.2# 🆑launchctl load /System/Library/LaunchDaemons/com.apple.DirectoryServices.plist
sh-3.2# 🆑ps -ef|grep DirectoryService
0 41576 1 0 0:00.11 ?? 0:00.23 /usr/sbin/DirectoryService
0 41578 11815 0 0:00.00 ttys002 0:00.00 grep DirectoryService
sh-3.2#
MacOS X固有の全文検索機能のSpotlightですが,サーバなので止めます.
一旦,ルートディレクトリ以下をインデックス作成対象外とする.
プロセスを確認する.
これをkillする.
停止してもゾンビのように再起動されている.これでしばらくして,CPUタイムが増えないことを確認すれば良いかな.
sh-3.2# 🆑ps -ef|awk '{print $5" "$8}'|sort -nr|head -n 5
154:41.20 /System/Library/Frameworks/CoreServices.framework/Frameworks
/Metadata.framework/Support/mds🈁
144:18.38 /usr/local/mysql/bin/mysqld
106:13.69 /usr/sbin/DirectoryService
103:15.47 /sbin/launchd
44:41.00 /System/Library/CoreServices/Finder.app/Contents/MacOS/Finder
sh-3.2#
sh-3.2# 🆑mdutil -i off /
/:
Indexing disabled.
sh-3.2#
sh-3.2# 🆑ps -ef|grep mds
0 69 1 0 154:41.22 ?? 240:06.70 /System/Library/Frameworks/CoreServices.framework/Frameworks
/Metadata.framework/Support/mds
0 24685 11815 0 0:00.00 ttys002 0:00.00 grep mds
sh-3.2#
sh-3.2# 🆑kill 69
sh-3.2# 🆑ps -ef|grep mds
0 24686 1 0 0:00.09 ?? 0:00.19 /System/Library/Frameworks/CoreServices.framework/Frameworks
/Metadata.framework/Support/mds
0 24689 11815 0 0:00.00 ttys002 0:00.00 grep mds
sh-3.2#
プロセスを見てみた.
地味にsnmpdがCPU利用が多いようだ.とりあえずこれも再起動.
これで様子見かなぁ.
sh-3.2# 🆑ps -ef|awk '{print $5" "$8}'|sort -nr|head -n 10
194:43.27 snmpd🈁
154:39.88 /System/Library/Frameworks/CoreServices.framework
/Frameworks/Metadata.framework/Support/mds
144:07.71 /usr/local/mysql/bin/mysqld
106:12.78 /usr/sbin/DirectoryService
103:10.03 /sbin/launchd
44:33.92 /System/Library/CoreServices/Finder.app/Contents/MacOS/Finder
40:55.58 servermgrd
15:47.48 /System/Library/Frameworks/CoreServices.framework/Versions
/A/Frameworks/CarbonCore.framework/Versions/A/Support/fseventsd
11:58.31 /System/Library/Frameworks/ApplicationServices.framework/Frameworks
/CoreGraphics.framework/Resources/WindowServer
9:52.78 /usr/sbin/notifyd
6:50.80 /System/Library/CoreServices/SystemUIServer.app/Contents/MacOS
/SystemUIServer
sh-3.2#
sh-3.2# 🆑ps -ef|grep snmpd
0 51🈁 1 0 194:46.15 ?? 195:48.11 snmpd -f
0 20682 11815 0 0:00.00 ttys002 0:00.00 grep snmpd
sh-3.2# 🆑kill 51
sh-3.2# 🆑/usr/sbin/snmpd
sh-3.2# 🆑ps -ef|grep snmpd
0 20826 1 0 0:00.02 ?? 0:00.06 snmpd -f🈁
0 20833 11815 0 0:00.00 ttys002 0:00.00 grep snmpd
sh-3.2#
サーバの負荷が高いのだけれど,HTTPリクエストなどが多いわけでも無いので,プロセスを調べたらCPU timeが多いserialnumberdというプロセスが気に止まった.
たしかMacOS X Serverがライセンス認証のために動いているサーバプロセスだと思うのだけれど,とりあえずプロセスを再起動してみた.
まだまだこれで沈静化してない・・・
と思ってイラ,syslogに以下のようなエラーがたくさん...
作法に則って起動してなかったのでエラーになっいる模様.という事で異常状態で起動したserialnumberdを停止.
再開.
これで様子見.
sh-3.2# 🆑ps -ef|grep serialnumber
0 44409🈁 1 0 58:25.41 ?? 58:40.08 /usr/sbin/serialnumberd
0 12863 11815 0 0:00.00 ttys002 0:00.00 grep serialnumber
sh-3.2#
sh-3.2# 🆑kill 44409
sh-3.2# 🆑ps -ef|grep serialnumber
0 13022 11815 0 0:00.00 ttys002 0:00.00 grep serialnumber
sh-3.2# 🆑/usr/sbin/serialnumberd
sh-3.2# 🆑ps -ef|grep serialnumber
0 13024 1 0 0:00.01 ttys002 0:00.01 /usr/sbin/serialnumberd🈁
0 13026 11815 0 0:00.00 ttys002 0:00.00 grep serialnumber
sh-3.2#
と思ってイラ,syslogに以下のようなエラーがたくさん...
Jul 30 00:23:43 ujp sandboxd[25291]: serialnumberd(31993) deny file-read-data
/dev/dtracehelper
Jul 30 00:23:43 ujp sandboxd[25291]: serialnumberd(31993) deny file-read-data
/dev/autofs_nowait
Jul 30 00:23:43 ujp sandboxd[25291]: serialnumberd(31993) deny file-read-data
/usr/sbin
Jul 30 00:23:43 ujp /usr/sbin/serialnumberd[31993]: SN_Register(): New
persistent, network record [tag=xsvr, extra=ujp.jp] registered successfully
by pid 31993.
Jul 30 00:23:43 ujp /usr/sbin/serialnumberd[31993]: _CreateUDPSocket():
Could not bind() our socket, errno = 48 (Address already in use).
Jul 30 00:23:43 ujp com.apple.launchd[1] (com.apple.serialnumberd[31993]):
Exited with exit code: 69
Jul 30 00:23:43 ujp com.apple.launchd[1] (com.apple.serialnumberd): Throttling
respawn: Will start in 10 seconds
sh-3.2# 🆑ps -ef|grep serial
0 32517 11815 0 0:00.00 ttys002 0:00.00 grep serial
sh-3.2#
sh-3.2# 🆑launchctl load /System/Library/LaunchDaemons/com.apple.serialnumberd.plist
com.apple.serialnumberd: Already loaded
sh-3.2#
browserconfig.xmlを設置してみて,Windows 10にしてあるSurface Pro 2から当サイトにアクセス,そしてピン留めしてみたんだけれど,せっかく用意した画像ファイルも読み込まれずピン留めIEのデフォルトの青いまま.
何か設定がおかしいのかなぁと思って,実害は無いので放置しつつ,でも気にしながら過ごしていたのだけれど,埃をかぶっているWindows RT 8.1のSurface 2を引っ張り出してアクセスしてピン留めしたら,ちゃんと画像が使われました.

これって,Windows 8.1までの短命な仕様だったのだろうか? それとSurface Pro 2のWindows 10がオカシイだけなのか...ほかのWindows 10マシンを今作れないので,とても気になる...
何か設定がおかしいのかなぁと思って,実害は無いので放置しつつ,でも気にしながら過ごしていたのだけれど,埃をかぶっているWindows RT 8.1のSurface 2を引っ張り出してアクセスしてピン留めしたら,ちゃんと画像が使われました.

これって,Windows 8.1までの短命な仕様だったのだろうか? それとSurface Pro 2のWindows 10がオカシイだけなのか...ほかのWindows 10マシンを今作れないので,とても気になる...
エラーログ見ていて気づいていたのだけれど,browserconfig.xmlというリクエストが404エラーになっていて.
全く気にしていなかったのだけれど,ふと検索してみたら,Windows 8以降のタイル表示で,Internet Explorer 11からピン留めの時に使われる定義ファイルを読み込もうとしているアクセスなのだそうです.
技術的資料はこれ.
IE11 での Web サイト用カスタム タイルの作成
https://msdn.microsoft.com/ja-jp/library/dn455106(v=vs.85).aspx
それで,簡易的にピン留め設定を作るサイトをMicrosoftが用意していました.
Build a site tile
http://www.buildmypinnedsite.com
全く気にしていなかったのだけれど,ふと検索してみたら,Windows 8以降のタイル表示で,Internet Explorer 11からピン留めの時に使われる定義ファイルを読み込もうとしているアクセスなのだそうです.
技術的資料はこれ.
IE11 での Web サイト用カスタム タイルの作成
https://msdn.microsoft.com/ja-jp/library/dn455106(v=vs.85).aspx
それで,簡易的にピン留め設定を作るサイトをMicrosoftが用意していました.
Build a site tile
http://www.buildmypinnedsite.com
久々に,USER_AGENTでロボットによるアクセスを集計してみた.
抽出はこんな感じでざっくり.
集計した結果,こんな感じでした.
最近,Googleで検索しても思うような所に行き着かずショッピングモールにばかり誘導される感じがあるので,マイクロソフトのbingも試してみても良いかもしれない.結果は同じかもしれないけれど.
それと,一時期凄かったBaiduのbotからのアクセスが激減しています.日本からは検索エンジンとしては撤退しているからかな. robot.txtも無視するしあまりにも頻繁だから,例の魔法の言葉をMETAにでも入れようかと考えた頃もあったけれどね.
Wikipediaをみても,あまり好意的じゃないね.
https://ja.wikipedia.org/wiki/Baiduspider
最大の,BLEXBotはwebmeup.comというサービスが運営しているそうなので,無料でバックリンクのレポートが見られるというので行ってみたのだけれど,こんな結果でした.
完全な無駄足のようだ...
バックリンクというのは,当サイトへリンクしているWebページの事でGoogleのPageRankのように「みんなからよくリンクされているページは良いページ=有益」と判断されているので,このバックリンクがたくさんあると良いサイト率が高いといえるかな.
その集合知を前提としたバックリンクも,たとえば映画プロモーションサイトとか,一時的に使われ既に所有権を手放されたドメインを取得し,そこに誘導リンクを貼るスパムサイトを広告会社が運営して,検索エンジンのランキングを上げようとするSEO対策ももう古典化されていてあまり効果は無い模様.
抽出はこんな感じでざっくり.
cat access.log|awk '{print $14" "$15" "$16}'|sort|uniq -c|sort -nr
27.9% BLEXBot/1.0 有料SEO
26.7% bingbot/2.0 マイクロソフト
7.4% SemrushBot マーケティング会社
3.4% MJ12bot 世界最大の検索エンジン作成プロジェクト
6.0% Googlebot/2.1 グーグル
3.1% ltx71 不明
3.2% Configuration/CLDC-1.1
3.2% Googlebot-Mobile グーグル
1.1% Steeler/3.5 東京大学 喜連川研究室
0.4% Yahoo! Slurp ヤフー
0.2% proximic インターネット視聴率の測定会社
0.2% Baiduspider/2.0 中国の検索エンジン
0.1% GrapeshotCrawler マーケティング会社
それと,一時期凄かったBaiduのbotからのアクセスが激減しています.日本からは検索エンジンとしては撤退しているからかな. robot.txtも無視するしあまりにも頻繁だから,例の魔法の言葉をMETAにでも入れようかと考えた頃もあったけれどね.
Wikipediaをみても,あまり好意的じゃないね.
https://ja.wikipedia.org/wiki/Baiduspider
最大の,BLEXBotはwebmeup.comというサービスが運営しているそうなので,無料でバックリンクのレポートが見られるというので行ってみたのだけれど,こんな結果でした.
Sorry, there are no backlinks indexed for this site.
Please make sure you've entered the right URL.
バックリンクというのは,当サイトへリンクしているWebページの事でGoogleのPageRankのように「みんなからよくリンクされているページは良いページ=有益」と判断されているので,このバックリンクがたくさんあると良いサイト率が高いといえるかな.
その集合知を前提としたバックリンクも,たとえば映画プロモーションサイトとか,一時的に使われ既に所有権を手放されたドメインを取得し,そこに誘導リンクを貼るスパムサイトを広告会社が運営して,検索エンジンのランキングを上げようとするSEO対策ももう古典化されていてあまり効果は無い模様.
XOOPSのファイルをアップデートしていたら突然サイトが動かなく...そして事前にtarしていたと思っていたけれどまだ完了していなかった.
エラーを見てもさっぱりわからないので,絶望的だったけれど,直前までタイムマシンで戻れました.素晴らしい.
それで,去年のこの海の日も,サーバを設定していたんだな...とログから思い出したり.
エラーを見てもさっぱりわからないので,絶望的だったけれど,直前までタイムマシンで戻れました.素晴らしい.
それで,去年のこの海の日も,サーバを設定していたんだな...とログから思い出したり.
スパムユーザは海外のドメインを使っている場合が多くて,例えばロシアの.ruとかは,当サイトを使っているユーザは少ないと仮定できるので消す事ができるのだけれど,.comドメインとかだとスパムかどうか見てみないとわからない場合がある.
それでずっとリストを眺めていたのだけれど,ある法則に気づいた.
それでずっとリストを眺めていたのだけれど,ある法則に気づいた.
ユーザをドメイン毎に集計してみた.
目的は,スパムユーザの抽出.URLクリックに承認メールでログインできているユーザの中でも,大量登録によるスパムユーザと思われるユーザを推測.
目的は,スパムユーザの抽出.URLクリックに承認メールでログインできているユーザの中でも,大量登録によるスパムユーザと思われるユーザを推測.
XOOPSで一度もログイン完了してないユーザ.つまりほとんどの場合スパムユーザになるけれど,これを消す.
まずは,現在の件数を確認.
XOOPSのユーザテーブルのlast_loginはログイン時のシリアル値が設定してあるので,これが0だとログインしてない事になる.
さくっと消す.
まずは,現在の件数を確認.
mysql> select count(*) from XOOPS__users where last_login=0;
+----------+
| count(*) |
+----------+
| 2503 |
+----------+
1 row in set (0.01 sec)
mysql>
さくっと消す.
mysql> delete from XOOPS__users where last_login=0;
Query OK, 2503 rows affected (0.23 sec)
mysql> select count(*) from XOOPS__users where last_login=0;
+----------+
| count(*) |
+----------+
| 0 |
+----------+
1 row in set (0.01 sec)
mysql>
デートを取っている期間が短いので,ビフォア,アフターで差分が出ないけれど,MRTGでステータスを取った結果をグラフ化してみたのがこんな感じ.

11時頃にSelect_scan(青色)の線が跳ねているけれど,これは幾つかのcreate indexを実行したので,当然と言えば当然.
全表走査の「回数」が減ったかというと,そうならなかった.調べてみた方法と対策のメモ.

11時頃にSelect_scan(青色)の線が跳ねているけれど,これは幾つかのcreate indexを実行したので,当然と言えば当然.
全表走査の「回数」が減ったかというと,そうならなかった.調べてみた方法と対策のメモ.
MySQLでSelect_scanが多いというのが分かったので,とりあえずスローログを記録するように設定.
vi /etc/my.cnfでmysqldセクションに追加.
反映させるためにMySQLを再起動.
これでslow.logファイルを見てみる.
一瞬ですごく溜まっている・・・
vi /etc/my.cnfでmysqldセクションに追加.
[mysqld]
#20160716 no index log
log_queries_not_using_indexes=1
slow_query_log=1
slow_query_log_file=/db/DBfile/slow.log
long_query_time=0.5
/usr/local/mysql/support-files
sh-3.2# cd /usr/local/mysql/support-files
sh-3.2#
sh-3.2# ./mysql.server stop
Shutting down MySQL
.. SUCCESS!
sh-3.2# ./mysql.server start
Starting MySQL
. SUCCESS!
sh-3.2#
sh-3.2# ls -la /db/DBfile/slow.log
-rw-rw---- 1 _mysql admin 30943 Jul 16 12:36 /db/DBfile/slow.log
sh-3.2#
最近はCactiを使っている人が多いと思うけれど,詳細な履歴までは不要なのでまだMRTGを使っている.
それでちょっと遅い事に気づいたので測ってみた.
18秒というのは遅すぎる.SNMPでデータを取得する場合に遅いとは思えないので,外部コマンドを呼びだしている要素についてtimeコマンドで実行時間を調べてみた.
まずは,温度データ取得が重い.
もう1つ,Time Machine関連データの取得も遅い.
温度とTime Machineのデータ取得を止めて,コマンドを実行.
12秒削減.取り外したやつは別タイミングで実行かな.
それでちょっと遅い事に気づいたので測ってみた.
sh-3.2# time /opt/local/bin/mrtg /usr/local/mrtg-2/data/mrtg.cfg
real 0m18.321s
user 0m5.619s
sys 0m4.360s
sh-3.2#
まずは,温度データ取得が重い.
sh-3.2# time /www/system/bin/MRTG_Temperature.sh
70
39
0
0
real 0m2.025s
user 0m0.045s
sys 0m1.454s
sh-3.2#
sh-3.2# time /www/system/bin/MRTG_timecapsuleBridge.sh
1710721156
1280836451
0
0
real 0m1.083s
user 0m0.104s
sys 0m0.113s
sh-3.2#
sh-3.2# time /opt/local/bin/mrtg /usr/local/mrtg-2/data/mrtg1.cfg
real 0m6.774s
user 0m3.818s
sys 0m0.516s
sh-3.2#
使ってないのにいつの間にか起動と終了を繰り返していたので,namedを停止.
10秒おきにログが吐き出されて,見るのが面倒.
launchctl unload /System/Library/LaunchDaemons/org.isc.named.plist
会社が潰れたときに.ほぼ現物支給の3000円で購入した,液晶が壊れたMacBook Air 2011があるのだけれど,これを次世代サーバにする.
液晶が割れている事以外は不具合はないのだけれどなぁ.修理は結構高いし.
液晶が割れている事以外は不具合はないのだけれどなぁ.修理は結構高いし.
404がたくさん😆出ているので,iPhone用のアイコンを設置してみた.とりあえず,3つのエラーがでていたので,これらを設置.
apple-touch-icon.png
apple-touch-icon-120x120.png
apple-touch-icon-precomposed.png
全部同じものだけどね.😎
一応,Apple的に仕様書があるようだ.もっとデザインに凝るのだったら,iOSのバージョンによって影がついたり色々と変更されるので,それに合わせて設置するというのがセオリーらしいけれど,うちのサイトはスマホは,ちょっとだけ対応状態なので,あまりアイコンについて考えてません.
App Icon
https://developer.apple.com/ios/human-interface-guidelines/graphics/app-icon/#//apple_ref/doc/uid/TP40006556-CH27
apple-touch-icon.png
apple-touch-icon-120x120.png
apple-touch-icon-precomposed.png
全部同じものだけどね.😎
一応,Apple的に仕様書があるようだ.もっとデザインに凝るのだったら,iOSのバージョンによって影がついたり色々と変更されるので,それに合わせて設置するというのがセオリーらしいけれど,うちのサイトはスマホは,ちょっとだけ対応状態なので,あまりアイコンについて考えてません.
App Icon
https://developer.apple.com/ios/human-interface-guidelines/graphics/app-icon/#//apple_ref/doc/uid/TP40006556-CH27