matoken's meme – ページ 30

MySQLをデータベースとして使用していますが、4バイト文字をサポートしていません。たとえば、ファイル名やコメントの問題なしに（絵文字のような）4バイト文字を処理できるようにするには、MySQLで4バイトサポートを有効にすることをお勧めします。詳細についてはこれに関するドキュメントページを読んでください。

ここでいうドキュメントページは以下のリンクでした．

Enabling MySQL 4-byte support — Nextcloud 15 Administration Manual 15 documentation

現在のデータベースのバージョンを確認します．

$ mysql --version
mysql  Ver 15.1 Distrib 10.1.38-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2

innodb_file_format を確認して，Barracuda でない場合は`Barracuda` に変更します．

$ mysql -udebian-sys-maint -p
MariaDB [(none)]> show variables like 'innodb_file_format';
+--------------------+----------+
| Variable_name      | Value    |
+--------------------+----------+
| innodb_file_format | Antelope |
+--------------------+----------+
MariaDB [(none)]> show variables like 'innodb_file_format';
+--------------------+-----------+
| Variable_name      | Value     |
+--------------------+-----------+
| innodb_file_format | Barracuda |
+--------------------+-----------+
MariaDB [(none)]> quit;
Bye
$ sudo service mariadb restart

ここからはMySQL/MariaDBのソフトウェア，バージョン毎に少し設定が異なります．

MariaDBの設定ファイルの`[mysqld]` セクションに`innodb_file_per_table=1` を設定

innodb_file_per_table=1

MariaDBを再起動して設定反映．

$ sudo service mariadb restart

データベースの文字コードなどを変更

MariaDB [(none)]> ALTER DATABASE nextcloud CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

Nextcloud側の設定も4バイト文字を有効にする

$ sudo -u www-data php ./occ config:system:set mysql.utf8mb4 --type boolean --value="true"
System config value mysql.utf8mb4 set to boolean true

repairを掛けるとエラーに
20190814 01 08 35 31677

$ sudo -u www-data php ./occ maintenance:repair
Nextcloud is in maintenance mode - no apps have been loaded

 - Repair MySQL collation
	 - Change row format for oc_addressbooks ...
	 - Change collation for oc_addressbooks ...

In AbstractMySQLDriver.php line 115:

  An exception occurred while executing 'ALTER TABLE `oc_addressbooks` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;':

  SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes


In PDOStatement.php line 107:

  SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes


In PDOStatement.php line 105:

  SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes


maintenance:repair [--include-expensive]

max key length is 767 bytes ということで以下の設定も追記して

[mysqld]
innodb_large_prefix=true
innodb_file_format=barracuda
innodb_file_per_table=1

MariaDBを再起動して設定反映．

$ sudo service mariadb restart

再度repairを掛けると正常に終了．

$ sudo -u www-data php ./occ maintenance:repair

メンテナンスモードを抜けてNextcloudを開き，エラーメッセージが消えているのを確認

$ sudo -u www-data php ./occ maintenance:mode --off
Maintenance mode disabled

PHP OPcacheの設定

20190814 01 08 05 2116

PHP OPcacheが適切に設定されていません。よりパフォーマンスを向上させるには、php.iniで次の設定を推奨します:
opcache.enable=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1

/etc/php/7.0/apache2/php.ini を編集してapache httpd2の設定を再読込して反映．

$ sudo vi /etc/php/7.0/apache2/php.ini
$ sudo service apache2 reload

データベースにインデックスを作成

20190814 01 08 43 6355

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

occ db:add-missing-indices を実行して解決．

$ sudo -u www-data php ./occ db:add-missing-indices

imagickモジュールの導入

20190814 01 08 54 8885

このインスタンスには推奨されるPHPモジュールがいくつかありません。パフォーマンスの向上と互換性の向上のために、それらをインストールすることを強くお勧めします。
imagick

php-imagick パッケージを導入してapache httpd2を再読込

