More from: エラー

サーバ間のメール転送が上手くいかない・・・

メールサーバの移行に伴い、新旧サーバ間でのメールの転送が必要になった。
具体的には新サーバの特定ユーザー宛のメールを旧サーバに転送することになる。
そこで該当ユーザーの”.forward”ファイルに転送先の旧サーバのアドレスを書いたのだけど、
「sendmail deferred connection refused by XXX」(XXXは送信先、要は旧サーバ名)
のエラーとなり送信出来ない。
それもその筈、旧サーバは当初外部からのsmtp接続を受け付ける必要が無かったので、”sendmail.cf”の
「O DaemonPortOptions=Port=smtp,Addr=127.0.0.1, Name=MTA」
という項目がデフォルトのままだったために、外部からのsmtp接続を拒否していた。
ここにもう一行
「O DaemonPortOptions=Port=smtp,Addr=aaa.bbb.ccc.ddd, Name=MTA」(aaa.bbb.ccc.dddは自サーバの実際のIPアドレス)
という行を追加し、sendmailを再起動することで回避出来た。
ところがその後も新サーバ側からメールを送ると、
”553 5.3.5 system config error”
とか
”553 5.3.5 xxx.yyy.zzz. config error: mail loops back to me (MX problem?)”
というエラーが出てやはり送信出来ない(汗)。
これらのエラーは”/etc/mail/local-host-names”ファイルに関係する全てのサーバ名(ホスト名、ホスト名+ドメイン名)を追加で記述しsendmailを再起動することで解消出来た。
また
”Relaying denied”
も出ていたので、これは”/etc/mail/access”ファイルにリレーを受け付けるホスト(要は新サーバ)のIPアドレス+”RELAY”を記述し、makeし直すことで解決した。

上記の設定変更でようやく新サーバから旧サーバへのメールの転送が可能になったので、ようやく落ち着いたよ(汗)。

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

telnetで接続できなくなった(汗)

職場のメール受信用サーバが最近調子が悪いので新たに構築したサーバに移行中。
ところが移行作業二日目の朝になるとPCからtelnetでサーバに接続しようとすると、
「getaddrinfo: localhost Name or service not known Connection closed by foreign host.」
というエラーメッセージが出て接続できなくなってしまった。
早速このエラーメッセージでググって見ると、どうも/etc/hostsファイルの記述(だけでは無いらしいが)に問題があるようだ。
そこを修正すればOKらしいんだけど、作業をするにはコンソールからログインしなければならない。
サーバを設置してある部屋に行って/etc/hostsファイルを見ると、/etc/sysconfig/networkファイルに書いてあるホスト名と異なっていた(汗)。
さっそく/etc/hostsファイル内のホスト名を書き直すとtelnetでの接続が復活した。
うーん、前日の作業で修正を間違っていたのかなぁ???

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

久々にRidocでトラブル

遠隔地の現場からRidoc DESK NavigatorLt.を起動しようとすると
「ridoc 設定情報のバージョンが正しくありません(100-75) シリアライズデータのロードに失敗しました(1-2083) 」
のメッセージが表示され、「OK」のボタンを押すと
「アプリケーションの初期化に失敗しました」
となって起動できない、しかも2台のPCで。
という連絡が来た。
聞いたことのあるエラーメッセージなのでググってみたら、2年前にもどこかの現場で発生していて、その時のことを自分でこのブログに書いていた(汗)。
その時の記事→「Ridocの設定情報が壊れた?」
これを読むとこの時は修復インストールで直ったとなっているので、同様に修復インストールを試みて貰ったが解決しないという(アンインストールしてからの再インストールでも同じとのこと)。
ということは原因と対策が以前とは異なるということになりそうなので、メーカーのほうに問い合わせてみたが、なにせ開発もサポートも終了しているソフトなので対応が期待出来ない。
ところがメーカーからの回答が来る前に現場から連絡が入り、結果的に直ったとのこと。
詳しく訊くと、アンインストール時に常駐しているアプリがあってきちんとアンインストール出来ていなかったので、常駐しているアプリの実行を止めて再度アンインストールとインストールを実行したらきちんと起動するようになったとのこと。
突然エラーが発生するようになった原因ははっきりしないけど、なんとか回復して良かったよ(汗)。

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

