More from: 仕事

復旧したようだ

P , by

c No comment

先週ネットへの接続が不安定になった現場でのNTTの作業が終了し接続が回復した。
pingの反応を見ていても復旧後は取りこぼしが無いので安定して接続出来ている様だ。
今日は朝からネットが重くて使えないとクレームが入っていたが、これでなんとか安定して使って貰えそうで助かった。
後はNTTから原因と対策の報告をして貰って上に報告せねば（汗）。

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

予定が早まりそうだ

P , by

c No comment

先週末に現場の回線が不安定になった件でNTTの対応が早まりそう。
当初予定では工事の件で連絡が来るのが明日3/23の予定だったが、日曜日になって今日3/22の午後に工事に来れるとの連絡が入ったとの連絡が今朝になって入った（ちょっとややこしい）。
LTEモデムで接続は維持しているものの、現場からは「重くて使えない」との苦情も入っているので、工事予定が早まるのは大助かりだよ。

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

なんとかなった・・・

P , by

c No comment

NTTの回線の不具合で通信が安定しなくなった現場の問題はなんとかなった。
今日になって4G端末をルーターに接続して回線に接続することが出来るようにして貰えた。
さすがに光回線に比べると速度は遅い（pingへの応答時間が10倍以上orz）ものの今のところ安定した接続が実現できている。
この連休を乗り切ってしまえばNTTに対応して貰える・・・と思ったら、NTTから修理に関する”連絡”が来るのが翌々営業日である3/23（水）になるとのことorz。
一体いつになったら回線が復旧するんだろう？？？

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

今更3G・・・

P , by

c No comment

とある現場でネットへの接続が頻繁に切れるようになった。
完全に切れるわけでは無く60-90秒ほどでルーターが再接続しにいくのでその間を我慢すれば使えないことは無いが、非常に使い難く業務に支障が出ている。
業者さんにお願いしてルーターを交換して貰ったが、その際にVDSLモデムの状態を見て貰ったら上位回線へのリンクが切れていることが判明。
なので問題は回線提供業者（NTT）の回線にあることが確定。
そこでNTTに対して故障対応を依頼したところ、先日の地震の影響で対応可能日時が全く不明で、依頼から数時間経っても予定の連絡が来ないorz
しかも悪いことに週末どころか三連休前の金曜日なので、その日中に来てもらえないと休み明けになってしまうし、実際に金曜日には来てくれなかったので最速でも3/22以降になってしまうことが確定。
現場の営業はこの週末が勝負でなんとか復旧させなくてはならないので業者さんと頭を絞って代替回線としてモバイル回線を利用することに。
ところが私の手元にある端末でルーターに接続できるUSB端子を持ったものは旧イーモバイル時代の”D41HW”と”GD03W”くらいで、両方とも4GLTEには非対応（汗）。
一応”GD03W”は発売時期から考えてSIMフリーのようなんだけど、実際にイーモバイル以外のSIMを挿したことが無いので他社回線で使えるかは未検証。
しかも3G回線でも対応している周波数は1.7GHz帯と2.1GHz帯だけらしいのでdocomoで使えるのは2.1GHz帯（バンド１）のみ。
現場は市内でFOMAのエリアに入っていて電波を掴まえることは出来ると思うけど、業務で使えるかはまた別の問題。
というか、今更3Gのみの端末を使うというのもなぁ・・・
と思っていたら業者さんの方でLTE対応の端末の手配が出来たということなので、そちらをルーターで使えるようにして貰って回線に接続して貰おう（汗）。

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

今度はITBユニットかぁ・・・

P , by

c No comment

先だってCanonのモノクロレーザープリンター「LBP-441e」で印刷時に付く汚れを定着ユニットを交換して解消した。
今度は同じ現場にあるカラーレーザープリンター「LBP-9100C」も同様に印刷時に汚れが付くというorz。
以前にも似たような機種の「LBP-841c」で同様のトラブルがあり、ドラム一体型のトナーを交換しても改善せず、ITBユニットを外してみたところ端にトナーが付着していて拭き取ってもすぐに付いてしまうのでユニットの経年劣化ということでプリンタ自体を買い替えたことがある。
今度も同じトラブルかと思ったがITBユニットの表面にトナーの付着は見られなかった代わりにユニットのフィルム表面の全体に細かい傷が入っていた。
こちらも印刷枚数から考えるとITBユニットの寿命を超えていて交換が必要だが、結構高い（メーカーサイトに依ると税別で49,920円）ので決済が降り難い（汗）。
調べて見ると先の2つの機種は同じITBユニット（ITB UNIT UM-722I）で、ネット上に分解するための情報もあるようだ。
そこで廃棄待ちの「LBP-841c」のITBユニットをメンテナンスして流用出来ないか試してみるつもり。
これが上手くいけばプリンタが２台（最低でも１台）復活させることが出来そうだ。
←クリックしてくれると嬉しいです。

LBP-441eの定着ユニットを交換

P , by

c No comment

現場のモノクロレーザープリンタ「LBP-441e」で紙の端の方が汚れるという現象があり、実際に印刷した紙を見ると確かに端の方に幅2-3mmの汚れが付いている。
最初はトナー（内部のドラム）の不良を疑って新品（のリサイクルトナー）と交換しても改善しなかった・・・どころか外したトナーを別の同型機に装着すると綺麗に印刷される。
ということは原因はトナーでは無くプリンタ本体、恐らくは定着ユニットのシートに付着した汚れと思われたので外してみたところ、汚れる部分にしっかりとトナー滓がこびり付いていて擦っても全然取れない。
仕方が無いので交換を試すことにしたが、生憎と同じ機種の予備が無く定着ユニットも無い。
そこで一つ前の機種であるLBP-8710eの定着ユニットが使え無いか調べて見ると思った通り同じ部品が使えるらしいことが判明。
駄目元で廃棄予定のLBP-8710eの定着ユニットを外して見ると異常は無さそうだったので問題のLBP-441eに組み込んでみると問題無く動作し、印刷の汚れも無くなった。
こうして今回は問題を解決することが出来たが、メーカーが定着ユニットの寿命としている15万枚の1.5倍の枚数を印刷していたプリンタなので買い替えて貰った方が良さそうだなぁ（汗）。
中古の定着ユニットを探すと見つかったけど、今日（2022/03/03）現在は品切れとなっていた。
←クリックしてくれると嬉しいです。

