徒然なるままに プログラミングメモや日々の生活などつれづれとつづっていくblog

2018年2月9日

Mastodonでリモートフォローが「承認待ち」になる場合の対処方法

Filed under: apache,Docker,Mastodon — ranpei @ 9:58 PM

2月初めごろからかな?(実はもっと前からあって表面化したのかそれぐらいかもしれませんが)

フォローすると「承認待ち」のステータスになり、

連合にも相手の最新のトゥートが出てこないなどの弊害が多数発生していました。

 

デバッグモードでログを追ったり、Mastodonのソースを読んだりしていろいろ調べましたましたが

結局Nginxの設定の問題だと分かったため、情報共有の目的でここに書かせていただきます。

 

 

■問題の設定

・変更前

ssl_certificate /etc/letsencrypt/live/mstdn-jp.site/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mstdn-jp.site/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/mstdn-jp.site1/chain.pem;

・変更後

ssl_certificate /etc/letsencrypt/live/mstdn-jp.site/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mstdn-jp.site/privkey.pem;
#ssl_trusted_certificate /etc/letsencrypt/live/mstdn-jp.site1/chain.pem;

ssl_trusted_certificateの設定をなくしただけですね。

(そもそもssl_trusted_certificateに指定する証明書間違ってるって突っ込みはなしでお願いします;;)

 

■なぜこれで治ったのか?

実は明確な原因はわかっていません;;

 

ただソースを見る限りActivityPubはSSLを基盤としているため証明書の評価を行っているようなんです。

その評価の過程でActivityPubでのやり取りが途中で止まってしまっていたのでは?と疑っています。

 

 

何はとも本来非公開ユーザーをフォローした場合にしかありえない「承認待ち」が

公開ユーザーでも発生するって場合はSSL証明書を疑って見た方がいいみたいです。

 

2017年10月18日

Mastodonをローカルファイルからオブジェクトストレージへ移行する

Filed under: Mastodon — ranpei @ 10:30 PM

個人インスタンスだし別にいいかな?って思っていたのですが、

今回master追随の試験インスタンスを作るに

本稼働インスタンスとデータを共有した状態にしたくて

オブジェクトストレージへ移行したのでその忘却禄をメモします。

 

 

まず、移行の流れですが

1. S3準拠のオブジェクトストレージを用意する。(今回はminioを使用)

2. public/system配下のデータをオブジェクトストレージへコピーする。

3. mastodonの設定を変更する。

っといった感じです。

 

最後の設定に手間取りましたがファイルのコピーはコマンド一発なので

わかってしまえばそれほど難しいことではないです。

 

では、細かい手順を書いていきます。

 

■S3準拠のオブジェクトストレージを用意する

DockerHubでminioのイメージが配布されていますのでこれを利用します。

mastodonのdocker-compose.ymlを以下のように修正

  # webとstreamingのdepends_on:設定にminioへの内部リンクを追記
    depends_on:
      - db
      - redis
   ↓
    depends_on:
      - db
      - redis
      - minio


  # 末尾に追記
  minio:
    image: minio/minio
    restart: always
    ports:
      - "9000:9000"
    volumes:
      - /root/mastodon-volume/minio/data:/data
      - /root/mastodon-volume/minio/config:/root/.minio
    command: [server, /data]

 

Dockerを起動したらaccessKeyとsecretKeyを起動ログから入手しましょう。

# docker-compose up -d
# docker logs mastodon_minio_1
[root@localhost mastodon]# docker logs mastodon_minio_1
Endpoint:  http://172.18.0.5:9000  http://127.0.0.1:9000
AccessKey: {accessKey}
SecretKey: {secretKey}
            :

※ これは以降の手順で必要となりますのできちんとメモしておきましょう

■public/system配下のデータをオブジェクトストレージへコピーする

まずは、オブジェクトストレージにファイルを配置する場所(bucket)を作成します。
http://[IPアドレス]:9000/にアクセスしてください。


上記の画面が表示されたらメモしたaccessKeyとsecretKeyでログインします。

ログインしたら右下の「+」からbucketを作成してください。


(今回は「media」という名前で作成しています)

次にアクセス権を設定します。
「media」の右側に出る「・・・」をクリックしてください。

