2015年07月

2015年07月23日
今まで google アナリティクスのコードを埋め込んでいました。
もちろんこれからもこのコードで何の問題も無いのですが、どうやら新しいサービスが始まったようなので、そちらに移行しました。
なお、デフォルトのまま利用している(と思う)ので、追加的に取得している情報はありません。

今までに比べて、なにが変わったということは正直わかりません。
唯一トラッキングコードは変わりました。

なお、一般的なサイトに導入するばあい、プライバシーポリシーなどによって注意書きが望ましいように思われます。

ユニバーサル アナリティクスの使用ガイドライン

上記では特に、以下の文章が気になります。
> ユニバーサル アナリティクスを使用していることをユーザーに伝え、有効/無効の選択肢も提示します。

なお、Google アナリティクス オプトアウト アドオン というのがあるようです
Google アナリティクス オプトアウト アドオン

IEなどブラウザへのアドオンで、google アナリティクスによるデータ収集を無効にすることができるようです。



2015年07月22日
毎年、会社の健康診断に行っています。
例年なんらかしらの異常というか経過観察が必要なところが見つかり、なかなか健康体というわけにはいかないもんだと思っています。

ちょっと前に覚えているのは、右心室肥大だったかな?
尿酸値は相変わらず高いので、投薬で治療中です。
うまれつきのぜんそくは、最近は良くなりました。投薬なしです。

という状況なので、健康が一番うれしいですね。

普段の健康診断は、身長や体重の計測のほか、レントゲンぐらいなのですが、今回は血液検査と心電図がありました。

まず血圧ですが、今まで
117/75 *2013年
124/80 *2014年
124/85 *2015年

という結果です。そして今までは問題なしだったのですが、今年は、軽度高血圧の疑いという結果になりました。前回と比べて、低い方の値が5上がっただけなのですが・・。

※ちょっと調べてみたら、85-89の範囲は正常高値血圧という分類になるようです。ギリギリのラインにいたようです。

それ以外の、箇所については正常でした。
RBC:475
HB:14.9

AST:27
ALT:30
GTP:27

LDL:104
HDL:83
TG:33

HbA1c:5.3

stock_value at 10:25|この記事のURLComments(0)TrackBack(0)健康 
2015年07月21日
いつも淡麗グリーンラベルを好んで飲んでいます。
ビールには、よく見かけるのですがシールが貼ってありました。今までずっと無視していたのですが、たまたま目に付いたので、そのキャンペーンに参加してみることにしたのです。

参考
キリン 淡麗「飲むほどオイシイ!」キャンペーン


だいたいのキャンペーンサイトは、バカバカしいほどわずらわしいことが多く、今まで参加したことはほとんどありませんでした。
仕事でよく飲む、缶コーヒーなどはやったことがありました。

キャンペーンにエントリーするために個人情報を登録する必要がありましたが、それらについてはとても簡易なものでした。これはとても好感が持てます。
仮登録を済ませると、登録したメールアドレスにメールが届き、それを認証するようにという、ごく普通の流れでした。しかしメールがまったく届かないのです。 hotmail のメールアドレスを利用していたのですが、ぜんぜんメールが届きません。
スパムメールなどに分類されるのではなく、そもそも届きませんでした。

数日まっても結局届かないので、何か問題があるかもしれませんね。結局他のメールアドレスを利用して登録することができました。
ポイントなども累積されるようなので、これはとても便利だと思いました。

2015年07月20日
今まで監視というのは、ちょっとナナメに構えて考えていました。
一つは僕自身が望まれている仕事が、そうした動き続けることを確認するというよりも、依頼の内容・・それは主に新しいサーバーの構築・・・をどれだけ要望通りに素早く実現するのか。ということでした。

またトラブルについては、当初に比べればずっと責任が重くなったものの、それに対応する内容というのは、サーバーが落ちないように、軽微なトラブルが起きないように構築をするという方向に向いていました。
そしてそれは比較的簡単に実現することができ、たとえば純正品を確実に使うとか、事前の検証を十分に行うといった程度で実現が可能でした。・・・しかしコストは倍ぐらいになりますが・・。

今まで僕自身は価格の低下が非常に望まれていたため、純正品以外を利用することもよくありましたし、サーバー類についても、パーツの寄せ集めのような状態で構築することもありました。もちろん検証などを十分に行えば、動作については問題ありません。

しかし長期間運用すると、メーカー製とは異なったトラブルが生じ、それについての対応は個別となり、そういうことの積み重ねが、今まで求められている内容とはズレが生まれ始めました。

そういった部品や長期間のサポートについて、求められることへの変化への対応は少しずつ行ってきました。そしてそうした考え方にも慣れてきました。しかし今度は、運用について求められることが昔よりも増えてきました。
たとえばトラブルが起きる前の予防としての対応。トラブルが起きたときには、どんな軽微なことであっても調査し、原因を追及する姿勢。などでしょうか。
予防というのは、難しい部分もありますが、たとえば過負荷であったり、空きメモリが減少していたりなど。そういう部分については対応が可能な感じがします。

