smbgetのパスワード指定

sambaの速度を測るのにsambaをwgetのように使える smbget を使おうとしたのですが以前使えていた気がする -p オプションが無くなっています.

$ bash -c "read -sp \"passwd: \" passwd; smbget smb://smbhost/share/data -U user -p $passwd -O > /dev/null"
passwd: -p: unknown option

usageを見ると確かにありません.

$ smbget --usage
Usage: smbget [-?aneruRODqv] [-?|--help] [--usage] [-w|--workgroup=STRING] [-U|--user=STRING] [-a|--guest] [-n|--nonprompt] [-d|--debuglevel=INT] [-e|--encrypt]
        [-r|--resume] [-u|--update] [-R|--recursive] [-b|--blocksize=INT] [-o|--outputfile=STRING] [-O|--stdout] [-D|--dots] [-q|--quiet] [-v|--verbose]
        [-f|--rcfile=STRING]

-pを無くせばプロンプトが出てきますが毎回入力するのは面倒なのでどうにか出来ないかなとmanを見てみます.

man smbget
       -U, --user=username[%password]
           Username (and password) to use

-U オプションに一緒に書けるようです.デミリタは要らないよう.

$ bash -c "read -sp \"passwd: \" passwd; smbget smb://smbhost/share/data -U user$passwd -O > /dev/null"

デミリタに : を指定しても動きました.

$ bash -c "read -sp \"passwd: \" passwd; smbget smb://smbhost/share/data -U user:$passwd -O > /dev/null"

他にもSMB URLにも書けるようです.

man smbget
SMB URLS
       SMB URL's should be specified in the following format:

           smb://[[[domain;]user[:password@]]server[/share[/path[/file]]]]

ただし,この書き方だとSMB URLが環境変数が展開されてSTDOUTに表示されるのでパスワードを隠したい場合は使えません.

$ bash -c "read -sp \"passwd: \" passwd; smbget smb://user:$passwd@smbhost/share/data -O > /dev/null"
smb://user:password@smbhost/share/data(100.00%) at 130.69MB/s ETA: 00:00:0008
Downloaded 2.17GB in 17 seconds

それを言うと -U の場合もプロセスにパスワードが表示されてしまうのであまりよろしくないですね.てことでとりあえずこんな感じならいいかな?

$ bash -c "read -sp \"passwd: \" passwd; echo $passwd | smbget smb://smbhost/share/data -U user -O > /dev/null"

このときのプロセス

$ ps -ef|grep smbget
mk       12626 14620  0 22:38 pts/6    00:00:00 bash -c read -sp "passwd: " passwd; echo $passwd | smbget smb://smbhost/share/data -U user -O > /dev/null
mk       13263 12626 49 22:39 pts/6    00:00:00 smbget smb://smbhost/share/data -U user -O

あれ?結局最初に戻って…….

余録(キャッシュクリア)

速度を測りたいけど2回目以降はキャッシュされてしまうのでキャッシュをクリアして測る.
以下はlocalhostで試してるので差が出ているが,ネットワーク経由だとネットワークがボトルネックになり差が出なかった.でも一応やっておく.

1回目
smb://smbhost/share/data(100.00%) at 28.12MB/s ETA: 00:00:00434
Downloaded 2.17GB in 79 seconds
2回目
smb://smbhost/share/data(100.00%) at 130.69MB/s ETA: 00:00:0008
Downloaded 2.17GB in 17 seconds
キャッシュをクリア
$ sudo sh -c "sync; echo 3 > /proc/sys/vm/drop_caches"
もう一回
smb://smbhost/share/data(100.00%) at 27.43MB/s ETA: 00:00:0044
Downloaded 2.17GB in 81 seconds

/proc/sys/vm/drop_caches についてはKernel Documentsの admin-guide/sysctl/vm.rst.gz あたりを参照のこと.

$ zgrep ^drop_caches -A42 /usr/share/doc/linux-doc-5.3/Documentation/admin-guide/sysctl/vm.rst.gz

環境

環境1
$ dpkg-query -W samba smbclient bash
bash    4.4.18-2ubuntu1.2
samba   2:4.7.6+dfsg~ubuntu-0ubuntu2.14
smbclient       2:4.7.6+dfsg~ubuntu-0ubuntu2.14
$ lsb_release -dr
Description:    Ubuntu 18.04.3 LTS
Release:        18.04
$ uname -rvm
4.15.0-72-generic #81-Ubuntu SMP Tue Nov 26 12:20:02 UTC 2019 x86_64
環境2
$ dpkg-query -W samba smbclient bash
bash    5.0-5
samba   2:4.11.1+dfsg-3
smbclient       2:4.11.1+dfsg-3
$ lsb_release -dr
Description:    Debian GNU/Linux bullseye/sid
Release:        unstable
$ uname -rvm
5.3.0-3-amd64 #1 SMP Debian 5.3.15-1 (2019-12-07) x86_64

Microsoft Teams の Linux版を少し試す

Microsoft Teams の Linux版パブリックプレビューが利用できるようになっています.
普段Microsoft Teamsは利用していないのですが少し試してみました.

以下のページより入手できます.amd64のDEB, RPMが用意されています.今回はDebian sid amd64で試しました.
(armhs, arm64 や snap, AppImageなんかがあると便利そう)

容量やhashはこんな感じでした.

