なんかてきとうに

わりと個人的な忘備録的ですよ。

WSLで遊ぶ。

WSLAPIというのが用意されています。

この中のWslLaunchInteractiveというのを呼ぶと、名前指定してWSL環境が呼べます。

つまり

from ctypes import *

ret = c_ulong()
windll.wslapi.WslLaunchInteractive("DistroName","",0,byref(ret))

などとやるとDistroNameなものが呼べます。

登録するために WslRegisterDistribution というものが用意されていますが、  これで

from ctypes import *
windll.wslapi.WslRegisterDistribution("DistroName","rootfs.tar.gz")

などと登録を試みると、 python.exeのある場所にインストールしてくれます。 とても辛い。

ですので、登録自体はレジストリを操作するなどして、用意されたAPIを利用しない方が良いような気がしています。

Windows10 の WSL で動かせる環境を増やす

WSLでUbuntuやKali LinuxDebianが動くようになりましたが、 Ubuntu を複数立ち上げても、すべて同じUbuntu環境になります。 topコマンドを複数立ち上げたUbuntuで実行してみるとわかるでしょう。

諸事情により、複数のUbuntu環境が欲しいような場合のやり方。

環境を見る

レジストリHKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss 配下に 各WSL環境情報が入っています。 UUIDのキーが存在し

BasePath
DefaultUid
DistributionName
Flags
State
Version

などの情報が入っています。

環境を作る

  1. DistributionNameから、元となるインストールされたWSL環境を推測します。
  2. BasePathに書かれているパスを開きます。
  3. そこにあるファイル、フォルダをすべて、任意の(新しい環境を作りたい)場所にコピーします。
  4. レジストリに新しいUUIDなキーを作ります(素のやつの末尾を1文字変えるとかでいいでしょう)
  5. 上記6個の値を同じ用に作成します、ただしBasePathDistributionNameは値を変更します。
  6. BasePathをファイルをコピーした先にします。
  7. DistributionNameは他と被らない一意の名前にします。

これで新しい環境ができました。

同じようにいくらでも環境が増やせます。(上限はあるかもしれません)

作った環境を動かす

  1. コマンドプロンプトから wslconfig /l と実行します。
  2. リストの中にDistributionNameで指定したものがあるのを確認します。
  3. コマンドプロンプトから wslconfig /s 上記で確認した名前 と実行します。
  4. コマンドプロンプトからbashと実行します。

これで新しい環境が実行できているはずです。

作成した別の環境を動かしたい場合は、新しいコマンドプロンプトを起動して 同じ操作を繰り返します。

おわりに

任意のDistributionNameを持つものを起動させる方法もありそうですが、まだ見つけられていません。

見つかると作った環境を動かす手間が減って良いなぁと思っています。

知っている方いたら教えてください。

ちょっとした説明用メモ(IPアドレス)

IPアドレスって?

IP(v4)アドレスって何?

0-255の数字を.で区切って4つ並べたもの

10.0.0.1 とか127.0.0.1 とかそういうの。

インターネットの住所とか言われたりしています。

IPアドレスってなんで必要なの?

住所という表現がわかりやすいですが、

通信を行うためには、相手を特定(識別)する必要があります。

IPアドレスは、インターネットで一意に決まるようになっているので 識別に利用しています。

IP(v4)アドレスの種類 

大まかにこのくらいの種類があります。

ユニキャストアドレス

1対1通信で使うアドレスです。

グローバルアドレス

インターネットで一意なアドレス。インターネットで通信するためにはこれが必要です。

ローカルアドレス

それぞれのイントラネットで一意なアドレス。会社とか家庭内で通信するのに使われています。

インターネットに出られません。

マルチキャストアドレス

1対多通信で使うアドレス。

送信者がマルチキャストアドレスに送信すると、

そのマルチキャストアドレスを受信したいと言っている相手全部に届きます。

インターネットでは使えないと思っておいて問題ないです。

グローバルIPアドレスがないとインターネットに出られない?

出られません。

ただ、ローカルIPアドレスを途中でグローバルIPアドレスに変換する仕組みがあって、それを使ってインターネットに出ていたりします。

NAT(Network Address Transration)

NAPT(Network Address and Port Transration)

というやつです。

ローカルIPアドレス - NAT変換装置 - グローバルIPアドレス

と、変換装置を通ると変換されます。

日本の一般的な家では、ブロードバンドルータという機械が行っています。

ローカルアドレスイントラネットで一意?

