冷蔵庫修理

投稿日: 2016年7月13日 作成者: 棉乃木

最近発泡酒がヌルい…と思って冷蔵庫に温度計ぶち込んでみたら，15℃までしか冷えてないでやんの。つい先日は，賞味期限までまだ3日もある牛乳飲もうとしたら明らかに異常な味，慌てて流しに吐き出したらなにやら黄ばんだ牛乳…。(‘A`)
これはイカンと思い，ダメ元で分解してみたらなんとかなるもんで，結局はファンの異常だけで，PCファン修理程度の知識で直りました。で，中開けてみて分かったこと色々。
冷蔵室うちのは，2ドア式の単身向けのオーソドックスなやつです。話題のシャープ製，たぶん15年選手。
まず冷蔵庫側の奥を開けてみると，制御基板しか入ってないし。ファンすらない。
温度調整のツマミは可変抵抗に直結されていて，サーミスタらしきものもあり一応ここで温度制御はしてそうなんだけど，冷気はというと上の冷凍室からダクトが繋がってるだけ。
冷凍室と冷蔵室連動かよっ。

冷凍室で，冷凍室の奥を開けると，良く見慣れたアルミの熱交換器。そしてファン。
分解して初めて分かったのが，冷凍室の温度調整つまみ，アレ実は機械式。
弱ってすると中央のダクトに対して引き戸みたいなフタが開き，強ってするとフタが閉まるだけ。
冷凍室から冷蔵室へ向かう冷気の量を，機械的に開いたり絞ったりして，冷凍室と冷蔵室の冷気の杯分を替えてるだけ…なんとういか雑。
冷蔵室の冷えが悪くなったんで，冷蔵室のつまみを強にまわして，さらに冷凍室も強にしたら吊られて冷蔵室も冷える？かと思ったけど実は間違い。冷凍室を強にすると，その分冷蔵室へむかう冷気が減る模様。
強ってして冷気を絞ると「冷蔵室への冷気が減る／冷凍室さらに冷える」→「冷蔵室の温度があがるから制御回路がさらに冷やそうとする」→「冷凍室もっと冷える」ということで，それでも目的通りの動作にはなるっぽい。

どうでも良いことだけど，興味深い知見が得られました。

カテゴリー: 未分類 | コメントする

[freebsd][server] Let’s Encrypt

投稿日: 2016年7月9日 作成者: 棉乃木

無料のSSL証明書やってみた。FreeBSDで。
とりあえずports見ると”security/letsencrypt.sh”と”security/py-certbot”ってのがあるけど，py-certbotのほうが本筋みたい（わりと最近に”certbot”という名前になったとか）。letsencrypt.shはpython使わずにbashだけで同等機能を実現したものっぽいんだけど，互換性やら最新版への追従状況とかよく分かりませんでした。あと設定ファイルの場所も同じみたいなんで，共存も出来ない可能性あり？タブンシランけど…。ただpy-certbotは10数種のpythonモジュールを依存portsとして読み込むのがやや面倒…。
日本語ポータルの情報もあって，certbot-autoをcertbotコマンドに置き換えて動かすだけで難しいことは無い。面倒臭い組織や所在地情報を一切入力すること無く，連絡用のemailアドレスとドメイン名入れるだけ。とても簡単。
無料ということでよからぬ輩も出てくると思うけれど，証明書の取得に要求ドメイン名のDNSが引ける実サイトが必要だとか90日の制限とか，一定の制限は設けている。それでも，今後Let’s Encryptの証明書を使ったフィッシングサイトが出てくる可能性は十分にある。そうなるとドメイン認証の証明書の地位が著しく下がるんだろうなぁ。別に良いけど。
そんなわけでSSL対応したんで，httpでのアクセスは勝手にhttpsにリダイレクトさせてます。原則https。多分実害は無い…筈。一部のWindowsXP用ブラウザからアクセス出来なくなったりしてるけどもう良いよね。実利は・・・あんま無いなw。googleさんの評価がちょっと上がるのと，アクセス解析でgoogleからのrefererが取れるようになるくらいかなぁ。
＜追伸＞
https化しなくてもgoogleのreferer取れてました。が、検索クエリは取れず。そういう仕様らしい。
http://yut.hatenablog.com/entry/20130809/1376005604

カテゴリー: 未分類 | タグ: , , | 3件のコメント

バイクの修理について

投稿日: 2016年7月6日 作成者: 棉乃木

バイク屋は何で儲けているのか？結論から言うと中古車販売だと思う。新車販売なんて納入価格と販売価格の上限が決まっていて大した利幅も無い。メンテナンスで儲けると言っても，オイル交換で得られる利益なんて二束三文。車検となれば少し纏まった金額になるけれど，車なら皆車検でもバイクは251cc以上限定。となるとバイクの数ががくんと減るし，用品店など競合も多い。
では修理は？…というと，1台1台の症状が必ずしも定形とは限らず，本来修理というのは個々の原因を探るのにとてつもない手間ととてつもない経験が物を言う世界。人間の場合，医者は高給取りだけれども，車バイクの技術料はそう高くない。面倒なら買い換えという事になる。それでも修理出来れば良いけど，原因を掴めなかったら「あのバイク屋はクソだ」と噂を流される。そんなわけで，ハイリスクローリターンでぶっちゃけ一番やりたくない仕事なんじゃ無いかと思う。
それでも経験と知識を併せ持って，的確な修理が出来るバイク屋もいるけど本当に少数派。しかもたいした売り上げに繋がらない。修理なんか求められても「あー，もうダメですねー，こっちの中古車やすくしときますよ，どうですか？」ってしたほうが利益が出ると思う。
ハーレーとかBMWみたいな，単価の凄く高い外車とかは別として，修理がちゃんと出来るバイク屋なんて，神か仏か清貧ですか？ってな感じで「居なくて当たり前」の世界だと思う次第。
結局車体価格が数百万円を越えるような乗り物で無い限り，商業的にはまともな対応してもらえないから，結局自分で面倒見るしか無いんだなぁ…と思う次第。

カテゴリー: 未分類 | タグ: | コメントする

[server] Apache2.4のアクセス制御とAllow from all

投稿日: 2016年7月3日 作成者: 棉乃木

少し前からApache2.4に上げたんだけれど，制限していたはずの海外からのコメントスパムがちらほら入るように。Apache2.2から引き継いだ設定が上手く機能していなかったようで。

Apache2.2の時はこんな風に記述してました。

<Directory "/home/*/public_html">
Order deny,allow
Deny from all
<LimitExcept POST PUT DELETE>
Allow from all
</LimitExcept>
<Limit POST>
Allow from 127.0.0.1
Include iplist_jp_allow
</Limit>
</Directory>

で，これをApache2.4に移行させるのに，こんなふうに書き直してみたら海外からもPOST書き放題に。

<Directory "/home/*/public_html">
Requrie all denied
<LimitExcept POST PUT DELETE>
Requrie all granted
</LimitExcept>
<Limit POST>
Require ip 127.0.0.1
Include iplist_jp_allow
</Limit>
</Directory>

LimitExceptのとこのAllow from allをRequie all grantedって書いちゃったのがそもそもの間違い。ここにRequie all grantedって書くと，最初のRequire all deniedが上書きされるっぽくて，結果的にすべて許可状態になってしまいました。
（試してないけど，<RequireAll/Any/None>あたりで括る必要があったのかも？）

じゃぁRequire allなのかというと文法エラー。ウチの力ではAllow from allにあたる設定を見つけることが出来ませんでした。Require all deniedに許可条件を追加していくのに，Allow from allみたいなちゃぶ台返しは危険だから止めましょうってことなのかな？

そんなわけで思案した結果，Apache2.4の文法に倣い，1から書き直すことに。で，Apache2.4の今風？に書き換えた結果がこちら。

<Directory "/home/*/public_html">
Require all denied
<RequireAny>
<RequireAll>
Require all granted
Require not method POST PUT DELETE
</RequireAll>
<RequireAll>
Require method POST
<RequireAny>
Require ip 127.0.0.1
Include iplist_jp_allow
</RequireAny>
</RequireAll>
</RequireAny>
</Directory>

最初のRequie all deniedはいらんかも。いまいちall grantedとall deniedの振る舞いが理解仕切れない。

<RequireAll/Any/None>はApache2.4の新しいディレクティブ。入れ子構造にもできて，記述としては分かりやすい…んだけど，実際書いた物を読み直すと微妙。2.4的にはこちらで書き換えること推奨なのかなぁ。

内容としては，<RequireAny>に許可する条件をリストアップ。一つ一つの条件は<RequireAll>で括った中身がすべて合致したとき。一つ目の条件のRequire all grantedは，Require not xxxxを指定するときは合致しなかった時の条件として必要とか。二つ目はRequire xxxなので，それだけで条件を満たすからRequire all xxxは要らんらしい。IPアドレスは列挙するので，どれかに合致で良いからまたRequireAnyで括る。

今までLimit/LimitExceptが無くなってすっきりしたような，余計にややこしくなったような…。

カテゴリー: 未分類 | タグ: , | コメントする