ポッピンQネタバレ感想 - クソガールのための物語
この文章は、2016年12月23日に公開された劇場用アニメ映画「ポッピンQ」について感じたことを書いたものです。どうしても本編を視聴した上での感想になりますので、ネタバレを忌避される方はお気をつけください。
続きを読むRHEL7/CentOS7でsyslogを全て出力するにはどうするか
RHEL7/CentOS7 では、御存知の通りsystemdが導入されています。この影響でログ関連も大きく構成が変わっています。まぁまずマニュアルの18章を読みましょうね。
第18章 ログファイルの表示と管理
とりあえず、標準構成ではだいたい以下のフローで動くと思っていれば特に問題ないと思います。
- 全ての Syslog メッセージはまず journald にキャッチされ、構造化された Journal データとして保持される。
- rsyslogd は、imjournal モジュールを利用して journald から必要なログを取得し、/var/log/messages や /var/log/maillog などに出力して永続化する。
ただ、標準設定のままだと困ったことがあって、上記の1と2の両方でログの流量制限が施されています。システムの保護という点ではよいのですが、デフォルトは結構キツめの制限なので、メールログなんかは割りとすぐ上限に達してしまいます。必要に応じて緩和しましょう。
journald の制限
journald の制限は、RateLimitInterval と RateLimitBurst によって決まります。以下、man journald.conf より。
- RateLimitInterval=, RateLimitBurst=
- Configures the rate limiting that is applied to all messages generated on the system. If, in the time interval defined by RateLimitInterval=, more messages than specified in RateLimitBurst= are logged by a service, all further messages within the interval are dropped until the interval is over. A message about the number of dropped messages is generated. This rate limiting is applied per-service, so that two services which log do not interfere with each other's limits. Defaults to 1000 messages in 30s. The time specification for RateLimitInterval= may be specified in the following units: "s", "min", "h", "ms", "us".
To turn off any kind of rate limiting, set either value to 0.
RateLimitInterval で指定した期間に RateLimitBurst を超える量のメッセージがあると破棄されます。デフォルトでは30秒あたり1,000メッセージ*1に制限されています。破棄されたメッセージの数は Journal には記録されており、 journalctl コマンドで確認することができます。必要なログの量を見積もって、適切な値を設定しましょう。
なお、いずれかの値を0にすると、破棄せず無制限に記録するようになるようです。よくわかんないのであれば無制限にしておけばいいのではないでしょうか。（投げやり）
rsyslogd の制限
rsyslog の制限は、$imjournalRatelimitInterval と $imjournalRatelimitBurst で決まります。以下、RedHatのドキュメントより。
18.6. Rsyslog での構造化ロギング
Journal から Rsyslog にデータをインポートするには、/etc/rsyslog.conf で以下の設定を使用します。$ModLoad imjournal $imjournalPersistStateInterval number_of_messages $imjournalStateFile path $imjournalRatelimitInterval seconds $imjournalRatelimitBurst burst_number $ImjournalIgnorePreviousMessages off/on（中略）
seconds では、レート制限の間隔を設定します。この間隔内に処理されるメッセージ数は、burst_number で指定して値を超えることはできません。デフォルト設定は、600 秒あたり 20,000 メッセージです。Rsyslog は、この指定された時間枠内で最大バースト後に届いたメッセージを破棄します。
だいたい書いてあるとおりで、考え方は journald と同じです。rsyslog のマニュアルによれば、$imjournalRatelimitInterval を 0 にした場合は無制限になるようです。よくわかんないのであれば無制限にしておけばよいのではないでしょうか。（投げやり）
imjournal: Systemd Journal Input Module — rsyslog v7-stable documentation
- ratelimit.interval seconds (default: 600)
- Specifies the interval in seconds onto which rate-limiting is to be applied. If more than ratelimit.burst messages are read during that interval, further messages up to the end of the interval are discarded. The number of messages discarded is emitted at the end of the interval (if there were any discards). Setting this to value zero turns off ratelimiting. Note that it is not recommended to turn of ratelimiting, except that you know for sure journal database entries will never be corrupted. Without ratelimiting, a corrupted systemd journal database may cause a kind of denial of service (we are stressing this point as multiple users have reported us such problems with the journal database - - information current as of June 2013).
- -ratelimit.burst messages (default: 20000)
- Specifies the maximum number of messages that can be emitted within the ratelimit.interval interval. For futher information, see description there.
その他
なんらかの理由でレガシーな syslogd を使う場合は、journald の ForwardToSyslog オプションを使って、journald がキャッチした Syslog メッセージを更に他の syslogd に転送する必要があります。このオプション、7.0/7.1ではデフォルトで有効になっているのですが、7.2で一旦無効化されている*2*3ので、この場合は journald.conf を編集して有効にする必要があります。
ForwardToSyslog=yes
ただし、ForwardToSyslog での転送は失敗することがあります。この場合も Journal には失敗したメッセージ数が記録されます。この辺りになると RedHat のサポート範囲外でもあるので、RHEL7/CentOS7 では、あまりレガシーな syslogd に拘らないほうがいいような気がします。
*1:systemd のバージョンによって異なる可能性がありますので、システムの man journald.conf をご参照ください
*2:システム負荷の懸念から systemd 216 で無効化され、これ以降のパッケージをインストールしている場合は影響を受けます。ただ、その後 219.20 でRHEL向けには再度有効化されたので、将来的にはまた有効になりそうです。
*3:Bug 1285642 – journald.conf - changed default for ForwardToSyslog parameter
家庭用小型結束機 しめしめ45-IIは神である
しめしめ45IIとは仁礼（ニレイ）工業株式会社家庭用小型結束機である。商品説明にそう書かれている。神ではない。
だがしかし、雑誌やダンボールを相手にビニールテープやハサミを持って悪戦苦闘するあの責め苦から、しめしめ45IIはその身ひとつで救済してくれる。神である。
おそらくすでに世界中に信徒はいるはずだが、あまり布教活動を見かけたことがないので布教したい。
見た目は複雑そうな神だが、基本的な使い方は以下の流れになる。
- 先端に装填されているクリップ穴を通しながらベルトを引き出し、結束したいものに巻きつける。
- 巻きつけたベルトをクリップに戻して固定し、余ったベルトを巻き取る。
- クリップの手前にあるカッターでベルトをカットする。
というか公式サイトに説明動画があるのでこっちを見ればよい。事前の準備から説明してくれている。神は慈悲深い。www.nirei.co.jp
クリップにツメ、ベルトにミゾが刻まれているのがポイントで、行きのベルトと戻りのベルトの厚みがクリップ内部で重なると、巻き取り方向にしか引き出せないようになっている、そうして固定したうえで、がっちり締め付けていくという寸法だ。
このしめしめする時の結束感はたまらないものがある。抵抗できないベルトを一方的に巻き取っていくのも気持ちいいが、現行のしめしめ45IIにはベルトを更に巻き取るための増し締めレバーが実装されており、レバーをシュコシュコしながら結束の限界までしめしめすることができる。この気持ちよさは神でなければ経験できない。
とはいえ神にも難点はある。
神からベルトを引き出すときには、ちょっとした慣れが必要である。行きのベルトがクリップのツメにひっかかってしまい、うまく引き出せなくなることがあり、それでも無理に引き出そうとすると、ツメが破損してクリップがひとつおしゃかになってしまう。
説明書に書かれている通り、ミゾのない上向きに引き出すことを意識すれば失敗はしにくくなるのだが、慣れないうちはなかなか難しく、ツメが破損したのに気付かず引き出してしまうことがしばしばあった。
あからじめベルトが上向きに反るようになっていたりと工夫はあるものの、もう少し改善してほしいところである。
とはいえ、こんな難点は慣れで解決できるものだ。信じ続けたものは救われる。
何よりしめしめするのが気持ちいいのでとてもオススメ。
PHPのDoS脆弱性(CVE-2015-4024)キツくない？
2015/05/14にリリースされたPHP 5.4.41/5.5.25/5.6.9で修正されたDoS脆弱性がある。
Fixed bug #69364 (PHP Multipart/form-data remote dos Vulnerability). (CVE-2015-4024)
バグレポートに細かい話（原理から再現手順まで）が載ってて、要は細工したリクエストを送るだけで、しばらくCPUリソースを浪費するって話と読み取った。リクエストパラメータをパースする段階で起こるので、脆弱性のあるバージョンのPHPをHTTPサーバ経由で実行できる環境が全て影響を受けるんじゃないかなあ。
数年前に話題になったHashdosと、攻撃のお手軽さも影響も大差はない気がするんだけど、あんまり騒がれていない気がする。なんでなんだろう。
いやまぁHashdosはいろんな処理系に共通してたから話題になったんだろうけど。
PHPのアップデートができない場合、IPSとかWAFとかでそれっぽい通信を弾くとか、Hashdosと同様にPHPのpost_max_size設定かHTTPサーバの設定でリクエストのサイズを制限するとかしかないような気がする。原理からするとinput_max_varsは関係なさそう。
あと一ヶ月くらいバグレポートが放置されてたのがおもしろいと思う。
==2015/06/30 追記==
ディストリの対応を１ヶ月ほどチェックしてたんだけど、Red Hat Enterprise Linuxの一部パッケージは対応されたっぽい。対応するCent OSのリポジトリにもパッチが来ているはず。
access.redhat.com | CVE-2015-4024
- RHEL 7 の php パッケージ（5.4系）
- RHEL 7 の php55-php パッケージ（5.5系）
- RHEL 7 の rh-php56-php パッケージ（5.6系）
- RHEL 6 の php55-php パッケージ（5.5系）
- RHEL 6 の rh-php56-php パッケージ（5.6系）
RHEL 5 の php パッケージ（5.1系）や RHEL 6 の php パッケージ（5.3系）はまだ脆弱なまま。
っつうか対応する予定あるのかなこれ……。
==2015/07/10 追記==
以下パッケージも対応された。
Tiarraをsystemdで起動する
CentOS 7が出たのでsystemdを勉強中。シェルがゴリゴリ書かれていたinitより超わかりやすいと思う。
Tiarraをとりあえずサービスにしたかったので、とりあえず動いたものを残しておく。
Tiarraの本体とtiarra.confは/usr/local/tiarraにインスコされているものとして、ExecStart、ExecReload、ExecStopさえ書かれていれば動くような雰囲気。前提サービスとしてsyslogとnetworkくらいは書いておく。たぶんホントは色々足りてない。
ExecStopをkill以外で穏便に済ませる方法がわかりません。。。
vi /lib/systemd/system/tiarra.service
[Unit] Description=Tiarra server daemon After=syslog.target network.target [Service] ExecStart=/usr/bin/perl /usr/local/tiarra/tiarra --config=/usr/local/tiarra/tiarra.conf ExecReload=/bin/kill -HUP $MAINPID ExecStop=/bin/kill $MAINPID [Install] WantedBy=multi-user.target
あとはサービス登録？
systemctl enable tiarra.service systemctl start tiarra.service
実行時の標準出力ログはsystemdに拾われて/var/log/messagesに出るのかな。
イノセントアイがエーゼット・ビュークリアになっていた件
3年くらい前に買った目薬で、結構気に入ってたんだけど、それ以来見かけたことがない目薬があって、ずっと気になっていた。
箱も容器も捨ててしまって名前がわからないんだけど、3,4色のバリエーションのあるパッケージだったことと、容器のキャップが特徴的だったことだけ覚えていた。それっぽい箱はよく見かけるんだけど、何かが違ってて全然発見できない。
ところがつい先日、日頃入ったことのないドラッグストアで、日頃見ない3種類のパッケージをたまたま発見してしまった。もしやと思って買ってみたら、見覚えのあるキャップ。間違いないこれだ。
俺が探していたのは、ゼリア新薬のイノセントアイだった。
箱捨てちゃったんでネットで拾った画像だけど、こんなやつ。
こんな特徴的なやつなのになんで見つからなかったのかと思うところもあり、イノセントアイで検索してみたら、製品情報が出てこない。ゼリア新薬のサイトで検索しても出てこない。
どうやらこれ絶版になってるっぽくて、同じ成分でエーゼットかビュークリアにリネームされたようだ。
で、パッケージを引用という名目のもと転載するけど、これが同じシリーズの目薬だと思える人いるのかな？AZのロゴすら違うよ。
ビュークリアは一部統一されているが、やっぱりよくわからんものが多い。ALクールなんて容器が違うわ。
イノセントアイ自体も、もしかしたらビュークリアの一部くらいしか統一されてなかったのではないかと思う。
少なくとも俺は、この箱を見てイノセントアイだと気付くことはとてもできなかった。ブランドのリネームと統一感のないパッケージングが重なるととても不幸なのではないかと思った。
