職場でファイルサーバのファイルをメールに添付できなくなったと連絡が来た。
いろいろ訊いてみると
・問題のファイルをダブルクリックすると問題なく開ける。
・メールにDrag&Dropで添付しようとしても添付ファイルのウインドウに入らない。
・そのまま送信しようとすると「添付ファイルが存在しない」というエラーになり送信が出来ない。
どうもエクスプローラーでは問題なく使えるが、一部のソフトではファイルを認識できなくなっているようだ。
電話でいろいろと話をしている内に先方が
「コンピュータの画面で容量とかを表示する青いバーがこのドライブだけ表示されていない」
「ドライブのプロパティを見るとディスク容量も使用領域も0バイトと出ている」
と言い出した。
これって切断されたネットワークドライブのプロパティと同じ表示だ・・・・・・・
その後現場に行って問題のPCを操作して、ネットワークドライブの切断／再接続を何度か実行しても同じ状況。
いろいろ調べている内にオフラインで使用可能になるように同期をしようとしてエラーになっていることが判明。
職場内はLANで接続しているのでオフラインでの使用を可能にする必要は無いわけで、そのような設定をした覚えは無い。
設定した覚えは無いが実際にオフライン同期が実行されているわけで、まずはオフラインでの使用を禁止する設定をした。
「同期センター」を開いてオフラインファイルを無効にしてPCを再起動したところ、問題のネットワークドライブ内のファイルをメールに添付できるようになった。
なぜオフラインでの使用が可能になったのかというと、今日の一時期ファイルサーバの負荷が上がり、問題を起こしたPCからファイルサーバの中を見るのに非常に時間がかかるようなったことがあったために、Windows7が勝手に問題となったドライブをオフラインで使用するようにしてしまったため。
本来は遅い回線を使っていたり、ネットワークへのアクセスが出来ない場合に使われる機能なんだけど、全く余計なことをしてくれたものだな。
時間を見てクライアントPC全てでオフラインファイルを使えないようにしてしまうか・・・・・・・
調べてみるとsambaサーバではsmb.confに
csc policy = disable
とするとOKらしい。
More from: linux
←クリックしてくれると嬉しいです。
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”を追加せよと書いてあるので、素直にそれに従って同ファイルの最初に追加したところアパッチが起動するようになった。
これでなんとか復旧できたのだが、連休前までは動作していたのに急にエラーになったのは何故なんだろう？
不思議だ・・・・・・・
←クリックしてくれると嬉しいです。
ディスクフルとは・・・・・（汗）
サーバの自動処理で作成しているファイルが一部しか出来ていないとの連絡が来た。
慌てて調べてみると処理途中のファイルを置いているディスクが満杯・・・・・・
幸い元ファイルは残っていたので、古いファイルを削除してディスクを空けてから再度作成処理を走らせて事なきを得た。
古いファイルは自動で削除するようにしてあったが、予想以上にファイルが大きくなっているので、ディスクを圧迫していたようだ。
なので保管期間を短くするようにスクリプトを書き換えた。
明日の朝チェックしてみて問題無いようだったら当面はそのままにしておこう。
今のスクリプト内では日付を取り込んでファイル名に付けているので、古いファイルを削除するにも該当の日付さえ取れれば良いことになる。
そこで下記のようにして2ヶ月前の日付を取り込むようにした。
file-name=`/bin/date –date ‘2months ago’ +%Y%m%d`
ここで”%Y%m%d”というフォーマットは
20120913
となるので（2012年9月13日の場合）、上記の場合”file-name”には”20120713″と2ヶ月前の日付の文字列が入ることになる。
スクリプトではこの後で
/bin/rm $file-name
のようにして2ヶ月前の日付のファイルを削除している（もちろんファイルの場所のpathの設定は必須だけどこの例では省略）。
ファイル名に日付を入れていない場合には、findコマンドで2ヶ月（60日）前に作られたファイルを探して削除するようにすればOKかな？
例えば
/bin/rm `find (PATH)/ -ctime +60 -type f -print`
のようにすれば60日以前に作成されたファイルが削除出来るはず。
←クリックしてくれると嬉しいです。
/dev/null が壊れた？
「サーバの一台でcronで実行している処理がおかしいので、調べてみると/dev/nullがおかしくなっている。」
との連絡が来た。
連絡をくれた当人は自分のアカウントでのログインですらエラーが出るとのこと。
調べてみると/dev/nullが通常のテキストファイルになってしまっていて、内容がエラーメッセージになっている（vimが無いとかなんとか）。
恐らくcronで実行している処理かなにかがエラー出力を/dev/nullに吐き出していて、その際に本来はキャラクタスペシャルファイルである/dev/nullをエラーメッセージで上書きしてしまったらしい。
とにかくこのままではいろんな処理が出来ないので、元に戻すことにした。
調べてみると戻し方は簡単で、
#rm /dev/null ; mknod -m 666 /dev/null c 1 3
で済んでしまった。
最初は
#mknod -m 666 /dev/null c 1 3
だけ実行したが案の定「既にファイルがある」と言われてしまったので、先にファイルを削除してから実行したところ新たにキャラクタスペシャルファイルが作成され、元通りになった。
後は上書きしてしまった処理を特定して修正せねば・・・・・
←クリックしてくれると嬉しいです。
1ページが60MB超って・・・・・・
職場のカラープリンタから印刷が出てこないとのSOSがあった。
問題のプリンタはネットワークに接続されていて、印刷用のサーバ経由で印刷するように設定してある。
このプリンタに時折データが送られなくなってしまって印刷が止まってしまう。
原因は大体がデータの容量が大き過ぎること。
プリンタが大きなデータを処理するのに時間がかかりすぎると印刷用サーバが次のデータを送らなくなってしまうようで、キューには溜っていてデーモンも動いているのだけど、実際にはプリンタ側にデータが送られていない状態になってしまう。
今回も1ページの印刷データが60MBを超えるものもあり、一番小さいデータでも30MB強。
こんなのを複数纏めて印刷要求されたらサーバも一個づつしかデータを送らなくなってしまうので、1つのデータが印刷完了するのを待ってサーバ側でデーモンの再起動を行うしか回復の手段が無い。
今回もプリンタの状態を監視しながらサーバ側の操作をしていたけど、なんとかならないものかなぁ？
つか、1ページ分の印刷データの容量が数十メガってどういうことだ？
←クリックしてくれると嬉しいです。
9時間のずれ
職場のサーバを仮想化した際に、一部のサーバのシステム時刻が9時間ほど進むようになってしまっていた。
9時間遅れるのであれば、ハードウェアクロックがUTCになっているにも関わらず設定上はlocaltimeになっていることが考えられるが、反対に9時間進んでいるのが不思議だ。
hwclock -r
でハードウェアクロックを確認してみると、システム時刻（正しく修正済み）に比べて9時間前の時刻を示していたので、ハードウェアクロックはUTCで設定されていた。
そこで
/etc/sysconfig/clock
というファイルの中を確認してみると、
UTC=false
となっていたので、これを
UTC=yes
にしておいた。
これで次回の起動時にどうなるかだな。
←クリックしてくれると嬉しいです。
繋がることには繋がったけど・・・・・・
先週から悩んでいたプリンタサーバへの接続は一応なんとかなった（と思う）。
net useコマンドでLPTポートにサーバのプリンタを接続する方法で一度はプリンタへのデータ送信は出来たものの、その後は何度試しても「ローカルダウンレベルドキュメントの送信に失敗」というエラーを解消することは出来なかった。
そこで違う方法で接続してみたところ、問題なくプリンタへデータを送信することが出来た。
接続方法は接続するポートに直接サーバのプリンタを指定するというもの。
具体的にはプリンタのプロパティ画面の「ポート」のタブで、「ポートの追加（T)」から「Local port」を選択し、「新しいポート（P)」を押し、ポート名として「\\サーバ名\プリンタ名」を設定した。
これで何故かサーバ経由でプリンタにデータを送ることが出来るようになった。
net useコマンドで接続するのと何が違うのかが判らないが、これで目的は果たせたので良いといえば良いのだが、なんかスッキリしないなぁ、、、、、、
←クリックしてくれると嬉しいです。
うまくいった！ と思ったらorz
一昨日から悩んでいるRISOのプリンタ「ORPHIS X7250A」へのLinuxサーバ経由での印刷が上手くいった！
サーバ側のSAMBAの設定でsmb.confのprinterセクションにあるguest ok=noをyesにしたら一度は印刷データをPCからサーバに送ることが出来、そのデータが正しくプリンタまで送られて印刷できた。
と思って実際に使用する部署のPCでチャレンジしたところ全く症状が改善していなかった・・・・・・orz
しかもその後一度（ならず数度）は印刷できたPC（私が普段使っているPC）でも印刷が出来なくなってしまっていた・・・・・
症状は昨日までと同じで、サーバへのデータ送信が出来ない状態。
うーん、どうしたものか・・・・・・・・
←クリックしてくれると嬉しいです。
ちょっとメモ
明日試すことをちょっとメモ。
・net useでのプリンタポートの割り当てをやめて、ポートとして直接サーバ上のプリンタを指定してみる。
・エラーメッセージをもっと細かく調べてみる（「ローカルダウンレベルドキュメント」とか出ていたような・・・・）。
後は・・・・・・・思い出せない（爆）。
←クリックしてくれると嬉しいです。
ちょっとだけ前進か？
RISOのカラープリンタ（「ORPHIS X7250A」）へLinux機からの印刷が出来なくて悩んでいる。
最初はlpdを使ったサーバから印刷させようとして/etc/printcapをいろいろ弄っていたが、どうやってもプリンタ側へのデータの送信が出来なかった。
「もしかしてlprに対応していないのか？」とも思ったが、仕様上は対応していることになっている。
それでも上手くいかないので次にcupsで運用しているサーバでRAWポート（9100番ポート）にデータを送ってみたが、データは送られたように見えるが印刷が出ない（これはプリンタ側に無いユーザーで送ったためと思われる）。
数時間の格闘の末lpdで運用しているサーバからのデータ送信に成功した（と思われる）。
/etc/printcapにはリモートホスト名とリモートホスト上のプリンタ名を記述するが、そのプリンタ名が違っていることが判明。
「ORPHIS X7250A」上のプリンタ名は単なる「lp」らしく、/etc/printcapのrpにlpを指定したところ、それまでスプールに溜まっていたデータが無くなった（プリンタに送られたと思われる）。
それまで「lpt1」やら「pr1」やらのプリンタ名を試していたけど、まさかこんな単純な名前だっとわ（汗）。
気付いたきっかけはWindowsXP上の「Standard TCP/IPポート」の詳細設定で、プロトコルをRAWからLPRに変えてLPR設定のキュー名を「lp」にしたら印刷が出来たこと。
このことで「ORPHIS X7250A」が持つプリンタ名は「lp」だろうと見当がついた。
これでサーバからプリンタへのデータ送信に関しては解決したと思われるが、サーバ上に定義したプリンタに対してクライアントであるWindowsPCから印刷データを送ることが出来ない・・・・・・
現在の接続方法はLPTポート（LPT1とかLPT2）に対してnet useコマンドでLinuxサーバ上のプリンタを接続していて、プリンタの使用するポートとしてLPT1等を指定している。
同じサーバ上の他のプリンタに対してはこの方法で問題無く印刷データを送ることが出来ている（印刷できている）。
ところがサーバ上に定義したRISOのカラープリンタ（「ORPHIS X7250A」）を接続したポートにはデータを送ることが出来ない。
テストページの印刷を試すと印刷開始から即座に
「このドキュメントの印刷に失敗しました。」
のメッセージが出てスプールに残ったままになってしまう。
サーバ上のスプールディレクトリのアクセス権とかもチェックしたが他のプリンタとの違いは無い。
PCからサーバにデータを送ることが出来なければ印刷されるかどうかも解らないままだ。
この問題に間しては昨夕から一歩も進んでいないなぁ・・・・・・・
明日もまたこの問題で悩むことになりそうだけど、多少思いついたことがあるので、明日はそれらを試して見ることにしよう。
←クリックしてくれると嬉しいです。