$ sudo apt install php-imagick
$ sudo service apache2 reload

データベースのbig intへの変換

20190814 01 08 22 10566

データベース内のいくつかの列で、big intへの変換が行われていません。大きなテーブルでカラムタイプを変更すると時間がかかることがあるため、自動的には変更されませんでした。 ‘occ db：convert-filecache-bigint’を実行することによって、それらの保留中の変更は手動で適用できます。この操作は、インスタンスがオフラインの間に行う必要があります。詳細についてはこれに関するドキュメントページを読んでください。
activity.activity_id
activity.object_id
activity_mq.mail_id
filecache.fileid
filecache.storage
filecache.parent
filecache.mimetype
filecache.mimepart
filecache.mtime
filecache.storage_mtime
mimetypes.id
storages.numeric_id

occ db:convert-filecache-bigint で反映

$ sudo -u www-data php ./occ db:convert-filecache-bigint
Following columns will be updated:

* activity.activity_id
* activity.object_id
* activity_mq.mail_id
* filecache.fileid
* filecache.storage
* filecache.parent
* filecache.mimetype
* filecache.mimepart
* filecache.mtime
* filecache.storage_mtime
* mimetypes.id
* storages.numeric_id

This can take up to hours, depending on the number of files in your instance!
Continue with the conversion (y/n)? [n] y

Nextcloud 16にも上げてみたいのですが，phpのバージョンを上げないといけないしE2EEプラグインが未対応だったりするのでとりあえず今回は見送りです．

20190814 17 08 22 16312

環境

$ sudo -u www-data php ./occ --version
Nextcloud 15.0.10
$ dpkg-query -W mariadb-common mariadb-server-10.1 php7.0 php7.0-mysql php-imagick
mariadb-common  10.1.38-0+deb9u1
mariadb-server-10.1     10.1.38-0+deb9u1
php-imagick     3.4.3~rc2-2
php7.0  7.0.33-0+deb9u3
php7.0-mysql    7.0.33-0+deb9u3
$ lsb_release -dr
Description:    Debian GNU/Linux 9.9 (stretch)
Release:        9.9
$ uname -m
x86_64

Google Chrome 76 でまた特定のサブドメインが表示されなくなったので表示するようにする

2019-08-112019-08-11 matoken コメントをする

Google Chrome 69 のときも一時的に表示されなくなっていたのですが，

Google Chrome 69 でURLのサブドメインが表示されなくなったのを表示する – matoken’s meme

Google Chrome 76 でまた特定のサブドメインが表示されなくなりました．

例えば， www.matoken.org は matoken.org と省略されます．

20190811 16 08 30 974

ちなみに 69 のときは www.hoge.www.matoken.org が hoge.matoken.org に見えるというバグらしき動きもありましたがこれは hoge.www.matoken.org に見えるようになっていました．

20190811 16 08 11 478

今回も Google Chrome 69 のときと同じように chrome://flags/#omnibox-ui-hide-steady-state-url-trivial-subdomains を Disabled にすると以前の挙動に戻ります．

20190811 16 08 11 3832

今回 Chromium 76 でも試してみましたが，この変更は入っていないようでサブドメインは省略されませんでした．

環境

$ dpkg-query -W google-chrome-stable chromium
chromium        76.0.3809.100-1
google-chrome-stable    76.0.3809.100-1
$ lsb_release -dr
Description:    Debian GNU/Linux bullseye/sid
Release:        unstable
$ uname -m
x86_64

mono製InlineHtmlImagesでhtml+画像の複数ファイルを単一の画像埋め込みhtmlに変換する

2019-08-112019-08-11 matoken コメントをする

npm の html-inline を試しましたが途中でコケてしまいます．

html-inline – npm

mono製の InlineHtmlImages を試すとうまくいきました :)

Inline and Extract base64 images into/from HTML

画像作成

