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

[code=’plain’]
import awsrest;

backend default {
.host = “s3.amazonaws.com”;
.port = “80”;
}

sub vcl_recv{
awsrest.s3_generic(
“accessKey”, //AWSAccessKeyId
“secretKey”, //SecretAccessKeyID
req.request, //HTTP-Verb
req.http.content-md5, //Content-MD5
req.http.content-type, //Content-Type
“”, //canonicalizedAmzHeaders
req.url, //canonicalizedResource
now //Date
);
}
[/code]

Output

[code=’plain’]
15 TxHeader b Date: Tue, 03 Jul 2012 16:21:47 +0000
15 TxHeader b Authorization: AWS accessKey:XUfSbQDuOWL24PTR1qavWSr6vjM=
[/code]

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を作ってみた

7月 112012
 

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


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

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

使い方

[code=’plain’]
import awsrest;

backend default {
.host = “s3.amazonaws.com”;
.port = “80”;
}

sub vcl_recv{
awsrest.s3_generic(
“accessKey”, //AWSAccessKeyId
“secretKey”, //SecretAccessKeyID
req.request, //HTTP-Verb
req.http.content-md5, //Content-MD5
req.http.content-type, //Content-Type
“”, //canonicalizedAmzHeaders
req.url, //canonicalizedResource
now //Date
);
}
[/code]
上記のように呼び出すとreq.http.Authorizationとreq.http.Dateに生成したヘッダがセットされます。
[code=’plain’]
15 TxHeader b Date: Tue, 03 Jul 2012 16:21:47 +0000
15 TxHeader b Authorization: AWS accessKey:XUfSbQDuOWL24PTR1qavWSr6vjM=
[/code]
セットされるのがbereqではないのでvcl_recvで呼び出すことを推奨します。

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

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

downloadはこちら(libvmod-awsrest)

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

5月 312012
 

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

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

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

やり方は非常に簡単で、同じアクションを複数定義するだけです。
[code=’plain’]
■VCL
sub vcl_deliver{
set resp.http.a = “a”;
}
sub vcl_deliver{
set resp.http.a = resp.http.a + “b”;
}
sub vcl_deliver{
set resp.http.a = resp.http.a + “c”;
}

■出力ヘッダ
a: abc
[/code]
上記のVCLは以下のように結合されVarnishで使用されます
[code=’plain’]
sub vcl_deliver {
{//ユーザの定義1
set resp.http.a = “a”;
}
{//ユーザの定義2
set resp.http.a = resp.http.a + “b”;
}
{//ユーザの定義3
set resp.http.a = resp.http.a + “c”;
}
{//デフォルト
return (deliver);
}
}
[/code]

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

実際のところどのように使えばいいかというと、includeと組み合わせて使うのが便利だと思います。
[code=’plain’]
include”/etc/varnish/ext.vcl”;
[/code]
先頭や末尾にincludeで別処理を入れることで、本来の処理を邪魔せず
デバッグすることや、複数のサーバにまたがる共通処理などを記述することが可能です。

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

5月 302012
 

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

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

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

    起動パラメータ
    VCL設定(default.vcl)

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

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

redhat系の場合起動パラメータは
/etc/sysconfig/varnish
に記述されており、LISTENポートは以下のように定義されています
[code=’shell’]
# # Default address and port to bind to
# # Blank address means all IPv4 and IPv6 interfaces, otherwise specify
# # a host name, an IPv4 dotted quad, or an IPv6 address in brackets.
# VARNISH_LISTEN_ADDRESS=
VARNISH_LISTEN_PORT=6081
[/code]


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

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

たとえば以下のようなコードです
[code=’plain’]
…バックエンドの設定…
sub vcl_recv{
if(req.http.If-Modified-Since) {
error 304 “Not Modified”;
}
}
[/code]
特に問題もなく動くブラウザと動かないブラウザが出てくると思います。
Varnishの304時のレスポンスをよく観察してみると、ボディがくっついているのが確認できると思います。

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

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

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

そのため、たとえば以下のようにvcl_recvを指定した場合でも
[code=’plain’]
sub vcl_recv{
if(req.http.If-Modified-Since) {
error 304 “Not Modified”;
}
}
[/code]
実際にVarnishは以下のように解釈します

