モーグルとカバとパウダーの日記 このページをアンテナに追加 RSSフィード Twitter

モーグルやカバ(EXカービングスキー)、山スキー(BC)の山行記録などがメインの日記です。
いろんな条件のいろんなところを、その時々の条件にあった滑り方で楽しむ、フリースキーをして遊んでいます。

検索で来られた方は、上の検索窓から再度検索していただくか、右サイドバーのカテゴリーやトピックスの項目で絞り込んでみてください。
仕事柄、コンピュータ系のネタも多いので、スキー関連ネタだけ読みたい方は[ski]、コンピュータ関連ネタは[pc]、スパム関連ネタは[spam]で絞り込んでください。

2017-10-11 (Wed)

[]httpsのサイトがChromeのみ「このサイトへの接続は完全には保護されていません」と言われる httpsのサイトがChromeのみ「このサイトへの接続は完全には保護されていません」と言われるを含むブックマーク httpsのサイトがChromeのみ「このサイトへの接続は完全には保護されていません」と言われるのブックマークコメント

httpsのページだとURLの横のところに、保護されたページであることを示す「緑の鍵」マークが表示されるようになります。


とあるページをChromeで見ると、httpsのページなのですが「緑の鍵マーク」ではなく、「灰色の(i)マーク」となっており、ここをクリックすると

このサイトへの接続は完全には保護されていません

と表示されるものがありました。


ただ、FirefoxIEで見ると問題がなく保護されたページとして表示されていました。


ChromeのDeveloper ToolsでSecurityタグを確認したところ

Non-secure form

The page includes a form with a non-secure "action" attribute.

と書かれていました。


そこでHTMLソースを確認すると

<form name="tmp_gsearch" action="http://example.jp/search/result.html">

となっているところがありました。


Chromeの場合、ここで「action」に指定されている先が「https」ではなく「http」のため、この表示が出てしまうようです。

つまり、現在危ないのではないけど、ここからなにか操作したら漏れるから危険、ということですね。

トラックバック - http://d.hatena.ne.jp/stealthinu/20171011

2017-09-26 (Tue)

[]MRTGなどでSNMPからCPU使用率を得る MRTGなどでSNMPからCPU使用率を得るを含むブックマーク MRTGなどでSNMPからCPU使用率を得るのブックマークコメント

MRTGCPUロードアベレージではなくCPU使用率を表示したい場合、ネットを検索するとSNMP

  • ssCpuRawUser.0(.1.3.6.1.4.1.2021.11.50.0) → ユーザCPU使用率
  • ssCpuRawSystem.0(.1.3.6.1.4.1.2021.11.52.0) → システムCPU使用率

で取れるという話が出てきます。


これをsnmpwalkで確認すると

$ snmpwalk -c example -v 2c localhost .1.3.6.1.4.1.2021.11.50.0
UCD-SNMP-MIB::ssCpuRawUser.0 = Counter32: 1043492

となにやらよくわからん数字が出てきてほんとにいいのか…?という気になります。


で、この話を調べていくと最初に詳細書かれた方のエントリがあるのですが、すでにサイトがなくなっていて参照できなくなっていました。

なのでWaybackMachineで探して読んでみました。


Net-SNMP & MRTGCPU使用率 - 空振り日誌

https://web.archive.org/web/20070312134025/http://www.strikeout.jp:80/karaburi/2004/08/netsnmp_mrtgcpu_1.html

Net-SNMPのUCD-SNMP-MIB::ssCpuUserなどでCPU使用率[%]を取得したいけどDeprecatedになってるし、そもそも正しい値じゃなさそうだ。じゃあどうしたらいいのだろう。

CPU使用率[%]を単位時間あたりに消費されたCPU時間の割合と考える。その上でNet-SNMPMRTGCPU使用率を取得するには、

  • UCD-SNMP-MIBのssCpuRaw〜がCPU時間の累積を表しているので、これを利用する
  • ssCpuRaw〜のカウンタ値の単位はtickらしい。Linuxでは1tick=10msらしい†1
  • MRTGサンプリング時間は300秒(5分)†2で 300 * 1000[ms]だ
  • なので300,000ms間でCPU時間が何ms消費されたか分かればCPU使用率が出せる

以上を踏まえて、MRTGデフォルト計算式は以下になるので

(今回の値 - 前回の値) / サンプリング時間

これをssCpuRawUserを例にして当てはめると

(今回のssCpuRawUserの値 - 前回のssCpuRawUserの値)[tick] / サンプリング時間[s]

= CPUタイム[tick] / サンプリング時間[s]

となる。これを以下のように計算する。

= CPUタイムT[tick] / サンプリング時間S[s] … (1)

= T*10[ms] / S*1000[ms] … 単位をmsにあわせる

= T / 100S … 約分する。ここまでCPU消費時間の割合が出る

= T / 100S * 100 … 百分率(%)で表したいので100をかける

= T / S … (2)

