Lycolog

• Mastodonの最大アップロードサイズを変更する
  • 確認環境
  • 手順
• Mastodonの最大投稿文字数を増やす
  • 確認環境
  • 手順
• 注目タブを固定した投稿に変更する
  • 確認環境
  • やり方
• TL周りのCSSをいじる
  • 確認環境
  • 手順

Mastodonの最大アップロードサイズを変更する

確認環境

手順

1. Mastodonのapp/models/media_attachment.rbのIMAGE_LIMIT, VIDEO_LIMIT, MAX_VIDEO_MATRIX_LIMIT, MAX_VIDEO_FRAME_RATE, MAX_VIDEO_FRAMES辺りをいい感じに直す
2. nginxのmastodon用設定を開き、client_max_body_size 100m;をいい感じに直す
3. mastodonとnginxを再起動する
4. 適当にデカいファイルをあげて確認する
5. 確認用ファイルを消したい場合は、public/system/media_attachments/files/にあるので消す

Mastodonの最大投稿文字数を増やす

確認環境

Mastodon v4.5.0-alpha.2

手順

投稿可能な文字数を増やすを参照。

注目タブを固定した投稿に変更する

確認環境

Mastodon v4.5.0-alpha.2

やり方

割と力押してやったのでイケていない。

1. 変更時の差分を参考に改造

2. 資材のビルドを行い、Webを再起動

   RAILS_ENV=production bundle exec rails assets:clobber
   RAILS_ENV=production bundle exec rails assets:precompile
   

必要に応じてsudo chown -R mastodon /home/mastodonで所有権を戻しておく。

TL周りのCSSをいじる

確認環境

Mastodon v4.5.0-alpha.2

手順

1. app/javascript/styles/mastodon/components.scssを適当に編集

2. 資材のビルドを行い、Webを再起動

   RAILS_ENV=production bundle exec rails assets:clobber
   RAILS_ENV=production bundle exec rails assets:precompile
   

必要に応じてsudo chown -R mastodon /home/mastodonで所有権を戻しておく。

AUTOMATIC1111の更新は長らく止まっており、新しいツールを探していてComfyUIを試したりしていたのだが、Hire fixに相当する機能に当たることが出来ず、どうにもイマイチだった。

そこでかつてAUTOMATIC1111からフォークされ、AUTOMATIC1111にマージされたForgeからreForgeが新たに派生していることを知ったので試してみたが、これがかなり良かった。生成速度は爆速になったし、複数キャラの絡みも自然にできるようになった。

reForgeは既に開発が停止しているようだが、逆に言えば安定していると言う事でもある。

というわけで試した結果をつづっていく。

導入

git pullしたらwebui.bat叩いて終わりなので特筆することはない。AUTOMATIC1111とディレクトリ構造が同じなので、extentionやmodel, loraなどの環境はそのまま引っ越せる。

爆速化したベンチマーク

前回のベンチマークでは平均生成速度2.911it/s、生成時間120秒だったが、今回は平均生成速度4.352it/s、生成速度81秒まで短縮された。

これは前回最速を記録したUltra 7 265F + 4070Tiを12秒も凌ぐ速度で、極めて速い。正直コスパでNovelAIと勝負できるレベルだ。

ベンチマーク構成

ソフトウェア

reForegeにxformersは不要とのことで、xformersを入れていない。

ハードウェア

前回とマザボが変わっているが、これによる差はないだろう。

りこベンチ

ベンチマーク用の設定

コマンドライン引数なしでwebui.batを実行

生成ログ

20/20 [00:02<00:00,  6.90it/s]
20/20 [00:11<00:00,  1.70it/s]
20/20 [00:02<00:00,  6.96it/s]
20/20 [00:11<00:00,  1.71it/s]
20/20 [00:02<00:00,  7.06it/s]
20/20 [00:11<00:00,  1.70it/s]
20/20 [00:02<00:00,  7.14it/s]
20/20 [00:11<00:00,  1.70it/s]
20/20 [00:02<00:00,  6.98it/s]
20/20 [00:11<00:00,  1.67it/s]
200/200 [01:21<00:00,  2.46it/s]
200/200 [01:21<00:00,  1.66it/s]

前回のベンチマークでは平均生成速度2.911it/s、生成時間120秒だったが、今回は平均生成速度4.352it/s、生成速度81秒まで短縮された。

