2007年11月
2007年11月16日
なんだかごり押しの設定ですがとりあえず。。。
【条件】
同じPleskで管理しているドメインじゃないとダメかと。
| if [ -z "$SA" ]; then export SA=1; /usr/local/psa/bin/psa-spamc -u test@example.com -U /tmp/spamd_full.sock -E > spamcheck$$; check=$?; if [ -s spamcheck$$ ]; then if [ $check = 1 ]; then /var/qmail/bin/qmail-local "$USER" "受信する人のメールボックスまでのフルパス" "$LOCAL" "" "" "$HOST" "$SENDER" "$DEFAULT" < spamcheck$$; retval=99; else /var/qmail/bin/qmail-local "$USER" "$HOME" "$LOCAL" "" "" "$HOST" "$SENDER" "$DEFAULT" < spamcheck$$; retval=$?; fi; rm -f spamcheck$$; [ $retval = 0 ] && exit 99; exit $retval; fi; rm -f spamcheck$$; fi # REJECT UCE
【条件】
同じPleskで管理しているドメインじゃないとダメかと。
| if [ -z "$SA" ]; then export SA=1; /usr/local/psa/bin/psa-spamc -u test@example.com -U /tmp/spamd_full.sock -E > spamcheck$$; check=$?; if [ -s spamcheck$$ ]; then if [ $check = 1 ]; then /var/qmail/bin/qmail-local "$USER" "受信する人のメールボックスまでのフルパス" "$LOCAL" "" "" "$HOST" "$SENDER" "$DEFAULT" < spamcheck$$; retval=99; else /var/qmail/bin/qmail-local "$USER" "$HOME" "$LOCAL" "" "" "$HOST" "$SENDER" "$DEFAULT" < spamcheck$$; retval=$?; fi; rm -f spamcheck$$; [ $retval = 0 ] && exit 99; exit $retval; fi; rm -f spamcheck$$; fi # REJECT UCE
2007年11月15日
Plesk は確かに管理が楽です。でも、Pleskでカバーされていないことが必要になると本当に不便になってしまいます。
スパムメールについては、誤判定をどうしても防ぎたいと思います。とはいっても、判定自体については、地道なトレーニングしかありません。しかも絶対はムリですし。
Plesk + Spam Assassin では、スパムメールの判定は、件名に文字列の付与もしくは、削除しかありません。なぜ転送などができないのでしょうか。
転送ができれば、全員のスパムメールを誰かがチェックし、判断することができます。少なくとも消失の危険は避けられます。でもPleskではそれができないんですね。
こまったもんです。
スパムメールについては、誤判定をどうしても防ぎたいと思います。とはいっても、判定自体については、地道なトレーニングしかありません。しかも絶対はムリですし。
Plesk + Spam Assassin では、スパムメールの判定は、件名に文字列の付与もしくは、削除しかありません。なぜ転送などができないのでしょうか。
転送ができれば、全員のスパムメールを誰かがチェックし、判断することができます。少なくとも消失の危険は避けられます。でもPleskではそれができないんですね。
こまったもんです。
2007年11月14日
僕は、セキュリティの業界に(一応)いるので思うのですが、不安を煽る仕事や提案の仕方は嫌いです。よりベストな。とか、全体を俯瞰したときに脆弱な部分があるという指摘程度なら別に問題ないと思います。
しかしありがちなのは、VPNだけじゃダメですよ、とか、サーバーの会社は本当に信頼できるんですか？とか、そういう脅し文句です。
VPNは運用が絡むので、セキュアの度合いは多少変化しますが、VPNの内容をキャプチャされたりだとかという話は聞いたことがありません。
もちろん平文については、本当に簡単に中身を見ることができてしまうので、それは危険だと思います。もちろんそれは社内でも同様です。
ただそれ以外については、少しセキュリティの対策を施せば意外にセキュアだと僕は思っています。
たとえばレンタルサーバの場合、カードの情報を入力させるのであれば、シビアにセキュリティを考える必要があります。
ただし、Webサーバぐらいであれば、80番ポートをあけ、FTPのパスワードを十分な長さにすれば、それでも結構安全です。
ただしFTPのパスワード認証については、アタックが比較的多いので、こちらは、接続元IPを制限するとかの対策が必要です。ポートとかも変えられたのかな？
で、そういう制限をしていれば、通常のサーバならまず大丈夫です。よっぽど狙われるような内容であったり、PVが多かったり、ID/PASS を知っている人が多くなければ。
ここにVPNを利用する意味はあまり感じません。
そしてレンタルサーバを借りていると、結構言われるのが、ホスティング会社は信用できるのですか？と。
もちろん、物理的に持ち出されたりすれば怖い事です。ただ僕はこの手の事件も聞いたことがありません。あとはサーバの廃棄の時の不安ぐらいです。
そもそも、そういう信頼まで問い始めたらキリがありません。どこかで必ず価格とサービスの妥協が必要なのです。
そんなことを言い始めたら、今に外国製のハードウェアだとどうなるかわかりませんよ。と言われかねません。
僕の管理するのはせいぜい中小企業のサーバであって、軍事情報ではありません。
そんなに危険を煽らなくても、価格とサービスのバランスで購入を決定します。
しかしありがちなのは、VPNだけじゃダメですよ、とか、サーバーの会社は本当に信頼できるんですか？とか、そういう脅し文句です。
VPNは運用が絡むので、セキュアの度合いは多少変化しますが、VPNの内容をキャプチャされたりだとかという話は聞いたことがありません。
もちろん平文については、本当に簡単に中身を見ることができてしまうので、それは危険だと思います。もちろんそれは社内でも同様です。
ただそれ以外については、少しセキュリティの対策を施せば意外にセキュアだと僕は思っています。
たとえばレンタルサーバの場合、カードの情報を入力させるのであれば、シビアにセキュリティを考える必要があります。
ただし、Webサーバぐらいであれば、80番ポートをあけ、FTPのパスワードを十分な長さにすれば、それでも結構安全です。
ただしFTPのパスワード認証については、アタックが比較的多いので、こちらは、接続元IPを制限するとかの対策が必要です。ポートとかも変えられたのかな？
で、そういう制限をしていれば、通常のサーバならまず大丈夫です。よっぽど狙われるような内容であったり、PVが多かったり、ID/PASS を知っている人が多くなければ。
ここにVPNを利用する意味はあまり感じません。
そしてレンタルサーバを借りていると、結構言われるのが、ホスティング会社は信用できるのですか？と。
もちろん、物理的に持ち出されたりすれば怖い事です。ただ僕はこの手の事件も聞いたことがありません。あとはサーバの廃棄の時の不安ぐらいです。
そもそも、そういう信頼まで問い始めたらキリがありません。どこかで必ず価格とサービスの妥協が必要なのです。
そんなことを言い始めたら、今に外国製のハードウェアだとどうなるかわかりませんよ。と言われかねません。
僕の管理するのはせいぜい中小企業のサーバであって、軍事情報ではありません。
そんなに危険を煽らなくても、価格とサービスのバランスで購入を決定します。
2007年11月13日
※時系列が変ですが、この記事を書いているのは2008年なので特に気にしないで下さい。
先日「メールでのトラブル」という記事を3回に分けて書きました。
そのままですが、僕がメールの内容について、配慮が足りなかったために関係をこじらせてしまいました。
それについて、非常に簡潔でわかりやすいコメントをいただきましたので、記事として書きたいと思います。
コメントの内容としては、確かにその通りで「指摘した事項についての説明が欲しかった」ということだと思います。
もちろん、このとき1〜2時間ぐらい打ち合わせをして、内容的な事、現状について十分に伝えたつもりではありました。しかしながら、口頭では誤解も生じるでしょうし、文章でしっかりと状況をつかみたかったのだと思います。
この点について、僕としてはこのとき非常に忙しいことがあって、ついつい説明がおろそかになってしまっていました。
そしてこちらの事情として、引っかき回される事への抵抗というのも確かにありました。
社内的な事情として
・稼働率の低下については極端に厳しい
・安価なコストの追求
・責任の範囲が広い
・運用の変更に対する人員の配置
それ以外にも
・現状について不満が無いこと
・おそらく価格とセキュリティがベストな状況になっているという自信
もちろん僕自身に原因があるので、転嫁するつもりは全くありません。ただ、稼働率については本当にシビアで、毎度のごとく胃が痛い思いをしていました。特にビジネスタイムのトラブルは許されませんでした。
そのほか責任の範囲が広いので、変更→配布→サポート という一連のサイクルをすべて自分で行う必要があります。特に設定変更については、非常に大きな労力が必要で、実質的に数日間は仕事になりません。なので、特に引っかき回される事については、必要以上にデリケートでした。
また、とてもびっくりした事で、なおかつ僕がうかつだったのが、「欲求が無いのに変更を求めてくる」ところでした。今まで必ず不満だとかがキッカケとなってサービスへの需要がありました。そして提案について合う部分と合わない部分をすりあわせつつ購入になるのが普通だと考えていました。
今回は終始一貫して、現状の環境に不満が無いことを伝えていました。不満があるのはあくまでアプリケーションについてであって、そのアプリケーションへのアクセス手段(ネットワーク構成)は全く不満がなかったのです。
しかしいきなりネットワークについてのメールだったのでビックリして、「そういった提案が必要ない理由」を説明してしまいました。これも問題でした。
ただ怖いのは、コレを教訓にして次は・・・としたいのですが、きっと次も同じようなミスをしそうです。
先日「メールでのトラブル」という記事を3回に分けて書きました。
そのままですが、僕がメールの内容について、配慮が足りなかったために関係をこじらせてしまいました。
それについて、非常に簡潔でわかりやすいコメントをいただきましたので、記事として書きたいと思います。
コメントの内容としては、確かにその通りで「指摘した事項についての説明が欲しかった」ということだと思います。
もちろん、このとき1〜2時間ぐらい打ち合わせをして、内容的な事、現状について十分に伝えたつもりではありました。しかしながら、口頭では誤解も生じるでしょうし、文章でしっかりと状況をつかみたかったのだと思います。
この点について、僕としてはこのとき非常に忙しいことがあって、ついつい説明がおろそかになってしまっていました。
そしてこちらの事情として、引っかき回される事への抵抗というのも確かにありました。
社内的な事情として
・稼働率の低下については極端に厳しい
・安価なコストの追求
・責任の範囲が広い
・運用の変更に対する人員の配置
それ以外にも
・現状について不満が無いこと
・おそらく価格とセキュリティがベストな状況になっているという自信
もちろん僕自身に原因があるので、転嫁するつもりは全くありません。ただ、稼働率については本当にシビアで、毎度のごとく胃が痛い思いをしていました。特にビジネスタイムのトラブルは許されませんでした。
そのほか責任の範囲が広いので、変更→配布→サポート という一連のサイクルをすべて自分で行う必要があります。特に設定変更については、非常に大きな労力が必要で、実質的に数日間は仕事になりません。なので、特に引っかき回される事については、必要以上にデリケートでした。
また、とてもびっくりした事で、なおかつ僕がうかつだったのが、「欲求が無いのに変更を求めてくる」ところでした。今まで必ず不満だとかがキッカケとなってサービスへの需要がありました。そして提案について合う部分と合わない部分をすりあわせつつ購入になるのが普通だと考えていました。
今回は終始一貫して、現状の環境に不満が無いことを伝えていました。不満があるのはあくまでアプリケーションについてであって、そのアプリケーションへのアクセス手段(ネットワーク構成)は全く不満がなかったのです。
しかしいきなりネットワークについてのメールだったのでビックリして、「そういった提案が必要ない理由」を説明してしまいました。これも問題でした。
ただ怖いのは、コレを教訓にして次は・・・としたいのですが、きっと次も同じようなミスをしそうです。
2007年11月12日
ずいぶん前の事ですが、VPSに関する記事を書きました。
『2007年06月27日：VPS サーバーの制限』
このときにコメントをいただきましたので、これについてフォローも含めて記事にしたいと思います。
さて、このときですが、某社のレンタルサーバから VPS サーバを借りていました。2社から借りていたのですが、僕としては Plesk が利用できること、価格が安いことを比較的重視していました。
このとき2社については、それぞれ別の案件でレンタルしたのですが、要件としてはほぼ同じです。ただし、少しでも信頼できるように1社を選んだ事、価格や柔軟性を重視して、1社を選らんだことは確かです。とは言っても、価格帯が同じなので、ほとんど差は無いと思っていました。
そして GM○ のサーバは痛い思いをしたので、避けました。
結果として、、、
ほとんど負荷のない状態にも関わらず、色々と制限にひっかかってしまいました。しかも高い方の会社のVPSがです。
おそらく、トラブルのほとんどがトラフィックだと思います。ですから、トラフィックに関わる部分について厳しい設定をしているのは理解できます。しかし負荷のない状態で制限にひっかかるのはちょっと困ります。
確かに意味不明でサーバーがトラブルになるようなことはありませんでした。でも運用はデリケートでした。
ちなみに Webarena も利用したことがあります。僕個人としては、GUIで設定できるPleskが無くても特に問題ないので、非常によかった記憶があります。
ただしメールアドレスの追加一つを考えても、知識が無いとできないことを考えると、会社では選択できないと思います。
ちなみにコメントを寄せて頂いた方も同じように制限にひっかかっているということでした。やっぱりちょっと厳しすぎるのかもしれませんね。
『2007年06月27日：VPS サーバーの制限』
このときにコメントをいただきましたので、これについてフォローも含めて記事にしたいと思います。
さて、このときですが、某社のレンタルサーバから VPS サーバを借りていました。2社から借りていたのですが、僕としては Plesk が利用できること、価格が安いことを比較的重視していました。
このとき2社については、それぞれ別の案件でレンタルしたのですが、要件としてはほぼ同じです。ただし、少しでも信頼できるように1社を選んだ事、価格や柔軟性を重視して、1社を選らんだことは確かです。とは言っても、価格帯が同じなので、ほとんど差は無いと思っていました。
そして GM○ のサーバは痛い思いをしたので、避けました。
結果として、、、
ほとんど負荷のない状態にも関わらず、色々と制限にひっかかってしまいました。しかも高い方の会社のVPSがです。
おそらく、トラブルのほとんどがトラフィックだと思います。ですから、トラフィックに関わる部分について厳しい設定をしているのは理解できます。しかし負荷のない状態で制限にひっかかるのはちょっと困ります。
確かに意味不明でサーバーがトラブルになるようなことはありませんでした。でも運用はデリケートでした。
ちなみに Webarena も利用したことがあります。僕個人としては、GUIで設定できるPleskが無くても特に問題ないので、非常によかった記憶があります。
ただしメールアドレスの追加一つを考えても、知識が無いとできないことを考えると、会社では選択できないと思います。
ちなみにコメントを寄せて頂いた方も同じように制限にひっかかっているということでした。やっぱりちょっと厳しすぎるのかもしれませんね。
2007年11月11日
仕事の関係でもそうですし、僕自身の趣味の事もあって、PC に関する本を読むことが多々あります。最近は知識もついてきたので、あまり初心者向けの本は買いませんが、中級程度の本などについてはたまに買います。
もちろんそれ以上に立ち読みもしています。
で、その時に "こういう本は買わない" というのをまとめておきたいと思います。
・字が大きい
・インストール方法から紹介されている
・画面キャプチャが多すぎる
・config が全文掲載されている
・仕組みについて書かれていない
・背景の記載が薄い
字が大きい本は、読みやすくわかりやすい事も多いのですが、それ以上にページを稼いでいるのかという疑問が出てしまいます。そしてページ数が増えれば、インパクトも価格も大きくなりますからね。
インストール方法から書かれている本が僕は大嫌いです。Windows にしても、Linux にしても、セットアップを実行するところや、.sh を叩くところなどは、基本的な部分だと思います。そこを解説する必要はまったくありません。
もちろん、インストール途中でしなければならない設定について、キャプチャとともに説明を書くのは大切な事です。"ようこそ" がいらないだけです。
上記に続き、キャプチャの多い本も嫌いです。読み飛ばす可能性が高くなってしまいますし、あまり意味が無いように思います。
もちろん、普段なかなか入手できないようなソフトウェアとか、ルータについてキャプチャがあるのは理解を深めます。逆に Apache だとかについては、あまりキャプチャが意味をなさないと思います。
config の過剰な掲載も嫌いです。特に linux 系のソフトウェアは config が非常に重要です。だからといって、すべてを掲載する事に意味はないと思います。もちろんこれについても、知識を深めるために、適度な量は必要です。しかしながら、全文は必要ありません。しかも行間なども、config 用に調整しないと、読みにくくなってしまいます。
もちろんプログラム系の本であれば、ソースをきれいに掲載するのは必要な事だと思います。
仕組みについて書かれていない本も非常に多くあります。たとえば apache などについて、その本の通り作業すれば Webサーバとしての機能は果たすかもしれません。しかしトラブルが起きたり、自分で設定を変更しようと思っても、結局はその仕組みとか背景を理解できていないので、できなくなってしまいます。
多少複雑な内容になったとしても、次につながるように書かれている本の方が好きです。
上記に関連し、技術的な背景の記載が無い場合もあります。特にネットワーク系の本は歴史的な背景を追うと、非常にわかりやすく、また次につながりやすいのですが、初心者に向けて書かれた本などによっては作業マニュアルになってしまっています。
ということで、上記のような本をさけつつ、いい本を探したいと思います。オライリーとかいいのかな？
もちろんそれ以上に立ち読みもしています。
で、その時に "こういう本は買わない" というのをまとめておきたいと思います。
・字が大きい
・インストール方法から紹介されている
・画面キャプチャが多すぎる
・config が全文掲載されている
・仕組みについて書かれていない
・背景の記載が薄い
字が大きい本は、読みやすくわかりやすい事も多いのですが、それ以上にページを稼いでいるのかという疑問が出てしまいます。そしてページ数が増えれば、インパクトも価格も大きくなりますからね。
インストール方法から書かれている本が僕は大嫌いです。Windows にしても、Linux にしても、セットアップを実行するところや、.sh を叩くところなどは、基本的な部分だと思います。そこを解説する必要はまったくありません。
もちろん、インストール途中でしなければならない設定について、キャプチャとともに説明を書くのは大切な事です。"ようこそ" がいらないだけです。
上記に続き、キャプチャの多い本も嫌いです。読み飛ばす可能性が高くなってしまいますし、あまり意味が無いように思います。
もちろん、普段なかなか入手できないようなソフトウェアとか、ルータについてキャプチャがあるのは理解を深めます。逆に Apache だとかについては、あまりキャプチャが意味をなさないと思います。
config の過剰な掲載も嫌いです。特に linux 系のソフトウェアは config が非常に重要です。だからといって、すべてを掲載する事に意味はないと思います。もちろんこれについても、知識を深めるために、適度な量は必要です。しかしながら、全文は必要ありません。しかも行間なども、config 用に調整しないと、読みにくくなってしまいます。
もちろんプログラム系の本であれば、ソースをきれいに掲載するのは必要な事だと思います。
仕組みについて書かれていない本も非常に多くあります。たとえば apache などについて、その本の通り作業すれば Webサーバとしての機能は果たすかもしれません。しかしトラブルが起きたり、自分で設定を変更しようと思っても、結局はその仕組みとか背景を理解できていないので、できなくなってしまいます。
多少複雑な内容になったとしても、次につながるように書かれている本の方が好きです。
上記に関連し、技術的な背景の記載が無い場合もあります。特にネットワーク系の本は歴史的な背景を追うと、非常にわかりやすく、また次につながりやすいのですが、初心者に向けて書かれた本などによっては作業マニュアルになってしまっています。
ということで、上記のような本をさけつつ、いい本を探したいと思います。オライリーとかいいのかな？
