Ubuntu18.04へのアップグレードに伴うデバイス名の変化

Ubuntu16.04で液晶タブレット(UGEE HK1560)をデュアルディスプレイで使うとき、ペンタブレットの入力を片方のディスプレイのみにマッピングするためにはxinputの"Coordinate Transformation Matrix"プロパティを使う。

私の場合は左のディスプレイ(液晶タブレット)が1920x1080で右のディスプレイが2560x1440だ。つまり液晶タブレットの入力はそのままだと2つのディスプレイをつなげた4480x1440の長方形にマッピングされる。これを左のモニターのみにマッピングするためには、x座標0~4480を0~1920に、y座標0~1440を0~1080に写像するような変換行列を用いる(3行3列の1はたぶん筆圧は無変換っていう意味だったと思う)。

さて、これを実行するコマンドは
xinput set-prop "UC-Logic TABLET MONITOR Pen" --type=float "Coordinate Transformation Matrix" 0.428571 0 0 0 0.75 0 0 0 1
だっ。Ubuntu16.04では。

Ubuntu18.04にしてからこのままのコマンドでは以下のようなエラーを吐くようになった。

X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  131 (XInputExtension)
  Minor opcode of failed request:  57 ()
  Serial number of failed request:  19
  Current serial number in output stream:  2

なんだこれは?ググっても全然わからない。そもそもLinuxでペンタブレットを使おうという変態の絶対数が少ない。

xinputでデバイス名を確認したらこうなっていた

⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ UC-Logic TABLET MONITOR Mouse           	id=10	[slave  pointer  (2)]
⎜   ↳ E-Signal COUGAR Minos X3                	id=11	[slave  pointer  (2)]
⎜   ↳ E-Signal COUGAR Minos X3                	id=12	[slave  pointer  (2)]
⎜   ↳ LingYao ShangHai Thumb Keyboard         	id=16	[slave  pointer  (2)]
⎜   ↳ UC-Logic TABLET MONITOR Pen Pen (0)     	id=18	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ Power Button                            	id=6	[slave  keyboard (3)]
    ↳ Power Button                            	id=7	[slave  keyboard (3)]
    ↳ Sleep Button                            	id=8	[slave  keyboard (3)]
    ↳ UC-Logic TABLET MONITOR Pen             	id=9	[slave  keyboard (3)]
    ↳ Mistel MD600                            	id=13	[slave  keyboard (3)]
    ↳ Mistel MD600                            	id=14	[slave  keyboard (3)]
    ↳ LingYao ShangHai Thumb Keyboard         	id=15	[slave  keyboard (3)]
    ↳ E-Signal COUGAR Minos X3                	id=17	[slave  keyboard (3)]

理屈はわからないが、なぜかこれまで使っていたデバイス名"UC-Logic TABLET MONITOR Pen"はキーボード扱いになっていた。その代わりに"UC-Logic TABLET MONITOR Pen Pen (0)"という怪しげなデバイスが出現している。先ほどのコマンドのデバイス名をこちらに入れ替えたところ、成功した。

LinuxでHK1560は普通に使える。筆圧も取れる。ワコムの同サイズ製品は18万円するのに対してHK1560は現在4万円だ(こちらはFHDであちらは4Kだが)。ガラスの厚みによる視差は液タブの宿命として当然あるが、それはワコムだろうとゼロにはできない以上程度の問題でしかない。発色が悪いと言われている(おそらく1677万色ではない)が、僕はそもそもきちんとキャリブレーションされたモニターを一つも所有していないのでこれを問うのは無意味だ。ペン先の沈み込みもよく不安がられる要素だが、ワコムの飛び出したり引っ込んだり不安定なペン先よりは弾力のあるこちらのペンの方が描きやすく、筆圧も自然につけられる。ワコムはドライバが不安定だと言われるが、こちらはLinuxで幅広く使われているxinputで作業中のトラブルは一度もない。

描画ソフトにはKritaを使っている。非常に大きな特徴として消しゴムツールが存在しない(全てのブラシツールに消しゴムモードがあり、オンオフして使う)ことが挙げられるが、慣れればどうということはない。

