読者です 読者をやめる 読者になる 読者になる

としたにあんの左脳

備忘録です.

LVMに入れたディスクを抜く

60GBのSSDを3枚ぶっこんで180GBのLVMを作った。 最近、その中の1枚が調子悪くて、LVM全体がRead-Only FileSystemになるようになった。 /dev/sdbが調子わるいみたいなので、抜くことにしたが、一苦労だったのでメモ。

[root@openstack-03 ~]# pvdisplay
  --- Physical volume ---
  PV Name               /dev/sda3
  VG Name               centos
  PV Size               55.21 GiB / not usable 4.00 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              14134
  Free PE               0
  Allocated PE          14134
  PV UUID               QV224J-DJhF-uCJT-hNLZ-2r3w-poke-ocOOjp

  --- Physical volume ---
  PV Name               /dev/sdb1
  VG Name               centos
  PV Size               55.90 GiB / not usable 4.90 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              14309
  Free PE               0
  Allocated PE          14309
  PV UUID               ggEsVq-g8Ho-3hSY-h8Sv-GxGK-bG5c-14h14A

  --- Physical volume ---
  PV Name               /dev/sdc1
  VG Name               centos
  PV Size               55.90 GiB / not usable 4.90 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              14309
  Free PE               0
  Allocated PE          14309
  PV UUID               1W3kxH-lapr-4Of1-tFTn-iRTN-08KF-RCNAXK

  "/dev/loop0" is a new physical volume of "20.60 GiB"
  --- NEW Physical volume ---
  PV Name               /dev/loop0
  VG Name
  PV Size               20.60 GiB
  Allocatable           NO
  PE Size               0
  Total PE              0
  Free PE               0
  Allocated PE          0
  PV UUID               PPATKZ-qISr-klKl-7uQT-qtal-fiG0-BCZMrJ

[root@openstack-03 ~]# vgdisplay
  --- Volume group ---
  VG Name               centos
  System ID
  Format                lvm2
  Metadata Areas        3
  Metadata Sequence No  10
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                2
  Open LV               2
  Max PV                0
  Cur PV                3
  Act PV                3
  VG Size               167.00 GiB
  PE Size               4.00 MiB
  Total PE              42752
  Alloc PE / Size       42752 / 167.00 GiB
  Free  PE / Size       0 / 0
  VG UUID               9hDy0r-CzyH-cf7T-79X4-58e8-DHTY-rSnWRw

[root@openstack-03 ~]# lvdisplay
  --- Logical volume ---
  LV Path                /dev/centos/swap
  LV Name                swap
  VG Name                centos
  LV UUID                Olznpo-lnKi-eBbF-Yy6o-suEQ-vxzF-4dM4gy
  LV Write Access        read/write
  LV Creation host, time localhost, 2015-05-05 22:04:44 +0900
  LV Status              available
  # open                 2
  LV Size                5.59 GiB
  Current LE             1431
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     8192
  Block device           253:1

  --- Logical volume ---
  LV Path                /dev/centos/root
  LV Name                root
  VG Name                centos
  LV UUID                5E0sB7-SC4Y-zgpg-gxs4-7eLn-yfND-z9mUnF
  LV Write Access        read/write
  LV Creation host, time localhost, 2015-05-05 22:04:44 +0900
  LV Status              available
  # open                 1
  LV Size                161.41 GiB
  Current LE             41321
  Segments               3
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     8192
  Block device           253:0

5.4. Removing a Disk from a Logical Volumeとかをみると、pvmove して、他の物理ボリュームに移したらOK的な事がかいてあるので、さっそく

[root@openstack-03 ~]# pvmove /dev/sdb1
  No extents available for allocation

他に空き容量が無いからダメっぽい。 最初にロジカルボリュームに全ての容量を割り当てたのが、ダメだったっぽい。

http://tldp.org/HOWTO/LVM-HOWTO/reducelv.htmlをみると、ロジカルボリュームを縮小してからやるとOKらしい。

[root@openstack-03 ~]# lvreduce -L-70G /dev/centos/root
  WARNING: Reducing active and open logical volume to 91.41 GiB
  THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce root? [y/n]: y
  Size of logical volume centos/root changed from 161.41 GiB (41321 extents) to 91.41 GiB (23401 extents).
  Logical volume root successfully resized

でも、”データ壊れるかもよ”って言ってる。

あとはこれに従って進める。

とりあえず、pvmoveで動かせるだけのextentsは確保できたっぽい

  PV         VG     Fmt  Attr PSize  PFree  Used
  /dev/loop0        lvm2 ---  20.60g 20.60g     0
  /dev/sda3  centos lvm2 a--  55.21g     0  55.21g
  /dev/sdb1  centos lvm2 a--  55.89g 14.11g 41.79g
  /dev/sdc1  centos lvm2 a--  55.89g 14.11g 41.79g

動かしてみる。動いた。