$ convert pango:"<span font=\"/Library/Fonts/NotoColorEmoji\" size=\"24576\">😺</span>" cat.jpg

html作成

$ cat << __EOF__ > cat.html
> <html>
> <body>
> <img src="cat.jpg">
> </body>
> </html>
> __EOF__

画像埋め込み

$ mono ~/Downloads/inlinehtmlimages-mono.exe -in ./cat.html -out ./cat_inline.html

埋め込まれているのを確認

$ cat cat_inline.html
<html>
<body>
<img src="data:image/png;base64,
/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAAmACgDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD1jV/EEllqzWqSpEEUH5o9wYkZ554qS38TMSUktvNcDh4D8uffPT8zWX4p0xptegkwRFNH8x916/piokurKK5WxSeBZwuRBvG7HrjrXx+Kx+MoYqpGMtE9t9D2I0aEqMXbVo1P+EubZ5n2D5PM8v8A13Of++aluPErAhIrfymIyWnPH4Y6/mKwvsB8gR+YOJvMzj36U97qymuGsGnhacrkw7xvx6461zrOMbJNKX4L/IuWGw6asvzNbR/EEl7qotWlSUMpOVj27SPTnmiqHhXTWh1y4kPMcUeFPqW6foDRX0eT1KtTDKdV3bb+44MdGEKtqfZE3ifWbC01a2gurgQMsTcyqVQ5K9GI2np2NcUvhJp/GK6/Hfxvas4mAXlicYwD0x/Tiuv8aR3E06Q219dvcld0Vja2ysxHQszsCFH1wOK871K58QaJDBe2NpHdxhNlxZyZYoQThgU2noeQO46Vw46hUhipSpyUXUVtdtvTTY1oNTpK6b5ex0Qudd/4TQ2P2i3/ALO8vz8bPm2dNvrnP+e1Uh4SNt4xfX5b9FtQ5mKtwwJGME9Mc/0rHbxlqAt/tY8LWf2jZt/4/wBy+OuNuc/hmpdLn1/V7W5vb+2jtxKgS3s4wVz8wJY79xzxgZ/SuSWGq4ePMpxSa5Xbrf5fidDjzNKUJX3V1Y9J8L6zYXeqXUFrcCcmNDuiUsgwWzlgNo6jvRUPgyO4hlkguL66W5C7prG6tkRlHRWV1ADD3GRzRX0WAoeww8ab6f538jy68+eo2drWTf6BZag5kZWilPWSM4J+o6GiiuirRp1Y8tRXREKkqbvB2Zl/8IXF5m77Yf8Av0M/nmtWw0Gy09xIitJKOkkhyR9OwoornpZfhqUuaENfv/M2ni61RWlLQ1aKKK7DnP/Z" alt='cat.jpg' >
</body>
</html>

画像ファイルを削除しておく

$ rm ./cat.jpg

ウェブブラウザで確認

$ xdg-open ./cat_inline.html

20190811 02 08 14 32387

他にもLinuxネイテイブなものがありそうな気がします．(shell script + base64 コマンドでも多分行ける?)

環境

$ mono ~/Downloads/inlinehtmlimages-mono.exe -help|head -6|uniq

InlineHtmlImages v1.7
 Build:  3/31/2018
 Author: Dennis Lang
 Web:    home.comcast.net/~lang.dennis
$ dpkg-query -W mono-runtime chromium imagemagick libpango-1.0-0
chromium        76.0.3809.100-1
imagemagick     8:6.9.10.23+dfsg-2.1
libpango-1.0-0:amd64    1.42.4-7
libpango-1.0-0:i386     1.42.4-7
mono-runtime    5.18.0.240+dfsg-3
$ lsb_release -dr
Description:    Debian GNU/Linux bullseye/sid
Release:        unstable
$ uname -m
x86_64

電源管理ソフトウェアTLP のGUI なTLPUI を試す

2019-08-102019-08-11 matoken コメントをする

