#author("2020-11-08T04:07:07+09:00","","")
#author("2020-11-09T00:22:46+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
 -（室長）解決案１　アップローダの画像をページに添付してそこから引っ張るようにする　 --  2020-05-30 (土) 22:54:54
 -（室長）解決案２　画像サイズ指定を％ではなく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

** 2020-11-8 [#y7ac0358]
*** httpからhttpsへの自動転送について [#c359f2c5]
- さすがにレガシー環境からのアクセスはもうねーだろ
-- 上記の判断からhttpアクセスを本格的に排除することにしました
- 今後はhttpでアクセスしようとするとhttpsサイトへ自動転送されます
-- 備えよう
*** 案の定影響が出た [#x8a36ed9]
- ユーザとのやりとり
 - なんか急にこのサイトがセキュリティに引っ掛かった・・・なぜだ・・・？ --  2020-11-08 (日) 11:15:31
 - 今日からサイト全体がh ttpからh ttpsに移行になって、h ttpでアクセスした場合自動的にh ttpsのサイトに飛ばされるようになったからじゃないかな、素人考えだけど自動的に別サイトの飛ぶという部分で引っかかったと思われ、知らんけど --  2020-11-08 (日) 11:23:23
 - tps対応は大分前にやったよと言ってた気がするけど移行したのって今日からなの？ --  2020-11-08 (日) 13:07:54
 - 今まではどっちでも接続♂できたが、興からはtpsのみになる。そういうことだ --  2020-11-08 (日) 13:11:29
 - 俺もそう思ってブクマのURL変えてみたけどPCからアクセスッ！できないん。やはり難民は悪・・・ --  2020-11-08 (日) 15:59:05
 - 同期してる携帯の方のブクマからだと入れる。これが、これが選民思想・・・ --  2020-11-08 (日) 16:03:21
 - スマホからブクマで入ると別タブで開かれていくのん…　やはり増殖する難民は間引かねば… --  2020-11-08 (日) 16:11:54
 - （室長）室長マンです。アドレスの頭にwwwが入ってると警告が出る可能性があります。削れ --  2020-11-08 (日) 18:47:23
 - （室長）それで解決する/解決しないの結果いただいたら設定見直すんでオナシャス --  2020-11-08 (日) 18:50:59
 - とりまトップページとモバイルラウンジでヤッてみたらその通りだよ。快傑した。室長まるで専門職みたいすごい！抱いて！ --  2020-11-08 (日) 20:27:46
 - （室長）専門職だよおばか！　いやうーんそこが犯人だと対応面倒くさい（難しくはない）ので後々考えて対策します --  2020-11-08 (日) 21:22:33
 - おっ室長じゃんチーッス(特に問題なくいつも通りアクセス出来ておりなんだか蚊帳の外状態の難民顔) --  2020-11-08 (日) 21:34:07
-おお、もう
*** 解説と対策 [#g5f5de31]
- 本サイトの正式なURIは''bladeandgrenade.sakura.ne.jp''である
- が、googleとかで検索すると''www.bladeandgrenade.sakura.ne.jp''と出る
-- 違うじゃねーか！
- 原因はさくらインターネットさんがドメイン登録の時に親切でwwwを付けている版も作ってくれるから
-- 余計な事しやがってとは思うが、www追記は歴史的あれこれが思いつくので文句が言えない
- で、2018年に本サイトのSSL対応をやった結果、サイトアクセスは下記の4通りが出来るようになった
++ http://bladeandgrenade.sakura.ne.jp/
++ https://bladeandgrenade.sakura.ne.jp/
++ http://www.bladeandgrenade.sakura.ne.jp/
++ https://www.bladeandgrenade.sakura.ne.jp/
- そしてChomeなどのセキュア気取りのブラウザを使用している場合、ivでアクセスすると警告が出る
-- 理由は色々あるのだが面倒くさいので詳細を飛ばすとiiと同じ証明書なのにドメイン名違うじゃねーか！ってなるわけ
-- そしてこれは今までも出ていたはずなんですよね

- つまり今回のhttpsへの強制転送でセキュリティ警告が出た人は2年間httpで接続していたユーザということ
-- 私が会社のセキュリティ担当者だったら鱗滝さんばりにビンタですわ
-対策としてwwwでアクセスしてくるのはwww無し版に飛ばすことにした
-- 備えよう
- 追記
 -（ちょい室長の読んでみて4つそれぞれアクセスしてみたらいい感じに転送？されてたけどivだけエラーでる。まぁできる子はわかるやろうから別に、ええわな！） -- 2020-11-08 (日) 23:52:59
 -（室長） ＞ivだけエラー　……（無言の検証）　www付き→無しに転送（www付きアクセスクリア） ttp→ttpsに転送（旧アクセスユーザ誘導クリア）　直でttps://wwwアクセスする子→はじかれて転送されない！！　まぁ今までと同じですわクッソ -- 2020-11-09 (月) 00:07:24
--詳細はさくらインターネットの[[【ここ】>https://help.sakura.ad.jp/206054862/]]が詳しい。サブドメイン提供しておいてSSL提供しないっておかしいと思わなかったんですかね？