phpでprotectedなメソッドにアクセスする。

phpでprotectedなメソッドにアクセスする。

この様なときに使う必要があった、laravelが持ってる protected な プロパティに強引にアクセスする。

laravelなどのフレームワークが内部に持ってるコールバックやプロパティを取り出して調べたり、意図通り、正しく内部登録されれてるかテストしたい。

しかし、内部へのアクセスは基本的に出来ない。

コールバック内部では、php の this を固定できるという事案を使ってハックする。

<?php
(fn()=> $this->protected )->call($ev);

たとえば、こんな感じ。

<?php
$eventObjects = ... 
$ev = $eventObjects[0];
$prop = (function(){return $this->callback;})->call($ev);
$deep_prop = (function(){return $this->entry;})->call($prop);

php/laravel がContractでFacadeから呼び出している実体クラスがあって、そいつが持ってる値を調べたいときに使う。

windows が ping 応答しない ssh 応答しない。

windows が ping 応答しない ssh 応答しない。

Windows は Ping 応答しない。

windowsは、ping も ssh も応答しない。Inbound のトラフィックをブロックする。

設定のファイアウォールでプロトコル別に許可する

Enabled && Allow

ssh / ping くらいは応答してもいいと思うんだけどなぁ

シェルでファイル名をエスケープにしてクォート地獄を解決する。

シェルスクリプトで、ファイル名をエスケープする

シェルスクリプトで、括弧（）やスペースなどの文字種をエスケープしたいときに手早い方法がないか。

printf が手軽だった。

printf "%q" 文字列

実際の例ーカッコ

次のようにいい感じにエスケープしてくれる。

takuya@~$ printf '%q\n' '(note)(todo) 2022-01-23.txt'
\(note\)\(todo\)\ 2022-01-23.txt

実際の例- バックスラッシュ

バックスラッシュをエスケープしてくれる。

takuya@~$ printf '%q' 'C:\Windows'
C:\\Windows

実際の例- シングルクォーテーション

所有で使われるシングルクォーテーションも

takuya@~$ printf '%q' "takuya's"
takuya\'s

いい感じにエスケープを処理してコマンド文字列を作り、xargs や for に流せそうですね。

wslpathを wslから使うとエスケープが必要だた

wslpathを wslから使うと

エスケープが必要になる。バックスラッシュ。

takuya@DESKTOP-2ALDRO3:~$ wslpath -u "'C:\ProgramData\ssh\logs'"
/mnt/c/ProgramData/ssh/logs

ちゃんと、grep して エスケープしないと面倒ですね。

OpenWrtでGNU GREPを使うためにopkg でインストール。

grep の指し示すもの

opkg の grep はbusybox なので正規表現の取り扱いが微妙

root@OpenWrt:~# grep -v
BusyBox v1.33.2 (2021-12-14 22:12:22 UTC) multi-call binary.
root@OpenWrt:~# which grep
/bin/grep
root@OpenWrt:~# ls -l $(which grep)
lrwxrwxrwx    1 root     root             7 Dec 21 03:26 /bin/grep -> busybox

GNU Grep を使う。

opkg install grep 

Grep をインストール。

root@OpenWrt:~# opkg find grep
grep - 3.6-1 - The grep command searches one or more input files for lines
 containing a match to a specified pattern. By default, grep
 prints the matching lines.

grep をいれても GNU grep にならないので、調べたら。busybox を上書きするわけではなさそう。

bin/grep にインストールされているわけではなさそう。

root@OpenWrt:~# find / | grep grep
/bin/egrep
/bin/fgrep
/bin/grep
/usr/bin/pgrep
/usr/bin/zipgrep
/usr/lib/opkg/info/grep.control
/usr/lib/opkg/info/grep.postinst
/usr/lib/opkg/info/grep.prerm
/usr/lib/opkg/info/grep.list
/usr/lib/opkg/info/procps-ng-pgrep.control
/usr/lib/opkg/info/procps-ng-pgrep.postinst
/usr/lib/opkg/info/procps-ng-pgrep.prerm
/usr/lib/opkg/info/procps-ng-pgrep.list
/usr/lib/git-core/git-bugreport
/usr/lib/git-core/git-grep
/usr/libexec/egrep-gnu
/usr/libexec/fgrep-gnu
/usr/libexec/grep-gnu
/usr/libexec/pgrep-procps-ng

