Scrapy のLinkExtractorとブラウザのリンク仕様

Scrapyでは

/ top.html
|----- subdir_a/index_a.html
|----- subdir_b/index_b.html

というディレクトリ構造があり、
top.html に、<a href="../../../../subdir_a/index_a.html">
とあった場合、正しいURLではないので、400エラーとなり、クロールができません。

一方で、最近のブラウザは頭がよくて、
ドキュメントルートトップ以上に遡れないリンクは、勝手にドキュメントルート直下にあるものと扱うようで、
上記のリンクは正しく動作するんです！


昔はそんなことなかったと思うんですがねぇ。。

Wordpressの検索結果画面にスクリーンキャプチャを表示してみた

商用のサイト内検索サービスだと、よく検索結果画面にページのキャプチャが載っているかと思います。
それを簡単にWordpressで実現できました（落とし穴あり）

結論から言うと、Wordpressの非公式APIであるスクリーンショットを取得するサービスを利用するというものです。
コードはこんな感じ。

<img width="230" height="130" src="https://s.wordpress.com/mshots/v1/<?php echo esc_url( get_permalink(get_the_ID()) ); ?>?w=230" class="attachment-post-thumbnail size-post-thumbnail wp-post-image">


これで、検索結果画面で、キャプチャを表示してくれます。

おおー、ちょっとリッチな検索結果画面になった。
と思ったのもつかの間、wordpressのこのapiは、日本語フォントは対応していないんですね。

まあ字を細かく見るものでもないし、十分っちゃ十分か・・・

Googleサイトサーチ(カスタム検索)終了！チーン！

3月いっぱいで、Googleカスタム検索の有料版であるGoogleサイトサーチが新規申し込みを締め切りました。
https://enterprise.google.co.jp/intl/ja/search/products/gss.html


ちゃんとサイトを設計していればあまり迷うことなく、すなわち検索機能を使わないことも多いですが、
やはり最後の受け皿としてサイト内検索は欲しいところです。


そういった中で、Googleのサイトサーチは、年間$100〜と、広告のないサイト内検索を導入可能というとこで
重宝していたウェブ制作者の方々も多かったのではないでしょうか。


もしかするとGoogleが代替サービスを出す可能性もありますが、
2018年4月以降は実質

  1. 広告の出るカスタム検索でがまんする
  2. 月額3-5万ほどするサイト内検索サービスを利用する
  3. CMSの検索機能を利用する

といった三択になってくるでしょう。

お手軽なサイト内検索がなくなったことで、逆にサービス開発のチャンスかもしれないですね。

qTranslateX を使用してWordpressで作成されたサイトをクロールするとクロールできないページが出る件

https://qtranslatexteam.wordpress.com/browser-redirection-based-on-language/

によれば、URLに言語情報を含まない場合は、下記の値を元に判断しているようだ。

  • referrer url (if cookie is not set)
  • cookie (‘qtrans_front_language’)
  • browser setting (if main home page ‘/’)
  • default language (as set on Settings/Languages configuration page)

すこしビビったのが、referer urlを使っての言語判断が優先されていたということ。


つまり、下記のページがあったとして
http://example.com/en/about

そのあと、リファラを保持しながら下記URLにアクセスした場合
http://example.com/about/history

302リダイレクトで下記英語サイトにリダイレクトされてしまうということだ。
http://example.com/en/about/history
そして永遠にhttp://example.com/about/historyページはクロールされないことになる。。。

クローラーなどを作る際はお気をつけください。

ansibleのlineinfile での落とし穴

bindの社内DNSのゾーン設定をansibleで自動化しようとしていたところ、


下記の記述だと、resolver 1のタスク しかincludeステートメントが追加されていなかった。

  - name: resolver 1
    lineinfile: dest={{namedconf}} insertafter="^###localhost_resolver" line='include "/etc/named.{{domain}}.zone";' state=present

  - name: resolver 2
    lineinfile: dest={{namedconf}} insertafter="^###internal_resolver" line='include "/etc/named.{{domain}}.zone";' state=present

