2019年9月6日金曜日

クレジットカードの再発行

先日、クレジットカードの再発行をしなければいけなくなりました。少しだけ困ったので、みなさんが同じような状況になったときの参考までに経緯をまとめます。

概要

  • いつも使っている、航空会社のマイレージサービスと結びついているクレジットカード (ブランドはmaster)のICの読み取りができなくなった。磁気ストライプは読みとれる
  • カード会社に再発行を依頼したのがある週の金曜日の午前9時、自宅に到着したのが翌週の金曜日の午前11時
  • 海外旅行への出発を控えていて、自宅を出るのが土曜日の午前7時過ぎ。郵便局のゆうゆう窓口が開くのが午前7時なので、金曜日のうちに受け取れないと厳しい状況だった

詳細

  • いつも使っているクレジットカードのIC部分の読み取りができなくなった。わかったのが再発行を依頼する週の火曜日。ただし、利用した店舗のカードリーダーの問題の可能性もあるため、ただちに行動は起こさなかった。というのも、以前に、この店舗で読み取れなかったことがあるため。
  • その後、水曜日と木曜日に、自宅近所の馴染みにしている店で事情を話して、決済時にいろいろと試してもらった。たとえば、何度も読ませてみたり、端末への挿入をゆっくりにしてもらったりなどをお願いした。そして、わかったことは、ICの読み取りができない、磁気ストライプでの決済なら可能ということだった。
  • 同じ銀行口座に結びついた家族カードが1枚、別に2枚のクレジットカードがあり、不調なものも磁気ストライプは読めるので渡航先での利用、少なくともホテルでの利用は問題がないようには思えた(渡航先はなぜか磁気ストライプでの読み取りが多い)。
  • しかし、以下の様な状況があり再発行を依頼することにした。
  • 最近は、IC読み取りが増えてきている
  • ホテルの予約が私の名前になっているのため、家族カードでの決済だと微妙なことになるかもしれない
  • 予備のクレジットカードのうち、1枚のブランドは渡航先で使えなことが多いことはわかっていた。
  • もう一枚の予備のカードは、ホテルポイントと結びついているものなのだが、今回の旅行ではできれば航空会社に結びついたものを使いたかった。
  • 金曜日の朝一番にカード会社に連絡をして事情を話し最短で発行してもらうことにした。すると、翌週の木曜日の夕方に速達簡易書留で発送するということだった。ただし、この時点では発送元は不明なので、輸送にどれくらいかかるかはわからない。
  • ふと思いついて、クレジットカードの裏側を確認すると「TOPPAN」とある。そうなるとたぶん製造工場は埼玉かと思われる。根拠は
    https://employment.en-japan.com/desc_116549/
    にある求人で
    勤務地・交通
    朝霞工場/東武東上線「志木駅」より路線バス5~10分
    というところから。あと、クレジットカードではないが特殊印刷の部門は八王子にあるようだ。
    https://www.ekiten.jp/shop_3717225/
  • 自宅は東京23区内であるため、速達での木曜日の夕方発送であれば、自宅最寄りの集配局には木曜日の深夜か金曜日の早朝、もしくは金曜日の昼にであろう、そうなれば、金曜日にはなんとか受け取れる可能性が高いと判断。
  • 出発日である土曜日の朝に受け取ることも考えたが、自宅は午前7時過ぎにでる必要があり、郵便局のゆうゆう窓口が開くのが午前7時。確実に受け取るとなると出発を15分から30分ほど遅らせる必要があるが、渡航先へは直行便ではないため、できれば余裕を持った時間に出発地の空港に到着したい。というもの、経由地から渡航先への航空便の時間が頻繁に変更されていたため、空港で様子を確認したい。
  • 木曜日の朝、クレジットカード会社に電話して状況を確認すると、夕方に郵便局へ持ち込みということ。郵便の問い合わせ番号を教えていただいたので、木曜日の夕方に  郵便局のWWWサイトで確認をしてみると、17時ぐらいに登録されたことを確認。
  • 金曜日の朝、7時半に自宅近くにある集配局に行き、 郵便を局で受け取れないか聞いてみるが、また郵便局での登録がないので、手続きができないとのこと。配達になる前に来ることができたら渡せるかもしれないということなので、問い合わせ番号を定期的に確認する。
  • 8時過ぎになり、問い合わせ番号が先ほどの集配局に登録されたことがわかったので、ふたたび集配局に向かうが、残念ながら配達に出てしまったとのこと。しかたがないので、自宅で待機していると11時前に配達された。