実はメインマシンをUbuntuに変えるときにこの辺りの用途がきちんとこなせるか不安だったのだが、マッピングを解決するだけですぐに使えたことで僕の中でのUbuntuへの信頼が高まった。

今日のUI心理学

2.2 類同

見た目が似ているものはグループとして見える。当たり前だね。小学生がやるみたいにメニューの項目で1つずつ色を変えたりしてはいけないということだ。

痛恨のミス

今日はポノック短編劇場『ちいさな英雄-カニとタマゴと透明人間-』を見てきた。事前にチケットを取ってからいったが、劇場の端末が反応しない。おかしいなと思って確認したら別の場所の劇場のチケットを取っていた。もう間に合わない時間だったので仕方なく行った劇場のチケットを取り直したが、1400円を虚空に溶かしてしまった。南無。

TI8はOGが優勝した。2-2でむかえた5ゲーム目、OGが選択したヒーローは癖が強かったが、anaのEmber Spiritが移動スキルを存分に活用し、死にそうで死なないまま戦闘に参加し続けることで勝利を手繰り寄せた。

7秒の時点でHPを入れ替えるスキルによってかなりHPを減らされるが、即座に移動スキルで右上に退避。短時間無敵になるアイテム(上空に巻き上がっている)の効果中に味方に安全を確保してもらう。その後回復アイテムですこし回復を入れたあと26秒から高速斬撃のスキルで再参戦。さらに30秒には移動スキルで残った敵に飛び込む。ここで敵の増援が瞬間移動アイテムで飛び込んで強力な範囲攻撃を放つが、ギリギリ死なない。高速斬撃スキルと無敵アイテムで数秒間しのいだあと歩いて下がるが、高速斬撃スキルをギリギリの間合いから放ってキル。

惚れ惚れするムーブだ。もちろん敵味方総勢10人が入り乱れて戦っているので偶然による部分も多いだろうが、体力が少ない状態でもスキルで飛び込む判断には度肝を抜かれた。

それにしてtwitchの切り抜き機能マジで便利だな。ニコニコにも欲しい。

ンギモチィィィ

※この記事は『秋梨 チューハイ』を飲んで書かれた。

JavaScriptで文字列の入った2次元配列をcsv風に結合する関数。最初はforループで以下のようなコードを書いた。

しかしこの方がずっとスマートだ。

そもそも上のようなコードを書くなという話。

ちゃんとUI心理学をやりたいのだが、今日は時期が悪い。何かというとTI8決勝だ。TI8というのはThe Internatinal 2018の略で、Dota2というPCゲームの世界大会だ。Dota2はLoLと同ジャンルで、この大会の賞金総額はe-sports界で1位だ(2500万ドル)。

1年間の各種大会の実績で8チームが招待され、加えて10チームが各地域の予選で出場権を獲得する。ある時期を過ぎてからメンバーを入れ替えたチームは招待を受ける権利を失う。1チーム5人なのだが、メンバーの入れ替わりが非常に多くそれを問題視したValve(開発元・TI運営)によってメンバー変更にペナルティが課されている。

面白いのは3位以上が確定している3チームのうち2チームはかなり遅い時期にメンバーを入れ換え、予選を勝ち抜いて出場してきたチームだ。世界トップクラスの選手になると、連携のために重要なのは練習ではなく相性ということだろうか。

OG

ヨーロッパのチーム。TI6とTI7の間のシーズンの大規模大会で全て優勝しTI7の優勝候補だったが、7位に終わる。その後midのanaが脱退し、長い低迷期に入る。TI8の3ヶ月前にFlyとs4も脱退するが、anaが復帰。予選を突破して本戦に出てみたらなぜか破竹の勢いで勝ち進み、グランドファイナル進出を決めている。

EG

TI5優勝。TI7は9位。本拠地は北米。メンバーはヨーロッパ。引退してコーチに回った選手をまた戻してみたり、かと思えばそのために優秀なmidプレイヤーを他のポジションに移動したりと謎の迷走を続けていたが、OGを離脱したFlyとs4を獲得して予選突破。

