alchemistarkの日記

やったことのメモ

漫画サーバーの乗り換え

Comistream Readerからkavitaに乗り換えを検討中。

そもそも何故Comistream Readerを使用していたかというと
画像データの圧縮機能がある(恐らく)唯一のサーバーだから

ゴリゴリ圧縮かけて250kbpsの回線でギリギリ耐えれる速度で動作しておりました。
とても助かりました。ありがてえ。

comistream.dcc-jpl.com

現在Reader機能のみで、最低限以外の機能が搭載されていないため
将来的には期待できるのですが現時点では本当にリーダーしか無いので
色々とかゆいところに手が届かないというかなんというか。

個人的に気になったのは
・機能切り替えボタンが「押したらそれになるよ」表記
 圧縮の有効無効がボタン切り替えなのだが今どっちかわかりにくい 切り替えボタンのあるある問題ですやね
・綴り方向が記憶されない
 ページ送りのタッチ位置を変更するため綴り方向を逆にして読んでるのですが
 本を開く度に元に戻るのでめんどい ページ送りのタッチ位置を左右逆にするオプションでもいいぞ
・次の本に移動してくれない
 それらしき窓は出るんだが、どうやって次の本はコレと指定するのか?

逆に気に入ってたところは
・画像トランスコード機能
 生命線。逆に他のリーダーは何故搭載していない??????
・実フォルダ階層でブラウズできる
 シリーズ単位とかメタデータでの仕分けは逆に無かったりするが…
 ライブラリをしっかりフォルダ分けしている場合はこっちの方がありがたかったり。
・動作が軽快
 カス回線だとwebページ自体を読み込めなくて落ちるんだよ。



先日回線変えまして、OCNモバイルONEからmineoにしたので
250kbpsから1Mbpsになりました。速度4倍。

試しにkavitaを導入して読み込んでみたところ普通に閲覧できたので
ちょっと本格的に移行しようかなぁというのが今。

移行時に問題になる点がワイの場合
Comistream ReaderではComicInfo.xmlに対応していない*1ので
ComicInfo.xmlを作成していなかったので
最低限の内容でも作成して入れてやる必要がある
既存のファイルにも入れてやらないといけないのでちょっと考えよう*2



触る予定だったけどやらなくなっちゃった内容のメモ

Comistream Readerのお気に入りや既読のフラグはsqliteファイル内に記録されている
ファイル名と保存先のペアでキーになっている為、ファイルを移動するとお気に入りや既読のマークが見えなくなる
その状態で再度お気に入りに入れるなどのdb変更を伴う操作を行うと
保存先のデータが移動先のパスで上書きされて既読状態などが正常に反映されるようになる
逆にdb内を直接編集して移動することも可能
これらは同じファイル名の本が2つ以上別のパスにある場合問題になり
片方で操作を行う度にフラグが片方に切り替わるという挙動になると思われる
複数パスにハードリンク貼ったワイでもない限り起きないけどなそんな問題
ファイル名やパスのハッシュが入っているが、消しても動く 何故?

ライブラリを大掃除したとかでファイルパスが大幅に変わってしまった場合、
db内のファイルパスを正常な位置に書き換えるスクリプトとか書けば
一括で既読状態を元に戻すことが可能ではある

*1:…よね?

*2:いつも通りAHKスクリプトでどうにかする予定

NPMplusでMyDNS.jpのワイルドカード証明書を取得する

NginxProxyManagerではどうかは知らない*1

運用がこれからなのでちゃんと更新されるかまだ分からないけど
とりあえずページが開けるまではできたので手順をまとめておく。

MyDNS.jpはNPMPlusからDNSチャレンジができないので
一旦適当な証明書を作成して、それにワイルドカード証明書を上書きして設定を乗っ取る手を使います。

MyDNS.jpにてワイルドカード証明書のDNSチャレンジ用のスクリプトがあるのでそれを使用します。

github.com

永続ボリュームかホストマウントの場所に展開。*2

