投稿

3月, 2017の投稿を表示しています

メールサーバの移行

イメージ
 自前のメールサーバを停止 これまで、自ドメインのメールサーバはVPS上に構築していた。 ・Ubuntu Server ・Postfix ・Dovecot ・spamAssassinと、BlackListの利用 Spam対策を行ってきたし、サーバ上でメールをトリガーにして各種プログラムを動かしたりしてきた。 メールサーバのメンテナンスは結構面倒くさくて、  ・Disk容量のチェック  ・不正アクセスのチェック  ・各種セキュリティパッチの適用 など、手間がかかる。 そこで、外部のサーバを利用することに…。 結構安くて使い勝手の良さそうなのが、「さくらのメールボックス」 3年契約で、3070円とな…。  メールアドレスは自分のだけなので、20GBまで利用可能!  (Gmailより大きいねぇ) ということで、早速契約。 アカウント設定を行って、既存のDNSを書き換える。WHOISも書き換えて完了。 SMTPとIMAPが利用できればOK。 ちょうど、GoogleがSPF設定していないと受信しないし、DKIMおよびDMARCに対応していないメールを弾くようになったので、対応しているのを確認。 さくらサーバ自体は、これまでお客さんのサーバとして何件も利用しているので、利用方法も難しくはない。  Webメールにも対応しているので、いざという場合にもありがたい。 ということで、各メールソフトの設定を変更。  PC(常時使用する3台)とタブレット、スマートフォンと台数は多いがそれ程手間はかからない。 問題は、旧サーバで送受信したメールの履歴だけれど、これはThunderbrdを使ってローカルに保存することで回避。  本当は、サーバtoサーバでMailboxに残そうとも考えたんだけど、古いメールはそれ程必要ないし、ローカルにバックアップしてあれば凌げるので、良しとする。 移行時にDNSの反映で若干時間がかかったものの、問題なく送受信できるのを確認して、作業完了。  これでメンテナンスの手間が減るので、安いもんです。

UTF8の指定ではまった

MariaDB+PHPにて PHPでDB上のデータを大量に処理するプログラムを書いていて、おかしな現象に出くわした。 1万件+42万件+43万件のjoinで、必要なもののみ取り出して、updateをかけるという手作業ではやる気にならない処理なので、サクッと書いてぶん回すしかない…。 ローカルでmysqlモニタを使用してSQLを叩くと、問題なく結果が返ってくる。 でもって、サーバ上で実行すると、結果がEmpty…。 あれれ? 試しに、phpmyadmin上でSQLだけ叩いてみる。 ローカルと同じ結果になる。 何かがおかしい。  :  : $mysqli = new mysqli("localhost",$username,$password); if($mysqli->connect_error){   print('<p>データベースへの接続に失敗しました</p>'.$mysqli->connect_error);   exit(); } $mysqli->select_db($dbname); $mysqli->set_charset("utf-8"); $sql="SELECT bill.bill_id,bill_item.bill_item_id,bill_item_detail.bill_item_detail_id,              bill.billing_id,bill.bill_month,bill.bill_date,bill.deposit_receive_date   FROM `bill_item_detail`   join bill_item on bill_item_detail.bill_item_id=bill_item.bill_item_id   join bill on bill.bill_id=bill_item.bill_id   WHERE `bill_item_detail`.`name` LIKE '繰越残高' AND  :  :   order by bill.bill_date"; $result = $m

404エラーが多発?

イメージ
Google Search Consoleからメールが来た 今度は、なりすましではなく…。 本家からエラーが急に出ているよと報告のメールが届いた。 特に、外部へのリンクは多く張らないようにしているし、急に増えるというのが解せない。 何か、トラブルが起きたのか? ということで、エラーの内容を確認してみる。 Search Consoleで確認 とりあえず、どのリンクでエラーが出ているのかを見てみると、 2013_03_null_archives.html とか、2015_04_null_archives.html という日付のアーカイブ?なのか、null_archivesなので、アーカイブでないのか良くわからないリンクへのエラーが大量に発生。 図は、すでに該当のリンクを全て「修正済とする」と指定した直後。 2017/02/05に初めて1件のエラーが出ているが、これは上記に残っているアタックと思われるアドレス。 大量に発生しているのは3月に入ってからで、10日以降にドンと発生している。 これらのリンクとして考えられるのは、レイアウト情報にあるガジェットの「ブログアーカイブ」くらいしかない。 過去の記事を、年月指定で見に行くガジェットで、別に自作したものではない。 Google謹製なので、自前のツールでエラーが出ているとしか思えない。 多分、時間と共に収束するのかもしれないが、気持ちが悪い。 まず、修正済にして様子を見てみるしか、現時点では手がない。 海外でも、同様のメールが届いたが、何をすればよいか?という書き込みを見つけたが、公式の案内に書かれている事以外、特に解決策らしきものはなさそうだ。 これでも、同じように404エラーを吐くのであれば、robots.txtにエラーとなるURLをすべて書き込むしか解決方法はなさそう…。 面倒なので、ちゃんとクロールするようにしてくれるのが嬉しいのだが…。

LINE乗っ取りにまんまとヤラれてしまった

イメージ
事の顛末 朝から少々面倒なデータ編集作業と、コード書きをしていて…。 頭が疲れてきたので、通常のメールの確認と、迷惑メール内のチェックをしてました…。 で、普段なら軽々しく信用しないのですが… で、以下がそのメール本文。 差出人は軽くチェックし、画面へ遷移。 いつもなら、URLも確認するんだけど…。 これが、その画面。 まあ、ログインして確認しておこうと、ログインしたのですが…。 で、さっくり乗っ取られて…。 ぐはぁ…と。 素人同然のことをやってしまいました。 疲れた脳味噌は判断力を低下させてくれるようです。 あちこちから、お電話もらいました。 絶対にヤラれているわ…とか、おかしいと思った…、とか。 連絡しようにも、LINE自体が使えないので、電話しか…。 ということで、本当に申し訳ないことをしました。 LINEのメッセージを信じて被害に遭わないことを祈って・・・。 本当にご迷惑をお掛けしました。 LINEには、乗っ取りの連絡をしてあるので、何時間かで収束するとは思うのですが…。