b-shock. Fortress

Mastodon 2.3にアップグレードした。全文検索できるようになった。

2.3.0がリリースされた。
今回の目玉は何か。LDAP対応?ノンノン、全文検索に決まってんだろw

2.3へのアップグレード以外にもいくつか作業したので、以下にご報告する次第。

2.3へのアップグレード

いつもどおりの手順である。DBのマイグレーションと、アセットの再構築を含む。
特に補足することはない。

Node.js 9.xを適用

少し前から、管理対象サーバ上の古いNode 6.xを少しづつアップグレードしてたが、 Mastodonインスタンスだけが未対応だった。

FreeBSDでは、 pkg install node ってやるとなんと8.xを飛び越えて、 9.xがインストールされる。 9.xでもストリーミングAPIは正常に動作する模様。

以下、FreeBSDでNode 6.xから9.xへのアップグレードを行った手順。

1
2
3
4
5
su
pkg delete node6 npm3
pkg install node npm
cd ~mastodon
yarn upgrade

faviconを変更

Mastodonのfaviconは、かなり面倒な手順を踏まなければ変更できない様だ。
最近某所で仲良くさせて頂いているワイヤード・パンチ氏に教えてもらったまとめがこちら。

マストドンのインスタンスのfaviconを変更する方法。

めんどくさすぎだろw
faviconを作るところまではいいとして、その先はもっと簡単に済ませた。

即ち、nginxが直接返すようにすれば良いのである。
nginx.confにもともと以下の記述があったので、今回特に対応不要だった。

1
2
3
location ~ \.(html|png|gif|xml|ico|json|svg|txt|ogg|mp3)$ {
root /usr/local/www/mastodon/public;
}

全文検索の導入

公式にある、この手順の通りであるが。

Elasticsearch Guide

aptコマンドを操作する手順、多分Ubuntuのものだろう。Debianでも動くのかは知らない。
FreeBSDでは当然、全く手順が異なる。

1
2
3
su
cd /usr/ports/textproc/elasticsearch6
make install clean

上記手順で、依存パッケージであるopenjdk8も一緒にインストールされる。

引き続き、以下実行。
必要なら /usr/local/etc/elasticsearch/elasticsearch.yml を編集するが、 通常は不要と思う。

1
2
sysrc elasticsearch_enable="YES"
service elasticsearch start

起動したら、一応、 curl http://localhost:9200 で動作確認を。

Elasticsearchの正常動作を確認したら、Mastodonを全文検索に対応させる。
.env.productionに、以下追記。

1
2
3
ES_ENABLED=true
ES_HOST=localhost
ES_PORT=9200

追記したら、以下実行。

1
2
cd ~mastodon
RAILS_ENV=production bundle exec rails chewy:deploy

このrakeタスクでインデックスの作成なんかも行う様だが、かなり時間がかかる。 5,000トゥートほどある弊インスタンスでは、16分ほど要した。

終了後、Mastodonの再起動。

全文検索の使い方

今まであった検索窓にワードを投入するだけ。
以前は間違いなくヒットしなかった、すごく古いトゥートもヒットするようになった。

この機能、クライアント側の対応が必要な模様。
Kurotodon では動かなかったが、他のクライアントの分をあとで試してみようかと。以上。

MacBook AirをXubuntuとのデュアルブートにした。

USキーボード原理主義

人生で最初に所有したパソコンはNEC PC-9801 RXだが、こいつを卒業したあとはずっと Macユーザーだった。
この頃のMac、キーボードはUS配列だった。それまでキューハチユーザーだったおれが 最初にUSキーボードに触ったときは戸惑ったものだが、のちのち慣れるとJIS配列より 合理的であると知り、以降20年は断然US配列派である。
生産性にも大きな影響があり、ここは一切譲れない。

ところで、日本でUS配列のPCを利用するならデスクトップ機、さもなければMacなのでは ないか?
おれはもう今後、デスクトップPCを購入することはないだろうから、選ぶPCは必然的にMacという ことになる。それがたとえ、WindowsやLinuxデスクトップという用途であっても。