さらに、サービスの停止についてユーザーからの申告で気づくことも大切ですが、それと同時期ぐらいに、監視ツールでアラートを出すということも重要な感じがしています
会社のサーバーも似たような感じです。
自社に人がいるときは、調子が悪いとすぐにサーバー再起動という安直な方法をとっているようです。そして後ほど「調子が悪かったの再起動しました」と報告を受けることがあります。
具体的にどのように調子が悪かったのか話を聞いても、いまいち理解できません。もちろん対処療法としての再起動は良いのですが原因を追いかけられないのは困ったもんですね。

などといったいろいろな意味でも、監視を今まで以上にちゃんとやりたいと思います。

2015年07月19日
たくさん事例があるので、単なるメモです。
最近 wordpress を触っていますが、このときに外部に公開しない方がいいファイルがいくつかあります。
これを .htaccess で拒否するために設定を調べました。

参考
Apache モジュール mod_access

前提としては、 mod_access モジュールが読み込まれていることです。

ありがちな記載例としては以下の通りです。
<Files ~ "(wp-config|xmlrpc)\.php$">
Order Deny,Allow
Deny From all
</Files>

ここで Order に続く、 Deny / Allow の順番がいまいちわかりませんでした。

Deny,Allow の場合には、Denyが先に評価され、デフォルトでは許可になります。そのため、ブラックリスト方式の場合には、こうなるようです。

Allow,Deny の場合には、Allow が先に評価され、デフォルトでは拒否になります。ホワイトリスト方式ではこちらの方法になります。


その他 Allow / Deny については、IPアドレスやホスト名を指定することが可能です。
それらについては、上記参考サイトを参照してください。

ドメイン名の一部・・・後方一致
IPアドレスの一部・・・前方一致
ネットワーク/サブネットマスク および ネットワーク/nnn (CIDR) ・・・192.168.0.1/255.255.255.0 もしくは 192.168.0.1/24

参考
Apache 2.4のアクセス制御をもうちょっとマジメに見てみた
Apache Module mod_authz_core

※2.4系からは制御方法が変わってくるようです。
すべて拒否の場合には、 Require all granted (もしくは Require all denied) を利用するようです。

2015年07月18日
Wordpressを利用するときに、最低限ではありますが以下の設定を行いました。


wp-config.php を外部からアクセス不可にする
xmlrpc.php を外部からアクセス不可にする ※プラグインなどによってはエラーになるようです。

<Files ~ "(wp-config|xmlrpc)\.php$\">
Order Deny,Allow
Deny from all
</Files>


wp-login.php へのアクセスを制限する

<files wp-login.php>
Require Host .jp
Require All Denied
</files>
※ プロバイダーの逆引きが jp ドメインであれば許可になっています。

しばらくこれで様子をみたいと思います。

なお、Wordpress Codex にセキュリティに関する記載があります。
WordPress の安全性を高める

2015年07月17日
今まで雷について2回ほど記事を書いています。
2011年07月02日:雷、落雷と家電の話。
2011年10月03日:サージプロテクター

被害の有無は別として、毎年落雷の話を聞きます。
そして数年に一度は大きな被害の話を聞くのです。もちろん、機器故障まで至らないにしても、UPSの故障程度の落雷であれば毎年数件は必ずあります。

去年の夏頃に、落雷対策について少し説明をすることがありました。
今年の夏もどうように、やはり落雷対策について、説明をしました。去年も今年も同じような考えですが、僕自身は電気の知識も無いので、毎回迷っていることがあります。
ということで、それらを整理したいと思います。

■PC/サーバー関係の落雷対策について
・電源
・LAN

電源については、UPSの利用で十分だと考えています。今までUPSを利用していたときに、大きな事故になったことはありません。もちろん、コンセントに侵入してくる前に、分電盤などでしっかりと遮断されているのかもしれません。
ただし予期せぬシャットダウンなどはありました。これはUPS由来によるもののようです。


一方でLANの対策は非常に難しいように思います。
落雷はどこにあるのかわからないので、予想されている適切な場所に雷が落ちた場合には、特に被害にならないか、せいぜい電源までの影響で済むようなのですが、落ちる場所によっては、LANや電話線などのケーブルに電気が乗ることがあるようです。
そしてこれは、そこまで珍しいことでは無く、頻繁ではないものの、たまに聞く話です。

LANや電話線には、雷サージプロテクターというのが販売されています。これは前回までの記事で書いたとおりです。APCなどいくつかのメーカーから発売されています。
アースを取るタイプのプロテクターと、もともと絶縁されているタイプのプロテクターがあります。

アースを取るタイプは安い。絶縁タイプは高い。そういう感じでした。

インターネット回線は、光回線であればケーブルは電線ではないので、そこまで考えなくても大丈夫のような気がします。ADSLとか電話線の方が注意が必要です。マンションで光回線でもメタル配線の場合には、やはり対策が必要です。しかも外部と接続されているのでなおさらですね。


■アースについて
アースに逃がすタイプの製品を導入する場合には、アースが必要だと思っています。しかし、アースを接続すると、アースからの逆流が考えられ、結局これが危険なのでは無いかと考えもあります。
いくつかの例では、あえてアース接続をせずに保護するというのがありました。特にLANの場合には、アース部分から侵入してくる可能性の方が高いのではないか。という考え方は理解できます。

一方で、アース接続しないと、LANから侵入してきた雷は防げないように思います。

絶縁されている製品は、、、使ったことが無いのでわかりません。が、なんだか頼もしいような気がします。