pslaboが試したことの記録

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

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

はてなダイヤリー時代はカテゴリ分けが適当だったのですが、これはそのうち直します。


MarkdownエディタのAtomにインストールする拡張機能のメモ

完全に私的なメモ。随時かつ不定期に更新。

japanese-menu

操作メニューを日本語にするために導入

language-markdown

入れてみたけど、入れない状態との違いが未だよく分からない。

markclip

画像をクリップボードから ctrl+v でコピペしたいのです。設定は file in folder にしてみた。

markdown-preview-plus

入れてみたけど、入れない状態との違いがイマイチわからない。

markdown-scroll-sync -> markdown-preview-enhanced

markdown-scroll-sync は編集画面とプレビュー画面のスクロールの同期が動かなかったので、markdown-preview-enhanced に変更

Macbook Pro 2016で出先でのプロジェクタ接続用にUSB-C→HDMI&VGA変換アダプタを調達した

過去にこんな記事を書いていたのですが……

pslabo.hatenablog.com

最終的に、こんな製品を買ってみました。

実際に試した範囲での感想はこんなところ

アダプタ1つでUSB-CからHDMIVGAの両方がとれるのに、アダプタが割と小さめ

もっとも重要視したのがコレ。1つのUSB-CでHDMIVGAが両方取れたとしてもアダプタ自体が大きいのは困ります。今回購入したのは、HDMIVGAを2つ横並びに並べた幅しかないので、結構小さいです。

HDIMは4K対応

4Kなモニタがないので実際に4Kが出るかどうかは知らないのですが、4Kだそうです。

VGAは1080pといいつつも 2560x1080 なウルトラワイドでも表示できた。

自宅には U2913WM があるのですが、これは 21:9 (2560x1080) という変則的な解像度です。しかし VGA 接続、HDMI接続ともに 2560x1080 で表示させることができました。

VGA & HDMI 同時接続でも 2560x1080 で表示できた。

HDMI & VGA の2本刺しは同じ画像を両方に出力と聞いていたのでU2913WM を PinP モードにして試してみたら、2560x1080 の同じ画像が両方に出力されました。

というわけで、この金額でVGA&HDMIが取れるのは、まあアリかなあと思っております。強いて言えば、USB-C端子の給電端子が付いていたら、Pro ではない Macbook で重宝しただろうなあ、というところでしょうか。

そういう意味では、USB-C が2系統以上付いている Macbook Pro 向けならば、これは悪くない選択肢だと思います。

Ubuntu 16.04 LTS で squid の透過型プロキシを立てるために squid をリビルドする

以前に、CentOS上のSquidSSLインターセプトしてフィルタリングする透過型プロキシを立てて、さらに Google の個人アカウント利用を禁止する設定を紹介しました。

pslabo.hatenablog.com

さて、同じことを Ubuntu 16.04 LTS で行おうとしてみたのですが、標準のリポジトリから配布されているバイナリでは、これは行えないようでした。その理由は下記の理由によります。

  • Ubuntu 向けの squid パッケージングは with-openssl を付けずにビルドされている

そこで、 Ubuntu 16.04 LTS で同じ設定を作るために、squid のリビルドを行ってみることにしました。

作業の流れ

概ね、以下の7ステップです。

  • source をダウンロードできるように apt の設定を変更する
  • ビルドに必要なパッケージをインストールする
  • ソースコードをダウンロードする
  • ビルドの設定を書き換える
  • ビルドする
  • ビルドしたパッケージをインストールする
  • apt update / apt upgrade で野良パッケージが標準リポジトリのパッケージで上書きされないようにする

source をダウンロードできるように apt の設定を変更する

sudo vim /etc/apt/sources.list します。ここで必要な設定は以下のエントリです。

deb-src http://jp.archive.ubuntu.com/ubuntu/ xenial main restricted

書き換えたら sudo apt update しておきます。

ビルドに必要なパッケージをインストールする

ここらへんをインストールしておきます。

sudo apt install devscripts build-essential fakeroot libssl-dev

ソースコードをダウンロードする

こんな感じですね。するとソースコードは git clone でもイケると言われます。しかしダウンロード自体は行なわれますので、今回はそのままで行くことにします。

$ apt source squid
Reading package lists... Done
Picking 'squid3' as source package instead of 'squid'
NOTICE: 'squid3' packaging is maintained in the 'Git' version control system at:
git://anonscm.debian.org/pkg-squid/pkg-squid3.git/
Please use:
git clone git://anonscm.debian.org/pkg-squid/pkg-squid3.git/
to retrieve the latest (possibly unreleased) updates to the package.
Skipping already downloaded file 'squid3_3.5.12-1ubuntu7.dsc'
Skipping already downloaded file 'squid3_3.5.12.orig.tar.gz'
Skipping already downloaded file 'squid3_3.5.12-1ubuntu7.debian.tar.xz'
Need to get 0 B of source archives.
Skipping unpack of already unpacked source in squid3-3.5.12

ま、今後は Git clone するかなあ。

ビルドの設定を書き換える

こんな感じで。

