WPP
Joplin-vieweb を試してみる

しばらく前から Evernote の代替として Joplin を使用している。Joplin には公式の Web クライアントが存在していない。会社支給の PC にはアプリをインストールできないので Joplin に書き溜めたメモをみることができないのでちょっとだけ困っていた。

Claude に聞いてみると Joplin-vieweb というサードパーティの Web クライアントがあるらしいのでインストールしてみた。

docker-compose

インストールする環境では、外からのアクセスをさばく nginx がリバースプロキシとして動作しているので、github の docker-compose-joplin-only.yml をベースにいじっていく。どうやらこの .yml だと外からのアクセス用の設定は、含んでいないようだ。

こんな風になった。
ポイントは、enviroment: ORIGINS で http://joplin-vieweb というコンテナ名の項目を追加しているところ。

docker には、内部ネットワークだとコンテナ名で名前解決してくれる機能があるのでそれを利用する。下の例では、network に IP アドレスを固定で割り当てているが、 不要です。

http://MYHOST.local は docker をホストしている PC の mdns ホスト名です。自IP でもかまわない。

version: '3.8'

services:
  joplin-vieweb:
    image: gri38/django-joplin-vieweb:latest
    container_name: joplin-vieweb
    depends_on:
      - joplin-terminal-xapi
    ports:
      - "8001:8000"
    volumes:
      - ./joplin-vieweb-data:/home/joplin
      - joplin:/root/.config/joplin:ro
      - joplin-vieweb:/root/.config/joplin-vieweb
    networks:
      joplin-net:
        ipv4_address: 172.20.0.2
    environment:
      - ORIGINS='http://MYHOST.local', 'http://joplin-vieweb'
      - JOPLIN_LOGIN_REQUIRED=False
    restart: unless-stopped

  joplin-terminal-xapi:
    image: gri38/joplin-terminal-xapi:latest
    container_name: joplin-terminal
    restart: unless-stopped
    volumes:
      - joplin:/root/.config/joplin
  
    networks:
      joplin-net:
        ipv4_address: 172.20.0.3  

volumes:
  joplin:
  joplin-vieweb:

networks:
  joplin-net:
    ipam:
      driver: default
      config:
        - subnet: 172.20.0.0/24

接続と初期設定

参考の公式 GitHub のままだが、

まず docker-compose up で起動して (MYHOST.local は適宜変更してください。)

http://MYHOST.local/admin
で django の管理画面? に入り、パスワード設定、ユーザー追加する

http://MYHOST.local/joplin
で joplin の画面が表示される。

使ってみた感想は、若干使いにくい。緊急時にはいいのかもしれない。これだったらリモートで PC のデスクトップに入ったほうが使い勝手はいいかもしれない。

参考

joplin-vieweb/joplin-vieweb: A web viewer for Joplin app

Rock64 + dietpi に casaOS をインストールしてみた

そろそろ synology NAS をやめようかなと考えている。現在の筐体で3代目だが、「HDD の対応が厳しくなって compatibility list 以外のものでは動かなくなるらしい」。

パッケージされているので楽なのは確かだが、正直にいうと適当なケースにボロい CPU のっけているだけで 5万円前後はするのでなんだかなーとは以前から思っていた。
適当な UI と Portainer があればいいんじゃね? と思い幾星霜。

Synology に限らず QNAP や Asustor、Netgear、UGREEN でも docker 動くものになるとこの位の価格になる。

そこでセルフホスト出来る代替品を探している。

とりあえず、手元で空いている Rock64 にインストールしてみた。

casaOS に行き着く前に Open Media Vault も試してみたが Rock64 + dietpi では自分は安定して稼働させることができなかった。ラズパイや x86 ならまた異なる結果になるのかもしれない。

インストール

インストールは公式のページ通りでOK

curl -fsSL https://get.casaos.io | sudo bash

DATA フォルダを ssd に移動する

casaOS は /DATA を データフォルダする設定のようで、各種アプリのインストール先や、共有ファイルの置き場になっている。

今回インストールした状況では /DATA は sdカード上の別パーティションにマウントされていた。

一方、Rock64 は sd カードに diepi os をいれ boot している。

つまり、ssd にパーティション切って /DATA でマウントすれば casaOS が ssd を使うようになる。

現時点では casaOS のドキュメントはあまり充実していないので discord のアカウントを作ってコミュニティのコンテンツみないとちょっと厳しいかも。

まだ、使って数日だが、様子をみて NAS 専用機から switch しようと思う。

参考

公式: IceWhale のGithub リポジトリ一覧

User Pages | CasaOS Wiki

Linux + OceanAudio でリモートのフォルダを扱うときは CIFS (Samba)を使うほうがいい

さて、これも自分向けメモではあるがきっと数カ月後には忘れているだろうから記録する。

状況

どんな状況かといいうと LM22.1 (Ubuntu 24.04) の Cinnamon デスクトップでリモートの CIFS (Windowsのファイル共有)フォルダをマウントすると gvfs でマウントされる。最近のデスクトップでは同じようなものも多いと思う。

gvfs でマウントすると CIFS でマウントした場合とはパスが異なる。これが原因で gvfs 経由のファイルアクセスには失敗することがある。具体的には

gvfs の例
/run/user/1000/gvfs/smb-share:server=192.168.1.xx,share=datafolder

cifs の例
/mnt/shared/datafolder

こんな感じで “,” や “:” などが意図しない場所に存在するために gvfs を考慮していないアプリだと上手く動作しないことがあるらしい。

要するに fopen() なんかに gvfs のパスをそのまま渡しても単に失敗するのだと推測される。

そんな場合は、素直に mount -t cifs でマウントすればいい。

$ sudo mount -t cifs -o uid=$(id -u),gid=$(id -g),file_mode=0777,dir_mode=0777,username=USER //SERVERl/PATH /mnt/MOUNT

コマンドの以下の部分は、適宜環境に合わせる必要がある

USER: リモートの共有フォルダにアクセスする際のユーザー名

SERVE: リモートの共有フォルダのサーバーアドレス

PATH: 共有フォルダのパス

MOUNT: マウントしたいフォルダ名

ちょっと長いのでスクリプトにしておいたほうがいいと思う。

Rock64 のDietpi 9.15.2 でコンソールが表示されないときの対処方法

Rock64 というラズベリーパイもどきをスモールサーバとして使用しているのですが、そこで動く OS: Dietpi を新たに入れ直したところコンソール画面が表示しない現象が発生しました。

以前のバージョンではこういった現象はおきませんでしたが、インストーラーなんかも少し変わっていたので起動周りでなにか変更があったのかもしれません。

ディスプレイからは信号なしのアラートがでるので、detect を失敗しているかディスプレイが対応していないモードで出力しているのかもしれません。中華製モバイルディスプレイなので何か作りがいい加減なのが根本原因かもしれませんが、真相はわかりません。

dietpi-config でコンソールの解像度(要するに kernel の起動パラメータ)を変更出来るようなのでやってみます。

やってみるとわかるのですが、dietpi-config でリセットしてから再セットする必要があるようです。

  1. sudo dietpi-condig でコンフィグツールを起動
  2. 1. Display Options に入る
  3. 0. DietPi-Display mode and rotation (beta) に入る
    こんな項目は以前なかったと思う。
  4. Reset を選択
  5. <Exit> を選び再起動する
  6. 再起動後、2度目の sudo dietpi-config
  7. 1. Display Options に入る
  8. mode に入り 1024×768 など写りそうなモードを選択する
  9. <Exit> を選び、また再起動

この手順でコンソールを表示するようになった。

まあ、通常は ssh しかしないので画面表示できなくても問題はないが、この手の SBC は初回起動時から ssh 接続まではどうしても画面があったほうがいいので一応対処した。

最近の Raspberry OS だとそこら辺のネットワークを埋め込んで SD に焼けるので初回からディプレイなしでいけるのはいいところ、とは言え画面あったほうが便利ではある。

LM22.1 (Ubuntu 24.04) の Viber で日本語入力できるようにする。

さて、とある取引先と Viber でやり取りをしているのだが、Linux Mint だと日本語入力できなかったので対処したという話。

作業内容からすると ibus をインストールして Viber で認識できるようにしたって感じでしょうか。

環境

  • Linux Mint 22.1 (cinammon)
  • Fcitx + Mozc
  • 公式の viber.AppImage を /opt/viber/ に配置

手順

Claude がわりといい感じで見つけてくれるので早速Claude に聞いてみると

# ダウンロードした AppImage を移動
$ mv viber.AppImage /opt/viber

$ sudo apt install ibus-mozc


$ ibus-setup
# 起動したら Mozc を追加する

# ここで再起動かデスクトップに再ログインしないと ibus がアクティブにならないかも

# 以下を .profile か .bashrc に入れろって指示だったが今回は、起動スクリプトで直接指定した。
# export GTK_IM_MODULE=ibus
# export QT_IM_MODULE=ibus
# export XMODIFIERS=@im=ibus

$ vi /opt/viber/launch.sh
#!/bin/bash
GTK_IM_MODULE=ibus QT_IM_MODULE=ibus XMODIFIERS=@im=ibus /opt/viber/viber.AppImage
:wq

$ chmod 755 /opt/viber/launch.sh

# メニューから起動できるように .desktop を作成
# Ubuntu だと場所や方法が異なるかも
# アイコンは LM の場合は入っていたのでそれを利用、なければ適当に。
$ vi ~/.local/share/applications/viber.desktop
[Desktop Entry]
# Name はお好みで
Name=Viber - AppImage
#Exec=/opt/viber/viber.AppImage
Exec=/opt/viber/launch.sh
Comment=
Terminal=false
PrefersNonDefaultGPU=true
Icon=/opt/assets/viber.svg
Type=Application
:wq

デスクトップのメニューから Viber を起動すると ibus 経由で日本語入力が出来るようになった。

参考

linuxmintでブラウザーでは日本語打てるんですがvIberだと英語… – Yahoo!知恵袋
ibus にしか対応していないという示唆

dietpi の mariadb にローカルからログイン

いつも忘れるのでメモ。

dietpi 公式の mariadb にはルートユーザーは コンソールにログインするときの root ユーザーとそのパスワードとなっているが、通常ユーザで ssh したコンソールでは mariadb -u root -p が動作しない。

$ sudo mariadb
とすることで mariadb のコンソールに接続することができる。

参考

Databases and Data Store Software Options – DietPi.com Docs

WordPress パスワードを強制リセット

これは、ネット上でみるが自分向けのショートカットのためにメモ。

新規で WordPress をインストールしたのだが、ユーザー作成まで完了しました。しかしパスワードマネージャーが生成したパスワードが自動で記憶されていない状態でした。クリップボードにパスワードを保存していません。

悪い事に、メールサーバーの設定も完了していなかったので、メールによるパスワードリセットもできません。

こんな場合は、DB のパスワードを直接書き換える必要があります。

手順

下記の例では、ワードプレスにログインするユーザは、wp とします。適宜変更してください。

# 新パスワードの md5sum ハッシュを取る (-n で改行を取らないとハッシュ値が異なるので注意)
$ echo -n 'newpass' |md5sum
xxxxx

$ mariadb -u ワードプレスDBのユーザーID -p
mariadb > use wordpress;

# ユーザー名等を確認する
mariadb > select id, user_login, user_pass from wp_users; 

# 変更
mariadb > update wp_users set user_pass=''xxxxx" where user_login="wp"

ネット上では、md5sum を取る方法はいろいろ見つかるし、そもそも mariadb の md5() 関数でもできるはず。

NextCloud のデータの場所を変更する方法

さて、Synology NAS の HDD 動作要件が厳しくなって Compatibility List にないドライブでは動作しないように仕様変更されているらしい。いま時点ではたまたま動作している HDD を使っているので問題はないが、いつも適当にいい感じのドライブを買っているだけなのでいちいち気にしなけばいけないのは面倒だ。