「メモリまたはディスクの容量が不足しているため~」???

Windows8.1(64bit版)+オフィス21032013の組み合わせのPCでエクセルのファイルを開こうとすると、
「メモリまたはディスクの容量が不足しているためファイルを開く事が出来ません」
とかいうエラーメッセージが出て開けないとの連絡が来た。
あれ?どこかで聞いたことのあるエラーだなぁ?と思いよくよく話を訊くと、開けないのは某大手通信キャリアのサイトからダウンロードしたファイルで、通常のファイルは問題無く開けるとのこと。
ここまで聞いて思い出したのは、Windows8(以降)では外部からダウンロードしたファイルにはブロックフラグが付いてしまい、そのままではオフィスアプリからは開けなくなってしまうということ。
これを解決するにはファイルを右クリックしてプロパティを表示し、”ブロックの解除(K)”というボタンを押して解除してやれば良い。
ネットの情報の中には”セキュリティレベルを下げる”なんて解決策があるが、こんなのは本末転倒なので決してそんなことはしないように(笑)。

というか、セキュリティ上の問題なのに表示されるメッセージがメモリ云々というのはどう考えても解せない。
これってエラーメッセージを表示する部分のバグだと思うんだけど、一向に解消されないなぁ(汗)。

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

エラー”E020”?

職場のカラープリンタ(CANONのLBP-9100C)のエラーランプが点灯したと連絡が来た。
この機種は本体に表示パネルが無くランプだけなので、リモートで入ってみると”E020”のエラーが発生していた。
調べてみるとこのエラーは4色のトナーの位置合わせがうまくいかない場合(要は色ずれを起こす)に出るようで、メーカーサイトでは対処法として一度電源を切ってからしばらく放置しその後再度電源を投入するように、それでも発生するならサービスマンを呼ぶようにとなっていた。
そこで現場に行って電源を切ってから再投入するとエラーが解消して印刷が可能になったが、普段から頻発しているらしいのであまりにひどい場合は修理が必要ということを伝えた。
同じ”E020”でも「LBP-5900/5910」等ではドラム手前のセンサー部分を清掃することで解消する場合もあるようで、メーカーサイトには清掃手順が載っていた。
「LBP-9100C」でも同じように清掃出来れば良いのになぁ。

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

あれ?転送出来ない???

ユーザーから「FAXが受信したFAXデータがファイルサーバーに入っていない。」という連絡が来た。
使っているのはRICOHの「RIFAX EL-6000」というFAX専用機で、受信したFAXをtiff形式にしてファイルサーバーの特定ディレクトリにftpで転送するようにしてある。
この転送がどうもうまくいっていないようで、ファイルサーバーの中にはここ数日で受信しているデータが全く入っていない。
最初は転送設定が狂ってしまったかと思い見てみたが特に問題は無い。
このFAX機はスキャナとしても使えるので、スキャンデータ保存用の宛先も設定してあって、そちらにはちゃんと転送出来ているのでサーバー自体がftp接続を拒否しているわけでもない。
転送されないのはFAX受信データだけなので、試しに受信データ用の宛先にスキャンデータを転送してみたところ、下の写真のエラー(ED0601)が出てデータの送信が出来なかった。

EL-6000のエラー表示

EL-6000のエラー表示


つまり問題は受信データ用の宛先にあることが判明。
そこでサーバー内の受信データ用ディレクトリの中を見ると過去に受信して転送されたファイルが6000個余りあったので、ファイル数が多すぎて駄目なのかと思い試しに自サーバーからlocalhostにftp接続して適当なファイルを送信してみると問題無く送信された。
ということはファイル数が多すぎて駄目と言うわけでも無さそう・・・
うーん、なんだろう?としばらく悩んだ後で駄目元でディレクトリ内のファイルを整理して数を減らしてみたところあっさりと解決した。
FAX機の内部でどんな処理をしているのか判らないけど、smb転送の場合と同じくftp転送の場合もファイル数が多すぎると駄目らしい・・・
なのでユーザーには原因を説明してあまりファイルを溜めないようにお願いしておいた。

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

洗濯機のエラー