入力欄には何も入力せずにAddでポリシーを追加します。
(Read Onlyとして外部からオブジェクトストレージへの参照ができるようにします)

bucketの作成が終わったらファイルをコピーしていきます。
コピーにはminioのcliクライアントを利用しますので、まずはcliクライアントをインストールします。

# curl https://dl.minio.io/client/mc/release/linux-amd64/mc -o /usr/local/bin/mc
# chmod +x /usr/local/bin/mc

インストールしたら以下のコマンドでローカルファイルをminioに登録していきます。
(自身の永続化設定に合わせてpublic/systemのパスはよみかえてください)

# mc config host add mastodon_minio_1 http://127.0.0.1:9000 {accessKey} {secretKey}
# mc -r public/system mastodon_minio_1/media

※ ファイル量によってコピーに時間はかかりますが、気長に待ちましょう。

 

■mastodonの設定を変更する

オブジェクトストレージを使用するように.env.productionを編集します。

minio用のひな型が記載されているのでコメントを外して以下のように設定します。

# S3 (Minio Config (optional) Please check Minio instance for details)
S3_ENABLED=true
S3_BUCKET=media
AWS_ACCESS_KEY_ID={accessKey}
AWS_SECRET_ACCESS_KEY={secretKey}
# S3_REGION=
S3_PROTOCOL=https
S3_HOSTNAME={インスタンスのドメイン}
S3_ENDPOINT=http://minio:9000/

 

設定が終わったらdocker-compose up -dで再作成&再起動しましょう。

以上でオブジェクトストレージへの移行は完了します。

 

頻繁に外部からトゥートが来る環境の場合、

設定を先に行い、ファイルコピーを後にするといいかもしれません。

2017年10月1日

Cakephp3.x系でSAML認証を実装する

Filed under: apache,Cakephp3,OSS,PHP,SAML認証 — ranpei @ 7:12 AM

今回は完全プライベートなネタではないのですが、

Cakephp3を使ってSAML認証を行うプラグインを作成したのでその使い方をまとめようと思います。

(SAMLの設定が結構面倒なのでまとめておきたかったってのもあります。)

 

■環境構築

何はともあれ、まずは環境構築です。

今回の構成は以下のようになります。

・基盤

OS: CentOS7.2

Webサーバー:Apache2.4

PHP: 5.6

・アプリケーション

Identity Provider: SimpleSAMLphp

Service Provider: Cakephp3.x + 自前プラグイン(SamlAuthenticationPlugin)

 

●Apacheインストール

# yum install httpd

●PHP5.6インストール

普通にyumでインストールすると5.4系が入るため、

ここを参考にEPELとRemiリポジトリのパッケージを使用します。

# yum install epel-release
# rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-7.rpm
# yum install --enablerepo=remi,remi-php56 php php-devel php-mbstring php-mysql php-pdo php-gd php-xml php-mcrypt php-gmp php-intl

バージョンを確認してみましょう。

# php -v
PHP 5.6.31 (cli) (built: Jul 6 2017 08:06:11)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies

 

Cakephpのパッケージ管理に使用されているためComposerをインストールします。


# curl -sS https://getcomposer.org/installer | php
# mv composer.phar /usr/local/bin/composer

 

●SimpleSAMLphp配置

SimpleSAMLphpを配置します。配置先はhttp://xxx.xxx.xxx/simplesaml/とします。

 

まずは、公式サイトからファイルを落としてきましょう。

DLし終わったらSCPなどを使ってWebサーバーにアップロードしてください。

 

●SimpleSAMLphpの設定

ファイルの解凍と配置を行います。(私は/var/www/simplesaml/に配置しました)

# tar zxvf simplesamlphp-1.14.16.tar.gz
# mv simplesamlphp-1.14.16 /var/www/simplesaml

 

●Cakephp3.x + 自前プラグイン

まずはCakephpを配置します。(私は/var/www/ssoapp/に配置しました)

# composer self-update && composer create-project --prefer-dist cakephp/app ssoapp

 

pluginsフォルダにSAML認証プラグインを配置します。

# cd ssoapp/plugins
# git clone https://github.com/gittrname/SamlAuthenticationPlugin.git

 

プラグインを有効化しましょう。

