作成者別アーカイブ: ジジイ

SSLとWWWありのURL正規化はこの記述で決まり。サクラサーバーではまた違うけど。

SSLが当たり前になってもうだいぶ経ちます。
ですが、まだ細かいケアは身についていなかったり。その代表格はSSLリダイレクトじゃないでしょうか?
いろいろ試しましたが、サーバーによってもまちまちで、毎回うまくいかなかったりでございますわねえ。
しかしとうとう決着。SSLとWWWありのURL正規化はこの記述で決まり。
.htaccessに以下を記述しよう。

RewriteEngine on
RewriteBase /
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

WWWをつける、つけないはあると思いますが、WWWはつけておいた方が使いやすいです。
よくwwwついてりゃなあと思わされるときは、WordpressなんかのDBの書き換え。wwwがついていればメアドのドメイン部分が書き換えられてしまうことなくスムースだったり、なにかと必要です。
それでもwwwはいらねえ、っていう場合はこちら。

RewriteEngine on
RewriteBase /
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\.
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

参考サイトはこちらです。ありがとー!
https://www.white-space.work/url-normalization-with-htaccess/
※よく読めばいいことなんですが、RewriteEngineとRewriteBaseを見落としがちなので、自分用にメモしたわけです。

ただ、さくらサーバーはこうはいかないはずなので、そのときはこちらのページを参考にするとよいと思います。
https://www.1-firststep.com/archives/3938

WordPressのマルチサイト(Multi site)でネットワーク管理画面(/wp-admin/network/)へログインできなくなってる場合

やっとわかった!
Wordpressのマルチサイトでサイトを作っていて、ネットワーク管理画面(/wp-admin/network/)へログインできなくなって長かったのだが、原因がようやくつかめた。
ログインができなくなっていた状況はというと、多数のリダイレクトが発生して、ブラウザがタイムアウトしてしまうのだ。

「このページは動作していません」
リダイレクトが繰り返し行われました

と表示される。
テスト環境に移しても同じような状態だ。テスト環境でもダメということは、サーバーの問題ではないようだ。プラグインも切ってみたが、変りない。
ただ、テスト環境を何度か作り直しているうちに直ったこともあった。やった!と思ったが、なにがどうやって直ったのかはわからずじまいで、本番環境を直すにはそこを知る必要がある。
テスト環境へ移すときに変更するのはドメイン名の変更だ。ドメイン名に問題がありそうだとだいたい目星はついていたが、長い間どう調べても糸口がつかめなかった。

[wordpress network redirect]などと検索していて、海外のサイトで以下のようなアンサーを何度か目にしていたのだが、よく読んでいなかった。
今日のような暇なときに腰を据えて読んでみると、ちゃんと説明してくれていることがわかる。

https://wordpress.stackexchange.com/questions/175728/redirect-loop-only-for-multisite-network-admin

There's another possible cause of the loop when trying to access:
/wp-admin/network/
There's a redirect triggered at the bottom of:
/wp-admin/network/admin.php
This checks that the current blog and current website have the same path and domain values, if they don't then the redirect occurs.
Double check that the path specified in the wp_blogs table is the same as the path set on the current site.
These values can end up out of sync, especially when installing the applications inside a directory, eg. /blog/

Andrew

簡単に要約すると「wp_blogs」にあるURLが正しくないとリダイレクトしてしまうよ、ということだ。
(the current blog and current website have the same path and domain values ここんとこね)

wp_blogs」がどこにあるかと言えば、データベースだ。テーブルの名前に「wp_blogs」というのがあって、Wordpressのリダイレクトは、そのURLと管理画面が同じパスであるかチェックするのだ。セキュリティの一つだね。

治し方 その1

