azureの試験利用終わったから、しばらくsteamでゲームでもやろっかなと思ったらローカルlinuxのubuntuのaptでゴロっとモジュールが置き換わってた。
もしかしてとendoflifeのページ見たら4月末にubuntu24出てるやん。
22のときはjellyfishでクラゲ。
水族館で涼しげに泳いでるのな。
numbatってなんや?
wikiで見たらフクロアリクイってリスみたいな感じの可愛いのが出てきた。
けど壁紙は王冠っぽい絵柄。
なんやろね。
ローカルlinuxは自分にとっては母艦で、いろんな役割持たせてるから、24への引っ越しは時間かかる。
dockerのローカル開発サーバとしてだけやなく、中間的なバックアップ置き場やったりクラウドへの入り口やったりするから、ちょっとずつ引っ越す。
インストールから稼働確認まで
まずは入手
今まではデスクトップ版を使ってた。
今回はUbuntu DesktopやなくてUbuntu Serverでやってみる。
5分もかからずisoイメージのファイル手に入る。
desktopやなくてserver
基本に立ち返って、できるだけ不要そうなものは入れずに使い始める。
それでもGUI使うのやめるわけやない。
んじゃ、導入。んんん? 日本語ないやん。後でロケール足す。
キーボードは日本語配列選べる。
ルートボリュームはubuntu22のときと同じ200GB。レイアウトは変える。ほんまはそんな要らんけど、まぁ何か新しいことやり始める時は欲しくなるからええか。
入れたいパッケージは決まってるけど手動で入れたいからいったんこのまま。
30分ぐらい待つ。
shutdownでブートするまで、その間朝メシ食っとこ。
GUI使えるようにする。
# apt-get update
# apt-get upgrade
# apt-get -y install ubuntu-desktop
# shutdown -r now
起動してきたらこんな感じ。
ロケールとかタイムゾーン設定してへんから時間は9時間ズレとるのぉ。
liberofficeも入ってるっぽいな。
後で使わんアプリは外そ。
まずはタイムゾーン変更とロケールの日本語化しとく。
# timedatectl set-timezone Asia/Tokyo
# apt -y install language-pack-ja-base language-pack-ja
# localectl list-locales | grep -i ja
# localectl set-locale LANG=ja_JP.UTF-8 LANGUAGE="ja_JP:ja"
# source /etc/default/locale
キーボードがpc105なんやな。
GUIでも設定画面あるやん。
たまにしか使わんから、まぁこれでええ。
なんか起動に時間かかる
1分ぐらい待たされる。
どこかなってsystemd-networkd-wait-online.service
ってのがゆっくりしとる。
解決しようとしてる人がいた。
作者さん調べてくれてありがとう。
なるほど、自己責任で「対処1」をやってみるかね。
# systemctl disable --now systemd-networkd-wait-online.service
OS起動待たなくなったし、GUIのLAN設定(IPとネットマスクとゲートウェイとdns)もできるやん。
そんな何度もやる設定やないし、いったんこれで行きましょ。
不要モジュールの削除
母艦で使わんモジュールは外す。
もしも勘違いとか、やっぱり必要とかなったら、また追加したらええねん。
- libreofficeはxrdpコンテナの中だけで動いてくれたらええ
- byobuターミナルってのがあるけど、普通のターミナルでええ
- remminaはrdpクライアントで使わん
- rhythmboxは音再生関連、macで足りてる
- thunderbirdはメールクライアント
- cupsとprinter-driver*は印刷系やしいらん
- modemmanagerってモデムなんか使ってへんがな
- pppとpptpってそんな昔の接続サーバ作らんし使わん
- saneってスキャナ系やったしいらん
- usbとワイヤレス系はデバイスとして使わん
- 最後にapt autorermoveで使わんくなったモジュールを掃除
やってみたのはこんな内容。
# apt remove libreoffice*
# apt remove byobu/noble
# apt remove remmina*
# apt remove rhythmbox*
# apt remove thunderbird*
# apt remove cups* printer-driver*
# apt remove modemmanager*
# apt remove ppp* pptp*
# apt remove sane-*
# apt remove usb-* wireless-*
# apt autoremove
モジュールの追加
自分のメモ使って入れてく。
apt-get install open-vm-tools
apt-get install nmon
apt install openssh-server
apt install xrdp
apt install mailutils
apt update
apt install postfix
apt install nkf
apt-get install apt-transport-https ca-certificates gnupg
google-cloud-sdkだけ入らんかったから、調べなおすか。
1日目はいったんここまで。
運用スクリプトまだ入れてないから、手動で綺麗にしとこ。
# apt autoremove
# apt clean
# apt update
# apt upgrade
必要モジュールの追加
大昔はdbとかアプリサーバとか地味にインストールして設定してた。
docker-ce使うようになってから、そういうの一切なくなった。
この負担軽減はデカい。
dockerfileと永続化領域だけコピーしてビルドしなおしてコンテナ動かすだけ。
前はldapサーバとかredhatのコンテナにフォーカスしてて、毎日何か検証してたときがあった。
phpのアプリをdjangoで作り直してたときもあった。
/etcの中の設定を試行錯誤しながら作ってるのもコンテナの中だけで済むなら、母艦の/etcはぐちゃぐちゃにならずに済む。
ファイルサーバとdockerコンテナへのリンクのためのapache設定と、普段使いの業務データのためのsambaだけは手動で入れる。
ということで、rootでやってみたメモはこんな感じ。
apt-get update
apt-get upgrade
apt install samba
apt install apache2
apt install rclone
apt-get update
apt-get install ca-certificates curl
install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
chmod a+r /etc/apt/keyrings/docker.asc
echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
$(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
rcloneの設定
設定ファイルの$HOME/.config/rclone/rclone.cnf
をコピるだけでいったん動いた。
手動で設定やると面倒なのな。
googleのアカウント設定で承認とか、APIからパスフレーズ取ってくるとかもやらずに済む。
運用スクリプトから呼び出してる処理でgoogledriveの一覧表示させる箇所を手動で動かして動作確認OK。
# rclone --config /home/nari/.config/rclone/rclone.conf lsl GoogleDrive:/ | more
gcloudの導入とポートフォワード
cli入るんかな。
google cloudにつながるようにgcloud init
は手動でやらなアカン。
やり方書いてあるページあるからやってみよか。
macのchromeでgmail開いて、アカウント管理とかで承認したら使えるようになった。
実際にデータvmdkマウントして維持
ubuntu22にくっつけてたvmdkをubuntu24につける。
ユーザIDの番号がそろってたら完全に所有権一致して使える。
ubuntu22はipアドレスを予備のもんに変更して、ubuntu24を母艦用のipに変更する。
rtx1210のdnsで名前解決されるから、teratermマクロの接続先も新しいほうに向いていく。
ここまで2日目。それほど大きなトラブルないやん。
コンテナのビルドと利用
このへんの方法でビルドしてく。
mariadb/django/ssl/xrdp/oracle21のコンテナをビルドして稼働。
できたdockerイメージはこんな感じ。
root@nafslinux-ubu24:/docker# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
sv_django 5 5b45fe13cede 24 hours ago 1.04GB
docker-sv_jupyter latest d053988eda0b 24 hours ago 1.7GB
mariadb 1011 4a5f2c1a4752 24 hours ago 401MB
oracle/database 21.3.0-ee abfeccc47b04 24 hours ago 7.94GB
gvis-ubu22 22gvis 288899a3cdfc 24 hours ago 3.72GB
ubu 22gvis 3314336c4a98 24 hours ago 3.51GB
steveltn/https-portal 1 0a68b1bbe5be 4 months ago 351MB
root@nafslinux-ubu24:/docker#
コンテナも元気に動いてくれる。
マシン変えてもちゃんと動くし冪等性って楽やわぁ。
root@nafslinux-ubu24:/docker# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
082b4945f5d4 steveltn/https-portal:1 "/init" 24 hours ago Up 2 hours (healthy) 0.0.0.0:30080->80/tcp, :::30080->80/tcp, 0.0.0.0:30443->443/tcp, :::30443->443/tcp docker-sv_https-portal-1
87883d283828 mariadb:1011 "docker-entrypoint.s…" 24 hours ago Up 2 hours 0.0.0.0:13306->3306/tcp, :::13306->3306/tcp docker-sv_mariadb1011-1
24474f90f9ab gvis-ubu22:22gvis "/usr/bin/run.sh nar…" 24 hours ago Up 2 hours 0.0.0.0:33389->3389/tcp, :::33389->3389/tcp docker-cl_ubu22gvis-1
dd903af1d21b sv_django:5 "supervisord -n" 24 hours ago Up 2 hours 0.0.0.0:38080->8080/tcp, :::38080->8080/tcp docker-sv_django-1
3e2d2de0ef35 oracle/database:21.3.0-ee "/bin/sh -c 'exec $O…" 24 hours ago Up 2 hours (healthy) 0.0.0.0:31521->1521/tcp, :::31521->1521/tcp, 0.0.0.0:35500->5500/tcp, :::35500->5500/tcp, 0.0.0.0:35501->5501/tcp, :::35501->5501/tcp docker-sv_ora21-1
99a748a52bf0 docker-sv_jupyter "jupyter-lab --allow…" 24 hours ago Up 2 hours 0.0.0.0:21088->8888/tcp, :::21088->8888/tcp docker-sv_jupyter-1
1ff2c94aee07 ubu:22gvis "/usr/bin/run.sh nar…" 24 hours ago Exited (0) 24 hours ago condescending_shaw
root@nafslinux-ubu24:/docker#
windowsから利用
samba共有でzipのバグに気づいたのと、apache2で少しハマったのでメモ。
sambaはええけどzipがうまくできん
sambaで共有してる領域はデータとプログラムの両方が入ってる。
プログラムってのは、vscodeとかa5sqlのポータブル版を置いてインストールなしで使ってる。
vscodeは起動オプションに”–no-sandbox”って足したけど、winmergeとかwinscpとか他はスンナリ動いた。
普段使うファイルは、ときどきバックアップ領域に書いてからzipで固めてるんやけど、zipにバグあるらしくてヘンなメッセージ出てきた。
root@nafslinux-ubu24:/nari/GVIS/98_backup# zip -r -P aaa _GVIS_Maimai_backup.zip ./Maimai_backup/
*** buffer overflow detected ***: terminated
zip error: Interrupted (aborting)
root@nafslinux-ubu24:/nari/GVIS/98_backup#
zipでバッファオーバフローってなんやねん、圧縮でけへんやんか。
ググったらubuntu24のzipでバグレポートしてる人いた。
対処はubuntu22の/usr/bin/zip使ってとかある。
どっちもzip --help
で見えるのはZip 3.0 (July 5th 2008)
なんやけど、ちゃうねんな。
クオートが入ってるような、半角文字だけで表現されてへんファイル名がアカンぽい。
応急処置でtarで固めて1ファイルにしてからzipすることにするけど、tarが入ってまうから時間が1.5倍ぐらいかかるやん。
zipのモジュールをzip24に変更しといて、ubuntu22から持ってきた。
# mv /usr/bin/zip /usr/bin/zip24
# ls -l /usr/bin/zip24
-rwxr-xr-x 1 root root 211952 4月 9 01:24 /usr/bin/zip24
# ls -l /usr/bin/zip
-rwxrw-r-- 1 nari nari 203768 6月 5 05:14 /usr/bin/zip
#
aptで更新されるまでしばらく待つかな。
はい、解決保留。
あとで気づいたけど、ubuntu24のサーバで動かすubuntu24ベースのxrdp稼働するdockerコンテナではこのzipの問題発生せん。
なんでや?
apache2でDocumentRootが出てこん
dockerコンテナのdjangoのコンテンツとか、大きめのpdfとかはapacheで管理してるhtmlにurlでリンクを埋め込んで使ってる。
このapache2でのhtmlがないと動作確認できん。
ubuntu24になった母艦のトップページを開いたら/var/html/wwwにあるindex.htmlが開いてもうた。
なんでやねん???
1つずつ調べた。
ドキュメントルートは/etc/apache2/sites-available/000-default.conf
にこう書いてる。
DocumentRoot /nari/nariDocs/smb
apache2の設定ファイルの確認。
ServerName nafslinux.intra.gavann-it.com
<Directory "/nari/nariDocs/smb">
Options Includes Indexes ExecCGI FollowSymLinks
AllowOverride All
Require all granted
AddType text/html .html
AddOutputFilter INCLUDES .html
</Directory>
許可設定あってるはずなんやけどなぁ。
ubuntu22のときはたまたま動いてたのか、ubuntu24のapache2から厳密になったのか、apache2.confの中ではダブルクオートやとアカンのか?
誤)Directory “/nari/nariDocs/smb”
正)Directory /nari/nariDocs/smb
くっそー、これだけでちゃんとページ表示できた。
ダブルクオート気づくのに1時間もかかってもうた。
画面見てるとき老眼でteratermの小さな文字苦しいから、自分としての再発防止策はフォントのポイントを1つ上げといた。
ちゃんと一覧表示できるか確認。
ムービーもちゃんと表示できるし、音も鳴ってる。
しっかしブラックレインの富三郎さんと優作さんカッコええ。
なんで今までhtmlの自分のトップページ表示できてたんかなぁ。
たぶん思い違いしてるんやろな。
ここまで3日目。
次は2日後ぐらいに続きやるかな。
google cloudのマシンとつながるか
昨日まででgcloud init
できたし、動かしてつないでみる。
普段は運用スクリプトをteratermマクロで動かしてるから一瞬で終わるけど、母艦の引っ越しなので1つずつ確認してく。
使ってる運用スクリプトはこんな感じ。
nari@nafslinux-ubu24:/gvis/script/gcp$ cat 101_Start-gvis-nalinux.sh
date >> /gvis/log/003_gcpLog.log
echo '++++++before Start status++++++' >> /gvis/log/003_gcpLog.log
gcloud compute instances list >> /gvis/log/003_gcpLog.log
gcloud compute instances start jelly-fslinux>> /gvis/log/003_gcpLog.log
echo '++++++after Start status++++++' >> /gvis/log/003_gcpLog.log
gcloud compute instances list >> /gvis/log/003_gcpLog.log
nari@nafslinux-ubu24:/gvis/script/gcp$
動かしてから起動状態見てみる。
nari@nafslinux-ubu24:/gvis/script/gcp$ gcloud compute instances list
NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS
jelly-fslinux us-east1-b e2-standard-8 xx.xx.xx.xx xx.xx.xx.xx RUNNING
nari@nafslinux-ubu24:/gvis/script/gcp$
母艦のローカルlinuxでポートフォワーディングして、gcpのlinuxのdockerコンテナに接続してる。
ポートフォワーディングの運用スクリプトはこんな感じ。
nari@nafslinux-ubu24:/gvis/script/gcp$ cat 301_ssh-tunnelCreate.sh
## SSH option
## -N : non command-line
## -f : background
## -C : compress
gcloud compute ssh jelly-fslinux \
--project xxxxxxxxx \
--zone xxxxxxxxx \
--ssh-key-file=/gvis/script/gcp/privateKEY \
-- -N -f -C \
-L nafslinux.intra.gavann-it.com:43306:gcp-gvis-dklinux.intra.gavann-it.com:3306 \
-L nafslinux.intra.gavann-it.com:53306:gcp-gvis-dklinux.intra.gavann-it.com:13306 \
-L nafslinux.intra.gavann-it.com:50022:gcp-gvis-dklinux.intra.gavann-it.com:20022 \
-L nafslinux.intra.gavann-it.com:53389:gcp-gvis-dklinux.intra.gavann-it.com:23389 \
-L nafslinux.intra.gavann-it.com:63389:gcp-gvis-dklinux.intra.gavann-it.com:33389
nari@nafslinux-ubu24:/gvis/script/gcp$
ポートフォワーディングして、システム状態確認の運用スクリプトにあるプロセス確認だけ動かしたらこうなる。
nari@nafslinux-ubu24:/gvis/script$ ps -ef | grep ssh | grep gvis | awk '{print $29 "\n" $31 "\n" $33 "\n" $35 }'
nafslinux.intra.gavann-it.com:43306:gcp-gvis-dklinux.intra.gavann-it.com:3306
nafslinux.intra.gavann-it.com:53306:gcp-gvis-dklinux.intra.gavann-it.com:13306
nafslinux.intra.gavann-it.com:50022:gcp-gvis-dklinux.intra.gavann-it.com:20022
nafslinux.intra.gavann-it.com:53389:gcp-gvis-dklinux.intra.gavann-it.com:23389
nari@nafslinux-ubu24:/gvis/script$
awkで処理してる出現カラムがちゃんと処理できているってことは、psコマンドも大きく変わらずに使えるってことね。
普通にxrdpコンテナ使えたし、コンテナの中でfirefox/chrome使ってネットやdjangoアプリもssl経由で使えた。
gcpの停止とバックアップ処理は割愛するけど、エラーなく終わってた。
ここまで4日目。
まぁイメージのビルドで待ってる時間多かったな。
google cloudからのデータをubuntu24とdockerコンテナの永続領域に展開できるか
バックアップはgoogle driveに入ったファイル類原本とdockerの永続化領域をcyberduckで母艦にダウンロードしておく。
ダウンロードした結果がコレ。
nari@nafslinux-ubu24:/nari/nariHTTP/configBackup/01_gcp-gvis-dkLinux$ ls -lh
合計 12G
-rwxr--r-- 1 nari nari 2.1G 6月 5 06:49 Docker.zip
-rwxr--r-- 1 nari nari 21M 6月 5 06:44 gvis_conf.zip
-rwxr--r-- 1 nari nari 4.2M 6月 5 06:44 log.zip
-rwxr--r-- 1 nari nari 9.0G 6月 5 06:58 nariDocs.zip
-rwxr--r-- 1 nari nari 15M 6月 5 06:44 script.zip
nari@nafslinux-ubu24:/nari/nariHTTP/configBackup/01_gcp-gvis-dkLinux$
このzip使ってgcpのdockerコンテナの永続化領域を母艦に展開する。
省くけど、展開専用の運用スクリプトで展開。
ファイル類は、winmergeとかdiffで比べながら更新対象やその他のファイルが維持できてるか確認しながら使う。
テンポラリ置き場に今のsambaの領域を移動しといて、smbフォルダを展開してdiffで比べたらええ。
過去データのtar.gzとかzipも比べてくれるから、古いデータも維持できるか担保できる。
diff -r /nari/nariDocs/smb /nari/nariHTTP/temp/smb
mariadbのデータ維持具合を確認するときはa5sqlでだいたいこんな感じ。
-- dbmsのバージョン
select @@version ;
-- mariadbに対するオプション指定の確認
SHOW VARIABLES LIKE 'max_allowed_packet';
-- mariadbのテーブル確認
SHOW tables ;
-- データ入ってる件数の確認
SELECT count(*) FROM GVIS_keihi ;
-- betweenで月指定変えながら、経費テーブルに特定の日付のデータ入ってるか確認
SELECT * FROM GVIS_keihi
WHERE year(workPeriod) = 2024 and month(workPeriod) between 4 and 6
order by workPeriod desc , workShubetsu, workPriority ;
-- 支払った消費税が入ってるか確認
select Kamoku,Tax8Kng,Tax10Kng from GVIS_keihi where Tax8Kng > 0 or Tax10Kng > 0 ;
ubuntu24のmariadbコンテナに実際につなぐ。
後でmacの中で動いてるminikubeのポッドに向かっても同じ確認する。
件数とか金額が完全一致するのな。
minikube用のコンテナイメージを用意してminikubeで動かす
ubuntu24の中にあるコンテナはdocker save
してtarをtar.gz化してイメージ維持してる。
root@nafslinux-ubu24:/docker# docker images | grep save
save-xrdpubu22 gvis-saved 10cd6c0641e6 2 hours ago 5.13GB
save-django gvis-saved af72e40c6088 2 hours ago 1.08GB
save-mariadb gvis-saved 7d1a32843fe8 2 hours ago 401MB
root@nafslinux-ubu24:/docker#
macで動いてるminikubeへはtar.gzをtarにしてdocker load
させてイメージ維持してる。
なんでdockerはloadとsave対象がtar.gzやなくてtarなんやろな。
tarは1つのファイルにするだけで圧縮はかかってへん。
いちいちgz化したり展開もせなアカンから時間も場所も食うやん。
nari@gvis-mac script % minikube ssh
_ _
_ _ ( ) ( )
___ ___ (_) ___ (_)| |/') _ _ | |_ __
/' _ ` _ `\| |/' _ `\| || , < ( ) ( )| '_`\ /'__`\
| ( ) ( ) || || ( ) || || |\`\ | (_) || |_) )( ___/
(_) (_) (_)(_)(_) (_)(_)(_) (_)`\___/'(_,__/'`\____)
$
$ docker images | grep save
save-xrdpubu22 gvis-saved 10cd6c0641e6 2 hours ago 5.13GB
save-django gvis-saved af72e40c6088 2 hours ago 1.08GB
save-mariadb gvis-saved 7d1a32843fe8 2 hours ago 401MB
$
最近teratermのマクロでmariadbのデータを流し込むとき、エラー出始めてきた。
minikubeの中のkubernetesクラスタのバージョンを1.30に上げたら、前よりのっそり動くようになった。
こういうのは処理のタイミング調整でうまくいく。
mariadbの永続化領域とポッドを作り直した後とポッドにログインした後、ディスク同期して10秒待たせる。
念のためもう1回syncさせたら、エラーでなくなった。
wait "nari@gvis-mac"
sendln 'kubectl create -f gvis-PersistentVol-mariadb1011.yaml'
wait "nari@gvis-mac"
sendln 'kubectl create -f sv-mariadb1011-deployment.yaml'
wait "nari@gvis-mac"
sendln 'sync ; sleep 10 ; sync' ★ここ足した
wait "nari@gvis-mac"
sendln "kubectl exec -it `kubectl get pod | grep mariadb | awk '{print $1}'` -- bash"
wait "root@svmariadb1011"
sendln 'sync ; sleep 10 ; sync' ★ここ足した
wait "root@svmariadb1011"
sendln '/bin/sh /etc/mysql/conf.d/nari/fullback/2_fullRecover.sh'
wait "root@svmariadb1011"
sendln '/bin/sh /etc/mysql/conf.d/nari/fullback/4_nariDB_DjangoRecover.sh'
wait "root@svmariadb1011"
sendln 'mysql -unari -pboo'
wait "MariaDB"
sendln "show variables like 'max_allowed_packet' ; "
データベースの中の金額も1円単位であってるやん。
pythonも12で維持できてるし、ついでにdjangoもpip3でモジュール全部最新に上げた。
ここまで5日目。
実際は着手から1週間かかったな。
zipの問題は残ったけど、それ以外は引っ越し完了。
ubuntu22さいなら。
dfしたら100GBってなってたけど、dockerの置き場vmdkファイルのサイズ見たら260GBってなってた。
何入っとんねん!? docker system prune
って定期処理で動いてるのに!? それか容量詐称とかか!?
ビルドしたらいくらでも作れるから即削除。
ssdにvmdk置いてるからたまにしか実用量見てへんのはアカンな。
今見たらubuntu24のdocker置き場vmdkファイルは95GB。
dfしたら59GB。
どないなっとんねん。
って、まだrdpコンテナとgoogle cloudの中のホストは22やな。
また苦しむかもな。
cuiとguiの使いわけ
今回からubuntuのdesktopやなくてserver使い始めた。
linuxはcui、windowsはguiって決めて使う人がいるけど、自分は安全優先、次にラクなやり方優先で使う。
linuxでネットワークの設定をcuiでやったら面倒くさい。
ipアドレス設定ぐらいやったら楽やけど、dnsやったらresolve.conとか書き換え必要。
guiでやるほうが自分には直観的で楽やん。
windowsでシャットダウンをguiでアイコンをクリックしたら、クラウドやったらserver版のwindowsやからいちいち停止の理由とか聞いてくる。
「停止したいから停止のコマンド打ってんねん!理由はどうでもええやろ!ボケ!」っていっつも思う。
せやから停止はshutdown -f -s -t 60
でログオフはlogoff
って打つ。
guiのボタンは使わん。
ログオフとシャットダウンのボタンが近接してるのは、windowsではずーっと続いてるけど、なんとかならんのかなぁ。
パソコンやったらええけど、お客さんのサーバで赤いボタン押したら悲惨やで。
レジストリいじったら赤いボタン消せたような気もするけど、わざわざそんなことしてくれてること少ないし。
間違って押せんようなデザインにはならなさそうやし、やっぱりボタン使うのは怖い。
ログオフは即実行やけど、停止は間違いに気づいたら1分以内にshutdown -a
で取り消せる。
怖かったら60を300にしたら5分の猶予ができる。
windowsにはuname -n
ないからhostname
って確認するクセつけとかな、本番のホスト間違って停止したらサイアク。
自分ではやったことないけど、パソコン使ってる感覚で本番ホスト停止した人がいて、お客さんからめっちゃ怒られてた。
意識して使うのは大事やで。