まとめ

クレジットカードの再発行にかかるのは1週間が最短のようだ。不具合があると思ったら直ちに再発行を依頼したほうが無難だろう。長期の旅行に行く前にはクレジットカードのICとストライプが読み取れるかを試すほうがよいかもしれない。たとえば、セブンイレブンのクレジットカード決済はIC、ファミリーマートはストライブなのでそれぞれで試すのが簡単だろう。

2019年7月15日月曜日

Windows 10 1903で改ざん防止機能を有効にする

Windows 10 1903にアップデートしたPCを操作していると、タスクバーに以下のような表示が出ていることに気が付きました。
 クリックしてみると、以下のような設定画面が開きます。
 さらに「ウイルスと脅威の防止」をクリックしてみると、次のような画面になります。
 さらに「ウイルスと脅威の防止の設定」にある「設定の管理」をクリックすると以下のような画面になります。
「改ざん防止」の機能が無効になっているようです。検索エンジンで調べてみると、次のような説明が見つかります。
改ざん防止機能によってセキュリティ設定の変更を防止する
https://support.microsoft.com/ja-jp/help/4490103/windows-10-prevent-changes-to-security-settings-with-tamper-protection
どうもWindows 10 1903から導入された機能のようです。必要な機能なように思えるので、「改ざん防止」の「オフ」と表示されているところをクリックして有効にするにしてみます。すると、以下のような確認画面が表示されるので「はい」を選びます。
 すると以下のように「改ざん防止」が有効になります。
これで様子を見てみます。

2019年6月25日火曜日

macOSでアプリケーションごとに言語を切り替えたい

macOSでアプリケーションごとに言語を切り替えたいときには、以下のサイトの記述のようにすればよいようです。
App Language ChooserでMail.app等特定のアプリだけ英語設定にする
https://rcmdnk.com/blog/2013/07/15/computer-mac-english/#defaults%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E3%81%A7%E7%9B%B4%E6%8E%A5%E6%9B%B8%E3%81%8D%E6%8F%9B%E3%81%88%E3%82%8B%E6%96%B9%E6%B3%95
以下に引用します。
上のアプリを入れなくてもdefaultsコマンドで変更することも出来ます。

$ defaults write com.apple.mail AppleLanguages "(English)"

Mail.appのAppleLanguagesと言う値をEnglishに指定しています。 ここでは環境設定の言語設定の様に"(English Japanese)"の様に 優先順位を決めて複数を指定することも出来るようです。 (あまりその恩恵を受けられるアプリは思いつきませんが。)

defaults findコマンドでこれまでに指定したAppleLanguagesを見ることが出来ます。 App Language Chooserも恐らくこの値を変えてるだけらしく、同じく このコマンドで変更を見ることが出来ます。

$ defaults find AppleLanguages
Found 1 keys in domain 'org.gimp.gimp': {
    AppleLanguages =     (
        English
    );
}
Found 1 keys in domain 'com.apple.mail': {
    AppleLanguages =     (
        English
    );
}

すっかり忘れてましたが、以前、Gimpを更新した際、ビルドされたものが 日本語環境だと落ちるバグ?があったのでGimpも英語にしてありました。 (多分もう大丈夫なんだと思いますが。)

逆に、英語環境下において日本語にしたい場合は

$ defaults write com.apple.mail AppleLanguages "(Japanese)"

