職場でファイルサーバのファイルをメールに添付できなくなったと連絡が来た。
いろいろ訊いてみると
・問題のファイルをダブルクリックすると問題なく開ける。
・メールに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日以前に作成されたファイルが削除出来るはず。
←クリックしてくれると嬉しいです。
9時間のずれ
職場のサーバを仮想化した際に、一部のサーバのシステム時刻が9時間ほど進むようになってしまっていた。
9時間遅れるのであれば、ハードウェアクロックがUTCになっているにも関わらず設定上はlocaltimeになっていることが考えられるが、反対に9時間進んでいるのが不思議だ。
hwclock -r
でハードウェアクロックを確認してみると、システム時刻（正しく修正済み）に比べて9時間前の時刻を示していたので、ハードウェアクロックはUTCで設定されていた。
そこで
/etc/sysconfig/clock
というファイルの中を確認してみると、
UTC=false
となっていたので、これを
UTC=yes
にしておいた。
これで次回の起動時にどうなるかだな。
←クリックしてくれると嬉しいです。
うまくいった！ と思ったらorz
一昨日から悩んでいるRISOのプリンタ「ORPHIS X7250A」へのLinuxサーバ経由での印刷が上手くいった！
サーバ側のSAMBAの設定でsmb.confのprinterセクションにあるguest ok=noをyesにしたら一度は印刷データをPCからサーバに送ることが出来、そのデータが正しくプリンタまで送られて印刷できた。
と思って実際に使用する部署のPCでチャレンジしたところ全く症状が改善していなかった・・・・・・orz
しかもその後一度（ならず数度）は印刷できたPC（私が普段使っているPC）でも印刷が出来なくなってしまっていた・・・・・
症状は昨日までと同じで、サーバへのデータ送信が出来ない状態。
うーん、どうしたものか・・・・・・・・
←クリックしてくれると嬉しいです。
ちょっとだけ前進か？
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からサーバにデータを送ることが出来なければ印刷されるかどうかも解らないままだ。
この問題に間しては昨夕から一歩も進んでいないなぁ・・・・・・・
明日もまたこの問題で悩むことになりそうだけど、多少思いついたことがあるので、明日はそれらを試して見ることにしよう。
←クリックしてくれると嬉しいです。
ORPHIS X7250AにLinuxからの印刷が出来ない・・・・・・・
職場には大型のカラープリンタ「RISO ORPHIS X7250A」がある。
普段は高速のカラーコピー機として使われているが、本来はプリンタなので一部のPCからカラープリンタとして使いたいという希望があり、それらのPCにドライバをインストールした。
ネットワークはいくつかのサブネットに分割していて、その間ではファイルやプリンタの共有を許可していないので、同じサブネット内のPCからしか直接は接続できなくなっている。
なのでプリンタサーバとしているLinux機を経由して印刷しようとしているが、これがなかなか繋がらない。
最初はデータの転送に必要なポートが開いていないのかと思って設定を確認すると、サーバとプリンタの間は特に制限は無いことが判明したので、通信が出来ない訳では無さそう。
プリンタの仕様を見ると各種の印刷用プロトコル（lpr,http,IPP,RAW）に対応しているとなっているのでサーバ側の設定でlprとRAWを試してみた。
RAWに設定したときはサーバ側からはプリンタへのデータ送信が完了した（ように見える）が、プリンタ側のスプールにはデータは入っていなかった。
現在はここで手詰まり状態となっている。
引き続き調べて試せることは試してみよう・・・・・・・
←クリックしてくれると嬉しいです。
昨夜の処理は終わっていたけど（汗）
昨日書いたスクリプトは無事に動作して、今朝見ると更新されたファイルだけをアーカイブすることに成功していた。
なので、それらのファイルを転送して展開することで更新されたファイルを新しいサーバに移すことは出来た。
ところが、同じ処理を毎日実行させようとしてスクリプトをコピーして多少手直ししてcrontabに登録しておいたのだが、こちらが動作していなかったorz
原因は単純で、なんとスクリプトのファイルに実行権限が無かった・・・・・・・・
コマンドラインからそのまま実行しようとして始めて気付くという（爆）。
慌てて
chmod +x スクリプト名
で実行権限を与え、さらにスクリプト内で使用している各種のコマンドの記述をフルパスに修正した。
以前コマンドラインからは実行すると動作するのに、crontabに登録すると動作しないことがあり、その時はコマンドパスが通っていないことが原因だったので、今回も同じことが無いようにしたということ。
最近は滅多にスクリプトを書くことも無くなったので、僅か数行のスクリプトを書くだけで苦労してしまった・・・・・・
←クリックしてくれると嬉しいです。
スクリプトは書いたけど・・・・・・・・
データの移動の為に過去に転送した時以降に更新されたファイルをアーカイブするスクリプトを書いた。
きちんと動作することは確認できたのだけど、いざ実行するとかなり処理時間がかかってしまう、、、、、、、
これはfindコマンドが検索結果を毎回lhaに渡し、その度にlhaがアーカイブファイルのバックアップを取るためと思われる。
lhaに一括でファイル名を渡すことが出来ればバックアップを取らずに処理されるので、もっと処理速度を上げられる筈なのだがその手段が今のところ分からない。
なので、今日はこのままサーバに処理をさせたままにして引き上げることにした。
明日の朝には処理が終わっていることを期待しよう（汗）。
←クリックしてくれると嬉しいです。
正確には-fぢゃなかった（汗）
昨日からfindコマンドのオプションについて書いているけど、”-f”というオプションではなく、”-type”オプションに”f”というパラメータを渡すことで、ファイルのみの検索が可能になるということだった。
自分では-typeオプションを使っていながら、ここの記事に書くときに取り違えていたという・・・・・・・・
先の記事の使用例にもちゃんと”-type f”と書いているにも関わらずタイトルには”-f”オプションって書いている。
なにを勘違いして書いたかなぁ？
←クリックしてくれると嬉しいです。