/usr/libexec/grep-gnu が私達がよく知る GNU Grep です。

root@OpenWrt:~# /usr/libexec/grep-gnu -v
Usage: grep-gnu [OPTION]... PATTERNS [FILE]...
Try 'grep-gnu --help' for more information.

opkg で確認してみる。

opkg files でインストールするファイル一覧が出せる。 これで答え合わせして調べてみると、/usr/libexec にインストールされることがわかる。

root@OpenWrt:~# opkg files grep
Package grep (3.6-1) is installed on root and has the following files:
/usr/libexec/egrep-gnu
/usr/libexec/fgrep-gnu
/usr/libexec/grep-gnu

2022-03-09

opkg files でfile list を出す方法について追記。

apt でアップグレードをワイルドカードでまとめてやる

apt でアップグレードだけをやるには、--only-upgrade をつける

sudo apt install --only-upgrade  php*

アップグレードはだめ

次は、壊れます。

sudo apt upgrade  php*

また、次は、すべてのアップグレード可能パッケージが対象になります。

sudo apt upgrade 

実際にやってみた例

takuya@:~$ sudo apt list --upgradable
一覧表示... 完了
gitlab-ce/buster  アップグレード可]
nodejs/不明 16.13 アップグレード可]
php-cli/bullseye  アップグレード可]
php-common/bullse アップグレード可]
php-xml/bullseye  アップグレード可]
php7.0-apcu/bulls アップグレード可]
php7.0-imagick/bu アップグレード可]
php7.0-memcache/b アップグレード可]
php7.4-apcu/bulls アップグレード可]
php7.4-igbinary/b アップグレード可]
php7.4-imagick/bu アップグレード可]
php7.4-memcache/b アップグレード可]
php7.4-redis/bull アップグレード可]
php8.0-apcu/bulls アップグレード可]
php8.0-igbinary/b アップグレード可]
php8.0-imagick/bu アップグレード可]
php8.0-memcache/b アップグレード可]
php8.0-redis/bull アップグレード可]

takuya@~: sudo apt install --only-upgrade  php*
php8.1-tidy  はインストールされておらず、アップグレードだけの要求なので、インストールをスキップします。
php8.1-tidy-dbgsym  はインストールされておらず、アップグレードだけの要求なので、インストールをスキップします。
php8.1-uopz  はインストールされておらず、アップグレードだけの要求なので、インストールをスキップします。
php8.1-uopz-dbgsym  はインストールされておらず、アップグレードだけの要求なので、インストールをスキップします。
php8.1-uploadprogress  はインストールされておらず、アップグレードだけの要求なので、インストールをスキップします。
php8.1-uploadprogress-dbgsym  はインストールされておらず、アップグレードだけの要求なので、インストールをスキップします。
php8.1-uuid  はインストールされておらず、アップグレードだけの要求なので、インストールをスキップします。
php8.1-uuid-dbgsym  はインストールされておらず、アップグレードだけの要求なので、インストールをスキップします。
php8.1-vips  はインストールされておらず、アップグレードだけの要求なので、インストールをスキップします。
php8.1-vips-dbgsym  はインストールされておらず、アップグレードだけの要求なので、インストールをスキップします。
php8.1-xdebug  はインストールされておらず、アップグレードだけの要求なので、インストールをスキップします。
php8.1-xhprof  はインストールされておらず、アップグレードだけの要求なので、インストールをスキップします。
php8.1-xhprof-dbgsym  はインストールされておらず、アップグレードだけの要求なので、インストールをスキップします。
php8.1-xml  はインストールされておらず、アップグレードだけの要求なので、インストールをスキップします。
php8.1-xml-dbgsym  はインストールされておらず、アップグレードだけの要求なので、インストールをスキップします。
php8.1-xmlrpc  はインストールされておらず、アップグレードだけの要求なので、インストールをスキップします。
php8.1-xmlrpc-dbgsym  はインストールされておらず、アップグレードだけの要求なので、インストールをスキップします。

このようにワイルドカードで指定すると本当にパッケージが全部選択されます。しかし、--only-upgrade でアップグレード対象のみに絞り込むこととで、ぶっ壊れを事前に防ぐことができるのです。

もうちょっと便利にならないかな。。。。これ

無償版 Gsuite がなくなるので、かなり思案する。

Gsuite legacy が消えます。

