ラベル Linux の投稿を表示しています。 すべての投稿を表示
ラベル Linux の投稿を表示しています。 すべての投稿を表示

2012年1月3日火曜日

Amazon Linuxで使われてるcloud-initをCentOS6で使ってみる

新年あけましておめでとうございます。
年明け最初の更新をこんなに早くするとは自分でも驚きですが、今年もブログをゆるく継続していきたいと思います。

さて、AWSを使用している方はAmazon Linuxに興味を持った事があると思います。
Redhat系のディストリビューションを使用していた方は操作感も近くてスイッチしやすいのではないでしょうか？
私も何度かAmazon Linuxを使用しましたが、その中でcloud-initってとても便利だなと思いました。
cloud-initはもともとUbuntuに搭載されたクラウド環境でのセットアップツールみたいですが、Amazon Linuxではこの機能が標準で移植されております。
個人的にはChefとかよりもチャラく使えるようなイメージでしょうか。。。
AWSで提供されているUbuntuやAmazon Linuxはcloud-initを使って、指定したSSH公開鍵の設置や、セキュリティアップデートなどが行われているようです。
自前でCentOSなどのAMIを作成した経験がある方はSSHの公開鍵を設置するスクリプトを使った事があると思いますが、Amazon Linuxではcloud-init経由でec2-userに公開鍵を設置しているのですね。

『なるほどー、これはCentOSでも使ってみたいですよねー』というネタです。

■AmazonLinuxで使用されているcloud-initのsrpmを取得する

Amazon Linuxで以下のようにコマンドを実行すると/usr/src/srpm/debug/以下にsrpmが保存されるので、これをCentOSでビルドします。
■CentOSでcloud-initのrpmを作成する

ビルドに必要なライブラリをインストールします。
epelをyumのリポジトリに追加している方はPyYAMLとlibyamlもyumでインストールが出来ると思います。
次に事前に転送しておいたcloud-initのsrpmをビルドします。
一部specファイルを以下のように編集しています。
■インストール

作成されたcloud-initのrpmをインストールします。
specファイルを見ると分かりますが、インストールするとec2-userやsudoの設定が追加されます。
■動作確認