= CPU使用率[%]

結果的に(1)と(2)は同じ式になり、MRTGデフォルト計算でCPU使用率が求められる。MRTGの設定としてはOptionsにguageも absoluteも指定しなければよい。ただ、これは1tick=10msだというのが前提なので、Kernelの設定なんかでこれが変更できたりする場合は適用できない。

前提条件がちょっと怪しいけど、vmstatを5分間隔で実行しときの結果とCPU使用率がほぼ同じになるので、これで良しとしている。


ということで、そのままMRTGに渡してやれば使えるようになってるとのことでした。

なので下記のように設定すれば良いようです。


mrtg.cfg 一部抜粋

Target[cpu_use]: .1.3.6.1.4.1.2021.11.50.0&.1.3.6.1.4.1.2021.11.52.0:example@localhost
MaxBytes[cpu_use]: 100
Options[cpu_use]: growright, noinfo, nopercent

(参考)

MRTGによるサーバ監視(SuSE編)

http://www.aconus.com/~oyaji/suse/mrtg_suse.htm

トラックバック - http://d.hatena.ne.jp/stealthinu/20170926

2017-09-19 (Tue)

[]vagrantのVMファイルサイズを縮小する vagrantのVMファイルサイズを縮小するを含むブックマーク vagrantのVMファイルサイズを縮小するのブックマークコメント

今どきHDDの容量不足に苦しむことはあまりないと思いますが、SSDだけのマシンで多数のVMを動かしている場合なんかだと、容量不足であたらしいVMが立てられない… という悲しい状況に陥ることもあると思います。


開発用VM群の中で一台のVMが突出して容量を食っており、調べてみたところそのVMで使ってるMySQL上にアクセスログのような消しても良い、大量のデータが載っており、それを消せば何10Gか減らせることがわかりました。


しかし、実際にVMのファイルサイズが縮小されるまでには結構な手数と時間がかかったのでその手順をまとめました。


この例ではVMの名前やUUID(仮想サーバや仮想ディスクを指定するためのユニークID)が下記のようになっていたとします。

  • vagrantの仮想サーバ名「example」
  • 「example」のVirtualBoxディレクトリ名「example_default_12345」
  • 「example」のサーバUUID名「5612d588-c7f6-48c0-8ac1-0c20a541d030」
  • 「example」の元の仮想ディスクUUID名「1759a61c-7445-4c58-af32-540c348c4ff6」
  • 変換後の仮想ディスクUUID名「fcccb41b-2ed1-46c1-bb37-308610cc1229」

MySQLデータベースファイルサイズを小さくする

VM内の不要なファイルや、データベース内の不要なデータを削除します。


truncateでテーブルを消してしまえばそれだけでファイルサイズが小さくなるそうです。

しかし、deleteでテーブル自体を残してデータだけを消した場合、データベースファイルのサイズはそのままで、小さくなりません

その場合、MySQLOPTIMIZEコマンドで削除されたデータの分を詰めて小さくします


VirtualBoxクライアント上の、MySQLroot

mysql> OPTIMIZE TABLE example_table;

この処理は結構な時間がかかります。


(参考)

第35回 OPTIMIZE TABLEでテーブル最適化する:MySQL道普請便り|gihyo.jp … 技術評論社

http://gihyo.jp/dev/serial/01/mysql-road-construction-news/0035


使われなくなった領域を0で埋める

仮想ディスクを縮小する際に、使われていない部分の値が「0」である必要があります

単にファイルを削除しただけではこの状況にならないため、ディスク空き容量全体を「0」で埋めて、そのファイルを消すことで、空き容量全体の中身を空にします


VirtualBoxクライアント上のroot

# dd if=/dev/zero of=zero bs=4k; \rm zero

この処理は結構な時間がかかります。


(参考)

仮想ディスクの圧縮 | VirtualBox Mania

http://vboxmania.net/content/%E4%BB%AE%E6%83%B3%E3%83%87%E3%82%A3%E3%82%B9%E3%82%AF%E3%81%AE%E5%9C%A7%E7%B8%AE


縮小可能な仮想ディスク形式に変換する

vagrantでマシンを生成するとVMDK形式の仮想ディスクになりますが、このVMDK形式だとディスクサイズを縮小することが出来ません

そこで縮小が可能なVDI形式の仮想ディスクへ変換してやる必要があります


VirtualBoxホスト上で、該当のディスクの情報を取得し、VDI形式に変換した仮想ディスクを新たに作成

$ vboxmanage list hdds
..略
UUID:           1759a61c-7445-4c58-af32-540c348c4ff6
Location:       /home/example/VirtualBox VMs/example_default_12345/_centos-6.6-x86_64-disk1.vmdk
Storage format: VMDK
..略

$ vboxmanage clonehd 1759a61c-7445-4c58-af32-540c348c4ff6 \
  "/home/example/VirtualBox VMs/example_default_12345/example-2.vdi" --format vdi

