Skip to main content

ログ取得ツール

Category: コンピュータ

オ パキャマラド

愛用のキーボードが微妙に壊れてしまった。あるキーだけが反応しなくなった。2013年12月に買った、ARCHISSの黒軸のやつ。在宅勤務が定常化してからは仕事にも使っているやつで、壊れると非常に困る。というか実際困った。

裏のシールを見ると、製造は2012年12月なのかな。毎日元気に叩かれ続けて、はや9年目。軽快な音を出しながら、自分に合ったタッチ、ほどよい打鍵感覚。

たまにキートップを水洗いしてまして。この春にもやったばかり。戻す時に乾き切ってなかったのかも、という後悔がある。あとボード側の掃除も甘かったかもしれない。気に入っていただけにいろいろ考えてしまう。

ただ、そうは言ってもこのキーが打てないのは耐えられないので、FILCOの似たやつを発注、無事に届いたので、こうやって文章を書ける。まあ同じCherry MX黒軸でも、ちょっとタッチは違うかなー(使っていっていい感じにエイジングされれば同じようなタッチになるのかもしれない)。刻印が控えめで、見た目は割とカッコ良くなった。

打てなくなったのは「9」のキーです。「(」でもあるので、この記事は壊れてたら書けなかったですね。今週は「(」と「9」常にエディタに表示していて、打ちたくなったらそこからコピペしてました。

what do you log for?

log4jの割とでかい脆弱性が世間を賑わせていますねー。年に一度のお祭りといった趣。このサイトのアクセスログにすら出てきてます。Wordpress丸出しで、まあだいぶ古いですがnginxとphp-fpmだから(リプレースしたい)、log4jを使ってるとは思えないはずですが、まあインターネット全体が見境なくフルスキャンされまくってるってことなんでしょうね。

このサイトは「ログ取得ツール」という名前にしていますけど、ログの取得と蓄積はソフトウェア技術においてはかなり重要度の高いもので、適切なログを吐くコードになってるかというのはプログラマが優秀かそうでないかを見分ける要素の一つだったりしますね。何かトラブルが起きた時は必ずログを見るわけで。それは昔から、このサイトを作った頃(2008年)にはすでにそうで、もしかしたら先代サイトの2003年ですらそうで、それから今に至るまで、変わりません。このくらい続くと、もはや「真理」と言ってもいいのでは?

いろいろ買い替えの時期

MacBook Pro(7年前から使用)、Amazon Fire TV Stick(5年前から使用)、Raspberry Pi(5年前から使用)、Huaweiの電話(4年前から使用)と、かなりガタが来ていた感があった。順次入れ替えて行こうと。

きっかけはFire TV Stick。こいつには律儀にアップデートが来ているんだけど、こないだUIが変わったと思ったらものすごく重くなった。DAZNなんて1分持たずにアプリが落ちて再起動してしまい、全く実用にならない。Fire TV Stickは事実上DAZNマシンなので、これはすごく困る(しょうがないのでJリーグや代表の試合はMBPをリビングのTVにつないで見ていた)。そして新しいモデルが発表されているのを見て、怒りの予約。安いし。その後、到着までの間に電源off/onしたら快適になったから、買い換える必要はなかったなと思ったが、おとなしく到着を待ち、新しいモデルに変更した。なんとかMaxとかいうやつ。キビキビ動くし、割と快適になったので結果オーライか。

自宅MBPの不調

ここのところ、自宅のMBPがスリープからの復帰で非常に不快な動きをするようになって悩んでいた。古くなってきてるからそのうちM1のやつに買い換えようとは思ってるんだけど、それまではしょうがない。で、OS再インストールで直るんじゃないかという気持ちがあるが、それをやるダメージは割と大きいので、ひとまず~/Library/Cachesを削除(実際はrename)してリブートして様子を見ることにした。

現象としては、スリープから復帰して例えばChromeのアドレスの欄を触るなりiTerm2のウィンドウに文字を入力するなりMacのメニューを触るなりすると、マウスカーソルが待ち状態になって何もできなくなるというもの。この現象が数分続いたのちにMacが使えるようになる。これなら再起動したほうが早いんだが…正常なシャットダウンすらできないからどうしようもない。電源長押しが最速かも(←それはやったことがない)。こうなる場合とならない場合があって、スリープからの経過時間と関係があるんじゃないかという印象がある。ハイバネート(ディープスリープ?)限定で起きるということなのかもしれない。

fail2what?

一つ前のエントリやら何やらで、sshdのポート番号を変えてたらbrute forceのlogin attemptが劇的に減るとかなんとか書いた。

すると、最近になって変えたポートで待ち受けるsshdへのlogin attemptが激増した。割とタイムリーだったのか。アクセス元のIPアドレスは3000種類くらいで、かなり規則性のあるバラツキがあるが、多いやつは600回くらい試行している。一応まだログインされた形跡はないと思うけど、気持ち良いものではないよなー。

うーん、このサーバって一応fail2banも入れてたはずなんだけどなー、と思って設定を見直してみたら、actionを書いてなかった! つまりDBに書くだけで実際にはbanしていなかったというオチを経験する一幕があった。デフォルトでfirewallcmd-ipsetにしとかないとダメですよね。

xmlrpc.phpの問題も、fail2banに任せればいいのかな。ちょっと設定してみたけど、効くかどうかは不明。

僕とブログとLogin rebuilderとBrute Force Login Protectionとxmlrpc.php

このサーバは借りたホストで自前で管理しているんだけど、よくいろんな国からログイン試行のアクセスが来る。sshでも来るし、Wordpress(WP)のログイン試行も多い。治安悪いなぁ。

fail2banやWPのBrute Force Login Protection(BFLP)といったソフトウェアは、ログイン試行を記録して不正と見なすほどの頻度で来た場合にそのIPアドレスをブロックするというものだ。割と有効で、ちょくちょく通知メールが来る。BFLPはApacheの.htaccessを作ってくれるけど、私はincronと自作スクリプトを組み合わせてnginxで運用している。

sshならポートを変えたり、WPならLogin rebuilderというプラグインがあって、ログインページのURLを変更することができる。これも効果があって、特にsshによるlogin attemptは劇的に減った。しかしWPのBFLPの通知は相変わらず、頻繁に来続けた。ログインページ変更ってほとんど効果ないじゃん。

アクセスログを見てみたら、不正なログインはxmlrpc.phpに向けたPOSTリクエストだった。wp-login.phpの倍くらいのxmlrpc.phpへのPOSTが来ている。なるほど。このエンドポイントもURL変更しないと効果は半減というわけか。ただこのエンドポイント、自分としては消すことはできなくて、Androidとかから投稿するのに必要なんだよね。

Raspberry Piの電源改善

2020年夏。在宅勤務が続いたので、まずは自宅のネットワーク環境を改善しようとした。とりあえず無線LANの調子がよくなかったこともあり、有線に戻した。私物MBPと会社のMBPを有線に。今時のスイッチングハブと、細めで長さがちょうどいいケーブルを調達して、と。

ついでに自宅のRaspberry Piの環境を改善しようと思ったんです。別の部屋に隠してあったRaspberry Piのサーバを自室の棚に引き取って。このサーバにはバスパワーのHDDがついていて、負荷をかけると電源が足りなくなって、落ちる。MBPのバックアップ先でもあり、PDF変換サーバでもあり、githubに上げる前の書きかけソフトウェアのリポジトリサーバでもある。その重要性にも関わらずこの貧弱さはどうだ。見たら1Aまでしか供給できないUSB充電器が使われていた。そりゃ足らんよ。今までその充電器で戦ってたのね。せめてHDDはセルフパワーにしてあげないと。うーむ…

RasPiのPyPyはXeonのPythonにすら勝てる!

https://github.com/wtnb75/rtow1#performance

話題沸騰(?)のRayTracing In One Weekendやってレイトレを完全に理解しました。性能度外視でいいかとPythonでやりましたが、PyPyを使うと割と実用的な速度で動くということがわかった。環境としては、普通に世間でvCoreとか言って売ってるVPSと、手元のRaspberry Pi。普通のCPythonは十分遅いけど、PyPyを使うことでそこそこ高速に動くことができる。Raspberry Piは2Bと3Bの2つ持ってて、2Bの方は設置場所の問題もあって、負荷をかけ続けると安定動作してくれない。最後のやつはついに完成しませんでした。どうしても途中で落ちてしまう。3Bは余裕だった。

それでこういう計算の場合、PyPyはPythonよりも10倍以上高速だということが判明した。なかなか凄いです。何より、ちゃんと動くという点も偉い。PyPyなかなか侮れませんよ。

しかしCPythonだと流石にきついね。最後のなんて、Xeonなのに45時間もかかりましたよ。PyPyなら1時間半で終わる。まあ、最適化も何もしてないGILありのPythonでシングルスレッドだから、高速とは最初から思っていないけども。まー単純にmultiprocessingで並列化するだけでもかなり効果はあると思うけどね。RasPi3Bだって4コア持ってるから。

サーバのスペックアップ

私が個人でサーバと言う時は、この(ブログの)サーバと、自宅用のRaspberry Piの2台があるんです。で、どちらも処理がきつくなってきたように思ったので、アップグレードしたいなと思った。

使っていたRaspberry Piは2Bで、USBのHDDをつけてMacのバックアップ先にしていたり、github.comに上げられない内容のgitサーバとしてgogsを立てていたり。他に何やってたっけ?? Raspiも最近4Bが出て、しかし日本で発売するまでにちょっと時間がかかりそうという感じ。先日技適が通ったとかどうとか…。4BはNICがUSB経由じゃなくなってGbEになったり、電源がType-Cになったりとだいぶ良さそうな感じを受けている。RaspiはCPUは割と強いけど、I/Oが弱かったからね。ただまだ買えない…ので、思い余って3Bを買ってしまいました。まあ、足りない時は困るけど、余る分には困らないでしょという精神ね。RaspbianもJessie LiteからBuster Liteにしたかった。ただ、2Bと3Bはあんまりスペックアップとは言えないんだよなぁ。電源が厳しくなっただけという説もある(無線とか要らんし)。バスパワーのUSB HDDで大丈夫か心配なところ。2Bはmax_usb_current=1で頑張ってるんで。

shred time

以前にTimeMachineに使っていた2TBのHDDにshredをかけた。

USB HDDなのでUSBでMBPにつないで、、、

  • gshred -v /dev/disk3

このコマンドはランダムデータを3周書く。2 days 5 hours 40 minutes かかった。計算すると、平均して30MB/s程度。

これは遅いのか速いのかというと、遅いです。HDDはだいたい200 IOPS、100MB/sくらいがざっくりした目安かな。まあ100MB/s出たとしても17時間かかるが。USBなんてそんなもんだよなどうせ。それでもRaspberry Piにつなぐよりは速かったと思いたい。

長い闘いだった。自分は放っておいただけだけど、疲れたよ。

高速にする方法はあっただろうか? VirtualBoxにUSBポートを見せるか/dev/disk3を直接見せられれば、Linuxからアクセスする方法はあったかもしれない。しかしそれで性能が変わるとも思えんよなぁ。ガワを剥いて、どうせSATAか何かだろうから、何とかしてつなげば良いのか…しかし使っているのはMBPかRaspberryPiか、あるいは古いCeleronのベアボーンのWindowsなので期待できないね。