FreeBSD」カテゴリーアーカイブ

PHP-WebDriverからFirefoxを操作 on FreeBSD

FreeBSD環境において、PHP-WebDriverからFirefoxを操作してヘッドレスFirefoxを試してみる。とりあえず、Googleのスクリーンショットを撮影するところまでやってみた。

環境

  • FreeBSD 12.3-STABLE r371191
  • 専用のJailゲストを作成して実行した。(jail内でも動く)
  • Firefox 95.0 / PHP 8.0.13 (本記事作成時点のFreeBSDパッケージで導入可能な最新版)

PHP-WebDriverとFirefoxの組み合わせで動かした訳

  • そもそもPHPぐらいしか普段使わないのでPHPで書きたかった。
  • 操作するブラウザをChromeにしなかったのは、WebDriverからChromeの操作に必要なchromedriverのパッケージがFreeBSDになく、Firefoxの操作に必要なgeckodriverはパッケージがあったので
  • 情報自体はChrome(chromedriver)向けの方が見かける気がする。もっというとコードもPHPじゃなくてPython等のサンプルの方が多いけど、そのへんは気合でなんとかする(Pythonで書いてあるのをPHP風に書いてみたら意外と動いたりする)

必要パッケージのインストール(root)

Firefox、geckodriver、日本語フォント、PHPを導入する。

# pkg install firefox geckodriver ja-font-migmix php80 php80-curl php80-mbstring php80-zip php80-phar php80-filter

作業ディレクトリを作成してphp-webdriver導入

% mkdir ~/webdriver
% cd ~/webdriver
% curl -sS https://getcomposer.org/installer | php
% php composer.phar require php-webdriver/webdriver

テストプログラム作成 (~/webdriver/test.php)

<?php
require_once('./vendor/autoload.php');

use Facebook\WebDriver\Firefox\FirefoxDriver;
use Facebook\WebDriver\Firefox\FirefoxOptions;
use Facebook\WebDriver\Remote\DesiredCapabilities;
use Facebook\WebDriver\Remote\RemoteWebDriver;
use Facebook\WebDriver\WebDriverBy;
use Facebook\WebDriver\WebDriverDimension;
use Facebook\WebDriver\WebDriverExpectedCondition;

run();

function run() {
    putenv('webdriver.gecko.driver=/usr/local/bin/geckodriver');

    $desiredCapabilities DesiredCapabilities::firefox();
    $firefoxOptions = new FirefoxOptions();
    $firefoxOptions->addArguments(['--headless',
                                   '--width=1920',
                                   '--height=1080',
                                   ]);
    $desiredCapabilities->setCapability(FirefoxOptions::CAPABILITY$firefoxOptions);

    $driver FirefoxDriver::start($desiredCapabilities);
    $driver->get('https://www.google.com/');
    sleep(3);
    $driver->takeScreenshot(__DIR__ '/ss.png');
    $driver->close();
}

この例だと $firefoxOptions のところでヘッドレスモード(–headless)、ウィンドウサイズ(–widthと–height)を指定している。
ページの取得($driver->get)からスクリーンショット撮影($driver->takeScreenshot)までの間sleepしてるのはページのロード待ちなんだけど本当はWebDriver側のwaitを使うべきで筋としては良くないです(テストなので勘弁を)

テストプログラム実行

実行すると同じディレクトリにスクリーンショット(ss.png)が作成される。

bhyve を試す。 #3 Windows10 インストール編

#1 下準備編#2 Ubuntu 20.04 インストール編の続き。#2 に書いた内容は説明を省きます。

VM作成とインストーラー起動

isoイメージは vm_dir/.iso/Windows10.iso に配置済みとする。VM名はwindows10、テンプレートwindows。ディスク容量は64GB。

# vm create -t windows -s 64G windows10
# vm install windows10 Windows10.iso

Ubuntuと違いデフォルトでvncの設定がされているので vm list コマンドで確認してVNCで接続してWindowsのインストール作業を行う。

VMに与えるCPU数を変更する

ホスト側の仮想CPUのトポロジに関する設定変更と再起動が必要。Core i3(2コア+HT)なのでパッケージあたりのコア数が2、コアあたりのスレッド数も2に設定。

# vi /boot/loader.conf
--- (追加する)
hw.vmm.topology.cores_per_package=2
hw.vmm.topology.threads_per_core=2
---
# reboot

VMの方の設定変更。cpu = cpu_sockets * cpu_cores * cpu_threads になるようにする。

# vm configure windows10
--- (追加・変更する)
cpu=4
cpu_sockets=1
cpu_cores=2
cpu_threads=2
---

以上でVMを起動すると仮想プロセッサが4つある状態で起動する。

仮想NICをvirtioドライバに変更する