$ cd squid3-3.5.12/
$ vim debian/rules
"Configure the package” sectionに2行足す
--with-openssl=yes \
--enable-ssl-crtd

ビルドする

./configure
debuild -us -uc -b

ビルドしたパッケージをインストールする

一つ上の階層に、ビルドされたパッケージ (*.deb) がこんなふうにできているはずですので、これをインストールします。

$ ls squid*.deb
squid3_3.5.12-1ubuntu7_all.deb
squid_3.5.12-1ubuntu7_amd64.deb
squid-cgi_3.5.12-1ubuntu7_amd64.deb
squidclient_3.5.12-1ubuntu7_amd64.deb
squid-common_3.5.12-1ubuntu7_all.deb
squid-dbg_3.5.12-1ubuntu7_amd64.deb
squid-purge_3.5.12-1ubuntu7_amd64.deb

私が squid 関連でインストールするのは、ここらへんのパッケージです。ただし squid-purge や squidclient を入れるかどうかは個々人の好み次第ですかねえ。

$ sudo apt install ./squid3_3.5.12-1ubuntu7_all.deb ./squid_3.5.12-1ubuntu7_amd64.deb ./squid-common_3.5.12-1ubuntu7_all.deb ./squid-purge_3.5.12-1ubuntu7_amd64.deb ./squidclient_3.5.12-1ubuntu7_amd64.deb

apt update / apt upgrade で野良パッケージが標準リポジトリのパッケージで上書きされないようにする

こんなふうに実行しておけば、標準リポジトリのパッケージがアップデートされたときに上書きされることがないようです。

dpkg --set-selections <<EOF
squid hold
squid-common hold
squid-purge hold
squid3 hold
EOF

# dpkg --get-selections | grep squid
squid                                           hold
squid-common                                    hold
squid-langpack                                  install
squid-purge                                     hold
squid3                                          hold

ここまで出来ていれば squid による https の透過型プロキシを Ubuntu 16.04LTS 上でも構築する準備は完了です。あとは過去記事の内容で設定するだけです。

iOS11に行ける端末、行けない端末。そしてその先は?

iOS11が発表になり、32bit CPUが切り捨てられるということなので、現時点でサポートが有効な端末のCPU種別と対応OSバージョンを表にしてみる。

f:id:pslabo:20170607162310p:plain

iOS11がサポートされないのはCPUがA6の端末。

そうすると、おそらくは次のデバイスCPUがA7だから、iOS11が最後のアップデートになるのだろう。

そしてCPUがA8系列の次のデバイスは来年のiOS12で打ち止めの可能性高し。

Windows 10 2015 LTSB を Windows 10 2016 LTSB にインプレースアップグレードしてみる

Windows 10 には CB (Current Branch), CBB (Current Branch for Business), LTSB (Long Term Servicing Branch) の3つのブランチがあるわけですが、LTSB についてインターネット上で見かける情報は少なめです。

LTSB について、自分が把握しているのはこんなところ。

  • ある時点の機能アップデートがベースのパッケージングだが、バグ修正と脆弱性対応のパッチだけが提供される
  • 現時点では 2015 LTSB と 2016 LTSB がリリースされているが、今後は2年~3年毎のリリースとなるので、2017 LTSB はリリースされない
  • サポートはリリースから10年間
  • Windows10 の新機能を必要としない、基幹業務やミッションクリティカルな用途、あるいは組み込み機器向け
  • 通常の業務にこれを用いることは想定されていない
  • Windowsストアからのアプリのインストールには対応していない
  • Enterprise Edition 向けのオプションとして提供される
  • インストールメディアは専用のものが必要

さて、2015LTSB については手元に試験環境を作っていたのですが、2016 LTSB へのアップグレードはインプレースアップグレードが可能らしいので、実際に試してみることにします。

まず、インプレースアップグレード前の状態はこうです。 f:id:pslabo:20170527152024p:plain

インストール用のDVDメディアを装着して setup.exe を実行します。 f:id:pslabo:20170527152221p:plain

そうすると、LTSB ではないブランチのインプレースアップグレードと同様の流れでインストールが進みます。此処から先のスクリーンショット4枚くらいはコメント不要でしょうからスクリーンショットだけ。 f:id:pslabo:20170527152259p:plain

f:id:pslabo:20170527152319p:plain

f:id:pslabo:20170527152331p:plain

f:id:pslabo:20170527152337p:plain

インプレースアップグレードが終わった直後の状態はコレ。確かに 1607 に変わっているけれど、なんと、ライセンス認証が無効になっています。 f:id:pslabo:20170527152358p:plain

Windows10 CB, CBB の場合はバージョン1507のライセンスが最新の機能アップデートにも適用できますが、LTSB ではそういうわけにはいかないようです。ただしこれは MSDN 向けのプロダクトキーを用いての検証なので、本番運用時では話が違うかもしれません。

というわけで、LTSB はインプレースアップグレードできる、という話を検証してみました。

なお、LTSB は CB, CBB に比べると余計なものは一切インストールされないので、スタートメニューは実に清々しい状態です。

f:id:pslabo:20170527153725p:plain

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側から繋がらないことを確実にチェックしておきます。