先ほど妻が洗濯をしていたのだが、何故か洗濯機の前でしゃがんでなにかをしている。
訊くと洗濯機がエラーを表示して止まってしまい、「フィルターの清掃をするよう」指示が出ていたので先ずは洗濯機内の水を抜いているとのこと。
どうも排水部分のフィルターに異物が詰まったらしく、フィルター部分から洗面器に出した実際に排水の中には細かい砂が少々混じっているのが見える。
この砂は恐らくRSRに着ていった服等から出たものと思われるが、量は少ないのでこの砂がエラーの原因とは思えない。
何度か洗面器に溜まった水を捨てながら内部に溜まっていた水を抜いていて、最後に残った水が全部出たところでフィルターを外すとそこにはある物が・・・
なんとRSRの時に服に貼っていた直径3cmほどの虫除け用のシールの一枚が出て来た(汗)。
このシールがエラーの原因であったことは間違い無さそう。

RSRから帰宅して着ていたものを洗濯した時に私の着ていたシャツの裏側に貼っていた一枚が行方不明になっていたが、まさかこんな所から出て来ようとは(笑)。

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

「条件付きの緩和処置を実施」

microsoftから「条件付きの緩和処置を実施」したとのメールが来た。
そのメールによると「条件付きの緩和処置」なので、「ブロックは解除されましたが、IPアドレスの評価が確立されるまで、メールの送信制限を受ける可能性がございます。」とのこと。
というわけで実際にメールが送れるようになったかどうかは不明だけど、ユーザーには連絡してその内に試してみて貰うようにお願いした。

念のためブロックされた”かもしれない”IPアドレスも念のために送ってみたが、こちらは「緩和処置の対象外となります。」との返答が来たので大丈夫なようだ。

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

live.jpのブロックリストに載ってしまったらしい・・・

ユーザーから「”@live.jp”宛に送ったメールがことごとく返ってきてしまって相手に届かない。どうにかならないか?」との相談を受けた。
その返って来たメールを転送して貰うと
「550 SC-001 (COL004-MC4F30) Unfortunately, messages from
aaa.bbb.ccc.ddd weren’t sent. Please contact your Internet service provider
since part of their network is on our block list. You can also refer your
provider to http://mail.live.com/mail/troubleshooting.aspx#errors.」
と書かれているので、どうも送信元サーバーのIPアドレスがlive.jp(旧hotmail,outlook.com)のブロックリストに載ってしまったらしい。
このままではユーザーがお客様にメールを送ることが出来ないので、早速解決方法を探してみると、同じようにブロックされたけど解決した人がいた。
その人によると下記のurlにアクセスして、そのページからIPアドレス(の範囲)を送ると30分ほどでブロックが解除されたとのこと。
https://support.msn.com/eform.aspx?productKey=edfsmsbl2&ct=eformts
私も早速解除依頼を送っておいたので、少し待ってから試してみるつもり。

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

gmailにブロックされた?

ユーザーから「メールマガジンを送ったら、一箇所だけエラーで帰って来たので調べて欲しい。」という依頼が来て、エラーメールも送られて来た。
早速そのエラーメールを見ると、gmail.comのサーバーが出した
>421-4.7.0 [aaa.bbb.ccc.dddd 15] Our system has detected an unusual rate of unsolicited mail originating from your IP address. To protect our users from spam, mail sent from your IP address has been temporarily blocked.
という部分があった。
Googleによると内容は
「ご使用の IP アドレスから送信された異常な数の未承諾メールが検出されました。ユーザーを迷惑メールから保護するため、ご使用の IP アドレスから送信されたメールを一時的にブロックしました。」
というものなので、送信に使われたIPアドレス(上のaaa.bbb.ccc.ddd)から一定量以上のメールが送られたことで一時的にブロックされたということになる。
しかもブロックされたアドレスはユーザーが送信に使ったメールサーバーのIPアドレスでは無かったので、こちらとしては何も対策が取れない。
というのは、受信者の一人が本来のアドレスからGmailに転送しているらしく、ブロックされたIPアドレスは転送に使われたサーバーのものだったため。
反対に言うと受信者側の問題なのでこちらが対策を取る必要は無いということになるわけだ。
それにしてもgmailにブロックされるほどの量のメールを転送するってどれだけ大量のメールを受けているんだろ?
大半が迷惑メールなのかな?

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