$ ls -l ~/Downloads/teams_1.2.00.32451_amd64.deb
-rw-r--r-- 1 matoken matoken 64874490 Dec 11 19:16 /home/matoken/Downloads/teams_1.2.00.32451_amd64.deb
$ sha512sum ~/Downloads/teams_1.2.00.32451_amd64.deb
2e921c0ebd2306b6f61f5ecd448206922394a19339e8c14023aa1778444a649bf4730c71362263e53bb833caed05907203d782221429e853d76695695835e407  /home/matoken/Downloads/teams_1.2.00.32451_amd64.deb
$ sha256sum ~/Downloads/teams_1.2.00.32451_amd64.deb
28d8a0e644a4bb9d4ee9295953b97b7fa6558b8a9d1d28363a594f5cde1c05dc  /home/matoken/Downloads/teams_1.2.00.32451_amd64.deb

こんな感じで導入.

$ sudo dpkg -i ~/Downloads/teams_1.2.00.32451_amd64.deb

導入時の容量は233.5MB程.

$ dpkg-query -s teams|egrep 'Size|Version'
Installed-Size: 233488
Version: 1.2.00.32451

teams コマンドで起動します.

環境変数 LC_ALLja_JP.UTF-8 とかにしておくとログイン画面等は日本語になります.しかしログイン後は英語に.
設定で日本語を選んで再起動で日本語になりました.

プロセスはこんな感じ.Electronぽいですね.

$ ps aux|grep -i teams
matoken 2994658 1.0 1.1 2993376 180704 ? Sl 19:29 0:13 /usr/share/teams/teams
matoken 2994660 0.0 0.2 201364 40000 ? S 19:29 0:00 /usr/share/teams/teams --type=zygote --no-sandbox
matoken 2994722 0.0 0.5 769764 94808 ? Sl 19:29 0:01 /usr/share/teams/teams --type=gpu-process --enable-features=SharedArrayBuffer --disable-features=SpareRendererForSitePerProcess --gpu-preferences=KAAAAAAAAACAAABAAQAAAAAAAAAAAGAAAAAAAAAAAAAIAAAAAAAAAAgAAAAAAAAA --service-request-channel-token=15734132888989265996
matoken 2994776 0.0 0.5 1342416 90296 ? Sl 19:29 0:00 /usr/share/teams/teams --type=renderer --autoplay-policy=no-user-gesture-required --enable-features=SharedArrayBuffer --disable-features=SpareRendererForSitePerProcess --service-pipe-token=18244068696510772569 --lang=ja --app-path=/usr/share/teams/resources/app.asar --user-agent=Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) MicrosoftTeams-Preview/1.2.00.32451 Chrome/69.0.3497.128 Electron/4.2.12 Safari/537.36 --node-integration=false --webview-tag=false --no-sandbox --preload=/usr/share/teams/resources/app.asar/lib/renderer/notifications/preload_notifications.js --disable-remote-module --background-color=#fff --electron-shared-settings=eyJjci5jb21wYW55IjoiRWxlY3Ryb24iLCJjci5kdW1wcyI6IiIsImNyLmVuYWJsZWQiOmZhbHNlLCJjci5wcm9kdWN0IjoiRWxlY3Ryb24iLCJjci5zZXNzaW9uIjoiIiwiY3IudXJsIjoiIiwiY3IudmVyc2lvbiI6InY0LjIuMTIifQ== --num-raster-threads=2 --enable-main-frame-before-activation --service-request-channel-token=18244068696510772569 --renderer-client-id=7 --shared-files=v8_context_snapshot_data:100,v8_natives_data:101 --msteams-process-type=notificationsManager
matoken 2994835 1.3 2.5 2363516 408984 ? Sl 19:29 0:17 /usr/share/teams/teams --type=renderer --autoplay-policy=no-user-gesture-required --enable-features=SharedArrayBuffer --disable-features=SpareRendererForSitePerProcess --service-pipe-token=15065448036180024072 --lang=ja --app-path=/usr/share/teams/resources/app.asar --user-agent=Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) MicrosoftTeams-Preview/1.2.00.32451 Chrome/69.0.3497.128 Electron/4.2.12 Safari/537.36 --node-integration=false --webview-tag=true --no-sandbox --preload=/usr/share/teams/resources/app.asar/lib/renderer/preload.js --disable-remote-module --background-color=#fff --electron-shared-settings=eyJjci5jb21wYW55IjoiRWxlY3Ryb24iLCJjci5kdW1wcyI6IiIsImNyLmVuYWJsZWQiOmZhbHNlLCJjci5wcm9kdWN0IjoiRWxlY3Ryb24iLCJjci5zZXNzaW9uIjoiIiwiY3IudXJsIjoiIiwiY3IudmVyc2lvbiI6InY0LjIuMTIifQ== --num-raster-threads=2 --enable-main-frame-before-activation --service-request-channel-token=15065448036180024072 --renderer-client-id=9 --shared-files=v8_context_snapshot_data:100,v8_natives_data:101 --msteams-process-type=mainWindow
matoken 2995068 0.2 0.6 3034988 109684 ? Sl 19:29 0:03 /usr/share/teams/teams --type=renderer --autoplay-policy=no-user-gesture-required --enable-features=SharedArrayBuffer --disable-features=SpareRendererForSitePerProcess --service-pipe-token=5738606405228482904 --lang=ja --app-path=/usr/share/teams/resources/app.asar --user-agent=Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) MicrosoftTeams-Preview/1.2.00.32451 Chrome/69.0.3497.128 Electron/4.2.12 Safari/537.36 --node-integration=false --webview-tag=false --no-sandbox --preload=/usr/share/teams/resources/app.asar/lib/pluginhost/preload.js --disable-remote-module --background-color=#fff --electron-shared-settings=eyJjci5jb21wYW55IjoiRWxlY3Ryb24iLCJjci5kdW1wcyI6IiIsImNyLmVuYWJsZWQiOmZhbHNlLCJjci5wcm9kdWN0IjoiRWxlY3Ryb24iLCJjci5zZXNzaW9uIjoiIiwiY3IudXJsIjoiIiwiY3IudmVyc2lvbiI6InY0LjIuMTIifQ== --num-raster-threads=2 --enable-main-frame-before-activation --service-request-channel-token=5738606405228482904 --renderer-client-id=14 --shared-files=v8_context_snapshot_data:100,v8_natives_data:101 --msteams-process-type=pluginHost

一人だけの新規作成したばかりのMicrosoft Teams for freeでのRAM使用量はこんな感じ.800MB以上食ってるみたいですね.

$ ps alx | grep teams | grep -v grep | awk '{printf ("%d\t%s\n", $8,$13)}'
145004  /usr/share/teams/teams
19160   /usr/share/teams/teams
67576   /usr/share/teams/teams
56808   /usr/share/teams/teams
487572  /usr/share/teams/teams
62344   /usr/share/teams/teams
$ ps alx | grep teams | grep -v grep | awk '{sum+=$8}END{print sum}'
834392

てことでElectronだと結構リソース食うしブラウザ版とそう変わらないのでブラウザ版でいいかな?

パッケージ削除

$ sudo apt purge teams
環境
$ dpkg-query -W teams
teams   1.2.00.32451
$ lsb_release -dr
Description:    Debian GNU/Linux bullseye/sid
Release:        unstable
$ uname -m
x86_64

速度や容量の偽装されたフラッシュストレージの確認ができるf3(Fight Flash Fraud)を少し試す

近年はフラッシュストレージの偽物が多く出回っています。速度を偽るものや容量を偽るものなどがあり、速度はともかく容量を偽られるとデータが壊れてしまい困ります。
このようなストレージのテストにWindowsでは H2testw というツールが定番のようですが、Linuxでは無いだろうかと探すとそのままH2testw代替というf3(Fight Flash Fraud)を見つけたので少し試してみました。

Debian sid amd64環境では f3 というパッケージでした。

$ apt show f3
Package: f3
Version: 7.2-1
Priority: optional
Section: utils
Maintainer: Antoine Beaupré <anarcat@debian.org>
Installed-Size: 183 kB
Depends: libc6 (>= 2.28), libparted2 (>= 3.1), libudev1 (>= 183)
Homepage: http://oss.digirati.com.br/f3
Download-Size: 47.3 kB
APT-Manual-Installed: yes
APT-Sources: http://ftp.jp.debian.org/debian sid/main amd64 Packages
Description: test real flash memory capacity
 F3 (Fight Flash Fraud or Fight Fake Flash) tests the full capacity of a
 flash card (flash drive, flash disk, pendrive).
 .
 F3 writes to the card and then checks if can read it. It will assure you
 have not been bought a card with a smaller capacity than stated. Note that
 the main goal of F3 is not to fix your removable media. However, there
 are resources to mark the invalid areas.
 .
 This package provides these executables: f3write, f3read, f3brew, f3fix
 and f3probe.

$ sudo apt install f3
$ dpkg -L f3| grep \/bin\/
/usr/bin/f3brew
/usr/bin/f3fix
/usr/bin/f3probe
/usr/bin/f3read
/usr/bin/f3write

先ずは書き込みテストコマンドの f3write を試します。これは該当ストレージをマウントした状態で、マウントポイントを指定します。

$ time f3write /media/matoken/A2BA-98E0
F3 write 7.2
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.

Free space: 29.80 GB
Creating file 1.h2w ... OK!
Creating file 2.h2w ... OK!
Creating file 3.h2w ... OK!
Creating file 4.h2w ... OK!
Creating file 5.h2w ... OK!
Creating file 6.h2w ... OK!
Creating file 7.h2w ... OK!
Creating file 8.h2w ... OK!
Creating file 9.h2w ... OK!
Creating file 10.h2w ... OK!
Creating file 11.h2w ... OK!
Creating file 12.h2w ... OK!
Creating file 13.h2w ... OK!
Creating file 14.h2w ... OK!
Creating file 15.h2w ... OK!
Creating file 16.h2w ... OK!
Creating file 17.h2w ... OK!
Creating file 18.h2w ... OK!
Creating file 19.h2w ... OK!
Creating file 20.h2w ... OK!
Creating file 21.h2w ... OK!
Creating file 22.h2w ... OK!
Creating file 23.h2w ... OK!
Creating file 24.h2w ... OK!
Creating file 25.h2w ... OK!
Creating file 26.h2w ... OK!
Creating file 27.h2w ... OK!
Creating file 28.h2w ... OK!
Creating file 29.h2w ... OK!
Creating file 30.h2w ... OK!
Free space: 0.00 Byte
Average writing speed: 7.43 MB/s

real    68m29.007s
user    0m7.454s
sys     0m51.266s

次に読み込みテストコマンドの f3read を試します。

$ time f3read /media/matoken/A2BA-98E0
F3 read 7.2
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.

                  SECTORS      ok/corrupted/changed/overwritten
Validating file 1.h2w ... 2097152/        0/      0/      0
Validating file 2.h2w ... 2097152/        0/      0/      0
Validating file 3.h2w ... 2097152/        0/      0/      0
Validating file 4.h2w ... 2097152/        0/      0/      0
Validating file 5.h2w ... 2097152/        0/      0/      0
Validating file 6.h2w ... 2097152/        0/      0/      0
Validating file 7.h2w ... 2097152/        0/      0/      0
Validating file 8.h2w ... 2097152/        0/      0/      0
Validating file 9.h2w ... 2097152/        0/      0/      0
Validating file 10.h2w ... 2097152/        0/      0/      0
Validating file 11.h2w ... 2097152/        0/      0/      0
Validating file 12.h2w ... 2097152/        0/      0/      0
Validating file 13.h2w ... 2097152/        0/      0/      0
Validating file 14.h2w ... 2097152/        0/      0/      0
Validating file 15.h2w ... 2097152/        0/      0/      0
Validating file 16.h2w ... 2097152/        0/      0/      0
Validating file 17.h2w ... 2097152/        0/      0/      0
Validating file 18.h2w ... 2097152/        0/      0/      0
Validating file 19.h2w ... 2097152/        0/      0/      0
Validating file 20.h2w ... 2097152/        0/      0/      0
Validating file 21.h2w ... 2097152/        0/      0/      0
Validating file 22.h2w ... 2097152/        0/      0/      0
Validating file 23.h2w ... 2097152/        0/      0/      0
Validating file 24.h2w ... 2097152/        0/      0/      0
Validating file 25.h2w ... 2097152/        0/      0/      0
Validating file 26.h2w ... 2097152/        0/      0/      0
Validating file 27.h2w ... 2097152/        0/      0/      0
Validating file 28.h2w ... 2097152/        0/      0/      0
Validating file 29.h2w ... 2097152/        0/      0/      0
Validating file 30.h2w ... 1671296/        0/      0/      0

  Data OK: 29.80 GB (62488704 sectors)
Data LOST: 0.00 Byte (0 sectors)
               Corrupted: 0.00 Byte (0 sectors)
        Slightly changed: 0.00 Byte (0 sectors)
             Overwritten: 0.00 Byte (0 sectors)
Average reading speed: 19.53 MB/s

real    26m7.658s
user    0m15.443s
sys     0m16.790s

そして本命の f3probe で全領域にデータを書き込んでベリファイして実際に表示される容量が利用できるかを確認します。実行にはroot権限が必要でアンマウントした状態で該当デバイスを指定します。 ※ストレージ内のデータは破壊されます。

$ time sudo f3probe /dev/mmcblk0
F3 probe 7.2
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.

WARNING: Probing normally takes from a few seconds to 15 minutes, but
         it can take longer. Please be patient.

Probe finished, recovering blocks... Done

Good news: The device `/dev/mmcblk0' is the real thing

Device geometry:
                 *Usable* size: 29.81 GB (62521344 blocks)
                Announced size: 29.81 GB (62521344 blocks)
                        Module: 32.00 GB (2^35 Bytes)
        Approximate cache size: 0.00 Byte (0 blocks), need-reset=no
           Physical block size: 512.00 Byte (2^9 Bytes)

Probe time: 4'01"

real    9m4.350s
user    0m0.887s
sys     0m1.602s

こちらはクイックテスト。通常テストが9分ちょっと掛かったのに対しこちらは2分ちょっとで終わっています。

$ time sudo f3probe --destructive --time-ops /dev/mmcblk0
F3 probe 7.2
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.

WARNING: Probing normally takes from a few seconds to 15 minutes, but
         it can take longer. Please be patient.

Good news: The device `/dev/mmcblk0' is the real thing

Device geometry:
                 *Usable* size: 29.81 GB (62521344 blocks)
                Announced size: 29.81 GB (62521344 blocks)
                        Module: 32.00 GB (2^35 Bytes)
        Approximate cache size: 0.00 Byte (0 blocks), need-reset=no
           Physical block size: 512.00 Byte (2^9 Bytes)

Probe time: 2'16"
 Operation: total time / count = avg time
      Read: 393.4ms / 4815 = 81us
     Write: 2'15" / 4192321 = 32us
     Reset: 0us / 1 = 0us

real    2m16.479s
user    0m0.612s
sys     0m0.320s

もし、容量を偽ったストレージを利用したい場合、f3probe コマンドの結果から f3fix コマンドで実際の容量までしか利用しないよう設定することが可能らしいです。(未確認)

$ sudo f3fix --last-sec=16477878 /dev/mmcblk0

add)
その後優先度を上げてみるとどうだろうと sudo nice -20 ionice -c1 -n0 を付けて試してみましたがほとんど速度は変わらず誤差レベルな感じでした。

て事で今回のカードはSamsung の高耐久モデルのMB-MJ32GA/EC だったのですが,容量は問題なし.ただ速度が読み込み最大100MB/sに対して20.03MB/s,書き込み30MB/sに対して10.11MB/sとかなり遅そうです.更にRaspberry Pi との相性が悪いらしく,Raspberry Pi Zero/ZeroW/A+ で起動に失敗します.Amazonで買ったので返品しようかと…….

おまけ。

f3-qt というGUIの皮もあるようです。これも少し試してみました。

パッケージが見当たらないのでbuildしました。

$ sudo apt install libudev1 libudev-dev libparted-dev
$ git clone https://github.com/zwpwjwtz/f3-qt
$ cd f3-qt
$ qmake
$ make
マウントポイントを指定して速度テスト。

f3 qt 20191118 07:11:24 1566360

歯車アイコンを押してadvanceテスト。

f3 qt 20191118 09:11:29 1693359

環境
$ dpkg-query -W f3 libudev1 libudev-dev libparted-dev
f3      7.2-1
libparted-dev:amd64     3.3-1
libudev-dev:amd64       243-7
libudev1:amd64  243-7
libudev1:i386   243-7
$ lsb_release -dr
Description:    Debian GNU/Linux bullseye/sid
Release:        unstable
$ uname -m
x86_64

Debian sidでChromiumが更新されないのでsnap版を試す

以下の記事は一昨日(2019-11-04)やっていたことで昨夜(2019-11-05)updateを確認したら降りてきていました :)

$ /usr/bin/chromium --version
Chromium 78.0.3904.87 built on Debian bullseye/sid, running on Debian bullseye/sid

Debian sid amd64 で Chromium がなかなか更新されないのでとりあえずsnap版を入れてみました。

snapd未導入なら導入。

$ sudo apt install snapd

検索して、

