半袖野郎 blog.hansode.org

OSインストール直後にパッケージを追加インストールしようとした

外界への通信は可能だ。はてさて。

検証環境

• OpenSolaris snv_134

$ pfexec pkg install [package]
pkg: 0/1 catalogs successfully updated:

Unable to contact valid package server
Encountered the following error(s):
Unable to contact any configured publishers. This is likely a network configuration problem.

原因

• hostエントリの名前解決対象にDNSが無かったから

対応方法

• /etc/nsswitch.confを修正
• hostエントリに"dns"を追加

$ pfexec vi /etc/nsswitch.conf
< hosts:        files
> hosts:        files dns

$ pfexec pkg install [package]

これで無事にパッケージインストール出来るようなった。

あと書き

きっと、OSインストール後の必須作業なのだろう。

OpenSolarisスタートアップバイブル

posted with amazlet at 11.08.18

大津 真 まえだ ひさこ
毎日コミュニケーションズ
売り上げランキング: 293310

Amazon.co.jp で詳細を見る

『○○コマンドだったら、やりたい事をすぐに出来るのに…』

使い慣れたパッケージマネージャならば鼻歌交じりに操れる事が、使い慣れないパッケージマネージャではオプションが分からなく、イライラする事はないだろうか？

自分の場合、普段はUbuntuでapt-get/apt-cache/dpkgを使い、パッケージ操作をする。その一方で、使い慣れないOpenSolarisのpkgコマンドでは、やりたい事を実現させるまでに費やす時間が長くなる。凄くもどかしい。

Ubuntuで良く使う操作に対応するOpenSolarisのコマンドを表にしてまとめてみた。 これで効率アップした。yum/rpmを使う時も同じ現象にブチ当たる。

対応表

あと書き

自分のネイティブ・パッケージマネージャは、apt/dpkg。

参考サイト

• OpenSolarisのIPS、pkgコマンドの利用方法

OpenSolarisスタートアップバイブル

posted with amazlet at 11.08.14

大津 真 まえだ ひさこ
毎日コミュニケーションズ
売り上げランキング: 70488

Amazon.co.jp で詳細を見る

サーバを新調する度に幾つものコマンドを実行するのか？

新プロジェクトが発足する度に開発環境が用意される事は、良くあるはずだ。 そして、その度に、使い慣れた環境へと変身させる作業が発生するはずだ。 中には何も設定しない人も居るのだろうか？ 何も無い環境だと、どうしても作業し辛い。その要因の大半は、いつもの使い慣れた環境とは違うからだ。

数年前、CodeReposにdotfilesとして個人環境設定を登録する流れが発生した。この流れに自分も少し乗っかり、emacsの設定をコミットしてみた。 使い慣れた環境の設定を登録しているだけだったので、その時には気付いていない、新規調達サーバ・開発環境をリプレースした際、素早く環境整理する仕掛けまでは用意していない自分が居た事に。

きっかけは開発環境の移行

Wakame-VDCの開発をアメリカからしてる時の事。アメリカの通信回線の細さに対し次第にストレスを感じ始める。Wakame-VDCの開発環境は、東京事務所内に置いてある物理サーバを使っていたのだ。これまでの開発スタイルは、

• 開発サーバへSSH接続してログイン
• emacsでプログラムを書く
• コマンドラインでコンポーネントを起動・停止

これをアメリカから行っていると、日本の10年以上前のダイアルアップ接続をしていた頃の様な速度になる時がある。YouTubeで動画を見たり、OSのインストールイメージをダウンロードしている時だ。東京に居たら考えられない事が、アメリカの通信事情では起こり得る。

通信状況に不満を覚えた自分は、『手元のラップトップに開発環境を構築してしまえば解消するはずだ。』 そう思い、開発環境移行に着手した。開発に必要となるOSは2つで、UbuntuとOpenSolaris。 Windows 7にインストールしたVirtualBoxで仮想マシンを用意し、2つのOSをインストール。ここまでは実に順調だ。しかし、この後だ。開発環境整理が待ち受けていた訳だ。

1. GitHubにdotfilesを作成、コミット
2. dotfileをデプロイする仕掛け・・・が無い
3. デプロイする仕掛けをシェルスクリプトで作り始めた

これらが、スクリプト作成に着手するまでに至る過程だ。

異なるOS、異なるユーザー名に対応させる

OSが2種類あり、作業するUNIXユーザー名も違う。いつも同じユーザー名を使えるとは限らない。 汎用性を重要視し、下記3つの事に注意してスクリプトを書き上げ、Gistに登録した。(※スクリプトのソースコードは、エントリ後半に埋め込んである。)

