HTTP::Tinyで httpsアクセスで 599が返るようになった問題の修正

某モジュールのメンテンスでテストに必要なモジュールを入れようとしたらそもそもエラーが出るということで, エラー原因を調べてみたところ下記のようなエラーが出ていた。HTTP::Tinyを使った httpsへの GETが軒並み失敗していることが原因であった。

$VAR1 = {
          'headers' => {
                         'content-type' => 'text/plain',
                         'content-length' => 110
                       },
          'success' => '',
          'url' => 'https://fastapi.metacpan.org/author/XSAWYERX',
          'status' => 599,
          'content' => 'IO::Socket::SSL 1.42 must be installed for https support
Net::SSLeay 1.49 must be installed for https support
',
          'reason' => 'Internal Exception'
        };

IO::Socket::SSLNet::SSLeay も最新バージョンが入っているのになんでだろと思って以下のコードを実行したところ, 次のようなエラーが出てすぐに問題が特定できた. Ubuntuをアップデートしたところ OpenSSLのバージョンが更新されメジャーバージョンも変わってしまったために再コンパイルが必要になっていただけであった.

use IO::Socket::SSL;
Can't load '/home/syohei/.plenv/versions/5.34.1/lib/perl5/site_perl/5.34.1/x86_64-linux-thread-multi/auto/Net/SSLeay/SSLeay.so' for module Net::SSLeay: libssl.so.1.1: cannot open shared object file: No such file or directory at /home/syohei/.plenv/versions/5.34.1/lib/perl5/5.34.1/x86_64-linux-thread-multi/DynaLoader.pm line 193.
 at /home/syohei/.plenv/versions/5.34.1/lib/perl5/site_perl/5.34.1/IO/Socket/SSL.pm line 19.
Compilation failed in require at /home/syohei/.plenv/versions/5.34.1/lib/perl5/site_perl/5.34.1/IO/Socket/SSL.pm line 19.
BEGIN failed--compilation aborted at /home/syohei/.plenv/versions/5.34.1/lib/perl5/site_perl/5.34.1/IO/Socket/SSL.pm line 19.
Compilation failed in require at a.pl line 2.
BEGIN failed--compilation aborted at a.pl line 2.

再インストールしたら問題が解消した

cpanm --reinstall Net::SSLeay

apt-key deprecation warningの解消

askubuntu.com

gihyo.jp

W: https://packagecloud.io/slacktechnologies/slack/debian/dists/jessie/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.

最近上記のような警告が出ていて何のことかわかっていなかったけど、apt-keyが廃止とのことだったのでこの際修正してみた。記事を読むと本質的な対応ではないようだが, 3rd partyのリポジトリのものはひとまずこれで良いっぽい. 手順は上記の askubuntu.comの手順の通り. まず該当の鍵を探す

% apt-key list
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
/etc/apt/trusted.gpg
--------------------

pub   rsa4096 2016-02-18 [SCEA]
      DB08 5A08 CA13 B8AC B917  E0F6 D938 EC0D 0386 51BD
uid           [ unknown] https://packagecloud.io/slacktechnologies/slack (https://packagecloud.io/docs#gpg_signing) <support@packagecloud.io>
sub   rsa4096 2016-02-18 [SEA]

次にそれを exportする

% sudo mkdir -p /usr/local/share/keyrings
% sudo apt-key export 038651BD | sudo gpg --dearmour -o /usr/local/share/keyrings/slack.gpg # 鍵IDは apt-key listで得られたもの(末尾2ブロック)

sourceファイルを編集し, exportしたものを明示的に指定する

% sudo vim /etc/apt/sources.list.d/slack.list

以下のように書き換えた

deb [signed-by=/usr/local/share/keyrings/slack.gpg] https://packagecloud.io/slacktechnologies/slack/debian/ jessie main

apt update をして警告が消えるかを確認する

sudo apt update

問題が解消したら鍵を消す

sudo apt-key del 038651BD 

ついでに expiredの未使用の鍵がたくさんあったので消しておいた.

