2022年5月8日日曜日

dockerのmailman3でメールのアーカイブができない

GWを使って、mailman3を構築している。下記のサイト(※)を見つつ進めたところ、メールのアーカイブができない事象に遭遇。

※ mailman-coreコンテナのmailman.logがこんな感じ。
tail -f core/var/logs/mailman.log
May 07 16:17:59 2022 (27) Exception in the HyperKitty archiver: <html><title>Auth required</title><body>
                    <h1>Authorization Required</h1><p>The archiver key is now
                     required to be sent over the Authorization HTTP header.
                     You need to upgrade the mailman-hyperkitty package to
                     1.2.0 or newer.
                    </p></body></html>
May 07 16:17:59 2022 (27) Traceback (most recent call last):
  File "/usr/lib/python3.8/site-packages/mailman_hyperkitty/__init__.py", line 154, in _archive_message
    return url
  File "/usr/lib/python3.8/site-packages/mailman_hyperkitty/__init__.py", line 210, in _send_message
    except ValueError as e:

メッセージのとおり、mailman-hyperkittyモジュールを1.2.0以上にする必要があるようす。githubで、maxking/docker-mailman/Dockerfileを見たら所、4/14にmailman_hyperkittyが1.2.0に変更されているが、コンテナイメージが更新されていない。

対処として、コンテナに入ってmailman-hyperkittyをアップデート(pip install -U mailman-hyperkitty)して、コンテナを再起動(docker container restart mailman-core)したら、無事にアーカイブできるようになった。さらに、過去の投稿も登録された。

コンテナイメージをアップデートしてくれないかなぁ…
pipを使ったら、pipのバージョンがふるいって言われるなぁ…
コンテナイメージとしてrollingを使うのが正しいのかぁ…

(※)サイト

https://github.com/maxking/docker-mailman

https://rohhie.net/ubuntu20-04-building-a-multi-domain-mailing-list-with-mailman3-first-half/

2022年5月5日木曜日

tcpdump で　syn/fin/rst をキャプチャする

tcpdump -n \(tcp[tcpflags] \& \( tcp-syn\|tcp-fin\|tcp-rst \) != 0 \)

※　(と&と|はシェルに解釈されないようにエスケープ

tcp-syn|tcp-fin|tcp-rst　の論理和(であってる？）と、tcp[tcpflags]で論理積をとって、0でなければどれかのフラグが立っているといる。

(参考)

https://eijiyoshida.hatenablog.jp/entry/20100805/1280995787

2022年4月2日土曜日

暗号化の考え方

公開鍵では、Lock「錠(じょう)」とKey「鍵(かぎ)」が作成される。

Lockを公開錠として、Keyを秘密鍵とすることで、データを秘密裏に受け取ることができる。

受信者が送信者にLock(公開錠)を渡す
送信者がデータをLockして、送付
受信者が暗号化されたデータをKye(秘密鍵)で開錠してデータを確認する。

Keyを公開鍵として、Lockを秘密錠とすると、自分を証明することができる。

送信者の証明書をLock(秘密錠)して相手に送付
受信者はデータをKey(公開鍵)で開封して証明書を取り出す。
証明書は、認証局でLock(秘密錠)されており、認証局のKey(公開鍵)で開封できれば、証明書が認証局でLockされたものと確定できる。(認証局のKeyで開封できるのは、認証局のLockで暗号化されているものだけだから) ※ この辺りは少しあやふや。

送付内容をLockしたものと、原文のまま(暗号化されてないまま)送る
受信者が開封して出てきた内容と、原文のまま届いた内容が同じであれば、Keyの所有者からもらった内容であると証明される

PFS（Perfect Forward Secrecy：前方秘匿性）

DHEを使う。詳細はここ。https://ja.wikipedia.org/wiki/%E3%83%87%E3%82%A3%E3%83%95%E3%82%A3%E3%83%BC%E3%83%BB%E3%83%98%E3%83%AB%E3%83%9E%E3%83%B3%E9%8D%B5%E5%85%B1%E6%9C%89
ざっくりいうと、通信するそれぞれが、「相手の公開鍵と自分の秘密鍵」で共通鍵を作ることができる。

2022年2月11日金曜日

LANG=C xdg-user-dirs-gtk-update

探せば簡単に出てくるのですが、どうしても忘れるのでメモっておきます。

Ubuntuなどでホームディレクトリの名前が日本語でつけられるのを変更する方法です。

LANG=C xdg-user-dirs-gtk-update

以上です。

ちなみに「LANG＝C」を外して再度実行すれば、自分のLANGで設定しなおしてくれるようです。

2021年4月25日日曜日