UJP - サイト運営カテゴリのエントリ

不正IP報告数

Okan Sensor
 
メイン
ログイン
ブログ カテゴリ一覧

  • カテゴリ サイト運営 の最新配信
  • RSS
  • RDF
  • ATOM

ブログ - サイト運営カテゴリのエントリ

 技術記事を書くときに導入しているXPwikiで,アクセスするとDB ERROR!: Please initialize an attach file database on an administrator screen.がでるようになった.  原因はわからないけれど,管理ツールのデータベースのシンクロナイズを行えば良い・・・とあるけれど,その管理ツールがない!!  それで,よくよく見ると記事が削除されているものがあったので再構築.権限があまかったようだ...

/etc/postfix/accessでアクセス制御

カテゴリ : 
サイト運営
ブロガー : 
ujpblog 2017/3/16 1:17
 メール配送を許可するIPアドレスと拒否するドメインを指定してみる.

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#
 postfixの再起動は不要.事前にmain.cfのsmtpd_client_restrictionsに指定しておく.
 アクセスログから,クライアントIPアドレス毎に集計して,そのトップ10だけを表示して見る.
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は,ウクライナからの不正アクセス...

AWSの中国リージョンからの

カテゴリ : 
サイト運営
ブロガー : 
ujpblog 2016/11/8 1:41
 1ヶ月ほど前だけれど,不正アクセス監視アラートがでて,調べたらAWSの中国リージョンだった.

cn.north.1.compute.amazonaws.com.cn

 AWSからの不正アクセスをグラフ化しているのだけれど,着実に増えています.


 ちなみにこれはユニーク数を取っていて同じアドレスからのアクセスはブロックしています.

 さくらインターネットも同時に関ししているけれど,一時期のような勢いはないね.みんなAWSに移っていったのかな.
 1週間ほど前にいれた,てーあんもんキーワードの効果測定.


 グラフを見ると減った!様に思うけれど,ただの三連休だから,言われるほどの効果はなかったと言えるかな.
 大量にアクセスがあるcnドメインからのアクセスを止めるおまじない,てーあんもん事件をキーワードに入れてみる.

 実際には,CMS上のヘッダにHTMLコメントとして.どれくらい効果があるのだろう?
 1ヶ月ほど前にセキュリティ対策でサーバを再起動する事があったので,そのタイミングでエコワットを出動さえてみた.


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

不正ログインを停めてみた結果

カテゴリ : 
サイト運営
ブロガー : 
ujpblog 2016/8/31 1:34
 不正なアクセスを検知したら,直後にブロックするシステムを運営中.それでどれくらいブロックされているかグラフで表現してみた.(青い線.緑はルール数)


 青いグラフが,ブロックしたログの行数.現在のログローテーションはログファイルが一定数になったらログスイッチしているので,青いグラフをみてのとおり高さは同じところを示している.

 つまり,ログスイッチが発生する一定容量までの到達時間によって,ブロックしたIPアドレスからの再攻撃されている様が解るようになっている.

 この動きを見ると,ブロックしたところで,それを検知して攻撃対象を変える様なことはしてない模様.単純に総当たり攻撃ですね.
 グラフの傾斜が緩やかな日もあるけれど,これは土日が絡む事が多いです.つまり,平日に使っているパソコンが意図せず攻撃をコントロールされていて,使用をやめると攻撃も停止するということなのだろうと推察します.

wp-loginへのアクセス

カテゴリ : 
サイト運営
ブロガー : 
ujpblog 2016/8/25 1:48
 名前からしてWordPressのログイン用のURLなんだけれど,WordPressを提供してないのにこのページにダイレクトにアクセスしてくるIPアドレスは,ブロック対象だろうね.

 WordPressは有名なのでわかるけれど,それ以外でもログインページに短時間ダイレクトにアクセスしてくる統一なブロック方法はないものだろうか.まぁにloginでログを引っ掛ければ良いのかなぁ.
 ログインしてないとTime Machineでバックアップしてくれないというので,コンソール画面からログインしてなくてもディスクをマウントすれば良いのでは?と思い立つ.
 /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#
 現在,/だけなので内蔵HDDしかマウントされてない.接続されているハードドライブを確認する.
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#
 disk1が認識されている.ここで,約320GBのJunoTMというボリュームがある.これをマウントしたいときは,disk1s3を指定する.disk1のスライス3番という事ね.こういうところを見るとUnixを感じるねぇ...
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#
 認識されてますね.

Time Machineをログアウトしていても動かす

カテゴリ : 
サイト運営
ブロガー : 
ujpblog 2016/8/22 21:24
 backupedプロセスのCPU Timeを測ってみたら,このようにどの曜日の夜中から動かなくなった.


 これは,Time Machineを使う設定をしているユーザがログインしてないと,backupedが動かないから.つまり,そのないだはバックアップされてない.

 サーバで動かす場合それは困るので,バックアップを取るように設定する.

