Category: サーバー

  • 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とホスト部が指定できて、デフォルトルートも設定できて、 ソースアドレスとして使用されない追加アドレスも設定できた。

  • StartTLS

    認証関係はやり始めると時間がかかる上、途中で辞められないので大変である。 やっとSSLとTLSとStartTLSの違いがわかった(気がする) SSLとTLSは実質一緒で、SSLがバージョンアップしてTLSになって、かつSSLはもう古いので使うな、ということらしい。でも通称SSLが多いのでSSL/TLSと表記することが多い、だそうな。 で、StartTLSは、最初から暗号通信するか途中から暗号通信するかの違いらしい。 httpsは最初から暗号通信を行う。http/StartTLSは最初httpで平文接続して、プロトコルの中でStartTLS -> ネゴシエーション -> 暗号化 という手順を行う。 同じポートで待ち受けできるので良いらしい。 そこでLDAPをTLS対応させてみたら色々はまりました。普通に間違えてつながらなくなってうひょーは割愛(これが大変だったのは確かだが… ldap.conf(のLDAPエントリ)に dn: olcDatabase={1}hdb,cn=configolcSecurity: tls=1 を追加すると、ldap://を受け付けるがStartTLSしないとダメ、と設定できる。この際なのでldapsの待ち受け消してldap/TLSのみにしてやろうと思ってやってみた。 結局のところ、クライアントにどうやってStartTLSを指示するか、が問題となった。あと、StartTLSをyesにして、ldaps://でつなぎに行くと2重になるのでエラーになる。なのでuri指定をldapi:/// ldap://…とldaps指定をやめた。ちなみにldapi:///指定でもStartTLSしないと弾かれる。UNIX socketなら暗号化は特にいらない気もするがまあ仕方ないのだろう。# それを言うとldap通信してるのは全部同一マシン内の仮想マシンなので根本的に暗号化の必要性は無いとも言えるが(汗 /etc/ldap/ldap.confにSSL start_tls でldap.confを読むやつはStartTLS対応になる。sudo-ldapなど。ただしTLS_REQCERTをneverとか、TLS_CACERTを適切に設定とかしないとはじかれる。nslcdもnslcd.confに同じ書き方で良さげ。 postfixはldap-*.cfにstart_tls = yes isc-dhcp-server-ldapはdhcpd.confにldap-ssl start_tls; wanderlust: .wlに(setq elmo-imap4-default-stream-type ‘starttls) openldap SyncRepl はstarttls=yesとtls_reqcert=allow|neverを指定。 と、ここまで来て困ってしまったのが、kerberos ldapだった。どうもMIT kerberosからLDAPを見に行くときにStartTLSの設定がないっぽい。このためだけにldapsを動かすのも嫌なのだが、諦めてldapsを指定してみる。 しかしオレオレ認証のためか検証エラーっぽくつながらない。やっぱりslapdのSecurity: tls=1 はダメなのだろうか・・・ 誰もkerberos ldap使ってないのだろうか。ググったけど1件だけ「まだ対応していないのでldapsにするかTLS諦めてね」というのがあっただけで、他は「対応しているかどうかは書かずに」「ldapにすれば動く」「ldapi:///でおけ」というものばかりだった。 世の中kerberosと言えばActive Directoryのようで、sambaとかAD使わずにkerberos+LDAP使っている人はかなり少数派のようである。 ldap://…/!StartTLSみたいなURIで指定する仕様もあるようだが、もちろんクライアントが対応していないと何ともならず。