良いコード/悪いコードで学ぶ設計入門

gihyo.jp

良いコードを書くのは難しいなと思った。自分が今どういうコード書いているのかとか激しく依存するからここに載っていることをすべて実践すればうまくいくのかと言われるとなんとも言えない。経験がある人で良いものも悪いものも知った上で今の自分が関わっているコード、これから関わるであろうコードに対してちゃんと考えて適用するってのがいいのかなと思った。悪いって書かれているものも必ずしも悪いかというとそうではないケースもあるんじゃないかなと思ったので、個人的には何も知らない人けど良いコードを知りたい人は少し向かないんじゃないかなと思った。良いと書かれているものでも本当にそうだろうか、自分たちのものに適用するのが正しいのだろうかと考えられるぐらいの人に適しているのかと思いました。

Ubuntu 22.04で JetBrains Toolboxが動かなくなった問題の対応

https://youtrack.jetbrains.com/issue/TBX-7534

ふと気づいたら, JetBrains Toolboxが動かなくなっていた。libfuse2を dlopenしているようだが, Ubuntu 22.04で libfuseが 3系がデフォルトになってしまったので動かなくなっていた。

以下のようなエラーが出るかを確認する

% ~/.local/share/JetBrains/Toolbox/bin/jetbrains-toolbox
dlopen(): error loading libfuse.so.2

AppImages require FUSE to run. 
You might still be able to extract the contents of this AppImage 
if you run it with the --appimage-extract option. 
See https://github.com/AppImage/AppImageKit/wiki/FUSE 
for more information

確認できたら, libfuse2をインストールする

sudo apt install libfuse2

これで動いた

/var/log/journal 以下を掃除する

unix.stackexchange.com

10年超動かしている Ubuntuサーバ(systemdが動いていたのは10年もないかもしれないが)のディスク容量が残り少なくなってきて掃除できないかなといろいろなディレクトリのサイズを見ていると /var/log/journal 以下にログが 10GB近く溜まっていることがわかった. 個人的に動かしているサーバでログを見ることも直近のをたまに見る以外ないので古いのは全部削除しようと思ってその方法を調べたので, そのメモ

サイズを調べる

sudo journalctl --disk-usage

定量を残して削除する

sudo journalctl --vacuum-size=100M # 直近の 100MBを残す
sudo journalctl --vacuum-time=2days # 直近の 2日分を残す

これでそれなりに空き容量ができた.

Ubuntu 22.04にアップデートした

トラブルは特になく自前でコンパイルしていたソフトウェアの emacsと h2oを再コンパイルしたぐらい. h2oはバンドルしている mrubyが古く Ruby 3では mruby handlerを有効にしてビルドできないため, Ruby 2が必要になった.

github.com

Ubuntu 22.04の Rubyは 3.0系になっているので, 一時的に Rubyを 2.7.6をインストールしてそれを使ってビルドするようにした. (Ruby 2.7.6の opensslが OpenSSL 3.0系に対応していなくて警告が出るが特に問題はなかった)

再インストール後 https://syohex.org/ も無事に動いた.

List::UtilsBy::XS 0.06をリリースした

metacpan.org

github.com

Debugビルドした Perlだと extract_by で assertionに引っかかることがあった問題の修正. 戻り値の個数が引数の数より多い場合 EXTEND を使って Stackを確保しないといけないという理解. 他のメソッドはなんで引っ掛からないんだって思ったけど引数の数と戻り値の数が同じ場合は問題ないようである. どちらも stackを使って渡されておりその分確保されているためだと思われる

Perlたまにテストが通らないとか動かないとかのレポートを受けてコード見るけど, XSはマジでわからん. 他の言語の C言語拡張も書いたことがあるけど, ここまで VMの構成を意識しないといけないのはないよなと思う. まあ最初期のもので他言語をそれを見て扱いやすいものにしたのだと思うけど. 今回は Perl coreにバンドルされるソースに似たものがあったので何とかなったという具合でした.