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

2019年6月24日

運用中のMisskeyをv10→v11に更新する。

Filed under: Fediverse,Misskey,オープンソース — ranpei @ 1:06 AM

分散型SNSが流行りだした当初、MastodonのほかにもMisskeyという国産の分散SNSも運用してまいりました。

月日はたちMisskeyも順調に開発が進められてついにv11になったのですが、
このv11からDB鯖がMongoDB→PostgreSqlに変更となったため
更新にひと手間かかります。

国産でありながらあまり情報が出回って無いようですので、
何かのお役に立てばと共有がてらメモを記録します。

■更新手順

リリースノートに更新の作業について書いているのですが、更新手順として

  • 最新ソースを取得後、migrationブランチをチェックアウトする。
  • 設定ファイルにMongoDBとPostgreSQLの接続設定を記載する。
  • ※またconfig.yml内のid:’aid2’となってる箇所をid:’objectid’にしてください
  • npm migrateを実行。
  • ブランチをmaster(もしくは使用するバージョン)に戻してMisskeyを起動する。

を行えばよいです。

ただ、上記には補足があって11.23.0現在までmigrationブランチは整備されています。
なのでv10.100→v11.0.0(migration)→v11.0.0(master)→最新verって感じに徐々に上げていく必要はありません。

上げる場合はその時点での最新バージョンで行いましょう。


手順は割愛します。リリースノート通りにやれば問題ないんで。

(むしろ更新するバージョンに合わせないと何度もやり直す羽目になります;;)

2019年3月1日

Dockerコンテナでポート変更せずに共存させる方法

Filed under: Docker — ranpei @ 8:45 PM

Dockerでサービスを起動させる場合

# docker run -p 80:80 wordpress

wordpress:
  image: wordpress
  ports:
    - "80:80"

って感じでポートを開けますね。

でもこのポートがかぶっていた場合はどうしますか?

“81:80”, “82:80”, “83:80” って開放するポートをずらして起動します?

 

それでも良いですがDockerのネットワーク機能を使うことで

ポートを変更せずに同居させる方法があるのでご紹介します。

 

■方法

やり方は簡単です。以下のように起動コンテナに固定のIPアドレス割り当てるだけです。

version: '3'
services:
  concrete5:
    image: concrete5
    restart: always
    networks:
      vpcbr:
        ipv4_address: 172.168.0.2
  wordpress:
    image: wordpress
    restart: always
    networks:
      vpcbr:
        ipv4_address: 172.168.0.3
networks:
  vpcbr:
    driver: bridge
    ipam:
      config:
        - subnet: 172.168.0.0/16
          gateway: 172.168.0.1

 

後はリバースプロキシ設定に固定化したIPアドレスを設定するすれば

ポート変更の必要なくサービスを同居させることができます。

 

■補足

当然ですが同じDockerネットワーク上にいることが条件です。

複数ホストで運用している場合は相互に通信できるようにDockerネットワークを構築してください。

ネットワークイメージ

(当サーバーではホスト上にインストールしたNginxでリバースプロキシしています)

2019年2月27日

マストドンを初めて使う人のためのハウツー

Filed under: Fediverse,Mastodon,オープンソース — ranpei @ 9:37 PM

これからマストドン(Mastodon)を始めようとする方が戸惑うポイントをつらずらと書いていきます。

 

■基本編

  • マストドン(Mastodon)って何?

    Twitterライクな分散型SNSです。(とりあえず今はこれだけ覚えてください。)

  • まず何をすればいいの?

    気になるアカウントをどんどんフォローしていって
    メインとなるホームタイムラインを充実させましょう。

  • 知らない人をいきなりフォローして失礼じゃないの?

    問題ありません。むしろマストドンは「勝手フォロー」「勝手ブースト」が推奨です。

  • Twitterと全然違うね。。。

    別物なんですからむしろ当然では?
    下手にTwitterと同じように使うよりも、別の切り口で使った方が楽しいかもですよ?

