Question 1

SSLが要求される場合に、ModoboaがマネージドMySQLまたはPostgreSQLデータベースへの接続に失敗する問題を修正するにはどうすればよいですか？

Accepted Answer

`--dburl` を通じて渡されたデータベースの `OPTIONS` を保持する issue #1835 の修正を含む Modoboa リリースにアップグレードしてください。アップグレードできない場合は、`settings.py` に SSL 設定を手動で追加してください。 PostgreSQL の場合は、次のように設定します: ```python DATABASES = { 'default': { 'ENGINE': 'django.db.backends.postgresql', 'NAME': '', 'USER': '', 'PASSWORD': '', 'HOST': '', 'PORT': '5432', 'OPTIONS': { 'sslmode': 'require', }, } } ``` サーバー証明書を検証するには、`sslmode: 'verify-full'` を使用し、`'sslrootcert': '/path/to/ca.crt'` を追加してください。 MySQL の場合は、次を追加します: ```python DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'NAME': '', 'USER': '', 'PASSWORD': '', 'HOST': '', 'PORT': '3306', 'OPTIONS': { 'ssl': { 'ca': '/path/to/ca.pem', 'cert': '/path/to/client-cert.pem', 'key': '/path/to/client-key.pem', } }, } } ``` CA 証明書のみが必要な場合は、`cert` と `key` を省略してください。Modoboa を実行しているデータベースユーザーが証明書ファイルを読み取れることを確認してから、Modoboa アプリケーションサービス（uWSGI や Gunicorn など）を再起動してください。Nginx だけを再起動しても不十分です。

Question 2

名前を変更したModoboaのメールボックスが利用できなくなり、Postfixが450を返すのはなぜですか？

Accepted Answer

失敗した、または未処理の名前変更操作は `admin_mailboxoperation` に行を残します。その結果、Postfix の `sql-maintain` クエリはそのメールボックスを保留中として扱い続け、`450` でメールを拒否します。「never leave a mailbox blocked by a pending rename operation」（保留中の名前変更操作によってメールボックスがブロックされたまま残らないようにする）という修正を含むリリースに Modoboa をアップグレードしてください。即時の回避策として、メールボックス/maildir の状態を確認してから、MySQL から古い行を削除してください:

```sql
SELECT * FROM admin_mailboxoperation;
DELETE FROM admin_mailboxoperation WHERE id = <stale_rename_operation_id>;
```

名前変更が既存の宛先、`mv`、または `makedirs` のエラーが原因で失敗した場合は、行を削除する前にメールディレクトリを手動で修正してください。また、アプリケーションにメールディレクトリの名前変更を自動的に行わせたい場合は、Modoboa のメールボックス処理/`handle_mailboxes` 設定が有効になっていることを確認してください。

Question 3

RedisがTCPポート6379ではなくUnixソケットのみでリッスンしている場合、Modoboaをデプロイするにはどうすればよいですか？

Accepted Answer

`--redisurl` オプションを含む Modoboa リリースにアップグレードし、デプロイ時に Redis ソケット URL を指定してください：

```bash
modoboa-admin.py deploy --redisurl unix:///run/redis/redis.sock
```

これにより、`redis://localhost:6379` が仮定される代わりに、指定した値が生成される `settings.py` の `REDIS_URL` に書き込まれます。

このオプションが利用できない Modoboa 2.4.10 では、TCP ループバックで Redis を一時的に有効にし（`redis.conf` に `bind 127.0.0.1 -::1` と `port 6379` を設定）、Redis を再起動してデプロイヤーを実行し、その後 `REDIS_URL = "unix:///run/redis/redis.sock"` を手動で設定して Modoboa サービスを再起動してください。

Question 4

Modoboa で doveadm -A が "User no longer exists, skipping" と報告する問題を修正する方法

Accepted Answer

このメッセージは、`core_user` に `email` フィールドが空の管理者アカウントが含まれており、Dovecot の `iterate_query` がその空のユーザー名を返す場合に発生します。次のようにして確認します:

```sql
SELECT username, email AS user FROM core_user;
```

管理者アカウントに有効なメールアドレスを割り当てるか、`/etc/dovecot/dovecot-sql.conf.ext` で空のアドレスを除外して修正します:

```conf
iterate_query = SELECT email AS user FROM core_user WHERE email != ''
```

その後、Dovecot を再起動します:

```bash
sudo systemctl restart dovecot
```

例えば次のようにして再テストします:

```bash
doveadm search -A mailbox Trash savedbefore 14d
```

Question 5

modoboa 1.4.2 の alias import が 'Local recipient not found' で失敗するのはなぜですか？

Accepted Answer

modoboa 1.4.2のバグにより、ターゲットアカウントがまだ存在しない場合にエイリアスのインポートが失敗します。メソッド`Alias.set_recipients()`は受信者が存在するかどうかをチェックし、存在しない場合、作成する代わりに`NotFound`例外をスローします。これにより、同じCSVファイル内で後で定義されるアカウントを参照するエイリアスのインポートが中断されます。

回避策: `modoboa/admin/models/alias.py`を編集し、133～139行目をコメントアウトしてください:
                    # if rcpt is None:
                    #     raise NotFound(
                    #         _("Local recipient {}@{} not found")
                    #         .format(local_part, domname)
                    #     )
                    # if rcpt.address == self.address:
                    #     raise Conflict

これにより、時期尚早なチェックがスキップされ、インポートが成功するようになります。コメントアウト後、ターゲットが欠落していてもインポートはエイリアスを作成することに注意してください。必要に応じて、CSVでアカウントをエイリアスの前にリストしてください。

Modoboa

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト