先だってクライアントから外部への接続を制限するためにsquidを導入した。
ところが、その後各所から「ネットが遅い」という連絡があって聞いてみるとsquidを設定したプロキシを通すと遅いという。
urlフィルタリングは有効なんだけど、外部への接続数が多いためにsquid自体がボトルネックになっている模様（汗）。
使用するキャッシュ容量やメモリ容量を多めに割り当ててみてどうなるかだなぁ？
More from: linux
←クリックしてくれると嬉しいです。
squidを導入してみた
職場の回線から外部へのアクセスが異常に多いので、ゲートウェイサーバーでフィルタリングをしてみることにした。
簡単にするためにLinux標準でインストールされているsquidを使うことにして、アクセス数が多く転送データ量も多いサーバーを含む複数のドメインに対する接続を禁止した。
動作させて数時間経ってからログを見ると、転送量がかなり減っているのが判ったが、曜日によっても異なるので、あと何日かは監視が必要だなぁ。
←クリックしてくれると嬉しいです。
ディスクフル・・・
現場のFAXで受信したFAXが紙で出てくるとの連絡があった。
調べてみると受信データを保存しているファイルサーバーのディスクが一杯になっている（汗）。
先日チェックした際は余裕があったのだけど、このパーティションにはsambaの.recycleディレクトリも置いてあって、その中に大量の削除済みデータが残っていた。
以前にこのディレクトリの中身が増えた際に削除後一定期間が経過したファイルを消すスクリプトを作ってcronで動作するようにしていたが、想定以上のファイルが削除されていたらしい。
中にはオフィスソフト（WORDやExcel）で作られたテンポラリーファイルも大量に残っている。
なので、取り敢えず毎日動作させているスクリプトを修正して削除済みファイルの保存期間を半分（2年->1年）にして動作させると、大量のファイルが削除されている。
さらにテンポラリーファイルに関しては保存期間を1-2日程度にするようにスクリプトを変更する予定。
で、気になるのはそのテンポラリーファイルのファイル名で、~$で始まるファイルが他にもなければ大丈夫なんだけど（汗）。
←クリックしてくれると嬉しいです。
一応対策は講じてみた
先日のdovecotの自殺騒動。
毎週日曜の早朝にntpdが時刻を調整するとdovecotが自殺してしまうので、dovecotの生存確認をして、もし落ちていたら起動するスクリプトを書いた。
後はlogを見て落ちる時刻を調べ、その数分後にスクリプトを動かすようにcrontabを設定。
念のため時間を空けて2回スクリプトを動作させるようにしたので、これで大丈夫だとは思うんだけどなぁ。
スクリプトの動作自体は確認したけど、動作させるタイミングが問題だな（汗）。
←クリックしてくれると嬉しいです。
dovecotの自殺・・・
先週に引き続き昨日もpop3デーモン（dovecot）が死んでいた。
maillogには
”Time just moved backwards by xx seconds. This might cause a lot of problems, so I’ll just kill myself now.”
というのが残っていて、時刻が巻き戻ったために自殺したとのこと。
たしかにntpdで時刻合わせをやっているけど、こんなことで一々死なれていては実運用上困ってしまう。
時刻が巻き戻るとトラブルの元になるのは解からないでも無いけどさぁ・・・
解決策としてはntpdで時刻を一気に合わせるのではなく、徐々に合わせるようにするか、時刻が巻き戻った後で生死を確認してdovecotを再起動するスクリプトを組むかのどちらか。
時刻が巻き戻るのは今のところ日曜日の早朝で、アクセスしてくる人が殆どいない時間帯だから、この時間帯に再起動のスクリプトを動かせば良さそうだな。
それにしても昨年までは時刻が大きく（20-30秒も）巻き戻ることは無かったんだけど、年明けから急に巻き戻るようになったのは何故だろう？？？
←クリックしてくれると嬉しいです。
ディスクフル？
ユーザーから「FAXがPCに入らず、紙で出てくる」という連絡が来た。
原因を調べるとFAXがデータを送るファイルサーバのディスクが満杯になっていたorz。
このディスク（というかパーティション）は500GBほど用意しておいたんだけど、FAXデータだけでなく他のパーティションに置いているユーザーディレクトリの共用のゴミ箱（.recycle）も置いてある。
このゴミ箱の中が整理されておらず、中には2年以上前に削除されたデータが残っていたりした。
このsamba用のゴミ箱を用意したのは私なんだけど、当初はディスクにかなり余裕があったので気にしていなかった（汗）。
取り敢えず古いファイルを30GBほど消して空き容量を確保したけど、このままではまた同じことが起きるのでゴミ箱の中の古いファイルを消すスクリプトを書いてcrontabに仕込んだ。
find ”ゴミ箱のあるディレクトリ” -mtime +730 -exec rm -v {} \;
深夜に動作するようにしたので、明日になったら空きが増えている筈なので確認しないとな。
←クリックしてくれると嬉しいです。
”/”デバイスを大きく出来ないかなぁ？
職場の古いサーバーのディスク容量を増やしたい・・・
しかもルートデバイスにあるディレクトリの容量を増やしたい。
他のデバイスだったら新規デバイスを作成してマウントし、そこにファイルをまるまるコピーしてからマウントし直せばなんとかなるけど、ルートデバイスではそうは行かないんだろうなぁ、、、
さて、どうやって拡張しようか。。。
←クリックしてくれると嬉しいです。
複数ファイル内の特定文字列の一括変換
Linuxで稼働させているサーバに置いてある特定のファイル群の内容を一部書き換える必要が生じた。
書き換える内容は特定の文字列を別の文字列に変換するだけなんだけど、なにせ書き換えが必要なファイルが数百個もある。
手作業で編集するには多すぎるので、なんか自動で出来ないかな？と思い調べてみると同じことを考える人はいるもので、ヒントどころか回答そのものがすぐに見つかった。
手順は一行のコマンド（実際にはパイプで接続した二つのコマンド）で非常に単純。
$grep -l ‘置換対象の文字列’ 置換対象のファイル群 | xargs sed -i.bak -e ‘s/置換対象の文字列/置換後の文字列/g’
要は書き換えが必要なファイルをgrepで探し出し、それをパイプでsedに渡すんだけど、その際にファイル名をパラメータで渡すためにxargsコマンドを使用している。
実際にやってみるとあっというまに数百個のファイルの編集が完了、いやぁ助かったなぁ（汗）。
←クリックしてくれると嬉しいです。
cronファイルの場所
linuxサーバのユーザーの移行に伴って、各ユーザーのcrontabの内容を確認する必要があった。
一人や二人ならそのユーザーでログインするか、スーパーユーザーでcrontab ユーザー名 -eで確認するんだけど、数十人分なのでちょっと面倒。
なので各ユーザーのcrontabの内容がどこにあるかをググって見たらすぐに見つかった。
/var/spoo/cron
というディレクトリにユーザー名のファイルがあって、その中身がcrontab -eで編集しているファイルそのもの。
所有権を見ると600だけど、スーパーユーザーならcatコマンドで中身を見ることは可能。
あー、これで楽になったなぁ。
←クリックしてくれると嬉しいです。
サーバ間のメール転送が上手くいかない・・・
メールサーバの移行に伴い、新旧サーバ間でのメールの転送が必要になった。
具体的には新サーバの特定ユーザー宛のメールを旧サーバに転送することになる。
そこで該当ユーザーの”.forward”ファイルに転送先の旧サーバのアドレスを書いたのだけど、
「sendmail deferred connection refused by XXX」（XXXは送信先、要は旧サーバ名）
のエラーとなり送信出来ない。
それもその筈、旧サーバは当初外部からのsmtp接続を受け付ける必要が無かったので、”sendmail.cf”の
「O DaemonPortOptions=Port=smtp,Addr=127.0.0.1, Name=MTA」
という項目がデフォルトのままだったために、外部からのsmtp接続を拒否していた。
ここにもう一行
「O DaemonPortOptions=Port=smtp,Addr=aaa.bbb.ccc.ddd, Name=MTA」（aaa.bbb.ccc.dddは自サーバの実際のIPアドレス）
という行を追加し、sendmailを再起動することで回避出来た。
ところがその後も新サーバ側からメールを送ると、
”553 5.3.5 system config error”
とか
”553 5.3.5 xxx.yyy.zzz. config error: mail loops back to me (MX problem?)”
というエラーが出てやはり送信出来ない（汗）。
これらのエラーは”/etc/mail/local-host-names”ファイルに関係する全てのサーバ名（ホスト名、ホスト名+ドメイン名）を追加で記述しsendmailを再起動することで解消出来た。
また
”Relaying denied”
も出ていたので、これは”/etc/mail/access”ファイルにリレーを受け付けるホスト（要は新サーバ）のIPアドレス＋”RELAY”を記述し、makeし直すことで解決した。
上記の設定変更でようやく新サーバから旧サーバへのメールの転送が可能になったので、ようやく落ち着いたよ（汗）。
←クリックしてくれると嬉しいです。