[root@openstack-03 ~]# pvmove /dev/sdb1
  Detected pvmove in progress for /dev/sdb1
  /dev/sdb1: Moved: 41.4%
  /dev/sdb1: Moved: 45.4%
  /dev/sdb1: Moved: 49.0%
  /dev/sdb1: Moved: 52.6%
  /dev/sdb1: Moved: 56.5%
  /dev/sdb1: Moved: 60.6%
  /dev/sdb1: Moved: 64.8%
  /dev/sdb1: Moved: 68.9%
  /dev/sdb1: Moved: 73.1%
  /dev/sdb1: Moved: 77.2%
  /dev/sdb1: Moved: 81.3%
  /dev/sdb1: Moved: 85.5%
  /dev/sdb1: Moved: 89.6%
  /dev/sdb1: Moved: 93.8%
  /dev/sdb1: Moved: 97.9%
  /dev/sdb1: Moved: 100.0%

/dev/sdb1が空いたっぽい。

[root@openstack-03 ~]# pvs -o+pv_used
  PV         VG     Fmt  Attr PSize  PFree  Used
  /dev/loop0        lvm2 ---  20.60g 20.60g     0
  /dev/sda3  centos lvm2 a--  55.21g     0  55.21g
  /dev/sdb1  centos lvm2 a--  55.89g 55.89g     0
  /dev/sdc1  centos lvm2 a--  55.89g 14.11g 41.79g
[root@openstack-03 ~]# vgreduce centos /dev/sdb1
  Removed "/dev/sdb1" from volume group "centos"

これで、/dev/sdb1がボリュームグループから剥がれたっぽい!

(追記) マシンを再起動したら、OSが動かなくなったので、失敗したっぽい

Ubuntu14.04でQRコード読み込む

UbuntuQRコードを読みたい。


zbar-tools というパッケージをインストールする

$ sudo apt-get install zbar-tools

zbarimgというコマンドが追加される。

$ zbarimg qrcode.jpg
QR-Code:QRCode on Ubuntu
scanned 1 barcode symbols from 1 images in 0 seconds

QRCode: XXXXXXの部分が検出された文字列になる。

ld: library not found for -ltbb

ビルドしてたらtbbのエラー出てきた。

ld: library not found for -ltbb

隣の人に聞いたら上手くいった。

$ brew install tbb
$ export  LIBRARY_PATH=/usr/local/lib:$LIBRARY_PATH

C++でglobっぽいの

参考:c++ - Can I use a mask to iterate files in a directory with Boost? - Stack Overflow

boost使う

#include <boost/filesystem.hpp>
#include <boost/regex.hpp>
#include <boost/foreach.hpp>

void re_glob(boost::filesystem::path& target_path, std::string& re, std::vector< std::string >& results)
{
    const boost::regex my_filter(re);
    BOOST_FOREACH(
        const boost::filesystem::path &path,
        std::make_pair(
            boost::filesystem::directory_iterator(target_path),
            boost::filesystem::directory_iterator()))
    {
        if( !boost::filesystem::is_regular_file( path ) ) continue;
        boost::smatch what;
        // Skip if no match
        if( !boost::regex_match( path.string(), what, my_filter ) ) continue;

        results.push_back(path.string());
    }
}

int main(){
    std::vector< std::string > results;
    boost::filesystem::path path("/home/ubuntu/someproject");
    std::string re(".*py");
    re_glob(path, re, results);
    for(auto e: results){
        std::cout << e << std::endl;
    }
}

hipchat-cliの使い方

hipchat/hipchat-cli · GitHub

コマンドが終了したらHipchatで通知飛ばしたい時とかに便利

インストール

wget https://raw.githubusercontent.com/hipchat/hipchat-cli/master/hipchat_room_message
chmod +x hipchat_room_message
mv hipchat_room_message /usr/local/bin

使い方

export HIPCHAT_TOKEN=xxx
export HIPCHAT_ROOM_ID=xxx
hipchat_room_message -f "System" -i hello

コマンドが成功したら通知くれるやつ

sleep 10 && hipchat_room_message -f "System" -i hello

隠されたgccの歴史

138億年前

ビッグバンの超高温度・超高密度の状態の中でgccが生まれる

40億年前

地球で原始生命が生まれたころ,宇宙のどこかの生命体によりgccが発見される

27億年前

gccを材料とした初めての宇宙船が建造される

2億5000万年前

地球に来ていた宇宙船が現在のアラスカに不時着し,gccの破片が氷河の中に残される.

...

1980年

アメリカ政府のアラスカ調査団により,氷河の中からgccが発見される.国家機密として扱われることが決定.

1987年

発見されたgccを基に,gcc1.0がリリースされる

2013年

実装のC++への以降が完了.

2030年

gccの発見に関する秘密文書が公開される(予定)

Ansible 勉強会 #1 にいってきた

Ansible勉強会に行って来たので,感想とかをつらつらと.