暑くなってきました．明け方でも室内で30度とかに．メインPCのウェブブラウザを開きっぱなしにしていたりたまにElectronなアプリが暴走してるとCPU温度が酷いことに．

$ acpi -t
Thermal 0: ok, 101.0 degrees C

この状態で放置しているとCritical温度に達して勝手に再起動してしまったりします．(現在の設定は105℃)

$ sensors coretemp-*
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +78.0°C  (high = +87.0°C, crit = +105.0°C)
Core 0:        +78.0°C  (high = +87.0°C, crit = +105.0°C)
Core 1:        +78.0°C  (high = +87.0°C, crit = +105.0°C)

Operaのバッテリーセーバーを使うと改善されないだろうかと試してみましたがあまり変わらないような感じ?

Linuxの電源管理を行うTLPというものがあります．NotePCなどで便利です．
これ経由でCPU のgovernor をpowersave に変えて発熱量を下げてみます．

TLPは基本的に設定ファイルを編集して設定します．設定ファイルの場所を Debian sid amd64/Ubuntu 19.10 amd64 で確認すると /etc/default/tlp です．

$ man tlp | grep FILES -A3
FILES
       /etc/default/tlp
              System-wide configuration file containing all power saving settings.

先ず，tlp を未導入の場合は導入

$ sudo apt install tlp tlp-rdw

Thinkpad の場合はこの辺りのKernel module も入れておきましょう．これは両方ともバッテリーのものでSandy Bridge 以降では acpi-call-dkms を，それより前では tp-smapi-dkms を導入します．よくわからない場合は両方を入れても大丈夫そうです．

Sandy Bridge 以降向け

$ sudo apt install acpi-call-dkms

Sandy Bridge より前向け

$ sudo apt install tp-smapi-dkms

/etc/default/tlp の以下の辺りでAC電源とバッテリー電源時の療法を powersave に変えます．

CPU_SCALING_GOVERNOR_ON_AC=powersave
CPU_SCALING_GOVERNOR_ON_BAT=powersave

tlp start で反映させます．

$ sudo tlp start
TLP started in AC mode.

とりあえずこれで暫く試すと70℃くらいで安定しています．
cpufreq で温度によってgovernor を変化させるともっとCPUを使うことも可能です．
( /etc/cpufreqd.conf の CPU Too hot! 辺り )

とりあえずこれでOKなのですが，GUI のツール無いかなと探してみると TLPUI というものを見つけたので試してみました．

GitHub – d4nj1/TLPUI: A GTK user interface for TLP written in Python

TLPUI の関連パッケージを導入します．

$ sudo apt install python3-gi git python3-setuptools python3-stdeb

アドホックにインストールせず実行，

$ git clone https://github.com/d4nj1/TLPUI
$ cd TLPUI
$ python3 -m ./tlpui

若しくはTLPUI のsource を入手してpkg を作成してインストールして実行します．

$ git clone https://github.com/d4nj1/TLPUI
$ cd TLPUI
$ python3 setup.py --command-packages=stdeb.command bdist_deb
$ sudo dpkg -i ./deb_dist/python3-tlpui_0.1-1_all.deb
$ which tlpui
/usr/bin/tlpui
$ tlpui

20190808 17 08 04 20549
20190808 17 08 08 20640

一般ユーザで実行すると裏の端末で設定反映時に認証が走るのですが，認証に成功しても設定ファイルの書き換えがうまく行きませんでした．

20190808 17 08 12 20759

sudo で実行すると問題無さそうです．

$ sudo tlpui

Software still in Beta status ということで未だβですがお手軽で便利そうです．
でもβなので設定ファイルのバックアップは取っておいたほうが良さそうです．

試した環境1(Debian sid amd64)