これも、複数のイントラネットをつなぐときに 前述のNATやNAPTを利用することで必ずしも一意とは限りません。

がこちらはNATしたりするほうがレアケースかも。

NATって1回しかおこなわれないの?

そんなことはありません。

ローカルIPアドレス - NAT変換装置 - ローカルIPアドレス

という変換もできるので、多段にNAT変換されていったりします。

アドベントカレンダーの最後を糞な記事で締めくくりたい!

この記事はWebスクレイピング Advent Calendar 12/25 の記事です。

初めに

大体タイトルの通りなので割と読むだけ時間の無駄です。

書くのも時間を無駄にした感が半端ないです。

私とクローリング

私がWebページをクローリングしようとした最初のきっかけは、とあるテキスト系サイトのテキストを読み逃しなく読みたいという欲求からでした。

当時、個人でWebサイトを持つのが普通になって、みんなhtmlタグをポチポチ自分で打ってた頃、過去ログなんて存在しない!みたいなテキストを不定期に更新するだけのページが存在しました。

RSSとかそんな良いものもなく、とりあえず毎日見てれば逃すことはないだろうという雰囲気があったころ。

ただ、毎日巡回するってまぁ大変で忘れますよねって、そこで毎日クローリングして変化があれば保存するというそれだけのスクリプトを書きました、perlで。

何のひねりもなく、常時起動してるWindowsマシンのタスクスケジューラに登録して毎日巡回させてました。

以来、RSSが登場してもRSSなんか見ないので、結局そのテのものはデイリーくらいで巡回させて拾うようにする癖がつきました。

私とスクレイピング

私がWebページのスクレイピングをしようとしたきっかけは、画像掲示板でした。

また当時、画像掲示板なるものが流行り、いわゆる二次加工な二次元壁紙をひたすらいろんな人が貼るだけの掲示板というのが大量にできました。

双葉とかしおからとかsweetnoteとかいちごとかいろいろ。

そういう画像を見るわけでもなく、ひたすらHDDの肥やしにするということに無駄に熱を注いでいる時期がありました。

当然ながら、効率よくデータを集めたくなるのが心情というものです。

で、巡回ツールが出回ったりするわけですが、当時はまだWebサイト側の回線も貧弱だったり、ホスティングサービスの無料プランでは大量にダウンロードされたりするとすぐ従量限界に達して503しか返さなくなるみたいなこともあり、メジャーどころの巡回ツールはだんだん対策されるわけです。

一例として、refererを見たりUser-Agentを見たりするようになりました。 cookieを使い始めるものもありました。

頑張ってるところでは、メインページにサムネイルと個別ページへのリンク、個別ページでimgタグを利用して画像を張り付けているもの(サムネイル、個別ページ、画像本体のアドレスが結構バラバラでちゃんと追わないと拾えない)や、通常の画像と同じようにhtml上では記載されているけれど、Webブラウザで見ると見えないようになっており、そこにアクセスすると一定時間IPAddressによる制限が入って閲覧できるなるもの、等、だんだん趣向を凝らしたものになっていったりしていました。

そこで、ツールに頼っていると対応待ちが発生するなど、不便極まりないため、やっぱり自分で作ることになります。

そんなに頑張って探したりもしてないので、クローリングに適したフレームワークが当時存在したのかどうかは定かではないのですが、そういうのは利用していませんでした。

htmlを適当に解析して、画像のURLをひろいだして、ファイル名一致でダウンロード済でないか確認して、持ってなければダウンロードみたいな単純なところから始まり、可能な限り人間がたどるのと同じようにたどって画像をダウンロードする、そんなところにばかり力を入れていました。 やっぱりperlで、perlにはLWPという素晴らしいモジュールが存在しまして、referercookieも当然のように扱え、この手の巡回にはとても便利だったのを覚えています。

画像掲示板自体は、いくつかの種類の掲示板スクリプトがとてもよくつかわれていたので、やっぱりそういうのに対応できるように作っていくわけです。

掲示板が数種類の累計に分類されるので、スクリプトのつくりも、クローリングする部分、htmlを解析して画像URLを回収する部分、次のページを指定する部分、画像をダウンロードする部分など、適度に交換可能な形で作るようになりました。今だといろんなフレームワークが便利にやってくれる部分ですね。

どうでもいいですが今でも当時の画像ファイル群がHDDに埋まっていたりします。1024x768とかでもまともなサイズだったんですよ。

