systemd が一般的になって、起動時のログを書くにする方法がsystemd経由になった。
journalctl /usr/lib/systemd/systemd -b
ただし、systemd が起動してからのログなので systemd が起動する以前の initrd のログを見ることはできない
全部を見たいときは。
journalctl -b
また、ブートログはこちら
/var/log/boot.log --- System boot log /var/log/dmesg --- print or control the kernel ring buffer
initrd が起動してから sytemd の init で起動し直すので、最近のLinuxのブートログはちょっとカオスかもしれませんね。
lsblk のオプションに -f があります。
lsblk にオプションをつけると、UUIDが表示されます。
takuya@:~/Downloads$ lsblk -f NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT sda ├─sda1 vfat 5601-CF5B 498.7M 2% /boot/efi ├─sda2 ext4 b051eadd-397c-42ea-b1c8-900bb4e6586e 456M 28% /boot ├─sda3 crypto_LUKS 4df88652-a2db-4aa9-b28d-2ba850132340 │ └─sda3_crypt LVM2_member TeBacs-1QVa-Za6E-Ain7-9RgV-oU3e-iBatiW │ ├─ubuntu--vg-root ext4 d2d6fb06-24ca-4f56-ae30-1e1b5cdc9df0 42.1G 55% / │ └─ubuntu--vg-swap_1 swap 0f0fbd57-d05f-4ed6-985f-1a62e61720d5 [SWAP] └─sda4 ext4 data 94eadf49-c020-47ee-b9cb-779af367cf58
ディスクの uuid を知りたいときに、 ls /dev/disk/by-id だとか叩いてもいいんだけど、lsblk のほうが圧倒的に見やすい
/dev/disk/by-uuidもいいんだけど、いいんだけどちょっとなぁ
takuya@:~/Downloads$ ls -l /dev/disk/by-uuid/ 合計 0 lrwxrwxrwx 1 root root 10 2020-01-20 02:04 0f0fbd57-d05f-4ed6-985f-1a62e61720d5 -> ../../dm-2 lrwxrwxrwx 1 root root 10 2020-01-20 02:04 4df88652-a2db-4aa9-b28d-2ba850132340 -> ../../sda3 lrwxrwxrwx 1 root root 10 2020-01-20 02:04 5601-CF5B -> ../../sda1 lrwxrwxrwx 1 root root 10 2020-01-20 02:04 94eadf49-c020-47ee-b9cb-779af367cf58 -> ../../sda4 lrwxrwxrwx 1 root root 10 2020-01-20 02:04 b051eadd-397c-42ea-b1c8-900bb4e6586e -> ../../sda2 lrwxrwxrwx 1 root root 10 2020-01-20 02:04 d2d6fb06-24ca-4f56-ae30-1e1b5cdc9df0 -> ../../dm-1
blkid でブロックデバイスの id を見てみると
blkid ｍでも十分見やすいんだけど、lvm on dm-crypt とかの階層構造がわかりにくい。
takuya@:~/Downloads$ blkid /dev/mapper/sda3_crypt: UUID="TeBacs-1QVa-Za6E-Ain7-9RgV-oU3e-iBatiW" TYPE="LVM2_member" /dev/mapper/ubuntu--vg-swap_1: UUID="0f0fbd57-d05f-4ed6-985f-1a62e61720d5" TYPE="swap" /dev/mapper/ubuntu--vg-root: UUID="d2d6fb06-24ca-4f56-ae30-1e1b5cdc9df0" TYPE="ext4"
ストレージのuuidを知りたいときは、lsblk -f が便利。
パスワードなど、履歴を残したくない文字列を履歴に残してしまった場合。
たまに、やらかしますよね。複数ウインドウでフォーカスが違ってたとか。
takuya@:~$ 'MyP@$$word' -bash: MyP@$$word: コマンドが見つかりません
ログアウトすると、パスワードが履歴に残ってしまいます。
takuya@:~$ history 1844 history -d 1840 1845 ll -al | grep hist 1846 history 1847 'MyP@$$word' 1848 history
history -d 1847 history -w
パスワードなど記録に残したくないコマンドの履歴を削除(?)して、historyファイル を更新しています。
history -r rm .bash_history vim .bash_history
もちろん、 vim .bash_histrory をしてもいいのですが、vim を使ったことがバレてしまう！！
たいていは削除をしたがると思うのですが、履歴はその場でファイルに書き込まれているとは限りません。
history -r で保存するより先に、履歴をファイルから読み直すとかもありです。
bash の設定にもよりますが、ヒストリは、環境変数と書き込みタイミングが設定次第で変えられます。
基本的にはログアウトした瞬間に書き込まれます。
shopt の histappend を設定していると、削除して保存は無く追記になります。
$HISTSIZE に指定した件数分が起動中にbash に保存されます。
$HISTFILESIZEに指定した件数分が ファイル保存されます。
$HISTFILE に指定したファイルに書き込まれます。
ファイルに書き込んだ履歴を呼び出すには history -r です。
この辺をうまく組み合わせると、保存せずにログアウトもできます。
保存先を /dev/null とかメモリにするとか。HISTSIZEをゼロにするとか。ですかね
exim4 にパニックログが残ってると、エラー監視ログが上がってくるんですね。ログファイルを空にしたい。
exim paniclog /var/log/exim4/paniclog on acid has non-zero size, mail system might be broken. The last 10 lines are quoted below. 2019-11-21 22:53:06 socket bind() to port 25 for address 172.17.0.1 failed: Cannot assign requested address: daemon abandoned
truncate でファイルを空にする事ができます。
truncate -s 0 /var/log/file
あります。
ファイルの監視の問題とopenしている場合
削除であれば、ファイルをWatchしている各種サーバー類やファイルの移動をすると面倒くさいことがある。open していると取り合いにある。truncate は成功する可能性がある。
パーミッションの問題。
なにより rm して touch すると umask の設定によってはオーナやパーミッションが変わってしまうことがあります。面倒くさい。
今回の exim4 のログファイルのように、「定期的にファイルを空にする」と解決する場合に活躍します。
ファイルを削除して作成してパーミッションを合わせるより、既存のファイルを空っぽにするほうがずっと楽だ。
truncate を crontab にサクッと書いて終わりです。
そもそもなぜexim4がlogrotate しないのかは謎だけど、調べるのも面倒くさい話です。
takuya@:exim4$ cat /var/log/exim4/paniclog 2019-11-21 22:53:06 socket bind() to port 25 for address 172.17.0.1 failed: Cannot assign requested address: daemon abandoned takuya@:exim4$ sudo truncate -s 0 /var/log/exim4/paniclog takuya@:exim4$ cat /var/log/exim4/paniclog
ファイルを指定サイズに切り詰めます。
一緒に覚えておくと便利です。
指定したサイズより、ファイルが小さいなら、指定サイズになるまで０埋めされる。
ファイルのサイズを指定したら０埋めしたダミーファイルをサクッと作れます。
たとえば１GBのファイルを作るのであれば truncate の 引数に 1GB を指定すれば良いわけです。
takuya@:~$ truncate -s $(( 1024*1024*1024 )) sample takuya@:~$ ll sample -rw-rw-r-- 1 takuya takuya 1.0G 2020-01-15 01:06 sample
dd といえば、USRシグナルを送れば進捗状況が見えるのですが。
kill -USR1 $pid; sleep 1; kill $pid
これは起動中にddコマンドに対してpidへシグナルを送ることで表示されるのですが。説明するのは大変ですよね。
status=progress をつけると、どれくらい進んでいるか閲覧が可能になって便利。
dd if=/dev/zero of=out.img bs=1024 count=$((1024*512)) status=progress
rsync みたいに転送状況を知りたいときはこれを使うと便利。
ddするときは、忘れずにつけておきたい。
次のような感じに、コピーの書き込み速度や、何バイトをddできたかを見ることができます。
takuya@NO NAME$ dd if=/dev/zero of=out.img bs=1024 count=$((1024*512)) status=progress 260588544 bytes (261 MB, 249 MiB) copied, 9 s, 28.7 MB/s
dd の変わりに dd_rescue を使うと良いのは周知の事実ですが。dd のほうがbs count の細かい数字が指定しやすくていいですよね。
dd コマンドで状況を確認するには、次の方法があります。
ddrescue なら、進捗を見れるが、dd は見れない・・・ってときに便利です。
dd で直接指定バイトを取り出すとき、状況が見やすくとても便利です。
sudo dd if=/dev/sda bs=512 skip=2048 count=$(( 408373247-2048)) of=/dev/nvme0n1p4 status=progress
上記のコマンドなら次のように表示される。
takuya@ubuntu:~$ sudo dd if=/dev/sda bs=512 skip=2048 count=$(( 408373247-2048)) of=/dev/nvme0n1p4 status=progress 28953080320 bytes (29 GB, 27 GiB) copied, 265 s, 109 MB/s
残り時間や、進捗のパーセンテージは自分の計算こそ必要です。通常のdd違って、状況を表示するだけでも、速度とコピー済みの実績バイト数がわかるので計算が可能になり、安心感が違います。
加筆修正。verbose がキーワードになかったので、本文に追加
本当に遅い。
信じられないくらいに遅い。2MB/s程度しか出ない。３２GBのraspi のSDカードをコピーに一晩中掛かってしまった。辟易した。調べたら mac はもともと遅いらしい・
mac の /dev/diskX は遅すぎるので、raw モードで読み書きすると早くなる
/dev/disk → /dev/rdisk
raw で読み書きすると本当に早くなる。2M/s → 30M/s になり、ちゃんとマイクロSDの速度になった。
rdisk と disk で違いがあるのがわかると思います。
sudo ddrescue raspbian-2020-01-13.img /dev/disk3s2 sudo ddrescue raspbian-2020-01-13.img /dev/rdisk3s2
これ、知らないと本当にハマるよね。
/dev/disk は 1.7MB/s で /dev/rdisk へは 38MB/s である。桁違いとはこのことだ。
takuya@Downloads$ sudo ddrescue raspbian-2020-01-13.img /dev/disk3s2 --input-position=$(( 512*94208 )) --size=16G --force 2020-01-13.dd.mapfile
GNU ddrescue 1.24
Press Ctrl-C to interrupt
ipos: 4024 MB, non-trimmed: 0 B, current rate: 917 kB/s
opos: 4024 MB, non-scraped: 0 B, average rate: 1766 kB/s
non-tried: 12023 MB, bad-sector: 0 B, error rate: 0 B/s
rescued: 3976 MB, bad areas: 0, run time: 37m 30s
pct rescued: 24.85%, read errors: 0, remaining time: 1h 53m
time since last successful read: n/a
Copying non-tried blocks... Pass 1 (forwards)^C
takuya@Downloads$ sudo ddrescue raspbian-2020-01-13.img /dev/rdisk2s2 --input-position=$(( 512*94208 )) --size=16G --force 2020-01-13.dd.mapfile
GNU ddrescue 1.24
Press Ctrl-C to interrupt
Initial status (read from mapfile)
(sizes limited to domain 48234496 B to 16048234496 B of 32010928128 B)
rescued: 3976 MB, tried: 0 B, bad-sector: 0 B, bad areas: 0
Current status
ipos: 5962 MB, non-trimmed: 0 B, current rate: 32636 kB/s
opos: 5962 MB, non-scraped: 0 B, average rate: 37271 kB/s
non-tried: 10085 MB, bad-sector: 0 B, error rate: 0 B/s
rescued: 5914 MB, bad areas: 0, run time: 52s
pct rescued: 36.96%, read errors: 0, remaining time: 4m
time since last successful read: 0s
てか、raw モード以外で読み書きすると、なんでこんなに遅いのmacOSは・・・
mac でdd するときは、rdisk を使ってraw モードで読み書きしよう。
mac のブロックデバイスへのアクセスは遅すぎる。たぶんFSEVENTとかnotify 系に通知しまくるんだろう。mac のdocker が遅いのとも、似たような理由なのかもしれない。
/dev/disk と /dev/rdisk の違いはランダムアクセスとシーケンシャルアクセスの考え方の違いで、バッファを経由して他のプロセスと共有するかどうかってことらしい。
https://www.junk-works.science/disk-and-rdisk/
macOS で dd / ddrescue するとすごく時間がかかるので、バックグラウンドで流してて、１日近く経過してた、ddrescue 実行中を忘れて再起動してしまいました。悲しい
悲しいので、こういう悲劇が二度と見たくない。未然に防止する方法を調べたら、ddrescue には「転送再開」のレジューム機能があります。やったね。
takuya@Downloads$ ddrescue -h | grep map 5:Always use a mapfile unless you know you won't need it. Without a 6:mapfile, ddrescue can't resume a rescue, only reinitiate it. 7:NOTE: In versions of ddrescue prior to 1.20 the mapfile was called
ddrescue には第３の引数があります。あるんです。
ddrescue $IN $OUT $MAP
次のように第３の引数を指定して実行する。
ddrescue /dev/input out.img 2020-01-10.dd.map
そのあと CTRL-C や 再起動/kill などでプロセスを中止する。
ddrescue /dev/input out.img 2020-01-10.dd.map ^C
再開するのは、同じ「ファイル名」を第３の引数にいれて 起動する
ddrescue /dev/input out.img 2020-01-10.dd.map
map ファイルがあれば再開するようだ。
ddrescue で作成したmap フィアルの状況を表示することができる。これも便利。
ddrescue 自体に３番めのファイルとしてログファイルを指定する。
LinuxデスクトップにいちいちUSBをつなぎ直すのが面倒くさいので、普段使いのmacOSでext4 を操作してチェック(verify)修正をしたいなと思った。
brew install e2fsprogs
e2fsprogs をインストールすると、次のようにLinuxでよく使うであろうファイルシステムを扱うコマンドが入ります。
PATHを通すと面倒くさい（ゴチャゴチャになる）可能性があるので、PATHは通さないほうが良い。
brew もインストール後は 特にlink しないので、リンクはしないほうがトラブル防止になるんだろうね。
とくに mkfs.関係とか。もともとmacにあるコマンドと名前の似ているコマンドはトラブルの素だ。
homebrew でいれたe2fsprogs は次の場所にインストールされる。
/usr/local/opt/e2fsprogs/sbin/
takuya@Downloads$ ll /usr/local/opt/e2fsprogs/sbin/ total 6.6M -r-xr-xr-x 1 takuya staff 184K 2019-10-25 16:33 badblocks -r-xr-xr-x 1 takuya staff 49K 2019-10-25 16:33 blkid -r-xr-xr-x 1 takuya staff 401K 2019-10-25 16:33 debugfs -r-xr-xr-x 1 takuya staff 234K 2019-10-25 16:33 dumpe2fs -r-xr-xr-x 1 takuya staff 178K 2019-10-25 16:33 e2freefrag -r-xr-xr-x 1 takuya staff 502K 2019-10-25 16:33 e2fsck -r-xr-xr-x 1 takuya staff 235K 2019-10-25 16:33 e2image -r-xr-xr-x 1 takuya staff 317K 2019-10-25 16:33 e2label -r-xr-xr-x 1 takuya staff 234K 2019-10-25 16:33 e2mmpstatus -r-xr-xr-x 1 takuya staff 192K 2019-10-25 16:33 e2undo -r-xr-xr-x 1 takuya staff 8.4K 2018-12-16 14:39 filefrag -r-xr-xr-x 1 takuya staff 317K 2019-10-25 16:33 findfs -r-xr-xr-x 1 takuya staff 58K 2019-10-25 16:33 fsck -r-xr-xr-x 1 takuya staff 502K 2019-10-25 16:33 fsck.ext2 -r-xr-xr-x 1 takuya staff 502K 2019-10-25 16:33 fsck.ext3 -r-xr-xr-x 1 takuya staff 502K 2019-10-25 16:33 fsck.ext4 -r-xr-xr-x 1 takuya staff 254K 2019-10-25 16:33 fuse2fs -r-xr-xr-x 1 takuya staff 14K 2018-12-16 14:39 logsave -r-xr-xr-x 1 takuya staff 333K 2019-10-25 16:33 mke2fs -r-xr-xr-x 1 takuya staff 333K 2019-10-25 16:33 mkfs.ext2 -r-xr-xr-x 1 takuya staff 333K 2019-10-25 16:33 mkfs.ext3 -r-xr-xr-x 1 takuya staff 333K 2019-10-25 16:33 mkfs.ext4 -r-xr-xr-x 1 takuya staff 14K 2019-10-25 16:33 mklost+found -r-xr-xr-x 1 takuya staff 229K 2019-10-25 16:33 resize2fs -r-xr-xr-x 1 takuya staff 317K 2019-10-25 16:33 tune2fs -r-xr-xr-x 1 takuya staff 26K 2019-10-25 16:33 uuidd
ext4 のパーティションをりサイズで拡張・縮小させたり、 e2fsck もちゃんと使える。
blkid でuuid を閲覧することもできるが、 /dev/ に対応しないので、引数にちゃんといれる必要がある。
brew install gptfdisk
mac で linux のフォーマットを扱うには brew install e2fsprogs 。インストール先を直接叩いて使う。
mac でもraspi のSDカードのメンテナンスが簡単にできることがわかりとても安心です。
マウントしたいとき、パーティションを触りたいときは。こっちを参考に。
mac にもfdisk があり gpt コマンドで GPT のボリュームも扱えるのですが。「覚えるのが面倒くさい」
linuxのgdisk コマンドと同じなら使い方も同じなので、覚えることが少ない。
brew install gptfdisk
gptfdisk をインストールすると、おなじみの sgdisk gdisk のGNUコマンドがmacOSでも使えるようになる。
takuya@~$ ll /usr/local/Cellar/gptfdisk/1.0.4/bin/ total 652K -r-xr-xr-x 1 takuya staff 200K 2018-07-06 05:19 cgdisk -r-xr-xr-x 1 takuya staff 64K 2018-07-06 05:19 fixparts -r-xr-xr-x 1 takuya staff 195K 2018-07-06 05:19 gdisk -r-xr-xr-x 1 takuya staff 190K 2019-03-11 22:02 sgdisk takuya@~$
ディスクのパーティションを触るときは、王手が掛かってるシビアなときが多いので、普段使いの慣れたコマンドで操作できるのは大変いいことだと思う。
LFでもCRLFでも関係なく、文字コードも関係ありません。php では終了タグで「改行」すると、出力には改行が反映されません。
<?php $title = 'コーチングのプロが教える 「ほめる」技術'; $author = '鈴木 義幸'; ?> 著者:<?= $title?> 書題:<?= $author?>
実行結果
$ php sample.php 著者:コーチングのプロが教える 「ほめる」技術書題:鈴木 義幸
不思議ですね。
次のように、単位が入るとさらに表示が想像がつかなくなります。
<?php $title = 'コーチングのプロが教える 「ほめる」技術'; $author = '鈴木 義幸'; $price = 1047; ?> 著者:<?= $title?> 価格:<?= $price;?>円 書題:<?= $author?>
これを実行すると次のようになります。
$ php sample.php 著者:コーチングのプロが教える 「ほめる」技術価格:1047円 書題:鈴木 義幸
”円”にだけ改行が反映されています。何故なんでしょうか。改行は無視されるときとされない時があるんです。
php では、<?php ?> で囲まれたエリアはそのまま、コードとして解釈されます。と一般的に習うんでしょうけど、例外があります。
終了タグは、「改行」を含んで終了と解釈されます。?> ⏎ は ?> と同じなのです。
一つだけだと
abc<?php ?> ⏎
実行後は
abc
になります。
なので、改行を反映したいときは、空行を入れるか、空白を入れます。
abc<?php ?> ⏎ ⏎
これが実行されると
abc⏎
になります。
こうします。空白を入れます。
<?php echo $name; ?>␣⏎
php のファイルから php をrequire したときに、改行コードをいい感じにしてくれるので便利なこともある。
そういう仕様なのです。如何ともし難い。仕方ないのです。php で改行がでなくてもHTMLは改行を無視するのであまり気になっていないという現実があります。
これが、phpでCSVやバッチ処理やメール送信など、プレーンテキストを扱うと途端に問題になります。とくにCSVとメールでしょうか。
仕様なのです。phpは4→5, 5→6とかなり後方互換を切り捨ててきたので、そろそろこの辺もバッサリ切ってほしいと思ったりするのですが。
テンプレートとしてphpを実行したときに改行コードを意識する必要があるのは若干不便ではないでしょうか。
今回は、このphp でサンプルコードを書いて実行しています。
PHP 7.3.11 (cli) (built: Oct 24 2019 11:29:42) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.11, Copyright (c) 1998-2018 Zend Technologies
with Xdebug v2.7.2, Copyright (c) 2002-2019, by Derick Rethans
mac には 最初から postfix が入っているので、 postfix を使うのが手っ取り早い
postfix を使ってSMTPリレーをし、GmailのSMTPサーバーに接続する。
takuya@mail$ sudo -e /etc/postfix/sasl_passwd
/etc/postfix/sasl_passwd
smtp.gmail.com:587 youname@gmail.com:your_password
私の環境では、なぜか、main.cf が空っぽのファイルになっていたので、デフォルトを取り出します。
sudo cp /etc/postfix/main.cf~orig /etc/postfix/main.cf
postmap をつかって、パスワードをdb に登録します。
sudo postmap /etc/postfix/sasl_passwd
main.cf を開いて、末尾に追記します。
# Apple Defaults # message_size_limit = 10485760 mailbox_size_limit = 0 biff = no mynetworks = 127.0.0.0/8, [::1]/128 smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated permit recipient_delimiter = + tls_random_source = dev:/dev/urandom smtpd_tls_ciphers = medium #### ここから追記 ## gmail へのリレー設定 relayhost=smtp.gmail.com:587 smtp_sasl_auth_enable=yes smtp_sasl_password_maps=hash:/etc/postfix/sasl_passwd smtp_use_tls=yes smtp_tls_security_level=encrypt tls_random_source=dev:/dev/urandom smtp_sasl_security_options = noanonymous smtp_always_send_ehlo = yes smtp_sasl_mechanism_filter = plain
設定ができたので、postfixを起動します。
sudo postfix start
起動を確認しておきます。
takuya@mail$ ps aux | grep postfix 321:_postfix 9807 0.0 0.0 4305160 4004 ?? S 4:32AM 0:00.03 tlsmgr -l -t unix -u 325:_postfix 9461 0.0 0.0 4324644 4092 ?? S 4:28AM 0:00.04 qmgr -l -t fifo -u 326:_postfix 9460 0.0 0.0 4332788 4036 ?? S 4:28AM 0:00.03 pickup -l -t fifo -u -o content_filter= 327:root 9459 0.0 0.0 4297908 560 ?? Ss 4:28AM 0:00.03 /usr/libexec/postfix/master -w
終了するときは、
sudo postfix stop
サンプル用のメールを作成します。 sample-mail.txt
To:takuya@example.com Subject: HELLO , from test Hi, can you see my mail?
sendmail コマンドで送信します。
cat sample-mail.txt | sendmail -i -t
無事に届けばOKです。
幾つか、気にしておく点をメモしておきます。
postfix を常時動かすのはセキュリティ的に怖いのですが。使うときだけ起動できるので、それで妥協する。
sendmail コマンドとを互換性を持った別のコマンドを作ってもいいんですけど。作るのはめんどくさすぎるので
使うときのみ postfix を起動し使い終わったら終了するようにしておく。
また、smtp のリレーを localhost ( ::1 / 127.0.0.1 ) に限定するのも一つの手段です。
Gmail でSMTPは「安全性の低いアプリ」などと呼称されている 。安全性の低いアプリ( less secure apps ) をオンにしないとSMTP経由でメールが送れないかもしれない。
最近は、SMTPだけは開放されているようです。以前はこれをONにしないとSMTPが使えなかった。
指定するGoogleのSMTP(s)のポートによっては使えない可能性が高い。
cat /proc/cpuinfo の出力が多すぎて見にくい。
表示は４コア２スレッドの合計８スレッドのCPUなんだけど、この数がどんどん増えていくんですよね。Ryzenとか買った日には、最大６４個とかになるんでしょ？
代替手段として lscpu コマンドを使うと便利。
takuya@:~$ LANG=C lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 8 On-line CPU(s) list: 0-7 Thread(s) per core: 2 Core(s) per socket: 4 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 94 Model name: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz Stepping: 3 CPU MHz: 799.987 CPU max MHz: 4000.0000 CPU min MHz: 800.0000 BogoMIPS: 6816.00 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 8192K NUMA node0 CPU(s): 0-7 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch invpcid_single ibrs ibpb stibp kaiser tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp
日本語表記もできる
takuya@:~$ lscpu アーキテクチャ: x86_64 CPU 操作モード: 32-bit, 64-bit バイト順序: Little Endian CPU: 8 オンラインになっている CPU のリスト:0-7 コアあたりのスレッド数:2 ソケットあたりのコア数:4 ソケット数: 1 NUMA ノード数: 1 ベンダー ID: GenuineIntel CPU ファミリー: 6 モデル: 94 モデル名: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz ステッピング: 3 CPU MHz: 799.987 CPU 最大 MHz: 4000.0000 CPU 最小 MHz: 800.0000 BogoMIPS: 6816.00 仮想化: VT-x L1d キャッシュ: 32K L1i キャッシュ: 32K L2 キャッシュ: 256K L3 キャッシュ: 8192K NUMA ノード 0 CPU: 0-7 フラグ: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch invpcid_single ibrs ibpb stibp kaiser tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp
カーネルの暗号化モジュールから、一覧を拾ってきて aesni が入ってれば大丈夫っぽい
takuya@:~$ sort -u /proc/crypto | grep module 66:module : aes_x86_64 67:module : aesni_intel 68:module : crc32_pclmul 69:module : crc32c_generic 70:module : crc32c_intel 71:module : crct10dif_pclmul 72:module : cryptd 73:module : ghash_clmulni_intel 74:module : kernel
詳しくは wikipedia:en を見ると書いてある。 wikipedia:ja は情報が更新されてない。
この辺が対応CPU
自分の買おうとしているCPUが対応しているかどうかは、Google検索で検索すればいい。
Skylake以降のデスクトップ用のCPUならほぼ確実に。それ以前はi7/i5以上。廉価CPUならGoldmont 以降CPUについてる。やすいの攻めたらついてないこともあるみたいね。
Celeron J1900 / 非対応 - よく売られている廉価ボードに搭載されている celeron j1900 aes - Google 検索
Pentium N4200 - Liva2 などに搭載されている。 pentium n4200 aes-ni - Google 検索
Amazonで中華製のLANポートがいっぱいついたマシンを買おうと思ってたけどJ1900ばっかりなんですよね。
HTTPSやOpenVPNとか考えるとAESがいいかもしれない。
ECS 小型デスクトップPC 「LIVA Z」シリーズ LIVAZ-4/64-W10(N3350)S ブラック
AESの速度議論のためには種類のCPUで、AESの速度を測定する。- intel arm mips - それマグで！
CPUのAES暗号化速度をCPU組込のaesサポートのありなしで測定する。 - それマグで！
How to find out AES-NI (Advanced Encryption) Enabled on Linux System - nixCraft
x86 の intel CPU にはAESのサポート ( AES-NI )が組み込まれていて 処理速度が速いということは、知られた事実だと思う。
暗号化アクセラレータとして動作しているのですが、どれくらいの速度の恩恵が出ているのか。知りたくなった。
HTTPSやSSD/HDDの暗号化で処理速度が気になると言われたので、じゃぁ調べてみようじゃないかと。
CPU(AES-NI) の機能を「オフ」/disable にした場合の測定。
OPENSSL_ia32cap="~0x200000200000000" openssl speed -elapsed -evp aes-128-cbc
CPUの機能をオン / enable にした場合
openssl speed -elapsed -evp aes-128-cbc
takuya@:~$ OPENSSL_ia32cap="~0x200000200000000" openssl speed -elapsed -evp aes-128-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-128-cbc for 3s on 16 size blocks: 62451619 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 18216095 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 4615725 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 1176014 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 147045 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 16384 size blocks: 73621 aes-128-cbc's in 3.00s OpenSSL 1.1.1d 10 Sep 2019 built on: Wed Oct 9 01:04:37 2019 UTC options:bn(64,64) rc4(16x,int) des(int) aes(partial) blowfish(ptr) compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -fdebug-prefix-map=/build/openssl-1.1.1d=. -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 333075.30k 388610.03k 393875.20k 401412.78k 401530.88k 402068.82k takuya@:~$ openssl speed -elapsed -evp aes-128-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-128-cbc for 3s on 16 size blocks: 153491212 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 66078098 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 16915245 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 4232165 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 533750 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 16384 size blocks: 266600 aes-128-cbc's in 3.00s OpenSSL 1.1.1d 10 Sep 2019 built on: Wed Oct 9 01:04:37 2019 UTC options:bn(64,64) rc4(16x,int) des(int) aes(partial) blowfish(ptr) compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -fdebug-prefix-map=/build/openssl-1.1.1d=. -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 818619.80k 1409666.09k 1443434.24k 1444578.99k 1457493.33k 1455991.47k
| type | 16 bytes | 64 bytes | 256 bytes | 1024 bytes | 8192 bytes | 16384 bytes |
|---|---|---|---|---|---|---|
| なし aes-128-cbc | 333075.30k | 388610.03k | 393875.20k | 401412.78k | 401530.88k | 402068.82k |
| あり aes-128-cbc | 818619.80k | 1409666.09k | 1443434.24k | 1444578.99k | 1457493.33k | 1455991.47k |
AES-NIはええ
AESの速度議論のためには種類のCPUで、AESの速度を測定する。- intel arm mips - それマグで！
https://github.com/mdaxini/howto-openssl/wiki/OpenSSL-Cipher-Speed
Google Chromeに保存されたパスワードを削除し、パスワードが自動入力されるのを防止したり、パソコンに保存されたパスワードが読み取られないようにする。
一つずつ削除してもいいのですが、履歴からすべての保存済みパスワードを削除するのが楽です。
Chromeを開いて「閲覧履歴データ」を表示します。
閲覧履歴データの削除を選びます。
詳細設定で、削除したいパスワードの「期間」を選びます。すべて削除するなら「全期間」です。
自動入力フォームの記録や、パスワードをスクロールして選びます。
あとは、「削除」ボタンを押すだけです。
パスワードは、記憶より機械に頼るほうが安全です。
最初に知っておくべきことですが、保存されたChromeのパスワードは暗号化されパスワードで保護されています。
Chromeのパスワードはパソコンにログインするパスワードで保護されています。macOSであればキーチェインで保護されています。
ときどき、「パスワードをパソコンに保存しないことがセキュリティ」という誤った説明を見かけますが、パスワードを保存すること自体が悪事ではなく、パソコンのユーザーにパスワードを掛けないことが危険なのです。
パソコンのログインにロックを掛けていない。その場合でも、Google ChromeにGoogle アカウントでログインしていればパスワードは安全に保存されています。データを復元されたとしても盗まれたとしてもパスワードの中身まで取り出せる可能性は極稀です。
危険なのは、基本的な安全対策を怠っている場合です。パソコンにユーザーロックを掛けてない。Chromeにログインせずにパスワードを保存した。パスワードをExcelファイルに保存している*1。パスワードを保存することそれ自体を悪魔のように呼称するのは間違いでしょう。
パスワードは「自動的に保存」され「自動的に入力」されます。
自動的に入力されるときに、サイトが「正規のドメイン」であるか一致検証してから入力されます。
フィッシング詐欺の偽装サイトには自動入力が行われません。
逆に言えば
自動入力がされない場合はフィッシング詐欺の可能性がある。ということです。
なので、できる限り自動入力を使いましょう。
自動入力ができないサービスの利用を控えるのもいいでしょう。
Google や chrome は大勢に支持され使われていますが、その分狙われることも多いいです。 またGoogleに頼るのも心配なことでしょう。
その場合は、次のような無料サービスや
次のような有料サービス
などを利用するのも一つの手段です。
復元ソフトで復元されたとしても、パスワード保存ファイルにパスワードが掛かっているので、そうかんたんには見られることはありません。WindowsやMacのログインパスワードを掛けておくことが重要です。またHDD・SSDは暗号化しておくとそれらを安全に扱えるのです。
もしロックもパスワードもかけてないのであれば、「物理的」に安全にパソコンを管理しましょう。他人にパソコンを触らせない。外出時に部屋にカギをかける。他人を部屋に入れないなど物理的なセキュリティを確保することが大事です。
パスワードの定期的な変更よりずっと大事です。
パスワードやセキュリティについてよく聞かれるので、そのときに答えていることを簡単にまとめました。
保存したパスワードを削除する方法は簡単です。履歴から削除すればいいのです。
ただし、パスワードは自動保存と自動入力したほうがむしろ安全な場面も多いと覚えておいてください。
万が一、Google を信用できないときは、パスワードを削除しましょう
