2016年7月31日日曜日

ドトールの神対応! バリューカードのチャージが JCB 対応に!!!

2016-05-03 の記事「楽天カード(JCB)でドトールバリューカードへクレジットチャージする方法」では、JCB から直接チャージできないドトールのバリューカードへ、楽天のバーチャルマスターカードを経由してチャージする方法を紹介しました。

今、偶然、気付いたのですが、JCB でチャージ可能になっているじゃないですか! それも、7/29 に始まったばかり。

実は、7 月 25 〜 31 日の期間限定で、LINE Pay カードのポイントが通常の 2 倍の 4.0% になっているところだったので、早速、上限の 3 万円ギリギリまでチャージしてしまいました。偶然良いタイミングで気付いたものです。

LINE Pay の件は脇に置くとして、ドトールの神対応ぶりに感心しました。

実は、5 月の時点で、上記のようなバーチャルマスターカードによる迂回策を編み出す前に、ドトールに JCB が使えるようにして欲しいとの要望を出していたのです。オンラインフォームから送信したので、こちらの文章は残っていませんが、ドトールからの回答はちゃんとメールでいただきました:


Sent: Wednesday, April 27, 2016 at 5:04 PM
From: support-dcs@doutor.co.jp
To: xxxx@xxxxx.xxx
Subject: バリューカードの件・お詫び申し上げます

拝啓
時下ますますご清祥のこととお慶び申し上げます。
平素は、弊社チェーン・ドトールコーヒーショップをご利用いただきまして、誠
にありがとうございます。またこのたびは、ドトールバリューカードに関しまし
て、貴重なご意見を賜りましたこと、重ねて御礼申し上げます。
しかしながら、マイドトールにてクレジットチャージを行う際“JCB”カードの
ご利用が叶いませんことから、ご不便をお掛けしておりますこと、お詫び申し上
げます。
現状、同カードの導入の予定はございませんが、弊社関係部署に申し伝え、今後
の検討課題とさせていただきます。
このたびは、貴重なご意見を賜りまして、誠にありがとうございました。
敬具

株式会社ドトールコーヒー
お客様相談室 

僕自身がどういう言い方で要望を伝えたのか残っていないのが残念ですが、確か、「ドトールの客層だと、普通に JCB をメインにしている人が VISA や mastercard のユーザー並にいると思うので、その人たちにとっては不便だと思う。今後の導入の予定はないか?」というようなものだったと思います。4 月末にこういったやりとりがあって、上の返事をいただいた時は、まあ、社交辞令的な想定内の返事として受け止めていましたが、時期的に、ちょうど 3 ヶ月後に導入されたというのは、上のやりとりで本気で関係部署に渡って検討してもらった可能性が高いように思われます。ドトール、凄過ぎる!

おそらく、ドトールとしては、バリューカードの業務をセディナに委託してやってもらっているので、「JCB 八分」にしている事態を把握していなかったのだと思います。セディナは三井住友VISAの下部組織のようなカード会社で、この三井住友系カードグループは日本全国で「JCB 八分」を主導しているわけです。ドトールから要請がない限り、「VISA/mastercard 対応で、クレジット対応してますよ」と知らんぷりを決め込んでいたのだろうと思います。しかし、マイナーな利益効率優先の安物ブランドなら別としても、ドトールみたいなメジャーで客層も広そうなブランドで、JCB だけ対応していないというのは、やっぱり不釣り合いなわけです。ですから、実際に要望が伝わると、ちゃんとその辺りのサービスのバランス面を重視してくれて、JCB 対応を決定してもらったのだと思います。

いやーともかくドトール、神対応ですよ!

2016年7月17日日曜日

Ubuntu (Linux) と QNAP (NAS) 間で rsync - その 3 / 3

rsync は SSH 越しでも行えるので、QNAP の SSH サーバーをセットアップすれば、「VPN を経由した NFS による rsync」(その 2)という少々器用な真似をせずに済むようになる。

※ただし、QNAP の SSH は admin しかログインできない点には留意する。以下の作業ではすべて、admin で SSH 接続するためのものである。