$ snap find chromium
Name                      Version       Publisher    Notes  Summary
chromium                  78.0.3904.70  canonical✓   -      Chromium web browser, open-source version of Chrome
chromium-ffmpeg           0.1           canonical✓   -      FFmpeg codecs (free and proprietary) for use by third-party browser snaps
restart-chromium          1             mgibbs-dfrs  -      Restart Browser
dashkiosk-client-browser  0.1           ogra         -      Chromium in Kiosk mode specifically adjusted for dashkiosk
boxy-svg                  3.29.0        jarek-foksa  -      Scalable Vector Graphics (SVG) editor
chromium-ffmpeg-test      0.1           osomon       -      Test snap that exercises the slots exposed by chromium-ffmpeg

導入。

$ sudo snap install chromium chromium-ffmpeg
$ snap list|grep chromium
chromium 78.0.3904.70 920 stable canonical* -
chromium-ffmpeg 0.1 15 stable canonical* -
$ dpkg-query -W chromium
chromium 76.0.3809.100-1

/snap/bin/chromium に入るのでそちらのパスを /usr/bin より優先して通しておく。

例えばbashだと ~/.bash_profile などで /usr/bin の設定のあとに以下の設定を書いておく。

if [ -d "/snap/bin" ] ; then
    PATH="/snap/bin:$PATH"
fi

パスが通っているのを確認する。

$ chromium --version
Chromium 78.0.3904.70 snap
$ /usr/bin/chromium --version
Chromium 76.0.3809.100 built on Debian bullseye/sid, running on Debian bullseye/sid

ちなみに今回の環境はamd64でしたが、他にi386, arm64, armhf もあるようです。

chromium snap01

今回の状態はメンテナが動けない状態なのかな?

環境
$ snap list|grep chromium
chromium 78.0.3904.70 920 stable canonical* -
chromium-ffmpeg 0.1 15 stable canonical* -
$ dpkg-query -W chromium snapd
chromium 76.0.3809.100-1
snapd   2.40-1
$ lsb_release -dr
Description:    Debian GNU/Linux bullseye/sid
Release:        unstable
$ uname -m
x86_64

Btrfsのbtrfs-transactionでioが100%になって困る

デスクトップ検索のRecollを試してみようと recollindex コマンドでindexを作ってみました.すると様々なアプリケーションがフリーズ.indexが出来るまでの辛抱だろうと1日ほど放置してみましたが解消しません.
1つのコマンドを発行して実行されるまで何分も掛かってしまいます.

cpuやmemoryはガラガラです.
iotop を叩いてみると btrfs-transaction がほぼ100%で張り付いています.

マウントオプションはこんな感じ.

$ mount | grep \ /\
/dev/mapper/t430s--vg-root on / type btrfs (rw,noatime,nodiratime,ssd,discard,space_cache,subvolid=5,subvol=/)

discard を `btrfs(5) ` で確認するとちょっと怪しいような?

       discard, nodiscard
           (default: off)

           Enable discarding of freed file blocks. This is useful for SSD devices, thinly provisioned LUNs, or virtual machine images; however, every storage layer must
           support discard for it to work. if the backing device does not support asynchronous queued TRIM, then this operation can severely degrade performance, because a
           synchronous TRIM operation will be attempted instead. Queued TRIM requires newer than SATA revision 3.1 chipsets and devices.

       If it is not necessary to immediately discard freed blocks, then the fstrim tool can be used to discard all free blocks in a batch. Scheduling a TRIM during a period
       of low system activity will prevent latent interference with the performance of other operations. Also, a device may ignore the TRIM command if the range is too
       small, so running a batch discard has a greater probability of actually discarding the blocks.

       If discarding is not necessary to be done at the block freeing time, there’s fstrim(8) tool that lets the filesystem discard all free blocks in a batch, possibly not
       much interfering with other operations. Also, the device may ignore the TRIM command if the range is too small, so running the batch discard can actually discard the
       blocks.

SATAのバージョンを確認すると 3.2 なので問題無さそう?

$ sudo smartctl --info /dev/sda | grep ^SATA
SATA Version is:  SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s)

でも一旦無効にしてみます.
#ついでに付けた compress=lzo は別でやるべきだった…….

$ time sudo mount -o remount,rw,noatime,nodiratime,ssd,nodiscard,compress=lzo,space_cache /
real    42m32.840s
user    0m0.014s
sys     0m15.209s
$ mount | grep \ /\
/dev/mapper/t430s--vg-root on / type btrfs (rw,noatime,nodiratime,compress=lzo,ssd,space_cache,subvolid=5,subvol=/)

これが当たりだったようでioは一気に空きました!
SATA 3.2 だけど何か別の条件が良くないのでしょうか?

忘れないうちに fstab も修正しておきます.(nodiscard は既定値なので書いていない)

 sudo git -C /etc diff HEAD^ -- /etc/fstab
diff --git a/fstab b/fstab
index b029749..386278f 100644
--- a/fstab
+++ b/fstab
@@ -5,7 +5,7 @@
 # that works even if disks are added and removed. See fstab(5).
 #
 # <file system> <mount point>   <type>  <options>       <dump>  <pass>
-/dev/mapper/t430s--vg-root /               btrfs   noatime,nodiratime,ssd,discard,space_cache 0       0
+/dev/mapper/t430s--vg-root /               btrfs   noatime,nodiratime,ssd,compress=lzo,space_cache 0       0
 # /boot was on /dev/sda2 during installation
 UUID=cba2591a-12da-481e-b239-c002faca22e1 /boot           ext2    defaults        0       2
 # /boot/efi was on /dev/sda1 during installation

これで暫く様子を見てみます.
問題なければ別途TRIMを設定したほうがいいかな?

環境