サーバーが壊れた？

P , by

c No comment

遠隔地の現場からlinuxサーバーに上がる筈のファイルが上がってこないとの連絡が来た。
ファイルをアップロードする機器側を見るとファイルの転送に失敗している。
クライアントPCでそのフォルダにファイルやフォルダを作ろうとすると権限がないと言われて作れなくなっている。
一昨日までは出来ていたとのことなのでサーバーにトラブルが発生している模様。
もしかしたらディスクが溢れたのかと思ってdfコマンドで確認するもまだ余裕があるので、容量の問題では無さそう。
それならi-node数絡みかとも思ったが、それほど多くのファイルがあるというわけでも無かった。
調べている内に問題のフォルダのあるパーティションが読み込み専用でマウントされている。
何故そうなったのかの原因を探るより使えるようにするのが先決なので、読み書き可能にするためにremountしようとしたが、どうやっても読み込み専用でしかmounto出来ないorz。
一度リブートしてmountコマンドで見ると(rw)となっているんだけど、/proc/mountsの内容は(ro)となっている。
仕方が無いのでumountしてfsckを走らせようとしたがファイルシステムが使用中ということでumountも出来ない。
それならば/etc/fstabを書き換えてブート時に自動でマウントしないようにしてリブートし、fsckを走らせてからfstabを元に戻して手動でmountしようとしたらコマンド入力に対する応答が来なくなってしまったorz。
pingには応答するものの、sshに対する応答が無くなったのでサーバーが止まってしまったらしいorz。
とにかくファイルをアップロードできるようにするのが最優先なので、現場からアクセスできる他のサーバーに場所を作って機器側に設定を追加してファイルをアップロードできるようにして取り敢えずは復旧した形にはなった（汗）。
サーバー本体はじっくりと調べないとなぁ・・・
＃それとも古いサーバーだからデータだけサルベージして他のサーバーに持って行こうかな？

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

思わぬところで連休になってしまった

P , by

c No comment

仕事場から明日から二日間の自宅待機を指示されてしまった。
別件で今日も休みを取ったので昨日の日曜から明後日の水曜日まで4連休となってしまった（汗）。
事実上は休みなんだけど、明日と明後日は極力自宅にいなければいけないので、どこかに遊びに行くなんてできないなぁ（汗）。

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

原因判明

P , by

c No comment

昨日の記事に書いたpostfixでの配送が完了せず/var/spool/mailの下に配信されてしまった原因が判明した。
あらためてログを見直すとpop3の箇所に
”failed: No space left on device”
の文字列がorz。
つまり配信先ユーザーのhomeディレクトリに空きが無くて配信できずに止まってしまったわけだ。
その後に別の作業の結果ディスクに空きが出来たのでそれ以降のメールは問題無く配信されていたということらしい。
恒常的にメールの配信が漏れるわけでは無いということが判明したのは良かったが、ディスクスペースが足りないのはどうやって回避しようかな？（汗）

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

メールの配送漏れ？

P , by

c No comment

ユーザーから昨日届くはずのメールが届いていないとの連絡があった。
なんでも特定の時間帯のメールが少なくて、ちょうどその時間帯に送られたメールがあるけどPCで受信できないとのこと。
”そんな筈は・・・”と思ってサーバーのログを見ると届いていない筈のメール（送信元のアドレス等で判断）は配信されたことになっている。
/var/spool/mail下にあるスプールを見てもちゃんと入っている（後で気付いたがこの時点で勘違いしていた）。
そこで自分のPCで同じアカウントを設定して受信させてみると受信できない（ユーザー側は一定期間サーバーに残す設定にしてあるので私のところでも受信できる筈）。
スプールにあるのに受信できない原因を探している途中で気付いたが、このサーバーはpostfixでmaildir形式で構築してあり、先のスプールファイルには配信されずユーザー毎のディレクトリ(~/Maildir下）に配信される筈だった（汗）。
とにかく受信できないメールをなんとか受信出来るようにするのが先決なので色々調べてformailコマンドで配信することにして実行したところ、今度は
: mail forwarding loop for hoge@hogehoge.dom
というエラーメールがrootに送られてくるだけで配送されない。
ループになるような原因としてはaliases以外に考えられなかったので/etc/alisesファイルを何度も修正し、最後には転送設定を削除までしたが結果は変化しないorz。
となると転送設定の問題では無いだろうということでエラーメッセージでググるとヒントが見つかった。
それは送られてきたメールヘッダーの
Delivered-To:
に受信者と同じメールアドレスの記述があるとMTA（postfix）がメールループだと判断してしまうということらしい。
なぜDelivered-To:に同じアドレスが入っているかを調べる時間が勿体ないので、とにかくスプールファイルを直接（もちろんバックアップを取ったうえで）編集し、Delivered-To:に書かれているアドレスを若干変更して保存。
そうした後にformailコマンド
# formail -s sendmail -v -t -oiee < ./hoge を実行したところ無事にmboxに配信された。 あとは特定の時間帯にだけこの現象が起きた原因を探らなければ（汗）。

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