More from: 仕事

リコー「EL6000」のワンタッチキー登録

リコーのFAX機「EL6000」を導入した。
設定の殆どはリコーのCEさんがやってくれるので楽なんだけど、ワンタッチキーの登録に関しては自分でやっている。
というのも以前の機種からの移行をする必要があるのだけど、登録データのフォーマットが違いすぎて古いFAX機からリコーのセンターに登録して新しいFAX機でダウンロードして移行するという手段が取れず、データを何らかの手段で一度フォーマット変換する必要があり、それをリコーに頼むと有料になるため。
というわけで古い機種からダウンロードしたデータをLinuxサーバに入れ、awkで書いたスクリプトを通してフォーマット変換をかけたファイルを「EL6000」のWEBインターフェースを使って一括で流し込んでいる。
ところが「EL6000」側でのチェックが思いのほか厳しく、最初の頃はエラーの連続で苦労した。
一番面倒だったのは古い機種とは違って宛先名に半角が使えないので、英数字も全て全角にする必要があり、変換後のファイルを一度目視でチェックして半角があれば全て全角に書き換えなくてはならないこと。
しかも振り仮名の部分は反対に全角を許していないので無条件に全角に変換するわけにもいかないので面倒だ。

他にもワンタッチキーは全部で1000件登録出来るにも関わらず一度の処理で登録できるのが100件までなので、100件以上ある時は複数回登録処理を繰り返さなくてはならない。
同じファイルに100件以上書いてある場合は何番目から登録するかを指定できるので、999番目に登録したい場合は900とかの数値を指定すると登録出来る。
このことを知るまではファイルに書いてあるのに何故登録出来ないのか判らず、登録されなかった分は手動で入力していた。
マニュアルには書いてあるかもしれないけど、WEBインターフェースにも注意書きで入れておいてほしかったなぁ。
いや、マニュアルをきちんと読んでおけば良いのだろうけど、リコーのCEさんも知らなくて本社の開発部門にまで問い合わせて初めて判ったんだよね(汗)。
でも何故そんな制限を設けてあるんだろう?

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

あせったあせった(汗)

部下が現場のサーバに遠隔からリモートデスクトップ接続でログインして作業して、ログアウト時に間違って「シャットダウン」を選んだままOKボタンを押してしまった。
当然サーバは電源が落ちるわけで、そうなると遠隔操作ではどうしようもない(HPのサーバだったら良かったのにと思ってしまった)。
慌てて現地の人に電話して電源SWを押して貰いサービスの中断は僅かで済ませることは出来たけど、報告を受けた時はあせったなぁ。

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

印刷が薄い?

現場からレーザープリンタ(LBP-8610)の印字が薄いという連絡が来た。
まだ現物を見ていないが過去の例から考えるとレーザーユニットの光学系に付着した汚れが原因と思って間違いない。
手元には同機種から取り出したレーザーユニットがあるので、それの光学系(ミラーやプリズム)を綺麗にして交換するつもり。
LBP-8610は上部カバーを外すのがちょっと面倒なんだけど、それ以外はそれほどでもないのでレーザーユニットの交換は楽なほうで助かるよ。

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

週末なのに・・・

今日は土曜日で、そろそろ仕事も終わりという頃にSOSの電話。
なんか現場のHUBが壊れたようで接続が安定しないので、これから替えのHUBを持って現場行きとなった。
さっさと済ませて帰ろうっと!

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

ネットが繋がらない?

今日になって元顧客のところから「ネットが見れなくなった」とSOSが来た。
最初はルーターのせいかと思い再起動をして貰ったとのことだが、それでも解決しなかったらしく再度SOSが来た。
そこのルーターはちょっと高価なルーターで、メーカー保守が切れているので別の製品に買い換えて貰っていた筈だったが、現在その顧客をサポートしている会社の人と話をすると、実は新しいルーターには替えていないとのこと。
なので丁度良い機会なのでルーターを交換して貰うことで話は終った(後はあちらの会社の仕事になる)。

ところが夕方になってから同じルーターを使っている別の元顧客からも同じSOSが入ってきた。
同様にルーターのせいかとも思ったが、業務用のルーターが1日で2台も壊れるとは思えない。
こちらもサポートをしている会社の人と話をするとDNSサーバーの情報がプロバイダ指定のものと異なっていることが判明した。
試しに設定をプロバイダ指定のアドレスに変更したところあっさりと解決。
元々設定してあったアドレスは別プロバイダ(KDDI)のもので、DNSサーバーとして返答を返してくれなかったらしい。
試しに私もそのサーバーに問い合わせを出してみると問題無く名前解決が出来るので、サーバーとして正しく動作しているのはたしか。
では何故元顧客のところでは駄目だったのかな?と思ったら、私の環境ではプロバイダがKDDIだった(汗)。
ということは今までは他のプロバイダを利用しているクライアントからの問い合わせにも応えていたが、今日になって自社の契約者のクライアントからの問い合わせにのみ応えるようになったのかな?
だとすると一軒目も同じ原因だったのかも・・・

後で他のプロバイダを利用しているところから試してみよう。

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

