uso8000k.net

GitHub的な何かを使うようにしました。

• 近頃サーバのStruct&Destroyの機会が多い
• 機密を含まぬ形で設定ファイルを一か所で管理して、共通化したい
  • 独自の情報を省いて他に設定を置く事で、安全性の向上とテンプレート化が進む
  • 都度、自管理の類似のサーバから設定ファイルを持ってくるのに疲れた
• ある程度何処からでもアクセスできる環境に置いておきたい
• 作った設定ファイルを使用するDevOps的なもののレシピ管理もしておきたい

そんな欲求ばかりを挙げてたら、オンラインのリポジトリ管理ツールを本格的に使おうかと思いまして。設定ファイルの差分程度でRCSの代わりにGitを使ってはいましてたがGitHub的なものに置くまでは・・・って感じでした。ので、今回導入に踏み切りました。とりあえず BitBucketに。非公開リポジトリを標準で使えるのは良いですね・・・いや、GitHubの場合非公開リポジトリが有料だからどうこうって話ではありませんが、さっくり使うのに標準でサポートしているのはとても助かります。月々の費用もですが支払情報とか登録と管理するのも億劫でして。

あとは触った感じ操作インターフェイスであったり、ログイン情報をOAuth使用サービスに結びつけたりと便利であったり。あとは個人プロフィールで自アイコンが設定できることかも重要？です。自分はプログラマではないので使い方が変ではあるが、一気に楽になりました。・・・もっと早く動けばよかった。

参考: BitBucketのいいところ - methaneのブログ

$sudo mount -t davfs  https://www.box.net/dav /mnt/davfs
/sbin/mount.davfs: Mounting failed.
404 Not Found