$ git show|head -1
commit 372463ba033df12dfa5c6c918f0b65c148f1ffac
$ dpkg-query -W acpi lm-sensors tlp tlp-rdw acpi-call-dkms python3-gi git python3-setuptools python3-stdeb python3-all
acpi    1.7-1.1
acpi-call-dkms
git     1:2.23.0~rc1-1
lm-sensors      1:3.5.0-3
python3-all     3.7.3-1
python3-gi      3.32.2-1
python3-setuptools      41.0.1-1
python3-stdeb   0.8.5-3
tlp     1.2.2-1
tlp-rdw 1.2.2-1
$ lsb_release -dr
Description:    Debian GNU/Linux bullseye/sid
Release:        unstable
$ uname -m
x86_64

試した環境2(Ubuntu 19.10 development amd64)

$ git show|head -1
commit 372463ba033df12dfa5c6c918f0b65c148f1ffac
$ dpkg-query -W acpi lm-sensors tlp tlp-rdw tp-smapi-dkms python3-gi git python3-setuptools python3-stdeb python3-all
acpi    1.7-1.1
git     1:2.20.1-2ubuntu1
lm-sensors      1:3.5.0-3ubuntu1
python3-all     3.7.3-1
python3-gi      3.32.0-1
python3-setuptools      41.0.1-1
python3-stdeb   0.8.5-3
tlp     1.2.2-1
tlp-rdw 1.2.2-1
tp-smapi-dkms   0.43-1
$ lsb_release -dr
Description:    Ubuntu Eoan Ermine (development branch)
Release:        19.10
$ uname -m
x86_64

Ubuntu 19.10 の initramfs-tools から dm-crypt 領域が見つからずエラーとなる

2019-08-062019-08-06 matoken コメントをする

Ubuntu 19.10 amd64 環境でapt upgrade でエラーになります．
新しいKernel が降りてきてinitramfs のところでdm-crypy 領域が見つからない感じのようです．

initramfs-tools (0.133ubuntu9) のトリガを処理しています ...
update-initramfs: Generating /boot/initrd.img-5.2.0-8-generic
cryptsetup: ERROR: Couldn't resolve device
  /dev/disk/by-uuid/805938be-2c29-4a53-9ed2-36fb233d76ea
cryptsetup: ERROR: Couldn't resolve device
  UUID=31145c5b-93fc-4fe0-9e46-3a68bfcadeae
W: initramfs-tools configuration sets RESUME=UUID=31145c5b-93fc-4fe0-9e46-3a68bfcadeae
W: but no matching swap device is available.
処理中にエラーが発生しました:

エラーメッセージで検索すると以下のページを発見．

live-build issue getting persistence with luks encryption : debian

The problem is that cryptsetup is not supported in the /etc/initramfs-tools/initramfs.conf configuration anymore.

The new location for loading dm-crypt during boot is /etc/cryptsetup-initramfs/conf-hook

CRYPTSETUP=y

you’ll see it in the conf-hook file commented out, just set it as above and it will work again.

If you build a system with encryption, I believe this gets changed at some point, but the live builds are systems that are not built like this, and there isn’t a lot to go on to direct you to make this change.

When you set that and re-make your iso image, you’ll be able to do encrypted persistence again. Worked for me on latest Kali January 2019. :-)

なるほど，この環境はいつも development branch にしているのでこの問題に当たったようですね．

/etc/cryptsetup-initramfs/conf-hook を CRYPTSETUP=y と編集して，

$ sudo vi /etc/cryptsetup-initramfs/conf-hook
$ sudo git diff HEAD /etc/cryptsetup-initramfs/conf-hook
diff --git a/cryptsetup-initramfs/conf-hook b/cryptsetup-initramfs/conf-hook
index 8a6a474..fdd7920 100644
--- a/cryptsetup-initramfs/conf-hook
+++ b/cryptsetup-initramfs/conf-hook
@@ -15,7 +15,7 @@
 # cryptsetup initramfs integration.
 #

-#CRYPTSETUP=
+CRYPTSETUP=y

 #
 # KEYFILE_PATTERN: ...