データベースを編集する
phpMyAdminなどのデータベース編集ツールを使うのが早いだろう。サーバーの管理画面から使えることが多い。自前のサーバーだったらphpMyAdminからダウンロードしてきてインストールするとかになる。
もしくは、プラグインのバックアップツールなどでデータベースをダウンロードして、直接編集をしてもいい。シリアライズが必要な部分でもなさそうだからね。他の部分はダメだよ![s:4:...][s:12:...]みたいな記述があるところはシリアライズと言って文字数も関わってくるところなので、手で治すのは危ない。手間もかかるしリスクも大きいから、ツールを使った方が確実だ。

「wp_blogs」
phpMyAdminにて、データベースを覗いてみた。しかし「wp_blogs」には二つの行があるだけで、それぞれにドメインとディレクトリが正しく入っている…。問題はなさそうだ。いや待てよ、うーんやはりドメインとディレクトリが正しく入っている…。問題はなさそうだ。などと10回くらい繰り返したときだった。
ドメインに、wwwがついてねえ!
と気が付いたのだ。「www」つきのドメインに変えたら見事、ネットワーク管理画面に入れた。


↑赤くしたとこにあるドメインが間違っていないか確認。

ありがとう!Andrewさん!私のドメインの記述が間違っていました!どこでどうやって間違えたのかはわかりませんが、とにかく私が悪かったんです!ありがとう!…

「wp_site」
データベースを見て回ると、「wp_site」というテーブルも見つかった。ここにもドメインが「www」なしで記述されている。ついでにここも直しておいた。とくに影響はなさそうだ。もしなにかマズかったら、ここは元に戻そうと思う。

治し方 その2
こっちは治せるというよりかは、確認ができる、と言った方がいい。ちょっと力わざなものだ。

/wp-admin/network/admin.php

というファイルの中に、

wp_redirect( network_admin_url() );
exit;

という記述がある。一番下あたりだ。これを

//wp_redirect( network_admin_url() );
//exit;

と「//」でコメントアウトする。PHPはこれでとりあえず動作させないようにできる。
ここのプログラムは、Andrewさんが言ってた、同じドメインかチェックをするプログラムの部分なのだ。
とりあえずこの機能を切ってしまおう、ということだ。この2行をコメントアウトしたら、管理画面よりネットワーク管理画面に入ってみよう。とりあえずは入れるはずだ。

URLを確認
そこで「サイト」にあるマルチサイトで作った各ブログのURLを確認してみてほしい。どうだろうか?wwwがなかったり、正しいURLになっているだろうか?
もともとのブログは直せないが、追加したブログはURLの変更ができるはずだ。そこで治してもダメなら、やはりデータベースを直接直した方がいい。
URLが正しいか確認できるかできないかは心理的にはけっこうでかい。原因がわかれば進むことができる。

これでサイト全体にアップデートがかけられるようになったわけだ。アップデートをすると、サイトのアップグレードもしておこう。ネットワーク管理画面にあるから、探してくれ。すぐに見つかるはずだ。

さくらサーバーで枯れたCGIを動かそうとするも500エラー

さくらサーバーで枯れたCGI(perl)を動かそうとするも、500internal server error。
古くから使っているからいい加減エラーなく設定できるようになりたいが、毎度毎度ひっかかる。perlってどうしてこうも繊細なんだろ。KYともいえるが。
要因はこんな感じ。全部試してみる価値ありです。

・cgiファイルのエンコード形式をチェック。SJISで、改行形式がCRLFで動いたが、ご自身の環境に合わせてみる。
LF(ラインフィード)っていうのがLINUX形式で、CR(キャリッジリターン)LFとが混ざっているのがWindows形式なのかね。

・FTPでアップするときにASCIIとバイナリの両方式を試す。自動にしておけば通常良いのだろうけど、どうしてもダメなときは試す。
 ※ASCIIっていうのは、テキストファイルなんかをサーバーの形式(主にLINUXか)に合わせてアップするよ、っていう感じなのかな、簡単に言うと。CR+LFになっちゃっているときに自動でサーバーの仕様に変換してくれるのがASCIIなんだけど、これがうまくいかない場合があるっていう話みたいね。

