もぐてっく

人は1つ歳を取る度、1ビットづつ大きくなれると信じてた。

Ubuntu18.04でdnsmasqの起動に失敗する。

環境

  • Proxox Virtual Environment 5.2-2
  • ubuntu-18.04-standard_18.04-1_amd64.tar.gzで作ったコンテナ

apt-get install dnsmasqしたところ、DNSのポート(53/UDP)が既に使われているってことでdnsmasqの起動に失敗しました。

何者だ?と調べてみると、systemd-resolvedって子らしい。

systemd-resolvedは新しい名前解決の仕組みで、DNS、LLMNR、mDNSなんかを統一的に扱えるものの様です。

しかしながら、従来の/etc/resolv.confを直接参照してDNSに問い合わせに行くプログラム(そんな奴いるの?)のために、localhost(127.0.0.53)にスタブDNSサーバを立てつつ、それをネームサーバに指定した/etc/resolve.confを自動的に生成してくれる機能があります。
今回はこの機能がおせっかいをしていると。

幸い、Proxmox VEのUbuntu18.04イメージはsystemd-resolvedのスタブDNSを使わない*1ので、さくっと止めてしまいましょう。

/etc/systemd/resolved.conf

[Resolve]
#DNS=
#FallbackDNS=
#Domains=
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
#Cache=yes
DNSStubListener=no  ←コメントを外して"no"にする。

systemctl restart systemd-resolvedでスタブDNSがいなくなります。

*1:コンテナの起動時にProxmoxのGUIで指定したDNSのアドレスを/etc/resolve.confに出力している。

CentOS7にMastodonをインストールしたときにハマったこと

すごく何となくMastdonインスタンスを立てたくなったので、週末を3つほど使って悪戦苦闘してました。

インストールはこちらのサイトを元に進めました。
要点が纏まっていて助かりました。

qiita.com

しかしながら、最後の「http://<ホスト名>:3000/」で動作確認するところがどうしてもうまく行きませんでした。

[root@localhost live]# curl http://localhost:3000
<html><body>You are being <a href="https://localhost/">redirected</a>.</body></html>

「http://<ホスト名>:3000/」にアクセスすると「https://<ホスト名>/」にリダイレクトされるのですが、webコンテナはHTTP用の3000ポートしか外部にNATしていないので、リダイレクト先のHTTPSポート(433)にアクセスできないという状況です。

よくよく調べてみると、HTTPプロトコルには要求時にUpgrade:と言うヘッダを付けるとHTTP用のポートを使ってHTTPSで通信できる機能があるらしく、Mastodonはそれを採用しているようです。

動作確認に使ってたChromecurlは要求時にこのUpgrade:ヘッダを付けないので上手く行かなかったと言う話でした。

RFC 2817 - Upgrading to TLS Within HTTP/1.1

結論として、Webサーバのnginxはリバースプロキシとして動作するときにUpgrade:ヘッダを付けられるようなので、Mastodon公式サイトの設定例を元にnginxを立ち上げてみました。

documentation/Production-guide.md at master · tootsuite/documentation · GitHub

結果、無事サインアップの画面が表示されました。
ミッションコンプリ。

Mastodonをインストールするだけでも各種最先端技術に振り回されて満身創痍になってしまったので、運用はもうちょっと経験値が貯まってからにしようと思います。

CentOS7.4でdocker-compose runがUpdating Permissions...から進まなくなった

下記の組み合わせで、タイトルの現象が発生しました。

  • CentOS Linux release 7.4.1708 (Core)
  • Docker version 18.02.0-ce, build fc4de44
  • docker-compose version 1.19.0, build 9e633ef
[root@localhost live]# docker-compose --rm run web rake secret
Creating network "live_internal_network" with the default driver
Creating network "live_external_network" with the default driver
Starting live_db_1 ... done
Starting live_redis_1 ... done
Creating mastodon user (UID : 991 and GID : 991)...
Updating permissions...
(コンテナ内のファイルのfindとchownに明け暮れて全く帰ってこない。)