5 年以上 NAS を使ってきているがドライブの故障にはでくわしたことがない、それ以前に容量が涸渇してより大きな HDD に買い替えているので RAID である必要もないのかもしれない。

などと考えており、代替策の 1 つとして NextCloud を検証している。

前置きが長くなったが、NextCloud のデータの保存場所を変更する方法をメモ。

環境

OS: Dietpi 9.15.2
NextCloud: 31.0.8

方法

どうやら、NextCloud は、1 つのフォルダに共有ファイルと関連するデータ (DB等) をまとめて管理するらしい。

config.php に datadirectory という項目があるので新しいパスにしてやる。

config.php は、/var/www/nextcloud/config/config.php にあった。(ディストリやインストール方法によって異なるのでこの辺から探してほしい)

<?php
$CONFIG = array (
  'passwordsalt' => 'XSqB+XXXXX',
  'secret' => 'O5PwBJjAkatBYxt876LL9ZA4ibfThOxkpXXXXXX',
  'trusted_domains' => 
  array (
    0 => 'localhost',
1 => '*',
  ),
  // これを変える
  // 'datadirectory' => '/mnt/dietpi_userdata/nextcloud_data',
  'datadirectory' => '/new_path',

  'dbtype' => 'mysql',
  'version' => '31.0.8.1',
'hashingThreads' => 4,
'memcache.local' => '\\OC\\Memcache\\APCu',
'filelocking.enabled' => true,
'memcache.locking' => '\\OC\\Memcache\\Redis',
'redis' => array ('host' => '/run/redis/redis-server.sock', 'port' => 0,),
  'overwrite.cli.url' => 'http://localhost/nextcloud',
  'dbname' => 'nextcloud',
  'dbhost' => 'localhost',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'oc_admin',
  'dbpassword' => 'cCD^4wy2Z&EpN]/w(GnQc_pq9h7TZy',
  'installed' => true,
  'instanceid' => 'ocmwukkz4mzw',
);

それだけだとデータが何もないので、もともとのデータディレクトリからデータをコピーし、chown をして所有者を調整する必要がある。

# ここでは例として /new_path にデータディレクトリを設定する
$ sudo cp -r /mnt/dietpi_userdata/nextcloud_data /new_path


# nextcloud が使うユーザに所有権を設定。(ディストリビューションなどにより実際のユーザー名、グループ名は合わせてほしい)
$ sudo chown -R www-data: /new_path

これでNextCloud が新しいフォルダを使うようになる。

NextCloud だとWeb やアプリ経由でのファイル共有は、ほぼ NAS と遜色ない。開発ペースの速さやアプリの多さはむしろ勝っているかもしれない。ここに Portainer を追加してコンテナを動かすようにすればいい感じになるかも。

が、Samba と macOS のAFP で行うローカルのファイル共有プロトコルを別管理しなければいけないのはちょっと面倒だということに改めて気付かされた。

ラズベリーパイの RUSTDESK をヘッドレスで使う

ちょっとYAMAHA ルーターの実験をするのに、LAN の向こう側約として Raspberry PI を使っていました。

それはどうでもいいのですが、RUSTDESK をインストールし vnc をアンインストールすると、RUSTDESK で接続できなくなってしまいました。

RUSTDESK に限らず、Linux で動くリモートデスクトップ系のアプリにはよくあるのですが自分が起動したときにデスクトップ環境のディスプレイが存在しないと接続に失敗してそのまま終わるという現象ですね。

VNC の場合も基本同じ設定でいけますがラズパイの場合、インストーラと raspi-config がよしなにしてくるのでこの設定は必要ない。

参考の von的部落格 でも Wayland から X11 に変更してが、たまたまそうなっていたのでそこはスルーする。

lightdm は使っていないのでここもスルー。

dummy ビデオドライバ?をインストールする。

$ sudo apt install xserver-xorg-video-dummy

; ダミーの xorg.conf を作成する
$ sudo /etc/X11/xorg.conf.d/xorg.conf 

ファイルの中身は以下のようにした。von的部落格 のサイトではもっと多くの解像度が定義されていたがうちにはそんな大きなモニタはないので外している。

