クロネコメンバーズのポイント
pcregrepとGNU grepの-P
先日pcregrepを紹介したが､grep -Pもあるとコメントで教えてもらった｡
(色々と調べるきっかけにもなりました､南の島さんありがとうございます)
GNU grepではpcreサポートも実装されているようで､以下のようにmanにも記載されていた｡
-P, --perl-regexp
Interpret the pattern as a Perl-compatible regular expression (PCRE). This is highly experimental and grep -P may warn of unimplemented features.
この前はmacのmanをみてしまったので気づかなかった｡｡｡(macはGNU grepではない)
と､ここで違いが気になってきたので少しだけ出自を調べてみた｡
pcregrep
pcregrepはpcre.orgで配布されているpcreライブラリに付属している｡
そもそもpcreとはperl5互換の正規表現ライブラリのことで､perl5で使える正規表現をAPIとして提供するライブラリがlibpcreということのようだ｡
perlはlibpcreを使っておらず､厳密にはlibpcreとperl5の正規表現は少し違うようだ｡
Perl Compatible Regular Expressions - Wikipedia
ということで､pcregrepはGNU grepとはまた別の開発主体によってメンテナンスされている､あくまでクローンということだと思う｡
(GNU)grep -P
GNU grepは言わずとしれたGNUのソフトウェアで､linuxでは基本的に利用できると思って間違いないと思う｡
GNU grepには-Pオプションがあり内部的にはlibpcreを使っているようだった｡
つまりオプション解析や出力の処理などはいつも使っているgrepそのままで､マッチング処理にlibpcreを用いることができるということのようだ｡
この-P自体はPOSIXで定められていないようなので､あくまでGNU grepの独自拡張ということになると思う｡
そのため､mac等､非GNUのgrepを使っているOSでは利用できなさそうだ｡
まとめ
結局はlibpcreが処理するようだ｡じゃあpcregrepを覚えておけばOKかな?と思ったあなた｡間違いです｡
libpcreは確かに多く使われているが､それが当たり前ではない環境もあるので､
少しでも多くの環境をサポートするならperlを使えと言われている｡
世間は厳しい｡
と､半分冗談は置いておいて､以下は自分なりに考えた結果｡
linuxで生活しているならならgrep -Pが良いと思う｡なぜならGNU拡張オプションが使えるので色々と楽だろう｡
pcregrepは普段使いするわけではないので細かい挙動が違い､細かい場面でハマる可能性がある｡
一方､macも使っているならpcregrepになると思う｡brewなどでggrepを入れても良いとは思うが､結局コマンド名が変わるのはわかりにくい｡
軽く使ってみている限りはpcregrepでも全く問題はないので､
凝った正規表現を使うならpcregrepで統一するというのは現実的だと思う｡
ということで､両方頭に置いておいて､状況に合わせてうまく使えるようにしておきたい｡
眠気と日曜
眠い時、どうやって乗り切るのが一般的なんだろう。
どうしようもなく眠いが寝てはいけない時がある(主に仕事)
寒い時期は暖房が効いているせいかせいか眠気がひどく、気をぬくと落ちそうになる。
特にオチや役立ち情報もなし、ただの困っていること、しかもそれほど大したことないものをカミングアウトするだけでした。
SummitDB
SummitDBはredisのようなin-memory dbだが、raftによるクラスタリングとACIDをもつdatabase。
JSONデータを保存することができ、任意のインデックスによる検索もできそうだ。
mongodbに近い使い方もできるように見える。
また、クラスタリングの挙動はstrong-consistencyとのことで、redisやmongodbはeventually-consistencyなのでクラスタ動作が異なるということになる。
自分の理解では - eventually-consistency - 複数台によるクラスタにおいて、アクセス先/タイミングによって古いデータが見えることがある - strong-consistency - 複数台によるクラスタにおいて、どのノードにアクセスしても同じデータが見える
という挙動で、可用性とパフォーマンスはeventually-consistencyに分がある。
KVSではeventually-consistencyが採用されることが多い印象なので、SummitDBは他にない特性をもつDBということになりそうだ。
また、APIはredisと一部互換のようなので、redisのリプレースとして使える可能性がある。
用途によってはハマるケースがありそうなので選択肢として覚えておきたい。
tcpdump 4.9.0
システムのパッケージをあげようとしたら、珍しくtcpdumpが現れたのでちょっと気になった。
changelogでも読もうかと www.tcpdump.org にアクセスしてみたが、なぜか4.9.0が見つからない。
でも手元でtcpdump –helpすると4.9.0と出ている。
気になったので少し追ってみた。
まず、この4.9.0はどこから来たのかを追った。
arch linuxを使っているのでarch linuxのパッケージ管理の中身を見ればソースをどこから取得しているのかわかる。
svntogit/packages.git - Git clone of the 'packages' repository
を見ると、
http://www.tcpdump.org/4.9.0-u82xFZBjZxWv/
というパスから取得している。
過去のリリースを取得しようとブラウザでリンクを辿っていくと
http://www.tcpdump.org/release/
が登場するので、4.9だけ特別扱いらしい。
ここで一旦手がかりが付きたので、ML等にリリースアナウンスが出ていないか調べてみた。
検索していると
が引っかかってきたので中身をみると、
このリリースはセキュリティの修正らしく、やり取りが公開されていないような感じだった。
賛否あるようでissueもlockされている、要するに悪用できるようなものだったという事だろうか。
バックアップとは
GitLab.com Database Incident - 2017/01/31
gitlab.com の障害。
操作ミスでDBのファイル削除で障害。
まぁここまではよくあるが、ここからがつらい。
24時間単位でLVMスナップショットがあるはずが設定ミスで存在せず、今までバックアップは動作していなかったとのこと。
幸い6時間前に手動で取ったデータがあったそうでそこから復旧しているようだ。
リポジトリのデータはここに含まれないとのことなので、影響範囲自体はそれほど広くないと思われる。
バックアップはリストアまで含めて確認しておこうというのはよく言われるが、なかなか徹底は難しい。
運用レベルが低かったと言われてしまうのはしょうがないが、この類のミスを非難するのはつらい。