[code=’plain’]
sub vcl_recv{
//ユーザの設定したvcl_recv
{
if(req.http.If-Modified-Since) {
error 304 “Not Modified”;
}
}
//Varnishのデフォルトのvcl_recv
{
if (req.restarts == 0) {
if (req.http.x-forwarded-for) {
set req.http.X-Forwarded-For =
req.http.X-Forwarded-For + “, ” + client.ip;
} else {
set req.http.X-Forwarded-For = client.ip;
}
}
if (req.request != “GET” &&
req.request != “HEAD” &&
req.request != “PUT” &&
req.request != “POST” &&
req.request != “TRACE” &&
req.request != “OPTIONS” &&
req.request != “DELETE”) {
/* Non-RFC2616 or CONNECT which is weird. */
return (pipe);
}
if (req.request != “GET” && req.request != “HEAD”) {
/* We only deal with GET and HEAD by default */
return (pass);
}
if (req.http.Authorization || req.http.Cookie) {
/* Not cacheable by default */
return (pass);
}
return (lookup);
}
}
[/code]
つまり、ユーザが何も指定しないアクションは全てデフォルトの動作となります。

vcl_errorのデフォルト設定は以下のとおりです
[code=’plain’]
sub vcl_error {
set obj.http.Content-Type = “text/html; charset=utf-8”;
set obj.http.Retry-After = “5”;
synthetic {”




“} + obj.status + ” ” + obj.response + {“

Error “} + obj.status + ” ” + obj.response + {“

“} + obj.response + {“

Guru Meditation:

XID: “} + req.xid + {“


Varnish cache server



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

これを防ぐためには、vcl_errorで以下のような記述をする必要があります。
[code=’plain’]
sub vcl_error {
if(obj.status == 304){
return (deliver);
}
}
[/code]
この設定によりerrorで304を発行する場合、
デフォルトの設定を行わずそのまま次の処理に移動します。

また204 No Contentや1XXについてもレスポンスボディを含んではいけないので
[code=’plain’]
sub vcl_error {
if((obj.status >= 100 && obj.status < 200) || obj.status == 204 || obj.status == 304){ return (deliver); } } [/code] とするのも良いでしょう。


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

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

vcl_recvのデフォルト設定を見てみましょう。
[code=’plain’]
sub vcl_recv {
if (req.restarts == 0) {
if (req.http.x-forwarded-for) {
set req.http.X-Forwarded-For =
req.http.X-Forwarded-For + “, ” + client.ip;
} else {
set req.http.X-Forwarded-For = client.ip;
}
}
if (req.request != “GET” &&
req.request != “HEAD” &&
req.request != “PUT” &&
req.request != “POST” &&
req.request != “TRACE” &&
req.request != “OPTIONS” &&
req.request != “DELETE”) {
/* Non-RFC2616 or CONNECT which is weird. */
return (pipe);
}
if (req.request != “GET” && req.request != “HEAD”) {
/* We only deal with GET and HEAD by default */
return (pass);
}
if (req.http.Authorization || req.http.Cookie) {
/* Not cacheable by default */
return (pass);
}
return (lookup);
}
[/code]
見ての通り、認証時やクッキーが付いている場合はデフォルトではpass動作となりキャッシュされません。
VCLの記述をする際は、必ず自分の書いたコードの後にデフォルトのコードが付与されることを意識して書く必要があります。
全て自分の記述したコードで完結し、デフォルトの設定を動かしたくない場合は
必ずreturn(XXXX)で終わるようにしましょう。

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

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

[code=’C’]

static vcl_func_f *vmod_redirect_Hook_vcl_error = NULL;
static pthread_mutex_t vmod_redirect_mutex = PTHREAD_MUTEX_INITIALIZER;
static unsigned hook_done = 0;

static int vmod_Hook_vcl_error(struct sess *sp){

…. //write the processing

//call original vcl_error
return(vmod_redirect_Hook_vcl_error(sp));

}

int
vmod_location(struct sess *sp, int status, const char*p,…)
{
//vcl reload detection.
if(hook_done == 1
&& sp->vcl->error_func != vmod_redirect_Hook_vcl_error ) hook_done = 0;

if(hook_done == 0){
//lock to prevent another thread write
AZ(pthread_mutex_lock(&vmod_redirect_mutex));

if(hook_done == 0)
{
//store the original vcl_error pointer
vmod_redirect_Hook_vcl_error = sp->vcl->error_func;

//hook
sp->vcl->error_func = vmod_Hook_vcl_error;

hook_done = 1;
}
//unlock
AZ(pthread_mutex_unlock(&vmod_redirect_mutex));
}

….

return (status);
}
[/code]
(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.

5月 252012
 

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

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

[code=’plain’]
sub vcl_recv {
if (req.http.user-agent ~ “iP(hone|od)”) {
error 750 “Moved Temporarily”;
}
}

sub vcl_error {
if (obj.status == 750) {
set obj.http.Location = “http://www.example.com/iphoneversion/”;
set obj.status = 302;
return(deliver);
}
}
[/code]
このように一回エラー関数でvcl_errorに飛ばして判断する必要があります。
しかしvmod_redirectではvcl_errorに記述することなくredirectを実現しています。
[code=’plain’]
import redirect;
sub vcl_recv {
if (req.http.user-agent ~ “iP(hone|od)”) {
error(redirect.location(302,”http://www.example.com/iphoneversion/”) , “Moved Temporarily”);
}
}
[/code]
これはvcl_errorの関数ポインタをフックすることにより
オリジナルのvcl_errorが呼び出される前に独自の関数を呼び出すためです。

ではフックするためのポインタは何処に定義されているでしょうか?
vmodで使うsturct sess構造体(sp)に含まれています。
[code=’plain’]
vcl_errorの場合
sp->vcl->error_func

vcl_deliverの場合
sp->vcl->deliver_func
…
[/code]

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

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

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

[code=’C’]
static vcl_func_f *vmod_redirect_Hook_vcl_error = NULL;
static pthread_mutex_t vmod_redirect_mutex = PTHREAD_MUTEX_INITIALIZER;
static unsigned hook_done = 0;

static int vmod_Hook_vcl_error(struct sess *sp){

….//任意の処理を書く

//オリジナルのvcl_errorを呼び出してリターン
return(vmod_redirect_Hook_vcl_error(sp));

}

int
vmod_location(struct sess *sp, int status, const char*p,…)
{
//VCLのreloadでフックが外れた場合の検知
if(hook_done == 1
&& sp->vcl->error_func != vmod_redirect_Hook_vcl_error ) hook_done = 0;

if(hook_done == 0){
//別のスレッドが同時に書き込みをしないようにロックする
AZ(pthread_mutex_lock(&vmod_redirect_mutex));
if(hook_done == 0)
{
//退避先にオリジナルのポインタを保存
vmod_redirect_Hook_vcl_error = sp->vcl->error_func;
//フックする
sp->vcl->error_func = vmod_Hook_vcl_error;

hook_done = 1;
}
//ロック開放
AZ(pthread_mutex_unlock(&vmod_redirect_mutex));
}

….

return (status);
}

[/code]

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


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

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

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

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

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)

[code=’shell’]
varnishncsa -m “RxHeader:^Host: a.example.net$” -a -w /var/log/varnish/a.example.net.access_log -D
varnishncsa -m “RxHeader:^Host: b.example.net$” -a -w /var/log/varnish/b.example.net.access_log -D
[/code]

after request

[code=’shell’]
cat a.example.net.access_log
192.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)”

cat b.example.net.access_log
192.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)”
[/code]

work as expected.

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

3月 202012
 

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

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

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

今回はテストでa.example.netとb.example.netでそれぞれログを出力します
こんな感じで指定します
[code=’shell’]
varnishncsa -m “RxHeader:^Host: a.example.net$” -a -w /var/log/varnish/a.example.net.access_log -D
varnishncsa -m “RxHeader:^Host: b.example.net$” -a -w /var/log/varnish/b.example.net.access_log -D
[/code]
それぞれwgetを投げてみて出力されたのが以下です。

[code=’shell’]
cat a.example.net.access_log
192.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)”

cat b.example.net.access_log
192.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)”
[/code]
きちんと分かれているのがわかります。

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