無償版「G Suite」、7月1日に完全終了 有償「Google Workspace」への切り替え推奨 - ITmedia NEWS

歴史的経緯の無償版 gsuite / google workspace が消えます。

Google appとして提供され始め、ブラウザでスプレッドシートが使えるようになり、当時使い始めてはや１０年超。

いまや、スプレッドシートなどのドキュメント機能やストレージ機能が一般無料Gmailに提供されていて、Gmailの機能だけでなく、GCPやGoogle Authenticator といった各種機能も無償版gmail側に提供されていて、GsuiteがGoogle Workspaceという名前に変更され組織向けに特化したことで、元来のドキュメント機能を使うための無償版の役割は果たしたということなでしょうか。

アカウントをどうするか

しかし、月額８００円（いまはもうすこし安いく680円だが、将来的にはこれくらいの価格まで値上げされるだろう事も含めて）程度の課金を、２０アカウントに行うのは、現実的ではなく、乗り換え先の探索と、移行作業が発生することとなる。

一時停止のまま60日経過すると、Gmail、カレンダー、Meetなどのコアサービスが使えなくなる（YouTubeやGoogleフォトなどはそのまま使える）。

アカウントのその後がわからない。

Google アカウントは、自分メールアドレス（ @gmail 以外）でも取得することができる。しかし、Gsuiteのアカウントで作成していたメアドでGoogle アカウントを取り直せるのかが、全くわからない。困ったものだ。

別のサービスの候補について

Gsuiteで独自ドメインでメールアドレス・アカウントを運用していると、困難に直面する。 素直にスパッと諦めてもいいのだが、メールアドレスやエイリアスを精査するのは困難になる。とくに「メールアドレス認証」とかいって、ログイン時にワンタイムキーを送付してくるサービスが多いのでそれをすべて調べるのは不可能に近い。

yandex / zoho

yandex がメールアカウントと独自ドメインでのメール運用が可能ですが、移行組で溢れかえって近い将来使えなくなるだろうと予想する。Google が捌いているメールトラフィックの１％程度でもYandexには辛いだろうと思われる。移行組が多いとコレらサービスに値上げが波及すると予想される。

vps+mailcow

さくらVPSを使って、メールを運用する。という手も取れるのだが、Gmailに変わるようなふさわしいWEB-UIを備えた、ソフトウェアツールはそうそう存在しない。mailcowというDockerパッケージを使えば、スパムフィルタリング・WEB-UIとアドレス帳、カレンダーまでは作ることができる。しかし、Gmailほど便利とも言えない。

google domains

Google DomainsでGoogle に移管すれば、メールアドレスは１００個まで無数に作ることができ、個人用Gmailアカウントに転送できる

Google Domains のメール オプション - Google Domains ヘルプ

cloudflare メール

Cloudflareにメール・ルーティング機能があるので、Google Domainsはちょっと・・・と思われるときに便利だと思います。

Cloudflare Email Routingでメールの作成とルーティングが簡単に

icloud+

appleの箱庭で満足出来るならicloud+で独自ドメインとメールが使える。アップルはクラウドサービスを長期間安定的に提供してくれるし実績もある、が、しかし、機能アップデートや使い勝手の改善などはまるで期待出来ない。 彼らはリリース後は放置する傾向にある。そういうことを踏まえて箱庭で良いなら良い選択肢であると思われる

NPO法人を作る

自治会とか消防団とか水利組合とかは、NPO法人を作ったほうが良さそうですね。NPO法人がベスト解だと思いますが、如何せんめんどくさい。

選択肢まとめ

メールアドレスでいいなら、Cloudflareのメール・ルーティング

アカウントとWEBとカレンダーなどがほしいなら、Yandexかmailcow+vps

今後もあらゆる無償版が有料化されていくこと、クラウドリスクを恐れるなら、いっそのこと NPO法人を維持するのもありだと思えました。

debian のミラーをいちいちネットで探すんがだるい

debian/ubuntu のミラーをいちいちネットで探すんがだるい

sources.list の自動生成と、作成ができる netselect-apt

netselect-apt で自動生成

sudo netselect-apt -c japan -s
cp /etc/apt/sources.list /etc/apt/sources.list.$(date -I)back
mv sources.list /etc/apt/sources.list

インストール

sudo apt install netselect-apt

インストールが必要なのが面倒ですね。dpkg で ミラーセレクトできたらいいのに

居住国のミラーを探す。