標準のe1000のままだとなぜかWindows Update中にフリーズしたため対応。
virtioのドライバーは別途下記からダウンロードして、vm_dir/.iso に展開しておく。
https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/

# vm configure windows10
--- (追加する)
disk1_type="ahci-cd"
disk1_dev="custom"
disk1_name="/vm/.iso/virtio-win-0.1.190.iso"
---
# vm start windows10

上記にてvirtioのドライバーディスクをマウントされた状態でVMを起動し、virtioドライバーのインストールを行ったあとシャットダウンしてドライバーを変更する。

# vm configure windows10
--- (変更・削除する)
network0_type="virtio-net"
#disk1_type="ahci-cd"
#disk1_dev="custom"
#disk1_name="/vm/.iso/virtio-win-0.1.190.iso"
---

以上で仮想NICがe1000からvirtioに変わる。(VM上のデバイスが変わるので、VMのIPアドレス等は再設定の必要がある)

bhyve を試す。 #2 Ubuntu 20.04 インストール編

#1 下準備編の続き。

インストーラーの準備

vm_dir/.iso にisoイメージを配置するだけで良いが、vm iso コマンドでダウンロードさせてもよい。

# vm iso http://ftp.jaist.ac.jp/pub/Linux/ubuntu-releases/20.04/ubuntu-20.04.1-live-server-amd64.iso

VM作成 / 設定変更

テンプレートubuntu を使い、ディスクサイズ30G、ubuntu という名前のVMを作成する。
※-t で指定できるテンプレートは、vm_dir/.templates 以下の*.confファイル

# vm create -t ubuntu -s 30G ubuntu

デフォルトだとVNC接続に対応していないのと、メモリが512MBだったので変更。

# vm configure ubuntu
---
loader="uefi"
cpu=1
memory=1G
network0_type="virtio-net"
network0_switch="public"
disk0_type="virtio-blk"
disk0_name="disk0.img"
uuid="XXXXXXXX-XXXXXXXXX-XXXX-XXXXXXXXXXXX"
network0_mac="58:9c:fc:XX:XX:XX"
graphics="yes"
graphics_res="1280x720"
xhci_mouse="yes"
---

赤字:変更箇所青字:追加箇所

VMとUbuntu 20.04のインストーラーを起動

vm install コマンドで起動する。通常のVM起動(vm start)と違い、指定したisoイメージをマウントした状態になるのと、VNC接続までは起動を待機する点が違うそう。

# vm install ubuntu ubuntu-20.04.1-live-server-amd64.iso
# vm list
NAME    DATASTORE  LOADER  CPU  MEMORY  VNC           AUTOSTART  STATE
ubuntu  default    uefi    1    1G      0.0.0.0:5900  No         Locked (bhyve.local)

server:5900 でVNCが起動しているので適当なビューアーで接続する。インストーラーに従ってインストールが終了した後の起動は

# vm start ubuntu

で起動可能。(自動起動の方法は後述)

余談

VMを自動起動する

vm_listに起動したいVM名(今回の例だと “ubuntu”)、vm_delayに自動起動する間隔(man vmによると短すぎると問題があるらしい)を指定する。

# vi /etc/rc.conf
---
vm_list="ubuntu"
vm_delay="5"
---

FreeBSD jailとの共存

FreeBSDの仮想化といえば古くからjailがあり、KVMやbhyveほどヘビーじゃないので手元の環境でも使っているので、共存ができるのか確認したところ、とくに問題なく共存できた。(まあそりゃそうか)
この環境だと物理NICのem0にIPアドレスのエイリアスを設定してそのIPアドレスをもつjailを作成し、別ホストからjail内にssh接続ができた。

bhyveのVNCが重たい?

macOSには標準でVNCビューアーが入ってる(標準の画面共有がVNC)けどそちらで接続ができなかったので、TigerVNC Viewer 1.10.0でVMのインストーラーを操作したところ手元の環境だけかもしれないが、反応が非常に遅かった。インストールさえ終わればsshなどで利用できるので些細なことではあるけどちょっと気になったので記録する。(macOSの画面共有で接続できないのは仕方ないとして他のVNCビューアーを使えばマシになるのかそのうち試す)

bhyve を試す。 #1 下準備編

FreeBSD における Linux KVM に相当する仮想化ハイパーバイザー bhyve を試してみる。

環境

ホスト
Core i3 2.4GHz、メモリ4GB、SSD 320GB なノートPC
バージョン
FreeBSD 12.2-RELEASE-p3 / bhyve 1.4.2

必要パッケージのインストール

# pkg install vm-bhyve grub2-bhyve bhyve-firmware

仮想マシン置き場を用意する

既存のzfs領域(FreeBSDのインストーラーで作った zroot)に新たに “vm” という領域を作成し、/vm にマウントした。

