読者です 読者をやめる 読者になる 読者になる

pslaboが試したことの記録

はてなダイヤリーからはてなブログに引っ越してきました

この日記は現在実行中の減量記録を含む個人的なメモとして始めましたが、最近はコンピュータやガジェット、ハック、セキュリティネタのほうがメインになっております。

iPad3のSIMロックに関する考察とSIM下駄による解除の試みはSoftbank版iPad3にiPhone用のSIM下駄を履かせてみるにいろいろ書いてます。

ポストした内容のカテゴリー分けがちゃんと出来てないので、過去記事を探したい方はお手数ですが検索で探してみてください。


Apple提携のBrightStarにiPadを下取りに出してみたが、デバイスの発送の方法に改善の余地あり?

iPad3は新しいiPadへの買い替えに伴って下取りに出したのですが、他にもiPad2がありまして、こちらも処分したいのでアップル提携の BrightStar のサービスに下取りに出してみることにしました。

https://reuserecycle-apple-jp-asia.brightstar.com/is-bin/INTERSHOP.enfinity/WFS/BrightstarAPAC-JPAPPCON-Site

このサービスは自宅にいながら下取りに出せるので便利なようにも思えますが、案外使いづらいので、自分の感想をメモとして残しておきます。

良い点

本人確認書類のコピーを用意しなくても良い

一般的に中古の買取では運転免許証などの本人確認書類が必要となります。しかしアップルが提携するブライトスターの場合は返送キットが送付先限定で届きます。この時点で中古売買に伴う本人確認ができているとみなせるためか、この手の本人確認書類は不要です。なお、サイトには送付キットの受け取りのときに本人確認が必要、と書かれていますが、受け取りの際に本人確認が求められることはありませんでした。デバイスWiFi only の iPad2 だったためですかねえ??

悪い点

発送用のキットの配送と、返送が別々の手続きに分かれていて二度手間であること

発送用のキットは単に宅配便で送られてくるだけです。キットの中にiPadを入れて発送するには集荷の手配が別途必要になります。え、普通でしょ? と思いたくなりますが、PC の修理では「宅配業者が回収用の梱包材を持参して引き取りにくる」というのが自分が経験した範囲では、多分普通のオペレーションです。

例えばMacBookVAIOを過去に修理に出したときは、クロネコヤマトの担当者が回収用の箱を持って指定した場所までやってきます。そしてその場で梱包して回収して持っていくと言う流れでした。つまり運送業者とのやりとりは1回だけです。このときに送り状になんらかの記入を行う必要すら無いのです。

しかし今回のiPad下取りでは、佐川運輸が発送用の箱キットを届けにきました。ここで回収されるわけではないのです。このキットにiPadを入れて送り状を記入して集荷を手配せねばなりません。なんと無駄なことでしょうか。下取りに出したい側からみれば、受け取りと集荷の2回の手配を行わねばなりません。時間の無駄です。

そして単身者の場合は平日の日中に返送キットを受け取ることは困難であり、場合によっては夜間でも受け取りが難しいかもしれません。そうすると返送キットは週末に受け取る前提で手配せねばならないのですが、手配の際に着日を指定できません。だから、週の前半に申し込みをかけておき、週末に確実に受け取れるような段取りを考えねばなりません。

佐川運輸の場合は持ち込みで配送手配できる取次店が少ないので、発送手配が少々めんどくさいこと

クロネコヤマトの場合は取次店が多いのでコンビニに持ち込めば発送できます。しかし佐川運輸の場合は取次店が少ないので持ち込みでの発送手配が容易ではありません。首都圏の場合は集配所がそれなりに配置されていますけれど、繁華街の集配所を除けば土日は閉まっているケースが多々あります。したがって、土日にキットを受け取った場合は、そのキットの発送のために集荷を手配するか、または開いている取次店を探して持ち込むことになります。私の場合はキットを土曜日午前中に受け取ったのですが、土曜日午後には外出の予定がありまして、外出先の近所の集配所に持ち込むことにしてみました。

そしたら、持ち込んだ集配所はドアや鍵が開けっ放しのままで不在の状態……。10分ほど待ったら佐川のお兄さんが戻ってこられましたが、ランチタイムだったので食事に出ていたんですかねえ。自分が持ち込んだ集配所以外でもこういう状況だったりするとは思いたくないけれど、防犯上の問題もあるし、そもそも集配所に持ち込むのは時間のロスを少なくしたいのが目的なのに、逆に時間をロスするとか意味不明。

まあそんなわけで、サービスとしては悪くはないけれど、使い勝手に難がある、というのが率直な感想かも。

RaspberyPi3で携帯用のWiFiのアクセスポイントを作るためにOpenWRT互換のLEDEをインストールしてみる

以前にこういう記事を書いていたのですが、このときは WPA2-EAP向けのパッケージが見当たらなかったので、一旦はLEDEの導入を断念しています。

pslabo.hatenablog.com