$ dpkg-query -W btrfs-progs iotop smartmontools
btrfs-progs     5.2.1-1
iotop   0.6-24-g733f3f8-1
smartmontools   7.0-2
$ sudo smartctl -i /dev/sda | grep -E '^Device Model:|Firmware Version:|SATA Version is:'
Device Model:     Seagate BarraCuda SSD ZA1000CM10002
Firmware Version: STAS1024
SATA Version is:  SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s)
$ lsb_release -dr
Description:    Debian GNU/Linux bullseye/sid
Release:        unstable
$ uname -m
x86_64

Google PhotoにHEIC形式でアップロードして16MP制限を回避する

※このエントリを書いてるうちにHEIC形式のファイルが縮小されないのはバグだという記事がでてきました.そのうち修正されてこの回避方法は使えなくなるはずです.

Google Photoの設定でアップロードサイズを「高画質」にしておくと16MPを超えるサイズの画像は16MPに縮小されますが容量を気にせず無制限でアップロードできます.
最近iPhoneの写真は16MPを越えていても無制限にアップロードできると話題になりました.これはiPhoneの写真はHEIF形式で保存され,これを16MPにするためにデコード&エンコードすると元の画像より大きくなるのでそのままにしているのではないかと言われたりしています.

この理由が正しいのであればiPhoneでなくともHEIF形式に変換してアップロードした画像はオリジナルサイズで保存されるではないかと試してみました.

先ず手持ちのカメラ(Pentax K-5)でRAW撮影して現像したファイルを確認してみます.

$ identify ./H-IIBF8_HTV8.TIFF
./H-IIBF8_HTV8.TIFF TIFF 4942x3276 4942x3276+0+0 16-bit sRGB 73.7626MiB 0.000u 0:00.000
$ echo $(($(identify -format "%w*%h" ./H-IIBF8_HTV8.TIFF)))
16189992

4942 x 3276 = 16189992ピクセルで制限の16MPを少し超えていそうです.
2**20*16 = 16777216 よりは小さい(MiP?)

この画像をアップロードしてみます.アップロードにはgpupを使いました.

$ gpup ./H-IIBF8_HTV8.TIFF

アップロードしたファイルの情報を見るとこうなっていました.16.2MPで縮小されていないようです.

H-IIBF8_HTV8.TIFF
16.2 MP
4942 × 3276
77.3 MB

念の為設定を確認.