connpassで参加登録した時は補欠100番目とかでしたが,イベント開始の2時間前とかに繰り上がりの連絡がきて急いで行ってきました! 急なお願いにもかかわらず早退をさせてくれた会社に感謝です.

とりあえず @tagomoris さんの話は圧巻でした.規模はやはり違いますね. お話されていた,Dynamic Inventoryは有効活用していきたいと思いました.むしろ,使わなかったら,大規模化で死亡する気が... zabbixのプラグインもあるらしいので連携がんばってみようと思いました.

発表者の方の中で割りと言われていたのは,公式のBest Practiceに素直に従うと,やりにくいということでした.一部ディレクト構成をかえたり,ペライチのPlaybookで管理するようにしているらしいです.

@saito_hideki さんがハードウェアスイッチをAnsibleでプロビジョニングするという取り組みをされていました. 個人的には,ルータの一括プロビジョニングとかをしてみようと思いました.

あと,冪等性なんか気にしてたら負けだったみたいです.

Playbookの育成がんばろうと思える勉強会でした.(ServerSpecも)

発表

Ansible の基本 + MySQL レプリケーションを設定する事例 @IanMLewis さん

スライド

MySQLのPlaybookを例にAnsibleのイントロダクション的な発表をして下さいました.

(Ansibleの中の人のPlaybook)https://github.com/bennojoy/ansible-roles/. AnsibleGalaxyでよく見るあの人のPlaybookですが,以前見て参考になったので,慣れてきた今,再度見なおしてみようとおもいました.(Debian系とRHEL系対応するようにPlaybook書いてあるから微妙に見難いんだよな...)

Jija2のテンプレートファイルの拡張子.j2だということを初めて知りましたorz

dynamic inventoryが便利な話: no more host list! @tagomoris さん

スライド @tagomorisさんの所属されている会社での実用事例として + データセンターの追加による iptablesの変更 + ssh-keyの追加 + 全サーバーでのopensslのアップデート + ミドルウェアのインストール/アップデート が挙げられていました.(最大2000台に同時適用されたとか...)

エージェントレス型なので,こういった処理には便利ですよね.

InventoryファイルのTipsとして + groupのgroupを定義できる + 範囲の展開ができる などを紹介されていて,Inventoryファイルの煩雑さから解放される気がしました.

本題のDynamic Inventoryですが, --list--host HOSTNAMEのオプションを受け付けて,jsonを返す実行可能プログラムがあればどのような実装であれ Dynamic Inventoryを使うことができるそうです. 実装は,zabbix serverのAPIを叩いたり,自前のホスト管理システムのAPIを叩いたりするみたいです.(LINEのはYabitzというらしいです)

うちは,zeushとhadeshです.

詳しい実装はここを参考にしたらいいらしい Developing Dynamic Inventory Sources — Ansible Documentation

serverspecのホスト管理もDynamic Inventoryみたいなことをしているらしいので,開発をしなければ.

LT

@r_rudi さん

gist

Ansibleの拡張ポイントにはmoduleとpluginの2つがあって,pluginの中のcallbackの話.

playbookの実行前後に何かしらの処理を行わせることができるらしい. Hipchatにplaybookの実行時間を通知するとかしてみたい(Hipchatモジュール実行時間とかは送れないよね) (HipChatモジュールを使って実行時間をHipChatに通知するとかはできなさそうかなぁ)

あと,InfluxDBよさげだなーと.

@saito_hideki さん

スライド

pythonの入らないマシンへのAnsibleでのプロビジョニングの話でした.

fabricがやってるようなことをやってたっぽいです.

一部のルータのように,sshコマンド実行ができないマシンの場合どうしたらいいのかなーって思ってつぶやいたら.

らしいので試してみる.

@laugh_k さん

確かにssh_configが使えるのは便利だなと思いました.

お客さんのシステム作る人とかは切実な問題そうですね.

@myb1126 さん

スライド

半年くらいで,大規模な企業にAnsibleを導入されたのはすごいなと思いました.

後戻りロス数百万円を回収できたなら入れた価値がありそうだなと.

@iktakahiro さん

スライド サンプル

./configureで頑張る姿勢が惚れる.

レッドハットで「yumは甘え」って言えるとこが惚れる.

サンプルのplaybookもすごかった.

@mystelynx さん

vagrantをansibleでprovisioningするやつ,VirtualBoxでしかためしたことなかったけど,EC2とかつかってると便利そうだなーと.

@xga さん

自分も以前Chefをがんばろうと思ったこともあったけど,Ansibleを触ったら簡単でAnsibleに流れたけど, 実際,Chefは学習コストは高いらしい.

Chefはタスクの実行順序がバラバラで制御が難しいらしい.その点Ansibleは上から下に実行されるのはよいなと思った.

Ansibleも一部並列にできたりできないのかな.

あと,Chef→Ansibleの移行の話もあって,ServerSpecで環境をテストしながらやったらしい.

ServerSpecの育成もがんばんなきゃ!