cd /your/domain/directory/
wget 'https://github.com/disco-v8/DirectEdit/archive/master.zip' -O DirectEdit-master.zip
unzip ./DirectEdit-master.zip
cd /your/domain/directory/DirectEdit-master/
chmod 700 ./*.php
chmod 600 ./*.conf

ワイ氏ホストパスの権限が面倒なのでchmodを無視
実際に実行したところ全て700(-rwx------)になってしまったが、システムやコンテナでそういうこともあるらしい。ほんまか?*3
外部からアクセスできないパスなのでままえやろ
ここで展開したphpファイルは更新時も使うので、パスを控えておく。

txtedit.confを編集する。
ログインIDとパス、取得している*.mydns.jpのアドレスを入力。

$MYDNSJP_MASTERID  = 'yourmasterid';
$MYDNSJP_MASTERPWD = 'yourpasswd';
$MYDNSJP_DOMAIN = 'yourdomain';

certbotを実行…したいのだが、NPMplusのコンテナ内にPHPが無いので
ENVからPHPを有効にする。
該当ENVは
・PHP85=true
・PHP85_APKS=php85-curl php85-openssl php85-mbstring php85-cli
PHP8.3から8.5が選べるようだが違いが分からない。とりあえず最新でいいのでは。

公式のENVリストにはmbstringとcliは含まれていないが、
mbstringが無いとエラーになる*4し、cliを入れないとパスが通らない。*5

TrueNASのappからだとAdditional Environment VariablesからAddして追加。

そして設定されるパスはusr/bin/phpではなくusr/bin/php85なので
txtregist.phpとtxtdelete.phpの1行目に85を付け足しておく。
…と思ったけど書き換えなくていいやつだな?あれ?なんでちゃんとパス通ってるの?*6

/usr/bin # ls -l | grep php
lrwxrwxrwx 1 root    root           5 Aug 31 17:05 php -> php85
-rwxr-xr-x 1 root    root    15474480 Aug  5 14:45 php85
/usr/bin # which php
/usr/bin/php

もし無かったらphp85に修正してください。多分俺の気のせいです。

次に証明書を手動で取得。
提示されているシェルスクリプトが以下の通りなのですが

certbot certonly --manual \
--preferred-challenges=dns \
--manual-auth-hook /your/domain/directory/DirectEdit-master/txtregist.php \
--manual-cleanup-hook /your/domain/directory/DirectEdit-master/txtdelete.php \
-d yourdomain -d *.yourdomain \
--server https://acme-v02.api.letsencrypt.org/directory \
--agree-tos -m yourmailaddr \
--manual-public-ip-logging-ok

・manual-auth-hookとmanual-cleanup-hookにスクリプトの置いてあるパスを設定する
・yourdomainに自分の取得しているURLを入れる
・yourmailaddrに自分のメールアドレスを入れる…必要?これ
で、--manual-public-ip-logging-okはcertbotのコマンドから廃止されているので削除する。動作には問題ない。*7

実行すると証明書が取得され、情報メール送るぜ!ってメッセージが出てくるのでNoと入力する。なにこれ。

取得した証明書の保存先パスが表示されていると思うので控える。
コンテナ再起動で消えてしまったので正確なパスが不明なのだが
恐らく
/etc/letsencrypt/live/[ドメイン名]/
/etc/letsencrypt/archive/[ドメイン名]/
に保存されています。
これらを一旦保存。

また、
/etc/letsencrypt/renewal/[ドメイン名].conf
というファイルがあると思うのでこれも保存。

で、自分がやってた時気付かなかったんだけど
liveディレクトリ内の証明書ファイルはarchive内のファイルにシンボリックリンクされてるので
liveだけ持っていくと壊れるので注意。
多分相対パスでシンボリックリンクされてると思われるが、念の為移動前に確認してください。*8
移動後確認したらこうなってたので参考までに。
これは証明書更新後なので少なくとも更新に成功したら正常になると思う

8f921edcf15d:/data/tls/certbot/live/npm-21# ls -l
total 15
-rwx------ 1 npmplus npmplus 692 Aug 31 16:11 README
lrwxrwxrwx 1 npmplus npmplus  30 Aug 31 21:21 cert.pem -> ../../archive/npm-21/cert3.pem
lrwxrwxrwx 1 npmplus npmplus  31 Aug 31 21:21 chain.pem -> ../../archive/npm-21/chain3.pem
lrwxrwxrwx 1 npmplus npmplus  35 Aug 31 21:21 fullchain.pem -> ../../archive/npm-21/fullchain3.pem
lrwxrwxrwx 1 npmplus npmplus  33 Aug 31 21:21 privkey.pem -> ../../archive/npm-21/privkey3.pem


ここで一旦NPMplusのWebUIに入り、適当な証明書を作成する。
名前を変更するのが面倒なので、サブドメイン無しで取得するかwww.とかall.とかのサブドメインにするといいかも。*9
この時ID番号を控えておく。

/data/tls/certbot/live/npm-[ID番号]
/data/tls/certbot/archive/npm-[ID番号]
ここに取得した証明書を上書きする。
フォルダ名が違う(リンク先が不正になる)が、更新処理したら全部上書きされるし多分大丈夫!!!*10*11

保存したrenewal/[ドメイン名].confも
/data/tls/certbot/renewal/npm-[ID番号].conf
として保存。

confファイルを開き、移動先のパスに書き換え。

archive_dir = /data/tls/certbot/archive/npm-[ID番号]
cert = /data/tls/certbot/live/npm-[ID番号]/cert.pem
privkey = /data/tls/certbot/live/npm-[ID番号]/privkey.pem
chain = /data/tls/certbot/live/npm-[ID番号]/chain.pem
fullchain = /data/tls/certbot/live/npm-[ID番号]/fullchain.pem

manual_auth_hook = /directedit-master保存先パス(絶対)/txtregist.php
manual_cleanup_hook = /directedit-master保存先パス(絶対)/txtdelete.php

config_dir = /data/tls/certbot

webroot_path = /data/tls/certbot/acme-challenge,

多分これだけだと思う(忘れた)

以上で乗っ取り完了なので、NPMPlusのWebUIから証明書の更新を実行して正常終了したら完了です。

後は設定して接続試験できたらOKです。お疲れ様でした。

自動更新されてるか確認するのでまた来週!

*1:こいつらわりと違う

*2:/dataが永続ボリュームなのでそこに突っ込んでもいいと思うけど何かあったら消えるのでバックアップは持っておこう

*3:例えば601で実行するときっちり-rw------xになる。実行権限が最低1つ残るんだろうか?

*4:コメントに日本語(マルチバイト文字)が含まれているから?ひどいはなし

*5:usr/bin/phpが存在しない

*6:最初やった時無かった記憶

*7:前の行の\を消すのを忘れるなYO!←忘れた人

*8:リンクは確実に壊れる

*9:後でsqlite開いて変えてもいいけど動かなくなっても知らない

*10:雑

*11:もしかしたら証明書の名前の空ファイルと更新用confファイルだけでも行けるのかもしれない…?

リバースプロキシ覚え書き

今回dbをサブドメインではなくパスの先に置いたんだけど
リバースプロキシの設定で詰まったのでメモ。

hogehoge.domain.com/でwebインターフェースに繋がるようにして、
hogehoge.domain.com/couchdb/でデータベース運用したいわけです

で、普通にカスタムロケーションに/couchdbとか/couchdb/とか入れただけだとcouchdbってパスが無いって怒られるので
接続先IPアドレスの指定の最後に/を入れるという事を知りました なんそれ*1

ううむ、これで動くならサブドメインで動かしてる各種サービスを
カスタムロケーションで運用できるのでは…?
ちょっと考えよう

*1:IPアドレスだけじゃなくてホスト名やパスも入れれる場所なので問題はないのだが、普段IPアドレスしか入れてないので末尾に/入れる発想は無いよ?

Obsidianも試す 導入

ノート難民です。
そんなノート取ることもないんだけどね

先の記事で貼ったIgnisの起動ができたので記録します。

github.com

まずcomposeがこちら

version: "3.8"
services:
  couchdb:
    image: couchdb:latest
    container_name: couchdb
    restart: always
    environment:
      - COUCHDB_USER=couchdb_username
      - COUCHDB_PASSWORD=couchdb_password
    volumes:
      - ./data/couchdb:/opt/couchdb/data
      - ./conf/local.ini:/opt/couchdb/etc/local.ini
    ports:
      - "5984:5984"
      
  ignis:
    image: nobbe/ignis:latest
    ports:
      - "5985:8080"
    environment:
      # match these to your host user (run: id)
      - PUID=1000
      - PGID=1000
    volumes:
      - ./vaults:/vaults
      - ./data:/app/data
      - ./obsidian-app:/app/obsidian-app
    restart: unless-stopped

couchdbの設定ファイルを事前に作成しておく。

local.ini

[couchdb]
single_node=true
max_document_size = 50000000

[chttpd]
require_valid_user = true
max_http_request_size = 4294967296

[chttpd_auth]
require_valid_user = true
authentication_redirect = /_utils/session.html

[httpd]
WWW-Authenticate = Basic realm="couchdb"
enable_cors = true

[cors]
origins = app://obsidian.md,capacitor://localhost,http://localhost,https://yourdomain.couchdb.url
credentials = true
headers = accept, authorization, content-type, origin, referer
methods = GET, PUT, POST, HEAD, DELETE
max_age = 3600

originsに同期サーバーにアクセスできるURLを追記しておく。モバイルappからのアクセスはhttps必須らしい。

起動したらdbの接続確認
http://host.ip:5984/_utils/
で接続できる。ここは接続できれば良い。*1

ignisの起動を確認できたら設定→コミュニティプラグインから
Self-hosted LiveSyncをインストールする
GitHub - vrtmrz/obsidian-livesync · GitHub

有効にするとセットアップをしろというバルーンが出るので開始

→初めて設定します→Configure a remote manually
から設定を開始

・E2E暗号化
・Obfuscate Properties
セキュリティ関連項目 とりあえずチェックを入れる E2E暗号化は暗号化キーを適当に入力
Advancedは無視

→CouchDBを選択

・URL 接続可能なURL
コンテナ間接続でもいいのかもしれないが、結局他の同期デバイスからもアクセスするし
Originとかtlsとか設定ややこしくなりそうなので大人しくドメイン入れた方がいいと思う。
・ユーザー名とパスワード
yamlで設定したやつ
・データベース名
適当に名前を付けてやればOK obsidianとかvaultと同じ名前とかでいいんじゃない
後は無視して接続テスト後に接続*2

後は普通にobsidianです ワイ普通に使ったこと無いから知らないけど


livesyncが失敗したのでメッチャ苦戦したんだが
最終的に最初からやり直したら行けたので苦労返せってなってる

注意点として、トップレベルにflag_とかの自動生成ファイルができた場合
それが残っていると永久に同期が始まらないので削除すること。

後はとにかく待つんだ 全部終わるまで待つんだ
どこで全部終わったかわかんねーよ初見なんだから

とにかくデータベースがロックされたままになっていないことと
Scram!が出ていると監視が停止するのでこの状態になっていないこと
で、多分どちらも手動で戻せないので初期化した方が早いってなると思われる

*1:もしこの後何も問題ないのに接続できない場合はログイン後configに入りCORSを有効にする必要があるかもしれない。確認する前に有効にしてしまった

*2:テストは必須

Joplinのwebクライアント

何故無いのか。

公式でwebアプリが提供されていはいるが、導入しやすいようにはなっていない
dockerイメージ提供してくれているフォークもあるが、どうもうまくいかなかったし
そもそもwebクライアントにローカルファーストは求めてなくない?ってなって終了。*1

定期的にwebクライアント出てないかな~って探してたんだけど出てました。

github.com

joplin serverに接続して動作し、データベースを直接読み書きする仕様。
いつも通り起動にクッッッッッッッッソ手間食ったのでメモ。

networks:
  default:
    external: True
    #既存のjoplinserverと同じネットワークに接続する
    name: ix-internal-joplin-joplin-net
services:
  joplock:
    environment:
      DEBUG: 'false'
      HOST: 0.0.0.0
      IGNORE_ADMIN_MFA: 'false'
      JOPLIN_PUBLIC_BASE_PATH: ''
      JOPLIN_SERVER_ORIGIN: https://joplin.app.url #JoplinServerのBase URLと同じ
      JOPLIN_SERVER_PUBLIC_URL: https://joplin.app.url #JoplinServerのBase URLと同じ
      JOPLOCK_ADMIN_EMAIL: ''
      JOPLOCK_ADMIN_PASSWORD: ''
      JOPLOCK_BACKUP_DIR: /backups
      JOPLOCK_PUBLIC_BASE_URL: https://joplock.app.url #設定してもIP:3001での接続は可能
      JOPLOCK_RECOVERY_ENABLED: 'false'
      JOPLOCK_RECOVERY_PASSWORD: ''
      PORT: 3001
      POSTGRES_DATABASE: joplin
      POSTGRES_HOST: postgres #postgresコンテナ名
      POSTGRES_PASSWORD: joplin_pg_password
      POSTGRES_PORT: 5432
      POSTGRES_USER: joplin
    extra_hosts:
      - joplin.app.url:192.168.0.2 #リバースプロキシのIP
    image: ghcr.io/abort-retry-ignore/joplock:latest
    ports:
      - '3001:3001'
    pull_policy: always
    volumes:
      - ./joplock/backups:/backups

コンテナ起動したらURLかIPで接続、ログイン情報にJoplinServerのログイン情報を入れる
この時、リバースプロキシのtls設定で"HTTPSを強制"にチェックを入れてはいけない
ORIGINにhttpsを指定していてもダメです 何故かログインできない*2

ログインできたらOKです お疲れ様でした

ここまでやってなんですが、ノートをD&Dできないので使わないかもしれない。泣きてえ。
確認したら本家webappでもandroidアプリでもできねぇのか。整理させろ。*3

Obsidianのweb版も最近出たっぽいので、今度はそっち試してみます。

github.com


Trilium Noteもいいんだけどさ…機能多すぎて逆にちょっとね…

triliumnotes.org

ワイはちょっとリッチな文章が書けていいとこ画像貼り付けれたらそれで十分なので…

*1:まず全てダウンロードしますというボケ挙動

*2:httpsへのリダイレクトが発生し、その際リクエストからログイン情報が消えるらしい。リダイレクト起きてなくない?

*3:デスクトップ版はできる

OpenWrt WF1200CRについて

ガチャのお時間です

WG1200CRとWF1200CRはOpenWrt化できる小型ルーターですが
ファームウエアが一定以上だと導入できないというガチャがありまして。
WG1200CRを運試しで買ったら見事にハズレで頭抱えて、先日ハードオフで再度見かけたので(使いもしないのに)再購入。

で、帰宅してよく見たらWF1200CRでした。バーカバーカ。
CPU周波数はどちらも同じだけどWF1200CRは100Mbpsしか出ねぇ。いいけどさどうせ1C1TのCPUだし…

マジかよいらねぇ!まぁしゃあないしガチャ確認すっかぁ!ってなって確認したら
見事ガチャ勝利。いらねえ。

いらねえけど入れれるなら仕方ねえ。喰らえ最新(2026/8/25現在)Ver25.12.5

ストレージ8MBしかねえのにファームウェア7.4MB!大丈夫かこれ。

大丈夫じゃなかった。
空き領域の見た目が60MB近くあるんだけどそんなわけねぇじゃん
Extroot化でメモリを仮想ストレージにしてるらしい。んでgoogle先生に聞きながら実ストレージ確認してたら脅威の250kb
試しにパッケージゴリゴリ入れて再起動してみたら見事に初期化。確実に仮想ストレージだーね。

軽く確認したらv24が7MB、v23が6.4MBなのでv23を導入*1*2
Extroot化が解除され、空きストレージが1.19MiBに。コレで使えるかな…パッケージ導入はまた今度やろう…
ギリギリv24が入れれるかもしれないが、最新Verが入れれない時点でってのもある。
ぶっちゃけこの記事書いてるの、実用するならv23入れましょうねって話したいだけ*3

導入内容はコレと同じ事します。
alchemistark.hatenablog.jp

この記事だとWCR-1166DSでやってるけどスペックがコチラ

■ NEC Aterm WF1200CR
・CPU型番:Qualcomm Atheros QCA9561
・クロック周波数:750 MHz
・RAM:128 MB
・Flash:8 MB

■ バッファロー AirStation WCR-1166DS
・CPU型番:MediaTek MT7628AN
・クロック周波数:580 MHz
・RAM:64 MB
・Flash:16 MB

先生によるとクロックだけでなくアーキテクチャ的にもQCA9561の方が上らしい。
メモリも倍積んでるし、Flash8MBがマジで何なのコイツってなるわ…

*1:そもそもWF1200CRはv22からしか無い

*2:WG1200CRはもっと前からあるので、パッケージがもっと必要な場合は更に下げる事も可能ではあるが、このCPUで何する気だ

*3:WG1200CRもストレージ8MBで同じなので一緒。

Autheliaを触ったのでついでに

Navidromeのクライアントを通過させるように設定した。
これでNavidromeもhttps化して認証かけれる

ルールの上位に以下を追加する。
指定サブドメインのrest以下を接続可能に。*1

    # navidromeクライアントアプリを通過させる
    - domain: 'navidrome.hogehoge.jp'
      resources: '^/rest/.*$'
      policy: bypass


obsidianのCouchDBも同様にアクセス制限を追加。
webクライアントの後ろにdbが置いてある構成。
db名を指定してアクセスしてきてるようなのでそこから先のみアクセス可能にする*2*3

    # obsidianクライアントアプリを通過させる
    - domain: 'ignis.client.web'
      resources:
        - '^/couchdb/(_node|vault_db)/.*$'
        - '^/couchdb/$'
      policy: 'bypass'
    # それ以外のdbパスへのアクセスを拒否
    - domain: 'ignis.client.web'
      resources: '^/couchdb/.*$'
      policy: 'deny'

接続試験でルートディレクトリと_nodeにアクセスするようなので許可
実際の通信はdb名のディレクトリ以下で行われるのでそれらを許可
それ以外のパスは全て拒否 特に_から始まるやつはwebインターフェースだったり色々あるので注意
_sessionは無くても大丈夫っぽい 多分webのログイン情報だけなんじゃないかな

*1:ブラウザから叩くと404なので問題ない はず

*2:セキュリティ的にどうかは知らない

*3:_utilsやらの機能があるパスへアクセスさせなければとりあえず良し