# cd ..
# vi config/bootstrap.php
// 最下部に追記
Plugin::load('SamlAuthenticationPlugin', ['bootstrap' => true, 'routes' => true]);
# vi composer.json
// 以下を編集
"josegonzalez/dotenv": "2.*"
↓
"josegonzalez/dotenv": "2.*",
"onelogin/php-saml": "^2.11.0"
 
"psr-4": {
"App\\": "src"
}
↓
"psr-4": {
"App\\": "src",
"SamlAuthenticationPlugin\\": "plugins/SamlAuthenticationPlugin/src"
}

 

終わったらcomposerで外部ライブラリのインストールと

autoloadの構築を行います。

# composer install

 

 

●ApacheのAlias設定

# vi /etc/httpd/conf.d/saml.conf ← 新規作成
// 以下を記載
Alias /simplesaml/ /var/www/simplesaml/www/
<Directory /var/www/simplesaml/www/>
AllowOverride None
Require all granted
</Directory>

Alias /ssoapp/ /var/www/ssoapp/webroot/
<Directory /var/www/ssoapp/webroot/>
AllowOverride None
Require all granted
<IfModule mod_rewrite.c>
RewriteEngine On
# RewriteRule ^(.*)/$ /ssoapp/$1 [L,R=300]
RewriteBase /ssoapp
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.php [L]
</IfModule>
</Directory>

Apacheを再起動します。

# systemctl restart httpd

 

ここまででとりあえず前段階終了です。

・・・・そう!前段階なんです。この後の設定が回りくどく苦戦しました;;;

 

ざっくり行くと、まずIdpの証明書情報などをSPに登録、

次にSPの証明書情報などをIdpに登録する流れになります。

 

●Idpの証明書情報をSPに登録

登録する前にIdp側で証明書を作成します。

(実働環境だとオレオレではなく正規に発行してもらったものを使用するんでしょうね)

# cd /var/www/simplesaml/cert
# openssl req -newkey rsa:2048 -new -x509 -days 3652 -nodes -out server.crt -keyout server.pem

SAML2.0-Idpのモジュールを有効化します。

# vi /var/www/simplesaml/config/config.php
// 以下を変更
'enable.saml20-idp' => false,
↓
'enable.saml20-idp' => true,
 # touch modules/exampleauth/enable 

終わったらhttp://xxx.xxx.xxx/simplesaml/saml2/idp/metadata.phpにアクセスしてみましょう。

XMLが表示されたらその内容をメモっておきます。

必要となるのは「md:EntityDescriptorのentityId」「ds:X509Certificateの証明書文字列」

「md:SingleLogoutServiceのLocation」「md:SingleSignOnServiceのLocation」です。

 

では、SPに登録しましょう。

・・・・・とその前にSPの証明書を作成します;;;(またかよ・・・)