の様にします。このJapaneseやEnglishについて、 どの値を取れるのがいまいち理解してませんが、 JapaneseはjaでもOKです。
com.apple.mailなどのアプリケーションの名前は、
$ ls ~/Library/Preferences
とすればそれらしい名前が得られます。

2019年4月25日木曜日

Versa Pro VA-G(VK18EA-G)のCeleron 1000MをCore i7 2640Mに交換

知人のVersa Pro VA-G(VK18EA-G)
型名 : VK18E/A 
http://121ware.com/navigate/support/productsearch/old_number/VK18EAG/spec.html
のCPUがCeleron 1000M
インテル® Celeron® プロセッサー 1000M
2M キャッシュ、1.80 GHz

https://ark.intel.com/content/www/jp/ja/ark/products/72060/intel-celeron-processor-1000m-2m-cache-1-80-ghz.html
でかなり遅く、手元にたまたまあったCore i7 2640M
インテル® Core™ i7-2640M プロセッサー
4M キャッシュ、最大 3.50 GHz

https://ark.intel.com/content/www/jp/ja/ark/products/53464/intel-core-i7-2640m-processor-4m-cache-up-to-3-50-ghz.html
に交換してみると、動いてしまいました。チップセットがHM75M Express
インテル、Intel 7シリーズチップセットを正式に発表
2012年04月08日 00時00分 公開
Ivy BridgeもSandy Bridgeも使えますから安心してください

https://www.itmedia.co.jp/pcuser/articles/1204/08/news008.html
でSandy Bridge(2640M)とIvy Bride(1000M)を両方サポートしているようです。BIOSのサポートがあるかはわからなかったのですが、試してみると、今のところ、うまく動いているようです。

VK18E/Aの分解については、以下のblogを参考にしました。
【パソコン】NEC Versa Pro VK18E/AのCPUを交換してみました。
https://mokkousan.blog.fc2.com/blog-entry-153.html
今回、CPUを交換したPCとは型番が違いますが同じ構造に見えるので、こちらにある手順を試したところ、うまくいきました。手順は以下のようです。
  1. バッテリーを外します。
  2. メモリと同様に背面の大きなカバー(ネジ×4)を外します。
  3. CPUを止めているヒートシンクのネジ×4とファンのネジ×2を外し、ヒートシンクを外します。
  4. CPUロックを反時計回りに回して外します。
  5. ファン廻りのほこりの掃除、ヒートシンクの古いグリスの除去。
  6. 新しいCPUを取付(取付位置に注意!)、グリスの塗布。
  7. ロックをしてヒートシンクを取付、カバー取付で終了。
  8. BIOSでCPUの認識を確認。
こういった作業に慣れている人であれば、15分から30分程度でできると思います。

2019年4月17日水曜日

Ubuntu Server 18.4をFreeBSD 10.xのNISクライアントとする