QNAP の SSH 環境を整備する

  1. 自機側で RSA キーペアを作成する。ssh-keygen -t rsa -C "作成するキーペアに関するコメント情報"
  2. 作成したキーペアのうち、公開鍵(id_rsa.pub)の方を QNAP (NAS) へ scp コマンドで転送する。当然、この際は、QNAP 側の SSH サービスはオンにしておく必要があり、admin アカウントとパスワード認証で scp の処理を実行することになる。
    scp ~/.ssh/id_rsa.pub admin@(NAS IP Address):~ (admin にとっての ~ へコピー)
  3. SSH で QNAP に admin でログインし、~/id_rsa.pub を ~/.ssh/authorized_keys へ(追記)コピーする
    cat id_rsa.pub >> .ssh/authorized_keys
    chmod 600 .ssh/authorized_keys
    rm id_rsa.pub
    以上で、QNAP 側の準備は終わり。
  4. SSH から一旦ログアウトし、再び SSH で QNAP にログインすると、(自機側によって)パスフレーズを尋ねられる。問題なければ、ログインに成功する。これでパスワード認証ではなく、公開鍵認証によるログインができるようになった。
  5. ※自機にある作成したキーペアはちゃんと管理しておくこと(セキュリティ面と、バックアップ面の両面において)

一応、SSH を利用するための作業としては以上である。SSH というのは、公開鍵をサーバー側にアップロードしておいて(公開鍵をアップロードできるのは、本人であるという前提による)、その公開鍵(サーバー側)と暗号鍵(本人側)をペアで使って、本人認証を行うというのが基本コンセプト。

ただし実用上の問題として、QNAP ではパスワード認証によるログインの方も依然として可能な状態のままなので、セキュリティ的に好ましい状態ではない。

QNAP の SSH でパスワード認証を潰しておく

これをやろうとすると、実は結構、複雑。ネットでもいくつか情報が見つかるが、少し古かったりするせいか、そのままでは動かなかったり、また他の情報をツギハギしたような情報だったりで、イマイチ洗練されていなかったりしたので、それなりに納得行く方法に辿り着くために、工夫を要した。

1. qpkg.conf の編集

/etc/config/qpkg.conf に自動起動アプリのエントリーを追記する:1) 自機にダウンロード(scp)して、2) 編集し、3) QNAP の /etc/config にコピー(scp)して戻す。

[autorun]
Name = autorun
Version = 1.0
Author = scaredeer
Date = 2016-07-15
Shell = /share/homes/admin/autorun.sh
Install_Path = /share/homes/admin
QPKG_File = autorun.qpkg
Enable = TRUE

※起動スクリプトは、wiki の説明にあるような複雑怪奇な path に置く必要はなく、admin の home フォルダに置けばよい。この方が普通に FTP などで更新できるので、全然スマート。

2017-08-30 追記:最近、QTS をアップデートしたところ、autorun が無効になり、SSH のパスワード認証が自動で無効化されなくなった。すぐに解決方法がわからなかったので、そのまま放置していたら、今日、SSH に対する brute force 攻撃が発生し、NAS から警告メールが 5 分毎に送信され続けた(ログイン異常は 5 分間 ban する設定)。とりあえず、攻撃元の IP を永久 ban して対応したものの、やはり SSH のパスワード認証が有効なのが気になり、今日、改めて調べたら、「QNAP QTS4.3.3で自作QPKGがブロックされたので対処」という完全に一致するケースのナイスな記事を見付け出すことができ、上の qpkg.conf の QPKG_File = autorun.qpkg のエントリーを追加することで、解決した。

2. autorun.sh

下のような autorun.sh を自機で作成し、/share/homes/admin に置き(FTP、scp を使うなどする)、パーミッションを適切に設定(chmod +x)する。

#!/bin/sh

echo "Shutting down SSHd services:" 
/sbin/daemon_mgr sshd stop /usr/sbin/sshd
/usr/bin/killall sshd
rm -f /var/lock/subsys/sshd
echo "SSHd"
/bin/sed -i -e 's/#PasswordAuthentication yes/PasswordAuthentication no/g' /etc/ssh/sshd_config
echo "Disabled SSHd Password Authentication in config file: /etc/ssh/sshd_config"
echo "Restarting SSHd services:" 
/sbin/daemon_mgr sshd start '/usr/sbin/sshd -f /etc/ssh/sshd_config -p $(/sbin/getcfg LOGIN "SSH Port" -d 22)'
echo "SSHd"

(Ref. How do I disable password access for the default SSHd?)

※1 この起動スクリプトは、sed コマンドの実行を前提とする。Entware-ng をインストールするなどして、sed が使える状態を整えておく必要がある。

