特にテーマを定めず気楽に書く日記（主に温泉やパソコン、アニメ、カメラに関することになるかな？） リンクはトップページ、個別記事のどちらでもご自由に。写真等の転載は該当記事へのコメント等でご連絡を頂けるとブログ主が喜びます。
米IBMがLinux ディストリビューターのRedHatを買収すると発表した。
法的な問題がクリアできれば買収は2019年中に完了する見込みとのこと。
RedHatと言うとLinuxの普及に大いに影響を与えた企業で、現在はデスクトップ用のLinux開発はFedoraプロジェクトに移管し本体は企業向けエンタープライズ事業及びクラウド事業を進めている。
IBMとは以前からエンタープライズ事業で協力してきており、今回の買収はIBMがRedHatのもつクラウド事業に目を付けたものと報道されている。
私も何度かRedHatLinuxをPCにインストールしてサーバーとして使ったりしていたが、まさかIBMが買収するとはねぇ、、、
先日、「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）も開けるように設定した。
いやぁ、良かった良かった（汗）。
Linuxサーバの再起動が必要になるのがほぼ確実なんだけど、1200日以上無停止で稼働しているサーバなので、再起動時にfsckが走ることになる。
そうなると起動が終わるまで長時間サービスを停めることになるので出来ればfsckを走らせたくない。
調べてみると起動時のfsckの実行を抑止する方法があった。
一つ目はfstabの6つ目のパラメータを”0″にする方法で、これだとヴォリュームラベル/デヴァイス単位で設定出来る。
二つ目はshutdownコマンドのオプションで”-f”（fastboot）を指定する方法で、このオプションを付けると”/”にfastbootというファイルを作成し、次回のboot時にbootプロセスがfsckをスキップする（ことを期待する）。
今回は全てのディスクのfsckをスキップさせたいので、”shutdown -f -r”を試してみようかな？
問題は短時間とは言え提供中のサービスを止めるのでタイミングをどうするかだなぁ（汗）。
仕事場のサーバの更新で、作業担当者がNFSサーバを先に止めてしまい、クライアント側でアクセス出来なくなってしまった。
クライアント側も一度止めて起動しなおせば良かったんだけど、こっちは止める予定が無かったのでそのままになっていた。
このことに気付いたのは作業が終了して運用に入ってから（汗）。
クライアント側でdfコマンドでマウント状況を見ようして途中で帰って来なくなって気付いた。
プロセスがディスク待ちとなってしまってシグナルを受け付けない状態で止められない。
こうなってしまっては一度再起動するしか手段は無いようだけど、すでに運用に入っているうえ、4年近く止めていないので起動時にfsckがかかるのが確実で起動にかかる時間が読めない。
mtabを見るとOS自体はNFSサーバの一部をマウントしたままと認識しているが、実際にはアクセス出来ない状態。
少なくとも、一度マウントを解除して再度マウントし直さなくてはならないんだけど、普通にumountコマンドで解除しようとしてもエラーが出て解除できない。
仕方がないので”umount -f”でやってみても駄目で、最後の手段”umoount -l”で試すとエラーは出たけどmtabからはエントリーが消えたので解除出来、df-kで見ても問題なく解除されていた。
後は再度マウントすれば良いんだけど、昨日の記事に書いたように再マウントできない状態になっている。
やっぱり再起動しないと駄目なんだろうなぁ・・・（汗）。
仕事場のサーバ（群）を更新したら、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スイッチのトラブルがあったので、その影響らしいが再起動するしか無いのかなぁ？
Linuxサーバーで自動的に作成しているファイルが作られていないとの連絡が来た。
調べてみるとファイルの先頭と最後だけが作られている。
ヘッダとフッタは固定文字列を出力しているため、中身だけが全く無い状態。
試しに手動で同じスクリプトを動かしてみると、中で使っているsortコマンドが/tmp以下に作るファイルがスペースが無くて作れないというエラーを吐いて処理が落ちた。
確かに基にしたファイルはいつになく大きいのでsortするにもいつも以上にディスクを必要としているようだ。
かと言って/tmpを含むファイルシステムを拡張するわけにもいかないので、テンポラリファイルの作成先を変更することにした。
それには環境変数”TMPDIR”を設定するか、sortに”-T”オプションでテンポラリファイル作成用ディレクトリを指定するかのどちらかが必要。
今回は”-T”オプションで容量に余裕のあるファイルシステム上のディレクトリを指定するようにしたら問題無くファイルが作成された。
いや、まさかあんな大容量のファイルを相手にすることになるとは想定外だったなぁ（汗）。
昨夕職場のサーバーのスクリプトを少し変更した。
たいした変更では無かったのでぶっつけ本番で動作させて、今日は結果を確認しに来た。
そうしたらなんと作られるべきファイルが作成されていないorz。
確認だけして問題無ければさっさと帰ろうと思っていたんだけど、これでは帰ることが出来ない（汗）。
まずは作られるべきファイルを作らなければならないので、元になったファイル等を確認すると問題無く存在したので、問題のスクリプトが行う処理を手動で行い、途中からは別スクリプトで作成させたところやはり作られない。
修正箇所を何度か見直したところ、ファイルパスのタイプミスが原因だったorz。
早速正しいパスに修正して動作させてみると無事にファイルは作られた。
いやぁ、少しの修正でもちゃんと検証しないと駄目だねぇ（汗）。
反省反省・・・
職場のサーバーの設定を確認しようとして普段入り浸っている（笑）サーバーからtelnetで入ろうとした。
ところが何故かtelnetがはじかれてしまって入れない。
滅多にログインしない（＝安定動作している）サーバーなので、入るのも年単位ぶりで細かい設定を忘れていたが、どうもtelnet接続を制限しているようだ。
そこでサーバーを経由しないでPCから直接接続を試みると無事に入れたのでtelnetの設定から見直すことにした。
このサーバーはxinetd経由で各サービスを動作させているので、/etc/xinetd.d以下のファイルで各サービスの設定を行っている。
その中のtelnetファイルを見ると、案の定”only_from”で接続を許可するホストを限定していた。
そこで最初に接続しようとして入れなかったサーバー等を追記してxinetdを再起動。
ついでに不便なので特定のネットワークを許可するために”192.168.xxx.0/24”も追加しておいた。
これで他のサーバーからも接続できるようになって使いやすくなった。
職場のサーバーにsquidを導入してurlフィルタリングを始めたところ、何らかの理由でネットの速度が落ちてしまっていた。
そこで朝一の混雑時だけフィルタリングして、その後はsquidを通さないように運用していた。
その後調べたところ、cache.logにファイルディスクリプタ不足の警告が出ていたので、キャッシュ用ファイルの数をデフォルトの1024から増やしてsquidを再起動して運用してみた。
そうしたところ、朝一の混雑時でも警告が出なくなり、現場からもネットが遅いという報告が入って来なくなった。
どうやら原因はこのファイルディスクリプタ不足によるsquidの応答遅延だったようだな。
とにかくこれでしばらくは運用できそうだ。
先日から導入したsquidが重いということで、運用でなんとかカバーしているが、重たい（と言われる）原因を探ってみた。
サーバーのCPU負荷やメモリ使用量を調べてみると、これが実に軽くてサーバーそのものの処理能力が不足しているわけでは無さそう。
となるとこの手のソフトウェアでよくある”同時接続数が足りない”のが原因では無いだろうか？
一体どれだけの同時接続数が許容されているのか？ということでググって見ると、デフォルトでは1024らしい。
その接続数は/etc/squid/squid.confで指定できるらしいことも判明。
ところが、その数値を増やすだけでなく、OSが同時にオープンできるファイル数（キャッシュ用）も増やさなくてはならないらしい。
とにかく、この対策をしてみて経過を見ることにしよう。