スレッドセーフなmruby-signal-threadを書いた

最近仕事でmrubyを触り始めて、だいぶC言語に触れ合う時間が増えてきたので、@matsumotoryのススメもあって、mgemを書きました。 なぜ作ったのか mrubyには既にmruby-signalというCRubyのクローン実装のmgemも存在するのですが、マルチスレッドでの動作を考えた場合に、グローバル変数にmrb_stateを持つことから、意図しない動作となるケースがあるため再実装しました。シングルプロセス、シングルスレッドで使うにはmruby-signalで十分なので、今回はコントリビュートではなく別実装とした意図があります。 使い方 シンプルにこのような実装にしました。mruby-threadにシグナルを指定可能にしたようなイメージが近いと思います。 工夫 実装するにあたり工夫が必要だったのは、下記のコードです。 今回の実装はSignalThread#trapが実行されるごとに、mruby-threadを利用して、そのシグナルを処理する専用のスレッドを起動し、スレッドでsigwaitするような実装としています。しかし、その場合、複数のスレッドを起動した場合に、先に起動したスレッドに後続のスレッドが処理するはずのシグナルが配送されてしまう事が起こりえます。 HUPを処理するスレッド1を起動 USR1を処理するスレッド2を起動 USR1シグナルを送る この場合に、スレッド1にUSR1が配送されてしまうケースに該当します。スレッド1のsigwaitはHUPのみを待ち受けているのですが、そこにUSR1が配送されても意図したハンドラ処理を行うことが出来ません。この辺のシグナルの流れは同僚の@harasouが書いたLinux

More

SSHのログイン先でも最適化されたvimが使いたい