この処理は結構な時間がかかります。


また、一時的に同サイズの仮想ディスクが作られるため、そのファイルを作れるだけの空き容量が必要です。

一時的に他のVMイメージを他のストレージに移すなどして容量を空けます。


(参考)

VirtualBox の仮想ディスクのサイズを変更する - Qiita

http://qiita.com/niwashun/items/f71b0b805a6f97b514ec


VMの仮想ディスクを縮小する

VDI形式の仮想ディスクだとmodifyhdで「compact」という使われていない部分の仮想ディスクサイズを縮小することが出来ます。


VirtualBoxホスト上で、新たに作られたVDI形式の仮想ディスクの情報を取得し、やっと本来の目的である仮想ディスクの縮小をする

$ vboxmanage list hdds
..略
UUID:           fcccb41b-2ed1-46c1-bb37-308610cc1229
Location:       /home/example/VirtualBox VMs/example_default_12345/example-2.vdi
Storage format: vdi
..略

$ vboxmanage modifyhd fcccb41b-2ed1-46c1-bb37-308610cc1229 --compact

この処理は結構な時間がかかります。


(参考)

仮想ディスクの圧縮 | VirtualBox Mania

http://vboxmania.net/content/%E4%BB%AE%E6%83%B3%E3%83%87%E3%82%A3%E3%82%B9%E3%82%AF%E3%81%AE%E5%9C%A7%E7%B8%AE


小さくなった仮想ディスクに付けなおす

新しく作られた仮想ディスクはまだVMと紐付いていないため、元々のディスクイメージとの付け替えを行います


VirtualBoxホスト上でVMに紐付いているディスクを付け替えます。

このとき「storageattach」で「storagectl」「port」「device」で指定する値は「showvminfo」で仮想ディスクが結び付けられている行の値になります。

「storageattach」の説明されているエントリではこの値がよく違っているため、たぶんバージョンにより変わることが多いようなので、実際に「showvminfo」で確認してその値を使ったほうが良いです。

$ vboxmanage list vms
..略
"example_default_12345" {5612d588-c7f6-48c0-8ac1-0c20a541d030}
..略

$ vboxmanage showvminfo 5612d588-c7f6-48c0-8ac1-0c20a541d030
..略
IDE Controller (0, 0): /home/example/VirtualBox VMs/example_default_12345/_centos-6.6-x86_64-disk1.vmdk
  (UUID: 1759a61c-7445-4c58-af32-540c348c4ff6)
..略

$ vboxmanage storageattach 5612d588-c7f6-48c0-8ac1-0c20a541d030 --storagectl "IDE Controller" \
  --port 0 --device 0 --type hdd --medium fcccb41b-2ed1-46c1-bb37-308610cc1229

$ vboxmanage showvminfo 5612d588-c7f6-48c0-8ac1-0c20a541d030
..略
IDE Controller (0, 0): /home/example/VirtualBox VMs/example_default_12345/example-2.vdi
  (UUID: fcccb41b-2ed1-46c1-bb37-308610cc1229)
..略

(参考)

VirtualBoxの仮想ディスクをコピーしてみた。

http://takaq1.plala.jp/freebsd/9_0r/kasou_copy.html


動作を確認し不要なディスクイメージを削除する

vagrant upして問題なく起動するか確認し、問題なければ不要となった大きなディスクイメージを削除します。


VirtualBoxホスト上で

$ vboxmanage closemedium disk 1759a61c-7445-4c58-af32-540c348c4ff6 --delete

これだけやってやっとこ場所が空きますが、各処理がだいぶ時間がかかると思ってやってみてください。

自分でその辺の店に行って外付けディスク買ってきて繋いでやる!という気分になります…

トラックバック - http://d.hatena.ne.jp/stealthinu/20170919

2017-08-08 (Tue)

[]URL中の文字をmod_rewriteのRewriteMapで全置換する URL中の文字をmod_rewriteのRewriteMapで全置換するを含むブックマーク URL中の文字をmod_rewriteのRewriteMapで全置換するのブックマークコメント

とある問題でURL中のクエリ文字列に含まれる「&amp;」を全て「&」に戻したいことがありました。

mod_rewriteを使ってなんとか実現できたんですが、結局もっと正しい修正箇所がわかったので使われませんでした。

が、せっかく新たに得た黒魔術だったので、エントリ化しときます。


URLが例えば本来は「/hoge?foo=1&bar=2&baz=3」となるものの予定が、この他に「/hoge?foo=1&amp;bar=2&amp;baz=3」のようにして渡ってきてしまうものもあるとします。

これを本来想定している「/hoge?foo=1&bar=2&baz=3」にmod_rewriteを使って戻したいわけですが、mod_rewriteでの置き換えでは「s/&amp;/&/g」みたいな全部置換するルールは簡単に書けません。


でこれをやるために、RewriteMapという機能から外部プログラムを呼び出すことで行うことが出来ます。