Σ (ﾟДﾟ）

追記1: なんとなく機能を確認したところ、文書は無いがFTPサーバ接続サービスがあるらしく接続先がftp.box.netであることを確認。ひょっとしてとdav.box.netでアクセスをしたらベーシック認証画面が出たので行けるかなと思った・・・がエラー(302)。諦めましょう。いつでもデータを退避できる場所って確保してたので、わりと余裕がなくなりました。

追記2: dav.box.net で302転送エラー。ブラウザでアクセスするとこれまでは自コンテンツ直で表示されていたが、変更後は /dav のサブディレクトリ配下へ移動している。試しに "https://dav.box.net/dav" にてアクセスを試みる。成功。あと3年は戦える。

急ぎメールをお送りします、っと (ｶﾀｶﾀ、ｯﾀｰﾝ

Pstfix/smtpd[11577]: 
NOQUEUE: reject: 
RCPT from xxx.ocn.ne.jp[www.xxx.yyy.zzz]: 
554 5.7.1: 
Relay access denied; from= to= proto=ESMTP helo=<[aaa.bbb.ccc.ddd]>

ファッ！？いつの間にか送信できなくなっていました。いつもローカル配送ばかりでしたので・・・どうやらRecipientアドレスが拒否されたから配送できていないっぽいのですが、SMTP認証を通せば配送できるようには対応していた・・・筈。しかしできなくなっていました。調べてみると設定は問題なく、このような事案 ([SOLVED] relay access denied after postfix 2.10 upgrade) が発生していた模様。微妙に仕様が変わったのだろうか。

変更前：

smtpd_recipient_restrictions = 
permit_mynetworks,
permit_sasl_authenticated,
(略)
reject_unauth_destination

変更後:

smtpd_relay_restrictions = 
permit_mynetworks,
permit_sasl_authenticated,
(略)
reject_unauth_destination

あぁ、Hardenedプロファイルを使用していたため遅かったですが、4月位にアップデートしましたね・・・2.10に。その影響で、どうやらRCPT TO をチェックするsmtpd_recipient_restructions が smtpd_relay_restructions に置き換わった模様。唐突でした…大方、パッケージ更新した時のメッセージ見逃したのでしょう。

本日のApacheのログにて

::1 - - [11/Apr/2013--:--:-- +0900] \
"GET /static/rum/50kb-20111128.html?cdn=21&t=1365653073612 \
HTTP/1.1" 404 227 "http://twitpic.com/ci8dc3" "Mozilla/5.0 (略)"

Proxyを通してTwitpic見たら、自身のApacheへリクエストを送っていたでござる。どういうことだってばよ。iframe中の何かのミスとは思うが・・・なんとも気持ちが悪いもので。

やるべきことがある日ほどコンフィグ作業が捗る。最近重宝しているSSL-VPNからのSquidによるProxy利用。AndroidでもiOSでもOpenVPNに対応したので、Squid周りももう少し整頓してみようかな、と思い、安全なSquid利用を出来るようにSquidの通信をClamAVにバイパスしてみる。

流儀はいろいろあるが、一発目に見たサイト「プロキシサーバーでウィルスチェック(Squid+SquidClamAV+ClamAV)」(iptablesの設定ではお世話になりました...) ではsquid.confからurlrewrite_programからsquidclamavを呼び出して実行している模様。なるほど。SquidとClamavは入っているのででは必要なSquidclamavを入れましょう。

# emerge -pv squidclamav
 [ebuild   R    ] net-proxy/c-icap-0.2.2  USE="berkdb ipv6 -ldap" 0 kB
 [ebuild   R    ] net-proxy/squidclamav-6.8  0 kB

# emerge squidclamav
...
Compiling...
...
 * To enable the service, you should add this to your c-icap.conf file:
 *
 *     Service clamav squidclamav.so
 *
 * And then this to squid.conf (for a local ICAP server):
 *
 *     icap_enable on
 *
 *     # not strictly needed, but useful for special access
 *     icap_send_client_ip on
 *     icap_send_client_username on
 *
 *     icap_service clamav respmod_precache bypass=0 icap://localhost:1344/clamav
 *     adaptation_access clamav allow all

なるほど、Gentoo的にはsquidclamavを使うにはc-icapを使いましょう、と。郷に入れば郷に従えということで警告の通りに設定するべきか。ICAPはInternet Content Adaptation Protocolとの事で・・・プロキシのフィルタ機能拡張用のプロトコルとの事です。どうにもフィルタ機能の一部が死んだ時にプロキシ機能全体が止まるのではなく、ある程度は無視してくれるらしい。Squid3系列以降から標準らしいし、汎用的で拡張性も良さそうなのでこの方法で決定。自分の環境はローカルからしか使えない閉じたSquid、閉じたICAPサーバ、そしてClamAV。これらをつなぐために以下の設定を行いました・・・というか、インストール後のメッセージ殆どそのままです。

# vim /etc/c-icap/icap.conf
...
Service clamav squidclamav.so #追記

## ACL & Control
acl localnet  src 173.230.147.180/255.255.255.255 192.168.x.0/255.255.255.0 
acl localnet6 src fe80::f03c:91ff:fe96:3cfd 2001:470:1f04:1a92::2
acl localhost src 127.0.0.1/255.255.255.255 ::1
acl all src 0.0.0.0/0.0.0.0 ::

client_access allow localnet
client_access allow localnet6
client_access allow localhost
client_access deny all

# vim /etc/squidclamav.conf
...
clamd_local /var/run/clamav/clamd.sock         # ClamAVのローカルソケット指定
redirect    http://ika.uso8000k.net/error.html # 検知時の転送先

# vim /etc/squidi/squid.conf
...
# Squid-Clamav
icap_enable on
icap_send_client_ip on
icap_send_client_username on

icap_client_username_header X-Authenticated-User
icap_service clamav respmod_precache bypass=0 icap://localhost:1344/clamav

adaptation_access clamav allow all

# /etc/init.d/c-icap restart
# /etc/init.d/squid  restart

にて、概ね設定完了。正常に起動してエラーもなく問題なし・・・に思われたがテストウィルスのEICARをそのままダウンロードしてしまう。何故だ。ログを見るとSquidで受け付けて正常にWebを見ることができているが一向にICAPに渡らない。ICAP設定はちゃんと書いているしエラーも出ていない・・・と思ってSquidのUSEフラグを確認したら USE=”icap-client” が必要だったらしい。Squidの再コンパイルしたら動きました。ところで、この挙動はICAP非対応の状態でSquidがICAP用設定を読めてしまっていた問題なのだろうか？それともSquidで読んでICAP関連でエラーが出ていたので、そのまま処理をSquidのみで動いていたのだろうか。後者だとわりと仕様の通りに動いていてすっきりします。図らずも一部の機能不全からの共倒れを確認できたことになります。

・・・マシン性能が一杯一杯なので少し大きめのZIPファイル落とすと辛いかも。

なんにしても
∩( ・ω・)∩

だまして利用させる“禁じ手”に歯止めを、“プライバシーエンジニア”育成も

個人個人の無自覚・曖昧な裁量で公開される情報や、法的に個人情報と扱われないという理由での個人の活動（特性情報）を自由に収集し取り扱ってしまう昨今のWebサービスの現状。提供側、受け側、両者の同意が取れている場合には収集する事は問題無いが、その同意が、オプトアウト型であったり、利用規約の長文に紛れさせて取り付け、情報を自由に扱ってしまう現状。こうして本人の(Y/N)を取らず静かに収集し「ビッグデータ」なりの言葉にて仕事の定石として扱う風潮であるモラル指摘。そういう対応が平然と行われていることが倫理的に的に如何なのさ？、と。

高木先生の意見は「法律」を知るべき立場となっている「情報を取り扱う企業」、そして高橋氏の意見は「情報を取り扱う企業」としてのあるべき組織の形。個人的に感じるのは、トップダウン型の仕事が多い世の中的には技術として疑問点を挙げても、無いことにされるだけであり、まずは上層の理解なり、仕事の組み方なりの会社体制の整頓が必要なのかなぁ、と。

ところで、この手の既存サービスへのシビアな意見に対して必ず言われるのが「イノベーションの阻害」の類の言葉であるが、流石十分経験されている方々かしっかり釘を打ち、意見をしている辺り凄い会議だったと思う。是非とも拝聴したかったです。

一昨日の投稿後の翌日AppleからiOS6.0.1が発表されたり。ナイスタイミング、ナイスタイミングです。ということで昨日の朝アップデート。

・・・直りました。

但し、 このアップデートにより、以下のようなことが改善および解決されます：

• ソフトウェア・アップデートをワイヤレスで iPhone 5 にインストールできない問題を解決します
• キーボード上に横線が表示される問題を解決します
• カメラフラッシュが消えなくなる問題を解決します
• 暗号化された WPA2 Wi-Fi ネットワークに接続しているときの、iPhone 5 および iPod touch（第 5 世代）の信頼性が向上します
• iPhone でモバイルデータ通信ネットワークを使用できなくなる問題を解決します
• iTunes Match 用に"モバイルデータ通信"スイッチを統合しました
• パスコードロックを設定しているのに、ロック画面から Passbook パスの詳細にアクセスできてしまう問題を解決します
• Exchange 会議に影響する問題を解決します
• このアップデートのセキュリティ内容については、以下の Web サイトを参照してください：http://support.apple.com/kb/HT1222?viewlocale=ja_JP

いずれかの不具合で問題が出ていただろうか・・・。まぁ、とりあえずストレス無く音楽再生出きるようになったのでありがたや、ありがたや。

20130306追記: 直ってねえ！

おのれ。iOS6になってからこういったことがよく起ります。手動同期と複数PC、複数デバイス入れ替えしてるせいかも知れないのだけれど、どうにも音楽ファイルが消えます・・・これで2度目。 さて、このような私自身の特殊な問題はともかく、iOS6になってから使い勝手があまり好ましくなくなって困っています。

昨今、Apple謹製の地図アプリが微妙等色々お話は挙がりますが、個人的かつ具体的にはiPhone/iPodTouchの「ミュージック」のシャッフル動作がiOS5から変わって困っています。ランダムではなくシャッフルですので再生済みの曲情報を管理する必要がありますが、再生初めの予め作られた曲順リストが作られていてメモリ解放後もそれをずっと保持している事、そして作成したリスト中で肝心な何曲再生しているかの情報が消えてしまう事が起っているように感じます。必要に応じては再生開始までリストを遡る事もありますのでリストをもち続けるのは消えてしまうiOS5と比べて正しい動作でもあり問題が無いとは考えられますが、再生済み情報が消えてしまうのは流石にどうかと思うのです。

とりあえずシャッフル設定を有効にしてから再生開始し、暫くを堪能します。 さて、音楽を他にもアプリを適度に立ち上げてメモリを使い切る/GC的な動作をするように長時間放置したり、メモリ開放アプリを使って手動で開放を行いますと、必ずシャッフル再生開始と全く同じ曲順で再生されるのです。曲を流して止めて、放置して、また再生するの繰り返しが主な使い方なので、何度も同じ曲の順番になってしまったり。ちゃんとシャッフルするには、またシャッフルを有効にするしかない・・・iOS5ではこんな事なかったのに。音楽プレイヤーとしては一気に欠陥品になった気がします。早くアップデートしませんかね・・・

はい・・・はい・・・すみません・・・

ところで、エラーメッセージで顔文字を出されるこの屈辱。許されざる。

最近、私的作業の合間合間にバックグラウンドでアニメを流しています。バンダイチャンネル様様ですね。で、つい先日「無責任艦長タイラー」を見終わりました。無責任に自分がやりたいことをやりつづけて良い方向に働く豪運な主人公のお話。そしてアニメだからこそ許されるひたすらお馬鹿でご都合主義な内容です。しかし、そんな劇中の後半、自分を含めた周りが出世街道に乗り状況に流される事となります。その時、自分のしたいことを思うように出来なくなったのに気づき放った「しっかりしてないと人生に逆襲されちゃうよ？」という言葉が、全編ニヤニヤして見ているこっちにも刺さりました。実生活から日々カリカリと何かのために動いているのは仕方が無いのですが・・・この状態が後で逆襲されるってのは、薄々思い当たるところがあるだけに、言いえて妙です。

さて私の人生の逆襲はやりたいことが出来ていない「消失感」として表れるか、思うような結果が得られない「失望」として表れるか。どうなのだろう。このタイトルは説教くさい内容ではないのですが、それほどイメージが変わる発言だったり。まぁ、程々にに人生を楽しむガス抜きは必要ですよね・・・

Apacheを使いながら複数のドメイン名のSSL証明書を用意する場合、もう一つIPアドレスが必要とよく言われる。しかしネットワーク資源的にも、やはりSSLは何とか使いまわせるととても嬉しい。さて、この件について何が駄目で問題になっているか。HTTPのサービスをVirtualhostにて提供する場合には

NameVirtualhost hogehoge:80
<Virtualhost hogehoge.com:80>
...
</Virtualhost>
...
NameVirtualhost foofoo.com:80
<Virtualhost foofoo.com:80>
...
</Virtualhost>

と書く。通常のHTTP (ポート80番指定) の場合にはこのように。HTTPS (ポート443番指定) 指定の場合には一応Virtualhostの機能は機能しそうに思う。が、できない。理由は名前ベースにてVirtualhostディレクティブを記述した場合には、振り分けに使うHTTPのHOSTヘッダが取得できずに振り分けをすることができない。そのため、Virtualhostディレクティブ内の情報は無視されてしまう。HTTPSのVirtualhostを提供する場合にはIPアドレス指定にて記述する事となり、新規のIPアドレスが必要になる。

NameVirtualhost 192.168.0.1:443
<Virtualhost 192.168.0.1:443>
...
</Virtualhost>
...
NameVirtualhost 192.168.0.2:443
<Virtualhost 192.168.0.2:443>
...
</Virtualhost>

このように書く事となる。因みに、

NameVirtualHost *:443
<Virtualhost *:443>
ServerName hogehoge.com
...
</Virtualhost>
...
<Virtualhost *:443>
ServerName foofoo.com
...
</Virtualhost>

で、いけなくはない。ただし、Virtualhostのディレクティブ内に設定した証明書はApacheにて最初に指定された証明書を使う。恐らくは後者のホスト名についてはこの例のfoofoo.comにて正常なアクセスが出来なくなる(証明書エラー)。これが正常なSSLアクセスを提供出来なくなるもう一つの理由。その為、複数のSSLを一つのIPで提供するのであれば、

<Virtualhost 192.168.0.1:443>
...
<Virtualhost>
...
<Virtualhost 192.168.0.1:444>
...
<Virtualhost>

のような、もはや当たり前の苦肉の策になる。そして、これは証明書のエラーこそ発生しないが、通常のブラウザでのアクセスの場合はポート指定が必要となりサービスを受けるユーザにはあまりよろしくない。今更このような話を書いて何が言いたいか。HTTPSを使用する際の一つのIPに対して証明書が一つの問題は、HTTPSの仕様によるホスト名からのApacheの証明書の切り替えが出来ない事と、同時に設定した場合には片方の証明書しか有効にならないことである。SSL証明書発行の際には名前だけしか見てはいない。しかし、Apacheの処理上、IP一つとどうしても絡んでしまうのだ。同僚とそのような話をして、結論はポート分けてしか提供ができないって事で収まりはしたが、HTTP同等の名前ベースでのVirtualhost分けを前提に会話するという超テキトウな説明をして猛省中。

彼を知り己を知れば、百戦危うからず

そろそろお互い目を覚ましたほうがいいんじゃないかな