More from: linux

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つのパーティションのフォーマットもしなくちゃならないんだけど、全部で何時間かかるのやら・・・・・

人気ブログランキングへ←クリックしてくれると嬉しいです。

設定忘れてた(爆)

今朝方職場のサーバーを再起動したところ、別ネットワークのPCから接続できなくなってしまった。
route情報を見るとものの見事にrouteが設定されていない。
どうもネットワークを分割した時には手動で/sbin/routeコマンドを使ってroute情報を設定して、その際に設定ファイルには書いていなかったようだ(設定ファイルそのものが存在していなかった)。
なので、以前書いた「ネットワークの分離」の記事を参考にroute情報の設定と設定ファイル(/etc/sysconfig/static-routes)の作成を行った。

今日が土曜日で良かった・・・・・・・・

人気ブログランキングへ←クリックしてくれると嬉しいです。

さてと、パーティション構成をどうするかな?

職場のファイルサーバ用に外付けHDDユニットを買ってきたけど、どのように分割するかで悩んでいる。
スペース効率を考えると1つの大きなパーティションだけを作って、その中に各部門用のディレクトリを作れば無駄なく使えるんだけど、そうすると特定の部門が大容量のデータを置いてしまい、他の部門で使える容量が減ってしまう危険がある。
かといって細かく分割すると空きが点在する形になり、効率が悪くなる。
うーん、どうしようかなぁ?
とりあえず、自分達用のパーティションだけは最初に確保しようっと(爆)。

fdisk->mkfsの順だっけか?(爆)
fstabも書き換えなくては・・・・・・・・・

人気ブログランキングへ←クリックしてくれると嬉しいです。

メモ:aliasのチェック

sendmailでaliasを使用している場合の設定のチェック方法のメモ。
#sendmail -bv alias名
これを実行すると指定したalias名がどのように展開されるかが分かる(-bvはベリファイモードの指定)。
aliasesファイル内に記述してあっても、上記コマンドで出て来ない場合は
#newaliases
でエイリアスデータベースを作り直してみる。

人気ブログランキングへ←クリックしてくれると嬉しいです。

-Fもしくは–flushオプションだったのね

一個前の記事「fetchmailで取得済みのメールを削除するには?」に書いたことは、-Fもしくは–flushオプションを付けてfetchmailを起動することで実現出来た。
man fetchmailでオプションを調べたときにこのオプションにも気付いてはいたんだけど、-kもしくは–nokeepと同じだと思っていた。
Manpageをよく読むと
-k or –nokeep
「取得したメッセージをリモートのメールサーバから削除します。」
-F or –flush
「新しいメッセージを取得する前に、古い (以前に取得した) メッセージをメールサーバから削除します。」
となっており、この二つの意味は違うことに気付いた(良く嫁!<自分)
試しに
fetchmail -Fv
を実行したところ、数千通ものメールがサーバから削除されていく様子を見ることが出来、終了後にホームディレクトリにあった「.fetchids」ファイルも消えていた。
うーん、最初にManpageを見たときに気付いていれば悩まずに済んだのになぁ(汗)。

#「.fetchids」ファイルは取得済みでサーバに残してあるメールのエントリを記録しているファイル。

人気ブログランキングへ←クリックしてくれると嬉しいです。

fetchmailで取得済みのメールを削除するには?

いやまぁタイトルの件が判らなくてサーバと格闘中。
受信するクライアントPCが複数台ある関係で”keep”オプションを.fetchmailrcに書いてあるユーザーがいるが、サーバ内に数千通溜まってしまって、受信にえらく時間が掛かってしまうので消してくれといわれて消そうとしてる。
単純に
fetchmail -avK (Kはnokeepと同じ)
とすると、過去に受信したメールを再取得してしまい、数千通を再受信するので少々困る。
いつもはnPopというソフトで古いメールを消しているが、今日に限ってエラーを起こしてしまい作業が出来ない。
うーん、fetchmailで取得済みのメールをサーバから削除する手段があると思うんだけどなぁ、、、、、、

解決策はこちら「-Fもしくは–flushオプションだったのね」

