![NginxのRatelimit発動時に、安定したアクセスを提供するngx-smart-ratelimitを開発しました | ten-snapon.com](https://cdn-ak-scissors.b.st-hatena.com/image/square/a23b4c4b4227656786e43a9672a23ce5b14a4992/height=288;version=1;width=512/https%3A%2F%2Ften-snapon.com%2Fwp-content%2Fuploads%2F2018%2F07%2FDSC09532.jpg)
サポート終了にあたり、WEBサービス提供者としてはユーザーに何らかの方法で、ユーザーの対応の有無を通知したい場合がほとんどだと思います。このエントリでは先日、ngx_mrubyに追加された、 tls_version メソッドを利用して、クライアントのサポートするTLSバージョンに応じて表示するサイトのコンテンツを変更する方法を紹介したいと思います。 今回の例は下記のような構成を想定しています。HTTPS(TLS)通信はNginxで終端し、後段のOriginサーバへHTTPでリバースプロキシする構成です。 この構成の場合に、TLS1.2、1.3であれば、 /tls_ok にリバースプロキシし、 該当しなければ /tls_ng にリバースプロキシするコンフィグ例は下記になります。 mruby_ssl_handshake_handler_code ' ssl = Nginx::SSL.new U
先日、来る下記のイベントの資料でmrubyの文字列結合におけるメモリパフォーマンスについて記述し、それを社内で共有したところ、それをみた @matsumotory がmrubyにおける文字列結合は + での結合より、破壊的ではあるが <<のほうがパフォーマンスが良いということに気づいた。 valgrindで測定すると下記のような具合である。 # new.rb a = "aaa" b = "bbb" 100000.times do |n| a += b end $ sudo valgrind ./mruby new.rb ... ==2374== HEAP SUMMARY: ==2374== in use at exit: 0 bytes in 0 blocks ==2374== total heap usage: 102,786 allocs, 102,786 frees, 15,002,
mod_mruby ngx_mruby Advent Calendar 2017の記事を書きます。内容は僕が12月の初旬に格闘していたくんさんレンタルについてです。 僕の今日は「くんさんレンタル」に捧げたといっても過言ではない。 — P山 (@pyama86) December 7, 2017 今日は俺がくんさんレンタルを倒す。 — P山 (@pyama86) December 8, 2017 だいぶ追い詰めたけど今日もくんさんレンタルを捉えることはできませんでした。 — P山 (@pyama86) December 8, 2017 なお、無事、収束しているので変ではなく乱として扱います。変と乱の違いは下記を参照ください。 "変"だと、その行動による改革が成功したことになるので、負けていないぞという気持ちがあるのであれば "乱" が適当でしょう — モノクロメガネ研究員 (@monochr
以前より個人で開発していたパッケージ脆弱性管理サービスVeetaをリリースしました。 現状はAWSで個人資金にて運用しているため、1オーガニゼーション5台までの制限がありますが、無料で利用できます Veetaのアーキテクチャは下記の通りです。 利用方法は、ドキュメントにも記載がありますが、以下の手順ですぐに始めることができます。 オーガニゼーションを登録する 認証トークンを発行する クライアントをインストールし、認証トークンを設定する この作業を行うだけで、クライアントであるVazがサーバ内のパッケージ情報を取得し、Veetaにアップロードし、自動的にスキャンしてくれます。 スキャンした結果はVeetaのコンソール上で確認することができ、脆弱性の詳細を確認したり、無視することができます。また、脆弱性の有無はレポート機能でメールやSlackに指定した時間に通知することが可能です。 解決したか
今年を振り返ると、何と言ってもSTNSだった。STNSのinitial commitは2016/01/03 3:30なので今年の冬休みにSTNSを書いていたんだと思う。 それをきっかけに第5回ペパボテックカンファレンス〜インフラエンジニア大特集〜やPHPカンファレンス福岡で話す機会が得られたし、これまで社内に閉じていたOSS活用が初めて社外に広がった初めてのプロダクトであった。また自分の中でこれまで、これは仕様だから出来ないと諦めていた壁を初めてブレイク・スルーできた機会でもあり、「技術的に出来ないことはそんなに無い」という自身の言葉に説得を与える出来事でもあった。 ペパボの中ではチーフテクニカルリードに就任し、これまでとは違ったチーム・ビルディングやメンターとしての振る舞いが求められるようになったが、そんなにやりきれた感じはない。自分自身が謙虚に向き合えきれてなかったところと、感情コント
どうも皆さんこんばんは。ナイスガイことカキフライ大好き@pyama86です。 この記事はpepabo Advent Calendar 2016の7日目の記事です。 エンジニアなので、何か技術的な記事を書こうと思ったのですが、それは破壊的イノベーションではないと思いとどまりました。 僕はペパボに入社する前は週に3回合コンをデプロイしていて、定時に帰れるしエンジニア最高!といっていた経歴があるので、そんなころに見つけた、忘年会シーズンに役立つ、福岡グルメの紹介でもしようかなと思います。 日常使いのお店を中心に紹介するので福岡に出張などございましたら是非ご活用ください。 ここは大名のプラザホテルの地下にあるこじんまりとしたイタリアンです。コースもリーズナブルで、ワインリストも手ごろなので、客単価6000円~8000円くらいで楽しめます。ギャルソンのお兄さんが面白く、接客も丁寧なので便利。 ビスト
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
STNS 0.0.4、libnss-stns 0.0.6リリースしました。今回の主な機能追加は下記のとおりです。 sudoersアトリビュートでsudo用パスワードを指定可能にした STNSがダウンしている時にロックファイルを作成し、一定時間通信を抑制する sudoersアトリビュートの追加 これまでSTNSを利用する場合、sudoersに下記のような設定を追加し、パスワード未利用での運用が必要でした。 /etc/sudoers example ALL=(ALL) NOPASSWD:ALL 今回のアップデートにより、NOPASSWD:ALLを指定せずとも、Linuxの認証基盤であるPAMと連携することにより、sudo時のパスワードが指定可能となりました。 PAMについては@ITのSambaユーザーのパスワード管理 PAMを利用して認証を行うの記事がイメージをつかみやすいと思います。 まずS
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く