mruby

mruby libraries provided by H2O

最近H2Oでmrubyを使うことに興味を持ち入門してみました。 Hello world with mruby on H2O 実際に使われているmrubyのコードもみてみたいと思い調べたところ、標準でH2Oがmrubyのライブラリを提供していました。ありがたい。 h2o/share/h2o/mruby at master · h2o/h2o · GitHub 読むぞ！！！ また、実際にこのライブラリを使いたい場合ですが、CentOS7かつtatsushid/h2o-rpmを使ってH2Oをインストールした環境では、以下のpathにライブラリが収まっていました。 $ rpm -ql h2o | grep rb /usr/share/doc/
ruby

Hello world with mruby on H2O

このブログのウェブサーバーにH2Oを使っています。 h2o - ゆるふわキャンパー H2Oはデフォルトでmrubyに対応しており、これが最近気になっています。 Using Mruby - Configure - H2O - the optimized HTTP/2 server 楽しそう。 H2O x mrubyで人はどれだけ幸せになれるのか from Ichito Nagata そこで、まずはHello Worldするところまでをやってみます。 その前に色々わからないので調べてみます。 mrubyとは mrubyとは以下の特徴を持つ言語。 組み込み機器やアプリケーションへの組み込みに最適化された軽量なruby ほぼrubyと互換性がある(
letsencrypt

Auto renew SSL Certificate with Certbot(Let’s Encrypt)

このブログのSSL証明書はLet’s Encryptという認証局のものを使っています。Let’s Encryptの証明書を使い始めてしばらく経ちましたがいいかんじです。 letsencrypt - ゆるふわキャンパー Let’s Encryptについて Let’s Encryptの証明書は無料で提供されており、certbotという証明書の取得や更新をコマンドで行うことの出来るツールが提供されているのが特徴です。神ってことです。 証明書の有効期限は90日(3ヶ月)と短いですが、コマンド一発で証明書を更新できるのでデメリットではありません。 また、証明書を細かくアップデートしていけるということは常に最新の暗号技術を取り入れた証明書を(Let’s Encryptが追随してくれているので)使えるということであり、度々世間を騒がせている弱い暗号方式を使った証明書によって起きる脆弱性に対しても運用上強いはずです。 certbotをインストールする Let’s Encryptの証明書はcertbotを通じて取得、更新を行うので、
redash

Visualization referral domains using google BigQuery

re:dashとGoogle BigQueryでアクセスログを可視化して遊んでいます。 bigquery - ゆるふわキャンパー redash - ゆるふわキャンパー 最近Google BigQueryのドキュメントを眺めていてDOMAIN関数の存在を知ったので、これを使ってリファラのドメインを集計してre:dashで可視化してみます。 h2oでリファラをログに出力する方法 ログフォーマットでリクエストヘッダを指定(%{Referer}i)することでリファラをアクセスログに出力することができます。 Access Log Directives - Configure - H2O - the optimized HTTP/2 server こんな感じでGoogle BigQueryに送られていっています。
h2o

Specify the status code by H2O

re:dash見てたら302ステータスコードがめっちゃ多い！ 本来301(恒久的な転送)であるべきなので301リダイレクトするようにh2oの設定を修正しました(301でリダイレクトしているだろうと勝手に思っていた...)。 こんな感じで指定できる。 "ghost.ponpokopon.me:443": listen: port: 443 ... paths: "/": redirect: status: 301 url: "https://blog.lorentzca.me/" 適用後curlを叩いて動作確認。 Before $ curl --head
h2o

Send h2o log to BigQuery

h2oのアクセスログをtd-agentを使ってGoogle BigQueryに送ってみる。幾つか手順が必要。 bigqueryの設定 スキーマ定義ファイルの作成 td-agentの設定 bigqueryの設定 bigqueryへアクセスするためにapiを有効化し、アクセスキーを発行するのだが、この工程が長い…。(´・_・`) 慣れてないと混乱する。 gcpアカウントの作成 作る。 Google Cloud Computing, Hosting Services & APIs  |  Google Cloud Platform プロジェクトの作成 請求先アカウントの設定 bigqueryのapiを有効化 認証情報(とサービスアカウント)の作成 これでやっと以下のようなjson形式の鍵ファイルがダウンロードされる。td-agnetの設定で使う。 { "type&
h2o

Update h2o, h2o yum repository

なんかh2oがアップデートされてないなと思ったらメンテされてるリポジトリ変わってたっぽい(非公式リポジトリなのには変わりないけど)。 GitHub - tatsushid/h2o-rpm: Unofficial H2O RPM for Fedora, RHEL/CentOS and OpenSUSE builder まあ公式からリンクしてるし半公式みたいなものであろう！というわけで使う。 まず既存のパッケージ、yumrepo削除。 sudo systemctl stop h2o sudo yum remove h2o sudo systemctl daemon-reload sudo rm
ansible

To create `/var/run/h2o/` directory using systemd-tmpfiles

h2oをインストールするansibleのタスクを書いた。ついでにh2oの実行ユーザーをh2oユーザーにしてみた(デフォルトはnobody)。しかし、h2oの起動に失敗する。 ログ見ると/var/run/h2oディレクトリへ書き込みできなくて起動失敗している。 h2oインストール時(?)に/var/run/h2oが作成される(nobody:nobodyで) h2o起動直後h2oユーザーで/var/run/h2o以下にpidファイルを作成しようとするが、オーナーがnobodyなので作成失敗→起動失敗 という流れ。 予めディレクトリを作成するタスク書けば良いと思ったけど微妙感が…。h2oの起動スクリプトをいじるのも、h2oアップデート時元に戻されそうだしダメそう。 そこで何かいい方法がないか探した所、systemdにsystemd-tmpfilesというものがあった！ これはその名の通り、systemdのテンポラリなファイルを管理できる。/etc/tmpfiles.d/