More from: server

Perlのバージョンを・・・・・・

職場で動作させているLinuxサーバの内の1台がPerlのバージョンが古くて必要なパッケージがインストール出来ない。
インストールをお願いした業者さん曰く、「5.6以降のバージョンが必要ですが、現在インストールされているのは5.0です。」だそうなので、5.6以降のバージョンを探してきてインストールしなくてはならない。
まぁこれは探してくればなんとかなるのだけど、同じディストリビューションのLinuxが他にもあって、そちらには5.6以降のPerlがインストールされていたのは不思議だ・・・・・・
どっちのサーバも私が構築したものなんだけど、なんでバージョンが違うんだろ?
両方とも明示的にPerlを使うようなことはしていないから、後からバージョンを上げた記憶は無いんだけどなぁ?

←クリックしてくれると嬉しいです。

Windows2000サーバでネットワーク接続のアイコンが消えていた

昨夜サーバのトラブルでHDDのチェックをしている時に「この現象って判りますか?」と訊かれた。
どんな現象かな?と思っていると、実際に症状を見せてくれた。
その現象とはタイトルに書いたようにWindows2000Serverで「ネットワークとダイヤルアップ接続」のウインドウにアイコンが一つもないというもの。
問題のサーバはきちんとネットワークに接続され、クライアントに対するサービスの提供も出来ているし、他のマシンの共有ディレクトリを参照することも出来る。
それなのにネットワーク接続にアイコンが見当たらないという状態。
試しにコマンドプロンプトで
#ipconfig /all
を実行するとインターフェースに設定されているIPアドレス等がきちんと表示されるので、ネットワークは正しく動作している。

いろいろ調べてみるとWindows2000のサービスの一つである「Network Connection」が起動していないことが判った。
このサービスはネットワーク接続の管理をするためのものらしいので、これが動いていないとネットワークの設定が出来ない。
「コンピュータの管理」からそのサービスを起動しようとしてもエラー(エラー内容は失念orz、一定時間内に準備完了にならないとかなんとか)になり起動出来ないので、なんとか回復できないかを現在調査中。
気になるのはサービスを起動する際の実行ファイル
c:\WINNT\SYSTEM32\svchost.exe
の日付が別のWindows2000Serverのものと異なること(どちらもSP4適用済み)。
このファイルを入れ替えれば良いのかもしれないのだが、システム起動中には入れ替えられないファイルなので、HDDを取り出して入れ替えることを検討中。
その前に仮想化した環境でどうにかならないか試してみようかな?

←クリックしてくれると嬉しいです。

あと少しでお役御免だというのに・・・・・・・

職場のサーバの一台が昨日の夕方から不調になった。
ユーザーからサービスが不調だとの問い合わせがあり、調べてみると来月にはリプレースすることになっているサーバからの応答が遅いことが判明。
すぐに設置しているところに行って見るとコンソールにはHDDのエラーメッセージが沢山出ていた。
そのままでは非常に負荷が高くて操作出来ないのでなんとか再起動してみたが、必要なサービスが起動しない状態。
そこで非常用のディスクから起動してHDDの完全チェックを始めたが、これが非常に時間がかかるために深夜になってから一度帰宅し、今日の朝になってから確認するとやはり異常があることが判明。
幸いOSの部分ではなくて助かったのだが、必要なサービスのファイルが損傷を受けているらしくどうやってもサービスが起動しない。
起動時にはエラーが出ず、statusを問い合わせても動作中とは出るが、プロセスが存在しない状態。
やはり必要なファイルになんらかの損傷があると思われるのでソフトを再インストールしてみたが症状は改善しないので、そのサービスだけを他のサーバに任せることにして、別のサーバにソフトをインストールした。
別のサーバでのサービスはすぐに開始できたのだが、問題のサーバでユーザーにサービスを提供するためにはユーザー単位の設定を全て変更する必要があり、それに丸一日近くかかってしまった。
それでもなんとかサービスの提供を再会することは出来たものの、いつまで動作してくれるかのか不安だ。
せめてリプレースが終わるまで無事に動いていてくれないかなぁ?

←クリックしてくれると嬉しいです。

sambaサーバでのアクセス制限

ファイルサーバとして使っているLinuxサーバでアクセス制限を掛ける方法を調べている。
やりたいのは共有をかけているディレクトリ単位にIPアドレスで制限を掛けるということ。
具体的には
/var/share/AAA
というディレクトリには
192.168.1.0/24 からだけアクセスを許し、
/var/share/BBB
192.168.255.0/24 からだけアクセスを許すというようなこと。

これを実現するには設定ファイル(smb.conf)内にアクセスを許可するIPアドレス(グループ)を記述する必要がある。
サーバ全体へのアクセスを制限するには
[global]
セクションに
hosts allow = 192.168.1. 127.
と書けば192.168.1.0/24とローカルホスト(サーバ自分自身)からのアクセスのみを許可することになる。
同じことを各ディレクトリ単位にしたい場合はこの
hosts allow =
の行を各ディレクトリ毎のセクションに記述すればOK。
つまり、上のほうに書いたようなことを実現するには、
[AAA]
    path = /var/share/AAA