apt でfix-broken を掛けると正常にinitramfs が通り，再起動して新しいkernal で起動しました :)

$ sudo apt install -f

環境

$ dpkg-query -W cryptsetup* initramfs-tools*
cryptsetup      2:2.1.0-5ubuntu2
cryptsetup-bin  2:2.1.0-5ubuntu2
cryptsetup-initramfs    2:2.1.0-5ubuntu2
cryptsetup-run  2:2.1.0-5ubuntu2
initramfs-tools 0.133ubuntu9
initramfs-tools-bin     0.133ubuntu9
initramfs-tools-core    0.133ubuntu9
$ lsb_release -dr
Description:    Ubuntu Eoan Ermine (development branch)
Release:        19.10
$ uname -m
x86_64

Have I Been Pwned からパスワード流出のお知らせが届く

2019-08-052019-08-05 matoken コメントをする

Have I Been Pwned からメールが届きました

You’re one of 23,205,290 people pwned in the CafePress data breach

Have I Been Pwned: Pwned websites

CafePress からパスワードが流出したようです．

早速パスワードを変更します．

20190805 12 08 45 18660
20190805 12 08 13 20506

とりあえずはこれでいいかな?

Have I Been Pwned は流出したパスワードのデータベースを持っていて，自分のメールアドレスを入力するとそのアドレスで流出したサービスを教えてくれます．
登録しておくと今回のようにお知らせしてくれるので助かります．

現在はMozilla のFirefox Monitor も同じデータベースで煮たサービスをしています．日本語がいいって人はこちらのほうがおすすめ．メールアドレスも複数登録できるようになりました．

ちなみに私は両方に登録していて今回の件のメールが届いたのは

Have I Been Pwned が 2019-08-05 10:58
Firefox Monitor が 2019-08-05 14:16

と Have I Been Pwned のほうが少し早かったです．

sshuttle がエラーになる

2019-07-292019-07-30 matoken コメントをする

SSH VPN がお手軽に利用できる sshuttle を久々に使おうとしたら失敗します．いくつかのremotehostを試してもうまくいかない．

GitHub – sshuttle/sshuttle: Transparent proxy server that works as a poor man’s VPN. Forwards over ssh. Doesn’t require admin. Works with Linux and MacOS. Supports DNS tunneling.

Debian sid 環境でのエラー

$ sshuttle -v -r user@remotehost 0/0
Starting sshuttle proxy.
firewall manager: Starting firewall with Python version 3.7.4
firewall manager: ready method name nat.
IPv6 enabled: False
UDP enabled: False
DNS enabled: False
User enabled: False
TCP redirector listening on ('127.0.0.1', 12300).
Starting client with Python version 3.7.4
c : connecting to server...
Host key fingerprint is SHA256:kUoWT4bCu7+HiegN9R5tYqO5nnvpQPobzSk46T8WEwU
+---[ECDSA 256]---+
|   .E...o        |
|    o o= .       |
|     +o +        |
|    oo . .       |
|    oo. S        |
|   *++ o         |
|  *.+=X+o        |
| ..=+X*=.        |
| .o+%B+o         |
+----[SHA256]-----+
Enter passphrase for key '/home/matoken/.ssh/id_ed25519':
Authenticated to nnn.nnn.nnn.nnn ([nnn.nnn.nnn.nnn]:nn).
-c:3: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
Starting server with Python version 3.7.3
 s: latency control setting = True
c : Connected.
 s: auto-nets:False
firewall manager: setting up.
>> iptables -t nat -N sshuttle-12300
>> iptables -t nat -F sshuttle-12300
>> iptables -t nat -I OUTPUT 1 -j sshuttle-12300
>> iptables -t nat -I PREROUTING 1 -j sshuttle-12300
>> iptables -t nat -A sshuttle-12300 -j RETURN --dest 127.0.0.1/32 -p tcp
>> iptables -t nat -A sshuttle-12300 -j REDIRECT --dest 0.0.0.0/0 -p tcp --to-ports 12300 -m ttl ! --ttl 42
firewall manager: undoing changes.
>> iptables -t nat -D OUTPUT -j sshuttle-12300
>> iptables -t nat -D PREROUTING -j sshuttle-12300
>> iptables -t nat -F sshuttle-12300
>> iptables -t nat -X sshuttle-12300
c : fatal: server died with error code 255