■使い方編

  • トゥートって何?

    Twitterでのツイート(つぶやき)のことです。

  • ブーストって何?

    リツイートのことです。

  • 「ホーム」「ローカルタイムライン」「連合タイムライン」って何?

    とりあえずは以下の認識で・・・・

    [ホーム] :メインで利用するやつ。(どんどんフォローしてにぎやかにしましょう。)
    [ローカル]:このサーバーにいる人たちの公開トゥートが見れる。
    [連合] ※ :このサーバー”以外”の人たちの公開トゥートが見れる。(ここから気になる人を見つけてどんどんフォローしよう)

    ※ ごめんなさい。分散型の核となる機能なんですが説明量が多いんで省かせてください;;

  • カメラアイコンの横に「公開」「未収載」「フォロワー限定」「ダイレクト」ってあるけど詳しく教えて

    トゥートの公開範囲ですね。トゥートが見れる範囲が以下のようになります。

    [公開] :トゥートがタイムラインに流されて多くの人の目に留まりやすくなります。
    [未収載] :トゥートはタイムラインには流されませんが、見れないわけではありません。(あなたのアカウントをたどれば普通に見れます。)
    [フォロワー限定]:フォロワーのみが見れる状態でトゥートします。
    [ダイレクト] :特定のアカウントと1対1で話す場合に使用します。(まんまTwitterのDMですね。)

  • 画像を上げると目のアイコンが出たんだけど何?

    NFSWを設定して画像を投稿するオプションです。

  • NFSWって何?

    画像を隠した状態でタイムラインに流します。
    その画像を見る人が不快に思ったり、傷つくことが予想される場合に使用します。

    見る人はクリック(or タップ)すれば画像が見れる状態になります。

  • それ意味あるの??

    ワンクッション置くことで見る人は心の整理が付きますし、
    本当に見たくない人はそのまま見なければいいです。

    私は相手に選択の余地を残してあげる「思いやり」だと思っています。

  • CWって何?

    NFSWの文字版。
    タイムラインには折りたたまれた状態でトゥートが流れます。
    そのトゥートを見る人が不快に思ったり、傷つくことが予想される場合に使用します。

  • ってことは・・・

    はい。見る人はクリック(or タップ)すれば見れる状態になります。

    でもいきなり言葉を投げつけられるよりも
    相手に受け取るかを選択してもらう方が親切ですよね。

 

※もっと楽しく使いたいなら以下のサイトもおすすめです
〇Quesdon(ザ・インタビューズとかaskfmとかそんなかんじのやつ)
https://quesdon.rinsuki.net/
〇カスタム絵文字でお絵かきツール
https://mamemomonga.github.io/mastodon-custom-emoji-oekaki/
〇ドン廃あらーと(毎日午前0時にアカウントの変動状態をトゥートします)
https://donhaialert.herokuapp.com/

2018年8月20日

GoAccessを使ってリアルタイムアクセス解析を行う

Filed under: GoAccess,Linux,Nginx,OSS,ログ,不正アクセス — ranpei @ 9:04 PM

Ubuntu 16.04 + Nginx にGoAccessを使ったリアルアイムアクセス解析の環境を作ったのでその内容をメモ。

 

1.GoAccessをインストール
これは公式の手順を参考にインストール。

// 必要パッケージをインストール
$ sudo apt-get -y install libncursesw5-dev gcc make
$ sudo apt-get -y install libgeoip-dev libtokyocabinet-dev

// GoAccessをダウンロード
$ wget http://tar.goaccess.io/goaccess-1.2.tar.gz

// コンパイルしてインストール
$ tar -xzvf goaccess-1.2.tar.gz
$ cd goaccess-1.2
$ sudo ./configure --enable-utf8 --enable-geoip=legacy
$ sudo make
$ sudo make install
$ sudo ln -s /usr/local/bin/goaccess /usr/bin/goaccess

インストールできたら試しに解析してみる。

$ sudo goaccess /var/log/nginx/access.log --log-format=COMBINED

こんな画面が表示される。

 

さて、GoAccessは解析結果をHTMLとして出力することもでき、
さらに –real-time-html オプションをつけることで常時情報が更新されるHTMLを出力できます。

注意点としては情報更新の通信(WebSocket)に 7890番ポートを使用するためFWを開放しておきましょう。

$ sudo ufw allow 7890

※ ルーターの開放なども必要ですが割愛します。

開放したら以下のコマンドでリアルタイム解析HTMLを出力しましょう。

$ sudo goaccess /var/log/nginx/access.log -a -o /usr/share/nginx/html/report.html --real-time-html --log-format=COMBINED

http://[ホスト名 or IPアドレス]/report.html にアクセスすると以下ような画面が見れるはずです。

 

 

2.サービス化する
常時起動するには毎回先ほどのコマンドを実行するわけにはいきませんので、

今回はサービス化して常時起動する状態にしたいと思います。

// 定義ファイルを作成
$ sudo vi /etc/systemd/system/goaccess.service
↓↓ 記載
[Unit]
Description=Goaccess Web log report.
After=network.target