インストールしたインスタンスからAMIを作成し、以下のようなUserDataを指定して起動してみました。
無事にec2-userへの公開鍵登録と 指定したパッケージがインストールされていましたよ:)
こんな事するならAmazon Linux使った方が(ryという突っ込みはご勘弁下さい:D
投稿者 時刻:
ラベル: , , ,

2011年7月29日金曜日

RackspaceのサーバをChef(knife-rackspace)から使ってみる

なんか頻繁に更新とかするとちょっと不思議な感じがしますね。
昨日書いたブログ１周年の感想はともかく、今回もRackspaceの作業記録ネタです。
今回の主役となるChefや、Puppetというソフトウェアは以前から聞いてましたが、正直あまりさわれていませんでした。

Chefについては色々な方が情報提供しているので、ここではChefを使ってRackspaceのCloudServersを操作するログだけ記録しておこうと思います。
なんかChefを使ってAWSって話は誰かが？(汗)書くようです。
ちなみにChef0.10.0からknife-rackspaceというプラグインを使用する事になったみたいなので忘れずに入れて下さいね。

Chefってなんぞ！？という方は以下のリンクが参考になるのではないでしょうか。
ちなみに私のChefサーバはOpscodeのSaaSを使用させて頂いております。
ネットワーク構成を本番に近い形にも出来るし、何しろChefサーバを運用しなくて良いのは素敵ですもんね。
※アナタそういうサーバ運用するのがお仕事でしょっ！ていう突っ込みは割愛して下さいね（笑）

以下、作業記録です。

１）knife-rackspaceのインストール

Chefとknife-rackspaceをMacBookにインストールするのは簡単でしたよ。

２）Cloud Serversをknifeコマンドで操作する為にAPIの設定

APIの情報を以下のように設定します。

３）Rackspaceへの接続確認

使用出来るサーバイメージをリストで表示します
指定可能なサーバのスペックの一覧表示します

４）起動確認=>レシピ適用=>削除

Cloud Serversのサーバを起動し、apache2のレシピを適用します
起動したサーバは一覧で表示出来ます
削除もknifeコマンドで実行出来ます
以上のように管理画面にログインする事なくknifeコマンドから操作出来ます。
Chefに慣れた人にとっては良い運用の選択肢になりそうです。
以前このブログで書いたcloudlbやcloudsrversとかと組み合わせると、さらに面白そう！

Rackspaceのロードバランサは外部のサーバも分散先に登録出来ます。
Chef経由でバランシング対象のRackspaceのサーバとEC2インスタンスに同じレシピを適用するなんて事も出来ますね。

あー、Rackspaceのデータセンターが日本にも出来ないかなー。出来ないだろなー。
Rackspaceを使って動く素敵なサービスは日本でもたくさん使われてるのになー。
投稿者 時刻:
ラベル: , , ,

2011年3月31日木曜日

Rails3環境用にSQLite3のRPMを作成する

いやー、最近のこのブログの技術ネタといったら、
  • このRPM作った
  • あのRPM作った
  • こんなRPM作った
と、ただのRPM作成ログの置き場となってますが、今回もRPMを作成したログです（汗）
すんません…orz
作成したきっかけは達人出版会さんから出版されている、”はじめる！Rails3”です。
こちらはRails3を始めるには良さそうな電子書籍で、Rails3の使い方を分かりやすく説明しています。
Linuxへの導入はUbuntu中心で書かれていますが、CentOSでも問題ないだろうと思ってました。

…しかし、SQLite3のインストール手順においてこんな記載がありました。
『Linux(CentOS 5)の場合は以下のコマンドを 実行します。』
残念な事に、この手順では”gem install sqlite3”が実行出来なかった訳です。
理由はCentOS5が使用するsqlite3のバージョンに古い事であり、『じゃあRPM作るか』ってなりますよね〜。

※今回はビルド専用ユーザーを作成していますが、SQLiteはrootでrpmbuildをするとエラーが出てしまいます

  • RPMBuildに必要なパッケージをインストール
  • ビルド用ユーザoko_changを追加
  • SRPMをダウンロードしてインストール
  • RPMビルドの準備
  • ビルド実行

以上で無事に”gem install sqlite3”が実行出来ました。
ちなみに素直にUbuntuを使えば、当然この手順は必要ありません。
投稿者 時刻:
ラベル: , , ,

2011年2月6日日曜日

Puppet2.6.4のインストール、起動、動作確認

以前の記事でPuppet2.6.4のRPMを作成しました。
せっかくRPMを作ったので、簡単な動作確認のメモを残しておこうと思います。
テスト環境はマスター（サーバー）、エージェント（クライアント）共にCentOS5.5となります。
また、マスターにはp-master.okochang.comという名前で接続が出来るようになっています。

英語が苦手が私は2.6.4の日本語情報があまりなくて設定にちょっと苦労してしまいました(汗)
なお、設定されているPuppetの設定は最小限のものですので注意して下さい。

まずはマスター側の設定と起動です。

  • インストール
  • Puppetマスターの設定
  • 簡単なマニフェストの作成
  • Puppetマスターを起動

マニフェストには/etc/hostsの所有者：root、グループ：root、権限は644であるべきとしています。
続いてはエージェントの設定、起動、動作確認です。

  • インストール
  • Puppetエージェントの設定
  • Puppetエージェントの起動と動作確認

/etc/hostsファイルの権限を666に変更後、エージェントを起動したら権限が644に戻りました。
エージェント側では動作確認が出来ましたので、最後にマスター側の動作確認をします。

  • クライアントの署名リクエストの確認

エージェント側(ip-10-160-118-49)が正常に表示されています。
以上でインストール、起動、動作確認が終わりました。
ちなみに2.6.4では[puppetmasterd]セクションは[master]へ、[puppetd]セクションは[agent]に変更されています。
私はそこで一人深夜に悩んでおりましたorz

参考リンク
投稿者 時刻:
ラベル: , ,

2011年1月19日水曜日

CentOS5.5でpuppet2.6.4のrpmを作成する

Puppetを使用する場合、使用するバージョンやインストール方法はどんな方法が良いかなと悩んだりしています。
RubyGemsを使ったインストール方法を覚えておけば、どんなディストリビューションでも使えて便利そうです。
ただ、個人的に一番使い慣れたディストリビューションはCentOSなので、rpmで管理したいという気持ちもあります。
そんな悩みを持ちつつ、とりあえずrpmを作成したので手順を残しておこうと思います。

参考にしたページはこちらで、手順はほんとにそのままで申し訳ないくらいです。

  • rpmbuildに必要なパッケージをインストールします
  • その他puppetのインストールに必要なパッケージをインストールします
  • /usr/src/redhat/SOURCESディレクトリに移動してfacterとpuppetのソースファイルをダウンロード
  • ダウンロードしたファイルを展開します
  • 必要なパッチがあるか確認します
  • パッチファイルを探してSOURCESディレクトリに移動させます
  • バージョン情報を確認します
  • バージョン情報をダウンロードしたものと合わせて%changelogを編集します
  • 編集したspecファイルをSPECSディレクトリにコピーします
  • 不要なディレクトリを削除します
  • SPECSディレクトリに移動してfacterをbuildします
  • puppetのbuildに必要なのでbuildしたfacterをインストールします
  • SPECSディレクトリに移動してpuppetをインストールします
  • puppetをインストールします

以上でrpm作成は終わりです。
FacterもPuppetもすぐにbuildが終わる事にびっくり！
んー、でもやっぱり色々なディストリビューションで使える事を考えるとRubyGemsが便利そうだなー。
投稿者 時刻:
ラベル: , , ,

2010年12月17日金曜日

githubへの初回pushでsshエラー

gitをテスト環境に入れてからgithubにpushしようとしたら、少しつまずいたのでメモ。
githubの始め方はこちらのブログで分かりやすく説明されているので割愛します。
gitのインストールとgithubリポジトリ(project_hoge)の作成は事前に完了しておいて下さい。

  • githubへのssh接続に使う秘密鍵と公開鍵のペアを作成
    • ※名前は自分で指定してますが、それがすべての始まり
    ※公開鍵はgithubに追加してくださいね 
    $ ssh-keygen -t rsa -C "github-hoge"
Generating public/private rsa key pair.
Enter file in which to save the key (/home/hoge/.ssh/id_rsa): /home/hoge/.ssh/hoge_rsa
Enter passphrase (empty for no passphrase):パスフレーズ
Enter same passphrase again:パスフレーズ
Your identification has been saved in /home/hoge/.ssh/hoge_rsa.
Your public key has been saved in /home/hoge/.ssh/hoge_rsa.pub.
The key fingerprint is:
  • gitの初期設定を行います
    • $ git config --global user.name "hoge"
$ git config --global user.email "hoge@example.com"
$ git config --global color.ui auto
  • git設定の確認
    • $ cat -n .gitconfig
     1     [user]
     2          name = hoge
     3          email = hoge@example.com
     4     [color]
     5          ui = auto
  • リポジトリの初期化、基本設定確認
    • $ mkdir project_hoge
$ cd project_hoge/
$ git init
Initialized empty Git repository in /home/hoge/project_hoge/.git/
$ git var GIT_COMMITTER_IDENT
hoge  1292429310 +0900
$ git var GIT_AUTHOR_IDENT
hoge  1292429366 +0900
  • README作成、最初のコミット
    • $ touch README
$ git add README
$ git commit -m 'first commit'
[master (root-commit) 92e6b51] first commit
 1 files changed, 256 insertions(+), 0 deletions(-)
 create mode 100644 README
  • githubをリモートリポジトリに追加
    • $ git remote add origin git@github.com:hoge/project_hoge.git
  • pushしようとするとエラーが発生！
    • $ git push origin master
Permission denied (publickey).
fatal: The remote end hung up unexpectedly
    SSHの鍵をデフォルトの名前にしなかった事があやしいです。
    ここらへん見るとそれらしき事が書いてます。
  • .ssh/configで使用する鍵を指定します
    • $ vi /home/hoge/.ssh/config
      1 Host                 github.com
      2 User                 git
      3 Port                 22
      4 Hostname             github.com
      5 IdentityFile         ~/.ssh/hoge_rsa
      6 TCPKeepAlive         yes
      7 IdentitiesOnly       yes

$ chmod 600 .ssh/config
  • 再トライをすると無事に接続が出来ます
    • $ git push origin master
Enter passphrase for key '/home/hoge/.ssh/hoge_rsa':
Counting objects: 3, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 4.57 KiB, done.
Total 3 (delta 0), reused 0 (delta 0)
To git@github.com:hoge/project_hoge.git
 * [new branch]      master -> master


以上、メモでしたー。
今日はクラウド勉強会に参加していましたが、とても勉強になりました。
おそらく年内は最後かもですが、勉強会はとても刺激になるので来年も積極的に参加したいですね。
投稿者 時刻:
ラベル: ,

2010年12月15日水曜日

CentOS5.5でgit1.7.3のrpmを作成する

そうだ！ブログやってたんだ！
相変わらずの気まぐれ更新になってしまった。
勉強会とかに参加した感想をもっとキチンと書きたいなー。
ブログがある事を思い出す為にもCentOS5.5でgit1.7.3のrpmを作る手順をまとめとく。

こちらのブログが非常に手順としては参考になった。
というか手順はまんまです。

必要になりそうなパッケージをとりあえず一気にインストール

# yum -y groupinstall "Development Tools"
# yum -y groupinstall "Development Libraries"

その他以下のパッケージは必須なのでインストール

# yum -y install zlib-devel openssl-devel curl-devel expat-devel gettext xmlto gettext-devel

EPELからダウンロードしてインストールするパッケージもあります

# cd /usr/local/src/
# wget http://ftp.iij.ad.jp/pub/linux/fedora/epel/5Server/i386/asciidoc-8.1.0-1.el5.noarch.rpm
# wget ftp://ftp.iij.ad.jp/pub/linux/fedora/epel/5Server/i386/perl-Error-0.17010-1.el5.noarch.rpm
# rpm -ivh ./asciidoc-8.1.0-1.el5.noarch.rpm
# rpm -ivh ./perl-Error-0.17010-1.el5.noarch.rpm

パッケージの作成ディレクトリにソースをダウンロード

# cd /usr/src/redhat/SOURCES/
# wget http://www.kernel.org/pub/software/scm/git/git-1.7.3.tar.gz

specファイルを取り出してSPECSディレクトリに移動

# tar zxvf ./git-1.7.3.tar.gz git-1.7.3/git.spec
git-1.7.3/git.spec
# mv ./git-1.7.3/git.spec /usr/src/redhat/SPECS/

不要なディレクトリは削除します

# rm -rf ./git-1.7.3

SPECSディレクトリに移動してビルド開始

# cd /usr/src/redhat/SPECS/
# rpmbuild -bb --clean git.spec

こんな感じで作成されます

# tree /usr/src/redhat/RPMS/
/usr/src/redhat/RPMS/
|-- athlon
|-- geode
|-- i386
|   |-- git-1.7.3-1.i386.rpm
|   |-- git-all-1.7.3-1.i386.rpm
|   |-- git-arch-1.7.3-1.i386.rpm
|   |-- git-cvs-1.7.3-1.i386.rpm
|   |-- git-debuginfo-1.7.3-1.i386.rpm
|   |-- git-email-1.7.3-1.i386.rpm
|   |-- git-gui-1.7.3-1.i386.rpm
|   |-- git-svn-1.7.3-1.i386.rpm
|   |-- gitk-1.7.3-1.i386.rpm
|   |-- gitweb-1.7.3-1.i386.rpm
|   `-- perl-Git-1.7.3-1.i386.rpm
|-- i486
|-- i586
|-- i686
`-- noarch
7 directories, 11 files

あとはrpmコマンドでインストールすればOKです


すぐに消すテスト環境なのでrootユーザーで作業をしています。
各自の環境でビルドする時は一般ユーザーでビルドして下さい。
投稿者 時刻:
ラベル: , , ,

2010年7月19日月曜日

Rackspace Cloud導入記その5(サーバー起動後にやる10の事)

前回までのエントリでサーバー起動、Server Imageの作成、サーバー停止という一連の動作を確認する事が出来ました。
今回はRackspace Cloudの具体的な操作ではなく、サーバーを起動させた後にまず行うべき事を簡単にまとめておきたいと思います。
サーバーを起動させたは良いものの、起動させたサーバーがクラックとかされたら大変ですからね。

  1. ロケールの変更
    起動直後は"en_US.UTF-8"になっているので"ja_JP.utf-8"に変更
    # vi /etc/sysconfig/i18n
    1 #LANG="en_US.UTF-8"
    2 LANG="ja_JP.utf-8"
    3 SYSFONT="latarcyrheb-sun16"

  2. タイムゾーンの変更
    起動直後はアメリカ時間になっているので日本時間に変更しましょう
    障害時に日本時間の方が分かりやすいです
    # cp /usr/share/zoneinfo/Japan /etc/localtime
    cp: overwrite `/etc/localtime'? y
    # date

  3. 外部NTPサーバーと時刻同期をする
    Rackspace CloudはホストOSと時刻同期はしてくれないようです
    サーバーがアメリカなので同期先もアメリカのサーバーにしました
    今回は米国標準技術局と同期しています
    # yum install -y ntp
    # crontab -e
    1 MAILTO=""
    2
    3 */5 * * * * /usr/sbin/ntpdate time-nw.nist.gov && /sbin/clock -w

  4. ユーザーディレクトリのひな形を作成
    これ以降作成するユーザーのホームディレクトリのひな形を作ります
    # mkdir -m 700 /etc/skel/.ssh
    # touch /etc/skel/.ssh/authorized_keys
    # chmod 600 /etc/skel/.ssh/authorized_keys

  5. 一般ユーザーの作成（例：oko_chang）
    なんでもrootで作業するのはやめましょう（自戒の念を込めて）
    # useradd oko_chang
    # passwd oko_chang
    Changing password for user oko_chang.
    New UNIX password:
    Retype new UNIX password:
    passwd: all authentication tokens updated successfully.

  6. ssh公開鍵と秘密鍵のペアを作成し、公開鍵を登録
    【Mac OS Xでssh公開鍵と秘密鍵のペアを作成する方法】
    $ ssh-keygen
    Generating public/private rsa key pair.
    Enter file in which to save the key :
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:

    秘密鍵「id_rsa」と、公開鍵「id_rsa.pub」が作成されます。
    デフォルトでは.ssh/以下に作成されます。

    公開鍵の中身をコピーして一般ユーザーのauthorized_keysに登録。

  7. rootユーザーのパスワード変更
    デフォルトのパスワードを使用するのはやめましょう
    # passwd
    Changing password for user root.
    New UNIX password:
    Retype new UNIX password:
    passwd: all authentication tokens updated successfully.

  8. sshdの設定を変更する
    root接続禁止、パスワード認証無効化、公開鍵認証方式の有効化
    # vi /etc/ssh/sshd_config
    39 PermitRootLogin no
    44 PubkeyAuthentication yes
    45 AuthorizedKeysFile .ssh/authorized_keys
    60 PasswordAuthentication no
    # /etc/rc.d/init.d/sshd restart

  9. iptablesの設定
    Rackspace Cloudはサーバー毎でF/Wを設定する必要があります
    sshの接続元IPが固定されている場合は他は拒否してしまいましょう
    # iptables -D RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
    # iptables -I RH-Firewall-1-INPUT 9 -p tcp -m state --state NEW -m tcp -s xxx.xxx.xxx.xxx --dport 22 -j ACCEPT
    # /etc/rc.d/init.d/iptables save

  10. ソフトウェアのアップデートの実行
    # yum update -y

以上、簡単に思いつくものを記載しました。
Rackspace CloudのCentOSは最小構成となっているので必要なソフトウェアは随時インストールして下さい。
新しいサーバーソフトウェアをインストールした場合はiptablesの設定を確認する事もお忘れなく！
投稿者 時刻:
ラベル: , ,
登録: 投稿 (Atom)