気がつけばこんなことになっていた。
iPad、nexus7、iPod touch
先日のことです。
これまでcvsup mirrorサーバをローカルに立てておいて、それを使ってportsを最新に更新していたのですが、portsをcvsupで配布するのをやめるよ、というアナウンスが出てしまったので、そろそろportsnapへ乗り換えなければならぬ、ということになりました。
でもって、portsnapを実行して動作確認しているうちに、こんなメッセージがでました。
Looking up portsnap.FreeBSD.org mirrors... none found.
Fetching snapshot tag from portsnap.FreeBSD.org... done.
Latest snapshot on server is older than what we already have!
Cowardly refusing to downgrade from Wed Sep 19 09:11:07 JST 2012
to Tue Sep 18 17:32:04 JST 2012.
ネットからダウンロードしようとしたファイルが、すでに持っているファイルよりも古いぞ、っていうことですが。
え~っと、どういうこと?と3秒ほど悩んで、ピンときました。
そんなところでしょうか。
というわけで、portsnapの中を眺めてみます。ただのshスクリプトです。
どうやらここらしいな、というところを発見。
またfetchか・・・
どうもfetchは、出来が悪いです。http proxyサーバのcacheを使わせないようにするために、Pragma: no-cacheみたいのを出してやればいいはずですが、その機能がfetchには無いみたいです。
というわけで、fetchをwgetに置き換えました。
# Fetch a snapshot tag
fetch_tag() {
rm -f snapshot.ssl tag.new
echo ${NDEBUG} "Fetching snapshot tag from ${SERVERNAME}... "
#fetch ${QUIETFLAG} http://${SERVERNAME}/$1.ssl \
/usr/local/bin/wget --no-cache ${QUIETFLAG} http://${SERVERNAME}/$1.ssl \
2>${QUIETREDIR} || true
if ! [ -r $1.ssl ]; then
echo "failed."
return 1
fi
一発目の、このファイルだけ、cacheを使わせないようにしておけば十分なようです。
それ以外のファイルは、cacheを使っても大丈夫。というか、そうしないと、portsnapのサーバに負担をかけすぎることになるので、cacheを使うべきでしょう。
安いから、というだけの理由で買ってしまいました。
nexus 7
まだぜんぜん使ってません。
箱をあけて、電源を入れてみて、WiFiの設定をして、Googleのアカウントを入れたとこまで。
ネットで購入しようとしたら、なぜかカードで買えなかったので、ビックカメラに行って予約。いつ買えるかわからないと言われましたが、発売日の夕方に購入できると電話連絡があり、次の日行こうと思ったら雨だったのでやめて、…そんなこんなで、ようやく購入となりました。
以前から、中華タブレットというのを買おうかなと考えていたところなので、まあ、これでもいいか、ということでnexus7。
Windows Server 2008 R2なるものを初めてインストールしてみました。
ふと気がつけば、ping(ICMP echo request)に応答しないので、死活監視ツールなどから動いているように見えてない。
いつのころからか、Windowsってデフォルトでpingに応答しないようになってるので、設定変更しなければと…
たしか、Windowsファイアウォールの設定じゃなかったっけ?
Windows 7とかもそうだったけど、どんどん設定項目が複雑化しているようなきがするな・・・
えーと、どこだ・・・
見つからないなー
わからないねー
ヘルプみるか
もっとわかんないー
グーグルで検索しよう
一発ですぐわかった
正解は
ファイルとプリンターの共有(エコー要求 - ICMPv4受信)
でした。
「ファイルとプリンターの共有」なんてところにあるとは、まったく想像もつきませんでした。
Windowsが得意な人には、そんなの常識だよ!と言われるかもしれませんが。
どうでもいいんですが、「セキュリティが強化されたWindowsファイアウォール」という長い名称が、正式名称なんでしょうか。なんとなく、英語版でどう書かれているか見てみたいです。勝手な憶測ですが、例のごとく翻訳がアレなんではないかと。
あるサーバに、FreeBSD 9.1-RC1をインストールしてみました。
LANがたくさんついていて、igbで認識されるネットワークインターフェースがたくさん出てくるのですが、なぜか2個までしか使えません。3個めのインターフェイスをupさせると、動いているように見えて、実際には通信できません。
最初まったく気がついていませんでしたが、こんなエラーメッセージがコンソールに出ていました。
igb5: link state changed to DOWN
igb5: Could not setup receive structures
よくわかっていませんが、いったんdownさせてからupさせるらしいので、1行目は関係なさそう。
Could not setup receive structuresをキーワードに、googleで検索してみました。
以前からある有名な(?)症状らしく、バッファ容量を計算するところが、今時のマルチプロセッサ構成にあっていないのか(?斜め読みなのでよく理解していない)、自動計算される値では足りないらしいです。
このあたりを参考にしました。
http://lists.freebsd.org/pipermail/freebsd-stable/2010-October/059533.html
http://redmine.pfsense.org/issues/1221
http://forums.freenas.org/archive/index.php/t-3122.html
とりあえず、/etc/sysctl.conf でパラメータをチューニングしてやれば動くようになる・・・らしいことがわかりました。
デフォルトではこんな感じになっているので
kern.ipc.nmbjumbo16: 3200
kern.ipc.nmbjumbo9: 6400
kern.ipc.nmbjumbop: 12800
kern.ipc.nmbclusters: 25600
/etc/sysctl.conf でこんな風に指定してみました。
kern.ipc.nmbjumbo16=32000
kern.ipc.nmbjumbo9=64000
kern.ipc.nmbjumbop=262144
kern.ipc.nmbclusters=262144
全部のインターフェイスはまだ使っていませんが、いまのところ、動いているみたいです。
GNOMEは、内部の仕組みなどぜんぜん理解せずに使ってますが…
とあるアプリケーションが、間違ったプロキシーサーバの設定で動いていて、どういうことだ?と思って、GDBでステップ実行しながら調査。
間違ったプロキシーサーバ設定っていうのは、実は昔の設定でして、現在は変更したのに、なぜかそのアプリケーションだけ、昔の設定を使っている、ということで、いったいどこからその設定をひっぱりだしているんだろう? という状況。
で、わかりました。普通、GNOME環境で設定するプロキシーサーバの情報は、gconfの方に格納されるらしいのですが、なぜか、そのおかしな挙動をしめすアプリケーションは、dconfの方から、プロキシーサーバの設定をもってきていました。
う~ん、dconf、gconf、よくわかっていませんが
dconf-editorを実行すると、こんな感じでした。
一方、gconf-editorはこんな感じ。両者の内容は、まったくの別物。
というわけで、dconf-editorで、古い設定を直してやればいいのかと思ったけど、なぜか、編集できない。editorと名前がついているのに、編集できない。どういうことだ
gsettingsというコマンドがあって、こいつを使うと、変更できることがわかった。実際には、$HOME/.config/dconf/user にアクセスしているらしい。
値を見るにはgetを使う
% gsettings get org.gnome.system.proxy.http host
'proxy.example.co.jp'
値を消すにはreset。消すのではなく、デフォルト値に戻すだけかもしれない。
% gsettings reset org.gnome.system.proxy.http host
どんなキーがあるか知りたいときは、list-keysだった。
% gsettings list-keys org.gnome.system.proxy.http
authentication-password
authentication-user
enabled
host
port
use-authentication
ちなみに、gconfの場合は、gconftool-2というコマンドが用意されていることがわかった。こんな感じ。
% gconftool-2 -g /system/http_proxy/host
proxy.example.com
先々月くらいでしたか、FreeBSDのportsの、libiconvがversion 1.14にアップデートされたとき、EXTRA_PATCHESというオプションが無くなったため、EUCJP-MSが使えなくなってしまいました。
詳しいことはわからないけど、おまじないのように、smb.confでEUCJP-MSを指定していたのですが、EUCJP-MSってもう使わなくていいものなんでしょうかね???
うちでは、とりあえず、古いlibiconvに戻して、そのまま使っているんですけど。
でも、ネット検索してみると、libiconv 1.14用のパッチが提供している方がおられました。
http://apolloron.org/software/libiconv-1.14-ja/
libiconv-1.14 日本語パッチ
たとえば、portsをこんな感じ↓↓↓に直せば、EXTRA_PATCHESが復活します。
「ports-libiconv.patch.txt」をダウンロード
一応、これでlibiconvをビルドしなおして、sambaでEUCJP-MSを指定しても、エラーが出ないことは確認しました。
う~ん、よくわかってなかったりしますが。
CentOS 5なサーバで、ひさしぶりにyum updateして、rebootしたら、どうもautomountが正しく動いていないらしい。
ログを見てみると、こんな感じで、/etc/nsswitch.confが読めないってどういうこと?
automount[*PID*]: Starting automounter version 5.0.1-0.rc2.164.el5_8, master map auto.master
automount[*PID*]: using kernel protocol version 5.02
automount[*PID*]: nsswitch_parse:173: couldn't open /etc/nsswitch.conf
automount[*PID*]: lookup_nss_read_master: can't to read name service switch config.
automount[*PID*]: no mounts in table
ネット検索してみて、ズバリを発見
http://www.mail-archive.com/centos@centos.org/msg86851.html
SELinuxが有効な環境で起きる問題らしく、sudoの最近のアップデートを適用したときに、/etc/nsswitch.confに、間違った属性が設定されてしまう、っていうことらしい。
# ls -Z /etc/nsswitch.conf
-rw-r--r-- root root root:object_r:rpm_script_tmp_t /etc/nsswitch.conf
詳しくないのでよくわからないけど、rpm_script_tmp_tというのが間違っているらしい。
直し方は、これでいいらしい
# restorecon /etc/nsswitch.conf
確認してみる
# ls -Z /etc/nsswitch.conf
-rw-r--r-- root root system_u:object_r:etc_t /etc/nsswitch.conf
あとは、service autofs restartで、automountを再起動。
・・・直りました。
昔、HP ProLiant ML115 G5というのを買ったんですが、最近はほとんど使うことも無く。
それじゃあ!ってことで・・・
バックパネル部分を、ニブリングカッターで切り取って、別のマザーボードを入れちゃいました。
切るのはけっこう大変で、途中で疲れちゃった。今回は、ここまでで許してやる、ってことにしてあります。もうちょっと切り取れば、バックパネルをはめられると思うのですが、握力の限界。その後、2~3日、手に力が入りませんでした
おや?っと思ったのが、LEDや電源スイッチがつながっているコードの部分。こんなふうに、1個のコネクタにまとめられちゃっています。
どれがどこにつながっているのか、一応、メモっておきましたが・・・見づらい
このままじゃ使えないので、コードを切断して圧着コネクタをつけちゃいました。
■ 過去記事