最後の行のエラーメッセージで検索すると以下のIssue を見つけました．

sshuttle crashes with server died with error code 255 · Issue #150 · sshuttle/sshuttle · GitHub

参考にして -x remotehostip で使えるようになりました．-x は除外オプションで接続先のip を指定して除外するとOKのようです．

NG $ sshuttle -r user@remotehost 0/0
OK $ sshuttle -r user@remotehost 0/0 -x remotehostip

VPN 対象のサブネットと同様 -x にも複数のサブネット/ip の指定ができます．

Debian sid 環境

$ dpkg-query -W sshuttle
sshuttle        0.78.5-1
$ hostnamectl|grep -E 'Operating System|Architecture'
  Operating System: Debian GNU/Linux bullseye/sid
	  Architecture: x86-64

Raspbian Buster 環境でのエラー

ちなみに sshuttle を Raspbian Buster で試すとまた違うこんなエラーに．でもやっぱり -x で解決しました．

Raspbian Buster での error message

 :
client: Connected.
packet_write_wait: Connection to 192.168.1.102 port 22: Broken pipe
Traceback (most recent call last):
  File "/usr/bin/sshuttle", line 11, in <module>
	load_entry_point('sshuttle==0.78.5', 'console_scripts', 'sshuttle')()
  File "/usr/lib/python3/dist-packages/sshuttle/cmdline.py", line 82, in main
	opt.sudo_pythonpath)
  File "/usr/lib/python3/dist-packages/sshuttle/client.py", line 787, in main
	seed_hosts, auto_hosts, auto_nets, daemon, to_nameserver)
  File "/usr/lib/python3/dist-packages/sshuttle/client.py", line 547, in _main
	ssnet.runonce(handlers, mux)
  File "/usr/lib/python3/dist-packages/sshuttle/ssnet.py", line 598, in runonce
	h.callback(s)
  File "/usr/lib/python3/dist-packages/sshuttle/ssnet.py", line 488, in callback
	self.flush()
  File "/usr/lib/python3/dist-packages/sshuttle/ssnet.py", line 439, in flush
	wrote = _nb_clean(os.write, self.wsock.fileno(), self.outbuf[0])
  File "/usr/lib/python3/dist-packages/sshuttle/ssnet.py", line 79, in _nb_clean
	return func(*args)
BrokenPipeError: [Errno 32] Broken pipe

Raspbian Buster の環境

$ dpkg-query -W sshuttle
sshuttle        0.78.5-1
$ lsb_release -d
Description:    Raspbian GNU/Linux 10 (buster)
$ uname -m
armv6l
$ cat /proc/device-tree/model ;echo
Raspberry Pi Model B Rev 2

Ubuntu 18.04 LTS 環境(OK)

Ubuntu 18.04 LTS のsshuttle でも試してみましたがこれは -x を付けなくても問題なしでした．sshuttle 0.78.4 〜 0.78.5 の間の修正での影響でしょうか?

error の出なかった環境

$ dpkg-query -W sshuttle
sshuttle        0.78.3-1ubuntu1
$ lsb_release -d
Description:    Ubuntu 18.04.2 LTS
$ uname -m
x86_64

Firefox のマウス，タッチパッド等でのズーム機能を無効にする

2019-07-202019-07-20 matoken コメントをする

精度の悪いタッチパッドを使っていると2本指でスクロールしたつもりが拡大，縮小になってしまうことがあります．スクロールのつもりなので操作量も多く一気に拡大されたり縮小されたり……．