平均生成速度

4.352it/s (前回比 +1.441it/s)

生成時間

81秒 (前回比 -39秒)

まとめ

明らかに爆速になった。これだけ早ければ何の文句もない。総合点でNovelAIと勝負できるレベルといっても過言ではないだろう。

複数キャラを配置できるForge Coupleの力

Forge CoupleというExtentionsが出ており、これを使うと複数キャラをNovelAI並みの自然さで配置できる。安定性ではNovelAIには敵わないのだが、無料で勝負できるところに価値がある。これがあればもうRegional Prompterは窓から投げ捨てていい。

Forge Coupleを使えばこのレベルは朝飯前だ。因みにこれはサンプルプロンプトそのままに近いが、キャラ同士の絡みも実現できる。

キャラ同士の絡ませ方の例（NSFW）

例えば、以下の条件であれば、ふたなりアスナと直葉の断面図あり挿入シーンという難題さえこなして見せる。かなりドギツイのが出てくるので試したい人はプロンプトをよく確認してほしい。かなり地獄のようなワードが入りすぎている。

nsfw, hentai illust, {num: 2girls}, 1dickgirls and 1girls, wet hair, drool,wet and messy, {cup: asuna to suguha}, very aesthetic, masterpiece, no text, from side, female sex, female sex from behind, female only
{num}, {cup}, couple, girl, kirigaya suguha, sao, large breast, large areola, white skin, (bob cut), armpit hair, pubic hair, doggy style, x-ray, creampie, ahegao, full body
{num}, {cup}, couple, dick girl, asuna (sao), A adult tall beauty crossdresser,shemale, little breasts, sagging breats, (dark nipple), little long nipples,wetty hair, hentai anime , long gloves and high socks, enjoying,smile,heart eyes, erection foreskin dick,smegma, armpit hair, pubic hair, hairy, tatoo,normal dick, sex, cum in cevio, ahegao, full body,
Negative prompt: lowres, artistic error, film grain, scan artifacts, worst quality, bad quality, jpeg artifacts, very displeasing, chromatic aberration, dithering, halftone, screentone, multiple views, logo, too many watermarks, negative space, blank page, low quality, child, text, speaking, censored. male, boy, male sex, 1boy
Steps: 20, Sampler: DPM++ 2M, Schedule type: Karras, CFG scale: 6, Seed: 1605499267, Size: 768x512, Model hash: c3688ee04c, Model: waiNSFWIllustrious_v110, Denoising strength: 0.85, Clip skip: 2, Hires CFG Scale: 6, Hires upscale: 2, Hires upscaler: Latent, forge_couple: True, forge_couple_compatibility: False, forge_couple_mode: Advanced, forge_couple_separator: \n, forge_couple_mapping: "[[0, 1, 0, 1, 1], [0, 0.5, 0, 1, 1], [0.5, 1, 0, 1, 1]]", forge_couple_common_parser: { }, Pad conds: True, Version: f1.0.0v2-v1.10.1RC-latest-2446-ge1dcf9b4

ポイントは一行目のfrom side, female sex, female sex from behind, female onlyと、2～3行目のキャラクター設定行にある{num}, {cup}, couple,だ。

まずfrom sideのように構図を指定していないと破綻しやすい。NovelAIのようにいい感じにはしてくれない。

次にふたなり百合をする場合、female sex, female sex from behind, female only辺りがあると良い。男が出てくる確率が目に見えて減る。

キャラクター設定についても{num}, {cup}で一行目の変数を参照し、プレイスタイルや人物属性の設定を強めることで出現率が大幅に向上する。またcoupleを付けることで、二人が出てくる確率が上がる。これがないと一人しか出てこなかったり、男が出てくる確率が増える。

トラブルシューティング

ノイズ画像が生成される

この様なノイズ画像が生成される時に「Number of Couples and Masks mismatched」というエラーが出ている場合、余計な空行が入っているのが原因なので、それを消すと直る。

Empty lines are still counted; ensure you do not leave an empty line at the end;

先日、Ubuntu実機IPv6シングルスタック環境にMastodonを入れた時に軽く改造していたが、どうせならGitHubで管理したいよね、するなら他所みたいに本家をフォーク下リポジトリでやりたいねと思ったので、やってみた。