どっちを優先するかの問題なんだけど

リコーのFAX機「EL-6000」を導入しようとしているが、実際に納入された実機で不具合が発生している。
1つは特別仕様でIP-FAX(メールを利用したネットワークFAXではなく、EL-6000同士が直接IP通信を行いFAXデータの送受信を行うモード)の使用を可能にして貰ったが、これが通信できず使えない。
2つ目は受信したFAXデータをサーバーに送信出来無い。

IP-FAXは同一セグメントに設置したEL-6000同士では問題が発生しないので、機能自体は動作している。
なのでこれはネットワーク上の問題と思われるが、事前にメーカーの人に通信で使用するポート番号を問い合わせた際に「SL3400/ML4600と同様」との回答を貰っていたので、各ルーターではそのポートしか開けていなかった。
ところがその後IP-FAXで通信に使うポートはデフォルトでは25(SMTPポート)ということが判明したので、ポート番号を25からSL3400/ML4600で使用しているポート(TCP1720,TCP49152-49153)に変更する必要があるとのこと。
早速実機でデフォルトのポート番号を25から1720に変更してみたがやはり通信が出来ない。
その際に気付いたのが実機からバックアップしたアドレス帳データ(短縮ダイヤル等)の中にある”ポート番号”という項目にセットした覚えの無い”25″という文字が入っていたこと。
メーカーには
「もしかするとアドレス帳の設定時にポート番号を設定しない場合はデフォルトのポート番号が自動で設定され、送信時にはそのポート番号を使っているのではないでしょうか?」
と質問してみたが、その時には明確な回答が得られず、再度調査させて欲しいとのことだった。
後日メーカーの人が実機での動作試験を行ったところ、先の推測が正しかったようで、アドレス帳のポート番号を1720に書き換えたら無事に通信が出来たとのこと。
なので今後設置して貰う機械では最初にデフォルトのポート番号を変更して貰うことになり、さらにこちらで書き込むアドレス帳データにも最初からポート番号を書いておくことにした。

でもなぁ、デフォルトを書き換えたら既に設定してあるデータも書き換えて欲しいと思うけど、無理なのかな?
うーん、運用を考えたらヘタに自動で書き換えないほうが使いやすいか。
だとしたらデフォルトの変更時に既にあるデータも書き換えるかどうか問い合わせて、「書き換える」を選んだら書き換えるとかにしたらどうかな?

この「EL-6000」という機械のWEB設定画面は今までの「SL3400/ML4600」に比べると退化したなぁ。
アドレス帳の個別設定すら出来ないのはかなり使い難いから、作り直して欲しいよ。

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

スクリプトは動くようになった

先日から作っていたファイルフォーマット及び文字コード変換用のスクリプトがようやく形になった(汗)。
元のファイルの中に複数の形式のレコードが混在していたので面倒だったけど、そこはなんとか力技で押さえ込んだ。
てこずったのが特定の文字(全角の長音記号)が元のコード(SJIS)から他のコード(EUC,UTF-8)に変換できなかったこと。
いろいろ調べてみたけど皆さん苦労していらっしゃるようで上手い解決策が見つからなかった。
仕方が無いのでテキストエディターで開いて全角のハイフンに一括変換をかけることで対処した。
元のファイルが三十数個程度だったのでこんな荒業が使えたけど、これがファイル数が三桁だったらやりたくないよなぁ・・・
どうにかして自動で変換できないものか・・・

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

久々にスクリプトを書いたら(汗)

先日仕事でスクリプトを書いた。
簡単なcsvファイルのフォーマット変換用のスクリプトだったんだけど、久々にawkを使ったら構文をすっかり忘れていた(汗)。
基本的な書き方は覚えていたんだけど、ifやらwhileの使い方があやふやだったのでネットで検索。
こういう時はネットはありがたいな。

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

またbashにパッチが当った模様?

bashの脆弱性に対する対策で先週bash-3.2.22からbash-3.2-33.el5_10.4に上げたばかりなんだけど、今日yumでチェックしたらbash-3.2-33.el5_11.4が出ていたらしいので早速アップデートした。
とはいえ、このバージョンはRHEL5のバージョンが5.11なので出たらしく、CentOS用のel5_10.4との違いは全く無いらしい。
それでも出来るだけ新しくしたほうが気分的に良いからそのままにしておこう(笑)。

3.0-27(EL4)のほうはOracleのサーバを見てもbash-3.0-27.0.3以降はまだ無いみたいだな。
こちらも引き続きチェックをするように心掛けておこうっと。

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

何故今頃?

先週の金曜日(9/26)に書いた「bashの脆弱性対策」の被参照数が今日になって増えている。
週末の休みが終って対策に奔走する羽目になったサーバー管理者の方々が多いのだろうか?
まぁ先の記事にはyumが使えない場合の手順も書いたからそのせいかな?

先の記事を書いた後にさらにパッチが公開されているので、ホントは「bashが「CVE-2014-7169」に仮対応」とか「さらにパッチが当っている模様(bash)」のほうが参考になると思うけど(汗)。

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