まあしかし、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/ にアクセスします。 するとインストール直後の状態ではパスワードなしでログインできるようです。 f:id:pslabo:20170515225815p:plain

そこでまずはパスワードを設定することにしましょう。ログイン後の画面で System → Administraton を選択します。 f:id:pslabo:20170515230555p:plain

するとパスワード設定用の画面が出ているかと思いますので、ここでパスワードを入力します。 f:id:pslabo:20170515225844p:plain

画面の最下部の Save & Apply をクリックするとパスワードが設定されます。 f:id:pslabo:20170515230654p:plain

無線LANの有効化

今回の設定ではNICはWAN側にして出張先のホテルのLANに繋ぐ想定です。

従って以下のような設定を作ります。 - WiFiをLAN側に収容し、LAN側はDHCPサーバとする。 - NICはWAN側に収容し、WAN側はDHCPクライアントとする。

しかしLEDEの初期状態ではWiFiは有効化されていません。これはセキュリティのことを考えると極めて正しい設定なのですが、NICはあくまでWANポートのつもりなので、いつまでもNICから設定を行うわけにもいきません。

そこで、さっさとWiFiを有効化してしまうことにしましょう。

この設定は Network→Wireless から行います。 f:id:pslabo:20170515230712p:plain

すると SSID = LEDE というエントリがありますが、これは無効化されています。そこでまずは無線側の設定を調整します。 f:id:pslabo:20170515230737p:plain

国設定を日本にして、Wireless Security で WPA2-PSK を選択します。また、Key も設定します。SSIDをデフォルトのLEDEから変更したい場合も適切に設定します。設定が済んだら Save & Apply して、Back to Overview します。 f:id:pslabo:20170515230805p:plain

あとは Enableをクリックすれば無線が有効になりますので、実際に接続できることを確認します。 f:id:pslabo:20170515230828p:plain

NIC を WAN 側に割り当てる

WiFI側から接続できるようになったら、NICをWAN向けの設定に変更します。

まずは Network → Interfaces を選びます。 f:id:pslabo:20170515230947p:plain

初期状態では LAN だけが存在していますので、Add New Interface を選択します。 f:id:pslabo:20170515231035p:plain

インタフェース名は wan で DHCP client にしておきます。また、following interface として eth0 を選択しておきます。 f:id:pslabo:20170515231055p:plain f:id:pslabo:20170515231123p:plain

なお、インタフェース lan には eth0 が含まれていますので、lan の設定から eth0 を外しておきます。 f:id:pslabo:20170515231142p:plain f:id:pslabo:20170515231148p:plain

LAN側ネットワークアドレスを変える

さらに LAN 側のIPアドレスをデフォルトの192.168.1.1 から別のネットワークアドレスに変えておきます。たとえばフレッツ光のレンタルルータは内部アドレスが192.168.1.0/24 と LEDE のデフォルトのアドレスと同じネットワークアドレスを使っています。これでは通信が正しく行えませんので、全く別のアドレスに変えます。

ここでは 192.168.4.1 に変更してみました。新しい設定は Save & Apply を押したらすぐに有効になります。 f:id:pslabo:20170515231430p:plain

管理UIの言語を日本語にする

英語が不得意な方にとって、管理UIが英語であることは非常にストレスになります。OpenWRTヤLEDEは管理UI向けの日本語リソースも配布されていますので、これをインストールすることで日本語のUIになります。

まずは System→Softwareを選択し…… f:id:pslabo:20170515231841p:plain

LEDE向けのソフトウェアパッケージのリストをダウンロードします。 f:id:pslabo:20170515232021p:plain

なお、このリストは LEDE をシャットダウンやリブートすると消えてしまうので、ソフトウェアメンテナンスを行う度にパッケージリストのダウンロードが必要です。

パッケージリストのダウンロードが完了したら、Filter に “luci-l18n-base-ja” と入力して Find Package します。 f:id:pslabo:20170515232322p:plain

そして Available packages から luci-l18n-base-ja を選んで install します。

インストールが完了したら、System→Systemより言語を日本語に変更します。 f:id:pslabo:20170515232436p:plain

これで LEDE を日本語で利用できるようになりました。 f:id:pslabo:20170515232529p:plain

WAN側からの管理ポートへのアクセスを禁止する

ここまでの作業で最低限の要件を満たす設定が出ています。しかし、実際に運用する前に、WAN側に不要なポートが開いていないかどうかを念のために確かめます。

まず、OpenWRT/LEDE では ssh サーバ機能が生きていますので、これは LAN 側だけに制限しておきます。

f:id:pslabo:20170516070749p:plain

f:id:pslabo:20170516070801p:plain

さらに、WAN側の HTTP が開いていないことも念のために確かめまsす。WAN側のIPアドレスはインタフェース設定から確認できますので、WAN側に繋いだ別の機器から、このアドレスの 80/TCP にブラウザで接続できないことを確認してください。 f:id:pslabo:20170516070431p:plain

