【Arch Linux】pacmanが遅いと思った時

VirtualBoxに入れているArchLinuxのパッケージ更新が遅いと気が付いた。

家の回線が遅いからと思って我慢していたが、そのレベルではないなと。

fastestmirrorみたいのが、必要なのではと調べると、

/etc/pacman.d/mirrorlist

が、ミラーリストであることがわかった。

しかも、同じディレクトリに、mirrorlist.pacnewが存在していた。

どうやら、古いリストを使い続けていたいようだ。

日本から遠く離れた国のミラーサーバを呼んでいた。負荷かけてすまぬ。

回線が遅いなどと思って、すいません。

善処いたします。

# cd /etc/pacman.d

# mv mirrorlist mirrorlist.20210220

# cp -p mirrorlist.pacnew mirrorlist

早速、ミラーリストを差し替えて、編集。

JAPANとされるサーバを有効にしてみた。

# pacman -Syu

速い気がするが、更新対象がないので、わからない。

次回の更新が楽しみだ。

mariadb10.3/CentOS8 透過的データ暗号化

CentOS8上のmariadbの透過的データ暗号化設定

説明上のファイルと、例の中のファイル名は以下ように対応する。

鍵ファイル	/etc/my.cnf.d/keyfile.txt
暗号文字列ファイル	/etc/my.cnf.d/password.txt
暗号化鍵ファイル	/etc/my.cnf.d/keyfile.enc

1. 透過的暗号化で使う鍵ファイルを作成する

1.1. 鍵ファイルを生成する

openssl rand -hex 32

として、ランダムな英数文字列を生成する。

生成されたランダムな英数文字列を使用して、鍵ファイルを作成する。

鍵ファイルの行の書式は、以下の通り。セミコロンは一つ。

鍵番号;鍵文字列

鍵番号は1以上の整数。鍵文字列は、英数字の文字列を指定。

複数行を使って、複数の鍵を登録できる。

鍵ファイル例：

# cat /etc/my.cnf.d/keyfile.txt
1;9a8cc46f1452e21a76a6ffe88a3abf337d04ba0b8dd8bccfe7a0a09bd63c1586

1.2. 鍵ファイルを暗号化する

暗号化のための文字列を生成し、暗号文字列ファイルに保存。

openssl rand -hex 128 > /etc/my.cnf.d/password.txt

暗号文字列ファイルを使って鍵ファイルから、暗号化鍵ファイルを生成する。

openssl enc -aes-256-cbc -md sha1 \

-pass file:/etc/my.cnf.d/password.txt \

-in /etc/my.cnf.d/keyfile.txt \

-out /etc/my.cnf.d/keyfile.enc

以下の警告がでるが、これらのオプションを使用しない。（mariadbで読めなくなる？）

*** WARNING : deprecated key derivation used.
Using -iter or -pbkdf2 would be better.

2. mariadbに透過的暗号化を設定する。

2.1. 設定ファイルの編集

• /etc/my.conf.d/mariadb-server.cnf

[server]
plugin-load-add=file_key_management
file_key_management
loose_file_key_management_filename = /etc/my.cnf.d/keyfile.enc
loose_file_key_management_filekey = FILE:/etc/my.cnf.d/password.txt
loose_file_key_management_encryption_algorithm = AES_CTR

innodb_encrypt_tables = ON
innodb_encrypt_temporary_tables = ON
innodb_encrypt_log = ON
innodb_encryption_threads = 4
innodb_encryption_rotate_key_age = 100

2.2. 設定の反映

systemctl restart mariadb

3. 特定のテーブルが暗号化できているか調べる。

mysqlコンソールから

select NAME, ENCRYPTION_SCHEME, CURRENT_KEY_ID from
information_schema.INNODB_TABLESPACES_ENCRYPTION
WHERE NAME='【データベース】/【テーブル】';

実行例：

MariaDB [(none)]> select NAME, ENCRYPTION_SCHEME, CURRENT_KEY_ID from
-> information_schema.INNODB_TABLESPACES_ENCRYPTION
-> WHERE NAME='test/prefecture';
+-----------------+-------------------+----------------+
| NAME            | ENCRYPTION_SCHEME | CURRENT_KEY_ID |
+-----------------+-------------------+----------------+
| test/prefecture |                 1 |              1 |
+-----------------+-------------------+----------------+
1 row in set (0.005 sec)