# zfs create zroot/vm
# zfs set mountpoint=/vm zroot/vm

自動起動設定

# vi /etc/rc.conf
--- (追加)
# bhyve
vm_enable="YES"
vm_dir="zfs:zroot/vm"
---

bhyve 初期設定

vm_dir(/vm) 以下に必要なディレクトリ等を展開する。

# vm init

続いて、仮想マシン作成時のテンプレートをテンプレートディレクトリ(vm_dir/.templates)にコピーしておく。

# cp /usr/local/share/examples/vm-bhyve/* /vm/.templates/

仮想ネットワーク(スイッチ)作成

public という名前でスイッチを作成、物理I/Fのem0をpublicに追加する。
※テンプレートのデフォルトでNICの接続先がpublicになっている

# vm switch create public
# vm switch add public em0

以上で下準備が完了。#2 Ubuntu 20.04 インストール編に続く。

Let’s Encryptの無料SSL証明書で常時HTTPS化

会社でLet’s Encryptというものを教えてもらった(というか、お前が試せって感じだけど)ので、うちのFreeBSD+Apache2.2なサーバーに導入してみた記録。例によってこの記録は個人的なものであり、本記録を真似・参考にされるなどした際に問題が起きても当方はいかなる責任も負わない。

追記(2017/01/11)

「証明書の更新」のコマンド例が間違っていたので修正。(オプションに追加:”–webroot -w”)

追記(2016/07/01)

Let’s Encryptコマンド(Let’s Encryptクライアント)の名称がCertbotクライアントとなり、FreeBSDのパッケージ名、コマンド名も変更となった。変更点は下記の通り。

パッケージ名

py27-letsencrypt から py27-certbot に変更された。パッケージは一度削除してインストールした。

# pkg delete py27-letsencrypt
# pkg install py27-certbot

コマンド名

/usr/local/bin/letsencrypt から /usr/local/bin/certbot に変更になった。

環境

  • FreeBSD 10.3-RELEASE
  • Apache 2.2系
  • 既にhttpで使っているサイトを対象に導入する。

FreeBSD用のCertbotクライアントのパッケージの導入

pkgで導入可能。

# pkg install py27-certbot

証明書の発行

certbotコマンドにcertonlyとつけて実行する。証明書の発行のみ行われる。

# certbot certonly --webroot -w [DocumentRootのパス] -d [ドメイン名] -m [メールアドレス] --agree-tos

ドメイン名へのアクセスチェックが行われるため、DocumentRootに一時的なファイルなどが作成され、letsencryptのサーバーから一時的なファイルへのアクセスが行われる模様。要アクセス権限。

/usr/local/etc/letsencrypt/live/[ドメイン名] 以下に証明書のファイルが生成される。シンボリックリンクになっていて、更新の度にリンク先が新しいファイルになるが、常にこのパスで参照できる。

プラグインが対応しているapache2.4系などは自動的に設定までしてくれるそうだが、apache2.4の環境で試してみたけど使い方がよくわからず、おとなしく証明書の発行を行って、設定は自分で行った。

証明書のインストール

apacheのVirtualHost設定等に下記を設定する。

  • SSLCertificateFile:cert.pem
  • SSLCertificateKeyFile:privkey.pem
  • SSLCertificateChainFile:chain.pem

apacheを再起動してhttpsでのアクセスを確認する。

証明書の更新

よくあるSSL証明書は有効期限が1年などの単位になっているが、この証明書の有効期限は3カ月なので、定期的に更新が必要。

# certbot certonly --webroot -w [DocumentRootのパス] -d [ドメイン名] -m [メールアドレス] --renew-by-default

証明書の発行にも書いたとおり、証明書へのパスの変更はないので、更新が済んだらapacheの再起動でOK。cronで毎月1日に更新するよう設定して様子見中。

httpでのアクセスをhttpsに強制リダイレクト

お手軽に.htaccessにて実施。WordPressのサイトの場合、「BEGIN WordPress」の前に書き加えた。

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
</IfModule>

mod_rewriteには明るくないが、同じ.htaccess内にRewriteEngine onが2行あっても問題ないらしい。

1つのIPアドレスで、複数のHTTPSサイトを運用する際の注意点

当サーバーの様にIPアドレスの割り当てが1つしかなく、名前ベースのバーチャルホストでHTTPS対応をしようとするとServer Name Indicationの利用が必要となる。サーバー、クライアントの双方て対応が必要だが、当サイトのサーバー(Apache 2.2系)は対応している。

クライアント側は、Windows XP以前のInternet Explorerなどで非対応となっているが、現時点でサポート継続中なOS・ブラウザではそれ程問題ない様に思われる。そのため、当ドメインも常時HTTPS強制としてみた。Windows XPなどを使っている人はせめてWindows 7あたりに更新を。