趣味の電子工作などの記録。時にLinuxへ行ったり、ガジェットに浮気したりするので、なかなかまとまらない。※サイト移転しました(tomono.eleho.net ⇒ tomono.tokyo)
RSS icon
  • サイトのSSL対応化

    投稿日 2018年 7月 5日 コメントはありません

    さくらのレンタルサーバの資料をみていたら、Let’s Encryptを使ったSSL化が簡単にできることがわかりました。

    ・・・といっても、本当に簡単で、マニュアルに沿って作業するだけです。CLIも必要なく、GUIだけで適用できました。

    1.SSL設定の有効化と確認

    マニュアル(『【無料SSL】サーバコントロールパネルからの導入手順』)に沿って作業するだけです。気をつけるとすると、マニュアル内にも書いてありますが、発行完了のメールが来るのに多少時間がかかります。15分くらいかかったでしょうか。ま、そんなレベルです。

    2.WordPressでの常時SSL有効化プラグインの導入

    さくらのレンタルサーバ専用の常時SSL有効化プラグインを導入して有効化します。これも、マニュアル(『【WordPress】常時SSL化プラグインの使い方』)に沿って作業するだけです。
    これだけでサイトがSSL対応できちゃいました。


  • サーバのPHPのバージョンを推奨バージョンに戻す

    投稿日 2018年 7月 3日 コメントはありません

    WordPressの引っ越しを行った際に、PHPのVer7系だと記事が表示されない現象があり、Ver5系に変更したのですが、その後調べてみるとWordPress自体はPHPのVer7系に対応していることがわかりました。さらに調べていくと、テーマやプラグインがPHPのVer7系に対応していないケースで発生することがわかってきました。

    セキュリティ面では最新のバージョンを使うに越したことはないので、なんとかならないか調べていたところ、PHP Compatibility ChekerというWordPressのプラグインを使うと問題点のチェックができることがわかったので、インストールして確認してみました。

    その結果、やはりテーマやプラグインに問題があるものが見つかりました。プラグインの出力するレポートにどのファイルの何行目がNGが記載されていますので、これを順に見ていくことにします。

    テーマについては、式の評価の部分がPHPのバージョンによって差があるところが検知されましたので、これをPHPのバージョンに関わらず同じ評価になるように{}を追加しました。具体的には、

    という記述をすると、PHP5では、

    と解釈されるのですが、PHP7では、

    と解釈されるようです。(参考:http://php.net/manual/en/migration70.incompatible.php)
    そこで、この$$が2つ続く箇所については{}を追加して、常にPHP5と同じ解釈になるように修正しました。

    他には、

    • Throws SPAM Awayというプラグイン
      セキュリティ上の課題で変更になった関数(spilt() ⇒ preg_split())の単純な置き換え
    • WP SyntaxHighlighterというプラグイン
      MySQLサーバのバージョン取得の関数(mysql_get_server_info() ⇒ mysqli_get_server_info())の単純な置き換え

    を行いました。
    また、使用していないプラグインについては停止・削除を行いました。

    一通りの整理を行った後、再度チェックをかけるとエラーはなくなったので、PHPのバージョンをさくらのレンタルサーバで標準の7系にしたところ、それでもきちんと表示できるようになりました。

    これとは別に、Crayon Syntax Highlighterというコードをきれいに表示してくれるプラグインが入っていたのですが、停止していました。その理由は、記号が化けてしまうからだったのですが、今回、ぐぐってみたところ、Crayon Syntax HighlighterのSettingの中のCodeのセクションにある「Decode HTML entities in code」にチェックを入れると治ったので、逆に有効化してあります。


  • WordPressの引っ越し&ドメイン変更作業

    投稿日 2018年 7月 1日 コメントはありません

    これまでドメインキングとさくらのVPSの組み合わせで運用してきた当ページですが、元々VPSの運用が面倒臭くなっていたし、CentOS6.5もサポート終了があと2年半くらいまで迫っていたのでどうしようかなー、と思っていたところにドメインキングの大幅値上げ(確か100円/月⇒500円/月)の話が来たので、この機に環境を一新することにしました。ドメインキングの値上げは Plesk の一方的な値上げという話だったと思いますが、さすがに5倍となると看過できません。12月の次回支払い時期の前に移行することにしました。

    で、元の構成はドメインキングでドメイン(+Webサーバもあるけど使ってない)取得、サーバはさくらのVPS(1Gプラン)上にCentOS6.5という組み合わせでした。

    移行後の構成は、新しいドメインを .tokyo ドメインで取得、サーバはアップデート管理の手間を省きたいので共用レンタルサーバ(さくらのレンタルサーバスタンダード)としました。まあ、CentOS6.5でも自動アップデートを有効にしていたので、それほど手間ではなかったのですが、移行後の構築の手間も考えるとレンタルサーバでいいか、ということにしました。

    で、移行自体は半日くらいで終わったのですが、せっかくなので作業手順のメモを残しておきたいと思います。

    1.Wordpressのデータバックアップ

    旧サーバー(VPS)上でWordPressのデータのバックアップを取ります。

    2.データベースのバックアップ

    次に、phpMyAdminを使ってデータベースのバックアップを行います。バックアップの方法は『【WordPress】さくらインターネットに移転(引越し)する方法』を参考にさせていただきました。

    3.さくらのレンタルサーバ(スタンダード)の契約

    契約できたら、サーバパスワードの変更を行います。メールで仮パスワードが送られてくるので、これを変更。変更後は、初期ドメイン名でsshログインできるようになります。

    4.お名前.com で新ドメインの契約

    手順は・・・・省略。whois代行があるのがいいですよね。あと、インフレ気味ですが、いろんなドメインがあるとことか。

    5.お名前.comで取得したドメインをさくらのレンタルサーバで使用する設定を行う

    基本的な流れとしては、さくらのレンタルサーバのサーバコントロールパネルで、「新しいドメインの追加」を行い、新しいドメインとレンタルサーバ上のディレクトリとの紐付けを行います。紐付けるディレクトリは別途作成が必要です。
    その後で、お名前.com側のドメインNaviで対象のドメインで使用するネームサーバーをさくらインターネット側で指定されたネームサーバに変更します。
    実施にあたっては『お名前.comで取得したドメインをさくらサーバーで使用する』を参考にさせていただきました。

    6.さくら上でデータベースの復元

    データベースの復元はサーバにログインしてシェル上で行いました。シェルが使えるなら、その方がずっと楽で簡単で一瞬で終わります。

    方法は、『MySQL/MariaDB コマンドを使った復元』を参考にさせていただきました。

    7.ドメイン変更に伴うデータベースの修正

    今回はドメインの変更を伴っていますので、WordPressの中のデータも修正しないといけません。そのためのツールがあるようで、『WordPressのサーバー移行_ドメイン変更の手順』を参考に、Search and Replace for WordPress Databases を使って新サーバー上でURLの置き換えを行いました。

    8.PHPのバージョンを5系に下げた

    アクセスしてみると、記事の本文が表示されない現象に悩まされました。ぐぐってみると、PHPのバージョンによって起きることあるらしいことが判明。確かに旧サーバは5系、新サーバーはデフォルトでは7系になっていました。さくらのサーバコントロールパネルでバージョンを7系から5系に下げたところ、本文が表示されるようになり、一通りの問題は解決したようです。

    9.バックアップ用のシェルスクリプトの作成

    データとデータベースのバックアップをするスクリプトを書いておきました。時々走らせようと思います。

    10.旧サーバーからのリダイレクトの設定

    旧サーバーはドメインキングのDNSサーバー設定でさくらのVPSのIPアドレスを返していました。
    できれば、さっさとさくらのVPSは解約したいので、ドメインキングのサーバ上に .htaccess を置いて、リダイレクトさせることにしました。

    <.htaccessの内容>

    .htaccessを設置したら、DNSの設定を変更します。設定の中から

    のレコードを削除します。

    あとは、DNS情報が行き渡るのを待ちます。


  • サイトを移転しました

    投稿日 2018年 7月 1日 コメントはありません

    2018年7月1日にサイトを移転しました。
    旧URL: tomono.eleho.net ⇒ 新URL: tomono.tokyo
    当面はURLのリダイレクトを行いますが、年内中にリダイレクトを停止する予定です。


  • MongoDBについて調べてみた

    投稿日 2018年 5月 13日 コメントはありません

    いろいろあって、MongoDBについて調べてます。

    調べた結果をメモしておきます。


  • WordPressでログインできなくなった!

    投稿日 2017年 2月 27日 コメントはありません

    WordPressでログイン認証のセキュリティ強化にCAPTCHAを入れようと、プラグインから「SI CAPTCHA Anti-Spam」をインストールしてみました。

    設定でログイン画面にキャプチャを入れて、ログアウトしてログインしなおしたらCAPTCHAが表示されていません(!)。

    しかも、ログインできない!!

    で、調べてみると、「SI CAPTCHA Anti-Spam」には、GDというライブラリが必要なので、

    としてインストールを試みるも、さくらのVPSにインストールしたPHPのバージョンが合わずphp-gdがインストールができません。

    で、四苦八苦した挙句の解決方法は、「プラグインディレクトリの名前を一時的に変更する」という方法でした。

    /home/(ユーザー名)/public_html/wordpress/wp-contents/plugins にカレントディレクトリを変更して、プラグインの名前の付いたディレクトリの名前を一時的に変更してやると、無事にログインできました。

    ログインしたら、ディレクトリの名前を元に戻して、プラグインを停止・削除しました。

    いや、焦りました・・(^^;


  • 安価なVPSを調査してみました

    投稿日 2017年 1月 30日 コメントはありません

    最近、激安VPSがまた増えている気がします。概ね、月額500円あたりが最下限で、1日使うだけでも500円を切ることができなかったのですが、日割り、時間課金のタイプもでてきているので、改めて調べてみます。あ、企業で契約するようなVPSはそもそも調べてませんw。ローエンドのVPSだけです。あしからず。

    • さくらのVPS
      ローエンドのVPSの代表といえばさくらのVPSでしょう。いまご覧頂いているページもさくらのVPSの1Gプラン(ただしHDD100GB)で動いてます。そんなにトラフィックないので、512プランでも十分だと思いますが。
      ちなみに、1Gプランが『CPU仮想2Core/SSD30GB/メモリ1GB』で月額972円/年額10,692円/初期費用1,620円(税込み)、512プランが『CPU仮想1Core/SSD20GB/メモリ512MB』で月額685円/年額7,543円/初期費用1,620円(税込み)です。
    • カゴヤ・クラウド
      ここは早くから日額課金があったところになります。SSDタイプAが『CPU仮想3Core/SSD80GB/メモリ保証1GB最大2GB』で日額31円/月額864円/初期費用無料(税込み)です。日額課金は実験や短期間のサーバ設置に便利だったので使ったことがあるのですが、去年の11月にクレジットカード番号を含めて漏洩する事件を起こしたので信用できません。支払いシステムを変更したので大丈夫とか言ってるのですが、生理的に受け付けられません。もしも、バーチャルカードで払えるならもう一度登録してもいいかとは思いますが。
    • ConoHa
      時間課金をやり始めたところです。512MBプランが『CPU仮想1Core/SSD20GB/メモリ512MB』で1時間1円/月額630円/初期費用無料、最低利用期間なし、といったところ。OSはいろいろ選べる。
    • WebARENA
      ポイント制というちょっと変わった課金体型。一番安い条件だと512M-SSDタイプで『CPU仮想1Core/SSD20GB/メモリ512MB』で10ポイントで、その10ポイントの月額基本料金が360円(税別、税込みだと388円)。課金はスタート時は日割り+月末締め。ちょっと変わっているのが、支払いは翌月分を先払い、というところ。OSはCentOS6のみ。
      NTT系なので、クレジットカードのセキュリティとかはまともにやってくれると期待できる・・・と思うので、試してみても良いかもしれない。
    • ServerMan@VPS
      メモリ1GB/HDD50GBで月額467円(税別)、ただしコンテナ型なのでカーネルを共有する形になるらしい。
    • ABLENET
      V0プランで『CPU仮想1Core/SSD30GB/メモリ512MB』で月額648円/年払い5,486円(税別)/初期費用934円だそうです。
    • FC2 VPS
      バリュープランで『CPU1Core✕13%/HDD80GB/メモリ1GB』で月額780円/初期費用なし。OSはCentOS6.3。
    • お名前.com VPS
      メモリ1GBプランで『CPU仮想2Core/HDD100GB/メモリ1GB』で月額896円/初期費用無し(税別)。

    着目すべきは、WebARENAの月額360円+消費税と、ConoHaの1時間1円でしょうか。


  • ESP8266でjumpwire.ioを試してみた

    投稿日 2015年 8月 9日 コメントはありません

    ESP8266についてググっていたら、広告欄に何やら「jumpwire.io」なるものが出てました。確か、ESP8266を使ったクラウドサーバーなんちゃらとか(細かい内容は忘れました)。

    とりあえずクリックしてみたら「MakerのためのIoTプラットフォーム」「Arduinoを5分でクラウドにつないで、あなたのIoTプロジェクトを成功に導きます。」だそうです。なんでも無料でお試しができるようなので、試してみることにしました。環境はUbuntu14.10LTS 64bit版 + ArduinoIDE1.6.5 + esp8266 version 1.6.5-947-g39819f0(ボードパッケージ)です。ボードパッケージのインストールまでの方法はこちらの記事を参照。

    無料サインアップ・・・から先は英語ですが、めげずに登録してみます。よくある「ユーザーIDはメールアドレス」ってやつです。ユーザーIDと設定するパスワードを打ち込むと、メールアドレス宛にアクティベート用のメールが届くので、そこにあるリンクをクリックするとサインアップ完了です。
    で、改めてログインし直します。(これもよくあるパターン)

    ログインすると、いきなり秘密のトークン(Secret token)が表示されます。この画面をコンソールと呼ぶようです。プロジェクトは無料で5つ作れて、A〜Eというアルファベットになるようです。で、プロジェクトごとにKEYが26個(A〜Z)セットできるようです。

    ここで一旦中断し、ローカル側(クライアント側)のプログラミングに戻ります。今回はgithubにライブラリとサンプルがあるようなので、これを動かしてみます。

    まず、gitでライブラリを持ってきます。

    これで~/Arduino/libraries/JWIO_ESP8266_ArduinoIDEの下にサンプルスケッチ(Sample_Sketch.ino)までコピーされますので、これをスケッチが保存されるべき場所にコピーします。

    これで「スケッチを開く」で、~/Arduino/JWIO_ESP8266_ArduinoIDE/ の下のSample_Sketch.inoを開きます。

    サンプルスケッチの冒頭に、

    という箇所がありますので、ここにWiFiの設定と、さっき出たSecret tokenをセットします。4つ目のAは多分プロジェクト名でしょうか、そのままにしておきます。

    下の方に

    という箇所があります。自分はGPIO2を使うので、ここを5から2に変更しておきます。後の方のdigitalWrite()のところも同様に修正しました。
    修正後のソースはこんな感じです。(開示できない箇所はxxxxxxxxxxxxxになってます)

    さて、ここで「マイコンに書き込み」とすると、コンパイルエラーが発生しました。

    だそうです。そこでサンプルソースの冒頭の

    とすることで、ビルド&書き込み、実行ができました。
    ログを見ていると、ところどころでなにやらWebSocket関連でエラーが発生しているっぽい感じもしますが、先に開いたjumpwire.ioのログインコンソール上にKey BとしてESP8266側から経過時間が設定されているのがわかります。(下記画面だと418秒経過後)

    Screenshot0001

    さらに、Webコンソールの下の方にはData logとしてログが表示されています。

    ArduinoIDEのシリアルコンソールにはラウンドトリップタイムも表示されていますが、自分の環境からだと150msくらいかかっているようです。

    そして、ブラウザ上で「Value」のところに1をセットして「Throw」を押すと、点灯していたLEDが消灯しました。0をセットして「Throw」を押すと、消灯していたLEDが点灯しました。ソースのコメントとは逆の動作ですが、これは回路の差によるものでしょう。

    サンプルソースを修正して以下のようにしてみました。

    GPIO0についているスイッチの状態が変化した場合にKey-Cの値をスイッチの状態に応じて0/1に変化させるように修正してみました。(無事動きました)

    公式サイトに日本語版の説明もない状態で動かしているため?)ログを見ていると途中でWebsocketが切れるみたいで、安定性に若干不安を感じないでもないですが、jumpwire.ioはシンプルに動くので、確かに手早くクライアント(ESP8266)の状態をブラウザで確認できるようにしておきたい、とにかく短期間でクラウドでデータ収集できるようにしたい、という場合には簡単でいいと思います。

    ちなみに、サインアップしてからこの記事を書きつつサンプルを改造したもの(ボタンの状態がアップロードされるように修正したもの)を動かすまでに要した時間は約1.5時間です。5分はちょっと眉唾ものとしても、ArduinoIDEでESP8266が動く状態からなら動かすだけなら30分もあれば十分動かせるでしょう。確かに非常にお手軽ですので、知っておいて損はないと思います。


  • ESP8266にWebSocketを喋らせてみる

    投稿日 2015年 7月 29日 コメントはありません

    世の中、同じようなことを考える方はいるようで、すでにESP8266+ArduinoIDEでWebSocketライブラリが存在しています。WebSocketが扱えるようになれば、(プログラミングスキルがあれば)クラウド側から好きなタイミングでESP8266に指示をおくることができるようになるはずです。(が、世の中そんなに甘くないんですねぇ〜)

    で、今回見つけたWebSocketライブラリは ESP8266-Websocket です。

    今回の記事はこれのサンプルを動かしてみよう、と苦戦した記録です。作業PCのOSはUbuntu14.10 LTS 64bit、ArduinoIDEのバージョンは1.6.5です。なお、Ubuntuで動かすにあたっては、

    として、/dev/ttyUSB0のアクセス権をユーザーにつけた後、再ログインしないと/dev/ttyUSB0へアクセスできないとしてエラーになります。

    Arduinoのライブラリは ~/Arduino/librariesの下に置けばいいようですので、そこにgitでライブラリを引っ張ってきます。

    その後、ArduinoIDEで「スケッチ」→「Include Library」→「Manage Libraries」で右上の「Filter your search」で「ESP8266-Websocket」と入力して「INSTALLED」になっていることを確認します。

    scrn1

    次に、WebSocketClientのデモを動かしてみます。

    「ファイル」→「スケッチの例」→「ESP8266-Websocket」→「WebSocketClient_Demo」を選択します。

    scren2

    ソースの冒頭の

    の部分に自分の無線LANのESSIDとパスキーを入力してから、名前を付けて保存します。

    このライブラリはおそらくWindows環境で作成されたのでしょう。Linux環境でビルドしようとすると、ファイル名の大文字小文字で失敗します。そのため、ライブラリの中の以下の部分を修正します。

    WebSocketClient.h と WebSocketServer.h の

    に、

    WebSocketServer.cpp と WebSocketClient.cppの

    とします。

    これでビルドが通るようになりましたが、それでもコネクションに失敗します。禁断のgoto文で接続しに行く部分のみを繰り返すと、何回目か以降は通るようです。ライブラリのWebSocketClient.cppの冒頭にデバッグのための#define文があるので、ここをコメントを外すとデバッグメッセージが出るのですが、これでもハンドシェークの途中で止まっていることはわかるものの、それ以上はなんともわかりません。
    これ以上は間にLANアナライザを入れてみてパケット解析しつつ、RFCを読んで何かおかしいのか調べるしかなさそうです。

    以下は、現時点でのサンプルプログラムを改造したものです。

    WebSocketClient.cppをみると、サーバ側からのヘッダの解釈の実装がまだまだであることがわかります。ひとつの可能性として、どうやらここで止まっていそうです。もうひとつは、パケットの受信バッファの処理がどうも変な感じがします。

    いずれにせよ、このライブラリはまだそのままでは使えるものではなさそうな感じです。(ま、よくみると色々と制約があるよ、って書いてあるんですけどね)


  • WebSocketについてちょっと実験してみた

    投稿日 2015年 7月 28日 コメントはありません

    たまたまWebをさまよっていたら、WebSocketの話が目についたので調べてみた。まあ、HTTPに比べると、一旦リンクを張ってしまえばサーバ側からも通信ができるってのが美味しいところ。

    で、ブラウザがWebSocketをサポートしているか確認することができるサイトが

    http://www.websocket.org/echo.html

    なのですが、ここには自分でHTMLを書いて確認したい場合のためのコードが置いてあったりします。で、これを試してみると・・・テキストエディタに貼り付けたら1行になってしまいました(T_T)

    整形しなおしたものをここに置いておきます。

    これをコピペしたら今度は1行になるようなことはなかったです。

    そして、これをローカルで表示させたらこうなりました。

    で、ごにょごにょっとしたことを考えているので、自分の理解の範囲で動作を解釈してみます。(間違ってたら指摘いただけると幸いです)

    1. 動作は8行目から始まって、testWebSocket()が呼ばれる。
    2. 13行目のnewでwebsocketのインスタンスを生成。ここでソケットをオープンする。
    3. 14〜17行目はイベントハンドラ。ソケットをオープンすると、この中の14行目のonopenに設定したハンドラが呼ばれる。(先の13行目から呼ばれるところが変な感じがしますが、Javascriptのスコープの特性から14行目で定義している内容を13行目で使用可能なのですね)
    4. 20行目がonopenのイベントハンドラ。この中で、doSend()を呼んでその先でwebsocket.send()でデータを送信している。
    5. websocket.send()の結果、サーバ側からエコーバックが帰ってくる。
    6. エコーバックを受信すると、16行目で定義しているonmessageのハンドラが呼ばれるので、29行目のonMessage()が実行される。この中で、websocket.close()を呼んでコネクションをクローズ。
    7. クローズすると、15行目で定義しているoncloseに対応したハンドラが呼ばれる。

    比較的簡単に使えそうですね。
    ちょっとだけソケットの使い回しができることを確認してみました。

    ソースコードをちょっとだけ弄ります。

    変数nに初期値10を設定して、受信時の動作をnの値によって切り替えています。nが0より大きい場合には次のメッセージを送ってnをカウントダウン、nがゼロならソケットをクローズします。
    結果は、

    Screenshot_soc

    となりました。同じソケットを開いたまま11回のメッセージやりとりができていることがわかります。

    参考にさせていただいた/参考になりそうなサイト