サーバでオペレーションするときに、ちょっとトラブルシュートしたりするくらいならよいのですが、定期的にログインして作業するサーバがそれなりにあって、その生産性があまり無視できなくなったのでSTNSにstns-setupという機能を設けました。 STNS導入済みのクライアントでstns-setupコマンドを実行すると、事前に定義しておいたコマンドを実行することが出来ます。 $ stns-setup アトリビュートはこんな感じです。 [users.example] id = 1000 name = "example" setup_commands = [ "git clone https://github.com/pyama86/dotfiles.git /home/example/dotfiles", "/bin/sh

More

STNSが単体でのTLS暗号化&クライアント認証に対応しました

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-09-22-22-54-23

先日STNS,libnss-stnsともに0.2.2をリリースしました。主な変更内容は下記のとおりです。 TLS暗号化に対応 TLSを利用したクライアント認証に対応 retry_requestパラメーターでクライントのリトライ回数を指定可能にした ubuntu14.04における再起動が完了しない不具合を修正 TLS関連 これまではnginxなどと組み合わせてTLS/SSL暗号化を提供していましたが、@naoto_gohkoさんからissueを頂いたのと、昨今みんな出来るだけサーバ立てたくないんだろうなぁというフォースを感じたので、単体でTLS暗号化に対応し、サーバ、クライアント共にパラメータを追加しています。 STNS.jp Configuration tls_ca = "keys/ca.pem" # using only client authentication tls_cert = "keys/server.crt" tls_key = "keys/server.key" クライアント、サーバいずれもパラメーターの内容は一緒ですが、サーバのtls_ca及び、クライアントのTLS関連のパラメーターについてはクライアント認証を行うときだけ指定してください。 TLS暗号化だけを利用する場合 stns.conf tls_cert = "keys/server.crt" tls_key = "keys/server.key" libnss_stns.conf api_end_point = ["https://example.jp:1104/v2"] TLSクライアント認証を利用する場合 stns.conf tls_ca = "keys/ca.pem" tls_cert = "keys/server.crt" tls_key

More

~/.ssh/configを分割管理できるpincというコマンドを世に産んだ

初夏が猛暑!皆様いかがお過ごしでしょうか? 昨今、サーバインフラのクラウド化により一人のエンジニアが複数のサービスのサーバに対してSSH接続することも多くなってきました。また多くのサーバでグローバルIPを保つ必要がなくなり、リバースプロキシを置いて管理する構成が増えてきたように思います。そこで悩まされるのが~/.ssh/configの管理じゃないでしょうか? ファイルが500行くらいになったり、新しいエンジニアが入るたびに 「xxxに接続したいんですけど、繋がらないんですよぉ~」 「なっぁぁぁにぃぃぃ~~~~!?この内容を~/.ssh/configに黙って書いてくれ!!!1」 なんてやり取り多いですよね。。そういったやり取りをなるべく少なく出来るようにGolangでpincというコマンドを開発しました。 インストール OS Xで利用することが多いかと思いますのでhomebrewを準備しています。 $ brew tap pyama86/pinc $ brew install pinc 使い方 $ pinc init initコマンドにより~/.ssh配下にconf.dディレクトリ、pinc.yml、base_configファイルが作成されます。 conf.d 配下に作成されたディレクトリ、ファイルを再帰的に読み込みます。 pinc.yml includeディレクティブ配下に配列でファイル、ディレクトリを定義すると再帰的に読み込みます。 base_config ~/.ssh/configをコピーしたファイルです $ pinc gen initファイルで作成、定義されたファイルをマージし、~/.ssh/configファイルを作成します。 便利な使い方 複数サービスを提供している会社の場合、~/.ssh/pinc.ymlに下記のように定義することで、複数サービスの~/.ssh/configを一元管理できるようになります。 include: - /path/to/ServiceA_File -

More

チーム開発を活性化するためにやったこと

issue

最近STNSのバージョンアップ記事ばっかり書いていたので、今日はチーム開発について書いてみます。僕は2016年からペパボのエンジニア職位制度のミドル層にあたるシニア・エンジニアという職位につきました。シニア・エンジニア以上の職位についてはエンジニアとして優れた存在であり続けることはもちろんのこと、それに加えて社内のエンジニアの育成や、社の全体の技術的課題の解決が求められます。 自身がなんからのプロダクトを生むことや、社の課題を解決するのは自分で手を動かせばよいだけなので、特に何も考える必要はありませんでした。対して社内のエンジニアの育成を考えた場合に、僕はまずはチームをいかに活性化し、生産性を高めるか?という事を考えました。 その理由は下記の3つです。 1. 生産性が上がるとこなせる仕事量が増加し、その結果、経験値が蓄積しやすい。 2. 生産性が上がると無駄に残業せずに早く帰れて最高!!(自己研鑚の時間が出来る) 3. 生産性が上がると、なんか自分やれてる感が生まれて更に頑張るから成長する チームとしての生産性を上げるために半期中にいくつか施策を打ちました。その中から今日は3つを紹介します。 自動テストで記法チェック、自動修正を導入する コードレビューをする際に、例えばphpであれば下記のようなコードが書かれていた場合。 if($hoge == "fuga"){ echo "check"; } ifと(の間にはスペースを入れましょうなどといった指摘って、言われた方も正直どうでもいいと思うってしまうし、言う方もタイプする時間が無駄ですよね。何も生まない指摘はしないに越したことはないので、下記のようなコードをCIツールで自動実行しています。 # !/bin/bash success=0 files="$(git diff --name-only --diff-filter=M origin/master HEAD | grep ".php$")" rootdir=$(cd ../$(dirname $0) 2>/dev/null;pwd) if [ `which php-cs-fixer` ]; then cmd=php-cs-fixer else cmd=$rootdir/vendor/bin/php-cs-fixer fi array=($(echo

More

パスワード暗号化について学びを得た

スクリーンショット 2016-05-29 11.03.17

今日はパスワードの暗号化について書いてみたいと思います。 きっかけはSTNSにSudoパスワードを追加した際に@matuuさんよりご指摘をいただいたのがきっかけです。 これまでパスワード暗号化に対する知見が全く無く、「とりあえずSHA256あたりでハッシュ化しとけば漏洩してもダイジョウV!!!」なんて思ってたものですから、これを機に調べてみました。 パスワードの暗号化が有効に働く機会として最も可能性が高いのは、サーバに何らかの手段で侵入され、データベース、ソースコードが参照された状態だと思います。要するに侵入者にすべてを見られた状態でもパスワードを知られ得ないことを目的として暗号化するわけです。 パスワードの暗号化時によく用いられる強固にする手法としてはSalt、Stretchingの2種類があります。今回はこの2点についてまとめてみました。 Saltを利用しパスワード暗号化を強化する Saltというのは御存知の通り塩です。パスワードに塩を足して、いい塩梅にするわけです。前提となる話として、パスワードクラックの手法の一つにレインボーテーブルを用いた手法があります。 レインボーテーブルとは予め一定量の文字列をハッシュ化したものを辞書化しておき、辞書と突合することにより瞬時に元のパスワードがわかるというものです。たとえば、下記のようなコマンドの結果をひたすら作りこんでおけば、passwordやp@sswordのようなパスワードは瞬時に破られてしまいます。 % echo -n 'password' | shasum -a 256 5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8 - % echo -n 'p@ssword' | shasum -a 256 0fd205965ce169b5c023282bb5fa2e239b6716726db5defaa8ceff225be805dc - これに対する有効な対策として、パスワードの文字列を長くすることにより、辞書に登録され得ない値を設定することが挙げられますが、我々人類の多くは怠惰であり、パスワードマネージャーを使うのもニュータイプに限られるため、システム側でなんとかしてやる必要があります。 それに対する一つの手段がSaltです。具体的にはユーザーに入力されたパスワードに何らかの文字列を追加してからハッシュ化し、保存してあげることにより、ユーザーに意識させることなく、パスワード暗号化を強固にすることが出来ます。 手軽にやるのであればユーザー名をハッシュ化したものをSaltとして利用してあげるのが良さそうです。 % echo -n 'pyama' | shasum -a 256 6b513449d1d9f85a652dc54f440603ec19761708c801eb8cd12fc96ee6cedbc9 - % echo -n '6b513449d1d9f85a652dc54f440603ec19761708c801eb8cd12fc96ee6cedbc9password' | shasum

More