sh-3.2# defaults write /Library/Preferences/SystemConfiguration/autodiskmount 
 AutomountDisksWithoutUserLogin -bool yes
sh-3.2#
 実際には1行で.オフにするときはこれ.

$ 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ストレージがインデックス対象になったのかも...

 という事で,プロセスを確認.
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#
 36分も使っている.
 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/>
このKeepAliveがtrueになっているので,falseにする.
        <key>KeepAlive</key>
        <false/>
 これでOS起動時にもmdsが起動してこないでしょう.多分.

MySQLのkey_buffer_sizeを考える その2

カテゴリ : 
サイト運営
ブロガー : 
ujpblog 2016/8/14 13:39
 以前,考察してから2週間経過した.
 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>
10MB.
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%
 前回99.999987%だったのだけれど,誤差の範囲だと思います.劣化して無い.
 ブロックの利用数を見る.
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>
 Key_blocks_usedが増えているけれど,圧倒的にKey_blocks_unusedが多かった分が減っているので最適化終了という感じで.

 ちなみに,再起動時からのメモリ容量.まずは再起動直後.
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:~$
 VSZ(仮想メモリサイズ)は起動直後も14.5日経過後もあまり変わらない.14.5日経過後のVSZが830944ブロックなので1ブロックは4096byteなので計算すると,約3.2GB.
 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#
 VSZが4GBで,RSSが130MB.このRSSが増えたのは,sort_bufferを変更した別の要因ですね.

mds その2

カテゴリ : 
サイト運営
ブロガー : 
ujpblog 2016/8/9 0:29
 全文検索のSpotlightのバックグラウンドサービスであるmdsがサーバで動いていたので,mdsを停止してみたのだけれど,その後OSを再起動したからか,まだCPUを消費している様である.
 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#
 そして前回と同じ様にmdsを停止してみた.
sh-3.2# mdutil -i off /
/:
	Indexing and searching disabled.
sh-3.2#

MRTGのgaugeとabsolute

カテゴリ : 
サイト運営
ブロガー : 
ujpblog 2016/8/7 1:04
CPUタイムをカウントしているのだけれど,使い分け的に見えてきた.

gauge
 httpdを監視する時に良い.プロセスに寿命が設定されているのと複数起動していてそれを合計しているタイプ.

absolute
 mysqldを監視する時に良い.ずっと1つのプロセスが起動しているタイプ.

Macを起動してからの時間

カテゴリ : 
サイト運営
ブロガー : 
ujpblog 2016/8/4 0:36
 MacOS Xも普通にUnixなので,uptimeコマンドで確認できる.
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#
 この1469977230はMon Aug 1 00:00:30 2016のことなので,現在時間との差分を求めればよい.
 今現在をシリアル値で表示.
sh-3.2# date '+%s'
1470238355
sh-3.2#
 で差分を求める.
sh-3.2# expr 1470238355 - 1469977230
261125
sh-3.2#
 261125秒を日にちに変換してみる.
sh-3.2# expr 261125 / 24 / 3600
3
sh-3.2#
 3日とでた.

Macのメモリデータを取る

カテゴリ : 
サイト運営
ブロガー : 
ujpblog 2016/8/1 1:31
 Windowsのタスクマネージャに相当するアクティビティモニターはアプリケーションフォルダのユーティリティフォルダの中にある.
 それを起動してメモリの状態を見ると,こんな感じになっている.


 これらを数値で取りたい.

 まずは搭載しているメモリ.
MBA13:~ ujpadmin$ sysctl hw.memsize
hw.memsize: 4294967296
MBA13:~ ujpadmin$
 これは4GBになる.
 まずはスワップ.
MBA13:~ ujpadmin$ sysctl vm.swapusage
vm.swapusage: total = 1024.00M  used = 469.75M  free = 554.25M  (encrypted)
MBA13:~ ujpadmin$
 アクティビティモニターではスワップ使用領域としてusedの値は表示されているが,確保されているサイズまでは表示されてない.
 次にメモリ使用状況.これはtopコマンドから取り出してみた.
MBA13:~ ujpadmin$ top -l 1 -s 0 | grep PhysMem
PhysMem: 4041M used (1142M wired), 53M unused.
MBA13:~ ujpadmin$
 wiredが1142Mなので,「確保されているメモリ1.12GB」に近いか.4041Mがわからないのだけれど,53M unusedなので3,988MBとなる.
 使用済みメモリ3.41GBとキャッシュされたファイル571.3MBを足すと,3891MBで近くなるか.100MBも差があるが...

MySQLのkey_buffer_sizeを考える