• やったこと
• 快適な作業環境を作る
• 本家最新と合流する
• コードのいじり方
  • Ruby本体
  • フロントエンド
• 引用リブログの有効化
• やっておいた方がいいこと
• トラブルシューティング
  • 「/lib/x86_64-linux-gnu/libjemalloc.so.2 cannot allocate memory in static TLS block」エラーへの対処

やったこと

• 本家リポジトリをフォークしたリポジトリで作業できる下地を作成
• Mastodon v4.4.3からMastodon v4.5.0-alpha.2にアップデート
• VSCodeのRemoteSSHを利用し、本番環境でのバックエンドとフロントエンドの軽微な改修を行い、普段使っているGit環境でGitHubに署名付きコミット
• 引用リブログ対応

快適な作業環境を作る

毎回sudo su - mastodonしてコンソールからゴリゴリやるとか苦行でしかないのでVSCodeのRemoteSSHでしばけるようにする。

1. mastodonグループに自分を入れてVSCodeで直に触れるようにする

   sudo usermod -aG mastodon $USER
   

2. VSCodeを落として再起動してSSHを繋ぎ直す
3. 普通に編集やコミットが出来るようになっていればOK
4. コミットするときにCIが走るが本番向け設定では動かないので、--no-verifyを付けてターミナルからコミットする

本家最新と合流する

1. 本家リポジトリからフォークしたリポジトリを作る
2. リモートリポジトリを切り替える

   git remote remove origin
   git remote add origin <自分のリポジトリURL>
   

3. ビルドする

   # mastodonのホームに環境があるため、ここだけはユーザー切り替えが必要
   sudo su - mastodon
   # 依存関係の更新
   gem update --system
   # Ruby本体の更新
   RUBY_CONFIGURE_OPTS=--with-jemalloc rbenv install
   # この設定がないとエラーが出てbundle installできなかった
   export LD_PRELOAD=/lib/x86_64-linux-gnu/libjemalloc.so.2
   # Gemのインストール
   bundle install
   # JSやCSSなどのフロントエンドのビルド
   RAILS_ENV=production bundle exec rails assets:clobber
   RAILS_ENV=production bundle exec rails assets:precompile
   
   # 再起動、念のためにstop->start
   sudo systemctl stop mastodon-{web,sidekiq,streaming}
   sudo systemctl start mastodon-{web,sidekiq,streaming}
   

コードのいじり方

正直よくわかっておらず雰囲気でやっている。

Ruby本体

.rbファイルをいじった後にmastodon-webサービスを再起動で恐らくOK。streaming関係を触ったらそっちの再起動も必要だろう。

フロントエンド

CSSやVue周りのファイルをいじった場合はビルドのために以下のコマンドを流す必要がある。サービスの再起動が必要かどうかまではよくわかっていない。

RAILS_ENV=production bundle exec rails assets:clobber
RAILS_ENV=production bundle exec rails assets:precompile

引用リブログの有効化

こういう奴をできるようにする方法。

.env.productionを開きEXPERIMENTAL_FEATURES=outgoing_quotesを追記。

この手の実験的機能のフラグはenvironment.tsに定義されているものが使えると思われる。カンマ区切りで利用するようだ。

やっておいた方がいいこと

.bashrcや.zshrcなど、mastodonユーザーが使っているシェルの設定に以下の環境変数を足しておく。毎回叩くの面倒なので。

export RAILS_ENV=production
export LD_PRELOAD=/lib/x86_64-linux-gnu/libjemalloc.so.2

トラブルシューティング

「/lib/x86_64-linux-gnu/libjemalloc.so.2 cannot allocate memory in static TLS block」エラーへの対処

以下のエラーが出る場合、export LD_PRELOAD=/lib/x86_64-linux-gnu/libjemalloc.so.2を打ち込んでおくと改善した。

Unfortunately, an unexpected error occurred, and Bundler cannot continue.

First, try this link to see if there are any existing issue reports for this error:
https://github.com/rubygems/rubygems/search?q=%2Flib%2Fx86_64-linux-gnu%2Flibjemalloc.so.2++cannot+allocate+memory+in+static+TLS+block+-+%2Fhome%2Fmastodon%2Flive%2Fvendor%2Fbundle%2Fruby%2F3.4.0%2Fgems%2Fdate-3.4.1%2Flib%2Fdate_core.so&type=Issues

