Varnish3.0.2 – cat /dev/random

Generate authorization header for Amazon S3 in Varnish

9月 062012

Amazon S3 REST-API is necessary to generate signature.
vmod-awsrest generate to Authorization and Date header for Amazon S3.

How to use

VCL

01import awsrest;
02 
03backend default {
04  .host = "s3.amazonaws.com";
05  .port = "80";
06}
07 
08sub vcl_recv{
09  awsrest.s3_generic(
10  "accessKey",            //AWSAccessKeyId
11  "secretKey",            //SecretAccessKeyID
12  req.request,            //HTTP-Verb
13  req.http.content-md5,   //Content-MD5
14  req.http.content-type,  //Content-Type
15  "",                     //canonicalizedAmzHeaders
16  req.url,                //canonicalizedResource
17  now                     //Date
18  );
19}

Output

`1`	`15 TxHeader b Date: Tue, 03 Jul 2012 16:21:47 +0000`

`2`	`15 TxHeader b Authorization: AWS accessKey:XUfSbQDuOWL24PTR1qavWSr6vjM=`

This module set to req.http.Authorization and req.http.Date, bereq is not use.
I recommend call in the vcl_recv.
And, be careful to default settings.
If req.http.Authorization contains, it is not caching. (default setting)

download here.
libvmod-awsrest

—
Reference site
PHP で Amazon S3 の REST API を使用 #1
Authenticating REST Requests

日本語はこっち
VarnishでAmazon S3の認証ヘッダを作るVMODを作ってみた

はてなブックマーク - Generate authorization header for Amazon S3 in Varnish

VarnishでAmazon S3の認証ヘッダを作るVMODを作ってみた

技術 9 Responses »

7月 112012

hiro_yさんからこんな質問を受けたので

@xcir VarnishからS3の認証突破する方法とかご存知ないですか…と思いまして

— 山岡広幸さん (@hiro_y) 7月 2, 2012

AWSの勉強がてら作ってみました。

S3のREST-APIのAuthorizationヘッダは、日付やリソースの場所などを改行で結合して
HMAC-SHA1でハッシュ化して、BASE64エンコードする必要があります。
HMAC-SHA1については、Varnish公式が公開しているvmod-digestを使うことでできるのですが
出力をBASE64にすることができないので、コードを拝借して今回のVMODを作ってみました。
ちなみに改行を扱うことについても、インラインCかVMODを使う必要があります。

使い方

01import awsrest;
02 
03backend default {
04  .host = "s3.amazonaws.com";
05  .port = "80";
06}
07 
08sub vcl_recv{
09  awsrest.s3_generic(
10  "accessKey",            //AWSAccessKeyId
11  "secretKey",            //SecretAccessKeyID
12  req.request,            //HTTP-Verb
13  req.http.content-md5,   //Content-MD5
14  req.http.content-type,  //Content-Type
15  "",                     //canonicalizedAmzHeaders
16  req.url,                //canonicalizedResource
17  now                     //Date
18  );
19}

上記のように呼び出すとreq.http.Authorizationとreq.http.Dateに生成したヘッダがセットされます。

`1`	`15 TxHeader b Date: Tue, 03 Jul 2012 16:21:47 +0000`

`2`	`15 TxHeader b Authorization: AWS accessKey:XUfSbQDuOWL24PTR1qavWSr6vjM=`

セットされるのがbereqではないのでvcl_recvで呼び出すことを推奨します。

またAuthorizationを生成するのでもしキャッシュを行いたい場合は適切にVCLを記述してください。
デフォルトのVCLではreq.http.Authorizationを含む場合はpassするためです。

僕の方でも簡単な動作チェックを行なっていますが、もし変な動きをしたら教えて下さい。

downloadはこちら（libvmod-awsrest）

—
参考サイト
PHP で Amazon S3 の REST API を使用 #1
Authenticating REST Requests

はてなブックマーク - VarnishでAmazon S3の認証ヘッダを作るVMODを作ってみた

同じVCLアクション(vcl_recvなど)を複数定義する

技術 1 Response »

5月 312012

若干小ネタですが、こんな書き方もできるという例です。

先日のエントリ（Varnishを使う際に覚えておきたいデフォルトの罠）において、
Varnishはユーザの入力したVCLコードの後に、デフォルトのVCLコードを挿入すると紹介しました。

これはユーザーのVCLとデフォルトのVCLの組み合わせですが、
実はユーザのVCLを複数定義して連結することが可能です。

やり方は非常に簡単で、同じアクションを複数定義するだけです。