カテゴリ : 
サイト運営
ブロガー : 
ujpblog 2016/7/31 23:19
 インデックス検索されている場合は,インデックスはkey_buffer_sizeで指定されたメモリに展開されるので,最適な容量を考えてみる.
 ということで,まず,全てのインデックスがメモリに乗るのかどうかを調べるため,インデックスのサイズを計算してみる.

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>
 このSQLは実行した時に選択されているデータベースに対してのインデックスサイズの総量です.単位はバイト数.これだと6MBなので余裕だな...
 現在使っている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>
 1ブロックはデフォルトでは1024バイトなのだけれど一応確認してみる.
mysql> SHOW VARIABLES LIKE 'key_cache_block_size';
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| key_cache_block_size | 1024  |
+----------------------+-------+
1 row in set (0.00 sec)

mysql>
 2382×1024=2,439,168byte=2.3MBでした.
 現在の設定はこんな感じ.
mysql> SHOW VARIABLES LIKE 'key_buffer_size';
+-----------------+-----------+
| Variable_name   | Value     |
+-----------------+-----------+
| key_buffer_size | 268435456 |
+-----------------+-----------+
1 row in set (0.00 sec)

mysql>
 256MBなので,これはメモリの無駄遣い.減らしましょう.10MBもあれば十分か.
 キーのキャッシュヒット率を計算してみる.
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に変更してみる.

メモリを使っているプロセスを確認

カテゴリ : 
サイト運営
ブロガー : 
ujpblog 2016/7/31 17:53
psコマンドで,vsz(仮想メモリで割り当てた)とrss(実際に使っている物理メモリ)をリストしてみる.

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#
 なんと,スクリーンセイバーScreenSaverEngine_が11GBも仮想メモリを割り当てている.実際には20MBだけれど.
 これは[システム環境設定]で,[スクリーンセイバーなし]に設定することでプロセスが終了しました.

Created_tmp_tables

カテゴリ : 
サイト運営
ブロガー : 
ujpblog 2016/7/31 17:32
 mysqladminでextended-statusを採ってみたら気になる値が.
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>
 16,777,216byteなので16MBとして設定してある.倍の32MBにしてみる.
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>

servermgrd

カテゴリ : 
サイト運営
ブロガー : 
ujpblog 2016/7/30 13:51
 気になり始めたらどうしようもない.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# 
 根本原因はわからないのだけれど再起動で治ることもあるから様子見です.体調不良って感じだな.

DirectoryService

カテゴリ : 
サイト運営
ブロガー : 
ujpblog 2016/7/30 1:14
 プロセスでTIME順の一覧を次のように取り出してみた.

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#
 ディレクトリサービスがCPUを消費している.uptimeが15daysなので106時間というのは4.4時間.かなり多いと思う.不正アクセスを受けているから暴走ぎみなのか?

 とりあえずリセットのための再起動.
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#

mds

カテゴリ : 
サイト運営
ブロガー : 
ujpblog 2016/7/30 0:01
 MacOS X固有の全文検索機能のSpotlightですが,サーバなので止めます.
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#
 これをkillする.
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#
 停止してもゾンビのように再起動されている.これでしばらくして,CPUタイムが増えないことを確認すれば良いかな.

snmpd

カテゴリ : 
サイト運営
ブロガー : 
ujpblog 2016/7/29 23:39
 プロセスを見てみた.
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#
 地味にsnmpdがCPU利用が多いようだ.とりあえずこれも再起動.
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#
 これで様子見かなぁ.

/usr/sbin/serialnumberd

カテゴリ : 
サイト運営
ブロガー : 
ujpblog 2016/7/29 23:16
サーバの負荷が高いのだけれど,HTTPリクエストなどが多いわけでも無いので,プロセスを調べたらCPU timeが多い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#
 たしかMacOS X Serverがライセンス認証のために動いているサーバプロセスだと思うのだけれど,とりあえずプロセスを再起動してみた.
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
 作法に則って起動してなかったのでエラーになっいる模様.という事で異常状態で起動したserialnumberdを停止.
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#
 これで様子見.

Windows8からのピン留めタイルファイル その2

カテゴリ : 
サイト運営
ブロガー : 
ujpblog 2016/7/27 23:42
 browserconfig.xmlを設置してみて,Windows 10にしてあるSurface Pro 2から当サイトにアクセス,そしてピン留めしてみたんだけれど,せっかく用意した画像ファイルも読み込まれずピン留めIEのデフォルトの青いまま.
 何か設定がおかしいのかなぁと思って,実害は無いので放置しつつ,でも気にしながら過ごしていたのだけれど,埃をかぶっているWindows RT 8.1のSurface 2を引っ張り出してアクセスしてピン留めしたら,ちゃんと画像が使われました.


 これって,Windows 8.1までの短命な仕様だったのだろうか? それとSurface Pro 2のWindows 10がオカシイだけなのか...ほかのWindows 10マシンを今作れないので,とても気になる...

