@hirose31さんと、Apache HTTPDからHTTPSでファイルダウンロード中にサーバプロセスがSIGBUSで死ぬって件にぶちあたり、 「OpenSSLの中でmemcpyがSIGBUSしてます」「な、なんだってー!」 って調べたのですが、理由は以下のとおりだった。 HTTPSの場合、デフォルト設定だとファイル読込にmmap(2)が使われる mmapされたファイルのサイズが変更されてもApacheはそれを検知しようがない そして、ファイル末尾以降のデータを読もうとするとセグメンテーションエラー(SIGBUS)が発生し、Apacheのサーバプロセスは異常終了する HTTPの場合は、ローカルファイルシステムの場合sendfile(2)が使われるので、ファイルサイズが変更になってもApacheは異常終了しない ただし、mod_deflateのような出力フィルタを使っている場合は、HTTP
こんにちは、本社引っ越しから2か月経過し、ようやく新環境に慣れてきた tomita です。晴れてる日はスカイツリーがよく見えますよ~ さて、html や js ファイルに以下のような記述をする場合、 var API_URL = 'http://www.example.com/rest/api'; 開発環境では、 var API_URL = 'http://local.example.com/rest/api'; にしたい、って場合はままありますよね。 でも、都度ソースファイルや hosts を編集するというのは面倒ですし、最悪、開発環境のURLのまま本番環境にデプロイしちゃう可能性もあります。 ということで、apache の 機能の一つ、 mod_substitute を使って、ソースには手を加えず、違いを吸収したいと思います。 書き方は簡単で、httpd.conf や .htaccess
シンボリックリンク攻撃を防ぐための Apache HTTPD モジュールの解説はこちら: Apache HTTPD: mod_allowfileowner https://fumiyas.github.io/apache/mod-allowfileowner.html 背景 ロリポップの共有 Web サービス下のサイト改ざん事件で、 攻撃手法の一つとして 「他ユーザー所有のファイルへのシンボリックリンクを自分のコンテンツディレクトリ下に作り、Apache HTTPD 経由でアクセスする」手順が利用されたらしい。 参考: http://blog.tokumaru.org/2013/09/symlink-attack.html 当社サービス「ロリポップ!レンタルサーバー」ユーザーサイトへの第三者による大規模攻撃について http://lolipop.jp/info/news/4149/#090
人間とウェブの未来(旧) 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 これまでのApache2.2系以前でのアクセス制御の書き方は賛否両論でした。僕はあまり好きじゃありませんでした。 過去のアクセス制御に関しては、以下の記事がとてもわかりやすくまとめられていると思います。 こせきの技術日記 – Apacheのアクセス制御をちゃんと理解する。 ここで、以下のように言及されています。 こんなバッドノウハウ、本当はどうでもいいと思う。Apache 3.0では、かっこいいDSL(VCL)で書けるようにする構想があるらしいのでがんばってほしい。 ということで、2.4系ではDSLとはいかないまでも、Require*というディレクティブを使ったモダンな書き方ができるようになったので、それを2.2系以前のアクセス制御の記述と比
Apacheを起動するときに使う事もある apachectl の -k restart は stop && start ではないので注意しましょう。 ServerLimitやThreadLimitなどの一部の設定は、restart では適用されず、stop && start が必要になります。 apachectl は実はshellscriptで出来ています。中をのぞくと #!/bin/sh .. HTTPD='../httpd' .. start|stop|restart|graceful|graceful-stop) $HTTPD -k $ARGV ERROR=$? ;; と書かれています。restartはhttpdコマンドにそのまま渡されるようです。 そこでhttpdコマンドのドキュメントを読むと詳しくは Stopping Apache httpd http://httpd.apach
こんにちは、combinedログ撲滅委員会のひろせです。 ApacheのcombinedやNginxのデフォルトのlog_formatは、機械処理(日付でのソートやパース)がしづらい上に、人の目にもあまり見やすいフォーマットとはいえないと思っています。 なので自宅のサーバーでは、 日付は ISO8601 にする sortコマンドとかで簡単にそぉーっとソートできるようになる 日付、レスポンスコード、所要時間とか固定長的なフィールドは左に寄せる URLとかUAとか可変長で長いのは右に寄せる リクエスト(%r)も右に寄せた方ががいいような気がしてきた。。。 数値だけだとわかりづらいのでなんとなくわかるようにフィールド名も添える フィールド名を長くするとわかりやすくなる反面、ログサイズが大きくなるので注意 という観点で次のようなログフォーマットにしています、 # Apache LogFormat
Webアプリケーションのパフォーマンスをトラッキングするために、app serverの処理にかかった時間を記録したい。 方法を、以下のように分類できる。 1. reverse proxy側で、proxy先のapp serverがレスポンスを返してくるのにかかった時間をログに記録する場合 1.1 nginx 1.2 apache 2. app serverでリクエスト処理にかかった時間を出して、ログに記録する場合 2.1 reverse proxyで記録する場合 2.2 app serverでログに記録する場合 1と2とでは出てくる数字が違うだろうけど、本件に必要なのはパフォーマンス改善を示す一貫した指標なので、どっちでもいいと思う。 1. reverse proxy側で取る場合 1.1 nginx log_formatディレクティブに$upstream_response_timeという変数
最近は個人的にはnginxやnode-http-proxyを使うことが多くなってきましたが、phpを手軽に使いたいときとかhttpdもまだまだ使う機会は多いです。今日は新しいサーバの設定しながらふとTipsを一つ吐き出してみます。 Apache httpdで名前ベースで複数ドメインを管理する際、始めの頃はドメイン増やす度にVirtualHostディレクティブを1つずつ増やしていったりするんだけど、そのやり方だと数が増えてくるとコピペ修正ミスが出たりどんどん管理が大変になってきます。でもこれ実は VirtualDocumentRoot というディレクティブを使うと一つのVirtualHostで書けちゃいます。↓こんな感じ。 NameVirtualHost *:80 VirtualDocumentRoot /home/domains/%0/public_html Options All All
「ニフティクラウドユーザーブログ」は、移転しました。 自動でページを移動しない場合は、下記のリンクをクリックし、 新しい「ニフティクラウドユーザーブログ」をご覧ください。 今後とも「ニフティクラウドユーザーブログ」をよろしくお願いいたします。 > ニフティクラウドユーザーブログ
KLab Advent Calendar 2011 「DSAS for Social を支える技術」の9日目です。 前回は php を動かしている Apache の手前にリバースプロキシを 置く必要性を解説しました。 今日は、 その前の php のプロセス数を絞る設定と合わせて、実際に Apache で 設定する方法を紹介します。 以降、 php を動かしている Apache の事をアプリサーバー、リバースプロキシ+ 静的ファイル配信を行っている Apache の事をプロキシサーバーと呼びます。 基本設定 まずは基本的な設定のおさらいです。 アプリサーバー 並列数を絞るには MaxClients を設定します。アプリがどれくらいの時間を CPUの処理で使って、どのくらいの時間を外部リソース待ちに使っているかにも よりますが、だいたいCPU数の1.5倍〜2倍くらいが適当だと思います。 Hyp
small lightシリーズ [1] ライブドアのsmalllightを使って動的に画像をリサイズしてみる [2] いろいろsmalllightを使って動的に画像をリサイズしてみる [3] smalllightでのエンジンの選択の仕方 [4] smalllightでのエンジンの選択の仕方 (ヒントオプション追加) 最近、動的に画像をリサイズするのが流行っているようです。 ゆめみラボのmod_ktaiやクックパッドのmod_tofu、livedoorラボEDGEのsmall_lightなどいろいろありますが 今回small_lightを使ってみたので記事を書いてみます。 ついでに速いと噂のlibjpeg-turboも入れてみます。 smalllightとは 公式を見るのが一番早いとは思うので一度見てみてください。(→smalllight) 僕がsmalllightで特にいいなぁと思ったのが
Uncategories 100ドメイン以上を運用する企業向けクラウドのWebサーバー(Linux + Apache + mod_proxy_balancer ) こんちには、インフラチームのyanaです。 前回のPostgresに続きまして、実際に弊社のサービスで利用しているWebサーバーの ご紹介させていただきます。 Linux+Apacheの標準的な構成で、負荷分散と可用性維持のためにApacheの標準モジュールであるmod_proxy_balancerを利用したロードバランサーを導入しています。 上記の構成にした理由は、以下の3つです。 1.複数のFQDN環境でのSSL提供が可能である 2.拡張性や自由度がある 3.上記の2つを実現させ、低コストでの運用できる 1.複数のFQDN環境でのSSL提供が可能である 弊社のサービスでは、個人情報やクレジットカード情報を取り扱う場合があるた
先日、Web サーバ勉強会 #2 が開かれました。内容は、Apache のチューニングということで、参加したかったのですが、他の予定があって参加できませんでした。 そこで、僕が個人的に行っている Apache のチューニングを紹介したいと思います。最初、スライドで作成しようかと思ったのですが、ブログにまとめたほうがよさそうなのでブログにまとめていきます。 まず、大前提として Apache をチューニングするうえで、大事なことはその Apache が提供する Web サービスの種類のよって大きくチューニングする内容が異なるということです。例えば、動画・写真共有サービスと株価情報のサービスを比較すると、当然のことながら大きくサービスの内容が異なりますし、HTTP レベルでみるとクライアントからのリクエスト数、データサイズ、などがかなり違ってきます。 ですので、まずは自分が扱っているウェブサービ
Apache HTTP Serverの開発チームは8月24日、同Webサーバーの脆弱性を突くDDoS攻撃ツール「Apache Killer」が出回っていると警告した。該当するApacheは1.3系および2系の全バージョン。パッチ発行までユーザーはおのおので対応を講じるよう呼びかけている。 Apache KillerはFull-disclosureというメーリングリストで先週公開された。問題となっているのは「Range header DoS」と呼ばれる脆弱性。リモートから多数のRange指定を含むリクエストを送ることで、ターゲットシステムのメモリとCPUを消費させるというもの。バージョン1.3系および2系のすべてがこの脆弱性を持つという。デフォルト設定ではこの攻撃に対し脆弱で、現在この脆弱性を修正するパッチやリリースはない。Apache Killerではこの脆弱性が悪用され、多数のリクエスト
紹介したrpmのspecファイル、設定ファイル、オレオレpatchなどはすべてgithubにあります。 rpm: https://github.com/kazeburo/rpm/tree/master/httpd_proxy patch: https://github.com/kazeburo/apache-httpd-patch あわせて読みたい プロのサーバ管理者がApacheのStartServers, (Min|Max)SpareServers, MaxClientsを同じにする理由 mod_expiresでExpiresとCache-Controlを上書きする 再掲: mod_proxyのretryを2段階にするpatch PSGIアプリケーションをリバースプロキシ下で使う際の静的コンテンツの配信方法について \n\n\n紹介したrpmのspecファイル、設定ファイル、オレオレp
nginxやvarnishなどがアツいですが、Apacheもまだまだ実績や安定性から採用されていると思います。ここではデフォルトとは異なる値に変更するサーバ設定を中心に、パフォーマンス改善、安全性向上のためのApacheの設定を紹介します。 mpmの確認 > /path/to/bin/httpd -V Server version: Apache/2.2.19 (Unix) Server built: Jun 23 2011 17:13:13 Server's Module Magic Number: 20051115:28 Server loaded: APR 1.4.5, APR-Util 1.3.12 Compiled using: APR 1.4.5, APR-Util 1.3.12 Architecture: 64-bit Server MPM: Worker PreforkやW
気がする! なぜProxyPassReverseにbalancer://~~ を設定できないのか *1 なぜProxyPassReverseにajp://~~ を設定できないのか なぜbackendがhttpとajpの場合で、ProxyPassReverseに設定するURLが異なるのか などなど。今まではmod_proxyする機会がほとんどなく適当にお茶を濁していたので、世間の人から相当遅れているとは思いますが、せっかくなので自分用まとめ。思いついたことをつらつらとメモっているからかなり冗長ですが。 追記 20100907 http://ftp.riken.jp/net/apache//httpd/CHANGES_2.2 apache 2.2.12 から、balancer:// のURLにもProxyPassReverseが使えるようにmod_proxyがパワーアップしていました。 *)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く