余談だが、USキーボードのノートPC。軽く調べた感じ、国内メーカーは全滅に近い。
macOS用途でなければ、MacBook以外であっても当然選択肢にはなりうる。 もちろん良いものであればの話だけど。
Apple以外で、安定してUSキーボードのマシンを供給しているのはLenovoだが、このメーカーは セキュリティに大きな懸念があるので敬遠。 (Windowsにへんなスパイウェア入れてることが多いみたいなので、興味あるひとはググって)
USキーボードにこだわるなら結局Macに行き着くという持論だけど、良いメーカーを ご存じの方は是非教えていただきたい。

ヤフオクにてMacBook Air 11を落札

そんなわけで、つい先日落札した。

  • MacBook Air Mid 2012 11インチ
  • Core i7 2GHz
  • 8GBメモリ
  • SSD 256GB
  • USキーボード

どうです。割といけてるでしょ。こいつを、懲りもせずXubuntuマシンにするのである。
やったことは大体、このブログに書いたこと。自分の備忘録にもなり、やっててよかった 個人ブログ。
本稿では、あえてMacにXubuntuをインストールしたことにより、今回初めて行った対応 について述べる。

デュアルブート

まずはXubuntuでブートできなければ始まらないのであるが。
当初、macOSとのデュアルブートの必要はないと考えていたが、一部の設定はmacOSからしか できない可能性がある。
30GB程度で良いので、macOSのパーティションも切っておくのがリスクヘッジというもの。 そう思い直した。

用意するものがある。

  • Xubuntuのインストーラ入りUSBメモリ
  • macOSのインストーラ入りUSBメモリ

macOSのUSBメモリは必須ではないが、あると便利。
Command+Rを押しながらのリブートで代用できる機種が多いが、万一出来ないときの為に。

どちらも定番の作業で作成できるので、説明はしない。
以降はざっくり、以下の手順で行う。(このへんの一連の手順、いいページがたくさん あるはずだからググってw)
以下、注意点だけ。

GUIDでパーティションを切る

macOSのUSBメモリはここで使用。
macOSのパーティションは、最新のHigh Sierraであっても30GBもあれば十分。 残りはすべてXubuntuに。
ここでファイルシステムに何を選んでも、結局はあとでAPFSとext4になる。なんでもいい。

小さな方のパーティションにmacOSをインストール

手順割愛。

rEFIndをインストール

インストール前に、SIPを切っておく必要あり。
Command+Rを押しながらリブートし、ターミナルから csrutil disable を実行。 直後に、再度Command+Rリブート。

Command+Rでリブートしたあとは、APFSボリュームはマウントされていない。 ターミナルを実行する前にディスクユーティリティでmacOSのパーティションをマウント しておくのをお忘れなく。
しかる後に、rEFIndをインストール。

インストール後は再度Command+Rで起動し、 csrutil enable でSIPを元に戻すのを忘れずに。

大きな方のパーティションにXubuntuをインストール

特別な手順は不要なので割愛。いつものPCでの手順でOK。
GRUBをXubuntuのパーティションに入れることだけ忘れない様に。

ここまでの作業で全てのデバイスを認識し、素晴らしいのだが、いくつかやることがある。

Commandキーをctrlキーにする

マカーには、この手順が意味するところの説明は不要だろう。
macOSの大半のショートカットキーは、Commandキーとのコンビネーションである。

実際の手順は、↓ここを参考にすれば良い。

Ubuntu 16.04のキーボード設定をMacBook向けにしてみる

但し、要アレンジ。Xubuntuではdconfの設定を行っても無駄。
「セッションと起動」にて、

1
/usr/bin/setxkbmap -option "ctrl:nocaps" -option "altwin2:cmd_n_ctrl"

をログイン時に実行するようにする。

  • ctrl:nocaps は、capsキーをctrlに変える定番設定。
  • altwin2:cmd_n_ctrl は、上記ページに書かれている、Commandをctrlに変更する設定。

複数の設定をsetxkbmapに適用する際は、この様にoptionを重ねて指定する。

トラックパッド、2本指スクロールの向きを上下逆に

↓このページ参考に。但しこちらも、要アレンジ。

XPS13 Ubuntu 12.04 でナチュラルスクロールを有効にする

ウチでこのページの手順を実行した結果、

1
xinput set-prop 12 287 -200 -200

