qmailを停止した状態で以下のコマンドを実行します。
echo /var/qmail/queue/*/*/* | xargs rm
-Rオプションなどでqueue配下のディレクトリまで削除してしまうと、整合性が保たれずに面倒なことになりますのでご注意ください。
qmailを停止した状態で以下のコマンドを実行します。
echo /var/qmail/queue/*/*/* | xargs rm
-Rオプションなどでqueue配下のディレクトリまで削除してしまうと、整合性が保たれずに面倒なことになりますのでご注意ください。
Apache 2.4でバーチャルホストを実際に運用する際の参考記事
WordPressの新エディタGutenbergは待ち望んでいたUI
VMware Workstation Player 仮想マシンの複製【簡単3ステップ】
WordPressでメディアをアップロードできない
Google Ad Grantsで支払情報を求められてしまう
Windows 10 April 2018(1803)の不具合【前編】
常時SSL証明書の更新エラー対処法
サーバーのバックアップで過去18年間に遭遇した問題点
小中学校「1人1台タブレット」いよいよ導入【豊後高田市】
WordPressテーマXeory Extensionのナビメニューを修整する
シルバーハッカー世代がやってくる。時代はVGA。
WordPress管理画面のユーザー一覧をソート可能な任意の項目にする
最近SSL化したサイトで旧サイト(http)へのアクセスが一向に減らないという現象が発生しました。 httpへのアクセスを301リダイレクトでhttpsへ遷移。 Google Search Consoleのプロパティにhttpsサイトを追加。旧サイトも削除せずに監視。 これで安心してしまっていたのですが、1ヶ月経っても、Google Search Consoleで旧サイト(http)の表示回数が減らない。(一時的に減少しましたが、盛り返してきている)平均掲載順位に至っては上昇している。 どうもおかしいと思い調べたところ、もともとHTTPヘッダとしてcanonical属性を出力していたのですが、スキンをカスタマイズした際に書き出されなくなってしまっていたようです。 これはChromeのデベロッパーツールを使って以下のように確認しました。 HTTPレスポンスヘッダ・リクエストヘッダの確認方法 Chromeを開き[F12]を押してデベロッパーツールを開く。 Networkタブを選択しておく。 HTTPヘッダを確認したいページを開く。 Nameの一番上(AdSense等がある場合は2番目以降になっている場合があります)にある該当ページをクリックする。 Headersタブをクリックするとレスポンスヘッダやリクエストヘッダが確認できます。 全てのページで<link rel=”canonical” href=”ページURL”>を<head>~</head>内に出力するように修正して完了です。 ※ページURLには各ページのURLを正確に書きます。
WordPress用のテーマXeory Extensionでトップページ表示用のfront-page.phpが、同じid属性の値(id=”front-contents-1″とid=”front-service-1″をそれぞれ複数)を持つ要素を出力してしまっているのを修正する方法。
紺屋の白袴とでもいいましょうか、いろいろと問題の多いOneToneというWordPressテーマを当コンテンツでは使用しています。 一般的なサイトでの使用はおすすめしません。 私がOneToneを選んだ主な理由 このテーマを使う以前は、ホームページ全面にFlashを多用したコンテンツとなっていて、早急な改善の必要性に迫られていた。 海外のWordPressテーマサイトで上位にランキングされていた。 OneToneのインパクトが強く一目惚れしてしまった。 SEOで検索結果上位を狙う気はあまりなかった。 コンテンツ移行に(サーバー移行も含めて)1時間程度しか掛けたくなかった。 また自社サイトでしかできない、お客様には提案できないような(爆弾を抱えた)テーマを試してみたかったという部分も大きいです。 悪い点 独自に作りこまれているためカスタマイズがしにくい。 プラグインも必要となり、ページ読み込み速度が遅い。 ランディングページ向きに設計されていて、WordPressのページという概念がほとんどない。 タグが微妙(h2タグがフッタータイトル等)でSEOに弱い。 英文フォント仕様なので、スタイルシートの変更が結構必要。 トップ動画等に一部不具合あり。 良い点 見た目のカッコよさ。 基本的に1カラムのレスポンシブなので、PCとスマホで同じイメージを提供できる。 jQuery盛りだくさんで、昔ホームページビルダーで「アニメーションgifで画像が動く」「音楽が流れる」というコンテンツを好んで作られていた方には受けが良いかもしれません。 時代に逆行している感は否めませんが、もうしばらくOneToneを少しずつカスタマイズして使ってみようと思います。 まずはフッター周りですね。 「関連サービス」 「リリース」 「障害情報」 で検索エンジンに働きかけても意味ないですし。
インデックス登録されましたが、サイトマップに送信していません Google Search Consoleのカバレッジで緑色の有効(インデックスに登録されている)になっているものの、「インデックス登録されましたが、サイトマップに送信していません」という詳細情報が気になりました。 クリックしてみると「例」としてURL一覧が表示されます。 そのURLをさらにクリックすると、UTF-8でエンコードされたURLが表示されます。 送信しているXMLサイトマップもUTF-8でエンコードをしていますし、URLの正規化も済んでいるのになぜ? じっくりと見比べてみると、XMLサイトマップのURLはスラッシュが「%2F」にパーセントエンコーディングされているのに対して、Googleでは「/」のままです。 サイトマップを出力しているphpソースを見てみると、PATH_INFOをrawurlencodeでエンコードしています。 rawurlencodeはRFC3986にもとづいて「-_.~」とアルファベット以外をすべてエンコードするようですので妥当なはずです。 Google独自仕様?と思ったのですが、RFC3986の3.4章に「スラッシュ (“/”) と疑問符 (“?”) の文字はパーセントエンコーディングする事を避けるほうがユーザビリティのためにはよい。」という記述がありました。 スラッシュはパーセントエンコードしないように修正 GoogleもRFCもスラッシュはパーセントエンコードしないと提唱しているのであれば、これに合わせるべきだと思い以下のように修正しました。 $r_page = rawurlencode($page); $r_page = str_replace(‘%2F’, ‘/’, $r_page); 修正後、XMLサイトマップの出力とGoogle Search ConsoleのURLを比較するとマッチしていましたので、これで解決です。
公開しているメールアドレスは、最近トレンドなフィッシングメールをピックアップで紹介したように、フィッシングメールが毎日山ほど届きます。せっかくなので訪問してみました。 フィッシングサイトに嵌ってみました 最近のブラウザはデフォルト設定で注意喚起してくれます。 Chromeの場合 Firefoxの場合 Firefoxのほうがキッパリと言い切っていてかっこいいですね。 どのブラウザも、うっかり誤クリックで進んでしまわないように「無視して進む」というボタンが無いインターフェイスになってますが、頑張って先に進んでみました。 仮想PC・ブラウザをプライベートモード・LAN切り離し・IPアドレス変更等を行ったうえでの検証です。アクセスするだけで様々な情報を抜かれる恐れがありますので、安易に先に進むようなことはしないようにしてください。 APPLEっぽいサイトが表示されました。 一見APPLE公式のように見えますが、中央の入力フォーム以外はリンクすらされていない張りぼてです。 ですが疑いの目を持って見ない限り、偽サイトだということに気づかないと思います。 フィッシングサイトの見抜き方 騙されないためにはアドレスバーに表示されているURLをよく見てください。まずこの習慣をつけましょう。 見るのは最初に現れるスラッシュ「/」よりも左側です。それよりも後(右側)は一切気にしないで大丈夫です。 http://cert-protection-account-appleid-apple.com ブラウザによっては cert-protection-account-appleid-apple.com とhttp://(またはhttps://)が省略されて表示されます。 以下のような場合にはさらに注意が必要です。 apple.example.com/rmd_nid_vcss… google.example.com/rmd_nid_vcss… ドメイン名「example.com」の前にドット「.」が入っている場合、それより左側はドメインの保有者が自由に好きな文字を設定できるサブドメインと呼ばれます。 一番最初に知っている名前が入っているからといって絶対に信用してはいけません。 itunes.apple.com これはitunesがサブドメインですが、その右側を見るとドメイン名がapple. […]
Apache 2.4でバーチャルホスト設定をすると403 Forbinddedが表示される原因はディレクティブを見直してみましょう。実際に運用していくうえでディレクティブに毎回記述しないで良いための設定方法。
Zoomに代わるオンライン会議ツールを無料で公開しています。 登録不要でブラウザからもすぐに利用できますので検証としてご活用ください。
ページ内に複数の広告がある場合には、広告コードの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>
サーバーを運用してきた18年間に遭遇したバックアップ・リストアの具体的な問題と改善策をまとめてあります。
大分県豊後高田市の小中学生に、1人1台導入されるタブレットについて概要を独自にまとめました。
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 […]
ConoHa VPSがリニューアルされました。自社サーバーの移設先として使えそうなVPSサービスを実際に契約して試した結果を独自の視点から検証しました。
Let’s Encryptから「証明書の期間があと20日で切れますよ」という英文メールが届きました。 cronで定期的にrenewをかけて自動更新しているのですが、何か設定がおかしいのかなと思い、複数のssl証明書を管理しているサーバにログインをしてみました。 原因が良くわからなかったので、該当ドメインを登録し直すために現在の更新情報ファイルを削除しました。 rm /usr/local/etc/letsencrypt/renewal/DOMAIN.conf 上記が正しいコマンドですが、深夜のせいか使い慣れないマウスのせいか、 rm /usr/local/etc/letsencrypt/renewal ん?ディレクトリだから消せないよと英文メッセージ。 confなのにディレクトリなのか。と深く考えもせずRオプション追加。 rm -R /usr/local/etc/letsencrypt/renewal ( ̄▽ ̄||| … Enter押して1秒後に気付きました。 renewalディレクトリごと消してしまった…。 全てのドメインのssl更新ファイルが消失しました。 Unix系のOSにはWindowsのようなゴミ箱はありません。 復旧ツールもあるみたいですが、稼働中サーバにいきなり入れてみるのも気が引けたので、潔くあきらめて手動で復旧させる事にしました。 私の環境では/usr/local/etc/letsencryptですが、/etc/letsencryptの場合も多いようですので、読み替えてください。 またcertbotコマンドはcertbot-autoになっているようですので、そのあたりも読み替えてください。 Let’s Encryptの登録をやり直す ドメインごとの情報ファイルを削除 以下を消します。 /usr/local/etc/letsencrypt/live/DOMAIN_DIR /usr/local/etc/letsencrypt/renewal/DOMAIN.conf /usr/local/etc/letsencrypt/archive/DOMAIN_DIR ここでも注意。 ※真似るな危険! ↓↓↓ rm -r /usr/local/etc/letsencrypt/archive DOMAIN_DIR として、今度はarchiveディレクトリまで消 […]
ConoHa VPSが2020年1月29日からSSD容量と料金が改訂されましたが、放っておいても既存のサーバーには適用されません。 適用させるには以下の手順が必要になります。 旧サーバー停止 ※自動バックアップを設定している場合には不要 旧サーバーのイメージ保存 ※自動バックアップを設定している場合には不要 新サーバー追加(保存イメージから) 旧サーバー削除 これで新契約の内容となります。 料金が重複してしまうのではと思い、問い合わせをしてみたところ以下のような回答をいただきました。 ConoHaのサービスについては1時間毎の課金となりますので 料金についてはご任意のタイミングで削除し1時間後に新たに サーバーを追加することで料金の重複は発生しないものとなります。 1時間毎の課金ですが、上限を超えると固定(1か月料金)となるため、その場合は「旧サーバーの1か月分+新サーバーの時間課金」になると思われます。 新サーバー追加後すぐに旧サーバーを削除すれば、多くても5日分増える程度ですね。 契約自体は上記で移行されますが、SSD容量が50G → 100Gになったとしても、パーティション操作等をしなければ意味がありません。 また、IPアドレスが変更になるためネームサーバーのIPアドレス変更も必要になります。 FreeBSDのパーティション拡張については下記の記事をご参照ください。 https://www.ii-sys.jp/notes/2211
数か月くらい前に取得して製作途中だったサイトが、いつからかアクセスできなくなっていました。 アクセスできない問題の切り分け サーバーの確認 IPアドレスを指定したsshやsftpなどではサーバーへアクセスできました。 Webサーバー(Nginx)の確認 正常に動作していた時から設定を変更していませんが、念のため見直しました。問題なさそうです。 DNSの動作確認 $ host my.domain Host my.domain not found: 3(NXDOMAIN) DNSの設定に問題がありそうですが、少し前までは正常に引けていて、それ以降設定は変更していません。 $ ping my.domain PING my.domain.work(xxx.xxx.xxx.xxx): 56 data bytes 正引きできないのに、設定した覚えがないホストに向かっています。(xxx.xxx.xxx.xxxは心当たりがないIPアドレス) そもそもドメインの最後にworkがついているのは何故…。 resolv.confを書き換えてみたり、hostsに書き込んでみたり、別のDNSサーバーに設定を移してみたり、半日格闘しましたが解決せず。 レジストラ(Value Domain)に問い合わせ Value Domainの問い合わせフォームにチャットでの問い合わせがあったので、初めてクリックしてみました。 運が良かったのだと思いますが、待ち時間6秒! 非常に手際よくドメインの状態を調べてくれて、2分後には的確な回答をいただきました。 (06:55:30) *** MYNAME joined the chat *** (06:55:30) MYNAME: ドメインが参照できません(DNS) (06:55:34) ※自動メッセージ: お問い合わせありがとうございます。只今込み合っております。お急ぎの場合はフォームよりお問い合わせいただきますようお願い申しあげます。 (06:55:36) *** Chat Support joined the chat *** (06:55:39) Chat Support: お問合せありがとうございます。担当の 【***】 と申します。 どうぞ、よろしくお願いいたします。 (06:55:44) MYNAME: よろしくお願いいたします。 (06:55:4 […]
