
komi
mysql5.6レプリケーションでold_passwordが拒否される
...こんにちは。小宮です。
同僚の湯尾さんから教えてもらった情報を貼っておきます。
【mysql5.6レプリケーション仕様が変わった話】
某環境で mysql5.5でフルdumpしたSQLを5.6に流し込む作業を行い、その後差分データを5.5→5.6にレプリケーションしようとしたところ レプリケーションが出来なかったという症状がありました。
その後、mysql5.6の設定見直しのため
stop slaveしてmysqlをrestartしレプリケーション貼り直しと試みましたが 今度は5.6環境同士でもレプリケーションが貼れなくなりました。原因はmysql5.6から
secure_authの仕様が変更されたためクライアント([mysql]以下の記述)設定でskip-secure-authが設定されていても レプリケーションIOの時点でold_password(16桁パスワード)が拒否されるためレプリケーション自体開始できないとのことです。 ステータス(show slave status\G)では下記の様になります。------------------------------- ・・・ Slave_IO_Running: Connecting Slave_SQL_Running: Yes ・・・ Last_IO_Errno: 2049 Last_IO_Error: error connecting to master 'repl@172.17.xx.xx:3306' - retry-time: 60 retries: 1 Last_SQL_Errno: 0 Last_SQL_Error: ・・・ -------------------------------解決策として、お客様の許可を得て、mysql5.5、5.6環境の両方に新たにセキュアなレプリケーション用アカウントを作成して、それでレプリケーション貼りました。 セキュア(
old_passwordではない)なパスの作り方は下記の通り。------------------------------- set session old_passwords = 0; GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'newrepuser'@'172.17.xxx.%' IDENTIFIED BY 'xxxxxxxxxxxxxx'; -------------------------------mysql5.6にデータ移設したいなど相談を受けた場合は、パスワードの桁数にご注意下さい。という話です。
Chef-Soloから卒業、chefのlocalmodeをつかってみた
...こんにちは。小宮です。
事の経緯
お急ぎの場合は飛ばして大丈夫です。 Chef-Soloがdeprecated(非推奨)とかで開発元からchef-zero(localmode)をつかうよう周知されたのが半年くらい前でしょうか。 当時はどうしたらええんやと色々比較してみたりしたあげく時が経ってとうとう検証することに。 数年で入れ替わるのではなく長く続くことが前提だとコストをかけても技術的負債を残したくない事情があるケースもあるようで。 個人的には正直コストをかけて移行するかどうかは微妙なところで、soloがすぐ無くなるみたいな話ではない気がしてます。 世の中的にはcookpadさんからitamaeとか出てたりAnsibleが流行ったりなど。 Ansibleはnot_ifに相当する機能を持たせようとするとドライランできなくなるみたいなのが致命的らしいと聞いたけど、 そもそもYAMLに書きなおすコストがあり得ないので試してないです。 itamaeも気になってたんですがroleとenvironmentをattributeになおす手間がありそうでした。 roleもenvironment数もそれなりの規模で配列attributeを優先順位で意図的にdeepmergeしたり初期化するようなことをしてるし その修正はだいぶヘビーな気が。あとdata_bags機能がないのも超困る。他に移行するにはchefの沼にだいぶつかりこんでいたようです。。 あとChef-Serverはコミュニティ版はHA機能がNGだときいたりしました。
現実的にはlocalmodeだろうということでそんな感じでいつもどおり右往左往で検証してみましたので備忘録です。
chefって情報は結構あるんだけどモヒカンの人(技術レベルの高すぎる人)ばっかりなため初心者がどこで惑うか想像つかないのか肝心なところが分かりづらくて 結局念入りにヘルプを眺めたりググりまくって試しまくるなどというのが多いような。。 使い方も多くてそれぞれの環境が違って色々まざると発狂ちょっとこんがらがりやすいかもしれません。
後日、分かりやすい素敵なチャートをみかけたので追記しておきます。 あなたに合ったChefはどれ? 〜 おすすめ構成確認チャート #getchef - クリエーションライン株式会社
普及と発展には分かりやすさというのはとても重要かなと思います。こんな感じのやってみた記事が多少それに寄与するといいなーと思います。
参考情報
まあ色々みてみたんで参考情報からご紹介いたしましょう。パターン分けておきます。 Chef-Zeroの仕組みとか機能とかの話は別途ググっていただくと分かりやすいと思うんですが、、 インメモリChef-Serverとローカルモードの違いがありまして、私がやりたいのはローカルモードのほうです。 インメモリChef-Serverとして使う場合は Chef-Zeroを起動してcookbookとroleとenvironmentとdata_bagsのデータなんかをknifeコマンドで登録しておく必要があるようです。 インメモリなので、Chef-Zeroを停止すると登録したデータは消えます。 なので手間を考えるとChef-Serverへの移行を見据えて1次的にとかchef-shellでとれる情報をみたい時に使うという用途になるのかなーと思いました。 ブラウザからアクセスすると登録したjson情報などが見えるのはまあ便利と言えば便利かもしれないけどgitでみればいいやんというレベルだったかなあ。 ローカルモードとして使う場合は、コマンド実行時だけChef-Zeroが内部的に起動してレシピ適用終わったら落ちるようで、 knife.rbに書いといたChef-Repoのパスを勝手に見てくれて余計な手間はなさそうでした。
・Chef-ZeroをインメモリChef-Serverとして動かしたいタイプ Amazon Linuxで簡易Chef Server(chef-zero)を動かしてみた | Developers.IO CentOSにchef-zeroのインストール - clavierの日記 chef-zero を構築して knife-xenserver と連携してみた一部始終 - ようへいの日々精進 XP Ruby - knife zero bootstrap で リモートに chef がインストールできない - Qiita 軽量簡易Chef Server「chef-zero」を使ってみよう #opschef_ja « CREATIONLINE, INC. 【#Docker】Chef Zero を軽量インメモリ Chef Server として使い、ホスト OS から Docker コンテナを Chef で管理する #Chef #GetChef_ja - Qiita
gitlabの導入方法のメモ
...こんにちは。小宮です。先輩から要望されていそうな気がしたのでgitlab導入時のメモです。。
やたらめったら長いし手順が複雑でこのとおりやって再現できるかはお使いの環境に依存する可能性があり保障できかねます。 この手順で再現した環境はOSはCentOS6.5でした。 postgresを許容できるのであれば自動的に入れられるオムニバス版があるのでそちらをお使いいただくのがよろしいかと。 個人的にpostgresの運用の知見が心もとなかったのと、RDSに逃げられなくなるのがアレだったのでmysqlで頑張りました。
自分で自動化する時は、passengerとgitlab:setup時の対話処理をなんとか自動化するオプションを付けるとこがキモかと思いました。 この手順自体は部分的にchefがでてきますがほぼ手動です。自動化オプションは最後のほうにちょろっと書いときます。
1.このへんからmysqlをなんとかして入れとく
$ wget http://ftp.jaist.ac.jp/pub/mysql/Downloads/MySQL-5.6/MySQL-5.6.17-1.linux_glibc2.5.x86_64.rpm-bundle.tar -P site-cookbooks/mysqld/files/default/usr/local/src/2.rbenv等でrubyをなんとかして入れておく
(chefでなにもせずにやるとchefgemに寄るので注意がひつよう) rubyのバージョンが低いとGemfileのシンタックスチェックでエラー出てmysql2とかが入らないことも。
3.Gitのインストール
# yum -y install libcurl-devel libxslt-devel libxml2-devel expat-devel gettext openssl-devel zlib-devel Installed: libcurl-devel.x86_64 0:7.19.7-37.el6_4 libxml2-devel.x86_64 0:2.7.6-14.el6 libxslt-devel.x86_64 0:1.1.26-2.el6_3.1 Dependency Installed: libgcrypt-devel.x86_64 0:1.4.5-11.el6_4 libgpg-error-devel.x86_64 0:1.7-4.el6 # su - chef;cd infra-chef-repo/ $ knife cookbook create git -o site-cookbooks $ knife cookbook create redis -o site-cookbooks $ vi site-cookbooks/git/recipes/default.rb # # Cookbook Name:: git # Recipe:: default # # Copyright 2014, YOUR_COMPANY_NAME # # All rights reserved - Do Not Redistribute # %W{libcurl-devel libxslt-devel libxml2-devel expat-devel gettext openssl-devel zlib-devel libgcrypt-devel libgpg-error-devel}.each do |pkg| package pkg do not_if "rpm -qa|grep #{pkg}" action :install end end bash "bash-install-git" do not_if "ls -d /usr/local/src/git-1.9.0" code <<-EOC wget https://git-core.googlecode.com/files/git-1.9.0.tar.gz -P /usr/local/src cd /usr/local/src/ tar zxf git-1.9.0.tar.gz cd /usr/local/src/git-1.9.0 ./configure --prefix=/usr/local/git make all make install ln -sf /usr/local/git/bin/git* /usr/local/bin/ EOC end $ knife solo cook localhost -o git # wget https://git-core.googlecode.com/files/git-1.9.0.tar.gz -P /usr/local/src # cd /usr/local/src/ # tar zxf git-1.9.0.tar.gz # cd /usr/local/src/git-1.9.0 # ./configure --prefix=/usr/local/git # make all # make install # ln -s /usr/local/git/bin/git* /usr/local/bin/ # which git /usr/local/bin/git # git --version git version 1.9.04.redisのインストール
# yum install -y --enablerepo=remi redis Installed: redis.x86_64 0:2.8.9-1.el6.remi Dependency Installed: gperftools-libs.x86_64 0:2.0-11.el6.3 libunwind.x86_64 0:1.1-2.el6 # /etc/init.d/redis start # chkconfig redis on # redis-cli ping PONG $ vi site-cookbooks/redis/recipes/default.rb bash "yum-install-redis-from-remi" do not_if "which redis-cli" code <<-EOC yum install -y --enablerepo=remi redis EOC end service "redis" do supports :status => true, :restart => true action [ :enable, :start ] end $ knife cookbook test redis $ knife solo cook localhost -o redis5.ユーザ作成
# useradd -c 'GitLab' git # chmod 755 /home/git # su - git -s /bin/bash $ mkdir .ssh $ touch .ssh/authorized_keys $ chmod 600 .ssh/authorized_keys $ chmod 700 .ssh $ git config --global user.name "GitLab" $ git config --global user.email "gitlab@localhost" ##### 6.gitlab-shellのインストール $ git clone https://github.com/gitlabhq/gitlab-shell.git -b v1.9.4 $ cp -a /home/git/gitlab-shell/config.yml{.example,} $ /home/git/gitlab-shell/bin/install install失敗する場合は、gitユーザの.bashrcか/etc/profile.d/の下あたりに環境変数を追加し読み込みしてから再実行 export PATH=/path-to-ruby:$PATH8.gitlabインストール
$ git clone https://gitlab.com/gitlab-org/gitlab-ce.git -b 6-8-stable gitlab $ cp -a /home/git/gitlab/config/gitlab.yml{.example,} 不要っぽい -------------------------- $ chmod -R u+rwX /home/git/gitlab/log/ $ chmod -R u+rwX /home/git/gitlab/tmp/ $ mkdir /home/git/gitlab/tmp/pids/ $ mkdir /home/git/gitlab/tmp/sockets/ $ chmod -R u+rwX /home/git/gitlab/tmp/pids/ $ chmod -R u+rwX /home/git/gitlab/tmp/sockets/ $ mkdir /home/git/gitlab/public/uploads $ chmod -R u+rwX /home/git/gitlab/public/uploads -------------------------- $ mkdir /home/git/gitlab-satellites $ ll -d /home/git/gitlab-satellites drwxrwxr-x 2 git git 4096 5月 19 12:20 2014 /home/git/gitlab-satellites $ $ ll -d /home/git/gitlab-satellites drwxr-x--- 2 git git 4096 5月 19 12:20 2014 /home/git/gitlab-satellites $ cp -a /home/git/gitlab/config/unicorn.rb{.example,} $ cp -a /home/git/gitlab/config/initializers/rack_attack.rb{.example,} $ cd /home/git/gitlab $ git config --global user.name "GitLab" $ git config --global user.email "gitlab@localhost" $ git config --global core.autocrlf input9.DB設定
$ cp -a /home/git/gitlab/config/database.yml{.mysql,} $ vi /home/git/gitlab/config/database.yml $ diff /home/git/gitlab/config/database.yml{.mysql,} 10,12c10,12 < username: git < password: "secure password" < # host: localhost --- > username: gitxxxxx > password: "xxxxxxxx" > host: localhost $ ls -al /home/git/gitlab/config/database.yml -rw-rw-r-- 1 git git 777 5月 19 12:32 2014 /home/git/gitlab/config/database.yml $ chmod o-rwx /home/git/gitlab/config/database.yml $ ls -al /home/git/gitlab/config/database.yml -rw-rw---- 1 git git 777 5月 19 12:32 2014 /home/git/gitlab/config/database.yml $ vi /home/git/gitlab/config/gitlab.yml $ diff /home/git/gitlab/config/gitlab.yml{,.example} 227c227 < bin_path: /usr/local/bin/git --- > bin_path: /usr/bin/gitローカル等てきとうなところ(database.ymlに指定したところ)にDBをなんとかしていれる
chefのruby_blockを用いて環境変数を再読み込み
...こんにちは。小宮です。
chefでいろいろ自動化していくうちに、途中で変更された値というか変数を使いたい場合が出てくるのかなと思います。 1回目は上手くいかないけど2回目は上手くいくというような冪等にならない怪現象を解決したいと思う時がそのうちきます。 そんなとき、、 ohaiで値がとれる場合はそれを使いなければohaiのプラグインを自作するか、 ruby_blockを書いたり、notifiesで:immediatelyとかつけて呼び出すって感じの対応が必要になったりします。。
何言ってっかわかんねえ!と思うかたは以下のリンク先にchefの実行順序に関して書かれているので見てみるといい気がします。 Chefのレシピは上から下に実行されるという誤解 | Engine Yard Blog JP
これだけだと不親切かもしれないので以下ご参考まで。
template "/etc/profile.d/rbenv.sh" do not_if "grep rbenv /etc/profile.d/rbenv.sh" source "rbenv.sh.erb" action :create notifies :create, "ruby_block[initialize_rbenv]", :immediately end ruby_block "initialize_rbenv" do block do ENV['RBENV_ROOT'] = node[:rbenv][:root] ENV['PATH'] = "#{node[:rbenv][:root]}/bin:#{node[:rbenv][:root]}/shims:#{node[:ruby_build][:bin_path]}:#{ENV['PATH']}" end action :nothing end少し解説しますと、 chefではレシピ中での改変を前提とした処理はくふうがひつようで、 rubyで書かれた処理はconvergeの手前で行われてしまってその時点では途中の改変を認識できないようです。(だから2回目に成功する) ruby_blockリソースはconvergeのタイミングと同じ時に動くようです。 特定のリソースの処理が行われるときだけ実行したい場合にはそのリソースのnotifiesにはタイミングを指定できます。(:immediatelyとか:delayedとかあるらしい) この場合、ruby_blockリソースのactionにはnothingを指定しておき、templateリソースでprofileの設定を置いて:immediatelyをnotifiesに指定することで ただちに変数の再読み込みが実行される、という話になります。(レシピを分けてる場合にnotifiesつかうと-oで個別実行しにくくはなりそう。)
AWSのSecurityGroup関連の調査・更新CLIメモ
...こんにちは。小宮です。
今回ご紹介するのはpiculetでgroupファイルでルール更新というのではありません。 ちょっと整理とか削除とかしたいけど手でポチぽちするには量が多いしオペミスが心配だし手間だし早く帰りたいので どれに紐づいてるのか一括で調べたい一括更新したいといった時にforループとCLIでなんとかする方法です。 SecurityGroupの上限緩和申請の際にSGの書き方的に通信パフォーマンスがアレで引っ掛かった時等にこんなような作業が必要に。
あんまり使いこなせてるほうでもないのですが、一応載せておきます。ご利用は自己責任でお願いします。 みなさま似たようなことしててもっと洗練されたやり方をご存知の方も沢山いそうです。 弊社だと稲田さんほか協力部隊の方々がもっと詳しそうな気がします。マサカリ歓迎いたします。 稲田さんに聞いたらもっとoutputはtextにしてjoinを使いこなせと言っていたのでそのうち何か書いてくれると思います。
SecurityGroupのidから紐づくインスタンス情報を得る
これは既存の情報を得るだけで更新しないので気軽に実行できると思います。 まずリストを作る(消したいSGをいれる)
vi listfile sg-xxxxxxxx,SG_hoge_dev1 sg-yyyyyyyy,SG_fuga_dev2 ... list=listfile profile=xxxxリストを読み込んでdescribe-instancesを実行
for i in `cat $list|grep -v elb` do groupid=`echo $i |awk -F, '{print $1}'` groupname=`echo $i |awk -F, '{print $2}'` echo $i aws ec2 describe-instances --profile ${profile} --filters Name=instance.group-id,Values=$groupid --output text \ --query 'Reservations[].Instances[*].[InstanceId,PrivateIpAddress,Tags[?Key==`Name`].Value[]]' --output json \ |sed -e '/\]/d' -e '/\[/d' -e '/^$/d' -e 's/ //g'|perl -pe 's/,[ ]*\n/,/g'|sort -t , -k 3 echo "" done出てきた結果からlistfileをつくりSGはずしたり替えたりするときにつかいます。
opsだけどgitを使ってみた~その2
...こんにちは。小宮です。 前回のつづきです。今回はgitマージとタグとコンフリクトの話を書きます。 まあ初心者が慣れてきた頃の様子ということで生温かく見守ってください。 git-flowやブランチモデルがどうという話はでてきません。
git branch でブランチを切る
現在居る場所を確認する
$ git branch -a add_custom_repository * masteraddしただけのやつがないのを確認します。
$ git status # On branch master # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: .gitignore # no changes added to commit (use "git add" and/or "git commit -a")※万が一addしただけのやつがある場合、commitするかstashするかする必要があります。
bashのhistoryをsyslog出力、jenkinsでビルド
...こんにちは。小宮です。 セキュリティ関連のお仕事で「実行コマンドを記録したい」という要望が最近多くなってきました。 何種類か方法はあると思いますが、今回はbash_historyに時刻を入れて一つのログにまとめてみたいと思います。
これやったあと便利に感じたのはメンテナンスの時作業時刻を報告する場合にログをgrepで解決可能というところです。
jenkinsでビルドするのは、最近はやりの継続的インテグレーションということでやってみました。 最初は心理的な障壁があったんですがやってみると結構楽で手順のもれがないので良いと思いました。 脆弱性の対応で何回かビルドすることになりましたがjenkinsジョブになってるのは便利でした。
CentOS6.5です。 jenkinsさんのジョブは以下のとおりです。 単にパラメータつきのシェルの実行です。
#!/bin/bash topdir="${HOME}/rpmbuild" rpmdir="${topdir}/RPMS/x86_64" if [ -f ${HOME}/.rpmmacros ];then echo "%_topdir ${topdir}" > "${HOME}/.rpmmacros" echo "%_signature gpg" >> "${HOME}/.rpmmacros" echo "%_gpg_name D279xxxx" >> "${HOME}/.rpmmacros" fi if [ -d ${HOME}/rpmbuild ];then mv ${HOME}/rpmbuild{,.`date +%Y%m%d.%H%M`} mkdir -p ${HOME}/rpmbuild/SRPM fi case "${TARGET}" in *.src.rpm) rpm -Uvh "${TARGET}" cp -p ${topdir}/SPECS/bash.spec{,.org} sed -i 's/make "CFLAGS=$CFLAGS -fwrapv" "CPPFLAGS=-D_GNU_SOURCE -DRECYCLES_PIDS `getconf LFS_CFLAGS`"/make "CFLAGS=$CFLAGS -fwrapv" "CPPFLAGS=-D_GNU_SOURCE -DRECYCLES_PIDS `getconf LFS_CFLAGS` -DSYSLOG_HISTORY"/g' ${topdir}/SPECS/bash.spec sed -i 's/Release: 29%{?dist}/Release: 29%{?dist}_isao_5/g' ${topdir}/SPECS/bash.spec sed -i '108s/^$/\n/g' ${topdir}/SPECS/bash.spec sed -i '109s/^$/Patch145: bash-syslog_facirity.patch\n/g' ${topdir}/SPECS/bash.spec sed -i '181s/^$/%patch145 -p1\n/g' ${topdir}/SPECS/bash.spec cd ${HOME}/rpmbuild/SOURCES/ tar xzf bash-4.1.tar.gz cp -rp bash-4.1{,.org} sed -i 's/# define SYSLOG_FACILITY LOG_USER/# define SYSLOG_FACILITY LOG_LOCAL6/g' ${HOME}/rpmbuild/SOURCES/bash-4.1/config-top.h sed -i 's!(SYSLOG_FACILITY|SYSLOG_LEVEL, "HISTORY: PID=%d UID=%d %s", getpid(), current_user.uid, line)!(SYSLOG_FACILITY|SYSLOG_LEVEL, "HISTORY: PID=%d PPID=%d SID=%d User=%s UID=%d CMD=%s", getpid(), getppid(), getsid(getpid()), current_user.user_name, current_user.uid, line)!g' ${HOME}/rpmbuild/SOURCES/bash-4.1/bashhist.c sed -i 's!(SYSLOG_FACILITY|SYSLOG_LEVEL, "HISTORY (TRUNCATED): PID=%d UID=%d %s", getpid(), current_user.uid, trunc)!(SYSLOG_FACILITY|SYSLOG_LEVEL, "HISTORY (TRUNCATED): PID=%d PPID=%d SID=%d User=%s UID=%d CMD=%s", getpid(), getppid(), getsid(getpid()), current_user.user_name, current_user.uid, trunc)!g' ${HOME}/rpmbuild/SOURCES/bash-4.1/bashhist.c diff -crN bash-4.1.org bash-4.1 > ${HOME}/rpmbuild/SOURCES/bash-syslog_facirity.patch rpmbuild -ba ${topdir}/SPECS/bash.spec ;; *) echo 'environment variable TARGET must be set.'; exit 1;; esacTARGETにしたパラメータは以下です。
http://vault.centos.org/6.5/updates/Source/SPackages/bash-4.1.2-15.el6_5.2.src.rpmopsだけどgitを使ってみた~その1
...こんにちは。小宮です。 opsだけどgitを使ってみた~その1ということで、githubもgitlabもgitも初心者なので忘れないようにメモ。 今回はたどたどしくpushするところくらいまでにします。branch切ってみるとこは初回から書くとおなかいっぱいになりそうなので。 たぶんその2までです。その2はbranchとtagとconfrictのことを書いています。
背景とメリットデメリット
・背景 昨今の継続的インテグレーションだとかでchefでサーバ構築の需要があってその流れ弾に当たった機会を得たため、 そのリポジトリをバージョン管理する必要が生じましてgitをつかうことに。最初は会社のエンタープライズ版のgithubに保存してもらっていたんですが、 VPN経由でのやり取りの需要からgitlabの導入を行うことになりました。 ・gitのメリット ヒストリ追わなくていい。見える化。ファイル内の差分が見やすいので確認がブラウザで容易に可能になる ・gitのデメリット 同僚がつかいはじめてくれない(必要にせまられないと忙しくてスルー傾向) まあなんか気持ちはわかります。私もきっかけは半ば強制的な感じでした。
githubとgitlabの違い gitコマンド的にはあんま変わんない気もしますが、制度がオープン(エンタープライズはクローズ可)かクローズでいけるか、 gilabの場合は容量制限もディスク容量とかの環境次第でユーザ権限を細かく設定できたりなどするのがいい感じです。 もっというとVPN越しにしかつながらないようにしたいとかの自由がききます。共有Webサービスつかうか自前構築のつかうかの差です。 gilab導入の手間は最近はchefで気軽に入るレシピもあり軽減されてきたようです。
githubの場合、二段階認証をなんとかする
詳細な説明は省きますが、まずgithubに登録して会社のgithubの二段階認証をなんとかします →会社で用意していただいたマニュアルのとおりに実施。 要はgmailの2段階認証みたいなことで携帯にSMS通知が届いて認証する仕組みのセットアップです。
接続するホストでsshの鍵の作成と、作成した公開鍵の登録をgithub側のユーザプロファイルで行います。
pushするホストでgitを初期設定する
まずgitコマンド打つ人のユーザ情報を登録です。
git config --global user.email "komiyay@xxxxx"` git config --global user.name "Yxxx Komiya"設定ファイルにメモリ制限やスレッド数を指定しないとOutOfMemoryエラーが出ます。
$ vi ~/.gitconfig [user] email = komiyay@xxxxx name = Yxxx Komiya [core] packedGitWindowSize = 128m packedGitLimit = 128m [pack] windowMemory = 128m threads = 2 deltaCacheSize = 128m packSizeLimit = 128m※m1.smallくらいでこの設定にしました。t1.microだとメモリエラー出ました。
innodb_stats_on_metadata=1でディスク容量激増とCPU負荷が発生
...こんにちは。小宮です。 ある日chefのレシピをなおしていると、同僚がこんなことをいってきました。
「おきゃくさまがphpmyadminのinformation_schemaのリンクをクリックしたとたんに サイトが重くなってディスク容量が数十GBも増えて今下がって落ち着いたって言ってます。 なにか原因わかりますか?」phpmyadminでinformation_schemaをクリックするのが危険過ぎる - K52.NIKKI ver3.0というのが添えられていました。
よくわからなかったので現象を呟いたところ、親切なMySQLのACE(えーす)のyoku0825さんがinnodb_stats_on_metadata=1があやしいんじゃないかと教えてくれました。 ググってみたところ、innodb_stats_on_metadata に要注意 - TAKUMI SAKAMOTO’S BLOGというページを見かけて何が起きたかわかった気になったのでした。
起きたことの予測: ・テーブルの更新状況が統計情報更新の発生条件に達している状態だった ・information_schemaのリンクをクリックすることでshow table status相当の統計情報更新のきっかけになるクエリが走った ・統計情報更新のためにANALYZE_TABLE相当の処理が走った ・ディスクがあふれたのはテーブルのコピーがtmpdirに作られたためで挿げ替えられて処理が完了したために使用率が下がった ・cpu負荷はALTER相当のTABLEメンテナンス処理とそれに伴うディスクI/Oによるものと考えられる
innodbの統計情報更新の発生条件については、漢のブログに書いてあるのをみつけました。いつもありがとうございます。 めでたしめでたし。とこれだけだと物足りないのでちょっと足します。
どのバージョンでONかOFFかについて、公式のマニュアルをみると5.6.6からOFFでそれ以前はONのようです。
つぎに仮にinnodb-stats-on-metadataを0にしたばあいメンテナンスを自分で行う必要が生じるけどどうしたらええんやという話について。
基本メンテ入れて統計情報更新するだけならANALYZE TABLEするかデフラグもしたいならALTER TABLEしたほうがいいです。 InnoDBのOPTIMIZEは内部的にALTERが実行されるだけなのでREADのロックがかかるのが嫌ならALTER TABLE使うといいです。 データ(とスペック)を極力本番同様にした試験環境でかかる時間を見積もるのがオススメです。 表にマニュアルのリンクを貼っておきました。左は5.1日本語で右は5.6英語のリンクです。
・参考サイト innodb_stats_on_metadata に要注意 - TAKUMI SAKAMOTO’S BLOG 漢(オトコ)のコンピュータ道: 大人のためのInnoDBテーブルとの正しい付き合い方。 漢(オトコ)のコンピュータ道: ALTER TABLEを上手に使いこなそう。 MySQLトラブル解析入門 テーブル メンテナンス ステートメント MySQL :: MySQL 5.5 Reference Manual :: 13.7.2 Table Maintenance Statements Percona Toolkit pt-online-schema-change でサービス無停止スキーマ変更 | 外道父の匠 pt-online-schema-changeを安全につかう - Around the World
ELBでssl転送してnginxでクライアント認証とssl終端してProxyProtocolで送信元IPを取得する
...こんにちは。 タイトル長いですがだいたい成功して時がたったので需要があるかはわかりませんが記録しておきます。
お時間あるときにどうぞ。
目的としては、以下のとおりです 外部ELB→nginx(ssl終端かつクライアント認証)→内部ELB→app
つまり、クライアント認証したいけどELBにその機能はないのでtcp443転送してnginxでやるが上位サーバでとれる送信元IPがELBのIPになってしまう為 ELBでProxyProtocolを有効化してnginxでssl終端しつつProxyProtocolをListenして送信元IPをログに出したいという話です。
securityGroupやインスタンス作るなどの部分は省略します。
1.elbをawscliで作成、proxy-protocol設定
参考:
AWS ELBのProxy Protocolを触ってみた Enable or Disable Proxy Protocol Support - Elastic Load Balancing 今更 VPC で 複数の AZ をまたいだ ELB を試す(2)〜 awscli を使って 〜 - ようへいの日々精進 XP
・elb作成
profile=xxxxx elbname-ext=xxxx-elb securitygrops="sg-xxxxxxxx sg-yyyyyyyy" subnets="subnet-xxxxxxxx subnet-yyyyyyyy" sudo bash -c "aws elb create-load-balancer --load-balancer-name ${elbname-ext} --listeners Protocol=TCP,LoadBalancerPort=443,InstanceProtocol=TCP,InstancePort=443 --subnets ${subnets} --security-groups ${securitygrops} --profile ${profile}"※外部ELBはTCP443からTCP443に転送するだけで証明書を入れない感じの設定にします
packerでhvmでもresize2fsをできるようにしてrebootを回避する
...こんにちは。小宮です。 packerでhvmでもresize2fsをできるようにしてrebootを回避するというのをやってみました。
おなじことがcloud-initを用いてもできるような気がしています。 CentOS 6 (HVM)にcloud-initを設定してAmazon Linuxぽくする | Developers.IO ただしpackerつかってるのでそっちでやったほうがラクというか。 何も設定せずにcloud-initいれただけのamiつくったらログインできなかったですorz 設定ファイルに書いた内容と具体的に裏で何してくれちゃうのかちゃんと理解できないとやりたくないけど調べるのが手間だったので。 軟弱ものですみません。
・事の発端 CentOS6.5のオレ俺AMIをもとにhvmのインスタンス作ったところ、 chefレシピで流して自動でresize2fsがrootボリュームに対して実施されたはずが サイズ変わらず。 10から50GBになるはずだったけど10GBのままになっていた
・とりあえずぐぐる 以下URL先で同様の現象と対策を知る EC2のCentOS-HVMでディスクのサイズを変更する | Hack fdiskで拡張するほかにこんなやり方もあったんだーと目からうろこ。 でもってreboot必須って詰んだー!と思いました。(手間と自動化的に) 具体的にいうとresize2fsはchefレシピ流してやってるのでログインしてやるのは二度手間です。
・問題提起というか相談してみた (ぎじゅつ的に)とんがり系のおかたに、 パーティションテーブルの問題なら以下URLのようなのをpackerに仕込んだらどうか と提案いただいたというか教えていただきました CentOS on Amazon EC2 でディスクサイズ変更しても変わらないときの対処方法 | Developers.IO
・実際やってみたら成功した
packerに仕込んでるシェルスクリプトに以下を追加
+# growroot等をepelからインストール +yum -y --enablerepo=epel install dracut-modules-growroot cloud-utils + +# rootパーティションテーブルをリサイズ +dracut --force --add growroot /boot/initramfs-$(uname -r).imgで、packerでAMIをビルド、 そのAMIから作成したインスタンスにchefレシピを流してみると、 dfしてみたところディスクが拡張されてました。 rebootしなくて済んだ!!わーい! めでたしめでたし。
data_bagsの用途について
...こんにちは。小宮です。 data_bagsについて内部的に解説する必要が生じたのでこちらにも書いておきます。
最近のdata_bagsの活用方法は以下のとおり
1.LDAPで管理していないシステム用途のOSユーザ情報をロードしてレシピで追加 2.SSL証明書の格納とレシピからロードしてtemplateで設定 3.ntpサーバの情報のロードとtemplateで設定 4.awsのクレデンシャル情報を管理して各種スクリプトへ埋め込み 5.mysqlやldapなどのパスワードなどアカウント情報の管理 6.roleとenvironmentに収まりきらないnginxやapacheのvhostやupstream等の情報の管理 7.gangliaのhead_nodeやcluster_nameの情報の管理
0.下準備的な解説
※前提条件としてchef-soloの場合"knife-solo_data_bag"というgemが必要なので入れる。 (gem listでなければgem installかbundlerで入れてください)
格納方法と確認方法
暗号化しない場合、viなど任意のエディタで編集OK chef-repository/data_bags/任意のディレクトリ名/任意のファイル名.json をつくる。 中身はjsonの規則にのっとっている必要があるので、シンタックスをjson_verifyでCHK。
cat data_bags/dirname/filename.json |json_verify で、JSON is valid と出るのを確認する
暗号化する場合、 まずEDITORの環境変数を~/.bashrcなりに設定しておく必要があるのと暗号化用の鍵を作って設定しておく必要がある。 (※鍵は案件ごとに異なるイメージで、.gitignoreに書いとく必要があります。 流出厳禁かつ無くすとデータが見えなくなります。)
export EDITOR=vi vi .chef/knife.rb ------コメントを外す--------------------- encrypted_data_bag_secret "data_bag_key" -----------------------------------------※コメント外すと鍵指定しなくてもknifeコマンドでcreateした場合常に暗号化される ゆえに暗号化せず扱いたいデータファイルはviで作るかコメントインしてから作る必要有
鍵が必要なら作る (※.chef/knife.rbの相対パスはchefリポジトリ直下を意味します)
openssl rand -base64 512 > data_bag_key knife solo data bag create dirname filename # 作成(※既存は上書きされる) knife solo data bag edit dirname filename # ファイルをエディタで編集 knife solo data bag show dirname filename # jsonの中身を表示 knife solo data bag list # ディレクトリ一覧表示・注意するべきこと →bashやexecuteリソースは極力使うべきではない。templateリソースつかってください。 bashでsedるとdata_bagsから変数に入れた特殊文字が展開されて意図しない値が入ったりします もうひとつ、sedると毎度毎度同じsedをする必要が生じるなど冪等にならないです。
mysqlのreplication関連リンクまとめ
...mysqlのreplication関連情報まとめ
こんにちは。小宮です。
なんだかmysqlのことを聞かれることが多い今日この頃なので、
聞かれたときコピペできるように聞かれがちなことが説明されてるリンクをまとめる試みです。
この記事だけ読んでも大したことはわかりませんのであしからずご了承ください。
(自分がすっかり忘れたときにも役立ちそうです。)・基本
現場指向のレプリケーション詳説
漢(オトコ)のコンピュータ道: MySQLレプリケーションを安全に利用するための10のテクニック
Art of MySQL Replication.
バイナリログに書かれるのは更新系のクエリです。
補足すると、I/Oエラーは、物理的にディスクが壊れた、ネットワーク的につながらない、レプリケーション用ユーザのIDとパスワードが間違っている、server_idが重複している
などの理由で起こることがあります。SQLエラーの主な原因は上記の最初のリンクに書いてありますが主に重複エラーが多い印象です。参考までに現在のreplicationまわりの設定値はだいたいこんなかんじです。
[shell]## replication (master/slave) log-bin=mysql-bin log-bin-index=mysql-bin.index binlog_format=mixed server-id = 133 relay-log=mysqld-relay-bin relay-log-index=mysql-relay-bin.index log_slave_updates=1 replicate-ignore-db=mysql,information_schema,performance_schema binlog-ignore-db=mysql,information_schema,performance_schema skip_slave_start read_only slave_net_timeout=120
## replication (for 5.6) gtid-mode = OFF enforce_gtid_consistency=false master-info-repository=TABLE relay-log-info-repository=TABLE relay_log_recovery=ON #sync-master-info=1 slave-parallel-workers=0 binlog-checksum=CRC32 #master-verify-checksum=1 #slave-sql-verify-checksum=1 binlog-rows-query-log_events=1 #log_bin_use_v1_row_events=ON #sync_binlog=1 report-port=3306 report-host = 192.168.1.133[/shell]
OpenSSLの重大バグ(CVE-2014-0160)への対応
...こんにちは。小宮です。
OpenSSLの重大バグが発見されたという記事をうけまして、
さすがに影響が大きいようなので関連情報を記録しておきます。
OpenSSLの重大バグが発覚。インターネットの大部分に影響の可能性 | TechCrunch Japan
JVNVU#94401838: OpenSSL の heartbeat 拡張に情報漏えいの脆弱性影響範囲はopenssl-1.0.1~1.0.1fということで、まじめに最新にしてるサイトが影響を受けるという皮肉なことに。
でもまあ影響範囲が限定的なのは良かったと思います。
弊社ではCentOS6.5とAmazonLinuxの環境が影響を受けました。まず以下をご覧ください。
対策方法を記しているサイト:
AWS - EC2インスタンスのOpenSSLのHartbleed Bug対応 - Qiita
opensslのTLS heartbeat read overrun (CVE-2014-0160)を対処した | Ore no homepageバージョンの確認方法は
rpm -qa|grep opensslとか
openssl versionという感じで、
CVE-2014-0160をfixしてるパッチがあたってるかどうかは、以下のように確認しました。rpm -q --changelog openssl |head * 月 4月 07 2014 Toma? Mraz <tmraz@redhat.com> 1.0.1e-16.7 - fix CVE-2014-0160 - information disclosure in TLS heartbeat extensionあたってなければ、yum update opensslして
sshd、crond、httpd等のopensslを利用しているサービスを再起動しました。