• OSに依存しない事
• ユーザー名に依存しない事
• ファイルシステムのフルパスに依存しない事

スクリプトを実行しさえすれば、使い慣れた環境の一歩手前、必要最低限の環境が手に入る。 一歩手前なのかは、アプリケーションインストールまでを行わないからだ。

スクリプト化した事により、新環境へ移行せざるを得ない状況になっても一撃必殺で作業が終わる。 細かい制約を挙げると、事前にGitをインストールしておく必要がある訳だが…大した問題ではない。 スクリプト化後は、大幅に作業工数が減った。

ギーク達がどのように個人的開発環境を新規構築しているのかが気になる。 『開発環境構築手順を晒すブーム』が到来してくれないだろうか？

あと書き

変化を好機と位置づけ、それを楽しめ

個人的な環境を構築するスクリプト

この環境は個人使用に特化しているので、万人が使って幸せになれる訳ではない。

詳解 シェルスクリプト

posted with amazlet at 11.08.13

Arnold Robbins Nelson H. F. Beebe
オライリージャパン
売り上げランキング: 95612

Amazon.co.jp で詳細を見る

踏み台ノードを経由し、内部ノードへssh接続

管理など、各種理由で踏み台サーバを経由する事がある。

手元ノード -> 踏み台ノード(step.project-a) -> 内部ノード(internal.project-a)

sshならば一度踏み台ノードへssh接続し、そこから内部ノードへsshすれば良いかも知れない。 しかし、scpの場合はどうだろうか？ 一度、踏み台ノードへファイルをコピーし、踏み台ノードから内部ノードへscpする事になり、時間とコストの無駄が明らかだ。どうにかして、一回のscpだけで済ませたい。

要件定義

• 踏み台を意識せず、内部ノードへssh接続
• 利便性を求め、ノーパスログインを行なう

作業概要

1. 手元ノードにて、ssh接続するノードの数だけキーペアを作成
2. ssh接続先に、それぞれ公開鍵を登録
3. 手元ノードのssh_configを修正し、多段ssh用設定を追加

作業内容

▼キーペア作成(踏み台ノード用、内部ノード用)

$ mkdir ~/.ssh/keys
$ cd ~/.ssh/keys
$ ssh-keygen

$ ssh-keygen -N "" -f common@step.project-a.hansode.pem -C common@step.project-a.hansode.pem
$ ssh-keygen -N "" -f hansode@internal.project-a.hansode.pem -C hansode@internal.project-a.hansode.pem

※手元のノードに全てのキーペアを持っている必要がある。

▼踏み台ノードに公開鍵を登録

$ ssh step.project-a -l common
step$ cat <<EOS >> ~/.ssh/authorized_keys
ssh-rsa A...== common@step.project-a.hansode.pem
EOS

▼内部ノードに公開鍵を登録

step$ ssh internal.project-a -l hansode
internal$ cat <<EOS >> ~/.ssh/authorized_keys
ssh-rsa A...== hansode@internal.project-a.hansode.pem
EOS

▼~/.ssh/configを修正

$ vi ~/.ssh/config
Host step.project-a
        User common
        IdentityFile ~/.ssh/keys/common@step.project-a.hansode.pem

Host internal.project-a
        User hansode
        IdentityFile ~/.ssh/keys/hansode@internal.project-a.hansode.pem
        ProxyCommand ssh step.project-a nc %h %p

ProxyCommandに設定されているssh接続先が踏み台ノードに成っている事が重要。

▼ssh接続確認

$ ssh internal.project-a

踏み台を意識せず、内部ノードへログイン出来れば良い。

あと書き

「踏み台→内部ノード」の鍵も手元ノードに持っておかなければ行けない事に気付くまで時間がかかった。

Bazzar用リポジトリを作る

▼要件定義

• Bazzrをsftpで使用
  • ログインシェルは不要
• 共通UNIXアカウント「bzr」を使用
• 利用者は公開鍵を「bzr」に登録

▼検証環境

• Ubuntu 10.04.1 LTS
• OpenSSH 5.3p1-3ubuntu4
• Bazzr 2.1.1-1

作業内容

リポジトリサーバ編

▼共通UNIXアカウント「bzr」を作成

$ sudo groupadd bzr
$ sudo useradd -g bzr -d /home/bzr -s /bin/false -m bzr

UNIXアカウント、UNIXグループ共に「bzr」とする。