を実行すればよいとわかった。
後ろの-200、負の数値であればなんでもいいみたい。移動量を数値で指定するものと思っていたが、 何を指定しても動作は変わらないっぽい。
こいつも先程同様、「セッションと起動」にてログイン時に実行するように。

pm2をsyslog対応に。

作成の経緯

MirakurunがNode.js 6.xの サポートを打ち切り、8.xでの動作が推奨になった為、昨日、録画鯖のNode 環境を8.9.4にアップグレードした。

ChinachuもMirakurunも、 pm2でデーモン化する導入手順。
今までは、これらをsyslog対応にする為にpm2-syslog を使用していたが、

  • syslogd側でUDPを開く必要あり。
  • タイムスタンプがUTC。

と、あまり使いやすいものではなかった為に、この機会に自作したという経緯。
syslogならOSのローテーションツールが使えたり、RDBをストレージにできたり、 便利だよ。アプリのログは極力syslogに流す派。

設計

…という程大層なものじゃないがw
素直にloggerコマンドを叩く実装が使いやすいはずと感じた。

syslogのクライアント自身がUDPを開けて通信する必要はあるのか?
仮にリモートのsyslogサーバに集約する用途でも、そのルーティングは syslogdがするべきではないか?と思うのだけど、いかがか。

通常時とエラー時に実行すべきコマンドライン例を、以下に示す。

1
2
logger -p user.info -t mirakurun-server hogehogehoge  #通常時
logger -p user.error -t mirakurun-server hogehogehoge #エラー時

何故ファシリティがuserなんだ?手抜きかよ?
いやいや、プログラム名(-t)さえ設定してあれば、rsyslogとかなら フィルタリングできるんだし。 ファシリティなんて前時代的な仕組みは使わんでいいだろ。と思った。

インストール手順

1
sudo pm2 module:install pm2-syslog-logger

詳しくはGitHubページ を参照のこと。(そんな大層なもんじゃないけど)
え、READMEは英語で書けって?勘弁してくださいよ…

利用範囲

録画鯖にはもちろんだけど。
MastodonのストリーミングAPIにも、pm2化すれば使えるよ。
てゆうか使ってる。

expressで書いたツールって、pm2化出来るのか?
これも試してみたい。

未実装機能

loggerコマンドは通常パイプで起動し、 echo hoge|logger みたいに、標準入力から 流し込む様な使い方をするのが本来。
録画鯖程度のログ流量なら今のままで問題ないけど、流量が大きくなることを 想定し、近々この形に修正したい。

その他

GitHubページとか npmページとか 見てください。恥ずかしいけどw

GDで透過PNGを扱う。

久しぶりの記事だが、何事もなかったかのように進めていく。

経緯

PHPで画像を扱う為には、

  • GDを使ったもの
  • ImageMagickを使ったもの

の主に2種類があると思うけど、今日の話題はGDのほう。

透過色(アルファチャネル)を含んだPNG画像のリサイズ(縮小)を行うと、透過色が失われて しまう現象に悩まされていた。

今回、アプリ本体はPHPで書かれているが、他言語から利用することも想定し、画像リサイズAPI (picon)はNode.jsで実装されている。
当初、この問題はAPI側の不具合と考えていて、Node.jsやImageMagickのことばかり調べていた が、実際にはAPI側は無関係だった。

画像リサイズAPIのクライアント(PHP)は、APIにファイルをPOSTしている。
このPOSTすべきファイルが、既にアルファチャネルを保持していなかったというわけ。

GDで透過PNGを扱う。

PHPの imagesavealpha 関数を実行し、 アルファチャネルを有効にする必要がある。
また、 imagealphablending を実行して、アルファブレンディングを解除する。

ひと通り書くと、以下の様な感じ。

このスクリプトと同じ階層に、 sample.png がある想定で。

おまけ

この修正を行ったクラスは、実際には以下の場所にある。
オレオレフレームワークのクラスのうちひとつ。

Image.class.php
241行目

以上、ご参考まで。

password_hash.php

おれ、自分ではPHPerのつもりなんだが、実はPHPの記事を書くのは初めてという。 なんというグダグダw。

基本的な使い方

