投稿

7月, 2016の投稿を表示しています

ドトールの神対応! バリューカードのチャージが 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 や M…

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

rsync は SSH 越しでも行えるので、QNAP の SSH サーバーをセットアップすれば、「VPN を経由した NFS による rsync」(👉 その 2)という少々器用な真似をせずに済むようになる。※ただし、QNAP の SSH は admin しかログインできない点には留意する。以下の作業ではすべて、admin で SSH 接続するためのものである。QNAP の SSH 環境を整備する自機側で RSA キーペアを作成する。ssh-keygen -t rsa -C "作成するキーペアに関するコメント情報"作成したキーペアのうち、公開鍵(id_rsa.pub)の方を QNAP (NAS) へ scp コマンドで転送する。当然、この際は、QNAP 側の SSH サービスはオンにしておく必要があり、admin アカウントとパスワード認証で scp の処理を実行することになる。
scp ~/.ssh/id_rsa.pub admin@(NAS IP Address):~ (admin にとっての ~ へコピー)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 側の準備は終わり。SSH から一旦ログアウトし、再び SSH で QNAP にログインすると、(自機側によって)パスフレーズを尋ねられる。問題なければ、ログインに成功する。これでパスワード認証ではなく、公開鍵認証によるログインができるようになった。※自機にある作成したキーペアはちゃんと管理しておくこと(セキュリティ面と、バックアップ面の両面において)一応、SSH を利用するための作業としては以上である。SSH というのは、公開鍵をサーバー側にアップロードしておいて(公開鍵をアップロードできるのは、本人であるという前提による)、その公開鍵(サーバー側)と暗号鍵(本人側)をペアで使って、本人認証を行うというのが基本コンセプト。ただし実用上の問題として、QNAP ではパスワード認証によるログインの方も依然とし…

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/backupLinux(UNIX 系 OS)の非常に優れた文化が、このように、ネットワークドライブであろうが、さらには、入出力デバイスであろうが、すべて「ファイル」としてアクセスできるように、スッキリと極めてスマートに整えられている所である。それはいいとして、この場合、rsync 側では、ネットワークのことは意識する必要はなくなるものの、NFS を使ってマウントする際には、ネットワークアドレスを指定する必要があるので、実質的には違いはない。誰が請け負うかが変わっただけである。1: QNAP 側 で NFS を設定するQNAP 側では、「権限 > 共有フォルダ > NFS ホストのアクセス」で homes を「アクセス権:制限なし」にする。 2: Ubuntu 側で NFS を設定するまず、NFS をインストールする: apt-get install nfs-commonNAS の共有フォルダを、Ubuntu 側に NFS としてマウント:マウント用ディレクトリを用意:mkdir /mnt/qnapマウントする: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イン…

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

実家に設置している QNAP 製の NAS に、自機(Ubuntu)からデータを rsync でバックアップする体制を確立する。rsync は、最初に一度バックアップしてしまえば、以降は差分(変更したもの)だけを修正する形になるので、毎回全体を丸ごとバックアップするような重い作業とはならず、極めてスマート。rsync コマンドの使い方rsync コマンドは、man rsync すれば詳細は調べられるとして、自分にとって必要な形は次の通り: rsync -auv --delete --progress src_folderdest_path-a はアーカイブ用オプションで、ファイルの権限情報の保持などのいくつかのオプションのセット指定。-u は、タイムスタンプが新しくなる場合にのみ更新する。-v --progress は詳細な情報を作業の進行とともに表示。--delete は、削除したファイルも同期して削除する。src_folderdest_path は他の多くの人が指摘するように、ひとつのハマりポイントなので注意すること。通常、バックアップする場合は、あるフォルダーを丸ごと NAS にコピーする意識で行う。こういった場合、src_path の指定はフォルダー名で終わり、/ を付けない形で記述する。/ を最後に記述してしまうと、そのディレクトリの中の各ファイルを意味してしまい、バックアップ先に、そのディレクトリ直下の各ファイルが直接ぶち撒けられる形となるので、要注意。一方、src_path の指定をフォルダー(src_folder)にした場合、dest_path は、そのフォルダーが置かれるべきパスにするべきである。つまり、バックアップ元の最後尾にあるフォルダー名は抜いた、そのフォルダーが配置されるべきディレクトリ名を指定する必要がある。初回のバックアップでは失敗しても気付かないかもしれないが、もし失敗した場合、同じフォルダー名のディレクトリが二重で置かれることになる。次回のバックアップでも同じ指定をするのなら、それでもいいのだが、もし一貫性がないと、前回のバックアップと別物として扱われ、差分ではなく、また新たに丸ごとがバックアップされてしまうようなことにもなりかねない。例えば、自機の ~/mydata を、NAS 上の、/share/homes/scared…