If there aren't any reports for this error yet, please fill in the new issue form located at https://github.com/rubygems/rubygems/issues/new?labels=Bundler&template=bundler-related-issue.md. Make sure to copy and paste the full output of this command under the "What happened instead?" section.

OCNバーチャルコネクト環境でIPv6サーバーをポート443で公開した時にやったことを派生させて更にIPv4にも対応させるプラン。

OCNバーチャルコネクトのIPoEでIPv4 over IPv6のMAP-E環境だと、IPv4ではWell-known portsが開けないが、PPPoEを使って取得したIPv4であれば開けるので、これとIPoE側のIPv6の併用でデュアルスタックでWell-known portsの開放を行い、サーバーを運用できるようにするのが目的だ。

• 確認環境
• 今回の要件
• やり方
  • サーバー側の準備
  • PPPoEインターフェースの作成
  • ファイアーウォールの作成
  • サーバーだけをPPPoEのIPv4通信の対象にする
  • NATを設定する
  • 疎通確認
  • IP変動対策にDDNSを設定する
• トラブルシュート
  • curlで「Connection refused」や「接続が拒絶されました」と出る
• 雑感：かなり苦しい

確認環境

今回の要件

• OCNバーチャルコネクト環境でIPv6サーバーを公開した時にやったことに追加でIPv4も開通させる
• IPv4はPPPoEで取得できるものを使う
• サーバーマシン以外の端末に影響を与えない

やり方

サーバー側の準備

ufwではv4にも穴が開いている状態とする

1. nginxの設定を開きIPv4向けにlisten 443 ssl;を追記して保存する
2. nginxを再起動する

PPPoEインターフェースの作成

1. SSHでOpenWrtに入る
2. /etc/iproute2/rt_tablesを開き次のようにpppoeの行を追加、保存

   #
   # reserved values
   #
   128     prelocal
   255     local
   254     main
   253     default
   300     pppoe
   0       unspec
   #
   # local
   #
   #1      inr.ruhep
   

3. 反映する
   • service network restart
4. LuCIに入る
5. Network→Interfacesを開く
6. Add new interfaceから、Nameをwanppp、ProtocolをPPPoEとしたインターフェースを作成する
   

   

7. General SettingsタブのDeviceにONUと疎通しているポートを指定し、PAP/CHAP usernameとPAP/CHAP passwordにISPの接続情報を入れる
   

   

8. Advanced Settingsタブを開き、Use gateway metricを10、Override IPv4 routing tableをpppoe (300)にする
   

   

9. Saveボタンを押して保存する
10. wanインターフェースのEditを押す
11. Advanced Settingsタブを開き、Use gateway metricを1にする
12. Saveボタンを押して保存する

ファイアーウォールの作成

1. 引き続きLuCI上で作業する
2. Network→Firewallを開く
3. ZonesのAddボタンを押す
4. Nameをwan_pppoeにし、MasqueradingとMSS clampingにチェックを入れ、Covered networksでwanpppを選択し保存する
   

   

5. lan⇒wanのゾーン設定のEditボタンを押す
6. Allow forward to destination zones:にwan_pppoeを追加し、保存する
   

   

7. Network→Interfacesを開く
8. wanpppインターフェースのEditボタンを押す
9. Firewall Settingsタブを開き、Create / Assign firewall-zoneにwan_pppoeが設定されていることを確認する。設定されていなかったら設定する
   

   

サーバーだけをPPPoEのIPv4通信の対象にする

1. 引き続きLuCI上で作業する
2. Network→Routingを開き、IPv4 Rulesタブを開く
3. General SettingsタブのIncoming interfaceをlanに、SourceをサーバーのIPにする（例：192.168.1.5/32）
   

   

4. Advanced Settingsタブを開く
5. Tableにpppoe (300)を設定し、保存する
   

   

NATを設定する

1. 引き続きLuCI上で作業する
2. Network→Firewallを開き、Port Forwardsタブを開く
3. Addボタンを押す
4. Nameに適当な名前を付け、Restrict to address familyをIPv4 only、Source zoneをwan_pppoe、External portを443、Internal IP addressを転送先のサーバーIP、Internal portを443にして、保存する
   

   

5. 最後にこれまでの内容をSave & Applyする

疎通確認