4. 特定のテーブルの暗号化を解く。

mysqlコンソールから

ALTER TABLE 【テーブル名】 ENCRYPTED=NO;

5. 特定のテーブルの暗号化をする。

mysqlコンソールから

ALTER TABLE 【テーブル名】 ENCRYPTED=YES ENCRYPTION_KEY_ID=【鍵番号】;

6. 参考

• https://mariadb.com/kb/en/file-key-management-encryption-plugin/

【Android】SSHクライアント

Android端末から、サーバに接続するとき、

VX ConnectBotというアプリを使っていた。

物理キーボードとの組み合わせが、良かったからである。

だが、Arch Linuxに接続できなくなっていることに気が付いた。

同じネットワークのCentOS8には接続できたし、

別のPCからは、Arch Linuxへも接続できていたので、

ネットワークや、サーバではなく、アプリ側の問題だと考えた。

おそらく、OpenSSH8.4の機能強化あたりで、はじかれるようになったのだろう。

VX ConnectBot自体、2013年が最終更新である。

これは、新たなアプリを探す時期にきたという事だ。

これまでありがとう。感謝しかない。

いろいろ見てみて、Termuxというアプリを入れる。

これは、SSHクライアントでなく、SHELLコンソールアプリである。

SSH利用には、さらにコンソール内からインストールが必要であった。

安全だろうか？

ユーザも多いし、大丈夫だろう。

新たに、ed25519形式の公開鍵を新調した。

sshコマンドを使用して、Arch Linuxへログインできることは確認できた。

SSHクライアントと違って、少々面倒である。

だが、時が来たら、進むしかない。

【Windows】msys2にまとめたい

Windows上のシェル環境として、長らく使っていたcygwinと、MSYS2とを

併用して使っていたが、今後は、msys2に一本化していこうと思う。

Cygwinに頼っていたのは、lgerpが強力であったからである。

文字コードを問わず、grepできるのが、たまらなく魅力だったのだ。

だが、EUC-JPで書かれたコードは、ここ数年まったく開いていないし、

SJISのコードも、もう残り少ない。（VisualStudioのWIN32プロジェクトだけ）

lgrep以外は、何とかmsys2でなるんじゃないかと思っている。

ダメだったら、戻るかもしれないけれど、ミニマムな環境を目指したいので、

まずは、やってみようと思う。

【Arch Linux】VirtualBoxで起動しなくなる

VirtualBoxに入れていたArchLinuxを更新して、再起動したところ、

SSHでログインできなくなった。

調べると、ネットワークインターフェースが認識されていない。

おかげで、インターネットにも、つながらなくなる。

しかたなく、ライブCDからの復旧を図ることになる。

つい最近も、過去にも起動しなくなって、復旧させたばかりだったのに。

なんだか、大変だ。

（追記）

結局、ライブCDから起動した後、カーネルのダウングレードを行って、

再起動して、起動するようになったが、次は、いつアップデートできるのだ？

ローリングアップデートは、ありがたいが、安定性は、もう少しほしい。

【Trac】Trac1.4.1にバージョンアップした

Trac1.4.1が出ていることに気が付き、アップデートしてみた。

問題なく、動いている様子。

先日上げたらダメだった、Jinjya2のバージョンも上げてみた。

Jinja2 2.11.1

無事、動いている様子。

やった！

【Trac】Jinja2のバージョンを上げたら、表示されなくなった

Trac1.4 / python2.7を動かしている環境のJinjya2のバージョンを上げたら、

ページが真っ白になってしまった。

何のレスポンスも返さなくなってしまったようだ。

インストールしたのは、Jinja2-2.11.1。

動いていた時のバージョンに戻す。

pip install Jinja2==2.10.3 -U

そして、アプリの再起動すると、画面が表示されるようになった。

Pythonの２系は、サポートされなくなったんだろうか？

https://pypi.org/project/Jinja2/

Requires: Python >=2.7

となっていて、外れたとは書いていなかったんだが。。。

面倒なので、もうパッケージの更新はしないようにしようかな。

Python3.5に対応した、Trac1.6よ、はよ。

と願うばかり。