どうも、lineinfileだと、lineの中身が同一だと、insertafterのマッチ文字列が異なっていても、そこにすでに、行がpresentなものとされ
二つ目は追加されないようです。


２つ目のline=includeの後ろにもう一個半角スペースを入れることで、二つとも追記できるようになりました。

line='include "/etc/named.{{domain}}.zone";' 
↓
line='include "/etc/named.{{domain}}.zone"; ' ← これで１回目の文字列と異なるものとしてansibleに認識される

社内ファイルサーバ検討（その３）〜純正ツールaws clientに落ち着いた〜

goofys でマウントした領域にrsyncをかけてバックップするという仕組みは原因不明で
実現できませんでしたが、
amazonの純正ツールで　sync コマンドを発見。
aws コマンドでs3のバケットと同期できるようです。


exclude オプションなどもあり、rsync的な使い方ができます。
http://docs.aws.amazon.com/cli/latest/reference/s3/sync.html


さっそくawsコマンドラインツールをインストールします。
pythonで書かれているので、pip からインストールしました。


コマンドはこんな感じで実行します。

$ /usr/bin/aws s3 sync ${SRC} ${TARGET} ${OPTION_EXCLUDE}


ここで１点問題が発生。
AWSのAPIでのアクセスはAWS側のサーバ時間とクライアント側の時刻がずれていないことが必須です。


VirtualBoxのゲストOSで動作させているため、時間が遅れていくという事象が発生し、
Additional Packageをインストールすれば大丈夫みたいなのがあったのですが、
私の環境だとうまくいきませんでした。


ちなみにntpdデーモンで同期しようとしてもうまく動かなかったため、
ntpdデーモンを停止した上で、むりくりntpdateコマンドで強制的にcronで時刻同期するようにしました。

/usr/sbin/ntpdate ntp.nict.jp && /usr/bin/time /usr/bin/aws s3 sync ${SRC} ${TARGET} ${OPTION_EXCLUDE}


syncには時間がかかることが予想されるので、timeコマンドで実行時間もわかるようにしました。
700GBのディスクスペースを同期精査するのに1時間半ほどかかりました。
（アップするファイルがある場合はもっと時間がかかります）


思ったよりも早かったので、夜中に実行しておけば問題はなさそうです。
実行時間もとってメールするようにしてあるので、遅くなった時は気づけるしね。


ちなみに、goofysでせっかくs3バケットをマウントできているので、
こちらのファイルマネージャを使って、どんなファイルがバックアップされるか参照できるようにしました。
検索ができるので便利だし、ファイルの操作やフォルダの作成機能も無効にできるので、
バックアップ領域の参照目的としてはパーフェクトです。

https://github.com/leefish/filethingie


本家サイトがなくなっているぽいですが、とても便利ですよ！
しばらくこんな構成で運用してみたいと思います。

社内ファイルサーバ検討（その２）

社内ファイルサーバ検討（その１）で


いろいろと今のNASからの代替案をあげましたが、
個々の代替案を検討したプロセスについてお話ししたいと思います。


パブリッククラウド

まずだれもが思いつくのがパブリッククラウドです。


Google Driveだと、G suite basicを使っているので、+600円/ユーザ/月 で無制限で使えるようになります。
本来はこれがファイルサーバの代替になると一番うれしかったのですが、

  • ファイルが特定のユーザに紐づく
  • ネットワークドライブとして利用できない
  • 既存の2TBのファイルをどうやって移行しようか・・
  • 2TBをクライアントで同期するのはナンセンスなので、基本ブラウザベースでの操作になりそう


という理由から、今回は見送りとしました。


MicrosoftのOne driveもOfficeライセンスが一緒なので、
結構魅力的だったのですが、やはりファイルサーバとしての用途はGoogleDriveと同様なので、見送り。
DropBoxなども１ユーザあたり月額1000円を超えるし、あまりメリットを感じず、といったところです。


Google Appsのビジネス版でファイルサーバみたいなのを用意すると売れる気がします。

ASPのクラウド ファイルサーバ

今回検討したのは、Fusion Secure Drive Plusというサービスです。


