2017/12/09(土)FreeBSD Ports のgnuplot は使い物にならなくなった・・・
2017/12/09 5:34
弊社では今まで gnuplot を安直に FreeBSD Ports コレクションからインストールしていたのですが、余計なものが依存関係で入って来るのが悩ましいところでした。
そこへいつものように FreeBSD Ports コレクションからアップデートを図ろうとしたところ・・・
なんと、X11 ライブラリ群がデフォルトで依存関係として入ってしまうようになったのです、、、
X11 サポートを外すことが出来なくなった。。致命的です。
弊社の環境では、単純にグラフが PNG や GIF,JPEG 形式で描画できれば十分で、X11 なんぞ邪魔！！！
ということで、止む無くソースコードから構築することにしたのです。
ちなみに現時点での最新は 5.2.2 です。
多機能な分、構築作業が複雑そうだなという先入観が強かったのですが、結局、
# setenv CPPFLAGS '-I/usr/local/include -I/usr/include' # setenv LDFLAGS '-L/usr/local/lib -liconv -L/usr/lib' # ./configure --with-readline=gnu # gmake # gmake installで、済むようです。FreeBSD 11.1R-p5 (amd64) の環境で確認しました。
注意点としては、gnuplot 本体をインストールする前に、libpng 等のグラフィックスライブラリ、readline ライブラリ、IPAやkochi等の日本語フォントを予め Ports などでインストールしておく必要があります。
-liconv オプションは、どういうわけか libiconv がリンク出来ないというエラーを吐いて構築が中断する状態になるので、その回避策として追記したという状態です。
2017/12/07(木)PowerDNS 4.1 リリース(with PostgreSQL)
2017/12/09 5:03
「久しぶりの記事がこれかい」と呆れられると思いますが。。orz
どうやら、今回の『売り』は、「当社比で PowerDNS 4.0.x から 最大で 400% 高速化した」ということらしいです。
単純に「4.0.4 の使用をやめて、セキュリティFIX された 4.0.5 以降にしなさい」という警告メッセージが出ていたのがきっかけなのですが。。orz
さて、PowerDNS 4.1.x に更新するにあたり、PostgreSQL を使用し、且つソースコードから構築する際の configure オプションが変更になっています。
PostgreSQL サポートに関しては、
--with-pg-config=/usr/local/pgsql/bin/pg_configこれだけでいけるようになったようです。
ちなみに弊社では、ソースコードから
# ./configure --enable-libsodium --with-pg-config=/usr/local/pgsql/bin/pg_config --enable-perl=yes --with-modules="bind gpgsql random"（実際には改行せず、１行で入力）のようにして構築しています。
環境は、FreeBSD 11.1R-p5 amd64版です。
2017/10/16(月)CGI に Python を利用し、PostgreSQL を使用する
2017/10/16 2:35
# cp mod_wsgi-4.5.20.tar.gz /usr/local/src # cd /usr/local/src # tar xvzf mod_wsgi-4.5.20.tar.gz # cd mod_wsgi-4.5.20 # ./configure --with-python=/usr/local/bin/python3.5 --with-apxs=/usr/local/apache2/bin/apxs # make # make install--with-apxs を指定することで、お使いのサーバにおける環境に合わせた構築が出来ます。 通常、mod_wsgi は、上記の場合、/usr/local/apache2/modules/ 配下に動的リンクでインストールされます。 Apache への mod_wsgi に対する設定は、以下を参考にどうぞ：
LoadModule wsgi_module modules/mod_wsgi.so
WSGIDaemonProcess cgi-bin user=webadmin group=webuser processes=1 threads=5
WSGIScriptAlias / /home/webroot/hoge/cgi/app.wsgi
<Directory "/home/webroot/hoge/cgi">
WSGIProcessGroup cgi-bin
WSGIApplicationGroup %{GLOBAL}
</Directory>
ちなみに WSGIインタフェース自体は、Python に特化する目的を持つものではありません。
この辺りは勘違いされている諸氏が結構多いようです。
Perl だと mod_perl という Apache に組み込む形での有名な高速化拡張モジュールがありますが、それと同じようなものでしょうか。
Python 以外では導入メリットが見えにくいです。
最近のPerl はそれ自身が高速化してきているので、mod_perl 導入のメリットが見えにくくなってきているのと、mod_perl を組み込んだ状態にてＣＧＩをスレッド動作させると原因不明の不安定な動作になったり、Perl 5.26 にすると、静的モジュールでは何故かインストールできないなど、色々問題があり、筆者のサーバでは mod_perl の利用は見合わせている状況です。
次に、Python から、PostgreSQL インタフェースを扱うモジュールをインストールするのですが、このインストールに先立ち、pip というサポートツール（？）を導入する必要があります。
Perl で言うところの CPAN に該当するものですね。
# python3.5 -m ensurepipあれ？ と思った諸氏も居られるかもしれません。 多くのサイトには「Python 3.4 以降では、pip は同時にインストールされる」と説明されているからですが、FreeBSD11 にて Ports から Python を導入した場合、pip は導入されません。FreeBSD11 にて Ports から Python を導入した場合、pip は手動操作で導入しないと駄目らしいです。 でも、pip は今後のメンテナンスで必須になるものの、今回は使いません。 最後に Python の PostgreSQLインタフェースモジュールをインストールするのですが、これもpip では環境誤認識をするため、ソースコードを持ってきて、下記の手順が確実です。 事前に、PostgreSQL 本体をインストールしておくことは言うまでもありませんね。
# cp psycopg2-2.7.3.1.tar.gz /usr/local/src
# tar xvzf psycopg2-2.7.3.1.tar.gz
# cd psycopg2-2.7.3.1
# setenv PATH '/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/pgsql/bin'
# python3.5 setup.py build
# python3.5 setup.py install
ここで重要なのは、pg_config コマンドのパスを、環境変数 PATH に含めることにあります。
Python の psycopg2 は、Perl における DBI と DBD::Pg の組み合わせに相当します。
2017/10/13(金)はんかくさい日報を新システムへ移行しました。
2017/10/13 5:11
しかし、見栄えは以前よりシンプルになってしまいました。
移行が何故か上手く行かず、更にデータの一部を壊してしまったため、
移行そのものを全て手動操作でやる羽目になり、足掛け３日掛かってしまいました。
また、手動操作移行の故、記事番号・記事URLが変わってしまい、Google 等への反映は１カ月程度かかるものと思われます。
2017/10/07(土)メールサーバへの攻撃事情
2017/10/12 22:20
こういう障害は２０年運用していて初めてのことでして・・・
どうも直接の原因は、これです。ＩＰアドレスも晒します。 ↓
52.166. 系のＩＰアドレスの登録上の使用者は、皆が誰でも知っている企業です。
調べればすぐ判るので、ここでは敢えて言及しません。
なんと、概ね 10秒毎にＳＭＴＰ認証を失敗しては繰り返しています。
文字列 'UGFzc3dvcmQ6' は、'Password:' を Base64エンコードして得られる文字列です。
ＳＭＴＰ認証も現在は数種類あって、これはセキュリティレベルが低いとされている LOGIN 認証と言われる種別。
サーバ負荷をこのようにして意図的に高くし、サーバ障害やサーバダウンを引き起こそうとする愉快犯か、何等かの意図を持っている連中の仕業です。
10/5 の 21:00 頃に、現在一緒に仕事をしている同業者がこのログを見て、 Twitter で呟いたそうです。
『○○社のネットワークから、メールサーバへの攻撃を受けている』と。
そうしたら、52.166. 系からの攻撃は「ピタッ」と止まりました。
これには余りの素早さに笑ってしまいましたね。勿論、対応された方々には感謝申し上げます。確信犯的にやっていたのであれば、逆に許せないですが。
で、今の攻撃主体はどうやら ↓ の模様。これもＩＰアドレスを晒しておきます。
間隔は４分毎ですが、攻撃と言えるレベルです。
時折「セキュリティ対策業者がセキュリティホール探しのためにやっている」なんていう話をする奴がいますが、ならサーバ負荷を意図的に上げるような行為を何故やる？ という 疑問が必然的に湧きますね。
SMTP サーバ自体の接続拒否機能は、SMTP認証処理成功後に機能するようで、認証前にＩＰアドレスや接続元ドメインなどで強制切断するようにはなっていないようです。
これをするには、ファイアウォールを使わないと駄目ですね。
この手の設定は、微々たるものだとしても傘下ネットワーク全体のパフォーマンス低下を招くので、出来れば余計なことはしたくない。
SMTP サーバ単体で、接続そのもの自体を拒否できる機能が欲しいと考えるのは自分だけでしょうか。
ま、発信元で犯人の処分をしてくれるのが最も有益なわけですが・・・
2017/08/28(月)powerDNS 4.0.4 は FreeBSD10 以降でソースコード構築途上でコンパイルエラー
2017/10/12 22:17
コンパイルを始めたばかりのところで、
ext/json11/json11.cpp:153:24: error: invalid operands to binary expression
('nullptr_t' and 'nullptr_t')
return m_value < static_cast<const Value<tag, T> *>(other)->m_value;
~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ext/json11/json11.cpp:209:5: note: in instantiation of member function
'json11::Value<json11::Json::Type::NUL, nullptr_t>::less' requested here
JsonNull() : Value(nullptr) {}
^
のようなエラーを吐いて構築不能になります。どうやら clang/LLVM 4.0.0 環境が少なくとも全滅です。
FreeBSD 11 はまさにこの環境。
% /usr/bin/clang -v FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0) Target: x86_64-unknown-freebsd11.1 Thread model: posix InstalledDir: /usr/bin日本語の情報が殆ど無いですね。
これは ext/json11/json11.cpp と ext/json11/json11.hpp の２つのファイルを修正することで解決します。
具体的な修正内容は下記リンクです：
json11 fixes from upstream via pdns #135それにしても日本人の感覚だと、この修正量と内容だとバージョンアップしてソースコード一式を再リリースするものですが、開発元であるオランダ人の感覚は違うようです。
https://github.com/PowerDNS/weakforced/pull/135/commits/9e4d9bd48663e849be13e2cb5fcf64f917aec608
2017/05/23(火)権威ＤＮＳ ― SOA レコードの記述方法
2017/10/12 22:15
SOA とは Start Of Authority を略したもので、
よく「権威の開始」を意味すると説明されます。
このあたりが、日本語での感覚と英語圏での感覚が合わなくてピンとこないのですが、要するにここでいう「権威の開始」というのは、「ゾーン情報を管理する権限を持っているこ とを明示する」ということになります。
ＳＯＡレコードは、BIND の設定ファイルに従うと、下記のような書式になります：
@ IN SOA ns.example.jp. postmaster.example.jp. (
17052301 ; Serial-No.
3600 ; Refresh
900 ; Retry
604800 ; Expire
1800 ; Minimum
)
以下、「マスターＤＮＳ」「スレーブＤＮＳ」「権威サーバ」等の用語は理解しているものとして記述していきます。これらの意味は１つ前の記事に全て記してあります。ひとつひとつのパラメータを理解しているようでよく解かっていないのではないかなと。
SOA レコードは実に７つのパラメータで成り立っています。
個々に示してみます：
MNAME [ns.example.jp.]
・マスターＤＮＳのホスト名。
・「完全修飾」という書式で通常、最後にもドットを付ける。
・CNAME レコードのホスト名は指定不可。ＩＰアドレス自体も指定不可。
RNAME [postmaster.example.jp.]
・連絡先の電子メールアドレス。
・「完全修飾」という書式で通常、最後にもドットを付ける。
・ＤＮＳの動作上使われることはないが、管理者同士の連絡先として使われることがある。
・記述の際、@ マークは . に置き換える。
SERIAL [17052301]
・ゾーンシリアル番号。符号なし 32bit長整数で保持される。
・ゾーン内容を更新したら、必ずこの番号を＋１以上更新する。
・０以上ならどのような値でも構わないのだが、更新日（作成日）を示す YYYYMMDDnn 或いは YYMMDDnn の形式が多い。
・4294967295 の状態で＋１すると 0 になるが、こういう場合の正常な動作は基本的に考慮されていないことに留意。
→ この場合は、スレーブＤＮＳを一旦停止し、該当ゾーンを含む保持データそのものを削除してから、スレーブＤＮＳを再起動するしかありません。 SERIAL を前回より小さい番号にした場合も同様の対処です。
○ 以下３つはスレーブＤＮＳの挙動を指定：
REFRESH [3600] 〔単位：秒〕
・当該ゾーン情報をリフレッシュする間隔。
・スレーブＤＮＳは、マスターＤＮＳからのゾーン転送処理を受け入れたあと、ここで指定した時間経過すると、マスターＤＮＳへゾーン情報更新問合わせを行い、シリアル番号 が更新されていたら適宜更新処理を行う挙動になる。
RETRY [900] 〔単位：秒〕
・リフレッシュがマスターＤＮＳや回線障害など原因で上手く行かなかった場合、リトライを試みる間隔。
・従って、REFRESH で指定する値よりも小さな値でないと意味がなく、通常は、REFRESH の整数分の１の値とする。（この例では４分の１）
EXPIRE [604800] 〔単位：秒〕
・ゾーン情報のリフレッシュができない状態が続いた場合、スレーブＤＮＳにて、ゾーン情報を最後にリフレッシュが成功してから保持を可能とする時間を示す。
・従って、REFRESH の整数倍で無いと意味がなく、２週間から４週間が適切とされている。（この例では７日＝１週間）
○最後の１つはキャッシュＤＮＳの挙動を指定：
MINIMAM [1800] 〔単位：秒〕
・このパラメータは Negative cache TTL とも呼ばれる。
・各レコードのデフォルトキャッシュ保持時間を指定する。
・値が小さいほど臨機応変に権威サーバにおける保持情報に追従できるが、ＤＮＳの負荷が上がるため、60 ～ 3600 の間で適宜指定されるのが実態である。
・また、レコードに存在しない情報の問い合わせを受けた場合、'NXDOMAIN' （情報なし）という回答をするが、キャッシュＤＮＳは「情報なし」もここで指定した時間だけ保持する挙動になる。
以上、参考にどうぞ。
ダイナミックＤＮＳを運用している場合、MINIMAM は 60 を指定するのが通例の設定のようです。ホストの増減が多い環境では MINIMAM は 600、比較的変化が少ない環境では 1800 や 3600 という設定が多いようです。
2017/05/15(月)権威ＤＮＳとキャッシュＤＮＳの分離をしました
2017/10/12 22:13
ＤＮＳをいじるので、工程途上で作業ミスがあると傘下のネットワーク運用への影響が大きいため、１年近くやりたくてもできない状態だったので、出来る時にやってしまおうとい うことで。。
権威ＤＮＳとかキャッシュＤＮＳとか判らない方々も多いので、基礎的な解説を交えていきます。
変更前は以下のような単純な構成でした：
これは、弊社管轄ドメインのネームサーバとして、レジストラに登録しているサーバになります。
レジストラに登録するサーバは、「権威サーバ」となる種別のＤＮＳでなければなりません。
では、「権威サーバ」と「キャッシュサーバ」の違いは何？ というところですが・・
「権威サーバ」とは、ドメイン各種情報の原本を持つサーバ、
「キャッシュサーバ」とは、探索したドメイン情報の写しを持つサーバ
を言います。
従来のＤＮＳは、「権威サーバ」と「キャッシュサーバ」が一緒で、ＤＮＳのサーバソフトウェアで有名な BIND が以前は「権威サーバ」「キャッシュサーバ」と区別する概念が 無く、最初から両方使えるようになっているので、このあたりが混乱を来す要因になっています。
さて、「権威サーバ」には更に２種類あって、
かつては本当の原本情報を持たせるサーバを「プライマリＤＮＳ」
原本情報の複製を保持するサーバを「セカンダリＤＮＳ」と言っていました。
最近では、
「プライマリＤＮＳ」は「マスターＤＮＳ」とか「マスター権威ＤＮＳ」、
「セカンダリＤＮＳ」は「スレーブＤＮＳ」とか「スレーブ権威ＤＮＳ」とかいう言い方が主流になってきているようです。
ちなみに、「キャッシュＤＮＳ」には「プライマリ」「セカンダリ」あるいは「マスター」「スレーブ」の区別も概念もありません。
さて、「マスターＤＮＳ」も「スレーブＤＮＳ」も「権威サーバ」の位置づけなので、レジストラに「ネームサーバ」として登録できます。
「マスターＤＮＳ」か「スレーブＤＮＳ」かの種別は問いません。「権威サーバ」であることが重要です。
「マスターＤＮＳ」か「スレーブＤＮＳ」かの種別は問いません。「権威サーバ」であることが重要です。
弊社では、ＤＮＳ関係は下記のような構成にしました(2017/05/08より)：
最近はこのような構成がやや強めにお勧めされています。
使用するＤＮＳソフトウェアは何でも良いのですが、弊社での環境的事情や BIND の相次ぐセキュリティアラートに加え、常用の FreeBSD にて BIND が標準提供から外された(BIND 10 から Python ベースになったのが主たる理由）のに辟易して、PowerDNS,nsd,unbound という構成を採用した次第です。
「hidden マスターＤＮＳ」とは、その名の通り、マスターＤＮＳを公開ネットワーク上から隠しています。
こうすることで、ドメイン原本情報に「毒」が外部から入ることを防ぐセキュリティ対策が出来ます。
レジストラへのドメイン登録はネームサーバが最低２つ要るため、２つのスレーブＤＮＳを稼働させます。このスレーブＤＮＳは自前ですが、費用面さえ許す環境ならば、他社サー ビスの利用でも良いでしょう。
同じくキャッシュＤＮＳも２つ用意します。これは最低でも１つあればいいです。
逆に３つ以上キャッシュＤＮＳを指定できるアプリケーションはあまり見かけませんね。
キャッシュＤＮＳは「ドメイン情報探索専用」のサーバです。
「権威ＤＮＳ」とは物理的に別のサーバとし、利用を許可するネットワークを限定することがコツです。
「権威ＤＮＳ」はＣＰＵ負荷はあまり重くならないので、Raspberry Pi 等の活用も可能です。
キャッシュＤＮＳで特殊なのは google の 8.8.8.8 とか 8.8.4.4 とかで、これはオープンＤＮＳとかオープンリゾルバとか呼ばれ、誰でも使用できる代物ですが、負荷分散の意味 で、キャッシュサーバを用意しない場合や、用意できない場合、出来る限り加入しているプロバイダで指定されているネームサーバを使うことをお勧めします。