これも実働環境だと(ry

# cd /var/www/ssoapp/plugins
# mkdir cert
# cd cert
# openssl req -newkey rsa:2048 -new -x509 -days 3652 -nodes -out server.crt -keyout server.pem

 

作成した証明書をプラグインに設定します。

# cd ..
# cd config
# vi app.php
<?php
return [
'saml_config' => [
'baseurl' => 'http://xxx.xxx.xxx/ssoapp',
'sp' => [
'entityId' => 'http://xxx.xxx.xxx/ssoapp',
'assertionConsumerService' => [
'url' => 'http://xxx.xxx.xxx/ssoapp/saml-auth/login',
],
'singleLogoutService' => [
'url' => 'http://xxx.xxx.xxx/ssoapp/saml-auth/logout',
],
'NameIDFormat' => 'urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress',
'x509cert' => '{server.crtの中身をコピペ}',
'privateKey' => '{server.pemの中身をコピペ}'
],
'idp' => [
'entityId' => 'md:EntityDescriptorのentityId',
'singleSignOnService' => [
'url' => '{md:SingleSignOnServiceのLocation}',
],
'singleLogoutService' => [
'url' => '{md:SingleLogoutServiceのLocation}',
],
'x509cert' => '{ds:X509Certificateの証明書文字列}'],
]
];

 

保存したらhttp://xxx.xxx.xxx/ssoapp/saml-auth/metadataを表示してみてください。

XMLが表示されたらOKです。例によってこのXMLの情報をIdp設定で使用します。

 

●SPの証明書情報をIdpに登録

# vi /var/www/simplasaml/metadata/saml20-sp-remote.php
// 以下を追記
$metadata['http://xxx.xxx.xxx/ssoapp/'] = array(
'AssertionConsumerService' => 'http://xxx.xxx.xxx/ssoapp/saml-auth/login',
'SingleLogoutService' => 'http://xxx.xxx.xxx/ssoapp/saml-auth/logout',
'NameIDFormat' => 'urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress',
'simplesaml.nameidattribute' => 'uid',
'simplesaml.attributes' => FALSE,
);

 

認証用アカウント(ID=test, Pass=test)を作成

# vi /var/www/simplasaml/config/authsources.php
<?php
$config = array(
    'example-userpass' => array(
        'exampleauth:UserPass',
        'test:test' => array(
            'uid' => array('test'),
            'eduPersonAffiliation' => array('member', 'employee'),
        ),
    ),

これで完了です。

 

 

■動作確認

http://xxx.xxx.xxx/loginにアクセスするとIdp側のログイン画面にリダイレクトされます。

そこで認証が完了すればSP側に戻って認証情報が参照できるはずです。

 

・動作サンプル




 

 

 

参考)

 

2017年4月20日

Mastodonをバージョンアップする

Filed under: 未分類 — ranpei @ 8:13 PM

この前v1.2.0が出たと思ったら

もうv1.2.2になってたのでサクッと更新しました。

※ docker環境での運用前提となります。

 

1.Mastodonリポジトリに移動


# cd mastodon

 

2.最新リポジトリを取り込みタグv1.2.2をチェックアウト


# git fetch

# git checkout -b 1.2.2 refs/tags/v1.2.2

 

3.コンテナの再ビルド


# docker-compose build web

# docker-compose build streaming

# docker-compose build sidekiq

 

4.DBを更新


# docker-compose run --rm web rails db:migrate

 

5.静的リソース(CSSや画像など)を更新


# docker-compose run --rm web rails assets:precompile

 

6.コンテナ起動


# docker-compose up -d

 

 

こんな感じでサクッと終わるのがDockerの良いとこです。

Mastodonで現在接続中のインスタンス一覧を取得する

Filed under: Docker,Mastodon — ranpei @ 1:33 AM

aboutなら接続中インスタンスの”数”ならわかるんですが、

実際どんなドメインと接続しているか知りたい場合に調べる方法です。
うちはdocker環境で運用していますが、PostgreSQLに接続してSQL叩ければOKです。

■ 接続ドメインの一覧を取得

# docker exec -it mastodon_db_1 bash
# psql -U postgres
# select * from (select distinct domain from accounts) as domains;
          domain
---------------------------
 social.targaryen.house

 mastodon.potproject.net
 gs.yvt.jp
 cksv.jp
 mstdnjp.wipiano.net
 mastodon.noraworld.jp
 pawoo.net
 z-socialgame.mstdn.cloud
 mstdn.h3z.jp
 mstdn.techdrive.top
 mstdn.hakai-macaron.com
 js4.in
 yontengop.com
 unnerv.jp
 mstdn.club
 md.ggtea.org
 friends.nico
 7144.party
 ostatus.ikeji.ma
 gnusocial.cardina1.red
 octodon.social
 cybre.space
 mastodon.social
 im-in.space
 mstdn-workers.com
 kero.ccsakura.jp
 m6n.onsen.tech
 mstdn.maud.io
 mstdn.kemono-friends.info
 mstdn.social
 boitam.eu
 mstdn.io
 mstdn.sanin.club
 mastodon.2502.net
 mastodon.paas.jp
 mstdn.nere9.help
 mstdn.nukaya.net
 mastodon.juggler.jp
 mstdn.mobilehackerz.jp
 mastodon.motcha.tech
 m.sighash.info
 jp-mstdn.com
 mastodon.cloud
 mstdn.aoitofu.net
 toot.mst-dn.me
 mdn.hinaloe.net
 mastodon.yumulab.org
 mstdn.jp
 mstdn.7kry.net
 ostatus.isidai.com
 pao.moe
 toot.kashishokunin.com
 mstdn.uec.tokyo
 oransns.com
 mstdn.haun.jp
 gs.smuglo.li
 mastodon.oresys.nagoya
 toot.yukimochi.jp
(59 rows)

空行が出てますがこれはローカルユーザーですので 59 – 1 = 58で接続インスタンス数にマッチしました。

 

追記)

