※apacheでヴァーチャルホストな場合の話です
掲題の通り、httpのアクセスをhttpsにリダイレクトさせたい。
といっても、Let’s Encryptを使うと自動で設定してくれますね。
↓こんな感じ。

<VirtualHost *:80>

  ServerName example.com

  RewriteEngine on

  RewriteCond %{SERVER_NAME} =example.com

  RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

</VirtualHost>

でも、コレって「Redirect」ディレクティブを使えばもっとシンプルに書けるんでないの？

<VirtualHost *:80>

  ServerName example.com

  Redirect permanent / https://example.com/

</VirtualHost>

うーん、実際にやってみると同じ挙動のように見えるんだけど。
なにか問題があるのかなー？

「Redirect」ディレクティブが入っている「mod_alias」のマニュアルにこう書いてある。

mod_alias は簡単な URL 操作向けに設計されています。 より複雑な操作、クエリーストリングの操作には、mod_rewrite で提供されるツールを使用してください。

今回のは『簡単な URL 操作』にあたるのでRedirectディレクティブを用いるべき、と思うのだけど…。

教えて詳しい人！
…って、こんなところで言っても誰も教えてくれないだろ(^_^;

systemctl とか service とか /etc/rc.d/init.d/ 的な話です。

結論から言うと、

『挙動が明らかな場合のみ、reloadを使いましょう。』


続きを読む

またしても罠にハマった…orz(死語(死語(ry

poppler-utils をインストールすると pdftotext でPDFのテキストを抽出できるようになる。
これは色んな記事があるのでここでは触れません。

えーと、結論から言うと、下記でできます。

pdftoppm -jpeg hoge.pdf hoge

これで、下記のようにページごとに出力される。

　　hoge-1.jpg

　　hoge-2.jpg

　　hoge-3.jpg

　　...

以下、恒例の蛇足。。。


続きを読む

下記は某ソニーペイメントサービス様の記事より引用したもの。
これは絶対にコピペして使わないでください！

ErrorDocument 503 /maintenance.html

< IfModule mod_rewrite.c >
RewriteEngine On
RewriteCond %{REQUEST URI} !=/maintenance.html
RewriteCond %{REMOTE_ADDR} !=xxx.xxx.xxx.xxx
RewriteRule ^.*$ - [R=503,L]
< /IfModule >

< IfModule mod_headers.c >
Header set Retry-After "Sun, 1 Apr 2018 7:00:00 GMT"
< /IfModule >

『「xxx.xxx.xxx.xxx」の部分は管理者のIPアドレスです』などと、いかにもコピペすれば使えますよー的に書かれていますが、鵜呑みにするとつまづきます。
もう、わざとやっているとしか思えない、罠が存在するのです。
まずはじめに、タグ開始文字の後ろとタグ終了文字の前にスペースが挿入されています。
これだけなら、まあ、単純なミスだなぁ、と思ってそのまま終わっていたと思う。
が、もう一つ悪質な罠が…。
それは「アンダースコアが空白になっている」です。
具体的には「REQUEST_URI」が「REQUEST URI」になっているのです。
これ、見た目ではわかりにくく、ついに間違いに気づくことができませんでした。。
そこで別サイトを参考に.htaccessを作り、事なきを得たのですが、、、
この正常稼働したものと、テキスト比較ツールを使って比較してもなお分かりにくく、その場では気づくことができず、他にも動作確認しなければならないので後回しにしていたのです。
んで、後日落ち着いてテキスト比較ツールで見ていると、どうやら前述の箇所が違っているらしい。
改めてテキストエディタで開いて良く見ると、「ここ空白になっとるやないかーい！」と、ようやく気づいたという次第。

もうね、こんな使えないものをあたかもコピペで使えますよ的に載せている企業なんて、信用できません。もし決済代行導入の機会がありました際には、今回の件、参考にさせていただきます。


もっとも、悪いのは動作確認を怠った私です！
私のような迂闊な人間に警鐘を鳴らすためにあえて罠を仕込んだのかもしれない…。
ただ、それを超大企業(のグループ企業)がやっていいものか、疑問ですが。。

うーむ、いつものことながら、なんだか尻窄み。。。

Larabelでマイグレーションを使用することになった。
んで、

>php artisan migrate

したわけだが、下記のエラーが。。

↓こちらの記事で詳しく解説してくださっているようです。
innodb_large_prefixを使ってERROR 1071を回避する | Yakst

具体的な解決方法は↓こちらに書いてあった。

my.cnfで以下の設定をおこないます。

[mysqld]

innodb_large_prefix

innodb_file_per_table

innodb_file_format=Barracuda

よし、設定できた！っと思って再びmigrationコマンドを実行するも…変わっとらんや内科医っ！

さらにググった結果、下記ページに辿り着く。
【Laravel5.4】migrationができない。SQLSTATE[HY000]: General error: 1709 Index column size too large. The maximum column size is 767 bytes.

やったことは、
・config/database.phpを編集

    'connections' => [

//...

        'mysql' => [

//...

            'engine' => 'InnoDB ROW_FORMAT=DYNAMIC',

        ],

//...

・テーブルのROW_FOMATを変更

> ALTER TABLE `<Table name>` ROW_FORMAT=DYNAMIC;

これで、migrationコマンドが通った＼(^o^)／！

うーん、もはや、どれが功を奏したのか不明。。。
やり直す気力もないので、今回はこのままで(-_-;)


しかし、ファイルフォーマットのBarracudaとかって言われても、さっぱりわからない┐(´〜`)┌
バラクーダといえばセアガテ(Seagate; シーゲートですね(^o^;)のハードディスクしか思いつかないぞっ( -`д-´)ｷﾘｯ

っと思ったけど、そういえば、バラクーダって深海魚？がいたなぁ。
…って、

サメより危険なオニカマス（バラクーダ）

こんなにコワいお魚さんだったとは(((( ;ﾟДﾟ))))