More from: 仕事

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

P , by

c 4 comments

リコーのＦＡＸ機「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」に比べると退化したなぁ。
アドレス帳の個別設定すら出来ないのはかなり使い難いから、作り直して欲しいよ。

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

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

P , by

c 4 comments

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

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

久々にスクリプトを書いたら（汗）

P , by

c No comment

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

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

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

P , by

c No comment

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以降はまだ無いみたいだな。
こちらも引き続きチェックをするように心掛けておこうっと。

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

何故今頃？

P , by

c 2 comments

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

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

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

さらにパッチが当っている模様（bash）

P , by

c No comment

先日セキュリティホールが公開されて騒ぎになっているbash。
私のところで使っている古いLinuxで使用可能なbashも対策が適用されたVer.と入れ替えた。
昨日の夕方インストールしたのは
bash-3.0-27.0.2.el4.src.rpmからビルドし直したbash-3.0-27.0.2.el4.。
→bashが「CVE-2014-7169」に仮対応参照。
今朝方チェックするとさらに新しい
bash-3.0-27.0.3.el4.src.rpm
が公開されているので、早速ダウンロードして（ダウンロード元は先の記事参照）
# rpmbuild –rebuild bash-3.0-27.0.3.el4.src.rpm
リビルドし、
# rpm -Uvh bash-3.0-27.0.3.i386.rpm
でインストールした。
検証用のコード
# env x='() { :;}; echo vulnerable’ bash -c “echo this is a test”
を実行すると前バージョンの3.0-27.0.2.el4の時には出力されていた
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x’
が抑制され、
this is a test
のみとなったが、これで正常の筈。

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

bashが「CVE-2014-7169」に仮対応

P , by

c 4 comments

「bashの脆弱性対策」で書いたbashの脆弱性に関して、未対応だった残りの脆弱性（CVE-2014-7169で報告）に仮に対応したbash-3.0-27.0.2.el4がリリースされていた。
先の記事同様ソースパッケージ
https://oss.oracle.com/el4/SRPMS-updates/bash-3.0-27.0.2.el4.src.rpm
をダウンロードして
# rpmbuild –rebuild bash-3.0-27.0.2.el4.src.rpm
でrpmパッケージをビルドして
# rpm -Uvh bash-3.0-27.0.2.i386.rpm
で適用完了。
CentOS版のbash-3.2-33.el5_10.4も出ているとのことなので、yumでアップデートが出来るようになる筈。

情報を下さったちょろさんありがとうございます。

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

ちょっと新しくなったVer.は駄目だった（汗）

P , by

c No comment

bashの脆弱性対策を行ったが、bash-3.2-33.el5.1.src.rpmを使ってビルドしようとしたら「とあるヘッダファイルが無い」って言われてコンパイル出来なかった。
bash-3.2-33.el5.1.i386.rpmをそのまま入れようとしたらglibcのVer.が古くて入れられないのでソースから入れ直そうと思ったけど、やっぱり無理だったか（汗）。

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

bashの脆弱性対策

P , by

c 7 comments

9/24にbashの脆弱性が発見されたと公表されてから一部では騒ぎになっている。
bashをインストールしていないシステムでは無関係だけど、使い勝手の良いshellなので各ディストリビューションではデフォルトのshellになっているものもあり、その場合は対処が必要となる。
まずは自システムにbashがインストールされているかどうかをチェックし、入っていたなら下記を実行して結果を見る。
$ env x='() { :;}; echo vulnerable’ bash -c “echo this is a test”
実行結果として
vulnerable
this is a test
と表示されたらこの脆弱性の影響を受ける可能性があるので、bashにパッチを適用する必要がある。
RedHat系でyumが使えるなら
# yum uodate bash
でbashパッケージをアップデートすればOK。

再度テスト用の上記コマンドを実行して
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x’
this is a test
と表示されれば一応は対策出来たことになる（今回のパッチでも脆弱性が残ると報告されているので、再度のパッチの適用が必要になる）。

yumが使えない古いシステムならup2dateを使うか、bashパッケージをダウンロードして自分でインストールする必要がある。

私の場合は古いシステムで1台だけbashの2系が入っていて、さらにyumもup2dateも使えないサーバがあり、結局その1台だけはソースパッケージを探し出してrpmパッケージをビルドしてインストールすることで対処した。
ソースパッケージはOlacle Linuxの配布サイトから
https://oss.oracle.com/el4/SRPMS-updates/bash-3.0-27.0.1.el4.src.rpm
をダウンロードし、
# rpmbuild –rebuild bash-3.0-27.0.1.el4.src.rpm
でrpmパッケージをビルドして
# rpm -Uvh bash-3.0-27.0.1.i386.rpm
でインストールした。

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

早朝から・・・

P , by

c No comment

昨夜は早くに寝てしまったので今朝は早起き。
は良かったんだけど、そんな時に限ってユーザーからSOSのコール。
いつもならそろそろ起きようかという時間だったけど、今日は早起きしていたので受けたところ、「メールの受信が出来ない」とのこと。
急いで身支度をして職場に駆けつけ問題のメールサーバーをチェックすると/var/の下が満杯orz
すぐに古いログ等を消してディスクを空けて受信は可能になった。
さらに調べると全く使われていないアカウント向けへのメールが大量に残っていることが判明したのでそれも削除。
そのアカウントに配信されるように設定してあるaliasもアカウント自体も削除したので、しばらくは大丈夫な筈。

他のサーバーからの受信も拒否していたので、問題のサーバーに向けてメールを送ろうとしていた他サーバーにはqueueが溜まっていた。
それら溜まっていたqueueを吐き出したところ自分のクライアントで受信が出来たので対応は完了。
sendmailで溜まっているqueueを強制的に吐き出すには
#sendmail -q
でOK。
溜まっているかをチェックするには
#sendmail -bp
を実行し、
Mail queue is empty
と出ればqueueは溜まっていない。
逆に
Mail Queue (1 request)
–Q-ID– –Size– —–Q-Time—– ————Sender/Recipient————
xxxxxxxx 9999999 ”曜日” ”月” ”日” ”時刻” <”送信者”/”送信先”>
のように表示されれば残っているということ。

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