Debian/11 で試しました。

takuya@:~$ sudo netselect-apt -c japan
Using distribution stable.
Retrieving the list of mirrors from www.debian.org...

URL transformed to HTTPS due to an HSTS policy
--2022-01-17 23:17:40--  https://www.debian.org/mirror/mirrors_full
www.debian.org (www.debian.org) をDNSに問いあわせています... 128.31.0.62, 130.89.148.77, 149.20.4.15, ...
www.debian.org (www.debian.org)|128.31.0.62|:443 に接続しています... 接続しました。
HTTP による接続要求を送信しました、応答を待っています... 200 OK
長さ: 122479 (120K) [text/html]
`/tmp/netselect-apt.9NpgR5' に保存中

/tmp/netselect-apt.9NpgR5     100%[=================================================>] 119.61K   229KB/s 時間 0.5s

2022-01-17 23:17:41 (229 KB/s) - `/tmp/netselect-apt.9NpgR5' へ保存完了 [122479/122479]

Choosing a main Debian mirror using netselect.
(will filter only for mirrors in country japan)
Running netselect to choose 10 out of 14 addresses.
...........................................................................................................................
The fastest 10 servers seem to be:

    http://mirrors.xtom.jp/debian/
    http://ftp.riken.jp/Linux/debian/debian/
    http://ftp.jaist.ac.jp/debian/
    http://ftp.yz.yamagata-u.ac.jp/debian/
    http://ftp.yz.yamagata-u.ac.jp/debian/
    http://hanzubon.jp/debian/
    http://ftp.yz.yamagata-u.ac.jp/debian/
    http://ftp.yz.yamagata-u.ac.jp/debian/
    http://ftp.nara.wide.ad.jp/debian/
    http://dennou-k.gfd-dennou.org/debian/

Of the hosts tested we choose the fastest valid for http:
        http://mirrors.xtom.jp/debian/

Writing sources.list.
sources.list exists, moving to sources.list.1642429063
Done.

探すとはいえ、だいたい、いつもは sakura さんにお世話になってたりするけど。。。

参考資料

https://unix.stackexchange.com/questions/431996/how-to-change-mirrors-in-sources-list-automatically

Debian Bullseye からomxplayer がなくなった

omxplayer がなくなってる。

takuya@raspberrypi:~ $ omxplayer
-bash: omxplayer: コマンドが見つかりません
takuya@raspberrypi:~ $ apt search omxplayer
ソート中... 完了
全文検索... 完了
takuya@raspberrypi:~ $

消えたらしい。

https://forums.raspberrypi.com/viewtopic.php?t=324184

OMXplayer simply does not work on Bullseye*, so it's not able to be installed.

If you really need OMXPlayer, the best option is to remain on Buster. If you just need a playback applications VLC should be fine, and also support HEVC which OMXPlayer did not.

LEGACY入れたほうが良かったかもしれない。

omxplayer の代わりにvlc を使うとコマンドラインからの操作で動画再生が、だいぶ違うんですが、どうしたらいいでしょうか。

しばらくは debian/busterでLTSがあるから行けるとしても、将来的にどうなるかわからないですよね。ある程度ネットに情報がたまるまで、2021.01 にアップグレードはちょっと見送りたい。

OpenMAXのサポートに関する問題。(2023-02-03 追記)

開発元のレポジトリ によると、OMXplayer はOpenMAXのO-M-Xであって、OpenMAXを利活用する目的で開発されているが、OpenMAX自体が停止されていて、Raspberry４からは64bit版になったので、OpenMAX自体が導入できない。OpenMAXは32bit版しか提供されない。それにより、32bit版のRaspberryPiで動くだろうが、64Bit版では動作不可能。ということらしい。LEGACY（32bit)であれば当面は動くので問題ないと考えられる。

では64bit版でCLIから操作できてハードウェア支援があるソフトウェアがあるかと問われても、vlc のcli版のcvlc はキーボード操作に不安があるし、ハードウェア支援もいくつかのところでまだ未完成っぽい。動画を再生したいなら32bitにしておいたほうが未だに無難かも知れない。

QSVがLinuxで楽に使えるようになったみたい

準備

• debian non-free を有効に
• debian multimedia を有効に

これらを有効にすれば使える。昔に比べて圧倒的に楽。

ぶっちゃけ、時間を掛けてインストールしても画質悪いし、そこまで使うわけじゃない。