パスワードのハッシュにpassword_hash使ってますか?下手にmd5()だのsha1()だの使う ぐらいなら、断然これ使いましょう。
何も考えずに標準の関数使っとけば幸せ、一見安易に見えて実はベストプラクティスであるという、 実にPHPらしい関数。
以下、ハッシュの生成手順。

1
2
3
4
<?php
$cost = 10; //コスト
$password = 'YOUR_PASSWORD'; //平文パスワード
$hash = password_hash($password, PASSWORD_DEFAULT, ['cost' => $cost]);

認証はこんなかんじ。

1
2
3
4
5
6
7
<?php
$password = 'YOUR_PASSWORD'; //ユーザーが入力したパスワード
if (password_verify($password, $hash)) {
//認証成功時の手順
} else {
//認証失敗時の手順
}

ラクすぎる。各関数の詳細はこちら。

ハッシュ生成ツール

で、これが本題。
管理者パスワードなんかのハッシュ生成に使えるツールを書いたです。

こんなふうに使う。

1
2
3
4
5
6
7
8
% ./password_hash.php YOUR_PASSWORD
{
"source": "YOUR_PASSWORD",
"hash": "$2y$10$d1SJDVqus8OvKeRrdnv8wuQk2TjD1QIuzBjoTEraJFGJ4M9VHge2m",
"algo": "bcrypt",
"cost": 10,
"verify": "OK"
}

YOUR_PASSWORDが、ハッシュ生成の対象となるパスワード。
必要なのは、出力されたJSONの hash 要素だけ。この内容をアプリの設定ファイルに控えて おけばよい。
あ、出力されるのはJSONだから、一部の記号(スラッシュとか)がエスケープされるので要注意。

処理内容は、ソースを見ての通りw
コスト7から始めて、0.05秒以内にハッシュ生成が完了する間はコストを1ずつ繰り上げていく。 当然、コストが高いほど強度の高いハッシュとなる。
今までほぼ毎回コスト10で、他はほとんど見たことないんだけどね。

ではまた。

フィードエントリーをトゥートするツール。

このツールの初回コミット、記録をみる限りは10/27。
とっくに運用始めてたのに、2ヶ月弱経ってようやくの公開である。

タイトルの通り、RSS/Atomフィードの新着エントリーをMastodonにトゥートする ツール。同種のツールが見つけられなかったら、自作した。

Ruby 2.4(たぶん2.3でも可)が入ってるUNIX系OSを対象とする。
Windowsでも動く可能性が高いけど、正直知ったこっちゃないのでそのつもりで。 (Win環境への設置に関する質問には答える気ないです)

GitHub

tomato-toot

設置手順などは、リポジトリのページを参照。

なぜトマトなのか?
深い意味は全くないので、追求するのはやめて頂きたいw

「これを裏技と呼ぼう」

READMEに書いてない機能がひとつある。
ドキュメント書いてて力尽きたw 利用頻度も低いし、まぁ説明しなくてもいいだろと。 (おれ自身も結局使ってないし)
興味あるひとはソースでも読んでください。

免責

個人の管理者が多いMastodonでは、流量の多いBOTが迷惑行為となる可能性があることに 注意したい。
インスタンスによっては、規約でBOTを禁じている可能性もありうる。 明確にOKと謳っているのでなければ、管理者が個人である場合は特に、ひとこと断って ほしいと思う。

自己責任での利用をお願いしたい。
おれは、このツールを使った上でのトラブルに責任をとるつもりはないので。

Mastodon 2.1、及びカスタムテーマの更新

Mastodon 2.1.0が 今朝リリースされたので、早速導入した。新機能等に関してはリンク先を見て頂くとして。

Mastodon自体の更新の手順はいつも通りで問題ないので割愛。1点除いて、特にひっかかった点も なかった。
その1点とは、2.0の新機能だったカスタムテーマだ。2.0のカスタムテーマは2.1と互換性がない ケースがある。
カスタムテーマのエラーを放置すると、更新の手順の最後に行われる rake assets:precompile を終了させることができず、Mastodon自体の更新も完了しない。

エラーが出ている場合に、手っ取り早くMastodonの更新だけを行いたい場合

以下のいずれかの手順を行った後に、通常通り rake assets:precompile を実行。