PSG.LGD

TI7は4位。中国人4人とマレーシア人1人のチーム。中国は強いチームが多い。シーズン中盤にメンバーが入れ替わって以降躍進し、招待枠2位で参加している。

もしグランドファイナルがEG vs OGなんてことになったらOGの元プレイヤーが2チームに別れて対戦するということになって面白い。

 

 

終電チャレンジ

内定先の懇親会があった。面白そうな部署の面白そうな話を聞くことができた。

そのあと近くの映画館で映画を見てきた。終了時刻が24時だったが、まさか終電がない時間に終わる映画はなかろう(明らかなレイトショーを除いて)と思って調べずにチケットを買った。

結果としては、結構危なかった。終電の5分前にホームについた。

それにしても、Macでなにやら作業しながらホームのベンチで終電を見送ったあの人は何者だったのだろう。

ぐぎぎぎぎぎ

使い慣れたものの感覚を捨てて新しいものに慣れようとしているときの僕が発する音。

2017年春からVirtualboxでUbuntuを使っており、2018年1月からはメインPCもUbuntuにした。ずっとUnityデスクトップを使ってきた。2018年春にUbuntu18.04がリリースされ、7月末には16.04からのアップグレード機能が提供された。

16.04は2021年までサポートされるが、僕は新しいものが好きだし、飛び移るときの高低差が小さいうちにどんどん新しいものに移っていくことが時代に取り残されないために大切なことだと思うので18.04にアップグレードした。

OSの機能としては特に変化は感じない。性能やセキュリティが若干向上しているらしい。大きく変化したのはデスクトップ環境だ。UnityからGNOME3に変わった。タイトルバーやらトップバーが無意味に空間を占拠していることに憤りは感じているが、空間の効率的な利用は絶対的な善なのでGNOMEにもやがてLIMが導入されるだろう。

GNOMEには多彩な拡張機能があるが、ちゃんと動かないものや組み合わせると動かないものなどがあり、気持ちが悪い。「拡張機能で自由自在」というのはよくない。ユーザーが好き勝手に拡張機能を作るということは、それらの間で爆発的に増えていく組み合わせのパターンを管理する人間がいないということだ。バニラが一番不愉快なエラーに遭遇しにくいし、だからこそバニラの使い心地こそが重視されるべきだ。

これはChrome拡張でOperaのスピードダイヤルを再現したものだ。見ればわかるが、右端に隙間がある。設定上は「4列」にしてあるにもかかわらずなぜか3列+空き列になる。実はさっきまでこの現象は直っていたのだが、GNOMEのbuggyな拡張を全部消したら戻ってしまった。ままならない。この左右非対称性にはいつまで経っても慣れない。気持ちが悪い。

今日は実験プログラムの最終調整(いつまで最終調整してるんだ)をした。同期が学部生向けの授業で使う実験プログラムをつくるらしいのだが、どうやらいつ誰が作ったかもわからない、ソースコードも残されていないプログラムを作り直す案件らしい。悲しい話だ。メンテナンスする人間がいなくなり、する方法も失われたプログラムの末路は死しかない。

明日は内定者懇親会ということで、内定先の金で銀座のうまい飯が食える。どうせなら映画もなにか見に行きたいところだ。

アルゴリズム

※この記事は『WHITE BELG』を飲みながら書かれた。

実験を実施するにあたってプログラムの最終確認をしていたら、アルゴリズムがおかしいところがあった。修正しようと思ったが、どうもスマートにいかない。難しい。

隣の研究室で実験用PCが壊れた。聞くと7年目とのことなので仕方がない。中のデータを取り出したいそうだが、たぶんHDDを引っこ抜いてSATA-USBケーブルで繋げばいけますよと伝えた。

研究室ではthinkpadのキーボード、自宅ではBaroccoピンク軸を使っているが、どちらも素晴らしく甲乙つけがたい。thinkpadのキーボードの良さはストロークの浅さと反発の良さで、底までバシバシ打ち込めて気持ちいい。Baroccoピンク軸は押した強さに比例する反発力があり、底まで押し込まなくても反応するので非常に軽いタッチで入力できる。これはこれで気持ちが良い。