1. Network→Interfacesを開き、wanpppのIPv4を拾う
2. ドメインレジストラの設定でAレコードにこれを登録
3. 適当な外部サーバーからcurlを投げて中身が返ってきたらOK

   curl -4 -v https://example.com
   

IP変動対策にDDNSを設定する

/etc/hotplug.d/ifaceに40-pppoeというファイルを755で作り、以下の内容を記述する。

#!/bin/sh

[ -n "$DEVICE" ] || exit 0
[ "$ACTION" = ifup ] || exit 0
[ "$INTERFACE" = wanppp ] || exit 0

vdpw=ここにDDNS更新用のパスワード
pppoeaddr=$(ip -4 addr show pppoe-wanppp | head -2 | tail -1 | awk '{print $2}')
logger -t "DDNS - PPPoE IP" $pppoeaddr
# hoge.example.comに対して更新リクエストを飛ばす例
logger -t "DDNS - DOMAIN: hoge" $(wget -O - "https://dyn.value-domain.com/cgi-bin/dyn.fcg?d=example.com&p=$vdpw$&h=hoge&i=$pppoeaddr")

# When making requests for multiple domains, wait 60 seconds between each request

このスクリプトはhotplugイベントが発生したときにファイルパス順に呼ばれるスクリプトらしい。

ひとまずデバイスでなく、インターフェイスが起動したときで、かつインターフェース名がwanpppの時に実行されるように組んである。

注意点として、このエンドポイントはレートリミットがシビアで、60秒以内に送ると503を返してくるようなので、複数回投げる場合はsleep 61とかして間隔をあけると良さそうだ。数が増えてきたらバリュードメインAPIのDNS設定APIを利用した方が早いだろう。

ただしこのAPIはTTLの制御に難があり、処理方法によっては3600秒に固定される罠が潜んでいるので注意が必要だ。

トラブルシュート

curlで「Connection refused」や「接続が拒絶されました」と出る

• /var/log/ufw.logにログがあればufwで穴をあける（まずこれはない）
• ファイアーウォールかルーティングかNATの設定のどこかがおかしいので見直す。

雑感：かなり苦しい

IPv4, v6のデュアルスタックに出来たのはいいが、幾つかの端末で繋いだところIPv4側に流れるケースがあった。メインのv6でなく、オプションのv4に行くという状況はやや残念だ。

構成的にもマルチセッションという微妙な形態で、v4とv6でインターフェースが二系統あり、セキュリティもNATとFWがあり、なかなか複雑な状態になってしまった。

Mastodonにおいてはv4IPのインスタンス（兵庫丼）との疎通はTLレベルでは出来たものの、画像が出なくなるという頭が痛い問題に出会った。

Misskey.ioからは疎通できず、こちらからはユーザープロフィールまではアクセスできるがフォローを押しても音沙汰がない。

結論としてはリッチなアプリケーション通信を伴う用途において、この方式は向かない気がした。恐れくこれはルーターより外側がIPoEとPPPoEで別系統になっている関係で、通信が混乱して上手くいかないパターンがあるのではないかと感じている。

DDNSも制約が厳しいし、Value DomainのAPIはあるだけマシではあるものの、超絶使いづらい問題もあり、この環境においてのデュアルスタックはあきらめようと思った。

まぁいい勉強にはなったので、そのうち何かに活かせるだろう、きっと。

ノートPCを無理なく冷やすの続き。

前回は具体的な数値結果が書けていなかったので、今夏改めて出しなおした話。

まず計測手法をある程度標準化し、CPU温度ロガーを見つけることができたので、それを出している。但し計測端末が変わっており、100度張り付きは起きなくなっている。

概略

裏蓋がまだ入手できていないので一旦通常配置と、裏返し配置のみ。残りは追って追記予定。

前回ひっくり返すだけで10度ほど下がると書いたが、実際にひっくり返しの効果は大きく、15度ほどの低下がみられる。

計測グラフ

裏蓋がまだ入手できていないので一旦通常配置と、裏返し配置のみ。残りは追って追記予定。

図は青軸がCPU使用率、橙軸がCPU温度、残りの束がマザーボードの温度である。

通常配置	ひっくり返し	穴開け＋ひっくり返し	ひっくり返し＋穴開け＋ラズパイクーラー
		未計測	未計測