(中略)
    hosts allow = 192.168.1.
[BBB]
    path = /var/share/BBB
(中略)
    hosts allow = 192.168.255.
と書けば良いことになる。

反対に特定のIPアドレス(グループ)からのアクセスを拒否したい場合は「hosts allow」の代わりに「hosts deny」と書けば良いのかと思ってやって見たけど上手く拒否されずにアクセスが出来てしまった。
今のところ拒否のほうは上手くいかないけど、とりあえず目的を達することは出来るので、denyのほうはおいおい調べていこうか。

←クリックしてくれると嬉しいです。

NFSマウントしたファイルシステムをsambaでクライアントに公開するには?

現場にあるPCサーバ(Linux)にはクライアントPCで共有するファイルを置くためのディレクトリを用意して、そこをsambaで公開している。
数年前に設置した当初はそれほど容量を必要としない筈だったので、用意したパーティションの容量は10GB程度。
ところが運用が始まると画像データの置き場にされてしまい、あっと言う間に容量不足となってしまった。
なので現在はクライアントPCの一台をファイルサーバとして使っている状態。
本当はサーバにファイルを置きたいのだが物理的にHDDの容量が足りず、かといって現場が遠隔地なので気軽にHDDを増設しに行くことも出来ない。
そこで思いついたのは他の現場にあるHDD容量の多いサーバにNFSでつないで、その領域をsambaで開放するという手段。
早速調べてみるとsambaユーザー会辺りのMLで「速度が実用に耐えない」との投稿があったorz
そのMLではSANとSANサーバをNFSで接続して(ネットワークはGbit)、SANサーバがsambaで領域を公開しているが、クライアントからのファイルコピーで実測1kBps未満の速度しか出なかったとのことだ。
やり取りを読んでみると最終的にはなんとか使えそうな速度にはなった(マウントオプションに”nolock”を付ける)とのことが書かれていたが、安易に行うと痛い目を見ることになりそうだ。
それでもやりかたによってはなんとかなりそうな気がしてきたので、今度じっくり試してみようかと思う。

←クリックしてくれると嬉しいです。

自然のフィルターが出来ていた(笑)

現場のPCサーバの調子が悪いというので先ほど直しに行って来た。
まぁ調子が悪かったのは不測の電源断が原因でアプリの処理が中途半端なところで終わっていたためで、処理途中のファイルを捨てて回復させることが出来た。
で、折角来たのだからと埃等を取り始めたところ、空気の取り入れ口を中心に埃が絡み付いていて、まるでフィルターの様になっていた(笑)。
そのままだとある程度以上の大きさの粒子は通さないのだろうけど、エアフローが悪くなって最悪は冷却不足で内部パーツが破損する恐れがあったので取り除いてきた。
専用の設置スペースがあるわけでは無いので、ある程度は仕方が無いのだけど、それにしても周りを見ると毎日掃除をしているとは思えない汚れ方。
それもサーバ周りだけではなくてお客様からは見えない箇所は同じようにゴミが散乱している。
こんな現場に置かれるサーバが可哀相だけど、専用のラックやケースを置いてくれとも言える立場では無いので気休め程度に少しだけ周囲のゴミや埃を片付けてきた。
そんな環境でも動いているくらいだからPCサーバって頑丈なんだなぁ(笑)

←クリックしてくれると嬉しいです。

サーバが壊れた(涙)

今日行った現場で搬入したサーバの1台が起動しなくなっていた。
通電すらしない状況なので現場ではどうすることも出来ずお持ち帰りと言うことに・・・・・・・
職場に持って帰ってきて電源ユニットを取り替えてみると電源が入ったので、電源ユニットの故障だった。
ひとまず安心したので本格的に電源ユニットを取り付け、念のためにOS(Linux)を含めてチェックをすることにした。

電源を入れBIOSの設定画面を出すと案の定バックアップ電池が切れていたようで日付等が初期状態になっていた。
日付を初めとして設定を変えている項目の設定をし直して再起動。
無事にOSが起動してくる・・・・・と思いきや自動で走ったfsckがエラーを報告してきて、自動では復旧できないからメンテナンスモードに入って自分でfsckをかけろと言って来た。
仕方が無いのでrootパスワードを入力して手動でfsckをかけたらエラーがたっぷり・・・・・・・・
電源を切る際にどうやって切ったんだ?と思うほど。
仕方が無いのでファイルシステムを復旧しているが結構な量のエラーがあるなぁこりゃ。
しかもI/O errorまで出してくるので、HDDが本格的に駄目になる寸前かも?
数日間寒いところに置いてあったからかもしれないので、しばらくは電源を切らずに放置してみようかな?

←クリックしてくれると嬉しいです。

clockコマンド