下のUI心理学を書きながら気づいたんだが、GNOMEのアプリケーションメニューを表示しないという仕様クソすぎない?Kritaでまったく何もできないんだけど。どういうこと?

今日のUI心理学

2.1 近接の要因

距離の近いオブジェクトはグループとして知覚される。これから先いくつかのグループ化の要因を取り上げていく。ゲシュタルト心理学ではそれらがグループとして知覚される理由を「よいまとまり=プレグナンツを構成するから」と説明するが、説明になっていない。多くの興味深い現象を発見したにもかかわらずゲシュタルト心理学という枠組み・流派が現在では廃れているのはこのためだ。

 

実験をするぞ

※この記事は『極搾り ピーチチューハイ』を飲みながら書かれた。

予備実験、学会発表を終えたのでいよいよ本格的な実験に入る。

今日はgoogleフォーム・スプレッドシート・カレンダーをフル活用して予約システムを構築した。最初はwordpressのプラグインでやろうと思っていたが、ゴミの山の中から使えるプラグインを探す手間が面倒になったので別の方法を探したらこの方法が見つかった。google様はすごい。

実験参加者にド鬱日記を見せるのはよろしくないという判断から、過去の日記が目に入りにくいようにホームページのメニュー構成を変えた。積極的に調べて見つけた人には隠すつもりはない。

明日は実験プログラムの最終調整をして、各所に実験参加者募集のお知らせを流すまでいきたい。目標は9月7日までに40人だが、どうなるか。卒論のときは友人に片っ端から頼んだが、今は卒業している友人が多い。難しいだろう。

今日のUI心理学

1.4はつまらないので飛ばす。2章はゲシュタルトの法則について述べられている。具体的なゲシュタルトの法則に入る前に、心理学史の講義にしよう。

ヴントがライプチッヒ大学に心理学実験室を開設した1879年が「科学としての心理学」の始まりと言われる。ヴントは自分の心の動きを自分で観察する内観法を用いて心を構成要素に分解する構成主義を志向した。

1910年にウェルトハイマーは、静止画像を続けて見ると動いているように見えることを発見した。画像Aと画像Bしか見せていないのに動きという第3の知覚が発生するこの現象は、動きに直接対応する知覚要素が存在しないという点においてヴントの構成主義を否定するものだった。

この発見に端を発して、ウェルトハイマー・ケーラー・コフカらは個々の刺激が作り出す全体的なまとまり(ドイツ語にすると「ゲシュタルト」)のはたらきに関する研究を深めていく。これがゲシュタルト心理学である。

続きは明日。

参考文献:梅本堯夫・大山正(1994)『心理学史への招待 現代心理学の背景』(新心理学ライブラリ15)サイエンス社

学会3日目

※この記事は『アサヒ スーパードライ』を飲んで書かれた。

今日はポスター発表日だった。多くの人が来てくれてアドバイスを受けてありがたかったし、それ以上に「面白い」とストレートに褒めてくれる人が多くて、嬉しかった。

マストドンを立てた記事を書いた。

学会も終わったことだし深夜に不健康なラーメンを食いに行こうかと思ったが、アニメの時間だったので諦めてお菓子を買って帰った。しかしお菓子を食べながらアニメは1時間後だと気づいて悲しかった。開放感と空腹感の中で深夜にラーメンを食うという条件を揃えるのは難しい。

Mastodonを立てる(Docker + nginx-proxy + letsencrypt-nginx-proxy-companion)2018年8月版

1.nginx-proxy + letsencrypt-nginx-proxy-companion

すでに同じサーバー上で他のアプリを動かしていたので、nginx-proxyを使った。ついでにletsencrypt-nginx-proxy-companionも使い、https化も自動化した。まずこの2つでdocker-compose.ymlを書いておく。