ただ、インストールが手軽だと、急ぐときに使う選択肢としてありかもしれない。

インストール

sudo apt-get install libva-dev libmfx-dev intel-media-va-driver-non-free vainfo ffmpeg

使ってみる。

mpeg2 を h264 へ

ffmpeg \
    -hwaccel qsv\
    -hwaccel_output_format qsv\
    -c:v mpeg2_qsv\
    -i test.ts\
    -vf deinterlace_qsv,scale_qsv=-1:720\
    -c:v h264_qsv\
    -tag:v hvc1\
    -f mp4 \
    out.mp4

オプションなどの解説は、参考資料に詳しく書いてあるので割愛。

画質

画質はやっぱり・・・

元が綺麗だとそれなりには。BSプレミアムのTSファイルをやったらまぁ見るには耐える。保存には耐えないかも

監視カメラで動体検出するなら余裕で使えそう。急いでトランスコードしてスマホに出すとかなら使えそう

デコーダーとエンコーダーをCPUからQSVへ回すとCPU負荷は当然だけどめっちゃ減る。

参考資料

IntelQSVを使ったHWEncode環境 (Ubuntu20.04版) - Qiita

group shadow ファイルってなんに使うの

そういえば、 vigr を実行後に、 vigr -s をする必要があるかもしれません、とメッセージが出る。

そもそも、group shadow ファイルってなんに使うの

グループに対するパスワードを付けられる。

グループの管理者がグループ名のみを指定して  gpasswd  コマンドを実行した場合は、 パスワードの入力を求められる。

グループに対するパスワードとは？

グループをメインのグループ（プライマリ・グループ）にログインする(newgrp)すると、そのグループをメインに変更することができる。

グループにユーザーを追加するときにパスワードを要求することができる。

多分使わない。

グループにパスワードをつける

gpasswd
groupadd -p

ユーザとの比較

	ユーザ	グループ
コマンド	passwd (または useradd -p )	gpasswd ( またはgroupadd -p )

参考資料

man virgr を見ると、gshadow を見ろってことらしい。

-s フラグが指定されると、これらのファイル
       の shadow 化版である /etc/shadow と /etc/gshadow をそれぞれ編集する。

man をみてgshadow を確認すると ・・・man 5 gshadow

gpasswrd を見ろってことらしい。

NAME
       gshadow - shadowed group file

DESCRIPTION
       /etc/gshadow contains the shadowed information for group accounts.

       This file must not be readable by regular users if password security is to be maintained.

       Each line of this file contains the following colon-separated fields:

gpasswd を確認すると。

名前
       gpasswd - /etc/groupファイルを管理する

書式
       gpasswd group
       gpasswd -a user group
       gpasswd -d user group
       gpasswd -R group
       gpasswd -r group
       gpasswd [-A user,...] [-M user,...] group

説明
       gpasswd  は /etc/group ファイル (および SHADOWGRP を定義してコンパイルした時は /etc/gshadow ファイル) の管理に
       用いられる。 各グループには、管理者・メンバー・パスワードを設定できる。 システム管理者は、 -A オプションを使っ
       てグループ管理者  (複数でも可) を定義したり、 -M オプションを使ってメンバーを定義したりでき、 各グループの管理
       者・メンバーと同等の特権を持つ。

       グループ管理者は、-a オプションを用いてユーザを追加したり、 -d オプションを用いてユーザを削除したりできる。 管
       理者は -r オプションを用いてグループパスワードを削除できる。 パスワードが設定されていない時は、 グループのメン
       バーのみが newgrp(1) を用いてグループの一員になれる。 オプション -R を指定すると、 newgrp(1)  コマンドを用いた
       グループへのアクセスはできなくなる。

       グループの管理者がグループ名のみを指定して  gpasswd  コマンドを実行した場合は、 パスワードの入力を求められる。
       パスワードが設定されている場合でも、 メンバーはパスワードなしで newgrp(1) コマンドを使えるが、  メンバーでない
       人はパスワードを入力しなくてはならない。

newgrpでグループを一時的に変えられる・・・？

