屑俺日記

☆ 遅くてもやらないよりは

libpngを1.2.8 にあげた。tar.bz2 を展開し、scriptディレクトリに 入ってたmakefile.linux をひとつ上段にもってきて編集し、make。 install の後、ldconfig -v|grep png で確認。古い libpng.so.3.1.2.5 と libpng12.so.0.1.2.5 を 念のため隔離。
gimp2 などを動かしてみたが、一応うまくいったようだ。

☆ I'm Feeling Lucky

を<A href=>の後に入れたら、どうなるかの テスト。

<a href="http://www.google.com/search?q=なんだそら&\
btnI=I%27m+Feeling+Lucky">

w3m -> http://blog.so-net.ne.jp/psychokinesis/2005-07-03
Firefox(Linux) -> http://www.kncn.net/blog/item/325
Firefox(MacOSX) -> http://www.kncn.net/blog/item/325
Firefox(Windows) -> http://www.kncn.net/blog/item/325
Safari -> http://www.kncn.net/blog/item/325
MSIE -> "?ʤ???????EbtnI=I'm Feeling Luckyに該当するページが見つかりませんでした。" (ステータスバーのURLは化けてなかったんだけどねぇ)

言語指定を入れたり、日本語を文字参照にすれば、もう少し結果が 揃うかもしれない。

☆ なんだそら

間違ったURLをFirefoxに入れるとヤフーに飛んだ。 ごちゃついてきたので少し整理する。

"http://www.openedu.org/ja/contacts/event.html" と入力しようとして、 "http//www.openedu.org/ja/contacts/event.html" と入れると、ヤフーに出た。

これはLinux及びWindows版のFirefox1.0.4で確認できた。
MacOSX版ではgoogleのトップページに飛び、Safariでは Searchmachine.comに至る。
MSIE6の場合、当然(?)search.msn.com の検索結果が出た。

入力間違いに気付いて対処した後、Linux 上で ethereal を 仕掛けて観察してみた。
まず、間違ったURLの名前解決を何度かやっている。すべて 失敗した後、どういうわけか "66.102.7.99" (逆引きが返らないが google臭い)に 向けて "search?q=http&btnI=I%27m+Feeling+Lucky" とhttp1.1 を送信。
しかるのちに向うの回答に沿って飛んで行く、らしい。

Safari の挙動も不思議だったので、tcpdump でキャプチャしてみた が、かなり複雑なようだ(関係ない処理まで拾っているかもしれない)。

☆ FreeBSD-SA-05:17.devfs

デバイスファイルがジェイルの中から不正利用される可能性、で いいんだろうか。 jail(8)は今のところ使ってないが、再構築だけはやっておく。 cvsup すると、ローカルなcvsup-mirror は既に更新済みだった。 リビジョンを確認してビルドする。10分弱で終了した。

☆ 2.6.17.6

をメールサーバ(現在2.6.12.5)にも入れる事とする。
とはいえPentiumClassic133MHz...makeにどのくらいかかることか。
time で様子を見てみよう。

☆ 時間計測失敗。

/usr/src/linux/.configと、最後にINSTALLされたモジュールの タイムスタンプを比較してみる。
ざっと5時間半というところか。

