More from: linux

今回は2千通弱だった

時々頼まれてサーバ上に残してあるメールを削除しているが、今日は約2ヶ月振りにやることになった。
いつもは先方から依頼されて実行するのだが、今回はこちらから削除が必要かどうかを尋ねたところ、
「是非やって欲しい!」
と言われた。
それだけならいつものように
fetchmail -Fv
で取得済みのメールを削除するのだけれど、今回は
「古いのだけを消して貰えないか?」
と言われてしまった。
ところが-Fvオプションを付けてfetchmailを実行すると、サーバ上にあるメールのほぼ全てを削除してしまうので、それは出来ないと答えた。
まぁそれでも良いとのことだったので早速実行して2千通弱のメールをサーバ上から削除した。
ヘッダー形式がRFCに則っていない数通が取得されずにサーバ上に残ってしまったが、全てSPAMだったのでnPopを使って削除した(先に「ほぼ全て」と書いたのはこのようなメールが残るため)。

後から考えたら.fetchidsファイルを加工してから実行すればサーバ上にメールを残すことが出来るかな?と思ったが、.fetchidsに書かれていないメールは再取得されるだけなので、やはり選択的にメールを削除するのは困難だということに気付いた。

うーん、なんか良い方法は無いかなぁ?

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

サーバを移設したら(汗)

今日はサーバの内の一台を移設する予定をたてていた。
昨日から関係各所には連絡をしておき、さらに作業1時間前にも再度連絡を入れておいた。
と言っても本運用開始前の試験運用中のサーバだったので、連絡する相手もほんの僅か。
設置場所には事前に必要な配線を済ませておき、後は件のサーバーを一旦停止して運び込むだけとなっていた。

予定時刻になったのでサーバを止め、仮の設置場所から本来の設置場所に持ち込み(重かった・・・)、先に配線を済ませておいた電源ケーブルやLANケーブルを接続して電源を投入。
本来はこれだけで作業は終わりの筈だったが、サーバが起動したは良いがネットワークに接続出来ないorz
さんざん調べて判ったことはLANケーブルの挿し間違いで、それに気付くまで30分程度も悩んでしまった(汗)
#オンボードのLANポートと増設分のLANポートの設定を勘違いしていたのが原因だったといふ・・・・

これでほぼ予定通りにサービスを再開できることになったので、関係各所に連絡を入れて利用を再開して貰った(中には連絡する前に再開したユーザーもいたけど)。

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

久々にメールボムを喰らった・・・・・・・

「同じメールが何通も繰り返し届くんだけど、なんかおかしくない?」
という問い合わせが来た。
調べてみると3MB~10MB弱のメールが数通届いていて、それをfetchmailで代行受信しようとしてタイムアウトを起こしていた。
問題のアカウントはfetchmailのオプションでタイムアウト時間(-t)を指定していなかったので、デフォルトの300秒では全てを受信できなかったようだ。
タイムアウトを起こすのでサーバ側のメールを削除しないものだから、何度も同じメールを受信してしまっていた。
早速サーバ側に残っている大きなサイズのメールを削除し、fetchmailのタイムアウト時間も延ばしておいたから、しばらくは大丈夫かな?
それにしても以前から無駄に大きなファイルを添付してくる業者だったけど、また業務妨害をしてくるなんてなぁ、、、、、いっそのこと受信拒否をかけてやろうか?(爆)

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

ubuntuのアップグレード

久しぶりにubuntuをインストールしてるノート(DELL Inspiron 6000)を起動したら、自動でアップグレードのチェックに行ったらしく、ubuntu11.10にアップグレードしてくれるとのこと。
まぁしばらく放っておいたから久々にアップグレードするかぁ、と思って進めていくと、ダウンロード容量が700MB超orz
ダウンロード自体は20分もかからずに終わったらしいが、インストールには2時間以上かかるらしい・・・・・・
というわけで、久々に使おうとしたubuntuノートはしばらく触れない状況になってしまった。
しかもこんな時に限ってオンラインでチェックしなければならないことが出来、仕方が無いのでWindowsの入ったThinkPad(T42)を起動して使うことにした。
別にThinkPadでなくても良かったのだけど、一番手近にあったのがこれだったのでT42を起動した。
こんな時はPCが複数台あって助かるなぁ(笑)。
普段はリビングで使うPCは一度に一台だけなんだけど、今日は特別だね。