・パーミッションは705か755。ほとんど755でOKだよね。そんなことないか。

・サーバーのコントロールパネルから、Perlのバージョンを変える。私はPerl 5.12.5でOKだった。

っていう感じか。
毎回失敗して、しぶしぶ上から順に試していくって感じ。だいたいこれで収まるね。

超大容量ハードディスクで警告: 操作の結果できるパーティションはアライメントが正しくないためにパフォーマンスがでません。UBUNTU(LINUX)

UBUNTU(LINUX)で6TBのハードディスクをフォーマットしようとしたけど、

警告: 操作の結果できるパーティションはアライメントが正しくないためにパフォーマンスがでません。

と出ちまったので解決したときのメモです。

まずはGNU partedを起動。設定したいハードディスクだかのデバイスを指定する。なにしろ2TB以上だとデカいので特別にパーティションを作らないといけないらしいんですよ。

parted /dev/sd?
あたしのときはparted /dev/sdd

そしたら↓こうなった?

GNU Parted 3.2
/dev/sdd を使用
GNU Parted へようこそ! コマンド一覧を見るには 'help' と入力してください。

次はpを打ってみるだけ。

(parted) p

するとまた「エラー: /dev/sdd: ディスクラベルが認識できません。」とエラーが。

エラー: /dev/sdd: ディスクラベルが認識できません。
モデル: TOSHIBA MD04ACA600 (scsi)
ディスク /dev/sdd: 6001GB
セクタサイズ (論理/物理): 512B/4096B
パーティションテーブル: unknown
ディスクフラグ:

そういうときはラベルを作成します。

(parted) mklabel gpt

でもう一回pを打つ

(parted) p
モデル: TOSHIBA MD04ACA600 (scsi)
ディスク /dev/sdd: 6001GB
セクタサイズ (論理/物理): 512B/4096B
パーティションテーブル: gpt
ディスクフラグ:

番号 開始 終了 サイズ ファイルシステム 名前 フラグ

すげえ、出来た。問題はここからです。
mkpartと打ってパーティションを作成するのですが、パーティションの開始位置を「0」と打つと、自動的に最小位置でやってくれようとするのですが、

番号 開始 終了 サイズ ファイルシステム 名前 フラグ
1 17.4kB 6001GB 6001GB ext4 primary

などと開始位置が「17.4kB」と半端になってしまって、フォーマットするときに

This may result in very poor performance, (re)-partitioning suggested.

って出ちゃうんですよ。パフォーマンスが乏しいよと。
なので、「4096s」とするのがいいと海外のサイトに書いてあったのを拝借。sをつけない「4096」だけだと4096MBの位置になっちゃうのでsはつけてくださいね。勝手にアレンジ禁止です。場合によっては「2048s」でもいいかもしれません。

(parted) mkpart primary ext4 4096s 100%
場合によっては
(parted) mkpart primary ext4 2048s 100%
でもいいかも。

おお、出来た。これでqと打てばパーティションの設定は完了。

(parted) q
通知: 必要であれば /etc/fstab を更新するのを忘れないようにしてください。

と表示されてご親切にfstabのことまで心配してくれる。たしかに助かるわ。こういうのを心配りというのだね。

でext4形式でフォーマット開始。

# mkfs.ext4 /dev/sdd1
mke2fs 1.42.13 (17-May-2015)
Creating filesystem with 1465129984 4k blocks and 183144448 inodes
Filesystem UUID: zxxxxxxxxxxxx-xxxxxxx-xxxxxxxxx-xxxxxxxx
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848, 512000000, 550731776, 644972544

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

ためしにmountコマンドでマウントして、dfでデバイスの接続状況を確認すると

/dev/sdd1 5814214160 59336 5521112444 1%

ということでした。やったぜ!

