作者アーカイブ: t-saitoh

不動産系迷惑電話の相手との雑談をしていた。その中の話の中で、 ある程度のリスクを感じながらも、非難を受けるような記事を書かなければ、 炎上といったトラブルもないだろうし…ということで「オープン主義」で、 子供のバカ親ページを作っていたことを多少反省。

ということで、子供の実名記載の部分をBlog記事の中から呼び名に置換or削除を 行った。ひとまずMovableType上の記事からは、子供の実名は削除した。 といっても、写真なども解像度のそれなりに低い写真はたっぷり。 Blogエンジンを使う前の記事の中にも個人名もまだまだ残っている。

とはいえ、Blogは家族の中のアルバム的な意味もあるし、 それなりに記事は便利。 バカ親の視点でも100%見えなくするのもちょっと寂しい。 世知辛い時代に応じたバカ親なりの妥協点ということで、 外からは個人情報をそれなりに隠す意味で、 古い記事のディレクトリには.htaccessファイルで、 自宅外からのアクセス制限をかけようかな…

夕方の停電に続いて2度目の停電。 さすがにこれ以上のネットワークトラブルはないだろうと安心していたけ ど携帯から自宅サーバが見えない。 心配したけど、ダイナミックDNSのアドレスが停電で変わっただけ だった。 さすがに2度の停電でUPSが欲しくなる。

夜の7:00頃、自宅が停電になった。1分後ぐらいに復旧したけど、自宅サーバがどうもおかしい。 調べてみるとすべてのネットワークが動いていない。 WiFiルータが雷で壊れたかと思ったが、どうも動いている様子。 サーバを見てみると、どのネットワーク機器も通信ができない。 色々調べてみると、"ifup eth0"がうまく動かない。自宅サーバはDHCPも動かしているので、 他のネットワーク機器は総倒れ。他の機器に一時的に固定アドレスを振ると、internetにもつながるし、サーバのeth0 ( NIC=Intel e1000 ) が根本原因。 んで、その状況を確認すると、Macアドレスが00:00:00:00:00:00になっている。 よって、"e1000 Mac Address"でググると、この記事と状況がおんなじ。

BIOSのNIC関連のEEPROMのチェックサムが異常で、こうなるらしい。 先頭1byte目を無視するとか、 書いてあるけど、下記の状況じゃ、きれいさっぱりデータが飛んじゃったみたい。

(( dmesg より ))
e1000: 0000:02:0c.0: e1000_probe: The EEPROM Checksum Is Not Valid
/*********************/
Current EEPROM Checksum : 0x0000
Calculated              : 0xbaba
Offset    Values
========  ======
00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Include this output when contacting your support provider.
This is not a software error! Something bad happened to your hardware or
EEPROM image. Ignoring this problem could result in further problems,
possibly loss of data, corruption or system hangs!
The MAC Address will be reset to 00:00:00:00:00:00, which is invalid
and requires you to set the proper MAC address manually before continuing
to enable this network device.
Please inspect the EEPROM dump and report the issue to your hardware vendor
or Intel Customer Support.

ひとまずは、/etc/network/interfaces にて、Mac アドレスを手動設定する。 00:11.22:33:44:66は、自宅内じゃ同じ値になることもないだろうし、適当な値。

(( /etc/network/interfaces ))
auto eth0
iface eth0 inet static
hwaddress ether 00:11:22:33:44:66
address 192.168.xx.yy
netmask 255.255.255.0

職場でdebianのアップグレードをかけていたら、post-install でエラーのメッセージが 出るようになった。

E: Problem executing scripts DPkg::Post-Invoke
'if [ -x /usr/sbin/localepurge ]
&& [ $(ps w -p $PPID | grep -c remove) != 1 ];
then
/usr/sbin/localepurge;
else
exit 0;
fi'

どうも、localepurge が悪さしているみたい。 パッケージインストールで不要な locale 情報を消すだけのプログラムだし、 必須でもないから、"aptitude remove localepurge"を実行すると、 正常に"aptitude safe-upgrade"ができるように戻った。

昨日の夜に除雪しておいたけど、朝までには当然のごとく大量の雪が積もってた。 今朝はじいちゃんばあちゃんが早くから除雪してくれてて、ちょいと助かったけど、 車の上はこの有様。

IPv6のネットワーク接続ということで、gw6c を設定していたけど、 gw6c のバージョンアップで動かなくなった。 "/etc/init.d/gw6c start" を実行すると "gw6c – no server key …" と表示され、 接続に失敗する。

確認をすると、/var/lib/gw6c/gw6ckeys.pub あたりが原因で、/etc/default/gw6c をのぞくと、

# Check that the keyfile /var/lib/gw6c/gw6ckeys.pub has the key for your
# tunnel broker and abort if not.
# "yes" - Default, check for presence of key
# "no"  - Do not check for key, required if the name of the server is different
#         from its hostname. (for load balancing reasons for example)
#
# CHECK_KEYFILE="yes"

と書かれていたので、最後の行のコメントをはずし、"no"に変更すると、再び動くようになった。

(( /etc/default/gw6c ))
CHECK_KEYFILE="no"