仕事の都合で、扱うブラウザを増やして対応しようと思い、SRware の Iron を用意した。
んで、Chrome で Flash が認識されているのに、新しく追加した Iron だと認識しないとき。
PPAPI 版 FlashPlayer をインストールする。
各環境向けのインストーラ等は下記の Iron のトピックを見ると良い。
HOW TO ACTIVATE PPAPI-FLASH - SRWare.net
検索すると、Chrome と Iron では共存できない、みたいな記事がヒットする。が、現在は問題無いよ模様。
手元で確認した環境では、
このようになっている。
参考：
stop slave して reset slave して change master to で stop slave した時点のログを指定すればオッケーでした。 復帰できない場合は、mysqldump かなんかでログの位置を記録できるバックアップ作成して再度スレーブの構築するしかないのではって感じ。
参考:
CentOS7 ばかり触ってて、AMI Linux の設定方法を書いてなかったので。多分 CentOS6 も同じ。
[ec2-user@localhost ~]$ sudo su - root [root@localhost ~]# mv /etc/localtime /etc/localtime.org [root@localhost ~]# ln -s /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
これを実行すると、即座に設定が反映されて JST になるはず。
[root@localhost ~]# date Mon Nov 21 16:06:23 JST 2016
パッケージ（glic）などのアップデートで上記の設定が飛ぶことがあるらしい……？ この clock も設定しておけばオッケーらしい。
[root@localhost ~]# vi /etc/sysconfig/clock
#ZONE="UTC" #UTC=true ZONE="Asia/Tokyo" UTC=false
こっちはリブートしないと反映されない系のはず。
ロケ地：AWS@m3.medium以上
m3.medium 以上のインスタンスを利用すると、永続化された領域（エフェメラルストレージ）が本当に少々ですが、ついてきます。 もちろん、インスタンス作成時にストレージの設定で「EBS」以外を選んで設定していれば、ですが。 今回は、その永続化された領域をすべて swap に割り当てます。
lsblk を実行して、マウントされているデバイスを確認します。
[root@ip-114-5-11-4 ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 30G 0 disk └─xvda1 202:1 0 30G 0 part / xvdb 202:16 0 4G 0 disk /mnt
SIZE が 4G の xvdb が今回の対象です。
/mnt が設定されていますが、とりあえず不要なのでアンマウントします。
[root@ip-114-5-11-4 ~]# umount /mnt
swap 領域を作成します。この時指定するのは、lsblkで確認したデバイスです。
※2016/12/27修正：mkswap と記述する所を swapon にしていましたすんませへぇん！
[root@ip-114-5-11-4 ~]# mkswap /dev/xvdb mkswap: /dev/xvdb: warning: wiping old ext3 signature. Setting up swapspace version 1, size = 4188668 KiB no label, UUID=1145141-9198-9381-0000-000000000000
作成した swap 領域を設定します。これで swap を利用できるようになります。
[root@ip-114-5-11-4 ~]# swapon /dev/xvdb
[root@ip-114-5-11-4 ~]# free -m
total used free shared buff/cache available
Mem: 3602 807 2577 16 217 2645
Swap: 4090 0 4090
ハイオッケー！
今の状態だと無対策なので、reboot されると swap の設定が剥がれて利用できなくなってしまいます。 fstab に設定を書いて、rebootされても大丈夫なようにします。
[root@ip-114-5-11-4 ~]# vi /etc/fstab
#/dev/xvdb /mnt auto defaults,nofail,comment=cloudconfig 0 2 /dev/xvdb swap swap defaults 0 0
ハイこれでオッケー！
ロケ地：AWS@t2.micro
いつも筐体用意してインストール時にロケール指定しとったから意外と気付かなかったんや！ワイが AWS noob なだけや！
[root@localhost ~]# timedatectl set-timezone Asia/Tokyo
参考：
CentOS7 から ntpd の代わりに chrony といヤツが用意されました。 minimal だとインストールされないはずなので、利用する場合は以下の手順で。 同期先のサーバは標準だと「centos.pool.ntp.org」です。
[root@localhost ~]# yum install chrony [root@localhost ~]# systemctl restart systemd-timedated
AWS 上で RDS 使ってて「UTC やんけ JST にしたろ！」みたいな記事は見るけど、生の MySQL ってそういえばどうなん？ってなったので、インストールから一式試してみました。
ロケ地：EC2@t2.micro MySQL 5.7.16
[root@ip-172-31-25-109 ~]# yum update [root@ip-172-31-25-109 ~]# yum localinstall http://dev.mysql.com/get/mysql57-community-release-el7-9.noarch.rpm [root@ip-172-31-25-109 ~]# yum install mysql-community-server その他client等必要そうなものをインストールする [root@ip-172-31-25-109 ~]# mysql_secure_installation #=> 設定を行う
作業したのが 21 時頃だったので、-9:00 の UTC で時間は合ってる。
mysql> select now(); +---------------------+ | now() | +---------------------+ | 2016-11-15 12:20:44 | +---------------------+ 1 row in set (0.00 sec) mysql> show variables like '%time_zone%'; +------------------+--------+ | Variable_name | Value | +------------------+--------+ | system_time_zone | UTC | | time_zone | SYSTEM | +------------------+--------+ 2 rows in set (0.00 sec)
現在の接続で利用してるセッションだけ、JST っぽい値にしてみる。
mysql> SET @@SESSION.time_zone = "Asia/Tokyo"; ERROR 1298 (HY000): Unknown or incorrect time zone: 'Asia/Tokyo' mysql> SET @@SESSION.time_zone = "JST"; ERROR 1298 (HY000): Unknown or incorrect time zone: 'JST' mysql> select * from mysql.time_zone; Empty set (0.00 sec)
だめー、各種タイムゾーンの情報もインポートされてない状態。 ここで一度 MySQL を抜ける。
ここで MySQL を動作させている Linux 自体の時間とロケールを確認する。
[root@ip-172-31-25-109 ~]# timedatectl status
Local time: Tue 2016-11-15 12:21:39 UTC
Universal time: Tue 2016-11-15 12:21:39 UTC
RTC time: Tue 2016-11-15 12:21:39
Time zone: UTC (UTC, +0000)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: no
DST active: n/a
[root@ip-172-31-25-109 ~]# timedatectl set-timezone Asia/Tokyo
[root@ip-172-31-25-109 ~]# timedatectl status
Local time: Tue 2016-11-15 21:21:49 JST
Universal time: Tue 2016-11-15 12:21:49 UTC
RTC time: Tue 2016-11-15 12:21:48
Time zone: Asia/Tokyo (JST, +0900)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: no
DST active: n/a
再び MySQL にログインする。
mysql> select now(); +---------------------+ | now() | +---------------------+ | 2016-11-15 12:22:59 | +---------------------+ 1 row in set (0.00 sec) mysql> show variables like '%time_zone%'; +------------------+--------+ | Variable_name | Value | +------------------+--------+ | system_time_zone | UTC | | time_zone | SYSTEM | +------------------+--------+ 2 rows in set (0.00 sec)
UTC のまま。
ここで mysqld を再起動する。
[root@ip-172-31-25-109 ~]# systemctl restart mysqld mysql> show variables like '%time_zone%'; +------------------+--------+ | Variable_name | Value | +------------------+--------+ | system_time_zone | JST | | time_zone | SYSTEM | +------------------+--------+ 2 rows in set (0.00 sec)
おっ。
mysql> select now(); +---------------------+ | now() | +---------------------+ | 2016-11-15 21:39:48 | +---------------------+ 1 row in set (0.00 sec)
わあい。
という訳で、timedatectl set-timezone したあとに、プロセスの再起動をすればシステムのロケールと同期を取ってくれるようです。 特に my.cnf に設定を追記することもないでしょう。
mysql> select * from mysql.time_zone; Empty set (0.00 sec)
インポートしなくてもシステムのタイムゾーンに合わせるなら、mysql.time_zone は空でも良いのですかね。 （過去の記事なんかを見てると、変更したい時はインポートしよう！というものをいくつか見ました。）
このあと、以下のようにすると怒られるので、やっぱ mysql.time_zone にインポートしないとシステム外のタイムゾーンは設定できないようですね。
mysql> SET @@SESSION.time_zone = "UTC"; ERROR 1298 (HY000): Unknown or incorrect time zone: 'UTC'
あとログファイルに出力される時刻が違うとかだとこういうのがあるらしい。
気をつけるべき点が一杯ありますねえ。
再現性は不明。
ロケ地：自分のMacbookPro@OSX El Capitan
vagrant up したら、前日まで利用していた環境が起動しない。 起動時のログを確認した所、vagrant box add したときに指定した box から、新しい VM 環境を作成している模様。
User-MacBook-Pro:rvm_vagrant user$ vagrant up Bringing machine 'default' up with 'virtualbox' provider... ==> default: Importing base box 'rvm_vagrant'...
なんか Importing とか出てるんですけお！ ちなみにこの様になるまえは、起動するとこのようなログが出ていた。
User-MacBook-Pro:rvm_vagrant user$ vagrant up Bringing machine 'default' up with 'virtualbox' provider... ==> default: Clearing any previously set forwarded ports... ==> default: Clearing any previously set network interfaces... ==> default: Preparing network interfaces based on configuration...
明らかにおかしい。
ははぁん、なるほど。
User-MacBook-Pro: $ VBoxManage list vms
"rvm_vagrant_default_1145141919893_46157" {0a5f536c-1fd5-40d5-8f7f-8c62749a9e11} <=こっちを使いたい
"centos6_mysql55_default_1145141919810_91735" {215b5e22-dffa-468f-bfee-83865f23d1c5}
本来利用したい「rvm_vagrant_default_1145141919893_46157」の UUID とは別の UUID が書き込まれているのを確認したので、書き換えてみる。
User-MacBook-Pro:vi /PATH/TO/.vagrant/machines/default/virtualbox/id #=> 0a5f536c-1fd5-40d5-8f7f-8c62749a9e11 に書き換える
User-MacBook-Pro: $ vagrnt up Bringing machine 'default' up with 'virtualbox' provider... ==> default: Clearing any previously set forwarded ports... ==> default: Clearing any previously set network interfaces... ==> default: Preparing network interfaces based on configuration... ...
おっやったｚ
default: Warning: Authentication failure. Retrying...
デデドン！
とりあえず vagrant の UUID はちゃんとつけ変わったようなので、このエラーの対処をする。
鍵が異なっているらしい。 VM と紐付けが変わった時になんかあったのかもしれん。原因は不明。 とりあえず鍵を作成しなおす。
User-MacBook-Pro: $ cd /PATH/TO/VAGRANTFILE User-MacBook-Pro: $ vagrant ssh-config ... IdentityFile /Users/hoge/key ...
IdentityFile に記載された鍵を使って ssh-keygen する。
User-MacBook-Pro: $ ssh-keygen -yf /Users/hoge/private_key > ./publickey
これをどうにかして、先程 UUID を書き換えた対象の VM へ持っていき、authorized_keys に書き込む。
今回は、VirtualBox の GUI から起動して、CLI を起動した所、ホストの Macbookpro の IP が見えたので、 MacOSX 側の SSH を許可して、SCP で取得させたのち、authorized_keys にリネームした。 （クリップボード共有が動かなかったのでこのような手段をとったが、クリップボード共有できている場合はコピペすればいい。）
編集終わったら、一応 sudo halt とかして一度 VM を止めておくといい。
ここまでやったので、改めて vagrant up する。
User-MacBook-Pro: $ vagrant up Bringing machine 'default' up with 'virtualbox' provider... ==> default: Clearing any previously set forwarded ports... ==> default: Clearing any previously set network interfaces... ==> default: Preparing network interfaces based on configuration... ... ==> default: Machine already provisioned. Run `vagrant provision` or use the `--provision` ==> default: flag to force provisioning. Provisioners marked to run always will still run.
やったーなおった！ このあと、vagrant ssh も無事疎通を確認できた。
カジュアルに紐付けが壊れるらしいので、壊れたらカジュアルに修正すること。 実は今回この現象に初めて遭遇したけど「本番デプロイするかー」とおもって vagrant up したら遭遇したので、めっちゃびっくりした。
