環境

• ESXi 6.5d (2017/06/16 時点で出ているパッチ適用済み）
• Core i5 4570 / 24GB RAM / SATA SSD
• Gigabyte Z87X-UD3H

2017/07/22 追記

Ryzen を使用している場合、この手順を行ってはいけません。
SATA が認識できなくなります（恐らく） また、ESXi 起動後にシステム領域を見失う為
復帰には再インストールしかなくなります。（設定を変更はできるが、保存できない）

症状

時々 VM がひっかかる。（動作が止まる）
完全に停止してしまうので、色々と処理オチしたりする。

確定方法

ホスト → 監視 → イベント　で datastore へのアクセスが切断された旨のログが出力されている。

切断自体は一瞬で回復している。

原因

6.5 以降？の SATA ドライバがいまいち安定していない

対応

以下のコマンドで新しい SATA ドライバを無効化して、古い SATA ドライバに入れ替える

ホストのリブートが必要

1

esxcli system module set --enabled=false --module=vmw_ahci

前提

ESXi 6.7 (無償ライセンス）

何が問題なのか

タイトルだけでは分かりにくいのですが、以下のような不思議なことが起こります。

• VM にネットワークアダプタを追加し、接続先ポートグループを設定する。
• 設定した接続先をリネーム、または削除する
• VM の設定を開くと、「ネットワーク アダプタ 2 のポート グループ (削除したポートグループ) が見つかりません。これは (名前順で最初のポートグループ)に割り当てられています。」
• 設定画面から、接続先ポートグループを設定しても反映されない。

回避方法 1

以下の用に設定すると設定できました。

• ネットワークアダプタの横の”接続”チェックボックスをオフにして、一度保存
• ネットワークアダプタの接続先ポートグループを変更して保存
• 1 でチェックをはずした、”接続”チェックボックスにチェックを入れて保存

回避方法 2

以下のようにしても設定可能ですが、MAC アドレスが変わってしまうのでおすすめできません

• ネットワークアダプタを削除して保存
• ネットワークアダプタを再度追加する。

蛇足

Web UI、バグバグなのは相変わらずなようです･･･

なお、回避方法 1 の手順 2 と 3 は同時にやっても上手く行く場合もあります（むしろ、上手く行く場合の方が多い感じです） が、失敗した例があったので、念のために分けて記述しています。

はじめに

Oracle Cloud の Always Free 枠、シビれましたね。

何がすごいって、O(racle)CPU 1 個、メモリ 1GB の VM インスタンスを 2 個も作らせてくれると。

OCPU は Xeon の物理 1 コア+HT をそのまま割り当てするので、OS から見ると 2 コアです。すげー。

ということで、ホイホイ釣られてサーバーとして使用している機能を一部試しに移してみようと思ったらハマったので記事化することにしました。

個人的な好みで Ubuntu 18.04LTS を使用します。

Oracle Cloud 上での作業

Compute を作成します。ここは Web から普通に作業すれば良いので省略します。

サーバーへの接続（ssh)も省略します。 接続後、 apt install nginx したものとして記述します。

ハマりポイント

インスタンス名は、あとから変更できません

Web からは変更できなそうです。CLI 使うと変更できるかもしれません。

インスタンス名は、Compute のホスト名として使用されてしまう

日本語を入れると sudo するたびに怒られます。

hostnamectl を使ってホスト名を変更し、 /etc/hosts に 127.0.1.1 yourhostname という感じに記述すると治ります。

作業手順

セキュリティリストの編集

• 左ペインの、 ネットワーキング→仮想クラウド・ネットワーク を選択
• VirtualCloudNetwork-201909xx-xxxx のような名前の VCN を選択。
• サブネット Default Subnet for xxx を選択。
• セキュリティリスト Default Security List for Virtual... を選択
• イングレス・ルールの追加をクリック
• ソースタイプ CIDR、ソース CIDR 0.0.0.0/0 IP プロトコル TCP ソース・ポート範囲 All （空欄にするか All と入れる） 宛先ポート範囲 80 を指定して、イングレス・ルールの追加 ボタンをクリック

※ default security list をいじるのではなく、セキュリティリストを追加すべきですが手順短縮の為にこうしています。

この手順で、Compute(=VM)まで 80 番宛のパケットが届くようになります。

OS のファイヤウォールの設定

Ubuntu 18.04 のイメージでは、iptables が最初から有効になっています。

Oracle Cloud 用のルールが入っているので、UFW に乗り換えるのは大変そうです。

仕方が無いので、iptables に設定を入れていきます。

お行儀がわるいのですが、ルールファイルを直接編集します。

vi /etc/iptables/rules.v4 (/etc/sysconfig/iptables ではありませんでした）

1
2
3
4

-A INPUT -p udp --sport 123 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT  <= この行追加
-A INPUT -j REJECT --reject-with icmp-host-prohibited   <= これより前に追加すること

編集後に、 /etc/init.d/netfilter-persistent reload を実行します。

これで、外からの http アクセスを受け付けられるようになりました。

蛇足

http アクセスだったら LoadBalancer とか使うべきかもしれませんが、あれは Always Free 枠ではないので割愛。

環境

Doma2 + SQL Server

ハマりメモ

Timestamp 列があるテーブルに INSERT しようとしたらエラー

文字が化けてよく読めないが、DOMA2009 が発生している模様。

原因 1:

Timestamp 列にデータを INSERT しようとしていた。

Entity クラスの当該列を以下の感じにして、挿入、更新の対象外にした。

1
2

	@Column(insertable = false, updatable = false)
LocalDateTime updateDate;

Timestamp 列があるテーブルを SELECT するとエラー

https://docs.microsoft.com/en-us/sql/connect/jdbc/using-basic-data-types

によると、Timestamp 列がマップされるのは、BYTE ･･･やってられないので、普通の DATETIME 型にすることにした。

前提

• Mastodon prodcution guide に従った非 docker 構成
• Ubuntu 18.04LTS

構成

• もともとの Mastodon サーバー(Mastodon サーバーと呼ぶ)
• 移行先 PostgreSQL DB サーバー(DB サーバーと呼ぶ）

やったことの前提

私は複数の Mastodon インスタンスを運営しており、ひとつはほぼ負荷がないテスト用で、もう一つは本番稼働しているものです。これらの PostgreSQL の DB を別のサーバー（2 つのインスタンスで共有）にまとめてみようと思い今回の作業を行いました。

手順

本作業は、Mastodon のインスタンスを停止して行う必要がある。

外出側の PostgreSQL にユーザーと DB を作成

DB サーバーでの作業。

postgres ユーザーで実行する。

1
2
3

CREATE USER mastodon_user; # 複数インスタンスのDBを統合するならその分作る
alter role mastodon_user with password 'password';  # パスワード設定
create database mastodon_db with owner=mastodon_user;

外部接続を可能にするように設定

DB サーバーでの作業。

/etc/postgresql/10/main/pg_pba.conf を編集し、以下の内容を追加する。

1
2

# ↓固定 database     user           ip              ↓固定
host    mastodon_db mastodon_user 192.168.10.0/24   md5

設定を反映させるためにリロード（restart でも OK）

1

sudo systemctl reload postgresql

もとの DB を dump する

ここから先は mastodon を停止して行う必要があります

Mastodon サーバーでの作業。

postgres ユーザーで実行。

1
2

sudo su - postgres
pg_dump mastodon_production > dump.sql

ダンプをロード

Mastodon サーバーでの作業。

postgres ユーザーで実行（だが、dump.sql にアクセスできればどのユーザーでもよい）

1
2

psql --host=192.168.10.40 --username=mastodon_username < dump.sql
# --no-owner オプションを追加すれば次項のユーザーに関する警告をスキップできる（コメント参照）

注意点

接続が拒否されるのであれば、DB サーバー側のファイアウォール(ポート 5432)や、pg_hba.confの設定を疑う。

ERROR: role "mastodon" does not exist が表示されるが無視して良い。

alter で所有者を変更しようとしているが、もともとは mastodon ユーザーが所有していたのを、DB 移行の際に mastodon_user に変更しているせい。

DB 自体の所有者を変更してあるので動作上問題はない（owner ならその DB とその中身に対して全権限がある）

しかし、mastodonユーザーが、移行先の postgresql に存在してしまっている場合は問題になる。

この場合は、dump.sqlを編集して(OWNER で検索して置換すると良い）ユーザー名を書き換えるしかないと思われる。

※ 私はこれに該当したのでdump.sqlを書き換えました。それなりに大きなサイズになるはずなので可能ならsedを使うなりした方がいいかもしれません。VSCode で頑張って置換しましたが動作がもっさりして辛かったです。

Mastodon の設定ファイル修正

mastodon サーバーでの作業。

DB の準備が終わったので接続先をそちらに変更する。

mastodon ユーザーで行う。

/home/mastodon/live/.env.production の以下の部分を編集

1
2
3
4
5

DB_HOST=192.168.10.40
DB_USER=mastodon_user
DB_NAME=mastodon_db
DB_PASS=mastodonpassword
DB_PORT=5432

動作確認

ここで、mastodon を立ち上げて、Web からアクセスできることを確認する。

一度テストでトゥートしたり、お気に入りをつけたり軽く動かしてみるとよい。

mastodon サーバー上で動作している postgresql を停止

ここまでで、DB サーバーの移行は完了したので、mastodon サーバーで動作している postgresql が

不要になったので停止する。

mastodon サーバーでの作業。

以下を実行。

1
2
3

<code class="language-bash"># sudo可能なユーザーで実行。mastodonサーバーで動作しているPostgreSQLを停止
sudo systemctl stop postgresql
sudo systemctl disable postgresql

1
2
3
4

# mastodonユーザーで実行。
cd ~/live
~/live$ RAILS_ENV=production bundle exec rake db:collation
en_US.UTF-8  # これが表示されればOK！

ここには記述しないが、この時点で PostgreSQL のデータファイルも削除することもできる。

以上

変更履歴

2018/09/27 この手順で DB の移設が可能なことを確認した。

2019/08/15 誤記修正、体裁修正

何がしたいのか？

• dockerhubのイメージから最新のバージョンのタグを取得したかった。

2019/09/07 更新 sort -V で簡単。

1
2
3
4

`curl https://registry.hub.docker.com/v1/repositories/misskey/misskey/tags \
 | jq -r '.[].name' \
 | sort -V
 | tail -n 2 | head -n 1

で終わり。

sort -V はバージョン番号のソートの指定で、前ゼロ等の処理をよしなにやってくれるというもの（man によると）

v11.4.1 のようなプレフィックスがあっても大丈夫という優れもの。

いつきさんご指摘ありがとうございました。

以下、古い記事を供養の為にそのまま残しておきます。

tl;dr;

1
2
3
4
5

`curl https://registry.hub.docker.com/v1/repositories/misskey/misskey/tags \
 | jq -r '.[].name' \
 | sed -e "s/\([0-9]*\)\.\([0-9]\)\.\(.*\)/\1.0\2.\3/g" | sort \
 | sed -e "s/\([0-9]*\)\.0\([0-9]\)\.\(.*\)/\1.\2.\3/g"
 | tail -n 2 | head -n 1

解説

curl

dockerhub の API でタグ一覧を取得する。

返り値はこんな感じ。

1

`[{"layer": "", "name": "11.28.0"}, {"layer": "", "name": "11.28.1"}, {"layer": "", "name": "11.28.2"}, {"layer": "", "name": "11.29.0"}, {"layer": "", "name": "11.3.0"}, {"layer": "", "name": "11.3.1"}, {"layer": "", "name": "11.30.0"}, {"layer": "", "name": "11.31.0"}, {"layer": "", "name": "11.31.1"}, {"layer": "", "name": "11.31.2"}, {"layer": "", "name": "11.31.3"}, {"layer": "", "name": "11.31.4"}, {"layer": "", "name": "11.4.0"}, {"layer": "", "name": "11.5.0"}, {"layer": "", "name": "11.5.1"}, {"layer": "", "name": "11.6.0"}, {"layer": "", "name": "11.7.0"}, {"layer": "", "name": "11.8.0-2"}, {"layer": "", "name": "11.8.1"}, {"layer": "", "name": "11.9.0"}]

jq

json の配列内から name だけを抜き出す。

dockerhub の API はタグ名を文字列としてソートしてくれているのか、以下のような出力が得られる。

-r を付けることで、ダブルクオートで囲まれていない出力が得られる。

1
2
3
4
5
6

`11.31.2
11.31.3
11.31.4
11.4.0
11.5.0
11.5.1

11.31.4 > 11.4.0 なのでこの並び順は都合が悪いので、どうにかしていく。

sed その 1

11.4.0 のような中央が一桁の場合、0 を補って二桁にする。

11.4.0 => 11.04.0

sort

文字列順ソートで良いのでそのまま並び替え

sed その 2

変更したままだと存在しないタグになってしまうので（当然）元に戻す。

“11.04.0” => “11.4.0”

tail & head

1
2
3

`11.31.3
11.31.4
latest

最新のタグの取得。

latest なら常に最新！だと最初からこの記事は不要になってしまうので、

ちゃんと最新のタグを取得します。

tail -n 2 で末尾二行を取得して、

1
2

`11.31.4
latest

head -n 1 でその先頭行を取得します。

1

`11.31.4

蛇足

わかっているがスルーした点

• メジャーバージョン一桁のコンテナはないのでバージョンの最初の桁の二桁化はしていない
• 三桁目が二桁になったら同じ事が起きるが対応してない
• 10.100.0 というバージョンが見えるが見なかった事にしている

蛇足

エスケープだらけでみづらい。 まさかグループ化の ( がエスケープ必要だとは思わなかった。

正規表現に関しては、 https://www.debuggex.com/ が大変わかりやすかったです。

バージョンなど

ESXi 6.0U2 (無償版)

イメージのコンバート

さすがの ESXi でも qcow2 イメージは読めないので vmdk にコンバートする必要がある。

KVM が動いているサーバー上で、以下のコマンドを使えば変換できる。

1

qemu-img convert -O vmdk [入力ファイル].qcow2 [出力先].vmdk

イメージの転送

一番素直なのは、 vSphere Client か　 Web Client を使ってデータストアに

ファイルをアップロードすることだけれども、転送速度があまり出ないわ、Web Client は

セッションタイムアウトで中断するわであまりうれしくない。

そこで、ESXi ホスト上で SSH を有効にして、scp コマンドを使って転送することにした。

1

scp imagefile.vmdk root@[esxiホストのIPアドレス]:/vmfs/volumes/datastore1/imagefile.vmdk

イメージを Zeroedthick に変換

転送したイメージファイルは.vmdk なので普通にそのまま VM に接続できそうに思えるが、

実際に接続してみると、以下のエラーがでる。

“Unsupported or invalid disk type 7. Ensure the disk has been imported”

どうも、形式が微妙に違うようなので変換する。

ESXi ホストに SSH して、以下のコマンドを使う。

1
2
3
4
5

cd /vmfs/volumes/datastore1/
mkdir temp
cd temp
mv ../imagefile.vmdk temp
vmkfstools -i imagefile.vmdk [VM名].vmdk

わざわざ、datastore1 の下にディレクトリを作ってそこで作業しているのは、

どういうわけか、datastore1 直下だと元ファイルの読み込みに失敗するから。

ファイルが存在しているのにファイルがないとか言われたりして少しハマった。

完了

最後に作った vmdk をよしなな位置に移動して、仮想マシンに接続すれば OK。

手順メモ

前提

必要なものをインストール

• npm i typescript -g
• npm i webpack -g
• npm i webpack-cli -g

typescript→javascript 準備

tsconfig.json 編集

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

{
  "compilerOptions": {
	  "experimentalDecorators": true,
    "module": "commonjs",
    "noImplicitReturns": true,
    "noUnusedLocals": true,
    "outDir": "./build/",         ※ ここだけ直す
    "sourceMap": true,
    "strict": true,
    "target": "es2017"
  },
  "compileOnSave": true,
  "include": [
	"src",
  ]
}

テスト

src に適当に index.ts のようなファイルを置いて、 tsc を実行する。

./build/index.js が出来ていれば OK。複数ファイル置いても全部トランスパイルされることを

確認する。

javascript を 1 ファイルにパックする

webpack.config.js 編集

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

// output.pathに絶対パスを指定する必要があるため、pathモジュールを読み込んでおく
const path = require('path');

module.exports = {
  // development or production。
  mode: 'development',
  resolve: {
    alias: {
      // vue はフルコンパイラー入りが必要
      'vue$': 'vue/dist/vue.esm.js' // 'vue/dist/vue.common.js' for webpack 1
    }
  },
  // エントリーポイントの設定
  entry: './build/index.js',
  // 出力の設定
  output: {
    // 出力するファイル名
    filename: 'index.js',
    // 出力先のパス
    path: path.join(__dirname, './public/lib')
  }
};

テスト

webpack を実行すると ./public/lib/index.js が出力されることを確認する。

蛇足

一番書きたかったのはここ

変更したらいちいち手動でコンパイルするの？

少しの間手動でやっていたのですが面倒過ぎます。

なのでどうにかしようと思います。…ファイルの変更を監視するオプションは tsc にはありません。

webpack にはあります。と言うことは、 typescript のトランスパイルも webpack にやって貰う必要があります。

webpack 用 ts-loader をインストール

• npm i ts-loader --save-dev
• npm i typescript --save-dev

webpack で typescript をトランスパイルする設定

webpack.config.js に以下を加えます。蛇足ですが、カンマ等にはお気を付け下さい。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

// 追加
  resolve: {
    extensions: ['.ts', '.js'],
  },

// 追加
  module: {
    rules: [
      {
        test: /\.tsx?$/,
        use: [
          {loader: 'ts-loader'}
        ]
      }
    ]
  }

// 変更。tscによりトランスパイルされたjsではなく、tsを直接見る
  //entry: './build/main/main.js',
  entry: './main/main.ts',

webpack によるトランスパイルテスト

webpack で、トランスパイルまで行われることを確認する。

tsc + webpack と出力は変わらない。

ソース変更を監視させる

webpack --watch

これでソースの変更を監視して自動でトランスパイル等をやってくれるようになる。

vue cli で作ったプロジェクトを webpack でやろうとしたらコケた

• @Prop() private msg!: string;
• TS6133: ‘msg’ is declared but its value is never read.

private ではなく、protected にすればよい。

最初に

Mirakurun は既に稼働状態であることを前提としています。

node.js

• 10.13.0 LTS をインストール（この時インストーラーにその他必要なモノを入れる的なチェックを入れておく）
• インストール後の処理で強制的に再起動されるので注意

git for windows インストール

• インストーラー使うだけ

Visual C++ Build Tools 2015 のインストール

以下の URL からダウンロードしてインストール

https://go.microsoft.com/fwlink/?LinkId=691126

ffmpeg のインストール

https://ffmpeg.zeranoe.com/builds/

直接リンク

https://ffmpeg.zeranoe.com/builds/win64/static/ffmpeg-20181125-370b8bd-win64-static.zip

20181125-370b8bd 4.1 / Windows 64bit 　を選択

zip アーカイブを好きな場所に展開する。このパスは後ほど使う。

EPGStation のインストール

https://github.com/l3tnun/EPGStation/blob/master/doc/windows.md に従う。

npm install が失敗するので、 npm install --msvs_version=2015 とする。

ここで先ほど入れた C++ Build Tools が必要。

config.json 変更点

• sqlite3 使用
• エンコーダーのパス変更 (enc.js)
• ffmpeg のパス変更

npm start すると sqlite3 モジュールがない。という感じのエラーが出るので次のステップで解消する

sqlite3 モジュールのインストール

https://qiita.com/noobar/items/0128677c44bb9dde88b2

1
2
3
4

cd c:\usr\EPGStation\node_modules\sqlite3
npm install -g node-gyp
npm install
npm run prepublish       ←これは失敗するが問題なかった

npm run prepublish が失敗しているが、EPGStation が起動するようになった。

蛇足

config.json は公式マニュアルを一通り見ながら設定した方がよい。ファイル名や、録画したファイルの保存場所など、

sample には書いていないけれども必須の設定がかなりある。

環境

Ubuntu 14.04 LTS

ディスクのパーテーションは

1. swap 2GB
2. / (ext4) 40GB

動機

物理マシン上で動いている Linux をそのまま仮想マシンにしたかった。

動機は Linux マシンの転送ですが、仮想マシンの Windows（ESXi）を同（Hyper-V）に移行する際に

同様の手順で実施可能な事を確認しています。その他、物理マシン上の Windows のディスクコピー等、物理コピーでどうにかなるものなら大抵なんとかなります。

準備（転送元）

パーティションをできるだけ小さくする。 gparted live dvd を使用した。

この手順はオプションなので、やらなくても良い。

準備（転送先）

仮想マシンを作成（ディスク容量は、転送元のパーティションがコピーできるだけの容量を確保）

Ubuntu の Live DVD で起動して、パーティションを転送元と同じブロック数で確保した。

転送元と転送先で、fdisk 　のブロック数が同じになるようにパーティションを作成。

ブート可能フラグを立てるのを忘れない（ブートしたい場合は）

なお、この手順はディスク丸ごと転送する場合は不要。

次の手順のデバイス名を /dev/sda とすればディスク丸ごと転送になる。

この場合、ブート可能フラグは自動で立つはず。

転送準備

転送元、転送先の両方の PC で同じ操作をする。

PC を Ubuntu Live DVD で起動する。（以下の手順は 14.04LTS で動作確認している）

起動後、Ubuntu を試す を選択してしばらく待ち、UI が起動するのを待つ。

起動したら、Windows キー(Linux 的には Super キー)を押下して、 terminal とタイプ。

すぐ下に、端末　というアイコンが出るのでそれをクリックする。

紫色のコマンドプロンプトみたいな何かが起動すれば OK。

転送

転送先 → 転送元の順で操作する。

ようするに、書いてある順に操作すれば OK。デバイス名を間違えると悲しいことになるので要注意。

1
2
3

# 転送先で以下のコマンドを打つ。デバイス名は適宜調整して下さい。（例： ディスク全体なら /dev/sda等）
sudo su -
nc -l 12345 | dd of=/dev/sda2

1
2
3

# 転送元で以下のコマンドを打つ。デバイス名は適宜調整して下さい。（例： ディスク全体なら /dev/sda等）
sudo su -
dd if=/dev/sda2 bs=10240000| nc [転送先IPアドレス] 12345

1
2
3
4
5
6
7
8

# 進捗確認用
# 転送元の別コンソールから使用すると、10秒ごとに進捗が dd を実行しているコンソールに表示される
sudo su -
watch -n 10 pkill -USR1 dd

# 今回は関係ないですが、 macOS上のdd は USR1 を送ると終了してしまいます。
# watch -n 10 pkill -INFO dd
# とすれば希望する動作になります。

起動してみる

新しくできた VM を起動してみると、GRUB Rescue の画面に入ってしまい起動できない場合がある（あった）

その場合の操作は以下の通り

1
2
3
4

grub rescue> set prefix=(hd0,2)/boot/grub
grub rescue> set root=(hd0,2)
grub rescue> insmod normal
grub rescue> normal

Windows の場合は、とりあえず Windows のセットアップ用 ISO を入れて起動し、diskpart コマンドを

使ってブートローダを上書きしてみる感じでしょうか（未検証）

20180123 追記 macOS 上でやる場合

いくつか違いがあります。

1
2

ディスクの一覧を表示
sudo diskutil list

ここでは、ディスクのデバイス名が /dev/diskN と表示されますが、ddを行う際は
/dev/rdiskN を使用するほうがよいかもしれないです。

参考

ddの進捗を確認 - Qiita
http://qiita.com/tukiyo3/items/5e3fd748287ffa4b6612

Linux 上の GRUB 2 がブートできなくなったときの対処方法
https://jp.linux.com/news/linuxcom-exclusive/418274-lco20140625

MacでRaspberry PiのSDカードをハードコピー（バックアップ） http://karaage.hatenadiary.jp/entry/2015/06/09/080000