イラストレーターでリンク画像がみつからない!とか探すのめんどくせえ時 二日酔いでそんな気になれない!

イラストレーター使っていると、リンク画像がみつからない、とか、探すのめんどくせえってときありますよね。
とくにクライアント支給のデータもらったときとかに、すげえ律義にフォルダ分けしてくれてたりとか、どこにあんだかわからない。
あるいは、ちょっと本気出せば見つけられるんだけれど、二日酔いでそんな気になれない、とかって言うときに便利な技です。

まず、イラストレーター開いて画像が見つからないと「置換」「無視」「キャンセル」って出てきますよね?「…というリンクファイルが見つかりません。」ってな感じで。
そしたら「置換」を選んでください。

エクスプローラーの画面が出てきますよね?出てこなかったら壊れていますよ。
えーっと、そしたらおよそ画像が入っているフォルダまでは進んでください。
フォルダはおおざっぱでいいです。そのフォルダ内のどっかに画像があればOKです。選んだフォルダの下の下の下の下の下の下の下の下の下の下に画像が入っている、とかでもOKです。なにせ検索で探すんで。

そう、右上にある検索ボックスありますよね?なければやっぱり壊れてますよ。
その検索ボックスに「.」半角ドットを入れて全ファイルを検索します。半角ドットは全ファイルを検索する、っていう呪文です。知らなかったらいろいろな場面で使えるので絶対覚えとけよぉ。

するとざざざーっとクライアントがよくもまあこんな画像だのepsだの使ってるわねえ、というくらい出てきますわ。
そのなかにきっと目的のファイルはある。
きっとあるヨ。
でもざざざーっといっぱい出て来ちゃったから、探すのめんどくさいです。
なので、探さなくていいです!
そのままで「置換」ボタン押しちゃってください!するとどうでしょう!

どんなにフォルダわけされちゃっていても、見つけてくれるはずです、しかも全部のファイルを一発で!

便利でしょう。
ぜひやってみてね。

Windows10どうしても消えないディレクトリ名・ファイル名を削除する

Windowsで、どうしても消えないディレクトリ名・ファイル名を削除する方法がわかったのでメモ。

客先からもらったZIPを解凍したところ、中にあったフォルダの様子が変だ。
中のファイルが開けなかったり、取り出せなかったりする。フォルダ自体のリネームさえできない。
よく見るとディレクトリ名の最後にスペースがある。果たしていわゆる半角スペースなのかどうかもわからない。
「Macの野郎…」
俺はそう思った。

そんなファイルやディレクトリは、コマンドプロンプトから削除する方法が、98や2000なんかの昔からよく使れている。
まずはこれを試してみてもらいたい。

●ディレクトリを消したいときのコマンド。
https://www.k-tanaka.net/cmd/rd.php

●ファイルを削除したいときのコマンド。
https://www.k-tanaka.net/cmd/del.php

懐かしいなあ、と思いながらコマンドを打つが、できない。
俺の場合だが、「指定されたファイルが見つかりませんでした」と出る。
そんなときは、↓こちらをすぐに試してくれ。すげえぞ。ありがとうatmarkit!!

https://www.atmarkit.co.jp/ait/articles/0501/29/news013.html
「¥¥?¥ドライブ名¥パス名¥ファイル名」

なんと、パスの書き方を変えただけで出来ちまった…頭に「¥¥?¥」これをつけるだけ。クォートで囲ってもOKとのこと。

¥¥?¥ドライブ名¥パス名¥ファイル名
"¥¥?¥ドライブ名¥パス名¥ファイル名"

すげえ時間くっちまったので、次はすんなり削除したいのでメモでした。

ブロック要素とブロック要素同士をfloatとoverflowで回り込みフロートができるなんて…CSSネタ

CSSネタです。
floatとoverflowで回り込みフロートができるなんて知らなかった…。

このサイトが詳しく解説してくれている。

