2016年12月18日日曜日

Webサーバとメールサーバが同一ドメインで異なるサーバの場合、Webサーバからメールが送信できない

Webサーバとメールサーバが同一ドメインで運用されていて、さらにメールがGmailなど異なるサーバの場合、Webサーバからメールが送信できないことがあります。
これ、今まで1台のサーバでWebとメールサーバを共用していて、メールだけGmailに移したりしたときに嵌りました。

ここの内容が助けになりました。

冷静によく考えれば、そりゃ飛ばないよなと思うのですが、焦っているときは、メールはMXレコードを参照するはずだし・・・と見当違いなことを考えてズブズブ嵌っていきます・・・




例えば、Webサーバがexample.comとし、いままで1台のサーバでメールも運用していましたが、
別サーバに移すことになりました。

ここで、Webサーバであるexample.comのサーバからテストとして、hoge@yahoo.co.jpに送るとします。
Webサーバは、@yahoo.co.jpなので、yahoo.co.jpのメールサーバへメールを転送し、無事届きます。
次に、Webサーバからhoge@example.comへ送信してみます。
Webサーバは、example.comのメールサーバへメールを転送・・・・しません。
なぜなら、example.comは自分自身なので、外部に送るまでもない。と判断し、内部でリレーされます。
当然、自分自身はメールサーバではないので、そんなユーザ知らんがな。と却下されます。
結果、外部にメールは飛ばないばかりか、UserUnknownでメール自体消滅します。


では参考サイトに従って、動作を確認してみましょう。
WebサーバのSendmailをテストモードで起動し、SendMailが自分宛と認識するホストを調べます。

# sendmail -bt
SendMailが自分宛と認識するホストを調べます。 /quitで抜けれます。
> $=w
example.com     <----------同じドメインが入っている
localhost.localdomain
localhost
> /quit
では、対処法です。ようはSendmailが自分宛と判断しなければよいので、Webサーバ名をwww.example.comのように”www”のサブドメインをつけます。

/etc/sysconfig/network
HOSTNAME=www.example.com    <------wwwをつける

/etc/hosts
127.0.0.1 www.example.com localhost localhost.localdomain
設定をしたら、反映させるためにサーバを再起動します。
また、DNSの設定を変更し、www.example.comをexample.comへのCNAME設定をします。


SendMailの設定を再度確認します。今度はwwwありが自分自身となりますが、www無しは対象外になり、外部へ送信されることになります。
> $=w
localhost.localdomain
localhost
[127.0.0.1]
www.example.com

そういえば、Webサーバのホスト名はwwwだし、メールはmailでしたね。


2016年12月10日土曜日

忘年会ですね・・・