Ubuntu Server 18.4をFreeBSD 11.xのNISクライアントとする場合、いくつかの設定が必要でした。
FreeBSD 11をNISサーバーに、Ubuntu 16.04をNISクライアントするための設定
http://www.sakashita-net.jp/2018/01/freebsd-11nisubuntu-1604nis-1.html
http://www.sakashita-net.jp/2018/01/freebsd-11nisubuntu-1604nis-2.html
今回、これ以外にも設定が必要であることがわかりました。
  1. NISのパッケージをインストールして設定ファイルを記述
    $ sudo apt install nis

    $ cat /etc/yp.conf
    domain NISドメイン名 server NISサーバーホスト名
    $ cat /etc/nsswitch.conf
    passwd:         compat systemd nis
    group:          compat systemd nis
    shadow:         compat nis
    $
  2. NISでの認証の場合、ログインに時間がかかるので、以下のWWWページを参照して設定を行った。

    Ubuntu 18.04 マシンへのログインに時間がかかることに対する対処
    https://ocg.aori.u-tokyo.ac.jp/member/daigo/comp/memo/?val=valid&typ=all&nbr=2018051801

    問題
    Ubuntu 16.04 のころから ssh でログインするのに異様に時間がかかるようになった. ログインするたびに /var/log/auth.log には
    pam_systemd(sshd:session): Failed to create session: Connection timed out
    とのエラーが出ており PAM に問題があるようだったため,sshd が PAM を使わないよう設定していた. なお, このタイムアウトは 25秒 に設定されている. しかし, パスワード認証に PAM を使うシステムは sshd だけでなく,デスクトップの lightdm なども該当するため根本的解決が必要になった.
    原因
    ログインに時間がかかるマシンは NIS のクライアントでもあった.sshd の起動時, /var/log/syslog には
    systemd-logind do_ypcall: clnt_call:
    RPC: Unable to send; errno = Operation not permitted

    とのエラーが出ていた. PAM が呼ぶ system-logind が NIS サーバにアクセスできていないようである. ypcat などで passwd データなどは引けているので, この原因は不明である.
    対処
    /lib/systemd/system/systemd-logind.service
    にて
    IPAddressDeny=any

    #IPAddressDeny=any
    とコメントアウトし
    $ sudo systemctl daemon-reload

    で systemd をリロード. これで ssh, lightdm 等のログイン問題は解決した.

    Linux NISクライアントがログイン時にハングアップする
    https://qiita.com/kakinaguru_zo/items/18258d4dd296a755badd

    Ubuntu 18や最近のDebian testingやArch LinuxでNISを用いた認証を行うようにすると25秒間固まる。これはsystemdバージョン235からsystemd-logindが一切のネットワーク通信を出来ないように設定されているからである。これを解決するための方法はいくつかあり以下のどれかを実行すればよい。
    1. /lib/systemd/system/systemd-logind.service の IPAddressDeny=any の行をコメントアウトする
    2. unscd をインストールする(nscdは問題が多いのでやめたほうがよい)
    この問題はsystemdの開発者に認識されているがsystemdのほうで修正される予定はない

    私は、後者のunscdをインストールすることで対処しました。というのは、ファイル/lib/systemd/system/systemd-logind.service はsystemdのアップデートで更新されてしまうことがあり、変更が失われてしまう場合があったためです。

Ubuntu Desktop 16.04で起動時にDHCPからのIPアドレス取得が遅く、NFSのマウントに失敗する

Ubuntu Desktop 16.04で起動時にDHCPからのIPアドレス取得が遅く、NFSのマウントに失敗するということがありました。これは
/lib/systemd/system/NetworkManager-wait-online.service

[Service]
Type=oneshot
ExecStart=/usr/bin/nm-online -s -q --timeout=30
RemainAfterExit=yes
の太字の部分を
[Service]
Type=oneshot
# ExecStart=/usr/bin/nm-online -s -q --timeout=30
ExecStart=/usr/bin/nm-online -s -q --timeout=90
RemainAfterExit=yes
とすることで回避できました。

