職場のサーバの時刻が狂っていたので、タイムサーバーに同期させたところ、分と秒は合ったが時がおかしくなってしまった。
あれぇ？と思ってよく見ると、時刻表示の最後の部分が”JST”ではなく”CST”になっている。
このサーバを構築したのは自分では無いのでインストール時にどのような設定を行ったかは知らないが、タイムゾーンが日本では無く、合衆国中部標準時になっている。
これを日本標準時にするのに下記の手順を実行した（全てスーパーユーザーにて実行）。
#cd /usr/share/zoneinfo/Asia
#cp Tokyo /etc/.
#cd /etc
#mv localtime localtime.org（念のためバックアップを取った）
#cp(or mv) Tokyo localtime
要はタイムゾーン情報を合衆国中部標準時用のファイルから日本標準時用のファイルに入れ替えたということ。
なにも実体のファイルを入れ替えなくても、次のようにしてシンボリックリンクを張っても良いと思う。
#ln -s /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
というか、こっちのほうがスマートかも。
More from: linux
←クリックしてくれると嬉しいです。
「時計が進まなくなるサーバ」のその後
昨年12/13に書いた記事「時計が進まなくなるサーバ」で取り上げたThinkCentreを転用したサーバーだが、起動オプションに”noapic acpi=off”を付けて再起動してから三週間が経過しても問題無く動作を続けている。
やはりカーネル内部でのハードウェアタイマ割り込みの処理がうまく行っていなかったようだ。
実は年末前にチェックした時も問題無かったので、そのまま年末年始の休みに入ったというわけ。
年が明けても問題が無いようなので、これでこの問題で手を煩わされることも無いかな？
←クリックしてくれると嬉しいです。
先日止まっていたDNSサーバ
先週末の土曜日にサービスが止まっていたDNSサーバに駄目元でリクエストを出したらきちんと名前解決が出来た。
ということは、12/11はなんらかの理由で一時的にサービスが止まっていたということか？
ま、なんにせよ復活してくれて良かった良かった。
だけど、また止まったら困るので、参照順位は最後にしてあるけどね。
←クリックしてくれると嬉しいです。
時計が進まなくなるサーバ
以前から時々時計が止まってしまい、それにともなっていろんなサービスが止まってしまうサーバがあるが、ここ三日間で三度のリブートをする羽目になった。
流石にこのままでは年末年始の休み期間中が不安なので、再度調べてみた。
稼動させているハードウェアがIBMのThinkCentreだということを思い出し、それでググってみた。
というのも過去にThinkPadにLinuxを入れたところ多少のトラブルがあったことを思い出したから。
そうしたところ、数は少ないながらも似たような事象が報告されているのを発見。
複数のサイトで見つけた対処法はapicの無効化というもの。
なので、/boot/grub/grub.conf内の
kernel /vmlinuz/xxxxxxxxxxxxxxxxxxxx の行の最後に”noapic acpi=off”の記述を追加してみた。
リブートしないと結果は判らないが、流石にサービスに支障がない状態で停めるわけにもいかず、明日の早朝に再起動し、その後経過を見ることにした。
これで解決してくれると助かるけどなぁ・・・・・・・・・・
←クリックしてくれると嬉しいです。
CENT OSのインストールCD
RED HAT系のフリーのOSであるCENT OSは現在5.5が最新らしいけど、インストール用のイメージファイルを見てびっくり。
なんとCD-ROMだと7枚にもなるのね、、、、、、
DVDのイメージだとファイル容量が約3.9GBなので、こっちだと一枚で済むけど、最近購入したサーバだとDVDからのインストールで躓くことが多いので、CD-ROMのインストールメディアを作ることにした。
それにしても7枚かぁ、、、、、、、、、、焼くのが面倒だなぁ（爆）
←クリックしてくれると嬉しいです。
タイムサーバに同期できないサーバがまだあった・・・・・
10/19付けの記事「NTPで時刻同期が出来ないサーバ」で書いたようなサーバがまだあった。
ファイルサーバにしているサーバの時刻が狂っていて、保存したファイルの更新時刻が未来の時刻になっていることに気付き、調べてみると前回と同様にタイムサーバに同期できない状態だった。
原因は前回と同じで自分自身のみしかアクセス出来ないようにしていたので、対処方法も前回と同じにしたところ、無事に同期動作が始まった。
うーん、普段問題なく動いていると監視が疎かになるなぁ、、、、、、
←クリックしてくれると嬉しいです。
delegatedがようやく動いた・・・・・・・
先月半ばに原因不明でハングアップしたサーバを無理やり再起動したが、それ以来delegatedが起動しなくなっていた。
とりあえず動かなくても支障は無かったのだが、今朝になって「○○にftpが繋がらないんだけど」と言われて調べてみると、delegated経由でftp接続していたことが判明した。
それで再度delegatedを動くようにしようとしたが、MD5値が違うというよくあるエラーで起動しない。
これは再コンパイルで解決することが多いのだが、実は前回もこのエラーで起動できずに再コンパイルは実施済み。
それでも起動に失敗するので、ダウンロードしてあった最新版のソースからmakeして実行モジュールを作り直した。
ところがこれでも起動できないので、「もしかして起動方法が間違っているのではなかろうか？」と思い、起動手順を見直してみた。
すると、設定ファイルで指定していると思ったポート番号が実際には設定されておらず、そのため「NO ACTIVE PORT」のエラーも出ていた（爆）。
しかも設定を外部ファイルに記述した場合に引数で渡す方法を間違っていたことが判明（汗）。
起動用スクリプトは環境変数の設定等を行うだけで、あとは渡された引数をそのままdelegatedに渡すだけ（$*）だったので、起動時の引数の渡し方を変えたらすんなりと起動してくれた。
要は今まで
delegated.sh（起動用スクリプト名) 設定ファイル名
としていたところを
delegated.sh -Pポート番号 +=設定ファイル名
としただけ。
この設定ファイル名の渡し方が間違っていたために起動してくれなかった訳だ（ポート番号も指定していない）。
久しぶりに触ると忘れてるなぁー、というわけで備忘録代わりにここに書いておこう。
←クリックしてくれると嬉しいです。
sambaで繋がらなかったのは（汗）
先日ここに書いたサブネットをまたいで繋がらなかったsambaサーバーはなんとか繋がった。
いろいろと調べてマスタブラウザの設定やら、WINSサーバがどうたらとかの情報が出てきたが、結局のところそんな面倒なことでは無かった。
いろいろ調べた情報を見ながら/etc/samba/smb.confの内容を見ていたら、global sectionにある「hosts allow」で、自分が所属するサブネットと127.0.0.0（自分自身）のアドレスしか書いてなかった。
これは自分が所属するサブネットのクライアントと自分自身からのアクセスしか許可しないということなので、ここに繋げたいクライアントのサブネットを記述することで無事に接続できるようになった。
具体的には
hosts allow = 192.168.1. 127.
となっていたので、これを
hosts allow = 192.168.1. 192.168.2. 127.
のように「192.168.2.」の部分を書き加えたというわけ。
こんな単純なことで週末悩んでいたのはちと恥ずかしいかも（汗）
←クリックしてくれると嬉しいです。
ルーター越しでsmbサーバに接続できない・・・・・・
職場内のネットワークを分割することになり（っていうか、既に分割してあるが）、間のルーター越しにファイルの共有を行う必要が出てきた。
Windows系OS同士は既に接続できることは確認しており、実際に接続して使っている。
ところが、Linuxで構築したファイルサーバには接続が出来ない。
お互いにpingは通るし、Windows同士では接続できるので、ルータはWindows共有用のパケットを通していることになる。
まだ調べ始めたばかりなのでよく判っていないが、その内なんとかなるだろう（爆）。
←クリックしてくれると嬉しいです。
delegatedが起動しなくて悩んだ
職場のサーバの一台が非常に重くてクライアントから接続できないとの連絡があり、試しに自席のPCからログインしようとしたところ、タイムアウトでログインできない。
仕方が無いので現場に行ってみるとディスプレイに一瞬だけログイン画面が表示されたが、すぐにブラックアウトしてしまい状態の確認が出来ない。
かといって放っておく訳にも行かないので、電源SWを押して自動でシャットダウンをさせたが電源が落ちない。
最後の手段で電源SWを長押しして電源を切り、すぐに電源を入れなおしたところ無事に起動したが、やはりログイン画面が一瞬で消えてしまう（ディスプレイには信号が行っている）。
とにかく起動自体は出来たので、近くのPCからログインしてみると問題なく入れた。
これでひとまずは安心と思っていたが、午後になってそのサーバ経由での印刷が出来ないとの連絡が入ってきた。
サブネット間のルーターの役目もしているサーバなので、パケットの中継がうまくいっていないのが原因と思い、試しに他のサーバから反対側のサブネットの特定のホストにpingを打ったが返事が無い。
ということで中継に使っていたdelegatedが起動しているかをチェックしたところ全く起動していなかった。
以前このサーバを扱ったのはかなり前だったので、記憶を頼りにdelegated用の起動ファイルを探し、そのファイルを使って起動してみたが、
NG, this executable is not signed
のメッセージが出て起動しない。
これは以前から良く出ていた現象で、makeし直して実行ファイルを/usr/sbinの下にコピーすればとりあえず動くことを覚えていたので、早速その通りにしたがやっぱり動かない（あれ？）。
いろいろ調べて
/usr/sbin/delegated -Fesign -w
を実行してサインをし直したところ、上記のエラーは出なくなったが、今度は
ERROR: NO ACTIVE PORT
とのエラーでやはり起動しない。
うーーーーん、、、、、、、、、困った・・・・・・・・
で、気付いたのは
「要はパケットフォワーディングが出来ればいいんじゃないか！」
ということ。
で、
/proc/sys/net/ipv4/ip_forward
の中身をチェックすると”1”となっていたので、パケットフォワーディングは有効になっていた。
さらに
/etc/sysctl.conf
の中にも
net.ipv4.ip_forward = 1
と記述されている。
だとすると反対側のサブネットまでパケットは到達しているはず。
あれぇ？おかしいなぁ？と思い、それまで試さなかったホストへpingを打つとしっかり返事が来たorz
なんと複数のIPアドレスに向けてpingを打っていたが、全て動いていないホストだったらしい、、、、、、、
不調の連絡をくれた部署に連絡すると、すでに印刷は出来るようになっているということだった（設定を多少変更したとのこと）。
存在しない問題に1時間以上も時間を費やしてしまった、、、、、、
←クリックしてくれると嬉しいです。