01■VCL
02sub vcl_deliver{
03  set resp.http.a = "a";
04}
05sub vcl_deliver{
06  set resp.http.a = resp.http.a + "b";
07}
08sub vcl_deliver{
09  set resp.http.a = resp.http.a + "c";
10}
11 
12■出力ヘッダ
13a: abc

上記のVCLは以下のように結合されVarnishで使用されます

01sub vcl_deliver {
02  {//ユーザの定義1
03    set resp.http.a = "a";
04  }
05  {//ユーザの定義2
06    set resp.http.a = resp.http.a + "b";
07  }
08  {//ユーザの定義3
09    set resp.http.a = resp.http.a + "c";
10  }
11  {//デフォルト
12    return (deliver);
13  }
14}

因みに結合する際の順番は先に出てきたものからどんどん突っ込んでいく感じです。

実際のところどのように使えばいいかというと、includeと組み合わせて使うのが便利だと思います。

`1`	`include"/etc/varnish/ext.vcl";`

先頭や末尾にincludeで別処理を入れることで、本来の処理を邪魔せず
デバッグすることや、複数のサーバにまたがる共通処理などを記述することが可能です。

ちょっと小ネタですが役に立てばいいなぁとおもいます。

はてなブックマーク - 同じVCLアクション(vcl_recvなど)を複数定義する

Varnishを使う際に覚えておきたいデフォルトの罠

技術 No Responses »

5月 302012

最近とある人が嵌っていて聞かれたので
Varnishを使う上で覚えておきたいデフォルト設定の罠を説明したいと思います。

デフォルトのLISTENポートは6081、VCLでなく起動パラメータで設定する

そのかたはbackendの設定をLISTENポートと勘違いしていました。
Varnishの設定は主に2つにわかれています

起動パラメータ

VCL設定(default.vcl)

起動パラメータはキャッシュを保存するストレージのサイズを指定したり、保持するスレッド数や、ワークスペースのサイズ、LISTENポートを指定したりなどと
主に変更する場合はVarnish自体の再起動が必要などと即時に反映できないものが多いです。
（デフォルトのTTLなどもあり、必ずしも全てではない）

そしてVCL設定はリクエストに対してVarnishがどのように振る舞うかを定義しています。

redhat系の場合起動パラメータは
/etc/sysconfig/varnish
に記述されており、LISTENポートは以下のように定義されています

1# # Default address and port to bind to
2# # Blank address means all IPv4 and IPv6 interfaces, otherwise specify
3# # a host name, an IPv4 dotted quad, or an IPv6 address in brackets.
4# VARNISH_LISTEN_ADDRESS=
5VARNISH_LISTEN_PORT=6081

if-modified-sinceに対して常に304を返そうとするが動作が不安定

保存されている画像などが変更されずに、URLに対してユニークであることが保証できる場合
if-modified-sinceを受け取った段階で、即304を返す場合があります。

たとえば以下のようなコードです

1...バックエンドの設定...
2sub vcl_recv{
3  if(req.http.If-Modified-Since) {
4    error 304 "Not Modified";
5  }
6}

特に問題もなく動くブラウザと動かないブラウザが出てくると思います。
Varnishの304時のレスポンスをよく観察してみると、ボディがくっついているのが確認できると思います。

ステータス304はレスポンスボディを含んではならないため
ブラウザによっては予期せぬ動作になったりします。

これはVarnishのデフォルト設定が原因です。
まずVarnishがユーザーの記述したVCLコードと、デフォルトのVCLコードをどのように扱っているかを説明します。

Varnishはユーザの入力したVCLコードの後に、デフォルトのVCLコードを挿入します。

そのため、たとえば以下のようにvcl_recvを指定した場合でも

1sub vcl_recv{
2  if(req.http.If-Modified-Since) {
3    error 304 "Not Modified";
4  }
5}

実際にVarnishは以下のように解釈します

01sub vcl_recv{
02  //ユーザの設定したvcl_recv
03  {
04    if(req.http.If-Modified-Since) {
05      error 304 "Not Modified";
06    }
07  }
08  //Varnishのデフォルトのvcl_recv
09  {
10    if (req.restarts == 0) {
11        if (req.http.x-forwarded-for) {
12            set req.http.X-Forwarded-For =
13                req.http.X-Forwarded-For + ", " + client.ip;
14        } else {
15            set req.http.X-Forwarded-For = client.ip;
16        }
17    }
18    if (req.request != "GET" &&
19      req.request != "HEAD" &&
20      req.request != "PUT" &&
21      req.request != "POST" &&
22      req.request != "TRACE" &&
23      req.request != "OPTIONS" &&
24      req.request != "DELETE") {
25        /* Non-RFC2616 or CONNECT which is weird. */
26        return (pipe);
27    }
28    if (req.request != "GET" && req.request != "HEAD") {
29        /* We only deal with GET and HEAD by default */
30        return (pass);
31    }
32    if (req.http.Authorization || req.http.Cookie) {
33        /* Not cacheable by default */
34        return (pass);
35    }
36    return (lookup);
37  }
38}

