Web技術 – ともの技術メモ

2019年5月11日2019年5月6日

ESP32でマイクロ波近接センサをロギング

ESP32はしばらく放置している間にすごく使いやすくなっていたので、調子に乗って、以前買ったESP32 DevKitCにOLEDモジュールをつけて、ドップラーセンサーモジュールで壁越しに動体検知するのにチャレンジしてみました。

開発はArduino環境で行いました。無線LANの初期化やNTPでの時刻同期、OLEDの表示に関する部分、Webサーバーに関する部分はT-Cameraのソースをベースに不要な部分を削除して用意しました。

今回使用したセンサはUARTで通信します。ESP32にはUARTが３つあり、１つはPC（Arduino IDE）との通信用となっていますので、残り２つが利用可能です。今回はUART1の送信を１６ピン、受信を１７ピンに割り当てて使用しました。

#define UART1_TX 16
#define UART1_RX 17

Serial1.begin(9600, SERIAL_8O1, UART1_RX, UART1_TX

#define UART1_TX 16

#define UART1_RX 17

Serial1.begin(9600, SERIAL_8O1, UART1_RX, UART1_TX

で初期化しました。

受け取ったセンサ情報は接近時、離別時、停止時の３つのパターンがありますが、それぞれ毎分０秒を境界とした１分毎、毎時０分を境界とした１時間毎に発生数を計数して Chart.js を用いてグラフ化してみました。

2019年3月25日

Google Cloud Print Connectorを設定

これまでAndoidから印刷するのに、わざわざGoogle DriveかGmail経由でLinux Mint側にファイルを持ってきて、それから印刷していたのですが、これが面倒なので、Google Cloud Printが使えるように設定してみます。
プリンタはBrother HL-2240DでLinuxMint19のPCにUSBで接続しています。

１．インストールと設定ファイル生成

まずはSynapticパッケージマネージャで「google-cloud-print-connector」をインストールして、引き続き設定ファイルを生成します。

~$ gcp-connector-util init
"Local printing" means that clients print directly to the connector via
local subnet, and that an Internet connection is neither necessary nor used.
Enable local printing?
Yes

~$ gcp-connector-util init

"Local printing" means that clients print directly to the connector via

local subnet, and that an Internet connection is neither necessary nor used.

Enable local printing?

Yes

ローカル印刷は引き続き使うので「Yes」を入力

"Cloud printing" means that clients can print from anywhere on the Internet,
and that printers must be explicitly shared with users.
Enable cloud printing?
Yes

"Cloud printing" means that clients can print from anywhere on the Internet,

and that printers must be explicitly shared with users.

Enable cloud printing?

Yes

クラウドプリントを使うので「Yes」を入力

Visit https://www.google.com/device, and enter this code. I'll wait for you.
XXXX-XXXX
Acquired OAuth credentials for robot account

Visit https://www.google.com/device, and enter this code. I'll wait for you.

XXXX-XXXX

Acquired OAuth credentials for robot account

ここでGoogle Chromeを起動して、https://www.google.com/device にアクセスするとGoogleアカウントの認証を求められるので認証ログイン。さらに、コードの入力に移るので、上記のコード（XXXX-XXXX）を入力。入力すると、コンソール画面が進んで、使わせたいユーザーの

Enter the email address of a user or group with whom all printers will automatically be shared or leave blank to disable automatic sharing:

1	Enter the email address of a user or group with whom all printers will automatically be shared or leave blank to disable automatic sharing:

Google Cloud Printを使いたいユーザーのメールアドレスをカンマ区切りで入力

xxxxxxx@gmail.com,yyyyyyy@gmail.com,zzzzzzz@gmail.com

1	xxxxxxx@gmail.com,yyyyyyy@gmail.com,zzzzzzz@gmail.com

入力すると設定ファイルが生成されたことが表示されます。

The config file /home/xxxxxxx/gcp-cups-connector.config.json is ready to rock.
Keep it somewhere safe, as it contains an OAuth refresh token.
t~$

The config file /home/xxxxxxx/gcp-cups-connector.config.json is ready to rock.

Keep it somewhere safe, as it contains an OAuth refresh token.

t~$

２．動作テスト

試しに動かしてみます。

~$ gcp-cups-connector -config-filename gcp-cups-connector.config.json 
Google Cloud Print Connector for CUPS version DEV-linux
Ready to rock as proxy 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx' and in local mode

~$ gcp-cups-connector -config-filename gcp-cups-connector.config.json

Google Cloud Print Connector for CUPS version DEV-linux

Ready to rock as proxy 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx' and in local mode

Android側では「クラウドプリント」をインストールします。

インストールされた状態でアプリケーションのメニューで「印刷」を選択して、「プリンタの選択」でLinux側でCUPSで管理されているプリンタを選択して、プリンタのアイコンをタップすると印刷できました。

３．自動起動の設定

cloud-print-connector というユーザー／グループを作成します。ホームディレクトリは不要、ログインしないのでログインシェルも不要です。

~$ sudo useradd -M -s /usr/sbin/nologin cloud-print-connector

1	~$ sudo useradd -M -s /usr/sbin/nologin cloud-print-connector

実行ファイルへのシンボリックリンクを作成します。

~$ sudo mkdir /opt/cloud-print-connector
~$ sudo ln -s /usr/bin/gcp-cups-connector /opt/cloud-print-connector/gcp-cups-connector

1 2	~$ sudo mkdir /opt/cloud-print-connector ~$ sudo ln -s /usr/bin/gcp-cups-connector /opt/cloud-print-connector/gcp-cups-connector

設定ファイルを /opt/cloud-print-connector にコピーして適切な権限を付けます。

~$ sudo cp gcp-cups-connector.config.json /opt/cloud-print-connector/.
~$ sudo chown cloud-print-connector.cloud-print-connector /opt/cloud-print-connector/gcp-cups-connector.config.json 
~$ ls -la /opt/cloud-print-connector/gcp-cups-connector.config.json 
-rw------- 1 cloud-print-connector cloud-print-connector 571 3月 24 23:10 /opt/cloud-print-connector/gcp-cups-connector.config.json
~$

~$ sudo cp gcp-cups-connector.config.json /opt/cloud-print-connector/.

~$ sudo chown cloud-print-connector.cloud-print-connector /opt/cloud-print-connector/gcp-cups-connector.config.json

~$ ls -la /opt/cloud-print-connector/gcp-cups-connector.config.json

-rw------- 1 cloud-print-connector cloud-print-connector 571 3月 24 23:10 /opt/cloud-print-connector/gcp-cups-connector.config.json

systemd のサービスファイルをダウンロードしてインストールします。

~$ wget https://raw.githubusercontent.com/google/cloud-print-connector/master/systemd/cloud-print-connector.service
~$ sudo install -o root -m 0664 cloud-print-connector.service /etc/systemd/system

1 2	~$ wget https://raw.githubusercontent.com/google/cloud-print-connector/master/systemd/cloud-print-connector.service ~$ sudo install -o root -m 0664 cloud-print-connector.service /etc/systemd/system

Google Cloud Print CUPS Connector serviceを許可してスタートします。

~$ sudo systemctl enable cloud-print-connector.service
Created symlink /etc/systemd/system/multi-user.target.wants/cloud-print-connector.service → /etc/systemd/system/cloud-print-connector.service.
~$ sudo systemctl start cloud-print-connector.service
~$ sudo systemctl status cloud-print-connector.service
● cloud-print-connector.service - Google Cloud Print Connector
   Loaded: loaded (/etc/systemd/system/cloud-print-connector.service; enabled; v
   Active: active (running) since Sun 2019-03-24 23:16:23 JST; 7s ago
     Docs: https://github.com/google/cloud-print-connector
 Main PID: 5221 (gcp-cups-connec)
    Tasks: 10 (limit: 4915)
   CGroup: /system.slice/cloud-print-connector.service
           └─5221 /opt/cloud-print-connector/gcp-cups-connector -config-filename

 3月 24 23:16:23 J3160 systemd[1]: Started Google Cloud Print Connector.
 3月 24 23:16:23 J3160 gcp-cups-connector[5221]: Google Cloud Print Connector fo
 3月 24 23:16:26 J3160 gcp-cups-connector[5221]: Ready to rock as proxy 'xxxxxxx
~$

~$ sudo systemctl enable cloud-print-connector.service

Created symlink /etc/systemd/system/multi-user.target.wants/cloud-print-connector.service → /etc/systemd/system/cloud-print-connector.service.

~$ sudo systemctl start cloud-print-connector.service

~$ sudo systemctl status cloud-print-connector.service

● cloud-print-connector.service - Google Cloud Print Connector

Loaded: loaded (/etc/systemd/system/cloud-print-connector.service; enabled; v

Active: active (running) since Sun 2019-03-24 23:16:23 JST; 7s ago

Docs: https://github.com/google/cloud-print-connector

Main PID: 5221 (gcp-cups-connec)

Tasks: 10 (limit: 4915)

CGroup: /system.slice/cloud-print-connector.service

└─5221 /opt/cloud-print-connector/gcp-cups-connector -config-filename

3月 24 23:16:23 J3160 systemd[1]: Started Google Cloud Print Connector.

3月 24 23:16:23 J3160 gcp-cups-connector[5221]: Google Cloud Print Connector fo

3月 24 23:16:26 J3160 gcp-cups-connector[5221]: Ready to rock as proxy 'xxxxxxx

停止する場合は、

~$ sudo systemctl stop cloud-print-connector.service

1	~$ sudo systemctl stop cloud-print-connector.service

とします。

2019年3月6日2019年3月6日

静的サイトジェネレータHugoを試してみた

このサイトは編集をいつでもどこでも簡単にできるようにWordPressで作成していますが、内容を固定したサイトの場合には、WordPressで作成すると定期的にアップデートが必要となるので結構管理が面倒です。（それでも、WordPressはセキュリティアップデートは勝手にやってくれるので、だいぶ楽ですが）

また、プラグインやテーマもちょっとマイナーなものを入れると、本体のアップデートについていけず、結構悩むことになります。

で、最近知ったのが静的サイトジェネレータというもので、マークダウン言語で書いた記事をHTMLとCSSに変換してくれるものだそうです。HTMLとCSSだけでデータベースなどはないのでセキュリティ上の心配も少なくて済むようです。で、変換したHTMLとCSSをまるごとサーバ上にアップロードすればOK（実際には同期するのかもしれませんが）ということらしいです。

今回はその静的サイトジェネレータの中からHugoというのを試してみることにしました。

１．Hugoの環境構築

今回は諸般の事情から、素のUbuntu18.04LTS環境に導入してみます。Hugoで検索すると、WindowsかMacOSのものが大部分で、Linux環境の場合にはどういうわけか（探し方が悪いのか）古いものしか見つかりません。どうせなら最新版をインストールしたいところです。そこで参考にしたのは一つ目はこちらの記事です。何はともあれ、参考にしながら最新版をgithubからダウンロードしてインストールしてみます。

下記手順で素のUbuntu18.04LTSに対してアップデートとVirtualBoxのGuest Addtionsのインストールを行った後、Hugoのバイナリパッケージをインストールします。
※今後の再テストを短時間で行うため、VirtualBoxのディスクイメージのスナップショットも採取しています。

$ sudo apt update
$ sudo apt upgrade
（一旦再起動）
$ sudo apt install build-essential perl make gcc git
（VirtualBoxのGuest Additionsをインストールして一旦シャットダウン、スナップショットを取って再起動）
$ wget https://github.com/gohugoio/hugo/releases/download/v0.54.0/hugo_0.54.0_Linux-64bit.deb
$ sudo apt install ./hugo_0.54.0_Linux-64bit.deb
$ hugo version

$ sudo apt update

$ sudo apt upgrade

（一旦再起動）

$ sudo apt install build-essential perl make gcc git

（VirtualBoxのGuest Additionsをインストールして一旦シャットダウン、スナップショットを取って再起動）

$ wget https://github.com/gohugoio/hugo/releases/download/v0.54.0/hugo_0.54.0_Linux-64bit.deb

$ sudo apt install ./hugo_0.54.0_Linux-64bit.deb

$ hugo version

２．新しいサイトの作成

$ mkdir WebSite
$ cd WebSite
$ hugo new site hugo.example.com

$ mkdir WebSite

$ cd WebSite

$ hugo new site hugo.example.com

３．新しいページの作成

以下の方法で新しいページを作成します。

$ hugo new <SECTIONNAME>/<FILENAME>.<FORMAT>

1	$ hugo new <SECTIONNAME>/<FILENAME>.<FORMAT>

実際にやってみます。

$ cd hugo.example.com
$ ls
$ hugo new post/test-page.md

$ cd hugo.example.com

$ ls

$ hugo new post/test-page.md

として、contentディレクトリの下のpostディレクトリの下に記事を生成します。生成したら、自動生成されたファイルcontent/post/test-page.md を編集します。冒頭の draft: の行は削除します。（この行があると、記事が生成されません）

---
title: "Test Page"
date: 2019-03-05T01:02:03Z
---

# Hello World

This is my first hugo site, wooo!!

```
hugo_install="success"
if [[ $hugo_install == "success" ]]; then
  echo "Happy me"
```

bye!

---

title: "Test Page"

date: 2019-03-05T01:02:03Z

---

# Hello World

This is my first hugo site, wooo!!

```

hugo_install="success"

if [[ $hugo_install == "success" ]]; then

echo "Happy me"

```

bye!

４．テーマをダウンロード

テーマをダウンロードします。ここでは試しに mainroad というのを使ってみます。

$ cd theme
$ git clone https://github.com/vimux/mainroad
$ cd ..

$ cd theme

$ git clone https://github.com/vimux/mainroad

$ cd ..

mainroadというテーマを使うために、config.toml に

theme = "mainroad"

1	theme = "mainroad"

を書き足します。

５．サイトを生成してみる

$ hugo

$ hugo

で、publicというディレクトリが生成されて中にデータが生成されます。

$ hugo server

1	$ hugo server

で組み込みサーバーが起動するようです。http://localhost:1313/ でインデックスページにアクセスできますが、かなり質素です（mainroadというテーマはこんなに質素じゃないはずなので要調査）。Ctrl+C で停止できます。

このまま、

$ cd hugo.example.com
$ hugo new post/sample.md

1 2	$ cd hugo.example.com $ hugo new post/sample.md

として、もう１ページを作成、content/post/sample.md を編集します。冒頭の draft: の行は削除しつつ適当に内容を作成すると、自動的にブラウザで開いていた記事のリストが更新されます。

記事を一通り作成したら、publicディレクトリを丸ごとWebサーバにアップロードすることで、公開完了、ということみたいです。（実際には rsync などで同期を取る形で運用するのが楽なのだと思います）

６．参考になりそうなもの

まくまくHugo/Goノート(https://maku77.github.io/hugo/)
Hugoの使い方を解説されています。これから頑張って試してみようかと。
Hugo Themes（https://themes.gohugo.io/）
Hugoのテーマがたくさん並んでいます。

2019年1月20日2019年1月20日

WordPressのテーマ変更

これまで、このサイトのテーマは初めてWordPressを使った際に選んだテーマをPHPのバージョンアップに伴う不具合とかを手直ししつつ使ってきたのですが、さすがに今の世の中、スマホやタブレットでサイトを見る機会が増えてきていて、レスポンシブデザインへの対応をしたいなー、と思うようになりました。

しかし、元のデザインを自力でレスポンシブデザイン対応させるようなスキルもないので、ついにテーマ変更することにしました。で、新しいテーマはできるだけ長くサポートされるであろう、標準のテーマのうち、レスポンシブデザインに対応しているもの・・・ということで、TwentySeventeenにしました・・・が、TwentySeventeenはそのままだとアクセスするとどどーんと画像が表示されてしまうので、こちらのサイトを参考に控えめに表示されるようにしました。

変更箇所は、テーマの中のfunctions.phpの最後に、以下の記述を追加して UTF-8 で保存しました。もう少しデザインはカスタマイズすると思いますが、とりあえずレスポンシブデザインになったのでよしとします。

///////////////////////////////////////////////////////////////////////////// 2019.1.20
// トップページヘッダー画像を他ページと同じ扱いとする
add_filter( 'body_class', 'top_body_class');
function top_body_class( $classes ) {
    unset($classes[array_search("twentyseventeen-front-page",$classes)]);
    unset($classes[array_search("home",$classes)]);
    return $classes;
}

///////////////////////////////////////////////////////////////////////////// 2019.1.20

// トップページヘッダー画像を他ページと同じ扱いとする

add_filter( 'body_class', 'top_body_class');

function top_body_class( $classes ) {

unset($classes[array_search("twentyseventeen-front-page",$classes)]);

unset($classes[array_search("home",$classes)]);

return $classes;

}

・・・が、何も考えずにテーマ自体のfunctions.phpを編集してしまうと、テーマがバージョンアップしたときに元に戻ってしまうようです。なので、子テーマを作って、そちらの funcions.php を編集しました。

子テーマは、サーバ上のテーマディレクトリと同じ階層に子テーマのディレクトリ（twentyseventeen-child）を作って、そこに必要なファイルを置きます。

一つは、functions.php で、以下の内容です。実際には、上記の内容も後ろに書き足して、UTF-8で保存しました。

<?php
add_action( 'wp_enqueue_scripts', 'theme_enqueue_styles' );
function theme_enqueue_styles() {
    wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/style.css' );
}

<?php

add_action( 'wp_enqueue_scripts', 'theme_enqueue_styles' );

function theme_enqueue_styles() {

wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/style.css' );

}

もう一つは、style.css で、以下の内容です。

/*
Theme Name:twentyseventeen-child
Template:twentyseventeen
Version:2.0
*/

Theme Name:twentyseventeen-child

Template:twentyseventeen

Version:2.0

ここに、こちらのサイトの記事の内容そのまま（ありがとうございます！）ですが、

@media screen and (min-width: 48em) {
	.wrap {
		max-width: 1100px;/*記事・サイドバー・余白の全幅*/
		padding-left: 2em;/*記事の左余白*/
		padding-right: 2em;/*サイドバーの右余白*/
	}
	.has-sidebar:not(.error404) #primary {
		float: left;
		width: 67%;/*記事幅*/
	}
	.has-sidebar #secondary {
		float: right;
		padding-top: 0;
		width: 29%;/*サイドバー幅*/
	}
	.navigation-top .wrap {
		max-width: 1100px;/*メニューバー幅*/
		padding: 0.75em 3.4166666666667em;
	}
	.site-content {
		padding: 2.5em 0 0;/*メニューバーと記事の間隔*/
	}
}

@media screen and (min-width: 48em) {

.wrap {

max-width: 1100px;/*記事・サイドバー・余白の全幅*/

padding-left: 2em;/*記事の左余白*/

padding-right: 2em;/*サイドバーの右余白*/

}

.has-sidebar:not(.error404) #primary {

float: left;

width: 67%;/*記事幅*/

}

.has-sidebar #secondary {

float: right;

padding-top: 0;

width: 29%;/*サイドバー幅*/

}

.navigation-top .wrap {

max-width: 1100px;/*メニューバー幅*/

padding: 0.75em 3.4166666666667em;

}

.site-content {

padding: 2.5em 0 0;/*メニューバーと記事の間隔*/

}

を後ろに書き足して元のテーマでは狭くて読みにくい記事の幅を広げてみました。

さらに、記事の見出しと記事内の見出しがともにh3で同じサイズで表示されてして醜いところがありましたので、あちこち参考にさせてもらいながら、style.css に

.entry-title {
	padding: 0.25em 0em 0.1em 0.5em ;
	background: transparent;
	border-left: solid 5px #753;
	border-bottom: solid 2px #333;
	font-size: 1.6em;
}

.entry-title {

padding: 0.25em 0em 0.1em 0.5em ;

background: transparent;

border-left: solid 5px #753;

border-bottom: solid 2px #333;

font-size: 1.6em;

}

を追加して記事のタイトルに装飾をつけてみました。

今しばらくはデザインがいろいろ変わるかもしれませんが、ご容赦を（笑）

2018年7月5日

サイトのSSL対応化

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

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

１．SSL設定の有効化と確認

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

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

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

2018年7月3日2018年7月3日

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

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

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

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

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

$$foo['bar']['baz']

1	$$foo['bar']['baz']

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

${$foo['bar']['baz']}

1	${$foo['bar']['baz']}

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

 ($$foo)['bar']['baz']

1	($$foo)['bar']['baz']

と解釈されるようです。（参考：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」にチェックを入れると治ったので、逆に有効化してあります。

2018年7月1日2018年7月1日

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

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

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

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

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

１．Wordpressのデータバックアップ

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

# cd public_html
# tar cvfz ../tomono.wordpress.tar.gz wordpress .htaccess favicon.ico index.html index.php

1 2	# cd public_html # tar cvfz ../tomono.wordpress.tar.gz wordpress .htaccess favicon.ico index.html index.php

２．データベースのバックアップ

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

３．さくらのレンタルサーバ（スタンダード）の契約

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

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

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

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

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

６．さくら上でデータベースの復元

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

$ mysql -u データベースユーザ名 -pパスワード -h データベースサーバホスト名 データベース名 < バックアップしたファイル（xxxxx.sql）

1	$ mysql -u データベースユーザ名 -pパスワード -h データベースサーバホスト名データベース名 < バックアップしたファイル（xxxxx.sql）

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

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

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

８．PHPのバージョンを５系に下げた

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

９．バックアップ用のシェルスクリプトの作成

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

#!/bin/sh
cd ~/BACKUP
mysqldump --add-drop-table -u (ユーザー名) -p(パスワード) -h (データベースサーバ名) (データベース名) | gzip -c > database-backup-`date +%Y%m%d`.sql.gz
cd ~（WordPressディレクトリのあるディレクトリ）
tar cfz ~/BACKUP/directory-backup-`date +%Y%m%d`.tar.gz .htaccess * 
cd ~

#!/bin/sh

cd ~/BACKUP

mysqldump --add-drop-table -u (ユーザー名) -p(パスワード) -h (データベースサーバ名) (データベース名) | gzip -c > database-backup-`date +%Y%m%d`.sql.gz

cd ~（WordPressディレクトリのあるディレクトリ）

tar cfz ~/BACKUP/directory-backup-`date +%Y%m%d`.tar.gz .htaccess *

cd ~

１０．旧サーバーからのリダイレクトの設定

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

<.htaccessの内容>

Redirect permanent / http://tomono.tokyo/

1	Redirect permanent / http://tomono.tokyo/

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

tomono.eleho.net IN A （旧サーバIPアドレス）

1	tomono.eleho.net IN A （旧サーバIPアドレス）

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

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

2018年7月1日2019年1月14日

サイトを移転しました

２０１８年７月１日にサイトを移転しました。
旧URL： tomono.eleho.net　⇒　新URL: tomono.tokyo
URLリダイレクトを停止しました（２０１８年１２月２５日）

2018年5月13日2018年5月20日

MongoDBについて調べてみた

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

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

Ubuntu Linuxへのインストール方法（64bit環境オンリー）
Ubuntuで提供されているパッケージではなく、公式サイトのやり方でインストールすべき。
https://docs.mongodb.com/manual/tutorial/install-mongodb-on-ubuntu/
MongoDBの薄い本
MongoDBのチュートリアル
http://www.cuspy.org/diary/2012-04-17/
PythonからMongoDBを使ってみる
NoSQLデータベース「MongoDB」をPythonで利用する～pymongoの基本的な使い方まとめ～
https://qiita.com/ognek/items/a37dd1cd0e26e6adecaa
業務でよく使うMongoDBコマンドまとめ
https://qiita.com/masarufuruya/items/33fbe059229230c8fc0c
MongoDBでよく使うコマンドなど
https://qiita.com/team8ware/items/ea318a7efa2a271a9783
MapReduceとAggregation
MapReduceの使い方、いろんな方が書いてくれていますが、結局必ずここは見たほうがいいと思う
https://docs.mongodb.com/manual/aggregation/
The MongoDB 3.6 Manual
英語ですが、やはり最後はマニュアルですね・・・。
https://docs.mongodb.com/manual/

2017年2月27日

WordPressでログインできなくなった！

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

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

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

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

$ sudo yum -y install gd php-gd

1	$ sudo yum -y install gd php-gd

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

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

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

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

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

2019年5月
月	火	水	木	金	土	日
« 4月
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31