nginx-proxyはデフォルトであるサイズ(1MB?)以上のファイルのアップロードを受け付けない。これを超えるサイズの動画の投稿などを可能にしたいので自前のカスタム設定用のファイルを作り、マウントしている。

dockerネットワークを作る

dockerのコンテナ間の通信はdocker networkで行う。

  • common_linkはmastodonを動かすnginxサーバーとnginx-proxyの通信を行う
  • back-mastodonはmastodonを構成する各コンテナ間での通信を行う
$ docker network create --driver bridge common_link
$ docker network create --driver bridge back-mastodon

なおdocker networkの管理に有用なコマンドを書いておく

# ネットワークの一覧を表示する
$ docker network ls
# ネットワークの詳細を表示する
$ docker network inspect <network名>
# 使用されていないネットワークを削除する
$ docker network prune

動作確認(必要なら)

mastodon以外にすでにdockerで動かしているアプリがある場合、ネットワークの設定を修正する。私はwordpressを動かしていたのでその例を示す。変更点は2つ。

  1. nginx-proxyと通信するコンテナには環境変数としてVIRTUAL_HOST, LETSENCRYPT_HOST, LETSENCRYPT_EMAILを与える。
    • VIRTUAL_HOSTにはサブドメイン名(ここでは違うが)を設定する。のちのちmastodonにはanimedon.chao.tokyoというサブドメイン名を設定するので、chao.tokyoとanimedon.chao.tokyoのどちらにアクセスされたかによって違うコンテナを呼び出せるようになる。なおサブドメイン名はお名前ドットコムで設定した。
    • LETSENCRYPT_HOSTとLETSENCRYPT_EMAILはletsencrypt-nginx-proxy-companionのための環境変数。前者にはVIRTUAL_HOSTと同じ値を、後者にはletsencryptの通知メールを受け取るメールアドレスを設定する。
  2. 先ほど設定したネットワークを使用する
    • トップレベルにnetworksを作り、先ほど作ったcommon_linkというネットワークを利用することを明示する
    • 各コンテナでcommon_linkを利用することを明示する
version: "2"
services:
  wordpress:
    image: wordpress:latest
    container_name: "wp-main"
    volumes:
      - .:/var/www/html
      - ./log:/tmp/log
    depends_on:
      - db
    environment:
      WORDPRESS_DB_HOST: "db:3306"
      VIRTUAL_HOST: chao.tokyo
      LETSENCRYPT_HOST: chao.tokyo
      LETSENCRYPT_EMAIL: 見せられないよ
    env_file: .env
    networks:
      - common_link

  db:
    image: mysql:5.7
    container_name: "wp-db"
    volumes:
      - "./db-data:/var/lib/mysql"
    env_file: .env
    networks:
      - common_link
networks:
  common_link:
    external: true

nginx-proxyのdocker-composeとアプリのdocker-composeを任意の順序で起動すると、アプリがアクセス可能になるはずだ。この段階でアプリ(例:chao.tokyo)にアクセスできない場合はどこかでエラーが出ているので頑張ってなんとかする。letsencrypt-nginx-proxy-companionは起動に時間がかかるし、初回起動時は特に長い。証明書の取得、あるいはその必要がないことの確認が済むと3600秒のスリープに入るというようなメッセージが出るので、それまではエラーが出ても焦らないで。

2.Mastodonの設定

ではMastodonをデプロイしていく。まず適当な作業ディレクトリにcloneする。

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

docker-compose.ymlの編集

公式のインストラクションによると

If you're not making any local code changes or customizations on your instance, you can use a prebuilt Docker image to avoid the time and resource consumption of a build

もしローカルでコードを変更しないのであれば、ビルド済みのDockerイメージを利用することで時間と資源を節約することができます。

とのことなので、そうすることにした。この場合docker-compose.ymlに若干の変更が必要になる。他にもいろいろな変更が必要になるがとりあえず載せる。

