さくらのクラウドで普通のゲートウェイサーバーを構築する

会社では相変わらずさくらのクラウド上で色々やっていますが、以前のGentooの記事が好評だったので今回も同じくGentooでいこうと思います!

今回は図のような構成でごく普通のGatewayサーバーを構築し、矢印で示したサーバーがインターネットに出られるようにします。

f:id:mazgi:20150814211433p:plain

まずはカーネルのコンフィグレーションですが、CONFIG_IP_NF_TARGET_MASQUERADEを有効にしておきます。

[root@gateway-left] # uname -a
Linux gateway-left 4.0.5-gentoo #1 SMP Fri Aug 14 20:27:22 JST 2015 x86_64 Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz GenuineIntel GNU/Linux
[root@gateway-left] # zgrep CONFIG_IP_NF_TARGET_MASQUERADE /proc/config.gz
CONFIG_IP_NF_TARGET_MASQUERADE=m

またsysctlnet.ipv4.ip_forward1に設定します。

[root@gateway-left] # sysctl -p
net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1

iptablesはこんな感じにしてみます。
なお、eth0がWAN側インタフェース、eth1がLAN側インタフェースです。

[root@gateway-left] # iptables -L -v
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
  671  100K ACCEPT     all  --  any    any     anywhere             anywhere             ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  lo     any     anywhere             anywhere
    0     0 ACCEPT     icmp --  any    any     anywhere             anywhere
    1    60 ACCEPT     tcp  --  any    any     anywhere             anywhere             tcp dpt:22 ctstate NEW limit: up to 2/min burst 3 mode srcip-dstip
    0     0 DROP       tcp  --  any    any     anywhere             anywhere             multiport dports epmap,netbios-ssn,microsoft-ds
    0     0 DROP       udp  --  any    any     anywhere             anywhere             multiport dports epmap,netbios-ns,netbios-dgm,microsoft-ds
   15   764 LOG_AND_DROP  all  --  any    any     anywhere             anywhere

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
   36 12342 ACCEPT     all  --  eth1   any     anywhere             anywhere
   31 21996 ACCEPT     all  --  eth0   any     anywhere             172.x.0.0/16

