Apple提携のBrightStarにiPadを下取りに出してみたが、デバイスの発送の方法に改善の余地あり？
iPad3は新しいiPadへの買い替えに伴って下取りに出したのですが、他にもiPad2がありまして、こちらも処分したいのでアップル提携の BrightStar のサービスに下取りに出してみることにしました。
このサービスは自宅にいながら下取りに出せるので便利なようにも思えますが、案外使いづらいので、自分の感想をメモとして残しておきます。
良い点
本人確認書類のコピーを用意しなくても良い
一般的に中古の買取では運転免許証などの本人確認書類が必要となります。しかしアップルが提携するブライトスターの場合は返送キットが送付先限定で届きます。この時点で中古売買に伴う本人確認ができているとみなせるためか、この手の本人確認書類は不要です。なお、サイトには送付キットの受け取りのときに本人確認が必要、と書かれていますが、受け取りの際に本人確認が求められることはありませんでした。デバイスが WiFi only の iPad2 だったためですかねえ？？
悪い点
発送用のキットの配送と、返送が別々の手続きに分かれていて二度手間であること
発送用のキットは単に宅配便で送られてくるだけです。キットの中にiPadを入れて発送するには集荷の手配が別途必要になります。え、普通でしょ？ と思いたくなりますが、PC の修理では「宅配業者が回収用の梱包材を持参して引き取りにくる」というのが自分が経験した範囲では、多分普通のオペレーションです。
例えばMacBookやVAIOを過去に修理に出したときは、クロネコヤマトの担当者が回収用の箱を持って指定した場所までやってきます。そしてその場で梱包して回収して持っていくと言う流れでした。つまり運送業者とのやりとりは1回だけです。このときに送り状になんらかの記入を行う必要すら無いのです。
しかし今回のiPad下取りでは、佐川運輸が発送用の箱キットを届けにきました。ここで回収されるわけではないのです。このキットにiPadを入れて送り状を記入して集荷を手配せねばなりません。なんと無駄なことでしょうか。下取りに出したい側からみれば、受け取りと集荷の2回の手配を行わねばなりません。時間の無駄です。
そして単身者の場合は平日の日中に返送キットを受け取ることは困難であり、場合によっては夜間でも受け取りが難しいかもしれません。そうすると返送キットは週末に受け取る前提で手配せねばならないのですが、手配の際に着日を指定できません。だから、週の前半に申し込みをかけておき、週末に確実に受け取れるような段取りを考えねばなりません。
佐川運輸の場合は持ち込みで配送手配できる取次店が少ないので、発送手配が少々めんどくさいこと
クロネコヤマトの場合は取次店が多いのでコンビニに持ち込めば発送できます。しかし佐川運輸の場合は取次店が少ないので持ち込みでの発送手配が容易ではありません。首都圏の場合は集配所がそれなりに配置されていますけれど、繁華街の集配所を除けば土日は閉まっているケースが多々あります。したがって、土日にキットを受け取った場合は、そのキットの発送のために集荷を手配するか、または開いている取次店を探して持ち込むことになります。私の場合はキットを土曜日午前中に受け取ったのですが、土曜日午後には外出の予定がありまして、外出先の近所の集配所に持ち込むことにしてみました。
そしたら、持ち込んだ集配所はドアや鍵が開けっ放しのままで不在の状態……。10分ほど待ったら佐川のお兄さんが戻ってこられましたが、ランチタイムだったので食事に出ていたんですかねえ。自分が持ち込んだ集配所以外でもこういう状況だったりするとは思いたくないけれど、防犯上の問題もあるし、そもそも集配所に持ち込むのは時間のロスを少なくしたいのが目的なのに、逆に時間をロスするとか意味不明。
まあそんなわけで、サービスとしては悪くはないけれど、使い勝手に難がある、というのが率直な感想かも。
RaspberyPi3で携帯用のWiFiのアクセスポイントを作るためにOpenWRT互換のLEDEをインストールしてみる
以前にこういう記事を書いていたのですが、このときは WPA2-EAP向けのパッケージが見当たらなかったので、一旦はLEDEの導入を断念しています。
まあしかし、LEDEが動くなら、出張の際にホテルのLANにつける携帯用WiFiアクセスポイントに仕立ててみるのはアリなので、あらためて設定してみることにします。
使うのは当然ながらRaspberry Pi3ですので、本体やmicroSDなどの必要な部材は揃えておいた上で作業にとりかかります。
なお、Raspberry Pi Zero W でもイケるとは思いますけど、手元に機材が無いので未検証です。
イメージの入手とmicroSDへの焼きこみ
2017/5/14時点では以下のURLからRaspberryPi3向けのイメージが入手できます。 https://downloads.lede-project.org/releases/17.01.1/targets/brcm2708/bcm2710/
gzip 形式で圧縮されていますから、gunzip などを使って展開します。シェル上でやるならこんな感じ。
$ cd Downloads/ $ ls lede-17.01.1-brcm2708-bcm2710-rpi-3-ext4-sdcard.img.gz lede-17.01.1-brcm2708-bcm2710-rpi-3-ext4-sdcard.img.gz $ gunzip lede-17.01.1-brcm2708-bcm2710-rpi-3-ext4-sdcard.img.gz $ ls lede-17.01.1-brcm2708-bcm2710-rpi-3-ext4-sdcard.img lede-17.01.1-brcm2708-bcm2710-rpi-3-ext4-sdcard.img
その他、7-zip などで展開してもよいでしょう。展開後のイメージは dd などで microSDHC に焼きます。
microSDからの起動
microSDをRaspberryPi3に装着して起動させるだけです。なお、RaspberryPiのNICは設定用のPCに接続しておいてください。既存のLANに接続してはダメです。LEDEの初期状態では、IPaddress = 192.168.1.1 かつ DHCPサーバが有効な状態となっていますので、既存のLANに接続すると問題を引き起こします。したがって、設定用のPCと直結しておく必要があるのです。
パスワード設定
LEDEへのブラウザからのログインは http://192.168.1.1/ にアクセスします。
するとインストール直後の状態ではパスワードなしでログインできるようです。
そこでまずはパスワードを設定することにしましょう。ログイン後の画面で System → Administraton を選択します。
するとパスワード設定用の画面が出ているかと思いますので、ここでパスワードを入力します。
画面の最下部の Save & Apply をクリックするとパスワードが設定されます。
無線LANの有効化
今回の設定ではNICはWAN側にして出張先のホテルのLANに繋ぐ想定です。
従って以下のような設定を作ります。 - WiFiをLAN側に収容し、LAN側はDHCPサーバとする。 - NICはWAN側に収容し、WAN側はDHCPクライアントとする。
しかしLEDEの初期状態ではWiFiは有効化されていません。これはセキュリティのことを考えると極めて正しい設定なのですが、NICはあくまでWANポートのつもりなので、いつまでもNICから設定を行うわけにもいきません。
そこで、さっさとWiFiを有効化してしまうことにしましょう。
この設定は Network→Wireless から行います。
すると SSID = LEDE というエントリがありますが、これは無効化されています。そこでまずは無線側の設定を調整します。
国設定を日本にして、Wireless Security で WPA2-PSK を選択します。また、Key も設定します。SSIDをデフォルトのLEDEから変更したい場合も適切に設定します。設定が済んだら Save & Apply して、Back to Overview します。
あとは Enableをクリックすれば無線が有効になりますので、実際に接続できることを確認します。
NIC を WAN 側に割り当てる
WiFI側から接続できるようになったら、NICをWAN向けの設定に変更します。
まずは Network → Interfaces を選びます。
初期状態では LAN だけが存在していますので、Add New Interface を選択します。
インタフェース名は wan で DHCP client にしておきます。また、following interface として eth0 を選択しておきます。
なお、インタフェース lan には eth0 が含まれていますので、lan の設定から eth0 を外しておきます。
LAN側ネットワークアドレスを変える
さらに LAN 側のIPアドレスをデフォルトの192.168.1.1 から別のネットワークアドレスに変えておきます。たとえばフレッツ光のレンタルルータは内部アドレスが192.168.1.0/24 と LEDE のデフォルトのアドレスと同じネットワークアドレスを使っています。これでは通信が正しく行えませんので、全く別のアドレスに変えます。
ここでは 192.168.4.1 に変更してみました。新しい設定は Save & Apply を押したらすぐに有効になります。
管理UIの言語を日本語にする
英語が不得意な方にとって、管理UIが英語であることは非常にストレスになります。OpenWRTヤLEDEは管理UI向けの日本語リソースも配布されていますので、これをインストールすることで日本語のUIになります。
まずは System→Softwareを選択し……
LEDE向けのソフトウェアパッケージのリストをダウンロードします。
なお、このリストは LEDE をシャットダウンやリブートすると消えてしまうので、ソフトウェアメンテナンスを行う度にパッケージリストのダウンロードが必要です。
パッケージリストのダウンロードが完了したら、Filter に “luci-l18n-base-ja” と入力して Find Package します。
そして Available packages から luci-l18n-base-ja を選んで install します。
インストールが完了したら、System→Systemより言語を日本語に変更します。
これで LEDE を日本語で利用できるようになりました。
WAN側からの管理ポートへのアクセスを禁止する
ここまでの作業で最低限の要件を満たす設定が出ています。しかし、実際に運用する前に、WAN側に不要なポートが開いていないかどうかを念のために確かめます。
まず、OpenWRT/LEDE では ssh サーバ機能が生きていますので、これは LAN 側だけに制限しておきます。
さらに、WAN側の HTTP が開いていないことも念のために確かめまsす。WAN側のIPアドレスはインタフェース設定から確認できますので、WAN側に繋いだ別の機器から、このアドレスの 80/TCP にブラウザで接続できないことを確認してください。
ssh と http が閉じていたら、基本的には安全と考えてよいはずです。なお、ここまでの設定では、LEDE は以下のようなポートで daemon が動いた状態です。
より厳密に確認したい場合は、これらのポートにWAN側から繋がらないことを確実にチェックしておきます。
WannaCrypt対策としてWindowsXP向けにリリースされたパッチを入れてみる
WannaCrypt向けのパッチがWindowsXP向けにもリリースされたということなので、ソフトウェアの旧バージョンの動作確認用に仮想マシンで作っておいたWindowsXPに適用しておくことにする。
なお、このXPはVMware WorkstationでNATのネットワークに接続しているので、LANの他のノードからのパケットは基本的に届かない構成です。また、古いソフトウェアの検証のみに使っており、普段はシャットダウンした状態で保存している環境です。
では、まずは日本語の一次情報をチェック！
なるほど、Windows Update カタログ Microsoft Update Catalog で配布している、と。ならば実際にアクセスしてみよう。
Windows XPのInternet Explorer8では表示できなかった！
ではWindows Updateを試してみると……
そもそもWindowsUpdateにもつながらんやんけ！ 今は Windows Update も封じられているんですかねえ。それともたまたま？
というわけで、別のマシンでWindows Updateカタログにアクセスしてみよう。
これやな。
ダウンロードを押すと、こんなページが出る。
これをダウンロードして実行すればよいわけですね。
というわけで、一応対策完了。
Windows PC のディスク使用量の時系列変化を Bash on Windows 上のワンライナーで記録してみる。
とある処理でディスクの使用量がどのように変化するかを記録する必要が出てきたので、Bash on Windows でワンライナーでやってみることにします。
まずはディスク使用量といえば df コマンド。Bash on Windows で実行すると、こうなります。
$ df Filesystem 1K-blocks Used Available Use% Mounted on rootfs 236091388 152891880 83199508 65% / data 236091388 152891880 83199508 65% /data cache 236091388 152891880 83199508 65% /cache mnt 236091388 152891880 83199508 65% /mnt none 236091388 152891880 83199508 65% /dev none 236091388 152891880 83199508 65% /run none 236091388 152891880 83199508 65% /run/lock none 236091388 152891880 83199508 65% /run/shm none 236091388 152891880 83199508 65% /run/user C: 236091388 152891880 83199508 65% /mnt/c D: 937560060 865705100 71854960 93% /mnt/d E: 12347388 10928952 1418436 89% /mnt/e root 236091388 152891880 83199508 65% /root home 236091388 152891880 83199508 65% /home
なるほど、Bash on Windows だと、Windows のドライブは C: とかで見えているわけですね。
ならば、df の出力を awk でフィルタしてみよう。こんなふうに。
$ df | awk '$1 == "C:" { print systime(),$2,$3,$4 }'
1494572754 236091388 152891884 83199504
これで UNIX秒、ディスク容量, 使用量, 空き容量がとれました。
あとは、これをずーっと実行したいので、while ループにしつつ、10秒ごとに記録するようにしてみる。
$ while : ; do df | awk '$1 == "C:" { print systime(),$2,$3,$4 }' ; sleep 10 ; done
1494572758 236091388 152891884 83199504
1494572768 236091388 152891884 83199504
1494572778 236091388 152891884 83199504
OK、こんなもんですね。あとは適当なファイルにリダイレクトすればよい。tee [ファイル名] とすれば、ファイルに保存しつつ表示してくれるので、さらによし。
RADStudio/Delphi/C++Builder向けの仮想マシン容量を節約するためにNTFS圧縮してみる
今時の開発環境は仮想マシン上にセットアップすることが多い訳ですが、マルチプラットフォーム向けの開発環境では、RAD Studio/Delphi/C++BuilderでもXamarinでも、ディスク使用量が大きいことが悩ましいです。
たとえば、手元の環境でRAD Studio をフルフルにインストールした手元の環境では、ディスクをコレくらい消費します。
これはつらい。
そこで、NTFS圧縮をピンポイントで設定して、ディスクの空きを増やすことを試みてみます。
実施後の状態はこんな感じ。おお、なんと空き領域が20GB以上も増えました。
違いをもう少し掘り下げてみる。
何がどのように変わっているかというと……NTFS圧縮を適用する前はこんな状態。
NTFS圧縮をかけたらこんな状態。
つまり、Program Files の下と users/public/documents の下が随分減ったわけですね。
実際にやったこと
安直な方法は C: 全体にNTFS圧縮を適用することですが、これはやめました。
そしてこんな感じで圧縮してみました。なお、compact.exe /compactos:always は Windows10 で利用できるオプションです。
compact.exe /compactos:always compact.exe /C /S:"C:\Program Files (x86)\Embarcadero" /I compact.exe /C /S:"C:\Users\Public\Documents\Embarcadero\Studio" /I compact.exe /C /S:"%HOMEPATH%\Documents\Embarcadero" /I
この設定によるリスクは？
一般論としてNTFS圧縮はデータベースのデータ保存領域には適用しないほうがよいです。データベースが壊れるという事例がググるといろいろ出てきます。
また、ビルドの速度は落ちるはずですが、厳密には検証していません。
ここらへんのリスクを自己責任として許容できるなら、試してみるのもよいかと。
作業用のデスクトップPCにIntelAMTの脆弱性CVE-2017-5689が見つかったようなので対処するテスト
Twitterでこういうのを見かけたので、
@piyokango ブラウザにttp://127.0.0.1:16992/たたいて管理画面でてきたら危険。サービス止めましょう。
— Takayuki Kurosawa (@Ta_ka_y_u_ki) 2017年5月8日
ためしに 127.0.0.1:16992 してみたら、
はい、アウトですね。
ここらへんの記事を読むと、Intelが配布するツールで本件の影響の有無を確認できるとか。
ダウンロードのページはこちらだそうです。 downloadcenter.intel.com
そこでダウンロードしてツールを実行してみた。
はい、完全にアウトですね、本当にありがとうございます。さて、このツールで案内されているURLの記事を見ると、OEMベンダー経由でファームウェアのアップデートの提供を受けるか、または INTEL-SA-00075 Mitigation Guide を読んで軽減策を実施しろ、と書いてある。
しかし手元のの機材向けにはファームウェアのアップデートがリリースされていないようなので、軽減策を実施することにしてみる。英語の文書をとりあえず流し読みしてみると、LMS (Local Managemanet Service) の機能を止めるには、以下のように実行しろ、と書いてあるようだ。
sc.exe config LMS start=disabled
なお、オリジナルの文書は単に sc と書かれているけど Windows10 1703 以降のように PowerShell がデフォルトな環境では sc だと別の処理が動いてしまうから、この手の文書には拡張子を含めたコマンドを書いて欲しいものだと思う。
さて、これを実行したら再起動して、前述のURLに再度アクセスしてみる。
とりあえずサービスは止まったようだ。これで安心してよいのかどうかはイマイチ分からんけど。
AWSやGCEの無料枠でmastodonを立てるための情報収集
とりあえずのメモ。とは言っても、すでに誰かがやっていることの後追いでしか無いわけだが。
ポイントは、無料枠のインスタンスではビルド時のメモリが足らんので、スワップを確保せねばならんことだろうか。
リファレンスの情報は、たとえばこんなあたり。
ただしDockerで立てるのは内部構造がわかりづらい。そういう意味では、こちらの記事の方が参考になるかも。 https://lithium03.info/mastodon/index.html
自分がやってみた場合の手順は別途ログをまとめる予定。とりあえずはDockerで平文のサーバが稼働するところまでは来ている。あとはSSL/TLSの処理をLBに載せるのか、それとも自力で扱うか。自力で扱うにしても、Dockferの中のWebサーバでやるのか、それともDockerの外側にreverse proxyを立てるのか、など、方法はいろいろ。
