屑俺日記
僕の備忘録(PC、UN*X、ネットワーク関連が中心)なんです。
自分の書いたところは適当(な時とか)に書き換えますので御了承を。
2005-07-15(Fri) 三日坊主
☆ 何処で話したか忘れた。
$ ssh $PLAMO-3.3 ls -l $LOG Enter passphrase for key '/home/user/.ssh/id_dsa': -rw-r----- 1 root root 7105 Jul 15 17:45 /var/log/messages $ ssh $FreeBSD-4.11 ls -l $LOG Enter passphrase for key '/home/user/.ssh/id_dsa': -rw-r--r-- 1 root wheel 41275 Jul 15 16:12 /var/log/messages $ ssh $Debian-woody ls -l $LOG Enter passphrase for key '/home/user/.ssh/id_dsa': -rw-r----- 1 root adm 13263 Jul 15 17:43 /var/log/messages
☆ ethereal
パケット全部を表示...では、正直目が眩みそうだ。キャプチャはともかく
表示に濾過が必要なことは分かりきっている。
んで、
マニュアルと睨めっこするも、フィルタリングの
シンタックスがなかなか分らない。ピンクを薄緑に変えようと試行錯誤。
15分で目的を果たすと、たちまち気力が尽きた。
ip.src != XXX.XXX.XXX.XXX/XX とか。
2006-07-15(Sat) どみそ
☆ $ echo y | next_command
パイプの向こうのコマンドに"y"など
を渡して、対話処理の必要なコマンドをバッチ処理させるという
テクニックがあった。
昔MS-DOS時代によく使ってたはずである。
おそらくはUN*X系シェルあたりの借り物らしく、
bashの下でも使える事に昨日気づいた。
$ /sbin/mkfs -t ext2 new.img mke2fs 1.38 (30-Jun-2005) new.img is not a block special device. Proceed anyway? (y,n)
ここにecho y|すると対話処理を省略できた。
とはいえ、mke2fs(mkfsはフロントエンドだ)のmanを
読み直して試すと、-Fで確認を省略できたけど。
☆ 2006年7月度LMS
に参加。場所は
前々回同様、NotFoundな
番号の会議室。
多少残念ながら1Getならず。
今回はLinuxKernelやGlibcがらみな話が三連発。
非常に堅茹でだったせいか、一睡もせずに聴講したが、最後の
講演がしめくくるあたりでは、流石に脳みそが石ころになった気がした。
懇親会に二次会までついて行く。
更なる前進なるやならざるや。
2007-07-15(Sun) やば
☆ 謎
SERVER$ grep ^::1 $ACCESS_LOG | head ::1 - - [15/Jul/2007:08:08:41 +0900] "GET /" 400 466 ::1 - - [15/Jul/2007:08:08:44 +0900] "GET /" 400 466 ::1 - - [15/Jul/2007:08:08:54 +0900] "GET /" 400 466 ::1 - - [15/Jul/2007:08:09:04 +0900] "GET /" 400 466 ::1 - - [15/Jul/2007:08:09:13 +0900] "GET /" 400 466 ::1 - - [15/Jul/2007:08:10:20 +0900] "GET /" 400 466 ::1 - - [15/Jul/2007:08:23:14 +0900] "GET /" 400 466 ::1 - - [15/Jul/2007:08:52:01 +0900] "GET /" 400 466 ::1 - - [15/Jul/2007:08:52:02 +0900] "GET /" 400 466 ::1 - - [15/Jul/2007:08:52:03 +0900] "GET /" 400 466
使ってないv6機能は、解除した方がいいかも。
2008-07-15(Tue) はれ
☆ 悪者とされたのは、俺か？それともGoogleか？
自分の変な英文サイトを
自動翻訳させたら、ウィルスバスター2008に
ブロックされてしまった。
面倒なので、URLをw3mにコピペしておしまい。にする
☆ ようやくlogin:
ようやく非力なNoteでLFSができた。
PCMCIAのNICを組み込むことを忘れたので、カーネルは再度作りなおす。
$host login: $user Password: No mail. -bash-3.2$ uname -a Linux $host 2.6.22.5 #2 Tue Jul 15 20:21:37 \ JST 2008 i586 pentium-mmx i386 GNU/Linux
あれ、shutdownしても電源が落ちない。
ではもう一度。
2009-07-15(Wed) 青空に下弦の月が見えた朝
☆ findで根こそぎ
$ find . -name "*.txt" | xargs grep second ./test.txt:second ./1/test.txt:second ./3/test.txt:second ./3/1/test3.txt:second ./3/1/2/test4.txt:second ./2/test2.txt:second ./2/2/test2.txt:second $ find . -name "*.txt" | xargs sed -i "s/second/2nd/" $ cat test.txt first 2nd third $ find . -name "*.txt"| xargs grep 2nd ./test.txt:2nd ./1/test.txt:2nd ./3/test.txt:2nd ./3/1/test3.txt:2nd ./3/1/2/test4.txt:2nd ./2/test2.txt:2nd ./2/2/test2.txt:2nd
*.txt を""で括らないとサブディレクトリの下の下がうまくできなかった。
☆ lenny のVirtualHost
DynamicDNSから $FIRST.domain.tld と、$SECOND.domain.tld を借りる。
ドキュメントをさっと見て、要点をつかんだら、Debianの流儀に
できるだけ合わせるかたちで設定変更。
今回は /etc/apache2/sites-enabled/000-default をいじる。
<VitualHost> の中に ServerName を追記し、
もう一つ<VirtualHost> のエントリを追加する。
適当にディレクトリを掘り、別々のコンテンツも用意する。
デフォルトのindex.htmlに少し手を入れただけ、だけど。
$ sudo /etc/init.d/apache2 restart の上で、確認。
$ w3m -dump http://$FIRST.domain.tld Virtualhost $FIRST.domain.tld works! $ w3m -dump http://$SECOND.domain.tld Virtualhost $SECOND.domain.tld works!
telnet でHTTP/1.0 でも、Host: を指定するとどちらもできた。
HTTP/1.1もやってみた。Host: は必須とのことである。
ところで、Keep-Aliveを今すぐ切るにはどうするんだろうか。
2012-07-15(Sun) 先週くらいからセミの鳴く曇天
☆ from ubuntu to debian
debootstrap で USB HDD に Debian Wheezy を突っ込んでみた。
若干の試行錯誤をまとめると、以下の如し。
パーティションを切って、ext4 で mkfsし、 mount。
Ubuntu-12.04 の debootstrap で SUITE に "wheezy" 、
MIRROR に "http://ftp.jp.debian.org/debian" を指定し、
しばらく放置。
TARGET に chroot。/etc/fstab の編集や、 root password
設定。
この時点でカーネルを入れておいてもよかったかもだけど、
なぜか Ubuntu からカーネルを借りる。exit して、/boot から
initrd.img-3.2.0-26-generic と
vmlinuz-3.2.0-26-generic
を、それから /lib/modules/3.2.0-26-generic をコピー。
再起動して、grub メニューが表示されたら、c で コンソールモードに移り、 以前のメモ通りに手入力。
やはりUSB が三つしかないマシンで USB HDD (二つ必要)
は面倒くさい。
/etc/fstab は /proc と root filesystem のみ
指定していたが、 root fs の option(4番目のフィールド)が
抜けていたため、ひとしきり ro で嵌った。
mount -n -o remount -t ext4 /dev/$DEV / が
効くかどうかは、未確認
。効くことを確認した。
☆ namei(1)
今日中にもう一本。
$ namei /usr/bin/editor
f: /usr/bin/editor
d /
d usr
d bin
l editor -> /etc/alternatives/editor
d /
d etc
d alternatives
l editor -> /usr/bin/vim.tiny
d /
d usr
d bin
- vim.tiny
2016-07-15(Fri) 雨の降る確率は低かったけど
☆ eog(1)
GNOMEデスクトップやLXDEで使われる「画像ビューアー」の コマンド名。Ubuntuにはmanも入っていた。
☆ ゲートウェイ多重化
Yamaha Routerの 記事より。
# ip keepalive 1 icmp-echo 10 3 $REMOTEHOST # ip route $REMOTEHOST gateway $ROUTER1 keepalive 1 \ gateway $ROUTER2 weight 0
この設定では $ROUTER1 (PPPoEで PP $NUMなど)からのpingに
$REMOTEHOSTから応答がなくなったら、30秒ほど後に
ゲートウェイを $ROUTER2 に変更する。
復旧したら10秒ほどで元に戻る。
weight 0が最も優先度が低いらしい。らしい。らしい...
Win7やJessieで一応このとおりに動いた。無線LANだと 若干追従が悪いようだ。
☆ 思ったほどホットでもないスポットで
8MBのwgetを試みた。例によってSimpleHTTPServer。
$ time wget http://$REMOTEHOST:8000/8M.img -O 8M.img --2016-07-15 19:43:17-- http://$REMOTEHOST:8000/8M.img $REMOTEHOST:8000 に接続しています... 接続しました。 HTTP による接続要求を送信しました、応答を待っています... 200 OK 長さ: 8388608 (8.0M) [application/octet-stream] `8M.img' に保存中 8M.img 100%[===================>] 8.00M 55.5KB/s in 2m 6s 2016-07-15 19:45:24 (65.1 KB/s) - `8M.img' へ保存完了 [8388608/8388608] real 2m6.247s user 0m0.120s sys 0m0.524s
☆ 思いのほかパケットが詰まる
ダウンロードしながら、違うリモートホストのIPに pingを打ち続けていた。
$ ping $RHOST_2 PING $RHOST_2 ($RHOST_2) 56(84) bytes of data. 64 bytes from $RHOST_2: icmp_seq=1 ttl=55 time=96.7 ms 64 bytes from $RHOST_2: icmp_seq=2 ttl=55 time=95.6 ms 64 bytes from $RHOST_2: icmp_seq=3 ttl=55 time=87.1 ms 64 bytes from $RHOST_2: icmp_seq=4 ttl=55 time=93.5 ms 64 bytes from $RHOST_2: icmp_seq=5 ttl=55 time=97.7 ms 64 bytes from $RHOST_2: icmp_seq=6 ttl=55 time=92.2 ms 64 bytes from $RHOST_2: icmp_seq=7 ttl=55 time=91.9 ms 64 bytes from $RHOST_2: icmp_seq=8 ttl=55 time=96.8 ms 64 bytes from $RHOST_2: icmp_seq=9 ttl=55 time=106 ms 64 bytes from $RHOST_2: time=149159 ms 64 bytes from $RHOST_2: icmp_seq=11 ttl=55 time=148246 ms 64 bytes from $RHOST_2: icmp_seq=12 ttl=55 time=147332 ms // 64 bytes from $RHOST_2: icmp_seq=183 ttl=55 time=114 ms 64 bytes from $RHOST_2: icmp_seq=184 ttl=55 time=114 ms 64 bytes from $RHOST_2: icmp_seq=185 ttl=55 time=113 ms ^C --- $RHOST_2 ping statistics --- 185 packets transmitted, 185 received, 0% packet loss, time 185200ms rtt min/avg/max/mdev = 87.182/66016.698/149159.754/47216.065 ms, pipe 148
見ていた感じ、icmp_seq=9(rtt 109ms) の次(icmp_seq=10)
は、wget が終了してかなり経ってから戻ってきた。
wget の始まりはicpm_seq 9のときとすると、終了がその約126秒後、rttが約149秒で、
ダウンロード終了の約14秒後に、放ったパケットがどっと戻ってきた計算になる。
パケットロスはなかった。
時間をもう少し揃えなければ。
2017-07-15(Sat) もう梅雨は去ったのだろうか、それとも
☆ 謎のARM64マシン
64bitのUbuntuが入ってた由。
$ uname -a Linux $HOSTNAME 3.10.105-bsp-1.2-ayufan-77 #1 SMP PREEMPT Sun Jul 9 12:09:30 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux $ cat /proc/cpuinfo Processor : AArch64 Processor rev 4 (aarch64) processor : 0 processor : 1 processor : 2 processor : 3 Features : fp asimd aes pmull sha1 sha2 crc32 CPU implementer : 0x41 CPU architecture: AArch64 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4 Hardware : sun50iw1p1
libgmp-devをapt-getして、coreutils-8.27をビルドする。
coreutils-8.27/src$ time echo 2^128+1 | bc | ./ 340282366920938463463374607431768211457: 59649589127497217 5704689200685129054721 real 15m12.092s user 14m55.270s sys 0m0.580s
ついでにdmesg。
Pentium M 1.6GHzのLet's Note(2005-6年頃)と同じくらいか。
☆ msieve
素因数分解が恐ろしく速かった。
PCでもそうだったが、RaspberryPi Bでも凄い。
パッケージに見当たらず、セルフビルド。
gmpやzlibのdevが要るようだった。
11分弱ほどかかった。
msieve-1.53 $ ldd ./msieve
/usr/lib/arm-linux-gnueabihf/libarmmem.so (0xb6fa0000)
libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6f84000)
libz.so.1 => /lib/arm-linux-gnueabihf/libz.so.1 (0xb6f5d000)
libgmp.so.10 => /usr/lib/arm-linux-gnueabihf/libgmp.so.10 (0xb6eea000)
libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb6e6b000)
libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6e42000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6d03000)
/lib/ld-linux-armhf.so.3 (0x7f61c000)
msieve-1.53 $ time echo 2^128+1 | bc | ./msieve -q -m next number: 340282366920938463463374607431768211457 p17: 59649589127497217 p22: 5704689200685129054721 next number: real 0m1.020s user 0m0.890s sys 0m0.080s
最新のfactorで68分かかっていたことが 信じられないくらい。
ついでに(?)PCで2^256+1を試してみた。
$ time echo 2^256+1 |BC_LINE_LENGTH=80 bc | ./msieve -q -m next number: 115792089237316195423570985008687907853269984665640564039457584007913129639937 p16: 1238926361552897 p62: 93461639715357977769163558199606896584051237541638188580280321 next number: real 0m8.134s user 0m8.108s sys 0m0.020s
2018-07-15(Sun) 蝉が騒々しく
☆ tcptraceroute(1)
$ tcptraceroute -n mail.kuzuore.net
1 172.20.10.1 8.162 ms 3.478 ms 3.291 ms
2 * * *
3 160.13.52.1 81.195 ms
160.13.52.66 33.725 ms 54.863 ms
4 160.13.52.1 42.851 ms 34.799 ms 47.592 ms
5 58.138.88.1 35.780 ms 51.759 ms 45.691 ms
6 58.138.102.98 38.022 ms 50.768 ms 51.185 ms
7 210.138.107.34 41.742 ms 36.005 ms 46.920 ms
8 * * *
9 * * *
10 * * *
11 153.126.180.146 159.280 ms * 160.893 ms
12 153.126.180.146 54.166 ms 64.012 ms 63.391 ms
13 153.126.180.146 [closed] 83.162 ms 67.557 ms 65.005 ms
man見た限り、AS名までは嗅がないようだけど、到達性はtraceroute(1) よりいいかも。
$ traceroute -n mail.kuzuore.net traceroute to mail.kuzuore.net (153.126.180.146), 30 hops max, 60 byte packets 1 172.20.10.1 6.419 ms 6.384 ms 6.354 ms 2 * * * 3 160.13.52.1 55.928 ms 55.895 ms 55.828 ms 4 58.138.88.1 55.686 ms 55.786 ms 55.740 ms 5 58.138.102.98 55.624 ms 55.593 ms 55.532 ms 6 210.138.107.34 55.522 ms 49.428 ms 49.322 ms 7 * * * 8 * * * 9 * * * // 30 * * *
リンクはご自由にどうぞ。でもURLや内容が変った場合はあしからず。