Chain OUTPUT (policy ACCEPT 506 packets, 66758 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  any    lo      anywhere             anywhere
    0     0 LOG_AND_DROP  all  --  any    eth0    anywhere             255.255.255.255

Chain LOG_AND_DROP (2 references)
 pkts bytes target     prot opt in     out     source               destination
   15   764 LOG        all  --  any    any     anywhere             anywhere             limit: avg 1/sec burst 5 LOG level warning prefix "(IPTABLES_DROPPED)"
   15   764 DROP       all  --  any    any     anywhere             anywhere

natテーブルはこんな感じで。

[root@gateway-left] # iptables -L -v -t nat
Chain PREROUTING (policy ACCEPT 2155 packets, 139K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain INPUT (policy ACCEPT 1 packets, 60 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 30 packets, 1931 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 30 packets, 1931 bytes)
 pkts bytes target     prot opt in     out     source               destination
   11 10788 MASQUERADE  all  --  any    eth0    anywhere             anywhere

Gateway経由でインターネットにでる各サーバーの設定はこんな感じです。
172.x.y.zがGatewayのIPアドレスです。

$ cat /etc/conf.d/net.eth1
config_eth1="172.x.a.b/16"
routes_eth1="default via 172.x.y.z"
dns_servers_eth1="172.x.v.1 172.x.v.2"
dns_domain_eth1="example.com"

以上、お手軽ですね。

ところでさくらのクラウドにはVPCルーターというアプライアンスが用意されており、これを使うともっとお手軽にネットワークを構築することができます。

VPCルータ | さくらのクラウドニュース

RedmineのユーザーページにGitHubへのリンクを表示する

会社では開発がほぼGitHub.com+Slackで完結するようにしていて、これはなかなかうまくいっています(と思っています)。 ただ、ハードウェア障害の対応等GitHubに載せにくいタスクもあり、そのようなタスクの管理にはさくらのクラウド上にRedmineを構築して使っています。

このように「GitHubメイン、ときどきRedmine」という状況で、Redmine上に「このRedmineユーザーはこのGitHubユーザーです」って表示できないかなと思ったらカスタムフィールドを使ってあっさりできたのでメモしておきます。

表示としてはこのような感じになります。

f:id:mazgi:20150813165522p:plain

手順

カスタムフィールドの作成

なにはともあれカスタムフィールドを作ります。

f:id:mazgi:20150813165541p:plain

typeは Users にします。

f:id:mazgi:20150813165412p:plain

Name は"GitHub Account"にしました。
Link values to URL がキモでAdministrator Guideによると https://github.com/%value% のように %value% でカスタムフィールドの値を参照できるようです。

f:id:mazgi:20150813165358p:plain

保存するとカスタムフィールドが作成されます。

f:id:mazgi:20150813165556p:plain

Redmineユーザーの編集

つぎにRedmineの各ユーザーにGitHubアカウントを入力していきます。
ユーザー編集ページで先ほど作った"GitHub Account"が入力できるようになっていますね。

f:id:mazgi:20150813165430p:plain

保存するとこのようにGitHubアカウント名がリンクとして表示されます。

f:id:mazgi:20150813165522p:plain

クリックするとちゃんとGitHubのユーザーページに飛びます。

f:id:mazgi:20150813165337p:plain

めでたしめでたし。
これ、個人ページのURLにアカウント名が含まれるあらゆるサービスに使えますね。
せっかくなのでTwitterとかFacebookとか作ってみようと思います。

参考にさせていただいたページ

さくらのクラウドで普通のLDAP認証ができるサーバーを量産する

会社でSSHの公開鍵やSUDOの権限をLDAPで一元管理していっているのですが、忘れないうちにLDAPクライアント側の構築方法を書いてみます。
なお、サーバーはさくらのクラウド上で構築し、LDAPサーバーはldap1.example.comというFQDNでアクセスできるものとします。

手順

OSとパッケージ

クラウドなので基本となるインスタンスを1台構築し複製することにします。
複製したインスタンスは普通のサーバーとして使う想定ですのでディストリビューションにはGentoo Linuxを使用します。
最近構築したのでカーネルバージョンは4.0.5と新しめです。

インスタンスの複製はロードバランサとサーバクローンで簡単スケールアウトというTIPSにスクリーンショット付きで解説されています。

# uname -a
Linux base 4.0.5-gentoo #1 SMP Wed Jul 1 02:23:16 JST 2015 x86_64 Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz GenuineIntel GNU/Linux

SSSD経由でLDAP認証を行うために必要なパッケージをインストールします。 USEフラグ設定のポイントは以下のとおりです。

  • OpenLDAPはクライアントのみでよいためminimalを指定
  • SSH公開鍵は後述するsss_ssh_authorizedkeysで取得するためOpenSSHにはldap指定不要
  • SSSDにはsshsudoを指定
  • sudoにはldapを指定
    (これは今回SUDOの設定をSSSD経由ではなくLDAPから直接取得したためです)
# emerge -pvq openldap openssh sssd sudo
[ebuild   R   ] net-nds/openldap-2.4.38-r2  USE="berkdb crypt gnutls ipv6 minimal sasl ssl syslog tcpd -cxx -debug -experimental -icu -iodbc -kerberos -odbc -overlays -perl -samba (-selinux) -slp -smbkrb5passwd" ABI_X86="(64) -32 (-x32)" 
[ebuild   R   ] net-misc/openssh-6.9_p1-r2  USE="hpn pam pie ssl -X -X509 -bindist -debug -kerberos -ldap -ldns -libedit -sctp (-selinux) -skey -ssh1 -static" 
[ebuild   R   ] sys-auth/sssd-1.12.4  USE="manpages nls ssh sudo -acl -augeas -autofs -locator -netlink -nfsv4 -python -samba (-selinux) {-test}" ABI_X86="(64) -32 (-x32)" PYTHON_SINGLE_TARGET="python2_7 -python3_3 -python3_4" PYTHON_TARGETS="python2_7 python3_3 -python3_4" 
[ebuild   R   ] app-admin/sudo-1.8.12  USE="ldap nls pam sendmail -offensive (-selinux) -skey" 

時代はflaggieなのでflaggieでUSEフラグを設定するといいと思います。

LDAPクライアントの設定

パッケージをインストールしたらLDAPクライアントとして仕立てていきます。

LDAPクライアントとしての基本的な設定を/etc/openldap/ldap.confに書きます。

# grep -vE '^\s*($|#)' /etc/openldap/ldap.conf
BASE dc=example,dc=co,dc=jp
URI ldap://ldap1.example.co.jp ldap://ldap2.example.co.jp
tls_reqcert naver
sudoers_base ou=SUDOers,dc=example,dc=co,dc=jp
nss_initgroups backlink
binddn cn=Authenticator,dc=example,dc=co,dc=jp
bindpw P@ssw0rd!

sudoコマンドが読む/etc/ldap.conf.sudoファイルはldap.confへのsymlinkにしています。 なお、sudoがどのldap.confを読んでいるかはリンク先の方法で調べることができます。

sudoがどのldap.confを読んでいるか確認する - Qiita

# ls -l /etc/openldap/ldap.conf /etc/ldap.conf.sudo
lrwxrwxrwx 1 root root  18 Jul 19 16:35 /etc/ldap.conf.sudo -> openldap/ldap.conf
-rw-r--r-- 1 root root 250 Jul 19 16:36 /etc/openldap/ldap.conf

SSSDの設定

続いてSSSDの設定を行います。 ドメインはexampleとしています。

# grep -vE '^\s*($|#)' /etc/sssd/sssd.conf
[sssd]
config_file_version = 2
services = nss,pam,sudo,ssh
domains = example
debug_level = 1
[nss]
filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
[pam]
[sudo]
subdomain_enumerate = true
debug_level = 9
[domain/example]
id_provider = ldap
auth_provider = ldap
sudo_provider = ldap
ldap_search_base = dc=example,dc=co,dc=jp
ldap_sudo_search_base = ou=SUDOers,dc=example,dc=co,dc=jp
ldap_tls_reqcert = never
ldap_uri = ldap://ldap1.example.co.jp
ldap_schema = rfc2307
debug_level = 1
enumerate = true
ldap_default_bind_dn = cn=Authenticator,dc=example,dc=co,dc=jp
ldap_default_authtok = P@ssw0rd!
ldap_group_object_class = posixGroup
ldap_group_search_base = ou=Group,dc=example,dc=co,dc=jp
ldap_group_name = cn
ldap_group_member = memberUid
ldap_id_use_start_tls = false
chpass_provider = ldap
cache_credentials = true

Name Service Switchの設定

passwd,shadow,groupsssを参照するようnsswitch.confを設定します。
sudoersldapsss両方を参照するよう設定していますが、これは私がうまくSSSD経由でSUDOersを取得できなかったためこのようになっています。。

# grep -vE '^\s*($|#)' /etc/nsswitch.conf
passwd:      compat sss
shadow:      compat sss
group:       compat sss
hosts:       files dns
networks:    files dns
services:    db files
protocols:   db files
rpc:         db files
ethers:      db files
netmasks:    files
netgroup:    files
bootparams:  files
automount:   files
aliases:     files
sudoers:     files ldap sss

PAMの設定

ディストリビューションによってデフォルトの設定がやや異なりますが、今回はこのように設定しました。
おおむねpam_sss.soを使用している行が追加した行です。合わせてpam_unix.soを使用している行をrequiredからsufficientに変えています。
またログイン時にホームディレクトリが作成されるようにpam_mkhomedir.soを使用しています。なお、/homeはNFSで共有されておりどのサーバーに入っても同じホームディレクトリが見えるようにしています。

# grep -vE '^\s*($|#)' /etc/pam.d/system-auth
auth            required        pam_env.so 
auth            sufficient      pam_unix.so try_first_pass likeauth nullok 
auth            sufficient      pam_sss.so use_first_pass
auth            optional        pam_permit.so
account required        pam_unix.so 
account [default=bad success=ok user_unknown=ignore]            pam_sss.so
account optional        pam_permit.so
password        required        pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3 
password        sufficient      pam_unix.so try_first_pass use_authtok nullok sha512 shadow 
password        sufficient      pam_sss.so use_authtok
password        optional        pam_permit.so
session         required        pam_limits.so 
session         required        pam_env.so 
session         required        pam_unix.so 
session         optional        pam_mkhomedir.so skel=/etc/skel/ umask=0077
session         optional        pam_sss.so
session         optional        pam_permit.so

OpenSSHの設定

OpenSSH 6.2からAuthorizedKeysCommandという項目名で公開鍵を取得する外部プログラムを呼び出せるようになっています。
この設定とSSSDが提供するsss_ssh_authorizedkeysコマンドによってLPKパッチを当てなくてもLDAPからSSSDを経由して公開鍵を取得できるようになります。
余談ですがLDAPサーバー側はLPKスキーマが欲しいのでOpenSSHのUSEフラグにldapを指定してインストールしています。

# grep -vE '^\s*($|#)' /etc/ssh/sshd_config
PubkeyAuthentication yes
AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser nobody
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes
PrintMotd no
PrintLastLog no
UsePrivilegeSeparation sandbox          # Default for new installations.
Subsystem       sftp    /usr/lib64/misc/sftp-server
AcceptEnv LANG LC_*

このようにsss_ssh_authorizedkeysコマンドの引数にユーザー名を渡すと公開鍵が取得できることを確認できます。

[mazgi@base] $ sss_ssh_authorizedkeys mazgi
ssh-rsa AAAA********Hs2V mazgi@BRUICHLADDICH.local
ssh-rsa AAAA********61rn mazgi@Ardbeg.local

デーモンの起動

ここまで設定できたらsshdsssdを起動します。
この例ではホームディレクトリをマウントするためにnfsclientも起動しています。

# rc-status
Runlevel: default
 netmount                                                          [  started  ]
 local                                                             [  started  ]
Dynamic Runlevel: hotplugged
Dynamic Runlevel: needed
 rpcbind                                                           [  started  ]
 rpc.pipefs                                                        [  started  ]
 rpc.idmapd                                                        [  started  ]
 rpc.statd                                                         [  started  ]
 nfsclient                                                         [  started  ]
Dynamic Runlevel: manual
 net.eth0                                                          [  started  ]
 sshd                                                              [  started  ]
 sssd                                                              [  started  ]
 net.eth1                                                          [  started  ]

ここまでの手順でLDAPに登録されている公開鍵でSSHログインしてsudoできるようになります。

[mazgi@localhost] $ id
uid=10001(mazgi) gid=10000(example) groups=10000(example),11001(level1),11002(level2),11003(level3),11004(level4),11005(level5)
[mazgi@localhost] $ sudo -ll
Matching Defaults entries for mazgi on localhost:
    ignore_local_sudoers, insults, !authenticate, !env_reset

User mazgi may run the following commands on localhost:

LDAP Role: level1
    RunAsUsers: root
    Commands:
    /bin/false

LDAP Role: level2
    RunAsUsers: root
    Commands:
    /usr/bin/tail
    /usr/bin/tailf
    /usr/bin/less
    /bin/ls
    /usr/bin/sha1sum
    /usr/bin/sha224sum
    /usr/bin/sha256sum
(snip)

ちゃんとログインできてUIDとグループとSUDO情報が取得できていますね!

おわりに

会社ではこのインスタンスを複製して本番環境や社内サービスに使っています。
クラウドなので複製後は以下の3ステップでサーバーが使い始められます。楽チンですね!

  • IPアドレスの設定
  • ホスト名の設定
  • SSHホスト鍵の再生成

参考にさせていただいたページ

flaggieをはじめ数々のGentoo TIPSについてはEmacs ひきこもり生活を参考にさせていただいています。

SSSDの設定についてはsssd.conf ファイルの設定をはじめとしたRed Hat社が公開してくださっているRHELのドキュメントが大変参考になります。

さくらのクラウドでサーバーを複製する方法はさくらのクラウドニュースで紹介されているロードバランサとサーバクローンで簡単スケールアウトというTIPSが参考になります。

普通のうるう秒対応をしました(June 30, 2015)

ITシステムに関わる人にとっては気が気ではなかったであろううるう秒ですが、無事に過ごすことができましたのでやったことをメモしておきます。

www.nikkei.com

やったこと

今回のうるう秒を迎えるにあたっては自宅ラック友の会 ポータルの記事とHIROCASTERさんの7/1の閏秒を迎えるにあたってLinuxでは何をすべきか?を大いに参考にさせていただきました。
ありがとうございます。

行った対策は以下です。

  • うるう秒による影響範囲の調査
    • Linuxカーネルのバージョン確認
    • ntpdのバージョン確認とアップデート
  • (ベンダー様による)ネットワーク機器の対策
  • Slewモードで動くNTPサーバーの構築
  • サーバーのNTP設定変更
  • 当日待機

影響調査

会社では東京のIDC(ハウジング)とさくらのクラウドを併用しており、どちらにあるサーバーも主にLinux系OSで動いています。

Linuxサーバーのカーネルバージョンを確認したところ下記いずれかでした。

  • 3.12, 3.18等比較的新しいカーネル
  • 対策済みの2.6系カーネル

大丈夫そうですね。

一方ntpdは一部古いものがありましたので下記いずれかのバージョンにアップデートしました。

  • ntpd 4.2.8@1.3265-o
  • ntpd 4.2.6p5@1.2349-o

続いてネットワーク機器ですが、保守してくださってるベンダー様から連絡をいただきまして、ハウジングで使用しているCiscoのNexusというスイッチが影響を受けることがわかりました。

ネットワーク機器の対策

Cisco Nexusは前後1日程度バッファを取って下記のオペレーションで対応することになりました。

  • 6/29 にNTP設定削除
  • 7/2 にNTP設定復元

Slewモードで動くNTPサーバーの構築

この機会にNTPの設定も整理しよう!ということでNTPサーバーを新設しました。

# uname -r
4.0.5-gentoo
# ntpd --version
ntpd 4.2.8@1.3265-o Sat Jun 27 17:13:03 UTC 2015 (1)
# ps aux | grep 'ntp[d]'
root      2871  0.0  0.0 102768 14852 ?        SLs  19:17   0:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -x
# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+ntp1.jst.mfeed. 133.243.236.17   2 u   66  128  377    0.538    2.622   0.016
*ntp2.jst.mfeed. 133.243.236.17   2 u  125  128  377    0.542    1.133   0.050
+ntp3.jst.mfeed. 133.243.236.17   2 u   90  128  377    0.734    1.299   0.062

意気込んで新設した結果カーネル4系になりました!
ピカピカですね!

サーバーのNTP設定変更

全サーバーのNTP設定を新設したNTPサーバーを見るように変更します。
Ansibleで設定ファイルを置き換えていくだけなので楽チンです。

当日待機

当日は念のため待機しました。
前回はけっこう大変なことになってたので、今度は自分が対応に追われる番かと覚悟もしていたのですが、幸い今回はとくに大きな異常は発生せずに9時(JST)を過ぎました。
でもちょっとくらい問題起こってもおもしろかったかも

さくらのクラウドでも事前にしっかりと対策していただいていたようでクラウド基盤での異常も皆無でした。

何事もなかったことをSlackで報告し意気揚々と帰路に着くことができました。
これもLinuxや各コミュニティ・企業の皆様のおかげですね!

f:id:mazgi:20150702123420p:plain

ただ、帰宅すると自宅のMacがフリーズしていました。
原因につきましてはわかりかねました。

参考にさせていただいたページ

対策実施および本記事を書くにあたっては下記ページを参考にさせていただきました。

<mazgi.github.io 移行済>#morisnite 2で生ハム原木担いでラーメンが美味しかった話

移動しました

https://mazgi.github.io/posts/2015.02/morisnite-02-with-whole-prosciutto/


モリスナイト2で無事に生ハムをdeployすることができた。
骨は@mirakuiさんが美味しいラーメンにしてくださった。

morisnite

例の@tagomorisさんと酒を飲む会である。

ノリで生ハム原木をポチったので担ぐことにした。

まずビールの量が恐ろしかった。
フリークアウトさんの広いカウンターが埋まるほどの量だった。
なおすべてなくなったらしい。

生ハム原木も f:id:mazgi:20150206194326j:plain あと栓抜きを持ち帰るのを忘れた
モリスさんや皆さんにカットしていただき(念のためモザイクをかけた) f:id:mazgi:20150206194519j:plain 無事 f:id:mazgi:20150206210628j:plain 完食された f:id:mazgi:20150206225108j:plain なお骨は@sora_hさんが持って帰ってくださった。

爪が飛び出た豚の脚(しかも骨のみ)を運んでいただきありがとうございます。
(生ハム原木ラーメン布石となる)

生ハム原木の持ち込みを黙認(あるいはスルー)していただいた@myfinderさんと会場を貸してくださったフリークアウト様ありがとうございます。

生ハム原木ラーメン

@mirakuiさんが生ハム原木の骨をラーメンにしてくださるとのことでお呼ばれしてきた。 それはもう美味かった。

f:id:mazgi:20150216131950j:plain チャーシューがとても美味かったのだが、チャーシューと別に生ハムの一部も入っておりそれはたしかにチャーシューとは異なる旨さで「ああ、たしかにmorisniteの生ハムだ」と感慨に浸らせられるものだった。

f:id:mazgi:20150216133937j:plain 完食。

f:id:mazgi:20150216130813j:plain 原木はこのように煮込まれていた

f:id:mazgi:20150216135055j:plain あとクックパッドさんのオフィスはとても眺めが良かった

仕込んでくださった@mirakuiさん、原料を運んでくださった@sora_hさん、「昼にエンジニアが集まってラーメンを食う」ただそれだけのためにテーブルを貸してくださったクックパッド様ありがとうございました。

morisnite 準備

ここで書かないと書く機会がなさそうなのでdeployまでの準備などを記録しておく。

生ハム原木が早く着きすぎたので冷却に悩んだ。
しかしコンビニの板氷4枚とエアキャップ少々、そして耐水性の箱(衣装ケースなどを想像していただきたい)で解決した。
(当日運搬中と開封後に触診により温度を確認したが冷えていたので解決したと考えている)

f:id:mazgi:20150202000948j:plain + SUN UP(サンアップ) 包装緩衝材 プチプチ d36 巾600mm×全長10m

運搬には公共交通機関を活用した。

f:id:mazgi:20150206185356j:plain

中央線乗車中の生ハム原木

f:id:mazgi:20150206191046j:plain

六本木駅のホームで佇む生ハム原木

f:id:mazgi:20150206191342j:plain

エスカレーターを昇る生ハム原木

f:id:mazgi:20150206192048j:plain

ヒルズと生ハム原木(重すぎて片手で持ち上げるのはこれが限界だった)

なおせっかくの機会なのでタイトル通り担いだ
(背景のイケてるスペースはフリークアウト様オフィスである) f:id:mazgi:20150206192907j:plain

How to install #innobackupex on #Gentoo Linux

Install xtrabackup-bin

# emerge -pvq xtrabackup-bin
[ebuild   R   ] dev-db/xtrabackup-bin-2.2.5 
# equery f xtrabackup-bin
 * Searching for xtrabackup-bin ...
 * Contents of dev-db/xtrabackup-bin-2.2.5:
/usr
/usr/bin
/usr/bin/innobackupex
/usr/bin/xbcrypt
/usr/bin/xbstream
/usr/bin/xtrabackup

Download and extract qpress

Download qpress-11-linux-x64.tar from this site:

Fast compression library for C, C# and Java

And extract qpress command.

# tar xvf qpress-11-linux-x64.tar -C /usr/local/bin/
qpress

Run innobackupex

  • Backup
# innobackupex --defaults-file=/etc/mysql/my.cnf --user=$USER --password=$PASS --ibbackup=xtrabackup --slave-info --safe-slave-backup --compress $TARGET_DIR
  • Restore
# innobackupex --user=$USER --password=$PASS --decompress $BACKUP_DIR
# innobackupex --user=$USER --password=$PASS --apply-log $BACKUP_DIR
# innobackupex --copy-back $BACKUP_DIR
# chown -R mysql:mysql /var/lib/mysql