Mac OSX El Capitan でのSIP対策

VPNのクライアントがEl Capitan で急に動かなくなったとかありませんか?
それはMac OSX 10.11 より新たに導入された System Integrity Protection(SIP)のせいかもしれません。

ええ・・私はそれで随分はまりました。

GlobalProtectというVPNクライアントを使っていたのですが、接続できなくなりました。
直接的な原因は 4767ポートで動作するPanGPSというデーモンが起動しないことによるものでした。
そして、起動しない原因がコードサイン(署名)されていないカーネルエクステンション(ドライバとか?)が起動するのを、
SIPで妨げていたことによるものでした。

# csrutil enable --without kext 

結果、リカバリーモードでSIPをkextには適用しないようにして解決。

詳細はこちら!appleのdeveloperフォーラムを参照ください。
https://forums.developer.apple.com/thread/17452

AWS s3fsとowncloudで(ほぼ)無限のストレージを手に入れよう

昨年、会社のストレージサーバをEC2のサーバに置き換えました。

以前は、HDD 100GBの共用サーバを利用してFTPでファイルをアップしたりして
仕事上で必要なファイルのやり取りを行っていました。
ただ、そこにはいろいろな使い勝手の悪さがあり、

  • チームメンバーが高解像度の画像などの素材をアップしがちで、すぐに100GBがいっぱいになる。
  • ディスクがいっぱいになると、他の人がファイルをアップできなくなる。
  • 要不要を判断し、ファイルを削除するのが手間。
  • セキュリティがゆるくなりがち
  • クライアントや、パートナー会社からはファイルアップができない(FTPアカウントを渡すことになる)

などが主な問題でした。



そこで、s3をバックエンドに、s3fs と ownCloudを使って、ファイルサーバを構築することにしました。
実はownCloud自体がs3をストレージとして利用出来る機能を持っているのですが、
PHPからHTTP接続でアクセスする形になり、少し使ってみた感じではあまりレスポンスがよくありませんでした。


s3fsだとCで書かれているため、s3へのアクセスが多少は高速だろうというのと、
ローカルストレージとしてマウントできるため、運用上扱いやすそうというのがありました。
また、s3を使うことで、表示上256TB のストレージを手に入れることになるので、ディスクがフルでアップできないといったビジネスワークとしてクリティカルな事態が避けられます。


※こんなの普段見たことありませんよね


ファイルアクセスがs3へのHTTPに依存しているので、レスポンスや運用上の不安があったのですが、
1年近く経って大きな問題もなく運用できているので、構築プロセスやそのメリットデメリットをまとめておきたいと思います。

環境構築

セットアップはいたってシンプル。

  • AWSにアカウント作る
  • s3のバケット作る
  • EC2サーバをセットアップ
  • s3fsをインストールし、s3のバケットをマウント
  • ownCloudをインストールし、マウントしたs3領域をローカルストレージとして登録

ごくたまに、s3fsがスタックしていたので、
monitを使って監視を行い、必要に応じてs3fsの再起動をかけています。

メリット(Pros)

  • AWSの無料利用枠を使えたので、毎月数十円で運用できた。
  • ec2とs3間のトラフィックが無料。
  • ディスクがいっぱいでファイルアップできないという心配がない。
  • ファイルがサーバディスク上ではなく可用性の高いs3にあるという安心感!
  • サーバの復旧時は、s3をマウントしなおせばOKのお手軽さ。

注) ownCloudがファイルリストをキャッシュしているので再スキャンは必要です。


あと、こちらはownCloudのメリットですが、

  • FTPいらずでブラウザでファイルのアップ・ダウンロードができる。
  • プレビュー機能により、画像やテキストファイル、PDFはダウンロードせずに中身を確認できる。
  • テキストファイルはブラウザ上で編集可能。
  • ファイル共有時に、URLで共有でき、パスワード・有効期限なども設定できる。
  • 編集可で共有すると、クライアントから素材などをアップしてもらうことも可能。

ownCloudに依るところも大きいですが、正直かなり便利になりました。