ちなみに、このころもrobots.txtなどはありましたが、そんなのは見もしていませんでした。でも特にそれが原因で揉めたような話も聞きませんので、牧歌的な時代ですね。 いくつか試した巡回ツールにもそんな機能はなかったんじゃないかと思います。

私と現在のクローリング

現在は、もうそんなにクローリングしてなくて、 某漫画家さんのサイトがちょうど過去ログ残さず、テキストと画像が不定期に差し変わるというサイトと、時間や数量制限のある、メディアプレイヤー向けskinをアップロードする掲示板の2か所くらいしか巡回していません。

今はperlではなくpythonを使っていて、普通にhttp.clientとかurllibで書いています。巡回してデータを拾ったらtwitterにDM送るようにして、貯めるだけ貯めて見ないという状況をなくす工夫もしています。

進化しました。

そうは言っても、言語が変わってもやっぱりやりたいこと、その方法はそう大きく変わらず、今でもフレームワークを利用して……みたいなことはやっていません。

たとえばこんな(随分前に書いたやつなので今見るとアレな感じですが)

from http.client import HTTPConnection, HTTPSConnection
import re
import os.path
from  localtwitter.twitter import *

img = re.compile(r'src="([^\s/]+\.[\w]{1,3})"')
SAVE_DIR = "/path/to/save/dir/"


def get_image_list(c):
    c.request('GET', '/')
    r = c.getresponse()
    if r.status == 200:
        return img.findall(str(r.read()))
    return []

if __name__ == '__main__':
    c = HTTPConnection('<URL>')
    images = get_image_list(c)
    print(images)
    save_list = list()
    for img in images:
        if os.path.isfile(SAVE_DIR + img):
            print(SAVE_DIR + img, "is exist")
            continue
        c.request('GET', "/" + img)
        r = c.getresponse()
        print(img)
        print(r.status)
        if r.status == 200:
            with open(SAVE_DIR + img, "xb") as file:
                file.write(r.read())
                save_list.append(img)
    if len(save_list) > 0:
        token,secret = get_cred()
        send_message(user = "<twitter_user_name>", message = ",".join(save_list) ,oauth_token = token, oauth_secret = secret)

このあたり、もうちょっと進歩すべきなんだろうなぁと思っています。

来年は、クローリングのためのフレームワークをちゃんと使えるようになりたいですね。

終わりに

そんなわけで、ほんとに糞みたいなというかまさに糞そのものな記事を書きました。

ここまで読んだ暇人さん、きょうは12/25ですよ、ほかにやることないんですか!

ということで、Advent Calendar お疲れさまでした。

決めるということ

お仕事で決めるというのが苦手です。

いくつか触ってみて、これがいい!とはっきり言える場合は良いのですが、 ぶっちゃけどれでもよくね?みたいな時、 それぞれのメリット、デメリットを提示しつつ、 総合的にみるとどれも大差ないです。 というとき、いつもどれも大差ないですっていう結論を持っていわゆる偉い人に持っていこうとするのですが、 とりあえず(経験豊富な)同僚にいったん見せて会話をすると、どれでもよくても、これがいいという推しを作って持っていけと言われます。

いや、マジどれでもいいんすよね、みたいな話なんですが、その分野に詳しい我々がとりあえず推しを決めていかないと、偉い人はもっとわからないので判断ができないという話です。

なので、どれでもよくても、とりあえずこれでという推しを用意するのが大切なんですが、説明するうえでは当然、推す理由というのが必要になります。 その辺の理由をでっちあげるみたいなのがいまいち苦手です。

そういうの、どうやったらうまくなるんですかね。

CODE BLUE に行ってきた

セキュリティのしごとをしているわけでは全く無いのですが、個人的な興味から行ってきました。

サイバーセキュリティについて、人的資源から、アプリケーションの実装など、様々な分野のセキュリティに関する話が聞けた2日間でした。

中でも話が面白かったのは * SSRF の新時代 有名プログラミング言語のURLパーサを攻撃 * 商用ホワイトボックス暗号方式に対する鍵回復攻撃 * インサイドShell .NETハッキング技術を応用したPowerShell可視性の向上 * 基調講演 OSSによる自動車の自動運転化 あたりです。

人的資源の観点とか、実際の攻撃がどんなだったか、みたいな話は、ためになるんですが、面白いかどうかはまた別問題という感じです。

内容はきっと詳しい人が詳しく書くので行ってきましたにとどめておきます。間違ったこと書いてもなんですし。