ChatGPT + DALLE-3にダジャレ絵を描いてもらう

ネタを考える

ひよこ豆のカレーたべながら「何がひよこなのかなー」って思う、とかそういうの。

ChatGPTさんにたのむ

「ひよこの形の豆」「20粒くらいが皿に盛られているように」だけで十分な感じのクオリティに……。なにも解説することがない……。

ひよこ豆のイラストができるまで

An illustration of a white porcelain plate filled with approximately twenty chick-shaped beans. Each bean should have unique but subtle variations, such as slightly different poses or expressions, to give a sense of individuality. The chick-beans should be a soft yellow color, with small wings and beaks, and the plate should be set against a light, neutral-colored table to keep the focus on the chick-beans. The composition should be from a slightly above angle to show both the chick-beans and the plate clearly.
ひよこ豆のイラスト

Altにプロンプトがありますが、ひよこそれぞれがちょっと違うポーズや表情をとるよう指定していたりして芸が細かいです。

An illustration of a humanoid figure made out of a block of salt. The figure should be sculpted from salt, showing crystal-like textures and transparency that characterizes salt crystals. The form should be simple but clearly human in shape, with discernible head, arms, and legs. The figure should be positioned in a neutral stance and placed on a plain background to emphasize the material and the humanoid form. Light should be used to enhance the sparkling, translucent qualities of the salt.
サラリーマンのイラスト

RHEL9のインストーラでrootのパスワードによるsshログインを許可したあとで拒否する話

問題

  1. RHEL 9のインストーラで、rootのパスワードを使ったsshログインを許可してインストールをおこなう。
  2. そのあと /etc/sshd/sshd_config 末尾に PermitRootLogin no のように書いても無視される。

なんでですかね?

インストーラのやること

RHEL 9のインストーラで、rootのパスワードを使ったsshログインを許可すると、 /etc/ssh/sshd_config.d/01-permitrootlogin.conf が作られて PermitRootLogin yes が記述される。

rootパスワードの設定画面。「パスワードによるroot SSHログインを許可」というチェックがある

作成される /etc/ssh/sshd_config.d/01-permitrootlogin.conf はこんなかんじ。

# cd /etc/ssh/sshd_config.d/
# ls
01-permitrootlogin.conf  50-redhat.conf
# cat 01-permitrootlogin.conf 
# This file has been generated by the Anaconda Installer.
# Allow root to log in using ssh. Remove this file to opt-out.
PermitRootLogin yes

sshdがやること

このファイルは /etc/ssh/sshd_config から Includeにより読み込まれている。

