仕事で使っているLinuxサーバーにブラウザでアクセスするとユーザー認証が通らなくなった。
調べてみるとDBが正しく動作していないのが原因と出て来たので、システムログを見ると随所に”No space left on device”のエラーが出ている。
慌てて
#df -k
で容量をチェックするとまだまだ（数GB）空き領域はあることになっている。
なので、動作していないプロセスを起動するスクリプトを走らせてみるも結果は同じ。
おかしいなぁ？と思いながらログを眺めていて閃いた。
”もしかしてi-nodeが足りないのか？”
ということで、今度は
#df -i
でチェックすると案の定i-nodeを使い切っていたorz
どこでそんなにi-nodeを使っているかと考えて、一番に思いついたのがキャッシュ。
apacheを使ってproxyとして動作させているので、/var/cacheの中のapache用のディレクトリをみるともの凄く沢山のディレクトリとファイルがあった。
直接消すのは怖いので、キャッシュ削除用になにかないかとググってみたら下のページがヒットした。
「Apacheのキャッシュを削除するhtcachecleanを使ってみる」
ここを参考に
#htcachecleanコマンドを使って消して・・・みたらもの凄く時間がかかりそうだったので、結局手動でいくつかのディレクトリを削除したところ、i-nodeが10万以上も開放されたのでサーバ自体を再起動、目的のシステムが動作していることを確認した。
その後、再発するとまた面倒なので、htcachecleanをデーモンモードで起動して様子を見ることにした。
いやぁ、i-nodeが足りなくなるなんて10年ぶりくらいかなぁ？（汗）
More from: apache
←クリックしてくれると嬉しいです。
apacheでシンボリックリンクが見えない場合の対処
仕事場のサーバーの一部が動かなくなったorz。
古い仮想化基盤のサーバーがHDDの不調のためかまともに動作しなくなってしまい、その上で動かしていた複数台のサーバーがどうにも動かなくなってしまった。
仕方が無いので新しい仮想化基盤に用意してあった同機能のサーバーに機能を移してサービスを再開したが、細かいトラブルがいくつか発生。
その中の一つにhttpdアクセスが出来ないというのがあった。
元々、ごく一部のユーザー向けにいくつかのディレクトリをブラウザで参照可能にするためにhttpdサーバー（apache）を動作させていたんだけど、ユーザーの指摘でそのことに気付くという体たらく（汗）。
最初に気付いたユーザー向けのサービスはhttd.confを弄ってDocmentRootを変更するだけで参照可能になったが、別のユーザーから指摘されたディレクトリにアクセスすると403エラー（Forbidden）で参照できない。
ファイルやディレクトリのパーミッションを見ても644（ディレクトリは755）で参照可能なはずなんだけど、何故か403になる。
問題のディレクトリはシンボリックリンクなので、リンク先のディレクトリも確認したがパーミッションの設定に問題は無い。
そこで調べてみると、apacheはデフォルトでシンボリックリンクの参照が可能なのは所有者ユーザーのみで他のユーザーがアクセスすると403になるらしい。
これを回避するにはhttpd.confで
Options Indexes SymLinksIfOwnerMatch
となっているのを
Options Indexes FollowSymLinks
に変更すると良いとのことだったので、問題のディレクトリのその部分を修正してhttpdをリスタートすると無事に参照可能になった。
ところが、問題はこれだけではなく、ディレクトリ名やファイル名に日本語（2byteコード）が使われており、そのままでは文字化けして読めない。
これは旧サーバーではEUCだったのが新サーバーではutf-8が標準のためデフォルトの設定ではヘッダーが、
Content-Type: text/html; charset=utf-8
となりブラウザ側はEUCの文字コードをutf-8として解釈しようとしたため。
これを直すにはhttpd.confの
IndexOptions charset=utf-8
を
IndexOptions charset=euc_JP
とすることで無事に日本語の文字が表示されるようになった。
←クリックしてくれると嬉しいです。
今時AGPとは（汗）
今日の作業で移設したサーバのディスプレイ出力が死んでいた。
駄目元で電源を入れて起ち上げたがやはり画面には何も表示されない。
しかもちゃんと起動していないためかいくら待ってもpingすら通らない。
画面に何も出ないので起動途中のどこで止まっているのかも不明。
たしかこのサーバのビデオカードってAGPだったような・・・
AGPのビデオカードなんて手元にあったかなぁ？何カ月か前に貰ったのが確かAGPだったけど大掃除で捨てちゃったしなぁ、、、
今時買おうとしてもショップの店頭なんかには無いだろうし・・・
と思っていたら部下が3枚ほど掘り出して来てくれてビックリ。
さて、これを組み込んだら動いてくれるかなぁ？
探してみたら今でも販売されているんだなぁ。
玄人志向 ビデオカード GeForce FX5500搭載 AGP 8x接続 GF-FX5500-A256HS
IGAGURI 7000-AGP ATI RADEON 7000 SDRAM 64MB AGPビデオカード
グラフィックカード★ATI 9550 DDR DVI グラフィックカード 256MB 並行輸入品
ATI RADEON 9550 AGPビデオカード IGAGURI 9550-AGP |
←クリックしてくれると嬉しいです。
apache起動時のエラー
3連休が明けて職場に出てきたら早速連絡があり、職場のWEBサーバの一台にアクセス出来ないとの事。
自分の使っているPCでもアクセス出来ないが、pingは通るしsshでの接続は可能なのでサーバそのものは動作している。
WEBサーバだけが駄目なのでこれはWEBサーバプロセスであるアパッチが正しく動作していないということが判明。
早速プロセスを再起動しようと
#/etc/rc.d/init.d/httpd start
としてみたが、
httpd を起動中: httpd: apr_sockaddr_info_get() failed for hoge.xxx.yyy（ホストのFQDN名）
httpd: Could not reliably determine the server’s fully qualified domain name, using 127.0.0.1 for serverName
とメッセージが出て起動できない。
このエラーを調べてみたら/etc/sysconfig/networkファイル内で記述している自分のホスト名がアパッチの設定ファイル（/etc/http/conf/httpd.conf）に記述されていないということなので、早速記述を追加（同時に/etc/hostsファイル内にも記述が無かったので127.0.0.1（localhost）の行に追加）した。
これで大丈夫だと思ってアパッチの起動を試したところ、今度はエラーメッセージ無しで起動に失敗。
/var/log/httpd/error_logを見ても特にエラーメッセージは無し。
「あれ？変だな？」
と思ってもう一つのエラーログである
/var/log/httpd/nss_error_log
を開くと、そこには
[error] Certificate not verified: ‘Server-Cert’
[error] SSL Library Error: -8181 Certificate has expired
[error] Unable to verify certificate ‘Server-Cert’. Add “NSSEnforceValidCerts off” to nss.conf so the server can start until the problem can be resolved.
と3行のエラーが残っていた。
これを解消するには/etc/httpd/conf.d/nss.confファイルに”NSSEnforceValidCerts off”を追加せよと書いてあるので、素直にそれに従って同ファイルの最初に追加したところアパッチが起動するようになった。
これでなんとか復旧できたのだが、連休前までは動作していたのに急にエラーになったのは何故なんだろう？
不思議だ・・・・・・・
←クリックしてくれると嬉しいです。