[Service]
Type=simple
User=root
Group=root
Restart=always
ExecStart=/usr/local/bin/goaccess -a -g -f /var/log/nginx/access.log -o /usr/share/nginx/html/report.html --real-time-html --log-format=COMBINED --ws-url <host名>
StandardOutput=null
StandardError=null

[Install]
WantedBy=multi-user.target
↑↑ 記載

// サービスファイルとして認識されたか確認
$ sudo systemctl list-unit-files --type=service | grep goaccess
goaccess.service disabled ← 表示されればOK

// サービスを有効化
$ sudo systemctl enable goaccess

// サービス起動
$ sudo systemctl start goaccess

// サービス状態確認
$ sudo systemctl status goaccess
● goaccess.service - Goaccess Web log report.
Loaded: loaded (/etc/systemd/system/goaccess.service; enabled; vendor preset: enabled)
Active: active (running) since 月 2018-08-20 16:46:27 JST; 4h 5min ago
Main PID: 91584 (goaccess)
Tasks: 3
Memory: 3.7M
CPU: 1min 7.536s
CGroup: /system.slice/goaccess.service
mq91584 /usr/local/bin/goaccess -a -g -f /var/log/nginx/access.log -o /usr/share/nginx/html/report.html -

8月 20 16:46:27 MainServer systemd[1]: Started Goaccess Web log report..

起動できたら先ほどのURLにアクセスしてみましょう
きちんと解析画面が表示されれば設定完了です。

 

あとは必要であればアクセス制限を設けるなどしてください。

2018年4月22日

1つのサーバーでMastodonとPleromaを運用すると相互にフォローできない件

Filed under: Docker,Mastodon,OSS,オープンソース — ranpei @ 8:31 PM

うちの鯖ではDockerで構築したMastodonとPleromaとMisskeyの各インスタンスをVirtualHostでドメインごとに振り分ける運用をしています。

 

ただ、外部のインスタンスとはフォローし合えるのに内部のインスタンス同士ではフォローできずに困っておりました。

 

で、原因を探ったら以下の手順を踏むことで回避できました。

■回避方法

  1. DNSやhostsを使って名前解決できるようにする。
  2. Mastodonのソースをいじる。

 

順に説明していきます。

 

1.DNSやhostsを使って名前解決できるようにする。

まあ、これは真っ先に疑うことですよね^^;

LAN内部からドメインでアクセスするためには内部DNSを構築するかhostsを書き換えなければいけません。

うちは内部DNSを構築済みだったためこいつに設定を追加するだけで済みました。

そして、相互に名前解決できるようになったのですがこれだけでは不十分という・・・・

(一応Mastodonの検索欄で”@名前@ドメイン”で検索した際のエラーが「503 Remote data could not be fetched」→「422 Mastodon::HostValidationError on ドメイン」と変化しました)

 

 

2.Mastodonのソースをいじる。

この「422 Mastodon::HostValidationError」ってエラーについて調べてみてもよくわかんない(422ってWebDav拡張のステータスらしいですが・・・)

しょうがないのでMastodonのソースを見て「Mastodon::HostValidationError」がスローされている箇所を見てみると

app/lib/request.rb(135行目)に気になる部分を発見。

        Addrinfo.foreach(host, nil, nil, :SOCK_STREAM) do |address|
          begin
            raise Mastodon::HostValidationError if PrivateAddressCheck.private_address? IPAddr.new(address.ip_address)
            return super address.ip_address, *args
          rescue => e
            outer_e = e
          end
        end

これはプライベートアドレスの場合は問答無用にHostValidationErrorにしている??

 

で、PrivateAddressCheckについて調べてみるとconfig/environments/development.rbでわざわざfalseを返すように書き換えを行っていました。

ということはここのチェックでfalseとなるようにすればいいのでは??っと思いconfig/environments/production.rb側に以下の記載を追記。

module PrivateAddressCheck
 def self.private_address?(*)
 false
 end
end

 

そしてDockerコンテナをビルドしなおしてみると・・・・


$ docker-compose build web
$ docker-compose up -d

無事検索欄で”@名前@ドメイン”で検索してもちゃんとアカウントが表示されるようになりましたv^^v

 

 

とりあえずフォローできない問題は解決したんですが以下の2つが気になる。。。

  1. Mastodonはなぜわざわざプライベートアドレスをはじくようにしているのか?
  2. この対応の仕方で不都合が起きることはないのか?

そんなわけでこの対処方法は自己責任で行ってください。

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"
&nbsp;
"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)

 

Older Posts »

Powered by WordPress