Firefox でこの機能を無効にしてみました．
以下の手順ではポインティングデバイスでのズーム機能は無効化されますが，キーボード・ショートカットでのズームは利用できます．

about:config で設定(GUI)

Firefox のアドレスバーに about:config を入力して開き， zoom.maxPercent, zoom.minPercent をそれぞれ 100 に書き換える．
この手順の場合即時反映される．

20190710 22 21 33 001

設定ファイルで設定

Firefox の対象のプロファイルのあるディクトリに user.js ファイルを作成し起動すると反映される．

プロファイルのあるディレクトリは ~/.mozilla/firefox/profiles.ini を確認する．
以下の例では，~/.mozilla/firefox/4dx27pta.default/ になる．

~/.mozilla/firefox/profiles.ini

[Install4F96D1932A9F858E]
Default=4dx27pta.default

[Profile0]
Name=default
IsRelative=1
Path=4dx27pta.default
Default=1

[General]
StartWithLastProfile=1
Version=2

user.js を以下の内容で作成する．既に存在する場合は追記する．

~/.mozilla/firefox/4dx27pta.default/user.js

user_pref("zoom.maxPercent", 100);
user_pref("zoom.minPercent", 100);

環境

$ dpkg-query -W firefox
firefox 68.0+build3-0ubuntu0.18.04.1
$ hostnamectl | egrep 'Operating System|Architecture'
  Operating System: Ubuntu 18.04.2 LTS
      Architecture: arm64

apt-cacher-ng で https リポジトリを直接アクセスするようにする

2019-07-192019-07-19 matoken コメントをする

apt-cacher-ng で各種リポジトリをキャッシュしているのですが，https の場合エラーになってしまいます．

error message

$ sudo apt update
Err:1 https://updates.signal.org/desktop/apt xenial InRelease              Reading from proxy failed - read (115: Operation now in progress) [IP: 192.168.1.102 3142]                                                      Err:2 https://deb.opera.com/opera-stable stable InRelease
  Reading from proxy failed - read (115: Operation now in progress) [IP: 192.168.1.102 3142]
 :
W: Failed to fetch https://deb.opera.com/opera-stable/dists/stable/InRelease  Reading from proxy failed - read (115: Operation now in progress) [IP: 192.168.1.102 3142]
W: Failed to fetch https://updates.signal.org/desktop/apt/dists/xenial/InRelease  Reading from proxy failed - read (115: Operation now in progress) [IP: 192.168.1.102 3142]
W: Some index files failed to download. They have been ignored, or old ones used instead.

Debian wiki に解決方法が載っていました．https の場合はキャッシュせずに直接見に行かせる設定が出来るようです．

AptCacherNg – Debian Wiki

HTTPS repositories
apt-cacher-ng will obviously fail to serve HTTPS repositories. There are many solutions upstream but I have found the simplest solution to be to simply tunnel HTTPS connections directly on the proxy, by putting this in /etc/apt-cacher-ng/acng.conf:
PassThroughPattern: .*
This is, as far as I can tell, the only way to avoid doing a special configuration on the clients for HTTPS repositories. The downside is that HTTPS content is not cached.

/etc/apt-cacher-ng/acng.conf に PassThroughPattern: .* を設定してデーモンを再起動することで直接アクセスしてエラーを出さなくなりました．

以下のページのように source.list を書き換えてhttps であってもキャッシュする方法もあるようですが今回はなしで．

HOWTOs and FAQ

apt-cacher-ng環境

$ dpkg-query -W apt-cacher-ng
apt-cacher-ng   3.1-1build1
$ hostnamectl | egrep 'Operating System|Architecture'
  Operating System: Ubuntu 18.04.2 LTS
      Architecture: x86-64

apt実行環境

$ dpkg-query -W apt
apt     1.8.2
$ hostnamectl | egrep 'Operating System|Architecture'
  Operating System: Debian GNU/Linux bullseye/sid
      Architecture: x86-64