これは、/var/log/syslogの内容を手がかかりにして見つけました。

  1. /var/log/syslogには以下のようなエラーが記録されていました。
    DHCPDISCOVER on enp2s0 to 255.255.255.255 port 67 interval 3 (xid=0xe6993237)
    DHCPDISCOVER on enp2s0 to 255.255.255.255 port 67 interval 8 (xid=0xe6993237)
    NetworkManager-wait-online.service: Main process exited, code=exited, status=1/FAILURE
    Failed to start Network Manager Wait Online.
    NetworkManager-wait-online.service: Unit entered failed state.
    NetworkManager-wait-online.service: Failed with result 'exit-code'.
    Reached target Network is Online.
    Mounting /home...
    mount.nfs: Failed to resolve server NFS0: Temporary failure in name resolution
  2. この「NetworkManager-wait-online.service」が怪しそうなので、検索をしてみると以下のWWWページがありました。
    デバイスの認識が遅くてnetwork.serviceがfailedになる問題
    https://qiita.com/kawaz/items/715d7ea761f13230607b

    systemctl list-unit-files を見てたら NetworkManager-wait-online.service なんて名前のサービスがあるじゃない!?デフォルトではdisabledらしいが、いかにも僕の問題を解決してくれそうなサービス名である。おもむろに有効化。

    systemctl enable NetworkManager-wait-online.service

    再起動してみる。…やったー、無事SSH入れたよ!network.service のステータス見ても failed しなくなってる!
  3. そこでこのサービスを確認し見たところ、enabledにはなっているがエラーがある(太字)。
    $ systemctl status NetworkManager-wait-online.service
    ● NetworkManager-wait-online.service - Network Manager Wait Online
    Loaded: loaded (/lib/systemd/system/NetworkManager-wait-online.service; enabled; vendor preset: enabled)
    Active: failed (Result: exit-code) since …; 3min 40s ago
    Docs: man:nm-online(1)
    Process: 874 ExecStart=/usr/bin/nm-online -s -q --timeout=30 (code=exited, status=1/FAILURE)
    Main PID: 874 (code=exited, status=1/FAILURE)
  4. このサービスの記述ファイルをlocateコマンドで探して中を確認してみると以下のようになりました。
    $ locate NetworkManager-wait-online.service
    /etc/systemd/system/network-online.target.wants/NetworkManager-wait-online.service
    /lib/systemd/system/NetworkManager-wait-online.service
    /var/lib/systemd/deb-systemd-helper-enabled/NetworkManager-wait-online.service.dsh-also
    /var/lib/systemd/deb-systemd-helper-enabled/network-online.target.wants/NetworkManager-wait-online.service
    $
    もう少し見てみると、
    $ cd /etc/systemd/system/network-online.target.wants/
    $ ls -l

    lrwxrwxrwx 1 root root  38  2月 19 19:50 networking.service -> /lib/systemd/system/networking.service
    lrwxrwxrwx 1 root root  54  2月 19 19:50 NetworkManager-wait-online.service -> /lib/systemd/system/NetworkManager-wait-online.service
    ようにシンボリックリンクとなっていて、/lib/systemd/system/NetworkManager-wait-online.service が本体のようです
  5. そこで/lib/systemd/system/NetworkManager-wait-online.serviceを最初に書いたように変更しました。
さらに、このUbuntu Desktop 16.04はサーバーとして運用しているのでGUIが不要です。そこで、以下のようにしてGUIを停止しました。
$ systemctl status lightdm
● lightdm.service - Light Display Manager
Loaded: loaded (/lib/systemd/system/lightdm.service; enabled; vendor preset: enabled)
Drop-In: /lib/systemd/system/display-manager.service.d
         └─xdiagnose.conf
Active: active (running) since … 15:24:23 JST; 3min 28s 


$ sudo systemctl disable lightdm 
$
補足: この「IPアドレスが必要なサービスがIPアドレスの付与を待たない」という問題は、Ubuntu Server 18.04では解消されていました。

2019年4月11日木曜日

Apple製品の廃棄

不要になったMac miniの廃棄をアップルに依頼してみました。リサイクルマークが添付されている製品だけだったためか、13時にWWWページから依頼して、その日の17時に引き取り日時が決まりました。引き取りは1週間後でした。

以下に時系列をまとめます
  •  13:00
    以下のWWWページの「事業系パソコンのリサイクルのお見積もり依頼」から引取を依頼
    Appleのリサイクルプログラム
    MacとiPadのリサイクル

    https://www.apple.com/jp/recycling/computer/
  • 13:01
    廃棄業者からメールで自動返信
  • 13:02
    廃棄業者から電話があり、廃棄するもの、引取の場所などの確認
  • 13:20
    見積書兼回収申込書がメールで送られてくる
  • 13:50
    申込書をメールで送付
  • 15:05
    申込書受領の確認されたという連絡をメールで受け取る
  • 17:00
    引取業者から引き取り日時の連絡
  • 一週間後
    引取
非常に迅速でした。