More from: linux

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

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

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

bashの脆弱性対策

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
でインストールした。

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

早朝から・・・

昨夜は早くに寝てしまったので今朝は早起き。
は良かったんだけど、そんな時に限ってユーザーから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 ”曜日” ”月” ”日” ”時刻” <”送信者”/”送信先”>
のように表示されれば残っているということ。

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

またやっちゃった・・・orz

先週サーバーにfetchmailを使ってメールサーバからメールを取り込むように設定した。
今朝になってそのサーバーからスプールが満杯で配信出来ないと警告のメールが来たので調べてみると、取り込んだメールをメールサーバ側に残すようにしていたために同じメールを何度も取り込んでしまい、その結果スプールが満杯になっていた。
あれ?何で何回も同じメールを取り込むかなぁ?と思って調べてみると、.fetchmailrcファイルにはkeepオプションを記述してあるのに、実際の取り込み時にはallオプションを付けていたorz
これじゃメールサーバに残したメールを毎回取り込んでしまうのも当たり前だ・・・
早速allオプションを外したので、今後は一度取り込んだメールは取り込まなくなる筈。
滅多にやらない設定なので油断したなぁ・・・

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

メールアドレスに使える文字の話

「メールが送れない」
と連絡が来た。
「送ろうとするとなんかエラーとなる。」
と言うのでエラーメッセージを読んで貰ったところ、
「501 Bad recipient address syntax」
というようなエラーが出ている模様だ。
このエラーは読んだ通り「宛先アドレスの書き方に問題がある」状態なので、送ろうとした相手先アドレスを見ると先頭と@の直前に「-(ハイフン)」が使われている。
メールアドレスに使える文字はRFC 2822内の”Internet Message Format”セクションで規定されていて、「-(ハイフン)」を先頭に使うことは特に禁止はされていない。
ところが、先頭に「-(ハイフン)」があるとUNIX系OSのコマンドに文字列を渡す際にオプションと混同される危険性があるので、UNIX系OS上で動作するMTAによっては先頭に「-(ハイフン)」を使うことを禁じているものがある(Postfix等)。
今回のエラーはまさにこれに引っかかった様で、現在のところはこの宛先にメールを送る手段が存在しない(Postfixを使っている場合はオプションで許可することも出来る様だ)ので、送るのを諦めて貰うことになった(汗)。

プロバイダによってはユーザーが希望するアドレスを使うことが出来るが、先頭の文字を英小文字に限定しているところがある(ソフトバンクとかOCNとか)。
反対に制限を設けていない(もしくは過去に設けていなかった)プロバイダやキャリアもあるが、そのようなアドレスを持っている人は受け取れないメールもあるということになるので、出来れば先頭には英小文字を使うようにしたほうが良さそうだ。

参考までに携帯電話各キャリアでの使用文字の制限は以下の通り(2013年10月10日現在)
au
・Eメールネーム文字数が、30文字まで利用可能です。
・半角英数字、小文字、「- (ハイフン)」、「. (ピリオド/ドット)」、「_ (アンダーバー)」が使用できます。
・「.」をアドレス内での連続使用や「.」をEメールネームの最初/最後に使用することはできません。また最初に数字の「0」を使用することもできません。

docomo
・半角英数字および「_」(アンダーバー)、「.」(ピリオド)、「-」(ハイフン)の記号にて、3字以上30字まで設定することができます。
ただし、「.」は「..」などのように連続で使用することや@マークの直前で使用することはできません。
・「スペース(空白)」は使用できません。
・英字を入力する場合、大文字小文字の区別はありません。すべて小文字で表示されます。(注:大文字の使用は不可ということ)
・先頭文字は英文字にしてください。

ソフトバンク
・文字数 半角文字 3字~30字
・文字の種類 半角英数字 「-」(ハイフン)、「.」(ドット)、「_ 」(アンダーバー)
・ひとつ目の文字は英文字のみ 「1abc@i.softbank.jp」などは、設定できません。
・英文字については、小文字のみ使用できます。
・「-」(ハイフン)、「.」(ドット)、「_ 」(アンダーバー)以外の記号は、ご利用いただけません。
 例 : 「a bc@i.softbank.jp」 など
・「@」直前の「.」(ドット) は設定できません。
 例 : 「abc.@i.softbank.jp」 など