version: '2'
services:
  nginx:
    image: nginx:1.11.10-alpine
    container_name: mstdn-nginx
    expose:
      - "9090"
    restart: always
    tty: false
    env_file: .env.production
    links:
      - web
      - streaming
    volumes:
      - ./setting/nginx/conf.d:/etc/nginx/conf.d:ro
      - ./setting/nginx/conf:/etc/nginx/conf/:ro
    volumes_from:
      - container:nginx-proxy_nginx-proxy_1
    networks:
      - common_link
      - back-mastodon
  db:
    restart: always
    image: postgres:9.6-alpine
    networks:
      - back-mastodon
### Uncomment to enable DB persistance
    volumes:
      - ./postgres:/var/lib/postgresql/data

  redis:
    restart: always
    image: redis:4.0-alpine
    networks:
      - back-mastodon
### Uncomment to enable REDIS persistance
    volumes:
      - ./redis:/data

#  es:
#    restart: always
#    image: docker.elastic.co/elasticsearch/elasticsearch-oss:6.1.3
#    environment:
#      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
#    networks:
#      - back-mastodon
#### Uncomment to enable ES persistance
##    volumes:
##      - ./elasticsearch:/usr/share/elasticsearch/data

  web:
#    build: .
    image: tootsuite/mastodon:v2.4.3
    restart: always
    env_file: .env.production
    command: bash -c "rm -f /mastodon/tmp/pids/server.pid; bundle exec rails s -p 3000 -b '0.0.0.0'"
    networks:
      - back-mastodon
    ports:
      - "127.0.0.1:3000:3000"
    depends_on:
      - db
      - redis
#      - es
    volumes:
      - ./public/system:/mastodon/public/system
      - ./public/assets:/mastodon/public/assets
      - ./public/packs:/mastodon/public/packs

  streaming:
#    build: .
    image: tootsuite/mastodon:v2.4.3
    restart: always
    env_file: .env.production
    command: yarn start
    networks:
      - back-mastodon
    ports:
      - "127.0.0.1:4000:4000"
    depends_on:
      - db
      - redis

  sidekiq:
#    build: .
    image: tootsuite/mastodon:v2.4.3
    restart: always
    env_file: .env.production
    command: bundle exec sidekiq -q default -q mailers -q pull -q push
    depends_on:
      - db
      - redis
    networks:
      - back-mastodon
    volumes:
      - ./public/system:/mastodon/public/system
      - ./public/packs:/mastodon/public/packs
## Uncomment to enable federation with tor instances along with adding the following ENV variables
## http_proxy=http://privoxy:8118
## ALLOW_ACCESS_TO_HIDDEN_SERVICE=true
#  tor:
#    build: https://github.com/usbsnowcrash/docker-tor.git
#    networks:
#      - external_network
#      - back-mastodon
#
#  privoxy:
#    build: https://github.com/usbsnowcrash/docker-privoxy.git
#    command: /opt/sbin/privoxy --no-daemon --user privoxy.privoxy /opt/config
#    volumes:
#      - ./priv-config:/opt/config
#    networks:
#      - external_network
#      - back-mastodon

networks:
  common_link:
    external: true
  back-mastodon:
    external: true

変更点を1つずつ説明する。

nginxコンテナの追加

mastodon専用のサーバーのコンテナ。nginx-proxyと各コンテナを中継する。volumesでコンテナの外から設定ファイルを編集できるようにしている。volumes_fromに関する解説はここを参照のこと。networksでcommon_linkと先ほど使用したmastodonの内部用ネットワークの両方に接続する。

なおvolumes_fromはdocker-compose version 3では使えない。解決策を調べたがよくわからなかったのでversionを2にした。

dbコンテナ, redisコンテナ

データベースの永続化のためにvolumesをコメントアウトした。先ほど使用したmastodon内部用ネットワークを利用するためにネットワーク名を変えた。

webコンテナ

ローカルで変更を加えないことにしたのでbuildをコメントアウト。imageでバージョンを指定。サーバー外部との通信はnginxコンテナが一括して担うのでnetworksはback-mastodonのみでよい。

volumesコンテナにアセットが保存されるディレクトリを追加。ここはエラーメッセージを頼りに手探りでやったことなのでよく理解できていないのだが、ビルドをしない場合はこうしないと動かないっぽい(参考)?。

