とりあえずのメモ。とは言っても、すでに誰かがやっていることの後追いでしか無いわけだが。
ポイントは、無料枠のインスタンスではビルド時のメモリが足らんので、スワップを確保せねばならんことだろうか。
リファレンスの情報は、たとえばこんなあたり。
ただしDockerで立てるのは内部構造がわかりづらい。そういう意味では、こちらの記事の方が参考になるかも。 https://lithium03.info/mastodon/index.html
自分がやってみた場合の手順は別途ログをまとめる予定。とりあえずはDockerで平文のサーバが稼働するところまでは来ている。あとはSSL/TLSの処理をLBに載せるのか、それとも自力で扱うか。自力で扱うにしても、Dockferの中のWebサーバでやるのか、それともDockerの外側にreverse proxyを立てるのか、など、方法はいろいろ。
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に再度アクセスしてみる。
とりあえずサービスは止まったようだ。これで安心してよいのかどうかはイマイチ分からんけど。
とりあえずのメモ。とは言っても、すでに誰かがやっていることの後追いでしか無いわけだが。
ポイントは、無料枠のインスタンスではビルド時のメモリが足らんので、スワップを確保せねばならんことだろうか。
リファレンスの情報は、たとえばこんなあたり。
ただしDockerで立てるのは内部構造がわかりづらい。そういう意味では、こちらの記事の方が参考になるかも。 https://lithium03.info/mastodon/index.html
自分がやってみた場合の手順は別途ログをまとめる予定。とりあえずはDockerで平文のサーバが稼働するところまでは来ている。あとはSSL/TLSの処理をLBに載せるのか、それとも自力で扱うか。自力で扱うにしても、Dockferの中のWebサーバでやるのか、それともDockerの外側にreverse proxyを立てるのか、など、方法はいろいろ。
マルチプラットフォーム向けの開発環境では、RAD Studio/Delphi/C++BuilderでもXamarinでも、ディスク使用量が大きいことが悩ましいです。
たとえば、手元の環境でRAD Studio をフルフルにインストールした手元の環境では、ディスクをコレくらい消費します。
これはつらい。
そこで、NTFS圧縮をピンポイントで設定して、ディスクの空きを増やすことを試みてみます。
実施後の状態はこんな感じ。おお、なんと空き領域が20GB以上も増えました。
何がどのように変わっているかというと……NTFS圧縮を適用する前はこんな状態。
NTFS圧縮をかけたらこんな状態。
安直な方法は 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圧縮はデータベースのデータ保存領域には適用しないほうがよいです。データベースが壊れるという事例がググるといろいろ出てきます。
また、ビルドの速度は落ちるはずですが、厳密には検証していません。
ここらへんのリスクを自己責任として許容できるなら、試してみるのもよいかと。
とある処理でディスクの使用量がどのように変化するかを記録する必要が出てきたので、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 83199504OK、こんなもんですね。あとは適当なファイルにリダイレクトすればよい。tee [ファイル名] とすれば、ファイルに保存しつつ表示してくれるので、さらによし。
WannaCrypt向けのパッチがWindowsXP向けにもリリースされたということなので、ソフトウェアの旧バージョンの動作確認用に仮想マシンで作っておいたWindowsXPに適用しておくことにする。
なお、このXPはVMware WorkstationでNATのネットワークに接続しているので、LANの他のノードからのパケットは基本的に届かない構成です。また、古いソフトウェアの検証のみに使っており、普段はシャットダウンした状態で保存している環境です。
では、まずは日本語の一次情報をチェック！
なるほど、Windows Updateカタログ Microsoft Update Catalogで配布している、と。ならば実際にアクセスしてみよう。
Windows XPのInternet Explorer8では表示できなかった！
ではWindows Updateを試してみると……
そもそもWindowsUpdateにもつながらんやんけ！ 今は Windows Updateも封じられているんですかねえ。それともたまたま？
というわけで、別のマシンでWindows Updateカタログにアクセスしてみよう。
これやな。
ダウンロードを押すと、こんなページが出る。
これをダウンロードして実行すればよいわけですね。
というわけで、一応対策完了。
以前にこういう記事を書いていたのですが、このときは WPA2-EAP向けのパッケージが見当たらなかったので、一旦はLEDEの導入を断念しています。
まあしかし、LEDEが動くなら、出張の際にホテルのLANにつける携帯用WiFiアクセスポイントに仕立ててみるのはアリなので、あらためて設定してみることにします。
使うのは当然ながらRaspberry Pi3ですので、本体やmicroSDなどの必要な部材は揃えておいた上で作業にとりかかります。
なお、Raspberry Pi Zero W でもイケるとは思いますけど、手元に機材が無いので未検証です。
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をRaspberryPi3に装着して起動させるだけです。なお、RaspberryPiのNICは設定用のPCに接続しておいてください。既存のLANに接続してはダメです。LEDEの初期状態では、IPaddress = 192.168.1.1 かつ DHCPサーバが有効な状態となっていますので、既存のLANに接続すると問題を引き起こします。したがって、設定用のPCと直結しておく必要があるのです。
LEDEへのブラウザからのログインは http://192.168.1.1/にアクセスします。
するとインストール直後の状態ではパスワードなしでログインできるようです。
そこでまずはパスワードを設定することにしましょう。ログイン後の画面で System → Administraton を選択します。
するとパスワード設定用の画面が出ているかと思いますので、ここでパスワードを入力します。
画面の最下部の Save & Apply をクリックするとパスワードが設定されます。
今回の設定では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をクリックすれば無線が有効になりますので、実際に接続できることを確認します。
WiFI側から接続できるようになったら、NICをWAN向けの設定に変更します。
まずは Network → Interfaces を選びます。
初期状態では LAN だけが存在していますので、Add New Interface を選択します。
インタフェース名は wan で DHCP client にしておきます。また、following interface として eth0 を選択しておきます。
なお、インタフェース lan には eth0 が含まれていますので、lan の設定から eth0 を外しておきます。
さらに LAN 側のIPアドレスをデフォルトの192.168.1.1 から別のネットワークアドレスに変えておきます。たとえばフレッツ光のレンタルルータは内部アドレスが192.168.1.0/24 と LEDE のデフォルトのアドレスと同じネットワークアドレスを使っています。これでは通信が正しく行えませんので、全く別のアドレスに変えます。
ここでは 192.168.4.1 に変更してみました。新しい設定は Save & Apply を押したらすぐに有効になります。
英語が不得意な方にとって、管理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側に不要なポートが開いていないかどうかを念のために確かめます。
まず、OpenWRT/LEDE では sshサーバ機能が生きていますので、これは LAN 側だけに制限しておきます。
さらに、WAN側の HTTP が開いていないことも念のために確かめまsす。WAN側のIPアドレスはインタフェース設定から確認できますので、WAN側に繋いだ別の機器から、このアドレスの 80/TCPにブラウザで接続できないことを確認してください。
sshと http が閉じていたら、基本的には安全と考えてよいはずです。なお、ここまでの設定では、LEDE は以下のようなポートで daemonが動いた状態です。
より厳密に確認したい場合は、これらのポートにWAN側から繋がらないことを確実にチェックしておきます。
iPad3は新しいiPadへの買い替えに伴って下取りに出したのですが、他にもiPad2がありまして、こちらも処分したいのでアップル提携の BrightStar のサービスに下取りに出してみることにしました。
このサービスは自宅にいながら下取りに出せるので便利なようにも思えますが、案外使いづらいので、自分の感想をメモとして残しておきます。
一般的に中古の買取では運転免許証などの本人確認書類が必要となります。しかしアップルが提携するブライトスターの場合は返送キットが送付先限定で届きます。この時点で中古売買に伴う本人確認ができているとみなせるためか、この手の本人確認書類は不要です。なお、サイトには送付キットの受け取りのときに本人確認が必要、と書かれていますが、受け取りの際に本人確認が求められることはありませんでした。デバイスが WiFi only の iPad2だったためですかねえ？？
発送用のキットは単に宅配便で送られてくるだけです。キットの中にiPadを入れて発送するには集荷の手配が別途必要になります。え、普通でしょ？ と思いたくなりますが、PC の修理では「宅配業者が回収用の梱包材を持参して引き取りにくる」というのが自分が経験した範囲では、多分普通のオペレーションです。
例えばMacBookやVAIOを過去に修理に出したときは、クロネコヤマトの担当者が回収用の箱を持って指定した場所までやってきます。そしてその場で梱包して回収して持っていくと言う流れでした。つまり運送業者とのやりとりは1回だけです。このときに送り状になんらかの記入を行う必要すら無いのです。
しかし今回のiPad下取りでは、佐川運輸が発送用の箱キットを届けにきました。ここで回収されるわけではないのです。このキットにiPadを入れて送り状を記入して集荷を手配せねばなりません。なんと無駄なことでしょうか。下取りに出したい側からみれば、受け取りと集荷の2回の手配を行わねばなりません。時間の無駄です。
そして単身者の場合は平日の日中に返送キットを受け取ることは困難であり、場合によっては夜間でも受け取りが難しいかもしれません。そうすると返送キットは週末に受け取る前提で手配せねばならないのですが、手配の際に着日を指定できません。だから、週の前半に申し込みをかけておき、週末に確実に受け取れるような段取りを考えねばなりません。
クロネコヤマトの場合は取次店が多いのでコンビニに持ち込めば発送できます。しかし佐川運輸の場合は取次店が少ないので持ち込みでの発送手配が容易ではありません。首都圏の場合は集配所がそれなりに配置されていますけれど、繁華街の集配所を除けば土日は閉まっているケースが多々あります。したがって、土日にキットを受け取った場合は、そのキットの発送のために集荷を手配するか、または開いている取次店を探して持ち込むことになります。私の場合はキットを土曜日午前中に受け取ったのですが、土曜日午後には外出の予定がありまして、外出先の近所の集配所に持ち込むことにしてみました。
そしたら、持ち込んだ集配所はドアや鍵が開けっ放しのままで不在の状態……。10分ほど待ったら佐川のお兄さんが戻ってこられましたが、ランチタイムだったので食事に出ていたんですかねえ。自分が持ち込んだ集配所以外でもこういう状況だったりするとは思いたくないけれど、防犯上の問題もあるし、そもそも集配所に持ち込むのは時間のロスを少なくしたいのが目的なのに、逆に時間をロスするとか意味不明。
まあそんなわけで、サービスとしては悪くはないけれど、使い勝手に難がある、というのが率直な感想かも。
Windows 10 には CB (Current Branch), CBB (Current Branch for Business), LTSB (Long Term Servicing Branch) の３つのブランチがあるわけですが、LTSB についてインターネット上で見かける情報は少なめです。
LTSB について、自分が把握しているのはこんなところ。
さて、2015LTSB については手元に試験環境を作っていたのですが、2016 LTSB へのアップグレードはインプレースアップグレードが可能らしいので、実際に試してみることにします。
まず、インプレースアップグレード前の状態はこうです。
インストール用のDVDメディアを装着して setup.exe を実行します。
そうすると、LTSB ではないブランチのインプレースアップグレードと同様の流れでインストールが進みます。此処から先のスクリーンショット４枚くらいはコメント不要でしょうからスクリーンショットだけ。
インプレースアップグレードが終わった直後の状態はコレ。確かに 1607 に変わっているけれど、なんと、ライセンス認証が無効になっています。
Windows10 CB, CBB の場合はバージョン1507のライセンスが最新の機能アップデートにも適用できますが、LTSB ではそういうわけにはいかないようです。ただしこれは MSDN向けのプロダクトキーを用いての検証なので、本番運用時では話が違うかもしれません。
というわけで、LTSB はインプレースアップグレードできる、という話を検証してみました。
なお、LTSB は CB, CBB に比べると余計なものは一切インストールされないので、スタートメニューは実に清々しい状態です。
以前に、CentOS上のSquidでSSLをインターセプトしてフィルタリングする透過型プロキシを立てて、さらに Googleの個人アカウント利用を禁止する設定を紹介しました。
さて、同じことを Ubuntu 16.04 LTS で行おうとしてみたのですが、標準のリポジトリから配布されているバイナリでは、これは行えないようでした。その理由は下記の理由によります。
そこで、 Ubuntu 16.04 LTS で同じ設定を作るために、squidのリビルドを行ってみることにしました。
概ね、以下の7ステップです。
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に２行足す --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
こんなふうに実行しておけば、標準リポジトリのパッケージがアップデートされたときに上書きされることがないようです。
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 上でも構築する準備は完了です。あとは過去記事の内容で設定するだけです。
過去にこんな記事を書いていたのですが……
最終的に、こんな製品を買ってみました。
実際に試した範囲での感想はこんなところ
もっとも重要視したのがコレ。１つのUSB-CでHDMIとVGAが両方取れたとしてもアダプタ自体が大きいのは困ります。今回購入したのは、HDMIとVGAを２つ横並びに並べた幅しかないので、結構小さいです。
4Kなモニタがないので実際に4Kが出るかどうかは知らないのですが、4Kだそうです。
自宅には U2913WM があるのですが、これは 21:9 (2560x1080) という変則的な解像度です。しかし VGA接続、HDMI接続ともに 2560x1080 で表示させることができました。
HDMI& VGAの２本刺しは同じ画像を両方に出力と聞いていたのでU2913WM を PinPモードにして試してみたら、2560x1080 の同じ画像が両方に出力されました。
というわけで、この金額でVGA&HDMIが取れるのは、まあアリかなあと思っております。強いて言えば、USB-C端子の給電端子が付いていたら、Pro ではない Macbookで重宝しただろうなあ、というところでしょうか。
そういう意味では、USB-C が２系統以上付いている Macbook Pro向けならば、これは悪くない選択肢だと思います。
完全に私的なメモ。随時かつ不定期に更新。
操作メニューを日本語にするために導入
入れてみたけど、入れない状態との違いが未だよく分からない。
画像をクリップボードから ctrl+v でコピペしたいのです。設定は file in folder にしてみた。
入れてみたけど、入れない状態との違いがイマイチわからない。
markdown-scroll-sync は編集画面とプレビュー画面のスクロールの同期が動かなかったので、markdown-preview-enhanced に変更
過去に、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
http://pslabo.hatenablog.com/entry/20150703/p1
いまさらCentOS6で環境を作るのもイマイチですから、今回はCentOS7でやってみることにします。 なお、CentOS7のsquidは–with-opensslつきでビルドされていますので、今回はこれをそのまま使います。
CentOS-7-x86_64-Minimal-1611.iso でインストールします。
とりあえずはこれだけでOK。
sudo yum install squid
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
これは以前の記事と基本的に同じですが、ここで作成する /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.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 の動作を確認するとよいでしょう。
Google Analyticsのタグが貼れないCMSで不定期に記事を書く必要が出たのだけど、せめてページ毎のアクセス集計くらいは見える化したいと思ってなんとかして見るテストです。
Measurement Protocol というのは、一言でいうとWebビーコンです。
ウェブコンテンツの中に Measurement Protocol へのリンクを として入れておけば、最低限、アクセス数の集計くらいは出せそうな感じ。
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 が全て同じなのだから正しく集計できるわけがない。
これについては何か解決方法がないかと考え中。
将来的には Bash on Windowsが来るんでしょうけど、現時点では来そうにないので、やむを得ず cygwinを使うことにします。
cygwinを使うなら、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
Qiita の記事は apt-cyg の取得に git を使っているので git を事前にインストールしておきます。
また、apt-cyg 自体は wgetまたは lynxを使ってファイル取得を行います。これをインストールしていないとファイル取得に失敗した上で 0 バイトのファイルをつくてしまいます。こうなると wget or lynxを正しくインストールしても apt-cyg が正常に動作しません。このようにやらかしてしまった場合は、Desktop に作成されているキャッシュ用のディレクトリを調べて 0 バイトのファイルを片っ端から削除します。
Microsoftのソフトウェア・ライセンスと料金はココで計算できる。
MS SQL Server 2016 のライセンスはコレを理解する必要あり。
Oracle Database のライセンスや金額の計算はコレが参考になる。
http://www.oracle.com/technetwork/jp/ondemand/database/db-new/oracle-license-abc-2704758-ja.pdf
Anker PowerCore Fusion 5000 はモバイルバッテリーとUSB充電器がニコイチになったデバイスなので、スマートフォンやタブレットの予備充電器としてはとても便利に使えます。
しかし、このデバイスのoutputは下記の仕様ですから、USB-PD 仕様のノートパソコンを充電するにはパワーが足りません。
そのことは承知の上で、あえて Macbook Pro 2016 の充電をトライしてみることにします。
ついでに、同じく Anker の PowerPort+ 5 の充電速度も測って比べてみることにします。
Macbook Pro 2016 13inch のバッテリーが空の状態で Power Core Fusion 5000 のバッテリでの充電を試みた場合に、何%まで充電できるかを確かめる。
Macbook Pro 2016 13inch を利用中に Power Core Fusion 5000 と接続した場合に、Macbook内蔵バッテリーの減りをどの程度抑えられるかを調べる。
実際にやってみたところ、約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 で youtubeで動画を再生しつつ、以下の状態を比較します。
youtubeの動画再生はいまどきのハードウェアには軽い負荷なので、給電系への負荷試験としては適切ではない可能性があります。
本当ならば、Macbook pro 2016 で仮想マシンを実行し、そこで youtubeを再生するべきだったかもしれませんが、とりあえず今回はそういう測り方をしていません。これは後日測ってみます。
基本的には、充電はできない、と考えて頂いだほうがよいです。しかしMacbook Proの内蔵バッテリーが減るペースは抑えられるかもしれません。
以下は時間ごとのバッテリ残量の変化です。
今回の前提条件ではバッテリは減りませんでしたので、AC接続の場合と同様にMacbook Proの内蔵バッテリーが減るペースは軽減できるはずですが、充電は厳しいでしょうね。
当然ながら、Macbook Proを内蔵バッテリだけで駆動させるとバッテリは減ります。この試験では概ね3分ごとに1%づつ減っています。
Macbook Proの内蔵バッテリが減るペースよりは速いペースでの充電が行えています。
先日、こんな記事を書きました。
しかしこれは簡易的な検証でしたので、もうちょっと内容を広げてみることにします。負荷が高い状況での比較とか、PowerPort+5との比較とか。
下記コマンドを同時に4本走らせておく。
cat /dev/urandom | md5 &
Macbookの内蔵バッテリが減る速度は、Power Core Fusion 5000 からの給電により半減できる模様です。
若干ではありますが、純正の充電器のほうが充電速度は速いです。しかし Anker PowerPort +5 でも全く問題なさげです。
こちらは純正の充電器のほうが相当速いですね。そういう意味では、Anker PowerPort +5 の給電能力は少々不足気味ではあります。ただし充電ができないわけではない。
Anker PowerCore Fusion 5000 は基本的には気休め程度と割り切って使う感じ。モバイルバッテリ機能が不要なら、Anker PowerPort +5 がやはりベターな感じですね。