と言っても、元々の目的は果たせて無いのには変わりが無いんだけど、取り敢えずアップグレードが終わらないとubuntu機は使えないから終わるまで待つしか無いか・・・・・

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

fetchmail でのサーバ上のメールの削除

4月にもやったけど、今日もメールサーバ上に溜めてあるメールの削除を頼まれた。
1アカウントを複数のPCで使うために普段の受信時にはサーバ上にメールを残すようにしてあるが、大量に溜ると受信時のレスポンスが悪くなってしまうので、ユーザーが我慢できなくなったら削除を依頼してくる。
なにせ前回実施したのが4月の末なので、詳細な手順を忘れている(爆)。
なので、この時の為にと思って当時このブログに手順を書いておいたので、今回はそれを参考にした。
「-Fもしくは–flushオプションだったのね」

今回は約4800通のメールが上記の手順で削除された。

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

awkのメモ

linuxサーバーのmaillogから下記の項目を抜き出す必要が出来た。
・端末のIPアドレス
・ユーザーアカウント
・端末名(名前解決が出来たもののみ)
しかも特定のネットワークからのアクセス分だけという条件付。

で、まずは/var/log/maillog*から特定のネットワークからの分だけを
#grep “ネットワークアドレス(xxx.yyy.zzz)” maillog* > hoge
でhogeというファイルに吐き出した。
次に
#cat hoge | grep pop | awk ‘NF=14{print $12,$13,$7}’ | sort +1 | uniq > hoge2.txt
を実行して結果をhoge2.txtというファイルに書き出した。

#grep “ネットワークアドレス(xxx.yyy.zzz)” maillog* | grep pop | awk ‘NF=14{print $12,$13,$7}’ | sort +1 | uniq > hoge2.txt
のように全部を一度に書いても同じ結果が得られたはず。

awkの中でやっているのは
フィールド数が14ならば(NF=14)12番目と13番目と7番目の項目を書き出す。
ということ。
これで(ほぼ)望みどおりの結果が得られ、数万行にのぼるログファイルから10行少々を切り出すことが出来た。

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

指定したのとは別のプリンタから印刷される

先日仕事で行った先で、
「印刷なんですけど、たまに違うほうのプリンタから出るときがあるんですよ。」
と言われた。
問題の印刷はサーバー上のプログラムから出しているもので、ユーザーが操作するクライアントPC側では出力先のプリンタの指定をすることは出来ない。
しかもサーバ上での設定で違うプリンタを指定しているなら毎回違うほうのプリンタから出るはずなのだが、毎回ではなく”たまに”だということなので単純な設定ミスでは無い。
不思議なこともあるものだと思っていたら、思わぬところに原因があった。
件の印刷は本社のサーバ上で動作するプログラムが出力し、その際に出力先を現場に置いてある別のサーバに定義してあるプリンタを指定している。
この現場のサーバでのプリンタの定義に問題があった。
現場のサーバは古く、印刷システムがlpdなので、プリンタは/etc/printcapで定義している。
この定義の中にはプリンタのエントリが2台分あるのだが、スプールディレクトリの指定(sd=/var/spool/lpd/hogeの部分)が2台とも同じディレクトリになっていた。
仮に1台目をプリンタA、2台目をプリンタBとした場合、プリンタAに対して印刷要求を出した場合もプリンタBに出した場合も実際の印刷データは同じディレクトリに置かれることになる
このためプリンタAに対して印刷要求を出した際に、たまたまプリンタBに対応するデーモンが動作していると、プリンタAに出力する筈のデータもプリンタBに出力してしまい、データをプリンタBに送り終わるとデータを消去することになる。
しかもプリンタは直付けではなくプリンタサーバ経由での接続の為、データの転送はプリンタに直接送るよりも早く終わる。
このため本来印刷する筈のプリンタAではなく、もう一方のプリンタBで印刷されるということが起きてしまっていた。