streamingコンテナ

buildをコメントアウト。networksをback-mastodonに。

sidekiqコンテナ

これも手探りでやったのでよくわからないが、volumesに/public/packsを追加した。もしかしたら要らないかも。

networks

先ほど作ったcommon_linkとback-mastodonを利用することを明示する。

mastodon用nginxの設定ファイルの編集

mastodon/settings/nginx/conf.d/default.confを編集する。参考をコピペしてドメイン名等を埋めていけばいいが、add_header Content-Security-Policyの行はそのままだと画像アップロードができないので、意味がわかる人なら画像アップロードを許可するようにここを編集する。僕はわからなかったので丸ごと消した。

.env.productionの編集

まずcp .env.production.sample .env.productionし、このファイルを編集していく。

# 冒頭に追加
VIRTUAL_HOST=animedon.chao.tokyo
VIRTUAL_PORT=9090
VIRTUAL_PROTO=https
LETSENCRYPT_HOST=animedon.chao.tokyo
LETSENCRYPT_EMAIL=見せられないよ
LETSENCRYPT_TEST=false

# 探して編集
LOCAL_DOMAIN=animedon.chao.tokyo

# それぞれdocker-compose run --rm web rake secretを実行し出力された文字列を入れる
SECRET_KEY_BASE=
OTP_SECRET=

# 探して編集
SMTP_SERVER=smtp.gmail.com
SMTP_PORT=587
SMTP_LOGIN=見せられないよ
SMTP_PASSWORD=見せられないよ
SMTP_FROM_ADDRESS=見せられないよ
SMTP_DOMAIN=gmail.com
SMTP_OPENSSL_VERIFY_MODE=none

冒頭はnginx-proxyとmastodon用nginxが通信するための環境変数。

メールはgmailを利用するのでこうなった。なおgmail側で事前に設定してmastodon用のアプリパスワードを発行するのが望ましい。

起動

docker-compose build
chown -R 991:991 public
docker-compose run --rm web bundle exec rake mastodon:setup

chownは以外なタイミングでトラブった記憶があるので(忘れた)、それっぽいエラーが出たら思い出したかのようにもう一度実行しよう。

最後のコマンドで対話型のセットアップが始まる。内容はここにある。

  1. ドメイン名→animedon.chao.tokyo
  2. シングルユーザー?→No
  3. Docker?→Yes
  4. DB設定→Enter連打
  5. Redis設定→Enter連打
  6. クラウドストレージ→No
  7. メール設定→NoとEnter連打。さっき設定したのでたぶん上書きはされてない。
  8. DBマイグレーション→永続化してあるので既にやってあるならスキップしないとエラーになる
  9. アセットのプリコンパイル→同上。ただしこれはやり直してもよい。とても時間がかかる。
  10. 管理者アカウント作成→しましょう
docker-compose up -d

起動します。

終わりに

参考にしたサイトはどれも素晴らしかったが、mastodonの進化が非常に早いのでそのままでは動かないところがいくつもあった。基本的な構築の流れは参考サイトを見てもらったほうがよくて、私のこの記事はどこにどういうエラーが起こりうるのか、それをどう考えて対処したのかというような記録として残しておきたいと思う。

参考

学会2日目

ポスターセッションでは面白い研究が多く、やっている人たちも楽しんでいるのが伝わってきた。研究は楽しい!研究は楽しい!楽しい!楽しい!

Mastodonは立った→animedon.chao.tokyo

僕もあなたも逮捕されない範囲内で好きに使ってください。

立てたけどそんなに使わなそう。2018年8月20日現在のMastodonの立て方にはとても詳しくなったので、この情報の価値が高いうちにまとめておきたい。立ったあともCSPとか画像・動画のサイズ上限とかメールとか適切に設定しないと上手く動かないのでなかなか難しいぞ。立てる順番が違うと壊れるというDockerにあるまじき事件まで起きたからな。

次はフロントエンドの改造に着手したい。自動ハッシュタグ挿入機能と公開範囲設定保持機能。