可変の要素を横並びにするにはfloatとoverflowを使うと便利‼︎

pタグ内に、imgを入れて、回り込ませるなんてことはよくやっていたのだけれど、ブロック要素とブロック要素同士を回り込ませるなんてことができるとは全く知らなかった。
ブロック要素とブロック要素をフロートさせるには、必ずwidthの指定か、内容物の大きさで幅を明示させないと流れてくれないものだとばかり思ってたので、いくつもの違う幅のものが出てくるといちいちwidthを指定してたりしたものだ。それがなんと幅を可変で回り込みっぽくできるじゃないか。素晴らしい。
勝手に「回り込みフロート」と命名してしまったが、名前があると検索しやすいじゃん?

UBUNTUにfail2banを導入したが、fail2banの起動でエラーが出てしまう。

# service fail2ban restart
をやると
Job for fail2ban.service failed because the control process exited with error code. See "systemctl status fail2ban.service" and "journalctl -xe" for details.
こんな感じ。

ググって見つけたこのページを参照してみた。
http://kazuminkun.hatenablog.com/entry/2016/08/30/234458

/usr/bin/fail2ban-client -x start
をやると
ERROR Server already running
とエラーがでる。

なにやらすでに起動されているというが、、なにが一体??
次にこんなこともしてみた。

# systemctl status fail2ban.service
とすると、吐き出されたエラーの中に
fail2ban.service: Failed with result 'exit-code'.
こんなのがある。

ググってみると、ここが出てきた。参照。
https://github.com/fail2ban/fail2ban/issues/1937
Server is already running とは、fail2ban-clientがすでに起動しているからじゃないか?的な話があったので試してみる。

# fail2ban-client stop
とやると
Shutdown successful
と出た!

fail2ban-clientはクライアントで?それを止めたわけだけれど?、エラーはサーバーが起動している、という出るのはなんか変だ、、けれど、いいのか。
とにかくこれでもう一度

# service fail2ban restart

今度はきれいに決まった。
再起動したらまたなんか出そうだが、今はよしとしよう!
おっと、fail2banからメールがどっさり来た。
Stopしたよ、startしたよ、とか、レポートなんかだ。おお、たしかに動いているようだ。

ちなみに、以下のコマンドをたたくと、fail2banの状況がわかるので、試してみてね。

#systemctl status fail2ban.service
# fail2ban-client status dovecot
 とか 
# fail2ban-client status sshd
 とかかな。
# tail -f /var/log/fail2ban.log ※もしログを取ってるなら確かめてね。

しかしこういうアプリが欲しかった。なかなか見つけられずにいたのは不覚だ。
ログを見るとちょくちょくBanし始めている。少し様子を見てみよう。大事なもんまでBanしてるといけないからね。

固定ページでループが含まれているときに、固定ページ自体のIDを取得したいとき。WordPress

WordPressで、固定ページでループが含まれているときに、固定ページ自体のIDを取得したいときもあるでしょう。
私の場合は、固定ページにショートコードでカスタム投稿の一覧を表示させていたのだが、$post->IDなどとしても、ループの最新投稿のIDが返ってくるばかりで固定ページそのもののIDを取得したいのに、まったくできなかった。
もちろんget_the_ID();もだめ。
結局、これで取得できた。

global $wp_query;
$thePostID = $wp_query->post->ID;

$wp_queryはデータベースの情報をWordpress用にオブジェクト化した塊、といえばあってるんでしょうか?
ループが始まる前の情報がある、と思ってよいかな。これもあいまいだが、とにかく取得できた。

悪夢再来か?ファーストサーバー、高負荷障害 2018年6月19日から発生

6月19日より一部のお客様で発生している高負荷障害に関するお詫びとお知らせ」と障害報告ページが出来上がっているが、2018年7月4日現在、まだ復旧していない。なんと2週間たっても復旧していないという。
かつてあった大規模事故(2012年(平成24年)6月20日17時頃発生)を思い起こさせるものがある。
あのときの大事故はデータ損失だったので、今回の接続不良とは訳が違うが、