※2 この起動スクリプトでは、ssh の常駐アプリを一旦停止してから、sshd_config の該当する 1 行(PasswordAuthentication)を yes から no に変更している。これもやはり、情報元では一部が間違っていてそのままでは動かなかったので、適切な形に修正してある。

4. 確認

NAS をリブートし、自機からパスワード認証ではログインできないことを確認する。

通常では、公開鍵認証で SSH が接続されてしまうので、公開鍵認証を禁止してパスワード認証で接続させるには、自機の SSH コマンド実行時に、以下のようなオプションで実行する:

$ ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no admin@XXX.XXX.XXX.XXX

※ポートをデフォルトの 22 から変更している場合は、ポート番号も指定する必要があることに留意する。

パスワード認証によるログインが拒絶されると、次のようなメッセージとなる。

Permission denied (publickey,keyboard-interactive).

SSH のポートの変更

以上までの作業が成功したら、最後にセキュリティのため、SSH のポートをデフォルトの 22 から変更する(QNAP の Web UI から設定する。上の autorun.sh の中での SSH Port の値は 22 のままでも、Web UI から設定したポート番号で問題なく稼動するようだ)。例えば 50022 であれば、ssh では -p 50022 という風にオプションを追加すればいいし、rsync においても -e 'ssh -p 50022' という風にすれば、ポートを指定できる。

$ ssh admin@XXX.XXX.XXX.XXX -p 50022

注意

最初に注記したように、以上はすべて admin アカウントで QNAP にログインすることが前提となっている。アカウントを admin 以外で行う方法は、ない(sshd_config をいじっても無理;任意のユーザーアカウントを使って SSH でログインできるようにするには、QNAP デフォルトの SSH ではなく、OpenSSH を別途インストールして使うしか方法はない)。この点はセキュリティ面での潜在的リスクであることは、よく認識しておく必要がある。QNAP のセキュリティ設定のネットワークアクセス保護機能を使うなどして、潜在的リスクに対して備えておくこと。


そして rsync

以上で、rsync から直接、SSH 経由で同期できる。NFS はもはや必要ないし、SSH をポートマップして公開すれば、VPN を経由する必要もない(さらに myQNAPcloud の機能を使えば、XXX.XXX.XXX.XXX の部分を ???.myqnapcloud.com にできる。)。

rsync -e 'ssh -p 50022' -auv --delete --progress src_folder admin@remote_address:dest_path

Ubuntu (Linux) と QNAP (NAS) 間で rsync - その 2 / 3

その 1 では主に rsync コマンドの記述について説明したので、ネットワーク経由で NAS の指定した path にバックアップする方法の詳細については述べなかった。今回からは、その部分について、僕が試行した方法について説明する。

NAS の特定のフォルダを、NFS を使って自機にマウントして、自機のフォルダとして利用する

まず最初に僕がやったのが、NFS を使って自機にマウントして、自機のフォルダと見做せるようにし、rsync では、ローカルのフォルダー間での同期として扱うやり方である。この場合、rsync の dest_path の指定において、NAS のネットワークアドレスに関する(admin@XXX.XXX.XXX.XXX: の部分の)記述は不要となり、次のような形で済む:

rsync -auv --delete --progress ~/mydata /mnt/qnap/backup

Linux(UNIX 系 OS)の非常に優れた文化が、このように、ネットワークドライブであろうが、さらには、入出力デバイスであろうが、すべて「ファイル」としてアクセスできるように、スッキリと極めてスマートに整えられている所である。

それはいいとして、この場合、rsync 側では、ネットワークのことは意識する必要はなくなるものの、NFS を使ってマウントする際には、ネットワークアドレスを指定する必要があるので、実質的には違いはない。誰が請け負うかが変わっただけである。

1: QNAP 側 で NFS を設定する

QNAP 側では、「権限 > 共有フォルダ > NFS ホストのアクセス」で homes を「アクセス権:制限なし」にする。

2: Ubuntu 側で NFS を設定する

まず、NFS をインストールする:

apt-get install nfs-common

NAS の共有フォルダを、Ubuntu 側に NFS としてマウント:

  1. マウント用ディレクトリを用意:mkdir /mnt/qnap
  2. マウントする:mount -t nfs XXX.XXX.XXX.XXX:/homes/username /mnt/qnap