つまり、ユーザが何も指定しないアクションは全てデフォルトの動作となります。

vcl_errorのデフォルト設定は以下のとおりです

01sub vcl_error {
02    set obj.http.Content-Type = "text/html; charset=utf-8";
03    set obj.http.Retry-After = "5";
04    synthetic {"
05<?xml version="1.0" encoding="utf-8"?>
06<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
07 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
08<html>
09  <head>
10    <title>"} + obj.status + " " + obj.response + {"</title>
11  </head>
12  <body>
13    <h1>Error "} + obj.status + " " + obj.response + {"</h1>
14    <p>"} + obj.response + {"</p>
15    <h3>Guru Meditation:</h3>
16    <p>XID: "} + req.xid + {"</p>
17    <hr>
18    <p>Varnish cache server</p>
19  </body>
20</html>
21"};
22    return (deliver);
23}

つまり、以下のようにデフォルトの設定が動いてしまいレスポンスボディが生成されたため
ブラウザによって不具合が起きてしまいます。

これを防ぐためには、vcl_errorで以下のような記述をする必要があります。

1sub vcl_error {
2    if(obj.status == 304){
3        return (deliver);
4    }
5}

この設定によりerrorで304を発行する場合、
デフォルトの設定を行わずそのまま次の処理に移動します。

また204 No Contentや1XXについてもレスポンスボディを含んではいけないので

1sub vcl_error {
2    if((obj.status >= 100 && obj.status < 200) || obj.status == 204 || obj.status == 304){
3        return (deliver);
4    }
5}

とするのも良いでしょう。

キャッシュできるはずなのにキャッシュできない

全て静的コンテンツで、バックエンドは200を返しているのにキャッシュされない場合があります。
これは先程のデフォルトの設定と絡んでいます。

vcl_recvのデフォルト設定を見てみましょう。

01sub vcl_recv {
02    if (req.restarts == 0) {
03        if (req.http.x-forwarded-for) {
04            set req.http.X-Forwarded-For =
05                req.http.X-Forwarded-For + ", " + client.ip;
06        } else {
07            set req.http.X-Forwarded-For = client.ip;
08        }
09    }
10    if (req.request != "GET" &&
11      req.request != "HEAD" &&
12      req.request != "PUT" &&
13      req.request != "POST" &&
14      req.request != "TRACE" &&
15      req.request != "OPTIONS" &&
16      req.request != "DELETE") {
17        /* Non-RFC2616 or CONNECT which is weird. */
18        return (pipe);
19    }
20    if (req.request != "GET" && req.request != "HEAD") {
21        /* We only deal with GET and HEAD by default */
22        return (pass);
23    }
24    if (req.http.Authorization || req.http.Cookie) {
25        /* Not cacheable by default */
26        return (pass);
27    }
28    return (lookup);
29}

見ての通り、認証時やクッキーが付いている場合はデフォルトではpass動作となりキャッシュされません。
VCLの記述をする際は、必ず自分の書いたコードの後にデフォルトのコードが付与されることを意識して書く必要があります。
全て自分の記述したコードで完結し、デフォルトの設定を動かしたくない場合は
必ずreturn(XXXX)で終わるようにしましょう。

以上
意外と嵌りやすいんじゃないかなーという点を解説しました。
（僕も触り始めの頃デフォルト設定が動いて嵌りました）
何かの参考になればと思います。

How to hook VCL function at VMOD

English, 技術 No Responses »

5月 262012

VMOD processing want to before/after VCL function processing.
But, I do not want to write extra line.
How to do it?

Can be realized by the replace the pointer to sp->vcl->XXXX_func (VCL_XXXX)

Can be added to the processing by replacing pointer

01static vcl_func_f         *vmod_redirect_Hook_vcl_error = NULL;
02static pthread_mutex_t    vmod_redirect_mutex = PTHREAD_MUTEX_INITIALIZER;
03static unsigned           hook_done = 0;
04 
05static int vmod_Hook_vcl_error(struct sess *sp){
06 
07    ....    //write the processing
08 
09    //call original vcl_error
10    return(vmod_redirect_Hook_vcl_error(sp));
11 
12}
13 
14int
15vmod_location(struct sess *sp, int status, const char*p,...)
16{
17        //vcl reload detection.
18        if(hook_done == 1
19           && sp->vcl->error_func != vmod_redirect_Hook_vcl_error ) hook_done = 0;
20 
21        if(hook_done == 0){
22            //lock to prevent another thread write
23            AZ(pthread_mutex_lock(&vmod_redirect_mutex));
24 
25            if(hook_done == 0)
26            {
27                //store the original vcl_error pointer
28                vmod_redirect_Hook_vcl_error = sp->vcl->error_func;
29 
30                //hook
31                sp->vcl->error_func = vmod_Hook_vcl_error;
32 
33                hook_done = 1;
34            }
35            //unlock
36            AZ(pthread_mutex_unlock(&vmod_redirect_mutex));
37        }
38 
39    ....
40 
41    return (status);
42}

(via:vmod_redirect)

Hook to vcl_error at vmod processing in first time.
because there is no way to write-access the pointer at vmod_Init.

also, has locked using the mutex, because to prevent the loop by thread concurrent access.

I hope that this code is of help to you.

ATTENTION
don’t use varnishadm’s command “vcl.use” and “vcl.discard” . because to the segfault or call to other vcl function.

—
modify(2012-08-01)
when you vcl reloaded, hook method be off.

はてなブックマーク - How to hook VCL function at VMOD

VMODで各アクション(vcl_errorなど)にフックする方法

技術 No Responses »

5月 252012

VMODを作る上で何かしらの後処理や前処理を、ユーザの処理前にやりたいケースが存在します。
たとえば僕が以前作ったvmod_redirectの場合です。

Varnishのリダイレクトはかなりめんどくさくて以下のように記述する必要があります。

01sub vcl_recv {
02  if (req.http.user-agent ~ "iP(hone|od)") {
03    error 750 "Moved Temporarily";
04  }
05}
06 
07sub vcl_error {
08  if (obj.status == 750) {
09    set obj.http.Location = "http://www.example.com/iphoneversion/";
10    set obj.status = 302;
11    return(deliver);
12  }
13}

このように一回エラー関数でvcl_errorに飛ばして判断する必要があります。
しかしvmod_redirectではvcl_errorに記述することなくredirectを実現しています。

1import redirect;
2sub vcl_recv {
3   if (req.http.user-agent ~ "iP(hone|od)") {
4      error(redirect.location(302,"http://www.example.com/iphoneversion/") , "Moved Temporarily");
5   }
6}

これはvcl_errorの関数ポインタをフックすることにより
オリジナルのvcl_errorが呼び出される前に独自の関数を呼び出すためです。

ではフックするためのポインタは何処に定義されているでしょうか？
vmodで使うsturct sess構造体(sp)に含まれています。

1vcl_errorの場合
2 sp->vcl->error_func
3 
4vcl_deliverの場合
5 sp->vcl->deliver_func
6...

ここのポインタを書き換えることでVarnishが呼び出すアクションを変更することが可能です。

そのことでオリジナルのアクションを呼び出す前後で任意の処理を行うことができ非常に便利です。

実際に書き換える場合はこのようなコードで行います

01static vcl_func_f         *vmod_redirect_Hook_vcl_error = NULL;
02static pthread_mutex_t    vmod_redirect_mutex = PTHREAD_MUTEX_INITIALIZER;
03static unsigned           hook_done = 0;
04 
05static int vmod_Hook_vcl_error(struct sess *sp){
06 
07    ....//任意の処理を書く
08 
09    //オリジナルのvcl_errorを呼び出してリターン
10    return(vmod_redirect_Hook_vcl_error(sp));
11 
12}
13 
14 
15int
16vmod_location(struct sess *sp, int status, const char*p,...)
17{
18        //VCLのreloadでフックが外れた場合の検知
19        if(hook_done == 1
20           && sp->vcl->error_func != vmod_redirect_Hook_vcl_error ) hook_done = 0;
21 
22        if(hook_done == 0){
23            //別のスレッドが同時に書き込みをしないようにロックする
24            AZ(pthread_mutex_lock(&vmod_redirect_mutex));
25            if(hook_done == 0)
26            {
27                //退避先にオリジナルのポインタを保存
28                vmod_redirect_Hook_vcl_error = sp->vcl->error_func;
29                //フックする
30                sp->vcl->error_func = vmod_Hook_vcl_error;
31                 
32                hook_done = 1;
33            }
34            //ロック開放
35            AZ(pthread_mutex_unlock(&vmod_redirect_mutex));
36        }
37     
38    ....
39 
40    return (status);
41}

ポイントとして初回のvmod関数呼び出し時にフックします。
これはvmod_Initではフックをするために必要な構造体へのアクセス方法が無いためです。
またmutexを利用してロックしていますが、これは複数のスレッドが同時にフックを行おうとしてフック関数でループするのを防ぐためです


ロックを行わないと、上図の(6)でオリジナルのポインタとおもって、フック後のポインタを取得してしまいます。
二回0チェックしているのは、ロックをかける間に他のスレッドが書き込んでいないことを確認するためです。

このようにフックを使うことでよりVMODの表現が増えるんじゃないかなと思います。
参考になれば幸いです

注意
varnishadmのvcl.useとvcl.discardを使わないでください。
vcl.useの場合は直前のVCLのメソッドが呼ばれ、vcl.discardはセグフォを起こす危険性があります

—-
2012-08-02追記
VCLのリロードを行った時にフックが外れるので検知用コードを追加（hook_done）

はてなブックマーク - VMODで各アクション(vcl_errorなど)にフックする方法

[tips]varnishncsa save the split log for every host

English, 技術 1 Response »

3月 202012

To save the split log for every host([hostname].access_log), Apache is easy.
I want the same action in varnishncsa. What should I do?

Use the options -m [tag:regex], -w [file], -a and -D.

-m perform a regex match to the tag’s log entry.
-w write log to a file.
-a append log. Will be overwritten if you do not specify.
-D Daemonize.

exec varnishncsa(host is a.example.net and b.example.net)

`1`	`varnishncsa -m` `"RxHeader:^Host: a.example.net$"` `-a -w /var/log/varnish/a.example.net.access_log -D`

`2`	`varnishncsa -m` `"RxHeader:^Host: b.example.net$"` `-a -w /var/log/varnish/b.example.net.access_log -D`

after request

1cat a.example.net.access_log
2192.168.1.199 - - [20/Mar/2012:12:51:50 +0900] "GET http://a.example.net/a HTTP/1.0" 200 280 "-" "Wget/1.12 (linux-gnu)"
3 
4cat b.example.net.access_log
5192.168.1.199 - - [20/Mar/2012:12:51:59 +0900] "GET http://b.example.net/a HTTP/1.0" 200 280 "-" "Wget/1.12 (linux-gnu)"

work as expected.

If you want to log rotate, please send the SIGHUP.

はてなブックマーク - [tips]varnishncsa save the split log for every host

varnishncsaでホスト毎にログを保存する

技術 No Responses »

3月 202012

Apacheでvirtualhostを切って複数のホストで運用する場合
よくログファイル名に[hostname].access_logとかつけるとおもいます。
ではvarnishncsaで似たようなことをするにはどうすればいいでしょうか？

-m [tag:regex]と-w [file] -D -aオプションを使うことで可能です。
このオプションはログエントリの指定されたタグ（RxHeaderなど）の内容（Host: c.example.netなど）を正規表現でマッチさせて
引っかかったものを対象にするオプションです
タグについてはvarnishlogを眺めてる時に出てくるのを見ればわかると思います

`1`	`↓ここがタグ　　　　　　↓ここが内容`

`2`	`12 RxHeader c Host: c.example.net`

-wは出力先のファイル名を指定して、-Dを指定するとデーモンとして動きます
-aはログの追記です。指定しないとログが存在する場合上書きされてしまいます。

今回はテストでa.example.netとb.example.netでそれぞれログを出力します
こんな感じで指定します

`1`	`varnishncsa -m` `"RxHeader:^Host: a.example.net$"` `-a -w /var/log/varnish/a.example.net.access_log -D`

`2`	`varnishncsa -m` `"RxHeader:^Host: b.example.net$"` `-a -w /var/log/varnish/b.example.net.access_log -D`

それぞれwgetを投げてみて出力されたのが以下です。

1cat a.example.net.access_log
2192.168.1.199 - - [20/Mar/2012:12:51:50 +0900] "GET http://a.example.net/a HTTP/1.0" 200 280 "-" "Wget/1.12 (linux-gnu)"
3 
4cat b.example.net.access_log
5192.168.1.199 - - [20/Mar/2012:12:51:59 +0900] "GET http://b.example.net/a HTTP/1.0" 200 280 "-" "Wget/1.12 (linux-gnu)"

きちんと分かれているのがわかります。

またvarnishncsaはSIGHUPを受け取るとファイルを開き直すので
ローテーションする場合はSIGHUPを使ってください

VarnishCache3.0.2がリリースされました

技術 No Responses »

11月 022011

VarnishCache3.0.2がリリースされました。
今回はバグ修正がほとんどですが一点言語仕様に変更があります。
Continue reading »