Ubuntu15.10でterminologyを使う
ふと、mikutterをBot的に使うために必要最低限のパッケージで構成したコンテナを作りたいなと思いました。
ベースは Ubuntu Server15.10(大好き)。
vnc経由で軽量なウインドウマネージャと適当なターミナルを使えるようにして、後はmikutterのインストールかなと。
ウインドウマネージャはFluxbox。ターミナルはUbuntu15.04からパッケージ化された未来的オシャレ端末terminologyにしました。
そこでちょびっとハマった時のメモです。
terminologyがFluxboxのメニューに出てこない!
次のコマンドでFluxboxとterminologyをインストールしました。
apt-get install fluxbox terminology
しかし、Fluxboxのメニューにterminologyが追加されませんでした。
試しに別のターミナルxterm、gnome-terminalを入れるとメニュー登録される。
逆にデスクトップ環境XFCE4を導入するとterminologyがメニューにちゃんといる。
謎。
UbuntuにおけるGUIメニューシステム
調べてみると、Ubuntuにはアプリケーションをデスクトップ環境のメニューに追加する仕組みが大きく2系統あることがわかりました。
freedesktop.org
デスクトップ環境を設計する上で、守ったほうがいいお約束をfreedesktop.orgと言う団体がまとめています。
このお約束に沿っていれば、例えばGTK製アプリとQtアプリで連携が取れるようになったり、各種設定ファイルがGnomeとKDEで共有出来たりします。
ランチャーのメニュー項目についてもfreedesktop.orgに規定があり、アプリケーションはメニュー項目を定義した*.desktopファイルを用意することで、freedesktop準拠のデスクトップ環境のメニューにアプリケーションを登録できます。
先ほどのXFCE4も freedesktop.org準拠のデスクトップ環境です。
Debian Menu System
とは言え、昔ながらのデスクトップ環境(とかランチャー付きのウインドウマネージャ)はfreedesktop.orgに準拠していないものも多いです。
これらのデスクトップ環境では、ユーザ自身がメニュー定義を編集してアプリケーションを登録する必要があります。
それはさすがに面倒だよねということで、Debian系のディストリビューションにはDebian Menu Systemと言う仕組みがあります。
これはfreedesktop.orgのdesktopファイルと同等に、アプリケーション提供側がメニューファイルを用意します。
そしてupdate-menuコマンドでメニューファイルを元に各種デスクトップ環境用のメニュー定義が生成できるというものです。
古き良きBlackbokの流れを組むFluxboxはこっちのグループです。
つまり
今回のterminologyのパッケージにはfreedesktop.orgのterminology.desktopは収録されていたけれど、Debian Menu Systemのメニューファイルが入っていなかったのが原因です。
対策
Debian Menu Systemのメニューファイルを書きました。
/usr/share/menu/terminology
?package(terminology): \ needs="X11" \ section="Applications/Terminal Emulators" \ title="Terminology" \ command="/usr/bin/terminology" \
めっちゃかっこいい
無事、Fluxboxでterminologyが起動できました。
カーソルが怪しい青白の光を放っていたり、ベルの代わりに赤色灯が回ったりします。
Fluxboxのテーマともあつらえたように合ってますね。かっこいい。
Yet Another 実行中のmikutterにコードを流し込むやつを作ったよ
何これ?
明けましておめでとうございます。
これは「あー正月ってテレビもつまんないしマジすることないよねー」カレンダー (なにそれ?)1日目の記事です。(1年ぶり2記事目)
今回は「起動中のmikutterに外部から任意のコードを流し込むプラグイン&コマンド」を作ったのでその紹介をば。
これ、コンセプトは@toshi_aさんのmikutter-modeと同じで、プラグインを改造するたびにmikutterをいちいち再起動したくないよねと言うところです。
じゃあなんで再発明してんだよ溜まってるIssue処理しろよ最近お前の腹の出方ヤバイだろ痩せろよ?のかと言うと、
インストール
GitHubからzipファイルをダウンロードして、プラグインディレクトリにmikutter-code-injectorと言うディレクトリ名で展開して下さい。
moguno/mikutter-code-injector · GitHub
※mikutterプラグインマネージャ"Packaged"で"moguno"を検索してインストールするのもおすすめです。
使い方
普通にmikutterを起動する。
ごく普通にmikutterを起動してください。
見た目には変化はありませんが、netstat -aするとこんな行が増えてたりします。
tcp6 0 0 localhost.39311 *.* LISTEN
コードを送り込む
~/.mikutter/plugin/mikutter-code-injector/にmktrと言うコマンドがあります。
そのmktrの標準入力にRubyコードを流し込んでみてください。
起動中のmikutterでコードが実行されます。
実行できるコードに制限はなく、mikutterのフル機能を操作できます。
仕組み的にはmikutterのトップレベルbindingをdrubyで公開しておいて、mktr側でそれを取得。
んで、取得したbindingのevalを呼ぶとmikutter側でコードが実行されると言う寸法です。
それでは試しに、コマンドラインからつぶやいてみましょう。
echo 'Service.primary.post(:message => "みくっ")' | ./mktr
ちゃんとつぶやけましたね。
速攻で複数人からふぁぼられてるのは弊TLの仕様です。
IPアドレス固定なしで家庭内サーバをインターネットに公開できるデーモンを作ったよ
何これ
自宅サーバを公開したい! →ルータのポートマッピングを設定しないといけない! →サーバのIPアドレスを固定しないといけない! →IPアドレスの管理めんどい!DHCPのまま公開したい!
と言う、おおよそサーバ管理者に向かないものぐさ思考をUPnPを使って解決することにしました。
UPnPとは、ネットワーク内でのサービス提供者の発見、サービス内容の公開、リモートプロシージャコールを行う仕組みです。10年以上前からあるふっるい技術ですね。
当時はWebサービスのマッシュアップ技術の本命だったのですが、結局、サービス探索なんてあんま使わないじゃん。RPCはシンプルなRESTでいいじゃん。となって流行る前に忘れられた感があります。
そんなわけで、UPnPを使ってて広く実用化されているのはルータのポート開放とDLNA位と言うのが現状です。
UPnPでのポート開放は通常はメッセンジャーなどのアプリケーションが自分用のポートを開けるために使用しますが、今回、これを使って任意のポートを制御するデーモンを作ってみました。
こだわったところ
mDNSとの親和性
mDNS(avahi、bonjour)を使えば、ローカルなDNSサーバがなくとも「ホスト名.local」と言う名前で端末にアクセスできるようになります。これを使えばDHCPでころころIPアドレスが変わる端末にも、ホスト名でアクセスできるということです。素晴らしい。
今回作ったデーモンはこの素晴らしいmDNSとの連携を意識した設計になっています。
デーモンは定期的にホスト名を正引きして、IPアドレスが変わっていた場合はルータにポートマッピングの再登録を行います。
この動きにより、ポート転送先サーバとして「ホスト名.local」を指定していれば、たとえサーバのリブートでDHCPから払い出されるIPアドレスが変わったとしても、ポート転送を追従させることができます。
これによって当初の「DHCP環境でもサーバ公開したい!」が達成できるというわけです。
集中管理にも分散管理にも使えます
このデーモンはデーモンが動作しているサーバへのポート転送の他に、別のサーバへのポート転送も設定することができます。
なので、管理サーバ立ててネットワーク内のすべてサーバのポートマッピングを集中管理することもできますし、それぞれのサーバでデーモンを動かして各サーバに自分が使うポートの管理を任せることもできます。
ダウンロード
インストール
Ruby開発キットをインストールする
apt-get install ruby ruby-dev build-essential
mupnp gemをインストールする
gem install mupnp
設定ファイルを編集して/etc/にコピーする
cp -p pnp_portmapd.conf.sample /etc/pnp_portmapd.conf
デーモンを起動する。
./pnp_portmapd
設定ファイル
YAML記法になってます。
JSONと違ってコメントが書き放題なのが良いですね。
# 設定 Settings: # ポートマッピング更新周期(秒) Period: 5 # ポートマッピング定義 PortMapping: # 転送先ホスト名 akari.local: - ExtPort: 82 # 外部ポート IntPort: 81 # 転送先ポート Protocol: TCP # プロトコル(TCP/UDP) - ExtPort: 100 IntPort: 101 Protocol: UDP alicia.local: - ExtPort: 101 IntPort: 102 Protocol: UDP
この設定を適用すると、うちのルータではこんな感じになります。
akari.localが192.168.11.17、alicia.localが192.168.11.11です。
両者ともIPアドレスはDHCPから払い出されたものであり、IPアドレス固定なしでサーバが公開できています。
ログファイル
/var/log/pnp_portmapd.logです。
ルータに設定を行うたびにINFOメッセージを出しているので、眺めてると楽しいです。
ライセンス
License: 3 clauses BSDとやらにします。