全自動「3分」で実用的なバーチャルドメイン対応のメールサーバーを構築できるQMAIL2020を配布しています。cdb+tcpserver+qmail+SMTP AUTH+VPopMailと諸々のパッチ自動化 for FreeBSD
IT実践
3分でメールサーバー環境（qmail+VPopMail+SMTP AUTH他）を構築【for FreeBSD】
qmail-extra-patch-utmpx.patch
ICT実践記事
- PukiWikiのURLをNginxで正規化【index.php非表示】
10年以上ぶりにPukiWikiをいじっているんですが、昔の情報は豊富にありますが最近の情報が乏しいですね。 PukiWikiの全盛期は、Nginxが誕生したばかりでしたので仕方ないのかもしれませんが。 PukiWikiのindex.php無しでURLを統一する URLの正規化としてまず、 http://example.com/ http://www.example.com/ https://www.example.com/ これらをhttps://example.comに301リダイレクトしました。 これについては各所に載っているようにserverディレクティブを追加して、return 301～といった感じです。（ここでは詳細は割愛します） これで完璧！と思いつつGoogle Search Consoleを眺めているとindex.php有りと無しが…。 pukiwiki.ini.phpの設定でindex.phpを表示しないという項目があります。 // Shorten $script: Cut its file name (default: not cut) //$script_directory_index = ‘index.php’; コメントアウトを外して試してみましたが、何かが違う。 確かに表示はされなくなりました。 index.php有りの膨大なURLがすでにGoogleにインデックスされているので、index.php有りで404エラーになると困るのですが、結果はindex.phpを入れたURLでもちゃんとページが表示されました。 しかしindex.phpが表示されたままの状態。ステータスコードは200。index.php有りと無しの両方のページが存在した状態です。 ということでNginxの設定を変更しました。 server { if ($request_uri ~* “^(.*/)index\.php(.*)$”) { return 301 $1$2; } } 上記のようにdefault serverディレクティブに書き加えて、 nginx -s reload で完了です。 PukiWikiネタってまだ需要あるんでしょうか。 今回PukiWiki 1.5.2（utf8）をベースに以下のようなカスタマイズをしたのですが、要望があれば時間を見つけて記事 […]
- 自社・自宅サーバーをVPSに移行するための有力候補3サービス
ConoHa VPSがリニューアルされました。自社サーバーの移設先として使えそうなVPSサービスを実際に契約して試した結果を独自の視点から検証しました。
- Google AdSenseで広告が表示されたりされなかったり
ページ内に複数の広告がある場合には、広告コードの1行目にある<script>～</script>は1回で良いそうです。 ページ上に複数の広告コードがある場合、各広告ユニットに <script async src=”//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js”></script> を含める必要がありますか？ 非同期タグでしたので何も考えずに最後の方（</body>直前）に書いたのですが、どうやらそれが原因で広告が表示されたりされなかったりしていました。 プラグイン等の外部ファイルにAdSense表示部分が書かれている場合には、非同期での読み込みが間に合って表示されるようで、インラインで書かれている場合だけが不安定でした。 Nginx（Webサーバ）のFastCGI（キャッシュ）も影響していたようで、気が付くまでに時間がかかってしまいました。 <head>～</head>の間に記述して安定しました。 <head> ・ ・ ・ <script src=”https://ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.min.js”></script> <script async src=”//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js”></script> </head> ・ ・ ・ <ins class=”adsbygoogle” data-ad-client=”ca-pub-XXXXXXXXXXXXXXXX” data-ad-slot=”XXXXXXXXXX”></ins> <script> (adsbygoogle = window.adsbygoogle || []).push({}); </script>
- 最近トレンドなフィッシングメールをピックアップ
JALがフィッシングメールで騙され3億8000万円を失ったというニュースは記憶に新しいところです。 プレスリリースを送信すると、連絡先メールアドレスが複数のWebサイトに載ったままになるわけですが、あえてそのアドレスを削除せずにスパムメール収集に使っています。（未読が数万件に達していますが放置しています） その中でうっかり開いてしまいそうな要注意メールタイトルを紹介します。 メールアプリの設定でHTMLメール表示にしている方は、本物と区別がつきにくいので特に注意してください。またHTML表示の場合、開くだけでもトラブルに巻き込まれるものも存在しますので、できれば表示設定でテキスト形式にしておくことをお勧めします。 件名：Apple IDアカウントの情報を完成してください。 差出人：Apple ID <apple_support@0-99.com> Appleをご利用いただきありがとうございます。お客様のApple ID情報の一部分は不足、あるいは正しくないです。お客様のアカウント情報を保護するために、検証する必要があります。 <http://retrying-cloud-id.com/>リカバリアカウント 私たちは24時間以内にあなたからの応答を受信しない場合、アカウントがロックされます。 今後ともよろしくお願い致します。 Apple サポートセンター <http://retrying-cloud-id.com/>Apple ID | <http://retrying-cloud-id.com/>サポート | <http://retrying-cloud-id.com/>プライバシーポリシー Copyright 2017 Apple Distribution International, Hollyhill Industrial Estate, Hollyhill, Cork, Ireland. すべての権利を保有しております。 件名：警告！！パスワードの入力は数回間違いました。 差出人：Amazon Security <amazon_noreply@0-99.com> お客様はウェブサイトでAmazon IDにログインした時にパスワードの入力は数回間違いました。 日付と時間：2019年5月8 […]
- WordPressテーマXeory Extensionで同名のid属性が出力されるのを修整する
WordPress用のテーマXeory Extensionでトップページ表示用のfront-page.phpが、同じid属性の値（id=”front-contents-1″とid=”front-service-1″をそれぞれ複数）を持つ要素を出力してしまっているのを修正する方法。
- 【Google公認】reCAPTCHA v3のバッジ（ロゴ）をコピペで簡単に非表示
WordPressのContact Form 7に対応しているreCAPTCHAがv3になってから、バッジ（ロゴ）が邪魔な場所に表示されてしまうようになりました。 これはContact Form 7の問題ではなく、Googleが出力しています。 Googleにしてみれば謙虚に右下を選んだのかもしれませんが、右下は多くのサイトで「トップに戻る」アイコンが表示される大事な場所です。 （もっともGoogleがそれを知らないはずもないので、注目させたかったのでしょうか。） スタイルシートのposition: absolute; をJavaScriptで追加すれば好きな位置に移動できますが、親要素を変えられないのであまり実用的ではありません。 JavaScriptでgrecaptcha-badgeクラスをappendChildしてみたりしましたが、トークンの発行がうまくいかなくなったり不安定でしたので断念しました。 ネットで検索すると、海外でも多くの議論がされていました。 display: hidden; で非表示にしてしまうとスパム防止が効かなくなるそうです。 reCAPTCHA v3のバッジをGoogle公認の方法で非表示にする よく探せばGoogleのFAQにありました。 以下の表示をすればバッジを非表示にしても構わない This site is protected by reCAPTCHA and the Google <a href=”https://policies.google.com/privacy”>Privacy Policy</a> and <a href=”https://policies.google.com/terms”>Terms of Service</a> apply. コンタクトフォームを表示させるページごとに入れるのも面倒ですし、のちのち別のページにフォームを追加することになった時にはきっと忘れてしまっているので、コンタクトフォームの送信ボタン下に1行で書き込みました。 <p class=”recaptcha_policy”>This site is protected by reCAPTCHA and the Google<a href=”https://policie […]
- Apache 2.4でバーチャルホストを実際に運用する際の参考記事
Apache 2.4でバーチャルホスト設定をすると403 Forbinddedが表示される原因はディレクティブを見直してみましょう。実際に運用していくうえでディレクティブに毎回記述しないで良いための設定方法。
- 無観客で行われる小学校の運動会を複数カメラでライブ配信したい
無観客で開催されることになってしまった小学校の運動会。一所懸命な姿を家族に見てもらうために複数カメラを使ってライブ配信できないか、多くの制約の中で試行錯誤しています。
- Web開発や効率が良いブログ記事執筆の環境構築の参考に
Web開発やブログ記事の執筆で安定して使えるソフトウェアと画面配置を具体的に説明。効率を追求するプロならではの環境・レイアウトを参考に、今以上に使い勝手の良い環境構築にお役立てください。
- WordPressの新エディタGutenbergは待ち望んでいたUI
WordPress 5.0から採用された新エディタGutenbergですが、WP 5.2を導入して本格的に触ってみました。 ネット上の意見は賛否両論のようです。 （否定派が圧倒的に目につきますが、声を上げるのは決まって反対派が多数ですので…。） 追記：Classic Editorプラグインのダウンロード数（5,000,000以上）と評価を見る限り、以前のエディタの人気が伺えます。 NetCommonsのようなUI NetCommonsというCMSをご存知でしょうか。 今から10年以上前になるのですが、各学校で簡単にWebサイトを管理できるように、NetCommonsを使ったシステム提案を教育委員会に行った覚えがあります。（スルーされたと思っていたら翌年には似たようなシステムが導入されていましたが…） WordPressは「文章を書く」のに対して、NetCommonsは「ブロックを配置」するのに特化していたため、HTML知識が無い方でもコンテンツの書き換えや追加時に、それなりの見た目が維持できるという利点がありました。 複数の学校の先生がそれぞれの担当枠を書き換えたり、毎年担当者が変わるることを考えると、WordPressでは書く人によって、見た目に大きな差が出てしまうのです。 ページ更新・追加・削除のたびに数千円～数万円をWeb制作会社に支払って更新依頼するという形態は、現在は稀なケースだと思います。 WordPress等のCMSが主流になり、クライアント自身が好きなタイミングでコンテンツの更新を行うように移り変わりました。 ですが、制作時にどんなに頑張ってCSSを用意しておいても、更新する人が適切なHTMLタグやショートコードを使わなければ、素っ気ないページに仕上がってしまいます。 素っ気なさすぎるからと、ホームページビルダーで作ってHTMLを貼り付けたり、WordやExcelから貼り付けたり、スペースで文字を揃えたりと、なんだか悲惨なページになってしまったりもします。 更新者のスキルに左右されにくいブロックエディタ ブロックエディタの強みは、見栄えの良いページが直感的に作れるので、HTML・CSSを何も知らない人が更新やページの追加をしていっても、あまり酷い結果にはなりにくいという部分です。 私は制作時に、クライアントのWeb担当者スキルに合わせて管理 […]
- WordPressの引越しプラグイン『Duplicator』の正しい使い方
WordPressを使い慣れていて、ドメイン変更等も手動でsql置換して～とやった事がある方が「今回は楽にやってみたい」と、ナメてかかると意外とハマります。 ドキュメント読めば書いてあるんでしょうが、甘く見ているだけに慣れ親しんだ日本語ページをGoogleで探して斜め読みして取り掛かるものですからなおさら。 移転先サーバーにはWordPressをインストールしない。 これ重要です。 多くのサイトで「WordPressをインストールしておく」と書いてありますが、zipが解凍できなかったり、パーミッションの問題が発生したりと問題を引き起こします。 私もエラーが発生したので、サーバーコンソールでunzipのパス確認したり、installer.phpの該当部分を眺めてみたりしましたが、ディレクトリを削除するだけでOKでした。 新しいサーバーに設置するのは旧サーバーからダウンロードした2つだけ。 installer.php 20180000_XXXXXXX_archive.zip これだけの記事なんですけど、少し寂しいので他のポイントも挙げておきます。 installer.phpにアクセスする前にドキュメントルート（public_html等）を一旦707等にしておき、終わったら戻す。 nginxでキャッシュを使っている場合には止めておかないとハマる。 正常に動作することが確認できたらアップロードした2つ以外にも消しておいたほうが良さそうなファイル。 20180000_XXXXXXX_archive.zip installer.php database.sql installer-backup.php web.config installer-data.sql .htaccess （旧サイトで使用していた場合を除く） installer-log.txt Contact Form 7等でGoogleのreCAPTCHAを使っている場合などは「サイト所有者のエラー:サイトキーのドメインが無効です」と表示されていると思うので申請を忘れずに。 旧サイトへの301リダイレクト設定。
- FreeBSDのディスク容量を拡張する（ConoHa VPS）
ConoHa VPSでサーバーOSにFreeBSDを使っている場合のパーティション拡張方法です。
- 最近主流のPC用ディスプレイ解像度は？【過去10年間の推移】
Webコンテンツの適正画像サイズをディスプレイ解像度の利用者統計データを元に検証します。 ホームページに載せる適正画像サイズをデータで検証という記事から11年も経ってしまいましたので2018年版を載せました。 （StatCounterによる統計データを元にしています。） 2018年版が確定したのでデータおよびグラフを修正しました。 2019年版も（確定版ではありませんが）掲載しました。 Webコンテンツに使用する画像サイズ結論 掲載データが多くなってしまいましたので、結論を先に書いておきます。 パソコンのモニター幅いっぱいの可変サイズの画像（ヘッダ等）を想定するのであれば、(w)2,000ピクセルは必要。これくらいあれば(w)2,560ピクセルで表示したとしても耐えられるクオリティ。10年前に比べると回線環境は良くなったとはいえ、画像サイズが大きくなれば読み込みに時間がかかり、またスマホユーザーに無駄なデータ通信量を消費させてしまう。 記事に添える画像は300～800ピクセル程度のサムネイルを表示して、高解像度が必要であれば元画像にリンクを張る。 レスポンシブデザインの場合、表示サイズと同等にリサイズされた画像が表示される工夫が必要。（CSSにwidthを書いても元画像が同じであればデータ量は変わらず、w320のスマホユーザーにw2,000の画像を送り付けるという事態に。） jQueryで端末サイズに応じて読み込む画像を振り分けるのが今のところ良さげ。 下記のようなメディアクエリーを書いても読み込む画像が増えるだけで逆効果。 <img class=”w1920″ src=”../img_1920.png” /> <img class=”w480″ src=”../img_480.png” /> .w1920 { display: block !important; } .w480 { display: none !important; } @media only screen and (max-width: 480px) { .w1920 { display: none !important; } .w480 { display: block !important; } } 2018年ディスプレイ解像度利用者率Best10（世界） 1366 […]
- 緊急でリニューアルが必須なWebサイト
Webサイトが「スマホに対応していない」「SSLに対応していない」「Flashなどの古い技術を使用している」に該当していたら至急リニューアルを検討してください。
- Photoshopなんていらない！フォトショップを見据えた無料ペイントソフト
習得したスキルがAdobe Photoshopでも生かせそうな無料ペイントツールを、実際に使った独自の感想です。【小学校のパソコン講座にも導入しました】