受信しているはずのUDPパケットをアプリケーション側では受け取れない（Redhat6） - Jの衝動書き日記
お仕事でハマった事例があったので、メモを残しておく。 問題詳細 解析 原因 解決方法 メモ 問題詳細 以下のような事象が発生した。 負荷分散サーバ（LB）上で動作するアプリケーション（AP1）は受信したUDPパケットを負荷分散先（S1）に送信する。だが、 S1上で動作するアプリケーション（AP2）はそのパケットを受け取れなかった。 S1上でパケットキャプチャした結果、LBから送信されたパケットはS1上で受信できるのは確認できた。しかし、AP2ではそれを受け取れない。 一方、AP1で中継させずにLBから直接UDPパケットをS1に対して送信すると、AP2はこれを受け取れる。 図にすると以下のような感じになる。 解析 S1上には複数のIFが存在し、そのうちの一つのIF(bond3)に設定されたIPアドレスに向けてAP1はパケットを送信している。一方AP2は、S1上のすべてのIFに対してUDPポー
rp_filter が静的ルーティング下の traceroute に及ぼす影響 - とあるSIerの憂鬱
静的ルーティングを設定した Windows と Linux (RHEL6.4) で、それぞれ tracert と traceroute を実行したとき不思議な差が出た。解明までのプロセスが自分の好みにドンピシャだったので順を追って書く。 環境 環境を大まかに書くと下図のようになる。外部との通信用のデフォルトゲートウェイと、内部のシステムである targethost と通信するための内部ネットワークに接続するゲートウェイ A がある。Windows Server 2012 のサーバと RHEL 6.4 のサーバそれぞれに、targethost 向けの静的ルートを入れ、ゲートウェイにはゲートウェイ A を設定した。 設定が終わったので、「さて、正しいルートを通っているかな♪」と tracert と traceroute を叩く。すると違いが。 Windows Server 2012 での実行結
KeepalivedによるロードバランサLVS構築 - RLB
LVS構築における最強の手順書を残してみました。 はじめに ロードバランサ（LVS）の需要は間違いなくあると思うのですが、いかんせんネットに情報が少ない。 かの有名な「サーバ/インフラを支える技術」が出版された2008年あたりがピークの感がある。(Klabさんの記事には大変お世話になりました) Googleで調べてもまとまった情報がなかったりするので、最初は大変でした。 普段インフラ周りで仕事しているので、そこで培ったノウハウを出したいと思います。マイブログ史上最大の情報量。 今回は「CentOS6.4 x86_64マシン」に「最新版keepalived-1.2.7を導入」で「割りと本番運用に耐えられる手順」を解説。もちろん定番のIPVS + Keepalived のDirect Server Return(DSR)構成。 ※是非コメント欄でもさらに有益な情報がありましたら歓迎です。 内容
GitLabのスロークエリを駆逐するマージリクエストを送りました - catatsuyとは
GitLabにマージリクエストを送ってみました。 gitlab.com 以前の経験からGitLabの開発チームはGitHubはほぼ見てないことを知っていたのでGitLabから送ってみました。 catatsuy.hateblo.jp ちなみに上のエントリに出てくるGritが使われている箇所は現在ではすべてRuggedに書き換わっているので状況は変わっています。 マージリクエスト送った！ / “'created_at DESC' is performed twice (#825) | Merge Requests | http://t.co/LLbgkxK7A7 / GitLab Comm…” http://t.co/F91TCk67US— 健康診断@4/26 (@catatsuy) 2015年6月16日 GitLabの人たちはGitHub見てないのでちゃんとGitLabから送った— 健康診断
C++11: Syntax and Feature
C++11の文法と機能(C++11: Syntax and Feature) Copyright (C) 2013 江添亮. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GN
RDBにおけるキャッシュという考え方
RDBの専門家として日々活動している中で気づいたことのひとつに、「RDBはデータへのアクセスの実装をインデックスに頼っているが、インデックスは全ての問題を解決できるほど万能ではない」ということがある。インデックスというのはとても強力な部品であり、その点には全く異論はない。だが、世の中の全ての問題（クエリ）を解決できるほど、柔軟性に富んだものではないということだ。RDBは、どのインデックスを使ってデータへアクセスするかということを、オプティマイザを用いて判断する。大抵のRDB製品では、オプティマイザはよい仕事をするので、インデックスとオプティマイザの組み合わせによって、ほとんどの問題に対応できる。だが、100%ではないのであり、そのようなケースがシステムの性能問題を引き起こしたり、プログラマ（アプリケーションの設計者）に、NoSQLへ完全に移行したり、クエリ高速化のために非正規化をすると言っ
Atrae Tech Blog — サーバの管理をItamaeでやったら楽だった
We are the tech members of Atrae Inc. This tech blog contains awesome information around tech of our concern. こんにちは、エンジニアの青野です。 最近サーバを新しく数台セットアップする機会があり、その管理にItamaeを使いました、という話です。 itamae-kitchen/itamae セットアップの手順はある程度ドキュメント化されていました。 が、コード化してGitHubに置いたほうが変更の履歴も追えるし暗黙知化もしにくいはずなので、 プロビジョニングツールを利用することに。 弊社のサービスはRailsで構築されているものがほとんどです。 Rubyの記法で書けるChefとItamaeを候補として考えましたが、結局後者の導入を選択しました。 Chef有名なので特に説明はしません
ping をある IP アドレスの範囲に対して実行したい - はちゅにっき
IPアドレスの割り当て範囲は分かってるんだけど 実際にどのIPに端末がつながってるか知りたい！ DHCP の割り当てログもない、Perlも使えない、OSはWindows。 Linux (bash / zsh) であれば、↓ な感じで調べるのに！ for ((i = 100 ; i <= 254 ; i++)); do ping -c 1 192.168.0.${i}; done そんなときに頼りになるのは、きっとコマンドプロンプト！ そんなワケで こことか見て for /l %v in (100,1,254) do ping -n 1 192.168.0.%v という方法にたどり着きました。 細かいことはリンク先にありますが、一応。。。 /l 範囲指定を有効に %v 変数 v (名前任意の一文字) (100,1,254) 100 から増分 1 で 254 まで という意味みたい。 他も見て
本当に PHP の DoS 脆弱性 (CVE-2015-4024) キツくない？ - はちゅにっき
hakaikosen.hateblo.jp 上記記事を「あら大変(棒読み)」とか思いながら読んでいたけれど、PHP の BTS の方を読んでみたら確かに原理から再現手順まで細かく記載されていて 「なんかこれまずそう」と思ったので、docker を使って検証してみることに。 PHP 入りの Docker コンテナは、Official のものを利用しました。registry.hub.docker.com 今回の脆弱性、POST しないページには関係ないのかな？と思ってましたが、よくよく見ると PHP さえ動くページであればなんでもいいらしい。 ということで以下のような PHP ファイルを用意し、ここにアクセス (攻撃) をします。 htdocs/index.php <!DOCTYPE html> <html> <head> <title>PHP Bugs #69364</title> </he
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Life with IT