▼chrooted sftp(chrooted ssh)環境設定

$ cd /etc/ssh
$ sudo cp -pi sshd_config sshd_config.0
$ sudo vi sshd_config

$ diff sshd_config.0 sshd_config
75c75,76
< Subsystem sftp /usr/lib/openssh/sftp-server
---
> #Subsystem sftp /usr/lib/openssh/sftp-server
> Subsystem sftp internal-sftp
77a79,82
>
> Match user bzr
> ChrootDirectory /home/chroot/bzr
> ForceCommand internal-sftp

$ sudo initctl restart ssh

▼chrooted sftp用ディレクトリを作成

$ sudo mkdir /home/chroot
$ sudo mkdir /home/chroot/bzr

▼bzrユーザーに公開鍵を登録

$ sudo su -m bzr
bzr$ cd /home/bzr
bar$ mkdir .ssh
bar$ chmod 700 .ssh
bar$ cd .ssh
bar$ cat <<EOS >> authorized_keys
...
(bzrユーザーの公開鍵をペースト)
...
EOS
bar$ chmod 600 authorized_keys

bar$ exit

▼bzrリポジトリを作成

$ cd /home/chroot/bzr
$ sudo mdkir repos
$ sudo chown bzr:bzr repos
$ sudo su -m bzr

bzr$ cd /home/chroot/bzr/repos
bzr$ bzr checkout lp:nova
[28075] 2011-01-06 07:23:58.313 INFO: Branched 521 revision(s).
Branched 521 revision(s).

bzr$ exit

ここではサンプルとして「nova」のブランチを作成している。

作業用サーバ編

▼必要に応じてsshクライアント設定

$ cd
$ vi .ssh/config
Host host
        Hostname bzr-host.example.com
        IdentityFile ~/.ssh/bzr.pem

ssh用設定はbzrコマンドで指定出来ないので.ssh/configで設定しておく。

▼sftp接続確認

$ sftp bzr@host
Connecting to host...
sftp> pwd
Remote working directory: /

sftp> ls -la
drwxr-xr-x    3 0        1002         4096 Jan  6 03:17 .
drwxr-xr-x    3 0        1002         4096 Jan  6 03:17 ..
drwxrwsr-x    3 1002     1002         4096 Jan  6 07:10 repos

sftp> ls -la repos/
drwxrwsr-x    3 1002     1002         4096 Jan  6 06:10 .
drwxr-xr-x    3 0        1002         4096 Jan  6 03:17 ..
drwxrwsr-x   13 1002     1002         4096 Jan  6 07:24 nova

sftp> quit

ログイン後、リモートワーキングディレクトリが「/」となっている。
「repos」ディレクトリ、及び「repos/nova/」を確認出来れば問題ない。

▼チェックアウト確認

$ bzr checkout sftp://bzr@host/repos/nova

作業環境にチェックアウト出来れば確認完了。

参考ページ

• OpenSSH SFTP chroot() with ChrootDirectory

仮想環境にVLANを導入する為の準備

▼検証環境

• Ubuntu 10.04.1 LTS
• Linux 2.6.35-22-server

▼設定項目

• 物理NIC名: eth0
• VLAN ID: 100

事前準備

▼必須パッケージをインストール

$ sudo apt-get install vlan

作業内容

▼システム起動時に読み込むモジュールに「8021q」を追加

$ sudo vi /etc/modules
> 8021q

▼一時的に動的反映

$ sudo modprobe 8021q
$ lsmod | grep 8021q

次回のシステム起動時には/etc/modulesに追記されているのでmodprobeコマンドを実行する必要はない

▼eth0にVLAN ID 100を認識させる

$ sudo vi /etc/network/interfaces
> auto eth0.100
> iface eth0.100 inet manual
>         up ifconfig eth0.100 up

▼ネットワーク設定再起動

$ sudo /etc/init.d/networking restart
...(省略)...
Set name-type for VLAN subsystem. Should be visible in /proc/net/vlan/config
Added VLAN with VID == 100 to IF -:eth0:-
...(省略)...

今回はinterfaceを追加するのが目的なので、IPアドレスの設定はしてない。

ビフォー

西新宿事務所へ引越ししてから1年半が経過。
引越ししてから、サーバ3台とストレージ2台が増加した。
その後、何度か構成変更しつつも、電源ケーブルが酷い状況になってしまった。

▼継ぎ接ぎだらけ

この状態でも、一週間前に一度整理した状態。
しかし、何となくLANケーブルの整理が行われただけで、電源ケーブルは未着手のまま。