Section "ServerFlags"
  Option "DontVTSwitch" "true"
  Option "AllowMouseOpenFail" "true"
  Option "PciForceNone" "true"
  Option "AutoEnableDevices" "false"
  Option "AutoAddDevices" "false"
  Option "IgnoreABI" "true"
EndSection

Section "InputDevice"
  Identifier "virtual_mouse"
  Option "CorePointer" "true"
  Driver "void"
EndSection

Section "InputDevice"
  Identifier "virtual_keyboard"
  Option "CoreKeyboard" "true"
  Driver "void"
EndSection

Section "Device"
  Identifier "virtual_videocard"
  Driver "dummy"
  VideoRam 192000
EndSection

Section "Monitor"
  Identifier "virtual_monitor"
  HorizSync   5.0 - 2000.0
  VertRefresh 5.0 - 200.0
  Modeline "1920x1440" 69.47 1920 1960 2152 2384 1440 1441 1444 1457
  Modeline "1920x1080" 23.53 1920 1952 2040 2072 1080 1106 1108 1135
  Modeline "1600x1200" 22.04 1600 1632 1712 1744 1200 1229 1231 1261
  Modeline "1440x900" 30.66 1440 1472 1584 1616 900 921 924 946
  Modeline "1280x1024" 31.50 1280 1312 1424 1456 1024 1048 1052 1076
  Modeline "1280x800" 24.15 1280 1312 1400 1432 800 819 822 841
  Modeline "1024x768" 18.71 1024 1056 1120 1152 768 786 789 807
EndSection

Section "Screen"
  Identifier "virtual_screen"
  Device "virtual_videocard"
  Monitor "virtual_monitor"
  SubSection "Display"
    Depth 24
    Modes "1920x1440" "1920x1080" "1600x1200" "1440x900" "1280x1024" "1366x768" "1280x800" "1024x768" "800x600" 
  EndSubSection
EndSection

Section "ServerLayout"
  Identifier   "virtual_layout"
  Screen       "virtual_screen"
  InputDevice  "virtual_mouse"
  InputDevice  "virtual_keyboard"
EndSection

RUSTDESK を初めてヘッドレスにする際は以下も必要になる。

$ sudo rustdesk --option allow-linux-headless Y
$ sudo rustdesk --get-id
$ sudo rustdeskt --password XXXXXX

rustdesk はデフォルトだと接続先の画面に表示されている接続ID とワンタイムパスワードをみながら接続する必要があるが、当然ヘッドレスだとそれができないので接続ID を取得して、固定パスワードに変更している。

$ DISPLAY=:0 xrandr --output DUMMY0 --mode 1024x768

は今回は必要なかったが、解像度変えたいときは使用すればいいってことか?

以上で無事接続できた。ディスプレイがなくても接続できる nomachine のほうがやっぱりかんたんかも。

参考

用RustDesk連線到headless的樹莓派Linux伺服器 · Ivon的部落格
中国語でしんどい、けど基本コピペでいけた

no display? · rustdesk/rustdesk · Discussion #1615 · GitHub

synology の openVPN に Linux MINT から接続する

synology の NAS には VPN サーバ機能があり openVPN 接続に対応している。

Linux MINT (22.1)を使った家の環境では openVPN 接続を追加する際、デフォルトの設定のままでは接続できなかった。試行錯誤して接続できたので設定画面をメモする。

設定アプリのネットワーク のキャプチャをメモしておく。

openVPN を設定した項目で ギアマークをクリックすると、ダイアログが開く。
Details タブはなにもないのでスルー。

Identity タブ から Advanced… ボタンをクリックする。

Advanced Properties ダイアログの General タブはこんな感じ。多分になにも変えていない。

Security タブは、synology の openVPN と合わせる。

TLS Authentication タブは、 Verify peer (server) certificate usage signature にチェックをいれ Server を選択する。これをしないとネゴシエーションに失敗するようで接続することができない。

再設定する際に、きっと忘れてしまうので記録しておく。