Anker PowerCore Fusion 5000でMacbook Pro 2016の充電を試みる(2)
先日、こんな記事を書きました。
しかしこれは簡易的な検証でしたので、もうちょっと内容を広げてみることにします。負荷が高い状況での比較とか、PowerPort+5との比較とか。
なお、0%～100%の充放電テストは行っていません。時間がかかってつらいので。
使用する機器
試験内容
- そこそこの負荷をかけた場合に、Macbook Pro 2016 13inch のバッテリはどのように減るか。さらに、Anker Power Core Fusion 5000 の内蔵バッテリから給電したら、内蔵バッテリの減るペースがどの程度緩和されるか？
- 負荷を掛けない状態でのApple純正充電器とPowerPort+5 での違いは？
- 負荷を掛けた状態でのApple純正充電器とPowerPort+5 での違いは？
負荷の掛け方
下記コマンドを同時に4本走らせておく。
cat /dev/urandom | md5 &
試験結果
Anker Power Core Fusion 5000 の内蔵バッテリからの給電によって、Macbook Pro 2016 13inch の内蔵バッテリの減りはどの程度緩和されるか？
Macbook の内蔵バッテリが減る速度は、Power Core Fusion 5000 からの給電により半減できる模様です。
負荷を掛けない状態で、Apple 標準のMacbook Pro 13inch 用USB-C充電器とAnker PowerPort +5 では充電速度がどれくらい違うか？
若干ではありますが、純正の充電器のほうが充電速度は速いです。しかし Anker PowerPort +5 でも全く問題なさげです。
そこそこの負荷を掛けた状態で、Apple 標準のMacbook Pro 13inch 用USB-C充電器と Anker PowerPort +5 では充電速度がどれくらい違うか？
こちらは純正の充電器のほうが相当速いですね。そういう意味では、Anker PowerPort +5 の給電能力は少々不足気味ではあります。ただし充電ができないわけではない。
結論？
Anker PowerCore Fusion 5000 は基本的には気休め程度と割り切って使う感じ。モバイルバッテリ機能が不要なら、Anker PowerPort +5 がやはりベターな感じですね。
Anker PowerCore Fusion 5000でMacbook Pro 2016の充電を試みる
Anker PowerCore Fusion 5000 はモバイルバッテリーとUSB充電器がニコイチになったデバイスなので、スマートフォンやタブレットの予備充電器としてはとても便利に使えます。
しかし、このデバイスのoutputは下記の仕様ですから、USB-PD 仕様のノートパソコンを充電するにはパワーが足りません。
- AC使用時 5V=2.1A (最大合計x2.1A)
- バッテリー使用時 5V=3A (最大合計3A)
そのことは承知の上で、あえて Macbook Pro 2016 の充電をトライしてみることにします。
ついでに、同じく Anker の PowerPort+ 5 の充電速度も測って比べてみることにします。
試験内容
Macbook Pro 2016 13inch のバッテリーが空の状態で Power Core Fusion 5000 のバッテリでの充電を試みた場合に、何%まで充電できるかを確かめる。
Macbook Pro 2016 13inch を利用中に Power Core Fusion 5000 と接続した場合に、Macbook 内蔵バッテリーの減りをどの程度抑えられるかを調べる。
Macbook Pro 2016 13inch のバッテリーが空の状態で Power Core Fusion 5000 のバッテリでの充電を試みた場合に、何%まで充電できるかを確かめる。
実際にやってみたところ、約3時間ほどで Power Core Fusion 5000 のバッテリは空になり、Macbook Pro 2016 13inch のバッテリーは 30%程度 まで回復していました。
なお、Anker PowerCore Fusion 5000接続時の給電状態は12Wでしたので、Macbook Pro を使用中に充電するには給電電力量が足りないことは言うまでもありません。しかしながら Macbook Pro 2016 13inch のUSB充電器を自宅またはオフィスに忘れてきたときに、AC電源が取れない場所で多少時間が掛かってもよいのでMacbook Proを使用しないときにバッテリーを回復させたい場合には使えそうです。
Macbook Pro 2016 13inch を利用中に Power Core Fusion 5000 と接続した場合に、Macbook 内蔵バッテリーの減りをどの程度抑えられるかを調べる。
こちらは Macbook Pro 2016 13inch で youtube で動画を再生しつつ、以下の状態を比較します。
- Power Core Fusion 5000 をAC接続して給電した場合に充電できるか？
- Power Core Fusion 5000 の内蔵バッテリで給電した場合に充電できるか？
- Mac book pro 2016 をバッテリ駆動した場合にバッテリがどれくらい減るか？
- PowerPort+ 5 でどれくらいのペースで充電できるか？
youtube の動画再生はいまどきのハードウェアには軽い負荷なので、給電系への負荷試験としては適切ではない可能性があります。
本当ならば、Macbook pro 2016 で仮想マシンを実行し、そこで youtube を再生するべきだったかもしれませんが、とりあえず今回はそういう測り方をしていません。これは後日測ってみます。
Power Core Fusion 5000 をAC接続して給電した場合に充電できるか？
基本的には、充電はできない、と考えて頂いだほうがよいです。しかしMacbook Pro の内蔵バッテリーが減るペースは抑えられるかもしれません。
以下は時間ごとのバッテリ残量の変化です。
Power Core Fusion 5000 の内蔵バッテリで給電した場合に充電できるか？
今回の前提条件ではバッテリは減りませんでしたので、AC接続の場合と同様にMacbook Pro の内蔵バッテリーが減るペースは軽減できるはずですが、充電は厳しいでしょうね。
Macbook Pro 2016 をバッテリ駆動した場合にバッテリがどれくらい減るか？
当然ながら、Macbook Pro を内蔵バッテリだけで駆動させるとバッテリは減ります。この試験では概ね3分ごとに1%づつ減っています。
PowerPort+ 5 でどれくらいのペースで充電できるか？
Macbook Pro の内蔵バッテリが減るペースよりは速いペースでの充電が行えています。
結論
- Macbook Pro 2016 がスリープ中なら Power Core Fusion 5000 での充電は可能です。ただし相当に時間が掛かることを覚悟の上で。
- Macbook Pro 2016 を利用中に Power Core Fusion 5000 で充電することは非常に困難なので、これを目的として購入してはダメです。ただしバッテリーの減りを軽減させる目的ならアリかもしれません。
- PowerPort+ 5 は案外使い物になります。そこそこの出力が取れるUSB充電器が欲しいなら、現時点ではおそらくベストチョイスです。
MicrosoftやOracleのライセンスに関するメモ
Microsoftのソフトウェア・ライセンスと料金はココで計算できる。
MS SQL Server 2016 のライセンスはコレを理解する必要あり。
Oracle Database のライセンスや金額の計算はコレが参考になる。
http://www.oracle.com/technetwork/jp/ondemand/database/db-new/oracle-license-abc-2704758-ja.pdf
Windows Server 2016にcygwinとapt-cygをインストールするための覚え書き
Windows Server への Bash on Windows は当面来ないので、cygwin を使うことにする
将来的には Bash on Windows が来るんでしょうけど、現時点では来ていないので、やむを得ず cygwin を使うことにします。将来的な話は以下の記事に出ていますね。
さて、cygwin を使うなら、apt-cyg は必須だと私は考えているので、これも入れてしまいます。
このときの最低必要限の手順をメモとして残します。誰かが読むことを想定していないので、手順はざっくりと。
サマリ
- cygwin のインストーラをダウンロードして実行する
- インストールを漫然と進めるのではなく、git, wget のパッケージを追加インストールしておく
- qiita の下記記事に従って apt-cyg をセットアップする
だけど引用部分のコマンドは引用を２つに分けたほうがよいので、自分用のメモとして以下に引用しなおしておく。
#!/bin/sh # cygwinターミナルを開き、リポジトリをクローンする. # 公式は transcode-open だが、野良も含めて多数の fork あり. # 下記の「参考記事」に紹介されているので、お好みのリポジトリを選べば良い. git clone https://github.com/transcode-open/apt-cyg.git cd ~/apt-cyg/ # gitの改行コード設定を、Windows環境にあわせてCRLFにしている場合は, # 改行コードLFでapt-cygを再取得する. git config core.autocrlf input rm -f apt-cyg git reset --hard # apt-cygをPATH上に置く. install apt-cyg /usr/local/bin # 国内のcygwinリポジトリを登録する. apt-cyg -m ftp://ftp.iij.ad.jp/pub/cygwin/ update
#!/bin/sh # 以後は、バージョンアップのタイミングで下記を実行する. cd ~/apt-cyg/ git pull install apt-cyg /usr/local/bin
git, wget の指定方法
それぞれ、こんな感じで。
補足
Qiita の記事は apt-cyg の取得に git を使っているので git を事前にインストールしておきます。
また、apt-cyg 自体は wget または lynx を使ってファイル取得を行います。これをインストールしていないとファイル取得に失敗した上で 0 バイトのファイルが作られててしまいます。こうなると wget or lynx を正しくインストールしても apt-cyg が正常に動作しません。このようにやらかしてしまった場合は、Desktop に作成されているキャッシュ用のディレクトリを調べて 0 バイトのファイルを片っ端から削除します。
Google Analytics のタグを貼れない環境でも Google Analytics で集計してみるテスト
Google Analytics のタグが貼れないCMSで不定期に記事を書く必要が出たのだけど、せめてページ毎のアクセス集計くらいは見える化したいと思ってなんとかしてみるテストです。
Google Analytics の Measurement Protocol を使ってみる
Measurement Protocol というのは、一言でいうとWebビーコンです。Webビーコンなのでパラメータをつけてリクエストを投げると集計が行われた上で縦横1ピクセルの画像が返されます。
だからウェブコンテンツの中に Measurement Protocol へのリンクを画像タクとして入れておけば、最低限、アクセス数の集計くらいは出せそうな感じ。
Measurement Protocol のパラメータは Hit Builder で作ることができる
Hit Builder — Google Analytics Demos & Tools
Google Analytics のトラッキングIDを新規に作ったら、Hit Builder でパラメータをカスタマイズする。
今回はとりあえずこんな内容を設定してみる。
| パラメータ名 | 値 |
|---|---|
| v | 1 |
| t | pageview |
| tid | トラッキングID |
| cid | 本来は閲覧者毎に割り振るIDだが、今回は固定値を振っている |
| ds | web |
| dl | ページのURL |
| dt | ページのタイトル |
そして Hit Builder が生成したパラメータと
www.google-analytics.com/collect? を連結したURLを作ればよい。
そしてこのURlを個別のページに で差し込んでいく。
今後はページを新規に作るたびに、dlとdtを変えたタグを差し込めば一応は集計できる。
ただしこの方法で集計した場合はページビューは集計できるけれど、個々のアクセスに紐作り情報は正しく集計されない点に注意。cid が全て同じなのだから正しく集計できるわけがない。
これについては何か解決方法がないかと考え中。
CentOS7でsquidでSSLをフィルタリングするproxyをforward proxyで設定し、さらにGoogleの個人アカウントへのアクセスを禁止する
過去に、squidで透過型プロキシを立てるネタを2件ほど書いているのですが、透過型プロキシのテストは案外めんどくさいものです。Linuxがルータとして動作するように設定した上で port forward を設定し、さらにクライアント側もそのルータを経由するように設定せねばなりません。
そこで、こういった設定をせずとも SSLの中継をテストするために、通常の forward proxy でSSLを取り扱えるように設定してみます。そしてさらにGoogleの個人アカウントを禁止する設定も作ってみます。
まずは過去記事の紹介から
[http://pslabo.hatenablog.com/entry/2017/06/11/Ubuntu_16.04_LTS%E3%81%A7_squid%E3%81%AE%E9%80%8F%E9%81%8E%E5%9E%8B%E3%83%97%E3%83%AD%E3%82%AD%E3%82%B7%E3%82%92%E7%AB%8B%E3%81%A6%E3%82%8B%E3%81%9F%E3%82%81%E3%81%AB_squid_%E3%82%92%E3%83%AA%E3%83%93:embed:cite]
今回の環境
いまさらCentOS6で環境を作るのもイマイチですから、今回はCentOS7でやってみることにします。 なお、CentOS7のsquidは–with-opensslつきでビルドされていますので、今回はこれをそのまま使います。
設定上のポイント
- SELinux を使用している場合は「都度生成されるサーバ証明書のディレクトリに対して squid がアクセスできるように設定変更する」ことをお忘れなく。これを忘れると意味不明なエラーが出てハマることになります。
- forward proxy の場合は ssl_bump の設定が client-first となります。（透過型の場合は server-first です）
- https_port は設定しません。今回のケースでは、http_port ですべてのリクエストを取り扱います。
- http_port の設定には intercept の設定を書きません。透過型ではなく forward proxy ですから。
実際の作業
CentOS7 のインストール
CentOS-7-x86_64-Minimal-1611.iso でインストールします。
squid のインストール
とりあえずはこれだけでOK。
sudo yum install squid
オレオレCAの作成
CentOS7 の場合は openssl をインストールすると /etc/pki/CA/private というディレクトリがあるので、ここにオレオレCAをセットアップするのが妥当な気がします。そこで今回は以下のように作業しています。（過去記事との違いは cd するディレクトリが違うことだけです）
cd /etc/pki/CA/private # オレオレCA作成。 openssl req -new -newkey rsa:2048 -sha256 -days 3650 -nodes -x509 -keyout oreoreCA.pem -out oreoreCA.pem # オレオレCAの証明書作成。これは利用者のブラウザにインストールするものです。 openssl x509 -in oreoreCA.pem -outform DER -out oreoreCA.der
ssl_crtd の設定
これは以前の記事と基本的に同じですが、ここで作成する /var/lib/ssl_db には SELinux での権限割り当てが行われていないので、SELinux が有効な場合はsquid からのアクセスが失敗します。
/usr/lib64/squid/ssl_crtd -c -s /var/lib/ssl_db chown -R squid /var/lib/ssl_db
よって SELinux が有効な場合は以下のコマンド実行を忘れないようにしてください。
chcon -R -t squid_cache_t /var/lib/ssl_db
これを忘れていると /var/log/squid/cache.log あたりにこういうメッセージが出てsquidが異常終了するという罰ゲームに遭遇します。このエラーメッセージを見ると ssl_crtd の初期化ができていないように読めますが、実はそうではなく、権限がないからアクセスできていない状態であることを、初期化できていないと判定しているわけです。
(ssl_crtd): Uninitialized SSL certificate database directory: /var/squid/ssl_db. To initialize, run "ssl_crtd -c -s /var/squid/ssl_db". (ssl_crtd): Uninitialized SSL certificate database directory: /var/squid/ssl_db. To initialize, run "ssl_crtd -c -s /var/squid/ssl_db". (ssl_crtd): Uninitialized SSL certificate database directory: /var/squid/ssl_db. To initialize, run "ssl_crtd -c -s /var/squid/ssl_db". (ssl_crtd): Uninitialized SSL certificate database directory: /var/squid/ssl_db. To initialize, run "ssl_crtd -c -s /var/squid/ssl_db". (ssl_crtd): Uninitialized SSL certificate database directory: /var/squid/ssl_db. To initialize, run "ssl_crtd -c -s /var/squid/ssl_db".
squid を設定する
デフォルトの squid.conf.default との差分形式を掲示しておきます。ここで記述している内容は過去記事に書いてますので、不明点があればそちらをご参照いただきたく。また、一部の設定では証明書の検証エラーをスルーしていますので、そのまま用いるとセキュリティ上の問題が生じることにご注意ください。これはあくまで基本的な動作検証を目的に作成した設定です。
[root@localhost squid]# diff -u /etc/squid/squid.conf.default /etc/squid/squid.conf --- /etc/squid/squid.conf.default 2017-04-13 04:43:17.000000000 +0900 +++ /etc/squid/squid.conf 2017-06-18 11:23:11.852000000 +0900 @@ -2,6 +2,21 @@ # Recommended minimum configuration: # +visible_hostname [適当なサーバ名] + +http_port 3128 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/pki/CA/private/oreoreCA.pem + +always_direct allow all +ssl_bump client-first all + +sslproxy_cert_error allow all +sslproxy_flags DONT_VERIFY_PEER + +cache_dir aufs /var/spool/squid 100 16 256 + +acl to_google dstdomain .google.com +request_header_add X-GoogApps-Allowed-Domains [自社ドメイン] to_google + # Example rule allowing access from your local networks. # Adapt to list your (internal) IP networks from where browsing # should be allowed @@ -56,7 +71,7 @@ http_access deny all # Squid normally listens to port 3128 -http_port 3128 +#http_port 3128 # Uncomment and adjust the following to add a disk cache directory. #cache_dir ufs /var/spool/squid 100 16 256
クライアント側の設定
oreoreCA.der をクライアント側のブラウザにインストールしてください。これを実施していない場合は、すべてのSSL/TLSな接続で証明書エラーが出てしまいます。
また、今回の設定は forward proxy ですから、クライアント側でプロキシサーバを明示的に設定しておく必要があります。
上記の設定で、自分の環境ではGoogleへの個人アカウントでの利用（メールとかGoogleドライブ）が禁止できることを確認できています。ただし、Google へのログイン自体は個人アカウントでも通ってしまいますので、検証の際は gmail 等の個別のサービスにアクセスしてみてください。
そして、forward proxy が意図通りに動くようになってから、transparent proxy の動作を確認するとよいでしょう。