パラメータはSTDINから渡されるので、そこからプログラムで適当に修正してやれば全置換等もできるわけです。

http://httpd.apache.org/docs/2.4/mod/mod_rewrite.html#RewriteMap


mod_rewriteのための設定追加と、perlなどで書かれたフィルタが必要になります。


/etc/httpd/conf/http.conf

RewriteMap amp_replace prg:/etc/httpd/conf.d/query_amp_replace.pl
RewriteCond %{REQUEST_FILENAME} ^/hoge$
RewriteCond %{QUERY_STRING} ^(.*&amp;.*)$
RewriteRule .* /hoge?${amp_replace:%1} [R,L,NE]

といったところを注意します。


/etc/httpd/conf.d/query_amp_replace.pl

#!/usr/bin/perl
$| = 1;
while(<STDIN>) {
  chomp;
  s/&amp;/&/g;
  print $_."\n";
}
  • バッファリングをさせないようにする(Perlなら「$| = 1」)
  • 出力の最後は改行が必要(この例だとchompしなければ"\n"は不要のはず)

という点を注意します。下記ページが参考になります。

Using RewriteMap - Apache HTTP Server Version 2.4

http://httpd.apache.org/docs/2.4/rewrite/rewritemap.html


これでどんな複雑な変換も可能になるわけですが、当然毎回perlなりスクリプトが起動するためパフォーマンスは悪いはずです。

ここでは対象となるプログラムの呼び出しで、かつパラメータに「&amp;」が含まれているときのみ起動するようルールが書いてあるため、そこまでではないと思いますが、注意が必要でしょう。

トラックバック - http://d.hatena.ne.jp/stealthinu/20170808

2017-07-10 (Mon)

[]文法エラーのあるHTMLで古いIEのみjQueryがエラーを起こす 文法エラーのあるHTMLで古いIEのみjQueryがエラーを起こすを含むブックマーク 文法エラーのあるHTMLで古いIEのみjQueryがエラーを起こすのブックマークコメント

CMSで作られたページが、とある環境でのみjQueryの特定行でエラーがポップアップしてきてしまう、という相談を受けました。

ポップアップされる内容はjQuery内で「Invalid argument」でエラーが起きているというものでした。

エラーが起きているjQueryの箇所は「this.parentNode.insertBefore(a,this.nextSibling);」という部分でした。

何かシステム的な変更があったわけではなく、通常のHTML編集しかやっていなかったのに、いつの間にかこれが出るようになったとのことでした。


調査していくと、エラーが出るのがCMSの編集(プレビュー)画面のみで、他の環境で試すと問題が出なかったため、なんらかの環境依存であることがわかりました。

IE7/8/9 の(既にサポートが切れてる)古いIEでは同じエラーが出ており、開発者モードではないのでエラーがポップアップしないだけ(下部のステータス行には黄色「!」でエラーが表示されている)であり、CMS依存ではなくjQueryIE7/8/9依存であることがわかりました。


そこでエラーメッセージやエラーの出た部分の内容から「jquery Invalid argument nextSibling」あたりで探していくと、やっとこ該当しそうな件がありました。


[SOLVED] JavaScript Error in IE8 - Webpage error details "Message: Invalid argument." | Zyxware Technologies

http://www.zyxware.com/articles/2724/solved-javascript-error-in-ie8-webpage-error-details-message-invalid-argument

just check for HTML errors and fix them one by one.


HTMLに腐ってるところがあると、jQueryがパースする時にIE7/8/9のときだけエラーで止まってしまうようです。


今回の例だと、下記HTMLのように


<li><a href="…"><b>hoge<a href=…">fuga</a></b></a></li>

  • aタグが入れ子になっていること
  • aタグとbタグが「<a><b></a></b>」のように互い違いになっていること

というようなおかしなHTMLがありました。ユーザが修正時に間違って入れ込んでしまったようです。

そこでこのHTMLを修正することで、エラーが出なくなることが確認できました。


jQuery内のInvalid argumentなので、なにかのJSから呼ばれている時にパラメータがおかしくなるのだろうか、と思ってしまい、HTMLの文法の問題とはなかなかわからなかったので、同様の問題に当たった方の参考になれば。


…というか今さらjQueryIE7/8/9のみで起こる問題とか、参考になる方少ないでしょうけども…

トラックバック - http://d.hatena.ne.jp/stealthinu/20170710

2017-06-29 (Thu)

[]bottleのhost指定の誤解 bottleのhost指定の誤解を含むブックマーク bottleのhost指定の誤解のブックマークコメント

PythonでWeb APIを叩くプログラムを組んでて、テスト用に相手先APIをエミュレートというか単に決まった値返すだけのダミーWeb APIをbottleで用意してました。

で、それをdockerで動かしてて、docker execで入って中から叩くとちゃんと動いていて、テストも通るのだけど、外から叩こうとするとどうしても動かない… となってました。