作業開始

整理するにあたり、重視した項目。

• 電源ケーブル整理
• LANケーブル整理
• コンパクト収納

▼スパゲディコード

酷い。とにかく、酷い。
何かを追加するたびに「マズイ…」と思いつつも、改善しないままだった。

アフター

▼スッキリ収納

今までの作業で不便だった事を改善すべく、工夫して整理した。

• 電源
  • ラック背面にて、棚の1段1段、レールに電源タップを結束
• スイッチ、ルータ
  • 中段に集約
  • ポートがある側を表へ出す
• サーバ
  • サーバ背面を、表に出す
  • ⇒ サーバ前面にあるのは電源ボタン程度で、主な作業対象は背面
• ケーブル
  • ケーブルとLANケーブルをレールに結束

結果

約1/2へと縮小された

• 費用
  • 電源タップ: 6個口x3本 (1,980x3)
  • LANケーブル: カテゴリ6A (840x5)
  • 結束バンド: 30本(168)
• 時間
  • 9時間

感想

• @hokkeさんによる、hbstudy#16『ラッキング、ケーブリングまわりのお話』が役に立った
• ケーブル類は同メーカー、同種類で揃える方が綺麗にまとまる
• サーバの作業対象は裏側が多いので、前面が表に出てる必要はない
• 時間を甘く見積もっていたので、土日が潰れた
• サーバが機動して来て安心した

サーバ用途には日本語が邪魔

忘れないように自分向けメモ。

意図せず日本語環境になっていてビックリする事が時々ある。
Debian系のシステム環境を変更するには、/etc/default/配下のファイルを修正。

▼検証環境

• Ubuntu 10.04 LTS

▼/etc/default/localeを修正

$ sudo vi /etc/default/locale
LANG="en_US.UTF-8"

図解でわかるLinux環境設定のすべて

posted with amazlet at 10.10.01

西村 めぐみ
日本実業出版社
売り上げランキング: 11300

Amazon.co.jp で詳細を見る

PHPからcurlを使うと何が良いのかは不明

要望があったので設定。

▼検証環境

• Ubuntu-8.04 LTS
• Linux 2.6.24-6-xen

▼環境構築

$ sudo apt-get install php5-curl
$ sudo /etc/init.d/apache2 restart

▼テストコード

<?php

if ($ch = curl_init('http://www.google.com/')) {
  echo curl_exec($ch);
  curl_close($ch);
}

この場合、Googleのトップページが表示されれば良い。

ジョブ処理しないので、Hinemos Agent不必要

『Hinemos』を監視システムとして利用したい。

この場合、Hinemos Agentを利用したジョブ処理は不用。
Hinemos Agentはインストール不用で、snmpdの設定さえあれば良い。
「果たして、Hinemosを使う意味があるのか…？」と言う事は、今回の議論の対象外とする。

▼動作実績環境

• Amazon EC2
• Ubuntu 8.04 LTS(x86_64)
• Linux 2.6.24-6-xen
• Hinemos 3.1.4
• snmp 5.4.1~dfsg-4ubuntu4.3

作業内容

監視対象ノード

▼snmpdインストール

$ sudo apt-get -y install snmpd

▼使用IPアドレスを変更

$ sudo cp -pi /etc/default/snmpd /etc/default/snmpd.0
$ sudo vi /etc/default/snmpd
$ diff /etc/default/snmpd.0 /etc/default/snmpd
11c11,12
< SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid 127.0.0.1'
---
> #SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid 127.0.0.1'
> SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid 0.0.0.0'

▼managerからシステム情報を取得可能に設定変更

$ sudo cp -pi /etc/snmp/snmpd.conf /etc/snmp/snmpd.conf.0
$ sudo vi /etc/snmp/snmpd.conf
$ diff /etc/snmp/snmpd.conf.0 /etc/snmp/snmpd.conf
61,62c61,62
< com2sec paranoid  default         public
< #com2sec readonly  default         public
---
> #com2sec paranoid  default         public
> com2sec readonly  default         public

▼snmpd再起動

$ sudo /etc/init.d/snmpd restart

Hinemos Manager

▼システム情報取得可能かどうかを確認

$ snmpwalk -v 1 -c public [ 監視対象IPアドレス ] .1.3.6.1

※HOST情報を取得出来れば良い

あと書き

今回は、Amazon EC2のセキュリティグループ設定があるのでsnmp接続許可設定を無視している。
その他環境では、snmp接続の許可・拒否を考慮すべき。