カスタムテーマを無効にする

config/themes.ymlにカスタムテーマを登録しているはずと思うが、追記分をコメントアウトし、 defaultテーマ(設定画面上では、サイトテーマ「Mastodon」に該当)だけを残す。

variables.scssに$cjk-langsを追記

defaultテーマの配色だけを変更したテーマの場合、テーマのファイル構成は踏襲している だろうから、defaultテーマ同様にvariables.scssが存在するはずと思う。

variables.scssに$cjk-langsが存在しない場合は、 rake assets:precompile 時に以下の エラーが発生する為、

最終行にでも $cjk-langs: ja, ko, zh-CN, zh-HK, zh-TW; と追記する必要がある。 2.0のvariables.scssからコピーしている場合、この記述がないはず。

簡単なカスタムテーマを作成する手順

話のついでなので、おれがやってる手順のまとめ。

config/theme.yml に追記

defaultはもとからあるテーマ。その下にdefaultテーマをまねて追記。
以下、 bshock がテーマの名前であるとして。

ルートのscssファイルを作成

1
2
cd app/javascript/styles
cp applications.scss bshock.scss

Mastodon 2.1では、bshock.scssは以下の様な内容。

defaultテーマから、2行目だけを書き換えている。もともと2行目には mastodon/variables と書かれていたが、 bshock/variables と書き換えた。
配色以外の要素はデフォルトのままで良いなら、variables.scss以外のファイルはオリジナル のファイルをそのまま参照すれば良いと思う。(もっとも、本来この手順が適切とは思うのだけど、 今回2.1への更新では裏目に出てしまった)

variables.scssを修正

variables.scssをdefaultテーマからコピー。

1
2
mkdir bshock
vi bshock/variables.scss

bshock/variables.scssは、以下の様な内容。

上記は実際には、defaultテーマから // Values from the classic Mastodon UI (9行目) 以下にある4つの変数だけを書き換えたもの。

$classicから始まる4つの変数は、カスタムテーマが実装された2.0よりずっと前から あったものみたい。
$classic-base-color などでググれば、1.6以前の記事でも参考にできる配色があると 思われるので、ありがたく拝借すればよいだろう。
配色のことは、デザインセンスのないおれに聞かないで頂きたいw

全て終わったら、エラーがないことを神に祈りつつ、いつもの rake assets:precompile を実行し 再起動。(もっと速い手順がありそうとも思うが、念の為おれはこの手順でやってる) うまくいけば、各ユーザーはデフォルトのMastodonテーマと別に、bshockテーマも選べる様に なるはず。
うまくいかなかったら…確か、PostgreSQLのsettingsテーブルを開いて、theme値をごちゃごちゃ やる必要があったはず。そうはならない様、各位の健闘を祈るw

次回予告

先日、自宅鯖にMastodonインスタンスを引っ越した。
この時メモした作業手順を踏まえ、FreeBSDでの構築手順を書く予定。
FreeBSDでMastodonなんて地雷じゃね?などと言う人もいるだろうが、地雷ばかりじゃない。 ZFSイイ!以上。

Ubuntu Server 16.04 LTSにOracle 11g XEを入れてみる。

↓主に参考にした記事はこれ。(ありがとうございます)

Ubuntu 16.04 へ Oracle 11g Express Edition を入れてみた

同じUbuntu 16.04LTSであるにも関わらず、当方の環境では微修正が必要だった。 こちらではVMware Fusion(Mac)とKVM(Xubuntu)で試したけど、あんまり関係ないよね。謎だ。

本稿は一見、元記事と変わらないけど(記事の名前もよく似てるしw)、修正後の手順と その後の後処理を反映させてる。パクリっぽいけど、一応違うからw

依存パッケージのインストール(元記事を微妙に修正)

1
sudo apt install alien libaio1 unixodbc unzip bc

bcは、元記事の指示にはなかったもの。
まっさらなUbuntu Serverには入ってないが、実際には必要。

debパッケージの生成

Oracle Database Express Edition 11g Release 2

Linux x64版をダウンロード。Oracleのアカウント(無料)が必要なので、持ってなければ作ること。
ダウンロードしたファイルを設置先サーバに置いて、以下実行。