どうもDockerのストレージドライバoverlay2が原因の様です。
別のストレージドライバに切り替えればいい模様。

aufsが一般的らしいですが、今更だなぁと思ってbtrfsにしてみました。

CentOSを再インストール。インストール先の設定で/と/homeをbtrfsにするだけでOKでした。自動でストレージドライバをbtrfsにしてくれました。

mikutter 3.6のSpellのメモ

スペル(Spell)って?

まだよくわからぬ。
mikutter内の「動作」を柔軟に抽象化する仕組みだと思います。

仕様

スペルはdefspellと言うDSLとして定義されています。

$(MIKUTTER_DIR)/core/plugin/spell/spell.rb

defdsl :defspell do |spell_name, *constraint, condition: nil, &block|

spell_name

スペル名をシンボルで指定します。
例えば「投稿」は:composeです。

constraint

そのスペルに関わるモデルのslugを適当に並べて指定します。

みたいな。

condition

そのスペルが今発動できるか否かを返すlambdaを渡します。
procにはconstraintに指定したモデルのインスタンスが渡されます。
発動可能ならtrue、ダメならfalseを返しましょう。

block

スペルを発動した時に行う処理です。

スペルの呼び出し方

任意のPluginのインスタンスにスペル名と同名のメソッド(「compose()」の様な)があるので、それを呼びます。

引数には関係するモデルのインスタンス、オプションたち(ハッシュ)を適当な順番で渡せばいいみたいです。引数にnilがあっても大丈夫っぽいです。

$(MIKUTTER_DIR)/core/mui/gtk_postbox.rb