いやぁ、最初は目的のプリンタにデータを送れない場合に自動で切り替えているのかと思ったが、そんな設定をした覚えはないし、lpdはそんな頭の良いことはしてくれない(爆)。
判明してみれば初歩的な設定のミスだったが、今後は気をつけないとなぁ。

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

sambaサーバに接続できない・・・・・・・

職場のPCの一台からLinuxで構築してあるファイルサーバに接続できない・・・・・・
クライアントのOSはWindows7Proの64bit版(だった筈)。
サーバ側のログを見る限りパスワードが間違っているということになっているが、設定したパスワードと入力したパスワードは同じ(筈、クライアントの操作は他人に依頼している)。
ちなみにXpのPCで同じユーザーアカウントを作成して同じようにアクセスすると問題無く接続出来るので、サーバ側よりもクライアント側に問題があるようだが、自由に触れるPCでは無いので原因調査に時間がかかりそうだ(操作を他人に依頼しているのもそのため)。

駄目元で「guest ok = yes」に設定してもパスワードが違うといってはじかれてしまう・・・・・・
うーん、謎だ・・・・・・・・

こういうことは時折あるが、大抵はちょっとした設定のミスとか見逃しが原因なんだよなぁ、、、、(汗)

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

vacationが動かないぃーーーーーー!!!

職場のメールサーバにvacationプログラムを入れたが、いくら試しても自動返信がされない。
maillogを見ると
“attempt to use “vacation -r 0 hoge” (stat failed)”
と出ている。
デーモンから来たメールには
“smrsh: “vacation” not available for sendmail programs (stat failed)”
となっているので、これをヒントに調べたら”smrsh”で動作を許可するプログラムを置いておくディレクトリにvacationプログラムが入っていなかったのでsmrshがファイルを見つけられなかったためと判明した(このため”stat failed”が出ている)。

職場で使っているサーバではsmrshで動作を許可するディレクトリは
/etc/smrsh
だったので、そこにvacationを置いたところ無事に動作した。
実際はvacationプログラムの本体をそこに入れるのも何なので、
ln -s /usr/sbin/vacation /etc/smrsh/vacation
でシンボリックリンクを張った。

プログラムを入れるディレクトリは環境によって異なるみたいで、
/usr/adm/sm.bin (smrshのソースに付いてくるREADMEファイルに書かれているのはここ)
/usr/libexec/sm.bin (man smrshに書かれているディレクトリはここ)
とかがあるみたいだ。
今回は
#man smrsh
で出てくるのと違うディレクトリだったので見つけるまで時間がかかったよー!

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

Linuxでのパーティション作成メモ

Linux上でのパーティション作成手順のメモ。
/sbin/fdisk  パーティション分割
/sbin/mkfs -t ext3 /dev/sda1 (size:必要なら) フォーマット
/sbin/e2label /dev/sda1 ラベル名  ラベル付け

ここまですれば後は
mount /dev/sda1 マウントポイント
とすれば使えるようになる。
/etc/fstab

LABEL=ラベル名 マウントポイント ext3 defaults 1 2
の行を追加して次回起動時に自動でマウントされるようにしておく。

それにしてもUSBの外付けHDD(ミラーリングユニット)へのアクセスが遅いのかmkfsコマンドの実行にえらく時間がかかるなあ、、、、たった400GBのパーティションなのに・・・・・
この後さらに5つのパーティションのフォーマットもしなくちゃならないんだけど、全部で何時間かかるのやら・・・・・

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