ssh と http が閉じていたら、基本的には安全と考えてよいはずです。なお、ここまでの設定では、LEDE は以下のようなポートで daemon が動いた状態です。

f:id:pslabo:20170516071136p:plain

より厳密に確認したい場合は、これらのポートにWAN側から繋がらないことを確実にチェックしておきます。

WannaCrypt対策としてWindowsXP向けにリリースされたパッチを入れてみる

WannaCrypt向けのパッチがWindowsXP向けにもリリースされたということなので、ソフトウェアの旧バージョンの動作確認用に仮想マシンで作っておいたWindowsXPに適用しておくことにする。

なお、このXPはVMware WorkstationでNATのネットワークに接続しているので、LANの他のノードからのパケットは基本的に届かない構成です。また、古いソフトウェアの検証のみに使っており、普段はシャットダウンした状態で保存している環境です。

では、まずは日本語の一次情報をチェック!

blogs.technet.microsoft.com

なるほど、Windows Update カタログ Microsoft Update Catalog で配布している、と。ならば実際にアクセスしてみよう。

f:id:pslabo:20170515082116p:plain

Windows XPのInternet Explorer8では表示できなかった!

ではWindows Updateを試してみると……

f:id:pslabo:20170515082201p:plain

そもそもWindowsUpdateにもつながらんやんけ! 今は Windows Update も封じられているんですかねえ。それともたまたま?

というわけで、別のマシンでWindows Updateカタログにアクセスしてみよう。 f:id:pslabo:20170515082321p:plain

これやな。

ダウンロードを押すと、こんなページが出る。 f:id:pslabo:20170515082736p:plain

これをダウンロードして実行すればよいわけですね。

というわけで、一応対策完了。 f:id:pslabo:20170515082932p:plain

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 をフルフルにインストールした手元の環境では、ディスクをコレくらい消費します。

f:id:pslabo:20170510101535p:plain

これはつらい。

そこで、NTFS圧縮をピンポイントで設定して、ディスクの空きを増やすことを試みてみます。

実施後の状態はこんな感じ。おお、なんと空き領域が20GB以上も増えました。

f:id:pslabo:20170510101551p:plain

違いをもう少し掘り下げてみる。

何がどのように変わっているかというと……NTFS圧縮を適用する前はこんな状態。 f:id:pslabo:20170510101603p:plain

NTFS圧縮をかけたらこんな状態。 f:id:pslabo:20170510101609p:plain

つまり、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でこういうのを見かけたので、

ためしに 127.0.0.1:16992 してみたら、 f:id:pslabo:20170508143918p:plain

はい、アウトですね。

ここらへんの記事を読むと、Intelが配布するツールで本件の影響の有無を確認できるとか。

japan.cnet.com

ダウンロードのページはこちらだそうです。 downloadcenter.intel.com

そこでダウンロードしてツールを実行してみた。 f:id:pslabo:20170508144659p:plain

はい、完全にアウトですね、本当にありがとうございます。さて、このツールで案内されているURLの記事を見ると、OEMベンダー経由でファームウェアのアップデートの提供を受けるか、または INTEL-SA-00075 Mitigation Guide を読んで軽減策を実施しろ、と書いてある。

f:id:pslabo:20170508144223p:plain

しかし手元のの機材向けにはファームウェアのアップデートがリリースされていないようなので、軽減策を実施することにしてみる。英語の文書をとりあえず流し読みしてみると、LMS (Local Managemanet Service) の機能を止めるには、以下のように実行しろ、と書いてあるようだ。

sc.exe config LMS start=disabled

なお、オリジナルの文書は単に sc と書かれているけど Windows10 1703 以降のように PowerShell がデフォルトな環境では sc だと別の処理が動いてしまうから、この手の文書には拡張子を含めたコマンドを書いて欲しいものだと思う。

さて、これを実行したら再起動して、前述のURLに再度アクセスしてみる。 f:id:pslabo:20170508145748p:plain

とりあえずサービスは止まったようだ。これで安心してよいのかどうかはイマイチ分からんけど。

AWSやGCEの無料枠でmastodonを立てるための情報収集

とりあえずのメモ。とは言っても、すでに誰かがやっていることの後追いでしか無いわけだが。

ポイントは、無料枠のインスタンスではビルド時のメモリが足らんので、スワップを確保せねばならんことだろうか。

リファレンスの情報は、たとえばこんなあたり。

qiita.com

translucens.hatenablog.jp

ただしDockerで立てるのは内部構造がわかりづらい。そういう意味では、こちらの記事の方が参考になるかも。 https://lithium03.info/mastodon/index.html

自分がやってみた場合の手順は別途ログをまとめる予定。とりあえずはDockerで平文のサーバが稼働するところまでは来ている。あとはSSL/TLSの処理をLBに載せるのか、それとも自力で扱うか。自力で扱うにしても、Dockferの中のWebサーバでやるのか、それともDockerの外側にreverse proxyを立てるのか、など、方法はいろいろ。