linuxでシステム時刻とCPU時刻(BIOSの時刻)は別物であり、起動時はCPU時刻を基準としてシステム時刻がセットされる。
#linuxに限らずWindowsOSでも同様。
CPU時刻はPCの内蔵時計の時刻だが、この時計が思いのほか精度が悪い(笑)。
なので一度起動するとしばらく止めることの無いサーバの場合、気付くとかなり狂っていることがある。
linuxには時刻を自動で合わせてくれるntpという仕組みが用意されていて、ディストリビューションによってはデフォルトでインストールされる。
これはタイムサーバと呼ばれる時刻の基準となるサーバとシステム時刻を同期してくれる仕組み。
ただ、ntpで修正されるのはシステム時刻だけで、CPU時刻は修正されない。
そのままではシステム時刻とCPU時刻が大きく乖離してしまい、再起動になかなか時刻の同期がされないことにもなりかねない。
多くのシステムではシャットダウン時にCPU時刻をシステム時刻に合わせるように動作するが、これはシャットダウン時に呼び出されるスクリプト内で実行されている。
それでも不意の電源断等でシャットダウン処理がされない場合はCPU時刻とシステム時刻は同期しない。

任意のタイミングでCPU時刻をシステム時刻に合わせるためには”clock”コマンドを使うことになる。
このコマンドはオプションを何も付けないで実行すると現在のCPU時刻を表示してくれる。
システム時刻をCPU時刻に設定するにはスーパーユーザーで
#clock -w
と”-w”オプションを付けてclockコマンドを実行するだけ。
これでCPU時刻とシステム時刻が”ほぼ”一致する(コマンド実行のオーバヘッドがあるので完全に一致はしない)。
長期間動作させるサーバでは一日に一度程度このコマンドを実行するのが良いと思う(crontabに登録すれば簡単)。

←クリックしてくれると嬉しいです。

またまたntpでタイムサーバと同期できないサーバがあった

以前にもntpでタイムサーバと同期できないサーバが有り、なんとか同期を取れるように出来た。
今回久しぶりに触ることになったサーバも時刻同期が取られておらず、1時間近くも時計が狂っていた。
見るとntpデーモンは動作しているが、/usr/sbin/ntpdcで見るとタイムサーバ(ローカル)と同期が取れていない。
設定ファイル(/etc/ntp.conf)を見てもサーバの指定に特に間違いは無かったが、そのサーバ名が/etc/hostsに書かれておらず名前解決が出来ない状態だった(爆)。
「なーんだ、これが原因かぁ」
と思ってサーバ名とIPアドレスを書き加えてntpdを再起動したが相変わらず同期が取れない。
/usr/sbin/ntpdcで確認するとタイムサーバからの応答が来ないようで、”receive timestamp:”の部分がいつまで経ってもオール”0”のまま。
他のサーバからは問題無く指定したタイムサーバと同期が取れているので、タイムサーバ側の問題とも思えない。
不思議なことにntpdateコマンドでは同期できるので、123番ポートが塞がっているとか、パケットがフィルタリングされているとかでも無い。
/usr/sbin/ntpq -p タイムサーバ名
でもタイムサーバ側が親サーバと同期している状態が見える。
なので、プロトコルやネットワークの問題では無く、件のサーバのntpdの問題のように思われる。
ntp.confで指定するセキュリティがきついのかとも思ったが、/etc/ntp.conf内にはそもそも”restrict”で始まる行が無い(全ての接続を許可している状態)。
駄目元でntpのセキュリティ設定を他のサーバと同様に設定してみたがやはり同期できないorz
うーん、一体どうなっているんだろう?
とりあえず大きな狂いはntpdateで直したからもうしばらく悩んでみるかぁ(爆)

←クリックしてくれると嬉しいです。

またまたsendmailの設定を見直した

2008年11月18日の記事「sendmail」ではsendmailにDNSサーバを参照させない方法を書いた。
たまたま別のサーバのメンテをしていて、root宛のメールが大量に滞留していたので見てみると宛先のサーバ名が引けないで送信できずに残っているものだった。
しかもこのサーバではsendmailを始めとするMTAが動作しておらず、メールを出そうとしても送信queueに溜るだけだったorz

そこで送信先のサーバ名を/etc/hostsファイルに追加して(ローカル環境なのでhostsファイルに書けば十分)、MTAとなるsendmailにDNSサーバを参照させないように
hosts files
の一行だけを書いた
/etc/service.switch
ファイルを準備し、sendmail.cf内の
#O ServiceSwitchFile=/etc/service.switch
の行頭の”#”を削除(コメントアウトを外)して有効化し、sendmailを再起動した。
これで件のサーバが出力するメールは無事に目的のサーバに届くようになった筈だったが、最初は正しく設定したはずが何故かきちんと配送されずに「???」だった。
そこでsendmail.cfを見直すとservice.switchファイルの場所を間違って記述していた。
再度sendmail.cfを修正してsendmailを再起動したところ無事に届くようになった。

←クリックしてくれると嬉しいです。