# make && make modules_install
(ry
  INSTALL net/xfrm/xfrm_user.ko
if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod \
  -ae -F System.map  2.6.17.6; fi
 
# ls -l /lib/modules/2.6.17.6/kernel/net/xfrm/xfrm_user.ko
-rw-r--r--    1 root     root        20907 Jul 21 06:42 \
  /lib/modules/2.6.17.6/kernel/net/xfrm/xfrm_user.ko
 
/usr/src/linux# ls -l .config
-rw-r--r--    1 root     root        23479 Jul 21 01:08 .config

linux/arch/i386/boot/bzImage を適当な位置にコピーして、 grub.conf も編集した。さて、再起動はいつか。

☆ 環境の罠

Etch(に限定されまいが)はインストール時の環境を覚えている。
CD/DVDからシステムをインストールすれば/etc/apt/sources.listに CDのエントリが書き込まれる。追加インストールで"[*]デスクトップ" などをプロキシの下からaptitudeしたりすれば、 当然/etc/apt/apt.confにプロキシサーバが記述される。

普通(といえるかは自信がないが)インストールが終ったら、リブート前に CDは抜く。プロキシ経由のLANも、DHCPに慣れたユーザの関知しない ところだろう。少なくとも、GNOMEの厚いGUIからapt-getして、 エラーメッセージの山を前に頭を抱えるまでは。
便利で快適なシステムの陰の、鋭く深い亀裂を見た思いだった。

☆ 意外なPDFリーダ

display(1)でPDFを開けるなんて知らなかった。

$ ldd `which display`
  linux-gate.so.1 =>  (0xb7f4d000)
  libMagick.so.10 => /usr/local/lib/libMagick.so.10 (0xb7d71000)
  libWand.so.10 => /usr/local/lib/libWand.so.10 (0xb7cc4000)
  libtiff.so.3 => /usr/lib/libtiff.so.3 (0xb7c75000)
  libc.so.6 => /lib/libc.so.6 (0xb7b61000)
  libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb7b42000)
  libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0xb7b34000)
  libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0xb7ae5000)
  libz.so.1 => /usr/lib/libz.so.1 (0xb7ad2000)
  libpthread.so.0 => /lib/libpthread.so.0 (0xb7ac0000)
  libfreetype.so.6 => /usr/X11R6/lib/libfreetype.so.6 (0xb7a55000)
  libdl.so.2 => /lib/libdl.so.2 (0xb7a51000)
  libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0xb7a49000)
  libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0xb7a32000)
  libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0xb796a000)
  libm.so.6 => /lib/libm.so.6 (0xb7946000)
  /lib/ld-linux.so.2 (0xb7f4e000)

☆ mkpasswd(8)

$ for id in `seq 3`
> do mkpasswd -l 10 -d 4 -C 3 -c 2
> done
Aqz>3D98P1
W4Tp853Kg\
r22oV&88YT

☆ Yルータで IP Masqurade

Linux なら 一発メモだけど。

ip route default gateway $GW_ADDR
ip lan1 address $INNER_ADDR/MASK
ip lan2 address $OUTER_UNI_ADDR/MASK
ip lan2 nat descriptor 1
nat descriptor type 1 masquerade
nat descriptor address outer 1 $OUTER_UNI_ADDR
nat descriptor address inner 1 $INNER_NET_ADDR-$INNER_BROAD_ADDR

lan1 が内部ネットワーク、lan2 が外向け。
最終行は、LAN1 が 192.168.0.0/24 なら、 192.168.0.0-192.168.0.255 になる。らしい。

「site:kuzuore.com freebsd ルータ」 で検索。
さて、 昔やってうまくいった設定は、今でも有効なんだろうか。
今、手元には確認できそうな機器が...

☆ icmp-redirect

動的にルーティングテーブルが追記される。
例えばYamaha ルータでLAN内のゲートウェイを二重化すると、 デフォルトゲートウェイしか知らないLinuxやFreeBSDでは ルータからicmp redirect通知を受け取り、 以後、そちらをゲートウェイとしてデータを送信するようになる。
定義されていない行き先については、やはりデフォルトゲートウェイに 転送している。

が、この通知を取り消す方法が分からない。
変えた転送先をいつまでも覚えているように見える。
あるとすればルーティングテーブルの初期化か、 追加したルータ側からくらいだろうか。

$ sudo ip route flush dev $IF
$ sudo ip route add default via $ADDR

iptablesでicmp redirectを落とすように設定すると、 Windows(やraspbian)同様、redirect先にデータを送信しなくなった。

$ sudo iptables -A INPUT -p icmp --icmp-type 5 -j DROP

この場合、ping(1)は、
0. ホストからpingがデフォルトゲートウェイにecho requestが送信され、
1. デフォルトゲートウェイからルータ2に転送し、
2. ルータ2から(転送を重ねて)宛先に転送し、
3. 宛先から(転送を重ねて)ルータ2に返送され、
4. ルータ2からホストにecho replyが返る

というあたりになる。らしい。

☆ tcpdump ether

redirect を調べるに当たり、どのMACアドレスの 機器にデータを送受信しているか調べてみる。