# cat /etc/ssh/sshd_config
(略)
# To modify the system-wide sshd configuration, create a  *.conf  file under
#  /etc/ssh/sshd_config.d/  which will be automatically included below
Include /etc/ssh/sshd_config.d/*.conf
(略)

sshd_configは同じディレクティブを複数回指定すると最初だけ有効になり、２回目以降の指定は無視される。そのためたとえば /etc/sshd/sshd_config 末尾に PermitRootLogin no のように書いても無視されるようになる。

なおsshdの設定内容がどう評価されたを確認するには sshd -T コマンドをつかう。

# sshd -T|grep -i root
permitrootlogin yes
chrootdirectory none

対策

Includeより手前なら同じ理屈で sshd_config に書いた方が有効だが、2回同じ設定がでてると人間が混乱する。変更するときはファイル 01-permitrootlogin.conf を消すのがおすすめ。

背景

  • 昔ながらのやりかただとインストーラでの指定と管理者の意図は一貫しているが、クラウドプロバイダーが用意したイメージをデプロイする場合などではそうとは限らない。そこでインストーラでの指定と反対の指定をあとで行うようなシーンが登場する。
  • パッケージ管理やAnsible、OpenSCAPなどを利用した自動的な設定との相性のよさから、 /etc/〜〜.d/*.conf のような分離されたファイルを配置するだけで設定を行えるような変更が徐々に広がっている。一方で設定作業を行うときには特定の1ファイルしか目に入っていないことがあるのでハマりどころになりがち。
  • sshdが2回目の設定を無視するときには特に警告などの表示はない。

2022年4月に呟いたRHELネタ

RHEL8

2022年3月に呟いたRHELネタ

RHEL 9

RHEL 8

RHEL一般

パートナー

その他

voicepeak買ってあそんでる

3/11に発売されたVOICEPEAKを買ってあそんでいます。 動作環境はUbuntu 18.04以上ということなんですが、手元のFedora 35でも動きました。最初の体験版は日本語入力ができなかったんですが現在は問題なく入力できています。

公式で予約して15800円で買ったんですがDLsiteとかでクーポン使うほうが安くなるらしいです。

www.dlsite.com

で、やりたかったblog読みあげをやってみました。かなりいい感じで読んでくれます。 「レッドハットの森若です」ってところがさわやかイケボすぎて同僚が吹きそうになったらしい。すまんw

rheb.hatenablog.com

英語の記事をDeepLで翻訳して読ませるだけでかなりそれらしくなってくれるのすごい。

www.youtube.com

なつかしの2chコピペを喋らせてあそんでみました。

現状のメモ

バージョンあがったらいろいろ良くなるだろうと期待しているんですが現状気付いたポイントのメモです。

発声の特徴

  • 「」とか,や-でつまる時間は長め。連続すると苦しそうになる。
  • 感情の設定しなくても呼気多め。文末で目立つ。
  • 聞きとりやすいが圧が強いので日常会話っぽくゆるくするのは難しい。

テキスト→読みあげ変換

  • 半角カナは読めない。
  • アルファベットで英単語を書いてもある程度カタカナ読みしてくれるけど辞書にない単語が多い。
  • 英単語は大文字小文字を区別する。辞書にある単語の最初を大文字にするとほとんど全滅する。ユーザ辞書登録に大小文字を無視するオプションが欲しい。
  • なぜか「うp」とか読める
  • ?をつけても疑問文になって声のトーンあげる処理はない。
  • ポーズが長め。ききとりやすいがスピード感を出したい時は最小の50%にしたほうがいい。
  • ブロック間の空き時間はかなり自由に設定できる。
  • .srtファイルを読み込むと任意のタイミングで発声させられる。英語動画を翻訳するとかで使えそう。

UI

  • エディタは直感的だがキーボードショートカットやtabでの移動がほとんどない。マウス操作が必須。
  • 辞書登録は都度辞書ウィンドウを出して、単語登録ウィンドウで登録、登録したあと辞書ウィンドウを閉じると反映される。 複数単語を登録するときに都度単語登録ウィンドウが開くのでいったりきたりが地味にめんどくさい。あと登録語と読みの入力をtabで移動できなくてマウス必須。
  • CLIやAPIはない。vppファイル(voicepeakのプロジェクトファイル)を指定して起動はできるがそこまで。複数テキストファイルをまとめて音声に変換とかは難しそう。

ファイルの編集と置き換えの違い または シェルスクリプトの安全な置き換え

この記事の目的

unixでのファイルの編集と置き換えの違いをまとめます。

  • unix系OSでのファイルの編集と置き換えの違いについて説明する。
  • シェルスクリプトの編集により事故が起きる仕組みを理解する。
  • 安全な置き換えの手順を理解する。

ファイル名→inode→ファイル実体の対応づけ

UNIX系OSのファイルシステムは、「ファイル名→ファイル実体」という対応関係ではなく、間にinodeを挟んだ「ファイル名 → inode → ファイル実体」という対応づけを行っています。

f:id:mrwk:20211230113629p:plain
inodeを経由した対応関係のイメージ

「ファイル名→inode」の対応づけは、ディレクトリエントリにより行われます。 ディレクトリ内でファイル名とinode番号の対応づけが行われていて、ls -iなどで確認できます。

「inode→ファイル実体」の対応づけは、ファイルシステム内部で行われ、ユーザからは隠されます。

inodeは、ファイル種類の情報、ファイルのアクセス権限やタイムスタンプ、ディスク上のどこにファイルの実データが存在するかというメタデータを保持するデータ構造です。inodeには番号がついていて、(デバイス番号、inode番号) の組み合わせでファイル実体がシステム全体の中で一意に定まります。

inodeを確認するコマンド例

ls に -i オプションをつけると、ファイルの inode番号を見ることができます。以下は / ディレクトリで ls -i をする例です。

$ ls -i /
  123242 bin        141 home   33709218 mnt      19489 run   16892486 tmp
     128 boot    123245 lib    50497111 opt        144 sbin  33575067 usr
    1025 dev        143 lib64         1 proc       142 srv   50331777 var
16777345 etc   16892485 media  33575041 root         1 sys

この例ではinode番号が同じ1のディレクトリが複数存在することがわかります。これはそれぞれ別のファイルシステムのmount pointで、各ファイルシステムのinode番号1番が付与されているためです。

lsofコマンドで、あるプロセスが扱うファイルを一覧することができます。DEVICEという欄がデバイス番号です。"253,0"のようにmajor, minorの2つの数字の組み合わせです。NODEという欄がinode番号です。 50498017 のように1つの数字が表示されていることがわかります。

$ lsof -p $$
COMMAND  PID     USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
bash    2734 kmoriwak  cwd    DIR  253,0     4096 33575046 /home/kmoriwak
bash    2734 kmoriwak  rtd    DIR  253,0      224      128 /
bash    2734 kmoriwak  txt    REG  253,0  1150584 50498017 /usr/bin/bash
bash    2734 kmoriwak  mem    REG  253,0  9253600 51182031 /var/lib/sss/mc/passwd
bash    2734 kmoriwak  mem    REG  253,0    46280  1156751 /usr/lib64/libnss_sss.so.2
(中略)
bash    2734 kmoriwak    0u   CHR  136,0      0t0        3 /dev/pts/0
bash    2734 kmoriwak    1u   CHR  136,0      0t0        3 /dev/pts/0
bash    2734 kmoriwak    2u   CHR  136,0      0t0        3 /dev/pts/0
bash    2734 kmoriwak    3r   REG  253,0  9253600 51182031 /var/lib/sss/mc/passwd
bash    2734 kmoriwak  255u   CHR  136,0      0t0        3 /dev/pts/0

念のため ls -i /usr/bn/bash をして対応していることを確認しておきましょう。

$ ls -i /usr/bn/bash
50498017 /usr/bin/bash

ファイルの編集

当たり前に聞こえますが、通常のファイルは書き換えることができます。 echo でファイルに書き込んで、内容を編集してもinodeは同じままであることを確認します。

$ echo hoge > hoge.txt
$ ls -i hoge.txt
9871508 hoge.txt
$ echo fuga > hoge.txt
$ ls -i hoge.txt
9871508 hoge.txt

他プロセスでファイルが編集された時、既存プロセスからどう見える?

1つのシステムの中で複数のプロセスが複数ファイルを操作でき、編集ができるので、あるファイルが編集された際に他のプロセスからどう見えるのかを注意する必要があります。

少なくともlinux+glibcでは、ファイル編集がされたあとの読み込みでは全てのプロセスから編集後の状態が読みだされます。(厳密な動作はlibcやカーネルの実装により変わります。NFSのような複数ホストを対象とするサービスは一貫性を犠牲にしてパフォーマンスを上げているため動作が違います。)

簡単なテストプログラムで様子をみてみましょう。 以下はhoge.txt を読んで3秒おきに出力するだけのプログラムです。

loop.py

import time

f = open("hoge.txt")
while 1:
    f.seek(0)
    print(f.read())
    time.sleep(3)

これを実行しながら、他の端末で書き換えます。

$ echo hoge > hoge.txt 
$ python3 loop.py
(別の端末で) $ echo fuga > hoge.txt

echoでhoge.txtを書き換えたあと、loop.pyの出力がhogeからfugaに変わることがわかります。

ファイルの置き換え

ファイルの置き換えは、新しいファイル実体を作成して同じ名前に置き換える操作です。inodeに注意してmvコマンドによる置き換え操作をみてみましょう。

$ echo hoge > hoge.txt
$ ls -i hoge.txt
9871798 hoge.txt

$ echo fuga > fuga.txt
$ ls -i fuga.txt
9872073 fuga.txt

$ mv fuga.txt hoge.txt
$ ls -i hoge.txt
9872073 hoge.txt

「hoge.txt というファイル名から内容をみると"fuga"になっている」という点はさきほどの編集と同じですが、inode番号が変わっています。

他プロセスでファイルが置き換えられた時、既存プロセスからどう見える?

置き換えにより既存プロセスからどう見えるかを確認しましょう。 さきほどのloop.pyを実行しながら、他の端末で書き換えます。

$ echo hoge > hoge.txt 
$ python3 loop.py
(別の端末で) $ echo fuga > fuga.txt
(別の端末で) $ mv fuga.txt hoge.txt

今回は loop.py の出力が変わらず、hogeのままであることがわかります。 そのままloop.pyを終了せずに、loop.pyから見たファイルの状態を見てみましょう。

$ ps aux|grep loop.py
kmoriwak    4450  0.0  0.0  32224  8704 pts/0    S+   12:30   0:00 python3 loop.py
kmoriwak    4535  0.0  0.0  12136  1140 pts/1    S+   12:30   0:00 grep --color=auto loop.py
$ lsof -p 4450
COMMAND  PID     USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
python3 4450 kmoriwak  cwd    DIR  253,0       37 35375171 /tmp/test
python3 4450 kmoriwak  rtd    DIR  253,0      224      128 /
(中略)
python3 4450 kmoriwak    3r   REG  253,0        5 35375173 /tmp/test/hoge.txt (deleted)
$ ls -i hoge.txt
35375180 hoge.txt

ファイル名のあとに(deleted)とあります。これは現在同じ名前で確認できる /tmp/test/hoge.txt とはinode番号が違う別のファイルを参照していることを示しています。

f:id:mrwk:20211230125255p:plain
ファイル置き換え時のイメージ

シェルスクリプトの編集により事故が起きる仕組み

シェルスクリプトを実行するときには、(例外はありますが)実行と読み込みを交互に行います。簡単に確認してみます。

ゆっくり実行されるシェルスクリプトyukkuri.shを作ります。

yukkuri.sh

sleep 3
echo hoge
sleep 3
echo fuga
sleep 3
echo piyo

strace経由でyukkuri.sh を実行して、プロセスの動作を見てみましょう。

$ strace -e read,write -o out.log bash yukkuri.sh

このような出力が得られます。

(略)
read(255, "\nsleep 3\necho hoge\nsleep 3\necho "..., 55) = 55
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=30951, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
read(255, "echo hoge\nsleep 3\necho fuga\nslee"..., 55) = 46
write(1, "hoge\n", 5)                   = 5
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=30952, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
read(255, "echo fuga\nsleep 3\necho piyo\n", 55) = 28
write(1, "fuga\n", 5)                   = 5
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=30953, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
read(255, "echo piyo\n", 55)            = 10
write(1, "piyo\n", 5)                   = 5
read(255, "", 55)                       = 0
+++ exited with 0 +++

最初にELFなんとかやGNUなんとかが読み込みされているのはライブラリの読み込みや初期化で、 SIGCHLDは、sleepプロセスの終了を意味しています。 スクリプトの続きを読むこととコマンドの実行を繰り返していることがわかります。

このreadを行う前にファイルの該当部分を編集することで、実行中のスクリプトの内容が一部変更されます。実際に試してみてください。

mattnさんの記事を読むともっとよくわかります。 zenn.dev

安全な置き換え方法

mattnさんの記事でもvimで上書き(置き換え)、cpで上書き(編集)、tarで上書き(置き換え)により再現有無が異なっていますが、利用するツールによりファイルが既に存在する場合の動作が異なります。オプションにより動作が変わるものもあります。不安がある場合は素振りをしてinode番号が変更される事を確認しましょう。

編集するもの:

  • cp
  • dd
  • シェルのリダイレクト
  • エディタの一部

置き換えするもの:

  • mv
  • tar
  • rpm, debなどのパッケージインストール
  • エディタの一部