v1.2.2で管理画面にUIが追加になりました。

https://github.com/tootsuite/mastodon/releases

  • List of known instances in admin UI (#2095)

 

2017年4月18日

Mastodonの永続化を忘れた場合の対処

Filed under: 未分類 — ranpei @ 8:32 PM

Mastodonの永続化をうっかり忘れた場合に

データを保ったまま永続化する手順です。

 

 

やり方は簡単で2種類のDBのバックアップを取り、

volumeの設定を施して再ビルドした後レストアするだけになります。

 

■バックアップ

・PostgreSQLのバックアップ


# docker exec mastodon_db_1 pg_dump -U > db_dump.sql

・Redisのバックアップ


# docker exec mastodon_redis_1 redis-cli save

# docker cp mastodon_redis_1:/data/dump.rdb redis_dump.rdb

 

■レストア

・PostgreSQL


# docker cp db_dump.sql mastodon_db_1:/tmp/dump.sql
# docker exec mastodon_db_1 bash -C "psql -U /tmp/dump.sql"

・Redis

# docker stop mastodon_redis_1
# docker run -it -v redis_dump.rdb:/data/redis_dump.rdb mastodon_redis_1 /bin/bash
# docker start mastodon_redis_1

 

 

 

P.S 半分記憶を頼りに書いてるので誤りがあれば連絡ください。

Mastodonインスタンスの立て方おさらい

Filed under: Docker,Mastodon — ranpei @ 8:04 PM

前回はさらっと流したけど、設定の足りていない部分などもあって

ちょくちょくいじっていたので整理も含めておさらいしてみます。

なお、構築環境は CentOS 7.0 (64bit)で以下はすでにあるものとして話しを進めます。

  • 外部送信可能なメールサーバー
  • 独自ドメイン

 

■Mastodonインスタンスの構築

・前提条件

Docker、Docker-Compose、Gitがインストール済みであること(なければここを参考にインストールしてください。)

・構築手順

1. 任意の場所にGitリポジトリをClone


# git clone https://github.com/tootsuite/mastodon.git

2. データ永続化

# cd mastodon
# vi docker-compose.yml
-----------------------------------------------------------
# volumes:
# - ./postgres:/var/lib/postgresql/data
  ↓ コメントを外す
 volumes:
 - /opt/mastodon/postgres:/var/lib/postgresql/data

# volumes:
# - ./redis:/data
  ↓ コメントを外す
 volumes:
 - /opt/mastodon/redis:/data
-----------------------------------------------------------

単にコメントを除去するだけでも良いのですが、
事故防止のためリポジトリの外に保存するようにしています。

 

3. 本番設定ファイルを編集


# cp .env.production.sample .env.production
# vi .env.production

-----------------------------------------------------------
LOCAL_DOMAIN=[独自ドメイン]
LOCAL_HTTPS=false ← いったんHTTPとしておきます(Nginx設定時に書き換えます)

PAPERCLIP_SECRET=[docker-compose run --rm web rake secretの実行結果(1回目)]
SECRET_KEY_BASE=[docker-compose run --rm web rake secretの実行結果(2回目)]
OTP_SECRET=[docker-compose run --rm web rake secretの実行結果(3回目)]

SMTP_SERVER=[SMTPサーバー]
SMTP_PORT=[SMTPポート]
SMTP_LOGIN=[SMTP認証ユーザー]
SMTP_PASSWORD=[SMTP認証パスワード]
SMTP_FROM_ADDRESS=[送信メールアドレス] ← このアドレスで通知メールが送られます
-----------------------------------------------------------

※ PAPERCLIP_SECRET、SECRET_KEY_BASE、OTP_SECRETに注意が必要です。
それぞれに別々のキーが必要なため生成コマンドを計3回実行して別々のキーを設定してください。

 

4. Dockerコンテナのビルド

# docker-compose build

 

5. 初期データ構築(DBテーブルや静的ファイルなど)

# docker-compose run --rm web rails db:migrate ← DB構築(正確にはDBマイグレーションというらしい)
# docker-compose run --rm web rails assets:precompile ← 静的ファイル作成みたい

6. Dockerコンテナ群の起動

# docker-compose up -d

“# docker ps -a”で5つのコンテナすべてが「UP」となっていることを確認後、
ブラウザを開き http://[ドメイン or IP]:3000 で画面が表示されることを確認しましょう。

 

■Nginxの設定(SSL対応)

・前提条件

Nginx、Gitがインストール済み

・構築手順

1. Let’s Encryptのインストール

# git clone https://github.com/letsencrypt/letsencrypt.git
# cd letsencrypt
# ./letsencrypt-auto --help ← これで必要なパッケージがインストールされる

 

2. 証明書作成

# git clone https://github.com/letsencrypt/letsencrypt.git
# cd letsencrypt
# ./letsencrypt-auto --help ← これで必要なパッケージがインストールされる
 ※初めての場合は途中で規約同意とメールアドレスを求められますので入力します。

生成が完了すると /etc/letsencrypt/archive/[独自ドメイン]/ 配下に必要ファイルが生成されています。

3. Nginxの設定(VirtualHost)

# cd /etc/nginx/conf.d
# vi [独自ドメイン].conf
 -----------------------------------------------------------
 server {
  listen 80;
  listen [::]:80;
  server_name [独自ドメイン];
  return 301 https://$host$request_uri;
 }
 server {
  listen 443 ssl;
  listen [::]:443 ssl;
  server_name [独自ドメイン];
 
  ssl_certificate /etc/letsencrypt/archive/[独自ドメイン]/fullchain1.pem;
  ssl_certificate_key /etc/letsencrypt/archive/[独自ドメイン]/privkey1.pem;

  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-Proto $scheme;
  proxy_set_header X-Forwarded-Host $http_host;
  proxy_set_header X-Forwarded-Server $host;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_read_timeout 600s;
  proxy_connect_timeout 10s;
 
  location / {
   proxy_set_header Host $host;
 
   proxy_pass http://127.0.0.1:3000/;
   proxy_redirect http://127.0.0.1:3000/ https://$host/;
 
   proxy_redirect default;
  }
  location /api/v1/streaming { ← 初期の手順では抜けてることが多いです。
   proxy_set_header Host $host;
   proxy_set_header Proxy "";
   proxy_http_version 1.1;
   proxy_set_header Upgrade "upgrade";
   proxy_set_header Connection $connection_upgrade;
 
   proxy_pass http://127.0.0.1:4000;
   proxy_redirect http://concrete https://$host;
 
   tcp_nodelay on;
  }
 }
 -----------------------------------------------------------

あくまでメモなので最小限ですが公式に設定ファイルのサンプルがありますので、
そちらを編集した方がよいでしょう。

 

4. 本番設定ファイルを編集

# vi .env.production
 -----------------------------------------------------------
 //確認のためHTTPとしていた箇所をHTTPSオンリーに変更します。
 LOCAL_HTTPS=false
  ↓
 LOCAL_HTTPS=true
 -----------------------------------------------------------

 

5. 設定反映

# docker-compose up -d ← これで.env.productionファイルが反映されます(再ビルドの必要はありません)
# service nginx restart

ブラウザを開き https://[独自ドメイン] で画面が表示されることを確認しましょう。

 

以上が今までやってきたことのまとめになります。

2017年4月15日

Mastodonインスタンス(サーバー)を構築してみる

Filed under: Docker,Mastodon — ranpei @ 8:53 PM

ここ数日何やらMastodonというのが話題となっているらしく、

新しいもの好きとして早速試してみました。

 

 

当サーバーはDocker導入済みのため、

GitHubからCloneして、GitHub上説明をもとに構築するとサーバー構築自体はあっさりと終わりました。

やはりこういうところがDockerの強みだな・・と改めて思いましたね。(唐突な所感w)

 

ただ、アカウントを作成しようとしたところで少し躓きましたのでメモ。

 

■発生した問題

Mastodonにアカウントを登録すると確認メールが送信されてくるのですが、

なぜかそのメールがいくら待っても送られてこないのです。

 

自前のメールサーバーに問題があるのか?と思い調べてみても

コマンドやメールクライアントからの送信は普通にできるため

何が原因だろうと思っていたら以外な方法で解決してしまいました。

 

■解決した方法

この問題、メールサーバーをIPアドレスで指定せず、ドメインで指定することで送られるようになりましたw

 

実装がどうなっているかわかりませんが、

設定ファイルのコメントで外部メールサーバー(https://sparkpo.st/smtp)の利用を推奨しているので

IPアドレスで接続するのはそもそも想定していない?のか??

 

まあ、何はともあれこれで利用できるようになったのでいいとしますか。(内部DNS作っててよかった~)

 

以下のドメインで公開しておりますので試しに触ってみたいという方はどうぞ

https://mstdn-jp.site/

 

 

P.S

メールに関して少し調べると「メール送信の遅延」が確認されているとのことですが、

私の勝手な想像ですが、みんなsparkpo.stを使うもんだからアクセス数が増大して

遅延してるんじゃないんですかね・・・

2016年11月7日

Docker + LDAP+ MailServer(Postfix + dovecot) + Roundcubeを構築する

Filed under: Docker,Linux,OSS,postfix,Roundcube,オープンソース — ranpei @ 3:11 AM

ちょっと流れから脱線しますが、

Dockerを使ってのメールサーバー構築に成功したため

その内容をメモとして残します。

 

1.メールサーバーの要件

現在のメールサーバーの使い方なのですが、

以下の2つがあるためこれらを満たす必要があります。

・サービス毎のメールアカウント管理

・フリーメールの集約

サービス毎のメールアカウントを管理するのは前にも言ったようにLDAPL+バーチャルメールボックスで行けるのですが、

フリーメールの集約はFetchmailを使っているためこれが動作する環境である必要があります。

ではできるのか?というとRoundcubeにはFetchmailの設定をWeb上で行えるプラグインが存在します。

ですが、Fetchmailは取得したメールをローカルのMDAにフォーワードすることしかできないのできません。

つまりRoundcube自身にプラグインが入った状態でなおかつローカルにMDAが存在する必要があるのです。

 

2.考えられる構成は?

考えられる構成は2種類あります。

1つは以下のようにすべてを1つのContainerにまとめること。

%e3%83%a1%e3%83%bc%e3%83%ab%e3%82%b5%e3%83%bc%e3%83%90%e3%83%bc_%e5%8d%98%e4%b8%80%e3%82%b3%e3%83%b3%e3%83%86%e3%83%8a

もう1つは以下のように転送用のメールサーバーを構築してメインのメールサーバーにメールを転送すること。

%e3%83%a1%e3%83%bc%e3%83%ab%e3%82%b5%e3%83%bc%e3%83%90%e3%83%bc_%e5%88%86%e9%9b%a2%e5%9e%8b

 

今回はどうしてもメールサーバーとRoundcubeは別に構築したかったため後者で構築を行いました。

 

3.メールサーバーを構築する

これらのContanerについては要件を満たすものがなかったため

DockerHub上のものを改造する形で自分で作りました。

GitHubに挙げてますのでダウンロードしてください。

 

// メールサーバーのチェックアウト
$ git clone https://github.com/gittrname/mailserver-ldap.git
// Roundcube + Fetchmailサーバーのチェックアウト
$ git clone https://github.com/gittrname/roundcube-fetchmail.git

・docker-compose.yml

version: '2'
services:  
  mail:  
    build: mailserver-ldap  
    ports:  
      - "25:25"  
      - "465:465"  
      - "587:587"  
      - "110:110" 
      - "143:143"  
      - "995:995"  
      - "993:993"  
    links:  
      - ldap  
    extra_hosts:  
      - "mail.example.com:127.0.0.1"  
    environment:  
      - "LDAP_SERVER=ldap"  
      - "DOMAIN=example.com"  
      - "HOSTNAME=mail.example.com" 
      - "LDAP_BASE=ou=People,dc=example,dc=com"  
      - "LDAP_USER_FIELD=uid"  
  roundcube:
    build: roundcube-fetchmail
    ports:
      - "80:80"
    links:
      - ldap
      - mail
    extra_hosts:
      - "fetch.example.com:127.0.0.1"
    environment:
      - "ROUNDCUBE_DEFAULT_HOST=mail"
      - "ROUNDCUBE_SMTP_SERVER=mail"
      - "ROUNDCUBE_USERNAME_DOMAIN=example.com"
      - "HOSTNAME=fetchmail.example.com"
  ldap:  
    image: sharaku/ldap  
    ports:  
      - "8080:80"  
    environment:  
      - "LDAP_DOMAIN=example.com"  
      - "LDAP_ADMIN_PWD=password"  
      - "LDAP_ORGANISATION=LDAP for docker."

 

※ RoundcubeとLdapAdminのポートが被らないようにしてください。

後はLdapAdmin上でユーザーを作成すればメールアカウントの作成は完了します。

 

 

定期的なメールの取得はログインした後「設定」⇒「Fetchmail]で設定します。

取得先のドメイン、ユーザー、パスワードを設定すると15分間隔でメールを取得し、

ログインユーザー@ドメインにメールを転送します。

 

ちょっとデータの永続化に多少の不安がありますが

一応、やりたいことはできたので公開してます。

2016年10月28日

Docker + PowerDNS + Sqlite + PowerDNS AdminでDNSサーバーを作る

Filed under: Docker,ESXi,OSS,オープンソース — タグ: — ranpei @ 12:00 AM

内部ツール系サーバーを構築するに当たり

内部DNSサーバーにはBindでは無くPowerDNSを使用していきます。

 

PowerDNSを使うことにしたのは単にGUIツールが存在しており

ファイルをいじって設定する手間が省けるな~とおもたっからですw

 

1.Dockerイメージを作成する

管理するドメインは大した量ではないのでDBにはSqliteをチョイス

管理GUIはSqliteに対応した物が無いため、API駆動のPowerDNS Adminを選んでみました。

PowerDNS + SqliteのDockerイメージは見つかったものの、

PowerDNS AdminのDockerイメージは見つからないし・・・・

そもそもこれぐらいならひとまとめにしてもいいじゃない!

ってことでPowerDNS + Sqliteをベースに自分で作ってみました。

[github]

PowerDNS Adminが80番ポートを使用するため、

PowerDNS標準のWebサーバーが8080番ポートに変更になっています。

また、内部運用するに当たり「DNSフォワーダ」の設定が追加されたので

管理外ドメインの問い合わせを外部にフォーワードしてくれます。

2.Dockerコンテナを起動する

$ git clone https://github.com/gittrname/powerdns-sqlite3-gui.git
$ docker build -t powerdns-sqlite3-gui powerdns-sqlite3-gui
$ docker run -p 53:53/tcp -p 53:53/udp -p 80:80 powerdns-sqlite3-gui

起動したらブラウザでGUIにアクセスしまずは管理用アカウントを新規に作成してください。

powerdnsadmin%e3%83%ad%e3%82%b0%e3%82%a4%e3%83%b3%e7%94%bb%e9%9d%a2 powerdnsadmin_%e3%82%a2%e3%82%ab%e3%82%a6%e3%83%b3%e3%83%88%e7%99%bb%e9%8c%b2

作成したアカウントでログインしたらドメインを追加しレコードの設定を行います。

powerdnsadmin_%e3%83%80%e3%83%83%e3%82%b7%e3%83%a5%e3%83%9c%e3%83%bc%e3%83%89 powerdnsadmin_%e3%83%89%e3%83%a1%e3%82%a4%e3%83%b3%e8%bf%bd%e5%8a%a0

digコマンドで動作の確認ができればDNSサーバーの構築は完了です。


$ dig www.ranran.mydns.jp @[DNSサーバーのIP]

; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.ranran.mydns.jp @[DNSサーバーのIP]
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35567
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1680
;; QUESTION SECTION:
;www.ranran.mydns.jp. IN A

;; ANSWER SECTION:
www.ranran.mydns.jp. 3600 IN A [対象サーバーのIP]

;; Query time: 43 msec
;; SERVER: 192.168.11.102#53(192.168.11.102)
;; WHEN: Thu Oct 27 23:59:11 JST 2016
;; MSG SIZE rcvd: 64

Older Posts »

Powered by WordPress