クリックイベントを起こさないとテストできないページが有る。
クリックイベントをFireしたり、ディスパッチしてイベントを起こすには。MouseEventオブジェクトを使う
マウスイベントを起こそうとしたら initEventはdeprecatedだと怒られるので、今の方法を調べた。
const click = new MouseEvent('click', { bubbles: false, cancelable: false })
node.dispatchEvent(click)
const click = document.createEvent('MouseEvents');
click.initEvent('click', true, false);
node.dispatchEvent(click)
昔の方法でも、互換性で今でもちゃんと動くよ。
慣れていると、いつも同じキーしかつかわないので、たまに眺めてみて自分の操作方法を見つめ直す.
Ctrl-A ? で一覧が出ますね
例えば、SELECT は - なので Ctr-A -
例えば、ウインドウ一覧は、Ctrl-A "
などのように、使い方を模索できるので便利。
gnu screen の設定を変えたいときに、すでに時間かかる処理を走らせてしまっていた。
GNU screen の 設定をreload したかった。調べたらあっさりした解決方法が出てきた。
:source ~/.screenrc
vim みたいなコマンドモードになります。 Escapeは Ctrl-a がデフォルトです。
Ctrl - a + : + source ~/.screenrc となります。
https://serverfault.com/questions/194597/how-to-reload-screenrc-without-restarting-screen
WSLでUSBメモリにアクセスするには、drvfs を使えばいい
mount -t drvfs E: /mnt/e
WSLでドライブをマウントするのは、デフォルト動作に存在する
$ mount | grep mnt C:\ on /mnt/c type drvfs (rw,noatime,uid=1000,gid=1000,case=off)
wsl2 からは、wsl.exeからもできる
GET-CimInstance -query "SELECT * from Win32_DiskDrive" wsl --mount <DISKPATH>
dd もできるかなぁとおもったけど、drvfs はマウント済 を提供するので dd は出来ないですね。
takuya@DESKTOP-Win:$ mount C:\ on /mnt/c type drvfs (rw,noatime,uid=1000,gid=1000,case=off) takuya@DESKTOP-Win:$ dd if=/mnt/c of=test bs=512 count=10 dd: error reading '/mnt/c': Is a directory 0+0 records in 0+0 records out 0 bytes copied, 0.0014909 s, 0.0 kB/s
https://docs.microsoft.com/en-us/windows/wsl/wsl2-mount-disk
通常のアップグレード手順と同じ
sudo apt update && \ sudo apt upgrade && \ sudo apt dist-upgrade && \ sudo do-release-upgrade
Point of no Return になったら、Y/Nと Enter で最終チェックの確認がされます。あとは待つだけ。
ubuntu はアップグレードでバージョンをアップグレードするのは本当に楽ちんでいい。
do-release-upgradeを行う前に、リリースチェックをしたほうがいいでしょう。
リリースチェック
do-release-upgrade -c
アップグレード
do-release-upgrade
正式版の未リリースで、デベロッパ版を入れたい場合（LTSのリリースは遅いので注意）
do-release-upgrade -d
LTSを使っているときは、LTS版が入手可能リリースになっているか注意する。
たとえば、2022-05-01 現在では、 22.04 はリリースされているが、Ubuntu Server 22.04 LTS はまだである。
pipenv でサクッと環境を整える
mkdir tatget cd target PIPENV_VENV_IN_PROJECT=1 pipenv install pipenv run pip install pip --upgrade
PIPENV_VENV_IN_PROJECT=1 変数を使うと、プロジェクトのディレクトリに作られる。変数の名前の通りです( pipenv venv in project)。 project root で実行される。有り体に言えばカレントディレクトリ、正確言うと上位のpipenvを探しに行く。
変数を使わないときは、user homeつまり、ユーザーのホームディレクトリが使われる。
使いたいときに、python3を明示的に指定する。最近はpythonコマンドではなくpython3コマンドかもしれない。
PIPENV_VENV_IN_PROJECT=1 pipenv --python=/usr/bin/python3 install
cd target pipenv run pip install PyP100
pipインストールではなく、pipenv install を使ってインストールする
先程の例だと、次のようになる。
cat Pipfile [[source]] url = "https://pypi.org/simple" verify_ssl = true name = "pypi" [packages] pyp100 = "*" [dev-packages] [requires] python_version = "3.9"
pipenv 自体は、python pip を使って グローバルにインストールしておく。または、apt でインストールしておく
pipの場合
pip install pipenv
apt の場合
apt install python-is-python3 apt install python3-pip apt install pipenv
rbash は bash の機能の一つで 「機能制限をされたbash」を提供するためのものです。
rbash とは、制限付きのシェル(RESTRICTED SHELL) の略です。
bash -rrbash コマンドは /usr/bin/rbash で提供されていて。bash へのエイリアスになっています。
ls -l /usr/bin/rbash lrwxrwxrwx 1 root root 4 Jan 6 16:23 /usr/bin/rbash -> bash
とにかくまずは、rbash を使ってみよう
サクッと lxc でubuntuを起動して実験環境を作ります。
NAME=rbash-test lxc launch ubuntu:22.04 $NAME lxc exec $NAME -- adduser takuya lxc exec $NAME -- usermod -aG sudo takuya lxc exec $NAME -- sudo --login --user takuya
ログインの代わりにシェルを起動して代替とします。
通常であれば、bashを起動します。
lxc exec $NAME --cwd /home/takuya --user $uid --cwd /home/takuya -- bash
docker で同じようなことをするのであれば、こんな感じですよね。
docker run --rm -it ubuntu bash
通常であれば bashを起動するところが rbashになるだけです。
lxc exec $NAME --cwd /home/takuya --user $uid --cwd /home/takuya -- rbash
docker で同じようなことをするのであれば、こんな感じですよね。
docker run --rm -it ubuntu -- rbash
rbashでLinuxを使ってみます。
lxc exec $NAME --cwd /home/takuya --user $uid --cwd /home/takuya -- rbash --norc
cd やコマンドが制限されています。PATH変数は固定化されています。 /tmp は書き込めるようです。
rbash-5.1$ echo $SHELL /bin/bash rbash-5.1$ cd / rbash: cd: restricted rbash-5.1$ touch /tmp/a rbash-5.1$ mkdir .bin rbash-5.1$ export PATH=$PATH:~/.bin rbash: PATH: readonly variable
rbash は起動したディレクトリより上のディレクトリには移動できません。
例
lxc exec $NAME --cwd /home/takuya --user $uid --cwd /home/takuya/.bin -- rbash --norc rbash-5.1$ rbash-5.1$ pwd /home/takuya/.bin rbash-5.1$ cd .. rbash: cd: restricted rbash-5.1$
LXCで試しているので少しややこしいですが、rbash をexecするときに cwd=/home/takuya/.bin で起動しています。その中にchroot状態になりますが、chrootではありません。
参照もできるし、ファイルも扱うことができます。
/home/takuya/.bin rbash-5.1$ cd .. rbash: cd: restricted rbash-5.1$ ls / bin dev home lib32 libx32 mnt proc run snap sys usr boot etc lib lib64 media opt root sbin srv tmp var rbash-5.1$ echo ~ /home/takuya rbash-5.1$ touch ~/in-home rbash-5.1$
rbash の制限機能は man に書いてある通りなんだけど
もう少し詳しく書くと、次のとおりです。
シンプルに表現すれば「PATHに書いたコマンドだけに制限するのがrbash」です。
PATHによる制限が基本機能なので /bin/bashがPATHに含まれていると、制限モードは解除されたbashが起動します。
人によってはrbashでシェルは実行できないと書いてますが、bash /ruby / python などがパスに含まれているとハッキリ何でも出来ちゃいます。
rbash を使うときは PATHにはスクリプトやバイナリを設置して、自由な記述をできるようなインタプリタを設置しないほうがいいと思います。
最初にPATHを用意する。PATHを用意して、「使っていいコマンド」を列挙する
SSH の authorized_keys に書く。 ログインシェルに指定する
ということです。
ただし、~/.profile や ~/.bashrc が動いていまうと台無しになることがあるので --norcや --noprofile を使って起動するほうが無難っぽい
このように、rbash は システムの運用者に渡して少し安心できるシェルです。フル機能ではありませんが、だいたいのことはできます 。
ただし、PATHに十分に配慮すること。
コマンドを使わせるだけなら、ssh の authorized_keys でコマンド制限したほうが速いと思います。
システムコーンソールにログインする場合などには有効だと思いますが、シリアルコンソールや直接マシンにアクセスさせるくらいなら、 ssh 経由が安全だし、sshのauthorized_keysに同じような機能があるの出番はあまりないかも難しいかもしれません。
ファイルを扱うときにrbashはいいかもしれません。
シェルスクリプトを実行時にrbash実行したり、スクリプトから呼び出せば、「うっかりミス」を防ぐという意味では大活躍できると思います。
たとえば、次のようにしておけば、、、、少しは安心はできるのかもしれない。。。。
cd ~/.bin PATH=~/.bin rbash my-mis-script.sh
詳しくは man bash (man rbash ではない）を見れば書いてある。
GNU bash, version 5.1.16(1)-release-(x86_64-pc-linux-gnu)
Usage: rbash [GNU long option] [option] ...
rbash [GNU long option] [option] script-file ...
GNU long options:
--debug
--debugger
--dump-po-strings
--dump-strings
--help
--init-file
--login
--noediting
--noprofile
--norc
--posix
--pretty-print
--rcfile
--restricted
--verbose
--version
Shell options:
-ilrsD or -c command or -O shopt_option (invocation only)
-abefhkmnptuvxBCHP or -o option
Type `rbash -c "help set"' for more information about shell options.
Type `rbash -c help' for more information about shell builtin commands.
Use the `bashbug' command to report bugs.
bash home page: <http://www.gnu.org/software/bash>
$ id takuya uid=1001(takuya) gid=1001(takuya) groups=1001(takuya),27(sudo)
この結果をついgrep / awk しちゃうが、ちゃんと id コマンドで取れますよ。ってことです。
オプションを付けます。
UID (ユーザ番号) をダイレクトに取り出す。
$id -u takuya 1001
GID（グループ番号）を直接取り出す
$id -g takuya 1001
所属するグループIDを全部取り出す
$id -G takuya 1001 27
uid わかってどうするの？って思うんだけど、シェルスクリプトを書くときにUIDがわかってるとSUDOやLOGINを扱いやすいし、ファイルの所有者を調べやすいのです。
例えばLXCのコンテナで内部で、コマンドを指定ユーザで実行するとき
$ uid=$(lxc exec $NAME -- id -u takuya) $ lxc exec $NAME --user $uid -- whoami takuya
lxcのようにユーザ指定を番号でできるコマンドは多いのです。
Laravel でログを、ターミナルに出す。
laravel のログを画面ではなくターミナルへ出力する事ができる。
またターミナルとファイルに出す事ができる。
dd とかよく使います。
dd( $model );
dump もよく使います。
dump( $model );
これはログの出力先に出てきます。
Log を使った場合。
このログを、stderr に書きます。
Log::debug('ここまで到達');
config/logging.php に書きます。
'channels' => [ 'stack' => [ 'driver' => 'stack', 'channels' => ['single','stderr'],//←追加、２つの出力先 'ignore_exceptions' => false, ],
ログも「laravel チャンネル」として定義されているので、サクッといけます。
loggerヘルパ Log::debug 書くのがめんどくさい
Log::debug('ここまで到達');
logger($event->task);
これを使えば、ログを任意の場所にだしておけるので、 syslog でもいけるし、php-fpmでも見れるし、ファイルに書き出してもいい。STDEERでターミナルで見ることもできる。
grafana+prometheus でロードアベレージを監視してもいいんだけど
ちょっとログを集めたいのに、あまりにもヘビィだと思うの。
古のパッケージ sar コマンドで、CPU利用率を集計する
sar / sysstat で cpu 利用率を詳しく調査する
apt でインストールが可能
sudo apt install sysstat
楽ちん
マニュアル起動（ログ書いて終了する）
sudo systemctl start sysstat-collect.service
タイマー開始
sudo systemctl start sysstat-collect.timer
タイマー間隔（取得間隔）を調整
sudo systemctl edit sysstat-collect.timer
例えば、１５分に１回(初期値は10分に一回)
[Timer] OnCalendar=*:00/15
設定(ログ保存期間)
sudo vim /etc/sysstat/sysstat
/etc/sysstat/sysstat
# How long to keep log files (in days). HISTORY=30 # Compression program to use. ZIP="pixz" # Parameters for the system activity data collector (see sadc(8) manual page) SADC_OPTIONS=""
設定したポイント - 初期設定は１週間ほどなので、1ヶ月間位残しておく - xz は pixz を使うようにする。 - CPU統計がほしいだけなのでディスク統計は要らない。足りなくなったら買うだけだし
ログが溜まったら、取得期間全体で統計（平均）が見れられる
sudo sar
直接ログの確認(日毎ファイルになってる)
sar -f /var/log/sysstat/sa$(date +"%Y%m%d")
cat したいところだけど、バイナリなのでsar コマンドで読む
実行例
sar -f /var/log/sysstat/sa$(date +"%Y%m%d") Linux 5.10.0-13-amd64 (acid) 2022年04月28日 _x86_64_ (8 CPU) 13時41分00秒 LINUX RESTART (8 CPU) 13時41分42秒 CPU %user %nice %system %iowait %steal %idle 13時44分30秒 all 4.80 0.50 1.17 0.36 0.00 93.17 平均値: all 4.80 0.50 1.17 0.36 0.00 93.17
指定した範囲のログの確認
takuya@:~$ sudo sar -s 13:00 -e 13:59 Linux 5.10.0-13-amd64 (acid) 2022年04月28日 _x86_64_ (8 CPU) 13時41分00秒 LINUX RESTART (8 CPU) 13時41分42秒 CPU %user %nice %system %iowait %steal %idle 13時44分30秒 all 4.80 0.50 1.17 0.36 0.00 93.17 13時50分00秒 all 4.66 0.47 1.17 0.69 0.00 93.02 平均値: all 4.71 0.48 1.17 0.57 0.00 93.07
ターミナルで表示し続けるする場合。マニュアル起動で今の状態を監視ができる。 ただし、この目的なら s-tui や htop を使ったほうがいい
1秒ごとに状態を取得する
sudo sar 1
1秒ごとに状態を取得する(最大10回,1s x 10=10sで終了)
sudo sar 1 10
マルチCPUを個別に見る
sudo sar -u -P 0,1 1 10 sudo sar -u -P 0,1,2,3 1 10 sudo sar -u -P ALL 1 10
sudo sar -q 1 10
ネットワークの状態
sudo sar -n DEV 1 10
指定したIFの状態
sudo sar -n DEV --iface=br0 1 10
CPUパワーが３倍に上がったとして、どこまでそのメリットを享受できるのか
金銭コストに対し、十分な時間的なリターン得られるのか。
電気代はどの程度になりそうなのか（CPUロードアベレージから概算）
など、CPU利用率を測定して計測値を集めるといろいろ見えてきそうですよね。
qcow2 backing ファイルで複数起動した場合について調べる
d03 の仮想マシン作り、そのイメージから ２つの仮想マシンを差分として起動する。
d03 ─┬ d03.1
└─ d03.2
Backing-fileのBASEが更新されたとき、差分側はどうなるのか
virt-install\ --connect=qemu:///system \ --initrd-inject=/home/takuya/preseed.cfg \ --name d03 \ --ram 8192 \ --disk path=/var/lib/libvirt/images/d03.qcow2 \ --vcpus 8 \ --virt-type kvm \ --os-type linux \ --os-variant debian10 \ --graphics none \ --location http://ftp.kddilabs.jp/pub/Linux/distributions/Debian/debian/dists/buster/main/installer-amd64/ \ --extra-args="console=ttyS0"
オーバーレイ（差分）を作る
sudo qemu-img create \ -b /var/lib/libvirt/images/d03.qcow2 \ -f qcow2 -F qcow2 \ /var/lib/libvirt/images/d03.1.qcow2
差分を使うDebianを起動する
virt-install \ --boot hd \ --connect=qemu:///system \ --name d03.1 \ --ram 8192 \ --disk path=/var/lib/libvirt/images/d03.1.qcow2 \ --vcpus 8 \ --virt-type kvm \ --os-type linux \ --os-variant debian10 \ --graphics none
差分を使うDebianをもう一つ作る
オーバーレイ（差分）をもう一つ作る
sudo qemu-img create \ -b /var/lib/libvirt/images/d03.qcow2 \ -f qcow2 -F qcow2 \ /var/lib/libvirt/images/d03.2.qcow2
仮想マシンを作る
virt-install \ --boot hd \ --connect=qemu:///system \ --name d03.2 \ --ram 8192 \ --disk path=/var/lib/libvirt/images/d03.2.qcow2 \ --vcpus 8 \ --virt-type kvm \ --os-type linux \ --os-variant debian10 \ --graphics none
オーバーレイを使う２つは起動できる
差分を使う２つの仮想マシンは同時に起動できる
sudo virsh start d03.1 sudo virsh start d03.2
差分１と差分２を使う２つの仮想マシンd03.1/d03.2 は同時に起動できた。
これが正しい使い方である。
Baseファイルを使うd03 というベースは、同時に起動できない。
Base側を起動して
sudo virsh start d03
差分も起動すると、エラー
takuya@:~$ sudo virsh start d03.1
エラー: Failed to start domain 'd03.1'
エラー: 内部エラー: process exited while connecting to monitor: 2022-04-27T06:49:56.304604Z qemu-system-x86_64: -blockdev {"node-name":"libvirt-2-format","read-only":true,"driver":"qcow2","file":"libvirt-2-storage","backing":null}: Failed to get shared "write" lock
Is another process using the image [/var/lib/libvirt/images/d03.qcow2]?
いちどオーバーレイを作成したら大本の仮想マシンは、もはや触るべきではありません。
Base側を更新して、終了
sudo virsh start d03 --console takuya@d03:~$ rm from-base takuya@d03:~$ echo 11 > from-base takuya@d03:~$ sudo shutdown -h now
差分側を起動する
sudo virsh start d03.1 --console takuya@d03:~$ rm from-base takuya@d03:~$ cat from-base cat: No such file or directory takuya@d03:~$ sudo shutdown -h now
こうすれば、d03.1にd03の変更点が適用されそうな予感はする。が、これは禁忌である。
動かないことはないが、d03.1に変更点が適用されることもない。
https://kashyapc.fedorapeople.org/virt/lc-2012/snapshots-handout.html
NOTE: Backing files are always opened read-only. In other words, once an overlay is created, its backing file should not be modified(as the overlay depends on a particular state of the backing file). Refer below ('blockcommit' section) for relevant info on this.
Backing file は参照先からリードオンリで読み取りがされる。言い換えれば、一度オーバーレイ作成したら、backing file は編集するべきではない。（オーバーレイ側の状況によるが）、差分（オーバーレイ）側からコミットなどを参照のこと
d03.2 の差分を、d03(base)へ書き出し（commit) する
sudo qemu-img commit /var/lib/libvirt/images/d03.2.qcow2
これで、d03.2 に差分はなくなり、d03 と同じ状態になる。
d03.1 はどうなるのか？変わらない。
d03 ─┬ d03.1
└─ d03.2
d03.2 とd03 を同じ状態にしたので d03'が生じている。これは d03.1 となんの関係もない状態になった。
試した結果
d03 ─┬ d03.1
└─ d03.2
⇓ commit 後
d03 ── d03.1
d03' ─┐
└─ d03.2
上記のようになっていた。 d03(＝d03’)になっているが、d03.1は古い状態を維持していた
d03にスナップショットを作ったのと同じような状況になったと考えられる。無名のスナップショット的ものなのかもしれない。
上流から下流へ変更点を伝播 (propagate)させるなら、virsh でできるかもしれない。
virsh blockpull virsh blockcommit
man of qemu-imgをざっと見た感じだと、細かいことがよくわからない。
OSをインストールしたファイルから、複数の仮想マシンをさくっと、インストールなしで作成できる。しかもコピーもなしで作れるから快適
その程度が実現できたらいい感じ。っていう機能なのかもしれない。
コンテナ全盛期で仮想マシンの関連の記事が空気になっていて、かんたんに結論が出る情報が少ないよぉ。
ソースコードやフォーラムをたどっていくのもしんどいしあまり深く追求しないことにする。
qcow2でオーバーレイ（差分）を作ってインストールすると、仮想マシンはすぐ作れる。
このあたりに大変魅力がある気がします。
Linuxへシリアルコンソールでターミナルを使って接続するには
いくつかのポイントで使ってるオプションが違う
ブート時点で動いてるモノが違うので、それぞれにシリアルコンソールの設定が必要
インストール前にインストーラーを起動するとき
インストール後には
ということで。
インストール時
インストール後
Linux起動後
以上を踏まえると、
インストールから起動までをすべてシリアルコンソールで行う。つまりSSH経由でホストに仮想ゲストを作る方法は
という３つのインストールパターンがるが、
最初から最後までシリアルコンソールでやるには、次の２つが選択肢
これらは、--location を指定して、 extra-ages を指定する。
いろいろと、やり方はあるが、サクッとインストールできるのは次やりかた
virt-install\ --connect=qemu:///system \ --initrd-inject=/home/takuya/preseed.cfg \ --name d03 \ --ram 8192 \ --disk path=/var/lib/libvirt/images/d03.qcow2 \ --vcpus 8 \ --virt-type kvm \ --os-type linux \ --os-variant debian10 \ --graphics none \ --location http://ftp.kddilabs.jp/pub/Linux/distributions/Debian/debian/dists/buster/main/installer-amd64/ \ --extra-args="console=ttyS0"
ただし、preseedは任意
netinstall でやるより、ISOのほうがダウンロードができるんで確実
curl https:// ... /ubuntu-20.04.3-live-server-amd64.iso virt-install\ --connect=qemu:///system \ --name u05 \ --ram 8192 \ --disk path=/var/lib/libvirt/images/u05.qcow2 \ --location /var/lib/libvirt/images/ubuntu-20.04.3-live-server-amd64.iso,kernel=casper/hwe-vmlinuz,initrd=casper/hwe-initrd \ --vcpus 8 \ --virt-type kvm \ --os-type linux \ --os-variant ubuntu20.04 \ --graphics none \ --extra-args "console=tty0 console=ttyS0,115200n8" \
22.04 では試してないので、動くかはわからない、ubuntuのカーネルイメージのファイル名が変わってなかったら動くと思う。