(参考:How To Set Up an NFS Mount on Ubuntu 14.04

アンマウントは:umount -f -l /mnt/qnap

インターネット越しの場合はあまり適していないかもしれない

以上で、ローカルのフォルダー間での同期としての rsync が可能となる。

しかし、上の場合は、LAN で NFS をマウントする場合ならいいのだが、実家の NAS と繋げて使う場合など、インターネット越しで行う場合には、さらにハードルが上がる。

僕の場合、1) 実家の NAS と繋げるため VPN (PPTP) 環境を整え、2) VPN によって LAN として NAS と繋がる状態にしてから NFS をマウントし、3) その上で rsync するという、何ともまあ器用な真似を当初は行っていた。この目的だけのために、一々 VPN でつなげて使うというのもあまり手軽ではない気がしたので、この方法はやめて、rsync で直接インターネット越しに接続・同期作業を行うやり方に、切り替えることにした。それについては、また次回(その 3)で説明することにする。ただし、結局このやり方をやめたと言っても、LAN で NAS と接続できるのであれば、NFS を使ったやり方は、普通にスマートだろうと思う。

Ubuntu (Linux) と QNAP (NAS) 間で rsync - その 1 / 3

実家に設置している QNAP 製の NAS に、自機(Ubuntu)からデータを rsync でバックアップする体制を確立する。

rsync は、最初に一度バックアップしてしまえば、以降は差分(変更したもの)だけを修正する形になるので、毎回全体を丸ごとバックアップするような重い作業とはならず、極めてスマート。

rsync コマンドの使い方

rsync コマンドは、man rsync すれば詳細は調べられるとして、自分にとって必要な形は次の通り:

rsync -auv --delete --progress src_folder dest_path

-a はアーカイブ用オプションで、ファイルの権限情報の保持などのいくつかのオプションのセット指定。-u は、タイムスタンプが新しくなる場合にのみ更新する。-v --progress は詳細な情報を作業の進行とともに表示。--delete は、削除したファイルも同期して削除する。

src_folderdest_path は他の多くの人が指摘するように、ひとつのハマりポイントなので注意すること。通常、バックアップする場合は、あるフォルダーを丸ごと NAS にコピーする意識で行う。こういった場合、src_path の指定はフォルダー名で終わり、/ を付けない形で記述する。/ を最後に記述してしまうと、そのディレクトリの中の各ファイルを意味してしまい、バックアップ先に、そのディレクトリ直下の各ファイルが直接ぶち撒けられる形となるので、要注意。

一方、src_path の指定をフォルダー(src_folder)にした場合、dest_path は、そのフォルダーが置かれるべきパスにするべきである。つまり、バックアップ元の最後尾にあるフォルダー名は抜いた、そのフォルダーが配置されるべきディレクトリ名を指定する必要がある。初回のバックアップでは失敗しても気付かないかもしれないが、もし失敗した場合、同じフォルダー名のディレクトリが二重で置かれることになる。次回のバックアップでも同じ指定をするのなら、それでもいいのだが、もし一貫性がないと、前回のバックアップと別物として扱われ、差分ではなく、また新たに丸ごとがバックアップされてしまうようなことにもなりかねない。

例えば、自機の ~/mydata を、NAS 上の、/share/homes/scaredeer/backup/mydata としてバックアップする体制にしたい場合:

rsync -auv --delete --progress ~/mydata admin@XXX.XXX.XXX.XXX:/share/homes/scaredeer/backup

という形になる。admin@XXX.XXX.XXX.XXX: の部分は、ネットワーク上の NAS を NAS のアカウント名と共に指定している部分で、これについては後述する(その 2)。ここでのポイントは、dest_path の指定が、/share/homes/scaredeer/backup であって、mydata を除いている点である。

また、試行で rsync を実行したい場合、-n オプションを使う。実際にはコピー・置換・削除等がされず、予行で -v --progress による動作の様子を確かめることができる。

QNAP の設定

上の rsync コマンドでは --delete を指定したが、初期状態の QNAP では、マルチメディアファイルデータベースの機能により、/homes 以下に対して自動的にメディアファイル(画像や動画)のサムネイル(隠しファイル)が作成されてしまうため、バックアップする毎に、本来存在しなかった隠しファイルが追加されてしまう。そのため、--delete オプションによって毎度削除され、都度、QNAP 側では再スキャンしてサムネイルを作り直すという作業が発生してしまう。

これを避けるために、/homes に対するスキャンは無効化しておく。「アプリケーション > マルチメディア管理 > メディアフォルダ」で、/homes のエントリーは削除しておく。