1
2
3
unzip oracle-xe-11.2.0-1.0.x86_64.rpm.zip
cd Disk1/
sudo alien --to-deb --scripts oracle-xe-11.2.0-1.0.x86_64.rpm

alienの実行には、かなり時間かかります。

debをバラす(元記事を微妙に修正)

1
2
3
4
mkdir tmp_deb
cp oracle-xe_11.2.0-2_amd64.deb tmp_deb #rpmから変換したdeb
cd tmp_deb
ar x ./oracle-xe_11.2.0-2_amd64.deb

このdebに入っているのは、以下の3つ。

  1. control.tar.gz
  2. data.tar.xz
  3. debian-binary

ファイル 1. と 2. は、内容を修正する必要あり。

data.tar.xzをバラして修正

1
2
3
4
mkdir tmp_data
cd tmp_data
tar axvf ../data.tar.xz .
vi ./etc/init.d/oraccle-xe

awkのパス(53行目)を、 /usr/bin/awk に修正。

1
if [ -z "$AWK" ]; then AWK=/usr/bin/awk; fi

/var/lock/subsys/ を /var/lock/ に置き換え。

1
:%s/subsys\///gc

シェバン(1行目)の下に、以下挿入。

1
2
3
4
5
6
7
8
### BEGIN INIT INFO
# Provides: OracleXE
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Oracle 11g Express Edition
### END INIT INFO

control.tar.gzをバラして修正

1
2
3
4
5
cd ..
mkdir tmp_control
cd tmp_control
tar axvf ../ccontrol.tar.gz .
vi ./postinst

update-rc.dへ書き換え。(114行目)

1
update-rc.d oracle-xe defaults 80 01

debファイルに戻してインストール(元記事を微妙に修正)

1
2
3
4
5
6
7
8
9
10
11
cd ..
rm data.tar.xz
rm control.tar.gz
cd tmp_control
tar acvf ../control.tar.gz ./
cd ../tmp_data
tar acvf ../data.tar.gz ./
cd ..
ar d ./oracle-xe_11.2.0-2_amd64.deb data.tar.xz
ar r ./oracle-xe_11.2.0-2_amd64.deb data.tar.gz control.tar.gz
sudo dpkg -i oracle-xe_11.2.0-2_amd64.deb

インストール(dpkgコマンド)もかなり時間かかります。

インストールスクリプトを修正(元記事にない手順)

以下のファイルについて、要修正。

  1. /u01/app/oracle/product/11.2.0/xe/dbs/init.ora
  2. /u01/app/oracle/product/11.2.0/xe/config/scripts/init.ora
  3. /u01/app/oracle/product/11.2.0/xe/config/scripts/initXETemp.ora

これらのファイルについて、 memory_target= から始まる行をコメントアウトする必要あり。
“=” の後ろに値が入っていないケースがあり(MacのFusionではそうだった)、その場合は インストールスクリプト実行時にシンタックスエラーになる為、 memory_target=1G 等と 修正せよと案内している記事もある。

ウチでは結局、行自体をコメントアウトする必要があった。(その旨を案内するログメッセージ も出てた)
ファイル 1. への修正は不要だったかもしれない。ちょっと自信ない。

インストールスクリプトを実行

1
sudo /etc/init.d/oracle-xe configure

最後にパスワードを聞かれるはずなので、入力したものを控えておく。
事前に無作為なパスワードを、apg等で用意しておくこと。

環境変数の設定

環境変数の設定を行う為に、 /u01/app/oracle/product/11.2.0/xe/bin/oracle_env.sh を実行する 必要がある。~/.profile 等に、このファイルを実行するよう追記。
シェルごとに手順が若干異なるので、各自お好みのシェルの手順で対応して頂きたい。

接続テスト

1
sqlplus

ユーザー名は system 、パスワードは先ほど控えたもの。
ここまでで設置の手順は終わり、元記事もここで終わっているが。

ユーザー作成(元記事にない手順)

このあとの手順はOracle使いには自明のことの様だけど、自分への備忘録を兼ねて。

デフォルトで作成されるsystemユーザーは、SYSTEM表領域を使用する等、通常の利用に適さない。
たとえ普段からDBA権限が必要であっても、systemではないユーザーを登録して普段はそちらを使うべき。