今年も最後が近く・・・
という感じが全くない、年中無休な悲しい性を背負ったインフラ担当だったりしますが(ぉ

広島ITエンジニア合同忘年会に参加してきました。

まぁ諸事情により参加者が少なかったり色々ありましたが・・

完全にネタ枠ですね。




2016年11月19日土曜日

SubVersionのチェックアウトが異様に遅いときに確認すること。

もう21世紀にもなってSubVersionかよ。と少々うんざりするのですが、
ところがどっこい、しぶとく生き残っているというか、バージョンが古すぎてもはやどこにも移行できない負の遺産と化している現実があったりなかったりします・・・


そんなSubVersionですが、最近諸事情があって再構築したのですが、動作試験段階でチェックアウトが異様に遅い。という症状に悩まされたので、ここに記録しておきます。


まず、SubVersionのチェックアウトが異様に遅い原因として、

SubVersionが1.8以上であればデフォルトの転送モードがBlukからSkeltaに変更になったのが原因かもしれません。参考:SVNサーバ1.8、チェックアウト等でChecksum mismatch error発生時の対応

次に、SubVersionがRedmine認証になっている場合で、RedmineがLDAP認証だった場合、SubVersionサーバ側にAuthen::Simple::LDAPモジュールが必要になります。
参考:Redmine.pm設定メモ
Redmine.pm内部で、Authen::Simple::LDAPモジュールが使えれば読み込むようになっているのですが、パスの問題か何故か読み込まれず、Redmineの内部ユーザでテストしていた時は問題なかったのに、LDAPユーザになるとチェックアウトするファイル毎に認証に行くらしく、タイムアウトまで待たされる。という事がありました。
どうも、Redmine.pmでは、最初MySQLを参照し、該当ユーザがLDAP認証であれば、LDAPモジュールを使って、LDAPサーバに認証しに行きます。
なので、LDAPサーバにIP制限をかけている場合、SubVersionサーバからLDAPへ問い合わせが行くので許可する必要があります。これも地味にはまり、数日帰れない日々を過ごしました(涙

最後に、RedmineのMySQLサーバの応答が遅い。というのがあります。
これは意外に盲点で、通常のRedmine使用時は問題がないのに、何故かRedmine.pmから繋ぎに行くと、応答が異様に遅い。という事があります。
そして、大抵RedmineサーバとMySQLは同居していたりします。
しかも、MySQLがスロークエリを出すほど詰まっている訳でも、負荷が高い訳でも無く、とにかく応答が遅いのです。
最初CPANでインストールされるライブラリが古いのが原因か?とか思いましたが、どうも違うようです。

おそらくMySQLのバージョンの問題かネットワーク的な問題だと思いますが、切り分け方法として、SubVersionでBASIC認証もしくは認証なしなど、Redmine認証以外でチェックアウトを行ってみて、速度が出ればMySQLサーバからの応答が遅いのが原因の可能性が高いです。

解決法としてMySQLのバージョンを5.6にしたり、MySQLのキャッシュ割り当てを見直したり、遅延するようなネットワーク的な問題がないかをチェックします。

検証目的であれば、SubVersion内にMySQLをインストールし、RedmineのMySQLからdmpをインポートし、ローカルのMySQLで認証をかけてみて、それでも遅い場合は他に原因がありますが、それで改善される場合、ネットワーク的な問題の可能性大です。

以上、二週間ほど寝れない、帰れない日々を送ったサバカンからでした。

2016年11月10日木曜日

格安HDMI変換機を買ってみた

最近どこもかしこもHDMI・・・
と言う訳でVGA->HDMI変換を買ってみました。
送料込み480円(汗




まずは届いた時から潰れており開封済み(汗
さすがのクオリティである。
なお、どこかの偽物っぽいみたいで、1080pとかFullHDとかはまぁ、察しな状況




いかにも印刷しました。的なロゴ。3Dプリンタで整形したのか?と思う程度の加工精度。
バリがあっても気にしない大らかさ。



そして謎の穴が・・・
類似品にSWがついているものがあるので、よく分からずパクったのかもしれん。



サクッと分解。爪で止めてあるだけですね。



しかし安定の中華クオリティだなぁ。
コンデンサなんてよく付けたな。
あとで直しておく。



型番らしきものを発見。
これでググるとたくさん出てくるので、基板だけ流用しているのが出回っているのか??



裏側はこんな感じ。
フラックスは付きっぱなしだし、手半田っぽいなぁ。



HDMIに出力する箇所のダンピング抵抗?フィルタ?がありません。
そもそもプリントパターン自体切れていなかったりするので意味がないけど。



なんかLEDが付きそうな場所を発見。
でも制限抵抗は付いているんだよなぁ・・
余ってるLEDを付けてみるか。



STマイクロ製8S003F3P6
8bitマイコンらしい。
制御用かな?



メインチップ。
MS9282
VGAやアナログをHDMIに変換するAD変換らしい。
解像度を変更する機能はない模様。なのでVGAで入力すればHDMI側もそのままの解像度で出力されるっぽい。
このチップを使った製品は大量に見つかる。
毎度思うけど、中華のこの手のLSI、集積度が半端ない。



見ての通り3レギ。
型番から1.8Vと3.3Vを生成していると思う。
はんだ付けがかなり微妙・・



ES7240
なんだこれ?と思ったら、オーディオ用のADコンバータらしい。
24-BIT 192K STEREO ADC FOR PCM AUDIO
本当かなぁ。



ATMELっぽい24C02N
EEPROMですね。

構成部品はほぼ同じで似たような製品が大量に見つかるところを見るに、ある程度リファレンス的な実装や回路図が出回っているんでしょうね。


しかし、中華パクりだと思っていても、驚異的な集積度を誇るLSIを作っていたりと驚くべきものがあります。






2016年9月19日月曜日

PHPで失効証明書(CRL)を作成してみた

普段はRubyでこまごました俺得便利ツールを作っているのですが、
PHPで失効証明書を作成する例が見当たらなかったので作ってみました。

作成したコードはここにあげておきます。

クライアント証明書といっても、通常のサーバ証明書と同じでようは発行する先がサーバかクライアントかの違いだけです。
クライアントには当然ドメイン名なんてないので、ユーザ名やメールアドレスを属性にセットします。

基本的な流れは、
公開鍵、秘密鍵を作成ー>属性情報を書き込んだCSR作成ー>CAに署名してもらう
という、サーバの証明書を作成するのと同じ流れで作成できます。公式のサンプルもあります。

ただ、PHPでやろうとすると、動かす環境のopenssl.conf設定を読み込まれる。という罠があります。
なので、ここここを参考に、各関数の引数にConfのパスを与えてあげます。
あと、ここで指定するOpenSSLのConfですが、[ca]や[v3_ca]セクションくらいしか見ていないようで、
クライアント証明書を作成しようと、[user_cert]にいくら設定しても無視されます。
[v3_ca]セクションに設定しましょう。
だいたい以下のような設定をすればOKでしょう。

basicConstraints = CA:false
authorityKeyIdentifier=keyid:always,issuer:always
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth
OpenSSLの設定はIBMにナレッジがありましたので、参考になります。

しかし、Rubyと違って、PHPのOpenSSL回りはマニュアルもなんか投げっぱなしな感じで、引数の説明がろくななかったり、実行環境のConfを読み込むなど環境依存だったりなかなかハードルが高いです。
自分なんて、引数に何を渡したらいいのか調べるためにOpenSSLのソース読む羽目になったし(涙

ちなみに、Rubyで作る場合は、QuickCertという便利なgemがあるので、これを使えば簡単にCAなり証明書(サーバ、クライアント)が作成できます。
ただ、失効証明書はこれではできないので、このあたりを参考に、QuickCertを継承して組み込めばいいと思います。





2016年8月18日木曜日

Apache2.4ではまったのでメモ

Apache2.4ではまったのでメモ

検証環境はCentOS7+Apache2.4です。

Apache2.4のアクセス権限回りは、従来のOrder Deny,Allow形式から、
Require All grantedのような形式に変わりました。

そんな中でApache2.4のアクセス権限回りを設定していて、不可解な現象に会いました。

自分はDirectoryディレクティブとLocationディレクティブの違いは、
サーバ内のリアルパスでの制御か、URIの仮想パスかの違い程度としか理解していなかったのですが、
設定する上では注意が必要なようです。参考


では検証していきます。
まずはサクッとバーチャルホストの設定をします。

<VirtualHost *:80>
  ServerName localhost.localdomain
  DocumentRoot /var/www/virtual
  <Location />
    Require all granted
  </Location>
</VirtualHost>

まぁ普通に見れます。


ではここで、アクセス制限をかけます。

<VirtualHost *:80>
  ServerName localhost.localdomain
  DocumentRoot /var/www/virtual
  <Location />
    Require all granted
  </Location>
  #管理ページにアクセス制限
  <Location /admin>
    Require all denied
  </Location>
</VirtualHost>

かかりました。

ではここで、特定のファイルだけアクセス禁止にしたいと思います。
FilesMatchディレクティブはLocationディレクティブの中では使えないようなので、
Directoryディレクティブを使用します。

<VirtualHost *:80>
  ServerName localhost.localdomain
  DocumentRoot /var/www/virtual
  <Location />
    Require all granted
  </Location>
  #管理ページにアクセス制限
  <Location /admin>
    Require all denied
  </Location>
  #ブログのReadme.htmlはアクセス拒否
  #それ以外は参照可能にする。
  <Directory /var/www/virtual/blog>
    <FilesMatch "^readme\.html">
      Require all denied
    </FilesMatch>
  </Directory>
</VirtualHost>


なんと見えてしまいました。

設定を間違えたのでしょうか?確認のため、旧来の書き方で書いてみましょう。

<VirtualHost *:80>
  ServerName localhost.localdomain
  DocumentRoot /var/www/virtual
  <Location />
    Require all granted
  </Location>
  #管理ページにアクセス制限
  <Location /admin>
    Require all denied
  </Location>
  #ブログのReadme.htmlはアクセス拒否
  #それ以外は参照可能にする。
  <Directory /var/www/virtual/blog>
    <FilesMatch "^readme\.html">
      #Require all denied
      Order Deny,Allow
      Deny from All
    </FilesMatch>
  </Directory>
</VirtualHost>

ちゃんと弾かれるので、あっているようです。


これずいぶん悩んだのですが、どうも最初に設定している
<Location />
の設定が優先されるようです。
Apacheのドキュメントによると、
<Location> セクションは、 <Directory> セクションと .htaccess の読み込みの後、 <Files> セクションを 適用した後に、設定ファイルに現れた順に処理されます。
とありますので、優先順位としては
Directory -> .htaccess -> Files -> Location
のようです。
しかし旧来の設定では有効なのはよくわかりませんが・・・

試しにLocationのほうを旧設定にしてみます。
<VirtualHost *:80>
  ServerName localhost.localdomain
  DocumentRoot /var/www/virtual
  <Location />
    #Require all granted
    Order Allow,Deny
    Allow from All
  </Location>
  #管理ページにアクセス制限
  <Location /admin>
    Require all denied
  </Location>
  #ブログのReadme.htmlはアクセス拒否
  #それ以外は参照可能にする。
  <Directory /var/www/virtual/blog>
    <FilesMatch "^readme\.html">
      Require all denied
      #Order Deny,Allow
      #Deny from All
    </FilesMatch>
  </Directory>
</VirtualHost>

ちゃんと動きます。


ファイル名で識別できています。

しかし、動くとはいえ、新旧設定が混在するのは気持ち悪い。
ということでいろいろ試した結果、
Location設定をDirectoryにすれば動作するようです。

<VirtualHost *:80>
  ServerName localhost.localdomain
  DocumentRoot /var/www/virtual
  <Directory />
    Require all granted
  </Directory>
  #管理ページにアクセス制限
  <Location /admin>
    Require all denied
  </Location>
  #ブログのReadme.htmlはアクセス拒否
  #それ以外は参照可能にする。
  <Directory /var/www/virtual/blog>
    <FilesMatch "^readme\.html">
      Require all denied
      #Order Deny,Allow
      #Deny from All
    </FilesMatch>
  </Directory>
</VirtualHost>
なお、最初のLocation /にアクセス許可与えている奴ですが、
これをすると、FilesMatchでRequire all deniedが有効にならないので・・・

むむむむ・・・・・

2016年6月12日日曜日

壊れたATX電源を修理してみた。



**警告**
お約束ですが、電源を分解すると保証がなくなるばかりか、感電、発煙発火、最悪火災など人的被害が出る可能性があります。
ましてや、よく分からず修理しようとするなど無謀です。今時数千円も出せばまともな電源は買えます。
そんなものに命を掛けなくてもよいです。最近の電源は内部に直流400Vほど掛かっていたりします。
寝ている間や外出した時に火災になるかもしれません。感電して死ぬかもしれませんし、助かっても後遺症が残るかもしれません。
掲載内容については各自自己責任で各自が判断してください。内容の正確性は保証しませんのであしからず。

某所より、突然電源が入らなくなった電源をもらいました。
まずはサクッと分解してみます。
まず目に飛び込んできたのは、真っ黒になってヒビが入っているヒューズです。


ちょっと見づらいので、取り出してみます。


ヒビが入っています。相当激しく切れたようです。
この事から、何処かがショートして切れたと推測されます。
電源でショートするとなると、真っ先に浮かぶのがFETなどパワー系素子です。
その場合、大電流や発熱により、パッケージが弾け飛ぶとか、基板が変色もしくは黒焦げになります。
基板を見てみます。何故か予想に反し綺麗なものです。全体的にパターンが細かったり、それをカバーするためにリード線の切れ端を半田で盛っていたりしますが(汗


となると、ショートの線は違うのでしょうか?
確認のため、ACラインの抵抗を測ると、短絡状態です。
これで、1次側の何処かが短絡していることは分かりました。


こうなると、あとは地味な作業です。
ACライン上のめぼしい部品を一つずつ剥がしていき、ショートがなくなればその部品が破損しています。
まずは破損したヒューズを除去します。


取り出したら割れてしまいました。
中に木綿糸?が入っていました。
ヒューズの型番はT8AL250V。
250V 8Aの遅延型ですね。
うん?8A??

この電源はMAX300Wなんですが、基板上には6.3Aと書いてあったような・・・

一次側のXコン、Yコンなどは外見的にはクラックや焦げた跡は見られず。一応外してみたけど問題なし。
コモンモードチョークコイルも問題なし。
パターンが細いせいか、pbフリーの半田のはずがバスバス抜けます。今まで修理した電源の中でダントツに部品が外しやすいです。てかほんとpbフリー半田かこれ??

うーん。あとはブリッジダイオードか。ってお前が犯人か!!


さて、少し困りました。電源は過去いくつか修理した都合上、よく壊れるコンデンサは手持ちがあります。
ですが、ブリッジダイオードがショートモードで壊れるのは今回初です。なので、余剰部品の持ち合わせがありません。
しかも、こういう部品を売ってるジャンクショップはもう閉店してしまったしOrz
規格上は600V6Aですね。秋月だとこのあたりが使えそうかな?

っと広島では入手できそうにないので、ダイオード単品でブリッジを組みます。
幸いプリント基板では両方対応できるようになっていました。


買ってきたのはIN5406。600V3Aです。一つ105円もした。広島では部品が高い・・・
これをサクッと付けます。ブリッジダイオードはあまり発熱しないのですが、気持ち足を長くして放熱できるようにしておきました。


あとは割れたヒューズを交換。
広島で入手可能なヒューズの種類はなく、一般的なものしか入手できないので、普通の250V7Aをセット。(6.3Aなんて中途半端なものは入手できなかったので)
突入電流で飛ぶかな?まぁ大丈夫でしょう。
ついでに3.3Vラインのコンデンサが一つパンクしていたので交換。
10V2200uFで低ESRなものは手持ちがなかったので、6.3V3300uFに交換。
ただ、部品の配置が悪く、コンデンサを取り囲むように大きめの抵抗が2本も隣接しているので、ほかのコンデンサも多分ダメだろうなぁ。てかなんでこんな配置したし。
しかも各ラインコンデンサ2個だけとか。


さて、最初に故障診断し、予測した修理箇所について、対応できることはやりました。
ACラインのショートはなくなりました。あと基板上でリード線が長くてショートしそうな個所は直しておきます。
これは、ケースに再度組み入れるとき指やケースの端などを不意にぶつけてしまい、ショートすることを防ぐのと、こういうところに埃が詰まるとマズイためです。

今回は半田が足りそうなところはとりあえず見当たらなかったので、追い半田はいいでしょう。
まずは電源単品でテストしたいところですが、面倒なので(ぉぃ 毎度電源の被験者になってくれている、実験用ATOM君に頑張ってもらいます。
どうせしくじってもヒューズが飛ぶか煙が出るくらいでしょう。


いざ電源ON!
マザーのLEDがついたので、5VスタンバイはOK。
電源を入れると、PCが起動し、ファンが回りだしたので、動作は問題ないようです。
BIOSで電圧を見てみます。おおむね問題なさそう。


では、耐久テストといきます。
ダミーロードなんて一般家庭にはないので、ちょうど手元にあったUbuntu16.04をインストールしてみます。


異常発熱とか、変なにおいがしたり、漏電したり電圧が不安定になるなどもなく、問題なさそうです。
インストールしたUbuntuで負荷をかけるため、DVDを再生してみましたが、普通に見終わってしまった(笑)ので、無事修理できたようです。

以外にも、ファンの音が静かだったので、わが自宅サーバの五月蠅い小型電源と交換することにしました。
小型電源は230W、時代が違うとはいえここまで大きさに差があるとは・・・


なお、余談ですが、この電源で使用されている制御用ICは2005Zというものでした。
色々使われているようで、ググるとロシア辺りのサイトで回路図が見つかります。


何故制御用ICを調べたかというと、大抵安物電源は、制御用ICのリファレンス設計をベースに部品をいくつか省略(!)していることが多く、例えば、「本当にこのコンデンサの耐圧合ってる?」とか調べるときに役に立ちます。
あと修理するうえで参考になる回路図があると、大体の構造や部品の役割が把握できるので助かります。
まぁ無ければ頑張って書くしかないし、実物から回路図を書けないとそれはそれで困るんですが。


2016年6月11日土曜日

LT駆動開発 26 - Extended 報告会 後朝祭で発表してきました。

LT駆動開発 26 - Extended 報告会 後朝祭で発表してきました。

今回は前日に2本のLTを仕上げるという、むっちゃ忙しい中がんばりました。

一つ目は、Simの容量が気になって安眠できないとして、ちょっと話題になった0Simの容量警告スクリプトを作成した内容を話しました。
スライドはこちら。
そのうちアプリが出るだろう。とおもっていましたが、一向に出る気配がないので、容量をチェックして、2か月未利用だと警告メールを送るスクリプトを作成しました。
どうせ作るなら、今後の応用ができるように、Rubyでスクレイピングやmechanizeで認証突破、SQLiteやメール送信など一通りの基本機能を盛り込みました。

次に、去年OSC島根でGetしたSRAMで遊んだ内容を話しました。




SRAMはDRAMに比べて扱いやすい。という話はよく聞きますが、果たして本当でしょうか??
という素朴な疑問を持ち続きて数十年。実物を入手し、Arduinoで実験しました。

たしかに前回チャレンジしたDRAMより圧倒的に簡単でしたが、すっかりC言語を忘れていたのでかなり苦戦しました・・・・
疑問に思ったことを仮説を立てつつあれこれ調べながら試行錯誤するのは楽しいですね。




2016年5月25日水曜日

自分が所有するSnapShotで、AMIがないものを探索するスクリプトを作ってみた

AWSを使っていて、気軽にEC2をスナップショットとったり、消したりしているのですが、
AMI削除したのに、何故かスナップショットが残ることがあり、地味に課金されていたので、
気が付いたら消していたのですが、そもそも自動で消えない仕様ということらしいので、
探索するスクリプトを作成してみました。

スクリプトはここらあたりにあります。

まぁ実はコンパネから全スナップショットを選択して削除すれば、
AMIがあるやつはエラーになるので、結果的に消せるんですが、警告無視した結果もろとも消してしまったので・・・

2016年5月24日火曜日

ThinkPad X100eとThinkPad Edge 11の液晶を交換してみた。

某所にて、バッテリが充電しないThinkPad Edge 11の中古を入手しました。
バッテリが充電しない原因は単純にバッテリが死んでいただけでしたので、とりあえずX100eのバッテリをつかって、動作確認をしていたのですが、どうもあのピカピカ液晶が我慢ならず、もう引退したX100eの液晶と交換しました。

なお、液晶パネル交換はかなり神経を使う細かい作業になります。
詳細な手順は記載しませんので、まぁこんなものか。と参考程度に見てください。
当然分解すると保証はなくなりますし、接触不良で発煙するかもしれませんし、最悪マザボや液晶を壊すかもしれません。その辺り覚悟のうえ自己責任で行っております。


X100eとEdge 11 は見た目も大きさも大変良く似ているばかりか、キーボードやHDDを付ける金具、バッテリなど結構部品が流用されています。さすが後継機ですね。
通常ノートPCの液晶パネルは、たとえ同じインチ数でも駆動方法やコネクタ、バックライト回りや取り付けるねじの位置など結構差異があり、ほぼ流用は不可なんですが、このX100eとEdge 11は同じコネクタ、駆動方式で流用が可能。ということは調べがついています。

ではまずは移植元となる、X100eの液晶パネルを取り出します。
液晶の外枠の下にある隠しねじを慎重に外し、液晶面から左右の枠を少しづつ外していきます。
ヒンジの個所や、上の角の所は爪が固くなかなか外れませんが、焦って力任せにせず、ほかの外せるところから外していきます。
焦ったり無理やり外すと十中八九、爪が折れます。

外すとパネルがむき出しになります。


いろいろやり方はあるのですが、自分の場合液晶パネルを外す際はこのように180度倒した状態で作業します。
これは、立てたまま作業すると、ねじを外した際パネルが倒れて、後ろにある配線が切れたりすることを防ぐためです。

ではまず、ヒンジの個所にある、パネルを止めているねじから外していき、次にサイドのねじを外していきます。
この再使用する精密ドライバーは、100均のような安物を使わないほうが良いです。高確率でねじの頭を潰します。適切な道具を使用することを強くお勧めします。

パネルのねじを全部外したら、カメラのある上部からゆっくりとパネルを持ち上げます。
パネルの後ろに、両面テープでフィルム状のケーブルが張り付いているので、マイナスドライバーなど先のとがったものではなく、ピンセットなどで少しづつ剥がします。
その際、カメラモジュールを外したほうが作業がやりやすいので、カメラモジュールから配線を外すのが難しい場合は、モジュールごと外してしまうほうがいいです。

この配線は大変細く、切れやすいものになります。慎重に剥がします。
剥がしましたら、ヒンジ部分にあるケーブルに気を付けつつ、パネルをキーボード側に倒します。
ヒンジ側から見て左下に、液晶と接続している金色の小さいコネクタがあります。
その上に透明の割と厚手で丈夫なフィルムが張り付いていますので、指紋など付けないよう慎重にピンセットなどで剥がします。
フィルムがはげたら、液晶パネルを接続している小さいコネクタの左右の出っ張りを細心の注意を払いながら、左右少しづつ押して外します。
絶対に銀色(灰色?)のケーブルを引っ張って抜いてはいけません!!
なかなか抜けませんが、ここでもマイナスドライバーとか持ち出してはいけません。爪の先かプラスティックの角などで慎重に押して外します。

移植先のEdge 11も同様にパネルを外します。
基本的にX100eと同じですが、パネルの後ろに走っているケーブルと、TOPパネルについているLEDへの配線が張り付いているので、気を付けて外します。
参考までに、裏側の配線はこんな感じでついています。


この写真は撮影のため液晶のコネクタを外していますが、実際は接続されているので、カメラの配線がついたまま液晶パネルを倒すと、カメラとパネルの配線の付け根が裂けてお亡くなりになります。

両方外れたら、あとは逆の手順で組み立てます。
パネルのコネクタは、極細で無理するとすぐ壊れますので、慎重に、真っすぐ奥まで差し込みます。
その後、外れないように、もともとついていたフィルムを張り付けます。

ねじを締める際、特にヒンジ部のねじは緩いと将来破損します。かといって絞めすぎると割れます。
ヒンジ部のねじは、ある程度絞めたら、パネルを前後に動かしながら左右均等に絞めるのがコツです。

こんな感じで無事交換完了です。


ノングレア液晶になり、電車内で日が差しても反射することなく快適に過ごせます。
ただし、ホットキーでの液晶の明るさ変更がおかしくなりました。
もしかしたら、明るさを変化する割合が違うのかもしれません。

しかし、なんであんなピカピカ液晶の製品出すんですかね・・・

2016年5月23日月曜日

DockerをWebで管理するツールを試してみた

この記事はすごい広島#157の成果物兼如法会1の発表ネタになる予定のものです。

如法会の当日現場で作っていたスライドはコレです。



DockerをGUIで使いたい! from Akira Kaneda


とある一般家庭の自宅サーバで検証しました。
Hyper-V上でDocerは問題なく動作します。

ただ、今回WeaveScopeのデモも兼ねてたくさんコンテナを稼働させた結果、ディスクIOとメモリが不足するという事態になりました。
メモリ4Gにしたのですが、しばらくするとコンテナがバシバシ死んでいく・・・・

Hyper-Vなど仮想マシンを使っていてもそうなのですが、ディスクIOは割と重要です。
Dockerはさらに頻繁にコンテナが生成、削除をやるので、ディスクIOは結構響きます。
ディスクIO待ちの結果ロードアベレージがガシガシ上がる・・・なんてことになりました。


2016年5月8日日曜日

AnsibleでUnicodeDecodeError: 'ascii' codec can't decode byte 0xe5 in position 79が出る。

Ansibleを使っていて、何かの拍子に上記エラーが出たのでメモ。

UnicodeDecodeError: 'ascii' codec can't decode byte 0xe5 in position 79:
ordinal not in range(128)

ググると、ここが見つかった。

対応方法としては、site-packagesディレクトリ内に以下の内容をsitecustomize.pyというファイル名で保存。

import sys
sys.setdefaultencoding('utf-8')
デフォルトエンコードをutf-8に変更すればよい。

2016年4月22日金曜日

Ansibleでmsg: the python mysqldb module is requiredが出る。

AnsibleでMySQLを利用する場合、MySQLモジュールを使うのですが、msg: the python mysqldb module is requiredというエラーメッセージが出ることがあります。
これは、サーバ側にPythonのMySQLライブラリが無い。ということなんですね。AnsibleはサーバにSSHで接続後、プレイブックにあるタスクを一つ一つ一時的なPythonスクリプトに変換して実行しています。これの動作に必要なんですが、解決法として、pipもしくはyumなどでMySQL-Pythonをインストール。というのがググれば出てきます。

大抵これで解決はするのですが、インストールしたにもかかわらず、msg: the python mysqldb module is requiredが出続ける場合、サーバ上のPythonのバージョンを確認してください。

実はOSによっては、Pythonのバージョンによって、MySQL-Python27のようにパッケージ名が異なるものがあります。

デフォルトでインストールされるライブラリがPythonのバージョンに依存していないか確認しましょう。

2016年4月21日木曜日

Ansibleで"No authentication methods available"がでてつながらない

Ansibleで"No authentication methods available"が出て何故かSSHにつながらず、ずいぶん嵌ったのでメモ。

Ansibleで、Hostsファイル(インベントリファイル)にSSH接続情報を設定して、その内容に間違いがないにもかかわらず、何故かSSHで接続できないとき。

ググると、SSHキーのパーミッションがどうとか出てくるのですが、SSHコマンドでは無事接続できる。

で、原因はこちら。

[target_server]
127.0.0.1 anshible_port=2222 anshible_ssh_user=vagrant anshible_ssh_pass=vagrant

お分かりいただけただろうか。正解はansibleです。

これ、焦っているときは本気で気づかないのでたちが悪いです。

2016年4月20日水曜日

Rubyでハッシュキーにシンボルを使った場合、代入式を短縮できる。

Chefのレシピをメンテしていて、Rubyのよく分からないものの一つにシンボルがあります。

で、これ、ハッシュ配列と組み合わせると、初心者にはよくわからないものになります。

a = { :A => "a", :B => "b"}

これは、シンボル:Aにaを代入しています。これはまぁOK。

a = { A: "a", B: "b"}

=>が消えまして、そのかわり前にあったコロンが後ろにつきます。
これは、=>を短縮したものなんですが、前にコロンが付くものがシンボルと思っていると訳が分からなくなります。

これの値を取り出すのは、 a[:A]になります。

ハッシュ配列に似たもの?として、構造体があります。
構造体はC言語の授業でならった人も多いと思います。

a = Struct.new(:ID,:Name)
rec = a.new(123,"taro")
pp rec.ID
みたいな感じで使います。
組み合わせて、ハッシュ配列に構造体を入れたり、配列を入れたりできます。
個人的には、a.bみたいな感じで値を取り出せる構造体が好みなんですが、Ruby的にはハッシュ配列が良いようですね。いろんなコード見ていますと。
(まぁ構造体だとメソッドとパッと見区別がつきにくい。てのがあるのかも)

最後に、Chefのレシピをメンテしていて、

a = {a: "a",b: "b}"
pp a.fetch(:a)

のようなコードを見て、なんでa[:a]じゃないんだろ?と疑問に思い調べてみました。
[]の場合、キーが存在しない場合、nilが帰ってきて、例外になりませんが、fetchの場合、key not found例外が発生します。
きちんと例外処理をしたい個所では使い分けないとなと思います。

参考:Rubyのややこしい配列とハッシュとシンボルについて整理してみた



2016年4月6日水曜日

JenkinsでProxy Errorが出る場合の対処方法

Jenkins+Apacheで動かしているとき、時々Proxy Errorが出ることがあります。

これ、時々ってのが厄介で、大抵はリロードすれば直ります。
今回、これの原因ぽいのが判明したのでメモっておきます。

Proxy Errorが出る環境は、Jenkins+Apacheでmod_proxyを使っている場合に出ますが、
どうやら、httpsにリダイレクトさせている環境で発生するようです。

というわけで、同様の事例がないか調べてみました。

どうやら、Apacheはhttpsなのに、レスポンスヘッダがhttpなのがいけないらしい。参考
なお、レスポンスヘッダの見方は以下の通り。

curl -ik https://foobar.example.com/jenkins
原因がわかれば対処ができます。参考サイトを参考に
RequestHeader set X-Forwarded-Proto "https"
RequestHeader set X-Forwarded-Port "443"

を追記してあげると無事直りました。

*Nginxの場合は以下のような感じ。(http->httpの例)
(--prefix=/jenkinsを付けているからと、
proxy_redirect http://localhost:8080/jenkins
なんてやるとダメだったので、バックエンドには付けないほうが良いみたい。)

location ^~ /jenkins {
proxy_pass http://localhost:8080;
proxy_read_timeout 90;
# Fix the “It appears that your reverse proxy set up is broken" error.
proxy_redirect http://localhost:8080 $scheme://$host;
# Optionally, require HTTP basic auth.
# auth_basic "Please authenticate to use Jenkins";
# auth_basic_user_file /opt/nginx/htpasswd;
}

2016年2月28日日曜日

EdgeRouter LITEのファームを上げてみた

購入してから一度もファームを上げていなかったので、今回ファームを上げてみました。

まず、ファームはここから入手します。

シリアルコンソールからのファームのアップデート方法は不明だったので、今回Webインターフェースから上げます。

まず、EdgeRouterに適当なIPを割り当ててログインします。


ログインしますと、今風な画面が出ます。自分は購入時点のVer1.2です。



少々見にくいのですが、下のほうにちょこっとsystemというタブがありますので、そこをクリックします。



右のほうにUpgradeSystemImageというのがあるので、Upload Fileという赤いボタンを押し、
ダウンロードしたファームウエアをアップロードします。

再起動するよ。というダイアログが出ます。



再起動します。シリアルコンソールでつないでいると、再起動時の様子が見えます。
あ、コケていますね。(汗



とりあえず起動はしたようなので、Webインターフェースにログインします。
一応ファームは上がったようです。



さて、こけた原因なんですが、OpenVPN周りの設定が綺麗に消し飛んでいます。



Vyattaの時もそうだったのですが、EdgeOSもそうか・・・
市販のルータと違い、Vyattaはファームアップグレード時、以前のConfが読めなくなることがあります。
その際、以前のConfをリネームしてくれたりとかはしてくれず、読めないものはこのように消えたりします。
基本的にはConfのバックアップなりから再度設定を流しなおすなりすればいいのですが。

(補足:EdgeOSのバージョンアップで、基になるdebianのバージョンが上がることがあります。その際、リポジトリを追加していたりした場合、リポジトリを変更する必要があります。)


どうもConfを読み込みperlなどをつかって、iptablesなど各種設定を行うのですが、これが時々順番が前後するのか失敗することがあります。
そうなると、成功した設定だけを反映した中途半端な状態で起動してしまいます。
しかもConfも中途半端な状態になるし・・・


あと、バージョンが上がって、OpenVPNの証明書を作成するeasy-rsaコマンドが無くなったようです。
別のマシンで作成してアップロードするしかないかな。