WordPressのサイトを静的コンテンツに変換して社内公開するまで

WordPressで構築された他社イントラのコンテンツを、SimplyStaticプラグインで静的サイトに変換し、自社イントラのWebサーバで公開する案件に対応したので手順をメモ。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/236222/4642c67b-3bdb-4548-791d-0e186335210a.png)

# 要件・制約

1. **B社**の社内ネットワークから、**A社イントラ**のサイトを、そのままの形で見せたい
2. リアルタイムな更新・同期までは求めない（多くても月に１回程度の更新頻度）
3. VPN等で回線をつなぐのは、A社のセキュリティポリシー的に認められない

## A社のイントラ情報

- `http://host1.intra.xxx.co.jp/ZZZZ`
- サイトはWordPressで構築されたポータル（Webサーバ、DBサーバ、PHPのバージョン等は不明。というか気にする必要は無い）

## B社のイントラ情報

- `http://host1.intra.xxx.co.jp/ZZZZ` （URLはA社とまったく同じにすること）
- 環境は Apache2 + CentOS7

# 実現方式と手順

WordPressの静的html生成プラグイン **Simply Static** を用いて、サイトを丸ごとZIP等でパッケージングし、オンラインストレージを介してB社に送信、B社でWebサーバにアップロードしていただく運用とした。

## Simply Static の設定（A社）
静的サイトのエクスポート方法に「オフラインで使用するために保存」（英語版なら Save for offline use）を選択する。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/236222/369f2fdc-db5f-e693-d67d-09cf7a4416e2.png)

## DNSゾーンファイルの編集（B社）

B社では **ActiveDirectory/DNS** サーバを運用している。
次の通りで追加してみよう。

- ゾーン：intra.xxx.co.jp
- ホスト：host1

### サーバマネージャーからDNSを選ぶ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/236222/581f1561-af6d-4c86-7ee8-7284efe26201.png)

### DNSマネージャー
前方参照ゾーン`intra.xxx.co.jp` にAレコード `host1` を追加。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/236222/93f7b26b-7a6d-16df-6267-5af3a9a9b8f1.png)

## Webサーバの設定（B社）
`host1.intra.xxx.co.jp`として接続するためにバーチャルホストの設定を行う。

ZIPファイルを展開するとファイル名の大文字小文字が元通りにならない場合があったので、併せて **mod_speling** モジュールを有効にした。
URLの判定が case-insensitive（大文字と小文字を区別しない）になるため *"404 Not Found"* を回避できる。

```apache:/etc/httpd/conf.d/host1.intra.xxx.co.jp.conf
LoadModule speling_module modules/mod_speling.so
<VirtualHost *:80>
    ServerName host1.intra.xxx.co.jp
    DocumentRoot /var/www/html2

    <Directory "/var/www/html2">
        Options -Indexes +FollowSymLinks
        AllowOverride All
        CheckSpelling On  # case-insensitive
    </Directory>
</VirtualHost>
```

## コンテンツのアップロード（B社）
アップロードはユーザー部門（非IT部門）が実施する運用だ。
ユーザー部門の端末にscp/sftpソフトを入れてのオペレーションはハードルが高いので、Windowsのファイル共有を使う。

### sambaの設定

```shell-session:インストール
# yum -y install samba

# smbd -V
Version 4.8.3
```

```conf:/etc/samba/smb.conf
[global]
  security = user
  passdb backend = tdbsam
  dos charset = CP932
  unix charset = UTF-8

[share]
  path = /var/www/html2/ZZZZ
  writable = yes
  create mask = 0644
  directory mask = 0775
```

```shell-session:アカウント作成
# useradd myuser
# passwd myuser

# pdbedit -a myuser
new password:
retype new password:
```

```shell-session:sambaのポートに穴を開ける
# firewall-cmd --add-service=samba --permanent
# firewall-cmd --reload
# firewall-cmd --list-all
```

```shell-session:再起動
# service smb start
# systemctl enable smb
```

情報システム部門が作成したショートカットファイルをユーザー部門に配布し、Webサーバの **DocumentRoot** にアクセスしてもらう。
![image (3).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/236222/0750277b-242b-17e0-5462-fb820426d5cc.png)

## 解凍
Windowsの解凍ソフトでは日本語ファイル名が文字化けするので、Webサーバ上で`unar`コマンドを実行する。
`unar`はファイル名の文字コードを自動で判定してくれる他、さまざまな圧縮形式に対応しているのでオススメ。

```
unar -D simply-static-XXXXXXXX.zip
```

# ファイルサイズの4GBオーバー問題
一般に、ファイルサイズが4GBを超えるような場合、様々な問題が起こり得る。

- ブラウザによっては4GBを超えるファイルをダウンロードできない
- 保存先のハードドライブやUSBメモリがFAT32でフォーマットされていると壊れる
- オンラインストレージが4GBを超えるファイルの送信に対応しない
- 標準のZIP形式では4GBを超えるファイルを解凍できない

数ヶ月のあいだ運用してたらZIPファイルが解凍できないという問題が発生した。
受領したファイルのMD5チェックサムを先方に伝え、照合すると一致した。つまり受領時に壊れたのでは無い。

ちなみにMD5チェックサムの出し方は次の通り。

```:Windowsの場合
certutil -hashfile ファイルパス MD5
```

```:Linuxの場合
md5sum ファイルパス
```

7zコマンドでZIPファイルをテストすると Unconfirmed start of archive と表示され、ファイルが壊れていると判る。

```:7z
$ 7z t foo.zip
7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=ja_JP.UTF-8,Utf16=on,HugeFiles=on,64 bits,1 CPU Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz (306F2),ASM,AES-NI)

Scanning the drive for archives:
1 file, 4416114003 bytes (4212 MiB)

Testing archive: foo.zip

ERRORS:
Headers Error
Unconfirmed start of archive

WARNINGS:
There are data after the end of archive

--
Path = foo.zip
Type = zip
ERRORS:
Headers Error
Unconfirmed start of archive
WARNINGS:
There are data after the end of archive
Physical Size = 380850288
Tail Size = 4035263715

Archives with Errors: 1
Warnings: 1
Open Errors: 1
```

4GBを超えているのが原因だった。
SimplyStaticの設定画面 [インクルード/エクスクルード]－[除外するURL] で、容量圧迫の要因となっている動画ファイル（*.mov）を指定し、回避した。 
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/236222/b2455963-e870-5b5f-63b0-3c36c86ab81d.png)