人気ブログランキングへ←クリックしてくれると嬉しいです。

MXレコードの設定が終わったようだ

昨日書いたMXレコードを設定していないDNSサーバは昨日の内に設定が完了したようで、nslookup -type=mx hogehoge.comで見ても、host -t mx hogehoge.comで見てもMXレコードが見えるようになった。
これでメールの送信元に昨日のようなエラーが返ることもなくなるだろう。

それにしてもDNSサーバの設定をしたのは経験1年のほぼ新人なんだけど、私の「MXレコードが設定されていない」の一言で理解したようなのには少々驚いた。
けっこう出来の良い新人らしい・・・・・・・

人気ブログランキングへ←クリックしてくれると嬉しいです。

特定の相手先からのメールが届かない?

職場の人からタイトルのような問い合わせがあった。
なんでもこちらからメールは届くのだが、それに対する返信がこちらへ届かないとのこと。
他の人からのメールは届くとの事なので、メーラーの設定誤りでは無い。
先方からエラーメールをFAXで送って貰ったのでそれを見ると、
”No delivery mechanism available”
となっている。
これは大抵は送信元のメールサーバが送信先のメールサーバのIPアドレスを引けない場合に発生し、DNSのMXレコードの設定が正しくない場合に発生する。
試しに適当なサーバで「host -a hogehoge.com」としてDNSの設定情報を見ると、案の定MXレコードが設定されていなかった(爆)。
ドメイン名のみでアドレス参照をするとIPアドレスを引くことは出来るので、大抵のメールサーバはそれを利用しているらしいが、件のメールサーバはRFCの既定通りの動作をしているようだ(だからIPアドレスを引け無い)。

問題はDNSの設定をしたのが私では無いので、設定を直すことが出来ないということだ。
設定した人間は上に書いたようなことを理解してくれるのだろうか???

人気ブログランキングへ←クリックしてくれると嬉しいです。

LANカードがやられるとは”想定外”だった

今日の朝早くにビルの電気工事(点検?)が入るとかで、昨日の内に連絡が入った。
そのビルにはPCをベースにしたサーバを2台置いてあり、停電に備えてUPSを設置してあるが悪いことにバッテリーが寿命で交換用バッテリーを注文したばかり。
しかも停電予想時間が30分ほどなのでUPSに頼るわけにはいかない。
なので、昨夜の営業終了後にサーバー2台の電源を切りに行き、翌朝出勤してきた人に電源を入れるように頼んできた。
さらに2台の内1台は以前電源を再投入したときに素直に起動しなかったことがあるので、念のため電源を入れたら連絡して貰う様に頼んできた。
今朝になって電源を入れたとの連絡があったので、そのサーバに向かってpingを打ち始めたが20分以上経過してもpingが返ってこないので、これは起動途中でハマっているなと思い現地に行った。
現地に付いてコンソールを見ると恐れていたHDDのエラーは出ていなかったが、その代わりLANインターフェースが応答してこないとのエラーが出ていた。
つまりpingに対する応答が無かったのはLANカードが正しく動作していなかったためだったのだが、何故正しく動作していないのかは不明。
とにかくネットワークに繋がらないとサーバの存在する意味が無いので、代わりに同じ型番のLANカードを複数用意して再度現地に行き交換してみた。
用意したのが手持ちの中古品だったせいか最初に交換した1枚はドライバすらロードされず使えない状態。
少々焦ったが用意した別のカードに再度交換したところ無事にドライバがロードされネットワークにも接続できた。
今回トラブったサーバは全体的に古いもので、今でも動作していること自体が不思議なくらい。
#CPUがPentiumIIIの550MHzというくらい古いが、電源ユニット以外は無交換。
それでも稼働中は特に問題を起こさないのでそのまま使っていたが、まさか電源の再投入でLANカードが死ぬとは思っていなかった。
幸い同じLANカードが何枚か手元にあったので復旧させることが出来たが、今後はなんらかの対策を講じないとならないなぁ。

人気ブログランキングへ←クリックしてくれると嬉しいです。