・「.」(ドット)の連続使用は設定できません。
 例 :  「a..bc@i.softbank.jp」 など
・携帯電話の社名、および、サービス名に関わる文字は、設定できません。
 例 : 「softbank.abc@i.softbank.jp」など

これを見ると各社で細かい違いはあるが、文字数(30字まで)や文字種(英小文字と数字の他は「-」「.」「_」のみ)は共通だというのが判る。
面白いのはソフトバンクの「携帯電話の社名、および、サービス名に関わる文字は、設定できません。」と言う項目で、例では”softbank”という文字列は駄目となっているが、”docomo”とか”ezweb”とかも駄目なのかな?(笑)

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

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

この大量のログはいったい???

職場のメールサーバでメールの配信が出来ないと連絡が来た。
調べてみるとディスク(/varを含むパーティション)がほぼ満杯になっている。
メールを溜める/var/の下には/var/logがあるので、その中のファイルで大きなものを探すとmessagesがかなり大きくなっていて、しかも4週間分残っている。
中身を見るとnamedのエラーが多くなっている(というか殆どがnamedのエラーで占められている)。
これはネットワーク環境を大きく変更した際にDNSのポートを閉じて外部のネームサーバへのアクセスを制限したために、以前は接続できた外部サーバへ接続できなくなったためだ。
問題のサーバは職場内だけのメールサーバで外部への配信はしていないので外部の名前解決のためにnamedを動かす必要は無いのだが、メールサーバ構築時はnamedが必須だと思っていて試行錯誤しながらbindの設定をしてなんとか動作させた。
ところが後に/etc/nsswitch.confで名前解決をfile(/etc/hosts)優先にしたのでnamedを止めても問題無くメールの配信が出来るようになっている。
試しに/etc/rc.d/init.d/named stopでnamedを止めてからメールの送信をしてみたが、職場内のどのルートでもメールの配信が出来たので今後はnamedを止めておくことにした。
なのでchkconfig –level 3 named offでサーバの起動時にもnamedを起動しないようにしておいた。

これで不要なログが出力されることも無くなる・・・・・・・・筈。

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

うー、お節介機能めぇー

職場でファイルサーバのファイルをメールに添付できなくなったと連絡が来た。
いろいろ訊いてみると
・問題のファイルをダブルクリックすると問題なく開ける。
・メールにDrag&Dropで添付しようとしても添付ファイルのウインドウに入らない。
・そのまま送信しようとすると「添付ファイルが存在しない」というエラーになり送信が出来ない。
どうもエクスプローラーでは問題なく使えるが、一部のソフトではファイルを認識できなくなっているようだ。
電話でいろいろと話をしている内に先方が
「コンピュータの画面で容量とかを表示する青いバーがこのドライブだけ表示されていない」
「ドライブのプロパティを見るとディスク容量も使用領域も0バイトと出ている」
と言い出した。
これって切断されたネットワークドライブのプロパティと同じ表示だ・・・・・・・
その後現場に行って問題のPCを操作して、ネットワークドライブの切断/再接続を何度か実行しても同じ状況。
いろいろ調べている内にオフラインで使用可能になるように同期をしようとしてエラーになっていることが判明。
職場内はLANで接続しているのでオフラインでの使用を可能にする必要は無いわけで、そのような設定をした覚えは無い。
設定した覚えは無いが実際にオフライン同期が実行されているわけで、まずはオフラインでの使用を禁止する設定をした。
「同期センター」を開いてオフラインファイルを無効にしてPCを再起動したところ、問題のネットワークドライブ内のファイルをメールに添付できるようになった。
なぜオフラインでの使用が可能になったのかというと、今日の一時期ファイルサーバの負荷が上がり、問題を起こしたPCからファイルサーバの中を見るのに非常に時間がかかるようなったことがあったために、Windows7が勝手に問題となったドライブをオフラインで使用するようにしてしまったため。
本来は遅い回線を使っていたり、ネットワークへのアクセスが出来ない場合に使われる機能なんだけど、全く余計なことをしてくれたものだな。
時間を見てクライアントPC全てでオフラインファイルを使えないようにしてしまうか・・・・・・・
調べてみるとsambaサーバではsmb.confに
csc policy = disable
とするとOKらしい。

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

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日以前に作成されたファイルが削除出来るはず。

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