ファイルの誤参照による障害
2012年6月20日に発生したデータ消失を免れ、残っていた一部のバックアップ環境で復旧プログラムを実行した。復旧プログラムの理解がないまま実行したので、不正なリカバリーファイルが作成された。その内容を確認せずに提供したので、ファイルの誤参照が発生した。

情報漏洩
二次的な情報漏洩事故も発生した。2012年(平成24年)6月20日に発生した「データ消失事故」によるデータ復旧プログラムによって、消失データを復旧したものの、一部の顧客がアクセス権限のないデータを閲覧できる状態となった。
利用者の復元データを同じサーバの他の顧客がダウンロード可能となってしまったことによって、この事故は発生した。
この事故の対応として、混在したデータをダウンロードした可能性のある顧客に対して、電話連絡で復元データの削除を依頼した。

参照元:Wiki
https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%83%BC%E3%82%B9%E3%83%88%E3%82%B5%E3%83%BC%E3%83%90

とあるように、対応の間違いで情報が漏洩してしまうなどの二次災害も心配だ。
そもそもなぜこのようにファーストサーバは障害だらけなのだろうか。

今回も数時間程度ならよくある障害としてもいいだろうが、これは障害というよりは完全に大事故。筆頭株主であるヤフー株式会社がなんとか言わないといけないレベルだろうが、Yahoo!のTOPページは「受託収賄 文科省局長を逮捕」をはじめとしたありふれた事件を報道している。

変化がない次第(へんな日本語だね)、引き続き報告していきたい。

現時点での報告履歴キャプチャ

追記:
2018/7/5(木) 17:10現在でもまだ復旧していない。

追記:
2018/7/6 20:00~7/9 9:30現在
なんと、サービス停止、60時間のメンテナンス!?それの甲斐なく、メンテナンス時間を延長。時間は未定だって???

2018年6月19日(火)より発生しているZenlogicホスティングの高負荷障害を改善するため、7月6日(金) 20時00分よりすべてのサービスを停止しメンテナンスを実施いたしました。
しかしながら、サービス再開処理後、再度の高負荷発生を確認いたしましたため、大変申し訳ございませんが、不本意ながらメンテナンスを延長させていただくこととなりました。

メンテナンス期間
7月6日20時00分 ~ 最長 7月9日08時00分 未定

https://zenlogic.jp/news/status/syogai/?_ga=2.149550006.1857334898.1531095613-625222788.1530512595

60時間メンテナンスはさすがに聞いたことがない。それでも復旧できなかったというのだから、いったいどんな障害が起こっているんだろうか。

障害報告用のtwitterも止まってしまっているようだ。
https://twitter.com/ZenlogicS

↓このサイトで言われているように、今回の大雨と相まって、被害は大きくなっている。また、他社のサービスへのリンクを掲載しているのが怒りの度合いを表している。
http://yua0209.hatenablog.com/entry/zenlogic201807shougai
たしかにイベント進行してたり、大雨の休業のお知らせを出せないというのは、WEB上において大きな損失だ。こういった機会損失をサーバー会社はどう補填してくれるんだろうか。500円のクーポンを配るくらいがせいぜいなんだろうか。

2018/7/9 10:38
とうとうメディアも取り上げ始めたようだ。
http://www.itmedia.co.jp/news/articles/1807/09/news059.html
目新しい情報ではないが、もうちょっと早めに上げるべきかと思う。記事によれば官公庁も含まれるということなので、重大な障害事故と言えるのではと思う。
こういう時に「事故」とはなかなか言わなずに、濁すのが定石だ。重大インシデント、とか、事象、とかの日常でない言葉で煙に巻こうとする。そういう姿勢が余計な怒りを買うとも思う。