メンバーにグループを使われないようにすることができる。 newgrp を使っていまのメイングループ(プライマリ・グループ）を変えることができるけど、現代ではあまり使わないと思われる。

iPhoneの緊急速報エリアメール・緊急地震メールを、サイレントにする・通知をオフにする。

「緊急地震速報」と、「自治体の緊急エリアメール」、システム的には別物であり通知音も全く異なる別物であるのに、iOSでは同一の設定でしか制御できないのも困りものです。

緊急地震速報・緊急エリアメールを通知を消さずに、音だけ消す。

iOSでは、通知から音を消すことができます。

「設定 → 通知 → 一番下へスクロール」そして、緊急速報の通知から、サウンドを消すことができます。

緊急エリアメールの通知を消す。

当然ですが、通知そのものを消すことができます。

「設定 → 通知 → 最下部へスクロール」そして、緊急通知そのものを消すことができます。

ずっと懸念していた。

地方自治体に「緊急エリアメール」を運用させると「オオカミ少年」になるんじゃないかとずっと懸念していた。

この頃から、大雨が降るだけで、「注意報的」に連絡するようになっていて、私の場合１５キロ離れた別河川地域でも、洪水避難の注意報の通知が出るようになっていて、ずっと懸念していた。2017年ころから懸念していました。

地方自治体による、「緊急エリアメール」も、銀行の重要なお知らせ的な、濫用と過剰通知を感じる。

— takuya@osaka(令和最新版) (@takuya_1st) October 25, 2017

お役所に緊急通知権限持たせると濫用と誤用が出まくっちゃうぞ、と言ってたそのままの結果になりつつある

— takuya@osaka(令和最新版) (@takuya_1st) February 20, 2019

このときツイートしているのは、「洪水避難」の「エリアメール」です。しかし１５キロ離れた別河川の流域についての注意報でした。それが数日で十数回の通知でした。緊急とはなんなのでしょうか。

そして、避難訓練などといって強制送信するようになり、私は我慢の限界でした。

懸念が現実に。一晩で418回

やはり、起きてしまった、通知地獄。

このうち神奈川県は異常な回数の緊急速報エリアメールを送信。1回だけでも大音量が鳴る緊急速報ですが、深夜に大量に送信。横浜だけで12回、沿岸部だけではなく内陸部にまで送信しており、418回送信されていることがわかります。これについてSNS上では苦情や批判、怒りの声が多数投稿されています。 https://smhn.info/202201-etws-kanagawa

最終的に、一晩で600回超える通知が確認されています。

今後、見直されるとは思いますが。「安全」のためという大義名分のために、また「責任回避」のために、今後もずっと乱用・誤用されることでしょう。

危険と安全の線引の難しさ

「津波」の危険性は、沿岸部で就寝時にあります。地震による揺れがなくても波にさらわれる恐れがあります。

しかし、日常生活を営んでいる場合、邪魔でしかありません。スマホの通知ではなく、沿岸のスピーカーなどでやるべきでしょう。

「洪水」の危険性は、大雨のあとに時間差にあります。豪雨がなくても「堤防決壊」による洪水の恐れがあります。堤防決壊が就寝時に起きたら目も当てられませんが、逃げ遅れる程に切羽詰まる前に、予想可能なのではないでしょうか。

「地震速報」は、本当に命に関わるのでオンにしておきたいところですが、都会にいると周囲の誰かのケータイが鳴るので、周囲の携帯の方が通知が早いことすらあります。

津波・洪水はともに、「浸水危険区域」で海抜と堤防強度から予測されています。めたらやったら出すものではないと思います。

緊急地震速報が、端末の「GPS」情報を用いて「細やか」な通知をできるようになるまで、通知は狼少年になる運命なのです。

安全のためという正義のために、私は日常生活が脅かされることを望みません。

「緊急地震速報」と、「自治体の緊急エリアメール」が同一に運用されていることが我慢なりません。システム的には別物であり通知音も全く異なる別物であるのに、iOSでは同一の設定でしか制御できないのも困りものです。

御用が誤用にならないように

御役所の要件による御用通知が、誤用・濫用にならないよう、十分に気をつけて運用してほしい。

通知をオフにしなくても良いよう、緊急エリアメールの適切な運用を切実に望みます。

gitのdiff/difftoolぜんぜん違うんですよ。

git diff/difftool の違い

git で差分をみるとき、git diff と git difftool は違う。

git diff は diff コマンドでよく見る形式

git diff 

git difftool は 任意の差分コマンド、大体の場合vimdiff

git difftool

gitのdiff/difftoolぜんぜん違うんですよ。

私もすっかりわすれて、勘違いしていました。

むかしむかし、ちゃんとやったのに、すっかり忘れてた。

私と同じ、うっかりをやった人もネット検索するとたくさん見つかります→　git-diff と git-difftool を混同していた話 - ばうあーろぐ

git df でショートカットに登録

~/.gitconfig にファイルを入れる。

[diff]
  tool = vimdiff
[difftool]
  prompt = false
[alias]
  df = difftool

これで、 git df とか。楽に呼び出せる。

gitでdiffをみるのが一番ラクですが、git diff だと表示が乱れるとか、エスケープ・シーケンスを解釈できずに不可視文字が見えちゃうときに便利ですね。

/var,/homeに設置した systemd ユニット・ファイルが実行されない

/var に設置した systemdファイルが読み込まれない。いくら正しいサービスファイルを書いても、起動時にサービスが起動しないのである。

色々見ていたら、こんなエラーが遭遇した

systemdはマジ怖い

存在するファイルを実行しない

/etc/systemd/system に設置したサービス・ファイルが「存在するのに」「存在しない」と言われて、起動時に実行されなくて、ずっと悩んでた。

原因がわかった。/home,/varマウントのタイミングだった

systemdが実行されるタイミングと私達が動作チェックするタイミングが異なる。

systemdが、サービスを実行するタイミングでは、ファイルシステムの一部はマウントされてない。そう /home も /var も /optもマウントされてない。

しかし、私たちが、動作チェックをするときは、すべてがマウントされたあとにssh ログインをして動作チェックをしているのだ。

再現方法

• /home を別ボリュームにする
• /etc/systemd/systemに /home/takuyaへのシンボリックとしてユニットファイルを設置する

これで、おかしなことができる。ユニットファイルが存在し動作も完璧。しかしsystemdに、file not found. のエラーを吐かせることができる。マウントのタイミングが異なるのだ。

依存関係がおかしいとかではなく、単にファイルが読み出せないのである。ファイルが読めないから依存関係の定義も読めないのである。

サービスファイルのリンク先が見つからない。

$ dmesg
[   11.819468] systemd[1]: smtp_proxy.service: Failed to open /var/repos/smtp-proxy/etc/systemd/smtp_proxy.service: No such file or directory

そうなんですよね。マウント前に、サービスが起動する。リンクをたどってユニットファイルを読み込もうとしても、マウントされてないのである。だから絶対に起動しないのだ。

シンボリックリンクとマウント時点の問題点

シンボリック・リンクを辿れないで systemd service が file not found のエラーを吐く場合

/etc/systemd/system にシンボリックリンクを設置してた場合

$ls -l /etc/systemd/system
iperf3@192.168.2.5.service -> /home/takuya/samples/iperf3@.service

このように、ホームディレクトリに、サンプルで作ったservice ファイルやtimerファイルなどのユニットを設置していた場合

そして、それをシンボリック・リンクで、/etc/systemd/systemに設置した場合。

このsystemdファイルは絶対に実行されない。

homeがマウントされるより先にsystemdファイル実行される

/etc/systemd/system が利用可能になった時点で、systemdはサービスを起動する。

しかし、その時点では/homeは存在するが、マウントされてないので、 /home/takuya はまだ存在してない。

そのために、/etc/systemd/system/に設置したファイルのリンク先を辿れない。

結果として、dmesg に service file not foundが大量に記録されることになる。

/etc/systemd/system とマウントの関係に注意

マウントされるよりさきに/etc/systemd/system が実行されるので、リンクが辿れずに、サービスファイルが見つからなくなる。

サービスファイル内で、いくらafter/wanterd/require を書こうとも、そもそも、ユニットファイルが読み込まれないのだから。お手上げである。

以前は、こんな事は起きなかったのだが・・・ debian 11 をインストールしたときに、インストーラーのおすすめ通りvar homeをパーティション分割したので、サービスが一切起動しない結果になった。

怖い・もういや

systemdはまじ怖い。まじめんどくさい。

systemd は窓から投げ捨てたい。っていうか、一般ユーザーがサービスユニットファイルを作るとき、マウント前に起動作業することなど全く殆ど皆無である。起動処理が終わってから実行してほしいのだ。systemdが起動処理を終えてから実行してくれ。確実に起動するエントリポイントを作って欲しい。ユーザーがマウントまで意識してサービス・ユニットファイルを書くようになってるのは絶対におかしい。

/etc/systemd/system 以外に設定箇所作って欲しい。マウントとネットワークの起動処理が、全部終わったら起動する確実なやつください。

systemdは シンボリック・リンクをつかうくせに、私達がシンボリックを使うとバグを踏むのです。別ボリュームの/homeに設置したシンボリック・リンクは、マウント前になってsystemdでは動かせないのです。当たり前だけど、油断してると絶対に気づかないんです。

何も書かなくても、シンボリックリンクなら、マウントされるまで待ってほしい。

そして、なによりマウントディスクに対し systemctl daemon-reload を掛けたのであれば、リロード時にわかるはずである。警告も何も出ない。

そして、/etc/systemd/systemに記載された内容をどこかべつの /lib/systemdにコピーしてsystemd設定ファイルをつくり起動時にロードしてくれればいいのだ。それもしてないのだ。ただただ、分割先が分かりにくい init.d でしか無い。

気づくまで何時間も溶けた・・・

Linux使うならもうdocker のコンテナに引きこもって root 権限でアプリを実行することで各種の地雷を回避するのが最高なんですよねやっぱり。

systemd の /etc/systemd/systemのファイル名とAliasの関係について。

systemd の /etc/systemd/systemにファイルがいっぱい初期設定されています。

ここには、「別名」で登録したユニットファイル<も>配置されます。

ユニットの別名とは？

たとえば、ssh.service とsshd.service がある。

これらは、どちらも同じことを意味している。

ssh.serviceを見ても

takuya@:system$ sudo systemctl status ssh.service
ssh.service
● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2022-01-09 23:26:53 JST; 18min ago

sshd.serviceを見ても

takuya@:system$ sudo systemctl status sshd.service
● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2022-01-09 23:26:53 JST; 18min takuya@:system$ sudo systemctl status 

これら、２つの別名は単なる名前の違いでしかなく、実際のサービスは同じものを指しています。

これをエイリアス（別名）と呼びます。

別名はリンクファイルでしかない。

sshd.service は /etc/systemd/system に定義された「別名」でしかない。

エイリアス（別名）を変更してみる

sshd という別名を、好きな名前に変更することができる。

cd /etc/systemd/system
sudo mv sshd.service  ssh-server.sevice
sudo systemctl daemon-reload

これで、ssh-server.serivice で別名の名前を変更できる

変更結果の確認。

もともとあったAlias名＝sshd.serviceではアクセスができなくなります。

$ sudo systemctl status sshd.service
Unit sshd.service could not be found.

変更後は、自分で決めた別名でアクセスできる。

$ sudo systemctl status ssh-server.service
● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2022-01-09 23:26:53 JST; 24min ago

このように、別名の実際は、単なるリンク・ファイル名がサービス名称として機能しています。

では、この別名ファイルはどこのタイミングで生成されるのでしょうか。

ユニットファイルのAlias定義

systemdのユニットファイルにはAliasという記載があって

$ cat ssh.service
[Unit]
Description=OpenBSD Secure Shell server
(略)
[Install]
WantedBy=multi-user.target
Alias=sshd.service

Alias=sshd.service と記載されているのです。しかし、Alias（別名）はインストール時に使われるだけで、実際には、/etc/systemd/systemに作ったファイル名が「サービス名称」として認識されます。Alias記述は、「インストール時に/etc/systemd/systemにリンクを作成しろ」という命令でしかありません。

ユニットファイルより、実際にリンク名のほうが優先

Aliasはインストール時に使われるので、その後、そのファイルがどこに配置されて、どのような名前になっているのか一切わからないのです。

別名はめんどくさい。

systemctl を使っていると「同じサービス」が「違う名前」出てくるんだけど、単なる別名でリンクが貼り付けられていると考えたら良さそうです。

ほんとうに、systemdは面倒な子です。

ユニットファイルのAlias記述を見ても実際のサービス名称が保証されない管理機構なので、ユニットファイルに完全に信頼できない。と考えるとちょっと空恐ろしい気がします。

定義ファイルに記載した名前より、実際のリンクファイルのファイル名を優先している現状は、意図しないコードの実行を引き起こす可能性が上がってしまう、チェックが漏れる。勝手にリンクを書き換えられえて同名のエイリアスを乗っ取られるなど、ちょっと考えただけでもセキュリティ懸念があります。 /etc/systemd/systemはいずれ技術的負債になっていく。そんな気がします。