Windows8からのピン留めタイルファイル

カテゴリ : 
サイト運営
ブロガー : 
ujpblog 2016/7/25 23:54
 エラーログ見ていて気づいていたのだけれど,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

bot,crawlerを調べてみた2016年7月

カテゴリ : 
サイト運営
ブロガー : 
ujpblog 2016/7/21 23:28
 久々に,USER_AGENTでロボットによるアクセスを集計してみた.
 抽出はこんな感じでざっくり.
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 マーケティング会社
 最近,Googleで検索しても思うような所に行き着かずショッピングモールにばかり誘導される感じがあるので,マイクロソフトのbingも試してみても良いかもしれない.結果は同じかもしれないけれど.
 それと,一時期凄かった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対策ももう古典化されていてあまり効果は無い模様.

タイムマシンに救われた

カテゴリ : 
サイト運営
ブロガー : 
ujpblog 2016/7/18 19:39
 XOOPSのファイルをアップデートしていたら突然サイトが動かなく...そして事前にtarしていたと思っていたけれどまだ完了していなかった.
 エラーを見てもさっぱりわからないので,絶望的だったけれど,直前までタイムマシンで戻れました.素晴らしい.

 それで,去年のこの海の日も,サーバを設定していたんだな...とログから思い出したり.

XOOPSでスパムユーザにある特徴を発見

カテゴリ : 
サイト運営
ブロガー : 
ujpblog 2016/7/17 18:46
 スパムユーザは海外のドメインを使っている場合が多くて,例えばロシアの.ruとかは,当サイトを使っているユーザは少ないと仮定できるので消す事ができるのだけれど,.comドメインとかだとスパムかどうか見てみないとわからない場合がある.

 それでずっとリストを眺めていたのだけれど,ある法則に気づいた.

...続きを読む

 ユーザをドメイン毎に集計してみた.
 目的は,スパムユーザの抽出.URLクリックに承認メールでログインできているユーザの中でも,大量登録によるスパムユーザと思われるユーザを推測.

...続きを読む

 XOOPSで一度もログイン完了してないユーザ.つまりほとんどの場合スパムユーザになるけれど,これを消す.
 まずは,現在の件数を確認.
mysql> select count(*) from XOOPS__users where last_login=0;
+----------+
| count(*) |
+----------+
|     2503 |
+----------+
1 row in set (0.01 sec)

mysql>
 XOOPSのユーザテーブルのlast_loginはログイン時のシリアル値が設定してあるので,これが0だとログインしてない事になる.
 さくっと消す.
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を実行したので,当然と言えば当然.
 全表走査の「回数」が減ったかというと,そうならなかった.調べてみた方法と対策のメモ.

...続きを読む

MySQLのスローログを取る

カテゴリ : 
サイト運営
ブロガー : 
ujpblog 2016/7/16 12:37
 MySQLでSelect_scanが多いというのが分かったので,とりあえずスローログを記録するように設定.

 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
 反映させるためにMySQLを再起動.
/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#
 これでslow.logファイルを見てみる.
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#
 一瞬ですごく溜まっている・・・

MRTGを高速化する

カテゴリ : 
サイト運営
ブロガー : 
ujpblog 2016/7/16 12:02
 最近はCactiを使っている人が多いと思うけれど,詳細な履歴までは不要なのでまだMRTGを使っている.
 それでちょっと遅い事に気づいたので測ってみた.

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#
 18秒というのは遅すぎる.SNMPでデータを取得する場合に遅いとは思えないので,外部コマンドを呼びだしている要素についてtimeコマンドで実行時間を調べてみた.
 まずは,温度データ取得が重い.
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#
 もう1つ,Time Machine関連データの取得も遅い.
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#
 温度とTime Machineのデータ取得を止めて,コマンドを実行.
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#
12秒削減.取り外したやつは別タイミングで実行かな.

namedを停止

カテゴリ : 
サイト運営
ブロガー : 
ujpblog 2016/7/15 0:57
 使ってないのにいつの間にか起動と終了を繰り返していたので,namedを停止.

launchctl unload /System/Library/LaunchDaemons/org.isc.named.plist
 10秒おきにログが吐き出されて,見るのが面倒.

新しいサーバはMacBook Air 13インチ 2011年を使う

カテゴリ : 
サイト運営
ブロガー : 
ujpblog 2016/7/14 23:52
 会社が潰れたときに.ほぼ現物支給の3000円で購入した,液晶が壊れたMacBook Air 2011があるのだけれど,これを次世代サーバにする.
 液晶が割れている事以外は不具合はないのだけれどなぁ.修理は結構高いし.

apple-touch-icon.png設置してみた

カテゴリ : 
サイト運営
ブロガー : 
ujpblog 2016/7/14 1:02
 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

広告スペース
Google