Category: サーバー

  • メモリ購入

    サーバー用にメモリ購入。これで8G -> 24Gにアップ。 今まででもappメモリは3G程度で5Gほどbufferだったので足りてないことは無いはずだよなーと思いつつ、swapoutは発生していたので増やした方がいいんだろうなと。 一応、最大32GのPCなので16Gx2を買って今の一枚はデスクトップに増設とかも考えたけど、高いしそこまで必要ないだろうということで8Gx2を購入。 刺さっていたのがPC4-19200 8Gで、購入したのがPC4-21300。規格合わないので引っ張られるぐらいなら16Gで止めておくのもありかなと思ったがもったいない精神が勝った。 まあCUIサーバーだし。そこまで神経質にならんでもいいだろということで。使ってみて余ってそうだったらデスクトップに持っていこう。 マニュアルDLして確認しながらメモリを刺す。DIMM1-4まであってDIMM1-2がチャネルB、DIMM3-4がチャネルAで、チャネルごとにサイズが違うならチャネルAの方を大きくしろと。 なんで数字大きい3,4がAなんだよとか思いつつ結局1,3に新しいメモリ8Gx2を、DIMM4に古いメモリ刺した。 memtest86動かしてエラーが無いことを確認する。1時間ぐらいかかった。結局デュアルチャネルにはなってないみたい? まあメモリの速度なんて体感できるようなもんでもないし。swapしない事の方がはるかに大きいので気にしないことにした。 結果として、早くなった感じはあんまりないが軽くなった気はする。特にjournal見るのが爆速。今までもっさりしてたのがサクサク出る。やっぱメモリ足りなかったんだなぁ。つーかキャッシュが足りないかっただろうか? でも重そうな処理回してみたらswapは少し使っているようだ。調べてみると使ってないメモリはそれなりにswapoutしてbuffer用に空けているっぽい。多分SQLserverがメモリ大量に要求して結局使ってない状態なのでswapoutしているんだ多分そうだ(勝手な予想)

  • MSSQL server

    しばらく前からSQL serverが起動できなくなっていた。startしてもしばらくするとSIGABRTで死亡する。 色々見ててもどうも起動しない。これはまずいと新しく仮想マシン作って再構築してみた。debootstrapして証明書入れてアップグレードして… やっぱり動かん。なんだこれ?と見ていたら、Ubuntu 20.04 と 22.04 を混同していたことに気が付く。 元のマシン見てみると、apt lineがシステム側はfocalなのにmicrosoft側はjammyとよくわからないことになっていた。つーかよく今まで動いてたな… 原因わかったからこれで大丈夫と思ったが揃えて作ったやつも動かんかったな?と思いつつapt line 書き換えて再度試す。やっぱりダメ。 適当にサイト探していたら、kernel version 対応していないとかいうのをちらりと見かけ、そういえば最近6.6.xから6.7に上げたなーと思って古いのに戻してみたら動いた。 最初のmssql-server起動時にupgrade処理が始まってそこそこ時間がかかったが、一応これで動くようだ。 起動エラーもNo such file or directoryでstraceしてみた時も/sys とか /dev オープンしてたっぽいのでsysfsとかudevあたりでなんか変わったのかな? とりあえず前はkernel 6.6.8だったので6.6.12をrebuildして試す。

  • ssh contents do not mutch public

    今までsshにはTeratermを使ってきた。 なんか知らん間にOSDNが実質死亡しててgithubに引っ越ししてたり、ver5がbetaじゃなくなったりしていたが、とりあえずv5.1を使っている。 Windows Terminalも使いやすくなってきているのでWindows Terminalからsshしてみたら、identity_sign: private key C:¥Users¥…¥ed25519 contents do not match public とか言われてIgnore private keyされてしまう。 なぜだなぜだと調べていたら、とりあえず鍵作り直せ的なページばかりヒットする。 よくよく見てみると、ローカルのid_ed25519 とid_ed25519.pub の日付が違う。どうも秘密鍵と公開鍵のペアが間違って置いてあるようだ。 Teratermはpublic keyは見ていないようで、秘密鍵のパスフレーズさえ入れれば使用できたが、ssh.exeはペアを確認するらしい。 結局、ssh-keygen.exe -y ed25519 で公開鍵を作り、ed25519.pubを書き直したら、無事sshできるようになりました。 このPC用の秘密鍵を作ったとき、別で作ってコピーしたような記憶があり、その時違うペアを置いていたようだ。まあ秘密鍵さえ正しければよかったので今まで気が付かなかったようだ。他のPCは正しかったようでssh.exeを使わなければわからなかった問題だな。 ちなみに WARNING: UNPROTECTED PRIVATE KEY FILE! がでかでかと表示されたが、これもちと苦労した。 explorerでid_ed25519のプロパティからセキュリティタブで継承化を無効にしたり、一度全部の権限取り上げてから再度自分のみ設定したりとかして警告は出なくなった。 cacls.exeで一発登録とかできそうな気がするけど、NT時代に諦めてexplorer property使うようになってしまったので今更調べる気はないw UNIX系と違ってオーナー/グループ方式じゃないからなぁ。まあaclの方が細かく設定できるんではあるんだが。継承とかあって更にややこしい。 そしていろいろ苦労してssh.exe使えるようになったのだが、タブの中でGNU screenを使うとわけわからんようになるので結局Teratermを使う事にしたとさ。

  • fail2ban

    最近、sl/ANY/IN のDNS queryが多発しているのでどうにかできないかと思ったのでfail2banの設定を。 しかし、そもそもUDPだしip偽装簡単だしfail2ban結構重いしであんまり意味なさげという記事が多いんではあるが、ここまで多いととりあえずのbanでも意味はありそうなので一応入れる。 元々fail2banにnamed-refusedというのがあったのでそれを使う。が、全くHitしないのでfail2ban-regexであれこれ調べる。 予想通り、用意されたfilterとログが一致していない。 named[10854]: client @0xf1fa4cd0 104.190.220.183#3074 (sl): query (cache) ‘sl/ANY/IN’ denied なんかログに@0xhogehogeというのが増えてたのでprefregexに追加した。 色々調べてたらわかったこと。 journalを使うときはDate template hitsが0のままになる。多分日付をparseせずに直接journalから読んでいる。 fail2ban-regex systemd-journal を使うと量が多いのですごく時間がかかる。しかしjournalctl > hoge; fail2ban-regex hoge では日付が普通にhitしない。 jounalctl -oshort-iso -n 500 > hoge と –output に short-isoを付けるとちゃんとhitするのでこれでテストすると良い。 ここが詳しい > fail2banをうまく動かすためのTips。正規表現はシンプルに見やすく – のめうブログ (nomeu.net) まずdatepatternでmatchして、残りがprefregexでmatch、そして最後にfailregexがmatchする。のだが、fail2ban-regexだとその辺がわからん。ので理解に非常に時間がかかった。それ以前にpythonのregex知らなかったというのもあるけど・・・ かつ、systemd-journalからだとdatepatternがそもそも使われない(っぽい) 色々試したのだが最終的には結構シンプルに修正できた。 まあ、ログの形式が変わったりfail2banの設定が古かったりで整合性合わないのが問題なのだが・・・fail2banの更新で修正されたりするとそれはそれで面倒だなぁ。 ついでにrecidiveも/var/log/fail2ban.logからじゃなくてjournalから読むようにしようと思ったのだが、これもよくわからない理由で断念。 まずfail2banの出力を/var/log/fail2ban.logからSYSLOGに変える。そしてrecidiveをbackend=systemdに変える。 基本的にはこれで良いのだが(完全に動いたホストもある)、なぜかERROR NOK: (“can’t start new […]

  • ipv6 source address

    同一インターフェイスに複数のipv6アドレスが付いている時、通常使うアドレスを指定する方法。 サービスごとにアドレスつけてたりすると、どれをソースアドレスとして接続しに行くかわからんので優先順位をつける。何も設定しないと、大体アドレスの長い奴が優先されて、一番単純なアドレスが代表なのに使ってくれなかったりする。例:2001:db8::1>(代表)と2001:db8::143(dovecot imapd用)と2001:db8::53(bind用)があったりすると(16進ではなくてBCDなのです(言い訳))、他のPCに接続しに行くと大体2001:db8::143でログが残って、これ誰だっけ?になりやすい。本当は2001:db8::1で接続しに行って欲しい。 また、相手がv6アドレスで接続制御してたりするとソースアドレスが決められなくて困る。まあこういうやつはtransfer-source-v6とかオプションがあったりするので個別対応すればいいんではあるが。 /etc/systemd/network/interface.networkに、 とすると、PreferredLifetimeがinfinitが最優先、0だとソースアドレスとして使用しない事になる。 ちなみにRAでステートレスアドレスつけると有効期限がそのままPreferredLifetimeに付く。なので、 とかすればステートレスとかいいつつ2001:db8::1とホスト部が指定できて、デフォルトルートも設定できて、 ソースアドレスとして使用されない追加アドレスも設定できた。