ネットワークドライブにもなるし、IP制限でアクセス制限もかけられる
と、機能的には現在のNASの代わりを十分に果たしてくれそうです。


うちの会社だと月額4万程度の見積もり試算でした。
とはいえ、年間50万弱の経費は小さな会社にはインパクトがあります。

S3バケットをマウントし、Windows ネットワークから参照する方法

３つのアプリケーションを検証しました。


ExpanDrive
ローカルの各端末にインストールして使うぶんには一番安定していました。
ただ、マウントしたS3のバケットをネットワークドライブとしてネットワーク経由でアクセスができません。
つまりはすべての端末にクライアントをインストールする必要があり、AWSへの認証情報も
各端末で設定する必要があり、運用管理上見送りです。


TntDrive
Windowsのみです。S3バケットをマウントし、ネットワークドライブとして利用でき、LAN内の端末からアクセス可能です。
ソフトウェア費用もたった数千円ですみ、社内のWindowsマシンにマウントしておけば、いまのNASと同様に使える。


しかもS3バケットなので、容量はほぼ無制限！


なーんていう夢ものがたりを描いたのですが、
大量のファイルをアップしたり、参照したりすると結構不安定で、エラーが頻発。
別のソフトウェアを探すことにしました。


Cloudberry Drive
AWSのマーケットプレースにも製品を掲載しているソフトウェア会社の製品です。
試したところ、S3バケットのマウントはできたのですが、ネットワーク経由でのアクセスができませんでした。


Windows Server OSだとネットワーク経由でのアクセスができるらしいです。
サポートに連絡して、普通のWindowsでも動くようにお試しビルドまでしてもらったのですが、
ネットワークドライブへのアクセスが拒否されうまく動作しませんでした。


あまり時間をかけたくもなかったので、これも諦めることにしました。
andyいろいろとありがとうよ・・・


こうして、たった数十ドルのソフトウェアでS3という巨大ストレージを使い倒す、という淡い思いは儚く散っていきました。


大きなNASサーバに買い換える。

12TB のNASサーバが約２０万で買えます。

アイ・オー・データ機器 WD Red搭載 RAID6対応 大容量ビジネスNAS 「LAN DISK」 12TB HDL-XR12TW

アイ・オー・データ機器 WD Red搭載 RAID6対応 大容量ビジネスNAS 「LAN DISK」 12TB HDL-XR12TW

RAID5して、8TBが利用可能ですので、まあコスト的にはわるくはなさそうだったのですが、

  • 停電とか心配するのやだな
  • ディスクは壊れるし
  • なんだかんだ電気代もバカにできないぞ！
  • ファイルがどんどん増えるときりがない・・

ということで、積極的な採用理由がありません。


S3バケットをバックアップ領域として利用する


このあたりから、小さな制作会社が、無限のストレージをファイルサーバとして安価に利用するなんてことは難しい、
ということにウスウス気がづいてきました。


そこで今使っているNASサーバを使いつつ、
既存のファイルを削除しやすく、
容量を増やさない工夫ができないかといった、
考え方にシフトし始めます。


普段の生活でも捨てられない人はたくさんいると思います。


「いつか使うかも・・」
「なんかあった時に使うかも・・」


で、結局何年も放置。それと一緒です。


削除しやすい仕組みを作ることがやっぱり大事なんじゃないかと思いました。
なくなった（削除した）時の不安を払拭することで気軽に捨てる（削除）してもらうことを目指します。

goofys を利用してうまいことNASサーバのデータをS3バケットと同期すれば？と考えました。


具体的には、linux サーバにマウントしたNASサーバの領域をlsync & rsyncでs3にバックアップするというものです。


しかしいざやってみると、rsyncでなぜかgoofysの領域にファイルコピーが失敗します。
いろいろ調べたのですが、よくわからず。。。



直接goofysでマウントした領域に、 mkdir や touch などはできるのですが、なぜかrsyncを使って
ファイルコピーができませんでした。


posix-ish なので、完全準拠していないせいでしょうか。


うーんと悩みながら、いろいろと調べていると、
s3 sync というものがあるというのを発見しました。


次回はこの一筋の光明を追いかける話をしたいと思います。