今週の東京出張は日帰りではなくなった。
希望は前泊で出していたが却下される可能性もあり不安だったが、意外とあっさりと前泊を認めて貰えたので助かった。
さて、宿を探すか・・・
いつもなら浅草辺りで探すんだけど、今回はどこにしようかなぁ？
現場が渋谷なので、渋谷まで乗り換えなしで行けるところが良いなぁ（汗）。
More from: 仕事
←クリックしてくれると嬉しいです。
今週は久しぶりに東京行き
前々から気配はあったんだけど、今週は仕事で東京に行くことになった。
作業の日取りは6/28で決まっているんだけど、日帰りになるか前泊で行くことになるか、反対に当日宿泊で翌日帰ることになるかが未定。
出来れば前泊にして朝から作業をしたいなぁ（汗）。
←クリックしてくれると嬉しいです。
キーボードを替えてみた
仕事場に現場から古いが余り使った形跡の無いキーボードが送られて来た。
昨年PCを入れ替えた際に余ったものらしい。
その中に薄くて小型のがあったので私が使っているPCのキーボードと交換してみた。
小さくなってその分机の上が広くなったのはありがたいんだけど、デスクトップではあまり使わないアイソレーションタイプなのと、キーレイアウトが若干変わったので慣れるまでちょっと打ちにくそう。
ま、これは慣れるしか無いな（汗）。
←クリックしてくれると嬉しいです。
誤報、その二
先の記事とは全く関係ない話（汗）。
今日の午前中に仕事場で火災報知器が作動した。
訓練通り、すぐに廊下に出て周囲を確認したが特に火災が発生した様子は無かった。
数分後には誤報である旨の連絡があったが、発報した際にはエレベーターも最寄り階で非常停止する等したので、多少の混乱があった模様。
うーん、なにが原因で発報したのかな？
←クリックしてくれると嬉しいです。
NFSがつながらない・・・（解決編）
先日、「nfsがつながらない・・・」という記事を書いた。
その時にはクライアント側のサーバー（ややこしいな）の再起動をすれば解決するのでは無いかと考えていた。
今週に入って再起動の機会がある筈だったので、その時までなんとか我慢して運用かと思っていたところ、土曜の夜にトラブルで再起動の必要なサーバが止まってしまい、図らずも再起動となってしまった。
このことを知ったのは月曜になってからだったんだけど、早速nfsマウントを試してみるとやっぱり接続できないorz。
つまり、nfsサーバを先に停止したことが障害の原因では無かったということになる。
クライアント側に出るエラーは
”ポートマッパと接続できません: RPC: 遠隔システムエラー – ホストへの経路がありません”
と以前と同じものなので、やはりnfsサーバ側との通信が出来ていないことになる。
portmapperでは無いかとの指摘もあったが、nfsサーバ側のrpcinfoの結果を見る限りportmapperは動作している（ディストリビューションの関係で”portmap”ではなく”rpcbind”だったが）。
いろいろ考えた結果、ファイアウォール（iptables）に思い当たり、試しに/etc/rc.d/init.d/iptables stopで止めてみると、クライアント側からのrpcinfoコマンドにnfsサーバ側が応答してくるようになり、さらにnfsマウントも試したところ無事にマウント出来た。
つまり、先週から悩んでいたのはiptablesが原因だったということだ（汗）。
そこで、iptablesの設定で必要なポートを開けようとポート番号を調べてみたところ、現状で使っているポートが以下のようになっていた。
（rpcinfoの出力）
100021 1 udp 44644 nlockmgr
100021 3 udp 44644 nlockmgr
100021 4 udp 44644 nlockmgr
100021 1 tcp 35635 nlockmgr
100021 3 tcp 35635 nlockmgr
100021 4 tcp 35635 nlockmgr
100011 1 udp 875 rquotad
100011 2 udp 875 rquotad
100011 1 tcp 875 rquotad
100011 2 tcp 875 rquotad
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100005 1 udp 60503 mountd
100005 1 tcp 35344 mountd
100005 2 udp 48471 mountd
100005 2 tcp 42678 mountd
100005 3 udp 50205 mountd
100005 3 tcp 41105 mountd
100024 1 udp 56315 status
100024 1 tcp 57525 status
これを見るとmountdとstatusの二つは任意のポートを使っているようだ。
これではiptablesで沢山のポートを開けなくてはならず、セキュリティ的に不安なので使用するポートを固定する方法を調べた。
ポートを固定するにはnfsの設定ファイル（/etc/sysconfig/nfs）でコメントアウトされているポート番号（*_PORT）の項目のコメントアウトを外してnfsを再起動すれば良いとのこと。
早速実行してクライアント側でrpcinfoを実行してみた結果が下。
100021 1 udp 44644 nlockmgr
100021 3 udp 44644 nlockmgr
100021 4 udp 44644 nlockmgr
100021 1 tcp 35635 nlockmgr
100021 3 tcp 35635 nlockmgr
100021 4 tcp 35635 nlockmgr
100011 1 udp 875 rquotad
100011 2 udp 875 rquotad
100011 1 tcp 875 rquotad
100011 2 tcp 875 rquotad
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100005 1 udp 892 mountd
100005 1 tcp 892 mountd
100005 2 udp 892 mountd
100005 2 tcp 892 mountd
100005 3 udp 892 mountd
100005 3 tcp 892 mountd
100024 1 udp 662 status
100024 1 tcp 662 status
mountdが892、statusが662で固定されたので、それらを含む必要なポートをiptablesで開けるように設定したところ、iptablesを動作させてもnfsでのマウントもファイルへのアクセスも可能になった。
※当然ながらportmapperのポート（111）も開けるように設定した。
いやぁ、良かった良かった（汗）。
←クリックしてくれると嬉しいです。
今月は東京行きがあるかも
今月末頃に東京に行くことになるかもしれない。
というか、ほぼ間違いなく行く用事が出来そう・・・
遊びなら良いんだけど、仕事なので自由な時間が取れるかどうか・・・
出来ることなら自由時間を作っていろいろ乗りたいなぁ（汗）。
多分、日帰りということは無いと思うので、夜なら時間が取れそうな気がするけど、実際にはどうなることやら？
←クリックしてくれると嬉しいです。
mount解除は出来たものの・・・
仕事場のサーバの更新で、作業担当者がNFSサーバを先に止めてしまい、クライアント側でアクセス出来なくなってしまった。
クライアント側も一度止めて起動しなおせば良かったんだけど、こっちは止める予定が無かったのでそのままになっていた。
このことに気付いたのは作業が終了して運用に入ってから（汗）。
クライアント側でdfコマンドでマウント状況を見ようして途中で帰って来なくなって気付いた。
プロセスがディスク待ちとなってしまってシグナルを受け付けない状態で止められない。
こうなってしまっては一度再起動するしか手段は無いようだけど、すでに運用に入っているうえ、4年近く止めていないので起動時にfsckがかかるのが確実で起動にかかる時間が読めない。
mtabを見るとOS自体はNFSサーバの一部をマウントしたままと認識しているが、実際にはアクセス出来ない状態。
少なくとも、一度マウントを解除して再度マウントし直さなくてはならないんだけど、普通にumountコマンドで解除しようとしてもエラーが出て解除できない。
仕方がないので”umount -f”でやってみても駄目で、最後の手段”umoount -l”で試すとエラーは出たけどmtabからはエントリーが消えたので解除出来、df-kで見ても問題なく解除されていた。
後は再度マウントすれば良いんだけど、昨日の記事に書いたように再マウントできない状態になっている。
やっぱり再起動しないと駄目なんだろうなぁ・・・（汗）。
←クリックしてくれると嬉しいです。
nfsがつながらない・・・
仕事場のサーバ（群）を更新したら、nfsでのマウントが出来なくなった。
元々全てのサーバを仮想環境で動かしていて、その基盤自体を更新したので一部のサーバを除いて再起動となった。
それぞれのサーバの環境そのものは古い基盤からコピーしたので設定そのものに変化は無いが、一部の古い基盤上に残したサーバからnfsでの接続が上手く出来なくなってしまった。
もちろん両サーバの間の疎通確認は取れていて、pingやsshでの接続は問題無い。
ところが”mount -t nfs NFSサーバ:ディレクトリ マウントポイント”コマンドを実行すると,
“mount: RPC: ポートマッパーの失敗です – RPC: 受け取れません”
というエラーが表示されマウントできない。
nfsサーバ側ではnfsデーモンは動作させているのだけど、クライアント側からもチェックしてみようと思って、
”/usr/sbin/rpcinfo -p NFSサーバ”を実行すると、
”rpcinfo: ポートマッパと接続できません: RPC: 遠隔システムエラー – ホストへの経路がありません”
となってしまう。
つまりpingは通るけど、rpcinfoコマンドは通信できないらしい。
NFSサーバ側でrpcinfoコマンドを実行するとnfsもmountdも動作していると出る。
”arp -d NFSサーバ”でarpテーブルのエントリを削除しても変化無いので、今のところはお手上げ状態。
スタックさせたL3スイッチのトラブルがあったので、その影響らしいが再起動するしか無いのかなぁ？
←クリックしてくれると嬉しいです。
アップデート終了（汗）
仕事場のWindowsPCのアップデートが終了。
およそ2時間少々で終わってくれたのでようやく作業を再開できる（汗）。
他のPCのアップデートに比べると比較的短い時間で済んだ方かな？
←クリックしてくれると嬉しいです。
何も出来ないorz
仕事場のPCがしつこくアップデートしろと言ってくるようになって数日。
いつも「後で」ボタンをおしていたけど、今日はそのボタンが出なくなってしまった。
仕方がないので作業を中断して再起動をしたら、1時間ほど経ってもまだ14パーセントしか進まず何も出来ない。
夜までに終わってくれるのかなぁ？
←クリックしてくれると嬉しいです。