dockerのポートマッピングの仕方がまずい?とか、Windows上のdocker toolboxで動かしてたのでWindows firewallが悪さしてる?とかそっちのほうを色々調べたんだけどもわからず。


で、最終的にわかったのは、自分のbottleの使い方がまずかった、ということでした。


bottleを走らせる時、下記のようにhostとportを指定するわけですが、このようにhost指定をlocalhostとすると、127.0.0.1の割り振られているインターフェイス、つまりローカルループバック(lo)だけをlistenするようになるため、自サーバ内からlocalhostに対してのアクセスには反応するものの、外からの接続には反応しないのです。

run(host='localhost', port=80)

全部のインターフェイスに対して反応させるには、localhostではなく「0.0.0.0」を指定してやります。

run(host='0.0.0.0', port=80)

これ、bottleのdeploymentってページの一番トップに出てたんで、めっちゃあるあるなんだと思うのですが、思いっきりハマったので。

Deployment ― Bottle 0.13-dev documentation

https://bottlepy.org/docs/dev/deployment.html

トラックバック - http://d.hatena.ne.jp/stealthinu/20170629

2017-06-05 (Mon)

[]dockerでCtrl-pでヒストリをのぼれない dockerでCtrl-pでヒストリをのぼれないを含むブックマーク dockerでCtrl-pでヒストリをのぼれないのブックマークコメント

docker

$ docker exec -it examplecontainer /bin/bash

で入って色々と作業をしている時に、「Ctrl-p」でヒストリをのぼろうとすると、1回では動かずに2回押すとやっと動くのだけども2つさかのぼってしまうという状況になっていました。


他に、下で書いたipythonで結果がすぐに表示されない、という問題もあったため、バッファリングされている問題?と思ったり、他にもちょっとヒストリの結果が崩れるときがあり、ターミナルのサイズとかがおかしく設定されているのだろうか、と思ったりしました。


が、そんな話をtwitterでつぶやいてたら@tmtmsさんに教えてもらえました…

というわけで、dockerだとデフォルトで「Ctrl-p q」でコンテナを抜ける用になっているため、「Ctrl-p」がエスケープシーケンスとして扱われているので、それでこんな状況が起きてしまうのでした。


これはdocker 1.10以降だと設定で変更できるとのこと。


docker で Ctrl-p 2回押し問題 (detach-keys の問題) を解決するには - Qiita

http://qiita.com/takahiroki/items/60ec916383025160fbb8