@posting = Plugin[:gtk].compose(
current_world,                                     # :twitterモデルのインスタンス
to_display_only? ? nil : @to.first,         # 送り先があるならそのモデルのインスタンス
body: text,                                           # オプション
visibility: @visibility                             # オプション
).next{

発動可能なスペルが存在するかを事前にチェックするには、「スペル名?」と言うメソッド(「compose?()」の様な)があるので、それを呼びます。

Plugin[:gtk].compose?(current_world, to_display_only? ? nil : @to.first, visibility: @visibility)

スペルの呼び出され方

$(MIKUTTER_DIR)/core/plugin/twitter/twitter.rb

defspell(:compose, :twitter,・・・・) do |twitter, body:, to: nil, **options|

ブロックの引数の種類に意味合いがあるので注意が必要です。
($(MIKUTTER_DIR)/core/plugin/spell/struct.rb"でやってます。)

  • twitter:普通の引数(req)
  • body:キーワード引数(keyreq)
  • to:デフォルト値ありのキーワード引数(key)
  • options:残りのキーワード引数(keyrest)

普通の引数(req)、デフォルト値ありの普通の引数(opt)

constraintに指定したモデルのインスタンス
(多かったり少なかったりすると例外が発生します*1

デフォルト値ありのキーワード引数(key)

スペルのオプションに同名のキーがある場合、それが代入されます。

キーワード引数(keyreq)

スペルのオプションに同名のキーがある場合、それが代入されます。同名のキーが無い場合は例外が発生します(*1)

残りのキーワード引数(keyrest)

オプションの内容が全部渡されます。

メモ

発動するスキルは次の条件で発見されます。

  • 呼び出し側が引数に指定したモデルと、スペル側のconstraintが完全に一致していること。⇒スペルのconditionが実行される。
  • conditionの結果がtrueであること。

*1:Plugin::Spell::ArgumentErrorが発生してるはずなんですがmikutterが落ちるわけでも--debugでもログが出るわけでもなく。謎です。

Windows Subsystem for LinuxのUbuntuでuim-mozcを使う

Windows Subsystem for Linux(WSL)が正式版になって、晴れてWindowsでmikutterが普通に使えるようになりました。

moguno.hatenablog.jp

しかしながら、WSLではfctixやibusと言った最近のインプットメソッドが動作しません。
なので、ちょいと古めのuimAnthyの組み合わせで使っていたのですが、このAnthyの変換精度がどうも微妙。

できればmozcの様な今どきの変換エンジンを使いたいなと。

実は、Ubuntu(と言うかDebian)にはmozcをuimで使うためのパッケージuim-mozcが存在します。

でも、uim-mozcは14.10(Utopic)でいったん廃止され(バグでも見つかった?)17.04(Zesty)で復活してる感じなので、WSLのUbuntuである16.04(Xenial)にはそれが存在していないというのが現実です。

この日曜日にいろいろ試して、Zestyからuim-mozcを借りてくることに成功したので、手順を書いておこうと思います。

準備

では、bashを起動してください。
sudoの連続は面倒なのでsudo -sでrootなシェルを起動しておきます。

sudo -s

aptの設定ファイルの調整

お好きなviで2つのファイルを新規作成しましょう。

/etc/apt/sources.list.d/zesty.list

zestyのリポジトリを検索対象に加えます。

deb http://ja.archive.ubuntu.com/ubuntu zesty main universe

/etc/apt/preferences.d/zesty

名指しで指定した場合のみzestyのパッケージを採用する様に優先度を調整します。

Package: *
Pin: release n=xenial
Pin-Priority: 990

Package: *
Pin: release n=zesty
Pin-Priority: 90

いつものアレ

apt-getでパッケージのデータベースを更新しておきます。

apt-get update

uim-mozcのインストール

それでは、いよいよuim-mozcのインストールです。
zesty名指しがポイントです。

apt-get install -t zesty uim-mozc

後は、uimをIMに使うように指定したアプリケーション(mikutterとか)を起動すれば、変換エンジンがmozcに変わっています。
日本語入力をONした後、ps -aux | grep mozcしてmozc_serverが常駐してたらOKだと思います。

moguno   28926  0.0  0.2 810056 16952 ?        Sl   22:55   0:00 /usr/lib/mozc/mozc_server

WSLを使ってWindowsでmikutterを動かす。

愛機MacBook Air(Mid 2012)の調子が悪くなったので、メインマシンを買い置きしていたThinkpad X1 Carbon(2016)に変更しました。*1

画面が広い!重量も軽い!Windows10も結構使いやすくなってきてる!と概ね満足だったのですが、唯一の懸念事項がmikutter。
mikutterはバージョンアップを重ねるごとにWindowsで動かすのが難しくなってきてるんで、これからWindowsで暮らしていく上で、伴侶であるみくったーちゃんと添い遂げることは出来るのかしらと。

そういえば、最近流行りのWSLでmikutterの動作報告があったなぁ。試してみるかと設定してみました。

結論としてはすごくいい感じ。macOSX11版)と同等の使い勝手が得られました。

f:id:moguno:20171008151829p:plain:w400

WSLのインストール

ここはいろんなサイトで手順が公開されているので端折ります。

(1)コルタナたんに「更新」と伝え「更新プログラムのチェック」を起動する。
「開発者向け」にある「開発者モード」を有効にする

(2)コルタナたんに「コントロール」と伝え「コントロールパネル」を起動する。
「プログラムと機能」の「Windowsの機能の有効化または無効化」から
Windows Subsystem for Linux(Beta)」をインストールする。

(3)コルタナたんに「bash」と伝え「Bash on Windows on Windows」を起動する。
Ubuntuのインストールが始まる。)

コルタナたんは仕事のできる子。

(4)bashが起動したら、環境を最新化しておく。

sudo apt-get update
sudo apt-get dist-upgrade

mikutterのインストール

今回は手抜きでUbuntuリポジトリにいるmikutterを使います。腕に覚えがある人はgitで最新版を取ってきてインストールしてください。なんだかんだでUbuntuなので、ハマり要素はかなり少ないと思います。

sudo apt-get install mikutter

日本語フォントのインストール

こちらを参考にしてGoogle謹製のnotoフォントをインストールします。

ぽぬぽぬ: Bash on Ubuntu on Windows + XサーバでLXDEを起動

ついでに絵文字(ttf-ancient-fonts)も入れておきましょう。

sudo apt-get install noto-fonts-hinted noto-fonts-cjk ttf-ancient-fonts

日本語入力システムのインストール

ここではちょっと懐かしいuimanthyをインストールします。*2

あれやこれやZakki: bash on ubuntu on windows(WSL)でGUIを立ち上げて日本語入力までやる

sudo apt-get install uim uim-xim uim-anthy

ブラウザ起動シェルスクリプトの作成

mikutterには、アカウントの認証時やURLをクリックしたときに起動するWebブラウザが必要です。
WSL側にfirefoxとかをインストールしてもいいのですが、せっかくのWindowsなのでEdgeとかIEを使いたいなと。

WSLでは、Windows用のプログラムを拡張子.exeまで含めて指定すると、そのプログラムが起動できるので、それでサクッと解決・・・と思ったのですが、EdgeもIEも実は.exeファイルは存在せずシェルエクステンションみたいな概念に昇華されてしまっているので、この方法はとれません。

なので、コマンドプロンプト(cmd.exe)を経由して、Windowsの既定のブラウザを起動するようにします。

/opt/mikutter-wsl/bin/start

#!/bin/sh
ESCAPED_URI=`echo "$1" | sed s/\&/^\&/g`
cmd.exe /C start "$ESCAPED_URI"

実行権限を付けておきましょう。

chmod 755 /opt/mikutter-wsl/bin/start

Xサーバのインストール

Windows用のXサーバはけっこう豊富に存在しますが、ここではVcXsrvを選択しました。理由はたまたま目についたからです。
この子どうやら高速なことで有名みたいです。実際サクサク動きます。

https://sourceforge.net/projects/vcxsrv/

VcXsrvの起動スクリプトの作成

VcXsrvには起動時に任意のコマンドを実行する機能があるので、mikutterをダイレクトに起動するようにします。
下記のXMLファイルを作成します。LocalProgramがキモの部分です。

mikutter.xlaunch

<?xml version="1.0" encoding="UTF-8"?>
<XLaunch WindowMode="MultiWindow"
ClientMode="StartProgram"
LocalClient="True"
Display="0"

LocalProgram="bash -c &quot;DISPLAY=:0 GTK_IM_MODULE=uim mikutter&quot; &gt; /dev/null 2&gt;&amp;1"

RemoteProgram="xterm"
RemotePassword=""
PrivateKey=""
RemoteHost=""
RemoteUser=""
XDMCPHost=""
XDMCPBroadcast="False"
XDMCPIndirect="False"
Clipboard="True"
ClipboardPrimary="True"
ExtraParams=""
Wgl="True"
DisableAC="False"
XDMCPTerminate="False"/>

実体参照が入ってて分かりにくいですが、デコードするとこんな感じになります。

bash -c "DISPLAY=:0 GTK_IM_MODULE_uim mikutter" > /dev/null 2>&1

標準出力、標準エラー出力を/dev/nullに捨てるのがポイントです。
そうしないとmikutterがコンソールにwarningとか出力するたびに、VcXsrvが「大丈夫?コマンド打つ?」ってダイアログを出してくるので。

起動してみる

さっき作ったmikutter.xlaunchをダブルクリックしてください。いつものmikutterが起動してくると思います。

f:id:moguno:20171008151850p:plain:w400

mikutterが起動したらさっき作ったブラウザを起動するシェルスクリプトを設定します。

(1)ウインドウ右下のネギレンチボタンを押す。
(2)「表示」の「URLを開く方法」に「/opt/mikutter-wsl/bin/start」と入力して下さい。

f:id:moguno:20171008151914p:plain:w400

これで完成です。Windowsでもレッツておくれ!

なお、日本語入力の切り替えはShift + スペースで行います。慣れましょう。

*1:使用頻度の低い公務用PCをスライドさせた感じっす。

*2:トレンディな日本語入力システムである(ibus|fcitx) + mozcは動きませんでした。Macでも定番のX用日本語入力システムはuimだったと思うので、そんなものなのでしょう。

ルータのボタンをワンプッシュ!Raspberry Pi Zero WのWifi接続を簡単に切り替える方法

第1回 全日本ラズパイゼロW争奪戦に運良く勝利して、Raspberry Pi Zero Wを手に入れました。

普段はPimoroniのScroll pHat HDを装着して、無線ルータ経由で為替とか明日の天気とかを取ってきてだらだら流しています。
結構実用的です。

f:id:moguno:20170830221018p:plain:w350

これをテザリングしたスマホに接続して飲み会でデモ(ドヤぁ!ええやろぉ!)をしたかったのですが、いちいちRaspberry Pi Zero Wにコンソールを繋いでWifi設定を変更するのが面倒でした。

なので、WPSを使ってWifi接続を簡単に切り替えられる仕組みを作ることにしました。

WPSって?

Wi-Fi Protected Setup - Wikipedia

ざっくり、ルータと端末の「WPSボタン」を押すことで、両者を設定なしで接続してくれる仕組みです。

しかしながら、Raspberry Pi Zero Wにはボタンみたいな入力デバイスは付いていないので、Raspbianの起動時にWPSボタンを押したのと同等の状態になるようにしました。

後はお好きなルータのWPSボタンを押すことでRaspberry Pi Zero WとのWifi接続が確立すると言う寸法です。

設定

これはRaspbianのwithout Desktop版用の設定です。

NICの設定

まずWifiアダプタwlan0を設定します。

/etc/network/interfaces
・・・
allow-hotplug wlan0
iface wlan0 inet dhcp
    wpa-conf /opt/wps/etc/wpa_supplicant/for_wps_button.conf
/opt/wps/etc/wpa_supplicant/for_wps_button.conf
ctrl_interface=/run/wpa_supplicant

普段はやたら面倒なwpa_supplicantの設定ですが、今回はWPSが全てやってくれるので超シンプルですね。

Raspberry Pi Zero W起動時にWPSボタンを押した感じにするスクリプトを実行する

/etc/rc.local
・・・
/opt/wps/bin/wps_connect.sh &
・・・

スクリプトの中身はこんな感じです。
Raspberry Pi Zero WのLEDを操作して、WPS接続待ちであることが視覚的に分かるようにしました。

/opt/wps/bin/wps_connect.sh
#! /bin/sh

# LEDを100ms周期で点滅させる
echo timer > /sys/class/leds/led0/trigger
echo 100 > /sys/class/leds/led0/delay_off
echo 100 > /sys/class/leds/led0/delay_on

# WPSボタンを押す
/sbin/wpa_cli -i wlan0 wps_pbc

# 5秒周期でWifi接続が確立したかチェックする
while sleep 5;do
	STATUS=`/sbin/wpa_cli -i wlan0 status | grep wpa_state= | cut -d = -f 2`

	case $STATUS in
                # 接続失敗
		INACTIVE)
                        # もう一度WPSボタンを押す
			/sbin/wpa_cli -i wlan0 wps_pbc
			;;

                # 接続成功
		COMPLETED)
                        # LEDを点灯に戻して終了
                	echo "mmc0" > /sys/class/leds/led0/trigger
			exit 0
			;;
	esac
done

使い方

  • Raspberry Pi Zero WにUSB電源を接続してしばらく待つと、オンボードのLEDが短い周期で点滅し始めます。
  • すかさず、ルータのWPSボタン(各社呼び方がバラバラみたいです)を押したり、AndroidスマホWifiテザリング設定画面にある「WPSプッシュボタン」をタップしたりします。

f:id:moguno:20170830220945p:plain:w350
f:id:moguno:20170830220859p:plain:w350

  • 10〜20秒程度でWifi接続が確立し、オンボードLEDが点灯状態になります。