blogzine.jp
Data Where You Need It Apache CouchDB ™ lets you access your data where you need it. The Couch Replication Protocol is implemented in a variety of projects and products that span every imaginable computing environment from globally distributed server-clusters, over mobile phones to web browsers. Store your data safely, on your own servers, or with any leading cloud provider. Your web- and native a
2007年7月4日 名前ベースのVirtualHostでそれぞれのSSLサーバ証明書を使う #なんだかんだしてたら、半月経ってしまった #来週になったら、ちゃんと再開 『Name-based SSL virtual hosts』 より 名前ベースのVirtualHostでSSLを使う場合、以下の方法をとれば、それぞれのVirtualHostごとの証明書を使うことができます。 ワイルドカード証明書を使うCN=*.example.com という設定の証明書を使えば、www1.example.com と www2.example.com で共通のサーバ証明書を使うことができます。 subjectAltNameを使う 証明書の subjectAltName に別名としてVirtualHostのDNS名を書いておきます。サーバにセットする証明書は1つですが、証明書内の別名をチェックすることで、「証明
cles::blog 平常心是道 blogs: cles::blog NP_cles() « この仕事には、過酷なバグに負けない心が必要です :: 髪をhackしました » 2007/07/07 SSLでName Based Virtual Hostをするには httpd ssl rfc 212 3へぇ もう4年位前になりますが、あるサイトのリリース前夜にSSLでName Based Virtual Hostを設定しようとしていてはまっていたエンジニアにそれができないことを教えてあげて、とても感謝されたということがありました。この件は今でも飲み会などでネタになるくらいの出来事だったので、自分自身にもそれが成功体験として残ってしまっていて「SSLでName Based Virtual Hostは使えない」とステレオタイプに考えてしまっていたんですがその知識はどうやら正確ではなかったよう
バージョン管理システムにはCVSやsubversionなど様々なものがありますが、サーバーのセットアップに抵抗がある人もいるのではないでしょうか? しかしながら実際のところ、パッケージ化されているので驚くほど簡単にできてしまいます。 今回は、もっとも簡単な手順でSubversionのレポジトリサーバーを構築する方法を紹介したいと思います。 動作環境 今回の手順の動作環境は下記のとおり。OSをインストールしたままの、まっさらな状態を想定しています。 OS Debian Linux etch Protocol http Web Server Apache2.2.3 それでは早速いきましょう。本当に10分間で構築できます。 パッケージのインストール 下記の作業はすべてrootで作業をするものとします。(まっさらな状態を想定しているため、sudoは利用していません。) それでは必要なパッケージをイ
忘れないうちにメモしとこっと φ(..) ■libapache-mod-dav のインストール。 # aptitude install libapache-mod-dav ■日本語ファイル名が文字化けしないように,libapache-mod-encoding のインストール。 # aptitude install libapache-mod-encoding ■/etc/apache/modules.conf の確認。 LoadModule dav_module /usr/lib/apache/1.3/libdav.so LoadModule encoding_module /usr/lib/apache/1.3/mod_encoding.so ■/var/www にdavというディレクトリを作る。 # mkdir /var/www/dav # chown www-data:www-dat
IT人材問題をアウトソーシングで解決し、給与業務から本格的なDXを前に進めませんか? ~1000名までのお客様 給与DX 未来の課題解決は給与から! 詳細はこちら 100~300名までのお客様 給与DX for 奉行 給与DXの前にご確認。こんなことになってませんか・・・ 詳細はこちら 給与アウトソーシング IT活用×業務プロセスアウトソーシングで 定型業務のお悩みをまるごと解決! 詳細はこちら DXサポーター 給与とITを本業として20年のエムザスが御社のデジタル化(DX)をサポート致します。 詳細はこちら 20年以上にわたる給与BPOのノウハウから、ミスしないサービスをご提供します。(4000名まで対応) 社会保険 各種手続きデータ管理はもちろん社員様問合せ対応等もお任せください。 詳細はこちら 住民税 テレワーク稼働中の住民税更新業務、エムザスにお任せください。 詳細はこちら 年末調
http://blog.livedoor.jp/nipotan/archives/50538571.html を読むとmixiではsquidが一部で使われているようだ.具体的にどこで使われているかはわからないけれど, 当然我々もsquidには目をつけていてapacheのmod_proxyとの比較検討を行ったことがある. その結果squidはスケーラブルな配信サーバを構築するのには向いていないという結論になった. それはこんな理由による. 1. キャッシュされたファイルのインデックスデータとメタ情報をメモリに置くのが無駄 squidはキャッシュされたファイルのインデックスデータとメタ情報をメモリに置く. よって画像が増えれば増えるほどインデックスが大きくなりすぎて,本来使用したい ファイルシステム用のバッファキャッシュが食いつぶされてしまうという結果になった. 実際某サイトでは数十万URL程
Proxy Balancerの使い方 Apache 2.2 から実装されたプロキシバランサを、左図のような構図で使うことを想定する。リバースプロキシはユーザ(インターネット) からの全ての http リクエスト と https リクエストをロードバランスして実サーバ 1, 2 へ振り分ける。 https の場合は、リバースプロキシがリクエスト内容の暗号化をほどいてから実サーバ (バックエンドサーバ) に HTTPリクエストを送る。つまり SSLキーはリバースプロキシにだけ置いておけばいい。 このやりかたでは、実サーバのドキュメント空間をリバースプロキシのローカルドキュメント空間に割り付ける (概念的には alias に近い) イメージになるので、帰りのトラフィックもリバースプロキシを通る。 SSL通信の場合、実サーバからリバースプロキシへは平文でレスポンスが返され、リバースプロキシがそれを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く