デメリット(Cons)

  • ディスク容量に制限がない分、DVD一枚レベルのデータを気軽にアップしてしまう。
  • 無料利用枠が終わったので、月額費用が共用サーバの時よりも少しだけかかるようになった。
  • ownCloudのアップデート作業がそこそこある。
  • ownCloudをアップデートするとデザインテーマ設定クリアされ、再設定が面倒。

メリットに比べれば微々たるものです。
基本お金で解決そうですが、アップデートでテーマがクリアされるのはどうにかならないかなーと思ったりはします。
地味に面倒なので。

その他

S3バケットの設定で、例えば、ファイル作成から1年以上たったファイルは自動でGlacierに移行するみたいなことができれば、とても自律的なストレージシステムになるんじゃないかって思います。


いかがでしたでしょうか?
興味を持った方は256TBの海に乗り出してみてください!

vagrant のプラグインはユーザごとにインストールされるので気をつけろ!

Jenkins ユーザでvagrantコマンドを叩かせていたら、digitalocean でエラー。
pluginをアップデートすれば治るかと思いきや、治らず。

Jenkinsユーザでpluginをアップデートしないといけなかった!
地味にはまった・・・

ansibleでcommand モジュールを使ってコマンドを実行する時は気を付けましょう

普通にcommandを使って、ユーザのパスワードを変更しようと思ったところ、
なぜか上手くいかない。

"changed" と返ってくるんだけど、かわってない。という現象に遭遇。

- name: change {{user_name}} password # set password for ftp access
  command: echo "{{user_password}}" | passwd --stdin "{{user_name}}"

色々悩んだあげく、
公式サイトで下記のような記述を発見。


commandモジュールはシェルを通して実行されないので、パイプやリダイレクトをコマンドで使う場合はshell モジュールを使ってね

これかぁぁぁ!
というわけで、シンプルにコマンドする場合は、shellをつかっとけってことでした。

- name: change {{user_name}} password # set password for ftp access
  shell: echo "{{user_password}}" | passwd --stdin "{{user_name}}"

git で一つ前のコミットとのdiffをとってarchiveするのに手間取った

HEAD^ と HEAD の間でtest.htmlといういらないファイルを削除してたとき、
このへん、やこのへんを参考に、
下記のようなコマンドをうっていた。

git archive --format=zip HEAD `git diff --name-only --diff-filter=AMCR HEAD HEAD^` -o archive.zip
 

すると

fatal: path spec 'test.html' did not match any files

と怒られた.


問題は、HEAD HEAD^の部分で、新しい→古い のgit diff のため、test.htmlは新しいHEADからすると ADD状態になるということ。


つまり、 "--diff-filter=AMCR"だと、test.htmlまで含まれてしまうのだ! "--diff-filter=MCRD" でうまくいくが、気持ち悪いので、

git archive --format=zip HEAD `git diff --name-only --diff-filter=AMCR HEAD^ HEAD` -o archive.zip
 

のように、HEAD^(古い) → HEAD(新しい) で設定し、
diff-filter をAMCR にして、test.htmlが抽出されなくなった。


よかった!

Amazon Linux の弱いところ

CentOS であれば、

$ sudo yum groupinstall 'Japanese Support'
$ sudo yum groupinstall 'Arabic Support'
$ sudo yum groupinstall 'Chinese Support'
$ sudo yum groupinstall 'Korean Support'

と多言語のサポートをインストールするのは簡単なんだけど、
Amazon Linuxだとgroupが入っておらず、使えません。

今回は、CentOS BaseのレポジトリをAmazon linux に追加し、インストールしました。

[base]
name=CentOS-6 - Base
mirrorlist=http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=os
enabled=0
gpgcheck=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-6

Chinese Supportの場合だけ、エラーがでたので、下記のように回避

sudo yum groupinstall "Chinese Support" --enablerepo=base --skip-broken

Amazon Linuxはレポジトリも新しく、早いので使いやすいと思っていたのですが、
こういう弱さもあるんですね。

baseレポジトリよりインストールした言語は無事に動いてはいるようです。

その他の言語をインストールする場合はこちらを参考にしてください。
https://fedoraproject.org/wiki/I18N/Language_Support_Using_Yum