さくらのVPSにMongo Rescueのリストアができなかった (未解決) | tech - 氾濫原 の続きで、結局クリーンインストールした。さっき DNS を切り替えたので様子見。一応 DNS の TTL 時間はとっくにすぎたので、変な BOT 以外はいまのところ旧サーバにアクセスない。
どうやったかのメモはまた別にかく
一通り移行できたつもりだけど、元々雑多なサーバ内容かつ長期運用していたのでよくわからない。外形監視を自宅 Raspi からやっておくべきだったかなあ。
プランは東京 2GB SSD にした。前がだいぶ古い大阪 1GB HDD プランだったので SSH で繋いで体感できるぐらいパフォーマンスあがった。ウェブ側も早くなってて Google からの評価があがるといいんだけどな〜
カスタムOSインストールガイド - Ubuntu 16.04 – さくらのサポート情報 を見ながらインストールまでやる。
旧サーバと同じホスト名にしてDNSをふりかえたいが、DNS やホスト名まわりは最後にやる。
手元からまず copy-id
$ ssh-copy-id user@ufhostname
リモートの設定をかえる
$ sudo vi /etc/ssh/sshd_config PasswordAuthentication no PermitRootLogin no UsePAM no $ sudo /etc/init.d/ssh restart # 別のターミナルを開いて ssh できることを再度確認
ssh, http, https と mosh 用の udp ポートをあけておく (該当するソフトウェアをインストールすると勝手に空いたりするのだが念のため)
sudo ufw default deny sudo ufw allow 80 sudo ufw allow 443 sudo ufw allow 22 sudo ufw allow 60000:61000/udp sudo ufw enable
sudo apt-get install zsh gcc libncurses5-dev language-pack-ja git daemontools daemontools-run mysql-server ca-certificates cpio curl dnsutils imagemagick imagemagick-common irssi libcairo2-dev libcurl4-openssl-dev mime-support nginx nginx-common nginx-full ntp ntpdate optipng pkg-config rsync shared-mime-info w3m wget xz-utils xml-core zip libxml2-dev libtiff5-dev libssl-dev libsqlite3-dev libreadline-dev libpng12-dev libpango1.0-dev libopenjpeg-dev libmysqlclient-dev libjpeg8-dev libgif-dev libfreetype6-dev libffi-dev cmake screen ruby-dev rrdtool libdb-dev postfix unattended-upgrades
sudo ln -s /etc/service /service
home ディレクトリごとまるごと移す
一時的に sudo で rsync をつかえるようにする
$ sudo vi /etc/sudoers.d/rsync Defaults env_keep += "SSH_AUTH_SOCK" Defaults!/usr/bin/rsync !requiretty cho45 ALL=(ALL) NOPASSWD: /usr/bin/rsync ||< >|| ## dry-run sudo rsync --dry-run -auvz -e 'ssh -i /home/cho45/.ssh/id_ecdsa' --rsync-path='sudo rsync' --progress /home/cho45/ cho45@160.16.210.51:/home/cho45/
/srv /etc/nginx /etc/postfix # /etc/mysql 変更点がなかった。。。あらためて見直そう /etc/letsencrypt # /var/lib/mysql mysqldump でやった # /service 手動でやる
意外とうつすのない?
git の HEAD を入れてるので再度コンパイルして /usr/local にインストール
cd ~/project/h2o git clean -f cmake -DWITH_BUNDLED_SSL=on . make sudo make install
ログファイルを /var/log/h2o に作るようにしてるが前もってディレクトリがないとしぬ
sudo mkdir /var/log/h2o
/var/log/h2o/*.log {
daily
missingok
rotate 90
compress
delaycompress
notifempty
create 0640 www-data adm
sharedscripts
postrotate
svc -h /service/h2o
endscript
} 5.14.4 が gcc の関係?で入らなかったので、これを期に 5.22.2 に移行
perlbrew install perl-5.22.2 --as perl-5.22
前のマシンで perlbrew list-modules した結果を保存して cpanm にくわせてインストール。入らないやつが無視されるので、完全ではないがだいたい入る。
5.22 で動かなくなったコードを地味に修正したりした。
db ファイルだけ rsync したらいけるだろと思ったけど割といけなかったので、dump して restore する。mysql 自体のバージョンもあがってるのでまぁこのほうがよさそう。
mysqldump -uroot --routines --all-databases --flush-privileges | ssh cho45@160.16.210.51 'mysql -uroot'
たいしてデータ入ってないので一瞬。--routines でユーザテーブルもコピーしている。 --flush-privileges をつけないとコピーしたユーザデータが反映されないのでつけとく。
160.16.210.51 www.lowreal.net 160.16.210.51 lowreal.net 160.16.210.51 cho45.stfuawsc.com 160.16.210.51 coqso.lab.lowreal.net 160.16.210.51 no-real.net 160.16.210.51 block.lab.lowreal.net
みたいなのを /etc/hosts に書いて検証。証明書も転送して設定済みなので DNS だけ書きかえればうごいてくれるという感じのはず。。
DNS の向き先を新サーバに向ける
さくらのVPSはA レコードがひけてないと逆引き設定がつくれないので、Aレコードが適用されたあとにやる。
/etc/hostname も変える。
ここまでやったら一旦リブート。30秒ぐらいで起動するのでたすかる……
旧サーバからぬいてくる
crontab -l > crontab.user sudo crontab -l > crontab.root
新サーバに適用する
crontab crontab.user sudo crontab crontab.root
/etc/sysctl.conf に追記
net.core.somaxconn = 50000 net.ipv4.tcp_max_syn_backlog = 30000 net.core.netdev_max_backlog = 5000 net.ipv4.ip_local_port_range= 1024 65535
sudo sysctl -p で反映
これだけ買った。本当はおむつが欲しいんだけど、欲しいブランドのものがなかった…
定期便でも頼んでるけど、定期便で頼んでいると在庫確認に無頓着になりがちで
の二択になる。適切な配達間隔を設定すること自体が難しい。定期便自体が月イチの決まった日付前後の配達になるので「なくなりそうだから頼もう」と思ったタイミングだと時既に遅しということがある。
結局
のいずれかになる。
おむつの場合ストックがものすごい邪魔なので、多めに頼むってのが難しい。それと成長にともなって商品変更を迫られるので、そもそも大量に買いたくない。おかげで、なくなりそうになったらプライムで追加発送とか、近くのドラッグストアで買うみたいな運用になる。
Dash Button だと「足りない」と気付いたときにすぐ買うという場合は便利そう。そして物理ボタンなので家族で共有して押せるというところが便利。洗剤とかだと気付いた人が詰めかえるという運用なので「なくなったから買って」「忘れてた」「はやく買って」「カートにはいれた」みたいなことが発生してめんどうくさい。
ただし「もうすぐ定期便で届くし、それまでは在庫持つよ」というケースでも発注してしまうことが予想できてちょっとむずい。
キャッシュの持ちかたを変えて、圧縮 (gzip) して持つように変えた。キャッシュを返すときは gzip ずみのをそのまま返すように。
gzip 非対応ブラウザでおかしくなる気がするけど、昨今そんなブラウザは聞いたことがないので現実的には問題なかろうという気がする。
これによりキャッシュ用のDBファイル(SQLite)のサイズが劇的に減ったので、ファイルキャッシュに乗りやすくなったはず……
誤り訂正や、超解像技術みたいなのを前提とした圧縮方法に興味がある。なんとなく面白い感じがする。本来存在していたデータを意図的に削って送って、受取側の「経験」みたいなものを信用する感じが面白い。
画像圧縮も、CPU速度と帯域を比べたときに帯域で律速されるぐらいに高解像度になると、ディープラーニングによる高解像度化や、自動色付けを前提とした画像圧縮アルゴリズムが産まれても不思議ではない。
つまりこれは「おい」と言うとお茶がでてくるみたいなシステム。これがコンピュータで実現すると面白い。送信側の「意図」みたいなものを最大限推論してデータを復元し、転送データを最小限にできる。