自分は下記のようにして「Ctrl-[」の後「q」に指定してみました。

docker toolboxの場合

~/.docker/config.json

に下記行追記

"detachKeys": "ctrl-[,q"

これで無事に「Ctrl-p」一回でちゃんとヒストリをのぼれるようになりました。


とみたさんありがとうございます!

[]ipythonでprint等の結果がなかなか表示されない ipythonでprint等の結果がなかなか表示されないを含むブックマーク ipythonでprint等の結果がなかなか表示されないのブックマークコメント

docker上のipython上でprintとかすると、エラーも出ずでも結果も表示されず、ただ色々叩いてると突然どばーっと出力が表示される、という状況になっていました。

これは上で書いたdocker環境で起きていたため、docker環境一般でのバッファリングの問題なのかと思ったのですが、ipython依存で起きていた問題だったようです。


この問題をぐぐってみると


pythonで print の出力結果を即時表示, 強制表示, フラッシュさせる(主にjupyter) - Qiita

http://qiita.com/mmsstt/items/469a9346ce545709f53c


python - Make ipython notebook print in real time - Stack Overflow

https://stackoverflow.com/questions/29772158/make-ipython-notebook-print-in-real-time


というあたりが出てきて

  • print("hoge", flush=True) のように「flush=True」を付ける(python3.3以降)
  • sys.stdout.flush() を都度呼んでで強制フラッシュする
  • sys.stdout を書き換えて出力時に強制フラッシュする

というあたりの解決法がありました。


どれも手間で、一番最後のsys.stdout書き換えが一番現実的だったのですが、これはこれでipython起動する度にこのスクリプトを貼り付けて実行しないといけなくてあんまりでした。


が、これまたそんなことをtwitterに書いてると@tatsushi_dさんに

と教えてもらえました。

ipythonって起動時に自動的に動かすスクリプトの指定ができるとのこと!


というわけで下記のように起動時に実行するスクリプトを設定してみました。

~/.ipython/profile_default/startup/99-flushstdout.py

import sys
oldsysstdout = sys.stdout
class flushfile():
  def __init__(self, f):
    self.f = f
  def __getattr__(self,name):
    return object.__getattribute__(self.f, name)
  def write(self, x):
    self.f.write(x)
    self.f.flush()
  def flush(self):
    self.f.flush()
sys.stdout = flushfile(sys.stdout)

これで普通にprintしたら即結果が表示されるようになりました!


たったこれだけのことなのにだいぶ紆余曲折して時間使ってしまった…

でも色々と勉強になったからいいことにしよう。


でまちさんありがとうございました。

2017-05-15 (Mon)

[]MacWindows混在でgit使ってる時の問題 MacとWindows混在でgit使ってる時の問題を含むブックマーク MacとWindows混在でgit使ってる時の問題のブックマークコメント

世の中の主なOSUnix系、Windows系、Mac系ではそれぞれ改行コードが違っています。

LinuxなどUnix系の改行コードは「LF」で、Windowsは「CRLF」、Macは「CR」(昔のOS9の頃まで。今のOSXUnix系なので「LF」)となぜかそれぞれ別になってしまっています。


自分はWindowsではSourceTreeでgitを使っているのですが、Linux上のスクリプト言語のソースは改行コードは普通LFにする必要があるため、SourceTreeのデフォルトgitの設定では、commitする時に「CRLF」→「LF」に自動変換され、checkoutする時には逆に「LF」→「CRLF」に変換されるようになっています。


でもこれだと、なにも触ってないのに修正されているファイルとして上がってきてしまうことがあって、そしてしかたないからcommitしようとすると、変更されてないからcommitしなかったよみたいなこと言われて気持ち悪かったりします。


エディタデフォルトの改行コードを「LF」にしてしまえば良い話なので、この自動変換をしないように設定出来ます。

git config --global core.autocrlf false

これで自動変換をしないようになります。


もう一つ、Macからgitで日本語ファイル名を扱うとき、これも触ってないのに新しくファイルを作ったと言われてしまうことがあります。

その現象が起きるのは条件があり、日本語ファイル名中に「バ」や「ぱ」といった濁点や半濁点が含まれている場合でした。


MacだとNFDと言う「バ」を「ハ」と「゛」に別けて保持する形式でファイル名が記録されます。

しかし他の環境で作られたリポジトリではNFCという「バ」は一文字の「バ」として保持する形式で記録されているため、ファイル名のコード的には違ってしまうので、あたらしいファイルが作られたことにされてしまうのです。


これはMacの場合にはNFCに変換するという設定にしておくことで解決できます。


MacGit で日本語ファイル名を扱うときは core.precomposeunicode = true にしておく - かわちょでぶろぐ

http://kawachodev.hatenablog.jp/entry/mac-git-core-precomposeunicode

git config --global core.precomposeunicode true

というか、この手の改行コードの違い、NFC/NFDBOM有り無し、utf8とutf8mb4みたいな問題、いつか統一されてスッキリする日が来て欲しい…

トラックバック - http://d.hatena.ne.jp/stealthinu/20170515

2017-05-11 (Thu)

[]Windowsdocker-composeでのマウント Windowsのdocker-composeでのマウントを含むブックマーク Windowsのdocker-composeでのマウントのブックマークコメント

WindowsDocker Toolbox上でdockerを動かしているのですが、最近はWindowsでもdocker-composeも使えるようになっています。

なのですが、普通にdocker run -vではマウントできる設定でも、docker-composeでvolumes指定を使ってマウントを行おうとすると、エラーが出てマウントできないという問題がありました。


調べてみると同様の報告が見つかり、どうやら「Windows用にパスの書式を変換する」という指定が必要らしく、

COMPOSE_CONVERT_WINDOWS_PATHS=1

環境変数が設定されていると良いようでした。


docker compose volume mounts not work on Windows · Issue #4303 · docker/compose

https://github.com/docker/compose/issues/4303


これで問題なくマウントされるようになりました。


ちなみに自分はnyagosから使いたかったため、.nyagosに下記設定を追加して対応しました。

set {COMPOSE_CONVERT_WINDOWS_PATHS='1'}

(関連)

NYAGOSからDockerを使う設定 - モーグルとカバとパウダーの日記

http://d.hatena.ne.jp/stealthinu/20161028/p1

トラックバック - http://d.hatena.ne.jp/stealthinu/20170511

2017-04-19 (Wed)

[]WordPressのW3 Total Cache導入時の注意点 WordPressのW3 Total Cache導入時の注意点を含むブックマーク WordPressのW3 Total Cache導入時の注意点のブックマークコメント

とあるサイトで使われているWPを高速化・低負荷化したいという話があり、いくつか提示した中で一番簡単なキャッシュプラグインの導入を試したいということで、W3TCの導入をしました。

その時にテスト用サーバで試して問題が出たこととその対策と、tipsをメモします。


W3TCの基本的な設定

W3TCの導入については下記ページが大変参考になりました。

基本的な設定はここのサイトの設定にしたがっています。


W3 Total Cache のおすすめの設定方法

https://bazubu.com/w3-total-cache-23854.html


ログイン後にW3TCの設定ができなくなる

このWPではマルチサイトで運用されていました。

W3TCの設定終了後にログアウトして再度ログインすると、W3TCの詳細設定メニューが出ないというか、特権管理者(ネットワーク管理者)になれなくなっている感じでした。

これは下記設定で回避出来ました。


「Miscellaneous」の「Use single network configuration file for all sites.」はチェック外す


特定の環境で文字化けが発生した

自分のブラウザ環境では問題なかったのですが、一部の人が文字化けと言うか完全に化けた表示しかされない状況になりました。

見た感じでgzipがそのまま表示されている感じだったので、下記設定で解決できました。


「Browser Cache」の「Enable HTTP (gzip) compression」はチェック外す


同じ症例を探してみると、どうも古いPHP(PHP5.4以前)だとこの現象が発生するらしいです。


Wordpress】W3TCが原因で文字化けする場合の対処 | TeraDas−テラダス

http://www.teradas.net/archives/24204/


500 Internal Server Error が発生する

毎回ではないのですが、たまに500エラーが発生するようになりました。

エラーログを確認すると、W3TCのオブジェクトキャッシュ処理中にPHPがメモリ不足で落ちていることがわかりました。

その環境ではmemory_limitが128Mになっており、同様の件を探すとやはりW3TC導入でメモリ不足でエラーになっている件がいくつか見つかりました。

その結果からObjectキャッシュとDatabaseキャッシュを利用する場合、512M程度までは上げておいたほうがよい感じでした。


メモリ割り当てを増やしてもメモリ不足でエラーが出る

上記問題に対応するため、memory_limitを512Mにしてもメモリ不足でエラーが出ることがありました。

調査すると、Pageキャッシュでは問題なく、ObjectキャッシュとDatabaseキャッシュで問題が出るため、このキャッシュを利用しないように設定しました。

ObjectキャッシュとDatabaseキャッシュは、Pageキャッシュに比べると速度への貢献が低いので、無理に使わなくても良いと思われます。

また後述のようにObjectキャッシュを使うと、スマホとPCでページ切り替えをしている場合にうまく表示できないという問題がでるようです。


「Database Cache」と「Object Cache」の「Enable」をチェック外す


スマホ用とPC用でページが混在してしまう

このサイトは同一URLスマホ用とPC用のページが出るサイトだったのですが、スマホ用ページとPC用ページがうまく切り分けられず混在してしまう問題が発生しました。

そこでPC用とスマホ用、携帯用で別々のキャッシュを持つように設定します。


「User Agent Groups」の「1. High」と「2. Low」の「Enabled」をチェックする


PCとスマホを分けて綺麗に高速表示してくれるWPキャッシュプラグイン「W3 Total Cache」の簡単設定方法

https://nelog.jp/w3-total-cache


Objectキャッシュを使っていると、この設定をしてもうまくいかないらしいので、そのためにも前述のようにObjectキャッシュは使わないようにする必要があるようです。


W3 Total Cacheスマホ版レスポンシブ表示でもキャッシュが効く

https://iphone-lab.net/page-cahe-mobile-397832/



スマホページが表示されるはずがPC版ページが表示されてしまう

キャッシュ導入後、スマホページが表示されるはずの条件でPC版ページが表示されてしまう問題が起こりました。

キャッシュファイルとアクセスログから調べてみると、iPadからの閲覧が行われたときに間違ったキャッシュが生成されていることがわかりました。


このサイトではPCとスマホ、携帯の表示切り替えを行っており、スタイルの切り替えは「Ktai Styleプラグインにより行っていました。

https://wordpress.org/plugins/ktai-style/


そこで、スマホ判定を行っている部分のコードを確認すると

/wp-content/plugins/ktai-style/operators/base.php

preg_match('/\b(iP(hone|od);|Android )/', $ua, $name)

となっていました。


この判定を行なう条件が、W3TCのスマホの条件と違っており、Ktai Style では iPad からのアクセスでスマホページの表示は行わないが、W3TCではスマホページとして扱うため、そこで差異が生じて iPad から見られた場合に、PC版ページがスマホ版のページとしてキャッシュされていることがわかりました。


そこでW3TCの設定を、Ktai Styleの判定条件に合わせるよう変更しました。

User Agent Groups -> Group name: 1.high -> User agents:

android
iphone
ipod

携帯ページがキャッシュ化されると文字化けする

携帯向けページがキャッシュ生成時には文字化けしないが、キャッシュから表示された場合には文字化けしてしまうことがわかりました。

調査すると、携帯向けはShift-JISで表示しているのですが、HTTPレスポンスヘッダのcharsetではUTF-8になっているためでした。


前述のように携帯向けページ表示はKtai Styleを利用しており、下記ソースから携帯向けは全て「SJIS-win」で出力されていることを確認しました。

/wp-content/plugins/ktai-style/operators/

emobile.php ezweb.php i-mode.php softbank.php willcom.php

$this->charset = 'SJIS-win'

W3TCの標準設定ではUTF-8として出力されるようになっていたため、まずはそこを修正しました。

各ページキャッシュディレクトリ.htaccess に AddDefaultCharset UTF-8 が付けられてしまうことを抑止します。

Page cache -> Advanced -> Charset:

「Disable UTF-8 blog charset support」をチェック


しかし、ここを修正してもUTF-8として返っていました。

/etc/php.ini にあるPHPデフォルトcharsetでUTF-8が設定されており、キャッシュ表示でそれが強制されてしまっていたためでした。

しかし、キャッシュファイルはHTMLを直接apacheから表示しているはずなのに、なぜPHPデフォルトcharsetが使われるのかが不思議でした。

ディレクトリ指定で表示されるページが、W3TC が生成した mod_rewrite のルールで _index_low.html などが返されるようになるのですが、元々の apachePHPの設定で DirectoryIndex の指定が index.php になっており、先にPHPが動く設定が生きてしまうようです。


そこでWPのルートのディレクトリにある .htaccess (W3TCの設定が追記されるファイル)に、PHPデフォルトcharsetを設定しないように追記しました。

/.htaccess

### for W3TC Ktai cache
php_value default_charset none
###

これでやっと携帯向けページのレスポンスヘッダに charset=UTF-8 がつかなくなり、文字化けが発生しなくなりました。


カテゴリーページのキャッシュが更新されない

カテゴリー(category)ページだけは、そのカテゴリーのエントリーを編集しても更新がされないという問題がありました。

ページキャッシュの設定で「Purge Policy」の「Post terms pages」などをチェックを入れてもダメでした。


調べてみると同様の問題がレポートされていました。


Page cache for categories not updating with W3 Total Cache - WordPress Development Stack Exchange

https://wordpress.stackexchange.com/questions/25425/page-cache-for-categories-not-updating-with-w3-total-cache


そこでさらに調べると、この問題だけ解決するためのプラグインがありました。

やはりタグやカテゴリーでの生成ページを消去することが出来ないという問題があるようです。


W3 Total Cache Purge All Page — WordPress Plugins

https://ja.wordpress.org/plugins/w3-total-cache-purge-all-post/


非常に小さなプラグインですが、これで解決できました。


動的なコンテンツの含まれるページの更新が遅い

デフォルトのページキャッシュの維持時間が1時間になっているため、動的なコンテンツが含まれる場合、最大で1時間更新が遅れます。


Page Cache -> Advanced -> Garbage collection interval:

で設定が行なわれており、デフォルトは「3600」秒となっています。


キャッシュ保持時間を例えば10分程度と短くすれば、設定時間より最大で10分遅れ(期待値で5分遅れ)でコンテンツが更新されるようになります。


このキャッシュ保持時間ですが、WP-CronというWordPressの持っている疑似cron機能を利用して、そこにキャッシュ削除の呼び出しを登録することで行われています。

このWP-Cron機能は、何分毎という指定ではなく、毎回何時以降に実行という登録を行なう必要があります。

W3TCでは、既にキャッシュ削除の登録が行われていると登録のし直しが行われず、その登録された処理が行われた後に再度登録されるとき、あたらしい設定での登録が行われます。

つまり、キャッシュ保持時間の変更を行っても、次のキャッシュ削除が行われるまではキャッシュ保持時間が変わりません。

また、WP-CronはWordPressへのなんらかのアクセスをトリガとして動くため、ほとんどアクセスがない場合は指定した時間にcronの処理が動くとは限りません。


どうしてもリアルタイムで更新させたい場合、特定ページのみキャッシュさせないようにすることが出来ます。


Page Cache -> Advanced -> Never cache the following pages:

に下記のように指定すると、example_directory以下のページはすべてキャッシュされなくなります。

/example_directory/*



キャッシュの場所

/wp-content/cache 以下のファイルにキャッシュが作られます。

その下の page_enhanced にページキャッシュが、dbデータベースキャッシュ、object にオブジェクトキャッシュが作られます。

ページキャッシュは対応するドメイン/ディレクトリ/ファイル毎に対応するディレクトリが掘られてそこに「_index.html」という名前でキャッシュが作られます。

スマホ用や携帯用のキャッシュは、「User Agent Groups」で設定した名前「high」や「low」を使って「_index_high.html」のようにキャッシュが作られます。

動きがおかしくて、どこまでは正しくキャッシュが生成されているのかを見たい場合にここから確認します。


ページキャッシュの表示方法と有効期間

ページキャッシュは「Disk: Enchanced」の場合、前記キャッシュ場所にHTMLとして保存されます。

そしてページキャッシュの表示は、WordPressPHPを介さずにapacheからこの場所のファイルが直接表示されるようになっています。

これは /.htaccess にW3TCにより追記された mod_rewrite のルールにより行われます。

キャッシュが存在していればそのキャッシュが表示されるようになっており、キャッシュの有効期間という考えはありません。

編集が行われた時に古いキャッシュが削除されることでキャッシュの同期が行われるようになっています。

トラックバック - http://d.hatena.ne.jp/stealthinu/20170419