1
2
3
CREATE USER your_id IDENTIFIED BY "your_password" DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp;
GRANT DBA TO your_id;
GRANT UNLIMITED TABLESPACE TO your_id;

下2行、ほんとに実行するかどうかは用途によるだろうけど、テスト環境なら問題ないはず。
以下のクエリーで、登録状況を確認。

1
SELECT username, default_tablespace, temporary_tablespace FROM dba_users;

Oracleインスタンスを立てた目的

少々訳あって、Oracle Master Bronzeが必要になった。
「なんだブロンズかよ、しょぼ!」とか言うなw 以上。

Mastodonインスタンスのメモリが湯水のように使える様になれ。

状況

mstdn.b-shock.orgのメモリがひっ迫し、ピンチなのである。 以下、Sensuによるスワップ容量の監視状況。

平常時のswapinfoはこんな感じ。

1
2
Device          1K-blocks     Used    Avail Capacity
/dev/vtbd0p3 1572864 798660 774204 51%

平常時で既にスワップしてて、しかも使用量が50%を越えているのは感心しないが、 それはそれとして。Mastodon本体にチューンの余地はあると思うが(スレッド減らしたりとか)。
調査したところ、一番メモリを食っているのは1時間ごとに実行しているpg_dumpらしい。 ちなみに、gzipする前のダンプファイルの大きさは以下の様な具合。383MBとのこと。

1
-rw-------   1 root   pooza   383M 12月  9 13:51 mastodon_2017-12-09.sql

スワップ容量をデフォルトのまま少なく設定してしまった(1.5GBほど)ことに まずは問題があり、運用を始めてしまってからでも出来る対策として スワップファイルの作成を試みた。
この対策は一見うまくいったかに見えたが、スワップファイルからの読み込みがスワップパーティション より遅い為に?VPSではエラーが発生して使い物にならなかった。

ちなみに、スワップを使い切っていよいよヤバいと、カーネルがこんなログを吐く。

1
2
3
2017-12-08T23:14:50.615180+09:00 dodok kernel: swap_pager: out of swap space
2017-12-08T23:14:50.615724+09:00 dodok kernel: swap_pager_getswapspace(6): failed
2017-12-08T23:14:50.816012+09:00 dodok kernel: swap_pager_getswapspace(2): failed

このログが出るとdmesgにも同様の出力がされるので、監視の対象になってる。
アラートが発生したら、出先からでもMastdonインスタンスのVPSをリブートしてる。 カジュアルにリブートができるのは、おひとりさまインスタンスだからだが。

対策

  1. スワップ領域を大きく取る為、OSのインストールから構築をやり直す。
  2. VPSのプラン変更。(1G→2G or 4G)
  3. 自宅鯖への撤退。

通常であれば1.か2.(又はその両方)が妥当だが、現在1Gのプランを2Gに上げたところで やはり将来不足する様に思われた。一方、物理PCなら、メモリ8GB程度ものでも非常に安価に 入手できる。
以前、自宅鯖をインターネットに晒すのは極力よそうと思い立ち、その後は大半のサービスを VPS化した。現在は、やむを得ない理由でsshを開けているだけ。(自宅のIPアドレスは 固定している 。たとえサーバを立てるわけでなくても、業務上必要なので)

自宅鯖にWebサービスを立てるのは、個人的な感情では「撤退」だ。
上で述べたような自宅鯖自体の是非もそうだし、また、おれ自身は「少しでも腕におぼえがあれば誰でも、 月額1,000〜2,000円程度の出費でMastodonインスタンスを立てられるんだから、もっとカジュアルに インスタンスを立てよう!」という立場だった。
月額2,000円を超えるVPS(又は自宅鯖)という条件は、気軽にお勧めできるラインを越えていると 感じる。

気を取り直して、今回買ったのはこれ。

DELL OptiPlex 7010 中古

届いたら、今回は記録をとりながら構築していく予定。既に多くの手順をChef化しているので、 手作業は多くないはずと思ってるが。
世にあまり出回っていない、FreeBSDでの構築記事が書けるのではないかと、そこは期待してる。