$ sudo tcpdump -n -v -i br0 ether dst $MAC_ADDR
tcpdump: listening on br0, link-type EN10MB (Ethernet), \
 capture size 262144 bytes
 
14:26:36.949258 IP (tos 0x0, ttl 64, id 38763, offset 0,\
 flags [DF], proto ICMP (1), length 84)
    $IP_SRC_HOST > $IP_DST_HOST: ICMP echo request, \
 id 5087, seq 9, length 64

☆ crochet

仮想からリアルに移す。
できれば一般ユーザでやりたかったが、デバイス/dev/mdctlの書き込み がrootでないとできないようだ(変えても動くかは要確認)。

$ grep -v "^$\|^#" config
board_setup RaspberryPi
option ImageSize 8192mb
option Growfs
option User pi
option SwapFile 1024mb [deferred] [file=/swapfile0]
option UsrSrc
option Ntpd
FREEBSD_SRC=$DIR

流石に仮想でない環境は速い。i5(2.67GHz)+4GBだけど。
以下、 typescriptログ(若干編集済み)より。

$ time sudo sh crochet.sh -c ./config
Starting at 2016年 7月21日 木曜日 15時33分27秒 JST
Loading configuration from ./config
Board: RaspberryPi
Option: ImageSize 8192mb
Option: Growfs 
Option: User pi
Option: SwapFile 1024mb [deferred] [file=/swapfile0]
Option: UsrSrc 
Option: Ntpd 
Source version is: 303122
Building FreeBSD version: 12.0
//
Installing ubldr in boot
Adding user pi with password pi
SwapFile: Swapfile will be 1024 MB
SwapFile: Unrecognized parameter '[deferred]'
 
real    77m17.415s
user    263m58.365s
sys     11m45.250s

一応起動できたようだ。

$ uname -a
FreeBSD raspberry-pi 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r303122:
Thu Jul 21 16:45:19 JST 2016     \
root@$BSDHOST:$DIR/crochet/work/obj/arm.armv6/$DIR/work/source/sys/RPI-B  arm

☆ またfacebook.com

今度はアクセスして、ログインして、pingが平常に戻るまで 待っただけ。

☆ そんだけ

☆ To: <s[5

本文のないメールが届いた。

Return-Path: <vzfwrwqkcem@******.net>
X-Original-To: $MY_ADDR
Delivered-To: $MY_ADDR
Received: from ipv4-46-167-238-116.tkom.cz (unknown [46.167.238.116])
	by $MY_MAIL_SERVER (Postfix) with SMTP id 31FE84009F
	for <$MY_ADDR>; Tue, 20 Jul 2021 20:59:44 +0900 (JST)
From: "Alejandra Quintana" <vzfwrwqkcem@******.net>
To: <s[5

Jul 20 20:59:44 $SERVER postfix/smtpd[11223]:
 warning: hostname ipv4-46-167-238-116.tkom.cz does not resolve
 to address 46.167.238.116: Name or service not known
Jul 20 20:59:44 $SERVER postfix/smtpd[11223]: connect from unknown[46.167.238.116]
Jul 20 20:59:45 $SERVER postfix/smtpd[11223]: 31FE84009F: client=unknown[46.167.238.116]
Jul 20 20:59:46 $SERVER postfix/cleanup[11229]: 31FE84009F: message-id=<>
Jul 20 20:59:46 $SERVER postfix/qmgr[10618]: 31FE84009F:
 from=<vzfwrwqkcem@******.net>, size=298, nrcpt=1 (queue active)
Jul 20 20:59:46 $SERVER postfix/virtual[11230]: 31FE84009F:
 to=<$MY_ADDR>, relay=virtual, delay=1.3, delays=1.3/0.01/0/0,
 dsn=2.0.0, status=sent (delivered to maildir)
Jul 20 20:59:46 $SERVER postfix/qmgr[10618]: 31FE84009F: removed
Jul 20 20:59:46 $SERVER postfix/smtpd[11223]: disconnect from
 unknown[46.167.238.116] helo=1 mail=1 rcpt=1 data=1 quit=1 commands=5

一体何がやりたかったのだろうか。