設定画面( https://photos.google.com/settings )にアクセスして,「高画質 (容量制限なし、無料)」にチェックが入っているのを確認します.

問題ないようです.

ちなみに,「元のサイズ」に設定した状態でアップロードした動画を「容量を解放」することで16MPに変換してGoogleドライブの容量を解放することも可能です.

HEICとJPEGも同様にアップロードしてみます.

$ convert ./H-IIBF8_HTV8.TIFF ./H-IIBF8_HTV8.heic
$ convert ./H-IIBF8_HTV8.TIFF ./H-IIBF8_HTV8.jpg
$ ls -1HSs ./H-IIBF8_HTV8.*
75536 ./H-IIBF8_HTV8.TIFF
 2632 ./H-IIBF8_HTV8.jpg
  688 ./H-IIBF8_HTV8.heic
$ gpup ./H-IIBF8_HTV8.heic ./H-IIBF8_HTV8.jpg

これも縮小されませんでした.

この画像は16MPを少し超えている程度なので縮小されないのかもしれません.もっと大きな画像で試してみます.

といっても自分の手持ちのカメラではこれが最大なので,画像を結合して作成します.(ちなみに処理時間はHEIC:56s, JPEG:3s)

$ convert -append H-IIBF8_HTV8.heic H-IIBF8_HTV8.heic 32MP.heic
$ convert -append H-IIBF8_HTV8.heic H-IIBF8_HTV8.heic 32MP.jpg
$ ls -1Ss 32MP.*
3572 32MP.jpg
1260 32MP.heic
$ identify 32MP.*
32MP.heic HEIC 4942x6552 4942x6552+0+0 8-bit YCbCr 0.010u 0:00.000
32MP.jpg JPEG 4942x6552 4942x6552+0+0 8-bit sRGB 3.4858MiB 0.000u 0:00.000
$ gpup 32MP.heic 32MP.jpg

結果はHEICは約32MPのまま 未圧縮 ,JPEGは 16 MP 3473 × 4605 になっていました.

同様に倍を試してみると HEIC 64.8 MP(9884 × 6552)未圧縮 となりました.
convertでキャッシュリソースが足りなくて転けたりしつつ更に倍( 9884 x 13104 )を試してみるとgpupでは「Failed: There was an error while trying to create this media item. (code=3)」,Chromiumでは「アップロードできません」というエラーメッセージが表示されアップロードに失敗しました.
容量は4.3MBほどしかないのでそのあたりは問題ないはずで解像度のリミットがありそうです.

てことで,少なくとも HEIC 64.8 MP(9884 x 6552) までは未圧縮でアップロード可能でなようです.
64.8 MP〜129.6MP の間に最大値があると思いますが今の所手持ちの機材では関係がないので確認していません.

環境
$ dpkg-query -W imagemagick chromium
chromium        76.0.3809.100-1
imagemagick     8:6.9.10.23+dfsg-2.1+b2
$ gpup -h 2>&1|grep Version
Version 1.x
$ git -C ~/go/src/github.com/int128/gpup/ log --oneline -1
fb48ce5 (HEAD -> master, origin/master, origin/HEAD) Merge pull request #27 from harupong/patch-1
$ lsb_release -dr
Description:    Debian GNU/Linux bullseye/sid
Release:        unstable
$ uname -m
x86_64

Imagemagickで画像変換時にキャッシュリソースが足りなくて転ける

Google Photoにheic形式でファイルをアップロードすると「高画質」(16MPに縮小される)設定でも縮小されないようなのでどのくらいのサイズまでOKなのかを試していたのですが,倍々で画像結合していたら128MPほどのファイル作成時に失敗しました.

$ convert -append out.heic out.heic out128.heic
convert-im6.q16: cache resources exhausted `out.heic' @ error/cache.c/OpenPixelCache/4083.

処理しているファイルは無駄にでかいです.

$ identify ./out.heic
./out.heic HEIC 9884x6552 9884x6552+0+0 8-bit YCbCr 0.020u 0:00.010

このあたりのページを参考にポリシーファイルを修正してメモリを増やしてみます.

$ sudo git -C /etc diff /etc/ImageMagick-6/policy.xml
diff --git a/ImageMagick-6/policy.xml b/ImageMagick-6/policy.xml
index 59d2fc6..4c6d088 100644
--- a/ImageMagick-6/policy.xml
+++ b/ImageMagick-6/policy.xml
@@ -57,8 +57,8 @@
   <!-- <policy domain="system" name="memory-map" value="anonymous"/> -->
   <!-- <policy domain="system" name="max-memory-request" value="256MiB"/> -->
   <!-- <policy domain="resource" name="temporary-path" value="/tmp"/> -->
-  <policy domain="resource" name="memory" value="256MiB"/>
-  <policy domain="resource" name="map" value="512MiB"/>
+  <policy domain="resource" name="memory" value="2048MiB"/>
+  <policy domain="resource" name="map" value="4096MiB"/>
   <policy domain="resource" name="width" value="16KP"/>
   <policy domain="resource" name="height" value="16KP"/>
   <!-- <policy domain="resource" name="list-length" value="128"/> -->

うまく行くようになりました :)

$ time convert -append out.heic out.heic out128.heic; echo $?

real    2m33.128s
user    6m42.527s
sys     0m4.704s
0
$ ls -l out128.heic
-rw-r--r-- 1 matoken matoken 4286359 Oct 20 00:30 out128.heic
$ identify out128.heic
out128.heic HEIC 9884x13104 9884x13104+0+0 8-bit YCbCr 0.000u 0:00.010

でも割り当て過ぎな気もするのでも少し減らそう.

$ dpkg-query -W imagemagick
imagemagick     8:6.9.10.23+dfsg-2.1+b2
$ lsb_release -dr
Description:    Debian GNU/Linux bullseye/sid
Release:        unstable
$ uname -m
x86_64

Nextcloud 15から16にアップグレードしたときのセキュリティ&セットアップ警告を解消

Nextcloud を15から16にアップグレードしました.すると管理アカウントの「設定」→「管理」→「概要」に以下のセキュリティ&セットアップ警告が表示されました.

Nextcloud check ok 20191019 04:10:57 2932

セットアップに関して警告がいくつかあります。
PHPのメモリ制限は推奨値512MBを下回ります。
データベースにいくつかのインデックスがありません。 大きなテーブルにインデックスを追加すると、自動的に追加されないまでに時間がかかる可能性があるためです。 "occ db:add-missing-indices"を実行することによって、インスタンスが実行し続けている間にそれらの欠けているインデックスを手動で追加することができます。 インデックスが追加されると、それらのテーブルへのクエリは通常はるかに速くなります。
テーブル "oc_twofactor_providers"のインデックス "twofactor_providers_uid"が見つかりません。
テーブル "oc_whats_new"のインデックス "version"が見つかりません。
テーブル "oc_cards"のインデックス "cards_abid"が見つかりません。
テーブル "oc_cards_properties"のインデックス "cards_prop_abid"が見つかりません。

これらを解消します.

PHPのメモリ制限は推奨値512MBを下回ります。

php.inimemory_limit512M 以上に設定します.
今回は /etc/php/7.3/apache2/php.ini

$ sudo git diff /etc/php/7.3/apache2/php.ini
diff --git a/php/7.3/apache2/php.ini b/php/7.3/apache2/php.ini
index 9a35de2..598dd82 100644
--- a/php/7.3/apache2/php.ini
+++ b/php/7.3/apache2/php.ini
@@ -403,7 +403,7 @@ max_input_time = 60

 ; Maximum amount of memory a script may consume (128MB)
 ; http://php.net/memory-limit
-memory_limit = 128M
+memory_limit = 512M

 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 ; Error handling and logging ;

編集後httpdを再読込して設定を反映します.

$ sudo service apache2 reload

データベースにいくつかのインデックスがありません。

データベースにいくつかのインデックスがありません。 大きなテーブルにインデックスを追加すると、自動的に追加されないまでに時間がかかる可能性があるためです。 “occ db:add-missing-indices”を実行することによって、インスタンスが実行し続けている間にそれらの欠けているインデックスを手動で追加することができます。 インデックスが追加されると、それらのテーブルへのクエリは通常はるかに速くなります。

Nextcloud のpathに移動して,occ db:add-missing-indices を実行してインデックスが作成されるのを暫く待ちます.

$ cd /var/www/Nextcloud
$ sudo -u www-data php ./occ db:add-missing-indices
Check indices of the share table.
Check indices of the filecache table.
Check indices of the twofactor_providers table.
Adding additional twofactor_providers_uid index to the twofactor_providers table, this can take some time...
Twofactor_providers table updated successfully.
Check indices of the login_flow_v2 table.
Check indices of the whats_new table.
Adding version index to the whats_new table, this can take some time...
whats_new table updated successfully.
Check indices of the cards table.
Adding cards_abid index to the cards table, this can take some time...
cards table updated successfully.
Check indices of the cards_properties table.
Adding cards_prop_abid index to the cards_properties table, this can take some time...
cards_properties table updated successfully.

ok

再度,管理アカウントの「設定」→「管理」→「概要」にアクセスしてチェックに合格しているのを確認 :)

Nextcloud check ok 20191019 04:10:14 19608

環境

$ sudo -u www-data php ./occ status | grep version:
  - version: 16.0.5.1
$ dpkg-query -W php apache2
apache2 2.4.38-3+deb10u3
php     2:7.3+69
$ lsb_release -dr
Description:    Debian GNU/Linux 10 (buster)
Release:        10
$ uname -m
x86_64

Google KeepのデータをCarnetにインポートする

Google Keep代替にCarmetを試してみようと思い先ずはCarnetのLinuxアプリにGoogle Keepのインポート機能があるのでそれを試してみました.

CarnetのLinuxアプリは以下のページからElectron製のi386, amd64 それぞれのAppImageが入手できます.

今回はamd64の current64.AppImage を利用しました.
ダウンロード後,実行権を付与して起動します.

$ wget https://qn.phie.ovh/binaries/desktop/current64.AppImage
$ mv ./current64.AppImage ./Carnet.AppImage
$ chmod u+x ./Carnet.AppImage
$ ./Carnet.AppImage

Settings で設定画面を開き, Import from Google Keep (only on desktop client) で Google Keep のImport画面に移動します.

Keep2Carnet 20191018 22:10:06 32370.jpg.s

先ずは Follow this link からGoogle Takeout に移動します. https://takeout.google.com/settings/takeout

Keep2Carnet 20191018 22:10:20 32675.jpg.s

Google Takeoutにて,「新しいアーカイブの作成」の「追加するデータの選択」で「選択を全て解除」した上で「Keep」にだけチェックを付けて一番下の「次のステップ」を押し,「アーカイブを作成」します.

Keep2Carnet 20191019 05:10:50 19472.jpg.s

しばらくすると(データ量により時間は変わる)Takeoutのデータをダウンロードできるようになるので適当な場所にダウンロードして展開しておきます.

展開したらCarnetアプリに戻り,「PATH TO EXTRACTED ARCHIVE」ボタンを押し,展開したKeepのパスを指定します.

Keep2Carnet 20191018 22:10:44 831.jpg.s

パスを指定したら「PICK FOLDER」ボタンを押してインポート対象を選択して「IMPORT」ボタンでインポート開始.

Keep2Carnet 20191018 22:10:13 1597.jpg.s

順調に行けばこれで終わりですが,いくつかの日本語ファイルでインポートが止まりました.

Keep2Carnet 20191018 22:10:17 1731.jpg.s

一旦画面を閉じて確認すると止まったファイルはインポートできているようでした.そのファイルを削除して再度インポート.
しかしまた止まったのでそのファイルがインポートされているのを確認してファイル削除して再度インポートすることで読み込みが終わりました.

自分の環境では2回止まりそのどちらも日本語ファイル名でした.日本語ファイル名だと必ず止まるというわけではなく問題なくインポートされた日本語ファイルのほうが多かったです.

とりあえずインポートできたのでGoogle Keep代替として試してみようと思います.

add)
インポートしたKeepのTodoリストは
☐ hoge
☑ fuga
な感じのテキストになっていました.Todoに戻すのが少し面倒.

環境
$ curl -s https://qn.phie.ovh/binaries/desktop/current_version
0.18.5
$ lsb_release -dr
Description:    Debian GNU/Linux bullseye/sid
Release:        unstable
$ uname -m
x86_64

LinuxとAndroidで動作するGoogle Keep代替を探す

Google Keepはメモアプリです.Evernoteに似ていますがもう少し機能が少ない感じ.

自分は主にTodoや買い物リストなどにKeepを利用しています.PCやAndroidで買い物をメモしてお店でAndroidのメモを見ながら買い物してチェックボックスをチェックしていく感じです.
メモの数もまだ少ないし使っている機能も少ないので代替になるものがあるのではと探してみました.

要件としてはこんな感じ

  • OSS
  • サーバ側はWebDAVなどでセルフホストが利用可能
    • 若しくはクラウドサービスを使うけどE2EEが利用可能
  • LinuxとAndroidで動作する
    • Android版では買い物メモをデスクトップウィジットで表示したい

Joplin

現在EvernoteとZim Wikiから乗り換えて作業メモなどに利用しています.サーバはNextcloudなどWebDAVが利用でき,単体でE2EEが可能です.
LinuxではAppimageやnodeでのcli版もあり,cli版はarmなどでも動作します.

既にあるノートを全部同期するのは大変,同期ディレクトリを分けることは出来ますがクライアントは1箇所しか登録できないので難しい.ノートブック単位で同期できればいいのですが今の所出来ないようです

それとAndroidでのウィジットはフレームワークでサポートされていないので今の所サポートされないようです(◞‸◟)

とりあえず見送りです.

Carnet

Google Keep代替のアプリのようです.Linux,Android,Webで利用でき,デスクトップ版はElectron製のAppimageが用意されていてGoogle Keepからのインポート機能も付いています.これはGoogle TakeoutでExportして展開したものを指定することでインポートできるようです.
同期先サーバはNextcloudかCarnetのサービスの https://carnet.live です.

今の所暗号化は未対応.

AndroidでのウィジットはIssueに上がっています.

Linux armで動作しない&暗号化未対応だけれどelectronではないLinuxアプリを開発中だし暗号化もウィジェットもIssueにあがっているので将来に期待しつつGoogle Keepをインポートして試してみようと思います.(Takeout待ち……)

add)
Web版はhttps://carnet.live だけかと思っていたのですが,NextcloudアプリのCarnetを導入することでNextcloudでWeb版が利用できます.

add)
インポートしてみました.