#author("2020-06-01T22:43:26+09:00","","") [[RightBar]]~ [[サーバ管理業務日誌一冊目>RightBar/サーバ管理業務日誌]] *サーバ管理業務日誌 [#b0b1255a] #contents * 2017 [#qeb4132d] ** 2017-1-24 [#wa6576d2] *** [[スパム関連日誌の集約>RightBar/スパム対策業務日誌]] [#w23b1230] - 年明け以降、スパム対策とその記録が肥大化しているため別ページ化 ** 2017-2-4 [#e4cfcdac] *** 404 Not Found用ページ作成 [#q99f19f1] - 本サイトはwikiベースで構築しているため、直接ファイルを叩こうとするのはだいたいロボットかスパムである -- が、念のため404(ファイルがみつかりません)対策を実施する - 通常は自動生成のHTMLが表示されるのだが、それでは味気ないためwiki内に404用ページを作成し、存在しないページにアクセスしようとしたものを誘導 -- [[【404_Not_Found】>404_Not_Found]]作成、ページ凍結 -- .htaccessに下記を追記 ErrorDocument 404 http://bladeandgrenade.sakura.ne.jp/index.php?404_Not_Found -- ミス、これだとHTTPのステータスコードがおかしくなる。下記に修正 ErrorDocument 404 /index.php?404_Not_Found - 結果としてスパムさんを呼び込む結果になった場合は削除する ** 2017-2-6 [#wea536bf] *** googleによるウェブサイトの品質の評価方法改善の影響 [#s17f21d7] - 先日、googleにて[[【ウェブサイトの評価方法が変更された】>https://webmaster-ja.googleblog.com/2017/02/for-better-japanese-search-quality.html]] -- 一説によれば、先のキュレーションサイト騒ぎ(コピペ記事量産でアクセス稼いで荒稼ぎするビジネスモデル)により、その手の低品質サイトを検索結果から排除するための変更だという - 念のため、当サイトへの影響を大雑把に確認しようという試みである -- さすがに検索でぜんぜんヒットしないレベルだと新人が来ないで限界集落化して滅びるから…… - というわけで「アーマードコア」とか「AC攻略」とかで雑に検索した -- 「AC」の文言が入るとだいたいアーケード関係に飛ぶ。これは諦める -- 以前は低いランクながらも出ていた「アーマードコア」の検索結果から当サイトが排除されている模様 - 結論:当サイト、googleから低品質と評価される どうしたらいいんですかねこれ!? ** 2017-6-24 [#p44a8ed9] *** 整形済みテキスト表示時のレイアウト崩れ対策 [#i64d34b0] - pukiwikiの機能で整形済みテキストというのがある --要はwikiルールによらず、書いたままに表示するための機能。例えば [[表示を変更したリンクの書き方。これはトップページへのリンク >FrontPage]] のように、通常はシステムに読み込まれるコードを表示したい際などに使う - で、よく私がジョークで使っているAA表示プラグインもこの機能を使っているのだが、書いたまま表示する機能のため右バーに普通にオーバーレイされてしまうことに気付いた -- 荒らしに使えるやんけ - というわけでpukiwiki_gs2.ini.phpの設定を変更 -- PKWK_SKIN_GS2_OVERFLOW_AUTOの設定を有効化 - 整形済みテキストの横サイズが大きいと横スクロールバーが生えるようになりました * 2018 [#sf57de9b] ** 2018-5-17 [#yaad4345] *** Blade & Grenade SSL/TLS対応状況について(技術日誌版) [#f9252782] - そもそもSSL/TLSって何? -- wikipedia見てください -- まぁ通信を安全にする仕組みで、有効になってるとWebサイトアクセス時にURLの先頭が''「https」''になる程度の理解でオッケーです -- 本文中の''「https」「SSL」''はだいたい似たような意味だと思ってください - 経緯 -- 2018-5-13 Chrome v68 から各種サイトへのアクセスがSSL接続じゃないと警告を出すようになるとの情報を得る(気づくの遅い) --- Googleがhttps接続を推奨しているため、各ブラウザが軒並みアクセスにうるさくなっている -- 2018-5-14 SSL/TLS対応について各種テスト実施、サイトトップ及びTwitterに報告文を掲載 B&Gはサイト立ち上げ速度の優先、レガシー環境への配慮から これまでSSL/TLS未対応(httpでのアクセスのみ)で運用されていました。 しかしながら、GoogleのSSL/TLS対応推奨、各種ブラウザの警告強化を鑑み、 本日SSL機能の有効化を実施いたしました。 本事項を確認された皆様は B&G へ https でのアクセスが可能かを確認し、 可能な場合はブックマーク等の変更を推奨します。 - SSL/TLS対応について -- さくらインターネットのレンタルサーバは初期ドメイン(sakura.ne.jp)を使っている場合、さくらの共有SSLを利用できるため有効化を実施 --- 実験棟にて各種テスト、既存のhttpでのアクセス、プラグイン対応状況確認、混在環境の確認等を実施 - 確認している不具合、対策 -- サイト中にhttpにてリンクされたコンテンツがあるとブラウザが警告を出すことを確認 ++ youtube.inc.php及びyoutubeauto.inc.phpについて、生成されるURLがhttpであることを確認 --- プラグインの修正を実施 ++ ニコニコ動画プラグインについても同様の事象を確認 --- コードがyoutubeプラグインより複雑なため現在対応検討中 ++ B&G画像アップローダの画像について、httpにてリンクを張る運用のため本事象に該当することを確認 --- リンクをhttpsにて修正することで解消することを確認 ++ 一部Amazon広告について、デフォルトで生成される画像の一部がhttpリンクとなっていることを確認 --- 確認できる限りのAmazonリンクを修正 *** インフォメーション B&G 画像アップローダからのリンクについて [#y7f1445d] - 既存環境ではアップローダに画像をアップロード後、http://~形式でリンクを張っている -- こちらを編集にてhttpsに修正することでブラウザからの警告を解消可能 -- ある程度高性能なエディタを用意し、編集内容をコピペし一括変換するのが現実的かと思われる --- 「http」→「https」で変換すると「httpss」とかになっちゃうと思うので、「http:」→「https:」と変換するといいかなと --- 実施する際は文字コードの混在に注意 ** 2018-12-14 [#f7a325d9] *** 削除したページの復旧方法について [#d339f8b8] - wikiの各ページはユーザが好きに編集できるのが売りである -- ということはオペレーションミスや悪意のあるユーザによって意図せずページが削除されることがある - では、ミスして消えたページは元に戻せるのか。謎の敵に消されたページは復活できるのか -- できる、できるのだ! - wikiのページはページ名で管理されていて、編集履歴が付いてくる -- ということは【[[RecentDeleted]]】から削除されたページの一覧に飛び、各ページ名の右にある小さい「?」を押すことでそのページの編集モードにして差分を漁ることで復旧可能なのだ! - みなも「あわてず・騒がず・騙されず・チェックを欠かさず」の「あ・さ・だ・ち」の精神で編集して欲しい * 2020 [#a1e1ab47] ** 2020-5-11 [#o1ed520c] *** Amazon広告の表示異常検証 [#gc5f685c] -数日前に気付いたのだがAmazonの広告表示が破綻しているように見える -端的に言うと画像型広告は問題ないが、検索型広告が内容表示されていない -下記手順で検証を実施 --実験用ページにていくつかの広告の表示テストをして正常・異常でパターン確認 --表示が破綻している広告から傾向確認 ---問題個所をサーチウィジェットに絞り込み --サーチウィジェットで表示正常・異常の差異があることから検証 ---本来の検索文字列が英単語のみの物は正常表示 ---本来の検索文字列に日本語や半角スペースが入る物は表示異常 ---上記より、検索文字列がURLエンコードされてると思われる --Amazonで広告再生成、事象再発を確認 --Amazonサーチウィジェットのバグと判断 -おそらくサーチウィジェットの検索窓にて、入力文字列をURLエンコードしてしまうバグが発生しているが、Amazon内部では通常の文字列として検索を実行した結果、表示が異常になると思われる。 -ユーザサイドには対応できないため様子見 ** 2020-6-1 [#b1eb1742] *** トップページ(whiteboard)表示崩れ [#e29fd772] -すでに検証済み・ユーザによる対応済みの問題なのだが、記録を取らないと後でチェックできないので書く --と思ったがめんどうくせぇー!ラウンジのやり取りべた張りします -ユーザによる指摘 -なんか上のインフォメーションの画像の余白が広がって文字も見切れてるんだけど自分だけ? -- 2020-05-30 (土) 21:52:17 -同じく>上のインフォメーション -- 2020-05-30 (土) 22:03:34 -幾つかの画像サイズ変更が効かなくなって死んでますね・・・ -- 2020-05-30 (土) 22:11:43 -本当だ、ウチもother欄の画像だけやたらデカくなってるわ -- 2020-05-30 (土) 22:23:00 -調査・検証 -(室長)偶然見てたんで検証した -- 2020-05-30 (土) 22:43:01 -(室長)インフォメーション欄は画像をリンク化してあるのだが、各画像を30%サイズで表示するようwiki上記述してあった。一部のみ効いていない -- 2020-05-30 (土) 22:44:17 -(室長)画像縮小が機能しているのは画像をページに添付しているタイプ。ダメなのはアップローダに張ったのを直で呼んでるタイプ -- 2020-05-30 (土) 22:45:11 -(室長)アップローダから引っ張るのはフルパスなのでhttps://~で記述してある。生成されたhtmlを確認したらサイズ指定が付いていない -- 2020-05-30 (土) 22:48:44 -(室長)pukiwikiのバージョンは変えていないので可能性1はレンタルサーバのphpバージョンが変わった。調べたら変わっていないのでこれは違う -- 2020-05-30 (土) 22:49:53 -(室長)可能性2はsshが悪いことしているので試しにhttp://~でプレビュー。なおった。なので容疑者はsshかブラウザ側の謎の仕様変更 -- 2020-05-30 (土) 22:51:10 -(室長)おそらくフルパス指定で元画像のサイズ情報が取れなくなっている。そのため%指定のサイズ変更が効かなくなっている。理由は知らぬ。というか前にもこれ似た事象の対策した記憶あるぞおい -- 2020-05-30 (土) 22:52:35 -(室長)解決案1 アップローダの画像をページに添付してそこから引っ張るようにする -- 2020-05-30 (土) 22:54:54 -(室長)解決案2 画像サイズ指定を%ではなくwidth/heightで決め打ちする。ちなみに生成データみたらwidth="123" height="73"だった -- 2020-05-30 (土) 22:56:15 -(室長)さすがにこれ直すのワイじゃなくてもできると思うので誰かやって欲しいが、どうしても無理だったら明日当たりワイがやります。ほな・・・(スゥー -- 2020-05-30 (土) 22:57:16 -ユーザによる対応 -ようはページ内の%を全部123/73に置き換えたらええんやな!簡単やないけ!(大惨事の先触れの音) -- 2020-05-30 (土) 23:40:18 -編集の手引き先に読もう!? -- 2020-05-30 (土) 23:54:36 -よっしゃちょっと試してくる -- 2020-05-30 (土) 23:55:03 -どう?治った? -- 2020-05-30 (土) 23:58:37 -同時に平行して俺含めて複数人がやってたらしい、更新衝突が起きてるな。こっちは直ってるよ -- 2020-05-30 (土) 23:59:47 -変なとこ弄るの怖いからhttpsってやつの%だけ123x73に変更した >23:40:18 惜しいんだけどなー -- 2020-05-31 (日) 00:00:50