24日静岡では、大きなイベントとして3つ有る。
- 安倍川はナビ
- 静岡ガンダム公開日
- ロボサッカー
濃い一日、そして、交通麻痺しそうな一日でござる:)
会社帰りの通り道で撮影。
前日のガンダムはこれだw
明るいレンズが欲しいなぁ。結構キツイ。
にしても、ガンダムの制服?衣装?コスプレをした大人がたくさん居たのだが、何かイベントがあったのだろうか。
それとも関係者・スタッフだったのだろうか。女子もいたし、肌色のスカートに衣装。うーん。悩
[IPネットワークアドレス] 2403:7a00::/32 [組織名] ソフトバンクテレコム株式会社 [Organization] SOFTBANK TELECOM Corp. [ネームサーバ] [割振年月日] 2010/07/23 [最終更新] 2010/07/23 15:17:16(JST)
会社のBBQで持ち出された物w
それは、、、あわもえ。
まずは、パッケージです!!
ラベルはこんな感じ!
呑みやすさは、泡盛が苦手な私でもさっぱりとのめて、泡盛という感じがあんまりしない感じで美味しくいただけました。
実は余り覚えていないので、飲みやすかったと言うこと、初心者でも万人受けしそうな感じということだけは足し課のようです。
そのほか、泡盛味比べという物も持ち込まれたので、写真掲載..
ということで、
というレポートや、
ニュー速VIPブログ:萌えパッケージの泡盛 「琉Q泡盛 あわもえ」 の可愛いイラストが人気などでネタになっているようです。
# zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT datapool1 928G 288G 640G 30% DEGRADED - rpool 67.5G 10.7G 56.8G 15% ONLINE -
# zpool status -v pool: datapool1 state: DEGRADED status: One or more devices are faulted in response to persistent errors. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Replace the faulted device, or use 'zpool clear' to mark the device repaired. scrub: none requested config: NAME STATE READ WRITE CKSUM datapool1 DEGRADED 0 0 0 mirror DEGRADED 0 0 0 c9t3d0 FAULTED 3 295 0 too many errors c9t1d0 ONLINE 0 0 0 c9t4d0 ONLINE 0 0 0
# iostat -En c7t0d0 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0 Vendor: LSILOGIC Product: Logical Volume Revision: 3000 Serial No: Size: 73.00GB <72999763968 bytes> Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0 Illegal Request: 0 Predictive Failure Analysis: 0 c9t1d0 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0 Vendor: ATA Product: ST31000528AS Revision: CC34 Serial No: Size: 1000.20GB <1000204886016 bytes> Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0 Illegal Request: 0 Predictive Failure Analysis: 0 c9t3d0 Soft Errors: 0 Hard Errors: 41 Transport Errors: 176 Vendor: ATA Product: WDC WD10EADS-00M Revision: 0A01 Serial No: Size: 1000.20GB <1000204886016 bytes> Media Error: 0 Device Not Ready: 0 No Device: 36 Recoverable: 0 Illegal Request: 0 Predictive Failure Analysis: 0 c9t4d0 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0 Vendor: ATA Product: WDC WD10EADS-00L Revision: 1A01 Serial No: Size: 1000.20GB <1000204886016 bytes> Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0 Illegal Request: 0 Predictive Failure Analysis: 0
抜粋してみる。
c9t3d0 Soft Errors: 0 Hard Errors: 41 Transport Errors: 176 Vendor: ATA Product: WDC WD10EADS-00M Revision: 0A01 Serial No: Size: 1000.20GB <1000204886016 bytes> Media Error: 0 Device Not Ready: 0 No Device: 36 Recoverable: 0 Illegal Request: 0 Predictive Failure Analysis: 0
orz
# zpool detach datapool1 c9t3d0 # zpool status -v pool: datapool1 state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM datapool1 ONLINE 0 0 0 mirror ONLINE 0 0 0 c9t1d0 ONLINE 0 0 0 c9t4d0 ONLINE 0 0 0 errors: No known data errors
# zpool attach datapool1 c9t4d0 c9t3d0 cannot open '/dev/dsk/c9t3d0': I/O error
# /opt/csw/sbin/smartctl -a /dev/rdsk/c9t3d0 smartctl version 5.36 [i386-pc-solaris2.8] Copyright (C) 2002-6 Bruce Allen Home page is http://smartmontools.sourceforge.net/ Standard Inquiry (36 bytes) failed [I/O error] Retrying with a 64 byte Standard Inquiry Standard Inquiry (64 bytes) failed [I/O error] A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.
お亡くなりに。。。
某IRCチャンネルでも話題にしていたのですが、FreeBSD8.1がリリースされたので、バージョンアップしました。
FreeBSD gw3.80 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Thu Jul 22 14:43:05 JST 2010 root@gw3.80:/usr/obj/usr/src/sys/TOMOCHA i386
でも、色々とはまったんですよ。これが。
zfs 周りのチューニングをしているので、GENERICでつくると、メモリが足りなくて、カーネルパニックするんです。
ことで、やっちゃいました(笑)
ま、それは良いとして、微妙なバグ?があり、カーネルを正常に作れない罠にはまりました。
GENERICをまんま、コピーを取り、identだけ書き換えて、TOMOCHA を作成します。
で、歴史的やり方で作業をしてみると...
# cd /usr/src; \ chflags -R noschg /usr/obj/usr ; \ rm -rf /usr/obj/usr ; \ make clean # cd /usr/src/sys/i386/conf/ # config TOMOCHA Kernel build directory is ../compile/TOMOCHA Don't forget to do ``make cleandepend && make depend'' cd ../compile/TOMOCHA # make cleandepend && make depend --- ===> usb/run (depend) @ -> /usr/src/sys machine -> /usr/src/sys/i386/include rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/src/sys/i386/compile/TOMOCHA /usr/src/sys/modules/usb/run/../../../dev/usb/wlan/if_run.c In file included from /usr/src/sys/modules/usb/run/../../../dev/usb/wlan/if_run.c:69: ./usbdevs.h:565:36: error: unterminated comment mkdep: compile failed *** Error code 1 Stop in /usr/src/sys/modules/usb/run. *** Error code 1 Stop in /usr/src/sys/modules/usb. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/src/sys/i386/compile/TOMOCHA.
orz
で、新しいやり方でやってみると。。。
# cd /usr/src # make buildkernel KERNCONF=TOMOCHA # make installkernel KERNCONF=TOMOCHA
ちゃんといける。うーん。謎だ(T_T
この話をしたところ、
> あ、config(8) に修正入ってるけど、新しい config(8) を使ってるよね?
という神のお声があったが、ダメでした。
ピンポイントでコンパイルしたいとき意外は、色々とケアされている、buildkernelを使うのが最近の流儀のようなので、そっちを使いましょうってことで。
このプレスリリースが出たのでDNSを確認してみた。
IN MX 20 mx6.iij4u.or.jp. IN MX 10 mx.iij4u.or.jp.
となっており、MX 10はv4で、DNS ラウンドロビン、 MX 20 は v6 で、DNS ラウンドロビンという状態になっていた。
以前、同一のMXのレコードにAとAAAAを書くと、正しく受信出来ないという問題が、
[janog:08776] デュアルスタックのSMTP
等で報告されていたが、その辺の回避の為だろうか。
$ dig @dns0.iij.ad.jp dd.iij4u.or.jp mx ;; QUESTION SECTION: ;dd.iij4u.or.jp. IN MX ;; ANSWER SECTION: dd.iij4u.or.jp. 900 IN MX 20 mx6.iij4u.or.jp. dd.iij4u.or.jp. 900 IN MX 10 mx.iij4u.or.jp. ;; AUTHORITY SECTION: iij4u.or.jp. 36000 IN NS dns0.iij.ad.jp. iij4u.or.jp. 36000 IN NS dns1.iij.ad.jp. ;; ADDITIONAL SECTION: mx.iij4u.or.jp. 600 IN A 210.138.174.71 mx.iij4u.or.jp. 600 IN A 210.138.174.72 mx.iij4u.or.jp. 600 IN A 210.138.174.69 mx.iij4u.or.jp. 600 IN A 210.138.174.70 mx6.iij4u.or.jp. 600 IN AAAA 2001:240:bb41:8011::1:70 mx6.iij4u.or.jp. 600 IN AAAA 2001:240:bb41:8011::1:71 mx6.iij4u.or.jp. 600 IN AAAA 2001:240:bb41:8011::1:72 mx6.iij4u.or.jp. 600 IN AAAA 2001:240:bb41:8011::1:69 dns0.iij.ad.jp. 86400 IN A 210.138.174.16 dns0.iij.ad.jp. 86400 IN AAAA 2001:240:bb41:8002::1:16 dns1.iij.ad.jp. 86400 IN A 210.138.175.5 dns1.iij.ad.jp. 86400 IN AAAA 2001:240:bb4c:8000::1:5 ;; Query time: 28 msec ;; SERVER: 2001:240:bb41:8002::1:16#53(2001:240:bb41:8002::1:16) ;; WHEN: Wed Jul 28 17:42:11 2010 ;; MSG SIZE rcvd: 380
$ dig @dns0.iij.ad.jp ff.iij4u.or.jp mx ;; QUESTION SECTION: ;ff.iij4u.or.jp. IN MX ;; ANSWER SECTION: ff.iij4u.or.jp. 900 IN MX 10 mx.iij4u.or.jp. ff.iij4u.or.jp. 900 IN MX 20 mx6.iij4u.or.jp.
$ dig @dns0.iij.ad.jp hh.iij4u.or.jp mx ;; QUESTION SECTION: ;hh.iij4u.or.jp. IN MX ;; ANSWER SECTION: hh.iij4u.or.jp. 900 IN MX 10 mx.iij4u.or.jp. hh.iij4u.or.jp. 900 IN MX 20 mx6.iij4u.or.jp.
$ dig @dns0.iij.ad.jp kk.iij4u.or.jp mx ;; QUESTION SECTION: ;kk.iij4u.or.jp. IN MX ;; ANSWER SECTION: kk.iij4u.or.jp. 900 IN MX 20 mx6.iij4u.or.jp. kk.iij4u.or.jp. 900 IN MX 10 mx.iij4u.or.jp.
$ dig @dns0.iij.ad.jp nn.iij4u.or.jp mx ;; QUESTION SECTION: ;nn.iij4u.or.jp. IN MX ;; ANSWER SECTION: nn.iij4u.or.jp. 900 IN MX 10 mx.iij4u.or.jp. nn.iij4u.or.jp. 900 IN MX 20 mx6.iij4u.or.jp.
$ dig @dns0.iij.ad.jp pp.iij4u.or.jp mx ;; QUESTION SECTION: ;pp.iij4u.or.jp. IN MX ;; ANSWER SECTION: pp.iij4u.or.jp. 900 IN MX 10 mx.iij4u.or.jp. pp.iij4u.or.jp. 900 IN MX 20 mx6.iij4u.or.jp.
$ dig @dns0.iij.ad.jp rr.iij4u.or.jp mx ;; QUESTION SECTION: ;rr.iij4u.or.jp. IN MX ;; ANSWER SECTION: rr.iij4u.or.jp. 900 IN MX 20 mx6.iij4u.or.jp. rr.iij4u.or.jp. 900 IN MX 10 mx.iij4u.or.jp.
$ dig @dns0.iij.ad.jp ss.iij4u.or.jp mx ;; QUESTION SECTION: ;ss.iij4u.or.jp. IN MX ;; ANSWER SECTION: ss.iij4u.or.jp. 900 IN MX 10 mx.iij4u.or.jp. ss.iij4u.or.jp. 900 IN MX 20 mx6.iij4u.or.jp.
$ dig @dns0.iij.ad.jp uu.iij4u.or.jp mx ;; QUESTION SECTION: ;uu.iij4u.or.jp. IN MX ;; ANSWER SECTION: uu.iij4u.or.jp. 900 IN MX 10 mi-stg.iij4u.or.jp. uu.iij4u.or.jp. 900 IN MX 20 mi6-stg.iij4u.or.jp. ;; ADDITIONAL SECTION: mi-stg.iij4u.or.jp. 36000 IN A 210.138.174.86 mi6-stg.iij4u.or.jp. 36000 IN AAAA 2001:240:bb41:8011::1:86
$ dig @dns0.iij.ad.jp bc.iij4u.or.jp mx ;; QUESTION SECTION: ;bc.iij4u.or.jp. IN MX ;; ANSWER SECTION: bc.iij4u.or.jp. 900 IN MX 10 mx.iij4u.or.jp. bc.iij4u.or.jp. 900 IN MX 20 mx6.iij4u.or.jp.
$ dig @dns0.iij.ad.jp bk.iij4u.or.jp mx ;; QUESTION SECTION: ;bk.iij4u.or.jp. IN MX ;; ANSWER SECTION: bk.iij4u.or.jp. 900 IN MX 20 mx6.iij4u.or.jp. bk.iij4u.or.jp. 900 IN MX 10 mx.iij4u.or.jp.
$ dig @dns0.iij.ad.jp bp.iij4u.or.jp mx ;; QUESTION SECTION: ;bp.iij4u.or.jp. IN MX ;; ANSWER SECTION: bp.iij4u.or.jp. 900 IN MX 10 mx.iij4u.or.jp. bp.iij4u.or.jp. 900 IN MX 20 mx6.iij4u.or.jp.
$ dig @dns0.iij.ad.jp bu.iij4u.or.jp mx ;; QUESTION SECTION: ;bu.iij4u.or.jp. IN MX ;; ANSWER SECTION: bu.iij4u.or.jp. 900 IN MX 10 mx.iij4u.or.jp. bu.iij4u.or.jp. 900 IN MX 20 mx6.iij4u.or.jp.
layer0.jp の木下氏が協力してくれたので、調べてみた。
$ dig @dns-d.iij.ad.jp. layer0.jp mx ;; QUESTION SECTION: ;layer0.jp. IN MX ;; ANSWER SECTION: layer0.jp. 28800 IN MX 10 mbox-mx.iijmio.jp. layer0.jp. 28800 IN MX 20 mbox-mx6.iijmio.jp. ;; AUTHORITY SECTION: layer0.jp. 28800 IN NS dns-d.iij.ad.jp. layer0.jp. 28800 IN NS dns-e.iij.ad.jp. $ host mbox-mx.iijmio.jp. mbox-mx.iijmio.jp has address 210.138.77.165 mbox-mx.iijmio.jp has address 210.138.77.166 $ host mbox-mx6.iijmio.jp. mbox-mx6.iijmio.jp has IPv6 address 2001:240:bb41:8012::1:166 mbox-mx6.iijmio.jp has IPv6 address 2001:240:bb41:8012::1:165
上記のようになっていた。
DualStack環境なFreeBSD、Postfix 2.5.6 からメールを送信してみたところ、MXの順番でしか判断していないので、IPv4でしか届かなかった。
===== Jul 28 18:02:45 bsdsrv15 postfix/smtp[9755]: 9487B9B46D: to=<XXXXX _at_ layer0.jp>, relay=mbox-mx.iijmio.jp[210.138.77.166]:25, delay=0.46, delays=0.01/0/0.19/0.26, dsn=2.0.0, status=sent (250 2.0.0 o6S92i6R003644 Message accepted for delivery) ===== Received: from XXXX (XXXXX [202.171.149.XXXXX]) by mbox-mx.iijmio.jp (mi11) id o6S92i6R003644 for <XXXXX _at_ layer0.jp>; Wed, 28 Jul 2010 18:02:44 +0900
IIJからのメールの受け取りについて実験。
受け取り側のMXがIPv6の優先度が高い状態で試すと、次のような結果になり、正しくIPv6で受け取り(IIJ側から射出)が出来た。
gyojya.jp. 3600 IN MX 30 mx2.gyojya.jp. gyojya.jp. 3600 IN MX 10 mx6.gyojya.jp. gyojya.jp. 3600 IN MX 20 mx0.gyojya.jp. mx6.gyojya.jp. 3600 IN AAAA 2001:200:564::2002 mx0.gyojya.jp. 3600 IN A 115.146.17.180 mx2.gyojya.jp. 3600 IN A 202.171.149.235 ===== Received: from mo.iijmio.jp (mo11.iijmio.jp [IPv6:2001:240:bb41:8012::1:171]) by mx6.gyojya.jp (Postfix) with ESMTP id 534579B427 for <tomo _at_ gyojya.jp>; Wed, 28 Jul 2010 18:16:58 +0900 (JST)
次に、下記の様に、MXに対して、AとAAAAがついているDualStackの状態で実験してみたところ、IPv4が優先された。
MX 10 hoge.example.com A 10.10.10.10 AAAA 2001:DB8:1000::25
Received: from mo.iijmio.jp (mo11.iijmio.jp [210.138.77.171]) by XXXXXX.XXXXXX.XXXXX (8.14.1+3.5Wbeta/8.14.1/smtpfeed 1.20)
IPv6 Only でない環境以外であれば、IPv4が優先、MXの優先順位にv6の方が高ければ、v6が利用されると言うことが分かった。
ってことは、殆どのケースでは、IPv4が優先されるのではないかと、考えられる。
独立行政法人情報通信研究機構、F5ネットワークスジャパン株式会社、KDDI株式会社、ソフトバンクBB株式会社、タレスジャパン株式会社、日本電信電話株式会社、株式会社バッファロー、パロアルトネットワークス合同会社、ブロケード コミュニケーションズシステムズ株式会社、マイクロソフト株式会社の10社・団体は共同で、IPv6(注1) の安全性、相互運用性を向上させ、安心、安定した利用を実現するため、「IPv6技術検証協議会」を7月28日(水)に設立し、活動を開始したことを発表します。企業・団体が協力して協議会を設立し、IPv6の利用環境における安全性を検証するのは、世界初の取り組みとなります。
株式会社バッファロー。。。。
ちゃんとした物(ry
駄目ルコをぬぐい取れるか!?
以前Buffaloのビジネススイッチと、CiscoとTagVLANを組んだとき、パケットロスするという相性問題が発生したのでサポートに問い合わせしたら、Cisco製品との動作検証は行っていないためサポート出来ませんとかいいやがったメーカーなので。それっきり信用しなくなりましたw
[IPネットワークアドレス] 2403:8a00::/32 [ネットワーク名] [組織名] アクセリア株式会社 [管理者連絡窓口] TT11297JP [技術連絡担当者] TT11297JP [Abuse] ttakeda _at_ accelia.net [ネームサーバ] [割振年月日] 2010/07/27 [最終更新] 2010/07/27 11:03:39(JST)
abuse に普通の担当者のメールアドレスが入っているのは初めて見た。